Re: [OT] Best way to isolate a GUI?

["Randy Brukardt" <randy@rrsoftware.com>]

Jeffrey Carter wrote in message <3E518EA0.1080702@acm.org>...
>> It might be easier to start with a tagged object, where methods can
>> be inherited and overriden instead. That way all events can just
>> do nothing, while you override the events you are interested in.
>> But this takes us back to a model similar to callbacks anyways, but
>> instead of registering a callback, you register a tagged record
>> to receive callbacks.
>
>This is the approach taken by CLAW. A widget is represented by a tagged
>type, with primitive operations that are called automatically when
>certain events occur. There are default versions of these operations.
To
>create a widget with specific behavior, you have to extend the type and
>override the appropriate operations. This can be useful when you want
to
>have data associated with a widget, as you can define the data as part
>of the extension, give the widget values when you create it, and check
>the values in the operations. But when all you want is to define the
>application's behavior when the user clicks a button, it seems like
>overkill. Consider a window with lots of buttons, different behavior
>when each button is clicked, and little or nothing else in the way of
>user input. This calls for many extensions and many overridings of the
>appropriate operation. It differs from callbacks in not requiring
>operations to be registered with the windowing system, but similar in
>that the windowing system controls your application.


That's not quite right. In Claw (as in MFC, but not quite as in
Windows), notifications are passed first to the control item, then to
the parent window of the control. In most cases, you handle
notifications in the parent window in order to avoid the need to
override so many items. The result isn't quite so pretty, but its a lot
easier to maintain (because there are far fewer packages and types).
This is also convinient for handling the data, which is usually shared
between multiple controls:

A typically handler would look like:

     procedure When_Child_Notify (Window  : in out My_Dialog;
                                 Code    : in
Claw.Notification_Code_Type;
                                 Data    : in
Claw.Notification_Data_Type'Class
                                 Control : in out
Claw.Root_Control_Type'Class;
                                 Unknown_Command : in out Boolean;
                                 Result_Value : in out
Claw.Win32.LResult) is
        use type Claw.Notification_Code_Type;
        use type Claw.Root_Control_Type;
    begin
        if Code = Claw.Buttons.Button_Clicked then
            if Control = Window.Button_1 then
                -- Do whatever.
                Unknown_Command := False;
            elsif Control = Window.Button_2 then
                -- Do whatever.
                Unknown_Command := False;
            else
                 Unknown_Command := True;
            end if;
        else
            Unknown_Command := True;
        end if;
        if Unknown_Command then -- Call the parent routine for default
processing:
               Claw.Dialog.Modal.When_Child_Notify (
                    Claw.Dialog.Modal.Modal_Dialog_Type(Window),
                    Code, Data, Control, Unknown_Command, Result_Value);
        end if;
   end When_Child_Notify;

(Note that calling the parent routine is harder to write and more likely
to break in Ada 95 than it really ought to be, because you have to
identify the parent type in it.  If the parent type changes, this call
may be wrong. I hope that the upcoming Amendment will address this
problem.)

           Randy.