windows-xp/Source/XPSP1/NT/enduser/stuff/hhctrl/uninotes.txt

Notes on Unicode-enabling certain UI elements of HTMLHelp.

Paul Chase Dempsey
August 20, 1998

Questions? mailto:[email protected]

-----------------
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.