I have code to generate an email based on data on a userform.
It worked for a long time across multiple machines, but when I changed machines it started throwing a run-time error 13 type mismatch on on the CreateItemFromTemplate method in the following section:
Private Sub AcaoEnviar_Click()
Dim OutlookApp As New Outlook.Application
Dim EmailKRI As Outlook.MailItem
Set EmailKRI = OutlookApp.CreateItemFromTemplate(PATH_EMAIL_TEMPLATE)
The code still runs on other machines, suggesting the problem is local. My Outlook library is the same as on the other machines, and the only difference I´m aware of is that I´m running it on a 64-bit system and 32-bit office, while most others have 32-bit systems (one other has the same 64-bit setup and runs fine).
Changing the object declaration from Outlook.MailItem to Object seems to solve the problem, which I think eliminates problems with Outlook's programmatic access, and in any case, my Antivirus status is valid.
I'm still confused as to why such an error would occur only with me.
Is there any solution so that I can go back to early binding for that email object?
You will get that error if CreateItemFromTemplate returns something other than MailItem object. Are you sure the OFT file is for a regular mail item.
As a test, declare EmailKRI as a generic Obejct and at run time check the value of the EmailKRI.Class property. It is supposed to be 43 (OlObjectClass.olMail) for the regular MailItem objects.
Related
I know it has been asked so many times, but I've gone through dozens of pages, with no luck, since mine seems to be a OS/machine related problem rather then of a specific library.
Trying to manage ID3Tags, or in general, files extended properties, it's clear that with a Shell object you can only retrieve them, but can't edit, therefore the only way to do that is using an external DLL (es. CDDBControl, or DSOfile), I can't get them to work, although I apparently successfully installed them with regsvr32 (references are available i.e. in Excel macro dev env.
I tried many ways....using regsvr32 either under System32 or SysWOW64, trying to put the DLLs in different location....but nothing.
Statement raising the error:
Set id3 = CreateObject("CDDBControl.CddbID3Tag")
Please note that a call like
Set FSO = CreateObject("Scripting.FileSystemObject")
instead, gives no error at all.
I just found the solution....hope this could help someone else....
The only way I made it work is to follow the instructions given in the page:
Setting MP3 ID Tags with CDDBControl.dll
Cheers.
Folks,
I'll been fighting this for a few weeks now. We have a proprietary corporate app running on thin clients in our organization. From this app we can apply VBA scripting behind the scenes to do simple functions. In the past adding buttons to open IE and direct them to certain web sites to enter data, open Calc and etc.
Recently I have been working the code below. It was developed on the Server using a RDP session which launches the full desktop and explorer.exe. What I have noticed that if explorer.exe isn't running then the code bombs at line in the function that reads "For Each oWin In oShApp.Windows " with "Run-time error '429'".
However if I script to start explorer.exe (which is bad because it enables the Start-bar and Task-bar) on the ThinClient which launches the desktop and full capabilities and it runs just fine as the Thin Client users that are logged in.
I have read a little bit about the "Limited Shell" that runs when using a remoteapp and not the full desktop and was wondering if there was anyway around it, without enable the start-menu and taskbar?
See the code below.
Thanks for the help, CreteIT
Private Sub cmdHomePage_Click()
Dim ie As Object
Dim sMatch As String
sMatch = "http://www.companyweb.com"
On Error Resume Next
Set ie = GetIEatURL(sMatch & "*")
On Error GoTo 0
If Not ie Is Nothing Then
ShowWindow ie.hwnd, 9
BringWindowToTop ie.hwnd
Else
Dim strHome
Dim strAPP
strHome = "c:\progra~1\intern~1\iexplore.exe www.companyweb.com"
strAPP = Shell(strHome, vbNormalFocus)
End If
End Sub
Function GetIEatURL(sMatch As String) As Object
Dim ie As Object, oShApp As Object, oWin As Object
Set oShApp = CreateObject("Shell.Application")
For Each oWin In oShApp.Windows
If TypeName(oWin.Document) = "HTMLDocument" Then
Set ie = oWin
If LCase(ie.LocationURL) Like LCase(sMatch) Then
Set GetIEatURL = ie
Exit For
End If
End If
Next
Set oShApp = Nothing
Set oWin = Nothing
End Function
I work on the RemoteApp team at Microsoft. I'm not quite clear whether you're running this script from an actual RemoteApp session or your own setup that has a different shell that replaces explorer.exe (or perhaps no shell at all), but either way the answer is about the same.
The Shell.Application ActiveX object your script is trying to instantiate appears to be implemented by the shell - typically explorer.exe. If that isn't running, the COM runtime won't be able to create an instance of the object, and when you try to activate it you'll get an error.
The obvious solution is to run explorer.exe but, as you observed, that also includes the taskbar and start menu, which you might not want. RemoteApp runs its own shell replacement (rdpshell.exe), but that doesn't implement Shell.Application, so just running your application under RemoteApp won't fix the problem.
There are a few potential solutions I can think of:
If you're not using RemoteApp, you could write your own replacement shell that does implement Shell.Application. This is quite a lot of work and there might not be a lot of documentation around on how to do it properly. If you already have a replacement shell, you might be able to extend it to implement Shell.Application.
You could use a different method to enumerate windows. Unfortunately this probably means Win32 (via the EnumWindows function), which isn't directly accessible from VB scripts; you might have to create an ActiveX object that implements the behavior you want, and invoke it from the script.
Similar to option 2 but more heavyweight - you could make that ActiveX object implement the whole Shell.Application interface - even though it isn't actually the shell - and register it on the remote machine. I can't guarantee you won't run into problems if you do this though; it isn't something I've tried before.
None of these solutions are ideal, unfortunately, but hopefully something lets you do what you need to.
I have a 1-min delay on all emails and want to assign a category set up as an exception to the rule to send immediately.
I created the macro but it stopped working.
Public Sub CategoriesButton()
Dim Item As Outlook.MailItem
Set Item = Application.ActiveInspector.CurrentItem
Item.Categories = "SendMe"
Item.Save
End Sub
Interesting - I just had the same issue. Working perfectly but then I restarted Outlook and it stopped working - for no apparent reason.
Took me a while to work this out - but when you restart Outlook it applies Macro security permissions to your macro.
If you haven't digitally signed your macro, the default behaviour is to prevent it from running.
You can relax the security settings so that Outlook with either ask your permission to run macros, or just run all macros regardless (this latter option is probably not a good idea!)
You can self-sign your own macro, there's quite a good guide to doing that here: http://www.slipstick.com/developer/how-to-use-outlooks-vba-editor/
But annoyingly it seems you will always get a notification, even with a signed macro... so it's probably easier to just change the security settings to 'notification for all'.
Hope this helps - the code you posted certainly helped me, it was exactly what I was looking for, also to control 1 minute delay!
Man, every time I go near macros in Outlook I end up losing half a day or so...
When calling a 32 bit COM component method registered in sysWOW64 fails with an error message:
"type mismatch in method OleVarToLsVal, Unknown found, Unknown
expected"
Its win7 64 bit, but the Notes client is installed by default as a 32 bit application. The code looks like:
dim c as Variant
dim n as Variant
set c = createobject("MSWC.counters")
n = c.Get("xx")
When debugging the call, the object is set and testable with "isObject(c)", (although you can't inspect each method/property in detail in LotusScript debug).
The method is supposed to return a primitive long. I've tried setting n as long, clng-ing the values, cstr-ing the values, the parameter, strconv the parameter, using a variable for the parameter, all to no avail.
The exact same code run by WScript VBS host (in syswow64) runs the code as expected.
So, does anybody know:
If Notes 9 COM value marshalling is working for any components?
Is Notes 9 COM set to recognize the 'wow64' alternate 32 bit registry
Are there some COM related marshalling settings somewhere in the registry I can check (if so what/where are they)?
Is there some setting to tell Notes to use 32 bit components (like IIS 32bit compatibility option)
Is there anything I need to do or could do in the main OS to 'redirect or configure' COM
Or is Notes just broken again and nobody cares?
Any help appreciated - Thanks.
The easiest and probably most productive way to solve this would be to open a PMR with IBM. They should be able to answer this quite quickly.
Well, 7 years on (and seriously obsolete!) just an update for anybody looking for an answer... There are a couple of Notes settings needed and not all COM/Active-X componenets or data types are supported by LotusScript, so even if Notes is setup correctly, you still may not be able to acces/use any specific component or some methods in the component.
The user must be allowed to run unrestricted agents/code in the 'Sign or run unrestricted methods and operations:' in the security section of the server(s) document.
The Notes client execution control list ('ECL') must allow access to 'External programs' either by default or to the code-signer. An ECL warning box will ask the user to continue if the external access has not been granted.
If you try to execute an unsupported method or unsupported data type, then further errors will be issued either by LotusScript or COM/Active-X error reporting. The Notes developer help file for 'CreateObject' gives a bit more detail about unsupported data types:
LotusScript does not support identifying arguments for OLE methods or properties by name rather than by the order in which they appear, nor does LotusScript support using an OLE name by itself (without an explicit property) to identify a default property.
Results are unspecified for arguments to OLE methods and properties of type boolean, byte, and date that are passed by reference. LotusScript does not support these data types.
Relying on the 'default property' to access a default method is a common mistake and requires you to pay extra attention to the component details. It is easy to assume the component is not working, but in fact you're just not using it properly.
One way to test this is to try to open a common object available on all Windows machines (maybe others?) maybe 'FileSystemObject' (FSO) or VbScript 'regExp' component. If these work, you can build on that. Getting the 32/64bit registration correct for your client install is another element to test/get right.
For my issues, I suspect that I was using unsupported methods or data types and having used COM/Active-X in Notes occasionally, its all worked ok in general.
I'm using the MAPI code by Dave Brooks.
I am attempting to programatically send out a Crystal Report that is generated.
When I run through the code without threading everything runs fine. The problem is when I use threading I get the return error "General MAPI failure [2]".
I have never used threading before and understand that there are dangers involved. Can anyone provide any insight into this issue? NOTE: I've removed exception handling to make the code clearer.
Private Sub RunReport()
SetParameters()
SaveReportFile()
Dim operation As New ThreadStart(AddressOf SendEmail)
Dim theThread As New Thread(operation)
theThread.Start()
End Sub
Public Sub SendEmail()
Dim m As MAPI
m = New MAPI()
Dim email As String
For Each email In emailAddress
m.AddRecipientBCC(email)
Next email
m.AddAttachment(#"c:\temp\report.pdf")
m.SendMailPopup("Requested Report", "")
End Sub
A very late answer, but thought I'd add it anyway as I just encountered this and couldn't find an answer elsewhere.
You need to set your thread's appartment state to STA before it is started using:
theThread.SetApartmentState(ApartmentState.STA);
Note that threads from the threadpool (e.g. used by BackgroundWorker component) are MTA.
I encountered this same error (General MAPI failure [2]) and came across this solution early in my debugging; however, the cause for my error was due to running my application as administrator while outlook was running as my user. I had a hard time finding the cause of my error so hopefully this will help someone on the same search as me.
If the above answer doesn't solve your problem, try running your application without elevated privileges if possible or find a way to call MAPI using user impersonation.