EXECDLG - Readme

Warning! This example requires BC4.02 or above - use OXECLDG
for the earlier versions.

Overview

This sample demonstrates how to use the main message loop to drive a
modal dialog.

Using the main message loop:

  - Enables PreProcessMsg, which in turn allows true accelerators,
  - Allows TApplication::IdleAction to process,
  - allows modal dialogs to own modeless dialogs,
  - allows modal dialogs to have menus,
  - allows exceptions to be handled.

Description

Modal dialogs in OWL 2 use the standard windows dialog procedure, deep
within the heart of windows, to run the message loop that makes dialogs
modal. This procedure also has the code that disables the parent windows
and makes the dialog "accelerators" work, and also steals some keys so
your application never sees them, making workarounds to normal dialog
behaviour a technical experience not for the feint-hearted.

Often there is a requirement to make dialogs work in a slightly different
way to the standard windows method, for instance trapping the F1 key for
help. In an ordinary OWL 2 window there are a number of ways of doing this,
but as the standard modal dialog does not use the normal TApplication::
MessageLoop (which calls PreProcessMsg where most of the behaviour is
implemented) these methods are barred.

The solution is to fake a modal dialog. The method uses TApplication::BeginModal
& EndModal. Note that this example relies on fixes introduced with BC4.02. Either
upgrade or use my old example which has a bit more code.

This example performs an Execute based on the TApplication::MessageLoop which
therefore enables all the message pre-processing that OWL likes to do. This
means that PreProcessMesg and IdleAction available, and true accelerators are
available, along with the normal keyboard handling. Truely the best of both
worlds!

The old Execute() is included to stop the "hidden function" warning and call
compatibility. Note that by changing the header you can convert your code in a
fairly straightforward way. I haven't heard of any problems of using this
alternative method.

In the test example, a copy of an OWL example, note that the F1 accelerator
does not work with the standard example, and that the Enter key works as standard.
There is a simple spinning device on the window (a bit naughty that as it should
be hidden by the client), changed by IdleAction, once per idle time.
Note that it stops when the standard dialog is running.

In the amended version, the F1 key works via an accelerator (though you could
code it in PreProcessMsg directly), and also the enter key goes from field to
field except when on a button (via PreProcessMsg). Also note that the spinner
keeps going during the dialog when messages are sent, unless an error
message box or the Help message box is shown (ie you need to invent your own
MessageBox if IdleAction is important to you).

The important point to note is that both versions execute exactly the same class,
but one gets access to the special features, the other doesn't. The use of the
enter key is popular with people doing heads down data entry, but should
be avoided for normal windows applications.


16/3/94 Amendments from original version

- After successful Create, Show called to ensure that dialog is always shown.
- IdleAction demonstration added.

5/7/94  Rewritten to use fixed version of BeginModal and to be call compatible
        with Execute().


Ian Spencer, TeamB
71333,3235