Helloo again!
Okie, I think I have found a proper solution that doesn't just conceal
the error message. Actually, this solution is taken from a python
project called PMW (Python Megawidgets).
This is the snippet from the PMW project:
----------
while 1:
try:
if globalMode:
widget.grab_set_global()
else:
widget.grab_set()
break
except Tkinter.TclError:
# Another application has grab. Keep trying until
# grab can succeed.
self.after(100)
----------Anyways so I have implemented it into gui.tcl and tested it. As expected, no more errors are produced and the chat window is blocked from keyboard/input events until the close dialog closes and returns focus and events to the chat window. Which is what the code intended to do in the beginning. The proposed patch is attached. I hope it's enough to fix the problem! On Mon, Jan 12, 2009 at 1:03 AM, PEACEYALL <peacey...@gmail.com> wrote: > Ooh and btw, that problem of course happens after the second solution > is applied. > > On Mon, Jan 12, 2009 at 12:58 AM, PEACEYALL <peacey...@gmail.com> wrote: >> Hii Tom! >> >> Ya I thought of that too. Although there is one more problem that I >> have seen but it is extremelyhard to replicate so I really don't think >> it's that big of an issue. See, sometimes, if you click one of the >> buttons on the close dialog too fast, as in less than a second and i >> really mean less than a second, a tk error dialog will pop up with the >> following in the detail: >> "can't read "customMessageBoxAnswerTracker(ContainerClose)": no such >> element in array >> while executing >> "list $customMessageBoxAnswerTracker($uniqueId) >> $customMessageBoxRememberTracker($uniqueId)" >> (procedure "::amsn::customMessageBox" line 117) >> invoked from within >> "::amsn::customMessageBox [trans closeall] yesnocancel question [trans >> title] $window 1 1 "ContainerClose"" >> (procedure "::ChatWindow::ContainerClose" line 18) >> invoked from within >> "::ChatWindow::ContainerClose .container_14" >> (command for "WM_DELETE_WINDOW" window manager protocol)" >> >> Again, this hardly ever happens since I really don't think anyone is >> going to click one of the buttons on the close dialog in less than a >> second of it opening. Though, even when it does happen, it doesn't >> affect any functionality since the buttons and the whole dialog itself >> still works as expected and doesn't casue any visible problems, at >> leats none that I have found. >> Anyways, I think it would be safe to commit overall :D >> >> On Mon, Jan 12, 2009 at 12:46 AM, Tom Hennigan <tomhenni...@gmail.com> wrote: >>> Hey man thanks for your in depth description of the issue! >>> >>> I think that the second solution is better. The customMessageBox is used >>> in other places throughout aMSN's code base as well, and the modal >>> behavior may be necessary there. >>> >>> If no-one has any better solutions I will commit this? >>> >>> - Tom >>> >>> PEACEYALL wrote: >>>> Hello! >>>> >>>> This is my first time programming tcl so I barely know anything about >>>> how dialog boxes work in tk. Anyways, If I try to close the chat >>>> window while more than one tab is opened from the compiz-fusion scale >>>> addon (as in the expose mac os x-like feature in compiz-fusion), after >>>> the close dialog appears, an empty tk error dialog also appears with >>>> the following text as detail: >>>> "grab failed: another application has grab >>>> while executing >>>> "grab set $w" >>>> (procedure "::amsn::customMessageBox" line 106) >>>> invoked from within >>>> "::amsn::customMessageBox [trans closeall] yesnocancel question [trans >>>> title] $window 1 1 "ContainerClose"" >>>> (procedure "::ChatWindow::ContainerClose" line 18) >>>> invoked from within >>>> "::ChatWindow::ContainerClose .container_0" >>>> (command for "WM_DELETE_WINDOW" window manager protocol)" >>>> When that error dialog appears, the buttons on the close dialog no >>>> longer work and the only way I can close the chat window is to close >>>> each tab seperately until all the tabs have closed. In addition, now >>>> the close dialog that has appeared before isn't receiving any input >>>> and the only way to close it is to restart amsn or press the "esc" key >>>> while the close dialog is focused. >>>> >>>> Since I know nothing of tk, I can only think of two solutions which are: >>>> >>>> 1. Create the close customMessageBox as a non-modal dialog. (Since I >>>> don't think creating it as a modal dialog is that necessary on >>>> account that it would be perfectly fine if all events are still >>>> available in the chat window while the dialog appears in my opinion) >>>> >>>> 2. In the function ::amsn::customMessageBox on line 835, add a catch >>>> statement around "grab set $w" >>>> >>>> Actually both those solutions aren't actually solutions, they're just >>>> workarounds. >>>> The first one doesn't even run the grab statement anymore since the if >>>> block it's in wouldn't be run. >>>> The second one is a workaround since even though the tk error messgae >>>> dialog isn't displayed anymore and everything seems to continue as >>>> normal (i.e.: All the buttons on the dialog work as they're supposed >>>> to), the chat window still allows events/inputs and therefore the >>>> dialog isn't actually a "real" modal dialog anymore. Honestly, I can't >>>> evaluate which would be the better solution for the reason that >>>> they're both just quick workarounds. Though, I think the second one >>>> would be better because in this case, the only drawback is that even >>>> though the close dialog will stay a modal dialog, when an error like >>>> this should have appeared, it would suppress it and the chat window >>>> would still be able to receive events, but as stated before, the close >>>> dialog actually does receive input and work as the user expects in >>>> comparison to if the error was not suppressed. >>>> >>>> Anyways, for the second workaround, I have proposed the patch for it >>>> if someone wants to test it. >>>> >>>> Again, I am pretty much illiterate in Tk, so if someone has a better >>>> idea or has a proper solution, please say it. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the new SourceForge.net Marketplace. >>>> It is the best place to buy or sell services for >>>> just about anything Open Source. >>>> http://p.sf.net/sfu/Xq1LFB >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Amsn-devel mailing list >>>> Amsn-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/amsn-devel >>> >>> ------------------------------------------------------------------------------ >>> Check out the new SourceForge.net Marketplace. >>> It is the best place to buy or sell services for >>> just about anything Open Source. >>> http://p.sf.net/sfu/Xq1LFB >>> _______________________________________________ >>> Amsn-devel mailing list >>> Amsn-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/amsn-devel >>> >> >
gui-grab-wait-patch.patch
Description: Binary data
------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
