Nektra Advanced Computing Blog

Nektra has released the new WLMailApi v1.0.2

Nektra has released the new WLMailApi v1.0.2, which has many more features & functions, this allows developers to create custom Windows Live Mail plug-ins.

Nektra Advanced Computing is glad to announce the release of the new WLMailApi version 1.0.2 which you can request a download by clicking here. This new version is an update of the official WLMailApi RTM version which has been released over 6 months ago.

Creating addons or plugins for Windows Live Mail Desktop® demands a deep knowledge of its internal behavior, it does not have any public Application Programming Interface.

Windows Live Mail is the desktop email client promoted by Microsoft for Windows XP®, Windows Vista® and Windows 7® as part of the Windows Live Essentials free software.

Contact us to ask any commercial question or use our forum for technical inquiries. For information about pricing or special demos please call 1-(310)237-6506.

The changes for this version are:

* Fixed: Memory leak when moving or deleting many messages left wlmail.exe process running after closing it
* Fixed: WLMail crashed when having an IMAP account
* Fixed: Getting a Toolbar object during the WLMailApiEvents::OnFolderSelectionChange event freezed WLMail
* Fixed the way WLMailApiAgent hooks the WLMail.exe process to avoid WLMailApiLoader.dll to be loaded in every process
* Implemented WLMailApiEvents::OnNewMessageInOutbox event that allows to modify and commit outgoing messages
* Implemented IWLMailApiEvents::OnSendButtonMsgWndClicked which is triggered when a new message window is set to be sent
* Implemented MsgWnd::GetTo(), GetCc(), GetBcc(), GetSubject(), SetTo(), SetCc(), SetBcc() and SetSubject()
* Added IMailAccountManager and IMailAccount interfaces to get the Default Account
* Implemented FolderManager::GetInboxFolder(), GetDraftFolder(), GetSentFolder(), GetJunkFolder(), GetDeletedFolder() for the Default Account
* Implemented Folder::IsInbox(), IsDraft(), IsSent(), IsJunk(), IsDeleted() functions for Default Account special folders
* Implemented FolderManager::GetOutboxFolder() and Folder::IsOutbox functions
* Added Unicode support to main API functions:
IFolderManager::CreateFolder() and RenameFolder()
IFolder::GetName(), Rename(), CreateFolder() and CreateMessage()
IMessage::GetSubject(), GetAllBody(), GetBody(), GetBodyText(), GetBodyDisplayName(), GetFilename() and SaveAsFile()
IMessage: For GetBodyProp() and SetBodyProp() functions, the message must be already encoded in Unicode

Nektra Advanced Computing is glad to announce that we are always working on Windows Live Mail API improvements from all your feedback. Now in our Windows Live Mail API Trial you are able to access the storage folders with read, write, delete, move, rename and clone capabilities. We are also able to append text and or HTML code inside each cloned message. Here is a screen shot of the Message Bodies in our WLMailApi C# Demo and below a video showing more capabilities of our product.

Contact us to ask any commercial question or use our forum for technical inquiries.

Nektra has released the new WLMailApi v1.0.1, which allows developers to create custom Windows Live Mail plug-ins.

Nektra Advanced Computing is glad to announce the release of the new WLMailApi version 1.0.1 which you can request a download by clicking here. This new version of WLMailApi left the Beta stage and is now an official RTM version.

Creating addons or plugins for Windows Live Mail Desktop® demands a deep knowledge of its internal behavior. Its Application Programming Interface (API) is undocumented and there is not a SDK available. Even the public interfaces IStoreNamespace and IStoreFolder supported in both Outlook Express® and Windows Mail® are not present in this new email client.

Windows 7® will not include Outlook Express or Windows Mail; its users will be forced to move to Windows Live Mail. Your product can be one of the first that plugs in!!!

Contact us to ask any commercial question or use our forum for technical inquiries.

This is the change log from previous version:

* Exiting from the system tray icon’s context menu crashed WLMail
* A stack overflow was produced when many database notifications were triggered
* There was a memory leak when handling database events
* C# DLL Demo solution made WLMail freeze after the evaluation expiration message when it was executed in Debug mode
* First events could get lost at startup before the first folder/message selection change event
* WLMailApi::GetCurrentMessageID() always returned -1 at startup until message selection was changed
* WLMailApi::GetCurrentMessageID() and NktWLMailApi::GetFirstSelectedMessageID() responses were not updated after current/selected message was deleted
* The WLMailApiEvents::OnDatabaseChange NKT_TR_INSERT_MESSAGE case was not triggered when messages were inserted in the Deleted Items folder
* Message.Delete(0) did not work when the message was in the Deleted Items folder
* WLMailApiEvents::OnCurrentMessageChanged event was not triggered if the current message was changed by selecting another message using “Ctrl + Click”
* When an unread message was selected in WLMail and was automatically marked as read, two WLMailApiEvents::OnDatabaseChange events (first NKT_TR_UNREAD_MESSAGE and then NKT_TR_READ_MESSAGE) were triggered instead of just one (NKT_TR_READ_MESSAGE)
* ToolbarButton::SetName and SetTooltip did not work if were called after the button was created
* Message::SaveAsFile() output file was corrupt if Message::GetHeader() was previously called
* Improved and corrected C++ and C# DLL Demos
* The solutions of the package now require Visual Studio 2008

The Nektra staff wishes you all a happy new year!

Best regards,

Nektra’s WLMailApi Team

It is hard to find on the internet a detailed and complete solution for modifying the contextual menu due to several reasons.

One of these reasons is that many of the implementations found use the System.Windows.Forms.ContextMenu; you can see one of them here:

Component-Based Development with Visual C#

In these kinds of examples the system menu is not invoked from the ShowContextMenu, instead a user customized menu is. This menu does not allow modifying it as we need.

Another reason is due to the programming language. In the MSDN website a C++ implementation of the ShowContextMenu can be found:

WebBrowser Customization (Part 2)

The problem is that when we want to implement it in C# difficulties such as not being able to call system functions, use the same data types, and many others arise.

Maybe the biggest difficulty can be found when trying to marshall the CComVariant class. A huge variety of solutions can be found on the internet, but they usually do not work (at least in the case mentioned above). Here are some examples of them:

VB Variant Equivalent in C#

Object To Variant

What is the equivalent of Variant data type in C#.NET?

Using the int[] type with size 3 or bigger is one of the ways of solving this.

   1:  int[] variantVar = new int[3];

The VARIANT type can be seen in this MSDN webpage:

VARIANT and VARIANTARG

Once we solved this problem, we can use the IOleCommandTarget function Exec:

   1:  [PreserveSig]

   2:  int Exec(

   3:      ref Guid pguidCmdGroup,

   4:      int nCmdID,

   5:      int nCmdExecOpt,

   6:      // we need to have this an array because callers 

   7:      // need to be able to specify NULL or VT_NULL

   8:      [In, MarshalAs(UnmanagedType.LPArray)] int[] pvaIn,

   9:      [Out, MarshalAs(UnmanagedType.LPArray)] int[] pvaOut

  10:      );

When calling Exec for the first time, we get the handle for the language submenu. We obtain it in variantVar variable:

   1:  int[] nullVariantVar = null;

   2:  int[] variantVar = new int[3];

   3:   

   4:  spCT.Exec(

   5:              ref CGID_ShellDocView,

   6:              SHDVID_GETMIMECSETMENU,

   7:              0,

   8:              nullVariantVar,

   9:              variantVar

  10:              );

Now we must parse variantVar in order to get the result (the handle for the language submenu). The first value that we get is a VARTYPE type, which indicates the kind of variable that we will find next. Then there is a reserved spot of three WORD long, followed by the value we are looking for. So the handle for the submenu is on the second place of the array:

   1:  IntPtr handleSubMenu = new IntPtr(variantVar[2]);

We can replace passing the CComVariant argument to the function by creating a new variable shown in the code below and then call again Exec:

   1:  variantVarIn[0] = VT_INT_PTR;

   2:  // Remember that variantVarIn[1] is reserved

   3:  variantVarIn[2] = handleMenu.ToInt32();

   4:   

   5:  variantVarOut[0] = VT_I4;

   6:  // Remember that variantVarOut[1] is reserved

   7:  variantVarOut[2] = dwID;

   8:   

   9:  // Insert Shortcut Menu Extensions from registry.

  10:  spCT.Exec(

  11:              ref CGID_ShellDocView,

  12:              SHDVID_ADDMENUEXTENSIONS,

  13:              0,

  14:              variantVarIn,

  15:              variantVarOut

  16:              );

We obtain the complete context menu as a result of the instructions shown above. This menu can be modified as much as we desire. Using this, you can add or remove menu items and also their functionality. For example you can call methods implemented in your project from the desired menu item.

Now you can build a customized browser using C# !