Nektra announces the release of the new version of WLMailApi, the most used SDK designed to develop plugins in Windows Live Mail Desktop email client.

Main features included in this version:

• Create toolbars and buttons.
• Create toolbars and buttons in message windows (Compose / Reply / Forward / Message detail).
• Access and modify folders and messages.
• Event notifying selected folder and message/s.
• Event notifying changes in local folders.
• Demo application and dll plugin developed in C# with source code.

Request trial version here! http://www.nektra.com/products/wlmailapi-windows-live-mail-api-plugin/request-trial License: Some changes were introduced to the license for WLMailApi. Now, it is necessary to purchase a license for each developer that will use the library or by each product that will be developed using the library, taking into account whichever number is greater. For more details visit license page. http://www.nektra.com/products/wlmailapi-windows-live-mail-api-plugin/license Contact us to ask any commercial question or use the technical inquiries. http://www.nektra.com/contact

Best Regards,

Business Development

Nektra has released the new WLMailApi v1.1.1

Nektra has released the new WLMailApi v1.1.1, 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.1.1 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 two years 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:

• SendMessage now works, but only for the default account.
• Resolved On click “create message” button Hang
• Resolved WLMail hang when I imported an account
• Resolved Hang when I drag and drop emails only if AVG is installed
• Resolved Moving messages through folders hang
• Added IMailAccount::GetMailAddress
• Moved all loading code to LiveMapiLoader
• Added GetButtonRect()
• Added Message::GetBodySize
• Changed folder enumeration to using ILMFolderEnumerator
• Fixed IMessage::GetBodySize
• Changed InternalRegisterMessageNotification folder limit from 30 to 20

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

We all remember when Ole Automation came out. We were all impressed how simple it was to implement a few COM Interfaces, place a toolbar and interact with the office package. Soon the competition began to show who could create the best and most creative Add-on. How many times did you wonder how that other plug-ins “did that”? What if now you can even know how Outlook, or any Office application operates? Well, my friend, take a closer a look…

This Deviare example is implemented as an Outlook Add-on. We have used C# .Net, but you can use any language that supports Component Object Model.

We are using 2 threads to avoid freezing the application. The first one is the standard thread where Outlook report its events to us. The second is our worker thread where we create an output window to print our messages and a Deviare Event Proxy to process functions’ calls.

From the events Outlook provides us to work with we are only interested in OnStartupComplete. Here we know that Outlook is done with all its initialization and we can start hooking its interfaces. As a regular plug-in we ask for the Outlook Application, Active Explorer, CommandBars and create a CommandBarButton. We are going to intercept all of them and see how their members are used.

Notice that to obtain the interface we don’t use the class implementation, but the underlying interface definition. That’s why, when calling HookInterface, we send the Type of Outlook._Application and not Outlook.Application. The second one, is the .Net wrapper, and the first one is the Ole Interface.

To intercept these objects, Deviare needs some information. The necessary elements are the COM Object Interface (that would be its virtual table), which members we are interested in (specified by index), and the name of the Interface. Identifying the interface by name, will let Deviare find all the information it needs during the call, so you can handle its parameters the same way we did with any function hook. To gather all this the .Net Framework provides us with marshaling facilities (System.Runtime.InteropServices.Marshal), this makes our lives pretty easy .

And that’s all. We print our calls, and see our results:

Cheers, and happy coding!

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# !

Custom Outlook Development

We have a team of experts developing plug-ins for Outlook. We can go beyond Outlook API and develop modifications to those functions that lacks of some features that your product may need. Our team leaders are experts running projects and our customers can feel confident that their product will be released in time. Our sales team can be contacted any time in our office in California  (310) 237-6506.
For more information visit Outlook plugin development