Led 3.0 Class Library DocumentationLed 3.0 Class Library DocumentationLed_Win32_Helper < BASE_CLASS > ::TemporarilyUseTablet Led_Win32_Helper < BASE_INTERACTOR > Led_Win32_SimpleWndProc_HelperqHookIMEEndCompositionMessageToWorkAroundWin2KIMEForNonUNICODEBugqScrollTextDuringThumbTrackingqSupportFunnyMSPageUpDownAdjustSelectionBehaviorqSupportWindowsSDKCallbacksNEW in Led 3.0. Based on templates in Led_MFC - from Led 2.3.
Led_Win32 is a module providing a an interface between the Win32 operating system/platform and
the Led class library. It is not class-library specific. It only depends on the Win32 API.
To get support specifically tuned to MFC - for example - see Led_MFC.
Led_Win32_Helper < BASE_CLASS > ::TemporarilyUseTablet [public]
Utility class to use (with caution), to temporarily for a given tablet to be
used for a given Led_Win32_Helper,
TextImager. NB: This causes the TextImager::TabletChangedMetrics method by default
(unless called with special arg).
Led_Win32_Helper < BASE_INTERACTOR > [public]
BASE_INTERACTOR = TextInteractorDOCUMENT SOON - BASED ON Led_MFC_Helper
| Member Details |
|---|
|
Override to hook |
|
Override to hook |
|
When the text is modified between clicks, that should reset any click count. Besides the logic of this, its actually IMPORTANT todo in case the change in text invalidates the fDragAnchor. |
|
|
|
|
|
OBSOLETE. See |
|
Simple, virtual wrapper on GetScrollInfo (SB_HORZ,...) call. Virtual so
you can easily override it in a Led subclass, and use a source of scrollbars, other than
the default - and still leverage the scrollbar maintainance logic in Led_Win32_Helper See also |
|
OBSOLETE. See |
|
|
|
Win32 SDK kind of queer in its OnGetDlgCode () API. In order to get enter keys, we see to have to request ALL_KEYS. Then - that means we get TAB keys - even if we didn't want them, and wanted them processed by the outer window automatically. So - try to guestimate the right default behavior here for handing a tab character. And in the end - leave it virtual so users can get what they want. |
|
Hook the Win32 SDK WM_CHAR message to handle user typing. Probably should not be called directly, except maybe to simulate user typing. |
|
Hook the Win32 SDK WM_GETDLGCODE message so that windows knows which messages to send to our WindowProc. See the Win32 SDK for more details. |
|
Part of |
|
Part of |
|
Part of |
|
Hook the Win32 SDK WM_KEYDOWN message to handle user typing. Most typing handled via Led_MFC::OnChar (). But some keystrokes only make it to here, and on the WM_CHAR message, for some reason. |
|
Hook the Win32 SDK WM_SETCURSOR message to handle set the cursor to an I-Beam, as appropriate. When over draggable text, instead use a standard arrow cursor. |
|
Called by the system when we receive the input focus. React by adjusting IME, showing cursor, etc. |
|
Called by the system when we lose the input focus. React by adjusting IME, showing cursor, etc. |
|
Sets the 'default window margins', retreivable through calls to
These margins are not to be confused with those specified in These margins simply specify a small inset to be automatically applied to the ::GetClientRect() in the WM_SIZE message (handler) so that there is a border around this control. The WindowRect is simply inset by the amount given (and the borders automatically erased in this classes WM_ERASEBKGND method). Margins default to zero, and so its as if this feature simply defaults to being off. |
|
OBSOLETE. See |
|
|
|
OBSOLETE. See |
|
|
|
Return true if Led_Win32_Helper See also |
|
|
|
Hook the |
Led_Win32_SimpleWndProc_Helper [public]
Led_Win32_Helper < BASE_INTERACTOR > Add a simple Win32 WndProc static function to be used in a window class, and have that call the right entries in BASE_WIN32_HELPER to handle the calls. Not a generic message map mechanism - but instead one simple and hardwired for our purposes here.
qHookIMEEndCompositionMessageToWorkAroundWin2KIMEForNonUNICODEBug [public]
On Windows 2000, you SUPPOSEDLY can now get UNICODE characters from the new IME. However - in practice - unless you build a so-called UNICODE application (really this means call RegisterClassW rather than RegisterClassA). Then the Win32 API IsWindowUnicode () returns TRUE or FALSE according to which way you registered your window class. Then the IME decides whether to hand your app UNICODE characters (WM_CHAR/WM_IME_CHAR) based on IsWindowUnicode () API.
However - UNICODE applications (so-called) cannot run under Win98 and earlier. For many (most applications)
this is not an acceptable limitation (which is why Led supports so-called 'Partial UNICODE' configurations - Led_tChar
is UNICODE - but Led_SDKChar is not).
Another relevant problem is that MFC allows you to build an application that is either fully UNICODE (-D_UNICODE) or fully ANSI (not -D_UNICODE). Nothing in between.
So - if you want your app to use MFC - and you want UNICODE support - you are out of luck getting characters from the IME (unless you set your OS SYSTEM DEFAULT LOCALE for the one locale all your characters character set can be found in).
In steps the qHookIMEEndCompositionMessageToWorkAroundWin2KIMEForNonUNICODEBug - to rescue the day. I asked MSFT for help on this question (CASE ID #SRX991213601271). Basicly they weren't very helpful. But after much discussion - I seem to have elicited a kludge that seems to work pretty well.
When ever I get an IME_CHAR message - instead of trying to decode the multibyte character inside (which will be bogus frequently) - I call ImmGetCompositionStringW () and then grab the characters out of that buffer directly. The only tricky part - and this was VERY tricky - is which characters to grab!
Eventually, through trial and error - I have evolved into doing this. Set an index counter to zero. And for every WM_IME_CHAR - grab the char at that index, and bump my index. And for ever WM_IMECOMPOSITION or WM_IME_ENDCOMPOSITION message - reset that counter to zero.
I've tried this on NT4Japanese, Win98J, and Win2K(RC2) with the default Locale Japanese or English. It seems to work.
This is probably somewhat error prone or risky. It is for that reason that I'm making this bug workaround optional - and easy to shut off. But I leave it on - by default (when building for UNICODE - but without -D_UNICODE), since in that case - you will almost certainly want that to work.
Default Value: (qWideCharacters && !qSDK_UNICODE)
qScrollTextDuringThumbTracking [public]
On Windows many applications scroll their content as the thumb is tracking. This CAN make thumb movement slower, and may be undesriable for other reasons
But its common enuf now that I make this behavior ON by default
qSupportFunnyMSPageUpDownAdjustSelectionBehavior [public]
On Windows page up/down have a very funny interpretation. Playing with MSWord and Notepad, I see they each do something different, and I really understood neither. But both agreed that after a page up/down, you reset the selection somehow. I tried to mimic the behavior of MS-word as well as I could. This behavior is SO bizzare, I've made it optional. But since it appears to be an MS standard - its ON by default.
Turn ON by default
qSupportWindowsSDKCallbacks [public]
This might be wanted if you have code which currently depends on these callbacks, but its probably better, and more portable (across platforms) to just override the appropriate Led method. And if you do that, there is no reason to pay the performance cost of sending unheeded messages.
Turn OFF by default - LGP 970710
Return to Led Page
Return to Led ClassLib Documentation Index
Return to Led Reference Manual Index