127 lines
5.2 KiB
Plaintext
127 lines
5.2 KiB
Plaintext
|
|
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.
|
|
|
|
|