[lazarus] Progress

[Michael A. Hess]

Jeff Wormsley wrote:
> 
> Does this mean an application can never prevent an event from being
> serviced?  Are there any equivalents to "Before" events?  Like a
> callback that is called before the widget does something, that can
> return something that prevents or allows the widget to act on the
> event?  Or are all of the callbacks always "After" the fact?

OK. First let me clarify something. GTK returns 2 things signals and
events. Signals are just flags saying that something has happened in
case you want to do something about it. Like Destroy. It isn't an event
as much as a maintence signal. Hence a signal.

It also sends callbacks that are for events. To answer your question yes
it is possible in some cases to have the widget ignore the event and for
you to take control and handle the event. However if you handle all of
the events instead of letting GTK handle them then what are you using
GTK for? 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.)

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.

Maybe this will help. What follows is out of the GTK Tutorial

--------------------

18.2 Signal Emission and Propagation

Signal emission is the process whereby GTK runs all handlers for a
specific object and signal. 

First, note that the return value from a signal emission is the return
value of the last handler executed. Since event signals are all of type
GTK_RUN_LAST, this will be the default (GTK supplied) handler, unless
you connect with gtk_signal_connect_after(). 

The way an event (say "button_press_event") is handled, is: 

   * Start with the widget where the event occured. 
   * Emit the generic "event" signal. If that signal handler returns a
     value of TRUE, stop all processing. 
   * Otherwise, emit a specific, "button_press_event" signal. If that
     returns TRUE, stop all processing. 
   * Otherwise, go to the widget's parent, and repeat the above two
     steps. 
   * Continue until some signal handler returns TRUE, or until the
     top-level widget is reached. 

Some consequences of the above are: 

   * Your handler's return value will have no effect if there is a
     default handler, unless you connect with
     gtk_signal_connect_after(). 
   * To prevent the default handler from being run, you need to connect
     with gtk_signal_connect() and use gtk_signal_emit_stop_by_name() -
     the return value only affects whether the signal is propagated, not
     the current emission. 


-------------------

As I have been saying all along. If the LCL was made to be GTK specific
then alot of what you are asking about would be easier. Again it is this
keeping it independent from the API that is causing the trouble.


-- 
==== Programming my first best destiny! ====

Michael A. Hess      Miracle Concepts, Inc.
mhess at miraclec.com   http://www.miraclec.com