[lazarus] Progress

[Jeff Wormsley]

On 9/2/99, at 2:41 PM, Michael A. Hess wrote: 

>However if you handle all of
>the events instead of letting GTK handle them then what are you using
>GTK for? 

See below...

>It would be possible for you to catch the event, tell GTK to ignore it
>and then handle it up the class chain yourself but then you lose all of
>the GTK functionality.
>

The only reason I am asking is that if there is a Before as well as an After, then Interfaces could by default set the Before callback to tell GTK to handle the event, but if the LCL event were overriden, it could in turn override the Before event.  So, to use a GTK button as normal, there would be no difference from current code.  But, if you wanted to, say, keep someone from clicking on it, you would set the callback that came before the click to something other than the default, then handle the event yourself, and return to GTK whether to keep going or not.  In essence, you have then overridden the event, just as you would have in windows if you intercepted the WindProc and acted on a WM_MOUSECLICK (or whatever that message is).  In Windows, you either pass the message on to the parent handler for normal handling, or throw it away.  In GTK, you either return False to the Before event for normal handling, or return True to tell GTK the event has already been handled.

>Since Qt is different in nature the way you would need to code
>the LCL to handle this will most likely be radically different for Qt.
>(I'm not familiar with Qt to really say.)

I don't know about QT either, but it would seem that the ability to override default event behavior would be a fairly common ability in any GUI toolkit.  Whether it is done, as GTK seems to, with a callback, or as windows with a message intercept, should be capable of being handled by the Interfaces code, I would think.

Jeff.