Notes on Unicode-enabling certain UI elements of HTMLHelp. Paul Chase Dempsey August 20, 1998 Questions? mailto:paulde@microsoft.com ----------------- What's been done: Common control wrapper layer for the Tree View, List View, and Tab controls. These files also implement generic helpers that let you create and manipulate selected windows as Unicode. There's also a subset of the WindowsX.h-style APIs for edit controls and combo boxes. include\cctlww.h hhctrl\cctlww.cpp I've implemented the use of these wrappers for the common controls, edit boxes, and combos on the major UI elements: the tab control, TOC, Search, Advanced Search, and the edit control for the index. Implemented dual Ansi/Unicode message pump. I'ts not enough to create just the control as Unicode or enable the Win95 Unicode support in the IE5 controls. The parent windows of the controls must also be Unicode [enabled]. All the windows in SendMessage/notify chains must all do the Uni thing in parallel. Just one Ansi proc or SendMessage slices off the Unicode-ness of the message or data. Take note of how we create, subclass, and call window procedures for conditionally Unicode windows. I modified CDlg so that it _can_ create Unicode version when possible. This must be done explicitly with SetUnicode(TRUE) for each dialog before calling DoModal() or DoModeless(). In some places, this is done in the constructor for the derived dialog class, so make sure you look at the headers to see if this is happening for a dialog or not. --------------------- What's not been done: grep for "paulde" for detailed points left to do or things to consider. Topic list needs CTable Unicode support. I haven't done the Unicode thing on bookmarks/favorites, subsets, infotypes, samples, notes, or history. I haven't handled the way conjunctions are inserted. Currently these use ANSI, so you can get text trashed in some scenarios by using the conjunctions dropdown. There are a couple of ways to approach fixing it. You probably need to write W_Edit_GetSel and W_ComboBox_GetEditSel that translate the DBCS byte index from the edit control to Unicode character index. If you need to use a codepage different from the sytem, use IsDBCSLeadByteEx rather than IsDBCSLeadByte or CharNext (I think there's an implementation in the intl utils I threw over from VS). Index.cpp needs Unicode version of isSameString and more. I expect there's a fair amount of work to make the word-wheeling Unicode. aboutbox.cpp: gets strings from the file, so should convert using an appropriate codepage and displayed using the Unicode text funcs. EXTENSIBLE_TAB for custom tabs. Need some way of indicating the proper codepage for the tab name. I don't think there are any Print issues. When a CHM is loaded, the LCID and codepage of the CHM should be checked to see if the support for that locale/codepage is installed on the system, and either refuse to load or warn that not everything is well in the world. (I was getting a GPF in ITSS doing a search on a Japanese title when the system didn't have the codepage). We'll probably need Unicode version of GetStaticDimensions, using the W text API wrappers so Uni text is measured correctly. If you see UI elements getting truncated or too wide, look for this as the cause. On NT we just create the controls as Unicode and use our generic A/W wrappers, so the significant input and display works natively as Unicode. Richedit is useful ONLY on win95/98. Since we're shipping 1.1d only in NT (no Office, Win95/98 service pack, and no web release), there's no point to doing the additional work to use richedit. Richedit supports Unicode in a different way than the common controls. The common controls use separate A and W message ids and notifications. Richedit uses the same message ids, but the arguments and return values are in terms of WCHARs. This means that you can't use the generic A/W wrappers with richedit. They aren't richedit-aware. Implementing that would require every wrapper to look at the window class name (ugh, slow, but doable), or get passed a flag to do things the richedit way. If a list or tree view is still getting Ansi notifications on NT5, then there's some Ansi window handling messages somewhere in the routing, or someone is calling IsDialogMessageA or another Ansi message API. To fix this, make sure that W APIs are called as appropriate (look at the wrappers in cctlww.cpp), and that the windows in question are created/subclassed/etc. using the wrappers following the model of the windows that have already been enabled. If you don't control the creation of the window, it can be subclassed using SetWindowLongW to convert it to a Unicode window. The subclass procedure will need to carefully map/send the relevant messages appropriately. I hope you don't have to do this -- it should only be necessary for the imbedded contents and search controls. If a subclassed Unicode edit box is getting trashed on NT, look for a DefWindowProc, DefDlgProc, or CallWindowProc. These need to use the wrappers W_DefWindowProc, W_DefDlgProc, and W_DelegateWindowProc.