Click above to get retro games delivered to your door ever month!

  
  The highlights in the normal life-cycle of a window object,
  including a dialog object, are:
  
  1. The class is instantiated, so the Init() method is
  invoked.  You often add code here in your sub-class, usually
  calling super:Init() at some point.  Clip-4-Win's Application
  Classes default to invoking the Create() method to actually
  create the window/dialog, but you can either prevent that or
  re-define Create in your sub-class.
  
  2. Preparations are made for creating the window.  Windows
  sends quite a few messages, any of which you can handle if you
  wish - but rarely do.
  
  3. The WM_CREATE message is sent, invoking the OnCreate()
  method.  This message is handled internally by dialogs.  In
  any case, you rarely process it.
  
  4. For a dialog with the DS_SETFONT style, the WM_SETFONT
  message is sent.  You could process this if you want, but
  rarely do.
  
  5. For a dialog, the WM_INITDIALOG message is sent, invoking
  the OnInitDialog() method.  At this point the dialog window
  and all its controls exist but haven't been made visible to
  the user.  You often add code here in your sub-class.
  
  6. The window or dialog becomes visible - unless you hid it,
  moved it off screen, or destroyed it.  Because they are
  windows too, this comment applies to each control as well -
  e.g. you could have used OnInitDialog() to create, destroy,
  hide, disable, and/or move controls.
  
  7. To make it visible, each window is sent a WM_PAINT message,
  which invokes the OnPaint() method.  Any owner-drawn controls
  send their parent at least WM_DRAWITEM, which is handled by
  the OnDrawItem() method.  You often add code here in your sub-
  class (or in the Paint() method).  Note: the WDialog() class
  handles OnDrawItem() by invoking the method in the control
  concerned, if it can.  This gives you a choice of where to
  handle it, allowing your dialogs to delegate intelligence to
  their controls.
  
  8. Usually, the input focus is set by sending a WM_SETFOCUS
  message, handled by the OnSetFocus() method.
  
  9. The user finally gets a chance to do things!
  
  10. Navigating a menu item results in some or all of:
  WM_INITMENU, WM_INITMENUPOPUP, WM_MENUCHAR, WM_MENUSELECT.
  
  11. Choosing a menu item or stimulating a control results in
  one or more WM_COMMAND messages, handled by the OnCommand()
  method.  You sometimes add code here in your sub-class.  Only
  sometimes, because Clip-4-Win's default menu handling is
  likely to be all you want, and controls are typically in
  dialogs - which can automatically invoke a method of your
  choice or run a code block you specify.
  
  12. More WM_PAINT / WM_DRAWITEM / WM_SETFOCUS messages are
  quite likely.
  
  13. The user indicates the window (or dialog) should be
  destroyed.  Various events can indicate this: a button push,
  maybe hitting Escape, double-clicking the system menu, Alt+F4,
  Ctrl+F4 (for an MDI child), and so on.  You can decide what to
  do, including destroying the window/dialog or keeping it, in
  each case.  Each of the messages has a default action, which
  tends to be the one you want.  In the rare cases where you
  want to explicitly destroy an ordinary window, you call the
  DestroyWindow() function.  For a dialog, you're advised to
  use its EndDialog() method because it handles several special
  cases automatically.  For an MDI child, you can use the
  frame's (or client's) DestroyChild() method.
  
  14. A button push generates a WM_COMMAND, as stated
  previously.  A dialog has Ok() and Cancel() methods already,
  which invoke its EndDialog() method if they decide it makes
  sense (doing final validation or cancellation, respectively).
  You often add code here in your sub-class.
  
  15. The Escape key in a dialog triggers the Cancel button, if
  there is one.
  
  16. Double-clicking the system menu, Alt+F4, Ctrl+F4 (for an
  MDI child) all produce a WM_SYSCOMMAND message, invoking the
  OnSysCommand() method.  The default action results in a
  WM_CLOSE message, invoking the OnClose() method.  The default
  for this will destroy the window/dialog.  If you process any
  message, you usually process the WM_CLOSE message.  You'll see
  that the Clip-4-Win Application Classes for top-level windows
  (WSDIWindow, WMDIFrame) handle OnClose().  For a dialog, the
  default for WM_CLOSE is to send WM_COMMAND with the id
  IDCANCEL, even if you don't have a Cancel button.  So, by
  default the OnCommand() method and then the Cancel() method
  will be invoked.
  
  17. Eventually the window/dialog is being destroyed.  Various
  messages are sent, including the following you might handle.
  
  18. A WM_DESTROY message is sent, invoking the OnDestroy()
  method.  A window/dialog receives this message before its
  children, so they still exist at this time.  You might add
  code in your sub-class to process this.
  
  19. A WM_NCDESTROY message is sent, invoking the OnNCDestroy()
  method.  A window/dialog receives this message after its
  children, so they do not exist any more.  You might add code
  in your sub-class to process this.  This is a good time to
  invoke the opposite of your Init() method, if you have one.
  The Clip-4-Win Application Classes call this an Axit() method.