From: Zbigniew Diaczyszyn on 18 Jul 2010 15:29 Perhaps someone has made a similar experience and could give me a hint: I have compiled an embedded Tcltk 8.5.8 version from the Sourceforge sources and taken the embedded Wish.app directory as a skeleton for my application bundle (see wrapping method described by Kevin Walzer). My application is working fine under Linux and Windows just the MacOSX bundle is crashing when I use a shortcut in the main window which is implemented like: bind . <Command-e> {.mbar.login invoke 1} The menu is implemented in this way: ..mbar.login add command \ -label [mc $menu_item] \ -command $menu_command \ -accelerator "Cmd-E" A mouse-click on the menu item - which is showing the correct apple key icon and the shortcut E - calls the appropriate menu command ie. a toplevel dialog. But if I am pressing Cmd-E in the main window the application crashes at the command: toplevel .mydialog Calling directly the dialog bind . <Command-E> {toplevelDialog} fails, too. The strange thing is that everything works well if I am putting an unused letter as the accelerator string , for example "Cmd-M" or even "". If I change the bind command to capital "e" and press "Cmd+Shift+E the toplevel dialog works, too. bind . <Command-E> {.mbar.login invoke 1} I do not understand this behaviour at all and would be appreciate any help.
From: Kevin Walzer on 18 Jul 2010 17:23 On 7/18/10 3:29 PM, Zbigniew Diaczyszyn wrote: > Perhaps someone has made a similar experience and could give me a hint: > > I have compiled an embedded Tcltk 8.5.8 version from the Sourceforge > sources and taken the embedded Wish.app directory as a skeleton for my > application bundle (see wrapping method described by Kevin Walzer). > > My application is working fine under Linux and Windows just the MacOSX > bundle is crashing when I use a shortcut in the main window which is > implemented like: > > bind . <Command-e> {.mbar.login invoke 1} > > The menu is implemented in this way: > > .mbar.login add command \ > -label [mc $menu_item] \ > -command $menu_command \ > -accelerator "Cmd-E" > > A mouse-click on the menu item - which is showing the correct apple key > icon and the shortcut E - calls the appropriate menu command ie. a > toplevel dialog. > > But if I am pressing Cmd-E in the main window the application crashes at > the command: > > toplevel .mydialog > > Calling directly the dialog > > bind . <Command-E> {toplevelDialog} > > fails, too. > > The strange thing is that everything works well if I am putting an > unused letter as the accelerator string , for example "Cmd-M" or even "". > > If I change the bind command to capital "e" and press "Cmd+Shift+E the > toplevel dialog works, too. > > bind . <Command-E> {.mbar.login invoke 1} > > I do not understand this behaviour at all and would be appreciate any help. > I can't reproduce this error, but here are a few common mistakes I've made with menu accelerators: 1. If you bind to <Command-E>, pressing <Command-e> will do nothing. Best to bind to both <Command-E> and <Command-e>. It's fine to set the menu accelerator to the capital letter, as long as both are bound. 2. <Cmd-E> is not a valid shortcut on the Mac. Looking at your code, I found that binding to Command-E and typing Command-e did nothing, as I expected. --Kevin Kevin Walzer Code by Kevin http://www.codebykevin.com
From: Zbigniew Diaczyszyn on 19 Jul 2010 07:49 Am 18.07.2010 23:23, schrieb Kevin Walzer: > I can't reproduce this error, but here are a few common mistakes I've > made with menu accelerators: Thank you, Kevin, for the quick response. I did some further debugging: If I try: bind . <$meta-e> {toplevel .test} then the toplevel window is appearing and answering well, but: set guimutex 0 bind . <$meta-e> { toplevel .test # Dialog with buttons changing # the global variable guimutex vwait guimutex # tkwait variable $guimutex } then I have no toplevel window but an empty white space. No chance to click on something or to change somehow the guimutex variable. Is the Tk event loop interfering with the Aqua event loop?
From: Kevin Walzer on 19 Jul 2010 09:56 > > If I try: > > bind . <$meta-e> {toplevel .test} > > then the toplevel window is appearing and answering well, but: > > set guimutex 0 > > bind . <$meta-e> { > toplevel .test > > # Dialog with buttons changing > # the global variable guimutex > > vwait guimutex > # tkwait variable $guimutex > } > > then I have no toplevel window but an empty white space. No chance to > click on something or to change somehow the guimutex variable. > > Is the Tk event loop interfering with the Aqua event loop? > > > There's not enough code here for me to reproduce this--can you post a self-contained example? -- Kevin Walzer Code by Kevin http://www.codebykevin.com
From: Zbigniew Diaczyszyn on 21 Jul 2010 11:06 Am 19.07.2010 15:56, schrieb Kevin Walzer: > There's not enough code here for me to reproduce this--can you post a > self-contained example? Here is a mini-program for creating the crash: Just clicking on the menu items everything is ok. But when you try the binding "meta+e" then you will see (hopefully :-) the crash. I tested the lines with the default tclsh (8.5.7) supplied from the installation DVD for Snow Leopard 10.6.2 and with tclsh 8.5.8 compiled freshly from the official sources. --- Code begin --- package require Tk 8.5 proc toplevelDialog {} { toplevel .dialog wm protocol .dialog WM_DELETE_WINDOW exit set ::mutex 0 vwait ::mutex destroy .dialog } set meta Control set menu_meta Ctrl if {[tk windowingsystem] == "aqua"} { set meta Command set menu_meta Cmd } menu .mbar .. configure -menu .mbar ..mbar add cascade -label Test -menu .mbar.test menu .mbar.test -tearoff 0 ..mbar.test add command \ -label Toplevel \ -command toplevelDialog \ -accelerator "$menu_meta-E" ..mbar.test add command \ -label "Set mutex 1" \ -command {set ::mutex 1} \ -accelerator "$menu_meta-S" ..mbar.test add command \ -label "Quit" \ -command {exit} \ -accelerator "$menu_meta-X" bind . <$meta-e> {.mbar.test invoke 0} bind . <$meta-s> {.mbar.test invoke 1} bind . <$meta-x> {.mbar.test invoke 2} --- Code end ---
|
Pages: 1 Prev: Font compatibility problem or bug Next: Code in dynamically evaluated environment |