|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
|
|
Run Time Errors must be forced quit!Hi,
With Apple's Tcl/Tk it appears to me that runtime errors lock tcl in such a way that it becomes necessary to "Force Quit" from the finder. I am running MacOSX 10.6.1. Apples Tcl/Tk 8.5.7 For example: My db app creates several toplevel windows in response to menu actions. Initially I did not check for the existence of the toplevel before creating the rascal. So if someone were to choose the "Display The Readme" while the Readme window exists then a runtime error will occur since the routine will attempt to recreate the window. When the error dialog pops up the top of the dialog is just a white bar and the dialog cannot be dismissed ( all of the buttons are non functional). My only option (that works for me) is to use the finder 'kill'. I also have an older 8.5.2 ActiveState Tcl/Tk installed which 'works' properly in the presence of errors. Is this a known problem or have I borked something? Jerry ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Tcl-mac mailing list tcl-mac@... https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
|
Re: Run Time Errors must be forced quit!On 9/25/09 5:44 PM, Jerry LeVan wrote:
> Hi, > > > My db app creates several toplevel windows in response to menu > actions. > Initially I did not check for the existence of the toplevel before > creating the rascal. > > So if someone were to choose the "Display The Readme" while the > Readme > window exists then a runtime error will occur since the routine > will attempt to > recreate the window. > > When the error dialog pops up the top of the dialog is just a white > bar > and the dialog cannot be dismissed ( all of the buttons are non > functional). I've observed that Tk-Cocoa, at least in the 8.5 version, can sometimes lock up when displaying a Tk error window in the manner that you describe. However, that doesn't mean that the issue itself is because of Tk-Cocoa. Try running your app in Terminal--error messages will be logged there as well. That might help you figure out what's going on. -- Kevin Walzer Code by Kevin http://www.codebykevin.com ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Tcl-mac mailing list tcl-mac@... https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
|
Re: Run Time Errors must be forced quit!Kevin Walzer wrote:
> On 9/25/09 5:44 PM, Jerry LeVan wrote: >> My db app creates several toplevel windows in response to menu >> actions. >> Initially I did not check for the existence of the toplevel before >> creating the rascal. >> >> So if someone were to choose the "Display The Readme" while the >> Readme >> window exists then a runtime error will occur since the routine >> will attempt to >> recreate the window. >> >> When the error dialog pops up the top of the dialog is just a white >> bar and the dialog cannot be dismissed ( all of the buttons are non >> functional). > > I've observed that Tk-Cocoa, at least in the 8.5 version, can sometimes > lock up when displaying a Tk error window in the manner that you > describe. However, that doesn't mean that the issue itself is because of > Tk-Cocoa. Try running your app in Terminal--error messages will be > logged there as well. That might help you figure out what's going on. I always have the following in any of my procs that display dialogs: proc SomeDialog {} { set w .blah if {[winfo exists .blah]} { return } ;# Dialog already exists. (Rest of the dialog code...) } It avoids the error cropping up. Pete ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Tcl-mac mailing list tcl-mac@... https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
|
Re: Run Time Errors must be forced quit!On Sep 28, 2009, at 4:35 PM, Peter Caffin wrote: > Kevin Walzer wrote: >> On 9/25/09 5:44 PM, Jerry LeVan wrote: >>> My db app creates several toplevel windows in response to menu >>> actions. >>> Initially I did not check for the existence of the toplevel before >>> creating the rascal. >>> >>> So if someone were to choose the "Display The Readme" while the >>> Readme >>> window exists then a runtime error will occur since the routine >>> will attempt to >>> recreate the window. >>> >>> When the error dialog pops up the top of the dialog is just a white >>> bar and the dialog cannot be dismissed ( all of the buttons are non >>> functional). >> >> I've observed that Tk-Cocoa, at least in the 8.5 version, can >> sometimes >> lock up when displaying a Tk error window in the manner that you >> describe. However, that doesn't mean that the issue itself is >> because of >> Tk-Cocoa. Try running your app in Terminal--error messages will be >> logged there as well. That might help you figure out what's going on. > > I always have the following in any of my procs that display dialogs: > > proc SomeDialog {} { > set w .blah > if {[winfo exists .blah]} { return } ;# Dialog already exists. > (Rest of the dialog code...) > } > > It avoids the error cropping up. > > > Pete Yeah, I put the checks in after I realized that I had not done the checking.... I tried a couple of simpler examples but could not replicate the behavior. <rant> It has been tough for me since Snow Leopard came out... 1) My postgresql db had bizarre startup errors in the log. It took me until last week to figure out that the old startup plist was not properly working and postgresql was starting 'way to early' causing some name resolution problems in some components of postgresql and even caused a display name glitch in Apple Remote Desktop! 2) I can compile Tkhtml 2 ( following Kevin's hints ) but it segs out. 3) There is the above problem with Apple Tcl. 4) Komodo won't launch Apple's Tcl as an interactive shell. 5) mds cannot index my disk ( it dies in a variety of ways ) so spotlight does not work. Apple 'thinks' there are some 'bad' files somewhere on the drive... 6) I also have a weird problem with my Tcl/Tk Postgresql app when running in a Fedora 11 VM running on my mac. ( It is the same code that I run on the Mac and my other linux box). I have a pop-up menu defined on a Tktable triggered by the <command-button-1> sequence. It refused to work (only) in the VM version, so I added a button-3 trigger for the pop-up and now *both* of the triggers invoke the pop-up ARRGH... </rant> Thanks, I needed that :) Jerry ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Tcl-mac mailing list tcl-mac@... https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
|
Re: Run Time Errors must be forced quit!Hello Jerry,
Am Dienstag, 29. September 2009 schrieb Jerry LeVan: > I have a pop-up menu defined on a Tktable triggered by the > <command-button-1> sequence. It refused to work (only) in the > VM version, so I added a button-3 trigger for the pop-up > and now > *both* of the triggers invoke the pop-up ARRGH... Just a quick guess: Try the virtual event <<Button3>>. This should handle both variants gracefully -- and if I remember correctly: the right mouse button is button-2 on the mac. Yours Uwe Koloska -- Dipl.-Ing. Uwe Koloska Leiter Softwareentwicklung voice INTER connect GmbH Tel +351 481 088 3 Ammonstraße 35 Fax +351 438 399 25 01067 Dresden - Germany www.voiceinterconnect.de voiceINTERconnect www.voiceinterconnect.de ... smart speech applications from Germany Geschäftsführung: Dr.-Ing. Diane Hirschfeld, Ludwig Linkenheil Eingetragen im Handelsregister: Amtsgericht Dresden HRB 19466 ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Tcl-mac mailing list tcl-mac@... https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
|
Re: Run Time Errors must be forced quit!On Sep 29, 2009, at 5:01 AM, Uwe Koloska wrote: > Hello Jerry, > > Am Dienstag, 29. September 2009 schrieb Jerry LeVan: >> I have a pop-up menu defined on a Tktable triggered by the >> <command-button-1> sequence. It refused to work (only) in the >> VM version, so I added a button-3 trigger for the pop-up >> and now >> *both* of the triggers invoke the pop-up ARRGH... > > Just a quick guess: Try the virtual event <<Button3>>. This should > handle both > variants gracefully -- and if I remember correctly: the right mouse > button is > button-2 on the mac. > > Yours > Uwe Koloska > I have not tried <<Button3>> yet but it appears that the right button is button-3 in linux and the scroll-wheel is button-3 on the Mac... A couple of more anomalies with Apple Tcl 1) My app initially pops up a window with about 13 text fields ( Entries) that the user can use to specify to set properties of the postgresql session. For some unknown reason double clicking on an entry does *not* select the contents of the field. Of course Fedora ( real and vm) do not have this problem nor does an slightly older ActiveState Tcl/ Tk. I have not been able to duplicate this behavior with simpler examples. 2) I have a menu command that pops up a list of all of the tables in the database. I use a scrolled listbox to hold all of the table names. After the code fills the listbox I issue an 'update idletasks' command. With apple tcl the contents of the listbox do not show until I create 'one more event' as a user ie move the mouse, press a key, etc... I don't have this problem with any other Tcl/Tks that I have access to. I guess the road to a non-carbon base native Tcl/Tk is going to be a bumpy road. Jerry ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Tcl-mac mailing list tcl-mac@... https://lists.sourceforge.net/lists/listinfo/tcl-mac |
| Free embeddable forum powered by Nabble | Forum Help |