Windows Parent Child Architecture

1
Windows Parent / Child Architecture
2
Child Windows

• So far we have only considered Windows
  applications which have a single main - parent -
  applications Window.
• WHAT IS A CHILD WINDOW ?
• A child window is simply an extension of the
  overall concept of a Windows system..
• Except for the main - parent - applications
  window everything else in any windows application
  is a Child window. Yes everything even STATIC
  TEXT.

3
CHILD CONTROLS

• The most common child windows are the active
  controls used to retrieve information from the
  USER PushButtons, CheckBoxes, RadioButtons,
  Lists, Combos etc., however any application can
  derive there own Child Windows to suit the
  requirements.
• In order to maintain compatibility with the
  overall event handling philosophy there has to be
  a ChildWinProc() for each Child created.
• This allows the Child to send messages to the
  Parent or visa versa.

4
CHAT

• A Child can determine the handle of the parent
  or for that matter any other Window currently
  active on the system.
• hwndParent GetParent(hwd)
• SendMessage (hwndParent,message,wParam,lParam)
  
• The message sent can mimic a standard message on
  the system or can be derived as application
  specific . wParam can contain some form if ID of
  the child.

5
CONTROLS

• The mechanism of using Controls is generally
  termed input information manipulation, we can
  offer the user of the system a cleaner and more
  effective user interface.
• Although you can create your own Controls to
  customise the application to meet a particular
  requirement. The flexibility offered by using the
  STANDARD Windows Controls offers advantages and
  speed of development.
• The standard Controls are simply predefined and
  registered Windows Classes, each has a specific
  message handling procedure and in many cases it
  is possible to use this without the need for
  extensive modification.

6
CONTROLS

• Buttons
• Check Boxes
• Radio Buttons
• Edit Boxes
• List Boxes
• Combo Boxes
• Static Text Strings
• Scroll Bars

7
CONTROLS

• To add a button on the left hand side of the
  applications Window all that is necessary is a
  single call to CreateWindow() possibly followed
  by a MoveWindow().
• IS IT REALLY THIS SIMPLE.. ?
• ALMOST BUT NOT QUITE....

8
CONTROLS

• In any application the majority of controls are
  grouped into Dialog Boxes. However there are
  times that a Control is needed in the Client Area
  - the rectangle within the main applications
  Window.
• All intercommunications will be via messages of
  the form WM_COMMAND.
• In order to place a Control in an application
  Window, first the application window class must
  registered and the instance of the class i.e..
  the window created. Once created the parent
  handle will be known or it can be recovered as
  discussed previously.

9
CONTROLS

• To us a predefined control there is no need to
  register the class simply create a Window from
  one of the following classes
• button
• static
• scrollbar
• edit
• listbox
• combobox

10
CONTROLS

• The control can then be created by using
  CreateWindow() and positioned using MoveWindow()
• Any Child Control is generally based on using
  99 of the predefined message procedure.
• Use of this predefined procedure eliminates the
  reinvent the wheel within the design.
• The use of Child Controls directly on the main -
  parent - or application Window requires a far
  greater involvement with the actual predefined
  class than is necessary when dealing with a
  Control in a Dialog Box.

11
WHY CONTROLS

• WHY USE CONTROLS DIRECTLY IN APPLICATION WINDOWS
  ?
• In certain cases it is not possible to use a
  dialog box. Information control from the user
  requires Dialog boxes and direct Child Window
  Controls.
• This need to understand the lower level
  manipulation of Child Windows is best illustrated
  by the of the FOCUS of controls.
• Once the input focus has been shifted from the
  application window to a control, effectively the
  application has lost control of its Input!

12
INPUT FOCUS

• The subject of focus is not simple.
• There is a demonstration of a simple application
  in which we create various styles of the Button
  in a client area available on the CD and WEB Page

13
The FOCUS problem

• The simple example highlights the focus problem,
  once a pushbutton has the input focus, indicated
  by the dotted line the parent has lost the input
  focus and is effectively no longer in control of
  the input process.
• We find that the spacebar mimics the mouse click.
• We have no means of stepping between buttons i.e.
  the standard TAB function.
• The parent cant get the keyboard input messages
  because a Button has the focus all of the time !

14
Solutions to FOCUS

• Simple Answer
• There are messages generated WM_KILLFOCUS and
  WM_SETFOCUS
• WM_KILLFOCUS occurs as the focus shifts from
  Parent to Child.
• WM_SERFOCUS occurs and is sent to the window that
  is just being granted input focus.
• Using this fact we can prevent any child from
  gaining FOCUS by monitoring messages in the
  Parent.

15
SOME TYPICAL ANSWERS

• If the parent has an array of Child handles
  called hwndChild
• case WM_KILLFOCUS
• for (i0iltnumberchildren,i)
• if (hwndChild i wParam)
• SetFocus (hwnd) // force focus back
  to Parent
• break

16
SOME TYPICAL ANSWERS

• case WM_KILLFOCUS
• if (hwnd GetParent(wParam)
• SetFocus (hwnd) // force focus back to Parent
• break
• Both these have shortcomings....
• Again they will not allow the user to TAB between
  Controls since the focus is not passed around the
  Controls its always with the Parent, this means
  we cant tell were the focus should be !!!

17
SUB CLASS

• Use of the idea of a SUBCLASS on the Child
  Window, allows the application to preprocess all
  messages to the Child before passing them on to
  the predefined windows procedure.
• The subject of SUBCLASSING is one that many
  people find difficult to grasp, but the essence
  is that we intercept messages before they get to
  the message procedure for that Windows Class..

18
The Technique of Sub Class

• So how can such a technique be implemented ?
• Remember the address of the message procedure is
  held in the Class Structure.
• So this procedure must be buried somewhere inside
  Windows itself as are the STANDARD procedures for
  STANDARD CONTROLS.
• If we could find the address of the procedure,
  remove it from the structure, replace it with an
  application specific address then we can
  preprocess them.

19
The Solution

• Since we are about to replace a procedure that is
  buried in the heart of the windows system it is
  important that we ensure the Data Segment is
  correctly aligned. In Win 16 you needed to use
  the MakeProcInstance.. For Win32 this is not
  needed.
• Assume we have a procedure called NewButtonProc
  ( ) which handles the keyboard etc., so the focus
  control etc., can be corrected, in our
  application code.
• WIN16 Only
• lpfnNewButtonProc MakeProcInstance( (FARPROC)
  NewButtonProc,hInstance)

20
The Solution

• To extract the old procedure address we will make
  use of GetWindowWord ( ) API.
• lpfnOldButtonProc GetWindowWord
  (hwndButton1, GWL_WNDPROC)
• We extract the pointer from the window created
  for the first button, whose handle was
  hwndButton1. storing the address at
  lpfnOldButtonProc.
• We can then replace the newly created pointer
  lpfnNewButtonProc in its place by using the
  SetWindowWord() API.

21
The Solution

• SetWindowWord( hwndButton1, GWL_WNPROC,
  lpfnNewButtonProc)
• Now all message processing will pass through this
  application specific filter first.
• Finally we have to ensure that if this new filter
  either modifies or ignores the message it is
  passed on to the original message handler and
  this is accomplished by a call to
  CallWindowsProc ( )
• Typically this new procedure would therefore have
  the structure..

22
The Solution

• int CALLBACK NewButtonProc(HWND hwnd, UINT
  message, UINT , wParam, Long lParam)
• switch (message)
• case
• case etc
• return CallWindowProc ( lpfnOldButtonProc,
  hwnd,message,wParam,lParam)