MESSAGES

  In this chapter we will describe API data structures that you will 
  encounter in many places of this guides, pointed to this section by the 
   RELATED TOPICS  menu.

  Windows consists of a bunch of Structures and Messages, and although 
  FiveWin handles nearly all of them automatically for you it is sometimes 
  important to know about the API world.

  Windows generates an input message for each input event, such as when the 
  user moves the mouse or presses a key. Windows collects input messages in 
  a systemwide message queue and then places the messages, as well as timer 
  and paint messages, in an application message queue. 

  An application message queue is a first in, first out queue. Timer and 
  paint messages are exceptions to the first in, first out rule; these 
  messages are held in an application's message queue until the application 
  has processed all other messages. 

  Windows places messages that belong to a specific application in that 
  application's message queue. FiveWin then reads the messages by using 
  the GetMessage function and dispatches them to the HandleEvent
  method of the appropriate window by using the DispatchMessage function. 

  Windows sends some messages directly to the window of the application 
  instead of placing the messages in the application's message queue. Such 
  messages are called unqueued messages, and typically are messages that 
  affects the window only ( like the WM_CREATE message ). The SendMessage 
  function is used to send such messages to the HandleEvent method of 
  the window. 


  FiveWin internally uses the GetMessage function in a loop to remove 
  messages from the application's message queue. This loop is called the 
  'main message loop', and is started if you activate a Window. 
  The GetMessage function searches an application's message queue and, if 
  any messages exist, returns the top message in the queue. If the message 
  queue is empty, GetMessage waits for a message to be placed in the 
  queue. While waiting, GetMessage relinquishes control to Windows, 
  allowing other applications to take control and process their own messages. 

  Once FiveWin has retrieved a message from the application's message queue, 
  it can dispatch the message to the window using DispatchMessage. 
  This function directs Windows to call HandleEvent() of the window 
  associated with the message, and passes the content of the message as 
  function arguments. 
  HandleEvent() can then process the message and carry out any requested 
  changes to the window. When the window procedure returns, Windows returns 
  control to the main message loop, and the next message is retrieved from 
  the queue. 

  Windows generates a message each time the user presses a key. FiveWin 
  passes this message up to the method KeyDown(). The message contains 
  a virtual-key code that defines which key was pressed, but does not define 
  the character value of that key ( see WM_BUTTON / WM_KEY ). 

  To retrieve the character value, FiveWin translates the virtual-key 
  message by using the TranslateMessage function. This function puts 
  another message with an appropriate character value in the application's 
  message queue, and the message is then be dispatched to the window method 
  KeyChar()

  Although Windows generates most messages, an application can create its 
  own messages and place them in its own message queue or that of another 
  application.  The SendMessage and PostMessage functions let 
  applications pass messages to their windows or to the windows of other 
  applications. 

  The Windows API messages are defined in WINAPI.CH !