Run Time Errors must be forced quit!

View: New views
6 Messages — Rating Filter:   Alert me  

Run Time Errors must be forced quit!

by Jerry LeVan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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!

by Kevin Walzer-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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!

by Peter Caffin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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!

by Jerry LeVan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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!

by Uwe Koloska-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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!

by Jerry LeVan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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