Article 004, "Automatic Notification of Window Activity"

	In a multi-tasking environment, polling is bad.  Interrupt driven is good
since it lets your app stay idle until it's needed.  Otherwise, your app has
to take
up system resources and time in order to check if it should kick in or not.
A
WAOL application that polls for changes to WAOL's windows is bad; how bad is
determined by how often the app is set to poll for activity.  There is a very
easy
way around this and it's a neat use for an otherwise rarely used feature of
the
Windows API.
	Look in the Windows API reference guide of your choice for a computer
based training hook.  You'll find a callback routine named CBTProc; install a
hook and trap all the HCBT_CREATEWND and HCBT_DESTROYWND
messages.  When you receive one of these messages, your program can inspect
the window caption or the type and number of controls and decide to activate
and
do its thing or not.  The Window API from Microsoft states something to the
effect that hooks need to be placed in a DLL.  This bit of information is
repeated
over and over in all the mainstream books and the on-line help files.  Well,
this is
sorta correct.  A system hook must be in a DLL and this is a requirement that
(currently) can't be changed.  However, what most Windows API books don't
tell
you is that a task hook can reside in an EXE instead of a DLL.  Read that
again
until you understand it.  If you're a Delphi programmer, you're probably a
bit
excited; if you "don't get it," then don't worry about it.  From a Delphi
programmers' point of view, these mean that a single EXE can control all of
WAOL without any extraneous DLL's or other files; one file does everything.
It
doesn't get any simpler than that!
