|
From: Brian G. <bgr...@mo...> - 2005-07-20 22:14:56
|
You have to make the destruction determined by the user. The reason is that error checks should be performed before action is completed, if a check fails, the dialog box should stay; reconstructing it would cause unnecessary flashing and additional "failure" dialog boxes are just super annoying or, if used, should be layered on top of the original dialog box anyway. IMO -Brian Joe English wrote: >New in CVS: [ttk::dialog]. Documentation here: > > <URL: http://tktable.sourceforge.net/tile/doc/dialog.html > > >Please review. > >This is similar to [tk_messageBox], with a few notable differences: > > + [ttk::dialog $dlg ...] constructs the dialog $dlg, maps it, > and returns immediately; [tk_messageDialog ...] blocks until > the dialog is dismissed. > > + [tk_messageDialog] returns the button name to the caller > after dismissing the dialog; [ttk::dialog] passes the button > name to a callback procedure specified by the -command option. > >(Rationale: it's easy to build a blocking API on top of a >nonbocking one, but not the other way around. I haven't done >the blocking API yet.) > > + There is no -parent option; instead, [ttk::dialog]s are > made transient for the nearest [toplevel] ancestor widget. > > + [ttk::dialog]s are nonmodal. > > + [ttk::dialog]s use the KDE / Win2K / XP layout style > instead of the older Motif/Windows 3.1/CUA style. > Gnome / Aqua - style button layouts are not (yet) supported. > >[ttk::dialog] supports the same set of predefined dialog '-type's [*], >but also allows an arbitrary user-specified list of '-button's >It also provides a "client frame" where the caller can add additional >widgets for further customization. There (will also be) a mechanism >(undocumented, not fully worked out) for defining new '-icon's >or theme/application-specific versions of the built-in ones. > >I've been using this interface for a while and am fairly happy >with it; a few things that should probably be changed though: > > + [ttk::dialog]s are "self-destructing" -- when the user > presses a command button, the dialog is destroyed. It > might be preferable to withdraw the window instead. > > + There should be an option to make [ttk::dialog]s modal. > (I don't think this should be the default, though, mostly > because of the all-around evilness of [grab].) > > + Possibly: an option for persistent dialogs, i.e., > ones that don't automatically dismiss themselves when > a command button is pressed. > >Other missing features/possible enhancements are listed in TODO >notes at the top of library/dialog.tcl. > > >--Joe English > > jen...@fl... > >[*] Except for '-type abortretryignore', which has been omitted > for obvious reasons. > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Tktable-tile-dev mailing list >Tkt...@li... >https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev > > > -- # 12th Annual Tcl/Tk Conference: Oct 24-28, 2005, Portland OR # http://www.tcl.tk/community/tcl2005 ------------------------------------------------------------- -- Mentor Graphics Corp. -- -- 8005 SW Boeckman Road 503.685.7000 tel -- -- Wilsonville, OR 97070 USA 503.685.0921 fax -- ------------------------------------------------------------- -- Technical support ............ mailto:su...@mo... -- -- Sales and marketing info ....... mailto:sa...@mo... -- -- Licensing .................... mailto:li...@mo... -- -- Home Page ........................ http://www.model.com -- ------------------------------------------------------------- |