You might also be able to bind a handler for <Visibility> events and raise the window again if it becomes obscured, which avoids continuous graphics traffic (until two programs both try to do this and end up fighting over "on top" status).

Is this a long-lived window or only a short-lived dialog box? Is this supposed to be a modal dialog? If so, grabbing the server may be appropriate.

Hello jcb,

I am not an expert on bindings. I just found the following

$dialog -> bind('<Visibility>', sub {$dialog->raise;});
[download]

which however doesn't seem to get activated if my main window gets the focus and hides the $dialog. Am I using it the wrong way? I searched on the Net quite a lot, but could find almost no examples in using this technique.

PS: My $dialog window is a short-lived Frame. It is a ListBox+Text widget added to an Entry widget in order to perform a choice (the various drop-down menus do not fit my purpose. I need a new custom widget).

Another approach, if it is supposed to be a modal pop-up and there is no significant cost to canceling is to $dialog->bind('<Leave>', 'destroy'); so that it will go away if the user moves the pointer out of the window. I have used $menu->bind('<Leave>', 'unpost'); to produce context menus that remain up only as long as the pointer remains over the menu, which have been convenient for my uses.

I have not actually tried binding <Visibility> events, since I have not needed them in any of my programs yet. Does this need to work only for you or is this to be distributed? If it only needs to work for you, you might be able to configure your window manager to keep the dialog box on top and avoid the need for override-redirect.

Thank you for the suggestion. For the moment I went adding

    $dialog->repeat(10, sub {
        $dialog->raise;
    });
[download]

which makes the GUI respond as intended