Windows Mail Folder Paths and Names are incorrect

Add-in Express™ Support Service
That's what is more important than anything else

Windows Mail Folder Paths and Names are incorrect
Internationalized and duplicate folders problems 
Colin Hendry




Posts: 12
Joined: 2008-12-08
Hi again,

I have finally got my addin (which contains extra unmanaged code) to run on windows mail. :D

gray

However when iterating over the mail folders I have found problems with the ADXOEFolder members Name and FolderPath.

Name does not support internationalized folder names even though they may be created in Windows Mail and work fine. Instead I get a set of question marks which looks like the result of a bad language conversion.

FolderPath also has this problem.

Should the FolderPath represent the folder on disk where the mail is stored? The documentation is a bit ambiguous here.

If so, it also does not correctly represent the true path on disk if there are two similar long folder names such as "Testing Image Format" and "Testing Image Results"

Are these known issues and if so is there any possibility of a fix.

Thanks for your help,

Colin

Posted 15 Jan, 2009 19:35:00 Top
Fedor Shihantsov


Guest


Hi Colin,

You should set an appropriate system locale for correct work.

> Should the FolderPath represent the folder on disk where the mail is stored?

No, the FolderPath property is not related to the folder on the disk.
This is the full path in the Outlook Express folders tree.
Posted 16 Jan, 2009 11:04:55 Top
Colin Hendry




Posts: 12
Joined: 2008-12-08
:| Why would I set a system locale - this doesn't make any sense. A locale can only represent one ansi character set/codpage at any one time and so would only be able to decode one ansi character set at a time.

i.e. in a japanese locale the charset is set to iso-2022-jp and only japanese characters can be represented in non-unicode programs.

In Windows Mail a user can set up mail folders which, for example, can have chinese and japanese and latin-1 characters in the mail folder names all at the same time as they use Unicode characters as defined in the Unicode character set and implemented in the Unicode codepage. They are all visible and readable to the user via the Windows Mail UI.

Are you saying that the plugin will only be able to decode folder names based on the local codepage for the current locale and will hence not operate correctly if attempting to decode a name which contains characters/codepoints which do not exists in the local codepage. If so then this is a bug as the addin should not attempt to convert the data using the local codepage.

The foldername is stored in UCS-2 unicode format in the winmail.fol file for each location on disk at byte 0x45 and so is available for use.

Posted 18 Jan, 2009 19:34:16 Top
Fedor Shihantsov


Guest


Hi Colin,

The fact is that we are using Windows Mail/Outlook Express API.
http://msdn.microsoft.com/en-us/library/ms709546(VS.85).aspx

Quite often the OE.API does not provide a possibility to work with Unicode strings.
Say, we get a folder name with the help of http://msdn.microsoft.com/en-us/library/ms709678(VS.85).aspx that returns the CHAR/single-byte array.

This situation is similar to http://msdn.microsoft.com/en-us/library/ms710223(VS.85).aspx that contains single-byte string as a parameter.

Unfortunately, I don't know any method to get a folder name correctly.

BTW: Windows Mail displays window caption incorrectly for Unicode names.

User added an image
Posted 20 Jan, 2009 07:21:19 Top
Colin Hendry




Posts: 12
Joined: 2008-12-08
Thanks for the response.

When the single byte folder name is returned is it already translated using the local codepage (i.e. are a string of ?'s received via the interface for unicode characters not represented in the local codepage) from your response I am assuming that yes this is the case.


Posted 27 Jan, 2009 21:50:05 Top
Fedor Shihantsov


Guest


That's right, the folder name is translated using the local codepage. If the local codepage does not correspond with folder name language then conversion is incorrect.
Posted 29 Jan, 2009 09:32:19 Top