The work we did to migrate AutoCAD 2007 to use Unicode (rather than MBCS), has impacted many developers around the world. For those that are yet to go through the pain themselves, I thought I'd talk about the resources that are available to ObjectARX developers needing to port their applications to Unicode.
Firstly, you should check out the Migration Guide that ships with the ObjectARX 2007 SDK (docs/acad_xmg.chm):
There's a whole section called "Upgrading to Unicode", with lots of useful information. A good deal of the material in the guide was compiled during the development phase of AutoCAD 2007, as our own engineering teams got to grips with porting AutoCAD to support Unicode.
Here's a quick outline listing of the topics, to give you a feel for the contents:
- Upgrading to Unicode
- Why Convert AutoCAD to Unicode?
- Terminology and Basic Concepts
- Characters and Glyphs
- MBCS, Multi-byte, DBCS, ANSI, ASCII, and Code Pages
- Unicode and its Formats (UTF-8, UTF-16, and UTF-32)
- Compiler Types: char, wchar_t
- Autodesk Type: ACHAR
- Affected AutoCAD-based Products
- Effect of Unicode Conversion on AutoCAD File Types
- Creating Unicode-compatible Source Code
- Unicode Porting Tool: Visual Teefy
- Text File Utilities Provided in the ObjectARX SDK
- Outline of Autodesk Porting Process
- Updating Large ObjectARX and ObjectDBX Applications
- Project Definitions for Unicode Compilation
- Command Line Processing Tip
- Basic Coding Tasks
- Change char to ACHAR or TCHAR for ObjectARX APIs
- Guidelines for Using TCHAR and ACHAR
- Wrap Literal Strings and Characters with _T() or ACRX_T()
- Replace ANSI String Pointer Types
- Update String Formatting Functions
- Check String Allocations for TCHAR Compatibility
- Check Usage of Win32 APIs With No Unicode Equivalents
- Check Usage of Lead Byte APIs
- Use _TUCHAR in Unicode Character Classification Functions
- Use #ifdef to Call the Correct Unicode Function
- Replace strlen() With _tcslen, Rather Than _tcsclen, in Dual Build Code
- Use Unicode Code Page Descriptors in Win32 APIs
- Use Native wchar_t
- AcArray of std::wstring Type Requires Special Allocator Argument
- DCL Dialogs Use Unicode, but Definition Files are ANSI
- Secondary Coding Tasks
- Centralize Recurring Literal Strings
- Replace Char Buffers with String Classes
- Revisit Low-Level Win32 API Calls
- Avoid Calling CRichEditCtrl::GetSelText()
- Evaluate Usage of wctombs() And mbstowcs()
- Prepare User Interface for Unicode Compatibility
- Fine-Tuning System Font Usage for Special Cases
- Prepare File I/O for Unicode Compatibility
- Tips on Supporting Supplementary Plane (UTF-32) Characters
- Linker Errors Caused By Conflicting Definitions of wchar_t
- Frequently Asked Questions
- Resources
Additionally I'd recommend using a tool called Visual Teefy, which is distributed via the ADN website. The name comes from the fact it helps add the T() macro into string literals (among other things), hence "T()-ify" => Teefy. The tool hooks off the Visual Studio IDE's search & replace mechanism to find potentially problematic pieces of code, and provide suggestions on how to address them. It's not recommended to use the automatic settings (Teefy really just makes suggestions), as clearly a search & replace-based tool is inevitably going to have trouble - as an example - differentiating a string literal in a compiler directive (such as #include "acdb.h" - which does not need any modification) from a string literal that does require the use of the T() macro.
As for other resources, I'd recommend searching the ADN KB, if you have access to it, or submitting your questions via the ObjectARX discussion group or DevHelp Online: at this stage it's almost certain that someone in our development community has experienced the same migration issues you're hitting, and it can certainly save time to ask.
Leave a Reply to ravindra Cancel reply