On Tue, Apr 01, 2003 at 12:37:16PM +0200, Herr Maik HERTHA wrote:
I played a little bit without sense and found that the following
combination does work, but I don't know why? I put the signal
propagation in a idle-hanlder and it works.
idle_add() just makes your callback run when the GTK+
On Tue, Apr 01, 2003 at 06:07:29PM +0200, Herr Maik HERTHA wrote:
However, in your case I honestly don't think this complication is at all
justified. If all you want to do is pop up a dialog window on
double-click, why don't you just check double-click, select the row your
event object is
Christian Reis wrote:
It is my approach of event-driven applications. There is only one
responsible callback to show the dialog.
See, I don't understand what you mean by this. Why can't you have a
method called show_dialog() which is called by N different callbacks?
One of them could be a
Maik Hertha wrote:
:: It sets the signal return value to the value returned by the last
:: handler. It then decides whether to continue the emission if the
return
:: value is False.
:: Most uses of stop_emit_by_name() can be converted to simply do
return
:: True now. You hardly ever need
On Tue, Mar 25, 2003 at 10:10:32PM +0800, James Henstridge wrote:
How does connect/connect_after relate to the `position' of the callback
in the list of handlers? Does connect() connect *before* the
GtkTreeView's `default' signal handler (can I call it default?) and
_after(), after? What about
Christian Reis wrote:
Can the class handler be run multiple times, then, if both _LAST and
_FIRST are set, for instance?
Yes, but they seldom do (I am not sure if any of the signals in GTK do so).
What are signals with return types?
Integer, boolean, etc. The type of the value returned by the
Christian Reis wrote:
On Fri, Mar 21, 2003 at 10:31:13AM +0800, James Henstridge wrote:
Stephen Kennedy wrote:
Plain connect works fine, but the connect_after
callback does not get called.
Or am I doing something wrong? See attached example.
For the standard widget event signals,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Answer from Christian Reis
Plain connect works fine, but the connect_after
callback does not get called.
Or am I doing something wrong? See attached example.
There might be a default handler that is returning TRUE somewhere that is running
For the standard widget event signals, a custom accumulator is set.
When going through the list of handlers to call for the signal, the
process goes like this:
1. call handler
2. if it returned True, skip the rest of the handlers in
the list and return True
3. otherwise,
Maik Hertha wrote:
The difference to the 0.6.x code is, that I include the return statements in the
functions with
FALSE. If I do a signal_connect I get a deadlock situation with the dialog window
which is called via
Set_options_button.clicked().
Could it be a bug anyway ?
The behaviour was
On Thu, Mar 20, 2003 at 09:06:53PM -, Stephen Kennedy wrote:
Plain connect works fine, but the connect_after
callback does not get called.
Or am I doing something wrong? See attached example.
There might be a default handler that is returning TRUE somewhere that
is running after your
Stephen Kennedy wrote:
Plain connect works fine, but the connect_after
callback does not get called.
Or am I doing something wrong? See attached example.
No bug here.
For the standard widget event signals, a custom accumulator is set.
When going through the list of handlers to call for the
12 matches
Mail list logo
