Re: enter in entry fields; modal windows




On Oct 8, 2006, at 4:37 AM, Michael Hartmann wrote:

Am Sonntag, 8. Oktober 2006 02:40 schrieben Sie:
In general, the -event signals want a boolean return value, saying
whether to continue event propagation.  You're not explicitly
returning anything, so the behavior may be unexpected.

I return the return code of $button->clicked. If there is no return in a sub in Perl, Perl just returns the last value, in this case the return value of
$button->clicked will be returned:
sub a { 5; 2; }
a(); # 2
So this works just fine, but it's a bit confusing, I guess.

Yes, that's what i meant by "not explicitly returning" --- you're using the implicit return value. However, $button->clicked() has no return value, so you're at the mercy of implementation details of the interpreter as to what value actually gets returned.

In general, you want always to use an explicit return in -event signal handlers. And, usually, you want that value to be 0.


Another problem: I have two windows and one window is modal. How can I prevent that the window that is not modal gets the focus. At the moment all widgets are not sensitive, but the window can still get the focus.

Do you mean that it is in front, or that the keyboard focus is on it? $window->present may be what you want.

I have two windows and one window is modal. However, you can still get the focus of the other window. I want a similar behaviour to a dialog: When you have a modal dialog, you cannot get the focus of the window that created it.

Ah.  You need to set the modal window to be "transient" for the other.

   $window2->set_modal (TRUE);
   $window2->set_transient_for ($window1);

This tells the window manager that the modal window is supposed to block events for its parent, and that it is supposed to stay on top of its parent. Dialogs typically use this.

--
"the ternary operator makes it a bit less ugly."
    -- kaffee




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]