Enablement of Multi-Threaded Double Byte Character Set Presentation Manager Subclasses
Original Publication Date: 1995-Jan-01
Included in the Prior Art Database: 2005-Mar-29
Morgan, SA: AUTHOR [+3]
Disclosed are alternate techniques that can be used for subclassing controls that handle the unique requirements of a Double Byte Character Set (DBCS) environment.
Enablement of Multi-Threaded Double Byte Character Set
alternate techniques that can be used for
subclassing controls that handle the unique requirements of a Double
Byte Character Set (DBCS) environment.
Presentation Manager* (PM) application often has need
to subclass individual controls within a dialog in order to enhance
or override the basic functionality of these controls. Subclassing
is performed by calling the WinSubclassWindow API. This API returns
the address of the PM system message procedure for that control,
which is used as the default message procedure in the message
procedure to which the control is being subclassed. Messages not
processed in the subclass procedure are passed to this default
procedure, which was the top level procedure before the subclass.
Since PM has
just one system message procedure for each control
type, it is the normal practice to store the PM message procedure
returned from the WinSubclassWindow API in a global variable which
all subclass procedures for that control type reference. Each new
call to subclass that control type stores the PM message procedure
address in the global variable. Since it is just the same address
being stored each time, this process is safe and efficient.
Unfortunately, this common technique does not work for all
controls when the application is running as a multi-threaded
application in a DBCS environment, such as on the OS/2-J Japanese
version of the operating system.
in a multi-threaded DBCS environment is that some
PM controls (for example, context menus, the frame of a window, the
pushbutton of a combo box) have different PM default procedures when
they are in different threads. It is not intuitive that this would
be the case, since it is not the case in the Single Byte Character
Set (SBCS) version of OS/2. Since the same control type might have a
different PM message procedure address based on what thread it is
running on, using a single global variable per control type to hold
the address of the PM message procedure will not work.
There are two
alternatives for storing the PM message procedure
address needed for control subclasses that will work in this unique
DBCS environment for all control types:
o One alternative is to store the procedure address in the window