I am trying to add pst store from outlook addin using Redemption with the code:
RdoSession = Redemption.RedemptionLoader.new_RDOSession();
RdoSession.MAPIOBJECT = (AddinModule.CurrentInstance as AddinModule).OutlookApp.Session.MAPIOBJECT;
string path = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) + #"\Microsoft\Outlook\mystore.pst";
RDOStores stores = RdoSession.Stores;
RDOStore store = stores.AddPSTStore(path, Outlook.OlStoreType.olStoreDefault, "test");
Line stores.AddPstStore throws System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure and it creates mystore.pst in correct location with the size of 265 KBs. New store/data file is not displayed in outlook and it does not apear in RdoSession.Stores on next execution. So my program tries to create it again (since it didint found it) and then same line crashes with:
System.InvalidCastException: Error in IMsgServiceAdmin::AdminProviders: MAPI_E_INTERFACE_NOT_SUPPORTED
Using office PIAs code works without any problems:
https://msdn.microsoft.com/en-us/library/office/bb612380.aspx
I would keep redemption code since there is much more logic around it. I just moved these 5 lines to the begining of function to isolate the problem.
MAPI has a few marshaling bugs in the profile management interfaces (such as IMsgServiceAdmin).
Try to replace setting the RDOSession.MAPIOBJECT property with calling RDOSession.Logon.
Is you code running in a Outlook addin or a standalone app?
Related
Trapping Excel COM errors from a VFP program.
A program is writing out an extract from several large tables to Excel using Automation.
Typical instructions include :
lCell = "I1234”
.sSheet1.Range(lCell).value = cCust.Name
This generally works fine, but if cCust.name has a value such as ‘=’ (which Excel does not like), this causes an OLE COM error.
Had tried using TRY .. . CATCH . . . ENDTRY to trap this error, but the OLE COM error still reports.
I suppose that I could find out all the possible errors in the data and clean them up, but is there any way of getting Automation to ignore the error and carry on (leaving the field unpopulated)?
Thank you.
I am adding this as an answer, since it contains some code that would otherwise cause a mess. With ON error it is working perfectly fine for me. ie:
*** Constant Group: XlSaveAction
#Define xlDoNotSaveChanges 2
#Define xlSaveChanges 1
Local loExcel As Excel.Application
Local lcValue
loExcel = Createobject('Excel.Application')
loExcel.Workbooks.Add()
loExcel.ActiveWorkbook.SaveAs('c:\temp\ExcelReadTest.xlsx')
loExcel.DisplayAlerts = .F.
*loExcel.Visible = .T.
On Error lcValue = .Null.
With loExcel.ActiveWorkbook.ActiveSheet
.Range('A5').Value = '=Like me'
lcValue = .Range('A5').Value
? m.lcValue
Endwith
On Error
loExcel.ActiveWorkbook.Close(xlSaveChanges)
loExcel.Quit()
I had this error pop up on exactly the 3rd line of code below. There seem to be no explanation on the Internet for this behaviour.
I'm looking at why this error came up, and fixed itself after few minutes.
Set Ftp = CreateObject("Reflection.FTP.3")
Ftp.Open "xxx.xxx.xxx.xxx", "username", "password"
Ftp.SetCurrentDirectory "DirectoryName/DirectoryName/DirectoryName"
What was the error?
Run-time error '-2147418113 (8000ffff)':
Method 'SetCurrentDirectory' of object 'IReflectionFTP' failed
More details:
Application: Excel Macro
Language : VB (VBA)
*Is this because of a coding error? *
Not likely. The macro has been long running and this came up for the first time.
*Is it because of a FTP service disruption? *
May be. But logs have a recording for every second and there seems to be no outage.
It seems to me there is a connection problem here - maybe a timeout? I assume that your three lines of code don't execute one after another (ie the SetCurrentDirectory is after some more code). This error will come up if the Ftp object doesn't have a valid connection that is logged in. Change the IP for the Open command to an invalid one and you'll see you get the same error.
Try setting the following line of code before SetCurrentDirectory command.
If FTP.Status = rcLoggedIn + rcConnected Then
Ftp.SetCurrentDirectory "DirectoryName/DirectoryName/DirectoryName"
Else
'Error handle
End If
Note, that you are late binding the object so for it to work for you, you'll need the If statement to be:
If FTP.Status = 17 Then
Also, if it is a timeout problem then I'd set the Timeout period for the session to be longer, ie FTP.TimeoutSession = 300.
I am trying to open word Template from AX 2012 Reports. It works fine in the env I have developed but when I try to execute the same from different login I face the "COM error"
Please help.
You can always find help for these mysterious Office error codes by decoding the error code. COM error codes contain three major parts:
the top 4 bits indicate the severity of the error. 8 means "warning", one you can't ignore
the next 12 bits is the facility code, the origin of the error. 10 means "automation"
the lower 16 bits is the internal error code, the one that you really care about.
Switch your calculator to hex mode, 0x175d is error code 5981. Now turn to Google and query "word error 5981".
Lots of good hits, you can read them at your leisure. But clearly there's a problem with macros on that machine. Best left to the IT staff at your site, use superuser.com if you need more help with that.
I have a VB.Net program written with .Net 2.0
I'm trying to write a code that logs entire registry entries into a log file.
I have got it to work wit the following code.
http://pastebin.com/kmA63cUe
However whenever I try to add an additional Registry key to log
LogPrint4("<-----------------HKLM/WebCheck-------------------->")
If reg.enumvalues(&H8000002, "Software\Microsoft\Windows\CurrentVersion\WebCheck", keys2, types) = 0 Then
If IsArray(keys2) Then
For p = 0 To UBound(keys2)
reg.getstringvalue(&H8000002, "Software\Microsoft\Windows\CurrentVersion\WebCheck", keys2(p), value)
LogPrint4(keys2(p) & "=" & value)
Next
End If
End If
It comes up with the following error
COMException was unhandled Check the ErrorCode Property of the
exception to determine the HRESULT returned by the COM object.
I'm not sure why it is limiting it only to 5 checks.
Anyone have any ideas?
Consider using the built-in Registry support instead of the COM libraries. At a minimum, you'll get clearer error messages. It is supported in .NET 2.0.
http://msdn.microsoft.com/en-us/library/microsoft.win32.registry(v=vs.80).aspx
Good luck!
I'm working on project, which main goal is synchronization between outlook's calendar and our application's calendar. In our application, we are using custom programming language and we are mapping outlook functions through dispatchId.
And here comes my problem. I'm using StorageItem in Outlook calendar for saving some internal data, but when I try to call GetStorage method, from time to time it ends with Exception.
Exception message is "Incorrect function" (its translated from czech "Nesprávná funkce").
I'm calling GetStorage in different folders (calendars), in different data stores (.pst). When I try to call GetStorage method right from vsto addin, it works everytime. But calling it within our app through COM, its just pain.
I cannot induce exact behavior, it looks like it happens randomly.
Syntax:
oFolder := oNS.GetFolderFromID(OFolderID,''); // ok, folder found
if oFolder <> nil then begin
oStorageItem := oFolder.GetStorage('Synchronization.Info', 0); // exception
if oStorageItem.Size > 0 then
Result := False;
end;
Example situation:
First datastore:
calendar called "firstCal"
calendar called "secondCal"
Second datastore:
calendar called "thirdCal"
Calling getStorage:
calling firstCal.GetStorage - Exception
calling secondCal.GetStorage - ok
calling thirdCal.GetStorage - ok
.. and other random combinations
I've finally found a solution thanks to this thread http://www.delphigroups.info/2/11/941254.html.
"Delphi raises an error it is anything but S_OK (0), but VB(Visual Basic) checks if it is>0 (that's what SUCCEEDED macro/function does)."
Our custom language is based on Delphi. GetStorage function call result was 1, and we were expecting S_OK (0) if call was ok.