Windows-ffi-example-2
---------------------

This code presents an approach to using Windows resources for
generating UI in Dylan and a generic event/message dispatch as the two
are related. Note, that this demo doesn't really use the resource
database, since there is no need to create any data structures
modelling the UI objects in this demo. However, duim presumably would
use the resource database to create its structures.

The COMMAND in Windows is a higher level semantic event. It is
generated by menus, buttons and other controls (i.e. gadgets in
Windows parlance). Windows doesn't register callbacks. The COMMAND
message is normally handled in a event dispatch loop.

Each command message contains its ID. When menus and other UI objects
are created through resources, those objects get assigned the IDs
which are later used to identify them when a COMMAND message is
received (when controls are created "by hand" the "menuID" slot in the
window structure is used for this purpose).

Another important part of the architecture is that those COMMAND
messages are send to the parent of the control, i.e. the top
window/dialog (I think the control generates those messages and
forwards them to the parent).

Several UI object can have the same ID. Note the "Draw" menu in the
example. The same COMMAND message is sent to the dialog if you select
the menu item "Draw Line" and when you click on the button "Draw
Line". 

The approach in the example relies on creating special Windows window
classes. Registering a window class amounts to registering with
Windows an event handler for this particular class of window. Note
that unlike in X, Windows can call the handler outside of the
message/event loop.

The class "duim_frame" handles mostly commands, whereas the class
"drawing_area" handles other types of messages. There is also a
generic DialogProc which dispatches COMMANDs for standard dialogs
(i.e. dialogs with standard Windows dialog window class).

There also is a dispatch mechanism (probably not the most efficient
implementation). There are two types of tables: command tables and
message tables. The generic handlers lookup those tables and call the
appropriate callbacks.

The tables are registered by the resource ID, not window id. As I
mentioned before Windows can call the event handlers at any time -
e.g. creating a window causes Windows to call those handlers several
times. So, we have to register the tables before the CreateWindow
function returns. I do that in response to the first message sent to a
window (WM_NCCREATE for our window classes and WM_INITDIALOG for
standard dialogs).

So if you want to register a different table for another window with
the same resource id, you just register a new table before creating
the window (this is not likely to be needed).

Note that I used the callback mechanism for event messages too. I
think it is too much overhead to dispatch all events even if they are
not needed. Registering a handler is a way for the application to
indicate an interest in the event. Note that Windows sends all events
to the application unlike X.

I don't know if duim expects to receive all events though.

There are two files you should look at: example.dylan is the example
itself and example-support.dylan is the supporting framework. The UI
has been created using VC++ dialog editor. You can change the UI and
the example will work without modification as long as the semantics
doesn't change (and the command IDs). The resource file example.rc has
to be loaded to VC++ outside of a project. For now, to use the
resource database the file has to be modified by hand to change
DIALOGEX resource generated by VC++ to DIALOG resource (just remove
EX). I will install a template for a resource file that you have to
use to start creating resources (this is to make sure that VC++ lets
you edit the window class field for the dialogs).

The user sets the main window dialog class to "duim_frame". The work
area is created as a custom control. You set the window class to
"drawing_area". We may want to create other special classes of
windows. 



