EXECDLG - Readme

An example which shows how you can execute a dialog modally under OWL
and still get OWL pre-processing.

To build. Default include directories are D:\BC4\INCLUDE & D:\BC4\LIB
Before building you may need to use Project | Options | Directories to 
suit your installation.


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 bare bones of the method are provided
in TApplication but unfortunately it does not work as intended. Also, the
method is based on calling a TApplication function, rather than being
near identical to the Execute() method.

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 PreProcessMessage is available, and true accelerators are available,
along with the normal keyboard handling. Truely the best of both worlds!

TMyDialog::ExecuteModally() is substantially borrowed from TApplication. For
simplicity I have removed the alternative disabling of windows to leave the
method that most people will find most useful - all non-child windows of the
application enabled at the time of execution will be disabled. (Another common
problem of dialogs is choosing the correct parent to ensure that the application
is not modal). Also, I have removed the 32 bit version for clarity. As you have
the source for both these options, it is easy to build this in again. Finally, as
the list of disabled windows stored is part of the dialog, it does not have
the problem of confused lists if child modal dialogs are then executed.

Note, this example does rely on EndModal to break the loop. It is possible
that its behaviour will change in the future, in which case you would need to
derive a class from TApplication to enable the BreakMessageLoop flag to be set and
pass back the return value.

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.

In the amended version, the F1 key works via an accelerator, and also the
enter key goes from field to field except when on a button (via PreProcessMsg).

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.


Ian Spencer, TeamB
100111,421