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

  
  The way applications are intended to work under Windows is to
  be as modeless as reasonably possible, and to respond to
  events generated by the user, Windows, other applications, or
  the application itself.
  
  Of course, there are times when something modal is the correct
  choice: warnings about problems, or important choices (like
  overwriting files) are examples.
  
  In practice, you should be guided by the principle of "least
  surprises", i.e. what would a user expect at this point?  So,
  if a menu choice implies quitting without saving some work,
  you may want to use the MessageBox() function (which is
  modal) to see whether the user would really like to quit, or
  what.
  
  Similarly, when you use TBrowse it's entirely reasonable to be
  modal.  Your user might be much happier, however, if you
  worked a little harder and produced a modeless browse.  That
  way, your user could open another window to browse some other
  data.  You have to be careful to avoid a couple of problems,
  though.  Firstly, think about when/where you lock records: you
  don't want to end up trying to lock a record in one browse
  window that's already locked in another browse.  Secondly,
  think about when/where you allow the user to make changes:
  your user may actually be able to edit several records at a
  time (each in a separate window), but is it really a good
  idea?
  
  What are events, and what does event-driven mean?
  
  Events are the things that affect your application, such as
  keystrokes, mouse clicks, and choosing menu items.  It's
  reasonable to say an error detected by your application (like
  file not found) is also an event, but here it's only external
  events sent to your application by Windows that concern us.
  
  By event-driven we mean an application that collects each
  event in a timely fashion and responds to it by performing an
  associated action.  Sometimes, the action is simply to ignore
  the event.  You could argue that a traditional Clipper
  application could be made event-driven "just by ignoring the
  events we don't want right now".  However, this loses sight of
  the central idea that it's not the application that is
  primarily in control any more: it's the user.
  
  In a nutshell, the user drives the application.  This is why
  your application should be modeless wherever reasonably
  possible.  That way, your users can interact with your
  application in a natural way.  "Natural?"  Yes: people are
  very much event-driven!
  
  To keep your application as modeless as possible, you'll
  probably have just one place where events are fetched and
  considered.  Each of the routines that carry out the action
  appropriate to the event will return to this central point,
  which will loop round to get the next event.  This sort of
  program structure is often called an event loop (or message
  loop).  The code that activates the actions is variously
  called a dispatcher, event handler or an event manager.
  However, the terminology is not universally agreed; some
  people use event handler to mean an action routine.
  
  You may very well be thinking that event-driven programming
  sounds strange and/or difficult, but like many new experiences
  it's really a case of being a little different.  The two main
  difficulties are that you're (probably) not used to it, and
  that there are rather more events sent by Windows than the
  typical Clipper application has ever encountered.
  
  Of course, you are almost certainly doing some event-driven
  programming now, if only in a limited way.  When you use
  TBrowse you use keystroke events to send messages to the
  TBrowse object.  (Probably in a modal fashion, though.)  Also,
  you may have been using an object-oriented Clipper add-on to
  make your applications event-driven.  That's not to say that
  using objects automatically makes your application event-
  driven: it's still up to you.
  
  Perhaps you're now thinking that you can't convert your
  existing Clipper applications to Windows.  This isn't true,
  but you will need to make some changes to adapt them to the
  Windows environment.  The biggest change is likely to be the
  conversion to being event-driven.  You'll also want to make
  changes to use some of the new features available (like
  graphics).  Lastly, you'll need to make changes to avoid
  Clipper features that conflict with or are not available for
  Windows.

  You can usually keep a lot of your existing code: the
  "business logic" to do with validating data, maintaining data
  files, etc.  Typically what you do is to design a new menu
  structure, using the Windows facilities (which are very
  powerful and easy to use).  You add some new initialisation
  code (e.g. SET SCOREBOARD OFF, call WinSetup(),
  SetHandleCount(), and C4W_AutoClose() ), and add a simple
  event loop.  The user's menus selections are dispatched by the
  event loop to the function of your choice.  To be properly
  event driven, you separate your existing code into functions
  that can be called as events occur.  In particular, you
  normally have to separate out user-interface code, and indeed
  you'll want to move to code suitable for the GUI.
  
  Many functions need to start something (e.g. a browse), and
  return to the event loop, and yet be able to pick up where
  they left off, depending on when the next event occurs that is
  for that function.  The easy way to do this is for the
  function to start its something (the browse), and add an event
  handler for future events.  The AddHandler() function does
  exactly this, using a code block you specify.  You put a call
  to HandleEvent() in your event loop, which then dispatches
  the event to the event handler (the code block).  This is
  covered in more detail in the next section.
  
  By the way, don't think you could avoid this conversion by
  moving from Clipper to a different xBase product.  At best
  you'd get an application that your users will complain doesn't
  behave like a Windows application should.  At worst you'd have
  to give up locals, statics, code blocks, ragged arrays,
  TBrowse, etc., and still have to make the conversion!
  
  Before turning to the details of event handling under Windows,
  let's just dispel a myth: there's nothing new about event-
  driven programming.  Operating systems and controllers (now
  often termed embedded systems) have been event-driven for
  decades.  Many of these are not only event-driven but also
  interrupt-driven, and sometimes interrupts can interrupt one
  another.  Your problems are comparatively simple, since you
  can generally finish handling one event before responding to
  the next.