BlogWell

I wanted to be able to easily email a file from a utility I wrote, and thought “wouldn’t it be so much easier if I could incorporate the ‘Sent To Mail Receipient’ functionality available within Windows” so I didn’t have to worry about which email application is actually installed.  I know this will typically limit this to either Microsoft Outlook Express or Microsoft Outlook, but at least I don’t have to worry about the mechanism required to create an email with an attachment which is yet to be sent.

So the following is the C++ code which implements createEmailWithAttachment().

The GetUIObjectOfFile() routine is taken from Raymand Chen’s blog where he posted How to host an IContextMenu, part 1.

The droptarget code was taken from a discussion thread which was incomplete.

Unicode and non-unicode variants are supported.

HRESULT GetUIObjectOfFile(HWND hwnd, LPCWSTR pszPath, REFIID riid,
                          void **ppv)
{
  *ppv = NULL;
  HRESULT hr;
  LPITEMIDLIST pidl;
  SFGAOF sfgao;
  hr = SHParseDisplayName(pszPath, NULL, &pidl, 0, &sfgao);
  if (SUCCEEDED(hr))
  {
    IShellFolder *psf;
    LPCITEMIDLIST pidlChild;
    hr = SHBindToParent(pidl, IID_IShellFolder, (void**)&psf,
                        &pidlChild);
    if (SUCCEEDED(hr))
    {
      hr = psf->GetUIObjectOf(hwnd, 1, &pidlChild, riid, NULL, ppv);
      psf->Release();
    }
    CoTaskMemFree(pidl);
  }
  return hr;
} 

#ifdef DEFINE_GUID
#undef DEFINE_GUID
#endif 

#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8)
        EXTERN_C const GUID name
                = { l, w1, w2, { b1, b2,  b3,  b4,  b5,  b6,  b7,  b8 } } 

DEFINE_GUID(CLSID_SendMail, 0x9E56BE60, 0xC50F, 0x11CF, 0x9A, 0x2C, 0x00,
            0xA0, 0xC9, 0x0A, 0x90, 0xCE); 

static HRESULT createEmailWithAttachment(LPCTSTR pszFileName)
{
  IDataObject *pDataObject = NULL;
  IDropTarget *pDropTarget = NULL;
  LPCWSTR pwszFileName = NULL;
  bool bCreated = false;
  HRESULT hr; 

#ifdef UNICODE
  pwszFileName = pszFileName;
#else
  WCHAR *pwszBuffer = NULL; 

  int nLength = MultiByteToWideChar(CP_ACP, 0, pszFileName,
                                    strlen(pszFileName), NULL, 0);
  if (nLength DragEnter(pDataObject, MK_LBUTTON, pt, &dwEffect);
      if (SUCCEEDED(hr))
      {
        hr = pDropTarget->Drop(pDataObject, MK_LBUTTON, pt, &dwEffect);
        if (SUCCEEDED(hr))
          bCreated = true;
      }
      pDropTarget->Release();
    } 

#ifndef UNICODE
    free(pwszBuffer);
#endif // UNICODE 

    pDataObject->Release();
  } 

  return hr;
}

Microsoft Office 2007 introduces a whole lot of new features – revamped UI, new file formats etc.  However, one thing is missing, which is support for the Outlook protocol (outlook://).

Developers wanting to open emails from other applications could use the Outlook protocol to get Microsoft Outlook to display them.  For example, outlook:00000000AEB50BC0928BD511A2700000E8D73A91C4A56101.

This is all well for Microsoft Outlook XP and 2003 (not quite sure about 2000); however, for Microsoft Outlook 2007 Microsoft have decided to no longer support it. 

Upgrading to Outlook 2007 will remove the Outlook protocol registry details which was setup by the previous version of Outlook.

Information about this is available [buried] in http://support.microsoft.com/kb/929590, which says:

Known issues when you develop custom solutions for Office Outlook 2007

The Outlook protocol no longer works outside Outlook

The Outlook protocol (Outlook://) has been changed. This protocol will only
work when you use it in Outlook. You can use this protocol on a folder home
page, on the Web toolbar, or in the body of an Outlook item.

Now registration of the Outlook protocol is straightforward, and results in outlook.exe being invoked with the /select command line argument with the value of the Outlook protocol following.

To reactivate the Outlook protocol with Outlook 2007 installed, simple copy the following into a .REG file and double click on it from Windows Explorer.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\outlook]
“URL Protocol”=”"
@=”URL:Outlook Folders”

[HKEY_CLASSES_ROOT\outlook\DefaultIcon]
@=”C:\\Program Files\\Microsoft Office\\Office12\\OUTLOOK.EXE,-9403″

[HKEY_CLASSES_ROOT\outlook\shell]
@=”open”

[HKEY_CLASSES_ROOT\outlook\shell\open]
@=”"

[HKEY_CLASSES_ROOT\outlook\shell\open\command]
@=”\”C:\\Program Files\\Microsoft Office\\Office12\\OUTLOOK.EXE\” /select \”%1\”"

If Microsoft Outlook  2007 is not installed in default folder “C:\Program Files\Microsoft Office\Office12″ you will need to update the above accordingly.

Obviously this will only work whilst Office 2007 still supports the /select command line argument.

Also, in this day and age of automatic updates, Microsoft could, if they wished, revoke full support of the Outlook protocol at any time.

This workaround will give you some breathing space for an alternative solution to be developed.

Microsoft has released a developer toolbar for Microsoft Internet Explorer which may be useful to SEO folk for ad-hoc analysis of individual pages.

For example, it allows the details of the commonly used description and keywords meta tags without having to troll through the raw html source code.

Tooltips are used to allow the all of the content to be displayed. 

 
It is interesting to note that MS capitalize the tag names within the toolbar even though lowercase is the strict W3C definition.

A suggestion for MS with respect to visually distinguishing between the different meta tags is to include the name value within the navigation tree on the left hand side.  For example, instead of “<META>” you would see “<META name=’description’>”.

The other common SEO attribute is the title tag, but viewing the actual contents is confusing at first as nothing is shown when the title tag is viewed even though one is set.

To view the value of the title tag you need to use the innerText attribute of the tag, which is done by checking the “Show Read-Only Properties”.

 
Another suggestion for MS would be for the innerText attribute to always be displayed.

Without going into too much detail, there are a lot of interesting things you can do with the toolbar:

1. Easily resize Internet Explorer to 800×600, 1024×768 etc to see what your page looks like for the resolutions you want to support.
2. Easy access to W3C validation tools and link checker, and accessibility reports.
3. Ability to turn off CSS – which is interesting for no other purpose that to see how awful a page looks.
4. Table and div tags etc can be outlined on the screen.
5. You can change the class of a tag and see its effect immediately before you edit the change within the actual page file.  All other read-write attributes can be changed also.
6. The toolbar can annotate the tag to image sizes, link paths, etc.  For example, viewing link paths replaces the original text of:

With the following:

 
7. And lots more

Download, install and give it a spin.

Displaying the toolbar is less than intuitive in my mind, which is done by selecting the >> to show additional items.

If you’re an engineer and live in Silicon Valley, Google is inviting you to its G’day Google night on May 8, to learn about all the cool things they are doing in Australia.

Neat huh?  Until you get to the added bonus:

“Australian food and drink — I’m talking Vegemite sangers, yabbies, meat pies, Australian beer, more   Australian beer, and wine”

Wow!  Sangers.  Really?  And lots of beer? Well…no doubt about it, I’m IN!

C’mon Google, give me a break.  Don’t fall into the trap so many other American companies have if you want credibility with the folk down under…it’s lame.

Here’s a clue:

Slang + Australians + Google =  ?*
* Pay particular attention to number 6.