0 Comments

Note: Japanese is the most relevant Asian language for us, as we had multiple request from developers in Japan, who would like to use Ivercy, but can’t for the reasons described in this post. So I frequently refer to Japanese in this post, but the issues are the same for any Asian language!

The last couple of days I struggled with supporting the Japanese Language in Ivercy. Today I have to admit defeat. - And I’m not doing this lightly.

There are two problems with using Ivercy in a Japanese language environment. As you probably are a software developer yourself and maybe interested in that, I’m going to describe the issue with quite a bit of technical detail. If you are not interested in that kind of detail, skip right to the bottom line.

The UI-Problem

The integration into Access is partially dependent on the UI-Language selected in Office. So Ivercy needs to know and understand the Japanese terms for Query (???), Form (????), Report (????) and so on. This is required for the UI-Integration into the Navigation Pane.

Access and the .net Framework, which Ivercy is implemented in, use Unicode Strings. So any character set can be represented in a simple string. So, this first issue can (and is) solved by simply adding a translation table between the Japanese terms and their English counterparts. This solves the UI-Integration issue and will be included in the next release of Ivercy (version 1.2.+x) and will be available soon.

The MSSCCI-API- Problem

The second issue with supporting Japanese is the MSSCCI-API. Unlike any Win32-API, the MSSCCI-API has no Unicode (…W) declaration/implementation of its functions. The functions are only available in an ANSI implementation, which uses the LPCSTR-Type or an array of LPCSTRs for character data.

Codepages and character encoding

With Western languages that can be represented by the Windows Codepage CP1252, it is fairly easy to pass data to the functions of the API. You simply declare the LPCSTR parameters as Strings and you are good to go. The .net runtime will sort out the marshalling of the data automatically.

Now, if you have got a file name (derived from an object name in Access) that consists of Japanese Characters, it will be automatically mapped using Codepage 1252. The result will be something like this: “????????????????”. - The question mark replaces any character that cannot be properly mapped. As CP1252 was never intended to represent Asian Characters, none of them can be mapped and the resulting data is completely unusable.

Now, the .net Framework supports all Windows Character Encodings, so it is possible to convert the Strings using the appropriate Codepage for Japanese (CP932). The result is a byte-array containing the string’s representation in the correct Codepage. – So far, so good.

Marshalling in the .net runtime

The conversion to the correct Codepage leaves us with an array of bytes that represent the Japanese character string

Now, for simple LPCSTR parameters it is pretty straight forward to implement. You would use an Byte() type in the declaration of the function and just pass our array of property encoded bytes to that. – Done.

Unfortunately, it is not that simple. Most of the functions in the MSSCCI-API do not use just simple LPCSTRs, but arrays of LPCSTRs. They would translate to an array of byte-arrays in our declaration – Byte()().

Other than a String or a simple byte array, the .net runtime cannot automatically marshal nested /jagged arrays. It should be possible to write a CustomMarshaler that would handle the marshalling of these types. There are actually some samples around on the internet. But I spend quite a bit of time trying to implement a CustomMarshaler for our jagged byte arras in Ivercy and simply could not get it to work. :-(

As I’m the developer with the most experience on WinApi and P/Invoke on our team, this is a pretty disappointing result.

Bottom line

You can use Ivercy in a Japanese edition of Microsoft Access and the icons and integration will work with the next version of Ivercy after 1.2.

But, you can only and strictly use plain English (western) characters in your object names in Access. As soon as there is any object in your Access database that contains a Japanese (or any Asian) Character, there will be exceptions all over the place and it will not be possible to work with Ivercy in that database.

We’re truly sorry about that. We might come back to this topic and try to address and fix the issues at a later time.

If you are an expert with Interop and P/Invoke in the .net environment and think you are able and willing to help with this, please get in touch. And we don’t expect your help for free.

Post comment