Make All the World a Stage for ActiveX Controls

by F. Avery Bishop

As a worldwide phenomenon, the Web provides exposure to multiple cultures and languages for developers and users alike. The challenge to Web site developers is to provide content that takes advantage of this diverse mix and is sensitive to it. In particular, ActiveX controls present special challenges because they are downloaded to a client machine that could be in any of dozens of locale or language environments.

Keep in mind that an ActiveX control is simply a Component Object Model (COM) object, that is, a (usually small) component of executable code. Thus, most of the guidelines for globalizing a standard Win32 application apply. (See the checklist inside the cover of Developing International Software for Windows 95 and Windows NT, by Nadine Kano, Microsoft Press, 1995.) The differences in guidelines for ActiveX controls arise from the need to keep the controls small and/or download asynchronously to maintain the user’s interest in the page.

Here are some guidelines to help you develop ActiveX controls that won’t embarrass you, wherever the controls show up in the world. Parents should be so lucky to have kids like this.

Avoid data, such as text, that needs to be localized (translated)

You read that right¾ avoid text if possible. This is actually a reasonable restriction in most cases, because controls are often at a level of granularity that doesn’t require menus, message boxes, and other text. If you just can’t avoid using text in your control, you’ll have to translate most of it (there are some exceptions, such as product names) into lots of languages, and then download the version appropriate to the client locale to avoid appearing English-centric.

Note that this says nothing about the use of locale-sensitive formats, such as those of date/time and currency. For example, it’s okay to use a date in an ActiveX control, because the data itself (the date) is not locale-sensitive. You can use the Win32 national language support (NLS) application programming interface (API) to render the date as appropriate to the locale without downloading extra data (see the next item).

Take advantage of the NLS API

This standard guideline for traditional applications is even more important for ActiveX controls. By using functions such as GetDateFormat or LCMapString to display or process data as appropriate to the client locale, you can avoid maintaining your own database—a significant timesaver, since that database must be accessed or downloaded over the net.

Use universal bitmaps

The overhead associated with downloading bitmaps makes this guideline all the more imperative in the case of ActiveX controls. Use icons, pictures, or symbols that are universal around the world, so that a single bitmap will work everywhere. In particular, avoid text in bitmaps, with the exception of product names or "design" text that does not need to be localized.

Separate text and other locale-sensitive resources from the program code

This is one of the first rules of globalization: "Thou shalt put all text in resource files separate from the program code," so it’s easier to find and localize. Because ActiveX controls are for the World Wide Web, you’ll eventually want to translate text strings into several languages, in which case this step is essential to maintaining your schedule and your sanity.

Verify that your locale requirements are met

If your control absolutely requires features not offered by all locales, check the locale setting, and set it to one you can use. For example, if your object requires an Input Method Editor (IME), check the locale of the client system to make sure that it is one of the Far Eastern locales. The following code will set the American National Standards Institute (ANSI) locale to the system default, and will return the name of the locale setting for use with the ANSI functions:

   #include <locale.h>
   char *szDefaultLocale = setlocale(LC_ALL, "") ;

The second parameter in the setlocale function can also be a string representing any valid locale, such as "German_Switzerland.1252". If the call is not successful, it will return a NULL pointer. You should call setlocale at the beginning of execution in any case, because programs always start out in the "C" locale, which is as boring as American rice lager.

If you prefer to use the Win32 locale functions, you can check the locale identifier (LCID) as follows:

   #include <winnls.h>
   LCID lcDefault = GetSystemDefaultLCID() ;

If your control cannot operate in this locale, you can fail gracefully, rather than simply crashing.

Download only the localized data needed for the client locale

If you have large amounts of locale-specific data, such as help files or special-purpose fonts, check the client’s locale ID, as shown above. You can then use the ANSI locale or LCID to decide which files are appropriate,(for example, by a switch statement) and then set up a URL moniker that will download only the files needed.

A general point to keep in mind during design is that because the Web is worldwide, you can’t assume anything about either the locale or the user using your ActiveX control, so it's important to make the design as general as possible.

Going Global online

For more information on globalizing software for international markets, consult Microsoft's Going Global site on the World Wide Web, http://www.microsoft.com/globaldev/.

When not writing for the Going Global title, F. Avery Bishop dabbles in exotic languages and scales the Cascade peaks in his backyard.

The differences in guidelines for ActiveX controls arise from the need to keep the controls small and/or download asynchronously

Because the Web is worldwide, you can’t assume anything about either the locale or the user using your ActiveX control