# ticket

tkt_uuid: 1488195fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: None
title: Solaris LP64 build incorrectly hardcodes /usr/openwin/lib
comment:
  Whether or not one specifies --enable-64bit when
  configuring tk 8.4.13, tk always hardcodes
  -R/usr/openwin/lib into both libtk-8.4.so and wish.

  I believe that's wrong when building for LP64 Solaris
  (e.g. generating ELF64 objects) -- if it's going to
  hardcode anything it should be -R/usr/openwin/lib/64.

  This type of thing no doubt applies to other multi-ABI
  platforms too (e.g. IRIX vs. IRIX64).


tkt_uuid: 634548ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: None
resolution: Accepted
title: OSX: scrollbar managed w/place disabled
comment:
  When the "place" geometry manager is used to put a scrollbar 
  widget the widget appears "disabled" and cannot be used.  This 
  does not happen to a "pack"ed scrollbar.

  Example code:

  listbox .lb1 -yscrollcommand {.sb1 set}
  scrollbar .sb1 -command {.lb1 yview} -orient vert

  for {set x 0} {$x < 100} {incr x} {
      .lb1 insert end $x
  }

  if {1} {
  place .sb1 -x 0 -y 0 -height 300 -width 16
  place .lb1 -x 16 -y 0 -height 300 -width 200
  } else {
  pack .sb1 -side left -fill both
  pack .lb1 -side left -fill both -expand on
  }

  wm geometry . "216x300"

  If you set the above example to use "pack" it works fine, but 
  otherwise the scrollbar is disabled.


tkt_uuid: 654233ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: Canvas arc item can't handle coord list
comment:
  The arc item do not handle coordinate lists well.

  % canvas 
  .c

  % .c create arc {10 10 20 20} -start 10 -extent 
  90
  unknown option "90"

  The bug is in tkCanvArc.c line 
  346 where 4 is subtracted instead of i.


tkt_uuid: 663981ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: Long dashed lines cause problems on canvases
comment:
  Long dashed horizontal lines cause problems for the
  canvas.  Consider
  the following script:

      pack [canvas .c]
     .c create line 0 20 100000 20 -width 4 -fill red -dash .
     .c create line -100000 40 100000 40 -width 4 -fill
  blue -dash .
     .c create line -32767 60 32767 60 -width 4 -fill
  green -dash .

  On Unix (RedHat 7.3),  the top red line is displayed
  correctly.  The
  middle blue line does not appear at all.  The lower
  green line initially
  does not appear.  But if you take another window and
  drag it slowly
  over top of the canvas, bits of the green line will
  appear as Expose
  events are processed.

  On win2k, (VMWare on the same RedHat 7.3 machine) the
  canvas
  displays correctly but expose events take about 10
  seconds to process.
  While expose events are pending, the CPU is maxed out
  at 100%
  usage and the display is locked up.

  The lines are displayed correctly (and quickly) if the
  -dash option is
  omitted.


tkt_uuid: 1957190fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Later
title: is "ttk::style element create" specification wrong?
comment:
  Hi,

  According to the docs, ttk::style element create is supposed to work like this:

    ttk::style element create elementName type ?args...?

  But then checking ttk.test at tk source package, I noticed it accepts this too:

    ttk::style element create plain.background from default

  And doing this:

    ttk::style element create plain.background from

  Returns me:

    wrong # args: should be "theme ?element?"

  Which confuses me even more, because I was expecting a return like: wrong # args: should be "ttk::style element  create name type ?options...?". 
  Does "plain.background from default" do something especial ? Does it return something that is then used by ttk::style element create ? Or is the specification incomplete ?

  Thanks


tkt_uuid: 220042ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Duplicate
title: <<ListboxSelect>> not documented
comment:
  OriginalBugID: 3499 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-08'
  LastModified: '1999-11-12'
  Severity: LOW
  Status: Closed
  Submitter: hobbs
  ChangedBy: hobbs
  RelatedBugIDs: 3500
  OS: All
  ClosedDate: '1999-11-12'


  Should also make examples of using it.


tkt_uuid: 2723425fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 8
foundin: obsolete: 8.4.19
resolution: Out of Date
title: "ButtonProc called on an invalid HWND "
comment:
  I think it is just the same as "W XP: ButtonProc called on invalid HWND - ID: 644641". I was able to reproduce it (thought not on tclsh/wish but on Tcl/Tk interpreter embedded into large C application). I believe that I have also debugged the problem and have a simple fix. Please read on:

  The problem is as follows: suppose you're creating a big number of buttons, and that under heavy load. Just immediately after issuing request to create them, you decide (for some reason) to delete them. It can happen (in fact, this is required for the bug to occur) that their (buttons) respective windows are not created yet when command for them to be destroyed is issued. It can also happen that their respective parent windows are not created, too. I believe that their creation requests (X events emulated on top of Win32 messages) are still in message queues at the time.

  Now, for some obscure reasons, Tk_DestroyWindow procedure calls Tk_MakeWindowExists if the former is called on not-yet-created window. Just like that:
  if (winPtr->window == None) {
      Tk_MakeWindowExist(tkwin);
  }
  Tk_MakeWindowExist for a given window can, in turn, cause Tk_MakeWindowExist call on parent window, if said parent window is not existent at the moment. Example code:
  if (winPtr->parentPtr->window == None) {
      Tk_MakeWindowExist((Tk_Window) winPtr->parentPtr);
  } 
  (tkwindow.c:1716 in tk version 8.4.16)
  Now the problem is, that somewhere along stack filled with recursive Tk_MakeWindowExist calls, event loop is being processed. That event loop can cause original creation requests for our buttons to be executed, and windows actually created, along with attaching (via Tk_AttachHWND) window handles to them. But, what follows in Tk_MakeWindowExist is _nonconditional_ call to CreateProc for current window, which causes this very same window to be re-created and re-attached to different handle. Handle window was originally attached to gets "orphaned" because of this (adding new mapping to Tk_AttachHWND causes old mapping to be removed). Thereby, when some event (Win32 message, actually) makes it's way to this HWND's ButtonProc, lookup for apropriate Tk_Window causes NULL to be returned and panic called in ButtonProc.

  So, to sum things up:
  1. Tcl script causes hierarchy of windows containing few buttons to be created. Creation requests for these are issued to queue but not executed yet (they have no physical windows), when...
  2. Request comes to delete all these buttons. Doing so requires their actual _creation_, so Tk_DestroyWindow calls Tk_MakeWindowExist (which can call itself recursively). Recursive execution of Tk_MakeWindowExist may cause event loop execution and creation of windows for buttons and controls.
  3. But on returing from recursive calls to Tk_MakeWindowExist, this very procedure makes no effort so as to check if window was created meantime, it just assumes that it has to create it. This can cause re-creation of already created window, and by this removing of HWND to TkWindow map entry, resulting in "orphan" HWND.
  4. Any message arriving to "orphaned" HWND (from some later-executed event loop) causes it to get NULL from HWND to TkWIndow map and, in consequence, panicking.

  Fortunatelly, resolution for this effect is very simple. It is enough to add simple check in Tk_MakeWindowExist, _just_ after Tk_MakeWindowExist was called recursively for parent window, like that:

  // original code from Tk_MakeWindowExist, calling recursively itself for parent
  if (winPtr->parentPtr->window == None) {
      Tk_MakeWindowExist((Tk_Window) winPtr->parentPtr);
  }
  parent = winPtr->parentPtr->window;
  } // from earlier if

  // this is added protection code
  if( winPtr->window != None ) {
      return;
  }

  // this is original, unconditional creation of window
  createProc = Tk_GetClassProc(winPtr->classProcsPtr, createProc);
  // and so on


  I have tested this and it works. I would prefer not to provide test environment, because that is really big and proprietary application, and setting for up it's compile environment alone takes days. Anyway, I had 100% reproductible test case, and after adding simple test (just like described above) problem is gone. In case of questions, doubts, etc, please contact m<dot>adamczak<at> google mail.

  Regards
  Michal


tkt_uuid: 831627ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: if embedded windows used, exit command causes a crash
comment:
  If I create any embedded windows in wish 8.4.4 (using 
  the toplevel's -container and -use options), issuing the 
  command "exit" will cause wish to pop the error 
  message "TkGetOtherWindow couldn't find window" and 
  then to crash.

  For example, sourcing the following script will crash wish 
  8.4.4:

      set parent [ toplevel .parent -container 1 ];
      
      set embedded [ toplevel .embedded -use [ winfo id 
  $parent ] ];
      
      exit;

  The problem seems to occur because the embedded 
  windows list is not cleared properly.  File 
  win/tkWinEmbed.c:

  ThreadSpecificData *tsdPtr =  (ThreadSpecificData *)
  Tcl_GetThreadData(&dataKey, sizeof
  (ThreadSpecificData));

  tsdPtr->firstContainerPtr

  etc.


tkt_uuid: 940117ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: Bwidget&TKAqua&Tabs--Problem with entry
comment:
  Try to write something in the "entry", or just give focus to the 
  entry. And then switch tabs...
  The entry will be include in the next tabs...! Very strange
  We don't have that problem on Linux or Windows..

  Tk Aqua 8.4.5
  Mac OS X



  ---begin tabstest.tcl---

  package require BWidget

  proc test_tabs {} {
  NoteBook .nb
  .nb insert 0 tab1 -text "Tab 1"
  .nb insert 1 tab2 -text "Tab 2"


  set tab [.nb getframe tab1]
  ScrolledWindow $tab.sw
  ScrollableFrame $tab.sw.sf -constrainedwidth 1
  $tab.sw setwidget $tab.sw.sf
  pack $tab.sw -anchor n -side top -expand true -fill both
  set tab [$tab.sw.sf getframe] 
  entry $tab.l1 -text "-- Just a test label --"
  pack $tab.l1 -side top
  label $tab.l2 -text "-- Just a test label --"
  pack $tab.l2 -side top
  checkbutton $tab.l3 -text "Zoum" -variable prueba
  checkbutton $tab.l4 -text "HOLY HOLY" -variable prueba
  pack $tab.l3 -side top
  pack $tab.l4 -side top


  set tab [.nb getframe tab2]
  ScrolledWindow $tab.sw
  ScrollableFrame $tab.sw.sf -constrainedwidth 1
  $tab.sw setwidget $tab.sw.sf
  pack $tab.sw -anchor n -side top -expand true -fill both
  set tab [$tab.sw.sf getframe]
  label $tab.l1 -text "***** TEST LABEL IN TAB 2 ****"
  pack $tab.l1 -side top
  label $tab.l2 -text "***** TEST LABEL IN TAB 2 ****"
  pack $tab.l2 -side top

  .nb compute_size
  .nb raise tab1
  pack .nb
  }

  test_tabs

  ---end tabstest.tcl---


tkt_uuid: 3086887fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Accepted
title: Aqua <Expose> events redraw whole subwindow
comment:
  Run the attached script in Cocoa 8.6 Wish.  It creates 2 toplevels titled "OK" and "FAIL" with a text widget and scrollbar in each toplevel.
  The "FAIL" window has an additional frame widget around the text and scrollbar.

  If you scroll the text widgets you can see <Expose> messages in the console showing the %h and %w fields of the <Expose> events.

  For the "OK" window the height %h is what you'd expect, 15 pixels when one line is scrolled.
  For the "FAIL" window the height %h is the height of the entire text widget, meaning the whole text widget gets redrawn during scrolling.

  When I comment out the lines below in tkMacOSXWindowEvent.c GenerateUpdates() the problem goes away:

      if (!Tk_IsTopLevel(winPtr)) {
  ChkErr(TkMacOSHIShapeUnion, boundsRgn, updateRgn, updateRgn);
  HIShapeGetBounds(updateRgn, updateBounds);
      }


tkt_uuid: 3044863fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Tk Mac crashes when accelerator key spawns window
comment:
  I have a cross-platform application that I have just added menu accelerators (keypress shortcuts) to.Works fine on Tcl/Tk in Linux and in Windows (Cygwin Insight). Freezes on Mac OS X 10.6 Snow Leopard when an accelerator key is pressed to spawn a window.

  I have a demonstration of this freeze (can't upload the tarball code, there's a 256k limit):
  http://personal.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/src/unreleased/savi-dev-kevin.tar.gz
  tar xvf savi-dev-kevin.tar
  cd savi-dev-kevin
  make ARCH=macosx
  ./savi &
  Click on the letterbox-shaped table-of-numbers window, then press either command-G to spawn the Global coverage window, command-F to spawn the fisheye window, or command-M to get the _empty space_ dialog - all windows will draw but missing a Mac titlebar and controls, and then the application freezes.

  If you relaunch savi and only point and click on the menu options, everything is fine. If you relaunch savi and force use of popup menus rather than the Mac menubar with the savi -redrawn-menus flag (more on the reason for that flag below), accelerators work fine. It's accelerators plus the Mac menubar that is the problem.

  A previous example you may have read about on the tcl-mac mailing list: The Tk Mac menubar never worked at all in 10.5 when Tk applications were launched from the terminal (I implemented a workaround for that in savi with -redrawn-menus and popup menus within window frames that avoided using the broken menubar - oddly, I see accelerators work fine from the Mac popup menus I implemented to work around that previous problem. Again, it's related to the Mac menubar). The release of 10.6 and the upgrade to Tcl/Tk in Xcode eventually fixed that problem (along with other Mac-specific problems like too-wide listboxes causing hangs), but that took eighteen months to happen, and has now exposed this crash.

  This appears at first glance to be a similar _maybe the Tk shipped with 10.7 will fix it_-level Mac menuing bug; I do not see what I can do about it, as the installed base on Snow Leopard has Xcode with Tcl/Tk 8.5.7 and that's it.

  Tk on the Mac should imo be as robust as Tk on other platforms, and should not require workarounds to prevent crashes.

  (I posted about this to the tcl-mac list, but, despite being a subscriber, my posts hit a filter rule and are queued for a moderator to look at. Hence the background detail here.)


tkt_uuid: 1567292fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: None
resolution: None
title: font size and tk scaling
comment:
  Font size selection in 8.4.13 depended on the
  current [tk scaling] factor, but doesn't do so in
  8.5a4 or the cvs HEAD version.

  The way it used to work was odd, if any item
  was using a particular font and size, the scaling
  factor was locked for that size until nothing was
  using it, then it would be recalculated.


  In the following script, in 8.4.13, initially it shows
  the first line smallest and second line largest;
  after the delay, the third line is smallest, the
  first line is the same size as the 2nd line was
  initially, and the second line is still largest,
  and larger than it was.

  In 8.5, initially it shows the first line largest and
  the third line smallest; then lines 1 and 2 swap,
  and none are scaled by the scaling factor.

  Note that a font in the context of a canvas should
  use the scaling factor of that canvas, even if
  tk scaling has been changed since then, as distance
  conversions in that canvas are all scaled based on
  the scaling factor at the time the canvas was created.

  tk scaling 1.25
  canvas .a -width 5i -height 5i -background grey45
  .a create rectangle 1i .2i 4i .8i -fill white
  .a create text 2.5i .5i -text {Sample text} \
          -font {Helvetica 14}

  tk scaling 2.5
  .a create rectangle 1i 1.2i 4i 1.8i -fill white
  .a create text 2.5i 1.5i -text {Sample text} \
          -font {Helvetica 12}

  .a create rectangle 1i 2.2i 4i 2.8i -fill white
  .a create text 2.5i 2.5i -text {Sample text} \
          -font {Helvetica 10}

  pack .a

  update
  after 2000

  tk scaling 1.25
  .a itemconfigure 2 -font {Helvetica 12}

  tk scaling 2.5
  .a itemconfigure 4 -font {Helvetica 14}


tkt_uuid: 1213864fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 02. Appearance
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: None
title: checkbutton text truncated on Aqua
comment:
  For aqua checkbuttons with indicatoron false, the text is truncated 
  on the bottom and on the left and right edges, making it very hard to 
  read. (There is just barely enough space above the text to avoid 
  truncating it there, but the margin is small enough to make it hard to 
  read).

  Thus not only are the margins too small, but the text could use to be 
  shifted up a bit.

  With the default fonts for each system, I find that padx = 5 and pady 
  = 5 on aqua matches the appearance on unix (except that the aqua 
  text is a bit too low). However, the x margin is a bit small even on 
  unix, so I use padx=2 on unix and padx=6 on Aqua.

  Optimally, the checkbutton behavior on aqua could be modified so 
  that all of these are true:
  - A given value of padx and pady would give approx. the same 
  appearance on all platforms, and 
  - The text is readable by default.
  - The text is readable at padx = pady = 1

  If that is not reasonable, then perhaps set a minimum padx and 
  pady on aqua?

  Note: the behavior with indicatoron true is already fine. The problem 
  only occurs with indicatoron false.


tkt_uuid: 220740ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: .text search -- pattern p1 p2 does'nt count elided chars
comment:
  OriginalBugID: 5470 Bug
  Version: 8.3
  SubmitDate: '2000-05-12'
  LastModified: '2000-07-21'
  Severity: MED
  Status: Released
  Submitter: angie
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-07-21'
  FixedInVersion: 8.4a2
  ClosedDate: '2000-06-21'


  Tk 8.3 Bug

  Name:  Wolf Busch
  email:  wolf-dieter.busch@t-online.de
  Support:  None
  Severity:  3
  OperatingSystem:  Windows 95
  Machine:  Pentium 200
  Extensions:  none
  Synopsis:  .text search -- pattern p1 p2 does'nt count elided chars

  ReproducibleScript:
  script: 
  text .text; 
  ...
  .text search -- $pat i


  ObservedBehavior:
  returns the found position, but counts only non-elided chars.

  DesiredBehavior:
  should return the found position *including* elided chars

  Patch:
  sorry, I don't understand C 
  Posted To comp.lang.tcl: Posted Successfully

  I am unable to duplicate the behavior you describe.  It works fine when I try it:

  % info patch
  8.3.0
  % pack [text .t]
  % .t insert end "foobar\nbarbaz\nbazboo"
  % .t tag configure hidden -elide true
  % .t tag add hidden 2.0 3.0
  % .t search boo 1.0
  3.3

  As you can see, the index it returns is correct, including the elided characters.  Can you provide more information?  Specifically, can you show us exactly what you are doing, the exact contents of the text widget, the exact result that [.text search] gives you, and the exact result that you expect to see?

  Thanks,

  Eric Melski
  Ajuba Solutions

  -- 06/21/2000 ericm

  From the user:

  The bug occurs counting letters inside the line. Try this:

  % info patch
  8.3.1
  % pack [text .text]
  % .text insert end 12345H7890
  % .text search 7 1.0
  1.6
  % .text tag configure hidden -elide true
  % .text tag add hidden 1.5
  % .text search 7 1.0
  1.5
  %

  Before letter H is hidden, search returns 1.6
  After letter H is hidden, search returns 1.5

  Yours Wolf

  -- 
  -- 06/22/2000 ericm

  Thanks for finding this bug.  I have corrected the problem and committed the fix to the CVS source repository.  The fix will go out with Tcl/Tk 8.4a2.

     Eric Melski                            The Other Tcl Guy
     ericm at ajubasolutions.com            Ajuba Solutions

  -- 07/21/2000 ericm


tkt_uuid: 690169ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: None
resolution: Fixed
title: resize problem with -minsize
comment:
  Take the following script:

  package require Tk

  panedwindow .p
  label .f1 -text "qwertyuiop" -bg blue
  label .f2 -text "azertyuiop" -bg red

  .p add .f1 -sticky news 
  .p add .f2 -sticky news -minsize [winfo reqwidth .f2]
  pack .p -side top -fill both -expand 1 

  wm geometry . 300x200

  And play with it:
  - Move the sash to the right until the red label reach
  its minsize
  - Shrink the toplevel horizontally. The red label keep
  its size, but is clipped. I can understand and accept
  this behaviour.
  - Now, move the sash to the left: the red label grow,
  instead of keeping its minimum size.

  -eric


tkt_uuid: 3106893fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: Notebook Tabs on Mac Drawn in Center
comment:
  Since 3105495 was closed, I cannot make comments. So I have opened a new case.

  Joe English stated that Tabs in the center is the OSX standard. We cannot think of any apps where this is true. Some examples of tabs on the left are:

  Excel, Safari, Adium. What apps under OSX have tabs centered?


tkt_uuid: 1467938fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 9 Immediate
foundin: obsolete: 8.5a4
resolution: Fixed
title: searching in file dialog crashes
comment:
  Hi,
  I found a bug with tk 8.5a4, latest CVS, it's easy to 
  reproduce, open a file chooser (under unix) and press a 
  key, for example 'a' (as in 'go to the first file 
  beggining with the letter 'a'). It will generate a bug. 
  I'm pasting here the trace of the bug :

  can't read "start": no such variable
      while executing
  "set i $start"
      (procedure "IconList_Goto" line 18)
      invoked from within
  "IconList_Goto $w $Priv(ILAccel,$w)"
      (procedure "tk::IconList_KeyPress" line 5)
      invoked from within
  "tk::IconList_KeyPress .cfg.notebook.nn.__tk_choosedir.
  icons a"
      (command bound to event)

  good luck.
  KaKaRoTo


tkt_uuid: 2949356fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 1 Zero
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: Cocoa Tk does not deiconify from Dock icon
comment:
  After iconifying Wish or our app (UCSF Chimera) that uses Tk Cocoa 8.6 Jan 8, 2010 source code, the app does not deiconify when the Mac Dock icon for the application is clicked. There are generally two icons shown on the Mac Dock, the application icon, and the instance icon.  The instance icon shows a miniature image of the app window.  The app icon show the application standard icon.  The instance icon correctly deiconifies the app.  The app icon does nothing when clicked.  The windows remain iconified.  All Mac app icons are supposed to deiconify the running application when clicked.  In Carbon Tk 8.5.8 deiconifying using the app icon works correctly.  The incorrect behavior is seen on Mac OS 10.6.2.  The same incorrect behavior is exhibited by the system Wish (/usr/bin/wish, Tk 8.5.7) on Mac OS 10.6.


tkt_uuid: 466773ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Invalid
title: Checkbuttons look wrong when activated
comment:
  In Windows Me with Tcl/Tk 8.3.3, checkbuttons keep a
  grey background when activated, they don't change it to
  white
  until they get a <Leave> event.


tkt_uuid: 220401ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Bug in &quot;wm maxsize&quot; on Win 95 and NT (8.0.3)
comment:
  OriginalBugID: 878 Bug
  Version: 8.0.3
  SubmitDate: '1998-11-25'
  LastModified: '2000-04-03'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-04-03'
  FixedInVersion: 8.3


  From: Jeff David <jldavid@enteract.com>

  Try this simple chunk of code in 8.0.3:

      set win .w
      set x [expr int(.3 * [winfo screenwidth .])]
      toplevel $win

      text $win.txt -wrap word -yscrollcommand "$win.sb set"
      scrollbar $win.sb -orient vert -command "$win.txt yview"
      pack $win.txt -side left -fill both -expand true
      pack $win.sb -side right -fill y
      $win.txt insert 0.0 "This is a test"

  #    set x [expr int(.3 * [winfo screenwidth .])]
      update idle
      set x [winfo reqwidth $win]
     wm maxsize $win $x [winfo screenheight .]
      wm geometry $win "-0+0"
      update idletasks

  It works as expected.  It places a text widget and scrollbar
  widget in $win and places it in the upper right corner of the
  screen.

  Now, uncomment the "wm maxsize..." line.  Not only is the window
  no longer positioned in the upper right corner of the screen, but
  the scrollbar disappears!

  I've tested this on both Windows 95 and Win NT 4.0.  Same thing.
  "wm minsize" seems to work fine.  Any known fixes/workarounds?

  The geometry management bug was fixed in 8.3, and the reason
  that the scrollbar disappears is because we've asked for a
  space in the 'pack'ed window that only fits the text widget.
  The user should use grid geometry management, or make a smaller
  default text box.  Really, the user probably wants:
     update idle ; set x [winfo reqwidth $win]
   
  -- 04/03/2000 hobbs


tkt_uuid: 1581435fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: None
title: menu index wrong if label is an integer
comment:
  If a menu contains an item whose label is an integer,
  then menu index returns the value of that menu item,
  or if the integer is too large, then it returns
  the index of the last item in the menu.

  Here is a procedure to see this.
  Enter it into wish and select menu items to see the index.
  The index of entry "3" is reported as 3, but should be 1.

  menubutton .mb -m .mb.menu -text testmenu
  pack .mb
  set m [menu .mb.menu]
  $m add command -label foo -command {puts "foo: [$m index foo]"}
  $m add command -label 3 -command {puts "3: [$m index 3]"}
  $m add command -label 3a -command {puts "3: [$m index 3a]"}
  $m add command -label bar -command {puts "bar: [$m index bar]"}
  $m add command -label baz -command {puts "baz: [$m index baz]"}

  I saw this on ActiveState Aqua Tcl/Tk 8.4.13 on MacOS X 10.4.7. I have 
  not tried to duplicate it on other operating systems nor with 8.4.14 
  (since the ActiveState version is not yet available).


tkt_uuid: 495549ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 74. Application Embedding
priority: 5 Medium
foundin: None
resolution: Accepted
title: Allow easier embedding on Mac OSX
comment:
  This patch, developed by Robert Kedoin and I, moves
  some MacOSX-specific calls out of the Tcl_AppInit
  function and into the TkpInit function.  This frees
  applications that embed Tcl/Tk from making those same
  MacOSX specific calls in thier own Tcl_AppInit.

  (The good stuff is due to Robert, blame me for bad stuff)


tkt_uuid: 220552ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 34. [tk_chooseColor]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: parent of tk_chooseColor Dialog Box
comment:
  OriginalBugID: 2334 Bug
  Version: 8.0p2
  SubmitDate: '1999-07-07'
  LastModified: '2000-03-01'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Unix
  FixedDate: '2000-03-01'
  FixedInVersion: 8.3.1


  Name:

  Didier Willam



  ReproducibleScript:

  # ... start wish on screen: tgv4:0.0

      toplevel .test -screen tgv4:0.1

      tk_chooseColor -parent .test

      

      and the Color Dialog Box appears on screen tgv4:0.0. It should appear on

      tgv4:0.1.



  ObservedBehavior:

  The sceen of the child window is wrong!



  DesiredBehavior:

  To see the window on the right screen.



  Patch:

  *** clrpick.tcl.old     Mon Jul  5 15:01:11 1999

  --- clrpick.tcl Mon Jul  5 14:59:31 1999

  ***************

  *** 25,33 ****

    #

    proc tkColorDialog {args} {

        global tkPriv

  !     set w .__tk__color

        upvar #0 $w data

   

        # The lines variables track the start and end indices of the line

        # elements in the colorbar canvases.

        set data(lines,red,start)   0

  --- 25,45 ----

    #

    proc tkColorDialog {args} {

        global tkPriv

  !

  !     set w tkPrivMsgBox

        upvar #0 $w data

   

  +     # Parse args to obtain the parent window

  +     tkColorDialog_Config $w $args

  +

  +     # Set the correct window path

  +     if [string compare $data(-parent) .] {

  +       set w $data(-parent).__tk__messagebox

  +     } else {

  +       set w .__tk__messagebox

  +     }

  +     upvar #0 $w data

  +

        # The lines variables track the start and end indices of the line

        # elements in the colorbar canvases.

        set data(lines,red,start)   0



  PatchFiles:

  lib/tk8.0/clrpick.tcl





  As you noted, the choose color dialog was not picking up the screen setting from its parent.  I fixed the problem slightly differently than you did, by having the dialog instead query its parent for a screen value, and creating the dialog with that value for its screen.  If the dialog has already been created, it will test for equivalence between the dialog's screen and the parent's screen, destroying and recreating the dialog if they are different.
  This cuts down on the proliferation of toplevels that would be seen with the patch you submitted, although it will cause a destroy/recreate every time you bring the dialog up on an alternate screen.  However, that should not happen so frequently that it becomes a problem.

  This fix will go out with 8.3.1.

  - eric

  -- 03/01/2000 ericm


tkt_uuid: 220229ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Invalid
title: WinNT Dr Watson when using WM_DELETE_WINDOW
comment:
  OriginalBugID: 2640 Bug
  Version: 1.3
  SubmitDate: '1999-08-31'
  LastModified: '1999-11-16'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT 4.0 SP4
  Machine: X86
  ClosedDate: '1999-11-16'


  Name:

  Raultk Segura Acevedo



  Comments:

  under my NT it does NOT crash if I pass "My_Exit"'s body as an argument

      to "wm protocol . WM_DELETE_WINDOW...", but it does under win95.

      it doesn't crash if I remove the line "if {$modificado..." nor with a

      shorter "set out [tk_messageBox..." command



  ReproducibleScript:

  run the following script and close it pressing Alt-F4 or clicking the

      button x

      

      set modificado 0

      wm protocol . WM_DELETE_WINDOW "My_Exit"

      

      proc My_Exit {} {

        global modificado

      

        if {$modificado == 0} {destroy .}

        set out [tk_messageBox -type yesnocancel -title "Confirmacion"

      -message \

          "El archivo no ha sido guardado.\nGuardar el archivo antes de

      salir?"]

        destroy .

      }



  ObservedBehavior:

  prowish82 crashes under windows, I get a Dr. Watson window and a memory

      dump on NT and a message error on Win95



  DesiredBehavior:

  a clean program termination





  Not verifiable on NT or 98 with 8.2.1, or NT with prowish82
  (Tcl 8.2.0). 
  -- 11/16/1999 hobbs


tkt_uuid: 1336531fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: Accepted
title: Drop use of Tcl internals
comment:
  Several files matching tk/macosx/tkMacOSX*.c
  include the private header file tclInt.h.  Most
  of them, I see no reason why this is so --
  perhaps a vestige of some copy/paste?

  tkMacOSXNotify.c uses TCL_TSD_INIT
  which ought to just be replaced by its
  expansion, which is fully public.

  tkMacOSXScrlbr.c calls TclServiceIdle()
  which is the only obvious need for access
  to Tcl privates.  If this cannot be done
  away with, perhaps a TIP to expose
  TclServiceIdle in Tcl's public interface
  is in order?


tkt_uuid: 3009450fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: Can't deiconify window if a child toplevel is grabbed
comment:
  Under windows, if a child toplevel has a grab and is transient, you can not deiconify the application.

  # Better example than words:
  package require Tk
  toplevel .t
  wm transient .t .
  grab .t

  # Now, click on "Show desktop" button
  # You will not be able to deiconify the application

  Bug introduced by resulotion of #1847002 ?


tkt_uuid: 1583065fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Test suite hangs on Windows XP - "Annuleren", not "Cancel"
comment:
  The test suite on Windows XP works automatically up to
  the point where the file selection dialogues are tested.

  On my particular system the text labels are in Dutch.
  Test winDialog-4.1 fails because the test returns 
  "Annuleren" instead of "Cancel". 

  But:
  - the file selection dialogue remains visible
  - after closing the dialogue manually the test suite
    "hangs" - no further tests are made.


tkt_uuid: 220539ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: wish8.1 cannot find tk.tcl
comment:
  OriginalBugID: 2225 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-15'
  LastModified: '1999-11-16'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: SunOS
  OSVersion: SunOS amazone 5.5.1 Generic_103640-24 sun4m sparc SUNW,SPARCstat
  Machine: Sparc
  FixedDate: '1999-11-16'
  FixedInVersion: 8.2


  Name: Bert Helthuis

  ReproducibleScript:
  Solaris 2.5, SUN'c C-compiler, sparc, tcl/tk 8.1.1
      
      did (standard)
      ./configure --enable-shared --prefix=/Window/X11/contrib/lib/tk8.1.1
      
      starting wish8.1 gave warning message that tk.tcl could not be found

  ObservedBehavior:
  The paths reported in the search for tk.tcl don't include TK_LIBRARY
      from the Makefile, which in my opinion should be the case.

  DesiredBehavior:
  TK_LIBRARY variable in unix/Makefile is not used in finding tk.tcl,
      although it is used in a -D-define when compiling tkUnixInit.c



  Could not reproduce this problem with 8.2 (it does include
  the prefix in the search path), so this was either fixed,
  or somehow the user's library was mangled (perhaps it picked
  up an older libtcl). 
  -- 11/16/1999 hobbs


tkt_uuid: 1809538fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5b1
resolution: Fixed
title: <<Modified>> lost before text widget mapped
comment:
  <<Modified>> event is not generated when text is changed before it is shown on screen. Example (demonstrated with 8.5b1 tclkit but also seen with 8.4 wish):

  # ./tclkit-linux-x86-8.5b1
  % package require Tk
  8.5b1

  % text .t; bind .t <<Modified>> "puts MOD"; pack .t; .t insert insert "xxx"
  % 

  Text was modified but the binding did not trigger. If the same thing is done in two pieces, it triggers as expected:

  # ./tclkit-linux-x86-8.5b1
  % package require Tk
  8.5b1

  % text .t; bind .t <<Modified>> "puts MOD"; pack .t;
  % .t insert insert "xxx"
  MOD
  % 

  One use for <<Modified>> is tracking all changes to text. To ensure continued tracking, one has to reset the modified flag (and do it with some caution, as explained in tk bug #1799782). User is likely to prepare this chain before the text is mapped onscreen. If the initial text is not empty, the bug (the one I report now) completely breaks any tracking by subverting the chain at the very start. Workaround is to do [.t edit modified 0] AFTER getting the widget onscreen.

  This bug may be related to another one, which I errorneously reported in the tk patch tracker as #1737288. Then Danckaert provided a patch - maybe that patch may also fix this issue, or at least help to understand it. Now I tested 8.5b1 and 8.5a6, thought I cannot force segfault, both versions still look broken as demonstrated by my "AAX" test described in 'patch' #1737288. So I suppose Danckaert's patch is not in 8.5b1 (he patched against 8.5a6).


tkt_uuid: 2844573fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Invalid
title: images missing from radiobuttons on Mac
comment:
  I have an "option menu" that uses images for selecting line types.  On Windows and on X11 it works.  But on the Mac, 10.4 and 10.5, while the image for the chosen type shows up just fine in the menu button, on the radiobuttons, it just says "(Image)".  If I switch the radiobuttons from using -value to the undocumented -label, then it shows the appropriate text, but still no image.


tkt_uuid: 1118340fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 8
foundin: obsolete: 8.4.9
resolution: Fixed
title: MouseWheel event under Win32 can cause crash
comment:
  This is most easily exposed by using Python's Tkinter interface -- 
  since I don't really know anything about Tcl, I cannot submit 
  sample code.  The problem is very obvious, though.

  In source file win/tkWinX.c, function GenerateXEvent(),

  case WM_MOUSEWHEEL:
  ...
     event.xany.send_event = -1;
  ...

  This line should clearly not be present.  This line causes Tk to call 
  TkpGetString() when ExpandPercents() is called with '%A' (which is 
  done by Python for ALL events, including <MouseWheel>).  This, in 
  turn, causes segmentation fault because event.xkey.trans_chars 
  and event.xkey.nbytes are not initialized.

  The fix is simply to remove this line of code, since 
  event.xany.send_event has been initialized to False.


tkt_uuid: 1060492fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Wont Fix
title: make install fails if binary installed
comment:
  The binary installation creates a different
  installation vs the make install, where a link/alias is
  created for Wish Shell.app in /Applications/Utilities.
  The source make install tries to install Wish Shell.app
  in /Application/Utilities directly, and chokes on the
  alias during install and fails. Understandably the
  project maintainers may not have any involvement in the
  development of binary installs but if you provide
  binaries from the project, either installation should
  be standardized or the source installs should account
  for this condition.


tkt_uuid: 1783474fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 3 Low
foundin: obsolete: 8.4.15
resolution: Wont Fix
title: Loading font when creating a widget
comment:
  Current policy for obligatory loading a default font first (when creating a widget) - and only then checking the option's "-font xyz" ev. existence - causes a long delay in case of unix-like systems, most probably because of the client/server architecture of X-Window.

  It can be easily checked using following code:

  set ii 0
  set report [time {
    label .label$ii -text "label #$ii" -font "Helvetica 10"
    pack .label$ii
    puts $ii
    incr ii
  } 200]

  ...when the "-font" option will be removed, the construction of such window will be done about 25 times(!) faster, than while using that option. The 
  details were cleared in the discussion thread available at: http://tinyurl.com/ytjs3u


tkt_uuid: 1491881fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: Problem with SetLayeredWindowAttributes and Tk windows
comment:
  If I try to use SetLayeredWindowAttributes on a Tk
  window, either to set transparency, or chroma keying,
  it doesn't work, nothing happens.  It does not matter
  if I do it within the application (via an extension I
  wrote) or from outside the application (in another tk
  app).  My library can control the chroma keying and
  alpha transparency of non-tk windows just fine. There
  are a variety of other programs for setting alpha
  transparency and none of those work on Tk apps.

  I suspect that there is some quality of Tk windows that
  does not allow them to have transparency or chroma
  keying applied?  Perhaps an attribute or a class thing?

  This is probably not properly a Tk bug, but rather, I
  need to know what I need to "do" to the Tk windows to
  make them accept changes in transparency and chroma keying.


tkt_uuid: 1529659fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 4
foundin: obsolete: 8.4.13
resolution: Accepted
title: Embedded toplevel makes the outer toplevel menu inaccessible
comment:
  Situation: The main window of an application has a
  menubar attached to it and it also contains a frame
  with the -container option set to true. When a toplevel
  window is embedded into this frame the menu of the main
  window gets replaced by the default menu (presumably
  the menu of the embedded toplevel). As far as I could
  tell there is no way to access the menubar of the main
  window of the application anymore, short of destroying
  the embedded toplevel.


tkt_uuid: 2149109fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: None
title: Wish unable to get focus if started from script
comment:
  Mac OS X Tiger only! It's fine on Leopard.

  If Wish is started repeatedly from a startup (shell) script, it cannot get application focus the second time (and subsequent times) it's started.
  This becomes a problem for an application that uses a shell script to restart a server regularly.

  Replications steps on Tiger, with a 8.5.4 Wish:
  - Place the attached StartupScript shell script as "Wish.app/Contents/MacOS/StartupScript", and give it execute privileges (chmod +x StartupScript).
  - Place the attached AppMain.tcl as "Wish.app/Contents/Resources/Scripts/AppMain.tcl".
  - Double-click on Wish. Application focus is as expected.
  - Press the "Restart" button, causing the application to exit and the StartupScript to start it again.

  Happens:
  It's impossible to get Wish into the foreground (to give it focus). So no buttons can be pressed anymore, except the X in the top-left corner.

  The contents of the startup script:
  ----------------------------
  #!/bin/sh

  here="${0%/*}"
  cmd='Wish'
  ulimit -S -n 1024
  i=0
  while [ $i -eq 0 -o -f "$here/../../.restart" ]
  do
  "$here/$cmd"
  i=`expr $i + 1`
  done
  ----------------------------


tkt_uuid: 1335485fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 6
foundin: obsolete: 8.4.9
resolution: Fixed
title: Error if parent widget has space in name
comment:
  (ActiveTcl 8.4.9 on a Fedora Core 4 box)

  % frame {.big gap}
  .big gap
  % tk_getSaveFile -parent {.big gap}

  ...gives the following error box when you hit Save:

  can't set "data(selectPath)": wrong # args: should be
  "::tk::dialog::file::SetPath w name1 name2 op"
  can't set "data(selectPath)": wrong # args: should be
  "::tk::dialog::file::SetPath w name1 name2 op"
      while executing
  "set data(selectPath) $path"
      (procedure "::tk::dialog::file::SetPathSilently"
  line 5)
      invoked from within
  "::tk::dialog::file::SetPathSilently $w $path"
      ("OK" arm line 7)
      invoked from within
  "switch -- $flag {
  OK {
      if {[string equal $file ""]} {
  # user has entered an existing (sub)directory
  set data(selectPath) $path
  $data(ent) ..."
      (procedure "::tk::dialog::file::VerifyFileName" line 9)
      invoked from within
  "::tk::dialog::file::VerifyFileName $w $text"
      (procedure "::tk::dialog::file::ActivateEnt" line 22)
      invoked from within
  "::tk::dialog::file::ActivateEnt $w"
      (procedure "::tk::dialog::file::OkCmd" line 18)
      invoked from within
  "::tk::dialog::file::OkCmd {.big gap.__tk_filedialog}"
      invoked from within
  "{.big gap.__tk_filedialog.f2.ok} invoke"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list $w invoke]"
      (procedure "tk::ButtonUp" line 22)
      invoked from within
  "tk::ButtonUp .big\ gap.__tk_filedialog.f2.ok"
      (command bound to event)


tkt_uuid: 219914ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Duplicate
title: Index of embedded window in text: dumps core
comment:
  OriginalBugID: 1003 Bug
  Version: 8.1b1
  SubmitDate: '1998-12-22'
  LastModified: '1999-02-02'
  Severity: CRIT
  Status: Closed
  Submitter: welch
  ChangedBy: pat
  OS: Other
  Machine: NA
  ClosedDate: '1999-02-02'


  Name:

  Don Porter



  ReproducibleScript:

  # FILE: demo.tcl

  package require Tk

  set t [text .t]

  $t insert end \n

  $t window create end -window [button $t.b]

  $t index end-2c

  pack $t









  ObservedBehavior:

  $ wish8.1 demo.tcl

  Segmentation fault (core dumped)









  DesiredBehavior:

  No crash.







  Patch:

  *** tkTextIndex.c.orig  Thu Dec 17 01:30:22 1998

  --- tkTextIndex.c       Thu Dec 17 01:31:00 1998

  ***************

  *** 1015,1021 ****

                  charCount--;

              }

          } else {

  !           if (charCount < segSize) {

                  dstPtr->byteIndex -= charCount;

                  return;

              }

  --- 1015,1021 ----

                  charCount--;

              }

          } else {

  !           if (charCount <= segSize) {

                  dstPtr->byteIndex -= charCount;

                  return;

              }









  PatchFiles:

  tkTextIndex.c









  Whenever an embedded window is at the first position of a line in
  a text widget (in demo.tcl, at index 2.0), and we try to compute that
  index using a modifier which starts with "-" (like "-2c"), a bug in the
  function TkTextIndexBackChars() causes an incorrect index to be computed.
  The incorrect index refers to one position past the end of the preceding
  line (in demo.tcl, 1.1) and when later code tries to reference that
  incorrect index, it attempts to follow a NULL pointer.  **CRASH**

  02/02/1999 16:57 - pat -duplicate of bug 991


tkt_uuid: 1432666fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 9 Immediate
foundin: obsolete: 8.5a4
resolution: Fixed
title: Crash with column or row >=1000
comment:
  The following script crashes:
  label .l
  grid .l -row 10 -column 10000

  tkGrid.c has a
  #define MAX_ELEMENT 10000

  and tkGrid.cc:2216:
  if (slot < 0 || slot >= MAX_ELEMENT) {
      return TCL_ERROR;
  }

  I have no idea how this turns into a coredump.


tkt_uuid: 528441ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 9 Immediate
foundin: obsolete: 8.4a4
resolution: Fixed
title: Tk builds incorrectly under VC++5.2 (focus, click bugs)
comment:
  The changes introduced by hobbs on Feb 26th to 
  tkText.c mean that the cursor doesn't blink at all 
  when a text widget is first created, under some 
  circumstances, and this then seems to break clicking 
  in the widget and making a selection.

  See, for example, the 'basic editable text' Tk demo, 
  and try out suggestion number '3'.  The widget doesn't 
  appear to take the focus (even thought it seems to 
  already have it), until the focus is manually moved to 
  a different window and back again.

  Vince.


tkt_uuid: 690178ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: OSX:blocking dialogs with menubuttons, called from menu item
comment:
  built from CVS on OSX 10.1.5... wish for OSX Aqua

  in tKMacOSXMenu.c, menus are posted with TkpPostMenu.  It sets the static inPostMenu, then unsets it at all exit points from the function...  further calls to the process bail out if inPostMenu is set.

  For a normal '-command' menu entry, this code is executed:
  result = TkMacOSXDispatchMenuEvent(menuID, LoWord(popUpResult));

  It waits for the command to return... and does this before the menu is cleaned up and inPostMenu is unset.

  This is breaking some code I'm using where I call up a blocking dialog that uses a menubutton.  Since the dialog calls tkwait, it doesn't return, right away... therefore the menu cleanup isn't completed, and menubuttons in the dialog are not able to post their menus.


tkt_uuid: 564521ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Objectify wm
comment:
  This patch is for objectifying wm.

  The first patch attached only objectifies the Windows
  file, tkWinWm.c, to get feedback before starting on
  the Unix/Mac files.

  The patch has one function for each subcommand and
  hopefully many of those can be identical between
  platforms, which will simplify centralization of
  common code in a later step.


tkt_uuid: 220690ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Linking VTK with Tcl/Tk support
comment:
  OriginalBugID: 4240 Bug
  Version: 8.3
  SubmitDate: '2000-02-25'
  LastModified: '2000-03-27'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  FixedDate: '2000-03-27'
  FixedInVersion: 8.3.1


  Name:
  Bernhard Hombitzer

  Comments:
  Linking VTK (www.kitware.com) with tcl/tk failed with the error
      _TkWinChildProc in library not found.
      Changing the line 
      extern LRESULT CALLBACKTkWinChildProc _ANSI_ARGS_((HWND hwnd, UINT
      message,  WPARAM wParam, LPARAM lParam));
      to
      EXTERN LRESULT CALLBACKTkWinChildProc _ANSI_ARGS_((HWND hwnd, UINT
      message,  WPARAM wParam, LPARAM lParam));
      in file tk8.3.0/win/tkWinInt.h resolved that problem.



  The fix as noted is not correct.  It should go into the platform
  specific stubs table.  For some reason it wasn't done with the
  rest in 8.1... 
  -- 02/25/2000 hobbs
  This required a bit more than the above, but the fix is in 8.3.1. 
  -- 03/27/2000 hobbs


tkt_uuid: 220708ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: tkUnixWm memory leak
comment:
  OriginalBugID: 4405 Bug
  Version: 8.3
  SubmitDate: '2000-03-20'
  LastModified: '2000-03-27'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Unix
  FixedDate: '2000-03-27'
  FixedInVersion: 8.3.1


  Name:

  Huver Hu



  ReproducibleScript:

  keep on creating new children top-levels with the same group leader.



  ObservedBehavior:

  a few of the places where allocated memory are not freed.



  DesiredBehavior:

  see diff attached.



  Patch:

  *** tkUnixWm.c.orig     Thu Feb 10 02:53:19 2000

  --- tkUnixWm.c  Wed Feb 23 21:40:38 2000

  ***************

  *** 1230,1235 ****

  --- 1230,1238 ----

              }

              wmPtr->hints.window_group = Tk_WindowId(wmPtr2->wrapperPtr);

              wmPtr->hints.flags |= WindowGroupHint;

  +           if (wmPtr->leaderName != NULL) {

  +               ckfree((char *) wmPtr->leaderName);

  +           }

              wmPtr->leaderName = ckalloc((unsigned) (strlen(argv[3])+1));

              strcpy(wmPtr->leaderName, argv[3]);

          }

  ***************

  *** 1354,1359 ****

  --- 1357,1365 ----

                      TCL_STATIC);

              return TCL_OK;

          } else {

  +           if (wmPtr->iconName != NULL) {

  +               ckfree((char *) wmPtr->iconName);

  +           }

              wmPtr->iconName = ckalloc((unsigned) (strlen(argv[3]) + 1));

              strcpy(wmPtr->iconName, argv[3]);

              if (!(wmPtr->flags & WM_NEVER_MAPPED)) {

  ***************

  *** 1847,1852 ****

  --- 1853,1861 ----

                      TCL_STATIC);

              return TCL_OK;

          } else {

  +           if (wmPtr->title != NULL) {

  +               ckfree((char *) wmPtr->title);

  +           }

              wmPtr->title = ckalloc((unsigned) (strlen(argv[3]) + 1));

              strcpy(wmPtr->title, argv[3]);

              if (!(wmPtr->flags & WM_NEVER_MAPPED)) {

  ***************

  *** 1903,1908 ****

  --- 1912,1920 ----

                  CreateWrapper(wmPtr2);

              }

              wmPtr->master = Tk_WindowId(wmPtr2->wrapperPtr);

  +           if (wmPtr->masterWindowName != NULL) {

  +               ckfree((char *) wmPtr->masterWindowName);

  +           }

              wmPtr->masterWindowName = ckalloc((unsigned) (strlen(argv[3])+1));

              strcpy(wmPtr->masterWindowName, argv[3]);

          }



  PatchFiles:

  unix/tkUnixWm.c





  Good find, and thanks for the patch.  I applied it to the CVS repository.  The fix will go out with Tcl/Tk 8.3.1.

  - eric

  -- 03/27/2000 ericm


tkt_uuid: 1163496fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Fixed
title: wm transient broken
comment:
   In tk 8.3.5, the "wm transient" command made a window
  so it always stayed on top of its parent. In addition,
  my window manager is configured to not put a title bar
  on a transient window.

  In Fedora 3, I am using tk 8.4.7 and my test window
  does not seem to be getting marked as transient. It
  doesn't stay on top of its parent and its title bar is
  no longer suppressed.

  I'm enclosing a test script. Just run the script and
  then move the "." window to the same part of the screen
  as the "HI" window. As I understand it, the "HI" window
  should always stay on top of the "." window.


tkt_uuid: 1553691fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 6
foundin: None
resolution: Remind
title: hard-coded control of selection display
comment:
  ALWAYS_SHOW_SELECTION is a hard-coded Tk behavior that
  determines whether entry and text widgets should always
  show their selection, regardless of focus (on for unix,
  off for OS X/Win).  Attached is a patch that moves this
  control to the Tcl level (still a private variable).


tkt_uuid: 220819ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 9 Immediate
foundin: final: 8.0.5
resolution: Fixed
title: image command segfault (overwrite .)
comment:
  OriginalBugID: 2156 Bug
  Version: 8.0.5
  SubmitDate: '1999-06-03'
  LastModified: '2000-03-02'
  Severity: CRIT
  Status: Assigned
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86


  Name: Tim Peters

  Comments:
  This got reported in the Python world as a crash using Tkinter (Python's
  interface to Tcl/Tk).  I can change Tkinter to refuse to accept
  non-string "name" arguments, but Tk still shouldn't die.

  ReproducibleScript:
  Run this one-liner under wish:
      image create photo .

  ObservedBehavior:
  Memory fault in tk80.dll under Windows.
  Segfault reported by someone else under an unspecified Linux version.

  DesiredBehavior:
  Don't care, so long as it doesn't bring down Tk!  An error msg would be
  appropriate (the cmd doesn't make sense).

  The problem here is that image create overwrites commands,
  but in this case the user has asked to overwrite '.', which
  is the main window.  Doing that brings down Tk, and in this
  case, brings it down rather rudely. 
  -- 09/20/1999 hobbs


tkt_uuid: 453624ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: None
title: setgrid+highlightthick 0 broken
comment:
  If you have a text widget that is -setgrid true and
  -highlightthickness 0, it will resize incorrectly
  ending up resizing slightly more or slightly less than
  the actual size of a line (vertically) and thus making
  -setgrid true useless when -highthick is 0.

  When -highthick is not 0 (left to the default, in
  specific) the gridding works fine.


tkt_uuid: 616988ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: dead keys ignored
comment:
  On foreign keyboards particularly, but also on US 
  keyboards, and dead-keys (used to produce 
  accented characters) are ignored.

  For example:

  Option-n followed by 'n' should produce a 
  spanish 'n~' combination.  All it does is produce 
  an 'n'.  (e.g. in the text widget).


tkt_uuid: 1449858fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 6
foundin: obsolete: 8.6b1.1
resolution: None
title: limit on inserted string size in an entry widget
comment:
  Try this in wish:

  set str [string repeat "0123456789" 4380]
  entry .e
  pack .e
  .e insert 0 $str


  Doing this I get after some amount of waiting an 
  entry widget packed in the . toplevel. Good.

  The problem is that the entry is apparently empty 
  (fully white).

  Selecting some area makes the selected characters 
  apparent, while unselecting them hides them again.

  Is there some (undocumented) limit in the length of 
  what can be inserted in an entry widget?

  Replacing 4380 by 4350 makes the string to be visible.

  I already found the tk_messageBox silently does not 
  open if the -message parameter exceeds some limit. 
  Maybe this limit is the same?

  Windows XP SP2, Tcl/Tk 8.5a4 or 8.4.12 as well.

  I have been told in the newsgroup that this limit 
  could have something to do with the font width. Some 
  limit in pixels number is probably silently hit.

  Moreover, still from the ng:
  On Mac OS 10.4.5 with tcl/tk 8.4.7 neither 4350 nor 
  4380 works, and indeed in either case the entry 
  appears to actually be *empty*, but it will not 
  accept any further input


tkt_uuid: 812415ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: wm stackorder causes wish to crash
comment:
  Test sequence:

  launch wish (Aqua-Tk)

  % toplevel .t
  % wm stackorder .

  wish crashes.

  Reproduced on a fresh TclTk8.4.4 install (from sourceforge / 
  Daniel's distribution).

  Works fine on Mac OS X - X11 and on windows 2k.

  Discussed on the tcl-mac mailing list:

  http://sourceforge.net/mailarchive/forum.php?forum=tcl-
  mac


tkt_uuid: 220461ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: added support for Postscript output of canvas images
comment:
  OriginalBugID: 1541 RFE
  Version: 8.0.5
  SubmitDate: '1999-03-18'
  LastModified: '1999-12-13'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '1999-12-13'
  FixedInVersion: 8.3b1


  Name:

  Marco R. Gazzetta


  CVS:

  RCS: @(#) $Id: tkCanvImg.c,v 1.2 1998/09/14 18:23:05 stanton Exp


  DesiredBehavior:

      canvas image items didn't have a postscript option. I added this.


  Patch:

  Index: tkCanvImg.c

  ===================================================================

  RCS file: /cvsroot/tk/generic/tkCanvImg.c,v

  retrieving revision 1.2

  diff -c -r1.2 tkCanvImg.c

  *** tkCanvImg.c1998/09/14 18:23:051.2

  --- tkCanvImg.c1999/03/19 00:17:12

  ***************

  *** 66,71 ****

  --- 66,74 ----

        char **argv));

    static intImageToArea _ANSI_ARGS_((Tk_Canvas canvas,

        Tk_Item *itemPtr, double *rectPtr));

  + static intImageToPostscript _ANSI_ARGS_((Tcl_Interp *interp,

  +     Tk_Canvas canvas, Tk_Item *itemPtr,

  +     int prepass));

    static doubleImageToPoint _ANSI_ARGS_((Tk_Canvas canvas,

        Tk_Item *itemPtr, double *coordPtr));

    static voidComputeImageBbox _ANSI_ARGS_((Tk_Canvas canvas,

  ***************

  *** 104,110 ****

        0,/* alwaysRedraw */

        ImageToPoint,/* pointProc */

        ImageToArea,/* areaProc */

  !     (Tk_ItemPostscriptProc *) NULL,/* postscriptProc */

        ScaleImage,/* scaleProc */

        TranslateImage,/* translateProc */

        (Tk_ItemIndexProc *) NULL,/* indexProc */

  --- 107,113 ----

        0,/* alwaysRedraw */

        ImageToPoint,/* pointProc */

        ImageToArea,/* areaProc */

  !     ImageToPostscript,/* postscriptProc */

        ScaleImage,/* scaleProc */

        TranslateImage,/* translateProc */

        (Tk_ItemIndexProc *) NULL,/* indexProc */

  ***************

  *** 558,563 ****

  --- 561,688 ----

    return 1;

        }

        return 0;

  + }

  + 

  + /*

  +  *--------------------------------------------------------------

  +  *

  +  * ImageToPostscript --

  +  *

  +  *      This procedure is invoked to create Postscript (TM) output

  +  *      for a photo image

  +  *

  +  * Results:

  +  *      The return value is a standard Tcl result.  If an error

  +  *      occurs in generating Postscript then an error message is

  +  *      left in interp->result, replacing whatever used

  +  *      to be there.  If no error occurs, then Postscript for the

  +  *      item is appended to the result.

  +  *

  +  * Side effects:

  +  *      None

  +  *

  +  *--------------------------------------------------------------

  +  */

  + 

  + static int

  + ImageToPostscript(interp, canvas, itemPtr, prepass)

  +     Tcl_Interp *interp;

  +     Tk_Canvas canvas;

  +     Tk_Item *itemPtr;

  +     int prepass;

  + {

  +     double x, y, w, h;

  +     int ix, iy;

  +     char buffer[2000];

  +     char color;

  +     unsigned char *pixel;

  +     char *photoName;

  +     Tk_PhotoHandle photo;

  +     Tk_PhotoImageBlock block;

  +     char hex[] = "0123456789ABCDEF";

  +     ImageItem *imgPtr = (ImageItem *) itemPtr;

  + 

  +     if (prepass == 1) return TCL_OK;

  + 

  +     /* Find photo and return with an error if we couldn't find it */

  +     photoName = imgPtr->imageString;

  +     if (!photoName) {

  +         Tcl_AppendResult(interp, "corrupt photo name", (char *) NULL);

  +         return TCL_ERROR;

  +     }

  +     if (photoName[0] == 0) {

  +         Tcl_AppendResult(interp, "empty photo name", (char *) NULL);

  +         return TCL_ERROR;

  +     }

  +     photo = Tk_FindPhoto(interp, photoName);

  +     if (!photo) {

  +         Tcl_AppendResult(interp, "\"", photoName, 

  +     "\" is not a photo name", (char *) NULL);

  +         return TCL_ERROR;

  +     }

  +     Tk_PhotoGetImage(photo, &block);

  + 

  +     /* Geometry info */

  +     w = imgPtr->header.x2 - imgPtr->header.x1;

  +     if (w < 0) w = -w;

  +     h = imgPtr->header.y2 - imgPtr->header.y1;

  +     if (h < 0) h = -h;

  + 

  +     /* Let's ignore images of 0 width or height */

  +     if (h==0 || w==0) return TCL_OK;

  + 

  +     /* Find the offset of the image */

  +     switch (imgPtr->anchor) {

  +     case TK_ANCHOR_NW:     x = imgPtr->x;           y = imgPtr->y + h;

  +         break;

  +     case TK_ANCHOR_W:      x = imgPtr->x;           y = imgPtr->y + h / 2.0;

  +         break;

  +     case TK_ANCHOR_SW:     x = imgPtr->x;           y = imgPtr->y;

  +         break;

  +     case TK_ANCHOR_N:      x = imgPtr->x - w / 2.0; y = imgPtr->y + h;

  +         break;

  +     case TK_ANCHOR_CENTER: x = imgPtr->x - w / 2.0; y = imgPtr->y + h / 2.0;

  +         break;

  +     case TK_ANCHOR_S:      x = imgPtr->x - w / 2.0; y = imgPtr->y;

  +         break;

  +     case TK_ANCHOR_NE:     x = imgPtr->x - w;       y = imgPtr->y + h;

  +         break;

  +     case TK_ANCHOR_E:      x = imgPtr->x - w;       y = imgPtr->y + h / 2.0;

  +         break;

  +     case TK_ANCHOR_SE:     x = imgPtr->x - w;       y = imgPtr->y;

  +     }

  +     y = Tk_CanvasPsY(canvas, y);

  + 

  +     /* let's create merry postscript output */

  +     sprintf(buffer,

  +         "/buffer %g string def \n%g %g translate\n%g %g scale\n%g %g 8\n",

  +         w*3, x, y, w, h, w, h);

  +     Tcl_AppendResult(interp, buffer, (char *)NULL);

  +     sprintf(buffer, "[%d 0 0 -%d 0 %d]\n", (int)w, (int)h, (int)h);

  +     Tcl_AppendResult(interp, buffer, "{currentfile\n",

  +         "  buffer readhexstring pop}\nfalse 3\ncolorimage\n",

  +         (char *)NULL);

  + 

  +     /* next, the actual data, one line at a time */

  +     for (iy = 0; iy < h; iy++) {

  +         for (ix = 0; ix < w; ix++) {

  +             pixel = block.pixelPtr + iy * block.pitch + ix * block.pixelSize;

  +             color = pixel[block.offset[0]];

  +             buffer[6 * ix    ] = hex[color >> 4 & 0xf];

  +             buffer[6 * ix + 1] = hex[color & 0xf];

  +             color = pixel[block.offset[1]];

  +             buffer[6 * ix + 2] = hex[color >> 4 & 0xf];

  +             buffer[6 * ix + 3] = hex[color & 0xf];

  +             color = pixel[block.offset[2]];

  +             buffer[6 * ix + 4] = hex[color >> 4 & 0xf];

  +             buffer[6 * ix + 5] = hex[color & 0xf];

  +         }

  +         buffer[6 * ix] = 0;

  +         Tcl_AppendResult(interp, buffer, "\n", (char *)NULL);

  +     }

  + 

  +     /* end */

  +     return TCL_OK;

    }

    

    /*


  PatchFiles:

      tkCanvImg.c




      tested on Windows NT 4.0 and Sun/Solaris
  --
  The dash patch support for this was added in 8.3b1. 
  -- 12/13/1999 hobbs


tkt_uuid: 220015ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Duplicate
title: wish82 + operating system crash on NT
comment:
  OriginalBugID: 2644 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-08-31'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2645
  OS: Windows NT
  OSVersion: 4.0 SP5
  Machine: X86
  ClosedDate: '1999-08-31'


  Name:
  Markus Maier

  ReproducibleScript:
  this more a Windows-NT bug then a wish82 bug:
      The following TCL Application will crash wish81/82 on Windows 9x and
      will cause a bluescreen (!) on Windows-NT 4.0 (Service Pack 5).
      
      Instructions:
      (Warning: Save all your files before trying it on NT!)
      
      - save the attached script in a file "crash.tcl"
      - open a wish console and type in "source crash.tcl"
      - open the "crash ..." cascade menu on the upper left border of the
      screen.
      - An Error Message Dialog Window will occur,
        on NT you'll not be able to press the OK button.
      - Click on the background or on any other (non-wish) Window.
      - Click on the Error Message Window again, press the OK button, till the
        Error Message Dialog Window disappears.
      - Save all your files
      - Change to the wish console window and type in "exit"
      
      here is the script:
      
      set m .crash
      catch { destroy $m }
      set m [menu $m -tearoff 0]
      set submenu $m.sub
      $m add cascade -label "Crash..." -menu $submenu
      menu $submenu -tearoff 0
      
      bind $m <<MenuSelect>> { 
          yes-it-is-just-an-invalid-command
      }
      
      tk_popup $m 0 0

  ObservedBehavior:
  on Win95 wish82 crashes (sometimes)
      on WinNT the operating system crashes (bluescreen), I was able to
      reproduce that on 2 different NT machines.

  DesiredBehavior:
  Error Message (without system crash :-))


tkt_uuid: 1306222fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.11
resolution: Out of Date
title: tk_getOpen(Save)
comment:
  [23:49:28] [ya1] look at filetkfbox.tcl
  [23:50:17] [ya1] proc ::tk::dialog::file::Create {w class} {
  [23:50:23] [ya1] creating of dialog...
  [23:50:43] [ya1] set set data(typeMenuLab) 
  [::tk::AmpWidget label $f2.lab2
  [23:51:06] [ya1] when we close this dialog...it's not 
  destroiy..it's just hide..
  [23:51:30] [ya1] and when we call it second time: we 
  trying to restore array data[]
  [23:51:34] [ya1] how?
  [23:51:55] [ya1] in function proc ::tk::dialog::file:: {type 
  args}
  [23:52:09] [ya1] set data(typeMenuLab) $w.f2.lab
  [23:52:14] [ya1] error!
  [23:52:15] [@azbridge] <suchenwi> Hm.
  [23:52:21] [ya1] wrong restoring!


tkt_uuid: 219930ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: ByteCode Stack Fatal Error
comment:
  OriginalBugID: 1366 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-09-13'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1454
  OS: Windows NT
  OSVersion: 4.0 SP 3
  Machine: X86
  ClosedDate: '1999-09-13'


  Name:
  Steven Sokol

  Extensions:
  odbctcl80.dll

  CustomShell:
  None

  ReproducibleScript:
  set IVRDB {}
  set CurValue {}
  set Channel_Number {SIM}
  set version [join [split $tcl_version .] {}]
  load odbctcl$version.dll

  wm title . "Stratagy Simulator"
  frame .top -borderwidth 0
  pack .top -side top -fill x

  #label .top.title -text "Stratagy Simulator 1.0" -justify center -font system
  #pack .top.title -side top

  set but [button .top.select -text "Select" -command Select -width 8]
  button .top.exec -text "Run" -command Run -width 8
  pack .top.select .top.exec  -side left -padx 2 -pady 0

  label .top.1 -text "SES Script:" -padx 1
  entry .top.cmd -width 20 -relief sunken -textvariable tvFileName
  pack .top.1 -side left
  pack .top.cmd -side left -fill x -expand true

  bind .top.cmd <Return> Run
  bind .top.cmd <Control-c> Stop
  focus .top.cmd

  proc Scrolled_Text {f args} {
  frame $f
  eval {text $f.text  -xscrollcommand [list $f.xscroll set]  -yscrollcommand [list $f.yscroll set]} $args
  scrollbar $f.xscroll -orient horizontal  -command [list $f.text xview]
  scrollbar $f.yscroll -orient vertical  -command [list $f.text yview]
  grid $f.text $f.yscroll -sticky news
  grid $f.xscroll -sticky news
  grid rowconfigure $f 0 -weight 1
  grid columnconfigure $f 0 -weight 1
  return $f.text
  }

  set browse(text) [Scrolled_Text .body -width 80 -height 10 -setgrid true]
  pack .body -fill both -expand true

  set t [Scrolled_Text .eval -width 80 -height 10]
  pack .eval -fill both -expand true

  $t tag configure prompt -underline true
  $t tag configure result -foreground purple
  $t tag configure error -foreground red
  $t tag configure output -foreground blue

  set eval(prompt) "tcl> "
  $t insert insert $eval(prompt) prompt
  $t mark set limit insert
  $t mark gravity limit left
  focus $t
  set eval(text) $t

  bind $t <Return> {EvalTypein ; break}
  bind $t <BackSpace> {
  if {[%W tag nextrange set 1.0 end] != ""} {
  %W delete sel.first sel.last
  } elseif {[%W compare insert > limit]} {
  %W delete insert-1c
  %W see insert
  }
  break
  }
  bind $t <Key> {
  if [%W compare insert < limit] {
  %W mark set insert end
  }
  }

  proc EvalTypein {} {
  global eval
  set command [$eval(text) get limit end]
  $eval(text) insert insert \n
  if [info complete $command] {
  $eval(text) mark set limit insert
  Eval $command
  }
  }

  proc EvalEcho {command} {
  global eval
  $eval(text) mark set insert end
  $eval(text) insert insert $command\n
  Eval $command
  }

  proc Eval {command} {
  global eval
  $eval(text) mark set insert end
  if [catch {$eval(slave) eval $command} result] {
  $eval(text) insert insert $result error
  } else {
  $eval(text) insert insert $result result
  }
  if {[$eval(text) compare insert != "insert linestart"]} {
  $eval(text) insert insert \n
  }
  $eval(text) insert insert $eval(prompt) prompt
  $eval(text) see insert
  $eval(text) mark set limit insert
  return
  }

  proc SlaveInit {slave} {
  interp create $slave
  interp eval $slave {set Channel_Number {SIM}}
  interp alias $slave reset {} ResetAlias $slave
  interp alias $slave puts {} PutsAlias $slave
  interp alias $slave tTrace {} PutsAlias $slave
  interp alias $slave cg_connectdb {} cg_connectdbA
  interp alias $slave cg_executesql {} cg_executesqlA
  interp alias $slave cg_return {} cg_returnA
  interp alias $slave cg_playFile {} cg_playFileA
  interp alias $slave cg_collectDtmf {} cg_collectDtmfA
  interp alias $slave pValue {} pValueA
  return $slave
  }

  proc ResetAlias {slave} {
  interp delete $slave
  SlaveInit $slave
  }

  proc PutsAlias {slave args} {
  if {[llength $args] > 3} {
  error "invalid arguments"
  }
  set newline "\n"
  if {[string match "-nonewline" [lindex $args 0]]} {
  set newline ""
  set args [lreplace $args 0 0]
  }
  if {[llength $args] == 1} {
  set chan stdout
  set string [lindex $args 0]$newline
  } else {
  set chan [lindex $args 0]
  set string [lindex $args 1]$newline
  }
  if [regexp (stdout|stderr) $chan] {
  global eval
  $eval(text) mark gravity limit right
  $eval(text) insert limit $string output
  $eval(text) see limit
  $eval(text) mark gravity limit left
  } else {
  puts -nonewline $chan $string
  }
  }

  #set eval(slave) [SlaveInit shell]

  proc Run {} {
  global tvFileName eval
  set eval(slave) [SlaveInit shell]
  EvalEcho [list source $tvFileName]
  }

  proc Log {} {
  global input log
  if [eof $input] {
  Stop
  } else {
  gets $input line
  $log insert end $line\n
  $log see end
  }
  }

  proc Stop {} {
  global input but
  catch {close $input}
  $but config -text "Run it" -command Run
  }

  proc Select {} {
  global tvFileName browse
  set types {{{TCL Scripts}       {.tcl}        }}
  set sFileName [tk_getOpenFile -filetypes $types -initialdir "C:/Vortec/Bin"]
  if {[string length $sFileName] > 0} {
  set tvFileName $sFileName
  set t $browse(text)
  $t config -state normal
  $t delete 1.0 end
  if [catch {open $sFileName} in] {
  $t insert end $in
  } else {
  $t insert end [read $in]
  close $in
  }
  $t config -state disabled
  } else {
  set tvFileName {}
  }
  }

  proc tTrace {strValue} {
  puts $strValue
  }

  #####################################################################
  # DOS Editing/Testing Functions
  #####################################################################
  proc tTrace {param} {
  puts $param
  }
  proc cg_connectdbA {DSN} {
  global IVRDB
  puts "CONNECTING TO DSN:$DSN"
  odbc_connect IVRDB $DSN
  return "Connected"
  }

  proc cg_playFileA {file opt wap enc rep} {

  global CurValue

  toplevel .playFile -height 200 -width 200
  wm title .playFile "Play File"
  frame .playFile.top
  pack .playFile.top -side top
  label .playFile.top.fileLabel -text "Audio File:"
  entry .playFile.top.fileName -textvariable fName -width 80
  pack propagate .playFile false
  pack .playFile.top.fileLabel .playFile.top.fileName -side left -padx 2 -pady 2
  .playFile.top.fileName insert 0 $file
  .playFile.top.fileName configure -state disabled

  frame .playFile.padOne -borderwidth 2
  pack .playFile.padOne 
  button .playFile.padOne.bOne -width 4 -height 2 -text "1" -command {pValue "1"}
  button .playFile.padOne.bTwo -width 4 -height 2 -text "2" -command {pValue "2"}
  button .playFile.padOne.bThree -width 4 -height 2 -text "3" -command {pValue "3"}
  pack .playFile.padOne.bOne .playFile.padOne.bTwo .playFile.padOne.bThree -side left

  frame .playFile.padTwo -borderwidth 2
  pack .playFile.padTwo
  button .playFile.padTwo.bFour -width 4 -height 2 -text "4" -command {pValue "4"}
  button .playFile.padTwo.bFive -width 4 -height 2 -text "5" -command {pValue "5"}
  button .playFile.padTwo.bSix -width 4 -height 2 -text "6" -command {pValue "6"}
  pack .playFile.padTwo.bFour .playFile.padTwo.bFive .playFile.padTwo.bSix -side left

  frame .playFile.padThree -borderwidth 2
  pack .playFile.padThree
  button .playFile.padThree.bSeven -width 4 -height 2 -text "7" -command {pValue "7"}
  button .playFile.padThree.bEight -width 4 -height 2 -text "8" -command {pValue "8"}
  button .playFile.padThree.bNine -width 4 -height 2 -text "9" -command {pValue "9"}
  pack .playFile.padThree.bSeven .playFile.padThree.bEight .playFile.padThree.bNine -side left

  focus .playFile

  #if {$wap == 0} {
  #puts "NO RESPONSE NEEDED"
  #return "Done"
  #} else {
  #puts "Enter A Response Digit:"
  #gets stdin Digit
  #if {[string length $Digit] > 0} {
  #return "Digit$Digit"
  #} else {
  #return "Done"
  #}
  #}

  while {[string length $CurValue] < 1} {
  vwait CurValue
  destroy .playFile
  return "Digit$CurValue"
  }

  }

  proc cg_executesqlA {statement} {
    global sqlres
    set ret_list {}
    set full_list {}
    puts "SQL STATEMENT:$statement"
    if [catch "IVRDB execdirect \$statement" msg] {
  puts "error: $msg\n"
  return "Error"
    } else {
  puts "cg_executesql Result = $msg\n"
  if {[lindex $msg 0] > 0} {
  # Convert sqlres Array Into List
  lappend full_list $sqlres(0,1)
    for {set row 1} {$row <= [lindex $msg 0]} {incr row} {
      for {set col 1} {$col <= [lindex $msg 1]} {incr col} {
        lappend ret_list $sqlres($row,$col)
      }
  lappend full_list $ret_list
  unset ret_list
    }
  return $full_list
  } else {
  return "1"
  }
    }

  }

  proc cg_collectDtmfA {max term silence inter cb ca} {
  puts "DIGIT COLLECTION - ENTER UP TO $max DIGITS:"
  gets stdin Digits
  return "Collected $Digits"
  }

  proc cg_returnA {args} {
  puts "END OF APPLICATION"
  }

  proc Beep {} {
  puts "BEEP!"
  }

  proc cg_recordFile {path option wait encode} {
  puts "RECORDING FILE $path PRESS ENTER TO CONTINUE"
  gets stdin junk
  return {}
  }
  proc play_money {amount args} {
  puts "PLAY MONEY VALUE: \$$amount"
  return {}
  }
  proc play_number {number} {
  puts "PLAY NUMBER VALUE: $number"
  return {}
  }

  proc play_alphanum {cvals} {
  puts "PLAY ALPHANUM: " $cvals
  return {}
  }

  proc pValue {Num} {
  global CurValue
  set CurValue "$CurValue$Num"
  }
  #####################################################################

  ObservedBehavior:
  The above script is a simulator for an IVR system we have using TCL as the script language.  I feed it a script that calls the oddly named cg_playFile command which can see calls back to the main interp though an alias.

  When I select a button in the toplevel which pops up when I call cg_playFileA, the system sometimes (every other time) throws a fit.

  Sometimes this gets an "Unrecognized op code 76" message.  Somtimes it gets "WISH FATAL ERROR: TclExecuteByteCode Execution Failure: end stack top != start stack top.  Occasionally I even get a GPF or IPF from NT.

  DesiredBehavior:
  The system should simply destroy the window and return the digit value entered with the "Digit" string prepended.


tkt_uuid: 2496114fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 9 Immediate
foundin: obsolete: 8.4.14
resolution: Fixed
title: Crash when focus change & window destroyed
comment:
  I've run into a situation where Tk will crash when the right (wrong?) sequence of events happen.  It's not easy to reproduce as I only see it with our application in an automated regression environment, and then only about 40% of the time.  The gist of the problem is:

   1) A subwindow of a toplevel gains focus
   2) Later a different sub window gains focus, probably because the previous window was unmapped.
   3) The first sub window is destroyed.
   4) Later focus is set back to the toplevel which tries to find the subwindow which last had focus.  This results in dereferencing the long gone window.

  There appears to be 2 locations where the focus window is stored:

     winPtr->mainPtr->tlFocusPtr->focusWinPtr

  and

     displayFocusPtr->focusWinPtr

  It looks to me like the code in TkFocusDeadWindow(), which is supposed to clean up these pointers when a window is destroyed, assumes the 2 different focusWinPtr's are always in sync.  In this particular case, they are not, so the displayFocusPtr->focusWinPtr is not cleared. Later, this stale reference is used.

  I'm currently using 8.4.14 that has been patched with TIP#125.  I don't have definitive proof that this bug is related to "undocking" one way or the other.  I think, however, that that is immaterial as the logic in TkFocusDeadWindow still allows the possibility of a stale pointer to exist long after the memory has been free'd.

  The following patch (note: relative to 8.4.14) will fix the problem.  This code is unchanged through the 8.6, top-of-trunk, so it should apply painlessly through all versions.

  $ cvs diff -p tkFocus.c
  Index: tkFocus.c
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/generic/tkFocus.c,v
  retrieving revision 1.10.2.1
  diff -p -r1.10.2.1 tkFocus.c
  *** tkFocus.c   11 Aug 2005 12:17:09 -0000      1.10.2.1
  --- tkFocus.c   9 Jan 2009 16:26:40 -0000
  *************** TkFocusDeadWindow(winPtr)
  *** 883,888 ****
  --- 883,896 ----
                  dispPtr->focusPtr = tlFocusPtr->topLevelPtr;
              }
              break;
  +       } else {
  +           if (displayFocusPtr->focusWinPtr == winPtr) {
  +               if (dispPtr->focusDebug) {
  +                   printf("focus cleared after %s died\n",
  +                           winPtr->pathName);
  +               }
  +               displayFocusPtr->focusWinPtr = NULL;
  +           }
          }
        }
    


tkt_uuid: 1824638fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 9 Immediate
foundin: obsolete: 8.5b2
resolution: Fixed
title: Aqua: wraplength 1 does not work correctly with ATSUI
comment:
  Is there difference of wraplength between 8.4.16 and 8.5 ?
  My environment 10.4.10, Powermac G4

  label .l -text abcd -wraplength 1
  pack .l

  Aqua TclTk 8.4.10
  each one letter, a new line feed
  a
  b
  c
  d

  Aqua TclTk 8.5b2
  the string "abcd" is displayed as one line.


tkt_uuid: 1236306fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: TraverseToMenu error with alt binding to toplevel destroy
comment:
  Consider the following three-line script:

  toplevel .t
  bind .t <Alt-a> {destroy .t}
  bind .t <Alt-b> {after 0 destroy .t}
  bind .t <Alt-c> {destroy .t;break}

  Pressing Alt-a displays an error message:

  bad window path name ".t"
  bad window path name ".t"
      while executing
  "winfo class $w"
      (procedure "tk::TraverseToMenu" line 6)
      invoked from within
  "tk::TraverseToMenu .t a"
      (command bound to event)

  while Alt-b or Alt-c does not.

  This occurs on Linux, not on Windows, for Alt bindings 
  only (not for Control, Shift... bindings).


  Analysis of the problem:

  % toplevel .t
  .t
  % bindtags .t
  .t Toplevel all
  % bind all
  <<PrevWindow>> <Key-Tab> <Key-F10> <Alt-Key>
  % bind all <Alt-Key>
   tk::TraverseToMenu %W %A

  The bindtags are processed in turn. <Alt-a> binding 
  for .t is executed first. There is no matching binding for 
  Toplevel, but there is a binding for the Alt key for the all 
  bindtag. So this one is executed after the toplevel is 
  destroyed.

  The bug is therefore that tk::TraverseToMenu doesn't 
  check that the toplevel still exists.


tkt_uuid: 513216ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: Tearoff menu failure
comment:
  Tearoff menus do not work. Perhaps this feature 
  should simply be disabled in MacOS X?

  The tearoff menu does produce a new window, but 
  this window has the top clipped off, it is not 
  movable, and it can sometimes cause problems 
  with focusing to other windows.


tkt_uuid: 682714ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: None
resolution: Fixed
title: colors(n) man page all wrong
comment:
  The entire third column (blue value) in the man page is
  simply a duplicate of the second column.  The values do
  not match those in xlib/xcolors.c.  Note that there was
  an earlier report (#432104), but that only noted the
  pure-blue colors (which were listed as "0 0 0").  Those
  have now been fixed, but every color which is NOT pure
  blue still has incorrect values in the blue column.


tkt_uuid: 2945088fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Tk Cocoa menu check marks not shown
comment:
  With Tk Cocoa 8.6 Jan 8, 2010 source code check marks are not drawn for checkbutton menu entries when the menu pane is posted with the post command.  The ckeck marks are drawn correctly in Tk Carbon 8.5.8 and also in Linux and Windows Tk 8.5.8.

  Here's a Wish script that demonstrates the problem.

  menu .m
  variable m1 1
  variable m2 1
  .m add checkbutton -label blue -variable m1
  .m add checkbutton -label green -variable m2
  bind . <Button-1> {.m post 100 100}

  Pressing mouse button 1 posts the menu but only the second entry has a check mark next to it.  Both should have check marks.  Posting the menu again shows no check marks for either menu entry.  If more menu entries are created, each posting removes one check mark.  Weird.


tkt_uuid: 1505182fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Duplicate
title: Accented characters not appearing where they ought to
comment:
  Hi,
  please read this forum thread for more detailed 
  information :
  http://amsn.sourceforge.net/forums/viewtopic.php?t=1164

  I will summarize it here : 
  It seems that on Linux, when an application is 
  'frozen', by taking 100% cpu on some script, the 
  keyboard events on a text widget make all characters 
  that need the use of a deadkey appear as the last chars 
  in the widget and they will all be the same as the last 
  accented char entered.
  Quoting from the forum : a message like "¿Cómo estás?" 
  would appear as "¿Cmo ests?áá".
  To test it, simply type in a wish shell :
  destroy .t 
  pack [text .t] 
  after 5000 { 
     for { set i 0 } { $i < 100000 } { incr i } { puts 
  test } 
  }

  The loop limit depends on how long you want it to hang, 
  use the 5sec grace time to set focus on the text widget 
  and while it's hanging, type a sequence of normal chars 
  interleaved with accented chars (using a deadkey). See 
  the result.
  I was unable to reproduce it on Windows, but it was 
  reported many times already and it is known to happen 
  on Linux (FC5) with Tcl/Tk 8.4.12. I have no means to 
  test it further. 
  I hope it helps.
  Thanks.


tkt_uuid: 1532360fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 14. [message]
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Invalid
title: tk_messagebox ignores msgcat
comment:
  tk_messagebox ignores msgcat's presence. I think the
  Yes and No buttons should use msgcat's strings if
  available. For example, I've defined:
     msgcat::mcset nl Yes Ja
  It would be nice if the Yes button would use Ja as
  text. Same goes for all other texts in all other
  tk_messageboxes.


tkt_uuid: 220835ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 40. Bitmap Images
priority: 5 Medium
foundin: None
resolution: Out of Date
title: image create bitmap not using Tk_DefineBitmap
comment:
  OriginalBugID: 1773 RFE
  Version: 8.1b3
  SubmitDate: '1999-04-09'
  LastModified: '1999-04-16'
  Severity: SER
  Status: UnAssn
  Submitter: pat
  ChangedBy: stanton
  OS: Solaris
  Machine: Other


  Name:
  Peter Weigand

  Comments:
  Feature for bitmaps:
      new commands "bitmap put x y foregroundorbackgroundorinvisible" and
      "bitmap get x y".
      this allows modification of bitmaps which sounds for me as a nice
      feature.

  ReproducibleScript:
  if you create an image of type bitmap with the "image create bitmap"
      command
      then this image is created in the hash list for images but not in the
      hash list
      for bitmaps. Therefore you are not able to use such a bitmap in certain
      commands, e.g. .canvas create bitmap.

  ObservedBehavior:
  try "image type gray50" it will say image does not exist.
      If you create a bitmap with "image create bitmap: then "image type
      nameofbitmap"
      will give you the information. If the bitmap and photo get mixed it also
      needs more checking of which type the image is in certain functions. If
      the mixing is allowed then why do we have a bitmap and photo type in the
      commands, it could be determined on the fly.
      If you created an image with "image create bitmap" then a ".canvas
      create image" will create the bitmap but as type image instead as
      desired of type bitmap.
      Therefore postscript generation of the bitmap does not work because it
      is of type image.

  DesiredBehavior:
  Bitmaps however they are created should be in the bitmap hash list so
      you can access this bitmap with any bitmap command, e.g. canvas create
      bitmap.
      Right now there is an inconsistence.


tkt_uuid: 1468291fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 8
foundin: obsolete: 8.4.13
resolution: Fixed
title: Threads: "called Tcl_Close on channel with refCount > 0"
comment:
  When using vfs::mk4 and [file copy] and multi threading
  on Windows, wish crashes with the error message:

  "called Tcl_Close on channel with refCount > 0" 

  This issue applies only to the wish application or
  tclkit on windows. Tclsh and tclkitsh on windows are
  not affected. When using [file copy] on normal non-vfs
  directories, everything is fine as well. Only with
  *non-existing* vfs directories mounted via
  vfs::mk4::Mount (or maybe other vfs::*::Mount's) the
  crash appeared to me.

  I've written a short script which makes it easy to
  reproduce the bug:

  # channel refcount bug
  package require Thread
  catch {console show}

  set T [thread::create -preserved]

  thread::send $T [list set D [file dirname [info script]]]

  set script {
      package require vfs::mk4
      
      set logOpen 0
      proc ::Log {msg} {
          if {$::logOpen} {
              set mode a
          } else {
              set mode w
              set ::logOpen 1
          }
          
          set L [open [file join $::D log.txt] $mode]
          puts $L $msg
          close $L
      }
      
      Log $D
      set src [file join $D test.txt]
      set tdir [file join $D tdir.kit]
      set dest [file join $tdir test.txt]
      Log $dest
      
      Log 1
      set vfsh [vfs::mk4::Mount $tdir $tdir]
      Log 2
      file copy $src $dest
      Log 3
      vfs::mk4::Unmount $vfsh $tdir
      Log 4
  }

  thread::send -async $T $script

  # end channel bug script

  When the directory exists, the crash does not happen,
  but the script runs only until "Log 2".
  It is not very clear to me whether this is a bug in Tk
  (because it only appears with wish/windows) or vfs or
  metakit.


tkt_uuid: 220158ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: Win95/NT: Focusing Tcl/Tk doesn't make it the active window
comment:
  OriginalBugID: 1712 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-05'
  LastModified: '1999-08-07'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0 with SP4
  Machine: X86
  ClosedDate: '1999-08-07'


  Name:
  Dean Tan

  Extensions:
  Tk

  ReproducibleScript:
  I'm using the Tik (Tcl version of AOL IM client) on WindowsNT, and if
      Tik is not the active application, and if you receive an instant message
      (IM), the IM window doesn't raise above and make Tik the activate
      application.
      
      It's using the "raise" command.
      
      The Tik developer think that this is a bug in the Windows version of
      Tcl/Tk.

  ObservedBehavior:
  window doesn't raise to be activate application

  DesiredBehavior:
  window should raised to become the application application



  On Windows you should do:
     focus -force $toplevel
     raise $toplevel
   
  -- 08/07/1999 hobbs


tkt_uuid: 220378ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: button state gets confused when state changes
comment:
  OriginalBugID: 664 Bug
  Version: 8.0p2
  SubmitDate: '1998-06-11'
  LastModified: '1999-08-06'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  From: Sandeep Pathak <sandeep@gti.com>

  Hi,
  I have the following environment: NT4.0, Tcl/Tk8.0p1.
  The button does not seem to behave properly when its state is being
  manipulated. Try this:

  button -b -text <some text>
  pack .b
  bind .b <ButtonRelease-1> {.b configure -state disabled}
  [Now if you click on .b, the button does become insensitive BUT it stays
  sunken].

  .b configure -state normal
  [The button becomes sensitive but it still stays sunken].


  In button.tcl, the unix and windows implementation of tkButtonUp differ
  as follows:

  windows:
  proc tkButtonUp w {
      global tkPriv
      if {$w == $tkPriv(buttonWindow)} {
       set tkPriv(buttonWindow) ""
       if {($w == $tkPriv(window))
            && ([$w cget -state] != "disabled")} {
           $w config -relief $tkPriv(relief) -state normal
           uplevel #0 [list $w invoke]
           }
       }
  }


  unix:
  proc tkButtonUp w {
      global tkPriv
      if {$w == $tkPriv(buttonWindow)} {
       set tkPriv(buttonWindow) ""
       $w config -relief $tkPriv(relief)
       if {($w == $tkPriv(window))
            && ([$w cget -state] != "disabled")} {
           uplevel #0 [list $w invoke]
           }
      }
  }

  The windows version is not restoring the 'relief' of the button.

  -sandeep
  sandeep@gti.com

  This is fixed for the 8.2b3 release. 
  -- 08/06/1999 hobbs


tkt_uuid: 1455241fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 8
foundin: obsolete: 8.5a4
resolution: Fixed
title: TkAqua wm attributes -titlepath throws error
comment:
  There are two problems with the '-titlepath' configuration:

  1)

  toplevel .tt ; wm attributes .tt -titlepath /foo/bar.txt

  throws an error, but:

  toplevel .tt
  (wait until the toplevel appears)
  wm attributes .tt -titlepath /foo/bar.txt

  works just fine.

  2) 

  Removing the proxy icon with 'wm attributes -titlepath
  {}' always throws an error.

   


tkt_uuid: 220257ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 48. Geometry Management
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Invalid
title: tcl/tk goes into infinite loop on both unix and windows platforms
comment:
  OriginalBugID: 3682 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-24'
  LastModified: '1999-11-29'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  OSVersion: windows NT4.0sp5 and HP-UX 10.20
  ClosedDate: '1999-11-29'


  Name:
  Bergur Ragnarsson

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  #! /opt/tcl/bin/wish
  # $Header: /home/CVS_ARCHIVE/tern/ats/integration/showmap.tcl,v 1.2 1999/11/18 18:53:36 bergur Exp $
  #

  #
  # $Header: /home/CVS_ARCHIVE/tern/ats/integration/stdinc.tcl,v 1.1 1999/11/05 16:19:48 bergur Exp $
  #
  #
  # Example 27-2
  # Scroll_Set manages optional scrollbars.
  #

  proc Scroll_Set {scrollbar geoCmd offset size} {
  if {$offset != 0.0 || $size != 1.0} {
  eval $geoCmd;# Make sure it is visible
  }
  $scrollbar set $offset $size
  }

  #
  # Example 27-3
  # Listbox with optional scrollbars.
  #

  proc Scrolled_Listbox { f args } {
  frame $f
  listbox $f.list  -xscrollcommand [list Scroll_Set $f.xscroll  [list grid $f.xscroll -row 1 -column 0 -sticky we]]  -yscrollcommand [list Scroll_Set $f.yscroll  [list grid $f.yscroll -row 0 -column 1 -sticky ns]]
  eval {$f.list configure} $args
  scrollbar $f.xscroll -orient horizontal  -command [list $f.list xview]
  scrollbar $f.yscroll -orient vertical  -command [list $f.list yview]
  grid $f.list -sticky news
  grid rowconfigure $f 0 -weight 1
  grid columnconfigure $f 0 -weight 1
  return $f.list
  }
  #####################################################################
  #
  # START
  #

  frame .f1 -width 3000 -height 300 -background blue

  text .f1.text -width 50 -height 10

  set aw [list G1 63.59.1 -22.36.5 64.39.5 -21.17.4 65.34.4 -19.29.2 65.45.4 -18.00.3 66.15.1 -15.15.4 END]
  set saw [lsort $aw]

  set aw_list [Scrolled_Listbox .f1.flst -width 30 -height 10] 
  #set aw_list [listbox .f1.flst -width 30 -height 10] 
  eval {$aw_list insert end} $saw
  #$aw_list insert end route1 route2 route3

  pack $aw_list
  grid .f1.flst

  grid .f1.text

  pack .f1

  # how to reproduce:
  # a) run the script
  # b) type a few characters in the text box, then try selecting a few 
  #    characters, i.e. hold down shift and press left arrow a few times
  # c) system hangs (infinite loop)

  ObservedBehavior:
  Infinite looping

  DesiredBehavior:
  no infinite loop !



  Followup:
  pack $aw_list
  seems to causes conflict between the geometry managers grid & pack;
  the list object was previously under grid's control. Granted this isn´t
  correct code but it's hardly acceptable to go into spin.

  Best regards,
  Bergur Ragnarsson
   
  -- 11/24/1999 foster

  It is a known problem that there is a manager contention between
  pack and grid, but they should never be used together.  This is
  a dup of simpler cases for pack v grid. 
  -- 11/29/1999 hobbs


tkt_uuid: 2218962fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: Duplicate
title: spinbox-1.8.4 fails
comment:
  Tk HEAD just started reporting this
  in the full `make test` results:

  spinbox.test


  ==== spinbox-1.8.4 -validate option: FAILED
  ==== Contents of test case:

      .sb configure -validate all -validatecommand {lappend ::spinbox_test %P}
      pack .sb
      .sb set 50
      focus .sb
      after 100 {set ::spinbox_wait 1} ; vwait ::spinbox_wait
      set ::spinbox_test

  ---- Result was:

  ---- Result should have been (exact matching):
  50
  ==== spinbox-1.8.4 FAILED

  Running just the spinbox.test files results
  in no failure, so this is probably a test
  isolation problem.


tkt_uuid: 452713ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Works For Me
title: repeated test runs give diff. results
comment:
  Environment:
  Sun Ultra 5 running Solaris 7
  Sun WorkShop Compiler 5.0
  logged in at console

  I did the following:

  cd tcl8.3.3/unix
  make -s distclean
  configure
  make -s
  make -s test
  cd tk8.3.3/unix
  make -s distclean
  configure
  make -s
  make -s test > test.1
  make -s test > test2
  make -s test > test3

  All 3 test runs gave different results, with different
  tests succeeding and failing.  I did nothing in between
  the test runs and no one else was using the machine. 
  Contrary to comments made in comp.lang.tcl, socket
  usage and slow X connections had nothing to do with the
  failed tests.  I'm attaching the output of the 3 test
  runs.


tkt_uuid: 1881903fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 38. [tk_messageBox]
priority: 6
foundin: obsolete: 8.5.0
resolution: None
title: tk_messageBox -icon on Mac wrong
comment:
  This was using ActiveTcl anyway.

  1. calling tk_messageBox with no icon on Mac OS X results in no icon in the dialog; according to manual pages (and other platforms) it should show the "info" icon

  2. "-icon question" shows the "warning" icon

  3. "-icon error" shows the application (info) icon


tkt_uuid: 1723812fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 9 Immediate
foundin: obsolete: 8.5a7
resolution: Fixed
title: TCL_ALPHA_RELEASE used before #define-d
comment:
  Line 50 of tk.h:

  #define TK_RELEASE_LEVEL        TCL_ALPHA_RELEASE

  comes before line 57:

  #   include <tcl.h>

  which means every program that has

  #include <tk.h>

  must first have

  #include <tcl.h>

  That's not so bad as a requirement, but
  lines 56-61 of tk.h indicate that's
  not what's been intended.

  Obvious fix is a bit of line shifting.


tkt_uuid: 3306909fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: ttk::menubutton -dir right wrong menu placement
comment:
  Bug report 3305175 descibes, that the menu is placed in screen center far away from the menu button, if the menu is posted with a widget at the lower screen border:
  ttk::menubutton .b -direction right

  IMHO, a good menu placement strategy is:

  Given a Menubutton with y borders at by0, by1.

  The menu to post with y borders my0,my1
  and the menu height: dmy=my1-my0

  If by0+dmy fits onto the screen, post the menu with: my0 = by0
  If by0+dmy do not fit on the screen:
  - current solution (I suppose): my1 = by0
  - proposed solution: my1 = by1
  E.g. allign the lower widget end if menu is posted upwards.

  The following modification:
  - implements that for directions left and right
  - does hide bug 3305175

  - File tcl8.5\lib\tk8.5\ttk\menubutton.tcl -
    - Procedure ttk::menubutton::PostPosition
      - insert below switch -- $dir {...}
        (Line 101)
  <code>
  # Align the lower ends of button and menu, if no place to show menu
  # downwards
      if { $dir in {"left" "right"} && $y >= $sh } {
          set y [expr {$y-$mh+$bh}] }
      }
  </code>


tkt_uuid: 1542205fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: pressing toolbar button crashes Tk
comment:
  If you run the following script:

  ::tk::unsupported::MacWindowStyle style . document {closeBox 
  toolbarButton resizable}

  bind . <<ToolbarButton>> {puts "toolbar"}

  and press the toolbar button, Tk will print 'toolbar' and dump core.

  I think this patch fixes it:

  ===== macosx/tkMacOSXMouseEvent.c 1.22 vs edited =====
  --- 1.22/macosx/tkMacOSXMouseEvent.c2006-08-17 12:50:10 
  -07:00
  +++ edited/macosx/tkMacOSXMouseEvent.c2006-08-17 12:45:28 
  -07:00
  @@ -1019,6 +1019,7 @@
       event.root = XRootWindow(winPtr->display, 0);
       event.subwindow = None;
       event.time = TkpGetMS();
  +    event.user_data = 0;
   
       event.x_root = medPtr->global.h;
       event.y_root = medPtr->global.v;


tkt_uuid: 219919ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 31. Cursor Names
priority: 1 Zero
foundin: None
resolution: Duplicate
title: Support for custom cursors on Win32
comment:
  OriginalBugID: 1252 RFE
  Version: 8.0.4
  SubmitDate: '1999-02-22'
  LastModified: '1999-08-31'
  Severity: LOW
  Status: Closed
  Submitter: welch
  ChangedBy: hobbs
  RelatedBugIDs: 1350
  OS: Windows NT
  OSVersion: 4, SP3
  Machine: X86
  ClosedDate: '1999-08-31'


  Name:

  David Ascher


  Extensions:

  None


  CustomShell:

  Patch to tkWinCursor, no backwards-incompatible changes.  Only added new functionality on Win32


  ReproducibleScript:

  As documented in the Tk doc, custom cursors don't work on Win32.


  ObservedBehavior:

  Custom cursors don't work on Win32 -- one is limited to the system cursors.


  DesiredBehavior:

  Behavior similar on win32 as on X.


  Patch:

  --- tkWinCursor.c.oldWed Jan 13 13:28:21 1999

  +++ tkWinCursor.c.newWed Jan 13 13:51:26 1999

  @@ -109,6 +109,29 @@

   cursorPtr->winCursor = LoadCursor(Tk_GetHINSTANCE(), string);

   cursorPtr->system = 0;

       }

  +#ifdef WINDOWS_CURSOR_FILES

  +    if (string[0] == '@') {

  +    int argc;

  +    char **argv = NULL;

  +    if (Tcl_SplitList(interp, string, &argc, &argv) != TCL_OK) {

  +    return NULL;

  +    }

  +    if ((argc != 1) || (argv[0][0] != '@')) {

  +    ckfree((char *)cursorPtr);

  +    Tcl_AppendResult(interp, "bad cursor spec \"", string, "\"",

  +     (char *) NULL);

  +    return NULL;

  +    }

  +    if (Tcl_IsSafe(interp)) {

  +    Tcl_AppendResult(interp, "can't get cursor from a file in",

  +     " a safe interpreter", (char *) NULL);

  +    ckfree((char *)cursorPtr);

  +    return NULL;

  +    }

  +    cursorPtr->winCursor = LoadCursorFromFile(&(argv[0][1]));

  +    cursorPtr->system = 0;

  +    }

  +#endif

       if (cursorPtr->winCursor == NULL) {

   ckfree((char *)cursorPtr);

   Tcl_AppendResult(interp, "bad cursor spec \"", string, "\"",


  PatchFiles:

  tkWinCursor.c




  This adds support for .CUR and .ANI cursors.

  I believe I've submitted this patch before, but it never showed up anywhere, nor did I get an ack.  Please acknowledge receipt.


tkt_uuid: 1623588fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Fixed
title: tk_getOpenFile crashes on Linux 64-bit
comment:
  Hi,

  In tk_getOpenFile, after double-clicking on a file, the application freezes, making it impossible as well to access the Gnome desktop or any other X application, until it is killed remotely.

  Running with GDB, this is what I get (see below for more info)

  #0  0x00000000004abcc0 in TclBN_mp_mul_d ()
  #1  0x00000000004aa33d in TclBN_mp_div ()
  #2  0x000000000049bfda in TclDoubleDigits ()
  #3  0x00000000004a3db8 in Tcl_PrintDouble ()
  #4  0x0000002a97ca2e31 in Tk_CanvasObjCmd () from /tmp/tclN0nroo
  #5  0x000000000042a7f4 in TclEvalObjvInternal ()
  #6  0x000000000045ea8e in TclExecuteByteCode ()
  #7  0x000000000045d5ab in TclCompEvalObj ()
  #8  0x000000000042bb0b in TclEvalObjEx ()
  #9  0x000000000043c0a7 in Tcl_SwitchObjCmd ()
  #10 0x000000000042a7f4 in TclEvalObjvInternal ()
  #11 0x000000000045ea8e in TclExecuteByteCode ()
  #12 0x000000000045d5ab in TclCompEvalObj ()
  #13 0x000000000049375e in TclObjInterpProcCore ()
  #14 0x00000000004933ac in TclObjInterpProc ()
  #15 0x000000000042a7f4 in TclEvalObjvInternal ()
  #16 0x000000000045ea8e in TclExecuteByteCode ()
  #17 0x000000000045d5ab in TclCompEvalObj ()
  #18 0x000000000049375e in TclObjInterpProcCore ()
  #19 0x00000000004933ac in TclObjInterpProc ()
  #20 0x000000000042a7f4 in TclEvalObjvInternal ()
  #21 0x000000000042af06 in TclEvalEx ()
  #22 0x000000000042ac8f in Tcl_EvalEx ()
  #23 0x0000002a97c640b8 in Tk_BindEvent () from /tmp/tclN0nroo
  #24 0x0000002a97c69106 in TkBindEventProc () from /tmp/tclN0nroo


  This is with latest CVS HEAD (it also happens with 8.5a4)
  It only occurs on Linux 64bit, Linux 32bit is ok.
  This was compiled on Debian:

  Linux 2.6.12-1-em64t-p4-smp #1 SMP Wed Sep 28 03:50:13 CEST 2005 x86_64 GNU/Linux

  And tested on that Debian and a RHEL3:

  Linux localhost.localdomain 2.4.21-47.EL #1 SMP Wed Jul 5 20:30:36 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux

  I have searched c.l.t and bug tracker, but was unable to find a similar problem. Any ideas? what else can I do to help troubleshoot?


tkt_uuid: 1023272fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 13. Win Menus
priority: 6
foundin: None
resolution: None
title: Win unpost and Menubutton support
comment:
  This is a patch to provide some infrastructure for
  improving
  menu handling on Windows, in particular making Menubuttons
  work better.

  Nothing that uses the support is included in this patch
  so nothing user visible should be affected by the patch.
  By applying just this part I hope to get confirmation that
  these changes does not affect anything.

  The main points are:

  1. Move bindings definitions to menu.tcl

  2. Implement "unpost" as well as it can be.

  3. Provide virtual events on Menubutton's menu to help it
     do the right thing.

  4. Make tk::WinMenu a general command for support
     functions. More subcommands are foreseen there.


tkt_uuid: 420510ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Fixed
title: Win32 -cursor doesn't handle fg/bg color
comment:
  Windows parsing of the -cursor option barfs if you specify a foreground and/or background color.  For example:
      . config -cursor {circle red black}
  works fine on Unix platforms, but results in the error message
      bad cursor spec "circle red black"
  on Windows.  It looks like TkGetCursorByName isn't breaking up the string parameter before trying to find the cursor.

  Correct behavior would be to handle the cursor as it is in the Unix world.

  An acceptable alternative would be to ignore the foreground and background colors under Windows.  This means the same source will run on both Windows and Unix, and behave correctly on Unix.

  I haven't checked this on Mac.


tkt_uuid: 3393315fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Invalid
title: Aqua Tk mishandles menus with Dvorak Qwerty Cmd input method
comment:
  See discussion here http://comments.gmane.org/gmane.comp.lang.tcl.mac/6977 and here http://bugs.python.org/issue12748

  When the OS X Dvorak - Qwerty Cmd Input Method is enabled (tested on OS X 10.6.8), Aqua Tk does not properly handle menu keyboard accelerators.  It appears that the Cocoa Tk backport for 8.5.10 incorrectly accepts either the Dvorak or Qwerty key equivalent for a menu accelerator rather than just the Qwerty one.  This is particularly bad for the common Edit -> Cut menu shortcut (Cmd-X) since Dvorak X is Qwerty Q and causes the app to terminate immediately.


tkt_uuid: 685777ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: 'missing buttons' on MacOSX
comment:
  Environment: Max OS X (10.2, gcc 3.1), Tcl/Tk 8.4.1 
  The following script: 
  --------------------------- 
  > proc gen {w} { 
  >   button $w.b1 -text b1 
  >   button $w.b2 -text b2 
  >   grid $w.b1 $w.b2 
  > } 
  >  
  > toplevel .t 
  > gen .t 
  > gen "" 
  --------------------------- 
  will demostrate the problem.  
  What I expect to see are 2 toplevels 
  with two buttons (b1 and b2) each. 
   
  If run, the ".t" toplevel shows 
  both buttons while "." only shows ".b1". 
   
  Clicking on ".t" or the empty space of ".b1" draws it finally. 
  Some things I found about it are: 
   
  1.) at least two toplevels are needed. Has this something to do with 
      the (not really working) "focus" command? 
    
  2.) only the last "gridded button" is affected. 
     if you change to "labels" or use "pack", everything works fine. 
   
  3.) You may change the width of one of the two buttons and find 
      them "clipped" partially; so I suspect this has something 
      to do with the clipping setup code inherited from the "old" 
      MacTcl 
   


tkt_uuid: 459343ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: TIP#37, grid -uniform, patch
comment:
  This patch implements TIP#37 "Uniform Rows and Columns in Grid".

  This implementation uses Tk_Uid which has been questioned and
  thus needs further discussion.


tkt_uuid: 1481496fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 4
foundin: obsolete: 8.4.13
resolution: None
title: help menu entries block the application
comment:
  In my application, when certain entries from the
  help menu are selected, the application stops,
  displays the rainbow wheel and can only be killed.

  I can make the menu entries work using "after idle"
  for the menu command or by renaming the menu from
  "help" to "myhelp" (in the latter case, I then have
  of course two Help menus).
  The menu entries that do not work simply call
  a procedure that should fire up a web browser.
  Other entries from the same menu, that e.g. only
  pop up an About dialog, always work.

  This bug does not show up with Tcl/Tk 8.4.7.

  Application:
  http://sf.net/projects/ayam

  best regards,
  Randolf,
  -- 
  http://www.ayam3d.org/    Ayam, where import means NURBS!


tkt_uuid: 220775ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Cache button pixmap in Tk on Windows
comment:
  OriginalBugID: 603 RFE
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '2000-04-03'
  Severity: SER
  Status: Assigned
  Submitter: hershey
  ChangedBy: ericm
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


  It is possible to get a small speedup in Tk on Windows by caching

  button pixmaps.  Currently the pixmap for a button is recomputed each

  time the button is displayed.  This can slow down a redisplay of a

  window which was buried.



  The appended patch caches the button pixmap when possible on Windows.



  Ian Taylor

  ian@cygnus.com



  *** /5g/ian/tk8.0p2/win/tkWinButton.c   Thu Oct  9 13:40:18 1997

  --- tkWinButton.c       Thu Apr 16 17:25:01 1998

  *************** typedef struct WinButton {

  *** 38,43 ****

  --- 38,44 ----

        WNDPROC oldProc;          /* Old window procedure. */

        HWND hwnd;                        /* Current window handle. */

        Pixmap pixmap;            /* Bitmap for rendering the button. */

  +     int pixFlags;             /* Button flags for pixmap field. */

        DWORD style;              /* Window style flags. */

    } WinButton;

    

  *************** static DWORD            ComputeStyle _ANSI_ARGS_((

  *** 99,104 ****

  --- 100,106 ----

    static Window         CreateProc _ANSI_ARGS_((Tk_Window tkwin,

                              Window parent, ClientData instanceData));

    static void           InitBoxes _ANSI_ARGS_((void));

  + static void           TkpRealDisplayButton _ANSI_ARGS_((ClientData, int));

    static void           UpdateButtonDefaults _ANSI_ARGS_((void));

    

    /*

  *************** TkpCreateButton(tkwin)

  *** 238,243 ****

  --- 240,247 ----

    

        butPtr = (WinButton *)ckalloc(sizeof(WinButton));

        butPtr->hwnd = NULL;

  +     butPtr->pixmap = 0;

  +     butPtr->pixFlags = 0;

        return (TkButton *) butPtr;

    }

    

  *************** TkpDestroyButton(butPtr)

  *** 314,328 ****

        if (hwnd) {

          SetWindowLong(hwnd, GWL_WNDPROC, (DWORD) winButPtr->oldProc);

        }

    }

    

    /*

     *----------------------------------------------------------------------

     *

  !  * TkpDisplayButton --

     *

     *    This procedure is invoked to display a button widget.  It is

  !  *    normally invoked as an idle handler.

     *

     * Results:

     *    None.

  --- 318,338 ----

        if (hwnd) {

          SetWindowLong(hwnd, GWL_WNDPROC, (DWORD) winButPtr->oldProc);

        }

  +     if (winButPtr->pixmap != 0) {

  +       Tk_FreePixmap(butPtr->display, winButPtr->pixmap);

  +       winButPtr->pixmap = 0;

  +     }

    }

    

    /*

     *----------------------------------------------------------------------

     *

  !  * TkpDisplayButton, TkpRealDisplayButton --

     *

     *    This procedure is invoked to display a button widget.  It is

  !  *    normally invoked as an idle handler.  The TkpRealDisplayButton

  !  *    subroutine is used to optionally use the cached pixmap rather

  !  *    than recomputing it.

     *

     * Results:

     *    None.

  *************** void

  *** 338,343 ****

  --- 348,361 ----

    TkpDisplayButton(clientData)

        ClientData clientData;    /* Information about widget. */

    {

  +     TkpRealDisplayButton(clientData, 1);

  + }

  + 

  + static void

  + TkpRealDisplayButton(clientData, force)

  +     ClientData clientData;

  +     int force;

  + {

        TkWinDCState state;

        HDC dc;

        register TkButton *butPtr = (TkButton *) clientData;

  *************** TkpDisplayButton(clientData)

  *** 355,365 ****

  --- 373,401 ----

                                   * the text to make the button appear to

                                   * move up and down as the relief changes. */

    

  +     if ((butPtr->flags & REDRAW_PENDING) != 0) {

  +       force = 1;

  +     }

  + 

        butPtr->flags &= ~REDRAW_PENDING;

        if ((butPtr->tkwin == NULL) || !Tk_IsMapped(tkwin)) {

          return;

        }

    

  +     if (! force && ((WinButton *)butPtr)->pixmap != 0

  +           && ((WinButton *)butPtr)->pixFlags == butPtr->flags) {

  +       XCopyArea(butPtr->display, ((WinButton *)butPtr)->pixmap,

  +               Tk_WindowId(tkwin), butPtr->copyGC, 0, 0,

  +               (unsigned) Tk_Width(tkwin), (unsigned) Tk_Height(tkwin),

  +               0, 0);

  +       return;

  +     }

  + 

  +     if (((WinButton *)butPtr)->pixmap != 0) {

  +       Tk_FreePixmap(butPtr->display, ((WinButton*)butPtr)->pixmap);

  +       ((WinButton*)butPtr)->pixmap = 0;

  +     }

  + 

        border = butPtr->normalBorder;

        if ((butPtr->state == tkDisabledUid) && (butPtr->disabledFg != NULL)) {

          gc = butPtr->disabledGC;

  *************** TkpDisplayButton(clientData)

  *** 602,615 ****

        }

    

        /*

  !      * Copy the information from the off-screen pixmap onto the screen,

  !      * then delete the pixmap.

         */

    

        XCopyArea(butPtr->display, pixmap, Tk_WindowId(tkwin),

              butPtr->copyGC, 0, 0, (unsigned) Tk_Width(tkwin),

              (unsigned) Tk_Height(tkwin), 0, 0);

  !     Tk_FreePixmap(butPtr->display, pixmap);

    }

    

    /*

  --- 638,656 ----

        }

    

        /*

  !      * Copy the information from the off-screen pixmap onto the screen.

         */

    

        XCopyArea(butPtr->display, pixmap, Tk_WindowId(tkwin),

              butPtr->copyGC, 0, 0, (unsigned) Tk_Width(tkwin),

              (unsigned) Tk_Height(tkwin), 0, 0);

  ! 

  !     /*

  !      * Cache the pixmap.

  !      */

  ! 

  !     ((WinButton*)butPtr)->pixmap = pixmap;

  !     ((WinButton*)butPtr)->pixFlags = butPtr->flags;

    }

    

    /*

  *************** TkpComputeButtonGeometry(butPtr)

  *** 714,719 ****

  --- 755,765 ----

        Tk_GeometryRequest(butPtr->tkwin, (int) (width + butPtr->indicatorSpace

              + 2*butPtr->inset), (int) (height + 2*butPtr->inset));

        Tk_SetInternalBorder(butPtr->tkwin, butPtr->inset);

  + 

  +     if (((WinButton*)butPtr)->pixmap != 0) {

  +       Tk_FreePixmap(butPtr->display, ((WinButton*)butPtr)->pixmap);

  +       ((WinButton*)butPtr)->pixmap = 0;

  +     }

    }

    

    /*

  *************** ButtonProc(hwnd, message, wParam, lParam

  *** 782,788 ****

              PAINTSTRUCT ps;

              BeginPaint(hwnd, &ps);

              EndPaint(hwnd, &ps);

  !           TkpDisplayButton((ClientData)butPtr);

              return 0;

          }

          case BN_CLICKED: {

  --- 828,834 ----

              PAINTSTRUCT ps;

              BeginPaint(hwnd, &ps);

              EndPaint(hwnd, &ps);

  !           TkpRealDisplayButton((ClientData)butPtr, 0);

              return 0;

          }

          case BN_CLICKED: {





  Evaluate the correctness of the patch; can a similar thing be done on Unix?  What about the memory issues?

  - eric

  -- 04/03/2000 ericm


tkt_uuid: 220948ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Fixed
title: TkWinHandleMenuEvent sets service mode incorrectly.
comment:
  OriginalBugID: 6238 Bug
  Version: 8.3.2
  SubmitDate: '2000-09-08'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: All Windows


  Name:
  Rick Hedin

  CVS:
  /cvsroot/tk/win/tkWinMenu.c,v revision 1.13

  ReproducibleScript:
  I found that if I restored a minimized Tk window by clicking on it, it worked fine.  But if I restored it by right-clicking and picking "Restore", Tk was broken.  Windows didn't update, and keypresses were ignored.  I am working with Tk embedded in C under Microsoft Windows.  

  It turns out that the TkWinHandleMenuEvent routine never stores the old service mode in the case of a Windows window.  When you leave the menu and TWHME restores the service mode, it restores the wrong thing.  That is why it works in a Wish environment:  Tk windows have their old service mode stored.  

  I made a small code change to TkWinHandleMenuEvent.  Now it works.  I don't think this change will propagate through the code.  I think it's isolated.

  ObservedBehavior:
  Old operation:  

  Set oldServiceMode in the thread specific data only if it was a Tk window.  Set service mode from oldServiceMode whether it was a Windows window or a Tk window.

  DesiredBehavior:
  New operation:

  Sets oldServiceMode in the thread specific data regardless of which kind of window it is.  oldServiceMode is always valid when it is used to set the service mode.

  Patch:
  C:\Users\rhedin\work\tk>cvs diff win/tkWinMenu.c
  Index: win/tkWinMenu.c
  ===================================================================
  RCS file: /cvsroot/tk/win/tkWinMenu.c,v
  retrieving revision 1.13
  diff -r1.13 tkWinMenu.c
  904a905
  >             tsdPtr->oldServiceMode = Tcl_SetServiceMode(TCL_SERVICE_ALL);
  908d908
  <               tsdPtr->oldServiceMode = Tcl_SetServiceMode(TCL_SERVICE_ALL);

  C:\Users\rhedin\work\tk>

  PatchFiles:
  win/tkWinMenu.c


tkt_uuid: 220451ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Divide by zero in TkCanvasArc.c
comment:
  OriginalBugID: 1479 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-11'
  LastModified: '1999-04-16'
  Severity: CRIT
  Status: Released
  Submitter: welch
  ChangedBy: rjohnson
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  FixedDate: '1999-04-16'


  Name:
  Bob Fletcher

  Extensions:
  expect

  ObservedBehavior:
      (note $$%% wincenter could not deal with the mixed case name,
       this was tkCanvArc.c)
      
      This bug involves very small arcs. Tk keeps track of a bounding box
      to help speed up find close items, and overlapping items. For arcs
      it is possible for the exents of this box to cover only one row or
      column
      of pixels (especially if you scale coordinates) If you are then checking
      all items (for a highlight or snap_to_geometry type function) the test
      for ths cursor passes thru code  that causes an integer divide by zero.
      
      



  Patch:
  768,777c768,769
  < 
  <     t1 = (arcPtr->bbox[3] - arcPtr->bbox[1]);
  <     if (t1 !=0.0) {
  <         t1 = (pointPtr[1] - vertex[1])/t1;
  <     }
  < 
  <     t2 = (arcPtr->bbox[2] - arcPtr->bbox[0]);
  <     if (t2 != 0.0) {
  <         t2 = (pointPtr[0] - vertex[0])/t2;
  <     }
  ---
  >     t1 = (pointPtr[1] - vertex[1])/(arcPtr->bbox[3] - arcPtr->bbox[1]);
  >     t2 = (pointPtr[0] - vertex[0])/(arcPtr->bbox[2] - arcPtr->bbox[0]);





  PatchFiles:
      TkCanvasArc.c
      





  I applied this patch.  04/16/1999 17:25 - rjohnson -


tkt_uuid: 219945ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Duplicate
title: Index of window in text STILL dumps core
comment:
  OriginalBugID: 1546 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-19'
  LastModified: '1999-03-24'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: surles
  RelatedBugIDs: 991
  OS: Other
  Machine: NA
  ClosedDate: '1999-03-24'


  Name:
  Don Porter



      See [BugID: 991] reporting the bug in Tk 8.1b1 on
      http://www.scriptics.com/resource/software/patches/tk81b1
      
      The bug is still present in Tk 8.1b2.  
      The submitted patch still fixes it.
      
      PLEASE, don't let 8.1 go final without fixing this.
      


tkt_uuid: 1847002fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 56. [grab]
priority: 5 Medium
foundin: obsolete: 8.4.16
resolution: Fixed
title: User may activate other toplevels.
comment:
  On Windows, when there is a grab, the user can interate with other toplevels on the same app using the taskbar.

  To replicate this, on wish, execute this code:

  toplevel .t ; grab .t

  You can activate the main toplevel (the one titled "wish84") clicking its icon on the windows taskbar. It comes to the front, possibly hiding the toplevel that has the grab. This is annoying and confusing. I know a case where the user rebooted Windows, after apparently being stuck with an unresponsive application. It goes against the semantics of grab, too. No Tk event is fired, so the programmer can do nothing to prevent this.

  In tkWinWm.c, the case where the user clicks onto a non-grabbed toplevel is managed (see WmProc, handling of WM_MOUSEACTIVATE message). Putting similar code on the handling of the WM_ACTIVATE message resolves the problem by making sure that no matter what toplevel the user tries to activate with the taskbar, if there is a grab active, the toplevel that has the grab stays active and on top.

  There is other related problem with the current implementation of grab: the user can interact with the system menu of the non-grabbed toplevels, thus being able to close, minimize, etc them. An ideal solution would be to disable the system menu for all toplevels except the grabbed one, and enable it again when the grab is released. However, an improvement over the current situation is to ignore WM_SYSCOMMAND when there is a grab (except for the grabbed toplevel).

  Finally, IMO the user should be not allowed to minimize a grabbed window.

  Patch implementing all this attached.

  To recapitulate, it is my undersanding that, when there is a grab, the user shouldn't be allowed to interact with those parts of the application's GUI that are outside the limits of the grabbed portion. Although the patch does not resolve enterely the problem, it avoids GUI states that can cause trouble and confussion both to the user and developer.


tkt_uuid: 707792ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: makefile.vc/rules.vc doesn't reflect d/g suffix change
comment:
  the makefile.vc and rules.vc files for Tk do not 
  reflect the change of debug suffix from 'd' to 'g'.  
  patch attached.

  JJM


tkt_uuid: 2930718fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: Undocumented API: Tk_Outline
comment:
  Entries 221-226 in tk.decls (the Tk_Outline function API) have no documentation anywhere in Tk. As part of the public API, this should be fixed.

      void Tk_CreateOutline(Tk_Outline *outline)
      void Tk_DeleteOutline(Display *display, Tk_Outline *outline)
      int Tk_ConfigOutlineGC(XGCValues *gcValues, Tk_Canvas canvas,
              Tk_Item *item, Tk_Outline *outline)
      int Tk_ChangeOutlineGC(Tk_Canvas canvas, Tk_Item *item,
              Tk_Outline *outline)
      int Tk_ResetOutlineGC(Tk_Canvas canvas, Tk_Item *item,
              Tk_Outline *outline)
      int Tk_CanvasPsOutline(Tk_Canvas canvas, Tk_Item *item,
              Tk_Outline *outline)


tkt_uuid: 220724ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: File browser: selecting multiple files
comment:
  OriginalBugID: 4999 RFE
  Version: 8.3
  SubmitDate: '2000-04-11'
  LastModified: '2000-06-22'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 604
  OS: All Unix
  FixedDate: '2000-06-22'
  FixedInVersion: 8.4a2


  Name:

  James Bonfield


  CustomShell:

  Just the xmfbox speed-up patch sent in another mail. It is not required for the above change.


  Comments:

  We have extensions to allow -multiple to work for the built-in windows

      browser too, although at present these are diffs against tk8.0.3. We are

      working on upgrading these to the windows version of tk8.3 and we will

      submit this patch when ready.


      We do not have patches to the Mac version and neither do we have patches

      to the non-motif style file browser, but due to the severe slowness of

      that version we also have no plans to do so.


  DesiredBehavior:

  A "-multiple" option to allow selection of multiple files using tk_getOpenFile


  Patch:

  *** orig/xmfbox.tcl     Thu Jan  6 02:22:25 2000

  --- new/xmfbox.tcl      Wed Apr  5 17:50:25 2000

  ***************

  *** 21,31 ****

    #     args            Options parsed by the procedure.

    #

    # Results:

  ! #     A list of two members. The first member is the absolute

  ! #     pathname of the selected file or "" if user hits cancel. The

  ! #     second member is the name of the selected file type, or ""

  ! #     which stands for "default file type"

  ! 

    proc tkMotifFDialog {type args} {

        global tkPriv

        set dataName __tk_filedialog

  --- 21,33 ----

    #     args            Options parsed by the procedure.

    #

    # Results:

  ! #     When -multiple is set to false, this returns the absolute pathname

  ! #     of the selected file. (NOTE: This is not the same as a single

  ! #     element list.)

  ! # 

  ! #     When -multiple is set to true, this returns a Tcl list of absolute

  ! #       pathnames.

  ! #

    proc tkMotifFDialog {type args} {

        global tkPriv

        set dataName __tk_filedialog

  ***************

  *** 97,102 ****

  --- 99,105 ----

          set data(filterBtn) $w.bot.filter

          set data(cancelBtn) $w.bot.cancel

        }

  +     tkMotifFDialog_SetListMode $w


        wm transient $w $data(-parent)


  ***************

  *** 138,143 ****

  --- 141,147 ----

          {-initialfile "" "" ""}

          {-parent "" "" "."}

          {-title "" "" ""}

  +       {-multiple "" "" ""}

        }


        # 2: default values depending on the type of the dialog

  ***************

  *** 154,160 ****


        if {[string equal $data(-title) ""]} {

          if {[string equal $type "open"]} {

  !           set data(-title) "Open"

          } else {

              set data(-title) "Save As"

          }

  --- 158,168 ----


        if {[string equal $data(-title) ""]} {

          if {[string equal $type "open"]} {

  !           if {[string equal $data(-multiple) "true"]} {

  !               set data(-title) "Open Multiple Files"

  !           } else {

  !               set data(-title) "Open"

  !           }

          } else {

              set data(-title) "Save As"

          }

  ***************

  *** 285,290 ****

  --- 293,310 ----

        wm protocol $w WM_DELETE_WINDOW [list tkMotifFDialog_CancelCmd $w]

    }


  + proc tkMotifFDialog_SetListMode {w} {

  +     upvar #0 [winfo name $w] data

  + 

  +     if {[string equal $data(-multiple) "true"]} {

  +       set selectmode extended

  +     } else {

  +       set selectmode browse

  +     }

  +     set f $w.top.f2.b

  +     $f.l configure -selectmode $selectmode

  + }

  + 

    # tkMotifFDialog_MakeSList --

    #

    #     Create a scrolled-listbox and set the keyboard accelerator

  ***************

  *** 302,308 ****


    proc tkMotifFDialog_MakeSList {w f label under cmdPrefix} {

        label $f.lab -text $label -under $under -anchor w

  !     listbox $f.l -width 12 -height 5 -selectmode browse -exportselection 0\

          -xscrollcommand [list $f.h set] -yscrollcommand [list $f.v set]

        scrollbar $f.v -orient vertical   -takefocus 0 -command [list $f.l yview]

        scrollbar $f.h -orient horizontal -takefocus 0 -command [list $f.l xview]

  --- 322,328 ----


    proc tkMotifFDialog_MakeSList {w f label under cmdPrefix} {

        label $f.lab -text $label -under $under -anchor w

  !     listbox $f.l -width 12 -height 5 -exportselection 0 \

          -xscrollcommand [list $f.h set] -yscrollcommand [list $f.v set]

        scrollbar $f.v -orient vertical   -takefocus 0 -command [list $f.l yview]

        scrollbar $f.h -orient horizontal -takefocus 0 -command [list $f.l xview]

  ***************

  *** 484,490 ****

        cd $appPWD

    }


  ! # tkMotifFDialog_BrowseFList --

    #

    #     This procedure is called when the directory list is browsed

    #     (clicked-over) by the user.

  --- 504,510 ----

        cd $appPWD

    }


  ! # tkMotifFDialog_BrowseDList --

    #

    #     This procedure is called when the directory list is browsed

    #     (clicked-over) by the user.

  ***************

  *** 596,602 ****

        if {[string equal [$data(fList) curselection] ""]} {

          return

        }

  !     set data(selectFile) [$data(fList) get [$data(fList) curselection]]

        if {[string equal $data(selectFile) ""]} {

          return

        }

  --- 616,625 ----

        if {[string equal [$data(fList) curselection] ""]} {

          return

        }

  !     set data(selectFile) ""

  !     foreach item [$data(fList) curselection] {

  !       lappend data(selectFile) [$data(fList) get $item]

  !     }

        if {[string equal $data(selectFile) ""]} {

          return

        }

  ***************

  *** 607,615 ****

        $data(fEnt) insert 0 [tkFDialog_JoinFile $data(selectPath) $data(filter)]

        $data(fEnt) xview end


        $data(sEnt) delete 0 end

  !     $data(sEnt) insert 0 [tkFDialog_JoinFile $data(selectPath) \

  !           $data(selectFile)]

        $data(sEnt) xview end

    }


  --- 630,644 ----

        $data(fEnt) insert 0 [tkFDialog_JoinFile $data(selectPath) $data(filter)]

        $data(fEnt) xview end


  +     # if it's a multiple selection box, just put in the filenames 

  +     # otherwise put in the full path as usual 

        $data(sEnt) delete 0 end

  !     if {[string equal $data(-multiple) "true"]} {

  !       $data(sEnt) insert 0 $data(selectFile)

  !     } else {

  !       $data(sEnt) insert 0 [tkFDialog_JoinFile $data(selectPath) \

  !                                 [lindex $data(selectFile) 0]]

  !     }

        $data(sEnt) xview end

    }


  ***************

  *** 678,685 ****

        upvar #0 [winfo name $w] data


        set selectFilePath [string trim [$data(sEnt) get]]

  -     set selectFile     [file tail    $selectFilePath]

  -     set selectPath     [file dirname $selectFilePath]


        if {[string equal $selectFilePath ""]} {

          tkMotifFDialog_FilterCmd $w

  --- 707,712 ----

  ***************

  *** 686,692 ****

          return

        }


  !     if {[file isdirectory $selectFilePath]} {

          set data(selectPath) [glob $selectFilePath]

          set data(selectFile) ""

          tkMotifFDialog_Update $w

  --- 713,723 ----

          return

        }


  !     if {[string compare $data(-multiple) "true"]} {

  !       set selectFilePath [list $selectFilePath]

  !     }

  ! 

  !     if {[file isdirectory [lindex $selectFilePath 0]]} {

          set data(selectPath) [glob $selectFilePath]

          set data(selectFile) ""

          tkMotifFDialog_Update $w

  ***************

  *** 693,732 ****

          return

        }


  !     if {[string compare [file pathtype $selectFilePath] "absolute"]} {

  !       tk_messageBox -icon warning -type ok \

  !           -message "\"$selectFilePath\" must be an absolute pathname"

  !       return

  !     }

  ! 

  !     if {![file exists $selectPath]} {

  !       tk_messageBox -icon warning -type ok \

  !           -message "Directory \"$selectPath\" does not exist."

  !       return

  !     }

  ! 

  !     if {![file exists $selectFilePath]} {

  !       if {[string equal $data(type) open]} {

              tk_messageBox -icon warning -type ok \

  !               -message "File \"$selectFilePath\" does not exist."

              return

          }

  !     } else {

  !       if {[string equal $data(type) save]} {

  !           set message [format %s%s \

  !               "File \"$selectFilePath\" already exists.\n\n" \

  !               "Replace existing file?"]

  !           set answer [tk_messageBox -icon warning -type yesno \

  !               -message $message]

  !           if {[string equal $answer "no"]} {

                  return

              }

          }

        }


  !     set tkPriv(selectFilePath) $selectFilePath

  !     set tkPriv(selectFile)     $selectFile

  !     set tkPriv(selectPath)     $selectPath

    }


  --- 724,770 ----

          return

        }


  !     set newFileList ""

  !     foreach item $selectFilePath {

  !       if {[string compare [file pathtype $item] "absolute"]} {

  !           set item [file join $data(selectPath) $item]

  !       } elseif {![file exists [file dirname $item]]} {

              tk_messageBox -icon warning -type ok \

  !               -message "Directory \"[file dirname $item]\" does not exist."

              return

          }

  ! 

  !       if {![file exists $item]} {

  !           if {[string equal $data(type) open]} {

  !               tk_messageBox -icon warning -type ok \

  !                   -message "File \"$item\" does not exist."

                  return

              }

  +       } else {

  +           if {[string equal $data(type) save]} {

  +               set message [format %s%s \

  +                                "File \"$item\" already exists.\n\n" \

  +                                "Replace existing file?"]

  +               set answer [tk_messageBox -icon warning -type yesno \

  +                               -message $message]

  +               if {[string equal $answer "no"]} {

  +                   return

  +               }

  +           }

          }

  + 

  +       lappend newFileList $item

        }


  !     if {[string equal $data(-multiple) "true"]} {

  !       set tkPriv(selectFilePath) $newFileList

  !     } else {

  !       set tkPriv(selectFilePath) [lindex $newFileList 0]

  !     }

  ! 

  !     # Set selectFile and selectPath to first item in list

  !     set tkPriv(selectFile)     [file tail    [lindex $newFileList 0]]

  !     set tkPriv(selectPath)     [file dirname [lindex $newFileList 0]]

    }


  PatchFiles:

  xmfbox.tcl




  Thanks for the patch.  I have applied it to the sources in CVS, and it will go out with 8.4a2.

  - eric

  -- 06/22/2000 ericm


tkt_uuid: 3472539fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Moving the cursor in elided text freezes Tk
comment:
  The attached patch fixes item 3021557:

  Moving the cursor in elided text freezes Tk:
  https://sourceforge.net/tracker/?func=detail&aid=3021557&group_id=12997&atid=112997

  The patch is against the latest Fossil sources.

  The existing text.test suite passes with no failure (but one completely unrelated: text-33.11).
  I have added one test item for issue 3021557 that the patch is fixing.


tkt_uuid: 508677ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Invalid
title: threaded wish, Solaris 8, Workshop 6 bad
comment:
  First built and tested Tcl with --disable-shared,
  --enable-threads.

  Then in Tk, using the Sun Workshop 6 C compiler:

  $ mkdir solaris
  $ cd solaris
  $ setenv CC cc
  $ ../unix/configure --disable-shared --enable-threads
  --with-tcl=../../tcl/unix
  ...
  $ make
  ...
  cc  tkAppInit.o \
          -L/local/src/tk/solaris -ltk8.4 \
          -L/local/src/tcl/unix -ltcl8.4  -lsocket -lnsl
  -lpthread -L/usr/openwin/lib -lX11 -ldl -lm
  -Wl,-rpath,/usr/local/lib:/usr/openwin/lib -o wish
  ld: fatal: file /usr/local/lib:/usr/openwin/lib: open
  failed: No such file or directory

  Something wrong with TK_CC_SEARCH_FLAGS ?  Not
  matching what the compiler expects?


tkt_uuid: 3607262fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 5 Medium
foundin: current: 8.6.0
resolution: Duplicate
title: All forms of embedding fail on Cocoa
comment:
  I note bug 3033786 - Cannot embed Tk in a(nother) Cocoa Application.  The present bug is that toplevel embedding also fails when attempted in the same application.

  The following commands all fail in a similar way on Tk/Aqua/Cocoa:

  toplevel $top -use [winfo id [frame $fr -container 1]]

  ::safe::loadTk [safe::interpCreate $int]

  ::safe::loadTk [safe::interpCreate $int] -use [winfo id [frame $fr -container 1]]

  ::safe::loadTk [safe::interpCreate $int] -use [frame $fr -container 1]

  For example,

  $ /usr/local/tcl8.6/bin/wish8.6
  % safe::interpCreate bar
  bar
  % ::safe::loadTk bar
  The window ID 0x6311ff10 does not correspond to a valid Tk Window
  % set errorInfo
  The window ID 0x6311ff10 does not correspond to a valid Tk Window
      invoked from within
  "load {} Tk $slave"
      (procedure "::safe::loadTk" line 61)
      invoked from within
  "::safe::loadTk bar"

  The standard "Untrusted Tcl applet" container is drawn, but the toplevel "." associated with interpreter "bar" never appears.  The interpreter "bar" is left in an inconsistent state where Tk commands exist but cannot be evaluated.

  Combined with bug 3033786, this means that Tk can no longer be loaded into a Safe Base interpreter on the Aqua windowing system.


tkt_uuid: 3567037fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: Duplicate
title: compiler warning
comment:
  Twylite reports on TCLCORE:

  C:\User\Tcl_BUILD\tcl86b3rc\tcl8.6b3\pkgs\tk8.6b3\win\..\win\tkWinWm.c(5529) 
  : warning C4133: 'function' : incompatible types - from 'TkWindow *' to 
  'Tk_Window'


tkt_uuid: 220511ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: Docs missing for Tk_SafeInit API
comment:
  OriginalBugID: 1884 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '2000-04-27'
  Severity: MED
  Status: Released
  Submitter: surles
  ChangedBy: ericm
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-04-27'
  FixedInVersion: 8.4a1


  .

  I added an entry for this API.  This fix will go out with 8.4a1.

  - eric
   
  -- 04/27/2000 ericm


tkt_uuid: 220656ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: Wrong option spec for tkListbox
comment:
  OriginalBugID: 4039 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-19'
  LastModified: '2000-01-19'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  FixedDate: '2000-01-19'
  FixedInVersion: 8.3


  Name:

  Harald Kunze


  Extensions:

  iTcl


  Comments:

  When creating megawidgets with [incr Tk] which include a listbox and an entry it causes an error, as the resource class for selectBackground of an entry and a listbox differs.


  ReproducibleScript:

  option add *Background red


  listbox .l

  pack .l -fill both


  .l insert end this

  .l insert end is

  .l insert end a

  .l insert end test


  ObservedBehavior:

  The active item and the listbox itself have the same background color.


  DesiredBehavior:

  Only the background color of the listbox is set to red.


  Patch:

  234c234

  <     {TK_OPTION_BORDER, "-selectbackground", "selectBackground", "Background",

  ---

  >     {TK_OPTION_BORDER, "-selectbackground", "selectBackground", "Foreground",

  282c282

  <     {TK_OPTION_BORDER, "-selectbackground", "selectBackground", "Background",

  ---

  >     {TK_OPTION_BORDER, "-selectbackground", "selectBackground", "Foreground",


  PatchFiles:

  tkListbox.c




  Correct, this got incorrectly swapped in the objectification of
  the widget.  Also the items -select* class was changed. 
  -- 01/19/2000 hobbs


tkt_uuid: 220051ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Duplicate
title: Thread compile option seriously slows down redraw
comment:
  OriginalBugID: 3833 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-09'
  LastModified: '1999-12-09'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2438
  OS: Linux-Red Hat
  OSVersion: Redhat 6.1
  Machine: dual PII Xeon 256M Matrox G200
  ClosedDate: '1999-12-09'


  Name: Tim Wallace

  ReproducibleScript:
  My colleague recently compiled tcl/tk 8.2.2 and BLT 2.4m as shared
  libraries under Linux (Redhat 6.1).  Comparing to our previous versions
  showed that the BLT zoom with the dotted box was very slow and jerky.
  It almost seemed that it waited until the motion events were done
  and the mouse stopped for some time before it updated the box.
  (His machine is a dual 450 MHz PII Xeon with 256 M.) 
  Rolling back to a previous BLT shared library didn't help.  I suggested 
  re-compiling tcl/tk without threads, and that cured the problem.
  We don't need threads, but this is a bug that should be fixed.
  If this was his first exposure to tcl/tk, that might have been enough
  to get him to decide that it just wasn't fast enough for serious work!

  ObservedBehavior:
  BLT zoom ( from bltGraph.tcl script) very jumpy

  DesiredBehavior:
  Smooth zoom



  Tk has not yet been condoned for use in a threaded environment.
  There are still issues about handling the X stuff to work out.
  This is not expected to work right now, but we do expect to make
  it work sometime in the future (Tcl was first priority, and is
  very stable with threads in 8.2.2). 
  -- 12/09/1999 hobbs


tkt_uuid: 220741ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: Target install-libraries wrng under Windows
comment:
  OriginalBugID: 5516 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-15'
  LastModified: '2000-05-22'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  OSVersion: Windows NT 4.0 with cygnuys b20 and vc6.0
  Machine: athlon, but does not matter
  FixedDate: '2000-05-22'
  FixedInVersion: 8.4a1


  Name:
  Wolfgang S. Kechel

  ReproducibleScript:
  The target install-binaries does not install the X-headers from win/xlib
  into the distribution. This causes a compile time error when trying
  to compile extensions that use the Tk internals.
  makefile.vc does this in a correct way.

  ObservedBehavior:
  ... missing header files

  DesiredBehavior:
  Correct installation, like present in makefile.vc

  Patch:
  88% diff -bc Makefile.in Makefile.in.orig 
  *** Makefile.in Mon May 15 22:02:27 2000
  --- Makefile.in.orig    Mon May 15 21:54:02 2000
  ***************
  *** 428,439 ****
                  fi;  done;
          @echo "Installing header files";
  !       @for i in $(GENERIC_DIR)/tk.h $(GENERIC_DIR)/tkDecls.h !       $(GENERIC_DIR)/tkIntXlibDecls.h ;  do  $(INSTALL_DATA) $$i $(INCLUDE_INSTALL_DIR);  done;
  -       @cp -r $(XLIB_DIR)/X11 $(INCLUDE_INSTALL_DIR);
          @echo "Installing library files to $(SCRIPT_INSTALL_DIR)";
          @for i in $(ROOT_DIR)/library/*.tcl $(GENERIC_DIR)/prolog.ps  $(ROOT_DIR)/library/tclIndex $(UNIX_DIR)/tkAppInit.c;  --- 428,437 ----
                  fi;  done;
          @echo "Installing header files";
  !       @for i in $(GENERIC_DIR)/tk.h $(GENERIC_DIR)/tkDecls.h ;  do  $(INSTALL_DATA) $$i $(INCLUDE_INSTALL_DIR);  done;
          @echo "Installing library files to $(SCRIPT_INSTALL_DIR)";
          @for i in $(ROOT_DIR)/library/*.tcl $(GENERIC_DIR)/prolog.ps  $(ROOT_DIR)/library/tclIndex $(UNIX_DIR)/tkAppInit.c;  
  PatchFiles:
  tk8.3.1/win/Makefile.in



  Fixed in 8.4a1 release. 
  -- 05/22/2000 hobbs


tkt_uuid: 220850ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: final: 8.0.5
resolution: Out of Date
title: Canvas arrows broken on Mac
comment:
  OriginalBugID: 2250 Bug
  Version: 8.0.5
  SubmitDate: '1999-06-16'
  LastModified: '1999-10-22'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: MacOS 8.6
  Machine: Power PC


  Name:
  Michael Halle

  ReproducibleScript:
  widget canvas items demo

  ObservedBehavior:
  arrowheads are not placed correctly on lines.


tkt_uuid: 1285304fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 9 Immediate
foundin: obsolete: 8.5a4
resolution: Duplicate
title: wrong exit handler used to clean up windows
comment:
  In function Initialize() (generic/tkwindow.c) an exit 
  handler is  created to deal with windows when exiting 
  the thread. Unfortunately it used  TkCreateExitHandler() 
  to create a process global exit handler, with a passed 
  argument of the thread specific data area the has the 
  lists of  active windows. I changed this to 
  Tcl_CreateThreadExitHandler() and  all is OK.


tkt_uuid: 2932808fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Fixed
title: Canvas items not updating on widget state change
comment:
  The canvas widget allows different attributes to be set on items depending on their state, normal/disabled/active.  However, the items are not updated if the overall widget state is changed.  Example:

  pack [canvas .c] -fill both
  .c create text 100 100 -text "Test Text" \
  -disabledfill blue
  .c configure -state disabled

  The text should now be displayed in blue, but isn't.  Doing any item configuration forces an update:

  .c itemconfigure 1 -text "Updated Text"

  The attached patch fixes the problem.  It is for tk 8.5.8, tkCanvas.c revision 1.46.2.2.


tkt_uuid: 220518ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: Documentation of "text" widget is incomplete
comment:
  OriginalBugID: 2004 Bug
  Version: 8.1
  SubmitDate: '1999-05-07'
  LastModified: '2000-01-18'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux-Red Hat
  Machine: Other
  FixedDate: '2000-01-18'
  FixedInVersion: 8.3


  Name:
  D. Richard Hipp

  ReproducibleScript:
  The is a documentation error only.  In the text widget in the
      "dump" widget command, there is no mention of the "-image" option.



  added in 8.3.0. 
  -- 01/18/2000 hobbs


tkt_uuid: 2899949fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 9 Immediate
foundin: obsolete: 8.5.8
resolution: Fixed
title: tk crashes when destroying a widget
comment:
  The added script causes an coredump when startet by

  wish85.exe core-858.tcl

  Sometimes the script runs fine but mostly tk crashes.
  Strange: i had no coredump when I removed the
      label  $w.l
  line.

  Probably this relays to bug 2828398. Althought the scipt i posted for bug 2828398runs fine with 8.5.8.
  The bug only occurs on Windows. - Linux works fine.
     


tkt_uuid: 2827327fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: transparent backgrounds
comment:
  [Transferred from Tcl tracker issue 798887]

  Hi,
  I'm a developper in the aMSN's project (amsn.sf.net) and we would 
  like a new feature but it looks pretty hard to add.. it's about skinning, 
  we want to create skins, which means we need two new things, first a 
  [wm border borderless] command that would tell the window manager 
  to disable border (so we can create our own title bar and close icons 
  with our own images) .. but that's not really *important* ...
  The second request is more important.. we would like to make a 
  background image for text widgets (chat windows or for the main 
  contact list window) I thought about doing something like pack $w.
  text -in $w.label (with a label -image ... ) but I noticed that the image 
  disappears behind the text widget... so the text widget background is 
  solid... what would help us alot, is having a transparent background... 
  only the text and windows/images added in the text widget would be 
  solid... that could be a new option (-backgroundimage) or with 
  -background transparent ... or maybe juste set a color that would be 
  transparent like -background #-1-1-1 ....
  anyways I would like your advice on this, are you going to add this 
  soon, or maybe there is some other way to do what I am requesting..
  .

  KaKaRoTo


tkt_uuid: 220246ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: no gui update while reading from socket (fileevent readable)
comment:
  OriginalBugID: 3235 Bug
  Version: 8.0.5
  SubmitDate: '1999-10-28'
  LastModified: '1999-11-02'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  ClosedDate: '1999-11-02'


  Name:robert karen

  Extensions:tktable

  ReproducibleScript:
  proc blink {win} {
        if {![string compare [$win cget -fg] red]} {
          $win configure -fg blue
        } else {
          $win confgugre -fg red
        }
        update
        after 500 "blink $win"
      }
      filevent $sock readable readit....
      set s [socket $address $port]
      after 500 blink $label
      puts $s "get_file"
      vwait var

  ObservedBehavior:
  once script starts reading from socket (like a  file download
      where there are many reads), the update doesn't cause the 
      color to change. I believe that I have also had statements like
      '$win configure -cursor watch; update' have no effect
      if they were right before the socket started reading. Not sure
      though.



  In this case, the user wants 'update idle'.  The update will
  cause the fileevent to just trigger again, making it seem like
  the window isn't wanting to update. 
  -- 11/02/1999 hobbs


tkt_uuid: 2031090fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Duplicate
title: gitk crash with tk8.5.3
comment:
  Original bug report:
  Running gitk gives the attached output, gitk doesn't work right. Window opens, but can't do anything on it with the mouse

  I have the same output, but gitk isn't crashing. The message disappeared after removing last changes in tcl.tk file. I'll ask bug reporter, if my patch solved the gitk's crash.


tkt_uuid: 220796ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.1b2
resolution: None
title: -stipple option for canvas text item disrupts positioning, b
comment:
  OriginalBugID: 1522 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-18'
  LastModified: '2000-04-03'
  Severity: SER
  Status: Assigned
  Submitter: pat
  ChangedBy: ericm
  OS: Windows 95
  OSVersion: OSR2, US English
  Machine: X86


  Name:
  Bill Schongar

  Extensions:
  None

  CustomShell:
  None

  ReproducibleScript:
      pack [canvas .c]
      .c create text 10 10 "Foo" -tags a
      .c create text 90 10 "Foo" -stipple gray12 -tags b
      eval .c create rectangle [.c bbox b] -fill green
      



  ObservedBehavior:
      1) The text is not stippled, it appears in a "selected" state
      2) The text with the '-stipple' option applied does not occupy the
        bounds reported by bbox, as shown by the rectangle drawn to occupy
        that reported space.
      



  DesiredBehavior:
      1) Text stippled based on the bitmap pattern specified
      2) Text occupies spaces which it's supposed to, and which it
        reports that it is.
      





      Not unique to 8.1b2, occurs in 8.1b1
  ---
  Only occurs on Windows.  Unix is OK.    
  There are two interesting bugs that appear in this report.  In interactive mode, enter in the following lines:

  BUG #1
  -----------
      pack [canvas .c]
      .c create text 20 10 -text "Default" -tags a
      .c create text 90 10 -text "Stipple Off" -tags b

  Notice that both strings are drawn at even Y-axis.  Now enter:

      .c create text 90 10 -text "Stipple ON" -stipple gray12 -tags b

  The stippled test, although it has the same coords, is drawn with a different Y-axis.
  Now enter:

      eval .c create rectangle [.c bbox b] -fill green

  Notice we did a bbox on the stipppled text.  However we got the coords for the non-stippled text.

  BUG #2
  -----------
  Notice that the stippled text is cropped.  Resize the window and the full text is now displayed.

  03/25/1999 12:06 - surles -


tkt_uuid: 1422430fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 9 Immediate
foundin: obsolete: 8.5a4
resolution: Fixed
title: segfault with grid (col/row)configure "all"
comment:
   # this crashes wish8.5:
   frame .foo
   grid columnconfigure .foo all -weight 1

  It appears to happen when columnconfigure is
  used with index "all" and no window have been
  added yet.


tkt_uuid: 220390ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: Tk C interfaces are inconsistent in their usage of bytes versus characters
comment:
  OriginalBugID: 749 Bug
  Version: 8.1a2
  SubmitDate: '1998-10-21'
  LastModified: '1999-05-20'
  Severity: SER
  Status: Released
  Submitter: stanton
  ChangedBy: hershey
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-03-29'
  FixedInVersion: 8.1b3


  We should be using bytes in most Tk C interfaces and characters at the Tcl level.  However, there is a confusing mixture of models that has caused various bugs.  We need to clean up the code and the docs so the usage is consistent.



  The layout APIs use characters (TextLayout.3), everything else is bytes.
  03/29/1999 20:03 - stanton -


tkt_uuid: 220831ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 7 High
foundin: obsolete: 8.0.4
resolution: None
title: Script crashes Macintosh
comment:
  OriginalBugID: 1444 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-04'
  LastModified: 
  Severity: CRIT
  Status: UnAssn
  Submitter: pat
  OS: Macintosh
  OSVersion: 7.5.1
  Machine: Power PC


  Name:
  Lindsay Marshall

  ReproducibleScript:
  This is using the Macintosh version of tcl/tk. The exact code that causes the failure is this:

      image create photo advert -file [file join $prog(lib) images $program.gif]
      set iw [expr {[image width advert] + 10}]
      set ih [expr {[image height advert] + 10}]

  If you move the extraction of width and height to later in the script there is no problem.

  ObservedBehavior:
  The system crashes and has to be rebooted.

  DesiredBehavior:
  No failure!


tkt_uuid: 1184104fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 54. [console]
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Child Process Wish.exe Refuses to Close STDIO Channels
comment:
  The problem lies in tkConsole/Tk_InitConsoleChannels()
  within ShouldUseConsoleChannel().  When wish.exe is
  started by double-clicking in Windows Explorer, or by
  typing "wish" on the command line, it is detached from
  the calling process' stdio channels.  When
  ShouldUseConsoleChannel() is called, it returns 1,
  bailing out early at handle==INVALID_HANDLE_VALUE, ==0,
  or FILE_TYPE_UNKNOWN.

  However, if the parent process does NOT relinquish
  control of stdio channels, as with using
  CreateProcess() and inheritable pipes assigned to the
  child's stdio, then ShouldUseConsoleChannel() makes it
  all the way to the call to Tcl_GetStdChannel(), which
  increments the refCount.

  By the end of initialization, refCount is at 3.  When
  [close] is called on a given channel, DetachChannel()
  decrements refCount to 2. 
  CheckForStdChannelsBeingClosed() sees a refCount of 2,
  and refuses to set refCount to 0, [incorrectly]
  presuming that a second interp has the stdio channel open.

  The fix is to decrement the refCount immediately if
  Tcl_GetStdChannel() is reached.


tkt_uuid: 2897967fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Duplicate
title: tk_getOpenFile crashes the application
comment:
  I'm running  tcl/tk 8.5.7 compiled by vc 2005 from batch files provided with the sources. When I'm trying to choose the file using tk_getOpenFile from desktop second time the application disappears. It's very similar to this thread: 
  http://www.opensubscriber.com/message/activetcl@listserv.ActiveState.com/1299837.html
  Is there some workaround allows to void this crash ? Or may be alternative file choose dialog ?
  I've tried to catch it with dlls and libs compiled in debug mode, but is throws no any exceptions at the time.
  I found same crash using ml editor  http://wiki.tcl.tk/13593
  Here is the code
  ...
  set vars(filetypes) {
            {{TCL Scripts}   {.tcl .ntcl .n}}
            {{Text Files}    {.txt}}      
            {{All Files}    * }
          }      
  ...
  proc file_open { parent } {
          variable vars               
          set filename [tk_getOpenFile -title "Open File" -filetypes $vars(filetypes)]      
          
          if {$filename != ""} {
              set vars(editor.filename) $filename       
              set fl [open $filename]
              
              set editor $vars(widgets.editor) 
              
              $editor fastdelete 1.0 end            
              $editor fastinsert end [read $fl]
              $editor highlight 1.0 end
              
              close $fl         
              editor_tab_update
          }    
      }

  thanks
  Ilya


tkt_uuid: 789272ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 8
foundin: obsolete: 8.4.4
resolution: Fixed
title: crash when many bitmaps are used (Windows)
comment:
  On Windows-NT, tk 8.3.3, the following snippet crashes
  wish with a NULL pointer dereference:

  set image [image create bitmap -data \
  {
  #define cross_width 14
  #define cross_height 14
  static char cross_bits[] = {
     0x00, 0x00, 0x00, 0x00, 0x06, 0x18, 0x0e, 0x1c,
  0x1c, 0x0e, 0x38, 0x07,
     0xf0, 0x03, 0xe0, 0x01, 0xe0, 0x01, 0xf0, 0x03,
  0x38, 0x07, 0x1c, 0x0e,
     0x0e, 0x1c, 0x06, 0x18};
  }]

  set maxi 200
  set maxj 62

  for {set i 0} {$i < $maxi} {incr i} {
      for {set j 0} {$j < $maxj} {incr j} {
          grid [button .b$i-$j -image $image] -row $i
  -column $j
      }
  }


  The reason is a failure of CreateBitmap() in
  win/tkWinPixmap.c, #68
      newTwdPtr->bitmap.handle = CreateBitmap(width,
  height, planes, depth, NULL);

  which returns NULL (probably out-of-resources).  This
  is not checked by the calling function, and the
  NULL-Pointer is eventually passed on to
  TkWinGetDrawableDC() which dereferences it.

  I haven't checked by running this in 8.4.4, but from
  looking at the code, the error is not caught there
  either.

  Simply returning NULL im ximage.c does not help, since
  the return-Value of XCreateBitmapFromData() is not
  checked either and simply used.


tkt_uuid: 3567786fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 9 Immediate
foundin: obsolete: 8.6b3
resolution: Fixed
title: wm.test segfaults
comment:
  An --enable-aqua build on Snow Leopard
  produces segfaults in the tests
  wm-manage-* and wm-forget-* in wm.test.


tkt_uuid: 2585265fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: None
resolution: Remind
title: bind Text <BackSpace> and selection
comment:
  insert the same position check like in ::tk::TextInsert
  into the two binding:
  bind Text <Delete> {
  and
  bind Text <BackSpace> {

  in unix you can move the insert pointer with a Paste-Operation with the middle mouse button without clearing the selection. This is Good, because you can paste the selection several times. 
  If you then strike the BackSpace-key or Delete-key your selection is deleted even though your insert cursor is at a completely different position.

  change the two bindings in the file lib/tk8.x/text.tcl

  OLD
  ---------------------------
  bind Text <Delete> {
      if {[%W tag nextrange sel 1.0 end] ne ""} {
          %W delete sel.first sel.last
      } else {
          %W delete insert
          %W see insert
      }
  }
  bind Text <BackSpace> {
      if {[%W tag nextrange sel 1.0 end] ne ""} {
          %W delete sel.first sel.last
      } elseif {[%W compare insert != 1.0]} {
          %W delete insert-1c
          %W see insert
      }
  }
  ===================================
  NEW
  ---------------
  bind Text <Delete> {
      if {[%W tag nextrange sel 1.0 end] ne "" \
       && [%W compare insert >= sel.first] \
       && [%W compare insert <= sel.last]} {
  # AMucha 02/10/09
  # delete only if the insert cursor is inside the selection
  %W delete sel.first sel.last
      } else {
  %W delete insert
  %W see insert
      }
  }
  bind Text <BackSpace> {
      if {[%W tag nextrange sel 1.0 end] ne "" \
       && [%W compare insert >= sel.first] \
       && [%W compare insert <= sel.last]} {
  # AMucha 02/10/09
  # delete only if the insert cursor is inside the selection
  %W delete sel.first sel.last
      } elseif {[%W compare insert != 1.0]} {
  %W delete insert-1c
  %W see insert
      }
  }
  ---------------------------
  feel free to remove the comment

  Albrecht Mucha 
  a.mucha<at>NOSPAMmdtec.de


tkt_uuid: 219911ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: Keysyms are not the same on Windows and Linux
comment:
  OriginalBugID: 947 Bug
  Version: 8.0.3
  SubmitDate: '1998-12-14'
  LastModified: '1999-10-21'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1160 870
  OS: Linux
  OSVersion: Also Windows NT 4sp3
  Machine: Other
  ClosedDate: '1999-10-21'


  Name:
  Laurent Duperval

  Extensions:
  Plus patch 3

  ReproducibleScript:
  button .b
  bind .b <KeyPress> {.b configure -text "%K"}
  pack .b -fill x



  ObservedBehavior:
  When running it on WinNT, pressing The right Alt, Shift and Control keys show
  Alt_L, Shift_L and Control_L while on Linux, it says _R. The Windows keys
  appear properly as Win_L and Win_R on WinNT but as Meta_L and Meta_R on Linux;
  this could be an Xserver issue since I don't have the latest and
  greatest on my machine (not sure about version #).  The menu key shows as
  "Menu" on Linux but "App" on WinNT.





  DesiredBehavior:
  I expect the name of all keysyms to be identical on all platforms.


tkt_uuid: 3608074fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
severity: Minor
foundin: None
resolution: Fixed
title: <<Invoke>> binding in lib/ttk/button.tcl
comment:
  In lib/ttk/button.tcl, there are two bindings (which are later copied to TRadiobutton and TCheckbutton as well):

  bind TButton <Key-space>{ ttk::button::activate %W }
  bind TButton <<Invoke>> { ttk::button::activate %W }

  <<Invoke>> is undocumented (it's not on the [event] manpage's list of Pre-Defined Events, or mentioned on the [ttk::button] manpage) - I'm not sure if this is an oversight, or if the binding is only there for backwards compatability or something. But it looks like it should probably either be removed, or should be documented (and the <Key-space> binding changed to [event add <<Invoke>> <Key-space>] so it's used).


tkt_uuid: 220057ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Duplicate
title: double-clicking in tk_get*File dialog generates click in the window underneath
comment:
  OriginalBugID: 4050 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-20'
  LastModified: '2000-01-31'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4107
  OS: Windows NT
  ClosedDate: '2000-01-31'


  Name:
  Jonas Beskow

  ReproducibleScript:
  pack [button .a -text Junk -command {tk_messageBox -message Click} -width 80 -height 20]
  pack [button .b -text Open -command tk_getOpenFile]

  # click open to bring up a file selection dialog. Double-clicking on any file causes the underlying button "Junk" to be invoked

  ObservedBehavior:
  The underlying button recieves a click-event when a file is selected by double-clicking

  DesiredBehavior:
  the underlying button should not be affected by double-clicking in the file selection dialog.


tkt_uuid: 1583055fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: Invalid
title: Conflict between Tcl and Tk rules for building with MSVC
comment:
  I tried to build Tcl and Tk on Windows XP, using
  the makefile.vc makefiles and MSVC 6.0.

  Tcl built fine and almost all tests succeeded.
  However, when I tried building Tk, it complained
  about not finding Release_i386\tcl85.exe.
  (Tcl simply resides in the Release directory)

  When I removed the suffix _i386 building Tk worked fine
  too.


tkt_uuid: 1881923fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: None
title: wm geometry with negative positions wrong
comment:
  Specifying a negative x/y position in "wm geometry" does not behave correctly.

  e.g. "wm geometry . -20-20"

  The correct behavior should be that the right/bottom edges of the window will each be 20 pixels from the bottom right corner of the screen. This is what happens on Windows and X11.

  When I try it on Mac OS X,  the window is mostly offscreen, with just the top left corner peaking out from the bottom right of the screen.


tkt_uuid: 1152809fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 7 High
foundin: None
resolution: Fixed
title: wm stackorder panics
comment:
  The TkWmStackorderToplevel function in unix/tkUnixWm.c
  seems to incorrectly calculate the number of toplevels
  when they are displayed on different displays. This
  results in the message "num matched toplevel windows
  does not equal num children" and then wish aborts.

  Script to reproduce the situation:

  # wish -display :0
  % toplevel .x -screen :1
  .x
  % wm stackorder .
  num matched toplevel windows does not equal num children
  Aborted

  In a conversation on the Tcler's chat Joe English
  remarked the following about this:
  The point where it's panicking looks to me like it's
  not really an error condition at all (let alone a fatal
  one) -- More like "I'm making an assumption about what
  the state of the system should be, and crashing hard if
  that assumption isn't true". But in this case the
  assumption in question (a) doesn't always hold and
  probably (b) doesn't even need to hold for the code to
  work.


tkt_uuid: 2870648fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Accepted
title: Wrong cursor in tk_getOpenFile (Unix)
comment:
  The unix file selection dialog currently uses an 'xterm' cursor in the iconlist field.
  This seems to be wrong. Here's a patch to use a normal arrow cursor instead.


tkt_uuid: 843172ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Wont Fix
title: win scrollbar odd behaviour.
comment:
  Not 100% sure this is a bug, but definitely odd:

  interp create foo

  interp alias foo bar {} bar
  proc bar {args} { interp delete foo ; error blah }

  foo eval {package require Tk}
  foo eval {scrollbar .s ; pack .s -side left}
  foo eval {.s configure -command bar }

  Now try to manipulate the scrollbar... I get not one
  error (which of course I would expect), but lots and
  lots of them.  In fact the 'interp delete foo' doesn't
  manage to delete the interpreter until after the mouse
  has been released.

  blah
      while executing
  "error blah "
      (procedure "bar" line 1)
      invoked from within
  "bar moveto 0"
      (scrollbar command)

  attempt to call eval in deleted interpreter
      while executing
  "bar moveto 0.0909"
      (scrollbar command)

  attempt to call eval in deleted interpreter
      while executing
  "bar moveto 0.1818"
      (scrollbar command)

  attempt to call eval in deleted interpreter
      while executing
  ...etc

  Note: if the above is carried out in the main
  interpreter, with '.s configure -command {destroy . ;
  error foo}', it's mostly ok, except that the scrollbar
  gets drawn, briefly, in the top-left corner of the
  screen (I suppose because '.' disappears, but the
  scrollbar remains and doesn't know where to draw
  itself, and doesn't know it should be dead).


tkt_uuid: 1467997fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 8
foundin: obsolete: 8.4.12
resolution: Fixed
title: [wm iconphoto] issues on Win XP
comment:
  I've received reports of several
  problems with [wm iconphoto] on
  Windows XP.

  It's reported that the displayed
  icons have red and blue colors
  transposed.  Perhaps a disagreement
  in the data format returned by
  Tk_PhotoGetImage() and that needed
  by the GetIcon() and other Windows
  calls?

  When two photo images are passed
  to [wm iconphoto], one 16x16 and
  one 32x32, it seems the 32x32 data
  is always used, and downsampled to
  produce 16x16 display.  It's desired
  to have the 16x16 icon provided used
  instead.

  The [wm iconphoto] docs are missing
  on the core-8-4-branch.


tkt_uuid: 1614362fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: Patch to call Tcl_Panic is button resources are missing
comment:
  This patch invokes Tcl_Panic is button resources
  that Tk expects to find can't be located. This
  should never happen.


tkt_uuid: 483833ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Duplicate
title: event.test event-click-drag-1.2 fails
comment:
  sparc/solaris 2.6/sun c compiler/cde window manager

  latest tk from cvs fails this test suite test:
  event.test

  ==== event-click-drag-1.2  click and drag in an entry
  widget, this
                              tests tkEntryMouseSelect in
  entry.tcl  FAILED
  ==== Contents of test case:

      destroy .t
      set t [toplevel .t]
      set e [entry $t.e]
      pack $e
      tkwait visibility $e
      focus -force $e
      _keypress_string $e "A Tcl/Tk selection test!"
      set anchor 6
      set selend 18

      set result [list [$e get]]

      # Get the x,y coords of the second T in "Tcl/Tk"
      foreach {anchor_x anchor_y} [_text_ind_to_x_y $e
  $anchor] break

      # Click down to set the insert cursor position
      event generate $e <Enter>
      event generate $e <ButtonPress-1> -x $anchor_x -y
  $anchor_y

      # Save the position of the insert cursor
      lappend result [$e index insert]
      
      # Now drag until selend is highlighted, then click
  up

      set current $anchor
      while {$current <= $selend} {
          foreach {current_x current_y} [_text_ind_to_x_y
  $e $current] break
          event generate $e <B1-Motion> -x $current_x -y
  $current_y
          incr current
          _pause 50
      }

      event generate $e <ButtonRelease-1> -x $current_x
  -y $current_y
      _pause 200
      # Save the position of the insert cursor
      lappend result [$e index insert]

      # Save the highlighted text
      lappend result [selection get]

      # Now click and click and drag to the left, over
  "Tcl/Tk selection"

      event generate $e <ButtonPress-1> -x $current_x -y
  $current_y

      while {$current >= ($anchor - 4)} {
          foreach {current_x current_y} [_text_ind_to_x_y
  $e $current] break
          event generate $e <B1-Motion> -x $current_x -y
  $current_y
          incr current -1
          _pause 50
      }

      event generate $e <ButtonRelease-1> -x $current_x
  -y $current_y
      _pause 200

      # Save the position of the insert cursor
      lappend result [$e index insert]

      # Save the highlighted text
      lappend result [selection get]

  ---- Result was:
  {A Tcl/Tk selection test!} 6 18 {Tk selection} 4 {l/Tk
  selection}
  ---- Result should have been:
  {A Tcl/Tk selection test!} 6 18 {Tk selection} 2
  {Tcl/Tk selection}
  ==== event-click-drag-1.2 FAILED


tkt_uuid: 1481503fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: TkAqua first Apple-, event swallowed
comment:
  In my application I define a ::tk::mac::ShowPreferences
  procedure. This procedure is only called on the
  second (and subsequent) presses of the Apple-,
  key combination. I expect that it works for the first
  use of Apple-, also. Note that the corresponding menu
  entry is not flashing, when Apple-, is used for the
  first time.

  Application:
  http://sf.net/projects/ayam

  best regards,
  Randolf,
  -- 
  http://www.ayam3d.org/


tkt_uuid: 220275ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Invalid
title: "-data" option on "image create photo" only takes base64 character strings
comment:
  OriginalBugID: 4129 Bug
  Version: 8.3b2
  SubmitDate: '2000-02-04'
  LastModified: '2000-02-07'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 4125
  OS: Windows NT
  OSVersion: Windows NT V4.0 SP3
  Machine: Gateway Pentium 166Mhz
  ClosedDate: '2000-02-07'


  Name:
  David Burns

  ReproducibleScript:
  The online Help documentation doesn't mention that the 'string' that is supposed to be submitted to the "-data" option in a "image create photo" invocation is a base64 character string (Welch mentions this in his book though).  If you
  submit a binary character string you get "can't recognize data" message.

  I'm presuming that to maintain compatibility with previous incarnations of Tk,
  that another option is to be added (maybe "-binarydata"?) that will allow
  submitting true binary strings to this command.



  This is fixed in 8.3 final.  You can obtain the latest sources from our NetCVS repository, or just want for the release in a few days.  JPEG support is not yet integrated into the core.  The implementation in Img depends on libjpeg, and we don't want to make Tk dependent on external libraries like that (excluding the X libs, obviously, there's not really any way around that).

  We didn't actually have to introduce a new option for the binary data, because it is possible to differentiate between base64 data and binary data by examining the first few bytes of data.  So in 8.3 final, you can do:

  set f [open myfile.gif r]
  fconfigure $f -translation binary -encoding binary
  set data [read $f]
  image create photo -data $data

  This works as expected.

  - eric

  -- 02/07/2000 ericm


tkt_uuid: 2820123fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Canvas item bindings don't always work.
comment:
  If, in a canvas <Motion> handler, you draw within 2 pels of the cursor hot spot, then <Enter> bindings on canvas items don't work. Happens with 8.5, 8.6b1, and possibly earlier. The example below uses the 'none' cursor, but the bug will also occur with any of the stock cursors.

  -cut here ----------------------------------------
  #NB: THIS WORKS, AS IS, EXHIBITING THE DESIRED BEHAVIOUR (rectangle changes colour
  # on enter/leave).
  #TO EXHIBIT THE BUG, CHANGE 0 TO 1 THREE LINES BELOW THIS.
  package require Tk

  set cursor_style 0
  # space at hot point. Works.
  # set cursor_style to 1 for no space, -> doesn't work

  proc main {} {

     pack [canvas .c -bg white]
     set r [.c create rectangle 40 40 240 140  -fill cyan]
     
     .c bind $r <Enter> [list .c itemconfigure $r -fill pink]
     .c bind $r <Leave> [list .c itemconfigure $r -fill cyan]
     
     .c configure -cursor "none"
     set ::cursor_items ""

     bind .c <Enter> {draw_cursor %x %y}
     bind .c <Motion> {draw_cursor %x %y}
     bind .c <Leave> erase_cursor
  }

  proc erase_cursor {} {

     foreach x $::cursor_items {.c delete $x}
  }

  proc draw_cursor {x y} {

     erase_cursor
     set ::cursor_items ""

     if {$::cursor_style == 0} {set d 2} else {set d 0}
     set s 24
  # s sets cursor size, d is central gap size

     set x1 [expr {$x - $s}]
     set x2 [expr {$x + $s}]
     set y1 [expr {$y - $s}]
     set y2 [expr {$y + $s}]

     lappend ::cursor_items [.c create line $x1 $y  [expr {$x - $d}] $y ]
     lappend ::cursor_items [.c create line [expr {$x + $d}] $y $x2 $y ]
     lappend ::cursor_items [.c create line $x  $y1 $x  [expr {$y - $d}]]
     lappend ::cursor_items [.c create line $x  [expr {$y + $d}] $x  $y2]
  }

  main


tkt_uuid: 1818491fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 51. [place]
priority: 9 Immediate
foundin: obsolete: 8.4.16
resolution: Fixed
title: Placer geometry manager crash, and patch
comment:
  When a Tk geometry manager reconfigures its
  slaves, almost anything can happen via event
  bindings, including deleting the manager widget or
  slaves.  The Tk pack and grid managers carefully
  handle this, through a combination of
  Tcl_Preserve/Tcl_Release and an abort flag.  The
  corresponding code is missing from the place
  manager.

  With Tcl/Tk 8.4.15 I was seeing crashes while using
  place in mega-widget construction, in complex
  timing-relating circumstances.  I have since
  produced a (very) contrived simple example, in
  placer.tcl.  Run it with wish.  Using Tcl/Tk
  8.4.15 resizing the main window crashes wish every
  time on my Solaris unix build, and on a Windows-XP
  single-threaded build.  Memory corruption - so
  your mileage may vary for different builds.

  I have applied exactly the same protection method
  as used in grid and pack to the placer.  This
  solve the problem in placer.tcl, and in my real
  application.  The Tcl/Tk 8.4 updated code applied
  to CVS 1.13.2.1 is in tkPlace.c.84.  I have also
  updated the Tcl/Tk 8.5 code from CVS 1.22, in
  tkPlace.c.85.


tkt_uuid: 2182522fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: Ttk combobox fails to restore grab.
comment:
  With the code below, the combobox bindings fail to restore the grab after the user opens up the combobox list and then discards it again by clicking somewhere outside the list. The grab is restored correctly if one of the list items is selected.

  The Quit button on top2 should never be active, but the button will work when clicked after opening and closing the combobox list without making a selection.

  wm withdraw .
  frame .tree1

  toplevel .tree1.top
  ttk::combobox .tree1.top.box -state readonly \
    -values {"Option 1" "Option 2" "Option 3"}
  button .tree1.top.quit -text Quit -command exit

  grid .tree1.top.box -padx 8 -pady 8 -sticky nwe
  grid .tree1.top.quit -padx 8 -pady 8

  toplevel .top2
  button .top2.quit -text Quit -command exit
  grid .top2.quit -padx 8 -pady 8

  grab .tree1

   
  Issue found on SuSE linux 11.0 with tcl/tk 8.5.4


tkt_uuid: 1073456fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: TkAqua: no zoom support
comment:
  The zoom/maximize button on Tk Aqua windows don't do
  anything.  Also, the "wm state $w zoomed" is not
  implemented.

  The attached patch to tkMacOSXWm.c changes
  TkMacOSXZoomToplevel() to call TkpWmSetState to
  zoom/unzoom, and implements "wm state $w zoomed", with
  "wm state $w normal" restoring the pre-zoomed window
  size/location.

  The patch is versus the HEAD (8.5) but it should be
  simple enough to apply manually to earlier versions.


tkt_uuid: 765642ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 74. Application Embedding
priority: 8
foundin: obsolete: 8.4.3
resolution: None
title: [load] Tk needs Tcl's --prefix
comment:
  During a [load <Tk>], the Tk_Init() routine runs.

  In turn, it tries to eval the [tcl_findLibrary] command
  to find the installed tk.tcl file.

  If Tk was installed with TK_PREFIX the same as
  Tcl's TCL_PREFIX, then this will succeed.

  However, if Tk is installed somewhere else, and
  a Tcl interpreter tries to [load] it, there will be an
  error as Tk is unable to find the tk.tcl file.  This means
  that Tk will not work correctly since it did not get
  initialized.

  There are a number of partial solutions possible.

  Tk's configure/build/install could be constrained
  to force TK_PREFIX to be the same as TCL_PREFIX.
  However, that just means the Tk will be [load]able
  in the Tcl installation it was configured against.
  The bug will remain when trying to [load] the same
  Tk shared library in a different Tcl installation.

  As requested in Tcl Feature Request 695441,
  [tcl_findLibrary] could be extended to also search
  directories on the auto_path.  This would workaround
  this bug in the most common case where the [load]
  is wrapped inside the mechanics of [package require],
  and the search for require-able packages is done
  using [tclPkgUnknown] -- the default [package unknown] 
  handler -- which is influenced by the value of ::auto_path.
  This will not fix the bug for direct [load]s though.

  Ultimately, the problem is that Tk_Init() needs a
  better tool/strategy for finding its script library than
  [tcl_findLibrary] is capable of providing.  Since the
  Tcl world now includes virtual file systems, the
  ultimate solution may require embedding Tk's
  script library into the binary library itself as an
  internal file system so that this problem of finding
  and joining two separately installed pieces of Tk
  just goes away.

  Short of that, a revised installation strategy that
  installs the Tk script library under TK_EXEC_PREFIX
  in the same directory as Tk's pkgIndex.tcl file
  would also be a solution.  There would be no need
  for a [tcl_findLibrary] call.  The pkgIndex.tcl file
  would just arrange for

      source [file join $dir tk.tcl]

  to be part of Tk's package loading script.  The cost
  of that solution is that on multi-architecture
  installations,
  each architecture gets its own copy of the Tk script
  library installed -- costing some disk space and
  costing some maintenance effort for those installations
  that make customizations to the script library.


tkt_uuid: 220048ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: final: 8.0.5
resolution: Duplicate
title: scale widget occasionally rounds numbers
comment:
  OriginalBugID: 3689 Bug
  Version: 8.0.5
  SubmitDate: '1999-11-24'
  LastModified: '2000-01-29'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4099
  OS: All
  ClosedDate: '2000-01-29'


  Name:
  john donahue

  ReproducibleScript:
  The scale widget usually doesn't change the value of its variable if its in the allowable range.
  I was counting for a latitude scale, until I picked a spot in South America, where the input value was
  changed. It only does this for negative numbers less than 1 with decimal fractions between .9 and .95

  % scale .s  -to  90 -from -90 -resolution  .1 -variable x
  .s
  % pack .s
  % set x -21.914
  -21.9
  % set x -21.956
  -21.956

  DesiredBehavior:
  Either round all number to the specified resolution, or leave the values as they are. I need consistancy.



  Verified on NT and Sol7 with 8.2.2. 
  -- 11/29/1999 hobbs
  See 4099 for bug that fixed this (for 8.3.0). 
  -- 01/29/2000 hobbs


tkt_uuid: 987107ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.4.8
resolution: Fixed
title: alpha blending cannot transition transparency properly
comment:
  The alpha blending does not transition from partially
  transparent to fully transparent correctly.

  Currently, it creates an undesired "ghosting" effect
  when using images whose transparency changes gradiently
  from partially to fully transparent.

  It appears that the result pixels near the boundary are
  brighter than they should be (perhaps this is a corner
  case?).

  Dawson and I have come up with test images and a
  special test script that fully illustrates the problem
  (and the desired output).


tkt_uuid: 965398ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: Wish console scroll bug (WinXP)
comment:
  I've just started using ActiveTCL 8.5a2 and have noticed 
  what appears to be an odd scrollbar bug in the Wish 
  console under WinXP SP1A.  The following script 
  illustrates the problem:

  console show
  for {set i 0} {$i < 599} {incr $i} {
      puts $i
  }

  Basically, it places 599 lines of "junk" in the console 
  window.  Once the output is in the console window, if I 
  grab the scrollbar thumbnail and drag it up a ways and 
  then back down to the bottom, the application hangs 
  and the data shown in the console "shimmers" (almost as 
  if it's vibrating).  Ultimately, wish has to be killed.

  For whatever reason, in my testing 599 seems to be the 
  magic breaking point.  Anything less and the console is 
  OK, but 599 or greater and it breaks as described above.

  Also, though I can consistently recreate this, it only 
  seems to happen when dragging the thumbnail (not 
  when pressing the arrows or clicking in the gutter).  
  Also, it only happens when the thumbnail is dragged up 
  and then completely back to the bottom.  Until the 
  bottom is reached, all is fine.

  Jeff


tkt_uuid: 1676682fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: new test failures
comment:
  On Solaris 9 /CDE, these
  test failures are new since
  8.5a5. Failures happen
  in both --enable- and --disable-xft
  configurations:


  ==== unixEmbed-10.2 geometry propagation in tkUnixWm.c/UpdateGeometryInfo FAILED
  ==== Contents of test case:

      deleteWindows
      frame .f1 -container 1 -width 200 -height 50
      pack .f1
      toplevel .t1 -use [winfo id .f1] -width 150 -height 80
      update
      wm geometry .t1 70x300+10+20
      update
      wm geometry .t1

  ---- Result was:
  70x250+0+0
  ---- Result should have been (exact matching):
  70x300+0+0
  ==== unixEmbed-10.2 FAILED


tkt_uuid: 220635ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: tk_getOpenFile man incorrectly states "-initialfile ignored by getOpenFile"
comment:
  OriginalBugID: 3882 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-14'
  LastModified: '1999-12-16'
  Severity: LOW
  Status: Released
  Submitter: ericm
  ChangedBy: hobbs
  OS: All
  FixedDate: '1999-12-16'
  FixedInVersion: 8.3b1


  The man page for tk_getOpenFile claims that the -initialfile parameter is ignored for the getOpenFile dialog, but it seems to work on Linux and Windows NT.

  - eric



  corrected, along with updated behavior on Unix. 
  -- 12/16/1999 hobbs


tkt_uuid: 220604ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: 'event generate . <Left>' generates bad %K %A
comment:
  OriginalBugID: 3195 Bug
  Version: 8.2.1
  SubmitDate: '1999-10-26'
  LastModified: '1999-10-30'
  Severity: SER
  Status: Released
  Submitter: hobbs
  ChangedBy: hobbs
  OS: Windows NT
  FixedDate: '1999-10-30'
  FixedInVersion: 8.2.2


  Do:

  bind . <KeyPress> {puts "K:%K k:%k a:%A"}
  pack [button .b -text Event -command {event generate . <Left>}]

  Click on button.  Fails for other sym-type events (Home, Up, ...)
  but works fine on Unix.


  Tk's XKeysymToKeycode was letting VkKeyScan return codes for
  such special sym events that didn't map into the right area.
  This could be due to bad casting, but the fix was to do the
  special key table lookup ahead of time. 
  -- 10/30/1999 hobbs


tkt_uuid: 802445ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Out of Date
title: bogus "image create" command crashes wish
comment:
  Running the following one-liner script crashes wish
  % image create photo .

  Here's a traceback from within gdb:
  #0  0x080de37d in ?? ()
  #1  0x4009a77d in Tk_ImageObjCmd () from
  /usr/lib/libtk8.3.so
  #2  0x4010e5b5 in TclExecuteByteCode () from
  /usr/lib/libtcl8.3.so
  #3  0x400f2233 in Tcl_EvalObjEx () from
  /usr/lib/libtcl8.3.so
  #4  0x401180a5 in Tcl_RecordAndEvalObj () from
  /usr/lib/libtcl8.3.so
  #5  0x40117f82 in Tcl_RecordAndEval () from
  /usr/lib/libtcl8.3.so
  #6  0x40045b54 in Tk_MainEx () from /usr/lib/libtk8.3.so
  #7  0x4011f8b0 in Tcl_NotifyChannel () from
  /usr/lib/libtcl8.3.so
  #8  0x40147fb9 in Tcl_DeleteFileHandler () from
  /usr/lib/libtcl8.3.so
  #9  0x4012b00d in Tcl_ServiceEvent () from
  /usr/lib/libtcl8.3.so
  #10 0x4012b335 in Tcl_DoOneEvent () from
  /usr/lib/libtcl8.3.so
  #11 0x40039f1f in Tk_MainLoop () from /usr/lib/libtk8.3.so
  #12 0x400459b4 in Tk_MainEx () from /usr/lib/libtk8.3.so
  #13 0x08048854 in main ()
  #14 0x42015574 in __libc_start_main () from
  /lib/tls/libc.so.6

  This is probably the cause of this Tkinter bug:
  python.org/sf/802417


tkt_uuid: 1000051fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 9 Immediate
foundin: obsolete: 8.4.7
resolution: Duplicate
title: Compose key doesn't work
comment:
  I just observed, that in some applications (e.g. tkchat
  and tkcon) the Compose key doesn't work under 8.4.7
  while 8.4.6 is OK.

  But when I run a simple test script like
   pack [entry .e]
   pack [text .t]
  under 8.4.7 the Compose key works fine in those widgets.

  I have already searched through the diff between 8.4.6
  and 8.4.7, but all keyboard-related changes seem to be
  for macosx.


tkt_uuid: 468139ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Improved tk_chooseDirectory on Windows
comment:
  The tk_chooseDirectory in the current and past Tk 
  versions on windows uses the built-in windows 3.1 
  style directory browse. This browser has many 
  shortcomings including inability to select network 
  shares via UNC names, returns all names in uppercase 
  and generaly appears klunky and outdated. The attached 
  patch, when applied to the latest Tk 1.21 
  tkWinDialog.c will add the newer windows directory 
  browser. You can still go back to the old version by 
  #defining USE_OLD_CHOOSEDIR. Hopefully, if test goes 
  well the code for the old browser can later be removed.
  Worked based on initial Jeff Hobbs code and modified 
  by Tom Wilkason (tom.wilkason@home.com).


tkt_uuid: 1550890fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Invalid
title: geometry not accepted if resizable set false before visible
comment:
  This worked as expected in 8.4.7 (default release for Mac OS X 10.4.7).

  It fails in 8.4.13, just downloaded from ActiveState.

  If the command

       wm resizable . false false

  is executed before the main window has become visible, and you try to 
  set the geometry with a wm geometry command, it fails;

  Specifically, trying to set the geometry with:

       wm geometry . +[winfo pixels . 5i]+[winfo pixels . 3i]

  leaves the window at the default location.

  If you execute it AFTER the window has become visible (e.g. by typing the 
  commands in to the command prompt one at a time, or sourcing the file 
  after starting up wish), it works as expected.

  A work-around is to set the resizable attribute after the geometry 
  command.

  In the case when it does fail, a tkwait visibility . will make it work correctly 
  (but of course that will wait forever if the main window has already been 
  processed).

  sep@shout.net


tkt_uuid: 946152ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 30. Color Names
priority: 5 Medium
foundin: TIP Implementation
resolution: None
title: TIP 154: Add Named Colors to Tk
comment:
  Attached is the first revision of a patch for TIP 154
  to add named colors to Tk accessible at the Tcl level.

  As it's my first-ever patch, and I'm not the finest C
  programmer in the world, please be kind and
  constructive. 0-]


tkt_uuid: 220903ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: None
title: Provide a 'None' modifier for event bindings
comment:
  OriginalBugID: 4437 RFE
  Version: 8.3
  SubmitDate: '2000-03-21'
  LastModified: '2000-04-07'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All


  Name:
  Jay Schmidgall

  Comments:
  Note that this functionality is backwards compatible. Only if the None
      or ! modifiers are specified does the new behavior occur.

  DesiredBehavior:
  Currently there is no simple way to create a binding on a widget which fires when a key is pressed with no modifiers, but which does not fire if that same key is pressed with a binding. For example,

      bind .button <Key-f> { puts fires }

  will fire when the f key is pressed, but will also fire when Control-f is pressed. One needs to write more code to weed out the cases when a modifier is present.

  If a 'None' modifier was provided, one could specify

      bind .button <None-Key-f> { puts fires }

  and pressing Control-f would not fire.

  A further consideration would be to provide exact match functionality. For example, if one specifies

      bind .button <!Control-Key-f> { puts fires }

  then the bind would fire only when only Control-f was pressed. If any other modifier was present, or a pointer button was depressed at the same time, the binding would not fire.

  In this case, the None modifier is the same as ! with no modifiers specified. That is,

      bind .button <None-Key-f> { puts fires }

  is equivalent to

      bind .button <!Key-f> { puts fires }

  Note this functionality is already present in the X translation table syntax. It would be nice if Tk could be extended to provide analogous behavior.


tkt_uuid: 1233009fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.11
resolution: Out of Date
title: Return and enter the same in callback
comment:
  When using [bind] and giving the callback the keysym substitution 
  (%K) Return and Enter both give a result of Return. This happens 
  at least on OS X but I heard it also happens on Windows.


tkt_uuid: 2811266fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: tk_dialog spacebar invokes focused button not Enter key
comment:
  On Linux, when using the tk_dialog proc to produce a dialog a two button dialog and using only the keyboard for navigation when a highlighted button is invoked using the enter key the default value is always returned. If the space bar is pressed then the correct value for the focused button is returned.  Test Code follows: When dialog is up tab to the Yes button then press Enter. The value 0 is returned rather than 1. Call it up again this time tab to the yes button and press spacebar. 
  Pressing the Enter key should invoke the button that has focus.  The binding needs to be changed. The binding for spacebar can either be removed or remain. 

  ========================== TEST CODE ===================
  #!/bin/sh
   # the next line restarts using wish \
   exec /opt/usr8.6b.1/bin/tclsh8.6  "$0" ${1+"$@"}
  if { [ catch {package require Tk } err ] != 0 } {
      puts stderr "Unable to find package Tk ... adjust your auto_path!";
  }
  proc mkExitDialog { } {
      return  [ tk_dialog .exit  "Quit or Cancel?" \
      "Are you sure you want to quit?" \
      questhead \
      0 \
      "No,Cancel" "Yes" ]
  }
   
  proc cleanup {} {
      set reply [ mkExitDialog  ]
      switch -exact -- $reply {
  1 {
      puts "reply was $reply"
      exit
  } 
  default {
      puts "reply was $reply";
  }
      }
  }
  wm protocol . WM_DELETE_WINDOW cleanup
  wm geometry . 500x500
  button .b -text "Push me or Close the Window" -command cleanup 
  pack .b -padx 10 -pady 10 -ipadx 5 -ipady 5 

  =============================END TEST CODE ================================


tkt_uuid: 997689ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: [wm attributes] patch for Mac OS X
comment:
  This patch fixes up [wm attributes] handling on Mac OS X. 
  Specifically, it updates to use newer APIs (both Tcl and Carbon), 
  implements read for the -titlepath option and correctly implements 
  individual option introspection.


tkt_uuid: 732662ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Under Win*, data copied to clipboard is lost upon app exit
comment:
  Using the Windows operating system, any data copied to 
  the clipboard is lost when the Tk based app is exited.

  With 2 separate Tk apps, data can be copied to the 
  clipboard in App_A and pasted into App_B, as long as 
  both apps are running.  But, if data is copied to the 
  clipboard in App_A and then App_A is closed, the 
  clipboard data is lost and can no longer be pasted.


tkt_uuid: 220418ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Text widget search problem - CharNu has wrong value if characters are not english
comment:
  OriginalBugID: 1056 Bug
  Version: 8.1b1
  SubmitDate: '1999-01-15'
  LastModified: '1999-04-02'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  RelatedBugIDs: 1148  1666
  OS: Solaris
  OSVersion: 5.6
  Machine: Other
  FixedDate: '1999-04-02'
  FixedInVersion: 8.1b3


  Name:
  Petasis George

  Extensions:
  none

  ReproducibleScript:
  encoding system iso8859-7
  set pattern [${win}.entry get]
  set index [$widget search -forwards -regexp -count CharNu --  $pattern 1.0 end]
  puts $CharNu

  ObservedBehavior:
  if you enter in the entry some greek characters, lets say 3 chars, CharNu has the value of 6. If you type 3 english characters in the entry widget, CharNu has the correct value (3).

  DesiredBehavior:
  CharNu having always value 3, if you type 3 characters, no matter which language you use...



  The text widget was returning byte counts instead of character counts.
  04/02/1999 15:49 - stanton -


tkt_uuid: 2782353fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: None
title: add -statevariable option to menus and possibly ttk widgets
comment:
  Many applications change state of menu items and toolbar buttons from normal to disabled and vice versa. Keeping them synchronized is complex. It would be easier to have -statevariable option for menus and ttk widgets, for example
    menu .m
    .m add command -statevariable ::statev0
    ttk::entry .e -statevariable ::statev0
    set ::statev0 disabled
    ... 
    set ::statev0 normal
  Currently this could be implemented using traces and overriding widget commands, but script code becomes very complex.


tkt_uuid: 700308ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: None
title: OS X Aqua: Key binds depend on modifier key press order
comment:
  On my PowerBook G4 laptop, if I press Control, then Fn,
  then Up-arrow (to get Ctrl-PgUp), it correctly triggers
  the Control-Prior bindings.  If I press Fn, then
  Control, then Up-arrow, however, it only triggers the
  bindings for Prior, and not for Control-Prior.  The
  same applies to Ctrl-PgDn, but I've not tried other
  combinations.

  You can reproduce this with the following code:

  entry .e
  pack .e
  bind .e <Key-Prior> ".e delete 0 end ; .e insert end PgUp!"
  bind .e <Control-Key-Prior> ".e delete 0 end ; .e
  insert end Ctrl-PgUp!"


tkt_uuid: 1323972fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4.11
resolution: Fixed
title: wm-grid-1.11,12 failures
comment:
  tests fail on tip of core-8-4-branch:

  ==== wm-grid-1.11 usage FAILED
  ==== Contents of test case:

      list [catch {wm grid . 13 14 -1 16} msg] $msg

  ---- Result was:
  1 {widthInc can't be <= 0}
  ---- Result should have been (exact matching):
  1 {widthInc can't be < 0}
  ==== wm-grid-1.11 FAILED


  ==== wm-grid-1.12 usage FAILED
  ==== Contents of test case:

      list [catch {wm grid . 13 14 15 -1} msg] $msg

  ---- Result was:
  1 {heightInc can't be <= 0}
  ---- Result should have been (exact matching):
  1 {heightInc can't be < 0}
  ==== wm-grid-1.12 FAILED


tkt_uuid: 853643ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: None
title: Index script preference for debug Tk
comment:
  When both debug and non-debug Tk
  are installed, the generated index scripts
  allow either one to successfully [load]
  into tclsh.  Which one you get from a
  [package require Tk] is currently
  quasi-random, depending on the order
  in which [tclPkgUnknown] [source]s
  the pkgIndex.tcl files.

  This patch forces a preference for
  the debug-enabled Tk when Tcl
  is also debug-enabled.  David
  Gravereaux reports he finds this
  combination useful when stepping
  through Tcl/Tk applications.

  When Tcl is not debug-enabled,
  the choice for Tk remains
  quasi-random even after this patch,
  but that seems OK.  Either Tk will
  work, so either satisfies the 
  [package require].

  This patch changes only win/Makefile.
  If it is accepted, similar changes should
  be made to the alternative makefiles.


tkt_uuid: 776545ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 02. Appearance
priority: 9 Immediate
foundin: TIP Implementation
resolution: Accepted
title: TIP 109 implementation
comment:
  Attached are the patches to apply to 8.5 HEAD versions
  of tkUnixButton.c and tkUnixMenu.c.  These changes
  implement TIP 109.

  -Brian


tkt_uuid: 220856ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 6
foundin: obsolete: 8.2b1
resolution: None
title: [winfo containing] doesn't work on non-root E desktops
comment:
  OriginalBugID: 2478 Bug
  Version: 8.2b1
  SubmitDate: '1999-08-02'
  LastModified: '2000-03-07'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: sven
  RelatedBugIDs: 3777  4301
  OS: Linux-Red Hat
  Machine: Other


  Name:
  John Ellson

  Comments:
  raster@raster.com (author of enlightenment) states:
      
      bug in tk - motif has the same bug with dnd. basically they asume eazch
      immediate chil o the root winow has on and onlyone appliation window
      in it - incorrect assumption to make. xwininfo, xprop anjmd others also
      suffer from thsi bad assumption. iccm oes nto forbid being able to
      reparent as many client windwos as the wm likes into another window.
      its badly written apps :) gtk's dnd code does it right :)
      
      so basically the answer is ... fix tk :) (nb - it will have he same
      problem with tvtwm i believe and amiwm - both are also virtal root
      winow wm's)

  ReproducibleScript:
  #!/usr/local/bin/wish
      # file "bug.tcl" illustrating "winfo containing"
      # problem on non-root E desktops (and poss other WMs)
      toplevel .t
      bind .t <B1-Motion> {puts [winfo containing %X %Y]}

  ObservedBehavior:
  Using Enlightenment WM.  "winfo containing" doesn't work on non-root
      desktops.
      
      The test script generates two windows. One labelled "bug" and the other
      labelled "t".   If the mouse-button-1 is held down over "t"
      and then dragged to "bug"  you should see the window name
      reported repeatedly as the mouse is dragged. (I'm trying to implement
      drag&drop between windows.)
      
      If the script is executed on desktop 1 you see ".t" and
      then "" as you enter window "bug"
      This is incorrect.
       
      Somehow the mouse entry into they "bug" window is not detected
      when on desktops other than 0.

  DesiredBehavior:
  If the script is executed on desktop 0 you see ".t"  and
      then "." as the mouse is dragged to window "bug"
      This is correct behavior


tkt_uuid: 220681ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: tk_getSaveFile causes wish app to become unresponsive under win98
comment:
  OriginalBugID: 4190 Bug
  Version: 8.2.3
  SubmitDate: '2000-02-16'
  LastModified: '2000-02-22'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  OSVersion: Windows 98 with update applied
  Machine: winbook xl
  FixedDate: '2000-02-22'
  FixedInVersion: 8.3


  Name: Devin Eyre

  Comments:
  If you encase tk_getSaveFile in a proc, the problem does not occur.

  ReproducibleScript:
  #!/usr/local/bin/wish
  if {[info exists argv0] && [file dir $argv0] != "."} {
     cd [file dir $argv0]
  }
  set pwd [pwd]
  frame .e
  if [file exists [file join $pwd data]] {
     set dir [file join $pwd data]
  } else {
     set dir $pwd
  }
  set file [tk_getSaveFile -initialdir $dir -defaultextension .dat -filetypes {{{Data files} {.dat}} {{Graph files} {.grf}}} -title "Choose a file to save"]
  if {[info exists file]} {
     set f [open $file w]
     foreach indx [array names pft] {
        puts $f "set pft($indx) $pft($indx)"
     }
     close $f
  }
  set now [clock seconds]
  set datetime [clock format $now -format "%m/%d/%Y 7:00%p"]
  entry .e.time -textvariable datetime -width 18
  entry .e.1 -textvariable attempt(1) -width 3
  entry .e.2 -textvariable attempt(2) -width 3
  entry .e.3 -textvariable attempt(3) -width 3 
  button .e.enter -text Enter -command {
  }
  pack .e -side top -fill both
  grid .e.time .e.1 .e.2 .e.3 .e.enter -sticky news
  focus .e.1
  #####end of script##########
  Run by double-clicking on file icon.  (note:  tcl8.2.3 is only version installed on this system)
  If wish is started first, and then the script is sourced, no problem occurs.
  Script runs fine under sparc solaris 2.6

  ObservedBehavior:
  After the tk_getSaveFile is run, widgets do not respond, no cursor is visible anywhere.
  It appears that focus grab isn't released.

  DesiredBehavior:
  The entry cursor should be in .e.1, button should respond to mouse event.



  This has already been fixed in 8.3.0. 
  -- 02/22/2000 hobbs


tkt_uuid: 220753ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: GetStdHandle OS bug on Win2K makes tkConsole.c fail
comment:
  OriginalBugID: 5971 Bug
  Version: 8.4a1
  SubmitDate: '2000-07-05'
  LastModified: '2000-07-18'
  Severity: LOW
  Status: Released
  Submitter: davidg
  ChangedBy: davidg
  OS: Windows 2000
  FixedDate: '2000-07-18'
  FixedInVersion: 8.4a1


  on line 143 of tkConsole.c is this test:

      handle = GetStdHandle(handleId);

      /*
       * Note that we need to check for 0 because Windows will return 0 if this
       * is not a console mode application, even though this is not a valid
       * handle. 
       */

      if ((handle == INVALID_HANDLE_VALUE) || (handle == 0)) {
  return 1;
      }

  GetStdHandle() on Win2K doesn't work as documented and returns what appears to be a valid handle, but isn't.  I found the following test to work more accurately:

       HANDLE StdOut;
       char buff[1];
       DWORD written;

       StdOut = GetStdHandle(STD_OUTPUT_HANDLE);

       if ((StdOut == INVALID_HANDLE_VALUE) || (StdOut == 0) ||
   !WriteFile(StdOut, buff, 0, &written, NULL))
       {
   // stdout not available
       }

  writing zero bytes is basicly the same as touch.



  this needs to be looked at more deeply under the debugger and see how Tcl finds it's standard channels under buggy Win2K and how it may mess-up wish as it's a -subsystem:windows app.

  adopted in 8.4a1.  Just added comments for a possible logic error that wasn't happening, but TclpGetDefaultStdChannel needed a patch. 
  -- 07/18/2000 davidg


tkt_uuid: 1456342fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.4.12
resolution: Fixed
title: slow deletion of whole text widget content/"sliced" deletion
comment:
  When a text widget contains a lot of data (i.e. 350
  lines of 2000 characters, with a total of 250 000
  characters tagged), the deletion of the content of the
  widget text is very slow using the normal command : $w
  delete 1.0 end (say 2-3 Minutes). If the same widget is
  deleted in a "sliced" way :

  set nl [lindex [split [$w index end] .] 0]
  while {$nl <= 30} {
       $w delete 1.0 30.end
       incr nl -30
  }
  $w delete 1.0 end

  takes few Seconds !!!

  This behavior seems not to be normal , and has benn
  reported since Tcl/Tk version 8.3.4.


tkt_uuid: 220555ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Fix for use of global var in entry.tcl
comment:
  OriginalBugID: 2350 Bug
  Version: 8.1.1
  SubmitDate: '1999-07-16'
  LastModified: '1999-08-06'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2370
  OS: Other
  Machine: NA
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  Name:

  Jeffrey Hobbs



  Comments:

  This exists in the 8.0 strain as well.



  ReproducibleScript:

  This is a fix for the bug report from 1bayuk@mindspring.com

      reporting the problem of the use of $data in entry Cut/Copy



  Patch:

  *** entry.tcl~  Thu May 27 13:38:16 1999

  --- entry.tcl   Thu Jul  8 15:24:28 1999

  ***************

  *** 26,31 ****

  --- 26,32 ----

    #                     char, word, or line.

    # x, y -              Last known mouse coordinates for scanning

    #                     and auto-scanning.

  + # data -              Used for Cut and Copy

    #-------------------------------------------------------------------------

    

    #-------------------------------------------------------------------------

  ***************

  *** 32,48 ****

    # The code below creates the default class bindings for entries.

    #-------------------------------------------------------------------------

    bind Entry <<Cut>> {

  !     if {![catch {set data [tkEntryGetSelection %W]}]} {

          clipboard clear -displayof %W

  !       clipboard append -displayof %W $data

          %W delete sel.first sel.last

        }

    }

    bind Entry <<Copy>> {

  !     if {![catch {set data [tkEntryGetSelection %W]}]} {

          clipboard clear -displayof %W

  !       clipboard append -displayof %W $data

        }

    }

    bind Entry <<Paste>> {

        global tcl_platform

  --- 33,51 ----

    # The code below creates the default class bindings for entries.

    #-------------------------------------------------------------------------

    bind Entry <<Cut>> {

  !     if {![catch {tkEntryGetSelection %W} tkPriv(data)]} {

          clipboard clear -displayof %W

  !       clipboard append -displayof %W $tkPriv(data)

          %W delete sel.first sel.last

        }

  +     unset tkPriv(data)

    }

    bind Entry <<Copy>> {

  !     if {![catch {tkEntryGetSelection %W} tkPriv(data)]} {

          clipboard clear -displayof %W

  !       clipboard append -displayof %W $tkPriv(data)

        }

  +     unset tkPriv(data)

    }

    bind Entry <<Paste>> {

        global tcl_platform



  PatchFiles:

  entry.tcl





  Applied for the 8.2b3 release. 
  -- 08/06/1999 hobbs


tkt_uuid: 712588ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 9 Immediate
foundin: obsolete: 8.4.2
resolution: Fixed
title: Missing -compound docs
comment:
  The checkbutton and radiobutton both accept the
  -compound option, but neither documents it on its
  manual page.  (Is the -compound option a candidate for
  moving to the options(n) manual page or is it policy to
  not use that page anyway?)


tkt_uuid: 219978ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 7 High
foundin: obsolete: 8.0p2
resolution: Works For Me
title: menu bugs in tk when deleting items
comment:
  OriginalBugID: 1960 Bug
  Version: 8.0p2
  SubmitDate: '1999-04-29'
  LastModified: '2000-07-27'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  RelatedBugIDs: 5275
  OS: Windows NT
  OSVersion: WinNT4sp2, Win95, SUN Solaris 2.5.1
  Machine: X86
  FixedDate: '2000-07-27'


  Name: Pascal BOUVIER

  ReproducibleScript:
  source the following on Win95/NT4 INTEL or SUN sparc Solaris 2.5.1

  toplevel .s
  menubutton .s.mb -text Fenetres -menu .s.mb.m
  pack .s.mb
  menu .s.mb.m

  for {set i 1} {$i < 7} {incr i} {
  .s.mb.m add command -label "a-$i" -command "puts ok__$i" 
  }
  .s.mb.m delete 3

  ObservedBehavior:
  BUG 1:
      On Windows (the following works correctly on sun):
      If you move the mouse over items, only a-1, a-2 and a-6 are highlighted
      (change their apearance). Items a-4 and a-5 don't.
      Clicking on "a-4" launchs the bad command (it prints ok__5)
      Clicking the last item of the menu is ok.
      
      BUG 2: (after having performed the previous sequence)
      Now detach the menu (on both SUN and Windows) and do:
      .s.mb.m delete 2
      
      On the torn off menu:
      click on "a-1" prints ok__1
      click on "a-4" jumps to and highlights the last item and prints ok__6
      (bad)
      click on "a-5" does nothing (bad)
      click on "a-6" does nothing (bad)
      
      Using a fresh torn off menu (created after deleting menu items) makes
      things work correctly.

  DesiredBehavior:
  Moving the mouse on any surviving menu item should make the item change
      its appearance .
      Clicking any surviving menu item should launch its associated command
      (not an other one or nothing).

  This bug is a duplicate of bug #5275, which has been fixed for Tcl/Tk 8.4a2. I'm sorry it took so long to notify you.  Thanks for reporting the bug.

     Eric Melski                            The Other Tcl Guy
     ericm at ajubasolutions.com            Ajuba Solutions

  -- 07/27/2000 ericm


tkt_uuid: 220333ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.4a2
resolution: Fixed
title: linking to tk84.lib fails
comment:
  OriginalBugID: 5849 Bug
  Version: 8.4a1
  SubmitDate: '2000-06-07'
  LastModified: '2000-07-28'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: shawn
  RelatedBugIDs: 6062
  OS: Windows 95
  FixedDate: '2000-07-28'
  ClosedDate: '2000-07-28'


  Name:
  Don Porter

  Comments:
  The disk is not full.

      cl == Microsoft(R) 32-Bit Optimizing Compiler Version 11.00.7022 for
      80x86

      The same sequence of operation succeeds with Tcl/Tk 8.3.1.

  ReproducibleScript:
  /* FILE: test.c
   */
  #include <tcl.h>
  #include <tk.h>

  int 
  Tcl_AppInit(Tcl_Interp *interp)
  {
      if (Tcl_Init(interp) != TCL_OK) {
          return TCL_ERROR;
      }
      if (Tk_Init(interp) != TCL_OK) {
          return TCL_ERROR;
      }
      Tcl_StaticPackage(interp, "Tk", Tk_Init, Tk_SafeInit);

      return TCL_OK;
  }

  int main(int argc, char **argv)
  {
    // Turn over control to the Tk library.
    Tk_Main(argc, argv, Tcl_AppInit);

    // Make picky compilers happy.
    return 0;
  }

  ObservedBehavior:
  C:> cl /nologo /c /IC:/PROGRA~1/TCL/include /Fotest.obj test.c
  test.c

  C:> link /nologo test.obj C:/PROGRA~1/TCL/lib/tk84.lib C:/PROGRA~1/TCL/lib/tcl84.lib /OUT:test.exe
  C:/PROGRA~1/TCL/lib/tk84.lib: fatal error LNK1106: invalid file or disk full: cannot seek to 0x393f800d

  DesiredBehavior:
  I should be able to statically link
  my C apps to tk84.lib.



  Dave Gravereaux suggests that this is because the distribution was built with VC 6.0, which produces library files that are incompatible with VC 5.0.
  We should either use VC 5.0 to build our distribution, or specify "/compat50lib" on the link line, so that the binaries produced are VC 5.0 compatible.

  - eric

  -- 06/19/2000 ericm

  Is a duplicate of 6062  
  -- 07/28/2000 shawn


tkt_uuid: 923174ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 4
foundin: obsolete: 8.3.4
resolution: None
title: Can't catch loss of X server displaying slave toplevel
comment:
  If a Tcl app on one host is displaying a slave toplevel
  on another host, and the remote host logs out (thus
  yanking the X server out from under the window), then
  the Tcl app dies with XIO error 131 (Connection reset
  by peer).  Any WM_DELETE_WINDOW protocol or <Configure>
  binding on the window does not fire.  There does not
  seem to be any way in Tcl to catch and handle this
  event.  I happened to be using ActiveTcl 8.3.4.1, but I
  think it's an intrinisic Xlib problem that would affect
  any version.

  This was discussed on c.l.t and in the Tcl chatroom.


tkt_uuid: 222477ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
resolution: Duplicate
title: XIM is not working on RedHat Linux 7J
comment:
  XIM is not working at all on RedHat Linux 7 Japanese Edition with
  tk useinputmethods 1

  I will submit patches to improve XIM on 8.4a2. Thanks.

  Keiichi Takahashi


tkt_uuid: 220301ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: PHOTO images (GIF) load very slowly into widgets
comment:
  OriginalBugID: 5443 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-11'
  LastModified: '2000-05-18'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  OSVersion: 4.2.1
  Machine: RS/6000 Model R50  (200 Mhz x 8 cpu, 2 Gig memory)
  ClosedDate: '2000-05-18'


  Name: Bernie Ott

  Comments:
  Everything else in TCL and TK works great.

  ReproducibleScript:
  Loading a photo image (PPM or GIF) into a button or label widget takes a long time.
  A 640x480 256 color GIF image takes approximately 1.5 minutes to load.

  ObservedBehavior:
  Loading a photo image (PPM or GIF) into a button or label widget takes a long time.
  A 640x480 256 color GIF image takes approximately 1.5 minutes to load.

  DesiredBehavior:
  Loading of a photo image of size 640x480 should only take 1 or 2 seconds.



  I'm unable to reproduce such a slowdown here on AIX or other
  machines.  It's possible that the lack of -O by default for
  the Tk compile really slows things down.  You can actually
  use -O2, but -O reveals a bug in IBM's compiler. 
  -- 05/18/2000 hobbs


tkt_uuid: 2479603fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: None
title: listbox aim is off after window gets moved. Mac OSX 10.3.9
comment:
  I'm using 8.5.6 on Mac OSX 10.3.9 on an old iMac G3. I have an app with a listbox, and I've noticed that the listbox reports (and highlights) the wrong entry after I have moved the app window. Initially, if I have not moved the window, the aim is correct, but afterwards the wrong entry is highlighted and reported. It looks as if there is a mapping between screen coordinates relative to the origin of the app window and absolute coordinates, and that mapping gets lost when the window is moved. I have a small test of this which I'm attaching.

  Uwe Hollerbach


tkt_uuid: 220194ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: Menus pop down in Windows
comment:
  OriginalBugID: 2112 Bug
  Version: 8.0.5
  SubmitDate: '1999-05-20'
  LastModified: '2000-02-25'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  ClosedDate: '2000-02-25'


  Name:
  Greg Orchard

  ReproducibleScript:
  To recreate this problem, start the [incr Widgets] demo and open the
      HTML help example (hyperhelp). Then click on a menu item on the inactive
      window.

  ObservedBehavior:
  If one Tk window is the active window and you click on a menu item of an
      inactive window, the menu item pops up but pops back down when you
      release the mouse button. The original active window becomes the active
      window.

  DesiredBehavior:
  The behaviour you get when a non-Tk window is active and you click on a
      menu item of a Tk window is for the Tk window to become active and for
      the menu to stay popped up. This is the desirable behaviour between Tk
      windows.



  This behavior is not reproducable with 8.2 (perhaps fixed?), based
  on the description. 
  -- 02/25/2000 hobbs


tkt_uuid: 3305175fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Duplicate
title: tk_popup incorrectly placement on Windows
comment:
  I have encountered an issue propably similar to closed bug 2548722.

  <Code>
  pack [ttk::menubutton .t -text abc -direction right]
  menu .t.s -tearoff 0
  for {set m 0} {$m < 20} {incr m} {
  .t.s add command -label m$m
  }
  .t configure -menu .t.s
  </Code>
  Environment:
  Wish 8.5.9 on Windows Vista with screen size: 1600x1024
  Reproduce:
  When I place the wish window at the lower border of the screen and press the button, the menu appears in the center of the screen (in y axis) far away from the menubutton.

  When I trace the called functions and do it manually, I get the same effect.
  % ttk::menubutton::PostPosition
  95 1005
  % tk_popup .t.s 95 1005

  So, there seams to be an issue of the "post menu above anchor point".

  Thank you,
  Harald


tkt_uuid: 1252259fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 8
foundin: obsolete: 8.4.10
resolution: Fixed
title: console erases puts output
comment:
  if you run "wish.exe test.tcl" where test.tcl contains

  console show
  puts "hello, world!"

  there's no output from the puts command

  This commit:
  http://cvs.sourceforge.net/viewcvs.py/tktoolkit/tk/library/c
  onsole.tcl?r1=1.26&r2=1.27

  causes the problem, I think.

  The behavior is the same for wish-8.4.11 and cvs head.

  changing to:
  after idle [list $con delete "output - 2 char" output]

  is an improvement but it still eats a newline character.

  Goodwin


tkt_uuid: 1456157fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a4
resolution: Fixed
title: new [text] test failures
comment:
  several tests in the Tk
  test suite have just started
  failing on unix/X11:

  ==== event-7.1(double-click) A double click on a lone
  character
          in a text widget should select that character
  FAILED
  ==== Contents of test case:
  ...
  ---- Result was:
  1.3 A 1.5 letter
  ---- Result should have been (exact matching):
  1.3 A 1.3 A
  ==== event-7.1(double-click) FAILED

  ==== textTag-15.1 TkTextBindProc FAILED
  ==== Contents of test case:

      bind .t <ButtonRelease> {lappend x up}
      .t tag bind x <ButtonRelease> {lappend x x-up}
      .t tag bind y <ButtonRelease> {lappend x y-up}
      set x {}
      .t tag add x 2.0 2.4
      .t tag add y 4.3
      event gen .t <Button> -x $x1 -y $y1
      event gen .t <Motion> -x $x1 -y $y1
      event gen .t <ButtonRelease> -x $x1 -y $y1
      event gen .t <Button> -x $x1 -y $y1
      event gen .t <Motion> -x $x2 -y $y2
      event gen .t <ButtonRelease> -x $x2 -y $y2
      event gen .t <Button> -x $x2 -y $y2
      event gen .t <Motion> -x $x3 -y $y3
      event gen .t <ButtonRelease> -x $x3 -y $y3
      bind .t <ButtonRelease> {}
      set x

  ---- Result was:
  x-up up up up
  ---- Result should have been (exact matching):
  x-up up up y-up up
  ==== textTag-15.1 FAILED


  ==== textTag-15.2 TkTextBindProc FAILED
  ==== Contents of test case:

      catch {.t tag delete x}
      catch {.t tag delete y}
      .t tag bind x <Enter> {lappend x x-enter}
      .t tag bind x <ButtonPress> {lappend x x-down}
      .t tag bind x <ButtonRelease> {lappend x x-up}
      .t tag bind x <Leave> {lappend x x-leave}
      .t tag bind y <Enter> {lappend x y-enter}
      .t tag bind y <ButtonPress> {lappend x y-down}
      .t tag bind y <ButtonRelease> {lappend x y-up}
      .t tag bind y <Leave> {lappend x y-leave}
      event gen .t <Motion> -x 0 -y 0
      set x {}
      .t tag add x 2.0 2.4
      .t tag add y 4.3
      event gen .t <Motion> -x $x1 -y $y1
      lappend x |
      event gen .t <Button> -x $x1 -y $y1
      lappend x |
      event gen .t <Motion> -x $x3 -y $y3 -state 0x100
      lappend x |
      event gen .t <ButtonRelease> -x $x3 -y $y3
      set x

  ---- Result was:
  x-enter | x-down | | x-up x-leave
  ---- Result should have been (exact matching):
  x-enter | x-down | | x-up x-leave y-enter
  ==== textTag-15.2 FAILED


  ==== textTag-15.3 TkTextBindProc FAILED
  ==== Contents of test case:

      catch {.t tag delete x}
      catch {.t tag delete y}
      .t tag bind x <Enter> {lappend x x-enter}
      .t tag bind x <Any-ButtonPress-1> {lappend x x-down}
      .t tag bind x <Any-ButtonRelease-1> {lappend x x-up}
      .t tag bind x <Leave> {lappend x x-leave}
      .t tag bind y <Enter> {lappend x y-enter}
      .t tag bind y <Any-ButtonPress-1> {lappend x y-down}
      .t tag bind y <Any-ButtonRelease-1> {lappend x y-up}
      .t tag bind y <Leave> {lappend x y-leave}
      event gen .t <Motion> -x 0 -y 0
      set x {}
      .t tag add x 2.0 2.4
      .t tag add y 4.3
      event gen .t <Motion> -x $x1 -y $y1
      lappend x |
      event gen .t <Button-1> -x $x1 -y $y1
      lappend x |
      event gen .t <Button-2> -x $x1 -y $y1 -state 0x100
      lappend x |
      event gen .t <Motion> -x $x3 -y $y3  -state 0x300
      lappend x |
      event gen .t <ButtonRelease-1> -x $x3 -y $y3 -state
  0x300
      lappend x |
      event gen .t <ButtonRelease-2> -x $x3 -y $y3 -state
  0x200
      set x

  ---- Result was:
  x-enter | x-down | | | x-up | x-leave
  ---- Result should have been (exact matching):
  x-enter | x-down | | | x-up | x-leave y-enter
  ==== textTag-15.3 FAILED


  ==== textTag-16.1 TkTextPickCurrent procedure FAILED
  ==== Contents of test case:

      event gen .t <ButtonRelease-1> -state 0x100 -x $x1
  -y $y1
      set x [.t index current]
      event gen .t <Motion> -x $x2 -y $y2
      lappend x [.t index current]
      event gen .t <Button-1> -x $x2 -y $y2
      lappend x [.t index current]
      event gen .t <Motion> -x $x3 -y $y3 -state 0x100
      lappend x [.t index current]
      event gen .t <Button-3> -state 0x100 -x $x3 -y $y3
      lappend x [.t index current]
      event gen .t <ButtonRelease-3> -state 0x300 -x $x3
  -y $y3
      lappend x [.t index current]
      event gen .t <ButtonRelease-1> -state 0x100 -x $x3
  -y $y3
      lappend x [.t index current]

  ---- Result was:
  2.1 3.3 3.3 3.3 3.3 3.3 4.4
  ---- Result should have been (exact matching):
  2.1 3.2 3.2 3.2 3.2 3.2 4.3
  ==== textTag-16.1 FAILED


  ==== textTag-16.2 TkTextPickCurrent procedure FAILED
  ==== Contents of test case:

      event gen .t <ButtonRelease-1> -state 0x100 -x $x1
  -y $y1
      event gen .t <Motion> -x $x2 -y $y2
      set x [.t index current]
      .t tag add big 3.0
      update
      lappend x [.t index current]

  ---- Result was:
  3.3 3.2
  ---- Result should have been (exact matching):
  3.2 3.1
  ==== textTag-16.2 FAILED


  ==== textTag-16.3 TkTextPickCurrent procedure FAILED
  ==== Contents of test case:

      foreach i {a b c d} {
          .t tag remove $i 1.0 end
      }
      .t tag lower b
      .t tag lower a
      set x {}
      event gen .t <Motion> -x $x1 -y $y1
      .t tag add a 2.1 3.3
      .t tag add b 2.1
      .t tag add c 3.2
      update
      lappend x |
      event gen .t <Motion> -x $x2 -y $y2
      lappend x |
      event gen .t <Motion> -x $x3 -y $y3
      set x

  ---- Result was:
  enter-a enter-b | leave-a leave-b |
  ---- Result should have been (exact matching):
  enter-a enter-b | leave-b enter-c | leave-a leave-c
  ==== textTag-16.3 FAILED


  ==== textTag-16.4 TkTextPickCurrent procedure FAILED
  ==== Contents of test case:

      foreach i {a b c d} {
          .t tag remove $i 1.0 end
      }
      .t tag lower b
      .t tag lower a
      set x {}
      event gen .t <Motion> -x $x1 -y $y1
      .t tag add a 2.1 3.3
      .t tag add b 2.1
      .t tag add c 2.1
      update
      lappend x |
      .t tag lower c
      event gen .t <Motion> -x $x2 -y $y2
      set x

  ---- Result was:
  enter-a enter-b enter-c | leave-c leave-a leave-b
  ---- Result should have been (exact matching):
  enter-a enter-b enter-c | leave-c leave-b
  ==== textTag-16.4 FAILED


  ==== textTag-16.5 TkTextPickCurrent procedure FAILED
  ==== Contents of test case:

      foreach i {a b c d} {
          .t tag remove $i 1.0 end
      }
      event gen .t <Motion> -x $x1 -y $y1
      .t tag bind a <Enter> {.t tag add big 3.0 3.2}
      .t tag add a 3.2
      event gen .t <Motion> -x $x2 -y $y2
      .t index current

  ---- Result was:
  3.3
  ---- Result should have been (exact matching):
  3.2
  ==== textTag-16.5 FAILED


  ==== textTag-16.6 TkTextPickCurrent procedure FAILED
  ==== Contents of test case:

      foreach i {a b c d} {
          .t tag remove $i 1.0 end
      }
      event gen .t <Motion> -x $x1 -y $y1
      .t tag bind a <Enter> {.t tag add big 3.0 3.2}
      .t tag add a 3.2
      event gen .t <Motion> -x $x2 -y $y2
      update
      .t index current

  ---- Result was:
  3.3
  ---- Result should have been (exact matching):
  3.1
  ==== textTag-16.6 FAILED


  ==== textTag-16.7 TkTextPickCurrent procedure FAILED
  ==== Contents of test case:

      foreach i {a b c d} {
          .t tag remove $i 1.0 end
      }
      event gen .t <Motion> -x $x1 -y $y1
      .t tag bind a <Leave> {.t tag add big 3.0 3.2}
      .t tag add a 2.1
      event gen .t <Motion> -x $x2 -y $y2
      .t index current

  ---- Result was:
  3.3
  ---- Result should have been (exact matching):
  3.1
  ==== textTag-16.7 FAILED

  Might also be related to 1325998


tkt_uuid: 1567927fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 8
foundin: obsolete: 8.4.13
resolution: Works For Me
title: tk 8.4.13 "make test" fails in MinGW/MSys
comment:
  Hi everyone,

  testing tk 8.4.13 (after building) fails.
  The following describes the environment I'm using:

  * Started with: German Win2kSP4 (never touched by MinGW
  & Co before)
  * Execute MinGW-5.0.3.exe, which installs previously
    downloaded files to "C:\MinGW":
      * binutils-2.15.91-20040904-1.tar.gz
      * gcc-ada-3.4.2-20040916-1.tar.gz
      * gcc-core-3.4.2-20040916-1.tar.gz
      * gcc-g++-3.4.2-20040916-1.tar.gz
      * gcc-g77-3.4.2-20040916-1.tar.gz
      * gcc-java-3.4.2-20040916-1.tar.gz
      * gcc-objc-3.4.2-20040916-1.tar.gz
      * mingw32-make-3.80.0-3.tar.gz
      * mingw-runtime-3.10.tar.gz
      * w32api-3.7.tar.gz
  * Execute MSys-1.0.10.exe, which installs itself into
    "C:\msys\1.0". After that "post install":
      * "Do you have MinGW installed?" -> "y"
      * "Where is your MinGW installation?" -> "C:/MinGW"
      * "You do not have C:/MinGW/bin/make.exe.
         Keep it that way."
  * Start MSYS

  Here are the commands used to build tcl and tk:

  $ tar xzvf tcl8.4.13-src.tar.gz
  $ tar xzvf tk8.4.13-src.tar.gz
  $ cd tcl8.4.13/win/
  $ ./configure  --prefix=/mingw
  $ make
  $ make install
  $ make test
  $ cd ../../tk8.4.13/win/
  $ ./configure  --prefix=/mingw
  $ make
  $ make install
  $ make test

  This gives the following output (accompanied by some
  windows appearing and disappearing):

  ->->->->->->->->->->->->->->->->->->->->
  Tests running in interp: 
  C:/msys/1.0/home/Administrator/tk8.4.13/win/tktest.exe
  Tests located in: 
  C:/msys/1.0/home/Administrator/tk8.4.13/tests
  Tests running in: 
  C:/msys/1.0/home/Administrator/tk8.4.13/win
  Temporary files stored in
  C:/msys/1.0/home/Administrator/tk8.4.13/win
  Test files sourced into current interpreter
  Running tests that match:  *
  Skipping test files that match:  l.*.test
  Only running test files that match:  *.test
  Tests began at Fri Sep 29 19:48:46 Westeuropäische
  Normalzeit 2006
  bell.test
  Bell should ring now ...
  bgerror.test
  bind.test
  bitmap.test
  border.test
  button.test
  canvImg.test
  canvPs.test
  canvRect.test
  canvText.test
  canvWind.test
  canvas.test
  choosedir.test
  clipboard.test
  clrpick.test
  cmds.test
  color.test
  config.test
  cursor.test
  dialog.test
  embed.test
  entry.test
  event.test
  filebox.test
  focus.test
  focusTcl.test
  font.test
  frame.test
  geometry.test
  get.test
  grab.test
  grid.test
  id.test
  image.test
  imgBmap.test
  imgPPM.test
  imgPhoto.test
  listbox.test
  macEmbed.test
  macFont.test
  macMenu.test
  macWinMenu.test
  macscrollbar.test
  main.test
  menu.test
  menuDraw.test
  menubut.test
  message.test
  msgbox.test
  obj.test
  oldpack.test
  option.test
  pack.test
  panedwindow.test
  place.test
  raise.test
  safe.test
  scale.test
  scrollbar.test
  select.test
  send.test
  spinbox.test
  text.test
  textBTree.test
  textDisp.test
  textImage.test
  textIndex.test
  textMark.test
  textTag.test
  textWind.test

  ==== textWind-13.2 EmbWinBboxProc procedure FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 5 -height 5 -bg $color
      .t window create 1.2 -window .f -align center -padx
  2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

  ---- Result was:
  5x5+21+10 {21 10 5 5}
  ---- Result should have been (exact matching):
  5x5+21+9 {21 9 5 5}
  ==== textWind-13.2 FAILED


  ==== textWind-13.9 EmbWinBboxProc procedure, spacing
  options FAILED
  ==== Contents of test case:

      .t configure -spacing1 5 -spacing3 2
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 5 -height 5 -bg $color
      .t window create 1.2 -window .f -align center -padx
  2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

  ---- Result was:
  5x5+21+15 {21 15 5 5}
  ---- Result should have been (exact matching):
  5x5+21+14 {21 14 5 5}
  ==== textWind-13.9 FAILED

  tk.test
  unixButton.test
  unixEmbed.test
  unixFont.test
  unixMenu.test
  unixSelect.test
  unixWm.test
  util.test
  visual.test
  visual_bb.test
  winButton.test
  winClipboard.test
  winDialog.test

  ==== winDialog-3.1 Tk_GetOpenFileObjCmd FAILED
  ==== Contents of test case:

      start {tk_getOpenFile}
      then {
          set x [GetText 2]
          Click 2
      }
      set x

  ---- Result was:
  Abbrechen
  ---- Result should have been (exact matching):
  Cancel
  ==== winDialog-3.1 FAILED


  ==== winDialog-4.1 Tk_GetSaveFileObjCmd FAILED
  ==== Contents of test case:

      start {tk_getSaveFile}
      then {
          set x [GetText 2]
          Click 2
      }
      set x

  ---- Result was:
  Abbrechen
  ---- Result should have been (exact matching):
  Cancel
  ==== winDialog-4.1 FAILED
  <-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-

  Here the test halts! There is also a window named
  "Visual Tests for TK" visible in the background, and an
  "Open" window (with a file list and everything else
  belonging to open windows) in the foreground which is
  waiting for user interaction. I closed both windows,
  but nothing happened. I pressed Ctrl-C, so he told me
  "make: *** [test] Interrupt" and I ended up at the MSYS
  prompt.

  I hope I help you with this!

  Wolfgang
  Wolfgang0815  .at.  gmx  .dot.  de


tkt_uuid: 2687966fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 9 Immediate
foundin: obsolete: 8.5.6
resolution: None
title: wish8.5 hangs up in tkcvs and nVidia driver. wish8.4 working
comment:
  Reproduction
  ==============================================
  While working with tkcvs (8.1-1) that runs wish8.5, wish8.5 hangs up while on non-free nVidia driver.
  Just open tkcvs, move mouse to browser window and point any file. It hangs up immidiatelly.

  IMPORTANT: wish8.4 works perfectly with above tkcvs.

  wish8.5 works correctly with above tkcvs while on nv (nvidia open xorg drivers).

  Attachements:
  =================
  1. strace_wish8.4_ok.txt: strace tkcvs good case 
  2. strace_wish8.5_failed.txt: strace tkcvs bad case

  Configuration
  ================
  Linux ryx 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux

  Graphics: nVidia Corporation NV17 [GeForce4 420 Go] (rev a3)


tkt_uuid: 1035348fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: loadable TkAqua
comment:
  patches to core-8-4-branch and HEAD that enable [package 
  require Tk] for TkAqua:

  All platform specific code from tkMacOSXAppInit.c is moved to 
  tkMacOSXInit.c and tkMacOSXAppInit.c is removed and replaced by 
  the generic unix/tkAppInit.c.

  Almost all such startup code was interp specific and is moved into 
  the existing initialization code in TkpInit(). The only pre-interp-
  initialization we need to do is setting up the Resources/Scripts/
  AppMain.tcl startup file (if present), this code is moved to a new 
  TkMacOSXDefaultStartupScript() which is called from Tk_Main() 
  (the only change to generic code).

  The main project change is addition of a pkgIndex.tcl script in 
  Tk.framework/Resources/Scripts, which enables [package require 
  Tk]. 

  I've also added code to TkpInit() that checks if we are loaded into a 
  bundled executable; and if not, attempts to dynamically acquire the 
  undocumented CPSEnableForegroundOperation SPI and use it to 
  notify the window server that we are now a full GUI application (this 
  will not break if that SPI ever disappears or changes its name).
  Even though we've previously discussed and rejected using CPS SPI, 
  I've lost my scruples on this after talking to the LaunchServices 
  engineers at WWDC (who said to go ahead and use the same 
  workaround that JAR launcher, SDL, wxPython etc all already use, 
  it's not likely to go away at this point and an official solution is not 
  in the pipeline). Just google for CPSEnableForegroundOperation to 
  see how widespread use of this SPI is... In any case, this code can 
  be disabled via #define if desired.
  Of course it's still much preferred to use a bundled executable, as 
  you cannot get a dock icon, document bindings, a bundle id, etc 
  otherwise, also the aete resource for Wish is not available to an 
  unbundled executable (i.e. app cannot be targeted via AppleScript)

  With all this, [package require Tk] now works from tclsh wrapped as 
  a bundled executable, and also unbundled if the above code is 
  enabled.

  In particular, this also allows the Tcl::Tk perl module to properly 
  load TkAqua:
  http://search.cpan.org/~vkon/Tcl/
  http://search.cpan.org/~vkon/Tcl-Tk/
  get release 0.84 which has my patches to build the Tcl module 
  against Tcl.framework, and configure the Tcl module with
  perl Makefile.PL --tclconfig /Library/Frameworks/
  Tcl.framework/tclConfig.sh --usestubs INSTALLSITEMAN3DIR=/usr/
  local/man/man3
  and the Tcl::Tk module with
  perl Makefile.PL INSTALLSITEMAN3DIR=/usr/local/man/man3
  both modules should pass all their 'make test's...

  Jim, could you review this for checkin?


tkt_uuid: 220684ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Segmentation fault in Tk_CanvasEventuallyRedraw
comment:
  OriginalBugID: 4202 Bug
  Version: 8.3
  SubmitDate: '2000-02-18'
  LastModified: '2000-04-13'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Linux-Red Hat
  OSVersion: Linux mitw.chipworks.com 2.2.5-15 #1 Mon Apr 19 23:00:46 EDT 199
  Machine: Intel PC clone
  FixedDate: '2000-04-13'
  FixedInVersion: 8.3.1


  Name:

  David F. Skoll


  Extensions:

  None


  CustomShell:

  Added new image type and canvas item type.


  ReproducibleScript:

  I am unable to show you how to reproduce the problem.  We have a 100 000-line proprietary C++ program with our own Image type, which worked fine with all versions of Tcl/Tk from 8.0 to 8.2.2.  However, we are sometimes getting crashes with 8.3.0.  It seems that when we destroy a canvas and an image in the canvas in the wrong order, Tk_CanvasEventuallyRedraw gets called with a null "tkwin" member in Canvas.  The enclosed patch fixes it.  I'm sorry that I'm unable to give your more data on what causes the problem -- it's very frustrating for you, I'm sure.


  Patch:

  *** tk8.3.0/generic/tkCanvas.c  Wed Jan 12 06:45:02 2000

  --- tk8.3.0-modified/generic/tkCanvas.c Fri Feb 18 12:03:29 2000

  ***************

  *** 2566,2571 ****

  --- 2566,2574 ----

                                   * Pixels on edge are not redrawn. */

    {

        TkCanvas *canvasPtr = (TkCanvas *) canvas;

  +     if (!canvasPtr->tkwin) {

  +       return;

  +     }

        if ((x1 >= x2) || (y1 >= y2) ||

              (x2 < canvasPtr->xOrigin) || (y2 < canvasPtr->yOrigin) ||

              (x1 >= canvasPtr->xOrigin + Tk_Width(canvasPtr->tkwin)) ||


  PatchFiles:

  generic/tkCanvas.c




  Your patch looks OK, but I'd like to try to find out what the root cause of the problem is, ie, why is Tk_CanvasEventuallyRedraw getting called in the first place?

  Can you tell us what the "wrong order" is?  Do you have to destroy the canvas first, and then the image, or vice versa?  Does this only happen with your new image type?  If so, can you send the source for the image type?

  Thanks,

  - eric

  -- 04/10/2000 ericm

  I applied this patch; the fix will go out with 8.3.1.  However, I am still concerned that this is not the best fix for the problem.  What it comes down to is that this patch, though it fixes this particular problem, only addresses the "what" of the bug, not the "why".  It does not provide us with any understanding, really, of why this behavior is occuring.  Because of this, it doesn't really help us to avoid problems like this in the future. 

  There are practical reasons to search for other fixes as well.  What if what's really going on is that the image handler is mistakenly calling Tk_CanvasEventuallyRedraw?  This fix will prevent the core dump, but it will not stop the image handler from calling Tk_CanvasEventuallyRedraw, which may happen many many times.

  Also, checks like this one penalize the nominal case (tkwin != NULL) in order to handle the exceptional case (tkwin == NULL).  It would be better, in my opinion, to prevent the call to Tk_CanvasEventuallyRedraw in the first place.

  Because of the brevity of information provided here, we are unable to make a more complete diagnosis of the problem, unfortunately.

  - eric

  -- 04/13/2000 ericm


tkt_uuid: 571433ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: grid propagate does unneeded re-layout
comment:
  Tk Bug 220546 was not fixed quite right.
  This causes a re-layout when grid propagation is turned
  off even though
  it is already off.  The problem is in
  tk8.3.4/generic/tkGrid.c line 581:

          /* Only request a relayout if the propagation
  bit changes */

          if ((!propagate) ^
  (masterPtr->flags&DONT_PROPAGATE)) {
   
  The "if" condition is not right.  The first argument of
  ^ is 0 or 1 while
  the second argument is 0 or 2.


tkt_uuid: 220289ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: scale test fails
comment:
  OriginalBugID: 4433 Bug
  Version: 8.3
  SubmitDate: '2000-03-21'
  LastModified: '2000-06-02'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: HP-UX 11.00, 32 bit kernel
  ClosedDate: '2000-06-02'


  Name:

  ed foltz


  CustomShell:

  tcl compile warnings corrected:


  Comments:

  Test 6.11. When .0001 is the argument to log10() the result is not 4.0~,

      it is 4.000000000000009. So floor() returns 5 instead of 4.


  ObservedBehavior:

  Fromsupplied regression  test suite:

  scale.test


  ==== scale-6.12 ComputeFormat procedure FAILED

  ==== Contents of test case:


      .s configure -from .00001 -to .0001 -resolution .00001

      .s set .00006

      .s get


  ---- Result was:

  6e-05

  ---- Result should have been:

  0.00006

  ==== scale-6.12 FAILED

  ==== scale-6.14 ComputeFormat procedure FAILED

  ==== Contents of test case:


      .s configure -to .00001 -from .0001 -resolution .00001

      .s set .00006

      .s get


  ---- Result was:

  6e-05

  ---- Result should have been:

  0.00006

  ==== scale-6.14 FAILED


  Also, test 6.11 fails with returned result 0.00060, expected 0.0006

  test scale-6.11 {ComputeFormat procedure} {

      .s configure -from .0001 -to .001 -resolution .0001

      .s set .0006

      .s get

  } {0.0006}


  DesiredBehavior:

  Result from 6.12 and 6.14 is valid because ComputeFormat() returns the shortest string representation.


  Expected 6.11 to return 0.0006.


  Patch:

  scale.test

  357c357

  < } {6e-05} 

  ---

  > } {0.00006}

  366,367c366,367

  <       .s get

  < } {6e-05} 

  ---

  >     .s get

  > } {0.00006}


  tkScale.c


  837c837

  <           leastSigDigit = (int) floor(log10f((float)scalePtr->resolution));

  ---

  >           leastSigDigit = (int) floor(log10(scalePtr->resolution));


  PatchFiles:

  scale.test

      tkScale.c




  This is a minor platform dependent difference on HP's part, and
  has no overall effect on the code, because 6e-05 == .00006.
  We could mark it non-portable (as we have to do because Windows
  has similar quirks), but it'd be better for the core team to
  see these tests run in general. 
  -- 06/02/2000 hobbs


tkt_uuid: 220590ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: canvas widget always draws its highlight border
comment:
  OriginalBugID: 2676 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-09-01'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: SunOS  5.5 sparc
  Machine: Other
  FixedDate: '1999-09-01'
  FixedInVersion: 8.2.1


  Name:
  Aldo MAZZILLI

  Extensions:
  TCL, TK 8.2

  ReproducibleScript:
  pack [canvas .c] [canvas .d]

  ObservedBehavior:
  Each canvas has its highlightthickness border *always* drawn.

  DesiredBehavior:
  No borders



  Occurs on all platforms. 
  -- 09/01/1999 hobbs
  This was a problem caused by GC swapping (fg <> bg) when Jim added
  better highlight support on the Mac.  This is fixed for 8.2.1. 
  -- 09/01/1999 hobbs


tkt_uuid: 220785ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 69. Events
priority: 7 High
foundin: None
resolution: Fixed
title: attach user-defined data to generated events
comment:
  OriginalBugID: 1146 RFE
  Version: 8.1b1
  SubmitDate: '1999-02-02'
  LastModified: '2000-04-03'
  Severity: LOW
  Status: Assigned
  Submitter: pat
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: 4
  Machine: X86


  Name:
  Bryan Oakley

  DesiredBehavior:
  It would be really nice to be able to attach random data to generated events, and to be able to access that data via standard binding substitutions. I suggest a -clientdata switch to event generate, and a %c substitution to get at that data. Here's a quick example:

      bind .handle <<Drag>> {handleDrag %c}
      ....
      event generate .handle <<Drag>>> -clientdata "-type image"
      ....
      proc handleDrag {clientData} {
          array set options $clientData
          switch $options(-type) {
              image {
                  # do image-specific things
              }
              text {
                  # do text-specific things
              }
              default {
                  error "dragging objects of type $options(-type) not allowed"
              }
          }
      }



  This seems like a really easy thing to implement, and would make event generate much more flexible. The alternative today is to set a global or namespace variable to contain the data. I think it would be more useful to attach the data directly to the event.
  --

  Verified in the sense that this is a good idea.

  - eric

  -- 04/03/2000 ericm


tkt_uuid: 2764272fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Accepted
title: Adjustable demo install location.
comment:
  Allow demos to be installed anywhere with overridable Makefile variable DEMO_INSTALL_DIR, defaults to current settings.


tkt_uuid: 3170714fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Works For Me
title: Menubutton and -direction flush does not work properly with
comment:
  When running attached code item selection works fine for first time, subsequently it seems to be hanging in OSX system call - probably due to Tk not passing mouse movement events.

  Clicking on menubutton multiple times causes the program to occasionally hang - doe snot change selected item and releasing mouse button does not cause item to be selected.

  Changing -direction or disabling -indicatoron still works - only this combination fails. When enabling Carbon events tracing, first click causes both button up/down events and move events to be received. Subsequent clicks only cause information on mouse up/down to be printed - and this might be the root of the problem.

  Sample Tcl code works fine with Tk up to 8.5.6 - 8.5.7 is the first release where this code does not work. Since CVS is down (at least as of now) I have not been able to determine more exact date when it broke.

  It can also be reproduced by doing [$menu post] on top of menubutton manually.


tkt_uuid: 1101854fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 4
foundin: obsolete: 8.4.9
resolution: None
title: Aqua grab confused if menu used in dialog box
comment:
  I see the following on Aqua Tk 8.4.9 (MacOS X 10.3.7) but not on a 
  unix/X11 build on the same MacOS X. So it may be specific to Aqua 
  Tk.

  If I create a dialog box that includes a menu then:
  - post the menu
  - select a menu item
  - button presses are ignored for one or more buttons of the dialog box

  Psueodcode to demonstrate this:
  - create a toplevel (the dialog box); within this dialog box:
  - create a variable doneVar
  - create an option menu with a few entries and two buttons: OK and 
  Cancel
  - set up commands so that if either button is pressed, it prints a 
  suitable message and sets doneVar
  - grab
  - wait for variable doneVar
  - release the grab
  - destroy the dialog box

  If you selects a menu item from the option menu, then the dialog box 
  goes into this funny mode where:
  - the first button (OK or Cancel) that you press will be ignored -- no 
  matter how many times you press it
  - once you have pressed one button at least once, then if you press 
  the other button it will act normally
  - if you bring up the menu but do NOT select an item from it then the 
  dialog box will act normally (both buttons work just fine)

  If you eliminate the grab then the problem does not appear.

  I have attached a python/tkinter script that demonstrates everything. 
  I have performed other tests and am pretty sure 

  I also tried a more complex dialog box with the OK and Cancel buttons 
  plus an Entry to which I had bound a contextual menu. I then bound 
  a print statement to <Enter> for all three of these widgets. After 
  selecting an item from the contextual menu, the bindings stopped 
  working for both buttons, though they continued to work for the 
  Entry widget. Clicking on the entry widget restored normal behavior.


tkt_uuid: 1048554fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Bug fix for pinstripe background--from Trebuchet developer
comment:
  From the Trebuchet developer: 

   Focus rings for text widgets are often wrong.  I'll take a look and 
  see if I can track this bug down later.

      Focus rings are implemented as a bit of a hack.  Carbon 
  appears to refuse to tell me the true region shapes of the controls 
  in question, so I had to fake it.  This means if apple changes the 
  shape of their theme buttons at some point in the future, the focus 
  rings will be incorrect.  I recently came across info on how to fix 
  this so it's done the correct way, but it will take a lot of rework of 
  the tkMacOSXButton.c and tkMacOSXMenuButton.c files.

      In canvas widgets, the pinstripe background gets offset from the 
  correct pattern.  This is a subtle effect usually, but it appears hard 
  to fix.

      The Application Preferences menu item will always be enabled, 
  even if no preferences handler proc is defined.

      Dashed lines in canvases don't work when drawing with 
  foreground color set to one of the theme background patterns.  You 
  can do one or the other, but not both at the same time.


tkt_uuid: 733835ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 3 Low
foundin: obsolete: 8.0
resolution: Fixed
title: Rename library/images/*.bmp files
comment:
  naming these files .bmp , when the contents are .xbm
  format, causes confusing to people trying to view the
  images and make use of them in other contexts.  The
  files should be renamed with a suffix that matches the
  format inside, or given no suffix at all.


tkt_uuid: 974421ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 28. Utility Functions
priority: 9 Immediate
foundin: obsolete: 8.5a1
resolution: Fixed
title: Documentation bug: Tk_PointToChar
comment:
  The description of Tk_PointToChar in TextLayout(3)
  seems to indicate that the return value is always a
  valid character index (except in the special case of an
  empty string).  It can actually return an index *one
  past* the end of the string (even when the string is
  nonempty).  Manpage should be clarified to reflect this.


tkt_uuid: 1711990fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: stubs strict-alias warning
comment:
  /home/dgp/src/tk8.5a6/unix/../generic/tkStubLib.c: In function ‘Tk_InitStubs’:
  /home/dgp/src/tk8.5a6/unix/../generic/tkStubLib.c:101: warning: dereferencing type-punned pointer will break strict-aliasing rules


tkt_uuid: 220477ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Need to call setlocale() before XOpenIM for input methods to work
comment:
  OriginalBugID: 1668 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-25'
  LastModified: '1999-10-22'
  Severity: SER
  Status: Released
  Submitter: stanton
  ChangedBy: hobbs
  RelatedBugIDs: 1636
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-10-22'
  FixedInVersion: 8.2


    Hi folks. I am a maintainer of Tcl/Tk Japanization patch kit (AKA
  tcl/tk[78]xjp). 

    BUT NOTE THAT:
    With Tk world, Tk or Tcl MUST call setlocale() with proper locale to
  handle XIM (X Input method) BEFORE calling XOpenIM(). Further more, if
  the X library is compiled with -DX_LOCALE, Tcl or Tk MUST NOT call
  setlocale() in libc BUT call _xsetlocale() in the X library. This is
  a specification of X11R[56].

  m-hirano@trc.rwcp.or.jp (m-hirano@sra.co.jp)
  Real World Computing Partnership, Tsukuba, Japan
  Software Research Associates, Inc., Japan 


  I have sent mail to m-hirano to determine what really needs to be done here. It is dangerous to call setlocale() because this affects the way Tcl parses numbers and letters.
  03/30/1999 15:25 - stanton -
  Tk 8.2 changed some initialization around, and setlocale will be
  called in Tcl.  If more work is needed, another more accurate bug
  report needs to be submitted based off the new features. 
  -- 10/22/1999 hobbs


tkt_uuid: 220798ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 6
foundin: obsolete: 8.1
resolution: Fixed
title: Creating a new widget during <Expose> prevents Windows
comment:
  OriginalBugID: 1601 Bug
  Version: 8.1
  SubmitDate: '1999-03-23'
  LastModified: '2000-01-03'
  Severity: LOW
  Status: Assigned
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2607 3865
  OS: Solaris
  OSVersion: 2.6
  Machine: Other


  Name:
  Petasis Georgios

  ReproducibleScript:
      text .t
      pack .t
      bind . <Expose> { destroy .t;frame .t; pack .t; update }

  ObservedBehavior:
  You cannot move or resize another tk window over ".". Also, alot of
  bg errors happen. This behaviour is only under windows. On unix,
  everything is
  fine. (In my application I use "place" to place a frame widget over a
  canvas,
  and those bgerrors do not occur. What happens is that tk does not block
  like
  it blocks with this script, but the update "reputs" the window you try to
  move to its earlier position. But this app is to complex to post here.)


  Verified, actually crashed on 8.3. 
  -- 01/03/2000 hobbs


tkt_uuid: 220858ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.2b3
resolution: Fixed
title: Tk build system incomplete on UNIX
comment:
  OriginalBugID: 2543 Bug
  Version: 8.2b3
  SubmitDate: '1999-08-13'
  LastModified: '2000-01-12'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: Redhat 4.2
  Machine: Other


  Name:
  Jan Nijtmans

  ReproducibleScript:
  The new UNIX build system for Tk was only partially implemented in
      Tk8.2b1, and there has not been any progress in b2 and b3. No-one at
      scriptics seems to be working at finishing it, so  - O.K. - I offer a
      little bit of my time.
      At least this works on Linux, and it should also work fine on Solaris,
      HP-UX, SGI and many other UNIX systems. Can someone check this on
      AIX?????

  DesiredBehavior:
  Tk should be built with -DUSE_TCL_STUBS in order to fully support Stubs.

  Patch:
  *** unix/configure.in.origWed Aug 11 20:45:18 1999
  --- unix/configure.inFri Aug 13 21:30:47 1999
  ***************
  *** 342,352 ****
    if test "${SHARED_BUILD}" = "1" -a "${SHLIB_SUFFIX}" != ""; then
        TK_SHLIB_CFLAGS="${SHLIB_CFLAGS}"
        TK_LIB_FILE=libtk${TK_SHARED_LIB_SUFFIX}
  !     MAKE_LIB="\${SHLIB_LD} -o \${TK_LIB_FILE} \${OBJS} \$(TK_LD_SEARCH_FLAGS) ${TCL_STUB_LIB_SPEC} \${LIBS}"
        RANLIB=":"

  ! #    TCL_STUB_FLAGS="-DUSE_TCL_STUBS"
  !     TCL_STUB_FLAGS=""
    else
        TK_SHLIB_CFLAGS=""
        TK_LIB_FILE=libtk${TK_UNSHARED_LIB_SUFFIX}
  --- 342,351 ----
    if test "${SHARED_BUILD}" = "1" -a "${SHLIB_SUFFIX}" != ""; then
        TK_SHLIB_CFLAGS="${SHLIB_CFLAGS}"
        TK_LIB_FILE=libtk${TK_SHARED_LIB_SUFFIX}
  !     MAKE_LIB="\${SHLIB_LD} -o \${TK_LIB_FILE} \${OBJS} \$(TK_LD_SEARCH_FLAGS) \${TCL_STUB_LIB_SPEC} \${LIBS}"
        RANLIB=":"

  !     TCL_STUB_FLAGS="-DUSE_TCL_STUBS"
    else
        TK_SHLIB_CFLAGS=""
        TK_LIB_FILE=libtk${TK_UNSHARED_LIB_SUFFIX}
  ***************
  *** 410,415 ****
  --- 409,415 ----
    AC_SUBST(STUB_LIB_FILE)

    AC_SUBST(TK_STUB_LIB_FILE)
  + AC_SUBST(TCL_STUB_LIB_FLAG)
    AC_SUBST(TK_STUB_LIB_FLAG)
    AC_SUBST(TK_BUILD_STUB_LIB_SPEC)
    AC_SUBST(TK_STUB_LIB_SPEC)
  ***************
  *** 444,452 ****
    AC_SUBST(SHLIB_VERSION)
    AC_SUBST(TCL_BIN_DIR)
    AC_SUBST(TCL_LIB_SPEC)
    AC_SUBST(TCL_LIB_FLAG)
  ! #AC_SUBST(TCL_BUILD_STUB_LIB_SPEC)
  ! #AC_SUBST(TCL_BUILD_LIB_SPEC)
    AC_SUBST(TCL_DBGX)
    AC_SUBST(TCL_LIB_FLAG)
    AC_SUBST(TCL_SRC_DIR)
  --- 444,453 ----
    AC_SUBST(SHLIB_VERSION)
    AC_SUBST(TCL_BIN_DIR)
    AC_SUBST(TCL_LIB_SPEC)
  + AC_SUBST(TCL_STUB_LIB_SPEC)
    AC_SUBST(TCL_LIB_FLAG)
  ! AC_SUBST(TCL_BUILD_STUB_LIB_SPEC)
  ! AC_SUBST(TCL_BUILD_LIB_SPEC)
    AC_SUBST(TCL_DBGX)
    AC_SUBST(TCL_LIB_FLAG)
    AC_SUBST(TCL_SRC_DIR)
  ***************
  *** 454,459 ****
  --- 455,461 ----
    AC_SUBST(TK_BUILD_LIB_SPEC)
    AC_SUBST(TK_CC_SEARCH_FLAGS)
    AC_SUBST(TK_LD_SEARCH_FLAGS)
  + AC_SUBST(TK_SHARED_LIB_FILE)
    AC_SUBST(TK_LIB_FILE)
    AC_SUBST(TK_LIB_FLAG)
    AC_SUBST(TK_LIB_SPEC)
  *** generic/Makefile.in.origWed Aug 11 20:45:18 1999
  --- generic/Makefile.inFri Aug 13 21:30:47 1999
  ***************
  *** 83,88 ****
  --- 83,89 ----

    # The linker flags needed to link in the Tcl library (ex: -ltcl8.2)
    TCL_LIB_FLAG =@TCL_LIB_FLAG@
  + TCL_STUB_LIB_FLAG =@TCL_STUB_LIB_FLAG@

    # Libraries built with optimization switches have this additional extension
    TK_DBGX =@TK_DBGX@
  ***************
  *** 182,187 ****
  --- 183,189 ----

    #TCL_LIB_SPEC = @TCL_BUILD_LIB_SPEC@
    TCL_LIB_SPEC = @TCL_LIB_SPEC@
  + TCL_STUB_LIB_SPEC = @TCL_STUB_LIB_SPEC@
    TK_EXP_FILE = @TK_EXP_FILE@
    TK_BUILD_EXP_FILE = @TK_BUILD_EXP_FILE@

  PatchFiles:
  configure.in Makefile.in


tkt_uuid: 2902214fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 70. Event Loop
priority: 8
foundin: obsolete: 8.5.6
resolution: None
title: Crash in X11 input-method handling with chinese locale
comment:
  bug shows here: http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/43fca0b5fbce3398/785ae0ad16e3ca37?pli=1

  I found only one line corrected, we can solve this problem. (maybe just skip, but anyway wish can run):
  line 365  in tkEvent.c :
  XGetICValues(winPtr->inputContext, XNFilterEvents, &im_event_mask, NULL);
  =>    if (winPtr->inputContext != NULL)  XGetICValues(winPtr->inputContext, XNFilterEvents, &im_event_mask, NULL);


tkt_uuid: 2911346fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: None
title: Add 'pixels' option to $w yview scroll
comment:
  The text and canvas widgets have commands

  $w xview scroll number what
  $w yview scroll number what

  For the text widget, 'what' is 'units', 'pages' or 'pixels'.  For the canvas, 'what' must be 'units' or 'pages'.  It would be useful to have the 'pixels' option so that the same scrolling code can be re-used for text and canvas.  For example, the text widget has sophisticated cross-platform bindings for mousewheel scrolling, but this code uses the 'pixels' option, and so cannot be directly re-used for a canvas.


tkt_uuid: 1913825fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.18
resolution: Works For Me
title: tk_getOpenFile freezes after internal filedialog was in use
comment:
  Hello,

  on Aqua (Tiger) the tk_getOpenFile dialog freezes wish if
  the internal file dialog (::tk::dialog::file:: open)
  was in use before.
  To reproduce, start wish, then type:
  > ::tk::dialog::file:: open
  (select cancel)
  > tk_getOpenFile -parent .
  (click on your home, or browse around, wish freezes
  sooner or later).

  The -parent option is important to trigger the freeze!

  best regards,
  Randolf


tkt_uuid: 493402ffffffffffffffffffffffffffffffffff
type: Patch
status: Deleted
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: TIP 48: style patch
comment:
  Modified version of:

  http://www.multimania.com/fbonnet/pub/style.patch

  This patch is not yet ready to be applied.


tkt_uuid: 810026ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Remind
title: TkAqua: handle resolution independent UI in Tiger+
comment:
  In Mac OS X Aqua, Tk assumes 72 DPI resolution.  Many 
  macs have higher resolution, though.  This patch correctly 
  finds the screen size, and thereby the correct tk scaling.


tkt_uuid: 1267484fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a4
resolution: Fixed
title: text-8.18 fails
comment:
  ==== text-8.18 TextWidgetCmd procedure, "replace"
  option FAILED
  ==== Contents of test case:

      list [catch {.t replace 3.1 2.3 foo} err] $err

  ---- Result was:
  1 {Index "2.3" before "3.1" in the text}
  ---- Result should have been (exact matching):
  1 {Index "2.3" before "3.1" in the text.}
  ==== text-8.18 FAILED


tkt_uuid: 2548722fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.5.6
resolution: Works For Me
title: tk_popup incorrectly placement on Windows
comment:
  This bug has been marked as closed in the past but it is still there. At least in Tk 8.5.4

  commenting the block specific to windows in proc "::tk::PostOverPoint", file menu.tcl seems to fix the problem.

   


tkt_uuid: 1470524fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 8
foundin: obsolete: 8.4.12
resolution: Out of Date
title: Wish core dumps when DISPLAY set to :<n>
comment:
  Running Tk 8.4.12 on a Solaris 5.8 machine and trying
  to display to a vncserver running locally as display :1.0.

  When my DISPLAY environment variable is set to :1.0,
  wish core dumps upon exit with this error message:

  "called Tcl_FindHashEntry on deleted table"

  If DISPLAY is set to <hostname>:1.0, this core dump
  does not happen.  It seems to only happen when the
  hostname is not explicitly set in the DISPLAY variable.

  e.g.:

  > setenv DISPLAY :1.0
  > wish
  % exit
  called Tcl_FindHashEntry on deleted table
  Abort (core dumped)
  > setenv DISPLAY machinename:1.0
  > wish
  % exit
  > 
  (no core file)

  Any help would be appreciated.  Thanks.
  Chris Hawes
  chawes@cadence.com


tkt_uuid: 685388ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 82. X11 Emulation
priority: 5 Medium
foundin: None
resolution: Fixed
title: Implementation for feature request 667631
comment:
  This patch implements XOR (and similar) drawing of
  Strings on the windows platform as requested in feature
  request 667631.

  The patch uses the bltModes array from tkWinDraw.c, so
  I had to export it and add it to tkWinInt.h. I renamed
  it according to the tcl/tk naming schemes for
  non-static variables. 


tkt_uuid: 220692ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Tk_CreateItemType doc out of date
comment:
  OriginalBugID: 4252 Bug
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-03-02'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  FixedDate: '2000-03-02'
  FixedInVersion: 8.3.1


  Name:
  Spiros J Boucouris

  ReproducibleScript:
  createProc, configProc and CoordPorc are listed as expecting
  char** argv
  instead of
  Tcl_Obj* CONST argv

  ObservedBehavior:
  Unexpected compiler errors.

  DesiredBehavior:
  Update the documentation



  adjusted for 8.3.1 
  -- 03/02/2000 hobbs


tkt_uuid: 623718ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Duplicate
title: image create -data fails on Alpha
comment:
  DEC Alpha OSF1 V4.0
  TK 4.0

  The -data parameter fails during an image create 
  operation.
  The following line(s) will no longer run on the ALPHA 
  under
  tk 8.4:

  image create photo Go32 -format gif -data {
  R0lGODlhIAAgAPQAAP///wAAACEYAP/OAAj3AAD/AA
  D3AAj/CFr3GEL/Qv+cAP+cCDEpAP/G
  AP+lEFIQCEIxAM4AMc4IMXMxCGMQENYIOffGAEohA
  DkQCAAAAAAAAAAAAAAAAAAAAAAAAAAA
  ACH/C05FVFNDQVBFMi4wAwEAAAAh+QQIDwAdACw
  AAAAAIAAgAAAFwiAgjqRgnqhJruwqDHAs
  C23txpCAYTFt/6+BQCKJSIK+X+0liDidkotQaWNGKs8Ix
  ZKk3ppZ7dTLYhazkzG5BINkkesb
  TPAw9eJsmb4bDwpPd3giSAsKhnCCAEwOho0ManhMj
  Y1MiYpChYYLC5WJTJmanYJImgsMDZB9
  PYBzln56rZ6rdrGjcwgFCQWItgIEBcAFBqKRQgbCyMSq
  AgcFzcDKa0zHwbup0nO/0LXFc6zX
  ZK+wfNIp5pYkAeoB6C3r7F4hADs=
  }

  I've tracked this down to line 2668 of 
  tk8.4.0/generic/tkImgPhoto.c.

  During initialization, the width and height are both zero 
  (0).
  On other platforms, an alloc of zero bytes, seems to 
  work, but
  on the ALPHA it throws an error.

  My hack was to ignore the error, if 0 bytes requested. 
  Another
  possible solution would be to modify attemptckalloc() 
  and specify
  a minimum size.


tkt_uuid: 1717472fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Display Mac icons with Carbon IconServices API
comment:
  I would like to see Tk Aqua display Mac icons natively using the Carbon IconServices API (see http://developer.apple.com/documentation/Carbon/Reference/IconServices/index.html). I envision this working in the following fashion: given a file path, Carbon would display the correct icon/image data in Tk. 

  There appear to be at least rudimentary hooks for doing this already in the Tk Aqua code base, specifically tkMacOSXBitmap.c. Currently the code is mostly broken, and does not display many of the icons that were previously supported under Mac OS Classic (i.e. the "folder" bitmap). This could be an opportunity to fix and modernize the code at the same time. 


tkt_uuid: 220652ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: Transient window madness
comment:
  OriginalBugID: 4026 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-17'
  LastModified: '2000-01-28'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-01-28'
  FixedInVersion: 8.3


  Name:
  Tim Baker

  Comments:
  When I remove the "wm resizable" line from the script, everything works as expected.

  ReproducibleScript:
  toplevel .topA
  wm resizable .topA no no

  toplevel .topB
  wm transient .topB .topA

  Put the above into a script and start wish83 (so that the console also appears), then source the script:
  % source script.tcl

  ObservedBehavior:
  Notice that topB is still withdrawn, it should be mapped. Type
  % wm deiconify .topB

  topB appears, but the contents are not being drawn!
  Now iconify topA by clicking the titlebar button, then deiconify topA by clicking the Windows Taskbar.
  If you drag topB, you'll discover that there are now two Win32 window frames for topB!



  This was introduced in 8.3b2 with reworking of the Windows wm.
  Must be corrected ASAP. 
  -- 01/17/2000 hobbs
  All the related problems have been solved.  This has always been
  an odd area, but now it should work more "as expected".  8.3 will
  also have clearer docs for 'wm', most directly pointing to the
  fact that there are some platform dependent aspects that must be
  considered when using the 'wm' command. 
  -- 01/28/2000 hobbs


tkt_uuid: 2987995fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 8
foundin: obsolete: 8.5.8
resolution: Fixed
title: Tk_getOpenFile returns garbage under described circumstances
comment:
  Tcl/Tk - ActiveTcl 8.5.8
  System: 64-bit Windows 7 Professional

  When using tk_getOpen file with "-multiple 1", it returns garbage under the following circumstance:

  - Type a partially matching filename in the "File name:" section of the dialog
  - Now, select a file from the list of presented (matching) files
  - Print out the results - they are complete garbage

  I cannot reproduce this under 32-bit Windows XP.  So, it's either a Win7 oddity or a 64-bit oddity.  As I don't have either 64-bit XP or 32-bit Win 7, I can't verify which is the issue.

  Remember, the keys to reproducing this are:
  - Win 7 / 64-bit
  - set "-multiple 1"
  - partially type a file name and then select from the presented matches


tkt_uuid: 1032953fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 4
foundin: obsolete: 8.4.7
resolution: None
title: menubutton: can\'t set fg on aqua Tcl/Tk
comment:
  Setting the fg or bg of a menubutton under aqua tcl/tk 
  (8.4.7 or earlier, MacOS X 10.3.4 or earlier) does nothing 
  useful. Setting bg sets the color of a border region around 
  the menubutton. Setting fg does nothing. Setting other 
  colors (active..., etc.) also does nothing.

  I realize this is probably an issue with limitations in the 
  native toolkit, but what with all the other problems with 
  aqua menubuttons (see my recent spate of bug reports and 
  reports from others), I was hoping you might consider 
  making your own menubutton instead of relying on the 
  native widget.

  (aqua buttons have some of the same limitations and would 
  also benefit from being homegrown instead of native).


tkt_uuid: 716500ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Wont Fix
title: Make fails
comment:
  When I run "make" in my RedHat 9 it appears a lot of
  parse errors ending with:

  /root/tk8.4.2/generic/tk3d.c:1394: request for member
  `borderTable' in something not a structure or union
  /root/tk8.4.2/generic/tk3d.c:1394: request for member
  `borderTable' in something not a structure or union
  /root/tk8.4.2/generic/tk3d.c:1396: parse error before
  ')' token
  /usr/include/sys/stat.h: At top level:
  /root/tk8.4.2/generic/tk3d.c:1134: storage size of
  `shiftTable' isn't known
  /root/tk8.4.2/generic/tk3d.c:31: warning: `BorderInit'
  declared `static' but never defined
  /root/tk8.4.2/generic/tk3d.c:36: warning: `Intersect'
  declared `static' but never defined
  /root/tk8.4.2/generic/tk3d.c:39: warning: `ShiftLine'
  declared `static' but never defined
  {standard input}: Assembler messages:
  {standard input}:696: Error: symbol `dy' is already defined
  {standard input}:702: Error: symbol `dx' is already defined
  {standard input}:749: Error: symbol `q' is already defined
  {standard input}:755: Error: symbol `p' is already defined
  {standard input}:761: Error: symbol `q' is already defined
  {standard input}:767: Error: symbol `q' is already defined
  make: *** [tk3d.o] Error 1

  I've read all your README files, and visited the
  websites listed there but i can't find a soluction.


tkt_uuid: 860991ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Fixed
title: Popup menu on Windows at wrong position
comment:
  On MS-Windows environment (NT,W2000,XP) popup menues
  which are too near to bottom or right screen edge are
  posted somewhere off the edge at a wrong place.

  Bug is in menu.tcl:  tk::PostOverPoint

  The fix mentioned there is wrong.

  See attached fixed version of menu.tcl


tkt_uuid: 2538769fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: Control the way tags bleed and are edited in the text widget
comment:
  When using the text widget, it would be nice to have the option to control how tagged text will bleed or if tagged text is user-editable. 

  For instance, I would love to insert formatting code into the body of a text which is elided - but the problem here, is that the user experiences the cursor acting chaotically when he deletes or backspaces over one of the elided characters. It would be good to have the option of either the hidden format mark being silently deleted, without causing a hesitation of the text cursor... or having the format mark pushed back so it remains within the text.

  Also, it would be nice to control how and when the text tags bleed. I have a program, for instance, that highlights the matching curly-braces with different colors, to make tcl code easier to read. But the problem there is that when there are two braces right next to eachother, and you type between them, the text in the middle takes on the color and size of the colored braces. 

  - Laif


tkt_uuid: 1591494fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 1 Zero
foundin: obsolete: 8.5a5
resolution: None
title: unixSelect 1.4, 1.5, 1.6 failure on tk cvs head
comment:
  tk 8.5 cvs head built with solaris 9 sun c compiler and
  test suite display via exceed 10.0.0.12 on win xp

  unixSelect.test

  ==== unixSelect-1.4 TkSelGetSelection procedure: simple
  i18n text, iso2022 FAILED
  ==== Contents of test case:

      setupbg
      setup
      selection handle -type COMPOUND_TEXT -format
  COMPOUND_TEXT .  {handler COMPOUND
  _TEXT}
      selection own .
      set selValue \u00fc\u0444
      set selInfo {}
      set result [dobg {
          set x [selection get -type COMPOUND_TEXT]
          list [string equal \u00fc\u0444 $x]  [string
  length $x] [string bytelength 
  $x]
      }]
      cleanupbg
      lappend result $selInfo

  ---- Result was:
  1 2 4 {COMPOUND_TEXT 0 4000 COMPOUND_TEXT 0 4000}
  ---- Result should have been (exact matching):
  1 2 4 {COMPOUND_TEXT 0 4000}
  ==== unixSelect-1.4 FAILED

  ==== unixSelect-1.5 TkSelGetSelection procedure: INCR
  i18n text, iso2022 FAILED
  ==== Contents of test case:

      # This test is subtle.  The selection ends up
  getting fetched twice by
      # Tk:  once to compute the length, and again to
  actually send the data.
      # The first time through, we don't convert the data
  to ISO2022, so the
      # buffer boundaries end up being different in the
  two passes.

      setupbg
      setup
      selection handle -type COMPOUND_TEXT -format
  COMPOUND_TEXT .  {handler COMPOUND
  _TEXT}
      selection own .
      set selValue [string repeat x
  3999]\u00fc\u0444[string repeat x 3999]
      set selInfo {}
      set result [dobg {
          set x [selection get -type COMPOUND_TEXT]
          list [string equal  [string repeat x
  3999]\u00fc\u0444[string repeat x 3999
  ] $x]  [string length $x] [string bytelength $x]
      }]
      cleanupbg
      lappend result $selInfo

  ---- Result was:
  1 8000 8002 {COMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000
  3999 COMPOUND_TEXT 7998 4000 C
  OMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000 3999
  COMPOUND_TEXT 7998 4000 COMPOUND_TEXT 0
   4000 COMPOUND_TEXT 4000 3998 COMPOUND_TEXT 7997 4000}
  ---- Result should have been (exact matching):
  1 8000 8002 {COMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000
  3999 COMPOUND_TEXT 7998 4000 C
  OMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000 3998
  COMPOUND_TEXT 7997 4000}
  ==== unixSelect-1.5 FAILED

  ==== unixSelect-1.6 TkSelGetSelection procedure: simple
  i18n text, iso2022 FAILED
  ==== Contents of test case:

      setupbg
      setup
      selection handle -type COMPOUND_TEXT -format
  COMPOUND_TEXT .  {handler COMPOUND
  _TEXT}
      selection own .
      set selValue \u00fc\u0444
      set selInfo {}
      set result [dobg {
          set x [selection get -type COMPOUND_TEXT]
          list [string equal \u00fc\u0444 $x]  [string
  length $x] [string bytelength 
  $x]
      }]
      cleanupbg
      lappend result $selInfo

  ---- Result was:
  1 2 4 {COMPOUND_TEXT 0 4000 COMPOUND_TEXT 0 4000}
  ---- Result should have been (exact matching):
  1 2 4 {COMPOUND_TEXT 0 4000}
  ==== unixSelect-1.6 FAILED


tkt_uuid: 220510ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: Docs missing for Tk_IsEmbedded API
comment:
  OriginalBugID: 1872 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '2000-01-18'
  Severity: MED
  Status: Released
  Submitter: surles
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-01-18'
  FixedInVersion: 8.3


  as above

  added to WindowId.3 for 8.3.0. 
  -- 01/18/2000 hobbs


tkt_uuid: 1501922fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 8
foundin: obsolete: 8.4.14
resolution: Fixed
title: regression in redraw behavior on OS X
comment:
  One of the changes post-8.4.13 for OS X has caused the
  behavior of the tile ttk::notebook to not properly
  refresh the tabbed window.  It works fine the first
  draw down the sequence of tabs, but then revisiting any
  doesn't refresh properly.  It works OK with 8.4.13, but
  not post-8.4.13.  You can test it against the tile
  widget demo notebook.


tkt_uuid: 1353414fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Fixed
title: [selection get -type TARGETS] returns a non-list
comment:
  If a graphic in OpenOffice.org is on the clipboard, and
  a Tcl script does [selection get -type TARGETS], the
  result does not have one list element per target type
  and in some cases is not even a well-formed list.

  % selection get -type TARGETS
  application/x-openoffice-svxb;windows_formatname="SVXB
  (StarView Bitmap/Animation)"
  application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile"
  application/x-openoffice-emf;windows_formatname="Image
  EMF"
  application/x-openoffice-wmf;windows_formatname="Image
  WMF"
  application/x-openoffice-bitmap;windows_formatname="Bitmap"
  PIXMAP image/bmp MULTIPLE

  Admittedly, OOo is taking liberties with XA_TARGETS,
  but Tk should tolerate their screwiness.


tkt_uuid: 220107ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: winfo children problem
comment:
  OriginalBugID: 629 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-06'


  I've been using Tcl/Tk 8.0p2 on Win95 and NT and have a question about
  the winfo children command in Tk. The help documentation says it returns
  a list of all the children of window and the list is in stacking order
  with the lowest window first. What it does return is the same list
  independent of stacking order. 
  Here's a brief example of what I mean.

  I make two windows 
          toplevel .a
          toplevel .b
  independent of stacking order, when I execute 
          winfo children .
  I get
  .a .b
  I tried it with frame with similar results. So the question is, am I
  misapplying this command, is it a bug or ?
  Does anyone know how I can find the path of the topmost window. Your
  help is greatly appreciated,

  Thanks,
  Bob Alkire <alkire@interval.com>

  This works as expected, with the difference that it works as you
  would have expected for frames, and toplevels ignore "stacking
  order" in this sense.  You can [raise] a toplevel, but it is
  really the children of toplevels, and their children, etc, that
  have a "stacking order" in this sense. 
  -- 08/06/1999 hobbs


tkt_uuid: 3552404fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: Fixed
title: ttk::entry - overzealous clipping
comment:
  Symptom (observed on Tk trunk under X11)

  pack [ttk::entry .e -width 10] -expand true -fill x

  Type in .e until it needs to scroll. Rightmost characters are not displayed, neither is insert cursor.

  Selection rectangle however is displayed.

  Suspected cause of problem: dkf's latest change.


tkt_uuid: 1151700fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 70. Event Loop
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: None
title: XIM input box font size hard coded
comment:
   In using XIM on SPARC Solaris, with kinput2, it was
  discovered that kinput2's font size is based on the
  font of the top level used to contain the input entry
  box.  The Tk code affected is in tkEvent.c:
  > 
  >                     if (dispPtr->inputXfs == NULL) {
  >                         /*
  >                          * We only need to create one
  XFontSet
  >                          */
  >                         char      **missing_list; 
  >                         int       missing_count;
  >                         char      *def_string;
  > 
  >                         dispPtr->inputXfs = 
  > XCreateFontSet(dispPtr->display,
  >                                
  "-*-*-*-R-Normal--14-130-75-75-*-*",
  >                                 &missing_list, 
  > &missing_count, &def_string);
  >                         if (missing_count > 0) {
  >                            
  XFreeStringList(missing_list);
  >                         }
  >                     }
  > 
  where the fontset is hard coded.

  So for a user to change the font size, they have to
  rebuild Tk! 

  The developer who researched this wrote:

  > 
  >    My thoughts on this would be to extend the tk 
  > useinputmethods command > (<http://wiki.tcl.tk/8695>, 
  > 
  <http://www.tcl.tk/man/tcl8.4/TkCmd/tk.htm>) to
  something like this:

  tk useinputmethods?-displayof window?
  ?-preeditfont fontset?
  #example -preeditfont
  '-*-*-*-R-Normal--24-230-75-75-*-*'
  ?-style style?
  #choices: root, over
  ?boolean?



  where the ones with comments are new.  The argument
  fontset to
  -preeditfont would be any string that can be passed to
  XCreateFontSet()
  (<http://www.xfree86.org/4.1.0/XCreateFontSet.3.html>).

     I was thinking about a sample implementation, but I
  haven't had a chance to do more than think.  In
  particular, I haven't checked whether the fontset can
  be changed dynamically with XSetICValues()
  (<http://www.xfree86.org/current/XSetICValues.3.html>).
   A simpler mechanism, like a new resource, is probably
  more feasible.


tkt_uuid: 220408ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: tkMenuFind walks through menus in other toplevels
comment:
  OriginalBugID: 924 Bug
  Version: 8.0.3
  SubmitDate: '1998-12-04'
  LastModified: '1999-02-03'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  FixedDate: '1999-02-03'
  FixedInVersion: 8.0.5


  Name:

  Frank J. Leitner


  ReproducibleScript:

  Create two toplevel widgets, each having a menubar. Hide/iconify one toplevel.

  Trigger the key binding (alt-underline) for the menu in the hidden toplevel.


  #!/usr/local/bin/wish


  toplevel .a

  menu .a.m -tearoff 0

  menu .a.m.a

  .a configure -menu .a.m

  .a.m add cascade -menu .a.m.a -label 1 -underline 0

  .a.m.a add command -label exit -command exit


  menu .m -tearoff 0

  menu .m.a

  . configure -menu .m

  .m add cascade -menu .m.a -label 2 -underline 0

  .m.a add command -label exit -command exit


  ObservedBehavior:

  All menubars are searched for the  keybindings (underline), even if they are in a different toplevel.

  If the toplevel is hidden/iconified the following error is created:


  grab failed: window not viewable

      while executing

  "grab -global $w"

      (procedure "tkTraverseToMenu" line 21)

      invoked from within

  "tkTraverseToMenu . 1"

      (command bound to event)


  DesiredBehavior:

  Only the menubar of the current toplevel (the one having focus) should be able to open menus on key bindings.


  Patch:

  *** menu.tcl.orig       Thu Jul  2 20:03:44 1998

  --- menu.tcl    Thu Dec  3 15:51:23 1998

  ***************

  *** 885,890 ****

  --- 885,891 ----

        set windowlist [winfo child $w]


        foreach child $windowlist {

  +         if {[winfo toplevel [focus]] != [winfo toplevel $child] } continue

          switch [winfo class $child] {

              Menu {

                  if {[$child cget -type] == "menubar"} {

  ***************

  *** 911,916 ****

  --- 912,918 ----

        }


        foreach child $windowlist {

  +         if {[winfo toplevel [focus]] != [winfo toplevel $child] } continue

          switch [winfo class $child] {

              Menubutton {

                  set char2 [string index [$child cget -text] \


  PatchFiles:

  library/menu.tcl


tkt_uuid: 1062022fffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
title: TIP 231: Support for [wm attributes] on X11
comment:
  Adds support for -topmost, -zoomed, and -fullscreen wm
  attributes on X11.  Implementation is based on the
  freedesktop.org EWMH spec.


tkt_uuid: 1458234fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 9 Immediate
foundin: obsolete: 8.4.12
resolution: Fixed
title: Segmentation fault when using animated GIFs
comment:
  When using the undocumented -index suboption of the
  -format option to the image create photo command, some
  GIF images can cause a segmentation fault. This happens
  when the first subimage is smaller than some later
  ones. The buffer for storing the image data is
  allocated based on the size of the first subimage.
  However, that same buffer is used to store all the
  subimages that don't all fit.

  For some reason I don't get the segmentation fault
  unless the requested subimage doesn't exist and the
  buffer has to be freed again.

  The problem has been observed on SuSE Linux 8.2.

  Reproducible script:

  package require Tk
  image create photo -file segv.gif -format "gif -index 2"


tkt_uuid: 693369ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 7 High
foundin: obsolete: 8.4.1
resolution: Fixed
title: Win2K unixWm test failures
comment:
  Here are failing tests that I get on Win2K.  Not the only 
  ones, but they strike me as recent.  Perhaps bugs that 
  shouldn't be run on Windows?  Note use of iconwindow 
  (does Windows support that?).

  ==== unixWm-9.4 TkWmMapWindow procedure, icon 
  windows FAILED
  ...
  ---- Result was:
  1
  ---- Result should have been (exact matching):
  0
  ==== unixWm-9.4 FAILED


  ==== unixWm-27.6 Tk_WmCmd 
  procedure, "iconwindow" option, changing icons FAILED
  ...
  ---- Result was:
  icon normal normal icon
  ---- Result should have been (exact matching):
  icon normal withdrawn icon
  ==== unixWm-27.6 FAILED


  ==== unixWm-27.7 Tk_WmCmd 
  procedure, "iconwindow" option, withdrawing icon FAILE
  D
  ...
  ---- Result was:
  $
  ---- Result should have been (exact matching):
  normal 1 icon 0
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== unixWm-27.7 FAILED


  ==== unixWm-42.1 WrapperEventProc procedure, map 
  and unmap events FAILED
  ...
  ---- Result was:
  unmapped 0 {no event} 1
  ---- Result should have been (exact matching):
  unmapped 0 mapped 1
  ==== unixWm-42.1 FAILED


tkt_uuid: 2931374fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 9 Immediate
foundin: obsolete: 8.5.8
resolution: Fixed
title: bad memory management in complex tag searches
comment:
  The module tkCanvas.c contains a serious bug
  which leds to memory corruption in some
  cases (a "segmentation fault" in malloc in
  my situation).

  The problem lies within TagSearchScanExpr and
  deals with memory allocation for TagSearchExpr.uids
  array.

  In the parsing-while loop the first if-statement:

     if (expr->allocated == expr->index) {
        expr->allocated += 15;
        ...
     }

  extends the exor->uids array, if expr->index
  has reached the maximum (expr->index points one
  ahead the last position). Please notify, that this
  construct is sufficient, if expr->index
  is (after writing the current slot) incr only once
  during the loop body!

  Looking at:

     if (looking_for_tag) {

        switch (c) {
           case ' ':/* ignore unquoted whitespace */
           case '\t':
           case '\n':
  case '\r':

        ...

        default: /* unquoted tag string */
           
  if (negate_result) {
  >>>         expr->uids[expr->index++] = searchUids->negtagvalUid;
              negate_result = 0;
           } else {
  >>>         expr->uids[expr->index++] = searchUids->tagvalUid;
           }

           ...

           *++tag = '\0';
  >>>      expr->uids[expr->index++] =
           Tk_GetUid(searchPtr->rewritebuffer);
           looking_for_tag = 0;
           found_tag = 1;
        }

     } else {    /* ! looking_for_tag */

      ...

     }

  As you can see, if the negate_result flag is on
  there are 2 slots used. Zhis results in memory 
  corruption, if expr->allocated == expr->index-1
  at the top.

  I've corrected this by making sure that there are
  at least 2 free slots in expr->uids at the top
  of the while loop:

     if (expr->allocated <= expr->index+1) {
        expr->allocated += 15;
        ...
     }


tkt_uuid: 220019ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Duplicate
title: ldAix
comment:
  OriginalBugID: 2685 Bug
  Version: 8.2
  SubmitDate: '1999-09-01'
  LastModified: '1999-09-15'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2624
  OS: AIX
  OSVersion: 4.3
  Machine: RS6000
  ClosedDate: '1999-09-15'


  Name:
  LE FUR Jean-Francois

  Extensions:
  tcl8.2.0

  CustomShell:
  no

  ReproducibleScript:
  ./configure is O.K
      
      make

  ObservedBehavior:
  /export/produits/.../tk8.2.0/unix/ldAix :  not found
       when trying to create libtk8.2.so


tkt_uuid: 1913750fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: tk_chooseDirectory -initialdir internationalization problem
comment:
  The problem can be observed when we use the Japanese name for the folder name.

  For example:

  tk_getOpenFile -initialdir [file join $env(HOME) "テスト"]

  This works fine, the dialog opens $env(HOME)/テスト

  "テスト" is a folder written in Japanese.

  However,

  tk_chooseDirectory -initialdir [file join $env(HOME) "テスト"]

  This does not work properly.

  The dialog does not indicate $env(HOME)/テスト but indicates $env(HOME) and a part of "テスト" is ignored.

  This problem can be observed on Windows version of Tcl/Tk.
  On UNIX version, this may not be observed, at least on Fedora 8, there seems no problem, it works fine. Thanks.

  Keiichi


tkt_uuid: 513948ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: TIP 27: restore Tcl_DString use
comment:
  Once Tcl_DStrings are converted back to
  white-boxes (Tcl Patch 513947), this
  companion patch makes a few simplifications
  to Tk code.


tkt_uuid: 1563874fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 9 Immediate
foundin: obsolete: 8.4.14
resolution: Fixed
title: [package require Tk] broken by TIP 268 in Tk 8.4.14
comment:
  Build current Tk 8.4.14 sources
  against current Tcl 8.4.14 headers
  in their default configuration.
  Install.  Then:

  % info patch
  8.4.14
  % package provide Tcl
  8.4
  % package require Tk
  can't find package Tk

  Examining $libdir/tk8.4/pkgIndex.tcl:

  if {[package vcompare [package provide Tcl] 8.4.14] !=
  0} { return }
  package ifneeded Tk 8.4.14 [list load [file join $dir
  .. libtk8.4.so] Tk]

  We see that Tk 8.4(.14) isn't offered because
  the version of Tcl (8.4) doesn't pass the screen
  for a minimum requirement of 8.4.14.

  Comment out the screen line, and we get this:

  % package require Tk
  version conflict for package "Tcl": have 8.4, need 8.4.14
  % set errorInfo
  version conflict for package "Tcl": have 8.4, need 8.4.14
      while executing
  "load /usr/local/lib/tk8.4/../libtk8.4.so Tk"
      ("package ifneeded" script)
      invoked from within
  "package require Tk"

  The problem is at line 2948 of tkWindow.c:

      if (Tcl_InitStubs(interp, TCL_PATCH_LEVEL, 1) ==
  NULL) {
          return TCL_ERROR;
      }

  This is demanding a Tcl stubs table of exactly
  version 8.4.14, but no default config build of
  Tcl 8.4 will label its stub table with that
  version number, so currently Tk 8.4.14 will
  not load in a standard Tcl interp.

  Tcl 8.4 does have a config option to
  make use of TIP 268 features, and I presume
  that would make things work, but the
  default build of Tk ought to work with
  the default build of Tcl.


tkt_uuid: 3205464fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: [wm forget] lose window
comment:
  Under Windows XP, Tk 8.5.9.
  If [wm forget $w] is called when $w original parent is not mapped, the window is "lost".
  The attached script demonstrates the problem: it creates a notebook with 5 tabs.
  Right click on a tab detach the content with [wm manage] in a toplevel.
  Close the toplevel, the content get back into tab page, but only if original tab page is raised.
  If you raise another page or iconify the application and then close the toplevel, the content is not visible anymore.
  Calling again [wm manage] on the same tab displays a toplevel without redraw.
  Looks like a flag is not well reset in [wm forget], although [wm ismapped] and [wm viewable] return 1.


tkt_uuid: 2879927fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 7 High
foundin: obsolete: 8.5.8
resolution: Fixed
title: Wrong color of submenu arrow in torn-off menu
comment:
  When a menu item is not activated, its label is drawn in black, and when activated - in white (given standard Windows settings), but the submenu arrow (if the item is actually a submenu, of course) is drawn in black, whether it is "activated" or "normal". The real menu draws the arrow in white when the item is activated.

  The attached patch fixes this behaviour.


tkt_uuid: 220879ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 3 Low
foundin: None
resolution: None
title: Can't set size of embedded window in a text widget in pixels
comment:
  OriginalBugID: 3457 RFE
  Version: 8.0p2
  SubmitDate: '1999-11-05'
  LastModified: '2000-01-25'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0


  DesiredBehavior:
  -width and -height options for windows embedded in a text widget (just
      like those available for windows embedded in a canvas).


tkt_uuid: 577086ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: bgerror dialog can be much too wide
comment:
  Example script:

  set err [string repeat "hello " 100]
  bgerror $err

  The dialog produced by 'bgerror' is several times 
  wider than the screen, so one can't even really see 
  the buttons properly (or at any rate, more than one 
  of them).

  The bgerror dialog should have a maximum width 
  of the size of the screen, at worst.

  (Note: this is on Windows, but I assume the same 
  on all platforms).


tkt_uuid: 1374935fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a4
resolution: Fixed
title: tcl/tk 8.5 peer crash: text tag names
comment:
  #! /bin/sh
  # -*- tcl -*- \
  exec wish $0 $@

  package require Tcl 8.5
  package require Tk 8.5

  text .text
  .text insert 1.0 "This is just a normal text widget"
  puts [.text tag names]
  .text peer create .peer
  puts [.text tag names]
  grid .text
  grid .peer


  The 1st puts works fine.
  The 2nd one seg faults.

  tcl/tk 8.5a4 run on sparc solaris 2.8


tkt_uuid: 861777ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: None
title: Tk_MeasureChars bug?
comment:
  In the latest tk cvs head (with the updated
  Tk_MeasureChars), various tk tests now fail.  From the
  results it looks as if there's a bug that's been
  introduced.  For example, winfont-5.4 fails:

      .b.l config -wrap [expr $ax*6] -text "00000000"
      getsize

  This is a label that is set to wrap at a width of 6
  times the (monspace) character width.  However, the
  result shows that in fact 7 characters are fit onto the
  first line of the label. Here's a full test:

  toplevel .b
  wm geometry .b +0+0
  update idletasks

  set courier {Courier 14}
  set cx [font measure $courier 0]

  label .b.l -padx 0 -pady 0 -bd 0 -highlightthickness 0
  -justify left -text "0" -font systemfixed
  pack .b.l
  canvas .b.c -closeenough 0

  set t [.b.c create text 0 0 -anchor nw -just left -font
  $courier]
  pack .b.c
  update

  set ax [winfo reqwidth .b.l]
  set ay [winfo reqheight .b.l]
  proc getsize {} {
      update
      return "[winfo reqwidth .b.l] [winfo reqheight .b.l]"
  }

      .b.l config -wrap [expr $ax*6] -text "00000000"
      getsize

  # Should equal "[expr $ax*6] [expr $ay*2]"


tkt_uuid: 1472624fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: obsolete: 8.5a4
resolution: Fixed
title: TkAqua focus lost example with balloon help
comment:
  The attached example shows how a toplevel created for balloon help on 
  TkAqua, which should not take the focus, does steal the focus from the 
  underlying widget.

  To reproduce:

  >wish8.5
  % source focusTestBalloonHelp.tcl

  -

  Now click on the new toplevel's titlebar to give the window the focus. Now 
  move the mouse over the text in the window. A balloon will appear, which 
  also contains information about the current focus. It says "focus is .tt.t" 
  for a fraction of a second, and then changes to say "focus is .balloon".

  To make things even worse, uncomment the second of these two lines in 
  the test file:

  # To make things even worse on TkAqua, uncomment this line
  #wm overrideredirect .balloon 1

  That makes the entire toplevel lose its frontmost status (contradicting the 
  documented behaviour and what happens on Win/Unix)

  Vince.


tkt_uuid: 1810818fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 9 Immediate
foundin: None
resolution: Fixed
title: [wm resizeable] broken in 8.5b1 on OS X only
comment:
  If resizing for either dimension is turned off then both dimensions get turned off.

  This has been introduced after 8.4.7.

  NOTE -- the windows works fine.


tkt_uuid: 568578ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Invalid
title: textIndex-5.2 kills xfs on Linux/Alpha
comment:
  Don't know what recent changes have been made here,
  but the test textIndex-5.2 pretty reliably does bad things
  to my XFree86-3.3.6-20 on Red Hat Linux 6.2 on Alpha.

  During a full `make test` it just hangs on that test with X
  consuming all CPU.  (AARRRRGGGHHH. just re-ran to
  verify, and no hang, so this isn't 100% repeatable.)

  If I limit the testing to the textIndex.test file (with
  -file option
  in TESTFLAGS) then the test just take uncomfortably long
  (a few seconds, while all others zip by in fractions of
  a second)
  and then sometimes (unreliably) I later have trouble with X
  closing and restarting when I log out/into another session.

  This is the first time I've noticed this trouble, have
  there been
  changes in this area recently?


tkt_uuid: 2122502fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: None
resolution: Fixed
title: matching colors in X11 and xcolors.c
comment:
  tk claims to support xlib color names, but /usr/share/X11/rgb.txt contains "crimson" which is missing from xlib/xcolors.c in tk sources.

  There may be other mismatches. xcolors.c should be regenerated from X11's current rgb.txt.


tkt_uuid: 1870330fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: None
priority: 5 Medium
foundin: None
resolution: None
title: Remove some Tk_Uid usage
comment:
  This patch cleans up some meaningless usages of Tk_Uid.

  If noone objects, I'll commit this some day.


tkt_uuid: 1867897fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 8
foundin: obsolete: 8.5.0
resolution: Fixed
title: ttk::label truncates text on drawing
comment:
   package require Tk ; # using 8.5.0
   ttk::label .l -anchor nw -justify left -width 70
   pack .l -fill both
   .l configure -text "There is text\n
  \there is some more.\n
  jsdflkjsdlkfjlsdjflksdjlkj slfdjs dflkjsdflkj sd fsdlfkjsdflk sd fasldkjasd asd asdlkjasd asdlkj asdkjasldjasd lasjdalksjdasd asldjaslkdjasd laksjdlkajsd asldkjasd asldjasdlkjas dlkasjlkasjdlkasjd asdlkjasldkjasdlk alskdjalksdjalksdj asldkjasdlkjasd asldj"

  This only displays "There is text", although it makes some space for the other text.  If you use \n's to split the long line on <70char boundaries, all is displayed.

  This happens on X11 and Windows at least.


tkt_uuid: 1322294fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 9 Immediate
foundin: obsolete: 8.5a4
resolution: Duplicate
title: Tcl_Panic on exit
comment:
  Latest cvs head of tcl, tk, when running on Windows,
  crash on exit here:

  /*
   * There have been several bugs in the past that cause
  exit handlers
   * to be established during Tcl_Finalize processing.
  Such exit
   * handlers leave malloc'ed memory, and
  Tcl_FinalizeThreadAlloc or
   * Tcl_FinalizeMemorySubsystem will result in a
  corrupted heap. The
   * result can be a mysterious crash on process exit.
  Check here that
   * nobody's done this.
   */

  if (firstExitPtr != NULL) {
      Tcl_Panic("exit handlers were created during
  Tcl_Finalize");
  }

  in tclEvent.c. 

  I've filed this against Tk, since Wish crashes for me,
  but Tclsh does not.

  Vince.


tkt_uuid: 220361ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 77. Square Demo
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: bug in Tk8.1 tkSquare.c example
comment:
  OriginalBugID: 613 Bug
  Version: 8.1a2
  SubmitDate: '1998-05-21'
  LastModified: '1998-11-19'
  Severity: SER
  Status: Released
  Submitter: hershey
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-19'
  FixedInVersion: 8.1b1


  Bug Report:
  Versions Affected: Tk 8.1a1 and 8.1a2
  Platforms: All

  There appears to be a typo in tkSquare.c for Tk8.1a[12]:

  tkSquare.c: line
      {TK_OPTION_BOOLEAN, "-dbl", "doubleBuffer", "DoubleBuffer",
              "1", Tk_Offset(Square, doubleBufferPtr) -1,},

                                          ^^^^

  The last "-1" and "," are transposed.  The code compiles, but leads to
  memory corruption.  Transposing them back seems to fix it.

  --mark

  -- 
  Mark A. Monheit                 direct: 650-858-6080
  Motorola, Lexicus Division      fax:    650-494-1143
  3145 Porter Drive               page:   800-SKYTEL2 id# 858-6080
  Palo Alto, CA  94304            email:  markm@lexicus.mot.com


tkt_uuid: 528892ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 4
foundin: None
resolution: Out of Date
title: Argv has value on startup
comment:
  When you start the OSX build of tk, argc is set to 1 and argv has a value 
  which was not provided by me! The value looks like -psn_0_1048577 
  (probably a process id of some kind as it changes every run)


tkt_uuid: 1743786fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Fixed
title: tk_getOpenFile returns garbage for "Cancel"
comment:
  Starting with 8.4.15 tk_getOpenFile returns garbage like "after#15"
  when the user presses the Cancel button in the file dialog.
  It is supposed to return ""...

  This happens in my application but I could not reproduce this
  with wish.

  Digging through the source of NavServicesGetFile() in tkMacOSXDialog.c
  I think I found the source of the problem:
  theResult = Tcl_NewObj();
  , something like:
  Tcl_SetStringObj(theResult, "", -1);
  , and
  Tcl_SetObjResult(interp, theResult);
  never seem to take place, when the result of the dialog is not
  noErr.
  However, for the Cancel button case err == userCanceledErr...
  So, I added the upper three lines to the branch where the
  userCanceledErr case is handled. This fixed it for me:
  -snip-
      } else if (err == userCanceledErr) {
        theResult = Tcl_NewObj();
        Tcl_SetStringObj(theResult, "", -1);
  Tcl_SetObjResult(interp, theResult);
  result = TCL_OK;
      }
  -snap-

  best regards,
  Randolf,
  -- 
  http://www.ayam3d.org/    The best things in life are free!


tkt_uuid: 219988ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: final: 8.1.1
resolution: Duplicate
title: Double-clicking in text widget wrong on NT
comment:
  OriginalBugID: 2132 Bug
  Version: 8.1.1
  SubmitDate: '1999-05-28'
  LastModified: '1999-08-08'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 1388
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-08-08'


  Name:

  Stephan Uyttebroeck



  ReproducibleScript:

  pack [text .t]

      .t insert 1.0 {ab cd(ef,gh);}



  ObservedBehavior:

  Now click with the mouse on e.g. 'e' or f'.

      On Unix you see the expected selection 'ef'.

      On Windows you get 'cd(ef,gh);}', thus only space-separated selection.

      

      From the man pages:

      ~~~~~~~~~~~~~~~~~~

      ... ``word'' refers to a contiguous group of letters, digits, or ``_''

      characters, or any single character other than these. 

      

      ...

      

      [2]

           Double-clicking with mouse button 1 selects the word under the

      mouse and positions the insertion cursor at the beginning of the

      word...



  DesiredBehavior:

  Same behavior on Windows as on Unix !!!


tkt_uuid: 3592736fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 29. Colormaps and Visuals
priority: 7 High
foundin: obsolete: 8.5.13
resolution: Fixed
title: color #909090909090 shows pink on win mingw
comment:
  I have two tcl/tk 8.5.13
  a) compiled by msvc6
  b) Starpack kbsvq8.5.13-gui.exe by René Zaumseil
      This is mingw compiled

  I start both and enter in the console:

  pack [label .l -bg #909090909090] -fill both -expand true

  on a) I get a grey box as expected
  on b) I get a red box. The displayed color value is: #ff9090

  I tried it also with 8.5.12:
  http://sourceforge.net/projects/kbskit/files/kbs/0.4.3/WindowsNT_kbsv...
  -> same funny color.

  and with ActiveState 8.5.12 wish, which does not have the bug.

  My box: Windows Vista 32 bit GER

  clt thread:
  http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/578ac55c2aebe643#


tkt_uuid: 472276ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: disable text selection bug on Windows
comment:
  Text selection in disabled (readonly) text widgets is
  not visible on Windows (unlike X11), even though it is
  selected.  You can duplicate this bug with the enclosed
  wish script.

  Greg Couch
  gregc@cgl.ucsf.edu
  -------
  #!/usr/bin/env wish

  text .text -exportselection 0 -takefocus 1
  .text insert 1.0 "some maybe selectable text\n"
  .text insert 2.0 "tcl$tcl_patchLevel tk$tk_patchLevel"
  .text tag add sel 1.0 end
  .text config -state disabled
  bind .text "<ButtonRelease-1>" {puts "[.text tag ranges
  sel]"}
  pack .text

  button .b1 -text Enable -command {.text config -state
  normal}
  pack .b1
  button .b2 -text Disable -command {.text config -state
  disabled}
  pack .b2


tkt_uuid: 220129ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: Listbox "-selectmode single" behavior
comment:
  OriginalBugID: 1358 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-08'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2086
  OS: HP-UX
  Machine: Other
  ClosedDate: '1999-08-07'


  Name:
  Bradley Mazurek

  Extensions:
  BLT, iTcl

  CustomShell:
  None

  ReproducibleScript:
  pack [listbox .lb -selectmode single]
  foreach item [list a b c d e f] {
    .lb insert end $item
  }
  .lb selection set 2 4

  ObservedBehavior:
  Even though the listbox selectmode is "single", more than one item is selected.

  DesiredBehavior:
  Because the selectmode is "single", precisely one item (don't really care which...first or last in given range), is selected.



  I could be completely off base, and this functionality/behavior may be
  intended....

  Yes, this is the intended behavior.  The listbox -selectmode is an
  option that the bindings use to interpret user interaction.  If
  the selection method is called by the programmer, then it can go
  against this behavior without problem. 
  -- 08/07/1999 hobbs


tkt_uuid: 2785744fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Incorrect setting of window flags
comment:
  On line 2356 of tkWinWm.c the WM_SYNC_PENDING flag is set with '=' instead of or'ing it with '|=' when a toplevel has a menu. This causes all other window flags (including those set by [wm resizable]) to be forgotten.

      if (wmPtr->hMenu != NULL) {
  wmPtr->flags = WM_SYNC_PENDING;
  SetMenu(wmPtr->wrapper, wmPtr->hMenu);
  wmPtr->flags &= ~WM_SYNC_PENDING;
      }


tkt_uuid: 220608ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Race in tkUnixWm.C:TkCoordsToWindow leads to X error
comment:
  OriginalBugID: 3328 Bug
  Version: 8.2
  SubmitDate: '1999-11-05'
  LastModified: '1999-12-22'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  FixedDate: '1999-12-22'
  FixedInVersion: 8.3b1


  Name:

  David Ackley


  CustomShell:

  Only the included patch.


  ReproducibleScript:

  TO DUPLICATE:


      #start of deathwish.tcl

      puts "set tk_version [set tk_version]"

      update

      for {set i 0} {1} {incr i} {

          set xy [winfo pointerxy .]

          set win [winfo containing [lindex $xy 0] [lindex $xy 1]]

          after 10

      }

      #end of deathwish.tcl


      #start of deathwin.tcl

      for {set i 0} {1} {incr i} {

          toplevel .foo

          update

          after 500

          destroy .foo

      }

      #end of deathwin.tcl


      Do 'wish deathwish.tcl'.  Get your window manager to place windows

      automatically.  My window manager places this window at 0,0.


      Do 'wish deathwin.tcl' as well.  Mine repeatedly puts .foo at 0,0.


      Now you have .foo blinking on and off (over the deathwish window,

      although I don't think that matters).


      Put the pointer into the area where the .foo window is being created

      and destroyed.  Wait.  Watch deathwish.tcl get an X error and die

      (BadWindow, from X_TranslateCoords).  (If you have to wait more than

      ten or fifteen seconds, your experience is very different than mine.)


  ObservedBehavior:

  $ wish deathwish.tcl

      set tk_version 8.0

      X Error of failed request:  BadWindow (invalid Window parameter)

        Major opcode of failed request:  40 (X_TranslateCoords)

        Resource id in failed request:  0x140e7da

        Serial number of failed request:  1911

        Current serial number in output stream:  1911

      $


  DesiredBehavior:

  DIAGNOSIS:


      There is a race condition in tkUnixWm.c, at least in versions 8.0

      through 8.2, perhaps earlier.  Tk4.2 does not suffer from the problem;

      it appears to have been introduced whenever the concept of 'embedded

      toplevel' windows (for the Tcl plug-in?) appeared.


      In tkUnixWm.c, TkCoordsToWindow uses XTranslateCoordinates on a series

      of windows down from the root window of the relevant screen.  At each

      step, the 'child' window returned from one XTranslateCoordinates call

      is used as the 'parent' in the subsequent XTranslateCoordinates call.


      No provision is made to handle the possible failure of a

      XTranslateCoordinates call.  However, it is possible that the returned

      'child' window will be destroyed between the time it is returned from

      one call and the time it is supplied in the next call.  In such cases,

      the latter XTranslateCoordinates call will fail with a BadWindow

      error, and take the application down with it.


      SOLUTION:


      The supplied patch against tk8.2.0 corrects the problem, albeit in

      less than optimal fashion.  It sets an error handler around each call

      to XTranslateCoordinates, and jumps back to the top of the routine if

      a call fails.  As a desperation fallback, if find we've restarted more

      than a few times in a single call, we return NULL.  This amounts to

      bogusly claiming that the pointer is not in any of the application's

      windows, even though it might be --- but if we've tried several times

      and failed to locate which one, things must be pretty dynamic on the

      server, so perhaps we could get away with this little lie..  And

      perhaps not --- but it's still better than an X protocol error and

      death. 


      The patch below is likely suboptimal, at least because:

      (1) It sets and clears the errorhandler inside the loop.  Would be

          better to move that out, but the loop has too many exits for me to

          touch. 

      (2) The restart point might be higher than necessary.  Perhaps the

          original parent could be saved and reused.


  Patch:

  diff -c tkUnixWm.c.orig tkUnixWm.c

  *** tkUnixWm.c.origSun Oct  3 20:22:35 1999

  --- tkUnixWm.cSun Oct  3 23:36:47 1999

  ***************

  *** 3490,3495 ****

  --- 3490,3496 ----

        WmInfo *wmPtr;

        TkWindow *winPtr, *childPtr, *nextPtr;

        TkDisplay *dispPtr = ((TkWindow *) tkwin)->dispPtr;

  +     int spincount = 0;


        /*

         * Step 1: scan the list of toplevel windows to see if there is a

  ***************

  *** 3498,3503 ****

  --- 3499,3505 ----

         * coordinates.

         */


  +  restart:

        parent = window = RootWindowOfScreen(Tk_Screen(tkwin));

        x = rootX;

        y = rootY;

  ***************

  *** 3529,3539 ****

         */


        while (1) {

  ! if (XTranslateCoordinates(Tk_Display(tkwin), parent, window,

  ! x, y, &childX, &childY, &child) == False) {

  !     panic("Tk_CoordsToWindow got False return from XTranslateCoordinates");

    }

  ! if (child == None) {

        return NULL;

    }

    for (wmPtr = (WmInfo *) dispPtr->firstWmPtr; wmPtr != NULL; 

  --- 3531,3567 ----

         */


        while (1) {

  !         /* Sun Oct  3 23:33:17 1999 Ackley: Need to be careful.  Between

  !    (1) the time we get a child window back from one 

  !        call to XTranslateCoordinates, and 

  !            (2) the time that we use that window as parent 

  !        in the subsequent call of XTranslateCoordinates, 

  !            that window might be destroyed.   If so the latter

  !    XTranslateCoordinates gets a Bad Window error.  So, we

  !    (1) Ignore X errors here

  !    (2) If XTranslateCoords returns false, we going to make sure

  !         we aren't looping too much.  If so, we'll just bogusly declare

  !        that the pointer is NOT in our windows, otherwise

  !    (3) We'll just jump back to restart again from the root(s) 

  !        and hope the churn on the server has calmed down. 

  ! */

  ! 

  !         int result;

  ! Tk_ErrorHandler errHandler;

  ! errHandler = Tk_CreateErrorHandler(dispPtr->display, -1, -1, -1,

  !    (Tk_ErrorProc *) NULL, (ClientData) NULL);

  !       

  ! result = 

  !   XTranslateCoordinates(Tk_Display(tkwin), parent, window,

  ! x, y, &childX, &childY, &child);

  ! Tk_DeleteErrorHandler(errHandler);

  ! 

  ! if (result == False) {

  !   if (++spincount > 5) return NULL; /* Last ditch lie during utter chaos.. */

  !   goto restart;

    }

  ! 

  !         if (child == None) {

        return NULL;

    }

    for (wmPtr = (WmInfo *) dispPtr->firstWmPtr; wmPtr != NULL;


  PatchFiles:

  tkUnixWm.c




  This could also occur in Tix through another means.  A different
  fix was applied for 8.3b1 where a message would be printed to
  stderr, but no panic will occur. 
  -- 12/22/1999 hobbs


tkt_uuid: 220875ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 9 Immediate
foundin: obsolete: 8.2.1
resolution: Works For Me
title: tests/unixSelect.tcl crashes the X server (CDE)
comment:
  OriginalBugID: 3407 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-17'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 7 (Intel)


  Name: Evgeny Roubinchtein

  Comments:
  Renaming unixSelect.test to unixSelect.notest lets the tests run to
      completion.

  ReproducibleScript:
  (assuming distribution has been fetched, unpacked, configured and built)
      $ cd tk8.2.1/unix
      $ make test

  ObservedBehavior:
  the X server crashes when the unixSelect.test script is ran.

  DesiredBehavior:
  I'd  prefer for the tests not to crash the X server :-)


  This must be Solaris x86 specific, because it works on SolSparc
  without problems. 
  -- 11/17/1999 hobbs


tkt_uuid: 220493ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: tkText.c: TextSearchCmd() memory loss
comment:
  OriginalBugID: 1790 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-13'
  LastModified: '1999-04-16'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: rjohnson
  OS: Solaris
  OSVersion: 5.5.1
  Machine: Other
  FixedDate: '1999-04-16'
  FixedInVersion: 8.1


  Name:

  Peter Weigand



  Comments:

  The Tcl_DStringInit(&line); is moved because you need to init it before

      you try to free it.



  ReproducibleScript:

  In the above mention function there are return TCL_ERROR without freeing

      the DStrings.T



  Patch:

  *** tkText.cSat Apr  3 01:56:02 1999

  --- tkText.c.newMon Apr 12 22:20:44 1999

  ***************

  *** 1624,1631 ****

    Tcl_UtfToLower(pattern);

        }

    

        if (TkTextGetIndex(interp, textPtr, argv[i+1], &index) != TCL_OK) {

  ! return TCL_ERROR;

        }

        numLines = TkBTreeNumLines(textPtr->tree);

        startingLine = TkBTreeLineIndex(index.linePtr);

  --- 1624,1635 ----

    Tcl_UtfToLower(pattern);

        }

    

  +     Tcl_DStringInit(&line);/* make sure init */

  + 

        if (TkTextGetIndex(interp, textPtr, argv[i+1], &index) != TCL_OK) {

  ! code = TCL_ERROR;

  ! goto done;

  ! /*return TCL_ERROR;*/

        }

        numLines = TkBTreeNumLines(textPtr->tree);

        startingLine = TkBTreeLineIndex(index.linePtr);

  ***************

  *** 1642,1648 ****

        }

        if (argsLeft == 1) {

    if (TkTextGetIndex(interp, textPtr, argv[i+2], &stopIndex) != TCL_OK) {

  !     return TCL_ERROR;

    }

    stopLine = TkBTreeLineIndex(stopIndex.linePtr);

    if (!backwards && (stopLine == numLines)) {

  --- 1646,1654 ----

        }

        if (argsLeft == 1) {

    if (TkTextGetIndex(interp, textPtr, argv[i+2], &stopIndex) != TCL_OK) {

  ! code = TCL_ERROR;

  ! goto done;

  ! /*return TCL_ERROR;*/

    }

    stopLine = TkBTreeLineIndex(stopIndex.linePtr);

    if (!backwards && (stopLine == numLines)) {

  ***************

  *** 1666,1677 ****

        } else {

    regexp = Tcl_RegExpCompile(interp, pattern);

    if (regexp == NULL) {

  !     return TCL_ERROR;

    }

        }

        lineNum = startingLine;

        code = TCL_OK;

  !     Tcl_DStringInit(&line);

        for (passes = 0; passes < 2; ) {

    if (lineNum >= numLines) {

        /*

  --- 1672,1685 ----

        } else {

    regexp = Tcl_RegExpCompile(interp, pattern);

    if (regexp == NULL) {

  ! code = TCL_ERROR;

  ! goto done;

  ! /*return TCL_ERROR;*/

    }

        }

        lineNum = startingLine;

        code = TCL_OK;

  !     /*Tcl_DStringInit(&line);*/

        for (passes = 0; passes < 2; ) {

    if (lineNum >= numLines) {

        /*



  PatchFiles:

  tkText.c





  Applied patch - 04/16/1999 19:27 - rjohnson -


tkt_uuid: 220658ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.1a2
resolution: Fixed
title: tkWinWm.c compile error
comment:
  OriginalBugID: 4047 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-19'
  LastModified: '2000-01-20'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT 4.0 Service Pack 4
  Machine: PC
  FixedDate: '2000-01-20'
  FixedInVersion: 8.3


  Name:
  K. Trenorden

  Extensions:
  N/A

  ReproducibleScript:
  With Visual C++ V 6.0 and Tk compiled with sysmbols on (ie. NODEBUG = 0) the compiler reports the following error in tkWinWm.c:

          "c:\PROGRA~1\MICROS~4\vc98\bin\cl.exe" -DDLL_BUILD -DBUILD_tk -Z7 -Od -WX -c -W3 -
  nologo -Fp.\Debug\ -YX -MDd -I"c:\PROGRA~1\MICROS~4\vc98\include"  -I..\win -I..\generic -
  I..\bitmaps -I..\xlib  -I..\..\tcl8.3.b2\generic -D__WIN32__   -DUSE_TCL_STUBS -Fo.\Debug ..\win\tkWinWm.c
  tkWinWm.c
  ..\win\tkWinWm.c(2218) : warning C4700: local variable 'masterPtr' used without having bee
  n initialized
  ..\win\tkWinWm.c(2218) : error C2220: warning treated as error - no object file generated
  NMAKE : fatal error U1077: '"c:\PROGRA~1\MICROS~4\vc98\bin\cl.exe"' : return code '0x2'

  Looking in the code variable masterPtr is indeed not set - believe this reference should be to wm->masterPtr and
  not the local variable (which probably should be deleted ?)

  If symbols are turned off the compiler produces a warning and continues on.

  ObservedBehavior:
  tkWinWm.c doesn't compile with Smbols on and Visual C++ 6.0

  DesiredBehavior:
  No warning and compilation



  Already fixed in CVS for 8.3.0. 
  -- 01/20/2000 hobbs


tkt_uuid: 1584042fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: Wont Fix
title: checkbutton binding behavior different on Windows and Linux
comment:
  In Windows when binding a checkbutton to
  <ButtonRelease-1> the associated variable does not
  appear to update until after the <ButtonRelease-1>
  event leaving the variables in the binding always one
  state behind. In the sample code provided in Windows
  clicking on a checkbutton doesn't update the text box
  until the second checkbutton event. In Linux this
  behavior is not observed, the text field is always
  updated correctly when the checkbuttons are pressed.

  Sample Code:

  #!/bin/ksh
  # execute wish \
  exec wish "$0" "$@"
  #!wish

  frame .sample

  checkbutton .p0 -variable p0 -onvalue 1 -offvalue 0
  -text ""
  checkbutton .p1 -variable p1 -onvalue 1 -offvalue 0
  -text ""
  checkbutton .p2 -variable p2 -onvalue 1 -offvalue 0
  -text ""
  checkbutton .p3 -variable p3 -onvalue 1 -offvalue 0
  -text ""

  bind .p0 <ButtonRelease-1> {
      set result [ list $p3 $p2 $p1 $p0]
      set result [ join $result "" ]
  }
  bind .p1 <ButtonRelease-1> {
      set result [ list $p3 $p2 $p1 $p0]
      set result [ join $result "" ]
  }
  bind .p2 <ButtonRelease-1> {
      set result [ list $p3 $p2 $p1 $p0]
      set result [ join $result "" ]
  }
  bind .p3 <ButtonRelease-1> {
      set result [ list $p3 $p2 $p1 $p0]
      set result [ join $result "" ]
  }

  entry .result -width 6 -textvariable result
  set result 0000

  grid .sample
  grid .p3 .p2 .p1 .p0 .result -in .sample

  # End of Script

  Seen in ActiveTcl8.4.13.0.261555 for Windows and Linux


tkt_uuid: 1791052fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Fixed
title: NULL pointer dereference in LayoutDLine
comment:
  There's a quite reproducible bug in the Text widget that occurs in Tkabber free XMPP client (http://tkabber.jabber.ru).

  Unfortunately I have not yet managed to successfully extract the testcase, so here's some background:

  Tkabber uses Text widgets to render chats, and there embedded images are used to render emoticons (smileys) and mathematical formulae (via the LaTeX plugin). The bug occurs when a window representing a chat session (implemented with the Text widget) is opened and is being initially populated either by chat history or by the message sent to the user that triggered creation of such a window. Then iff the text in that Text widget is happened to contain an embedded image in the last chat message, the bug is almost always triggered.

  I have managed to narrow the bug: it was most probably introduced with the implementation of TIP #256 since version of 04-Oct-2005 works and one of 11-Oct-2005 crashes.

  This bug occurs on both Windows and X Window-based systems. 8.4.15 (from ActiveState) is also affected (probably, the implementation has been backported there).

  I can propose the occurence of this bug does somehow relate to the fact that the Text image in subject ends up being packed in several [grid]s and BWidget's ScrolledWindow which may affect size of the widget in the process of creation of the whole window hierarchy for a chat session.

  Here's the stack trace (MS VC6):

  LayoutDLine(TkText * 0x0290bc48, const TkTextIndex * 0x0026fc68) line 1503 + 22 bytes
  CalculateDisplayLineHeight(TkText * 0x0290bc48, const TkTextIndex * 0x0026fc68, int * 0x0026fc18, int * 0x0026fc1c) line 3429 + 13 bytes
  TkTextUpdateOneLine(TkText * 0x0290bc48, TkTextLine * 0x0290c080, int 240, TkTextIndex * 0x0026fc68, int 1) line 3595 + 21 bytes
  TkTextUpdateLineMetrics(TkText * 0x0290bc48, int 0, int 0, int 256) line 2969 + 29 bytes
  AsyncUpdateLineMetrics(void * 0x0290bc48) line 2789 + 28 bytes
  TCL85G! 100ca4a8()
  TCL85G! 100a776f()
  TCL85G! 100a7b72()
  Tk_MainLoop() line 2143 + 15 bytes
  Tk_MainEx(int 3, char * * 0x00b0263c, int (Tcl_Interp *)* 0x00401005 _Tcl_AppInit, Tcl_Interp * 0x00b05070) line 308
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00292332, int 1) line 129 + 37 bytes
  WinMainCRTStartup() line 330 + 54 bytes
  KERNEL32! 7c816d4f()

  The actual place of dereference is line 1503 at generic/tkTextDisp.c:

      if (breakChunkPtr == NULL) {
  /*
   * This code makes sure that we don't accidentally display chunks with
   * no characters at the end of the line (such as the insertion
   * cursor). These chunks belong on the next line. So, throw away
   * everything after the last chunk that has characters in it.
   */

  breakChunkPtr = lastCharChunkPtr;
  breakByteOffset = breakChunkPtr->numBytes;
      }
      if ((breakChunkPtr != NULL) && ((lastChunkPtr != breakChunkPtr)
      || (breakByteOffset != lastChunkPtr->numBytes))) {
  while (1) {
      chunkPtr = breakChunkPtr->nextPtr;
      if (chunkPtr == NULL) {
  break;
      }
      FreeStyle(textPtr, chunkPtr->stylePtr);
      breakChunkPtr->nextPtr = chunkPtr->nextPtr;
  here ->    (*chunkPtr->undisplayProc)(textPtr, chunkPtr);
      ckfree((char *) chunkPtr);
  }
  if (breakByteOffset != breakChunkPtr->numBytes) {
      (*breakChunkPtr->undisplayProc)(textPtr, breakChunkPtr);
      segPtr = TkTextIndexToSeg(&breakIndex, &byteOffset);
      (*segPtr->typePtr->layoutProc)(textPtr, &breakIndex,
      segPtr, byteOffset, maxX, breakByteOffset, 0,
      wrapMode, breakChunkPtr);
  }
  lastChunkPtr = breakChunkPtr;
  wholeLine = 0;
      }

  P.S. sorry for not presenting a working testcase. If anyone in charge would like to try to run Tkabber so see the bug, feel free to contact me for support.


tkt_uuid: 1577290fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: Non-visible blocks of text on Aqua
comment:
  When I fire up tkchat using the latest Tk and look back
  through the history there are occassional blocks of
  text that are not visible. Selecting the area where the
  text should be makes it visible again. See
  http://www.cs.nott.ac.uk/~nem/AquaTextBug.png and
  http://www.cs.nott.ac.uk/~nem/AquaTextBug2.png for an
  illustration of what I mean here. This only seems to
  happen on Mac/Aqua and only with tagged text.


tkt_uuid: 220583ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: wish fails to bind on AIX 4.3.2
comment:
  OriginalBugID: 2591 Bug
  Version: 8.2
  SubmitDate: '1999-08-20'
  LastModified: '1999-09-20'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  OSVersion: 4.3.2
  Machine: RS6000
  FixedDate: '1999-09-20'
  FixedInVersion: 8.2.1
  ClosedDate: '1999-08-21'


  Name:
  Dave Marquardt

  Extensions:
  None

  CustomShell:
  Modified generated Makefile to specify a copy of

  ReproducibleScript:
  Having fixed a previous bug where ldAix didn't exist by modifying the
      Makefile to specify the ldAix from
      the Tcl 8.2 source, wish still fails to bind.  Just run "make" to see
      this.

  ObservedBehavior:
  When binding wish, I see many errors related to unresolved symbols:
      
      rm -f libtk8.2.so
      /usr/local/src/tcl8.2.0/unix/ldAix /bin/ld -bhalt:4 -bM:SRE -bE:lib.exp
      -H512 -T512 -bnoentry -o libtk8.2.so tk3d.o tkArgv.o tkAtom.o tkBind.o
      tkBitmap.o tkClipboard.o tkCmds.o  tkColor.o tkConfig.o tkConsole.o
      tkCursor.o tkError.o tkEvent.o  tkFocus.o tkFont.o tkGet.o tkGC.o
      tkGeometry.o tkGrab.o tkGrid.o  tkMain.o tkObj.o tkOldConfig.o
      tkOption.o tkPack.o tkPlace.o  tkSelect.o tkUtil.o tkVisual.o tkWindow.o
        tkUnix.o tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o
      tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o  tkUnixFocus.o
      tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o  tkUnixMenubu.o
      tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o  tkUnixSend.o tkUnixWm.o
      tkUnixXId.o tkStubInit.o tkStubLib.o tkButton.o tkEntry.o tkFrame.o
      tkListbox.o  tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o tkScale.o
      tkScrollbar.o tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o
      tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o  tkCanvUtil.o
      tkCanvWind.o tkRectOval.o tkTrig.o !
      tkImage.o tkImgBmap.o tkImgGIF.o tkImgPPM.o tkImgPhoto.o tkText.o
      tkTextBTree.o tkTextDisp.o tkTextImage.o tkTextIndex.o  tkTextMark.o
      tkTextTag.o tkTextWind.o -L/usr/local/lib -L/usr/local/src/tcl8.2.0/unix
       -lX11 -ldl -lm -lc
      noDotA="libtk8.2.so"
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetString
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Free
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_InitHashTable
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_NewObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Panic
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_NewIntObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ListObjAppendElement
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetIndexFromObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_AppendResult
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_WrongNumArgs
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetStringFromObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetObjResult
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetIntObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_NewStringObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetStringObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Alloc
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetThreadData
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_QueueEvent
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CancelIdleCall
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DoWhenIdle
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetResult
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateTimerHandler
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Preserve
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetEncoding
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DStringInit
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DStringAppend
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ExternalToUtf
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DStringSetLength
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Release
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DStringFree
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_FreeEncoding
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ResetResult
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetInt
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetDoubleFromObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetIntFromObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetDouble
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetBooleanFromObj
      ld: 0711-317 ERROR: Undefined symbol: .TclpGetTime
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetMaxBlockTime
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DeleteEventSource
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ServiceEvent
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateEventSource
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateExitHandler
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateFileHandler
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DeleteFileHandler
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DeleteHashEntry
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DoOneEvent
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DStringStartSublist
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DStringAppendElement
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DStringEndSublist
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DStringResult
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UtfToExternalDString
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetBoolean
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_AppendElement
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SplitList
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Merge
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_IsSafe
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_TranslateFileName
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateInterp
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DeleteInterp
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_PrintDouble
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_FirstHashEntry
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_StringMatch
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UniCharToUtf
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UtfToExternal
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UtfToUniChar
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetEncodingName
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_NextHashEntry
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DeleteHashTable
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateEncoding
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_NewListObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ListObjGetElements
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Realloc
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_NumUtfChars
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_NewBooleanObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetObjResult
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UniCharIsUpper
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UniCharToLower
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DuplicateObj
      ld: 0711-317 ERROR: Undefined symbol: .TclFreeObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UniCharToUpper
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UtfAtIndex
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UtfNext
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_AddErrorInfo
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_OpenFileChannel
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_PosixError
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Seek
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Close
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Read
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_BackgroundError
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DeleteCommandFromToken
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateCommand
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetChannelOption
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_EventuallyFree
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GlobalEval
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ExternalToUtfDString
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ScanElement
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ConvertElement
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetStringResult
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ObjGetVar2
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ObjSetVar2
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_TraceVar
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_AppendToObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_NewDoubleObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetAssocData
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_AppendStringsToObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetAssocData
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetVar
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateObjCommand
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UntraceVar
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_EvalObjv
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ListObjLength
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ListObjIndex
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_ListObjReplace
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_EvalObjEx
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_AppendObjToObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetCommandInfo
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Eval
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_HideCommand
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_VarEval
      ld: 0711-317 ERROR: Undefined symbol: Tcl_Free
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DStringGetResult
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_AllowExceptions
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DeleteTimerHandler
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Sleep
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetBooleanObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetVar2
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetLongObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetLongFromObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetVar2Ex
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetObjErrorCode
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetDoubleObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetVar2Ex
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetCommandInfo
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetChannel
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Write
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetVar
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UtfPrev
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetVar2
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UtfToLower
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_RegExpCompile
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_RegExpExec
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_RegExpRange
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UniCharIsAlpha
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_PkgRequire
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetMaster
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetInterpPath
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_GetStdChannel
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_WriteChars
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UtfToTitle
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Gets
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Exit
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_DeleteChannelHandler
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CommandComplete
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateChannelHandler
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_RecordAndEval
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_WriteObj
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Flush
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_FindExecutable
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_EvalFile
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SourceRCFile
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetErrno
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Init
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateChannel
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetStdChannel
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_PkgProvideEx
      ld: 0711-317 ERROR: Undefined symbol: tclStubsPtr
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_Eof
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_LinkVar
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_InterpDeleted
      ld: 0711-317 ERROR: Undefined symbol: .Tcl_UnlinkVar
      ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
      information.
      make: 1254-004 The error code from the last command is 8.
      
      Stop.

  DesiredBehavior:
  I expect to see no such errors.



  As Larry Virden pointed out on the newsgroup, there is no reference
  to -ltcl anywhere, which is why all the Tcl calls aren't being found... 
  -- 08/21/1999 hobbs
  This was a failure in the Tcl config stuff.  It is fixed in 8.2.1. 
  -- 09/20/1999 hobbs


tkt_uuid: 568701ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 7 High
foundin: obsolete: 8.4a5
resolution: Fixed
title: remove panic on unfreed fonts
comment:
  Line 439 of Revision 1.13 of generic/tkFont.c is a
  panic() when the font subsystem is finalizing, yet
  there are unfreed fonts.

  Unfortunately, we know that some Tk widgets, notably
  [text] and [canvas], do not always free the fonts they
  are using.  This panic() has been helpful in uncovering
  those bugs, but it is not a good thing to expose to
  end users.  We should either remove it, or perhaps
  disable it unless a debugging version of Tk is compiled.

  See also Tk Bugs 559450 and 458309.


tkt_uuid: 723765ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: grid remove does not remember -in
comment:
  The [grid remove] command should remember the grid
  configuration options for a slave. But it does not
  remember the -in option value.

    frame .dock    -relief sunken -bd 1
    frame .toolbar -relief raised -bd 1

    grid .toolbar -in .dock
    puts "[grid info .toolbar]"

    grid remove .toolbar
    grid .toolbar
    puts "[grid info .toolbar]"

  returns:

  -in .dock -column 0 -row 0 -columnspan 1 -rowspan 1
  -ipadx 0 -ipady 0 -padx 0 -pady 0 -sticky {}
  -in . -column 0 -row 0 -columnspan 1 -rowspan 1 -ipadx
  0 -ipady 0 -padx 0 -pady 0 -sticky {}


tkt_uuid: 3607259fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: tag pixel range errors in Aqua/Cocoa
comment:
  The attached archive contains a script and a screenshot that demonstrate the bug.  Sorry about the tarball, Sourceforge only allows one file upload these days.

  The script tries to color a tagged range in a text widget.

  $text tag configure $tagName -foreground red

  For certain fonts, the range of pixels that are colored is about 5 pixels to the left of where it should be.  This is independent of any borders that the widget has.  In the demo script, the borders are set to 0.

  One font that behaves this way is {Courier New}, which is supplied with OS X.

  The screenshot image shows that the glyph positions agree with Tk's [$text bbox] measurements, and are consistent with a fixed-width font with width 11 pixels.

  $ /usr/local/tcl8.6/bin/wish8.6
  % source text-tag-colors2.tcl
  -ascent 15 -descent 5 -linespace 20 -fixed 1
  % font metrics {{Courier New} 18} 
  -ascent 15 -descent 5 -linespace 20 -fixed 1
  % 
  % .f.t bbox 1.0             
  0 0 11 20
  % .f.t bbox 1.1             
  11 0 11 20
  % .f.t bbox 1.2
  22 0 11 20
  % .f.t bbox 1.3
  33 0 11 20


  Most fonts do not exhibit this bug: the Courier, Menlo, and Monaco fonts are fine.  Apart from {Courier New}, I also have trouble with {DejaVu Sans Mono}, which is a TrueType font.

  The bug seems to occur only with Tk/Aqua/Cocoa; I do not see it on the 8.5.11 Carbon version of Tk, or on other platforms.  I don't see it in other applications either - e.g. TextEdit appears to be a Cocoa application, and can correctly color a range of {Courier New} text.


tkt_uuid: 3543050fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 9 Immediate
foundin: obsolete: 8.6b3
resolution: Fixed
title: segfault in ClipboardHandler
comment:
  While running the Tk test suite, I can (sometimes) trigger
  a segfault during test clrpick-3.1 by moving the mouse
  rapidly so that focus is rapidly changing between several
  non-Tk windows.  Catching it in the debugger produces
  this partial backtrace:

  0x00000000004e74ba in ClipboardHandler (clientData=0xe2d2c0, offset=0,
      buffer=0x7fffffffa5d0 "\001", maxBytes=4000)
      at /home/dgp/fossil/tk/unix/../generic/tkClipboard.c:74
  74              if (scanned + cbPtr->length > offset) {

  #0  0x00000000004e74ba in ClipboardHandler (clientData=0xe2d2c0, offset=0,
      buffer=0x7fffffffa5d0 "\001", maxBytes=4000)
      at /home/dgp/fossil/tk/unix/../generic/tkClipboard.c:74
  #1  0x00000000004cf0bd in ConvertSelection (winPtr=0xfeaab0, eventPtr=0xfb0ad0)
      at /home/dgp/fossil/tk/unix/../unix/tkUnixSelect.c:927
  #2  0x00000000004ceb69 in TkSelEventProc (tkwin=0xfeaab0, eventPtr=0xfb0ad0)
      at /home/dgp/fossil/tk/unix/../unix/tkUnixSelect.c:709
  #3  0x00000000004f22e9 in Tk_HandleEvent (eventPtr=0xfb0ad0)
      at /home/dgp/fossil/tk/unix/../generic/tkEvent.c:1327
  #4  0x00000000004f296e in WindowEventProc (evPtr=0xfb0ac0, flags=-3)
      at /home/dgp/fossil/tk/unix/../generic/tkEvent.c:1753
  #5  0x000000000060c5de in Tcl_ServiceEvent (flags=-3)
      at /home/dgp/fossil/tcl-only/generic/tclNotify.c:670
  #6  0x000000000060c8e3 in Tcl_DoOneEvent (flags=-3)
      at /home/dgp/fossil/tcl-only/generic/tclNotify.c:907

  At the time of the segfault, cbPtr holds a value that is
  not a valid pointer.


tkt_uuid: 856484ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Non-Latin scripts don't work
comment:
  On a German system Mac OS X 10.2.8 most scripts
  except latin don't work.  The "Unicode Label
  Demonstration" from demos/widget just shows
  garbage for all the interesting scripts.

  The reason is that macosx/tkMacOSXFont.c uses
  Quickdraw to draw text.  This depends on QuickDraw
  script codes and their support as primary scripts by
  fonts.  Although I have all fonts necessary for the
  scripts, they are not found by QuickDraw.

  In addition scripts that are not covered by the
  QuickDraw script list can't be supported at all.

  Patch #638966 can be used to fix this problem.


tkt_uuid: 1533112fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: None
title: core dump on HP-UX when generating events in tk's test suite
comment:
  Hi *,

  Tcl/Tk 8.4.13 and 8.4.12 dump core on HP-UX 11.11 (11i
  v1) and 11.23 (11i v2) PARISC, when running Tk's
  test-suite. Last line of focus.test:

  ---- focus-2.6 start
  sh[5]: 27198 Memory fault(coredump)
  *** Error exit code 139

  Tcl and Tk where build from patched sources using
  CC="aCC -Ae +DAportable". The used aCC versions were

  HP-UX 11.11: HP ANSI C++ B3910B A.03.45
  HP-UX 11.23: HP ANSI C++ B3910B A.03.60

  I patched the sources with those from bug 1122671, see
  also 1532273. I did not yet test earlier versions of
  Tcl/Tk.

  I am only posting the last few lines of the core dump
  as it is 47 levels deep. It comes from an 8.4.13 tktest
  executable:

  #0  0xc1ad1a6c in _XimLocalFilter+0x30 () from
  /usr/lib/libX11.3
  #1  0xc1a8cec8 in XFilterEvent+0xe8 () from
  /usr/lib/libX11.3
  #2  0x4b578 in Tk_HandleEvent (eventPtr=0x7f7f424c)
      at [...]/tk8.4/unix/../generic/tkEvent.c:952
  #3  0x41470 in HandleEventGenerate (interp=0x40041958,
  mainWin=0x40056a80, objc=2, 
      objv=0x7f7f3ed4)
      at [...]/tk8.4/unix/../generic/tkBind.c:3851
  #4  0x3f618 in Tk_EventObjCmd (clientData=0x40056a80,
  interp=0x40041958, objc=4, 
      objv=0x7f7f3ecc)
      at [...]/tk8.4/unix/../generic/tkBind.c:2823
  #5  0x140de4 in TclEvalObjvInternal (interp=0x40041958,
  objc=4, objv=0x7f7f3ecc, 
      command=0x401c9e5b "event gen . <KeyPress-x>\n   
  list $x $focusInfo\n", length=25, flags=0)
      at [...]/tcl8.4/unix/../generic/tclBasic.c:3087
  #6  0x141cf8 in Tcl_EvalEx (interp=0x40041958, 
      script=0x401c9dc8 "\n    focus .t.b1\n    focus .\n
     update\n    event gen [testwrapper .t] <FocusIn>
  -detail NotifyAncestor\n    set focusInfo {}\n    set x
  [focus]\n    event gen . <KeyPress-x>\n    list $x
  $focusInfo\n", numBytes=195, flags=262144)
      at [...]/tcl8.4/unix/../generic/tclBasic.c:3689

  I'll happily provide more information, do testing etc.
  - just let me know.

  kind regards -- Matthias Kraft


tkt_uuid: 220458ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: test suite failures
comment:
  OriginalBugID: 1523 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-18'
  LastModified: '1999-04-16'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hershey
  OS: Solaris
  Machine: Other
  FixedDate: '1999-04-02'
  FixedInVersion: 8.1b3


  Name:  Don Porter
  Many test suite failures.  I'll summarize:
      ==== canvText-6.1 FAILED
      ==== config-8.9 FAILED
      ==== grid-6.9 FAILED
      ==== grid-14.3 FAILED
      ==== main-1.1 FAILED
      ==== safe-5.1 FAILED
      ==== scale-3.29 FAILED
      ==== scale-3.30 FAILED
      ==== scale-3.31 FAILED
      ==== send-10.19 FAILED
      ==== send-12.2 FAILED
      ==== textDisp-2.22 FAILED
      ==== textDisp-2.23 FAILED
      ==== textDisp-24.9 FAILED
      ==== unixEmbed-1.3 FAILED
      ==== unixEmbed-1.4 FAILED
      ==== unixfont-5.4 FAILED
      ==== unixfont-5.5 FAILED
      ==== unixfont-5.6 FAILED
      ==== unixfont-5.7 FAILED
      ==== unixfont-5.8 FAILED
      ==== unixfont-5.10 FAILED
      ==== unixfont-5.11 FAILED
      ==== unixfont-5.12 FAILED
      ==== unixfont-8.3 FAILED
      ==== unixfont-8.4 FAILED
      ==== unixfont-8.6 FAILED
      ==== unixSend-10.19 FAILED
      ==== unixSend-12.2 FAILED
      ==== unixWm-2.1 FAILED
      ==== unixWm-2.2 FAILED
      ==== unixWm-2.7 FAILED
      ==== unixWm-2.8 FAILED
      ==== unixWm-2.9 FAILED
      ==== unixWm-3.1 FAILED
      ==== unixWm-3.2 FAILED
      ==== unixWm-3.7 FAILED
      ==== unixWm-3.8 FAILED
      ==== unixWm-3.9 FAILED
      ==== winfo-3.4 FAILED
      
      all.tcl:Total6054Passed5851Skipped163Failed40
      Sourced 68 Test Files.
      Files with failing tests: canvText.test config.test grid.test main.test
      safe.test scale.test send.test textDisp.test unixEmbed.test
      unixFont.test unixSend.test util.test winfo.test
      
      Several tests report that an integer is expected,
      but what looks like a floating point value is seen.

  Here's how I handled the failures:
      ==== canvText-6.1 FAILED:  marked nonPortable
      ==== config-8.9 FAILED:  marked nonPortable
      ==== grid-6.9 FAILED:  marked nonPortable
      ==== grid-14.3 FAILED:  marked nonPortable
      ==== main-1.1 FAILED: can't reproduce this one
      ==== safe-5.1 FAILED: fixed bug in safe interp deletion.
      ==== scale-* FAILED:  fixed a bug in the scale command.
       The ScaleWidgetObjCmd was not checking the result of the
       Tcl_GetIndexFromObj call, so it didn't always error out correctly.
      ==== send-10.19 FAILED-fixed bad reference to tcltest namespace variable
      ==== send-12.2 FAILED-fixed bad reference to tcltest namespace variable
      ==== textDisp-* FAILED: could not reporduce
      ==== unixEmbed-* FAILED: marked nonPortable
      ==== unixfont-5.* FAILED: cannot reproduce
      ==== unixfont-8.3 FAILED: fixed bad test
      ==== unixfont-8.* FAILED: cannot reproduce
      ==== unixSend-10.19 FAILED-fixed bad reference to "fd"
      ==== unixSend-12.2 FAILED-fixed bad reference to "fd"
      ==== unixWm-* FAILED: can't reproduce
      ==== winfo-3.4 FAILED: can't reproduce


tkt_uuid: 219995ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Duplicate
title: significant slow down after longer tcl/tk usage
comment:
  OriginalBugID: 2239 Bug
  Version: 8.0p2
  SubmitDate: '1999-06-16'
  LastModified: '2000-01-25'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3220
  OS: Linux-Red Hat
  Machine: Other
  ClosedDate: '2000-01-25'


  Name:
  Georges Thill

  ReproducibleScript:
  proc __DialogInfo {mesg} {
          global DauerTestId
      
          set win .info
          toplevel $win
      
          frame $win.controls
          pack $win.controls -side bottom  -fill x    -padx 4 -pady 4
      
          frame $win.sep -height 2 -borderwidth 1 -relief sunken
          pack $win.sep      -side bottom  -fill x    -pady 2
      
          frame $win.entry
          pack $win.entry    -side bottom  -fill both -padx 2 -pady 0
      
          frame $win.help
          pack $win.help     -side bottom  -fill x    -padx 2 -pady 0
      
          frame $win.info
          pack $win.info     -side bottom  -fill both -padx 2 -pady 0 -expand
      yes
      
          bind $win <Escape> "destroy $win"
          update
          after 100
      
          destroy $win
      }
      
      proc GroupDauerTest   { } {
          global DauerTestId
      
          __DialogInfo hallo
          update
      
          set DauerTestId [after 200 GroupDauerTest]
      }
      
      proc GroupDauerTestOff  { } {
          global DauerTestId
          after cancel $DauerTestId
      }
      
      for { set i 0 } {$i < 16  } {incr i  } {
          frame .f$i
          pack .f$i -side bottom
          for { set j 0 } {$j < 32  } {incr j  } {
              button .f$i.b$j
              pack .f$i.b$j -side left
          }
      }
      
      button .b1 -text Start -command GroupDauerTest
      button .b2 -text Stop  -command GroupDauerTestOff
      
      pack .b1 .b2
      
      bind . <Escape> exit

  ObservedBehavior:
  when starting the test script, everything works as expected, a window is
      opened and close periodically. When switching virtual desktops the
      refresh starts immediately. After about 20 minutes of test run, this is
      no longer the case. when switching back to the screen where the test
      window is on, there is an (increasing) delay before refresh starts.
        The problem seems to be related to the use of the use of the function
      XFilterEvent . Thus, by undefining  TK_USE_INPUT_METHODS  in tk.h for a
      tk  recompile, the problem can be worked around. It is not known if it
      is actually XFilterEvent itself or related function calls that are
      erroneous. The effect does not show up on an AIX with and older X
      revision. It seems to be related to the X server tho, because
      redirecting the display from the AIX on a linux box makes the problem
      appear. Additional tests showed that the Metrox server has the same
      problems with it as the (latest) XFree86 we are using.
         The workaround mentioned above exists, but any help to fix the actual
      bug would be greatly appreciated.



  This isn't confirmed, but there are several mentions of
  TK_USE_INPUT_METHODS slowing down some X servers due to excessive
  request traffic.  We are looking into making this functionality
  a runtime option for 8.3. 
  -- 08/21/1999 hobbs


tkt_uuid: 1456851fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 9 Immediate
foundin: obsolete: 8.5a4
resolution: Fixed
title: panic: exit handlers were created during Tcl_Finalize
comment:
  Something in Tk is creating exit handlers during
  finalize again.  Not sure if this is due to recent
  changes or if it was just missed previously.

  Further digging reveals that TkMenuCleanup and
  MenuExitHandler appear to be the culprits here.

  tcl85tg.dll!Tcl_PanicVA(const char * format=0x10100f48,
  char * argList=0x0026cde8)  Line 103 + 0x8C
  tcl85tg.dll!Tcl_Panic(const char * format=0x10100f48,
  ...)  Line 132 + 0xdC
  tcl85tg.dll!Tcl_Finalize()  Line 948 + 0xaC
  tcl85tg.dll!Tcl_Exit(int status=0)  Line 731C
  tcl85tg.dll!Tcl_ExitObjCmd(void * dummy=0x00000000,
  Tcl_Interp * interp=0x01145488, int objc=1, Tcl_Obj *
  const * objv=0x01152a2c)  Line 707 + 0x9C
  tcl85tg.dll!TclEvalObjvInternal(Tcl_Interp *
  interp=0x01145488, int objc=1, Tcl_Obj * const *
  objv=0x01152a2c, const char * command=0x00000000, int
  length=0, int flags=0)  Line 3381 + 0x1bC
  tcl85tg.dll!TclExecuteByteCode(Tcl_Interp *
  interp=0x01145488, ByteCode * codePtr=0x042397b8)  Line
  1843 + 0x27C
  tcl85tg.dll!TclCompEvalObj(Tcl_Interp *
  interp=0x01145488, Tcl_Obj * objPtr=0x02144128)  Line
  1051 + 0xdC
  tcl85tg.dll!ObjInterpProcEx(void *
  clientData=0x021444f8, Tcl_Interp * interp=0x01145488,
  int objc=4, Tcl_Obj * const * objv=0x01152960, int
  skip=1)  Line 1401 + 0x10C
  tcl85tg.dll!TclObjInterpProc(void *
  clientData=0x021444f8, Tcl_Interp * interp=0x01145488,
  int objc=4, Tcl_Obj * const * objv=0x01152960)  Line
  1144 + 0x17C
  tcl85tg.dll!TclEvalObjvInternal(Tcl_Interp *
  interp=0x01145488, int objc=4, Tcl_Obj * const *
  objv=0x01152960, const char * command=0x00000000, int
  length=0, int flags=0)  Line 3381 + 0x1bC
  tcl85tg.dll!TclExecuteByteCode(Tcl_Interp *
  interp=0x01145488, ByteCode * codePtr=0x04122c60)  Line
  1843 + 0x27C
  tcl85tg.dll!TclCompEvalObj(Tcl_Interp *
  interp=0x01145488, Tcl_Obj * objPtr=0x011c4d88)  Line
  1051 + 0xdC
  tcl85tg.dll!Tcl_EvalObjEx(Tcl_Interp *
  interp=0x01145488, Tcl_Obj * objPtr=0x011c4d88, int
  flags=0)  Line 4058 + 0xdC
  tcl85tg.dll!NamespaceEvalCmd(void * dummy=0x00000000,
  Tcl_Interp * interp=0x01145488, int objc=4, Tcl_Obj *
  const * objv=0x0026f7b0)  Line 3423 + 0x12C
  tcl85tg.dll!Tcl_NamespaceObjCmd(void *
  clientData=0x00000000, Tcl_Interp * interp=0x01145488,
  int objc=4, Tcl_Obj * const * objv=0x0026f7b0)  Line
  2961 + 0x15C
  tcl85tg.dll!TclEvalObjvInternal(Tcl_Interp *
  interp=0x01145488, int objc=4, Tcl_Obj * const *
  objv=0x0026f7b0, const char * command=0x0026f9d8, int
  length=71, int flags=0)  Line 3381 + 0x1bC
  tcl85tg.dll!Tcl_EvalEx(Tcl_Interp * interp=0x01145488,
  const char * script=0x0026f9d8, int numBytes=71, int
  flags=0)  Line 3789 + 0x27C
  tcl85tg.dll!Tcl_Eval(Tcl_Interp * interp=0x01145488,
  const char * script=0x0026f9d8)  Line 3904 + 0x11C
  tcl85tg.dll!Tcl_GlobalEval(Tcl_Interp *
  interp=0x01145488, const char * command=0x0026f9d8) 
  Line 4796 + 0xdC
  tk85tg.dll!Tk_BindEvent(Tk_BindingTable_ *
  bindingTable=0x011dc580, _XEvent * eventPtr=0x0026fbb0,
  Tk_Window_ * tkwin=0x03f3b3f0, int numObjects=0, void *
  * objectPtr=0x0026fafc)  Line 1771 + 0x19C
  tk85tg.dll!TkBindEventProc(TkWindow *
  winPtr=0x03f3b3f0, _XEvent * eventPtr=0x0026fbb0)  Line
  286 + 0x1fC
  tk85tg.dll!Tk_HandleEvent(_XEvent *
  eventPtr=0x0026fbb0)  Line 1425 + 0xdC
  tk85tg.dll!Tk_DestroyWindow(Tk_Window_ *
  tkwin=0x03f3b3f0)  Line 1383 + 0x9C
  tk85tg.dll!TkWmProtocolEventProc(TkWindow *
  winPtr=0x03f3b3f0, _XEvent * eventPtr=0x0136c2a0)  Line
  6453 + 0x9C
  tk85tg.dll!Tk_HandleEvent(_XEvent *
  eventPtr=0x0136c2a0)  Line 1393 + 0xdC
  tk85tg.dll!WindowEventProc(Tcl_Event *
  evPtr=0x0136c298, int flags=-3)  Line 1821 + 0xcC
  tcl85tg.dll!Tcl_ServiceEvent(int flags=-3)  Line 644
  + 0xdC
  tcl85tg.dll!Tcl_DoOneEvent(int flags=-3)  Line 947 + 0x9C
  tk85tg.dll!Tk_MainLoop()  Line 2150 + 0xfC
  tk85tg.dll!Tk_MainEx(int argc=-1, char * *
  argv=0x00ac2e80, int (Tcl_Interp *)*
  appInitProc=0x004010f3, Tcl_Interp * interp=0x00ac6298)
   Line 309C
  wish85tg.exe!WinMain(HINSTANCE__ *
  hInstance=0x00400000, HINSTANCE__ *
  hPrevInstance=0x00000000, char *
  lpszCmdLine=0x00292342, int nCmdShow=10)  Line 125 + 0x25C
  wish85tg.exe!WinMainCRTStartup()  Line 330 + 0x36C


tkt_uuid: 571600ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4a5
resolution: Fixed
title: new wm bug with geometry in 8.4a5
comment:
  The latest 'wm' modifications have brought in a 
  new bug on Windows (Win2000 at least).

  proc test {} {
      catch {destroy .foo}
      toplevel .foo
      wm withdraw .foo
      wm geometry .foo 510x684+2+40
      wm deiconify .foo
      raise .foo
  }

  this procedure ignores the geometry specification 
  that has been given to the window.  In fact we can 
  reduce the above test to:

  proc test {} {
      catch {destroy .foo}
      toplevel .foo
      wm geometry .foo 510x684+2+40
  }

  Tk 8.3 and older versions of Tk 8.4 did not show 
  this bug.


tkt_uuid: 2912356fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.6b1
resolution: Fixed
title: ttk::sizegrip behaviour is wrong in compiz
comment:
  The default behaviour of ttk::sizegrip on compiz is not right. The window manager seems to reposition the window on every <Configure> event, and the toplevel start jumping to the lower left corner of the screen when the grip is dragged.
  Other toolkits uses the _NET_WM_MOVERESIZE message as specified in http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551196 to get the "right" behaviour.
  As a workaround, the patch in http://paste.tclers.tk/1890 improves things a bit. 


tkt_uuid: 220794ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: Mac: tk_getSaveFile default filename is illegal
comment:
  OriginalBugID: 1466 Bug
  Version: 8.1a2
  SubmitDate: '1999-03-08'
  LastModified: '1999-11-30'
  Severity: MED
  Status: Assigned
  Submitter: pat
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: 8.0
  Machine: Power PC


  Name: Andy Rushton

  ReproducibleScript:
  set response [tk_getSaveFile -initialfile "webget" -parent $win -title
  "Save where"]

  ObservedBehavior:
  The default filename gets a leading ':' which if chosen leads to an
  illegal path to the file

  e.g. the file comes out as :webget in the dialog and the return value
  is:
      Mydisk:data::webget

  The extra colon is incorrect

  DesiredBehavior:
  No leading colon


  This is indeed the case, although it seems to just make the mistake
  of putting the file one dir up (:: is like ../). 
  -- 11/30/1999 hobbs


tkt_uuid: 3310586fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: Doubleclicks generated at any speed
comment:
  If you use 'event generate' to send mouse button events to a widget, all but the first come out as doubleclicks, no matter what the time interval between them. You only get another single click after a real click. e.g.,
  % pack [canvas .c]
  % bind .c <Button-1> {puts aah}
  % bind .c <Double-1> {puts ooh}
  % event generate .c <Button-1>
  aah
  % # now wait a bit
  % event generate .c <Button-1>
  ooh
  % # now wait a bit
  % event generate .c <Button-1>
  ooh
  % # now actually click in .c
  % aah
  # now doubleckick in .c
  % aah
  ooh
  event generate .c <Button-1>
  aah


tkt_uuid: 570764ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 8
foundin: obsolete: 8.4a5
resolution: Fixed
title: Withdrawn transients resurrected
comment:
  # The following demonstrates the problem;
  # enter interactively at the wish prompt

  toplevel .t ; wm transient .t .
  wm withdraw .t

  # Here, .t is withdrawn.
  wm iconify .   ;# Or use window manager controls ...
  wm deiconify . ;# ... ditto

  # .t reappears!  This should not happen

  --

  This happens on Unix/X11.

  Jeff reports that it also happens on Windows, and also
  affects the dropdown listbox for comboboxes.


tkt_uuid: 1217092fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 6
foundin: obsolete: 8.5a4
resolution: Works For Me
title: compile error in tkWinX.c
comment:
  With VC++ 6.2 and latest cvs head:

          cl -DBUILD_tk -Oti -nologo -c -YX
  -Fp.\Release\tk_Dynamic\ -W3 -QI0f -MD
   -I"..\win" -I"..\generic" -I"..\bitmaps" -I"..\xlib" 
  -I "..\..\cvs-tcl\win" -I
   "..\..\cvs-tcl\generic"
  -DTCL_CFGVAL_ENCODING=\"cp1252\" -DTCL_CFG_OPTIMIZED -D
  USE_TCL_STUBS -Fo.\Release\tk_Dynamic\
  @C:\DOCUME~1\VinceD\LOCALS~1\Temp\nma0243
  6.
  tkWinX.c
  ..\win\tkWinX.c(1930) : error C2065: 'ULONG_PTR' :
  undeclared identifier
  ..\win\tkWinX.c(1930) : error C2064: term does not
  evaluate to a function
  NMAKE : fatal error U1077: 'cl' : return code '0x2'
  Stop.


tkt_uuid: 645342ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 9 Immediate
foundin: obsolete: 8.4.1
resolution: Fixed
title: canvas create image w/no args segfault
comment:
  The following script causes a segmentation fault on Linux, using the latest ActiveTcl release, as well as the latest tk 8.4 from CVS:

  canvas .c
  uplevel 0 .c create image

  Platform:
   uname -a
  Linux tallniel 2.4.19-4GB #1 Mon Oct 14 22:11:39 UTC 2002 i686 unknown
  neil@tallniel:~/tk/unix> wish
  % parray tcl_platform
  tcl_platform(byteOrder) = littleEndian
  tcl_platform(machine)   = i686
  tcl_platform(os)        = Linux
  tcl_platform(osVersion) = 2.4.19-4GB
  tcl_platform(platform)  = unix
  tcl_platform(user)      = neil
  tcl_platform(wordSize)  = 4

  GDB backtrace:
  #0  0x4018bfb0 in Tcl_GetStringFromObj () from /usr/lib/libtcl8.4.so
  #1  0x400a90ca in CreateImage (interp=0x804a080, canvas=0x80e4020,
      itemPtr=0x80e5108, argc=0, argv=0x8094194)
      at /home/neil/tk/generic/tkCanvImg.c:177
  #2  0x4009c55e in CanvasWidgetCmd (clientData=0x80e4020, interp=0x804a080, argc=3,
      argv=0x8094188) at /home/neil/tk/generic/tkCanvas.c:959
  #3  0x4013f326 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
  #4  0x4013f78d in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so
  #5  0x4014050b in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so
  #6  0x401957e9 in Tcl_UplevelObjCmd () from /usr/lib/libtcl8.4.so
  #7  0x4013f326 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
  #8  0x401654af in TclExecuteByteCode () from /usr/lib/libtcl8.4.so
  #9  0x40164a4e in TclCompEvalObj () from /usr/lib/libtcl8.4.so
  #10 0x40140532 in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so
  #11 0x40172114 in Tcl_RecordAndEvalObj () from /usr/lib/libtcl8.4.so
  #12 0x40171fdd in Tcl_RecordAndEval () from /usr/lib/libtcl8.4.so
  #13 0x4004ccd3 in StdinProc (clientData=0x8080460, mask=2)
      at /home/neil/tk/generic/tkMain.c:355
  #14 0x4017aae3 in Tcl_NotifyChannel () from /usr/lib/libtcl8.4.so
  #15 0x401ad322 in FileHandlerEventProc () from /usr/lib/libtcl8.4.so
  #16 0x4018b478 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so
  #17 0x4018b7c6 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so
  #18 0x4003da82 in Tk_MainLoop () at /home/neil/tk/generic/tkEvent.c:1457
  #19 0x4004cae7 in Tk_MainEx (argc=1, argv=0xbffff4c4,
      appInitProc=0x804874e <Tcl_AppInit>, interp=0x804a080)
      at /home/neil/tk/generic/tkMain.c:284
  #20 0x08048741 in main (argc=1, argv=0xbffff4c4)
      at /home/neil/tk/unix/tkAppInit.c:68
  #21 0x402fe4a2 in __libc_start_main () from /lib/libc.so.6


tkt_uuid: 2874745fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: TEA 3.6 incompatible TK_INCLUDE_SPEC define
comment:
  TEA 3.6 defines  the include path to the Tk header files in TK_INCLUDES .  The Tk configuration file tkConfig.sh does not define TK_INCLUDES but rather TK_INCLUDE_SPEC.  As a result, compiles with TEA 3.6 fail for extensions that want to see TK_INCLUDE in the Makefile.in file. An example that uses TEA 3.6 is itclwidgets4.0.  Solution is to define both in the tkConfig.sh  and update the tcl.m4 file associated with TEA 3.6 to AC_SUBST both.  


tkt_uuid: 1854913fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: Fixed
title: [.txt delete] deletes before startindex
comment:
  Consider following code:
    pack [text .t]
    .t insert end abcd\n
    .t delete 2.0 end

  One would expect that the delete operation would do nothing, since 2.0 is the end of the text. However, it deletes the newline *before* index 2.0.
  In interactive mode, this shows up as the <Delete> key deleting backwards when it's at the end of the text.

  The reason lies withing the DeleteIndexRange() function in tkText.c, which contains the following comment:
      /*
       * The code below is ugly, but it's needed to make sure there is always a
       * dummy empty line at the end of the text. If the final newline of the
       * file (just before the dummy line) is being deleted, then back up index
       * to just before the newline. If there is a newline just before the first
       * character being deleted, then back up the first index too, so that an
       * even number of lines gets deleted. Furthermore, remove any tags that
       * are present on the newline that isn't going to be deleted after all
       * (this simulates deleting the newline and then adding a "clean" one back
       * again). Note that index1 and index2 might now be equal again which
       * means that no text will be deleted but tags might be removed.
       */

  However, I really do not see the reason for the "...so that an even number of lines gets the deleted..." part. As if it shouldn't be possible to delete an odd number of lines!? I propose to remove that part of the comment (and the accompanying code). This fixes the bug, and I didn't see any adverse effects.


tkt_uuid: 2816150fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: Rotated text displays incorrectly on WinXP
comment:
  Run this script:
  ---
  canvas .c
  grid .c 
  set id [.c create text 200 100 -text "Angled text" -angle 15 -font {Courier 42}]
  for {set f 40} {$f>20} {incr f -2} {
      .c itemconfigure $id -font "Courier $f"
      update
      }
  ---
  I see traces of bigger fonts in window. They dissapear on resizing it.


tkt_uuid: 1143776fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a3
resolution: Fixed
title: Panic: Added too many new lines in UpdateDisplayInfo
comment:
  The current cvs head contains a bug in the text widget
  that causes a panic with the message "Added too many
  new lines in UpdateDisplayInfo". I can reproduce this
  consitently on Linux, using Donal's text justification
  demo: http://www.man.ac.uk/~zzcgudf/tcl/wordwrap.tcl

  Run the demo in wish and then move the scrollbar on the
  text widget to show the last line - this causes the
  panic for me. Basic stack trace:

  (gdb) bt
  #0  0x403b5d71 in kill () from /lib/i686/libc.so.6
  #1  0x403b5af5 in raise () from /lib/i686/libc.so.6
  #2  0x403b71e0 in abort () from /lib/i686/libc.so.6
  #3  0x401754d8 in Tcl_PanicVA () from
  /usr/local/lib/libtcl8.5.so
  #4  0x40175500 in Tcl_Panic () from
  /usr/local/lib/libtcl8.5.so
  #5  0x400c6129 in UpdateDisplayInfo () from
  /usr/local/lib/libtk8.5.so
  #6  0x400cb2be in TkTextPixelIndex () from
  /usr/local/lib/libtk8.5.so
  #7  0x400d2d8b in TkTextPickCurrent () from
  /usr/local/lib/libtk8.5.so
  #8  0x400c83a6 in DisplayText () from
  /usr/local/lib/libtk8.5.so
  #9  0x401891ba in TclServiceIdle () from
  /usr/local/lib/libtcl8.5.so
  #10 0x40172f96 in Tcl_DoOneEvent () from
  /usr/local/lib/libtcl8.5.so
  #11 0x4003cd7d in Tk_MainLoop () from
  /usr/local/lib/libtk8.5.so
  #12 0x400494af in Tk_MainEx () from
  /usr/local/lib/libtk8.5.so
  #13 0x0804886e in main ()
  #14 0x403a2c57 in __libc_start_main () from
  /lib/i686/libc.so.6


tkt_uuid: 220783ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 6
foundin: obsolete: 8.0.3
resolution: Fixed
title: [BITMAP config -maskdata $data] doesn't work
comment:
  OriginalBugID: 970 Bug
  Version: 8.0.3
  SubmitDate: '1998-12-15'
  LastModified: '1999-08-15'
  Severity: MED
  Status: Assigned
  Submitter: welch
  ChangedBy: hobbs
  OS: Linux-Red Hat
  Machine: Other


  Name:

  D. Richard Hipp



  CustomShell:

  Plus/Dash patches



  ReproducibleScript:

  image create bitmap t1 -data $data -maskdata $data -background red

  label .x -image t1

  pack .x

  update

  t1 config -maskdata $NewMaskData







  ObservedBehavior:

  The new mask specified by the "configure" does not

  take effect.







  DesiredBehavior:

  I expect the mask to change.  Here's a workaround:



      t1 config -maskdata {}

      t1 config -maskdata $NewMaskData



  The problem results from a unfortunate interaction between the

  XID allocator and the Tk_GetGC allocator.







  Patch:

  *** tkImgBmap.c.orig    Mon Dec  7 17:45:41 1998

  --- tkImgBmap.c Mon Dec  7 18:11:49 1998

  ***************

  *** 353,358 ****

  --- 353,359 ----

        XGCValues gcValues;

        GC gc;

        unsigned int mask;

  +     Pixmap oldMask;

    

        /*

         * For each of the options in masterPtr, translate the string

  ***************

  *** 395,410 ****

                  (unsigned) masterPtr->height);

        }

    

  !     if (instancePtr->mask != None) {

  !       Tk_FreePixmap(Tk_Display(instancePtr->tkwin), instancePtr->mask);

  !       instancePtr->mask = None;

  !     }

        if (masterPtr->maskData != NULL) {

          instancePtr->mask = XCreateBitmapFromData(

                  Tk_Display(instancePtr->tkwin),

                  RootWindowOfScreen(Tk_Screen(instancePtr->tkwin)),

                  masterPtr->maskData, (unsigned) masterPtr->width,

                  (unsigned) masterPtr->height);

        }

    

        if (masterPtr->data != NULL) {

  --- 396,418 ----

                  (unsigned) masterPtr->height);

        }

    

  !     /*

  !      * Careful:  We have to allocate a new mask Pixmap before deleting

  !      * the old one.  Otherwise, The XID allocator will always return

  !      * the same XID for the new Pixmap as was used for the old Pixmap.

  !      * And that will prevent the mask from changing in the GC below.

  !      */

  !     oldMask = instancePtr->mask;

  !     instancePtr->mask = None;

        if (masterPtr->maskData != NULL) {

          instancePtr->mask = XCreateBitmapFromData(

                  Tk_Display(instancePtr->tkwin),

                  RootWindowOfScreen(Tk_Screen(instancePtr->tkwin)),

                  masterPtr->maskData, (unsigned) masterPtr->width,

                  (unsigned) masterPtr->height);

  +     }

  +     if (oldMask != None) {

  +       Tk_FreePixmap(Tk_Display(instancePtr->tkwin), oldMask);

        }

    

        if (masterPtr->data != NULL) {









  PatchFiles:

  tkImgBmap.c









  This fix is a quick hack.  We really need to think long and hard about a
  better way to fix the interaction between AllocXId() and Tk_GetGC().

  It also seems like the same bitmap could be shared across multiple
  image instances, at least on the same display.  Is there any particular
  reason why this optimization is not done?

  02/03/1999 17:17 - stanton - I have applied the suggested patch, but the fundamental problem still exists.  The core issue is that Tk_GetGC doesn't notice when an XID is reused for a different object of the same type, so it will return a stale GC.


tkt_uuid: 219927ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Duplicate
title: X Error of failed request: BadWindow (invalid Window parameter)
comment:
  OriginalBugID: 1355 Bug
  Version: 8.0p2
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-14'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 716
  OS: Linux-Red Hat
  Machine: Other
  ClosedDate: '1999-08-14'


  Name:
  Danny Bach

  Extensions:
  Tix4.1 and DP4.0

  CustomShell:
  No

  ReproducibleScript:
  crash under RedHat Linux 5.0 with tk8.0p2, and RedHat Linux 5.2 with tk8.0.3.
  It happens fairly often after clicking on buttons from the GUI



  ObservedBehavior:
  Program aborts with the following message
  X Error of failed request: BadWindow (invalid Window parameter)
  Major opcode of failed request: 40 (X_TranslateCoords)


tkt_uuid: 220752ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: add nmake support for NT/Alpha
comment:
  OriginalBugID: 5939 RFE
  Version: 8.4a1
  SubmitDate: '2000-06-22'
  LastModified: '2000-07-20'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 5938
  OS: Windows NT
  Machine: Compaq/Digital Alpha XL300
  FixedDate: '2000-07-20'
  FixedInVersion: 8.4a2
  ClosedDate: '2000-07-19'


  Name:
  Don Porter

  CVS:
  $Id: makefile.vc,v 1.34 2000/05/03 00:18:37 hobbs Exp $

  DesiredBehavior:
  Add lines to makefile.vc so that a simple edit
  enables building on NT/Alpha.

  Patch:
  Index: win/makefile.vc
  ===================================================================
  RCS file: /cvsroot/tk/win/makefile.vc,v
  retrieving revision 1.34
  diff -c -r1.34 makefile.vc
  *** makefile.vc 2000/05/03 00:18:37     1.34
  --- makefile.vc 2000/06/22 21:10:24
  ***************
  *** 31,40 ****
  --- 31,44 ----
    
    # Set this to the appropriate value of /MACHINE: for your platform
    MACHINE       = IX86
  + #MACHINE = ALPHA
    
    !IF "$(MACHINE)" == "IA64"
    TOOLS32               = c:\ia64sdk17
    TOOLS32_rc    = c:\ia64sdk17
  + !ELSE IF "$(MACHINE)" == "ALPHA"
  + TOOLS32         = C:\Progra~1\Micros~2\vc98
  + TOOLS32_rc      = C:\Progra~1\Micros~2\common\MSDev98
    !ELSE
    TOOLS32               = c:\Progra~1\devstudio\vc
    TOOLS32_rc    = c:\Progra~1\devstudio\sharedide

  PatchFiles:
  makefile.vc



  Is an exact duplicate of 5938 

  Integrated 

  -- 07/19/2000 shawn

  Oops, this is not a duplicate as I originally thought; this patch is for Tk, 5938 was for Tcl.  I have applied this patch to the CVS repository.  Thanks for pointing this out, Don, and for submitting the patches!

     Eric Melski                            The Other Tcl Guy
     ericm at ajubasolutions.com            Ajuba Solutions

  -- 07/20/2000 ericm


tkt_uuid: 3003353fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 7 High
foundin: obsolete: 8.5.8
resolution: Fixed
title: crasher in unix/tkUnixWm.c UpdatePhotoIcon
comment:
  I'm developing coccinella on OpenBSD, and wanted to try the port on other architectures than i386. 
  So I tried on OpenBSD 4.7 sparc64, or OpenBSD -current mips64, and I get random crashes with the following, and similar backtraces:

  Program received signal SIGSEGV, Segmentation fault.                                                                                                                                                                                                                               
  0x0000000057292780 in _XData32 () from /usr/X11R6/lib/libX11.so.12.0                                                                                                                                                                                                               
  (gdb) bt                                                                                                                                                                                                                                                                           
  #0  0x0000000057292780 in _XData32 () from /usr/X11R6/lib/libX11.so.12.0                                                                                                                                                                                                           
  #1  0x000000005725fafc in XChangeProperty () from /usr/X11R6/lib/libX11.so.12.0                                                                                                                                                                                                    
  #2  0x000000005b89b99c in UpdatePhotoIcon () from /usr/local/lib/libtk85.so.0.5                                                                                                                                                                                                    
  #3  0x000000005b894428 in TkWmMapWindow () from /usr/local/lib/libtk85.so.0.5                                                                                                                                                                                                      
  #4  0x000000005b7ddc44 in Tk_MapWindow () from /usr/local/lib/libtk85.so.0.5                                                                                                                                                                                                       
  #5  0x000000005ac39a70 in _ftext () from /usr/local/lib/tktray1.2/libtktray12.so.0.0                                                                                                                                                                                               
  #6  0x0000000000000001 in ?? ()                                                                                                                                                                                                                                                    
  Cannot access memory at address 0xfffffffffffffffe 


  static void
  UpdatePhotoIcon(
      TkWindow *winPtr)
  {                    
      WmInfo *wmPtr = winPtr->wmInfoPtr;
      unsigned char *data = wmPtr->iconDataPtr;
      int size = wmPtr->iconDataSize;          

      if (data == NULL) {
          data = winPtr->dispPtr->iconDataPtr;
          size = winPtr->dispPtr->iconDataSize;
      }                                        
      if (data != NULL) {                      
          /*                                   
           * Set icon:                         
           */                                  

          XChangeProperty(winPtr->display, wmPtr->wrapperPtr->window,
                  Tk_InternAtom((Tk_Window) winPtr, "_NET_WM_ICON"), 
                  XA_CARDINAL, 32, PropModeReplace,                  
                  (unsigned char *) data, size);                     
      }                                                              
  }

  Searching google for XChangeProperty, or _XData32 I found a lot of similar bug reports with similar backtraces in other applications, which was not considered a bug in Xorg, but in the application, in the call to XChangeProperty. This seems to be a 64Bit problem.

  On OpenBSD 4.6 i386, I do not have that problem, there everything works perfectly. 
  I'll try to install and run it on my other 32Bit systems, a sparc and vax in the next couple of days, but I guess there the problem will also not show up.


tkt_uuid: 2958768fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: error immediately destroying interpreter
comment:
  If an interpreter is created and then immediately destroyed, an error occurs:
  % interp eval [interp create] { package require Tk; destroy . }
  % can't invoke "event" command:  application has been destroyed
      while executing
  "event generate $w <<ThemeChanged>>"
      (procedure "ttk::ThemeChanged" line 6)
      invoked from within
  "ttk::ThemeChanged"


tkt_uuid: 220662ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: Font in Wish and Console unreadable
comment:
  OriginalBugID: 4078 Bug
  Version: 8.2.1
  SubmitDate: '2000-01-24'
  LastModified: '2000-01-24'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: Mac OS 8.6
  Machine: Power Computing Power Center Pro 210
  FixedDate: '2000-01-24'
  FixedInVersion: 8.3b2


  Name:
  Paul Lujan

  CVS:
  1/24/00

  ReproducibleScript:
  The fonts on the Wish and Console windows are almost unreadable. The font in the Shell window is fine. I have tried to 
  change the system fonts, but this does not help.  I have also redownload TCL 8.2.1 to make sure its not corrupted.
  I am opperating using Mac OS 8.6. 

  I have read all the documentation on your web site that may relate to this with no luck 
  Please help.



  There was a problem with font choosing in Mac Tk for 8.2.1 that
  has been fixed in the 8.3b2 source code. 
  -- 01/24/2000 hobbs


