Re: [boost] Thoughts for a GUI (Primitives) Library

Subject: Re: [boost] Thoughts for a GUI (Primitives) Library
From: Gwenio (urulokiurae_at_[hidden])
Date: 2010-09-26 12:08:58

The same handler could be assigned to multiple windows or controls, so
unless the programmer chooses to create a new handler for each object that
needs one, it would be O(N+M). Refernce counting like with facets would be a
good thing, though if there are construction/destruction events then ref
counting could be tied to that (depending on how control specific data is
associated). The call on f is to set up the functions, not signal an event.
That constructor is for static objects so all the events can be set without
passing all the functions as parameters. Each event would pass the target
along with the message data, similar to how the window procs for WIndows
receive the HWND of the reciever of the message.

Regarding extensibility, the handler is meant to deal with system messages;
therefore at best for custom messages there would be a way to install
translators that would convert unknown messages into generic events such as
command and notify (message flow: system -> standard or custom translator ->
event handler -> application). This is because the code processing the
system messages would need to know how to format the data for the event
handler, and if it cannot then the ability to add custom events to the
handler would be useless. Furthermore it seems redundant to me to have both
custom translations and custom event types.

The reason behide dynamically creating the handler is because other than
having the handler be a virtual class no method of creating it at compile
time comes to mind, and I was trying to find a better way because it seems
that many feel that is not good enough (or at least with some
implementations of it like in MFC). Would you care to suggest a way?