in reply to Perl/Tk Oddities
The problem with Tk::Dialog and Tk::DialogBox is that they both want to manage the closing buttons in a separate bottom section of the dialog box. From my understanding, there is no way to intercept the results of the bottom buttons. Actually, there is a built-in mechanism through the -command option, and that is where you can save data, etc. But once the bottom button is clicked, you can't cancel it (for example, if the user forgot to enter a critical field) and force the dialog to stay open.
The good thing about Tk::Dialog and Tk::DialogBox is that they don't appear to create separate applications with icons showing on the bottom of the display (in Win32). This is despite the fact that both are derived from Tk::Toplevel.
As I mentioned earlier, Tk::Toplevel provides a method for building completely functioning dialog boxes with total control of all widgets and processing. There is a drawback, however, in the fact that every Tk::Toplevel is treated by Tk as if it were a separate application, which shows up as an icon on the bottom of the display.
The only workaround I've been able to come up with is to use the toplevel->withdraw() function in both the calling module (when it calls a module that has its own respective Toplevel) and then in the called module when it closes down. The crazy thing about this is that the callee must have a link back to the caller, i.e., a subroutine call, to tell the caller that the callee has completed its processing and withdrawn itself, and that it's time for the caller to deiconify() and raise() itself.
The use of withdraw() in this way prevents the situation where there are multiple application icons. It's not perfect, however, as I can literally see the withdrawing of one module and the raising of another as the icons repaint themselves at the bottom of the display. But that's a small price to pay for having the control of the Toplevel serving as a dialog: I can completely manage the exiting process and I fully control the positioning of all widgets within the Toplevel (whereas with Tk::Dialog and Tk::DialogBox I have no control of the button placement).
If anyone has any suggestions or insights where I may be making a mistake or may be overlooking some option that might make the Tk::Dialog and Tk::DialogBox processing work better, please let me know. Thanks.
Tom