Ticket UUID: | 901880 | |||
Title: | "Motion" binding fails during startup | |||
Type: | Bug | Version: | obsolete: 8.4.5 | |
Submitter: | cekim | Created on: | 2004-02-21 21:19:00 | |
Subsystem: | 21. [panedwindow] | Assigned To: | hobbs | |
Priority: | 5 Medium | Severity: | ||
Status: | Closed | Last Modified: | 2004-05-04 02:39:28 | |
Resolution: | Invalid | Closed By: | hobbs | |
Closed on: | 2004-05-03 19:39:28 | |||
Description: |
This code is called (within panedwindow.tcl) due to a binding of a panedwindow widget as my application is starting up (but prior to any user input): proc ::tk::panedwindow::Motion {w x y} { set id [$w identify $x $y] .... The trouble appears to be that while the application is starting up (widgets are being created), there is a race (within the various widgets, as I don't see how I can influence this...) between when this binding is assigned and when various resources are actually created (to the point that they support an "identify" call). I randomly get this error: Error: bad option "identify": should be one of... .... It happens 1 out of of 3 times I start up the application - the other 2 of 3 times everything works... It never occurs again after the application is running, presumably because now the resources is fully initialized and responds as expected to an "identify" request. The flow of my application is: 1. create toplevel 2. create panedwdiget 3. create child(ren) of panedwidget within "childsite(s)" 4. place, place, place 5. enter event loop I have had no luck creating a smaller application to demonstrate this as it appears that the shear size of my application is what increases the likelyhood that this race will occur. This root cause (failure to answer the "identify" request) might be a bigger problem, but it seems that this library code could/should trap this case as a matter of cleanliness (other calls in this file do similar things that ideally would have similar traps). As an additionaly note, running with a slower link to the Xserver (i.e remote display over wireless ethernet) reduces the occurance of this error to near zero - further demonstrating that this is a race of some sort... System info: Using VTCL as an IDE, but hand editing code after inital widget creation/placement RH 7/8/9 (same result on all) Window managers (same result on all): a. KDE b. remote display to NT + Xwin32 client c. gnome Using Tcl/tk ("wish") with itcl/itk/BLT/iwidgets all latest stable versions as of ~2/12/2004 The easy solution seems simple and harmless enough and perhaps should be applied to most of the bound functions in this file (panedwindow.tcl): --- panedwindow.tcl Fri Feb 20 17:08:23 2004 +++ panedwindow.tcl~ Mon Feb 9 13:14:48 2004 @@ -108,12 +108,7 @@ # proc ::tk::panedwindow::Motion {w x y} { variable ::tk::Priv - # this resource may not yet be fully initialized, if so return without - # doing anything... - if {[catch {set id [$w identify $x $y]}]} { - return - } - + set id [$w identify $x $y] if {([llength $id] == 2) && \ (!$::tk_strictMotif || [string equal [lindex $id 1] "handle"])} { if { ![info exists Priv($w,panecursor)] } { | |||
User Comments: |
hobbs added on 2004-05-04 02:39:28:
Logged In: YES user_id=72656 This is highly unlikely to be a core bug, as a core panedwindow binding is being called on something other than a panedwindow. cekim added on 2004-04-19 20:44:53: Logged In: YES user_id=886869 oops - panedwindow is in the tk8.4 dir... not tkincr Just to clarify... cekim added on 2004-04-19 20:35:17: Logged In: YES user_id=886869 Sorry for the delay in responding... 1. Do not have any files called panedwindow.tcl in my project 2. mixing widget sets? hmm, yes... using BLT and tkincr... tkincr is the paned window (obviously) BLT is being used for its container capabilities... The BLT container is a sub-frame within one of the pane childsites.... 3. The "should be" is a little harder, I will remove my patch and try to catch it (it is rather non-deterministic - dependant on CPU load...) /mike hobbs added on 2004-02-25 07:46:44: Logged In: YES user_id=72656 What is the "should be one of ..." part of the error? That is critical, as I don't think this is a core error. Are you sure that you aren't mixing widget sets, or have some main file called panedwindow.tcl, or some other case where Panedwindow class would be assigned somewhere it shouldn't be? |