I'm using Windows Search API, which returns mapi URLs.
How can I find the file which contains the data for the URL? E.g. the path to the PST file from which that message came?
How can I programatically get the contents or data of the MAPI message (i.e. as opposed to just opening it up with the shell).
Usually MAPI allow you to invoke a method that retrieves a IMAPITable associated to an object and then sets its columns accordingly to the properties you want to query
check this out
]
Related
If you have some application with an ordinary HWND, is it possible to embed an Outlook email .msg file into the window using OLE?
It appears that, after opening an Outlook message using OpenSharedItem, you can successfully QueryInterface for IOleObject. But after that, I can't seem to successfully call any IOleObject methods.
Thanks for any input.
MSG file format is well-described in MSDN. So, you can read the content without any third-party components or interfaces. To display the content (I guess the message body) you can use any web browser (for example, WebView2). The message body (HTMLBody) is represented by a regular web page. Most probably you will also need attached files that are used in the body.
Another possible alternative to use Extended MAPI for getting item properties. For example, you can use any third-party components for simplifying the work - Redemption.
When I try this with messages that are opened from a .msg file on disk and contain attachments, IMAPIProp::CopyTo returns 0x80070005 (MAPI_E_NO_ACCESS).
Standalone MSG files implementation has more bugs than a bait store. CopyTo also does not correctly remap named properties.
I always use my own implementation that calls GetPropList / SetProps excluding some properties, copies recipients, and processes attachments recursively (since they can contain embedded messages).
I am getting the currently selected mailItem from the explorer and saving it to the local file system. The file is then being uploaded to a server. My problem is sometimes the server (which I have no control over) returns that the file format is invalid.
I save the mailItem with the following code:
oMailItem.SaveAs("C:\path\savedEmail.msg")
This creates a file which is 174kb in size. If I add the OlSaveAsType of olMSG then I get the same file size.
If I save the exact same email with the Outlook UI then the chosen/suggested Message format is Unicode. This produces a file of about 251kb ie. much bigger. If I save it with the above code and olMSGUnicode then I also get the same file size.
I am therefore assuming that leaving out the OlSaveAsType option saves the mailItem as an olMSG.
I am currently also assuming that this may be causing some issues with the upload to the server.
What property of a mailItem tells me which OlSaveAsType to use? Can I safely use olMSGUnicode for all saves?
Yes, you can safely use olMSGUnicode format on all modern versions of Outlook.
But the real problem is why the server (?!) returns an error that the format is invalid? Was it corrupted? Can you successfully open the same file you sent to the server? You need to figure out why that error is returned.
I am using Outlook.Attachment attachment object in my C# Outlook AddIn. But the attachment object doesn't have any field which suggest what is the full source path of the file being attached.
The attachment object has the following fields/methods, but they are not helpful.
attachment.DisplayName
attachment.FileName
attachment.GetTemporaryFilePath()
There is no such thing - attachment does not have to come from the file system even it is created. After its is inserted, it is stored outside of the file system alongside messages in the store.
I was just wondering something and I could not find it.
Is it possible to make a custom file format that is searchable by Windows? Like Word or HTML files are searchable.
I've written a program that has a custom file format (extension) associated. It would be nice if windows could search inside that file.
It looks rather involved. Essentially, you provide an implementation of a COM interface for your file type, which lets the search indexer discover what's in your file.
From MSDN:
You can extend Windows Search to index the contents and properties of new file formats, and data stores using data add-in interfaces. To create Windows Search add-ins, third-party developers must first implement a Shell data store, and then develop a protocol handler so that Windows Search can access the data for indexing. If you have a custom file format, you must develop a filter handler to index file contents, and a property handler for every file type to index properties.