# ticket

tkt_uuid: 578238ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Additions to ::tk::unsup::MacWindowStyle
comment:
  Adds noActivates and noUpdates to
  ::tk::unsupported::MacWindowStyle

  It was possible to get these values while querying the
  style of a window, but not to set them.

  Also, tool tips work really well with "help noActivates"


tkt_uuid: 578569ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: iconified windows won't get drawn
comment:
  using the following script with parameter iconify
  produces an empty window with *no* label and *no*
  buttons inside !
   
  #!/bin/sh
  # the next line restarts using wish \
  exec wish "$0" "$@"
   
  # Parameter : iconify - starts new toplevel inconified
  # Parameter : withdraw - starts new toplevel withdrawn
   
  proc noclose win {
      wm protocol $win WM_DELETE_WINDOW { }
      wm resizable $win 0 0
      bind $win <Unmap> "wm deiconify $win"
  }
   
      wm withdraw .
   
      set w .pw
      toplevel $w
      wm $argv $w
      wm title $w "Toplevel"
      label $w.l -font {helvetica 18 bold} -text "Test
  Toplevel"
      frame $w.b
      button $w.b.ca -text Cancel -command "set r 0"
      button $w.b.ok -text OK -command {set r 1} -default
  active
      pack $w.b.ca $w.b.ok -side left -padx 2m
      bind $w <Return> "$w.b.ok invoke"
     grid $w.l -row 0
      grid $w.b -row 1
      update idletasks
      wm geometry $w +100+100
      wm deiconify $w
      noclose $w
      tkwait variable r
      destroy $w
      exit
   
   
  --- using this script under linux with fvwm produces an
  empty window. I sent a bug report to the fvwm mailing
  list an go the following response:
  On Tue, Jul 02, 2002 at 01:34:45AM +0200, Dominik Vogt
  wrote:
  > On Mon, Jul 01, 2002 at 08:33:18PM +0200, Gerhard
  Hintermayer wrote:> >
  > > Dominik Vogt wrote:
  > > >
  > > > Okay, it took me quite some hours to figure this
  out: It's *not*
  > > > a problem with fvwm. Although you can't see it,
  the application
  > > > window *is* mapped. It's just that tk thinks it
  is not visible
  > > > and thus does not draw anything into it. I
  couldn't find
  > > > anything that fvwm is doing wrong. Actually, I
  couldn't even
  > > > find any difference in the requests that wish
  sends to fvwm -
  > > > regardless if the deiconify line is in the code
  or not. I think
  > > > there must be a bug in wish.
  > > >
  > >
  > > Could it be the case,that fvwm>2.2.5 delivers
  events to "wish" as a different
  > > type. The update command distinguishes between all
  events (no parameter) and> > idle callbacks (parameter
  idletasks). Using no parameter for the update there
  > > are no problems (if I remember correctly), but that
  aim't no the way to go.
  > > Seems like good old 2.2.5 delivers events the do
  get processed as idle
  > > callbacks, whereas all follow versions don't. I
  have to take a look at the tcl
  > > sources to get an idea, which event's are put into
  which category.
  >
  > Fvwm does not send any events to the application
  (well, almost,
  > there are some cases, but these don't play a role here).
  I am mistaken here. These events do play a role. For
  some reason
  (I think to make some other application happy when it
  starts as an
  icon), I forced an UnmapNotify event being sent to the
  application
  before the icon was created. I'm mystified as to why
  wish thinks
  the UnmapNotify negates the MapNotify that arrives later.
  Maybe it processes events out of their proper order.
  Anyway, I've
  added a faked MapNotify event that is sent right before the
  UnmapNotify, and wish seems to be happy now.
   
  Please consider reporting this problem to the wish
  developers. I
  still think it's a bug in there that may well show
  other symptoms.
  In general processing events out of order - especially
  events
  that are of related types like MapNotify and
  UnmapNotify - is
  dangerous. It usually works as long as not much is
  happening on
  the desktop, but when things get really busy it may cause
  problems.
   
  Bye
   
  Dominik ^_^ ^_^
   
  --
  Dominik Vogt, dominik.vogt@gmx.de
   
   
  So there seems to be a problem with wish handling
  window events. If I do an update instead of the update
  idletasks, everything is fine, but that's not the way
  this (window center, popup under mouse, popup at fixed
  position) should be done.
   
  Gerhard


tkt_uuid: 578654ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Canvas lines -smooth config problem
comment:
  Tcl bug 571682 (submitted by someone to the wrong
  project) can really described as a complaint that the
  following code doesn't work:

    pack [canvas .c]
    .c create line 0 0 0 2 2 2 -smooth 1 -tag src
    set s [.c itemcget src -smooth]
    .c create line 1 1 1 3 3 3 -smooth $s

  Problem is that although -smooth accepts only boolean
  values for -smooth at the moment, "-smooth 1" gets
  reported back as "bezier".  The problem (in
  tkCanvUtil.c) is that tkBezierSmoothMethod is not part
  of the "smoothMethod" assoc-data (maybe a missing init
  funcion?)

  The documentation in canvas.n needs updating too.


tkt_uuid: 579651ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: leftover assert in tkFont.c
comment:
  While chasing the origin of static strings in the compiled 
  binaries, I saw that there is one in tkFont.c, generated by 
  a call to assert(). 
   
  SInce it's the only one, I suggest removing it.  


tkt_uuid: 579879ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: Photo Masters: use Tcl_AttemptAlloc()?
comment:
  Photo masters should use Tcl_AttemptAlloc(),
  particularly when the amount of memory being asked for
  is large (perhaps over 1MB as an arbitrary threshold?)
  as the failure to allocate a large chunk of memory
  doeesn't mean that Tcl can't recover from the problem
  by reporting an error message back to the script level.


tkt_uuid: 580362ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Fixed
title: isDirty flag not updated during undo
comment:
  Since the tkUndo.c-related changes to tkText.c, the 
  isDirty flag is no longer decremented when undoing an 
  edit. Previously the isDirtyIncrement was set to -1 during 
  undo.


tkt_uuid: 581560ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: canvas scan with no other args
comment:
  % canvas .cv
  .cv
  % .cv scan
  bad scan option ".cv scan
  ": must be mark or dragto
  % info patchlevel
  8.3.4
  % array get tcl_platform
  osVersion 2.4.17 byteOrder littleEndian machine i686 
  platform unix os Linux
  user wan
  % .cv scan foo
  bad scan option "foo": must be mark or dragto

  This is a bug in tkCanvas.c (access to argv[2] without 
  prior checking of
  argc).


tkt_uuid: 581627ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4b2
resolution: Fixed
title: 35 tests fail (up from 14)
comment:
  On Windows 2000, the latest tk build fails 94 
  tests.  A few weeks back (see bug 571563) this was 
  down to 14 but something (test suite changes 
  recently?) has caused a lot to fail.

  There is also a hang in unixWm.test (should this be 
  running on Windows?) where the user has to 
  manually tearoff a menu for the test to proceed.

  null
  ---- Result should have been (exact matching):
  44
  ==== send-10.4 FAILED


  ==== send-10.5 SendEventProc procedure, 
  extraneous command options FAILED
  ==== Contents of test case:

      testsend prop comm Comm  "c\n-n tktest\n-x 
  miscellanous\n-y who knows?\n-s s
  et a new\n"
      set a null
      update
      set a

  ---- Result was:
  null
  ---- Result should have been (exact matching):
  new
  ==== send-10.5 FAILED


  ==== send-10.6 SendEventProc procedure, 
  unknown interpreter FAILED
  ==== Contents of test case:

      testsend prop [winfo id .f] Comm {}
      testsend prop comm Comm  "c\n-n unknown\n-
  r $id 44\n-s set a new\n"
      set a null
      update
      list [testsend prop [winfo id .f] Comm] $a

  ---- Result was:
  {} null
  ---- Result should have been (exact matching):
  {
  r
  -s 44
  -r receiver never heard of interpreter "unknown"
  -c 1
  } null
  ==== send-10.6 FAILED


  ==== send-10.7 SendEventProc procedure, error in 
  script FAILED
  ==== Contents of test case:

      testsend prop [winfo id .f] Comm {}
      testsend prop comm Comm  "c\n-n tktest\n-r 
  $id 62\n-s foreach i {1 2 3} {err
  or {test error} {Initial errorInfo} {test code}}\n"
      update
      testsend prop [winfo id .f] Comm

  ---- Result was:

  ---- Result should have been (exact matching):

  r
  -s 62
  -r test error
  -i Initial errorInfo
      ("foreach" body line 1)
      invoked from within
  "foreach i {1 2 3} {error {test error} {Initial errorInfo} 
  {test code}}"
  -e test code
  -c 1

  ==== send-10.7 FAILED


  ==== send-10.8 SendEventProc procedure, 
  exceptional return FAILED
  ==== Contents of test case:

      testsend prop [winfo id .f] Comm {}
      testsend prop comm Comm  "c\n-n tktest\n-r 
  $id 62\n-s break\n"
      update
      testsend prop [winfo id .f] Comm

  ---- Result was:

  ---- Result should have been (exact matching):

  r
  -s 62
  -r
  -c 3

  ==== send-10.8 FAILED


  ==== send-10.9 SendEventProc procedure, empty 
  return FAILED
  ==== Contents of test case:

      testsend prop [winfo id .f] Comm {}
      testsend prop comm Comm  "c\n-n tktest\n-r 
  $id 62\n-s concat\n"
      update
      testsend prop [winfo id .f] Comm

  ---- Result was:

  ---- Result should have been (exact matching):

  r
  -s 62
  -r

  ==== send-10.9 FAILED


  ==== send-10.13 SendEventProc procedure, return 
  processing FAILED
  ==== Contents of test case:

      testsend prop comm Comm  "r\n-c 1\n-e test1
  \n-i test2\n-r test3\n-s [testsen
  d serial]\n"
      list [catch {send dummy foo} msg] $msg 
  $errorInfo $errorCode

  ---- Result was:
  1 {invalid command name "send"} {invalid command 
  name "send"
      while executing
  "send dummy foo"} NONE
  ---- Result should have been (exact matching):
  1 test3 {test2
      invoked from within
  "send dummy foo"} test1
  ==== send-10.13 FAILED


  ==== send-10.14 SendEventProc procedure, 
  extraneous return options FAILED
  ==== Contents of test case:

      testsend prop comm Comm  "r\n-x test1\n-y 
  test2\n-r result\n-s [testsend ser
  ial]\n"
      list [catch {send dummy foo} msg] $msg

  ---- Result was:
  1 {invalid command name "send"}
  ---- Result should have been (exact matching):
  0 result
  ==== send-10.14 FAILED


  ==== send-10.15 SendEventProc procedure, serial 
  number FAILED
  ==== Contents of test case:

      testsend prop comm Comm  "r\n-r response\n"
      list [catch {send dummy foo} msg] $msg

  ---- Result was:
  1 {invalid command name "send"}
  ---- Result should have been (exact matching):
  1 {target application died or uses a Tk version 
  before 4.0}
  ==== send-10.15 FAILED


  ==== send-10.16 SendEventProc procedure, serial 
  number FAILED
  ==== Contents of test case:

      testsend prop comm Comm  "r\n-r 
  response\n\n-s 0"
      list [catch {send dummy foo} msg] $msg

  ---- Result was:
  1 {invalid command name "send"}
  ---- Result should have been (exact matching):
  1 {target application died or uses a Tk version 
  before 4.0}
  ==== send-10.16 FAILED


  ==== send-10.17 SendEventProc procedure, 
  errorCode and errorInfo FAILED
  ==== Contents of test case:

      testsend prop comm Comm  "r\n-i test1\n-e 
  test2\n-c 4\n-s [testsend serial]\
  n"
      set errorCode oldErrorCode
      set errorInfo oldErrorInfo
      list [catch {send dummy foo} msg] $msg 
  $errorInfo $errorCode

  ---- Result was:
  1 {invalid command name "send"} {invalid command 
  name "send"
      while executing
  "send dummy foo"} NONE
  ---- Result should have been (exact matching):
  4 {} oldErrorInfo oldErrorCode
  ==== send-10.17 FAILED


  ==== send-10.18 SendEventProc procedure, send 
  kills application FAILED
  ==== Contents of test case:

      setupbg
      dobg {tk appname t_s_3}
      set x [list [catch {send t_s_3 destroy .} msg] 
  $msg]
      cleanupbg
      set x

  ---- Result was:
  1 {invalid command name "send"}
  ---- Result should have been (exact matching):
  0 {}
  ==== send-10.18 FAILED


  ==== send-10.19 SendEventProc procedure, send 
  exits FAILED
  ==== Contents of test case:

      setupbg
      dobg {tk appname t_s_3}
      set x [list [catch {send t_s_3 exit} msg] $msg]
      cleanupbg
      set x

  ---- Result was:
  1 {invalid command name "send"}
  ---- Result should have been (exact matching):
  1 {target application died}
  ==== send-10.19 FAILED


  ==== send-11.1 AppendPropCarefully and 
  AppendErrorProc procedures FAILED
  ==== Contents of test case:

      testsend prop root InterpRegistry "0x21447 
  dummy\n"
      list [catch {send dummy foo} msg] $msg

  ---- Result was:
  1 {invalid command name "send"}
  ---- Result should have been (exact matching):
  1 {no application named "dummy"}
  ==== send-11.1 FAILED


  ==== send-12.1 TimeoutProc procedure FAILED
  ==== Contents of test case:

      testsend prop root InterpRegistry "$id dummy\n"
      list [catch {send dummy foo} msg] $msg

  ---- Result was:
  1 {invalid command name "send"}
  ---- Result should have been (exact matching):
  1 {target application died or uses a Tk version 
  before 4.0}
  ==== send-12.1 FAILED


  ==== send-12.2 TimeoutProc procedure FAILED
  ==== Contents of test case:

      winfo interps
      tk appname tktest
      update
      setupbg
      set app [dobg {
          after 10 {after 10 {after 5000; exit}}
          tk appname
      }]
      after 200
      set result [list [catch {send $app foo} msg] $msg]
      cleanupbg
      set result

  ---- Result was:
  1 {invalid command name "send"}
  ---- Result should have been (exact matching):
  1 {target application died}
  ==== send-12.2 FAILED


  ==== send-13.1 DeleteProc procedure FAILED
  ==== Contents of test case:

      setupbg
      set app [dobg {rename send {}; tk appname}]
      set result [list [catch {send $app foo} msg] $msg 
  [winfo interps]]
      cleanupbg
      set result

  ---- Result was:
  1 {invalid command name "send"} {}
  ---- Result should have been (exact matching):
  1 {no application named "tktest #2"} tktest
  ==== send-13.1 FAILED


  ==== send-13.2 DeleteProc procedure FAILED
  ==== Contents of test case:

      winfo interps
      tk appname tktest
      rename send {}
      set result {}
      lappend result [winfo interps] [info commands 
  send]
      tk appname foo
      lappend result [winfo interps] [info commands 
  send]

  ---- Result was:
  can't delete "send": command doesn't exist
  ---- Result should have been (exact matching):
  {} {} foo send
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== send-13.2 FAILED


  ==== send-15.1 UpdateCommWindow procedure 
  FAILED
  ==== Contents of test case:

      set x [list [testsend prop comm 
  TK_APPLICATION]]
      newApp "" t_s_1 Test
      send t_s_1 wm withdraw .
      newApp "" t_s_2 Test
      send t_s_2 wm withdraw .
      lappend x [testsend prop comm 
  TK_APPLICATION]
      interp delete t_s_1
      lappend x [testsend prop comm 
  TK_APPLICATION]
      interp delete t_s_2
      lappend x [testsend prop comm 
  TK_APPLICATION]

  ---- Result was:
  invalid command name "send"
  ---- Result should have been (exact matching):
  tktest {t_s_2 t_s_1 tktest} {t_s_2 tktest} tktest
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== send-15.1 FAILED

  spinbox.test
  text.test
  textBTree.test
  textDisp.test
  textImage.test
  textIndex.test
  textMark.test
  textTag.test
  textWind.test

  ==== textWind-10.1 EmbWinLayoutProc procedure 
  FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      .t window create 1.5 -create {
          frame .f -width 10 -height 20 -bg $color
      }
      update
      list [winfo exists .f] [winfo geom .f] [.t index .f]

  ---- Result was:
  1 10x20+45+5 1.5
  ---- Result should have been (exact matching):
  1 10x20+40+5 1.5
  ==== textWind-10.1 FAILED


  ==== textWind-10.11 EmbWinLayoutProc 
  procedure, doesn't fit on line FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 130 -height 20 -bg $color -bd 
  2 -relief raised
      .t window create 1.12 -window .f
      update
      list [.t bbox .f] [.t bbox 1.13]

  ---- Result was:
  {101 5 130 20} {231 6 8 17}
  ---- Result should have been (exact matching):
  {89 5 126 20} {}
  ==== textWind-10.11 FAILED


  ==== textWind-11.1 EmbWinDisplayProc 
  procedure, geometry transforms FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      pack forget .t
      place .t -x 30 -y 50
      frame .f -width 30 -height 20 -bg $color
      .t window create 1.12 -window .f
      update
      winfo geom .f

  ---- Result was:
  30x20+131+55
  ---- Result should have been (exact matching):
  30x20+119+55
  ==== textWind-11.1 FAILED


  ==== textWind-11.2 EmbWinDisplayProc 
  procedure, geometry transforms FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      pack forget .t
      place .t -x 30 -y 50
      frame .t.f -width 30 -height 20 -bg $color
      .t window create 1.12 -window .t.f
      update
      winfo geom .t.f

  ---- Result was:
  30x20+101+5
  ---- Result should have been (exact matching):
  30x20+89+5
  ==== textWind-11.2 FAILED


  ==== textWind-13.1 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 top -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

  ---- Result was:
  5x5+23+6 {23 6 5 5}
  ---- Result should have been (exact matching):
  5x5+21+6 {21 6 5 5}
  ==== textWind-13.1 FAILED


  ==== 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+23+11 {23 11 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+23+16 {23 16 5 5}
  ---- Result should have been (exact matching):
  5x5+21+14 {21 14 5 5}
  ==== textWind-13.9 FAILED


  ==== textWind-16.2 EmbWinTextStructureProc 
  procedure FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 30 -height 20 -bg $color
      .t window create 1.6 -window .f
      update
      set result {}
      lappend result [winfo geom .f] [.t bbox .f]
      frame .f2 -width 150 -height 30 -bd 2 -relief 
  raised
      pack .f2 -before .t
      update
      lappend result [winfo geom .f] [.t bbox .f]

  ---- Result was:
  30x20+53+5 {53 5 30 20} 30x20+53+35 {53 5 30 
  20}
  ---- Result should have been (exact matching):
  30x20+47+5 {47 5 30 20} 30x20+47+35 {47 5 30 
  20}
  ==== textWind-16.2 FAILED


  ==== textWind-16.4 EmbWinTextStructureProc 
  procedure FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .t.f -width 30 -height 20 -bg $color
      .t window create 1.6 -window .t.f
      update
      pack forget .t
      update
      list [winfo ismapped .t.f] [.t bbox .t.f]

  ---- Result was:
  1 {53 5 30 20}
  ---- Result should have been (exact matching):
  1 {47 5 30 20}
  ==== textWind-16.4 FAILED

  tk.test
  unixButton.test
  unixEmbed.test
  unixFont.test
  unixMenu.test
  unixSelect.test
  unixWm.test

  ==== unixWm-9.4 TkWmMapWindow procedure, 
  icon windows FAILED
  ==== Contents of test case:

      catch {destroy .t}
      sleep 500
      toplevel .t -width 100 -height 50 -bg blue
      wm iconwindow . .t
      update
      set result [winfo ismapped .t]

  ---- Result was:
  1
  ---- Result should have been (exact matching):
  0
  ==== unixWm-9.4 FAILED


  ==== unixWm-16.2 Tk_WmCmd 
  procedure, "deiconify" option FAILED
  ==== Contents of test case:

      catch {destroy .icon}
      toplevel .icon -width 50 -height 50 -bg red
      wm iconwindow .t .icon
      set result [list [catch {wm deiconify .icon} msg] 
  $msg]
      destroy .icon
      set result

  ---- Result was:
  1 {can't deiconify .icon: it is an icon for .icon}
  ---- Result should have been (exact matching):
  1 {can't deiconify .icon: it is an icon for .t}
  ==== unixWm-16.2 FAILED


  ==== unixWm-22.1 Tk_WmCmd 
  procedure, "iconbitmap" option FAILED
  ==== Contents of test case:

      list [catch {wm iconbitmap .t 12 13} msg] $msg

  ---- Result was:
  1 {illegal option "12 must be "-default"}
  ---- Result should have been (exact matching):
  1 {wrong # arguments: must be "wm iconbitmap 
  window ?bitmap?"}
  ==== unixWm-22.1 FAILED


  ==== unixWm-23.4 Tk_WmCmd 
  procedure, "iconify" option FAILED
  ==== Contents of test case:

      catch {destroy .t2}
      toplevel .t2
      wm geom .t2 +0+0
      wm iconwindow .t .t2
      set result [list [catch {wm iconify .t2} msg] $msg]
      destroy .t2
      set result

  ---- Result was:
  1 {can't iconify .t2: it is an icon for .t2}
  ---- Result should have been (exact matching):
  1 {can't iconify .t2: it is an icon for .t}
  ==== unixWm-23.4 FAILED


  ==== unixWm-25.1 Tk_WmCmd 
  procedure, "iconname" option FAILED
  ==== Contents of test case:

      list [catch {wm icon .t} msg] $msg

  ---- Result was:
  1 {unknown or ambiguous option "icon": must be 
  aspect, attributes, client, comma
  nd, deiconify, focusmodel, frame, geometry, grid, 
  group, iconbitmap, iconify, ic
  onmask, iconname, iconposition, iconwindow, 
  maxsize, minsize, overrideredirect,
  positionfrom, protocol, resizable, sizefrom, 
  stackorder state, title, transient,
   or withdraw}
  ---- Result should have been (exact matching):
  1 {unknown or ambiguous option "icon": must be 
  aspect, attributes, client, comma
  nd, deiconify, focusmodel, frame, geometry, grid, 
  group, iconbitmap, iconify, ic
  onmask, iconname, iconposition, iconwindow, 
  maxsize, minsize, overrideredirect,
  positionfrom, protocol, resizable, sizefrom, 
  stackorder, state, title, transient
  , or withdraw}
  ==== unixWm-25.1 FAILED


  ==== unixWm-27.6 Tk_WmCmd 
  procedure, "iconwindow" option, changing icons 
  FAILED
  ==== Contents of test case:

      catch {destroy .icon}
      catch {destroy .icon2}
      toplevel .icon -width 50 -height 50 -bg green
      toplevel .icon2 -width 50 -height 50 -bg red
      set result {}
      wm iconwindow .t .icon
      lappend result [wm state .icon] [wm state .icon2]
      wm iconwindow .t .icon2
      lappend result [wm state .icon] [wm state .icon2]
      destroy .icon .icon2
      set result

  ---- 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
  ==== Contents of test case:

      catch {destroy .icon}
      toplevel .icon -width 50 -height 50 -bg green
      wm geometry .icon +0+0
      update
      set result {}
      lappend result [wm state .icon] [winfo 
  viewable .icon]
      wm iconwindow .t .icon
      lappend result [wm state .icon] [winfo 
  viewable .icon]
      destroy .icon
      set result

  ---- Result was:
  couldn't send withdraw message to window 
  manager
  ---- 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-35.1 Tk_WmCmd procedure, "state" 
  option FAILED
  ==== Contents of test case:

      list [catch {wm state .t 1} msg]  $msg

  ---- Result was:
  1 {bad argument "1": must be normal, iconic, 
  withdrawn or zoomed}
  ---- Result should have been (exact matching):
  1 {bad argument "1": must be normal, iconic or 
  withdrawn}
  ==== unixWm-35.1 FAILED


  ==== unixWm-39.1 Tk_WmCmd procedure, 
  miscellaneous FAILED
  ==== Contents of test case:

      list [catch {wm unknown .t} msg] $msg

  ---- Result was:
  1 {unknown or ambiguous option "unknown": must 
  be aspect, attributes, client, co
  mmand, deiconify, focusmodel, frame, geometry, 
  grid, group, iconbitmap, iconify,
   iconmask, iconname, iconposition, iconwindow, 
  maxsize, minsize, overrideredirec
  t, positionfrom, protocol, resizable, sizefrom, 
  stackorder state, title, transie
  nt, or withdraw}
  ---- Result should have been (exact matching):
  1 {unknown or ambiguous option "unknown": must 
  be aspect, attributes, client, co
  mmand, deiconify, focusmodel, frame, geometry, 
  grid, group, iconbitmap, iconify,
   iconmask, iconname, iconposition, iconwindow, 
  maxsize, minsize, overrideredirec
  t, positionfrom, protocol, resizable, sizefrom, 
  stackorder, state, title, transi
  ent, or withdraw}
  ==== unixWm-39.1 FAILED


  ==== unixWm-42.1 WrapperEventProc procedure, 
  map and unmap events FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 400 -height 150
      wm geometry .t +0+0
      tkwait visibility .t
      set result {}
      bind .t <Map> {set x "mapped"}
      bind .t <Unmap> {set x "unmapped"}
      set x {no event}
      wm iconify .t
      lappend result $x [winfo ismapped .t]
      set x {no event}
      wm deiconify .t
      lappend result $x [winfo ismapped .t]

  ---- Result was:
  unmapped 0 {no event} 1
  ---- Result should have been (exact matching):
  unmapped 0 mapped 1
  ==== unixWm-42.1 FAILED


  ==== unixWm-44.10 UpdateGeometryInfo 
  procedure, menubar changing FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 80 -height 60
      wm resizable .t 0 0
      wm geometry .t +0+0
      tkwait visibility .t
      .t configure -width 180 -height 50
      frame .t.m -bd 2 -relief raised -width 100 -
  height 50
      testmenubar window .t .t.m
      update
      .t configure -height 70
      .t.m configure -height 30
      list [update] [destroy .t]

  ---- Result was:
  testmenubar is supported only under Unix
  ---- Result should have been (exact matching):
  {} {}
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== unixWm-44.10 FAILED


  ==== unixWm-48.1 ParseGeometry procedure 
  FAILED
  ==== Contents of test case:

      wm geometry .t =100x120
      update
      list [winfo width .t] [winfo height .t]

  ---- Result was:
  104 120
  ---- Result should have been (exact matching):
  100 120
  ==== unixWm-48.1 FAILED


  ==== unixWm-49.1 Tk_GetRootCoords procedure 
  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 300 -height 200
      frame .t.f -width 150 -height 100 -bd 2 -relief 
  raised
      place .t.f -x 150 -y 120
      frame .t.f.f -width 20 -height 20 -bd 2 -relief 
  raised
      place .t.f.f -x 10 -y 20
      wm overrideredirect .t 1
      wm geometry .t +40+50
      tkwait visibility .t
      list [winfo rootx .t.f.f] [winfo rooty .t.f.f]

  ---- Result was:
  0 0
  ---- Result should have been (exact matching):
  202 192
  ==== unixWm-49.1 FAILED


  ==== unixWm-50.1 Tk_CoordsToWindow 
  procedure, finding a toplevel, x-coords FAILE
  D
  ==== Contents of test case:

      deleteWindows
      toplevel .t -width 300 -height 400 -bg green
      wm geom .t +40+0
      tkwait visibility .t
      toplevel .t2 -width 100 -height 80 -bg red
      wm geom .t2 +140+200
      tkwait visibility .t2
      raise .t2
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing [expr $x - 30] [expr $y + 
  250]]  [winfo containing [e
  xpr $x - 1] [expr $y + 250]]  [winfo containing $x 
  [expr $y + 250]]  [winfo cont
  aining [expr $x + 99] [expr $y + 250]]  [winfo 
  containing [expr $x + 100] [expr
  $y + 250]]  [winfo containing [expr $x + 199] [expr 
  $y + 250]]  [winfo containin
  g [expr $x + 200] [expr $y + 250]]  [winfo 
  containing [expr $x + 220] [expr $y +
   250]]

  ---- Result was:
  {} {} .t {} .t2 .t2 .t2 .t
  ---- Result should have been (exact matching):
  {} {} .t {} .t2 .t2 {} .t
  ==== unixWm-50.1 FAILED


  ==== unixWm-50.3 Tk_CoordsToWindow 
  procedure, finding a toplevel with embedding
  FAILED
  ==== Contents of test case:

      deleteWindows
      toplevel .t -width 300 -height 400 -bg blue
      wm geom .t +0+50
      frame .t.f -container 1
      place .t.f -x 150 -y 50
      tkwait visibility .t.f
      setupbg
      dobg "
          wm withdraw .
          toplevel .x -width 100 -height 80 -use [winfo 
  id .t.f] -bg yellow
          tkwait visibility .x"
      set result [dobg {
          set x [winfo rootx .x]
          set y [winfo rooty .x]
          list [winfo containing [expr $x - 1] [expr $y + 
  50]]  [winfo containing
  $x [expr $y +50]]
      }]
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      lappend result [winfo containing [expr $x + 200] 
  [expr $y + 49]]  [winfo con
  taining [expr $x + 200] [expr $y +50]]

  ---- Result was:
  {} .x .t {}
  ---- Result should have been (exact matching):
  {} .x .t .t.f
  ==== unixWm-50.3 FAILED


  ==== unixWm-60.1 wm attributes FAILED
  ==== Contents of test case:

      destroy .t
      toplevel .t
      wm attributes .t

  ---- Result was:
  -disabled 0 -toolwindow 0 -topmost 0
  ---- Result should have been (exact matching):

  ==== unixWm-60.1 FAILED


  ==== unixWm-60.2 wm attributes FAILED
  ==== Contents of test case:

      destroy .t
      toplevel .t
      list [catch {wm attributes .t -foo} msg] $msg

  ---- Result was:
  1 {wrong # arguments: must be "wm attributes 
  window ?-disabled ?bool?? ?-toolwin
  dow ?bool?? ?-topmost ?bool??"}
  ---- Result should have been (exact matching):
  1 {wrong # arguments: must be "wm attributes 
  window"}
  ==== unixWm-60.2 FAILED

  util.test
  visual.test
  visual_bb.test
  winButton.test

  ==== winbutton-1.1 TkpComputeButtonGeometry 
  procedure FAILED
  ==== Contents of test case:

      deleteWindows
      image create test image1
      image1 changed 0 0 0 0 60 40
      label .b1 -image image1 -bd 4 -padx 0 -pady 2
      button .b2 -image image1 -bd 4 -padx 0 -pady 
  2
      checkbutton .b3 -image image1 -bd 4 -padx 1 -
  pady 1
      radiobutton .b4 -image image1 -bd 4 -padx 2 -
  pady 0
      pack .b1 .b2 .b3 .b4
      update
      # with patch 463234 with native L&F enabled, 
  this returns:
      # {68 48 70 50 88 50 88 50}
      list [winfo reqwidth .b1] [winfo reqheight .b1]  
  [winfo reqwidth .b2] [winfo
   reqheight .b2]  [winfo reqwidth .b3] [winfo 
  reqheight .b3]  [winfo reqwidth .b4
  ] [winfo reqheight .b4]

  ---- Result was:
  68 48 72 52 92 54 92 54
  ---- Result should have been (exact matching):
  68 48 70 50 90 52 90 52
  ==== winbutton-1.1 FAILED


  ==== winbutton-1.2 TkpComputeButtonGeometry 
  procedure FAILED
  ==== Contents of test case:

      deleteWindows
      label .b1 -bitmap question -bd 3 -padx 0 -pady 
  2
      button .b2 -bitmap question -bd 3 -padx 0 -
  pady 2
      checkbutton .b3 -bitmap question -bd 3 -padx 
  1 -pady 1
      radiobutton .b4 -bitmap question -bd 3 -padx 
  2 -pady 0
      pack .b1 .b2 .b3 .b4
      update
      # with patch 463234 with native L&F enabled, 
  this returns:
      # {23 33 25 35 43 35 43 35}
      list [winfo reqwidth .b1] [winfo reqheight .b1]  
  [winfo reqwidth .b2] [winfo
   reqheight .b2]  [winfo reqwidth .b3] [winfo 
  reqheight .b3]  [winfo reqwidth .b4
  ] [winfo reqheight .b4]

  ---- Result was:
  23 33 27 37 47 39 47 39
  ---- Result should have been (exact matching):
  23 33 25 35 45 37 45 37
  ==== winbutton-1.2 FAILED


  ==== winbutton-1.3 TkpComputeButtonGeometry 
  procedure FAILED
  ==== Contents of test case:

      deleteWindows
      label .b1 -bitmap question -bd 3 -
  highlightthickness 4
      button .b2 -bitmap question -bd 3 -
  highlightthickness 0
      checkbutton .b3 -bitmap question -bd 3 -
  highlightthickness 1  -indicatoron 0

      radiobutton .b4 -bitmap question -bd 3 -
  indicatoron false
      pack .b1 .b2 .b3 .b4
      update
      # with patch 463234 with native L&F enabled, 
  this returns:
      # {31 41 23 33 25 35 25 35}
      list [winfo reqwidth .b1] [winfo reqheight .b1]  
  [winfo reqwidth .b2] [winfo
   reqheight .b2]  [winfo reqwidth .b3] [winfo 
  reqheight .b3]  [winfo reqwidth .b4
  ] [winfo reqheight .b4]

  ---- Result was:
  31 41 23 33 27 37 29 39
  ---- Result should have been (exact matching):
  31 41 23 33 27 37 27 37
  ==== winbutton-1.3 FAILED


  ==== winbutton-1.9 TkpComputeButtonGeometry 
  procedure FAILED
  ==== Contents of test case:

      deleteWindows
      button .b2 -bitmap question -default normal
      list [winfo reqwidth .b2] [winfo reqheight .b2]

  ---- Result was:
  25 35
  ---- Result should have been (exact matching):
  23 33
  ==== winbutton-1.9 FAILED

  winClipboard.test
  winDialog.test
  winFont.test
  winMenu.test
  winSend.test
  winWm.test

  ==== winWm-5.1 UpdateGeometryInfo: menu 
  resizing FAILED
  ==== Contents of test case:

      set result {}
      toplevel .t
      frame .t.f -width 150 -height 50 -bg red
      pack .t.f
      update
      set result [winfo height .t]
      menu .t.m
      .t.m add command -label foo
      .t conf -menu .t.m
      update
      lappend result [winfo height .t]
      .t.m add command -label "thisisreallylong"
      .t.m add command -label "thisisreallylong"
      update
      lappend result [winfo height .t]
      destroy .t
      set result

  ---- Result was:
  50 50 32
  ---- Result should have been (exact matching):
  50 50 50
  ==== winWm-5.1 FAILED

  window.test
  winfo.test
  wm.test
  xmfbox.test

  Tests ended at Mon Jul 15 11:45:43 AM GMT 
  Daylight Time 2002
  all.tcl:        Total   8112    Passed  6651    Skipped 
  1367    Failed  94
  Sourced 182 Test Files.
  Files with failing tests: panedwindow.test send.test 
  textWind.test unixWm.test w
  inButton.test winWm.test
  Number of tests skipped for each constraint:
          8       altDisplay
          16      colorsFree
          7       emptyTest
          265     fonts
          2       knownBug
          310     macOnly
          15      macOrUnix
          81      nonPortable
          79      nonUnixUserInteraction
          35      nt
          3       pseudocolor
          3       pseudocolor8
          1       tempNotPc
          2       testwrapper
          294     unix
          176     unixOnly
          19      userInteraction
          51      winSend
  stderr32
  Administrator@TRAPPER ~/tcl-source/tk8.4/win
  $


tkt_uuid: 581682ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Invalid
title: Cannot compile tk8.4 with DEBUG on VC60
comment:
  I wanted to compile Tk with the NODEBUG option off, because my program
  crashes when i try to exit it (not always but very often). As my program runs
  correctly under Tk8.3.1 and Tk8.3.2 i assumed an error in the Windows part
  of the code (no crashes with Tk8.4 under UNIX !!) or some incompatibility with
  the recent Tk win code,  but ..

  I cannot compile Tk8.4a4 under MS Windows 98 with the NODEBUG option off.
  The offending code is in tkWinWindows.c. Apparently, the CONST char *string
  is the culprit - when i make a cast to (char *)string in the Tcl_GetInt statement,
  it would compile !
  An error - or just my dumbness ??


  int
  TkpScanWindowId(interp, string, idPtr)
      Tcl_Interp *interp;         /* Interpreter to use for error reporting. */
      CONST char *string;         /* String containing a (possibly signed)
                                   * integer in a form acceptable to strtol. */
      Window *idPtr;              /* Place to store converted result. */
  {
      Tk_Window tkwin;
      Window number;

      /*
       * We want sscanf for the 64-bit check, but if that doesn't work,
       * then Tcl_GetInt manages the error correctly.
       */
      if (
  #ifdef _WIN64
          (sscanf(string, "0x%p", &number) != 1) &&
  #endif
          Tcl_GetInt(interp, string, (int *)&number) != TCL_OK) {  <===== ERROR ?
          return TCL_ERROR;
      }

      tkwin = Tk_HWNDToWindow((HWND)number);
      if (tkwin) {
          *idPtr = Tk_WindowId(tkwin);
      } else {
          *idPtr = None;
      }
      return TCL_OK;
  }


tkt_uuid: 581731ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 7 High
foundin: obsolete: 8.4b2
resolution: Invalid
title: crash in windows tk_getSaveFile
comment:
  When using tk_getSaveFile, if the user manoeuvers 
  to a directory which contains a lot of 
  files/directories, it takes a few seconds for the 
  dialog to display everything (and the "searching 
  flashlight" is shown sweeping back and forth).

  If, during those seconds, the user decides to click 
  on 'save' (a perfectly reasonable thing to do if the 
  user wants to save the file in that directory), wish 
  exits immediately, with no warning or error 
  message at all.


tkt_uuid: 581795ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 7 High
foundin: obsolete: 8.4b2
resolution: Accepted
title: '$menu post' halts tcl script
comment:
  unixWm.test numbers 54.1 and 54.2 both hang 
  under windows 2000.  The user is required to click 
  somewhere (once for each test) and then the test 
  proceeds fine.  The problem appears to be that 
  when the menu is posted, the script halts and it is 
  only when the user clicks somewhere that 'update' 
  is actually reached...

  test unixWm-54.1 {TkpMakeMenuWindow 
  procedure, setting save_under} {
      catch {destroy .t}
      catch {destroy .m}
      toplevel .t -width 300 -height 200 -bd 2 -relief 
  raised
      bind .t <Expose> {set x exposed}
      wm geom .t +0+0
      update
      menu .m
      .m add command -label First
      .m add command -label Second
      .m add command -label Third
      .m post 30 30
      update
      set x {no event}
      destroy .m
      set x
  } {no event}
  test unixWm-54.2 {TkpMakeMenuWindow 
  procedure, setting override_redirect} {
      catch {destroy .m}
      menu .m
      .m add command -label First
      .m add command -label Second
      .m add command -label Third
      .m post 30 30
      update
      set result [wm overrideredirect .m]
      destroy .m
      set result
  } {1}


tkt_uuid: 582150ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Rejected
title: Tk 8.4b1 doesn't build on HP-UX 10.20
comment:
  Commands executed:
      cd unix
      ./configure --prefix=/home/jbek --exec-
  prefix=/home/jbek
          --bindir=/home/jbek/bin/hp700 --
  sbindir=/home/jbek/bin/hp700
          --x-includes=/usr/include/X11R6 --x-
  libraries=/usr/lib/X11R6
      make
      

  Results:

  1. cc: "/home/jbek/src/Xsrc/tcl8.4b1/generic/tcl.h", line 
  378: error
     1681: Must use +e or -Ae for long long in ANSI mode.
     This is fixed by adding "-Ae" to CFLAGS in the 
  Makefile after "-Aa".

  2. The following message:
         
  cc: "/home/jbek/src/Xsrc/tk8.4b1/unix/../generic/../unix/tk
  UnixPort.h",
         line 94: error 1584: Inconsistent type 
  declaration: "fd_mask".
     This is fixed by deleting "-DNO_FD_SET=1" in 
  AC_FLAGS in the Makefile.

  After this, Tk 8.4b1 compiles and works fine.


tkt_uuid: 582370ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: panedwindow tests fail on Win
comment:
  Several tests for the new panedwindow command in 
  tk8.4 fail, at least on Windows.  This doesn't seem 
  like a good precedent for a new command ;-)

  panedwindow.test

  ==== panedwindow-10.1 sash mark/sash dragto 
  interaction FAILED
  ==== Contents of test case:

      panedwindow .p -borderwidth 0 -sashpad 0 -
  sashwidth 4 -showhandle false
      .p add [frame .f -width 20 -height 20] [button .c]
      .p sash mark 0 10 10
      .p sash dragto 0 20 10
      set result [.p sash coord 0]
      destroy .p .f .c
      set result

  ---- Result was:
  28 0
  ---- Result should have been (exact matching):
  30 0
  ==== panedwindow-10.1 FAILED


  ==== panedwindow-10.2 sash mark/sash dragto 
  interaction FAILED
  ==== Contents of test case:

      panedwindow .p -borderwidth 0 -sashpad 0 -
  sashwidth 4 -orient vertical  -sho
  whandle false
      .p add [frame .p.f -width 20 -height 20] 
  [button .p.c]
      .p sash mark 0 10 10
      .p sash dragto 0 10 20
      set result [.p sash coord 0]
      destroy .p .p.f .p.c
      set result

  ---- Result was:
  0 28
  ---- Result should have been (exact matching):
  0 30
  ==== panedwindow-10.2 FAILED


  ==== panedwindow-12.1 moving sash changes 
  size of pane to left FAILED
  ==== Contents of test case:

      panedwindow .p -borderwidth 0 -sashpad 0 -
  sashwidth 4 -showhandle false
      .p add [frame .f -width 20 -height 20] 
  [button .c] -sticky nsew
      .p sash place 0 30 0
      pack .p
      update
      set result [winfo width .f]
      destroy .p .f .c
      set result

  ---- Result was:
  28
  ---- Result should have been (exact matching):
  30
  ==== panedwindow-12.1 FAILED


  ==== panedwindow-12.4 moving sash changes 
  size of pane above FAILED
  ==== Contents of test case:

      panedwindow .p -showhandle false -
  borderwidth 0 -sashpad 0 -sashwidth 4  -or
  ient vertical
      .p add [frame .f -width 20 -height 10] 
  [button .c] -sticky nsew
      .p sash place 0 0 20
      pack .p
      update
      set result [winfo height .f]
      destroy .p .f .c
      set result

  ---- Result was:
  18
  ---- Result should have been (exact matching):
  20
  ==== panedwindow-12.4 FAILED


tkt_uuid: 582371ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: several textWind tests fail on Win.
comment:
  These tests fail in 8.4b2:

  textWind.test

  ==== textWind-10.1 EmbWinLayoutProc procedure 
  FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      .t window create 1.5 -create {
  frame .f -width 10 -height 20 -bg $color
      }
      update
      list [winfo exists .f] [winfo geom .f] [.t index .f]

  ---- Result was:
  1 10x20+45+5 1.5
  ---- Result should have been (exact matching):
  1 10x20+40+5 1.5
  ==== textWind-10.1 FAILED


  ==== textWind-10.11 EmbWinLayoutProc 
  procedure, doesn't fit on line FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 130 -height 20 -bg $color -bd 
  2 -relief raised
      .t window create 1.12 -window .f
      update
      list [.t bbox .f] [.t bbox 1.13]

  ---- Result was:
  {101 5 130 20} {231 6 8 17}
  ---- Result should have been (exact matching):
  {89 5 126 20} {}
  ==== textWind-10.11 FAILED


  ==== textWind-11.1 EmbWinDisplayProc 
  procedure, geometry transforms FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      pack forget .t
      place .t -x 30 -y 50
      frame .f -width 30 -height 20 -bg $color
      .t window create 1.12 -window .f
      update
      winfo geom .f

  ---- Result was:
  30x20+131+55
  ---- Result should have been (exact matching):
  30x20+119+55
  ==== textWind-11.1 FAILED


  ==== textWind-11.2 EmbWinDisplayProc 
  procedure, geometry transforms FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      pack forget .t
      place .t -x 30 -y 50
      frame .t.f -width 30 -height 20 -bg $color
      .t window create 1.12 -window .t.f
      update
      winfo geom .t.f

  ---- Result was:
  30x20+101+5
  ---- Result should have been (exact matching):
  30x20+89+5
  ==== textWind-11.2 FAILED


  ==== textWind-13.1 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 top -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

  ---- Result was:
  5x5+23+6 {23 6 5 5}
  ---- Result should have been (exact matching):
  5x5+21+6 {21 6 5 5}
  ==== textWind-13.1 FAILED


  ==== 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+23+11 {23 11 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+23+16 {23 16 5 5}
  ---- Result should have been (exact matching):
  5x5+21+14 {21 14 5 5}
  ==== textWind-13.9 FAILED


  ==== textWind-16.2 EmbWinTextStructureProc 
  procedure FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 30 -height 20 -bg $color
      .t window create 1.6 -window .f
      update
      set result {}
      lappend result [winfo geom .f] [.t bbox .f]
      frame .f2 -width 150 -height 30 -bd 2 -relief 
  raised
      pack .f2 -before .t
      update
      lappend result [winfo geom .f] [.t bbox .f]

  ---- Result was:
  30x20+53+5 {53 5 30 20} 30x20+53+35 {53 5 30 
  20}
  ---- Result should have been (exact matching):
  30x20+47+5 {47 5 30 20} 30x20+47+35 {47 5 30 
  20}
  ==== textWind-16.2 FAILED


  ==== textWind-16.4 EmbWinTextStructureProc 
  procedure FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .t.f -width 30 -height 20 -bg $color
      .t window create 1.6 -window .t.f
      update
      pack forget .t
      update
      list [winfo ismapped .t.f] [.t bbox .t.f]

  ---- Result was:
  1 {53 5 30 20}
  ---- Result should have been (exact matching):
  1 {47 5 30 20}
  ==== textWind-16.4 FAILED


tkt_uuid: 582381ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: None
title: win wm bugs
comment:
  Many of the tests in unixWm.test now run on 
  Windows.  This is good, since many of those tests 
  are really cross-platform tests.  However, many of 
  those tests do actually fail.  I fixed a couple of 
  simple ones in cvs, but the rest are beyond me:

  unixWm.test

  ==== unixWm-9.4 TkWmMapWindow procedure, 
  icon windows FAILED
  ==== Contents of test case:

      catch {destroy .t}
      sleep 500
      toplevel .t -width 100 -height 50 -bg blue
      wm iconwindow . .t
      update
      set result [winfo ismapped .t]

  ---- 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
  ==== Contents of test case:

      catch {destroy .icon}
      catch {destroy .icon2}
      toplevel .icon -width 50 -height 50 -bg green
      toplevel .icon2 -width 50 -height 50 -bg red
      set result {}
      wm iconwindow .t .icon
      lappend result [wm state .icon] [wm state .icon2]
      wm iconwindow .t .icon2
      lappend result [wm state .icon] [wm state .icon2]
      destroy .icon .icon2
      set result

  ---- 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
  ==== Contents of test case:

      catch {destroy .icon}
      toplevel .icon -width 50 -height 50 -bg green
      wm geometry .icon +0+0
      update
      set result {}
      lappend result [wm state .icon] [winfo 
  viewable .icon]
      wm iconwindow .t .icon
      lappend result [wm state .icon] [winfo 
  viewable .icon]
      destroy .icon
      set result

  ---- Result was:
  couldn't send withdraw message to window 
  manager
  ---- 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
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 400 -height 150
      wm geometry .t +0+0
      tkwait visibility .t
      set result {}
      bind .t <Map> {set x "mapped"}
      bind .t <Unmap> {set x "unmapped"}
      set x {no event}
      wm iconify .t
      lappend result $x [winfo ismapped .t]
      set x {no event}
      wm deiconify .t
      lappend result $x [winfo ismapped .t]

  ---- Result was:
  unmapped 0 {no event} 1
  ---- Result should have been (exact matching):
  unmapped 0 mapped 1
  ==== unixWm-42.1 FAILED


  ==== unixWm-48.1 ParseGeometry procedure 
  FAILED
  ==== Contents of test case:

      wm geometry .t =100x120
      update
      list [winfo width .t] [winfo height .t]

  ---- Result was:
  104 120
  ---- Result should have been (exact matching):
  100 120
  ==== unixWm-48.1 FAILED


  ==== unixWm-49.1 Tk_GetRootCoords procedure 
  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 300 -height 200
      frame .t.f -width 150 -height 100 -bd 2 -relief 
  raised
      place .t.f -x 150 -y 120
      frame .t.f.f -width 20 -height 20 -bd 2 -relief 
  raised
      place .t.f.f -x 10 -y 20
      wm overrideredirect .t 1
      wm geometry .t +40+50
      tkwait visibility .t
      list [winfo rootx .t.f.f] [winfo rooty .t.f.f]

  ---- Result was:
  0 0
  ---- Result should have been (exact matching):
  202 192
  ==== unixWm-49.1 FAILED


  ==== unixWm-50.1 Tk_CoordsToWindow 
  procedure, finding a toplevel, x-coords FAILE
  D
  ==== Contents of test case:

      deleteWindows
      toplevel .t -width 300 -height 400 -bg green
      wm geom .t +40+0
      tkwait visibility .t
      toplevel .t2 -width 100 -height 80 -bg red
      wm geom .t2 +140+200
      tkwait visibility .t2
      raise .t2
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing [expr $x - 30] [expr $y + 
  250]]  [winfo containing [e
  xpr $x - 1] [expr $y + 250]]  [winfo containing $x 
  [expr $y + 250]]  [winfo cont
  aining [expr $x + 99] [expr $y + 250]]  [winfo 
  containing [expr $x + 100] [expr
  $y + 250]]  [winfo containing [expr $x + 199] [expr 
  $y + 250]]  [winfo containin
  g [expr $x + 200] [expr $y + 250]]  [winfo 
  containing [expr $x + 220] [expr $y +
   250]]

  ---- Result was:
  {} {} {} {} {} {} {} {}
  ---- Result should have been (exact matching):
  {} {} .t {} .t2 .t2 {} .t
  ==== unixWm-50.1 FAILED


  ==== unixWm-50.2 Tk_CoordsToWindow 
  procedure, finding a toplevel, y-coords and o
  verrideredirect FAILED
  ==== Contents of test case:

      deleteWindows
      toplevel .t -width 300 -height 400 -bg yellow
      wm geom .t +0+50
      tkwait visibility .t
      toplevel .t2 -width 100 -height 80 -bg blue
      wm overrideredirect .t2 1
      wm geom .t2 +100+200
      tkwait visibility .t2
      raise .t2
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      set y2 [winfo rooty .t2]
      list [winfo containing [expr $x +150] 10]  [winfo 
  containing [expr $x +150]
  [expr $y - 1]]  [winfo containing [expr $x +150] $y]  
  [winfo containing [expr $x
   +150] [expr $y2 - 1]]  [winfo containing [expr $x 
  +150] $y2]  [winfo containing
   [expr $x +150] [expr $y2 + 79]]  [winfo containing 
  [expr $x +150] [expr $y2 + 8
  0]]  [winfo containing [expr $x +150] [expr $y + 
  450]]

  ---- Result was:
  {} {} {} {} {} {} {} {}
  ---- Result should have been (exact matching):
  {} {} .t .t .t2 .t2 .t {}
  ==== unixWm-50.2 FAILED


  ==== unixWm-50.3 Tk_CoordsToWindow 
  procedure, finding a toplevel with embedding
  FAILED
  ==== Contents of test case:

      deleteWindows
      toplevel .t -width 300 -height 400 -bg blue
      wm geom .t +0+50
      frame .t.f -container 1
      place .t.f -x 150 -y 50
      tkwait visibility .t.f
      setupbg
      dobg "
  wm withdraw .
  toplevel .x -width 100 -height 80 -use 
  [winfo id .t.f] -bg yellow
  tkwait visibility .x"
      set result [dobg {
  set x [winfo rootx .x]
  set y [winfo rooty .x]
  list [winfo containing [expr $x - 1] [expr 
  $y + 50]]  [winfo containing
  $x [expr $y +50]]
      }]
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      lappend result [winfo containing [expr $x + 200] 
  [expr $y + 49]]  [winfo con
  taining [expr $x + 200] [expr $y +50]]

  ---- Result was:
  {} {} {} {}
  ---- Result should have been (exact matching):
  {} .x .t .t.f
  ==== unixWm-50.3 FAILED


  ==== unixWm-50.4 Tk_CoordsToWindow 
  procedure, window in other application FAILED

  ==== Contents of test case:

      catch {destroy .t}
      catch {interp delete slave}
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      tkwait visibility .t
      interp create slave
      load {} Tk slave
      slave eval {wm geometry . 200x200+0+0; tkwait 
  visibility .}
      set result [list [winfo containing 100 100]  [slave 
  eval {winfo containing 1
  00 100}]]
      interp delete slave
      set result

  ---- Result was:
  {} {}
  ---- Result should have been (exact matching):
  {} .
  ==== unixWm-50.4 FAILED


  ==== unixWm-50.6 Tk_CoordsToWindow 
  procedure, embedding within one app. FAILED
  ==== Contents of test case:

      deleteWindows
      toplevel .t -width 300 -height 400 -bg orange
      wm geom .t +0+50
      frame .t.f -container 1
      place .t.f -x 150 -y 50
      tkwait visibility .t.f
      toplevel .t2 -width 100 -height 80 -bg green -
  use [winfo id .t.f]
      tkwait visibility .t2
      update
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing [expr $x +149] [expr $y + 
  80]]  [winfo containing [ex
  pr $x +150] [expr $y +80]]  [winfo containing [expr 
  $x +249] [expr $y +80]]  [wi
  nfo containing [expr $x +250] [expr $y +80]]

  ---- Result was:
  {} {} {} {}
  ---- Result should have been (exact matching):
  .t .t2 .t2 .t
  ==== unixWm-50.6 FAILED


  ==== unixWm-50.7 Tk_CoordsToWindow 
  procedure, more basics FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 300 -height 400 -bg green
      wm geom .t +0+0
      frame .t.f -width 100 -height 200 -bd 2 -relief 
  raised
      place .t.f -x 100 -y 100
      frame .t.f.f -width 100 -height 200 -bd 2 -relief 
  raised
      place .t.f.f -x 0 -y 100
      tkwait visibility .t.f.f
      set x [expr [winfo rootx .t] + 150]
      set y [winfo rooty .t]
      list [winfo containing $x [expr $y + 50]]  [winfo 
  containing $x [expr $y + 1
  50]]  [winfo containing $x [expr $y + 250]]  [winfo 
  containing $x [expr $y + 350
  ]]  [winfo containing $x [expr $y + 450]]

  ---- Result was:
  {} {} {} {} {}
  ---- Result should have been (exact matching):
  .t .t.f .t.f.f .t {}
  ==== unixWm-50.7 FAILED


  ==== unixWm-50.8 Tk_CoordsToWindow 
  procedure, more basics FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 400 -height 300 -bg green
      wm geom .t +0+0
      frame .t.f -width 200 -height 100 -bd 2 -relief 
  raised
      place .t.f -x 100 -y 100
      frame .t.f.f -width 200 -height 100 -bd 2 -relief 
  raised
      place .t.f.f -x 100 -y 0
      update
      set x [winfo rooty .t]
      set y [expr [winfo rooty .t] + 150]
      list [winfo containing [expr $x + 50] $y]  [winfo 
  containing [expr $x + 150]
   $y]  [winfo containing [expr $x + 250] $y]  [winfo 
  containing [expr $x + 350] $
  y]  [winfo containing [expr $x + 450] $y]

  ---- Result was:
  {} {} {} {} {}
  ---- Result should have been (exact matching):
  .t .t.f .t.f.f .t {}
  ==== unixWm-50.8 FAILED


  ==== unixWm-50.9 Tk_CoordsToWindow 
  procedure, unmapped windows FAILED
  ==== Contents of test case:

      catch {destroy .t}
      catch {destroy .t2}
      sleep 500           ;# Give window manager time to 
  catch up.
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      tkwait visibility .t
      toplevel .t2 -width 200 -height 200 -bg red
      wm geometry .t2 +0+0
      tkwait visibility .t2
      set result [list [winfo containing 100 100]]
      wm iconify .t2
      lappend result [winfo containing 100 100]

  ---- Result was:
  {} {}
  ---- Result should have been (exact matching):
  .t2 .t
  ==== unixWm-50.9 FAILED


  ==== unixWm-50.10 Tk_CoordsToWindow 
  procedure, unmapped windows FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      frame .t.f -width 150 -height 150 -bd 2 -relief 
  raised
      place .t.f -x 25 -y 25
      tkwait visibility .t.f
      set result [list [winfo containing 100 100]]
      place forget .t.f
      update
      lappend result [winfo containing 100 100]

  ---- Result was:
  {} {}
  ---- Result should have been (exact matching):
  .t.f .t
  ==== unixWm-50.10 FAILED


  ==== unixWm-51.6 TkWmRestackToplevel 
  procedure, window to be stacked isn't mappe
  d FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      tkwait visibility .t
      catch {destroy .t2}
      toplevel .t2 -width 200 -height 200 -bg red
      wm geometry .t2 +0+0
      winfo containing 100 100

  ---- Result was:

  ---- Result should have been (exact matching):
  .t
  ==== unixWm-51.6 FAILED


  ==== unixWm-51.7 TkWmRestackToplevel 
  procedure, other window isn't mapped FAILED

  ==== Contents of test case:

      foreach w {.t .t2 .t3} {
  catch {destroy $w}
  toplevel $w -width 200 -height 200 -bg 
  green
  wm geometry $w +0+0
      }
      raise .t .t2
      update
      set result [list [winfo containing 100 100]]
      lower .t3
      lappend result [winfo containing 100 100]

  ---- Result was:
  {} {}
  ---- Result should have been (exact matching):
  .t3 .t
  ==== unixWm-51.7 FAILED


  ==== unixWm-51.8 TkWmRestackToplevel 
  procedure, overrideredirect windows FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200 -bg green
      wm overrideredirect .t 1
      wm geometry .t +0+0
      tkwait visibility .t
      catch {destroy .t2}
      toplevel .t2 -width 200 -height 200 -bg red
      wm overrideredirect .t2 1
      wm geometry .t2 +0+0
      tkwait visibility .t2

      # Need to use vrootx and vrooty to make tests 
  work correctly with
      # virtual root window measures managers: 
  overrideredirect windows
      # come up at (0,0) in display coordinates, not 
  virtual root
      # coordinates.

      set x [expr 100-[winfo vrootx .]]
      set y [expr 100-[winfo vrooty .]]
      set result [list [winfo containing $x $y]]
      raise .t
      lappend result [winfo containing $x $y]
      raise .t2
      lappend result [winfo containing $x $y]

  ---- Result was:
  {} {} {}
  ---- Result should have been (exact matching):
  .t2 .t .t2
  ==== unixWm-51.8 FAILED


  ==== unixWm-51.9 TkWmRestackToplevel 
  procedure, other window overrideredirect FA
  ILED
  ==== Contents of test case:

      foreach w {.t .t2 .t3} {
  catch {destroy $w}
  toplevel $w -width 200 -height 200 -bg 
  green
  wm overrideredirect $w 1
  wm geometry $w +0+0
  tkwait visibility $w
      }
      lower .t3 .t2
      update

      # Need to use vrootx and vrooty to make tests 
  work correctly with
      # virtual root window measures managers: 
  overrideredirect windows
      # come up at (0,0) in display coordinates, not 
  virtual root
      # coordinates.

      set x [expr 100-[winfo vrootx .]]
      set y [expr 100-[winfo vrooty .]]
      set result [list [winfo containing $x $y]]
      lower .t2
      lappend result [winfo containing $x $y]

  ---- Result was:
  {} {}
  ---- Result should have been (exact matching):
  .t2 .t3
  ==== unixWm-51.9 FAILED


tkt_uuid: 582382ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Invalid
title: winButton.test failures
comment:
  There are four test failures in latest cvs head in 
  winButton.test:

  winButton.test

  ==== winbutton-1.1 TkpComputeButtonGeometry 
  procedure FAILED
  ==== Contents of test case:

      deleteWindows
      image create test image1
      image1 changed 0 0 0 0 60 40
      label .b1 -image image1 -bd 4 -padx 0 -pady 2
      button .b2 -image image1 -bd 4 -padx 0 -pady 
  2
      checkbutton .b3 -image image1 -bd 4 -padx 1 -
  pady 1
      radiobutton .b4 -image image1 -bd 4 -padx 2 -
  pady 0
      pack .b1 .b2 .b3 .b4
      update
      # with patch 463234 with native L&F enabled, 
  this returns:
      # {68 48 70 50 88 50 88 50}
      list [winfo reqwidth .b1] [winfo reqheight .b1]  
  [winfo reqwidth .b2] [winfo
   reqheight .b2]  [winfo reqwidth .b3] [winfo 
  reqheight .b3]  [winfo reqwidth .b4
  ] [winfo reqheight .b4]

  ---- Result was:
  68 48 72 52 92 54 92 54
  ---- Result should have been (exact matching):
  68 48 70 50 90 52 90 52
  ==== winbutton-1.1 FAILED


  ==== winbutton-1.2 TkpComputeButtonGeometry 
  procedure FAILED
  ==== Contents of test case:

      deleteWindows
      label .b1 -bitmap question -bd 3 -padx 0 -pady 
  2
      button .b2 -bitmap question -bd 3 -padx 0 -
  pady 2
      checkbutton .b3 -bitmap question -bd 3 -padx 
  1 -pady 1
      radiobutton .b4 -bitmap question -bd 3 -padx 
  2 -pady 0
      pack .b1 .b2 .b3 .b4
      update
      # with patch 463234 with native L&F enabled, 
  this returns:
      # {23 33 25 35 43 35 43 35}
      list [winfo reqwidth .b1] [winfo reqheight .b1]  
  [winfo reqwidth .b2] [winfo
   reqheight .b2]  [winfo reqwidth .b3] [winfo 
  reqheight .b3]  [winfo reqwidth .b4
  ] [winfo reqheight .b4]

  ---- Result was:
  23 33 27 37 47 39 47 39
  ---- Result should have been (exact matching):
  23 33 25 35 45 37 45 37
  ==== winbutton-1.2 FAILED


  ==== winbutton-1.3 TkpComputeButtonGeometry 
  procedure FAILED
  ==== Contents of test case:

      deleteWindows
      label .b1 -bitmap question -bd 3 -
  highlightthickness 4
      button .b2 -bitmap question -bd 3 -
  highlightthickness 0
      checkbutton .b3 -bitmap question -bd 3 -
  highlightthickness 1  -indicatoron 0

      radiobutton .b4 -bitmap question -bd 3 -
  indicatoron false
      pack .b1 .b2 .b3 .b4
      update
      # with patch 463234 with native L&F enabled, 
  this returns:
      # {31 41 23 33 25 35 25 35}
      list [winfo reqwidth .b1] [winfo reqheight .b1]  
  [winfo reqwidth .b2] [winfo
   reqheight .b2]  [winfo reqwidth .b3] [winfo 
  reqheight .b3]  [winfo reqwidth .b4
  ] [winfo reqheight .b4]

  ---- Result was:
  31 41 23 33 27 37 29 39
  ---- Result should have been (exact matching):
  31 41 23 33 27 37 27 37
  ==== winbutton-1.3 FAILED


  ==== winbutton-1.9 TkpComputeButtonGeometry 
  procedure FAILED
  ==== Contents of test case:

      deleteWindows
      button .b2 -bitmap question -default normal
      list [winfo reqwidth .b2] [winfo reqheight .b2]

  ---- Result was:
  25 35
  ---- Result should have been (exact matching):
  23 33
  ==== winbutton-1.9 FAILED


tkt_uuid: 582383ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 7 High
foundin: obsolete: 8.4b2
resolution: None
title: winWm.test failure
comment:
  There is one test failure in winWm.test on Windows.

  winWm.test

  ==== winWm-5.1 UpdateGeometryInfo: menu 
  resizing FAILED
  ==== Contents of test case:

      set result {}
      toplevel .t
      frame .t.f -width 150 -height 50 -bg red
      pack .t.f
      update
      set result [winfo height .t]
      menu .t.m
      .t.m add command -label foo
      .t conf -menu .t.m
      update
      lappend result [winfo height .t]
      .t.m add command -label "thisisreallylong"
      .t.m add command -label "thisisreallylong"
      update
      lappend result [winfo height .t]
      destroy .t
      set result

  ---- Result was:
  50 50 32
  ---- Result should have been (exact matching):
  50 50 50
  ==== winWm-5.1 FAILED


tkt_uuid: 582457ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 6
foundin: obsolete: 8.4b2
resolution: Fixed
title: checkbutton -overrelief doesn't work
comment:
  I suspect that the addition of the -offrelief may have 
  cause the -overrelief functionality (to make it appear like 
  a new Windows-style toolbar button) to not work.  
  Regular buttons still work fine.  Did not check 
  radiobuttons.  This is 8.4b1 on Windows2000.


tkt_uuid: 582799ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: tk test suite no longer operational
comment:
  Before the CVS snapshot available on activestate's ftp
  site today, July 17, 2002, Tk's make test worked
  relatively well.

  Today however it fails miserably.

  Platform: SPARC Solaris 2.6
  Sun's C compiler.

  Tcl/Tk CVS snapshot

  fresh copy of tcl configured, make, test, and installed
  successfully.

  fresh copy of tk configured:
  $ vol/tclsrcsol/tcl84/tk/unix/configure 
  --prefix=/usr/tcl84 --enable-symbols --enable-shared
  $ make all
  $ make test
  Tests running in interp: 
  /vol/tclsrcsol/tcl84/tk/unix/tktest
  Tests located in:  /vol/tclsrcsol/tcl84/tk/tests
  Tests running in:  /vol/tclsrcsol/tcl84/tk/unix
  Temporary files stored in /vol/tclsrcsol/tcl84/tk/unix
  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 Wed Jul 17 08:34:38 EDT 2002
  bell.test
  Bell should ring now ...
  A core file was created!
  bgerror.test
  A core file was created!
  bind.test
  no fontsLeft
  Abort - core dumped
  make: *** [test] Error 134

  Unfortunately, the core file left is one caused by the
  new intentional panic created by last nite's changes.  


tkt_uuid: 583286ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: Strange focus handling
comment:
  Execute the following script:

    pack [text .t]
    .t window create 1.0 -window [button .t.b -text hi]
    .t insert end " some random text "
    focus .t.b

  Now, pressing the space bar operates the button (which
  is good) but the insertion cursor is flashing in the
  text widget while this is happening as if keypresses
  will be inserted there (which is bad.)  Surely the
  insertion cursor should only flash when the focus is
  directed to the text widget, and not to one of its
  children?


tkt_uuid: 583292ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Works For Me
title: Test file entry.test - several failures
comment:
  Compiled with SUN's cc
  Running on SunOS 5.6, Reflection-X as X-emulator
  Test report:
  entry.test

  ==== entry-5.8 ConfigureEntry procedure FAILED
  ==== Contents of test case:

      catch {destroy .e}
      entry .e -width 0
      pack .e
      .e insert end "0123"
      update
      .e configure -font $big
      update
      winfo geom .e

  ---- Result was:
  62x35+0+0
  ---- Result should have been:
  62x37+0+0
  ==== entry-5.8 FAILED



  ==== entry-6.7 EntryComputeGeometry procedure FAILED
  ==== Contents of test case:

      catch {destroy .e}
      entry .e -font $big -bd 3 -relief raised -width 5
      pack .e
      .e insert end "01234567"
      update
      list [winfo reqwidth .e] [winfo reqheight .e]

  ---- Result was:
  77 37
  ---- Result should have been:
  77 39
  ==== entry-6.7 FAILED

  ==== entry-6.8 EntryComputeGeometry procedure FAILED
  ==== Contents of test case:

      catch {destroy .e}
      entry .e -font $big -bd 3 -relief raised -width 0
      pack .e
      .e insert end "01234567"
      update
      list [winfo reqwidth .e] [winfo reqheight .e]

  ---- Result was:
  116 37
  ---- Result should have been:
  116 39
  ==== entry-6.8 FAILED


  ==== entry-6.9 EntryComputeGeometry procedure FAILED
  ==== Contents of test case:

      catch {destroy .e}
      entry .e -font $big -bd 3 -relief raised -width 0
  -highlightthickness 2
      pack .e
      update
      list [winfo reqwidth .e] [winfo reqheight .e]

  ---- Result was:
  25 37
  ---- Result should have been:
  25 39
  ==== entry-6.9 FAILED


tkt_uuid: 583293ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Duplicate
title: Test file listbox.test - failure
comment:
  Compiled with SUN's cc
  Running on SunOS with Reflection-X as X-emulator
  Test report:
  listbox.test

  ==== listbox-13.3 ListboxScanTo procedure FAILED
  ==== Contents of test case:

      .l yview moveto 1.0
      .l xview moveto 1.0
      .l scan mark 10 20
      .l scan dragto 5 10
      update
      set x [list [.l xview] [.l yview]]
      .l scan dragto [expr 5+$width] [expr 10+$height]
      update
      lappend x [.l xview] [.l yview]

  ---- Result was:
  {0.8 1} {0.75 1} {0.64 0.84} {0.25 0.5}
  ---- Result should have been:
  {0.8 1} {0.75 1} {0.62 0.82} {0.25 0.5}
  ==== listbox-13.3 FAILED


tkt_uuid: 583301ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Works For Me
title: Test file spinbox.test: several failures
comment:
  Compiled with SUN's cc
  Running on SunOS 5.6 with Reflection-X as X-emulator
  Test report:
  spinbox.test

  ==== spinbox-5.8 ConfigureSpinbox procedure FAILED
  ==== Contents of test case:

      catch {destroy .e}
      spinbox .e -width 0
      pack .e
      .e insert end "0123"
      update
      .e configure -font $big
      update
      winfo geom .e

  ---- Result was:
  79x35+0+0
  ---- Result should have been:
  79x37+0+0
  ==== spinbox-5.8 FAILED

  ==== spinbox-6.7 SpinboxComputeGeometry procedure
  FAILED
  ==== Contents of test case:

      catch {destroy .e}
      spinbox .e -font $big -bd 3 -relief raised -width 5
      pack .e
      .e insert end "01234567"
      update
      list [winfo reqwidth .e] [winfo reqheight .e]

  ---- Result was:
  94 37
  ---- Result should have been:
  94 39
  ==== spinbox-6.7 FAILED


  ==== spinbox-6.8 SpinboxComputeGeometry procedure
  FAILED
  ==== Contents of test case:

      catch {destroy .e}
      spinbox .e -font $big -bd 3 -relief raised -width 0
      pack .e
      .e insert end "01234567"
      update
      list [winfo reqwidth .e] [winfo reqheight .e]

  ---- Result was:
  133 37
  ---- Result should have been:
  133 39
  ==== spinbox-6.8 FAILED


  ==== spinbox-6.9 SpinboxComputeGeometry procedure
  FAILED
  ==== Contents of test case:

      catch {destroy .e}
      spinbox .e -font $big -bd 3 -relief raised -width 0
  -highlightthickness 2
      pack .e
      update
      list [winfo reqwidth .e] [winfo reqheight .e]

  ---- Result was:
  42 37
  ---- Result should have been:
  42 39
  ==== spinbox-6.9 FAILED


tkt_uuid: 583303ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Works For Me
title: Test file text.test: one failure
comment:
  Compiled with SUN's cc
  Running on SunOS 5.6 using Reflection-X as X-emulator
  Test report:
  text.test

  ==== text-1.9 text options FAILED
  ==== Contents of test case:

          set result {}
          lappend result [catch {.t2 configure [lindex
  $test 0] [lindex $test 3]}]
          .t2 configure [lindex $test 0] [lindex $test 1]
          lappend result [.t2 cget [lindex $test 0]]

  ---- Result was:
  0 fixed
  ---- Result should have been:
  1 fixed
  ==== text-1.9 FAILED


tkt_uuid: 583691ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: Incorrect focus ring under windows...
comment:
  Hi all,

  There seems that the focus ring in checkbuttons and radiobuttons is wrongly
  calculated, if these widgets are displaying an image and a label at the
  same time. Submitted a small script that displays the problem...

  George


tkt_uuid: 585003ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 81. Portability
priority: 4
foundin: obsolete: 8.3.4
resolution: None
title: tk_popup platform differences
comment:
  tk_popup behaves differently on unix and on windows.

  windows:
    * The <Unmap> binding isn't fired when the popup
  dissapears, which includes when the user doesn't select
  one of the menu items.
    * All processing of the script stops as soon as the
  popup is displayed. The script continues where it left
  off after the popup dissapears.

  unix:
    * Here the <Unmap> binding actually gets fired when
  the popup dissapears.
    * Processing of the script continues after the popup
  is shown. The rest of the script doesn't wait for the
  popup to dissapear. 

  For more information see
  http://mini.net/tcl/3713

  Rohan Pall
  http://www.RohanPall.com


tkt_uuid: 586955ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 86. Test Tools
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Wont Fix
title: update for tests/README suggested
comment:
  A note should be added to this file indicating that the
  user should use tktest rather than tcltest when running
  the individual tests.

  Right now the README says to use the tcl/tests/README
  for info about the test suite - and that file says to
  use tcltest ...


tkt_uuid: 587698ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Duplicate
title: wm attributes -topmost and System Menu
comment:
  Trying to use the new -topmost option of wm attributes, 
  a typical application would be to post a new "Always on 
  Top" menu option in the windows system menu (see 
  code below). However, when running this code and 
  selecting the "Always on Top" option, the menu choice 
  disappears! If I replace the wm -topmost command with 
  one from a custom dll that does the same thing, the 
  menu option stays as expected.

  There is some interaction with the topmost command 
  and system menu.
  #---Demo Code below ---------------------------------------
  proc pinOnSystemMenu {M W} {
     if {$M=={}} {
        set M $W.menubar
        menu $M -tearoff 0
        $W config -menu $M
     }
     $M add cascade -label System -font menu -menu 
  $M.system
     menu $M.system -tearoff 0
     set ::TA($W,pinned) 0
     $M.system add separator
     $M.system add checkbutton -label "Always on Top" \
        -variable ::TA($W,pinned) \
        -command "control $W \$::TA($W,pinned)"
  }

  proc control {win how} {
     wm attributes $win -topmost $how
  }
  proc state {win} {
     return [wm attributes $win -topmost]
  }

  wm withdraw .
  toplevel .test
  wm protocol .test WM_DELETE_WINDOW {exit}
  ;##
  ;# Play with system menu, the option will disappear 
  when selected.
  ;#
  pinOnSystemMenu {} .test


tkt_uuid: 587745ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 86. Test Tools
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Duplicate
title: Results of running "make test" on RH7.3
comment:
  Just downloaded tcl/tk 8.4b1 source tar files, built
  them on a freshly
  loaded Redhat 7.3 system with ALL current patches
  (Athlon 1.4Ghz,
  256 MB RAM, IDE disks), and ran make test for both tcl
  and tk.
  The "make test" for tcl was perfect.  The "make test"
  for tk had the
  errors are enclosed below.


tkt_uuid: 587937ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: None
title: Don't shuffle tag list sequence
comment:
  Canvas should not shuffle the tag list sequence (on
  which I'm relying to retrieve "dynamic option"
  parameters) in dtag.

  Current code:

  for (i = itemPtr->numTags-1; i >= 0; i--) {
  if (itemPtr->tagPtr[i] == tag) {
      itemPtr->tagPtr[i] = itemPtr->tagPtr[itemPtr->numTags-1];
      itemPtr->numTags--;
  }
      }

  Rather, it should use memmove to delete the tag.


tkt_uuid: 587939ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 53. [selection]
priority: 5 Medium
foundin: None
resolution: None
title: Access to binary selections on Windows
comment:
  I have an attempt to a tcl proc to decode WMF clipboard
  data into canvas items. However, selection get
  currently only accepts string type data, not binary
  blobs. Could an option be added to selection get to
  indicate the expected type of data, if not string?


tkt_uuid: 588831ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: Free memory read in GenerateFocusEvents
comment:
  Running purify, I ran across a situation which I
  believe has been causing intermittent crashes in our
  application regression tests.  Here's the scenerio: 
  The application has three toplevel windows, ".",
  ".signals", and ".dataflow".   As part of the exit code
  the two toplevel windows, ".signals" and ".dataflow"
  are destroyed.  Free memory reads and writes occur
  while processing background events after the windows
  have been destroyed.  This happens because the focus is
  passed from ".signals" to ".dataflow" when ".signals"
  is really deleted, but ".dataflow" has already been
  marked for removal.  Later, the queued FocusIn event is
  processed, but at this point the ".dataflow" window is
  finally gone and the window ptr has been free'd.  

  I don't have a simple test case for this that can run
  in wish.  I suspect the situation is timing critical
  and changes based on other queued activity.

  The attached patch will prevent the queing of dead windows.

  -Brian


tkt_uuid: 589277ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: 5 panedwindow tests fail
comment:
  ==== panedwindow-13.7 horizontal panedwindow reqheight
  is max slave height FAILED
  ---- Result was:
  20 20
  ---- Result should have been (exact matching):
  20 40
  ==== panedwindow-13.7 FAILED


  ==== panedwindow-13.12 vertical panedwindow reqwidth is
  max slave width FAILED
  ---- Result was:
  20 20
  ---- Result should have been (exact matching):
  20 40
  ==== panedwindow-13.12 FAILED

  ==== panedwindow-20.1 ComputeGeometry, reqheight taken
  from widgets FAILED
  ---- Result was:
  {60 20} {60 20}
  ---- Result should have been (exact matching):
  {60 20} {60 40}
  ==== panedwindow-20.1 FAILED


  ==== panedwindow-20.4 ComputeGeometry, reqwidth taken
  from widgets FAILED
  ---- Result was:
  {20 60} {20 60}
  ---- Result should have been (exact matching):
  {20 60} {40 60}
  ==== panedwindow-20.4 FAILED

  ==== panedwindow-23.1 PanedWindowReqProc, react to
  slave geometry changes FAILED
  ---- Result was:
  40 40
  ---- Result should have been (exact matching):
  40 80
  ==== panedwindow-23.1 FAILED


tkt_uuid: 589396ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Duplicate
title: tk_popup incorrectly placment on Windows
comment:
  I noticed that with 8.4, if a tk_popup menu needs to 
  popup at the bottom of the screen, rather than 
  positioning the bottom of the menu at the cursor, it is 
  offset by the menu height. I noticed the code added 
  below for windows in 8.4 which appears to be causing 
  the problem. If I disable the windows check in the code, 
  everything works fine as it did on 8.3.

  This is under Windows 2000.


  proc ::tk::PostOverPoint {menu x y {entry {}}}  {
      global tcl_platform
      if {[string compare $entry {}]} {
  if {$entry == [$menu index last]} {
      incr y [expr {-([$menu yposition $entry] \
      + [winfo reqheight $menu])/2}]
  } else {
      incr y [expr {-([$menu yposition $entry] \
      + [$menu yposition [expr 
  {$entry+1}]])/2}]
  }
  incr x [expr {-[winfo reqwidth $menu]/2}]
      }
      if {$tcl_platform(platform) == "windows"} {
         puts yes
  # We need to fix some problems with menu 
  posting on Windows.
  set yoffset [expr {[winfo screenheight $menu] 
  \
  - $y - [winfo reqheight $menu]}]
  if {$yoffset < 0} {
      # The bottom of the menu is offscreen, so 
  adjust upwards
      incr y $yoffset
      if {$y < 0} { set y 0 }
  }
  # If we're off the top of the screen (either 
  because we were
  # originally or because we just adjusted too 
  far upwards),
  # then make the menu popup on the top 
  edge.
  if {$y < 0} {
      set y 0
  }
      }
      $menu post $x $y
      if {$entry ne "" && [$menu entrycget $entry -state] 
  ne "disabled"} {
  $menu activate $entry
  GenerateMenuSelect $menu
      }
  }


tkt_uuid: 589804ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Borland support for Tk8.4b1
comment:
  Hello,
  just noticed that Tk8.4b1 didn't build with Borland. I
  add a diff file and a makefile.bc ('cause there ain't
  any yet).
  Items:
  1) The combination of STRINGIFY / JOIN is not
  understood by Borland's resource compiler. I changed it
  back to how it was done up to 8.4a4.
  2) tkWinX.c defines a constant for the MingW compiler.
  However, this clashes with Borland. Added a test for
  Borland.

  Best regards
  Helmut Giese

  PS: Just found out that you can only attach one file,
  so I combined the two files mentioned above.


tkt_uuid: 589853ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: direct interp->result access
comment:
  Tk_ConfigureValue directly read/writes
  to the interp->result field of a Tcl_Interp,
  and directly sets the interp->freeProc
  field as well.

  Such use of Tcl has been deprecated
  for > 5 years.  Tk should stop doing this.


tkt_uuid: 590379ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 25. Built-in Bitmaps
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: Tk_GetBitmapFromData not doc'd
comment:
  Tk_GetBitmapFromData() appears in the 

  .SH NAME

  section of GetBitmap.3, but it is not
  actually documented there.


tkt_uuid: 590704ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Invalid
title: unmap crash in PackReqProc(), tkPack.c
comment:
  I'm using the C interface, on win-32. I'm using mostly 
  script calls (Tcl_Eval) but some Tk library calls where 
  necessary.

  When a Tk dialog is being unmapped, I crash in 
  PackReqProc(), tkPack.c. This happens if I have made 
  the dialog a "transient" to another dialog. If the dialog is 
  not a transient, it can be unmapped without crashing. 
  The unmapping is being done totally under script control.

  On line 482 in tkPack.c, PackReqProc(), it is casting 
  the clientData into packPtr. But packPtr->masterPtr 
  (next line of code) is 0xddddddd (probably not what the 
  author had in mind!).

  The call stack makes me think we shouldn't even be 
  going down this far - it looks like the dialog has already 
  been unmapped but we keep running until we get down 
  to PackReqProc(). Here's the call stack:

  PackReqProc()
  Tk_GeometryRequest()
  ArrangeGrid()
  TclServiceIdle() 
  Tcl_ServiceAll() 
  TkWinChildProc() 
  USER32! 
  USER32! 
  USER32! 
  USER32! 
  NTDLL! 
  Tk_UnmapWindow() line 1733: XUnmapWindow

  As I follow the Tk_UnmapWindow() calling down 
  ultimately to Tk_GeometryRequest(), I get confused by 
  all the cast and nested pointers so I'm afraid I can't offer 
  more insight... 

  Why would we be packing something that's already 
  been unmapped - Can we assume that NTDLL and 
  USER32 are busy trashing the window, following the 
  XUnmapWindow call?


tkt_uuid: 591351ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Windows Tk Icon
comment:
  On behalf of the Windows Python Community I would 
  like to suggest that the Tk Icon in Windows be 
  alterable via Tk/Tcl commands. Presently there is no 
  way to do this succesfuly and we would rather be able 
  to use our own icons than be forced to use the default 
  Tk Icon.


tkt_uuid: 592096ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Remind
title: Tk requires same build setup as Tcl
comment:
  Platform: SPARC Solaris 2.6.
  Sun's C compiler, version WorkShop 6 update 2 C 5.3
  Patch 111679-08 2002/05/09

  On Aug 7, I downloaded a fresh CVS snapshot of tk from
  the ActiveState ftp site.

  I configured using

  $PWD/configure --prefix=/usr/tcl84 --enable-symbols
  --enable-shared

  I then did a make and got this error:

  /usr/ccs/bin/ld -G -z text -o libtk8.4g.so  tk3d.o
  tkArgv.o tkAtom.o tkBind.o tk
  Bitmap.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o
  tkConsole.o tkCursor.o tkEr
  ror.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 tkStyle
  .o tkUndo.o tkUtil.o tkVisual.o tkWindow.o tkUnix.o
  tkUnix3d.o tkUnixButton.o tk
  UnixColor.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 tkPanedWindow.o
  tkScale.o tkScrollbar.o 
  tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o
  tkCanvLine.o tkCanvPoly.o tkCanv
  Ps.o tkCanvText.o tkCanvUtil.o tkCanvWind.o
  tkRectOval.o tkTrig.o tkImage.o tkIm
  gBmap.o tkImgGIF.o tkImgPPM.o tkImgPhoto.o tkText.o
  tkTextBTree.o tkTextDisp.o t
  kTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o
  tkTextWind.o -lsocket -lnsl 
  -L/usr/openwin/lib -lX11 -ldl -lm
  -L/vol/tclsrcsol/tcl84/tcl/unix -ltclstub8.4g 
  -Wl,-R,/usr/tcl84/lib:/usr/openwin/lib
  /usr/ccs/bin/ld: illegal option -- W
  usage: ld
  [-abc:d:e:f:h:il:mo:p:rstu:z:B:D:F:GI:L:M:N:P:Q:R:S:VY:]
  file(s)
          [-a]            create an absolute file
          [-b]            do not do special PIC
  relocations in a.out
          [-c file]       record configuration `file'
          [-d y|n]        operate in dynamic|static mode
          [-e sym]        use `sym' as entry point address
          [-f name]       specify library for which this
  file is an auxiliary
                          filter

  etc.

  Note that the previous version of Tk that I have been
  building was using -R directory rather than
  -Wl,-R,directory


tkt_uuid: 592201ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 9 Immediate
foundin: obsolete: 8.4b1
resolution: Fixed
title: wm transient fails with two masters
comment:
  It seems that "wm transient <window> <master>" has 
  changed between 8.4a2 and 8.4b1. If <master> is 
  specified and is not the empty string, then the 
  <window> must not already have a master.

  The code at the bottom causes the error:

       Fatal Error in Wish

       numTransients should be 0

  ---

  toplevel .t1
  toplevel .t2
  toplevel .transient
  wm transient .transient .t2

  # next line necessary in 8.4b1 but not in 8.4a2 - should 
  it be?
  # wm transient .transient ""

  wm transient .transient .t1
  destroy .t2
  exit


tkt_uuid: 592638ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: remove tcltest dependence
comment:
  Tk's Makefile on Windows enforces
  a dependence of the tktest executable
  on the tcltest executable from Tcl, and
  its components, even though nothing
  in those components is actually used.

  This patch removes this dependence,
  which appears to be vestigial.

  Assigning to kennykb in hopes he
  has time to test this on an appropriate
  platform.  If not, pass along to someone
  who can.


tkt_uuid: 592639ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 7 High
foundin: obsolete: 8.4b2
resolution: Fixed
title: remove tcltest dependence - MAC
comment:
  Here's a patch that removes references
  to Tcl's tcltest executable and its components
  from tkMacAppInit.c.  It uses nothing in them.

  There are probably accompanying changes
  that should be made to the build instructions
  on Mac -- whatever is analogous to a
  Makefile -- but I don't know what that is.


tkt_uuid: 592862ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 86. Test Tools
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: None
title: Tk tests fail to load constraints.tcl
comment:
  I just tried running "make shell" and then loading the
  tests defined in tk/tests/wm.test, but it failed.

  The problem is here:

  package require tcltest 2.1
  namespace import -force tcltest::configure
  namespace import -force tcltest::testsDirectory
  configure -testdir [file join [pwd] [file dirname [info
  script]]]
  configure -loadfile [file join [testsDirectory]
  constraints.tcl]

  When the constraints.tcl file is loaded, it fails
  because the
  system in looking in the build directory and not the source
  directory. For example, I see the following on my system.

  ...
  invalid -loadfile value
  "/usr/local/project/build/tk/constraints.tcl": 
  /usr/local/project/build/tk/constraints.tcl" is not
  readable

  That should be looking for the
  ~/project/tk/tests/constraints.tcl
  file.

  I could have sworn this used to work.


tkt_uuid: 593646ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Out of Date
title: wish can't open library: libtk8.4.dylib
comment:
  I am running MacOS X 10.1.5 with tk8.4b1. The make and make 
  install appear to run correctly. I set the configure prefix to /sw. If I 
  run /sw/bin/wish8.4 from my user directory I get "wish8.4 can't 
  open library: libtk8.4.dylib. If I run /sw/bin/wish8.4 from the src 
  directory /sw/src/tk8.4b1/unix, wish works. This directory contains 
  libtk8.4.dylib.It appears that the install did not set up wish 
  correctly to find libtk8.4. The install did create a /sw/lib/
  libtk8.4.dylib file which the correct permissions. 


tkt_uuid: 594836ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Invalid
title: Bad graphics corruption
comment:
  Hi,

  I noticed some bad graphics corruption *most* of the latest 
  windows releases.  Listboxes for example are most times initially 
  drawn with half the listbox corrupted - almost black out but with 
  distorted horizontal lines in in.   Noticed this on canvas widgets 
  aswell.

  Selecting and item in the listbox usually takes it away and the box 
  is drawn normally.  Sometimes resizing the wondow removes the 
  garbage from listbox and canvas widgets but mostly just re-
  corrupts thier display.

  Sorry if this has already been long posted.


tkt_uuid: 595257ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Borland: Additional info for a TK build
comment:
  Hello David,
  another attempt to get along with SF.
  Just found out that my original patch for building TK
  wasn't  really sufficient: I had been using C++
  Builder, not the command line compiler.
  So, there is another (small) patch necessary: tkWinX.c
  #includes <zmouse.h> - which (being part of MFC) is not
  available in the free compiler. All this file does,
  however, is to contribute the definition of 
  "WM_MOUSEWHEEL".
  No big deal: just include <winuser.h> instead and all
  is fine. I add a diff, comparing my patched version of
  tkWinX.c with the original version.
  Just an idea: *winuser.h" seems like a fairly generic
  header file. If this file contains "WM_MOUSEWHEEL" on
  *all* Windows compilers, we could change the #include
  mentioned above for all of them to "#include
  <winuser.h>", thus avoiding another test for the
  current compiler.
  Just a thought - with the conditional I added it works
  well with the Borland compiler.

  Best regards
  Helmut Giese


tkt_uuid: 597009ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: None
resolution: Fixed
title: configuring tabs is counterintuitive
comment:
  Consider the following script:

  ----
  text .t1 -width 50 -height 3 -font courier -bd 2
  -relief sunken
  text .t2 -width 50 -height 3 -font courier -bd 2
  -relief sunken

  # configure t2 to have tabs set at every 8 characters
  set font [font actual [.t2 cget -font]]
  set emWidth [expr {([font measure $font M]/72.0)/[tk
  scaling]}]
  .t2 configure -tabs "[expr {$emWidth * 8}]i"

  set text "1234567890123456789012345678901234567890
  \tt1\tt2\tt3\tt4
  Hello, World!\ttab\ttab\ttab\ttab
  "
  .t1 insert end $text
  .t2 insert end $text

  pack .t1 .t2 -side top -fill both -expand y
  ----

  Notice that the bottom window has a different behavior
  than the top window, even though the tabstops in both
  windows are, in theory, identical. 

  The problem is, when the widget is configured via
  -tabs, the first occurance of a tab tries to place the
  text at the first tabstop rather than the next tabstop.
  This latter behavior -- moving the text to the next
  tabstop -- is what I consider to be the proper behavior
  since that's what probably every text editor known to
  man does.

  Fixing this could break old scripts, though I doubt
  very few scripts actually rely on this feature. If
  backwards compatibility is a concern, I'd humbly
  suggest another option be added to the text widget,
  such as "-tabmode" (eg: -tabmode traditional)


tkt_uuid: 597012ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Duplicate
title: named color support
comment:
  I'd like "named colors" much like we now have named
  fonts. As an example:

  color create myDefaultColor -rgb #ff0000
  button.b -background myDefaultColor
  ...
  color configure myDefaultColor -rgb #00ff00

  This would make it a lot easier to create application
  preference dialogs which let the user change colors on
  the fly. It might also make it much easier to support
  color themes on all platforms. If all tk widgets
  defaulted to named colors (eg: SystemButtonFace, etc),
  it would be easy to change color schemes on the fly.


tkt_uuid: 597404ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 9 Immediate
foundin: obsolete: 8.4b2
resolution: Works For Me
title: misnamed distribution directory
comment:
  The source distribution tarball unpacks
  into a directory named "tk".  Following
  tradition, the directory should be named
  "tk8.4b2".

  We should note what went wrong and
  avoid a repeat of the problem for the
  Tk 8.4.0 release.

  I would think a `make dist` would do
  the right thing?


tkt_uuid: 597432ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk Build Doesn't Check for Proper Tcl
comment:
  Tk doesn't check for the proper tcl header or configuration.  
  I fetched the CVS head of tcl and tk.  I created a tcl_build 
  directory then ran ../tcl/unix/configure && make.  Tcl built 
  properly.  Then I ran cp -R tk mod_tk and tried to build tk 
  from the mod_tk/unix directory.  I found that tclDecls.h wasn't 
  working, because it was using an older tcl.  Obviously I 
  should have used --with-tcl when configuring Tk, but it seems 
  like some sort of warning should have been displayed about 
  it not finding the proper Tcl version to build with.


tkt_uuid: 597847ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: panic with thread-enabled Tcl
comment:
  On Solaris 8 / CDE, with 8.4b3 Tcl/Tk, and gcc 3.0.3:

  Build Tcl:

      ./configure --enable-threads --disable-shared
      make

  Build Tk:

      ./configure --with-tcl=... --disable-shared
      make

  Try to run wish:

      ./wish
      Tcl_InitNotifier: unable to start notifier thread
      Abort


tkt_uuid: 597920ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 9 Immediate
foundin: obsolete: 8.4b3
resolution: Fixed
title: button appearance/behavior changed
comment:
  In wish 8.4b3,

  % pack [button .b]

  pass the pointer over the button,
  and it will change color (relief?).

  Move the pointer away from the
  button, and it does not change
  back to its original appearance.

  Don't recall seeing this before. 
  Something recent?  Perhaps
  the 2002-08-13 change?


tkt_uuid: 598905ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.4b3
resolution: Works For Me
title: tk test suite select.test failure
comment:
  with a cvs snapshot tar file from activestate's ftp
  site, built against the most recent tcl, I get this new
  error:

  select.test

  ==== select-10.2 ConvertSelection procedure FAILED
  ==== Contents of test case:

      setup
      setupbg
      set selValue [string range $longValue 0 3999]
      set selInfo ""
      selection handle .f1 {handler STRING}
      set result ""
      lappend result [dobg {selection get}]
      cleanupbg
      lappend result $selInfo
  ---- Result was:
  Aa.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ba.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Ca.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Da.1a.2a.3a.4a.5
  a.6a.7a.8a.9a.10a.11a.12a.13a.14Ea.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14
  Fa.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ga.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Ha.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ia.1a.2a.3a.4a.5
  a.6a.7a.8a.9a.10a.11a.12a.13a.14Ka.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14
  La.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ma.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Na.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ab.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Bb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Cb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Db.1b.2b.3b.4b.5b.6b.7b.8b.9b.10
  b.11b.12b.13b.14Eb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Fb.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Gb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Hb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Ib.1b.2b.3b.4b.5b.6b.7b.8b.9b.10
  b.11b.12b.13b.14Kb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Lb.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Mb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Nb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Ac.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Bc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Cc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Dc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14
  Ec.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Fc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Gc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Hc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Ic.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14
  Kc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Lc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Mc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Nc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Ad.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Bd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Cd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Dd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Ed.1d.2d.3d.4d.5
  d.6d.7d.8d.9d.10d.11d.12d.13d.14Fd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Gd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Hd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Id.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Kd.1d.2d.3d.4d.5
  d.6d.7d.8d.9d.10d.11d.12d.13d.14Ld.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Md.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Nd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Ae.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Be.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14Ce.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  De.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ee.1e.2e.3e.4e.5e.6e.7e.8e.9e.10
  e.11e.12e.13e.14Fe.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ge.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14He.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  Ie.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ke.1e.2e.3e.4e.5e.6e.7e.8e.9e.10
  e.11e.12e.13e.14Le.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Me.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14Ne.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  Af.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Bf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Cf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Df.1f.2f.3f.4f.5
  f.6f.7f.8f.9f.10f.11f.12f.13f.14Ef.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14
  Ff.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Gf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Hf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14If.1f.2f.3f.4f.5
  f.6f.7f.8f.9f.10f.11f.12f.13f.14Kf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14
  Lf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Mf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Nf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Ag.1g.2g.3g.4g.5
  g.6g.7g.8g.9g.10g.11g.12g.13g.14Bg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14
  Cg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14Dg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10
  g.11g.12g.13g.14Eg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14Fg.1g.2g.3g.4g.5
   {STRING 0 4000 STRING 4000 4000 STRING 0 4000 STRING
  4000 4000 STRING 0 4000 ST
  RING 4000 4000 STRING 0 4000 STRING 4000 4000}
  ---- Result should have been (exact matching):
  Aa.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ba.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Ca.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Da.1a.2a.3a.4a.5
  a.6a.7a.8a.9a.10a.11a.12a.13a.14Ea.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14
  Fa.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ga.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Ha.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ia.1a.2a.3a.4a.5
  a.6a.7a.8a.9a.10a.11a.12a.13a.14Ka.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14
  La.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ma.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Na.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ab.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Bb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Cb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Db.1b.2b.3b.4b.5b.6b.7b.8b.9b.10
  b.11b.12b.13b.14Eb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Fb.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Gb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Hb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Ib.1b.2b.3b.4b.5b.6b.7b.8b.9b.10
  b.11b.12b.13b.14Kb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Lb.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Mb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Nb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Ac.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Bc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Cc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Dc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14
  Ec.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Fc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Gc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Hc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Ic.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14
  Kc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Lc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Mc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Nc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Ad.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Bd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Cd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Dd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Ed.1d.2d.3d.4d.5
  d.6d.7d.8d.9d.10d.11d.12d.13d.14Fd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Gd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Hd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Id.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Kd.1d.2d.3d.4d.5
  d.6d.7d.8d.9d.10d.11d.12d.13d.14Ld.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Md.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Nd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Ae.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Be.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14Ce.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  De.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ee.1e.2e.3e.4e.5e.6e.7e.8e.9e.10
  e.11e.12e.13e.14Fe.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ge.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14He.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  Ie.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ke.1e.2e.3e.4e.5e.6e.7e.8e.9e.10
  e.11e.12e.13e.14Le.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Me.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14Ne.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  Af.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Bf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Cf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Df.1f.2f.3f.4f.5
  f.6f.7f.8f.9f.10f.11f.12f.13f.14Ef.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14
  Ff.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Gf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Hf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14If.1f.2f.3f.4f.5
  f.6f.7f.8f.9f.10f.11f.12f.13f.14Kf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14
  Lf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Mf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Nf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Ag.1g.2g.3g.4g.5
  g.6g.7g.8g.9g.10g.11g.12g.13g.14Bg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14
  Cg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14Dg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10
  g.11g.12g.13g.14Eg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14Fg.1g.2g.3g.4g.5
   {STRING 0 4000 STRING 4000 4000 STRING 0 4000 STRING
  4000 4000}
  ==== select-10.2 FAILED


tkt_uuid: 600313ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: None
title: Several problems with tkfbox.tcl
comment:
  - I find the FocusIn binding disturbing. If I move
  accidently the cursor out o f the dialog after
  painfully selecting some multiple items, everything is
  lost (I have a FocusFollowsMouse window manager). I
  think it's better to disable the FocusIn and FocusOut
  bindings.

  - There should be nop bindings for Control-B1-Motion,
  Shift-B1-Motion, Control-Double-ButtonRelease-1 and
  Shift-Double-ButtonRelease-1. If multiple items are
  selected and while pressing the control key I do a
  little horizontal movement, all items are deselected.

  - In the IconList_Selection proc there is obviously a
  [incr ind] missing, somewhere around line 107.

  - Is there any reason why Curselection has a lowercase
  "s" while DrawSelection has a uppercase "s"?

  - In IconList_Arrange, a final call to
  IconList_DrawSelection is missing. Otherwise the
  selection will not be correctly redrawn if the window
  is resized.

  - If multiple directories are opened, day /a and /b,
  then tkfbox.tcl seems to chdir first to /a and then
  tries to open b in this directory, which of course
  fails.

  - All references to data(curItem) may be deleted, as
  it's not used anymore.


tkt_uuid: 601518ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 67. Unix Window Operations
priority: 8
foundin: None
resolution: Accepted
title: Fix the two-second raise delay
comment:
  The attached patch fixes the longstanding two second
  "raise delay" seen under certain window managers, by
  making [raise] and [lower] asynchronous.

  A forthcoming TIP describes the changes in detail; for
  now see
  <URL: http://www.flightlab.com/~joe/tcl/raise-delay.txt
  >


tkt_uuid: 601954ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 6
foundin: None
resolution: None
title: destroying menubuttons leaves them unpostable
comment:
  I had the following behavior reported to me, which I have 
  verified on my machine.

  Code to reproduce bug:

  #################
  proc create {} {
  menubutton .mb -text Sample -relief raised -
  menu .mb.menu
  pack .mb
  set m [menu .mb.menu -tearoff 0]
  $m add radio -label One -command {}
  $m add radio -label Two -command {}
  }

  create
  after 10000 {destroy .mb; create}
  #################

  As reported by the other user:

  "The problem occurs if the menu is still posted when the 
  menubutton is destroyed (i.e. no selection was made, or 
  the user did not click outside the window).  Under these 
  circumstance, if the menubutton is then recreated, the 
  menu is no longer dislayed properly (sometimes it won't 
  display at all).  I have tried "unpost"ing the menu before 
  destroying the menubutton but this doesn't seem to 
  have any effect.

  The version of tcl/tk I'm using is 8.4 and the platform is 
  Solaris. Try clicking on the menu button when it comes 
  up and waiting until the program destroys it -- then try to 
  open the menu again.  After some time and multiple 
  clicks the menu usually reappears -- but this behavior is 
  inconsistant and I would like it to be dismissed properly."

  I observed the same behavior on a Linux system 
  (specifically Linux 2.4.8-26mdk) with the KDE window 
  manager (other window managers not tried). I duplicated 
  the behavior using Tcl/Tk 8.3.4 and 8.4b2.

  The same code was able to crash wish (both 8.3.2 and 
  8.4b2) on Windows 2000. If the menu is posted but no 
  items are active (the mouse isn't over the menu), there's 
  no problem; it's as if nothing happened, and the 
  menubutton and menu still work fine. However, if there is 
  an active item (the mouse is over an item), the 
  destroy/create seems to occur, but then as soon as I 
  move my mouse, wish crashes.

  (I'll admit that what the user was doing isn't great 
  programming practice. But wish shouldn't crash as a 
  result.)


tkt_uuid: 602667ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: obsolete: 8.4b3
resolution: Fixed
title: cursor-3.1 fails
comment:
  Building and testing the macosx-8-4-branch tip
  on Solaris/CDE shows 15 new failed tests compared
  to the HEAD.  Would be good to fix these prior/during
  the merge.

  ==== cursor-3.1 Tk_FreeCursorFromObj - reference counts
  FAILED
  ---- Result was:
  {} {} {} {}
  ---- Result should have been (exact matching):
  {{3 1}} {{2 1}} {{1 1}} {}
  ==== cursor-3.1 FAILED

  ==== safe-1.1 Safe Tk loading into an interpreter FAILED
  ---- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):

  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-1.1 FAILED


  ==== safe-1.2 Safe Tk loading into an interpreter FAILED
  ---- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):
  bell cd clipboard encoding exec exit fconfigure file
  glob grab load menu open pwd selection send socket
  source tk toplevel wm
  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-1.2 FAILED


  ==== safe-1.3 Safe Tk loading into an interpreter FAILED
  ---- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):
  encoding exit file load source
  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-1.3 FAILED


  ==== safe-2.1 Unsafe commands not available FAILED
  ---- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):
  ok
  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-2.1 FAILED


  ==== safe-2.2 Unsafe commands not available FAILED
  ---- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):
  ok
  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-2.2 FAILED


  ==== safe-3.1 Unsafe commands are available hidden FAILED
  ---- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):
  ok
  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-3.1 FAILED


  ==== safe-3.2 Unsafe commands are available hidden FAILED
  ---- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):
  ok
  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-3.2 FAILED


  ==== safe-4.1 testing loadTk FAILED
  ---- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):

  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-4.1 FAILED


  ==== safe-4.2 testing loadTk -use FAILED
  ---- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):

  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-4.2 FAILED


  ==== safe-5.2 multi-level Tk loading with clearance FAILED
  ---- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):

  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-5.2 FAILED


  ==== safe-6.1 loadTk -use windowPath FAILED
  ---- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):

  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-6.1 FAILED


  ==== safe-7.1 canvas printing FAILED
  -- Result was:
  Can't find a usable tk.tcl in the following directories: 
      {$p(:147:)}

  $p(:147:)/tk.tcl: script error
  script error
      invoked from within
  "source {$p(:147:)/tk.tcl}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  ---- Result should have been (exact matching):
  0
  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 0 2
  ==== safe-7.1 FAILED

  ==== send-15.1 UpdateCommWindow procedure FAILED
  ---- Result was:
  {tktest {tk #5} {tk #3}} {t_s_2 t_s_1 tktest {tk #5}
  {tk #3}} {t_s_2 tktest {tk #5} {tk #3}} {tktest {tk #5}
  {tk #3}}
  ---- Result should have been (exact matching):
  tktest {t_s_2 t_s_1 tktest} {t_s_2 tktest} tktest
  ==== send-15.1 FAILED

  ==== tk-1.2 tk command: general FAILED
  ---- Result was:
  1 {bad option "xyz": must be appname, caret, scaling,
  useinputmethods, or windowingsystem}
  ---- Result should have been (exact matching):
  1 {bad option "xyz": must be appname, caret, scaling,
  or useinputmethods}
  ==== tk-1.2 FAILED


tkt_uuid: 602680ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 7 High
foundin: obsolete: 8.4b3
resolution: Fixed
title: DBGX needs to die
comment:
  Using all configuration defaults for both Tcl
  and Tk on an AIX system, the tkConfig.sh
  file contains:

  # String to pass to linker to pick up the Tk library
  from its
  # installed directory.
  TK_LIB_SPEC='-bI:/sci-apps/nist/donahue/lib/libtk8.4${DBGX}.exp'


  This looks like a mistake to me, because the name of
  the library (export file) that was built and installed
  by Tk
  is not fully specified.  It remains contingent on the value
  of DBGX.

  Now, Tk had some value of DBGX in effect when it built and
  installed the actual Tk library file, and extensions
  building
  on Tk need to know what that actual Tk library file name is
  so they can add the right options to their linker calls.
  That fully substituted library file name should be
  recorded in tkConfig.sh instead of one containing the
  literal ${DBGX}.


tkt_uuid: 603394ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 34. [tk_chooseColor]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Improve example in man page
comment:
  Just a tiny correction: The example for the
  tk_chooseColor command sets the foreground color. But,
  since there is no text / caption defined for the
  button, nothing shows up. Please change the example to
  work on '-bg' to be a lot more impressive.
  Regards
  Helmut Giese


tkt_uuid: 603781ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: obsolete: 8.4b3
resolution: Out of Date
title: missing heart cursor on macosx?
comment:
  followup on bug #602667:

  according to a comment of Jim's in tk-misc.diff to Jeff:

  4) We don't have a heart cursor, so I made the test
  test for arrow instead.

  which caused problems on other platforms and had to be
  reverted.

  However, it appears we actually have a heart cursor on
  macosx:

  tk/macosx/tkMacOSXXCursors.r:
  data 'CURS' (3031, "heart") {
  ...

  and it appears to work fine here, so I'm not sure what
  the original reason for the change was, is this still a
  problem?


tkt_uuid: 604004ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: None
title: unixWm-51.7 fails
comment:
  On Solaris 8 with CDE:

  ==== unixWm-51.7 TkWmRestackToplevel procedure, other
  window isn't mapped FAILED
  ==== Contents of test case:

      foreach w {.t .t2 .t3} {
          catch {destroy $w}
          toplevel $w -width 200 -height 200 -bg green
          wm geometry $w +0+0
      }
      raise .t .t2
      update
      set result [list [winfo containing 100 100]]
      lower .t3
      lappend result [winfo containing 100 100]

  ---- Result was:
  .t3 .t3
  ---- Result should have been (exact matching):
  .t3 .t
  ==== unixWm-51.7 FAILED

  Perhaps a consequence of TIP 107?


tkt_uuid: 604270ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4b3
resolution: Fixed
title: Button Events not handled properly
comment:
  The code below demonstrates the problem:
  When the mouse moves on, then off, the button the 
  relief should change from raised to flat, like the buttons 
  on ms applications (on linux the relief looks sunken 
  rather than raised, but it has always been that way). 
  Now under 8.4, the relief does not revert when the Any-
  Leave event occurs. The relief gets "stuck". This is post 
  8.4b2 "I think", but it did not occur in 8.4b1.

  ;##
  ;# Demonstrate error in recent 8.4, fails to reset button
  ;#
  option add *Button.borderWidth            1
  option add *Button.font                   menu
  option add *Button.pady                   0
  option add *Button.relief                 flat

  namespace eval balloon {
  }
  proc balloon::button {w help} {
     bind $w <Any-Enter> "balloon::_bubbleIt %W 1"
     bind $w <Any-Leave> "balloon::_bubbleIt %W 0"
  }
  proc balloon::_bubbleIt {W Enter} {
     if {$Enter} {
        $W configure -relief ridge
        puts "$W ridge"
     } else {
        $W configure -relief flat
        puts "$W flat"
     }
  }
  proc test {args} {
     destroy .test
     toplevel .test
     foreach {but} [list a b c d e f] {
        pack [button .test.$but -text "Button $but" -
  command exit] -side left
        balloon::button .test.$but "Help for $but"
     } ;# end foreach
  }
  wm withdraw .
  test


tkt_uuid: 605101ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Fixed
title: Cursor gets wrong shape
comment:
  When a horizontal and a vertical panedwindow are 
  combined, the cursor shape will change to "left/right 
  arrows" where this is not right (in the listbox; in the 
  canvas; over the horizontal pane).

  Seen on Windows 2000 with 8.4b1 Tclkit.

  Sample script:

  panedwindow .p
  .p add [listbox .p.lb]
  panedwindow .p.2 -ori vert
  .p.2 add [text .p.t]
  .p.2 add [canvas .p.c -bg beige]
  .p add .p.2
  pack .p -fill both -expand 1


tkt_uuid: 605105ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Duplicate
title: Panedwindow initially wrong size
comment:
  When a panedwindow is added to another panedwindow, 
  and the second is later filled with content, it is not seen 
  when the toplevel comes up, and has to be drawn wider 
  manually. 
  Workaround: First add contents of child panedwindow, 
  then add it.

  Seen on Windows 2000, Tclkit 8.4b1

  Problem example:
  panedwindow .p
  .p add [listbox .p.lb]
  .p add [panedwindow .p.2 -ori vert]
  .p.2 add [text .p.t]
  .p.2 add [canvas .p.c -bg beige]
  pack .p -fill both -expand 1

  Working counterexample:
  panedwindow .p
  .p add [listbox .p.lb]
  panedwindow .p.2 -ori vert
  .p.2 add [text .p.t]
  .p.2 add [canvas .p.c -bg beige]
  .p add .p.2
  pack .p -fill both -expa(nd 1

  (Richard Suchenwirth)


tkt_uuid: 605121ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 8
foundin: obsolete: 8.4.0
resolution: Fixed
title: segfault in entry var trace / ns delete
comment:
  Reported by Ramon Ribó on CLT:

  interp create local
  local eval { set argc 0 ; set argv "" }
  local eval source notebook.tcl
  interp delete local

  where notebook is the nice Notebook App in
  http://mini.net/cgi-bin/wikit/3712

  (needs BWidgets and other packages installed)

  Stack trace:

  Crash because TclLookupVar is being passed NULL for part1.

  #0  0x1201c8394 in TclLookupVar (interp=0x12043b620,
  part1=0x0, part2=0x0, 
      flags=1, msg=0x120216be7 "set", createPart1=1,
  createPart2=1, 
      arrayPtrPtr=0x11fffe5c0) at ./../generic/tclVar.c:236
  #1  0x1201ca084 in Tcl_SetVar2Ex (interp=0x12043b620,
  part1=0x0, part2=0x0, 
      newValuePtr=0x12051bac0, flags=1) at
  ./../generic/tclVar.c:1430
  #2  0x1201c9f80 in Tcl_SetVar2 (interp=0x12043b620,
  part1=0x0, part2=0x0, 
      newValue=0x1205ba810 "", flags=1) at
  ./../generic/tclVar.c:1367
  #3  0x1201c9ecc in Tcl_SetVar (interp=0x12043b620,
  varName=0x0, 
      newValue=0x1205ba810 "", flags=1) at
  ./../generic/tclVar.c:1311
  #4  0x1200392cc in EntryTextVarProc
  (clientData=0x1205ba5c0, 
      interp=0x12043b620, name1=0x1205312c0 "", 
      name2=0x12054ad40 ".pb-searchtext", flags=192)
      at /local/src/tk/unix/../generic/tkEntry.c:3305
  #5  0x1201ceef8 in CallVarTraces (iPtr=0x12043b620,
  arrayPtr=0x0, 
      varPtr=0x12054ad60, part1=0x1205312c0 "", 
      part2=0x12054ad40 ".pb-searchtext", flags=192,
  leaveErrMsg=0)
      at ./../generic/tclVar.c:4188
  #6  0x1201cff40 in DeleteArray (iPtr=0x12043b620,
  arrayName=0x1205312c0 "", 
      varPtr=0x120576df0, flags=64) at
  ./../generic/tclVar.c:4769
  #7  0x1201cf8b0 in TclDeleteVars (iPtr=0x12043b620,
  tablePtr=0x120589ac8)
      at ./../generic/tclVar.c:4573
  #8  0x12019ede8 in TclTeardownNamespace (nsPtr=0x1205899d0)
      at ./../generic/tclNamesp.c:761
  #9  0x12019eb04 in Tcl_DeleteNamespace
  (namespacePtr=0x1205899d0)
      at ./../generic/tclNamesp.c:640
  #10 0x12019eea0 in TclTeardownNamespace (nsPtr=0x1204df7a0)
      at ./../generic/tclNamesp.c:791
  #11 0x12019eb04 in Tcl_DeleteNamespace
  (namespacePtr=0x1204df7a0)
      at ./../generic/tclNamesp.c:640
  #12 0x12019eea0 in TclTeardownNamespace (nsPtr=0x12043b920)
      at ./../generic/tclNamesp.c:791
  #13 0x120119e14 in DeleteInterpProc (interp=0x12043b620)
      at ./../generic/tclBasic.c:990
  #14 0x1201b3504 in Tcl_EventuallyFree
  (clientData=0x12043b620, 
      freeProc=0x120119d80 <DeleteInterpProc>) at
  ./../generic/tclPreserve.c:313
  #15 0x120119d60 in Tcl_DeleteInterp (interp=0x12043b620)
      at ./../generic/tclBasic.c:927
  #16 0x12017e7d0 in SlaveObjCmdDeleteProc
  (clientData=0x12043b620)
      at ./../generic/tclInterp.c:2031
  #17 0x12011be5c in Tcl_DeleteCommandFromToken
  (interp=0x1203462f0, 
      cmd=0x1203d8bc0) at ./../generic/tclBasic.c:2447
  #18 0x12017b544 in Tcl_InterpObjCmd (clientData=0x0,
  interp=0x1203462f0, 
      objc=3, objv=0x11ffff080) at
  ./../generic/tclInterp.c:511
  #19 0x12011cf3c in TclEvalObjvInternal
  (interp=0x1203462f0, objc=3, 
      objv=0x11ffff080, command=0x12043b5d4 "interp
  delete local\n", length=20, 
      flags=0) at ./../generic/tclBasic.c:3033
  #20 0x12011e05c in Tcl_EvalEx (interp=0x1203462f0, 
      script=0x12043aef0 "interp create local\nlocal eval
  [list set argc 0]\nlocal eval [list set argv {}]\nlocal
  eval {\nset notebookVersion \"V0.9\"\npackage require
  Tk\nset appdir [file dirname [info script]]\nlappend
  auto_path [fil"..., 
      numBytes=1784, flags=0) at ./../generic/tclBasic.c:3631
  #21 0x120191608 in Tcl_FSEvalFile (interp=0x1203462f0,
  pathPtr=0x1203b76b0)
      at ./../generic/tclIOUtil.c:1371
  #22 0x120190288 in Tcl_EvalFile (interp=0x1203462f0, 
      fileName=0x11ffff3e8 "crash.tcl") at
  ./../generic/tclIOUtil.c:234
  #23 0x12001b348 in Tk_MainEx (argc=1, argv=0x11ffff550, 
      appInitProc=0x12001ae80 <Tcl_AppInit>,
  interp=0x1203462f0)
      at /local/src/tk/unix/../generic/tkMain.c:234
  #24 0x12001ae58 in main (argc=2, argv=0x11ffff548)
      at /local/src/tk/unix/tkAppInit.c:68


tkt_uuid: 605277ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Fixed
title: ctrl-v paste doesn't work on Linux
comment:
  On Linux, I cannot use ctrl-V to paste text into a text widget 
  that I copied using ctrl-C or ctrl-X.  It works fine on Win32.

  Ctrl-C works. Ctrl-X works. Ctrl-V doesn't work. 

  This problem (on Linux) was there in 8.3.3 as well;
  I upgraded to 8.4b2 ... problem still present.

  For grins, here is the test script I used:

  #! /usr/bin/wish -f 

  global GotSelection 
  set GotSelection 0 

  frame .fr -width 10c -height 5c ;#main window 
  wm title . "Simple Text Editor V 0" 
  pack .fr 

  #configure menubar on top 
  frame .menubar -relief raised -bd 2 
  pack .menubar -in .fr -fill x 
  frame .edf 

  #put a text widget with scroll bars 

  text .ed -width 80 -height 20 -bg grey \ 
  -yscrollcommand ".ys set" 

  scrollbar .ys -command ".ed yview" 
  pack .ed .ys -in .edf -side left -fill y 

  pack .edf -in .fr -after .menubar -fill x 


tkt_uuid: 606546ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Invalid
title: LEFT-CLICK maximize doesn't always
comment:
  The bug is that the LEFT-CLICK won't expand the window
  in all directions if the width is already maximized, or
  if the height is already maximized.  LEFT-CLICK (Button
  1) will only have effect if both the width and height
  are not at maximum.

  What I expect is that a LEFT-CLICK of the maximize
  control will toggle between fully maximized in all
  direction and the unmaximized dimensions.

  I'm basing that on the following expected behavior of
  maximize control in the title bar of main window (frame):

  1. LEFT-CLICKing the maximize control is suppose to expand
  the window in both directions.
  2. MIDDLE-CLICKing the maximize control is supposed to
  expand the window vertically
  3. RIGHT-CLICKing the maxmize control is supposed to expand
  the window horizontally.

  I'm using Tk/Tcl 8.4b2 on Linux 2.4.9 with Gnome.


tkt_uuid: 606658ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: various MacOSX fixes.
comment:
  The attached patch provides fixes for the following 
  problems:

  tk.tcl:
  (1) ctrl-z/x/c/v are used for cut/copy/etc.  This 
  should be 'command' on aqua.
  (2) dialogs can appear under the menubar.

  tkMacOSXKeyEvent.c:
  (1) Keypress/release events for pure modifier keys 
  were not being passed to Tk.
  (2) Deadkey presses were inserting null characters 
  into text windows.  Now they do nothing.  (Still not 
  ideal, but better than before!)

  tkMacOSXMenu.c:
  (1) Allow more than 200 menus to exist.  (Increased 
  to 2000).

  tkMacOSXMouseEvent.c:
  (1) Bad interactions between floating windows and 
  ordinary ones.  Ensure that local<->global 
  coordinate transformations are wrt to the correct 
  window.

  tkMacOSXWm.c:
  (1) Better error msg for 'wm attributes'
  (2) Remove crash in 'wm transient'
  (3) Add 'noActivates' and 'noUpdates' flags to 
  unsupported command.


tkt_uuid: 606665ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Fixed
title: [wm attributes] missing docs for Mac!
comment:
  The paragraph about the [wm attributes] command on the
  Mac ends rather abruptly (middle of a sentence!)  Has
  something got lost here?


tkt_uuid: 606719ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Message: File "$item" does not exist.
comment:
  Line 835 of xmfbox.tcl reads:
  tk_messageBox -icon warning -type ok \
      -message [::msgcat::mc {File "$item" does not exist.} \
          $item]

  It should read:
  tk_messageBox -icon warning -type ok \
      -message [::msgcat::mc {File "%1$s" does not exist.} \
          $item]

  The variable substitution fails with the current code.


tkt_uuid: 607009ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: patches to build 8.4.0 with CW 6.3
comment:
  After some tweaks, I managed to build Tk 8.4.0 (CVS as 
  of a few days ago) with CodeWarrior 6.3, as part of the 
  recent TclKit 8.4.0 build fest.

  Most changes affect CONST.  Some changes tell me the 
  code has not been built for a long time (perhaps code 
  moved around or added to mac without testing), given 
  that there were typo's among them.

  Some changes may be due to switching to MoreFiles 1.5.3 
  (was 1.5.2, I think).

  The Universal Interfaces version I used was 3.4.1, 
  applying all patches mentioned by Daniel Steffen in the 
  docs and rebuilding all libraries, as advised.  Latest 
  is now 3.4.2, but this was not tried.

  One or two casts will cast CONST away, but as far as I 
  can tell this is valid because in each of those cases 
  the pointers are known to be allocated.


tkt_uuid: 607390ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Duplicate
title: segfault in entry var trace
comment:
  Another segfault similar to 605121:

  set FOO init
  entry .e1 -textvariable FOO -validate all \
      -vcmd {%W configure -bg white; format 1}
  bind .e1 <Destroy> {set FOO hello}
  destroy .e1

  Again the problem is that EntryTextVarProc passes a NULL
  varName to Tcl_SetVar.



  Program received signal SIGSEGV, Segmentation fault.
  0x1201c8394 in TclLookupVar (interp=0x120346320,
  part1=0x0, part2=0x0,
      flags=1, msg=0x120216bef "read", createPart1=0,
  createPart2=1,
      arrayPtrPtr=0x11fffddb8) at
  ../unix/../generic/tclVar.c:236
  236         for (p = part1; *p ; p++) {
  (gdb) bt
  #0  0x1201c8394 in TclLookupVar (interp=0x120346320,
  part1=0x0, part2=0x0,
      flags=1, msg=0x120216bef "read", createPart1=0,
  createPart2=1,
      arrayPtrPtr=0x11fffddb8) at
  ../unix/../generic/tclVar.c:236
  #1  0x1201c99ac in Tcl_GetVar2Ex (interp=0x120346320,
  part1=0x0, part2=0x0,
      flags=1) at ../unix/../generic/tclVar.c:1075
  #2  0x1201c98cc in Tcl_GetVar2 (interp=0x120346320,
  part1=0x0, part2=0x0,
      flags=1) at ../unix/../generic/tclVar.c:1027
  #3  0x1201c9844 in Tcl_GetVar (interp=0x120346320,
  varName=0x0, flags=1)
      at ../unix/../generic/tclVar.c:987
  #4  0x12003931c in EntryTextVarProc
  (clientData=0x120436de0,
      interp=0x120346320, name1=0x120439f80 "FOO",
  name2=0x0, flags=32)
      at /local/src/tk/unix/../generic/tkEntry.c:3321
  #5  0x1201ceef8 in CallVarTraces (iPtr=0x120346320,
  arrayPtr=0x0,
      varPtr=0x120436120, part1=0x120439f80 "FOO",
  part2=0x0, flags=32,
      leaveErrMsg=512) at ../unix/../generic/tclVar.c:4188
  #6  0x1201ca874 in TclPtrSetVar (interp=0x120346320,
  varPtr=0x120436120,
      arrayPtr=0x0, part1=0x120439f80 "FOO", part2=0x0,
  newValuePtr=0x1203b3b00,
      flags=512) at ../unix/../generic/tclVar.c:1658
  #7  0x1201ca208 in Tcl_ObjSetVar2 (interp=0x120346320,
  part1Ptr=0x1203ddb20,
      part2Ptr=0x0, newValuePtr=0x1203b3b00, flags=512)
      at ../unix/../generic/tclVar.c:1492
  #8  0x1201c9df8 in Tcl_SetObjCmd (dummy=0x0,
  interp=0x120346320, objc=3,
      objv=0x11fffe450) at ../unix/../generic/tclVar.c:1263
  #9  0x12011cf3c in TclEvalObjvInternal
  (interp=0x120346320, objc=3,
      objv=0x11fffe450, command=0x11fffe668 "set FOO
  hello", length=13, flags=0)
      at ../unix/../generic/tclBasic.c:3048
  #10 0x12011e05c in Tcl_EvalEx (interp=0x120346320,
      script=0x11fffe668 "set FOO hello", numBytes=13,
  flags=0)
      at ../unix/../generic/tclBasic.c:3646
  #11 0x12011e5dc in Tcl_Eval (interp=0x120346320,
      string=0x11fffe668 "set FOO hello") at
  ../unix/../generic/tclBasic.c:3811
  #12 0x120120ec4 in Tcl_GlobalEval (interp=0x120346320,
      command=0x11fffe668 "set FOO hello") at
  ../unix/../generic/tclBasic.c:5261
  #13 0x1200c723c in Tk_BindEvent (bindingTable=0x1203a2400,
      eventPtr=0x11fffead8, tkwin=0x120436170, numObjects=0,
      objectPtr=0x11fffe910) at
  /local/src/tk/unix/../generic/tkBind.c:1805
  #14 0x1200d00a4 in TkBindEventProc (winPtr=0x120436170,
  eventPtr=0x11fffead8)
      at /local/src/tk/unix/../generic/tkCmds.c:287
  #15 0x1200dbc7c in Tk_HandleEvent (eventPtr=0x11fffead8)
      at /local/src/tk/unix/../generic/tkEvent.c:1017
  #16 0x12001d634 in Tk_DestroyWindow (tkwin=0x120436170)
      at /local/src/tk/unix/../generic/tkWindow.c:1356
  #17 0x1200d07cc in Tk_DestroyObjCmd
  (clientData=0x1203a11b0,
      interp=0x120346320, objc=2, objv=0x11fffef10)
      at /local/src/tk/unix/../generic/tkCmds.c:472
  #18 0x12011cf3c in TclEvalObjvInternal
  (interp=0x120346320, objc=2,
      objv=0x11fffef10, command=0x120436106 "destroy
  .e1\n", length=12, flags=0)
      at ../unix/../generic/tclBasic.c:3048
  #19 0x12011e05c in Tcl_EvalEx (interp=0x120346320,
      script=0x120436080 "set FOO init\nentry .e1
  -textvariable FOO -validate all
  \\\n\t-vcmd {%W configure -bg white; format 1}\nbind
  .e1 <Destroy> {set FOO hell
  o}\ndestroy .e1\n", numBytes=146, flags=0)
      at ../unix/../generic/tclBasic.c:3646
  #20 0x120191608 in Tcl_FSEvalFile (interp=0x120346320,
  pathPtr=0x1203b3b60)
      at ../unix/../generic/tclIOUtil.c:1371
  #21 0x120190288 in Tcl_EvalFile (interp=0x120346320,
      fileName=0x11ffff278 "seg3.tcl") at
  ../unix/../generic/tclIOUtil.c:234
  #22 0x12001b348 in Tk_MainEx (argc=1, argv=0x11ffff3e0,
      appInitProc=0x12001ae80 <Tcl_AppInit>,
  interp=0x120346320)
      at /local/src/tk/unix/../generic/tkMain.c:234
  #23 0x12001ae58 in main (argc=2, argv=0x11ffff3d8)
      at /local/src/tk/unix/tkAppInit.c:68


tkt_uuid: 607649ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Duplicate
title: XP Menu Sizing and Image Problems
comment:
  The screenshots here demonstrate the bugs: 
  http://www.xmission.com/~georgeps/bugs/

  As you can see the menu items get cut off on the right.  
  This shows up with images mostly, and it seems that 
  images don't animate properly in TkChat with the 
  current menu code (redraw issue?).  These problems 
  don't occur with Tcl/Tk 8.3.2 in XP.  Jeff Hobbs thought 
  that it might be a bug introduced by the compound 
  menu code.


tkt_uuid: 607657ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Duplicate
title: Entry validation seg-fault after destroy
comment:
  The following script produces a segmentation fault under Windows 2000,
  when the "-textvariable FOO" is written *after destroying* the entry widget.

  It may be helpful to notice that there is no seg-fault,
  if the windows configuration in the validation procedure is made
  "after idle" (see commented line).

  ######################################
  proc validate {win event val} {
      set ok [expr {[string length $val] < 8}]
  #    after idle [list $win configure -bg [expr {$ok ? "white" : "yellow"}] ]
      $win configure -bg [expr {$ok ? "white" : "yellow"}]
      set ok
  }
  proc fooWin {} {
      toplevel .t
      entry .t.e1 -textvariable FOO -validate all -vcmd {validate %W %V %P}
      pack .t.e1
      focus .t.e1
  }

  set FOO "foo1"
  fooWin

  after 3000 {destroy .t}
  after 5000 {set FOO "hallo"}
  ######################################


tkt_uuid: 608115ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Fixed
title: Tk virtual events not documented
comment:
  The initialization script of Tk, $tk_library/tk.tcl,
  defines
  several virtual events with the [event add] command.
  Effective users of Tk need to know what these events
  are, but they are not documented.


tkt_uuid: 608690ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: wm geometry slow on Linux
comment:
  On comp.lang.tcl, Ian Gay reports that:

  1. A script was ok on Windows and showed slow response
  on Linux.
  2. Inspection showed I was frequently doing the
  equivalent of
     [wm geometry . [wm geometry .]]
  3. When I stopped doing this the script worked ok on
  Linux. Tentative       
  conclusion: Linux spends a lot of time in wm geometry.
  4. Joe English reported, and I confirm, that
     time  {wm geometry . [wm geometry .]} 1000 shows
  that wm geometry does not 
  take a long time, it executes in microseconds, so that
  can't be the answer.
  5. If I source the whole script and run it a bit, and
  then time the routine in 
  which wm geometry occurs, I also find that routine to
  be fast.
  6. If I disable my binding on <Configure> then the
  response is good, even when 
  doing the unnecessary [wm geometry . [wm geometry .]]
  calls.
  7. Aha! Obviously [wm geometry . [wm geometry .]]
  generates a <Configure> 
  event and I have gone into some kind of loop or race.
  8. No. When I instrument my <Configure> callback to
  show when it is run, I 
  find that [wm geometry . [wm geometry .]] does not
  generate a <Configure>.

  Slaven Rezic provided the missing clue:

  > Add "update" or "update idletasks" [after wm
  geometry].

  The problem occurs under icewm, fvwm2 and twm.


tkt_uuid: 608698ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 8
foundin: obsolete: 8.4.0
resolution: Fixed
title: SC_PATH_TCLCONFIG favors betas
comment:
  When no --with-tcl= option is given to configure,
  and both tcl8.4.0 and tcl8.4b1 source distros are
  siblings of the unpacked Tk source distro, then
  unix/configure will happily point the compiler to
  tcl8.4b1/generic/tcl.h which does not work.

  Seems that as long as Tk and Tcl get released
  in lock step, the matching version of Tcl should
  get a preferred status in the search path.

  Even if we break away from that, it would be
  good for stable distros to be preferred over alpha
  and beta ones.


tkt_uuid: 610641ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Fixed
title: incorrect %A docs in bind(n)
comment:
  bind(n) says:

       %A   Substitutes the ASCII character 
  corresponding  to  the
            event,  or  the  empty  string  if  the 
  event  doesn't
            correspond to an ASCII character (e.g.  the 
  shift  key
            was  pressed).   XLookupString  does  all 
  the  work of
            translating from  the  event  to  an  ASCII 
  character.
            Valid only for KeyPress and KeyRelease events.

  With Unicode encodings and XIM the truth is more complex
  than that; you can get non-ASCII characters from a %A.

  Also, the subtitution is described incorrectly.  The
  substitution
  is done with Tcl_ConvertElement() which *never* substitutes
  "the empty string".  If the empty string would be
  called for,
  it gets brace-quoted, and the true substitution is
  "{}".  Since
  all string values of %-substitutions in [bind] are
  inserted with
  Tcl_ConvertElement(), there are probably other errors in
  bind(n) also, misleading users into thinking that
  %-subsitutions
  in [bind] are like those in [format], when they are not.


tkt_uuid: 611615ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Accepted
title: Unwanted mouse events after double click
comment:
  Unwanted mouse messages are sent to the underneath
  window after double clicking in the file open dialog box.

  See patch for detailed explanation. It's a bug in the
  windows operating system, and this is a tried and
  tested work around.

  Changes have been made to TkWinDialog.c


tkt_uuid: 612110ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: obsolete: 8.4.0
resolution: Fixed
title: Crash on FocusIn / FocusOut binding
comment:
  Jakub Travnik wrote:
  > Jakub Travnik wrote:
  >> P.S.: searching ruby-talk archive show that this bug
  has been noticed
  >> before but with no attempt to correct it. But since
  python can do it
  >> and ruby tcl/tk is modeled after python's so it
  should be fixable.
  >>
  > 
  > Hello,
  > 
  > I have solved the problem. Bug is in the Tk itself,
  see following
  > tcltk code:
  > ----cut_here-------------------
  > entry .e1 -width 10
  > entry .e2 -width 10
  > label .l1 -text "initial"
  > pack .e1 -side left
  > pack .e2 -side left
  > pack .l1 -side left
  > bind .e1 <FocusIn> {.l1 configure -text %S}
  > bind .e1 <FocusOut> {.l1 configure -text %S}
  > -------------------------------
  > 
  > This will crash in Tk_GetHWND called from
  TkpPrintWindowId
  > called from case "%S" in ExpandPercents when
  FocusIn/FocusOut event
  > happen.
  > 
  <snip>

  > 
  > Long term fix is to remove %S from tk.rb file
  depending on event, or
  > fix tcl/tk windows version to behave in correct way
  for this situation.
  > 
  I can confirm the crash with tcl/tk 8.4.0 from cvs.
  Windows 2000.

  Michael Schlenker

  callstack dump:
  Tk_GetHWND(unsigned long 3) line 147 + 3 bytes
  TkpPrintWindowId(char * 0x0012f800, unsigned long 3)
  line 174 + 15 bytes
  ExpandPercents(TkWindow * 0x00a23cc8, const char *
  0x00a1f06c, _XEvent * 
  0x00a7f798, unsigned long 0, Tcl_DString * 0x0012faa4)
  line 2576 + 19 bytes
  Tk_BindEvent(Tk_BindingTable_ * 0x008c4448, _XEvent *
  0x00a7f798, 
  Tk_Window_ * 0x00a23cc8, int 4, void * * 0x0012fbc0)
  line 1670 + 40 bytes
  TkBindEventProc(TkWindow * 0x00a23cc8, _XEvent *
  0x00a7f798) line 288 + 
  31 bytes
  Tk_HandleEvent(_XEvent * 0x00a7f798) line 1017 + 13 bytes
  WindowEventProc(Tcl_Event * 0x00a7f790, int -3) line
  1399 + 12 bytes
  Tcl_ServiceEvent(int -3) line 622 + 11 bytes
  Tcl_DoOneEvent(int -3) line 861 + 9 bytes
  Tk_MainLoop() line 1457 + 13 bytes
  Tk_MainEx(int 1, char * * 0x008626c8, int (Tcl_Interp
  *)* 0x00401005 
  _Tcl_AppInit, Tcl_Interp * 0x00864790) line 285
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ *
  0x00000000, char * 
  0x0013285d, int 10) line 140 + 26 bytes
  WinMainCRTStartup() line 330 + 54 bytes
  KERNEL32! 77e7d326()


tkt_uuid: 614240ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: WINSCP and dde services
comment:
  Theres a Windows SSH client called WinSCP2 from http://winscp.vse.cz/eng/

  Running version 2.0.0 build 89 with tk 8.3.3, that software will slow Tcl's
  dde command by a factor of 100 when it's transfering files.

  % dde server foo
  foo
  % dde services {TclEval} {}
  {TclEval foo}

  # During a file transfer

  % time {dde services {TclEval} {}}
  6710000 microseconds per iteration
  % time {dde services {TclEval} {}}
  6650000 microseconds per iteration
  % time {dde services {TclEval} {}}
  6100000 microseconds per iteration
  % time {dde services {TclEval} {}}
  6490000 microseconds per iteration

  # After the transfer is complete (WINSCP still running).

  % time {dde services {TclEval} {}}
  60000 microseconds per iteration

  No other applications on the desktop seem to suffer when WINSCP2 is running.

  Windows ME for what it's worth.


tkt_uuid: 614325ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Invalid
title: Tk crash upon Tcl_DeleteInterp...
comment:
  The problem [apparently] stems from having no 
  main windows upon entering the following routine 
  at the bottom of this report.  The "dispPtr" local 
  variable is set to the result of a function.  The 
  resulting pointer is NOT checked for a NULL value 
  prior to dereferencing the pointer in the IF 
  statement that follows.  At some point, the 
  assumption might have been made that there 
  would always be a main window???

  void
  Tk_FreeGC(display, gc)
      Display *display;/* Display for which 
  gc was allocated. */
      GC gc;/* Graphics context 
  to be released. */
  {
      Tcl_HashEntry *idHashPtr;
      register TkGC *gcPtr;
      TkDisplay *dispPtr = TkGetDisplay(display);

      if (!dispPtr->gcInit) {
  panic("Tk_FreeGC called before 
  Tk_GetGC");
      }
      if (dispPtr->gcInit < 0) {
  /*
   * The GCCleanup has been called, and 
  remaining GCs have been
   * freed.  This may still get called by 
  other things shutting
   * down, but the GCs should no longer be 
  in use.
   */
  return;
      }

  --
  JJM


tkt_uuid: 614474ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: UMR in TextBlinkProc
comment:
  A run through purify spots that certain redraw events 
  (enter?) when the text cursor has been set off the edge of 
  the visible text widget area causes uninitialised accesses to 
  memory. The solution is simply to check the return code of 
  TkTextCharBbox.


tkt_uuid: 614650ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 8
foundin: obsolete: 8.4.0
resolution: Fixed
title: Tk crashes when pasting large selections
comment:
  When a selection of more than 3999 bytes gets pasted
  from a Tk text widget into e.g. vi running inside
  xterm, wish crashes with a segfault.

  This can be reproduced by the following script:

  pack [text .t] -expand yes -fill both
  .t insert end [string repeat a 4000]

  Select the whole content of the text widget by
  double-click and try to paste it elsewhere. I observed
  this crash on SuSE Linux 8.0, and 8.1 under fvwm2 and
  windowmaker.

  The following little patch fixes the segfault, but
  pasting selections > 3999 bytes still doesn't work
  after applying it.

  --- tkUnixSelect.c      2002/09/25 21:03:59     1.1
  +++ tkUnixSelect.c      2002/09/25 21:25:58
  @@ -469,7 +469,7 @@
                          eventPtr->xproperty.window,
                          eventPtr->xproperty.atom,
  formatType, 8,
                          PropModeReplace,
  -                       (unsigned char *)
  Tcl_DStringValue(&ds), numItems);
  +                       propPtr, numItems);
                  Tk_DeleteErrorHandler(errorHandler);
   
                  ckfree(propPtr);


tkt_uuid: 615302ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Fixed
title: Tcl_Finalize, Tcl/Tk unloading crash
comment:
  Currently, you must call Tcl_Finalize manually prior 
  to calling FreeLibrary on the Tcl DLL because the 
  Tcl_Finalize routine called in Tcl's DllMain calls Tk 
  exit handlers after the Tk DLL was unloaded via 
  FreeLibrary

  It is my belief that it is a Tk bug, because I think Tk 
  should remove it's own exit handlers in it's DllMain 
  when it detects it has been unloaded by 
  FreeLibrary...

  ----

  The following sequence of calls will cause the error:

  ----

  FreeLibrary(hModuleTk); // unload Tk DLL
  hModuleTk = NULL;

  FreeLibrary(hModuleTcl);  // unload Tcl DLL
  hModuleTcl = NULL;

  ----

  The following sequence of calls will NOT cause the 
  crash:

  ----

  Tcl_Finalize(); // finalize first...

  FreeLibrary(hModuleTk); // unload Tk DLL
  hModuleTk = NULL;

  FreeLibrary(hModuleTcl);  // unload Tcl DLL
  hModuleTcl = NULL;

  ----


tkt_uuid: 616245ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 7 High
foundin: obsolete: 8.4.1
resolution: Fixed
title: tk main eats first arg
comment:
  When built as tclkit, tkMain.c cannot be made to ignore
  the first argument.  The logic is quite broken, because
  appinit gets called too late to prevent tclMain.c and
  tkMain.c from abosrbing a first arg.  This required for
  starpacks - which should *not* treat their first args
  as scripts.  I currently get around this by repairing
  the damage in my custom appinit hook - it's a bad hack
  but it works.

  Unfortunately, on Windows it still fails.  The fix is
  quite easy: introduce the same logic in tkMain.c as is
  already in tclMain.c.  I've attached the patch which
  does this.

  The above patch also removes the "-file" arg handling,
  because that would cause starpacks to still drop a
  leading "-file" arg - I hope this historical "feature"
  can be dropped now.  It's not a showstopper - just a
  timebomb for starpack use.

  -jcw


tkt_uuid: 616589ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 9 Immediate
foundin: obsolete: 8.4.0
resolution: Fixed
title: Segfault with panedwindow
comment:
  Hi,

  libtk segfaults on next simple example:

  #!/usr/bin/wish
  panedwindow .sample_panedwindow -variable
  example_panedwindow

  I know that -variable is invalid option but libtk
  should not Segfault.


tkt_uuid: 616791ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Blinking cursor drawing bug
comment:
  TextBlinkProc() tries to draw the insertion indicator even 
  when it is not visible. The result of TkTextCharBbox() is 
  ignored (it could be -1).

      TkTextCharBbox(textPtr, &index, &x, &y, &w, &h);
      TkTextRedrawRegion(textPtr, x - textPtr-
  >insertWidth / 2, y,
      textPtr->insertWidth, h);


tkt_uuid: 616923ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Invalid
title: Selection not always claimed by text
comment:
  The following will not claim the selection:
    pack [text .t]
    update
    .t insert 1.0 "any text" sel

  Note that the problem is independent of the index, but
  things work if the text widget was the last window on
  the display to claim the selection.  However if the
  selection was anywhere else (including another Tk
  widget in the same toplevel as the text widget) the
  selection will not be claimed by the text (though it
  will be highlighted as if it is.


tkt_uuid: 616985ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 7 High
foundin: None
resolution: Fixed
title: crash in scrollbar
comment:
  Open a console in the latest aquatk binary release.  
  Hit return a bunch of times so the scrollbar is 
  active.  Click in the trough (or one of the arrows), 
  and crash!

  If compiled with OS X 10.1.5, this doesn't happen.


tkt_uuid: 616986ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: Wish won't 'Hide'
comment:
  Tkaqua ignores the MacOS X 'Hide' operation (either 
  through hide others, or hide self).

  When hiding, Tkaqua should withdraw all of its 
  windows, etc.


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: 617392ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Fixed
title: File browser scales wrongly on Unix/Linu
comment:
  On Unix/Linux the file browser scales wrongly if one is 
  using a very long list of file types "that had a
  gazillion *.xxx types attached".

  One needs an option to control the width of the file 
  browser widget in cases like this.


tkt_uuid: 617446ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 8
foundin: None
resolution: Fixed
title: Segfault, Entry -textvariable, trace textvariable, destroy
comment:
  Situation:
  - wish8.3.4 under Linux
  - an entry uses the textvariable option
  - an unset trace (any trace?) on the text-variable
  invokes a command that affects the entry or accesses
  its -textvariable option
  - segmentation fault occurs

  Reproducible script below

  dgp writes at 1-10-02 in c.l.t..:
  - Reproduced with wish 8.4.0.
  - Is this just a variation of Tk Bug 607390 ?


  -- reproducible script --

  package require Tk
  set sec 2
  set textvar "Crashes after $sec seconds"
  pack [entry .e -textvariable textvar]
  update; # `update idletasks' doesn't do the trick here
  (KDE wm)
  trace variable textvar u destroyEntry
  proc destroyEntry {args} {
      # this crashes the program
      destroy .e
      # this will also if you comment out the cause of
  crash right above.
      .e configure -textvariable {}
  }
  after [expr {$sec*1000} ]
  unset textvar


  -- end of message --


tkt_uuid: 618096ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: None
title: menu bugs with huge display (xinerama)
comment:
  (FYI, tk bug reporting is very well hidden from the
  tcl/tk home page)

  Environment: Solaris 8, openwin X11 server, CDE
  window manager (dtwm) I'm running X in "Xinerama"
  mode with one logical screen across two physical
  displays.  To X clients, it appears as if there
  is one single 2560x1024 display.

  Both of the problems below occur when a Tk window
  is moved to the right half of the screen (into
  the second monitor), but it doesn't happen
  exactly at the same spot each time.  Sometimes I
  can get a window fully into the right monitor,
  plus another 20 or 30 pixels without problems,
  but then if I move it farther to the right, the
  problems start.

  First, menus (at least within a menubar) become
  very slow and unresponsive.  They don't respond
  at all to press-and-drag menu selection.  Once
  started, this problem persists regardless of
  where the window is posistioned.

  Second when submenus of a menu are posted, they
  appear at the correct y, but far to the left, in
  the first monitor.  This problem eventually goes
  away if the window is moved to the left again,
  but also not at a consistent x-position.

  I checked winfo: x, y, rootx, rooty, screenwidth,
  screenheight, pointerx, and pointery all return
  values that you'd expect for the main window
  regardless of where the window is.  However when
  I post a menu with ".mb1.menu1 post 1800 120",
  and the immediately do "winfo rootx .mb1.menu1",
  it returns 520, which is 1800-1280, and 1280 is
  half the screen width, one monitor width.  The
  menu still appears in the right half of the
  screen though.  If I then call ".mb1.menu1
  postcascade 2", the sub menu winds up (not
  surprisingly) at an x of 639, both visibly and as
  reported by winfo rootx.  (winfo x reports the
  same as winfo rootx in these two cases also.)

  dtwm uses a "rooms" virtual window paradigm, so
  vrootx and vrooty should always be zero, and they
  are reported as such.  vrootwidth and vrootheight
  are also reported correctly by winfo.


tkt_uuid: 618872ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 8
foundin: obsolete: 8.4.6
resolution: Fixed
title: segfault due to re-used memory
comment:
  In doing the perl/Tk port I have discovered a bug.
  When a font has a lot of subfonts and then adds even
  more for it you can get 
  segfaults due to accessing re-used memory.


  In Tk_MeasureChars:

       lastSubFontPtr = &fontPtr->subFontArray[0];
  //  i.e. take address of 0'th element of subfont array


      for (p = source; p < end; ) {
      next = p + Tcl_UtfToUniChar(p, &ch);
      thisSubFontPtr = FindSubFontForChar(fontPtr, ch);
      if (thisSubFontPtr != lastSubFontPtr) {
  familyPtr = lastSubFontPtr->familyPtr;       //  use the
  pointer
  Tcl_UtfToExternalDString(familyPtr->encoding, source,
  p - source, &runString);
    
  But in CanUseFallback that array can be reallocated :

      if (fontPtr->numSubFonts >= SUBFONT_SPACE) {
  SubFont *newPtr;

  newPtr = (SubFont *) ckalloc(sizeof(SubFont) *
  (fontPtr->numSubFonts + 1));
  memcpy((char *) newPtr, fontPtr->subFontArray,
  fontPtr->numSubFonts * sizeof(SubFont));
  if (fontPtr->subFontArray != fontPtr->staticSubFonts) {
      ckfree((char *) fontPtr->subFontArray);
  }
  fontPtr->subFontArray = newPtr;
      }


tkt_uuid: 619440ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Invalid
title: Problem compiling tk 8.4
comment:
  Hi,

  I try to compile tk8.4.0 on my GNU/Linux system with
  gcc-3.2
  There was no problem with the configure but for the
  make i got this :

  # gmake
  gcc -pipe -rdynamic  tkAppInit.o \
  -L/tmp/tk8.4.0/unix -ltk8.4 \
  -framework Tcl  -lpthread -L/usr/X11R6/lib -lX11 -ldl
  -lieee -lm -Wl,-rpath,/usr/local/lib:/usr/X11R6/lib -o wish
  gcc: Tcl: No such file or directory
  gmake: *** [wish] Error 1


  I compiled tcl8.4.0 with --enable-framework




  It would be great if you could help me with this !

  Best regards,

  Pierre.


tkt_uuid: 619544ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Fixed
title: Can't create image
comment:
  Platform: ALPHA, Tru UNIX v5.1

  Cannot create photo image:

  seabbvsta0085> wish8.4
  % image create photo image1 -file tai-ku.gif
  not enough free memory for image buffer


  No matter what image i try to create, I always get the 
  same error. Bitmaps seems to work though.


tkt_uuid: 620449ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: None
title: NT modal backwards text entry (+ fix)
comment:
  # NT backwards entry bug (8.3, 8.4)
  # (1) must be NT or (windows?)
  # (2) must be modal window
  # (3) Use mouse button 1 to select and drag the entry 
  text,
  #     release to the left of the window (over desktop)
  # (4) type entry text, see it entered backwards

  proc showbug {{w .show}} {
      catch {destroy $w}
      toplevel $w
      message $w.m -text "Mouse button 1 Select and 
  drag the entry text to the left, let go
    outside of the window"
      pack $w.m -side top -fill x
      entry $w.e
      $w.e insert 0 "Select Me"
      pack $w.e -side top -fill x
      button $w.b -text Dismiss -command "destroy $w"
      pack $w.b -side top -fill x
      grab $w
      }

  The fix is in $tk_library/entry.tcl  - change use of after
  in tk::EntryAutoScan

  proc ::tk::EntryAutoScan {w} {
      variable ::tk::Priv
      set x $Priv(x)
      if {![winfo exists $w]} return
      if {$x >= [winfo width $w]} {
          $w xview scroll 2 units
          EntryMouseSelect $w $x
      } elseif {$x < 0} {
          $w xview scroll -2 units
          EntryMouseSelect $w $x
      }
      # Hume bug fix, if there is a grab, there are extra B1-
  Leave invocations
      # we need to limit re-invocations to avoid backwards 
  data entry!
      #    set Priv(afterId) [after 50 [list ::tk::EntryAutoScan 
  $w]]
      if { $Priv(afterId) == {}} {
          set Priv(afterId) [after 50 [list ::tk::EntryAutoScan 
  $w]]
          }
  }


tkt_uuid: 620458ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Fixed
title: TkWinWmCleanup exit crash, null datakey
comment:
  On NT 2000 Pro, my build of a custom shell based on 
  8.4.0 was reproducibly crashing on exit in 
  TkWinWmCleanup (file ..win/tkWinWm.c) during 
  detachment of the Tk DLL.  The problem was caused by 
  using the thread pointer "datakey" when it was null.  The 
  problem was fixed by added a null test:

  oid
  TkWinWmCleanup(hInstance)
      HINSTANCE hInstance;
  {
      ThreadSpecificData *tsdPtr;

      /*
       * If we're using stubs to access the Tcl library, and 
  they
       * haven't been initialized, we can't call 
  Tcl_GetThreadData.
       */

  #ifdef USE_TCL_STUBS
      if (tclStubsPtr == NULL) {
          return;
      }
  #endif

      if ( dataKey == NULL ) return;    /* ECH exit crash fix 
  */
   
      tsdPtr = (ThreadSpecificData *)
              Tcl_GetThreadData(&dataKey, sizeof
  (ThreadSpecificData));

      if (!tsdPtr->initialized) {
          return;
      }
      tsdPtr->initialized = 0;

      UnregisterClass
  (TK_WIN_TOPLEVEL_CLASS_NAME, hInstance);
  }


tkt_uuid: 620498ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 6
foundin: obsolete: 8.4.0
resolution: Fixed
title: TkWinXCleanup free uniEn. exit heap erro
comment:
  When working with a custom shell and Tk 8.4.0 on NT 
  2000, I found that during Tk DLL detachment, there were 
  heap access errors coming from file TkWinXCleanup, file 
  tkWinX.c at the Tcl_FreeEncoding(unicodeEncoding) 
  call.  I am using the default build for Tk as far as 
  threading.  These problems were fixed by changing the 
  logic to be re-entrant safe for the cleanup.  The thinking 
  is that there is more than 1 thread going through the 
  cleanup logic but this is only a hypothesis.  It could be I 
  just moved some bad pointer reference around and thats 
  the real fix!

  void
  TkWinXCleanup(hInstance)
      HINSTANCE hInstance;
  {
      /*
       * Clean up our own class.
       */

      if (childClassInitialized) {
          childClassInitialized = 0;
          UnregisterClass(TK_WIN_CHILD_CLASS_NAME, 
  hInstance);
      }

      if (unicodeEncoding != NULL) {
          Tcl_Encoding ue;
          ue = unicodeEncoding;
          unicodeEncoding = NULL;
              Tcl_FreeEncoding(ue);
      }

      /*
       * And let the window manager clean up its own class
  (es).
       */

      TkWinWmCleanup(hInstance);
  }


tkt_uuid: 620808ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4.1
resolution: Duplicate
title: wish crashes after "destroy .toplevel"
comment:
  Following script crashes wish (press 'Exit' button):
  ---
  wm withdraw .
  toplevel .t
  pack [frame .t.f]
  pack [button .t.f.b -text Exit -command {destroy .t}]
  bind .t <Destroy> exit
  ---

  Environment:
  Linux 2.4.18, glibc 2.2.5, XFree86 4.2.0.
  Tcl: ActiveTcl8.4.0.1

  Message:
  Segmentation fault


tkt_uuid: 621241ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Grid size becomes incorrect
comment:
  A grid keeps track of the number of rows and columns,
  but this count
  is not updated when you remove (either by destroying or
  forgetting) a child. However the count is recalculated
  when the 'grid size' function is called.  This gives
  some very strange effects, the following program gives
  a different result depeding on if the call to 'grid
  size' is done or not.

  label .l1 -text l1
  grid .l1
  grid forget .l1

  # The output differs depending on if the following line
  # is commented or not
  #grid size .

  label .l2 -text l2
  grid .l2
  puts "Result [grid size .]"
  destroy .


  I have attached a patch which solves the bug and also
  includes two new test-cases for it.


tkt_uuid: 621672ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Fixed
title: Tk's 'hacky port of FSpPathFromLocation'
comment:
  Per recent discussion on tcl-mac:

  Date: Thu, 10 Oct 2002 10:28:49 -0700
  Subject: Re: [MACTCL] Opening scripts with TkAqua

  > Why is the filename passed to ::tk::mac::OpenDocument in the classic
  > Macintosh "Volume Name:path:to:file.tcl" format instead of native OS X
  > "/path/to/file.tcl" format, even though [file separator] is set to 
  > "/"? That makes it hard to parse without hard-coding "magic characters",
  > which I don't like.

  You should definitely file a bug about this.  We should steal the TclAE 
  code & add it to the Tk version.


tkt_uuid: 621811ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Fixed
title: search -count var ignores elided chars
comment:
  when textwidget searches a sequence with elided chars
  inside, counting the found chars doesn't work properly.
  Try this:

  (bin) 1 % info patchlevel
  8.4.0
  (bin) 2 % pack [text .t]
  (bin) 3 % .t insert 1.0 {My name is Otto.}
  (bin) 4 % .t search -count cnt Otto 1.0
  1.11
  (bin) 5 % set cnt
  4
  (bin) 6 % # as expected
  (bin) 7 % .t tag configure hidden -elide yes
  (bin) 8 % .t tag add hidden 1.12 1.14
  (bin) 9 % # .t displays: My name is Oo.
  (bin) 10 % .t search -count cnt Oo 1.0
  1.11
  (bin) 11 % set cnt
  2
  (bin) 12 % # cnt contains 2 (the visible letters Oo)
  (bin) 13 % # but should contain 4 (including the hidden tt)

  workaround: find out, which chars are elided by
  programming. Quite heavy. 


tkt_uuid: 621901ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: TIP Implementation
resolution: Accepted
title: tip113 and objectify text widget
comment:
  Attached is a patch to objectify the text widget.  It 
  should be complete, except there seems to be 
  some sort of init bug which causes a crash on 
  startup, at least on Windows, which I don't 
  understand.  This may be caused by some errors in 
  the new option table, but I'm not sure...

  I'd appreciate it if someone who understands this 
  better could take a look at this some more...


tkt_uuid: 622582ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 69. Events
priority: 9 Immediate
foundin: None
resolution: Accepted
title: TkAqua IME: Partial fix for bug #616988
comment:
  Fixes deadkey problem for Mac encoded keyboards (tested
  on German).  Not tested yet on DBCS keyboard input and
  Unicode keyboards like Hebrew (code included, but based
  only on documentation). Also input methods don't work yet.

  Next step seems to be to adapt the Mac->Tk event handling
  to support TSM.


tkt_uuid: 623114ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Add support for scrollbars when needed
comment:
  Request consideration for adding support for scrollbars when needed, for the
  appropirate widgets (text, canvas, listbox, etc)  to the core.

  This feature would save a lot of time when coding, and would add a nice
  feature and appearance to Tk.


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: 624116ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 8
foundin: obsolete: 8.4.0
resolution: Fixed
title: Scrollbars crash on windows XP
comment:
  The scrollbars crash on XP if they are fully expanded 
  and you try to drag them with the mouse.

  To reproduce, start the wish console, try to drag the 
  vertical scrollbar, and then move the graphics window 
  over the top of the scrollbar to detect the fact that it's not 
  repainting itself and has indeed crashed.

  Not sure if it occurs on any other windows variants.


tkt_uuid: 624732ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.3.4
resolution: Fixed
title: text -wrap none crash with binary data
comment:
  Adding a whole load of nulls to a text widget with -wrap 
  none causes it to crash on Digital Unix 4.0E.

  For example:

  pack [text .t -wrap none] 
  .t insert end [string repeat "\0" 500] 

  gdb gives some info, but unfortunately this was built 
  without debugging.

  Program received signal SIGSEGV, Segmentation fault.
  0x300008a1c00 in Tcl_UtfToUniChar ()
     from 
  /home5/pubseq/share/distrib/unix-2002.0/lib/alpha-binaries/libtcl8.4.so
  (gdb) where
  #0  0x300008a1c00 in Tcl_UtfToUniChar ()
     from 
  /home5/pubseq/share/distrib/unix-2002.0/lib/alpha-binaries/libtcl8.4.so
  #1  0x3000005cc08 in TkpFontPkgInit ()
     from 
  /home5/pubseq/share/distrib/unix-2002.0/lib/alpha-binaries/libtk8.4.so
  #2  0x30000859178 in Tcl_UtfToExternalDString ()
     from 
  /home5/pubseq/share/distrib/unix-2002.0/lib/alpha-binaries/libtcl8.4.so
  warning: Hit heuristic-fence-post without finding
  warning: enclosing function for address 0x1400834c8


tkt_uuid: 624974ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: image create photo -format
comment:
  This crashes or causes incorrect behavior:

  image create photo -format
  image1 cget -format

  I "fixed" it like so:

  --- tkImgPhoto.c        9 Oct 2002 09:32:24 -0000     
   1.35
  +++ tkImgPhoto.c        17 Oct 2002 23:56:26 -0000
  @@ -1848,9 +1848,12 @@
                  }
              } else if ((args[j][1] == 'f') &&
                      !strncmp(args[j],"-format",
  (size_t) length)) {
  -               if (i < objc) {
  +               if (i+1 < objc) {
                      format = objv[++i];
                      j--;
  +               } else {
  +                   j--;
  +                   format = NULL;
                  }
              }
          }

  But I don't know if that's the correct place or way to
  fix it.


tkt_uuid: 625283ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: None
resolution: Fixed
title: Cygwin fixes for Tk 8.3.5
comment:
  This is a back port of the following changes, all are 
  required for a Cygwin build:

  2002-09-18  Mumit Khan  <khan@nanotech.wisc.edu>

  Added basic Cygwin support.

  * win/tkWinPort.h (tchar.h): Do not include on 
  Cygwin.
  (_T): Define for Cygwin.
  * win/winMain.c (main): Conditionally define.

  2001-06-26  Mo DeJong  <mdejong@redhat.com>

  * unix/configure: Regen.
  * unix/configure.in: Set CFLAGS to "" if the 
  user
  did not set CFLAGS in the env. This keeps 
  AC_PROG_CC
  from adding "-g -O2" to the CFLAGS by 
  default.
  * win/configure: Regen.
  * win/configure.in: Ditto.

  2001-07-24  Mo DeJong  <mdejong@redhat.com>

  * win/configure: Regen.
  * win/tcl.m4 (SC_CONFIG_CFLAGS): Check 
  for bug in
  Cygwin version of windres and work around 
  that
  case by passing a POSIX path instead of a 
  Windows
  native path. One can't always pass a POSIX 
  path
  because the mingw native toolchain accepts 
  only
  Windows native paths.

  And win/tkWinPort.h was altered to make sure 
  OPEN_MAX is only defined if not already defined by 
  system (ie Cygwin)


tkt_uuid: 625472ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: None
resolution: Fixed
title: Cygwin fixes for Tk 8.4.1 cvs
comment:
  The following back port and minor change are required to 
  compile Tk 8.4.1 cvs on Cygwin:
  2001-07-24  Mo DeJong  <mdejong@redhat.com>
   * win/configure: Regen.
   * win/tcl.m4 (SC_CONFIG_CFLAGS): Check for bug in
   Cygwin version of windres and work around that
   case by passing a POSIX path instead of a Windows
   native path. One can't always pass a POSIX path
   because the mingw native toolchain accepts only
   Windows native paths.

  And win/tkWinPort.h was altered to make sure 
  OPEN_MAX is only defined if not already defined by 
  system (ie Cygwin)


tkt_uuid: 627416ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: buildTkConfig.tcl missing in Dist
comment:
  the file buildTkConfig.tcl that is used on MacOSX is
  missed in the distributed source package of tk 8.4.1

  After downloading from the CVS tk and wish builds well.


tkt_uuid: 627453ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 76. Widget Tour
priority: 6
foundin: None
resolution: Accepted
title: Unicode demo
comment:
  It is proposed to add the script below, or a variation of it 
  to the Tk demo to illustrate the Unicode abilities. 
  (Richard Suchenwirth)

   pack [text .t -font {Helvetica 16}]
   .t insert end "
   Arabic \uFE94\uFEF4\uFE91
  \uFEAE\uFECC\uFEDF\uFE8D\uFE94\uFEE4\uFEE0
  \uFEDC\uFEDF\uFE8D
   Trad. Chinese      \u4E2D\u570B\u7684\u6F22\u5B57
   Simplified Chinese \u6C49\u8BED
   Greek   \u0395\u03BB\u03BB\u03B7\u03BD\u03B9
  \u03BA\u03AC\
   \u03B3\u03BB\u03CE\u03C3\u03C3\u03B1
   Hebrew  \u05DD\u05D9\u05DC\u05E9\u05D5\u05E8
  \u05D9\
   \u05DC\u05D9\u05D0\u05E8\u05E9\u05D9
   Japanese \u65E5\u672C\u8A9E\u306E\u3072\u3089
  \u304C\u306A,\
   \u6F22\u5B57\u3068\u30AB\u30BF\u30AB\u30CA
   Korean          \uB300\uD55C\uBBFC\uAD6D\uC758 
  \u3CA2\u3498
   Russian         \u0420\u0443\u0441\u0441\u043A\u0438
  \u0439\
   \u044F\u0437\u044B\u043A"


tkt_uuid: 627462ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 78. Other Demos
priority: 5 Medium
foundin: None
resolution: Accepted
title: New widget demo - keysym display
comment:
  A regularly posted script is tk code displaying the
  names of keys as used by bind.  A 'best practices'
  version of such code , included in the widget tour, m
  ight make a useful utility as well.


tkt_uuid: 627466ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 76. Widget Tour
priority: 3 Low
foundin: None
resolution: Accepted
title: Add animation to the widget tour
comment:
  Show how to make an animated picture (probably a set of
  different objects to chose from). The basic technique
  is to use the "after" command


tkt_uuid: 627471ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 76. Widget Tour
priority: 8
foundin: None
resolution: None
title: Add a simple game to the Widget tour
comment:
  It might be a nice idea to add a game to the demos,
  such as appear on the Wiki. This will show:
  - How to interact with the keyboard/mouse
  - How to set up a game board (a more complicated
  picture)
  - How to do the logic for a game


tkt_uuid: 627553ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 9 Immediate
foundin: final: 8.3.5
resolution: Fixed
title: unix/configure is broken
comment:
  The unix/configure file in the Tk 8.3.5 source distro
  is completely broken.  Several macros from
  unix/configure.in have not been expanded, including:

  SC_ENABLE_GCC
  SC_ENABLE_THREADS
  SC_PATH_TCLCONFIG
  SC_LOAD_TCLCONFIG
  SC_CONFIG_CFLAGS
  SC_ENABLE_SYMBOLS
  SC_PATH_X
  SC_BUGGY_STRTOD
  SC_ENABLE_SHARED

  It appears that "autoconf" was run without having
  the necessary tcl.m4 file around.

  A corrected distribution should be released.

  The release process should be examined to determine
  how this error could escape notice.


tkt_uuid: 627556ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 4
foundin: final: 8.3.5
resolution: Invalid
title: tcl.m4 is not up to date
comment:
  The released files tcl8.3.5/unix/tcl.m4 and
  tk8.3.5/unix/tcl.m4 are not the same.  I 
  think they are supposed to be the same.

  The real fix for this bug is not to update
  Tk's copy of tcl.m4, but to complete the
  factoring out of tcl.m4 and friends into
  a separate CVS module that both Tcl and
  Tk can include so that they automatically
  have the same version without all the
  endless copying from one CVS repository
  to another.


tkt_uuid: 628273ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Duplicate
title: AIX image buffer allocation failure
comment:
  On an AIX 4.3 system the command "image create 
  photo" fails in file tkImgPhoto.c, function, 
  ImgPhotoSetSize, line 2656, when attemptckalloc() is 
  called.  AIX and some other systems (Tru64) return 
  NULL from an alloc call for 0 size.  This problem affects 
  only Tk 8.4.  The fix that I have successfully tested is

  if ((width != masterPtr->width) || (height != masterPtr-
  >height) || (masterPtr->pix24 == NULL) {
      unsigned size;
      size = height * pitch;
      if (size > 0) {
         newPix24 = (unsigned char *) attemptckalloc(size);
        if (newPix24 == NULL) { return TCL_ERROR; }
        }
     else { newPix24 = NULL; }
     }


tkt_uuid: 628863ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.4.1
resolution: Rejected
title: tab incorrect with lmargin1
comment:
  in the latest 8.4.1 with the following code:

  text .text
  .text tag configure text -lmargin1 30 -font {Courier 10}
  .text insert 1.0 "a\n\tb\tc"
  .text tag add text 0.0 end
  pack .text

  the distance between a,b is not the same as
  the distance between b,c. the first tabstop seems
  to be caculated wrong, this seems to be caused
  by the -lmargin1 parameter, 

  the following diff in tkTextDisp.c seems to fix the
  problem:
  320c320
  <                           TkTextDispChunk *chunkPtr));
  ---
  >                           TkTextDispChunk *chunkPtr, int 
  tabOrigin));
  379c379
  <                           int maxX));
  ---
  >                           int maxX, int tabOrigin));
  800a801
  >     int tabOrigin;
  880a882
  >     tabOrigin = 0;
  958a961
  >           tabOrigin = x;
  1060c1063
  <               AdjustForTab(textPtr, tabArrayPtr, tabIndex, 
  tabChunkPtr);
  ---
  >               AdjustForTab(textPtr, tabArrayPtr, tabIndex, 
  tabChunkPtr, tabOrigin);
  1065c1068
  <           tabSize = SizeOfTab(textPtr, tabArrayPtr, 
  tabIndex, x, maxX);
  ---
  >           tabSize = SizeOfTab(textPtr, tabArrayPtr, 
  tabIndex, x, maxX, tabOrigin);
  1131c1134
  <       AdjustForTab(textPtr, tabArrayPtr, tabIndex, 
  tabChunkPtr);
  ---
  >       AdjustForTab(textPtr, tabArrayPtr, tabIndex, 
  tabChunkPtr, tabOrigin);
  4823c4826
  < AdjustForTab(textPtr, tabArrayPtr, index, chunkPtr)
  ---
  > AdjustForTab(textPtr, tabArrayPtr, index, chunkPtr, 
  tabOrigin)
  4834a4838
  >     int tabOrigin;
  4864c4868
  <       desired = NextTabStop(textPtr->tkfont, x, 0);
  ---
  >       desired = NextTabStop(textPtr->tkfont, x, 
  tabOrigin);
  5005c5009
  < SizeOfTab(textPtr, tabArrayPtr, index, x, maxX)
  ---
  > SizeOfTab(textPtr, tabArrayPtr, index, x, maxX, 
  tabOrigin)
  5016a5021
  >     int tabOrigin;
  5022c5027
  <       tabX = NextTabStop(textPtr->tkfont, x, 0);
  ---
  >       tabX = NextTabStop(textPtr->tkfont, x, tabOrigin);


tkt_uuid: 629827ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: None
title: Moving toplevel windows fails
comment:
  Moving or resizing toplevel windows under Windows OS
  sometimes fails. This problem occured within an
  application running cyclic http calls. The attached
  code reduces the problem to a few lines of code. To
  reproduce the problem simply run the attached code
  inside a wish, drag the window to another position and
  wait until the mouse looses the window (still holding
  the left mousebutton).


tkt_uuid: 630171ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: long, fat lines fail on Windows
comment:
  # Source this into wish. Test with

  #

  #   drawlines [makepts $count] $width

  #   

  # where $count is number of points, $width is width of
  lines

  # in pixels.

  #

  # Works well on unix.  Time required depends linearly
  on the

  # number of points, with thick lines (width>1) taking only

  # marginally longer than thin lines.

  #

  # On Windows, thin lines (width=1) work well, with time

  # required depending linearly on the number of points.

  # Thick lines are rendered slowly, with time required

  # increasing much worse than linear once the number of

  # points is more than say 100.  On my Win98 box, with

  # Tcl/Tk 8.4.1, 'drawlines [makepts 1638] 2' raises

  # an illegal operation fault.  More points than this

  # results in nothing being drawn.  On Win2k, system

  # response becomes very sluggish as the number of points

  # moves into the thousands.


tkt_uuid: 630533ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 8
foundin: obsolete: 8.4.1
resolution: Fixed
title: TkpCloseDisplay panic
comment:
  On Linux/Alpha,  with Tcl/Tk 8.4.1:

  #FILE panic.tcl
  proc Die { win } {
      if {![string equal . $win]} { return }
      exit
  }
  bind . <Destroy> {Die %W}
  #END FILE panic.tcl

  $ wish8.4 panic.tcl
  <Use the [x] of the wm to close the . window>
  input contexts not freed before XCloseIM
  Abort

  Now for the really weird part, compare with:

  #FILE nopanic.tcl
  proc Die { win } {
      if {. ne $win} { return }
      exit
  }
  bind . <Destroy> {Die %W}
  #END FILE nopanic.tcl

  $ wish8.4 panic.tcl
  <Same [x] wm close as before works fine>


tkt_uuid: 631595ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Invalid
title: tkDarken has disappeared
comment:
  I am running a few scripts with various versions of Tcl/Tk 
  on Windows 2000, and noticed the following problem 
  with version 8.4.1.
  The function tkDarken is no longer available.
  (works fine in 8.3.5 and previous versions).
  I am using the ActiveState builds for Windows.


tkt_uuid: 632514ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 7 High
foundin: obsolete: 8.4.1
resolution: Fixed
title: disabled listbox error
comment:
  Summary:
  Listbox new disabled state seems not tested inside lisbox.tcl.

  Test code:
    set ::listvar {a b c d e f g h i j}
    pack [listbox .lb -state disabled -listvar ::listvar -selectmode 
  extended]

  Result:
  Browsing the listbox give an error:
  expected boolean value but got ""
      while executing
  "if {[$w selection includes anchor]} {
      $w selection clear $i $el
      $w selection set anchor $el
        } else {
      $w selection clear $i $el
      $w selecti..."
      ("extended" arm line 7)
      invoked from within
  "switch [$w cget -selectmode] {
    browse {
        $w selection clear 0 end
        $w selection set $el
        set Priv(listboxPrev) $el
        event generate $w..."
      (procedure "tk::ListboxMotion" line 7)
      invoked from within
  "tk::ListboxMotion .lb [.lb index @39,79]

  Correction:
  Don't know.
  Should all events disabled when the listbox is disabled?

  ulis


tkt_uuid: 632816ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Fixed
title: cannot remove transient
comment:
  The following should make the toplevel .t
  non-transient, but it retains some partially-transient
  behaviour ( see http://wiki.tcl.tk/3542 )

  toplevel .t
  wm withdraw .t
  update idletasks
  wm transient .t ""
  wm deiconify .t

  Toplevel .t remains 'in front' or 'on top' of the main
  window.. I see the same behaviour in 8.3.4 and 8.4.0 on
  Linux, but not on Windows.


tkt_uuid: 633300ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 39. Image Basics
priority: 6
foundin: None
resolution: None
title: Garbage collection for image
comment:
  There should be a possibility to have images
  automatically deleted when they are no longer used.

  Currently, "image delete" causes the image data to be
  removed immediately, resulting in an empty rectangle if
  the image is used. At the same time, the image will
  stay in memory even if no widget uses it anymore.

  I'd like to request a command "image autocollect <name>
  on/off", which causes the image command to be removed
  when the last instance of the image goes away.


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: 634864ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 9 Immediate
foundin: obsolete: 8.5a0
resolution: Fixed
title: invalid images in [images names]
comment:
  This started out as an RFE 633300
  /tracker/?func=detail&aid=633300&group_id=12997&atid=362997
  but I think the problem may be somewhat different. I'll
  rephrase the problem and have attached a Tcl script
  that shows it.

  The problem is that if you [image delete] an image 
  that is being used by a Tk widget, the reference to the
  widget
  stays in [image names] even though a config in the image
  results in a "invalid command name" error.

  The bug is:
  1) deleting an image when a widget is using it
  results in an incomplete deletion, and/or
  2) [images names] is returning a list with images
  that results in an error when queried by configure.

  I believe this is platform and version independent.
  Tested under 8.3.3 under Windows and 8.3.5 under Linux.


tkt_uuid: 635025ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 51. [place]
priority: 5 Medium
foundin: None
resolution: Fixed
title: place info doesn't handle spaces with -i
comment:
  [place info] does not return a proper list when the
  master contains a space:

  frame {.place master}
  button .b
  place .b -in {.place master}
  array set place [place info .b]
  -> list must have an even number of elements

  [place info .b] returns '-x 0 -relx 0 -y 0 -rely 0
  -width {} -relwidth {} -height {} -relheight {} -anchor
  nw -in .place master'

  when it should return '-x 0 -relx 0 -y 0 -rely 0 -width
  {} -relwidth {} -height {} -relheight {} -anchor nw -in
  {.place master}'


tkt_uuid: 636358ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 6
foundin: obsolete: 8.4.2
resolution: Out of Date
title: File selector unstable
comment:
  The file selector (when called from my client app) often leads to a 
  complete crash (using Tcl/Tk Aqua Runtime Jaguar), when 
  browsing a directory. Usually happens, when some directory is 
  clicked. (Might be coincidence: crash occurred quite often when 
  working on a network volume. Very often happens when scrolling 
  through a folder with mouse wheel.) 

  Error occurrs with RSTTool 3.32 (www.wagsoft.com)


tkt_uuid: 636562ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: Rejected
title: OSX: No Drag&Drop in Wish Shell
comment:
  When no source file is loaded, the Wish shell accepts drag&drop 
  of tcl files. However, they don't get executed (which would be the 
  obvious behavior).

  Similarly, starting the Wish shell with an tcl file as argument 
  should immediately execute the program. Using a runtime binary, 
  the user  shouldn't be bothered with yet another file selector to 
  load a tcl source file. Instead, double-clicking on the tcl 
  application should start it right away (as in the Windows port). The 
  installer should create the right file association.


tkt_uuid: 637653ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: None
title: Deleting a popup menu crashes wish
comment:
  Transferred from
  https://sourceforge.net/tracker/?func=detail&atid=110894&aid=637648&group_id=10894
  -------------------------------------
  The following code causes a serious crash of 
  wish84.exe on Windows XP,  if you click the right 
  mouse button on the canvas.
  -------------------------------------
  pack [canvas .c]
  bind .c <ButtonPress-3> {
      set w .popupmenu
      catch {destroy $w}
      menu $w -tearoff 0
      $w add command -label TEST
      $w post %X %Y
  }
  bind .c <ButtonRelease-3> {
      catch {destroy .popupmenu}
  }
  ------------------------------------
  This script is okay on Unix.


tkt_uuid: 637828ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 8
foundin: None
resolution: Fixed
title: [<entry> selection present] returns ""
comment:
  Observed behaviour
  ==================

  In the case of *disabled* entry widgets, the widget command

          <entry> selection present
          
  returns an empty string instead of the documented
  return values 0 or 1.

  This behaviour makes code like:

          if { [.entry selection present] } {

  return an error, complaining about a non boolean operand.



  Desired behaviour
  =================

  Assuming that disabled entry widgets can't hold a
  selection, the return value from [<entry selection
  present] should be zero.



  Additional remark
  ==================

  Please note that the observed behaviour may only be an
  *example* of more general mishap of the same nature in
  the entire family of [<entry> selection <option>]
  subcommands.



  Reproducible script
  ===================

  package require Tk
  pack [entry .e -state disabled]

  set resultsAccordingToManpage {0 1}
  set result [.e selection present]
  if { [lsearch $resultsAccordingToManpage $result] < 0 } {
      puts "In this case, the behaviour of the `selection
  present' subcommand\
              for the entry \"widget command\" is not in
  accordance\
              with the man page."
  }

  -- end of reproducible script --


  Erik Leunissen.

  -- end of bug report --


tkt_uuid: 638966ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 45. Aqua Fonts
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Font rendering on MacOSX with ATSU
comment:
  Installation
  ============

  tkMacOSXUnicodeFont.c is a new file.  This is a drop-in
  replacement for tkMacOSXFont.c, so you just add
  tkMacOSXUnicodeFont.c in Project Builder and remove or
  disable tkMacOSXFont.c.

  Features
  ========

  Drawing and measuring text with ATSU and Quarz.

  Encoding issues are eliminated because ATSU uses Unicode.

  Text drawing is *much* nicer because of Quarz.

  Font fallback is done by ATSU. 

  Anti-aliasing can be configure to three different settings:
  System (-1), off (0), on (1).

  Open questions and to-do
  ========================

  Tk_MeasureChars(): The flags parameter has not yet been
  tested, especially the implementation for TK_WHOLE_WORDS
  may well be wrong.

  The generic Tk mechanisms assumes that the sum of the width
  of two strings is equal to the width of the combined
  string.
  ATSU does not comply with that assumption.  There are
  work-arounds in the code, but it's still not perfect.  A
  real solution should come from the generic Tk side.

  Quarz drawing in tkMacOSXUnicodeFont.c is not coordinated
  with the Quarz functionality in other places.

  The module could export a regular TkpFontInitInterpreter()
  function to add additional functionality to an interpreter.
  This would require a slight change in tkMacOSXInit.c.

  The calculation of font size (pixel vs. points) depends on
  TkFontGetPoints() which depends on the calculations for the
  display size in tkMacOSXXStubs.c which in turn seems rather
  dubious to me.  Is there a rationale for the formula used
  there?

  Test
  ====

  This module has been tested with a simple multi-line edit
  control with the default font and with Helvetica.  It also
  has been tested with "demos/widgets".


tkt_uuid: 640026ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: Photo documentation error
comment:
  In the Tk 8.4 documentation for "photo" (the 
  version at 
  http://tcl.activestate.com/man/tcl8.4/TkCmd/pho
  to.htm at least) at least, the specification for the 
  "put" subcommand is totally false.  It seems to 
  be referring to some other s(sub)command, 
  since it refers to options that aren't even 
  available in the actual "put" subcommand.


tkt_uuid: 640333ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Fixed
title: Canvas items are offset on Mac
comment:
  Canvas lines and ovals (and probably other objects) are offset on MacOS Classic and MacOS X aqua relative to unix and to MacOS X built for an x server (i.e. built as regular unix).

  I have attached a source file that demonstrates the problem (I doubt it matters, but I personally ran it by copying it and pasting it to the wish console).

  This code shows the gyrations I use on MacOS to work around the bug (hence it may serve as a template for a fix). The line fix is probably not complete: I think the ends aree too long with width > 1 (fixing that was much more work than I felt it was worth).

  -- Russell


tkt_uuid: 640337ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 4
foundin: obsolete: 8.4.1
resolution: Out of Date
title: Grid behaves oddly on aqua Tk 8.4.1
comment:
  I coded a command/entry widget that consisted of an existing scrolling log widget plus a command entry field underneath. It has a problem on MacOS X 10.2.1 with aqua Tk 8.4.1 (but apparently not under unix or Windows):

  When I bring up the window, the scrollbar shimmies and the CPU usage is high. Both of these can be stopped by resizing the toplevel window, and it does not happen if I specify an initial size for the toplevel window.

  I reduced my code to quite a bit and have attached it as gridbug.tcl. I run it by pasting it into the Wish Shell console.

  Several folks have reported that a Python/Tkinter version of this minimal code works fine on various flavors of unix and Windows, whereas I see the problem on MacOS X. Hence I suspect it is a Mac-specific bug, and possibly an aqua-Tk-specific bug.


tkt_uuid: 640340ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Out of Date
title: font families broken in aqua Tk 8.4.1
comment:
  the command:
    font families
  crashes on MacOS X. This is with the aqua version of Tk 8.4.1. Errors include a lot of lines similar to:

  Nov  7 15:00:01 rowen /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Support/ATSServer: FOExceptionMainHandler caught a fatal exception at 0x0000b65c 

  Nov  7 15:00:01 rowen /Applications/Utilities/Wish Shell.app/Contents/MacOS/Wish Shell: kCGErrorFailure : GetGlyphAddresses failed: status = 8

  Nov  7 15:00:02 rowen /Applications/Utilities/Wish Shell.app/Contents/MacOS/Wish Shell: kCGErrorFailure : GetGlyphAddresses failed: status = 5

  and always end with the following:

  *** malloc_zone_malloc[29768]: argument too large: -12910904
  Nov  7 15:00:02 rowen crashdump: Crash report written to: /Users/rowen/Library/Logs/CrashReporter/Wish Shell.crash.log

  The crash is a problem but the GetGlpyshAddresses failed error is also a problem. It is the latter that actually caused me to discover the former.

  I normally program in Python and use it's Tk interface called Tkinter. A Python font selection widget I'd written was giving "GetGlyphAddress failed" errors, though otherwise it worked fine (no crashes). It turns out that the list of fonts returned by Tk includes some that have very weird characters in their names (such as what appears to be Chinese). Python got the list from Tk just fine (with no errors) but when I used this list to create an option menu, that's when Tk started complaining about GetGlyphAddress failed errors. In Python my current workaround is to filter out any font names with non-ascii characters. The widget then runs without errors.


tkt_uuid: 641216ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 7 High
foundin: None
resolution: Duplicate
title: Misleading messages on photo name "."
comment:
  A photo named "." can not be created, but still leads to 
  partial "brain-death" (Tk commands are refused):

  X:\tcl>tclsh
  % package require Tk
  8.4
  % image create photo .
  this isn't a Tk applicationNULL main window
  % image names
  can't invoke "image" command:  application 
  has been destroyed
  % pwd
  X:/tcl
  %

  A destroyed app that speaks? BTW, the NULL error 
  comes only if a tclsh was upgraded with [package 
  require Tk]. In a genuine wish it just exits, just like   
       proc . {} {} 
  - but also that is not what I call expectable behavior...

  [Richard Suchenwirth]


tkt_uuid: 641778ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: SEGV on "see"
comment:
  I am not a tcl programmer, I use Python/Tkinter, so here 
  is the bug I originally posted on the Python bugs list:

  [ 641215 ] Fascinating Text.see() SEGV

  OS: GNU/Linux 2.4.16, Debian 3.0
  Python:
  2.1.3 (#1, Apr 20 2002, 10:14:34)
  [GCC 2.95.4 20011002 (Debian prerelease)] on linux2
  After my large Python/Tkinter application did a SEGV, I 
  chopped out code till I was left with this little beauty:
  #!/usr/bin/python
  # An interesting bug in the Tk Text widget
  #
  # To find where the bug is, go:
  #  gdb python
  #  (gdb) run textsee.py
  # The output I get is:
  #  Program received signal SIGSEGV, Segmentation fault.
  #  [Switching to Thread 1024 (LWP 13789)]
  #  0x403162ce in TkTextSeeCmd () from 
  /usr/lib/libtk8.3.so.1
  from Tkinter import *
  root = Tk()
  # If this font is any bigger, it's OK
  # If this bd is any smaller, it's OK
  t = Text(root, font=("Helvetica", 8, "normal"), bd=16)
  # Packing actually makes no difference
  t.pack()
  # If this string is any shorter, it's OK
  t.insert(END, "Hello")
  # This see() method SEGVs
  t.see(END)
  # We never get here
  root.mainloop()
  # EOF
  It does the same under python1.5.2 (#0, Jan 12 2002, 
  11:51:45)  [GCC 2.95.4 20011006 (Debian prerelease)] 
  on linux2.
  I have not tried it under windows
  I'm not a tcl programmer, so have not tested using tcl.
  Pythonically yours.



  Date: 2002-11-20 14:10
  Sender: grahamh
  Actually, packing does make all the difference, if you call
  update() or update_idletasks on the text widget or root 
  (or any widget, even one that is not 
  packed|placed|gridded). So, the bug seems to be: calling 
  see() on a Text widget (I have not tested others) that is 
  not visible yet does a SEGV.



  Date: 2002-11-20 22:51
  Sender: nnorwitz
  Logged In: YES
  user_id=33168
  I'm closing this bug, since it is definitely Tk.  Here's the
  tcl code which crashes:
  $ wish
  % text .t -font { Helvetica 8 normal } -bd 16 .t
  % .t insert end Hello
  % .t see end
  Segmentation fault (core dumped)

  I'm running Tcl/Tk 8.3.3 on Redhat Linux 7.2.  Please file 
  a bug report with Tcl/Tk.  I think they can be found at:
  http://sf.net/projects/tcltk



  So there it is, but note that it only crashes at certain font 
  and border sizes (wierd!).

  Sorry I cannot provide a patch, it's over to you guys :-)


tkt_uuid: 642756ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Invalid
title: Segmentation fault with Img library
comment:
  Bug in tk8.4 (both 8.4.1 and 8.4.0) that affects
  any Tcl/Tk application using the Img library: when
  creating an image photo after the package require
  Img, the wish gives a segmentation fault and exits.

  Here is a transcript of a terminal session under
  Linux (Debian):

  08:49:08 gps$ wish8.4
  % image create photo -file h.gif
  image1
  % package require Img 
  1.2.4
  % image create photo -file h.gif
  Segmentation fault
  08:49:36 gps$ 

  Best regards,
  Miguel Filgueiras
  mig _AT_ ncc.up.pt


tkt_uuid: 643615ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: cascaded menu disappears
comment:
  There is a problem with heavily cascaded menus.
  When you open several consecutive cascades, you will
  eventually reach the border of your screen. At that
  moment, the already opened and new parts of the menu
  will start to overlap.
  When trying to open a new cascade, your pointer may be
  in a region that will get overlapped by the newly
  opened cascade. If you release the mouse button in such
  a case (or open the cascade with a click), the whole
  menu structure will disappear, but no command will get
  invoked.
  This is obviously due to the structure of
  ::tk::MenuInvoke, which unposts all menus when the
  "else" branch is hit.

  ::tk::MenuInvoke now looks like this:
  proc ::tk::MenuInvoke {w buttonRelease} {
  ...
      if {[string equal [$w type active] "cascade"]} {
  ...
      } else {
  MenuUnpost $w
  uplevel #0 [list $w invoke active]
      }
  }

  I think it should rather be
  proc ::tk::MenuInvoke {w buttonRelease} {
  ...
      if {[string equal [$w type active] "cascade"]} {
  ...
      } elseif { ![string equal [$w type active] ""]}  {
  MenuUnpost $w
  uplevel #0 [list $w invoke active]
      }
  }

  to avoid the above mentioned problem.
  The difference is that I ignore the case in which $w
  type active returns the empty string. This doesn't seem
  to cause any adverse effects.

  Please note: I originally encountered this problem in
  Tcl 7.3/Tk 3.6 which I'm forced to work with.
  After examining the current source code - including an
  attempt to backport it - I am pretty sure that this
  problem persists.


tkt_uuid: 643800ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 4
foundin: obsolete: 8.4.1
resolution: Out of Date
title: buttonrelease-2 copy/paste on aqua Tk
comment:
  aqua Tk 8.4.1 on MacOS X 10.2: the buttonrelease-2 event seems to paste the selected text (at lest for entry and text widgets). I'd not be surprised to learn this is normal unix X behavior (though it seems oddly specialized; I could not find corresponding clicks to just copy or just paste data!), but it has some problems on the Mac, including:

  - The usual Mac behavior for button-2 is to pop up a contextual menu, if there is one. Thus the default binding for buttonrelease-2 will not only confuse users, but could easily corrupt the data the user has entered. (I found this out when I started putting contextual menus in my application; I also had to disable buttonrelease-2 to get sane behavior).

  - The copied data does not go onto the Mac clipboard, and thus cannot be moved to other normal Mac applications.

  My main suggestion would be to remove the binding for buttonrelease-2. If it will be kept, then please consider changing it to something less easy to stumble over (e.g. something that requires a modifier key) and putting the data on the normal clipboard.

  -- Russell


tkt_uuid: 643823ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Out of Date
title: insertion cursor not seen at right
comment:
  If the insertion cursor is displayed at the right side of an entry widget it is not shown at all. This is on aqua Tk 8.4.1 (MacOS X 10.2.1).

  To see this effect, make an entry widget with right justification:
  entry .test -justify right
  pack .test
  Then manually resize the window size so the grow box does not obscure any of the entry widget.

  No insertion cursor is shown when the widget has focus unless the insertion cursor is somewhere other than after the right-most character.

  -- Russell


tkt_uuid: 644356ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: Resurrected transients part 2
comment:
  (Reported under KDE; replicated under 4DWm; similar
  behavior probably happens on any Unix WM with mulitiple
  desktops/workspace.)

  wish8.4
  % toplevel .t ; wm withdraw .t ; wm transient .t .

  % # Now switch to a different workspace, then switch
  back again.
  % # .t reappears!

  If you set [wm transient .t .] before [wm withdraw .t]
  then this does not occur.


tkt_uuid: 644409ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
title: PEEK_XCLOSEIM on by default
comment:
  PEEK_XCLOSEIM  was introduced in 8.4.1 and the way
  I read configure, it is set by default in configure
  for Linux systems only. If it is set, it triggers a panic
  if the are input contexts that have not been freed when
  the display is closed.

  The comment in tkUnixEvent.c is:

   There is an input context that has not been freed when
  exiting.  This  caused core dumps on some systems
  (Solaris 2.3 1/6/95).  The most   likely cause of this
  is a bug in X that accesses memory that was   already
  deallocated inside XCloseIM().  One can work around
  this  issue by making sure a XDestroyIC() gets invoked
  for each  XCreateIC(). In Tk 8.4.1 you can undefine
  PEEK_XCLOSEIM in Tk's  Makefile to avoid the diagnostic
  core dump on all systems.

  So even on systems which unfreed contexts do not cause
  a coredump, presumably because the X lib is not buggy, 
  Tk gives you a coredump anyway! 

   It's a nice debugging aid to have the ability to
  detect unfreed contexts, but IMHO  it should not be set
  by default, and it should not be set by configure. It
  should be documented and placed, but not set, in tk.h
  or tkInt.h so it is not added by the voodoo of configure.


tkt_uuid: 644641ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 6
foundin: obsolete: 8.4.1
resolution: Works For Me
title: W XP: ButtonProc called on invalid HWND
comment:
  when destroying a toplevel a message appears:  
  ButtonProc called on an invalid HWND  
  and wish crashes with a segmentation fault.  
    
  Unfortunately I was not able to write a simple script to show the  
  problem but it is reproduceable on a complex application.  
    
  What basically happens:  
  - Main application with menu  
  - Toplevel created: toplevel .t  
  - Messagebox created as a child from .t: tk_messageBox -parent .t  
  - change to the main window (.) and select a menu entry which  
  destroys the toplevel .t:  
          destroy .t  
  The toplevel and the message box disapears and an error message  
  shows up:  
          ButtonProc called on an invalid HWND  
  Then wish crashes with a protection fault on a read operation.  
    
   If someone is interested to get the application to reproduce the error 
  I will e-mail the whole application and instructions or I can make tries. 
   
  I just wanted to document this. Clear it off if it is not sufficient. 
   
  M. Cristiano Bernini [cbernini at iontrading com] reported the same 
  problem. 


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: 646382ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
title: TIP#116 Sample Implementation
comment:
  Sample implementation of scheme to get rid of panic()
  from everywhere in normal use of the photo image system.
  See http://purl.org/tcl/tip/116 for details.


tkt_uuid: 647497ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 8
foundin: None
resolution: Fixed
title: user fontpath priorities ignored on X11
comment:
  (Report forwarded from Debian. The original bug report,
  with analysis and patch, can be seen at
  <http://bugs.debian.org/156118>.)

  This bug was originally reported against Debian's tk
  8.3.3 package, but it is still present in 8.4.1.

  Executive summary:  when scanning X11 fonts, Tk chooses
  the last best match, rather than the first best match
  (in the case where more than one font qualifies as a
  "best" match).  This completely subverts the user's
  chosen priorities, making the user's least preferred
  font into the top choice.  It is, of course, a simple
  case of "<=" being used where "<"  would be
  appropriate.  The simple patch (from Massimo Dal Zotto
  <dz@cs.unitn.it>) is attached.


tkt_uuid: 649209ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: tkinter based applications crash
comment:
  [ This was first submitted to the Debian Bug Tracking
  system, see http://bugs.debian.org/171353 for the
  original report]

  tkinter is the tk support module for python.

  The setup is a Debian GNU/Linux system (unstable) with
  glibc-2.3.1, tcl/tk-8.4.1 configured with
  --enable-threads and python configured with
  --enable-threads as well.

  After the change to build python with tk8.4.1 instead
  of tk8.3, many tkinter based applications crash. One of
  them is

  pydoc -g

  same behaviour with python versions 2.1, 2.2

  I don't include the stack trace here, it looks awfully
  in the SF bug tracking ... please see
  http://bugs.debian.org/171353

  One of the python developers gave the following analysis:

  The problem appears to be Tcl's use of thread-local
  data. TkGetDisplay is implemented as

  TkDisplay *
  TkGetDisplay(display)
       Display *display;          /* X's display pointer */
  {
      TkDisplay *dispPtr;
      ThreadSpecificData *tsdPtr = (ThreadSpecificData *) 
              Tcl_GetThreadData(&dataKey,
  sizeof(ThreadSpecificData));

      for (dispPtr = tsdPtr->displayList; dispPtr != NULL;
      dispPtr = dispPtr->nextPtr) {
  if (dispPtr->display == display) {
      break;
  }
      }
      return dispPtr;
  }

  If Tcl sees a call in a new thread "coming out of
  nowhere", then Tcl_GetThreadData will find that there
  are no thread-local data for this thread. It will
  allocate an amount of memory and zero-initialize it.
  Then, displayList for that thread will be NULL, and the
  function will be NULL.

  NULL is a documented return value for TkGetDisplay, but
  apparently, Tk_FreeGC does not expect to get NULL, and
  crashes.

  I'm not sure how this is supposed to work. To me, the
  notion of the TkDisplay being thread-local sounds
  inherently broken: In this case, it means that you
  can't free a GC in one thread that you have allocated
  in another. So I would conclude this to be a bug in Tk.


tkt_uuid: 650291ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 6
foundin: obsolete: 8.4.1
resolution: Out of Date
title: Report of tests failures
comment:
  Hi,

  I just compiled fine tk8.4.1 with gcc 3.2,
  but during the make test, some tests failed :

  $ gmake test
  TCL_LIBRARY=/tmp/tcl8.4.1/library; export TCL_LIBRARY; \
  TK_LIBRARY=/tmp/tk8.4.1/library; export TK_LIBRARY; \
  ./tktest /tmp/tk8.4.1/unix/../tests/all.tcl -geometry
  +0+0 \
   
  Tests running in interp:  /tmp/tk8.4.1/unix/tktest
  Tests located in:  /tmp/tk8.4.1/tests
  Tests running in:  /tmp/tk8.4.1/unix
  Temporary files stored in /tmp/tk8.4.1/unix
  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 Sun Dec 08 04:54:22 CET 2002
  bell.test
  Bell should ring now ...
  bgerror.test
  bind.test

  ==== bind-22.10 HandleEventGenerate FAILED
  ==== Contents of test case:

      setup
      bind .b.f <Key> {set x "%s %K"}
      set x {}
      event gen .b.f <Control-Key-1>
      set x

  ---- Result was:
  5 1
  ---- Result should have been (exact matching):
  4 1
  ==== bind-22.10 FAILED

  bitmap.test
  border.test
  button.test
  canvImg.test
  canvPs.test
  canvRect.test
  canvText.test
  canvWind.test
  canvas.test
  choosedir.test
  bad window path name ".__tk_choosedir.f2.ok"
      while executing
  "winfo ismapped $button"
      (procedure "SendButtonPress" line 11)
      invoked from within
  "SendButtonPress $parent ok mouse"
      (procedure "EnterDirsByKey" line 14)
      invoked from within
  "EnterDirsByKey . {/tmp/tk8.4.1/unix/non-existant
  /tmp/tk8.4.1/unix/choosedirTest
  /tmp/tk8.4.1/unix/choosedirTest}"
      ("after" script)


  and there it seems to timeout... I had to do a "Ctrl-C"...



  It would be great if you could help me with this !

  Best regards,

  Pierre.


tkt_uuid: 651396ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: tktest build fails with makefile.vc
comment:
  tktest will not currently compile with makefile.vc 
  on Windows.

  *** Compiler has 'Optimizations'
  *** Compiler has 'Pentium 0x0f fix'
  *** Linker has 'Win98 alignment problem'
  *** Doing threads
  *** Doing symbols
  *** Doing profile
  *** Doing memdbg
  *** Doing compdbg
  *** Intermediate directory will 
  be '.\Debug\tk_ThreadedDynamic'
  *** Output directory will be '.\Debug'
  *** Suffix for binaries will be 'td'
  *** Optional defines are '-DTCL_MEM_DEBUG -
  DTCL_COMPILE_DEBUG -DTCL_COMPILE_STATS -
  DTCL_THREADS=1'
  *** Dependency rules are not being used.

  ... a lot of files are compiled successfully ...

          cl -Z7 -Od -WX -nologo -c -W3 -YX -
  Fp.\Debug\tk_ThreadedDynamic\ -QI0f -
  MDd -I"..\win" -I"..\generic" -I"..\bitmaps" -
  I"..\xlib"  -I "..\..\tcl\win" -I
  "..\..\tcl\generic" -DTCL_MEM_DEBUG -
  DTCL_COMPILE_DEBUG -DTCL_COMPILE_STATS -
  DTC
  L_THREADS=1 -
  Fo.\Debug\tk_ThreadedDynamic\tkWinTest.obj ..\w
  in\tkWinTest.c
  tkWinTest.c

  NMAKE : fatal error U1073: don't know how to 
  make '\tclThreadTest.obj'
  Stop.


tkt_uuid: 652088ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Out of Date
title: paned window option problem
comment:
  There apears to be a problem in the panedwindow code.
  Although the documentation indicates that the height
  and width of a pane can be controled with the -height
  and -width options to the paneconfigure command, this
  doesn't appear to be the case. The following two
  command (for example) produce the same results (a pane
  that is 150 high).

  ${pwin} paneconfigure ${frame} -minsize 150
  ${pwin} paneconfigure ${frame} -minsize 150 -height 250

  A more telling example is the following which produces
  a pane that has 0 height.

  ${pwin} paneconfigure ${frame} -height 250

  I have also tried to use the sash place command to
  ajust the possition of the sash (and thus the size of
  the window) but this does not seem to work eather.


tkt_uuid: 653156ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: search start wrong when elided chars
comment:
  bug with text-widget search function.
  When there are elided chars,
  the start index of search is wrong.

  % info patchlevel
  8.4b1
  (bin) 2 % pack [text .text]
  (bin) 3 % .text insert 1.0 "1234 ab ab ab ab ab ab ab"
  (bin) 4 % .text tag add hidden 1.0 1.4
  (bin) 5 % .text search ab 1.5 end
  1.5
  (bin) 6 % .text tag configure hidden -elide yes
  (bin) 7 % .text search ab 1.5 end
  1.11
  (bin) 8 % 

  Before the letter sequence 1234 was hidden, 
  the start index was taken correctly.
  When the letter sequence 1234 is hidden, 
  the start index is obviously 1.5 + 4 chars  = 1.9,
  so the next found occurrence of ab was 11.


tkt_uuid: 653895ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Mac: scrollbar set:slider wrong
comment:
  On Tk-Aqua the scrollbar slider size and position is 
  not corectly configured by the scrollbar set command.
  Bug can be demonstrated by:

  grid [scrollbar .s] -row 0 -column 0 -sticky ns
  grid rowconfigure . 0 -weight 1
  .s set .1 .9

  the slider is positioned between ~.25 and ~.75

  try
  .s set .0001 .9999
  -there is no way using set to make a slider that is 
  longer than 0.5 the height of the scrollbar.

  now try 
  .s set .1 .99
  .s set .01 .9

  the slider jumps to the bottom then the top of the 
  scroll bar.
   In the sources it appears that the middle of the 
  scrollbar is being set to first_fraction/(first_fraction+1-
  last_fraction), when it appears to me that it would be 
  more appropriate to set the middle of the scrollbar to 
  (first_fraction+last_fraction)/2

  I'm not sure where the bug in the slider length comes 
  in.

  This may be a bug in the non-Aqua versions for the 
  Mac as well.

  -wayne@eatworms.swmed.edu


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: 655788ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: R-click "cut/copy/paste" menu as default
comment:
  The most basic and common feature of editable text is 
  being able to right-click the text and having a menu pop-
  up that gives (at a minimum) cut-copy-paste options.  

  Any Windows or Linux program has this, and Perl/TK 
  has this too, as a default.  Tcl/TK should absolutely 
  have this feature, since it is much more Windows/Linux -
  friendly in general. 

  It would be really nice to see these five options:

  cut
  copy
  paste
  -------
  undo
  select all


tkt_uuid: 657656ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 7 High
foundin: None
resolution: Remind
title: -initialfile doesn't hilight filenames
comment:
  tk_getOpenFile -multiple 1 -initialfile [glob *.jpg]

  Lists all of the files in the 'filename' entry,
  however, they are not selected.  It would be nice to
  have the visual confirmation that the files are indeed
  the ones you want, and also "not breaking the metaphor"
  or some such.


tkt_uuid: 657835ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Postponed
title: changes to makefile.vc & rules.vc
comment:
  I've made a couple of changes to these files while 
  building Tcl and Tk, hopefully they can be of use to 
  someone other than me :)
  Included in the zip file are both the diffs and full versions 
  of these files.
  Any feedback is welcome...

  makefile.vc v1.66
      -- made to conform with Tcl's makefile better
      -- added support for 'Global Optimisation'
         (ie. whole program optimisation) (VC++ 7.0)
      -- added variable 'libflags'
      -- added progress messages
      -- corrected some long filename quoting
      -- corrected some references to $(CPY)
      -- removed some '/=\' conversions (these are already
         corrected in rules.vc)
      -- modified 'release' to build 'winhelp' as well
      -- modified to use $(MKDIR) & $(RMDIR) which are
         now declared in rules.vc
      -- modified 'clean' to remove 'DOCTMP_DIR'
      -- renamed 'console-wish' to 'con-wish' to make
         instructions line up better
      -- moved 'install-doc' to installation section
      -- renamed helpfile main window text to
         'Tk Reference Manual'
      -- modified to change title to
         'Tcl\Tk Reference Manual' if merged with
         'Tcl Reference Manual'
      -- cleaned up screen output
      -- cleaned up style to match majority already used
      -- corrected some spelling errors

  rules.vc v1.4
      -- added support for 'Global Optimisation'
         (ie. whole program optimisation) (VC++ 7.0)
      -- added $(MKDIR) & $(RMDIR) macros
      -- modified logic for decoding options
      -- cleaned up screen output
      -- cleaned up style to match majority already used


tkt_uuid: 658197ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Out of Date
title: TkAqua: torn-off menus are not functional
comment:
  This is on MacOS X 10.2.x, with the latest Tk-cvs-head.

  Torn-off menus which should appear in a floating
  palette are first of all drawn completely in black
  (sometimes if you move the mouse over the items they
  are drawn correctly), and events don't seem to
  propagate correctly to the floating window.


tkt_uuid: 659129ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 72. Atoms
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: Tk_Uids clean up incorrectly w/ threads
comment:
  From Christian Werner (chw ch-werner de)

  While playing around with Tk 8.4.1 and multi-threading 
  on Win32
  I observed some strange behaviour w.r.t. Tk_Uids:

  1. Tk_ConfigureWidget() converts the name/class/default 
  values
  in the given Tk_ConfigSpec to UIDs.

  2. Tk_GetUid() installs a per-thread exit handler
  (FreeUidThreadExitProc()) which destroys the per-thread 
  UID
  table (and the UIDs, too) on thread termination, i.e.
  after the thread using Tk exited, some Tk_ConfigSpec 
  fields
  point to free'd memory.

  3. When Tk is re-animated later (Tk_Init()) in a new 
  thread,
  arbitrary Bad Things happen as consequence to 
  invalidated UIDs
  from point 2.

  Questions:

  - Is it really necessary to convert name/class/default 
  values to
  UIDs in Tk_ConfigureWidget ?
  - Is it really necessary to have a per-thread UID table ? 
  ---
  In the meantime I tried to temporarily fix it by:

  1. Making dbName/dbClass/defValue fields in 
  Tk_ConfigSpec
  to normal char pointer instead of Tk_Uids
  2. Using a mutex locked global (= per process) Uid table
  3. Making a temporary copy of the Tk_ConfigSpec array 
  in
  Tk_ConfigureWidget

  See the attached patch. However, this isn't perfect since 
  the
  TK_CONFIG_OPTION_SPECIFIED bit is not reflected to 
  callers
  of Tk_ConfigureWidget for threaded builds of Tk. 
  ---
  And attached patch.


tkt_uuid: 659218ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 49. [grid]
priority: 9 Immediate
foundin: None
resolution: Accepted
title: make column/row configure easier
comment:
  When I use the grid tool, I don't care about what
  columns or rows get certain options.  I care about the
  widgets.  It would make my life easier to let Tk figure
  things out for me.  This is what I had in mind, more or
  less:

  grid columnconfigure .foo.bar -weight 1

  where .foo.bar is a widget, not a 'master'.

  Maybe there is another way to do it that is cleaner.

  Thankyou,
  Dave


tkt_uuid: 659497ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 20. [tk_optionMenu]
priority: 5 Medium
foundin: None
resolution: None
title: hardcoded 2 pixel borders
comment:
  in tk_optionMenu{} (optMenu.tcl file), border width and
  highlight thickness are hardcoded to 2 (ugly) pixels,
  thus preventing setting an application wide 1 pixel
  border width for widgets, using the option command.
  (bug present in both 8.3 and 8.4 releases)

  Jean-Luc Fontaine (jfontain@free.fr)


tkt_uuid: 661792ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: TkCreateFrame didn't get application name
comment:
  When a window is created (or tried to be "place"d) when wish  
  exists (activated by a <Destroy> binding), wish aborts,  
  instead of returning some kind of error... 
   
  There is a small script (WishAbort.tcl) that reproduces 
  the error...  


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: 664111ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: tk_getOpenFile on WNT does not see VFS
comment:
  Under the Windows family of OSes (and I suspect Macs) tk_getOpenFile, tk_getSaveFile and 
  tk_chooseDirectory do not see VFS directories and files. 

  Example: 

                                   #!/bin/sh 
                                   # the next line restarts using wish \ 
                                   exec wish "$0" "$@" 

                                   package require vfs 

                                   ## 
                                   ## Mount your favoriate directory as /test 
                                   ## 
                                   ... 

                                   ## 
                                   ## Test should be seen as the initial directory 
                                   ## 
                                   set file [tk_getOpenFile -initialdir {/test}] 


  Please note that this bug was originally submitted as bug 655505 against TclVfs.


tkt_uuid: 664780ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 3 Low
foundin: obsolete: 8.4.1
resolution: Fixed
title: SGI warning: OpenIM
comment:
  cc-1552 cc: WARNING File =
  /home/fs3c/dgp/tk8.4.1/unix/tkUnixEvent.c, Line = 587
    The variable "modifier_list" is set but never used.

        char *modifier_list;
              ^


tkt_uuid: 664781ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 3 Low
foundin: obsolete: 8.4.1
resolution: Fixed
title: SGI warning: EntrySetValue
comment:
  cc-1552 cc: WARNING File =
  /home/fs3c/dgp/tk8.4.1/unix/../generic/tkEntry.c, Line
  = 2512
    The variable "code" is set but never used.

        int code, valueLen, malloced = 0;
            ^


tkt_uuid: 664783ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 3 Low
foundin: obsolete: 8.4.1
resolution: Fixed
title: SGI warning: ListboxSelect
comment:
  cc-1552 cc: WARNING File =
  /home/fs3c/dgp/tk8.4.1/unix/../generic/tkListbox.c,
  Line = 2940
    The variable "increment" is set but never used.

        int i, firstRedisplay, increment, oldCount;
                               ^


tkt_uuid: 664785ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 7 High
foundin: obsolete: 8.4.1
resolution: Fixed
title: SGI warning: DisplayBitmap,DisplayLine
comment:
  cc-1552 cc: WARNING File =
  /home/fs3c/dgp/tk8.4.1/unix/../generic/tkCanvBmap.c,
  Line = 613
    The variable "fgColor" is set but never used.

        XColor *fgColor;
                ^

  cc-1552 cc: WARNING File =
  /home/fs3c/dgp/tk8.4.1/unix/../generic/tkCanvBmap.c,
  Line = 614
    The variable "bgColor" is set but never used.

        XColor *bgColor;
                ^


tkt_uuid: 664787ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 3 Low
foundin: obsolete: 8.4.1
resolution: Fixed
title: SGI warning: TkPostscriptImage
comment:
  cc-1552 cc: WARNING File =
  /home/fs3c/dgp/tk8.4.1/unix/../generic/tkCanvPs.c, Line
  = 1212
    The variable "depth" is set but never used.

        int i, depth, ncolors;
               ^


tkt_uuid: 664788ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 3 Low
foundin: obsolete: 8.4.1
resolution: Fixed
title: SGI warning: ZeroDataBlock
comment:
  cc-1552 cc: WARNING File =
  /home/fs3c/dgp/tk8.4.1/unix/../generic/tkImgGIF.c, Line
  = 742
    The variable "ZeroDataBlock" is set but never used.

    static int ZeroDataBlock = 0;
               ^


tkt_uuid: 664790ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 3 Low
foundin: obsolete: 8.4.1
resolution: Fixed
title: SGi warning: TextWidgetCmd
comment:
  cc-1552 cc: WARNING File =
  /home/fs3c/dgp/tk8.4.1/unix/../generic/tkText.c, Line = 621
    The variable "lastEnd" is set but never used.

                  TkTextIndex *indices, *ixStart, *ixEnd,
  *lastStart, *lastEnd;
                                                        
                ^


tkt_uuid: 666243ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: None
resolution: None
title: labels not moving in Mac OSX
comment:
  Problem detected only at Mac OSX when using the multi-column listbox, tablelist package, from www.nemethi.de. It works under Sun Solaris 8.0 and Window 2000.

  After creating a tablelist with multiple columns, and attaching it with vertical and horizontal bar. Shrink the width of the multi-col listbox, so you can slide the horizontal bar.

  In Sun and Window 2000, the lable and data columns move left and right accordingly.

  In Mac OSX, I am using 8.4.1 tcl/tk, the label will not move, only the data column move.

  Enclosed are the sample program you can use.
  You can start my example use:

  % source NavigateDir.tk
  % fmgr::NavigateDir:display {} -dir /usr


tkt_uuid: 666346ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 9 Immediate
foundin: obsolete: 8.4.1
resolution: Fixed
title: Selection handling crashes under KDE 3.0
comment:
  Consider the following simple script:

      set win .f
      label $win -text "I am the selection owner.\nClick
  on <Close>."
      selection own $win
      selection handle $win [list fetchSelection $win]

      button .b -text "Close" -command exit
      pack $win .b -padx 10 -pady 5

      proc fetchSelection {win offset maxChars} {
          return ""
      }

  Running the script with wish8.4 under KDE 3.0 and
  clicking on the
  "Close" button raises the message "Segmentation fault".

  The abnormal termination seems to be caused by a bug in
  the C-code
  related to the "selection handle" command.  After
  experiencing the
  problem using the ActiveState binary distribution, I
  compiled Tcl and
  Tk 8.4.1 with the TCL_MEM_DEBUG flag and ran the script
  again.
  The result was a premature termination of the program
  with the
  message

      unable to alloc 1633771903d bytes,
      /home/csaba/tcltk/tk8.4.1/generic/tkSelect.c line 1382

  (BTW:  The "d" appended to the erronously huge number
  of bytes
  above is due to the incorrect use of the format
  descriptor "%ud"
  instead of just "%u" in the file "generic/tclCkalloc.c".)

  By replacing "exit" with "destroy .", or even just
  [list destroy $win],
  the behavior remains unchanged.

  I have also checked out the newest CVS version of Tcl
  and Tk, and got
  the same segmentation fault.

  I suspect that the new (objectified) version of
  tkSelect.c (or of some
  other C file related to selection handling) has a bug
  that causes the
  crash under KDE 3.0.  Note that the attempt to allocate
  1.6 GB
  memory occurs still before the window could become
  completely
  visible.  This is probably because the first attempt to
  retrieve the
  selection occurs within a very short time (of one or
  two seconds). 

  Bryan Oakley's mclistbox and my Tablelist package make
  use of the
  "selection own" and "selection handle" commands to
  implement the
  "-exportselection" option.  Unfortunately, this bug
  makes it necessary
  to set the "-exportselection" option of all tablelist
  and mclistbox
  widgets to false (at least when created with Tk 8.4
  under KDE 3.0).


tkt_uuid: 667631ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: Drawing Text in XOR mode does not work on Windows
comment:
  Submitted by: jmartin _a_t_ notamusica D.O.T com

  When the current GC has been set to use XOR mode
  (XSetFunction(GCxor)), I would expect Tk_DrawChars() to
  draw the characters in xor mode, i.e. a second
  Tk_DrawChars() of the same text at the same location
  should remove the text. This is indeed how things work
  under Unix.

  Unfortunately, the windows implementation of
  Tk_DrawChars() always draws characters in copy mode. It
  uses the windows SetROP2() function to set the
  appropriate drawing mode, but SetROP2() applies only to
  windows drawing operations, not to windows text output,
  so it does not affect the way text is drawn.

  A solution might be to draw the text to a temporary
  bitmap and then XOR (or whatever the appropriate
  gc->function is) this temporary bitmap with the
  drawable/dc.


tkt_uuid: 669159ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Fixed
title: error msg on loading Tk in safe interpreter
comment:
  squish:44> /autons/ActiveTcl8.4.1/bin/wish
  % info patch
  8.4.1
  % interp create -safe i
  i
  % ::safe::loadTk i
  can't read "Si(access_path,n)": no such element in array
  %

  This happens on solaris2.6 and win2k.


tkt_uuid: 669595ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 8
foundin: obsolete: 8.4.1
resolution: Fixed
title: disabled check/radiobutton coloring changed
comment:
  For disabled Unix checkbuttons and radiobuttons in
  8.4.1 it is hard to tell, whether they are selected or not.

  I've set up a small page to see the changes from 8.3.5
  to 8.4.1 and with my submitted patch.

  http://www.inode.at/g.hintermayer/buttons/

  I have only *nix environment, can someone verify this
  on other OS's ?

  Gerhard


tkt_uuid: 669759ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 7 High
foundin: obsolete: 8.4.1
resolution: Fixed
title: image destruction on <Destroy> crashes
comment:
  This script crashes WinTk (debug or non-dbug build) on
  Windows 2000.


  # script
  image create photo splash -file [file join $tk_library
  images logo100.gif]

  canvas .c -width 100 -height 100
  .c create image 0 0 -image splash -anchor nw

  bind . <Destroy> {catch {image delete splash}}
  update

  destroy .
  # end script

  The crash occurs here:

  static void
  DeleteImage(masterPtr)
      ImageMaster *masterPtr;/* Pointer to main data
  structure for image. */
  {
      Image *imagePtr;
      Tk_ImageType *typePtr;

      typePtr = masterPtr->typePtr;
      masterPtr->typePtr = NULL;
      if (typePtr != NULL) {
  for (imagePtr = masterPtr->instancePtr; imagePtr != NULL;
  imagePtr = imagePtr->nextPtr) {
     (*typePtr->freeProc)(imagePtr->instanceData,
     imagePtr->display);

  with 'typePtr' being garbage.

  Vince.


tkt_uuid: 671122ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: None
resolution: Fixed
title: wish crashed with -visual truecolor when packing a panedwin
comment:
  wish crashes when a panedwindow is created.

  The script is as follows:

  % wish8.4 -visual truecolor

  toplevel .t
  panedwindow .t.p
  frame .t.p.1 -bg green
  frame .t.p.2 -bg blue
  pack .t.p.1 -expand yes -fill both
  pack .t.p.2 -expand yes -fill both
  .t.p add .t.p.1
  .t.p. add .t.p.2
  pack .t.p -expand yes -fill both
  % X Error of failed request:  BadMatch (invalid parameter attributes)
    Major opcode of failed request:  70 (X_PolyFillRectangle)
    Serial number of failed request:  138
    Current serial number in output stream:  139

  Note: wish does not crash when invoked without -visual truecolor

  This occured on a Silicon Graphics SGI O2 (standard display & flat screen)
  R5000, 256 Mb 

  I'd consider this a serious bug.


tkt_uuid: 671330ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4.1
resolution: Fixed
title: segfault when e.g. deiconifying destroyed window
comment:
  (at least that's what it looks to me)
  I have a (quite long) script that does on toplevel on
  the local screen and on on a remote screen. If there
  are more top-levels on the remote screen (sometimes
  requires user interaction) I do raise & deiconify the
  toplevel on <Visibility> and <Unmap> event (just in
  case the operator tries to close the window). In case
  more toplevels are fighting for the topmost postion, I
  do the raising with a (random) delay of ~2000 ms.
  Sometimes I do get segfaults, when, so far I have
  debugged the thing, I do deiconify the window. I thing
  (but I'm not sure) this is when I binded an empty
  script to the two events, destroyed the toplevel and
  the random delay is still running and fireing the
  deiconify/raise later. (Well, that might not be a good
  way to code, but that's another story). It could as
  well be, that X on on of the 2 screens terminates, I
  just don't know.

  You can check the thread "suggestion to track down
  segfaults"
  at Google
  http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&safe=off&threadm=3E2814AC.9070107%40inode.at&prev=/groups%3Fdq%3D%26num%3D30%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.tcl%26safe%3Doff%26start%3D30

  Everything (code exaples and stack traces are listed there)

  I've spent quit a lot hours trying to set up a x-liner
  to reproduce the error, but I was'nt successful. Sorry.
  If you want me to do some more debugging, give me a
  note (and a list of gdb commands ;-) )

  Gerhard


tkt_uuid: 672169ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Invalid
title: tag option problem (-background)
comment:
  This is a problem with tk text widget.

  When a tag is used to override the widgets -background
  value it also overrides the widgets -selectbackground
  value which means selection highlighting no longer
  occurrs in the tagged text.


tkt_uuid: 672362ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 3 Low
foundin: None
resolution: Wont Fix
title: No flash when tk_strictMotif is 1
comment:
  [.button flash] has no effect when tk_strictMotif is
  set to 1.
  If this behaviour is intentional, it should be mentioned
  in the manpage, if not, it should be fixed ;)


tkt_uuid: 673687ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: None
title: Entry widget inputs goes right-to-left
comment:
  Sometimes when you are typing into an entry widget, the
  characters
  will be inserted from right to left instead of from
  left to right.
  To see this, first create an entry widget.  For example:

         entry .e -width 30
         pack .e -padx 10 -pady 10

  Now enter some text into this widget.  With the mouse,
  click to
  the right of the text and drag the mouse all the way to
  the left past
  the beginning of the widget.  All text in the widget
  should become
  highlighted.  Continue holding down the mouse button
  and start
  typing.  The first key press deletes the selected text
  (which is correct)
  and inserts the typed key.  The second key press is
  inserted to the left
  of the first character instead of to the right.

  You can well argue that this is an unusual case since
  not many people
  begin typing with the mouse button still held down. 
  But sometimes
  (on the OS of the monopolist) a stray button-press
  event will leak into
  a widget as the widget is being created.  Thus Tk might
  think the
  button is being held down even when it is not.  (This
  is rare, and
  perhaps another bug - but it does happen.)

  The fix to this problem is simply to add a call to
  ::tk::CancelRepeat in the <KeyPress> binding of
  the entry widget.  I'll do that straight away.  The
  purpose of this bug report is merely to document
  what was done.


tkt_uuid: 673722ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 4
foundin: obsolete: 8.4.1
resolution: Fixed
title: Button width computation in standard dialogs
comment:
  The standard dialogs (tk_get*File, etc.) only pay
  attention to the button -text when computing the
  maximum button widths.   If buttons are also given an
  -image (say via the option database), the layout is
  miscomputed.

  For example:
  ----
  # Quick-and-dirty "theme" support: (Requires Tk 8.4+)
  image create photo check -data
  {R0lGODlhEAAQAIIAAPwCBMT+xATCBASCBARCBAQCBEQCBAAA
  ACH5BAEAAAAALAAAAAAQABAAAAM2CLrc/itAF8RkdVyVye4FpzUgJwijORCGUhDDOZbLG6Nd2xjwibIQ
  2y80sRGIl4IBuWk6Af4EACH+aENyZWF0ZWQgYnkgQk1QVG9HSUYgUHJvIHZlcnNpb24gMi41DQqpIERl
  dmVsQ29yIDE5OTcsMTk5OC4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCmh0dHA6Ly93d3cuZGV2ZWxjb3Iu
  Y29tADs=}

  option add *ok.image check
  option add *ok.compound left

  pack [button .ok -text OK];# This does the Right Thing
  tk_getOpenFile;# [Open] button is too small!
  ---


tkt_uuid: 676424ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: obsolete: 8.4.1
resolution: Fixed
title: No unmap event when iconifying, Aqua
comment:
  Pressing the iconify button on a toplevel window does not 
  generate an unmap event in Mac Aqua Tk 8.4.1.  The window 
  disappears and an icon is shown on the Mac OS X Dock but no 
  unmap event is generated.

  The following wish8.4 script demonstrates the problem

  bind . <Unmap> {puts unmap}

  After invoking this command press the iconify button on the 
  window frame.  The word "unmap" should be printed to the 
  console but is not.  Although the window is iconified the "winfo 
  ismapped ." command returns true.

  winfo ismapped .
  1

  In the Tk molecular graphics application we develop the unmap 
  event on the main window is used to unmap other dialogs the 
  application is showing.  It is also used to stop updating the 
  realtime display so the CPU utilization drops when the application 
  is iconified.


tkt_uuid: 676438ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 4
foundin: obsolete: 8.4.1
resolution: Works For Me
title: Button 2 and 3 reversed, Aqua
comment:
  Pressing the rightmost button on my 3 button mouse generates a 
  Tk event saying button 2 was pressed, while pressing the middle 
  button generates an event saying button 3 was pressed.  This is 
  on Aqua Tk 8.4.1.  Other applications on my Mac, such as the X 
  server identify the rightmost button as button 3 and the middle 
  button as button 2.  Only Tk appears to reverse buttons 2 and 3.

  The following wish8.4 script will display the button number 
  associated with button presses.

  bind . <ButtonPress> {puts "%b"}

  Pressing my 3 mouse buttons from left to right, prints 1 3 2.


tkt_uuid: 676462ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Out of Date
title: Overrideredirect window takes focus, Aqua
comment:
  A toplevel window with overrideredirect set takes the input focus 
  when raised in Aqua Tk 8.4.1. This kind of window is used for 
  implementing balloon help. It should not take keyboard and pointer 
  events when raised.  The raise command is intended to change 
  stacking order -- the window manager then determines whether it 
  gets the focus. Overrideredirect windows are not supposed to be 
  managed by the window manager and so should never be given 
  the focus unless explicitly done so by a Tk command.  The X11 
  and Windows Tk implementations do not give an overrideredirect 
  window the focus when it is raised.

  The consequence of the current Aqua Tk 8.4.1 behaviour is that 
  balloon help windows steal the focus.  For example, in the Python 
  shell (IDLE) after typing a function name and an open parenthesis 
  a balloon shows the expected arguments to the function.  Since 
  this balloon window takes the keyboard focus when you continue 
  to type the function arguments they go to the balloon window 
  instead of the shell window.

  Here are wish8.4 commands that demonstrates the problem.

  toplevel .t ; wm withdraw .t ; wm overrideredirect .t 1
  wm deiconify .t
  wm raise .t

  After the deiconify the toplevel (without a window frame) has the 
  keyboard focus.  Clicking on another window and then invoking 
  the "wm raise .t" command gives the focus back to the 
  overrideredirect window .t.


tkt_uuid: 678281ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Works For Me
title: Double-Button-1 not detected
comment:
  I discovered a situation where Double-Button events are
  not detected.
  Basically, if the widget hierachy is sufficiently deep
  enough, physical events get lost before a Double,
  Triple, etc., events can be detected.

  Making the event ring larger solves the problem, but I
  think this just postpones the issue and might have the
  side effect of slowing down event processing on slower
  machines.

  The problem can be demonstrated with the attached code.
   Double clicking on the window should produce a
  Button-1, ButtonRelease-1, and Double-Button-1 message,
  which it does as long as the hierarchy depth is small
  (~12).

  Before you argue that this kind of widget depth is
  ludicrous, it's quite possible when using something
  like incrTk, building up megawidgets from other
  megawidgets.

  -Brian


tkt_uuid: 678939ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: None
resolution: None
title: reqwidth and reqheight not reset
comment:
  A frame's reqwidth and reqheight are not reset after
  children/slaves are removed.

  When a frame is created (with default -width 0 -height
  0), the frame has a reqwidth and reqheight of 1 pixel.
  When packing/griding a child label, for example, the
  frame's reqwidth/height increases to accomodate its
  child. After the child widget is
  destroyed/unpacked/ungrided, I believe the frame's
  reqwidth/height should return to 1 pixel, but it
  remains the same.

    set f [frame .f]
    set l [label .f.l -text "Hello World"]

    pack $f -e 1 -f both
    puts "$f reqwidth='[winfo reqwidth $f]'
  reqheight='[winfo reqheight $f]'"

    pack $l
    update
    puts "$f reqwidth='[winfo reqwidth $f]'
  reqheight='[winfo reqheight $f]'"

    destroy $l
    update
    puts "$f reqwidth='[winfo reqwidth $f]'
  reqheight='[winfo reqheight $f]'"

  returns:

  .f reqwidth='1' reqheight='1'
  .f reqwidth='71' reqheight='20'
  .f reqwidth='71' reqheight='20'

  This happens on Linux, tcl_patchLevel 8.3.4 / 8.4.0 / 8.4.1


tkt_uuid: 679892ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: Dialog-box crashes on Tcl/Tk Aqua 8.4.1 / Iwidgets
comment:
  Version: Tcl/Tk Aqua 8.4.1 
  OS: OS X 10.2 (Jaguar)
  Extensions: Itcl/Itk/Iwidgets supplied with Aqua version

  Many of my dialog boxes that were created using 
  iwidgets dialogshell and contain other iwidgets crash 
  sometime during the activation process (e.g., "$ds 
  activate" where $ds is the variable assigned the dialog 
  box widget).  The dialog box itself appears, but it seems 
  to crash during the drawing of its component widgets.
  There is no core dump file, the application just closes 
  inexplicably.  It occurs on virtually all such dialog boxes 
  in the scripts that I have tried.   I have tried setting the 
  dialog boxes to be both modal and modeless, with no 
  change in behavior.

  The file in which this occurs is quite large, but it is from 
  another SourceForge-hosted project OpenSoundWorld, I 
  am happy to send to whomever is handling this request.

  I have tried unsuccessfully to isolate the problem using 
  puts statements and strategic "commenting out" of 
  lines to no avail.

  Since it appears to happen in Tcl scripts and I can't 
  isolate it to a particular Tk issue, I'll try here first.  If 
  someone knows this to be a Tk issue, I'll happily refer it 
  on to that project.

  Any help would be appreciated!  Thanks!
  -Amar
  peoplestank@users.sourceforge.net


tkt_uuid: 679960ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 4
foundin: obsolete: 8.4.1
resolution: Out of Date
title: Option menu shows \'...\', Aqua
comment:
  Option menu entries sometimes are shown in the menu button 
  abbreviated with "..." even though the button is allowed to resize 
  to accomodate the text.

  This happens on Aqua Tk 8.4.1.  Testing shows that the option 
  menus can only use the default font.  This is probably an 
  implementation limitation that should be documented.  If the font 
  is changed using the Tk option database then the option menu 
  continues to use the default font but sizes the button to 
  accomodate text using the requested font.

  Here is a wish script that demonstrates the problem.

  option add *font {system 8}
  wm geometry . 400x100
  tk_optionMenu .m v {The menu button is not} {made big enough} 
  {to accomodate the text.}
  pack .m

  The option menu button will show part of the text of the selected 
  entry followed by "...".  If the first line of the script is commented 
  out then the full text is shown in the option menu button.

  This bug makes panels of preferences containing many option 
  menus difficult to use.


tkt_uuid: 679968ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 4
foundin: obsolete: 8.4.1
resolution: Out of Date
title: Checkbutton text wraps when it shouldn\'t, Aqua
comment:
  Checkbutton text wraps even though the checkbutton is allowed to 
  resize to accomodate the text.

  This happens on Aqua Tk 8.4.1 when the checkbutton font is set 
  to something smaller than the default font.  The following wish 
  script demonstrates the problem.

  wm geometry . 400x100
  checkbutton .b -text {This text should not wrap} -font {system 8}
  pack .b

  The text in the checkbutton is wrapped onto two lines even though 
  there is adequate space for it to be on one line.  Removing the 
  font option causes the text to be displayed on one line with no 
  wrapping.

  The problem appears to be that the checkbutton does not 
  correctly calculate the space needed to display the text on one 
  line when the font is something other than the default font.

  This bug makes preference dialogs with many checkbuttons a 
  mess of wrapped text where no wrapping is needed.

  Tom Goddard
  goddard@cgl.ucsf.edu


tkt_uuid: 67c8e8bd7181b6b96e3e8dc8bc5493aa12e192e9
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
severity: Minor
foundin: 8.5
private_contact: e40bee9bb70e18ae53b0901318cf2dc9b532d408
resolution: None
title: DISABLEd Tkinter.Listbox still fires <<ListboxSelect>> for mouse click
comment:
  Run the script below. Clicking on the window will fire off <<ListboxSelect>> events even though the widget is disabled. Keyboard actions do not fire this event. I was bounced by the Python guys to you.

  #-- Test file --

  import Tkinter as tki

  def selection_changed(event):
    print 'Selection changed'

  root = tki.Tk()
  listbox = tki.Listbox(root, selectmode=tki.BROWSE)
  listbox.pack(side='left', fill='both', expand=True)
  listbox.bind('<<ListboxSelect>>', selection_changed)
  listbox.config(state=tki.DISABLED)
  root.mainloop()


tkt_uuid: 680660ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: Menu items accidentally selected
comment:
  The bindings for menubuttons/menus allow mouse
  selection by
  either press-drag-release or by click-move-click, and
  both
  normally work fine.  However, when the menu is posted
  so it
  overlaps the menubutton, the click-move-click scheme
  fails
  because some random menu item receives the
  ButtonRelease 
  from the initial click on the menubutton, and gets
  selected
  immediately.

  I have included a demo, if that is of any use.  Try
  clicking on
  the menu button with the window positioned mear the
  bottom
  of the computer screen.

  This behavior occurs on Linux installations of Tcl 8.0
  - 8.4.1
  (at least).  I suspect the problem does not occur on
  Windows.

  I think the bindings for menus should not accept a
  ButtonRelease 
  for some short period after the menu is posted.  The
  short period
  is probably specified by the window manager settings as
  the
  button-click time.  

  As a work-around, I have been using:

  bind Menubutton <Button-1> {+
     bind [winfo children %W] <ButtonRelease-1> {break}
     after 300 { bind [winfo children %W]
  <ButtonRelease-1> {}}
  }

  to disable the ButtonRelease event in menus for the
  first 300ms
  after the MenuButton is clicked on.


tkt_uuid: 680884ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Accepted
title: menubutton scripts are confused about their owning menu
comment:
  The attached script shows a bug in the menubutton 
  scripts, when the act of creating a menu takes 
  some time, and the user inadvertently moves the 
  mouse onto a different menu button. Tk tries to 
  *post* the menu for the other menubutton, but that 
  doesn't exist!

  Given we are in the middle of executing bindings 
  for the first button, there is no reason for Tk to try 
  to do something on the other.

  # Now click on menu 'one', but while you 
  # are waiting for it to popup, move the 
  # mouse over menu 'two'.  
  # 
  # You will get the following bgerror:
  # 
  # invalid command name ".two.m"
  #     while executing
  # "$menu cget -type"
  #     (procedure "MbPost" line 13)
  #     invoked from within
  # "MbPost $new $rootx $rooty"
  #     (procedure "tk::MbMotion" line 14)
  #     invoked from within
  # "tk::MbMotion .one down 95 93
  # "
  #     (command bound to event)


tkt_uuid: 681692ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Remind
title: Map <Button-4/5> to <MouseWheel> on UNIX
comment:
  Currently on UNIX, mousewheel events are mapped to
  mouse buttons 4 and 5. On Windows, there is a separate
  <MouseWheel> event. I understand that historically,
  buttons 4 and 5 are used on UNIX, but in the interests
  of hiding platform-specific details, it would useful to
  be able to portably register interest in mousewheel
  events, without having to work out how those are
  conveyed on a particular platform.
  To this end, I propose adding a simple mapping to Tks
  script library so that button 4/5 events also generate
  an appropriate <MouseWheel> event. This can be done
  easily in two lines of code:

  bind all <Button-4> {event generate %W <MouseWheel>
  -delta 1}
  bind all <Button-5> {event generate %W <MouseWheel>
  -delta -1}

  This seems to get things working on my Linux box. I
  haven't looked at the delta values on Windows, so they
  may need some tweaking (finding a suitable default
  value, and working out whether up is negative or positive).
  I think this is a small change, but one which does
  quite a lot in hiding platform specific details, in a
  backwards-compatible way.


tkt_uuid: 682183ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: None
resolution: None
title: Support for quick positioning by typing first letter
comment:
  A feature that would make life much easier with
  listboxes with long lists is that it scrolls to the
  first or next item which starts with the letter or
  character that you typed. 

  It is a common enough feature in many Windows
  applications


tkt_uuid: 682603ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Works For Me
title: canvas arc and rect broken on alpha
comment:
  Forwarded bug reports from Debian.  Original reports
  can be seen at <http://bugs.debian.org/151435> and
  <http://bugs.debian.org/156702>.  Basically, "create
  rect" (with reasonable coordinates) and "create arc"
  both fail on Alpha (64-bit architecture).  I suspect
  that they will also fail on other 64-bit archs (like
  ia64), will confirm/deny this last as soon as possible.


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: 683813ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Fixed
title: TabToWindow should treat spinbox same as entry
comment:
  A Spinbox is really just a fancy kind of Entry widget.
  And when the keyboard focus is moved to an Entry widget
  using the Tab key, the contents of the widget is
  automatically selected. The same thing should happen
  for the Spinbox.


tkt_uuid: 684070ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Encoding problems (no Unicode)
comment:
  I don't know if this is a bug not noticed before,
  or simply something which is because things haven't
  been implemented yet, but the fact remains: The Tk
  widgets don't display the characters that they are
  told to. A note on http://mini.net/tcl/3753 
  (encoding problems are listed as "solved") seems to 
  claim that all this has been fixed as of 8.4.1, but
  the below indicates that they are not.

  Consider the sequence of commands:

  () % info patchlevel
  8.4.1
  () % label .a -text "Hello world!"
  .a
  () % pack .a -padx 10 -pady 10

  Now we're at picture A in the attached archive.
  So far, everything is OK, but now let's try it with
  a non-ASCII character.

  () % .a configure -text "Hello \u01F5world!"

  This changes the window to what it shown in picture B.
  Clearly, the expected U+01F5 (LATIN SMALL LETTER G WITH
  ACUTE) is missing in the label text. Of course, this 
  could be because it is missing from the font, so let's
  check that.

  () 7 % .a cget -font
  system
  () 8 % font actual system
  -family {Lucida Grande} -size 13 -weight normal -slant roman -
  underline 0 -overstrike 0

  Hence the font is Lucida Grande. Switching to the 
  character palette (which BTW does not seem to want to 
  show when Wish is the active program), we see what is
  in picture C: This character _is_ included in Lucida
  Grande. Hence it is not the font that is to blame.

  Most of the characters in the ISO latin 1 range work
  all right, but a few produce very strange results.
  Consider

  () % .a configure -text "Hello \xa4world!"

  --the result of which can be seen in picture D.
  That doesn't like the expected international currency
  sign to me, but rather like some CJK ideograph.


tkt_uuid: 684319ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Duplicate
title: Incorrect screen positions reported, Aqua
comment:
  Screen positions reported by winfo rootx and winfo rooty are 
  sometimes incorrect in Aqua Tk 8.4.1.  When I bring up a toplevel 
  Tix window, all other toplevel windows in the application after 
  being moved report that their rootx, rooty position equals that of 
  the Tix toplevel.  This situation persists until the Tix toplevel is 
  unmapped or destroyed.

  This problem occurs using a port of the Tix meta-widget package 
  to Mac Aqua that is not yet distributed so I cannot easily provide 
  test code to demonstrate the problem.

  I have tracked the problem to Tk source code file

       tk8.4.1/macosx/tkMacOSXMouseEvent.c

  line 292 in function TkMacOSXProcessMouseEvent():

          case inDrag:
              DragWindow(medPtr->whichWin, where, NULL);
              where2.h = where2.v = 0;
              LocalToGlobal(&where2);
              if (EqualPt(where, where2)) {
                  return false;
              }

  The LocalToGlobal() call in this code uses the current graphics 
  port, but the port is not set anywhere nearby above this call.  In 
  the above incorrect rootx,rooty situation the wrong port is current.  
  Adding a SetPortWindowPort() before the LocalToGlobal() call 
  fixed the problem.

          case inDrag:
              DragWindow(medPtr->whichWin, where, NULL);
              where2.h = where2.v = 0;
  SetPortWindowPort(medPtr->whichWin);    /* Added by Tom G to 
  fix wrong window position bug. */
              LocalToGlobal(&where2);
              if (EqualPt(where, where2)) {
                  return false;
              }

  I am not familiar enough with the code to know if this is the 
  correct solution.

  Tom Goddard
  goddard@cgl.ucsf.edu


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: 685505ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Fixed
title: add description of ^z processing to wish man page
comment:
  The 'wish.1' man page needs a description of end-of-file handling to discuss the effect
  of the ^Z Windows file terminator.  Larry Virden logged the corresponding issue in 'tclsh' as
  http://sourceforge.net/tracker/?func=detail&aid=685485&group_id=10894&atid=110894


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: 686329ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 87. Logos
priority: 5 Medium
foundin: None
resolution: Out of Date
title: extended Tk icon for Win32
comment:
  The current Tk icon (tk.ico) contains only a few resolutions and colr depths.  Most notably, 48x48 icons are missing.  These are used to produce much nicer-looking (read: professional) icons on newer Windows releases (actually, I think as far back as Win98).

  It would be very useful to extend the icons included in Tk so Win32 builds would have a better look in Windows Explorer.

  The second reason for doing this, is that it enables a way to patch executables and replace built-in icons.  These "resources" are fixed size, but can be patched to change the icon.  Such changes are important for standalone versions of Wish, and derived single-file apps such as Tclkit and custom-made Starpacks.

  The file submitted below contains 6 icon images, the current 48x48 versions were created by stretching 32x32 versions (not perfect, but enough to support replacement later).  The resolutions are:
     16x16, 32x32, 48x48 - 16 and 256 colors each

  I dropped the 1-bit (monochrome) version.  It was probably a Win3.x/Win32s leftover.

  This same icon is currently in Tclkit.  It can be replaced by the SDX utility when creating Win32 Starpacks.  The presence of 6 known resolutions is essential for developers to be able to create a replacement .ico file.

  -jcw


tkt_uuid: 687522ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.4.1
resolution: Fixed
title: <<Modified>> triggers too often
comment:
  The <<Modified>> virtual event now triggers 
  everytime the modified flag is explicitely set with 
  the 'edit modified <boolean>' command. It should 
  only trigger when the value of the modified flag 
  actually changes.


tkt_uuid: 688188ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: Leave event not working correctly in OS X Aqua
comment:
  Compiled CVS version today of tk OS X Aqua.  When the
  user presses the mouse button and moves the mouse, both
  B1-Motion and B1-Leave are immediately generated (even
  when the mouse stays inside the window) and B1-Leave is
  not generated as the user leaves the window.


tkt_uuid: 688572ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Minor message formatting fix
comment:
  Literal \n strings appear in the "File xxx already 
  exists.\n\nReplace existing file" message generated by the 
  save dialogue.

  Use quotes instead of curly braces to cure.


tkt_uuid: 689099ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Pane increases size badly
comment:
  The panedwindow does not compute the sizes
  correctly when increasing the size.
  It subtracts the borderwidth wrongly in a
  way that gets obvious when increasing this:

  panedwindow .p -bd 10
  frame .f1 -width 100 -height 50 -bg blue
  frame .f2 -width 100 -height 50 -bg red

  .p add .f1 -sticky news
  .p add .f2 -sticky news
  pack .p -side top -fill both -expand 1

  Attached is a fix and a test case.

  If a maintainer says ok I can commit
  this before 8.4.2.


tkt_uuid: 689199ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: Memory Leak when GIF reading fails
comment:
  There is an execution path in FileReadGIF that can
  result in trashBuffer being allocated but not
  deallocated.


tkt_uuid: 689357ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 9 Immediate
foundin: obsolete: 8.4.1
resolution: Duplicate
title: Read of Freed Memory
comment:
  Tk_MeasureChars() and Tk_DrawChars() (in
  unix/tkUnixFont.c) are both capable of ending up
  reading freed memory (which is a critical failure when
  Tcl is built with memory debugging turned on) the
  *second* time the subfont table for a font is extended.

  The problem is that those two functions keep around a
  pointer into the old subfont table over a call to
  FindSubFontForChar() which (via its calls to
  CanUseAlias()) can reallocate the subfont table.  The
  first reallocation is harmless enough, because we start
  out with a subfont table that is allocated as part of
  the overall font structure, but the second leaves us
  dangling off into nowhere...


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: 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: 690507ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Accepted
title: Fix for 690178
comment:
  This patch moves the actual running of the menu command till idle time.  This brings it closer to how the Windows implementation works (there the Native tracking function posts a WM_COMMAND event and then exits, and the command is run in the WM_COMMAND event handler.)


tkt_uuid: 691774ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 41. Photo Images
priority: 8
foundin: None
resolution: None
title: Photo Image Rotation
comment:
  Add a subcommand to photo images to allow for rotation
  of them.  You can do this partially using code on the
  Wiki, but it is slow (especially due to colour
  reparsing, I believe) and can't handle the alpha
  channel at all.


tkt_uuid: 691908ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: Compiling static Tcl and dynamic Tk fails on mingw Windows
comment:
  When trying to build static Tcl 8.4.1 with dynamic Tk,
  building failed as Tk tried to link against
  libtclstub84.a, while libtclsutb84s.a was available.

  This can probably be the same with non-mingw builds on
  Windows (do not have the software to check it)


tkt_uuid: 691973ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: OS X Aqua: accelerators not drawn for menu entries under men
comment:
  Compiled from recent CVS checkout, OS 10.1.5, 
  Devel tools April 2002.  The -accelerator flag has
  no effect when the menu is attached to a menubutton.
  -accelerator works for menubutton menus on other OS's.
  I poked around in the source code, but wasn't able to
  track down where this is happening... perhaps in the 
  calls to MacOS?  At any rate, DrawMenuEntryAccelerator
  is not called when the menu attached to a menubutton 
  is posted

  test code:

  menubutton .mb -menu .mb.m -text Test
  menu .mb.m
  .mb.m add command -command {puts hello} -label hello
  .mb.m entryconfigure 1 -accelerator h
  pack .mb


tkt_uuid: 693063ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 62. Geometry Functions
priority: 8
foundin: None
resolution: Accepted
title: Rework pack, grid, and place geom managers
comment:
  After some discussion with Jeff, I created this patch
  to fixup
  a couple of problems in the geom managers. The first big
  problem was with place. When certain errors were raised
  by the place command, the winfo geometry command
  would return invalid results. Here is a quick example:

  place .foo -in .foo

  The above returns an error but also makes . the parent and
  sets place as the geom manager. Fixing this is actually
  quite
  tricky, what needs to be done is to have one block of code
  in the place command that gets executed when a new slave
  is added. Then, the Tk_ManageGeometry function can
  be called from that spot instead of from CreateSlave where
  it currently is called. To do that, one needs to check for
  simple cases like "place .foo -x 0 -y 1" followed by
  "place .foo -x 1 -y 1" to ensure that these do not change
  anything related to the slave window. The attached patch
  also adds this sort of check for the grid command so that
  it also works more like the pack impl.

  The other change this patch makes is to check for a
  NULL master and slave in each of the structure callbacks
  that can be invoked for child windows. The trick is that
  in error cases like "pack .foo -in .foo" the window .foo
  is entered into the pack slave table even though it is not
  linked into a master and slave. The PackStructureProc
  callback need to check for this sort of window before
  doing anything else so that no geom calculations are
  done for these sorts of error windows. The pack code
  did this, but it needed to be fixed in the grid code.

  I have run the test suite with these changes added and
  I am not seeing any failures. I would like to get this
  patch added as soon as possible since I am working on
  another patch to fix other geom manager problems
  and it needs to have this one applied first.


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: 693466ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 9 Immediate
foundin: obsolete: 8.4.2
resolution: Fixed
title: README update for 8.4.2
comment:
  tk/unix/README refers to Tcl 8.4.1 -- ought to be 8.4.2

  tk/macosx/README claims some features were added
  in 8.4.3.  Unless that's a prediction about future
  releases, it should be corrected.


tkt_uuid: 693512ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: make install fails with spaces in winhelp path
comment:
  After 'nmake -f makefile.vc TCLDIR=../../tcl8.4 
  winhelp', I try to install, and I get this:

  ..\library\msgs\ru.msg
  10 File(s) copied
          xcopy /i /y ".\Release\tk84.hlp" "C:\Program 
  Files\Tcl\doc\"
  .\Release\TK84.HLP
  1 File(s) copied
          xcopy /i /y ".\Release\tk84.cnt" "C:\Program 
  Files\Tcl\doc\"
  .\Release\tk84.cnt
  1 File(s) copied
          "..\..\tcl8.4\win\Release\tclsh84.exe" 
  C:\WINNT\Profiles\VinceD\LOCALS~1
  \Temp\nma00476.
  Installing tk's helpfile contents into Tcl's ...
  expected integer but got "a"
      while executing
  "open C:/Program Files/Tcl/doc/tcl84.cnt a"
      invoked from within
  "set f [open C:/Program Files/Tcl/doc/tcl84.cnt a]"
      (file "C:\WINNT\Profiles\VinceD\LOCALS~1
  \Temp\nma00476." line 16)
  NMAKE : fatal error U1077: '"..\..\tcl8.4
  \win\Release\tclsh84.exe"' : return cod
  e '0x1'
  Stop.


tkt_uuid: 693603ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 86. Test Tools
priority: 5 Medium
foundin: None
resolution: None
title: Tk test suite should hardwire options
comment:
  To prevent make test from failing due to unusual X (or
  Windows, or  other) resources, the test suite should
  expect all settings for colors, fonts, font sizes,
  window sizes, etc. to be read via the options command.


tkt_uuid: 694271ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Accepted
title: TK_DLL_FILE for tkConfig.sh
comment:
  Just like tclConfig.sh.in defines a TCL_DLL_FILE
  environment variable, tkConfig.sh.in should define a
  TK_DLL_FILE environment variable, so install scripts of
  dependant programs know which files to copy to build a
  complete distribution.


tkt_uuid: 694280ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 3 Low
foundin: obsolete: 8.4.1
resolution: Invalid
title: impossible to create an image named "info" on windows
comment:
  set tcl_platform(os) 
  Windows NT

  set tcl_platform(osVersion)
  5.1

  info patchlevel
  8.4.1

  image create photo info -file info.gif

  bad option "exists": must be blank, cget, configure, 
  copy, data, get, put, read, redither, transparency, or write

      while executing
  "consoleinterp eval "info exists tcl_prompt1""
      (procedure "ConsolePrompt" line 6)
      invoked from within
  "ConsolePrompt"
      (procedure "tk::ConsoleInvoke" line 23)
      invoked from within
  "tk::ConsoleInvoke"
      (command bound to event)


tkt_uuid: 694528ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: None
resolution: None
title: Postscript text too small
comment:
  The canvas postscript command outputs text that is the 
  wrong size, in relation to other canvas elements. The 
  size is too small by a factor of [tk scaling].
  A detailed description and test script are on the wiki,
  http://mini.net/tcl/8483

  Ian Gay
  gay@sfu.ca


tkt_uuid: 694532ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Tk test suite failuers...
comment:
  =================================
  =================================
  =============
  *** Compiler has 'Optimizations'
  *** Compiler has 'Pentium 0x0f fix'
  *** Linker has 'Win98 alignment problem'
  *** Doing threads
  *** Doing symbols
  *** Doing profile
  *** Doing thrdalloc
  *** Doing memdbg
  *** Doing compdbg
  *** Intermediate directory will 
  be '.\Debug\tk_ThreadedDynamic'
  *** Output directory will be '.\Debug'
  *** Suffix for binaries will be 'td'
  *** Optional defines are '-DTCL_MEM_DEBUG -
  DTCL_COMPILE_DEBUG -DTCL_COMPILE_STAT
  S -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1'
  *** Dependency rules are not being used.

          set TCL_LIBRARY=..\..\tcl\library
          set PATH=..\..\tcl\win\Debug
          ".\Debug\tktest.exe" ..\tests\all.tcl  
  | ".\Debug\cat32.exe"
  Tests running in interp:  
  F:/tcl/pure/8.4.2/tk/win/Debug/tktest.exe
  Tests located in:  F:/tcl/pure/8.4.2/tk/tests
  Tests running in:  F:/tcl/pure/8.4.2/tk/win
  Temporary files stored in F:/tcl/pure/8.4.2/tk/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 Thu Feb 27 10:33:05 AM Pacific 
  Standard Time 2003
  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-10.1 EmbWinLayoutProc procedure 
  FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      .t window create 1.5 -create {
          frame .f -width 10 -height 20 -bg $color
      }
      update
      list [winfo exists .f] [winfo geom .f] [.t index .f]

  ---- Result was:
  1 10x20+45+5 1.5
  ---- Result should have been (exact matching):
  1 10x20+40+5 1.5
  ==== textWind-10.1 FAILED


  ==== textWind-10.11 EmbWinLayoutProc 
  procedure, doesn't fit on line FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 130 -height 20 -bg $color -bd 
  2 -relief raised
      .t window create 1.12 -window .f
      update
      list [.t bbox .f] [.t bbox 1.13]

  ---- Result was:
  {101 5 130 20} {231 6 8 17}
  ---- Result should have been (exact matching):
  {89 5 126 20} {}
  ==== textWind-10.11 FAILED


  ==== textWind-11.1 EmbWinDisplayProc 
  procedure, geometry transforms FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      pack forget .t
      place .t -x 30 -y 50
      frame .f -width 30 -height 20 -bg $color
      .t window create 1.12 -window .f
      update
      winfo geom .f

  ---- Result was:
  30x20+131+55
  ---- Result should have been (exact matching):
  30x20+119+55
  ==== textWind-11.1 FAILED


  ==== textWind-11.2 EmbWinDisplayProc 
  procedure, geometry transforms FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      pack forget .t
      place .t -x 30 -y 50
      frame .t.f -width 30 -height 20 -bg $color
      .t window create 1.12 -window .t.f
      update
      winfo geom .t.f

  ---- Result was:
  30x20+101+5
  ---- Result should have been (exact matching):
  30x20+89+5
  ==== textWind-11.2 FAILED


  ==== textWind-13.1 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 top -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

  ---- Result was:
  5x5+23+6 {23 6 5 5}
  ---- Result should have been (exact matching):
  5x5+21+6 {21 6 5 5}
  ==== textWind-13.1 FAILED


  ==== 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+23+11 {23 11 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+23+16 {23 16 5 5}
  ---- Result should have been (exact matching):
  5x5+21+14 {21 14 5 5}
  ==== textWind-13.9 FAILED


  ==== textWind-16.2 EmbWinTextStructureProc 
  procedure FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 30 -height 20 -bg $color
      .t window create 1.6 -window .f
      update
      set result {}
      lappend result [winfo geom .f] [.t bbox .f]
      frame .f2 -width 150 -height 30 -bd 2 -relief 
  raised
      pack .f2 -before .t
      update
      lappend result [winfo geom .f] [.t bbox .f]

  ---- Result was:
  30x20+53+5 {53 5 30 20} 30x20+53+35 {53 5 30 
  20}
  ---- Result should have been (exact matching):
  30x20+47+5 {47 5 30 20} 30x20+47+35 {47 5 30 
  20}
  ==== textWind-16.2 FAILED


  ==== textWind-16.4 EmbWinTextStructureProc 
  procedure FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .t.f -width 30 -height 20 -bg $color
      .t window create 1.6 -window .t.f
      update
      pack forget .t
      update
      list [winfo ismapped .t.f] [.t bbox .t.f]

  ---- Result was:
  1 {53 5 30 20}
  ---- Result should have been (exact matching):
  1 {47 5 30 20}
  ==== textWind-16.4 FAILED

  tk.test
  unixButton.test
  unixEmbed.test
  unixFont.test
  unixMenu.test
  unixSelect.test
  unixWm.test

  ==== unixWm-9.4 TkWmMapWindow procedure, 
  icon windows FAILED
  ==== Contents of test case:

      catch {destroy .t}
      sleep 500
      toplevel .t -width 100 -height 50 -bg blue
      wm iconwindow . .t
      update
      set result [winfo ismapped .t]

  ---- 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
  ==== Contents of test case:

      catch {destroy .icon}
      catch {destroy .icon2}
      toplevel .icon -width 50 -height 50 -bg green
      toplevel .icon2 -width 50 -height 50 -bg red
      set result {}
      wm iconwindow .t .icon
      lappend result [wm state .icon] [wm state .icon2]
      wm iconwindow .t .icon2
      lappend result [wm state .icon] [wm state .icon2]
      destroy .icon .icon2
      set result

  ---- 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
  ==== Contents of test case:

      catch {destroy .icon}
      toplevel .icon -width 50 -height 50 -bg green
      wm geometry .icon +0+0
      update
      set result {}
      lappend result [wm state .icon] [winfo 
  viewable .icon]
      wm iconwindow .t .icon
      lappend result [wm state .icon] [winfo 
  viewable .icon]
      destroy .icon
      set result

  ---- Result was:
  couldn't send withdraw message to window 
  manager
  ---- 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
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 400 -height 150
      wm geometry .t +0+0
      tkwait visibility .t
      set result {}
      bind .t <Map> {set x "mapped"}
      bind .t <Unmap> {set x "unmapped"}
      set x {no event}
      wm iconify .t
      lappend result $x [winfo ismapped .t]
      set x {no event}
      wm deiconify .t
      lappend result $x [winfo ismapped .t]

  ---- Result was:
  unmapped 0 {no event} 1
  ---- Result should have been (exact matching):
  unmapped 0 mapped 1
  ==== unixWm-42.1 FAILED


  ==== unixWm-48.1 ParseGeometry procedure 
  FAILED
  ==== Contents of test case:

      wm geometry .t =100x120
      update
      list [winfo width .t] [winfo height .t]

  ---- Result was:
  104 120
  ---- Result should have been (exact matching):
  100 120
  ==== unixWm-48.1 FAILED


  ==== unixWm-49.1 Tk_GetRootCoords procedure 
  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 300 -height 200
      frame .t.f -width 150 -height 100 -bd 2 -relief 
  raised
      place .t.f -x 150 -y 120
      frame .t.f.f -width 20 -height 20 -bd 2 -relief 
  raised
      place .t.f.f -x 10 -y 20
      wm overrideredirect .t 1
      wm geometry .t +40+50
      tkwait visibility .t
      list [winfo rootx .t.f.f] [winfo rooty .t.f.f]

  ---- Result was:
  0 0
  ---- Result should have been (exact matching):
  202 192
  ==== unixWm-49.1 FAILED


  ==== unixWm-50.1 Tk_CoordsToWindow 
  procedure, finding a toplevel, x-coords FAILE
  D
  ==== Contents of test case:

      deleteWindows
      toplevel .t -width 300 -height 400 -bg green
      wm geom .t +40+0
      tkwait visibility .t
      toplevel .t2 -width 100 -height 80 -bg red
      wm geom .t2 +140+200
      tkwait visibility .t2
      raise .t2
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing [expr $x - 30] [expr $y + 
  250]]  [winfo containing [e
  xpr $x - 1] [expr $y + 250]]  [winfo containing $x 
  [expr $y + 250]]  [winfo cont
  aining [expr $x + 99] [expr $y + 250]]  [winfo 
  containing [expr $x + 100] [expr
  $y + 250]]  [winfo containing [expr $x + 199] [expr 
  $y + 250]]  [winfo containin
  g [expr $x + 200] [expr $y + 250]]  [winfo 
  containing [expr $x + 220] [expr $y +
   250]]

  ---- Result was:
  {} {} .t {} .t2 .t2 .t2 .t
  ---- Result should have been (exact matching):
  {} {} .t {} .t2 .t2 {} .t
  ==== unixWm-50.1 FAILED


  ==== unixWm-51.7 TkWmRestackToplevel 
  procedure, other window isn't mapped FAILED

  ==== Contents of test case:

      foreach w {.t .t2 .t3} {
          catch {destroy $w}
          toplevel $w -width 200 -height 200 -bg green
          wm geometry $w +0+0
      }
      raise .t .t2
      sleep 2000
      update
      set result [list [winfo containing 100 100]]
      lower .t3
      sleep 2000
      lappend result [winfo containing 100 100]

  ---- Result was:
  .t3 {}
  ---- Result should have been (exact matching):
  .t3 .t
  ==== unixWm-51.7 FAILED


  ==== unixWm-51.8 TkWmRestackToplevel 
  procedure, overrideredirect windows FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200 -bg green
      wm overrideredirect .t 1
      wm geometry .t +0+0
      tkwait visibility .t
      catch {destroy .t2}
      toplevel .t2 -width 200 -height 200 -bg red
      wm overrideredirect .t2 1
      wm geometry .t2 +0+0
      tkwait visibility .t2

      # Need to use vrootx and vrooty to make tests 
  work correctly with
      # virtual root window measures managers: 
  overrideredirect windows
      # come up at (0,0) in display coordinates, not 
  virtual root
      # coordinates.

      set x [expr 100-[winfo vrootx .]]
      set y [expr 100-[winfo vrooty .]]
      set result [list [winfo containing $x $y]]
      raise .t
      lappend result [winfo containing $x $y]
      raise .t2
      lappend result [winfo containing $x $y]

  ---- Result was:
  {} {} {}
  ---- Result should have been (exact matching):
  .t2 .t .t2
  ==== unixWm-51.8 FAILED


  ==== unixWm-51.9 TkWmRestackToplevel 
  procedure, other window overrideredirect FA
  ILED
  ==== Contents of test case:

      foreach w {.t .t2 .t3} {
          catch {destroy $w}
          toplevel $w -width 200 -height 200 -bg green
          wm overrideredirect $w 1
          wm geometry $w +0+0
          tkwait visibility $w
      }
      lower .t3 .t2
      update

      # Need to use vrootx and vrooty to make tests 
  work correctly with
      # virtual root window measures managers: 
  overrideredirect windows
      # come up at (0,0) in display coordinates, not 
  virtual root
      # coordinates.

      set x [expr 100-[winfo vrootx .]]
      set y [expr 100-[winfo vrooty .]]
      set result [list [winfo containing $x $y]]
      lower .t2
      lappend result [winfo containing $x $y]

  ---- Result was:
  {} {}
  ---- Result should have been (exact matching):
  .t2 .t3
  ==== unixWm-51.9 FAILED

  util.test
  visual.test
  visual_bb.test
  winButton.test
  winClipboard.test
  winDialog.test
  winFont.test
  winMenu.test
  winSend.test
  winWm.test

  ==== winWm-5.1 UpdateGeometryInfo: menu 
  resizing FAILED
  ==== Contents of test case:

      set result {}
      toplevel .t
      frame .t.f -width 150 -height 50 -bg red
      pack .t.f
      update
      set result [winfo height .t]
      menu .t.m
      .t.m add command -label foo
      .t conf -menu .t.m
      update
      lappend result [winfo height .t]
      .t.m add command -label "thisisreallylong"
      .t.m add command -label "thisisreallylong"
      update
      lappend result [winfo height .t]
      destroy .t
      set result

  ---- Result was:
  50 50 32
  ---- Result should have been (exact matching):
  50 50 50
  ==== winWm-5.1 FAILED

  window.test
  winfo.test

  ==== winfo-4.5 "winfo containing" command 
  FAILED
  ==== Contents of test case:

      winfo containing [winfo rootx .t.f] [winfo 
  rooty .t.f]

  ---- Result was:
  .
  ---- Result should have been (exact matching):
  .t.f
  ==== winfo-4.5 FAILED

  wm.test
  xmfbox.test

  Tests ended at Thu Feb 27 10:35:59 AM Pacific 
  Standard Time 2003
  all.tcl:        Total   8317    Passed  6871    Skipped 
  1425    Failed  21
  Sourced 182 Test Files.
  Files with failing tests: textWind.test unixWm.test 
  winWm.test winfo.test
  Number of tests skipped for each constraint:
          7       altDisplay
          16      colorsFree
          7       emptyTest
          265     fonts
          2       knownBug
          310     macOnly
          17      macOrUnix
          80      nonPortable
          79      nonUnixUserInteraction
          3       pseudocolor
          4       pseudocolor8
          71      secureserver
          1       tempNotPc
          1       tempNotWin
          5       testmenubar
          301     unix
          186     unixOnly
          19      userInteraction
          51      winSend
  stderr32

  This is on Windows NT 4 Service Pack 6a+.

  Not sure how many of these are "known bugs".

  JJM


tkt_uuid: 694534ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Works For Me
title: Error in makefile.vc (typo?)
comment:
  These lines:

  !if "$(OS)" == "Windows_NT"  || "$(MSVCDIR)" 
  == "IDE"
  $(TKTEST) $(ROOT)/tests/all.tcl 
  $(TESTFLAGS) | $(CAT32)
  !else
  $(TKTEST) $(ROOT)/tests/all.tcl 
  $(TESTFLAGS) | $(CAT32)
  !endif

  Should read like this instead (notice the use of 
  backslashes instead of slashes):

  !if "$(OS)" == "Windows_NT"  || "$(MSVCDIR)" 
  == "IDE"
  $(TKTEST) $(ROOT)\tests\all.tcl 
  $(TESTFLAGS) | $(CAT32)
  !else
  $(TKTEST) $(ROOT)\tests\all.tcl 
  $(TESTFLAGS) | $(CAT32)
  !endif

  The tests will NOT run at all when slashes are used 
  (at least in my environment).

  JJM


tkt_uuid: 697652ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 5 Medium
foundin: None
resolution: Fixed
title: toplevel/frame can't take empty -colormap or -use
comment:
  I think you should be able to do:

  toplevel .t -colormap ""

  seeing as [. cget -colormap] returns an empty string.

  Similarly:

  toplevel .t -use ""

  should not cause an error.


tkt_uuid: 697915ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: Tk_MainWindow error ?
comment:
  If I try to start a C application which makes use of
  Tk, and
  DISPLAY is not set, tk/generic/tkWindow.c's
  Tk_MainWindow() routine appears to output this message:
  this isn't a Tk applicationcouldn't connect to display ":0"


  There appears to be a missing newline - and it might
  not hurt to capitalize "this" and "couldn't" .

  I just saw this in Tk 8.4.2 - but I suspect it has been
  there for quite some time.


tkt_uuid: 698571ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: image create failure when mem low
comment:
  [image create photo -file {whaterverfile} ] fails when not 
  enough memory is available. 




  Fe if a whole range of images (+150 1080x1420 images) 


  is already loaded.




  On W32 it shows "Unable to alloc xxxx bytes" and the 
  tcl/tk app shuts down. On Linux it tends to coredump.




  It would be nice to get a error back from Tk so that I can 
  display a warning myself and safely exit my program.


tkt_uuid: 699022ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: None
resolution: Fixed
title: invalid handle issues
comment:
  attached is a patch to resolve invalid handle problems 
  that are usually not noticed (no exceptions raised), but 
  tools such as NuMega's BoundsChecker can catch.


tkt_uuid: 700305ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: OS X Aqua: Entry controls get drawn in incorrect places
comment:
  This bug appears to occur only in the MacOS X Aqua Wish
  Shell.app.

  In the below example code, the entry widget gets drawn
  in the upper-left corner of the toplevel dialog,
  overlapping the label that it should be beside.

  If you click on where the entry widget is drawn,
  nothing happens.  If you click on where the entry
  widget is SUPPOSED to be, it takes focus as expected.

  Below is the shortest code I could get to reproduce the
  bug.  If you uncomment the 'update idletasks', the bug
  goes away.  It seems to only happen in a separately
  created (non-.) toplevel.  If I remove the selection
  command, the bug goes away.  The bug does not seem to
  happen with pack.

  Here's the code:

      toplevel .tl
      label .tl.l -text Label
      entry .tl.e
      grid .tl.l .tl.e
      # update idletasks
      .tl.e selection range 0 end


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: 700311ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: None
title: OS X Aqua: Command-key bindings don\'t seem to work.
comment:
  Bindings to <Alt-Key-n>, <Alt-Key-o>, <Alt-Key-a>, etc.
  (Which should match Command-N, Command-O, Command-A,
  etc.) don't seem to be triggering at all in my widgets
  under Aqua Tk.

  The following code demonstrates this for Command-A:

  entry .e
  pack .e
  bind .e <Alt-Key-a> ".e delete 0 end ; .e insert end
  Command-A!"


tkt_uuid: 700316ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Fixed
title: OS X Aqua: Preferences menu item disabled in app menu
comment:
  Even if you provide the appropriate
  ::tk::mac::ShowPreferences procedure for handling
  preferences, the 'Preferences...' menu item in the
  application menu will not be enabled unless you have an

          EnableMenuCommand(NULL, kHICommandPreferences);

  call in your Tk interpreter.

  This should probably only be called if the
  ::tk::mac::ShowPreferences proc is defined.


tkt_uuid: 700317ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: OS X Aqua: Tk forces quit despite exit handler procedure
comment:
  If the 'exit' command is replaced by a proc, (ie: via
  rename) and that procedure pauses for the results of a
  dialog, the Tk interpreter should NOT force the
  application exit via Tcl_Exit(0) as it does now.

  The Quit command is a request to quit, not an
  imperative.  There may be unsaved files to save,
  confirmation dialogs, etc. that need the user's attention.


tkt_uuid: 700323ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: None
title: OS X Aqua: event generate fails to trigger key bindings
comment:
  The 'event generate' command seems to not be triggering
  bindings on the target widget.  For example, with the
  following code, typing 'a' in the first entry wiget
  should cause a <key-b> event to insert a b into the
  second entry widget:

  entry .e1
  entry .e2
  pack .e1
  pack .e2
  bind .e1 <Key-a> "event generate .e2 <Key-b> ; break"


tkt_uuid: 700993ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 50. [pack]
priority: 4
foundin: None
resolution: Out of Date
title: Pack may fail to show a button in aqua Tk 8.4.1
comment:
  The following scrip demonstrates a problem first reported by "Larry" on the MacPython mailing list. He said the bug did not appear on Windows but did appear on MacOS X.

  The problem is that the box brought up when you press the Demo button does not show the "OK" button until you click in the resize box. (Again, only on MacOS X, and at least in my case, only when using aqua Tk).

  The script shown is a simple a version as I could make. I also tried some variants which did NOT reliably show the problem:
  - Simply painting the dialog box (instead of pressing a button to bring it up) works fine (the OK button is shown).
  - Using after to paint the dialog box 50 ms later (instead of making the user push a button) is a weird borderline case; sometimes the button is not shown at first, but as soon I click on the dialog to bring it to the front then the OK button appears.

  In any case, this script reproduces the bug completely reliably on MacOS X 10.2.3 (at least) and in aqua Tk 8.4.1:


  button .demo -text "Demo" -command {
  toplevel .dlg
  label .dlg.txt -text "No OK button?\nClick in resize (lower right) to see it."
  pack .dlg.txt
  button .dlg.but -text "OK" -command { destroy .msgdlg }
  pack .dlg.but
  }
  pack .demo


tkt_uuid: 701726ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Borland patches for Tk
comment:
  Hi there,
  I just got the latest sources from SF and with the
  patches applied Tk builds fine. The patches itself are
  really minimal - the diff file is rather long because
  it contains my newest makefile.bc.
  I should maybe add that the identical patches worked
  with T8.4, too, so a 'back-porting' shouldn't be any
  problem.
  Best regards
  Helmut Giese


tkt_uuid: 701812ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: Message box buttons too wide
comment:
  It's been reported to me that buttons in the tk_messageBox on Unix/X are too wide with 8.4.2 when the 
  text inside the message-box is large.  I've investigated, and I find that this is due to an unneeded -weight 
  1 in the line that configures the grid columns containing the buttons.

  Note 1: Check whether (when the -weight 1 is removed) the -padx of the buttons needs to be boosted.  
  This seems to be the case on Windows, but button size handling varies slightly across platforms.

  Note 2: Check whether this problem is there in other standard dialogs.

  Note 3: Make sure this change goes into the 8.4 branch too!


tkt_uuid: 701927ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: None
title: extremely long, fat lines not displayed
comment:
  Tk user reports:

  > extremely long
  > lines still don't render if their width is bigger
  than 1.  For example:
  > 
  >    canvas .c -width 100 -height 100 -bg white
  >    pack .c
  >    set xbig [expr {pow(2,31)-3}]
  >    .c create line 0 30 $xbig 30 -fill red -width 1
  >    .c create line 0 50 $xbig 50 -fill blue -width 2
  > 
  > The second line isn't visible.

  Problem exists in both 8.4.2 and 8.4.1 on Win2K,
  and in 8.3.4 on Linux/Alpha.

  This is not a duplicate of 663981 or 630171.

  Might be related to Tk Bug 559792 ?


tkt_uuid: 701931ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 7 High
foundin: obsolete: 8.4.2
resolution: Fixed
title: listbox.test drifts off screen; causes failures
comment:
  The test spinbox-5.7 now fails for the Tk HEAD,
  but not on the core-8-4-branch.

  ==== spinbox-5.7 ConfigureSpinbox procedure FAILED
  ==== Contents of test case:

      catch {destroy .e}
      spinbox .e -font $fixed -width 4 -xscrollcommand scroll
      pack .e
      .e insert end "01234567890"
      update
      .e configure -width 5
      set scrollInfo

  ---- Result was:
  0.315789 0.842105
  ---- Result should have been (exact matching):
  0 0.363636
  ==== spinbox-5.7 FAILED

  This is on Linux/Alpha/GNOME.

  Failure (as well as 2 other spinbox test failures)
  seems to only happen during a full `make test`.
  Testing just the spinbox.test file all tests pass.

  Anything in the big geometry manager commit
  that could have caused this?


tkt_uuid: 702230ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 9 Immediate
foundin: obsolete: 8.4.2
resolution: Fixed
title: Another panewindow/visual related problem
comment:
  I had the original visual related problem where if I 
  created a panewindow within a frame which had a 
  truecolor visual, but the root window had a visual of 
  psuedocolor, I would crash.

  This was fixed in 8.4.2 - Thanks - I can now create the 
  window.

  But.... If I use left mouse to adjust the size of the 
  panes, we are back to what appears to be a visual 
  related crash when trying to draw the "proxy" line.

  Using the middle mouse to adjust the panes on the fly 
  worked great. I attempted to locate the problem, and 
  followed it fairly deep, but a time crunch resulted in a 
  hack of just changing my binds to avoid use of the 
  proxy.

  I've attached a short example to demonstrate the 
  problem. You'll need to run on a Xserver with a default 
  root window which uses the psuedocolor visual (All of 
  our SGI and SUN systems do).

  The example should fail at start time for 8.4.1, but not 
  fail until the panes are adjusted with the left mouse 
  under 8.4.2.

  Thanks for your time.


tkt_uuid: 703090ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 86. Test Tools
priority: 5 Medium
foundin: None
resolution: Works For Me
title: multiple segmentation errors and failures
comment:
  Tcl/Tk 8.4.2
  Solaris 8 [SPARC]
  gcc 3.2.2

  8.4.1. currently installed

  tcl8.4.2 makes without errors amd make tests produces
  no errors [failures from 8.4.1 fixed]

  However although tk8.4.2 makes without errors make test
  fails spectacularly

  bind.test
  Segmentation Fault - core dumped

  panedwindow.test
  Segmentation Fault - core dumped

  textDisp.test
  Segmentation Fault - core dumped


  Tests ended at Wed Mar 12 21:35:36 GMT 2003
  all.tcl:        Total   7107    Passed  6281    Skipped
  800     Failed  26
  Sourced 174 Test Files.
  Files with failing tests: canvRect.test canvText.test
  canvas.test entry.test image.test listbox

  If I remake the 8.4.1 versions the tests behave as
  before so I dont think anything significant has chaned
  on our build system.

  Any suggestions?

  ps this is user ignorance but how is the verion detemined ?

  /usr/local/src/tcl_tk/tcl8.4.2/unix/tclsh
  % info patchlevel
  8.4.1

  iain.morrison@mrc-cbu.cam.ac.uk


tkt_uuid: 703697ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 82. X11 Emulation
priority: 3 Low
foundin: obsolete: 8.4.2
resolution: Fixed
title: Wrong init in XGetImage W32
comment:
  Hi I noticed folowing initializers in XGetimage




  infoPtr->bmiHeader.biCompression = BI_RGB;


  infoPtr->bmiHeader.biCompression = 0;




  This should actually be :




  infoPtr->bmiHeader.biCompression = BI_RGB;     
  infoPtr->bmiHeader.biSizeImage = 0;




  Luckily BI_RBG has the value 0, but you never know if 
  this behaveour changes through compiler versions.


tkt_uuid: 703787ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: Tk 8.4.2 test on Solaris 7 unauthorizes DISPLAY :0.0
comment:
  Running on Solaris 7, using GCC 3.2.1 and Tcl/Tk 8.4.2,
  I can run quite a lot of tests, but then the DISPLAY is
  disabled so that neither Tk testing nor other
  applications (eg Netscape) can connect any more:


  tk.test
  unixButton.test
  unixEmbed.test
  Error in startup script: unexpected EOF from
  "/work4/open.source/Tcl/tk8.4.2/unix/tktest"
      while executing
  "error "unexpected EOF from \"[interpreter]\"""
      (procedure "setupbg" line 10)
      invoked from within
  "setupbg"
      (file
  "/work4/open.source/Tcl/tk8.4.2/tests/unixEmbed.test"
  line 18)
      invoked from within
  "::source
  /work4/open.source/Tcl/tk8.4.2/tests/unixEmbed.test"
      ("uplevel" body line 1)
      invoked from within
  "uplevel 1 [list ::source $file]"
      (procedure "tcltest::runAllTests" line 57)
      invoked from within
  "tcltest::runAllTests"
      (file
  "/work4/open.source/Tcl/tk8.4.2/unix/../tests/all.tcl"
  line 19)
  make: *** [test] Error 1


  ...let's try again...


  Anubis JL: make test
  TCL_LIBRARY=/work4/open.source/Tcl/tcl8.4.2/library;
  export TCL_LIBRARY; \
  TK_LIBRARY=/work4/open.source/Tcl/tk8.4.2/library;
  export TK_LIBRARY; \
  ./tktest
  /work4/open.source/Tcl/tk8.4.2/unix/../tests/all.tcl
  -geometry +0+0 \
   
  Xlib: connection to ":0.0" refused by server
  Xlib: Client is not authorized to connect to Server
  Application initialization failed: this isn't a Tk
  applicationcouldn't connect to display ":0.0"
  Tests running in interp: 
  /work4/open.source/Tcl/tk8.4.2/unix/tktest
  Tests located in:  /work4/open.source/Tcl/tk8.4.2/tests
  Tests running in:  /work4/open.source/Tcl/tk8.4.2/unix
  Temporary files stored in
  /work4/open.source/Tcl/tk8.4.2/unix
  Test files sourced into current interpreter
  ...

  I have to logout to get things back to normal again! 
  There's one minor failure earlier:

  listbox.test

  ==== listbox-13.3 ListboxScanTo procedure FAILED
  ==== Contents of test case:

      .l yview moveto 1.0
      .l xview moveto 1.0
      .l scan mark 10 20
      .l scan dragto 5 10
      update
      set x [list [.l xview] [.l yview]]
      .l scan dragto [expr 5+$width] [expr 10+$height]
      update
      lappend x [.l xview] [.l yview]

  ---- Result was:
  {0.8 1} {0.75 1} {0.64 0.84} {0.25 0.5}
  ---- Result should have been (exact matching):
  {0.8 1} {0.75 1} {0.62 0.82} {0.25 0.5}
  ==== listbox-13.3 FAILED

  macEmbed.test


tkt_uuid: 704212ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 55. [focus]
priority: 8
foundin: obsolete: 8.4.2
resolution: None
title: [focus] dumps core with certain extensions
comment:
  The [focus] command will dump core if the target window
  is a widget
  with certain unusual characteristics. If the target
  window is the top
  of a window hierarchy but is NOT a toplevel with a
  wrapper window,
  it will core dump. To demonstrate the problem, get the
  "rootwin"
  widget extension (which makes the X display's root
  window into
  a Tk widget):

   
  http://www.eecs.umich.edu/~mckay/computer/rootwin0.4.tar.gz

  Then do the following:

    load /path/to/libRootwin0.4.so
    rootwin .r
    focus -force .r

  The problem is in tkFocus.c; I fixed it, and the diff
  looks like:


  diff tkFocus.c.orig tkFocus.c
  565c565
  <     TkWindow *topLevelPtr;
  ---
  >     TkWindow *topLevelPtr, *focusToplevelPtr;
  667c667,671
  <       serial =
  TkpChangeFocus(TkpGetWrapperWindow(topLevelPtr), force);
  ---
  >       focusToplevelPtr =
  TkpGetWrapperWindow(topLevelPtr);
  >       if (focusToplevelPtr == NULL) {
  >           focusToplevelPtr = topLevelPtr;
  >       }
  >       serial = TkpChangeFocus(focusToplevelPtr, force);

  NOTE: there's a bad line break in the diff, but you can
  see that
  the fix is simple. Address questions to:

    mckay at eecs dot umich dot edu


tkt_uuid: 705567ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: unixWm.test failed
comment:
  after configuring tk 8.5 with enable 64 bit on a sparc
  solaris 8 system and sun's c compiler, I did a make all
  and then a make test.
  The test suite halted early with this error:
  unixWm.test
  Error in startup script: wrong # args: should be "test
  name desc ?options?"
      while executing
  "test unixWm-41.2 {ConfigureEvent procedure, menubars}
  {nonPortable testmenubar}
   unix {
      catch {destroy .t}
      toplevel .t -width 300 -height 200 -..."
      (file "/vol/tclsrcsol/tcl85/tk/tests/unixWm.test"
  line 1368)
      invoked from within
  "::source /vol/tclsrcsol/tcl85/tk/tests/unixWm.test"
      ("uplevel" body line 1)
      invoked from within
  "uplevel 1 [list ::source $file]"
      (procedure "tcltest::runAllTests" line 57)
      invoked from within
  "tcltest::runAllTests"
      (file
  "/vol/tclsrcsol/tcl85/tk/unix/../tests/all.tcl" line 19)
  *** Error code 1
  make: Fatal error: Command failed for target `test'


tkt_uuid: 705787ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: "winfo server ." crashes Mac Acqua Tcl
comment:
  I am running Tcl/Tk 8.4.2 built from the standard
  source distribution, following the README instructions
  in Tk's macosx directory.

  Typing "winfo server ." causes a segmentation violation
  with wish (running under Acqua).


tkt_uuid: 706411ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 7 High
foundin: obsolete: 8.4.2
resolution: Works For Me
title: text selection in a text widget significantly slower
comment:
  Tk applications which make use of text in text widgets
  are exhibiting significant slowdown in the text
  selection action under 8.4.2 as compared to 8.3.

  Behavior is being reported in cases where the
  application runs on solaris and displays on either
  solaris or back to a Windows machine (XP in at least
  one report) via Exceed's X software.

  The simplest example can be seen by:
    text .t
     pack .t

     Then typed some text into the widget and did a
  Button-1 drag
  selection with the mouse.  Wish 8.3 was as fast as ever in
  forming/altering the selection, with a speed comparable
  to highlighting
  text in MDE or an xterm.  But with 8.4, dragging the
  cursor alters the
  selection at a rate of about 1 character per second,
  which is incredibly
  slow. 


tkt_uuid: 706446ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 6
foundin: obsolete: 8.4.2
resolution: Fixed
title: active button not drawn correctly
comment:
  If a button is configured to the disabled state and then 
  reconfigured to the active state, it still look like a disabled button, 
  even though you can press the button:

  pack [button .b -state disabled]

  .b configure -state active

  Kish Shen
  Imperial College London
  U.K.
  K.Shen@icparc.ic.ac.uk


tkt_uuid: 706765ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 7 High
foundin: obsolete: 8.4.2
resolution: Fixed
title: -sliderrelief not honored
comment:
  the sliderelief option is always returned to the raised 
  appearance after being clicked regardless of the 
  prevsion configuration

  pack [scale -sliderrelief flat]

  observe the appearance of the slider before and after 
  clicking on the scale.


tkt_uuid: 707102ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: None
title: exec rsh doens't work under wish but does under tclsh
comment:
  The following command hangs under wish but not tclsh:

  puts [exec rsh hostname /bin/ls / < /dev/null ]

  This with 8.4.2.


tkt_uuid: 707778ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: None
title: canvas/scrollbar/text return wrong configure synonym info
comment:
  Most widgets return configure information with synonyms
  pointing to the associated configure option switch. The
  canvas, scrollbar and text widgets return synonyms
  pointing to the database name. e.g.

  % button .b
  .b
  % join [lsort [.b configure]] \n
  ...
  -background background Background #d9d9d9 #d9d9d9
  -bd -borderwidth
  -bg -background
  -bitmap bitmap Bitmap {} {}
  -borderwidth borderWidth BorderWidth 2 2
  ...
  -fg -foreground
  -foreground foreground Foreground Black Black
  ...

  (Note how -bg maps to -background and -bd to -borderwidth)

  % text .t
  .t
  % join [lsort [.t configure]] \n
  ...
  -background background Background #d9d9d9 #d9d9d9
  -bd borderWidth
  -bg background
  -borderwidth borderWidth BorderWidth 2 2
  ...
  -fg foreground
  -foreground foreground Foreground Black Black
  ...

  (Here -bg maps to background and -bd to borderWidth}

  In 8.3.5, the frame, message and toplevel widgets also
  suffered from this bug, but appear fixed in 8.4.


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: 708375ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Works For Me
title: windows2000 background colors
comment:
  I install tcl/tk8.4 in windows2000 and the colors for
  background buttons, menus and windows are white! I try
  all the samples. The same tcl/tk8.4 works fine in
  windows98.
  What can I do?

  thanks
  Marcelo Modolo


tkt_uuid: 709970ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 8
foundin: obsolete: 8.4.2
resolution: None
title: problems when make test
comment:
  E-mail : morel@ig-edu.univ-paris13.fr

  OS : Solaris8  host : sparc Ultra5
  tcl : 8.4.2
  tk  : 8.4.2

  bind.test

  ==== bind-22.10 HandleEventGenerate FAILED
  ==== Contents of test case:

      setup
      bind .b.f <Key> {set x "%s %K"}
      set x {}
      event gen .b.f <Control-Key-1>
      set x

  ---- Result was:
  5 1
  ---- Result should have been (exact matching):
  4 1
  ==== bind-22.10 FAILED

  focus.test

  ==== focus-5.1 ChangeXFocus procedure, don't take focus
  unless have it FAILED
  ==== Contents of test case:

      focusSetup
      focus -force .t
      update
      set result [focus]
      send [dobg {tk appname}] {focus -force .; update}
      lappend result [focus]
      focus .t.b2
      update
      lappend result [focus]

  ---- Result was:
  .t .t {}
  ---- Result should have been (exact matching):
  .t {} {}
  ==== focus-5.1 FAILED


  ==== focus-6.2 miscellaneous - embedded application in
  different process FAILED
  ==== Contents of test case:

      eval interp delete [interp slaves]
      catch {destroy .t}
      setupbg
      toplevel .t
      wm geometry .t +0+0
      frame .t.f1 -container 1
      frame .t.f2
      pack .t.f1 .t.f2
      entry .t.f2.e1 -bg red
      pack .t.f2.e1
      bind all <FocusIn> {lappend x "focus in %W %d"}
      bind all <FocusOut> {lappend x "focus out %W %d"}
      setupbg -use [winfo id .t.f1]
      dobg {
          entry .e1 -bg lightBlue
          pack .e1
          bind all <FocusIn> {lappend x "focus in %W %d"}
          bind all <FocusOut> {lappend x "focus out %W
  %d"}
          set x {}
      }

      # Claim the focus and wait long enough for it to
  really arrive.

      focus -force .t.f2.e1
      after 300 {set timer 1}
      vwait timer
      set x {}
      lappend x [focus] [dobg focus]

      # See if a "focus" command will move the focus to
  the embedded
      # application.

      dobg {focus .e1}
      after 300 {set timer 1}
      vwait timer
      lappend x |
      dobg {lappend x |}

      # Bring the focus back to the main application.

      focus .t.f2.e1
      after 300 {set timer 1}
      vwait timer
      set result [list $x [dobg {set x}]]
      cleanupbg
      set result

  ---- Result was:
  {{} {} |} |
  ---- Result should have been (exact matching):
  {.t.f2.e1 {} {focus out .t.f2.e1 NotifyNonlinear}
  {focus out .t.f2 NotifyNonlinearVirtual} {focus in
  .t.f1 NotifyNonlinear} | {focus out .t.f1
  NotifyNonlinear} {focus in .t.f2
  NotifyNonlinearVirtual} {focus in .t.f2.e1
  NotifyNonlinear}} {{focus in . NotifyVirtual} {focus in
  .e1 NotifyAncestor} | {focus out .e1 NotifyAncestor}
  {focus out . NotifyVirtual}}
  ==== focus-6.2 FAILED

  ==== listbox-13.3 ListboxScanTo procedure FAILED
  ==== Contents of test case:

      .l yview moveto 1.0
      .l xview moveto 1.0
      .l scan mark 10 20
      .l scan dragto 5 10
      update
      set x [list [.l xview] [.l yview]]
      .l scan dragto [expr 5+$width] [expr 10+$height]
      update
      lappend x [.l xview] [.l yview]

  ---- Result was:
  {0.8 1} {0.75 1} {0.64 0.84} {0.25 0.5}
  ---- Result should have been (exact matching):
  {0.8 1} {0.75 1} {0.62 0.82} {0.25 0.5}
  ==== listbox-13.3 FAILED

  window.test : never finish, I must type Ctrl C to stop


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: 714385ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: Rejected
title: Attempting to compile scid; see below
comment:
  Running Scid, I get the following error while trying to switch focus to the application:

  "SetFrontProcess failed,-606"

  Moreover, there is no icon in the dock; Also, I have to "kill -9 tkscid" to quit the program.

  Here is how I went about compiling it:

  A) Get tarball from scid homepage http://scid.sourceforge.net
  B) Run ./configure unsuccesfully
  C) Change lines in Makefile to read:

  TCL_INCLUDE = -I/Library/Frameworks/Tcl.Framework/Headers -I/Library/Frameworks/Tk.Framework/Headers

  TCL_LIBRARY = -framework Tcl

  TK_LIBRARY = $(TCL_LIBRARY) -framework Tk

  D) make
  E) ./scid

  I appreciate any assistance you can give me fixing this :-) 
  rickbischoff@mac.com


tkt_uuid: 714956ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 7 High
foundin: obsolete: 8.5a0
resolution: Fixed
title: window-2.9 hangs when threads enabled
comment:
  With a --enable-threads build of Tcl,
  running `make test` for Tk leads to
  test window-2.9 hanging.

  Solaris 8, using a Forte compiler.


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: 720350ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Works For Me
title: Memory leak or ? in canvas, WinXP Home
comment:
  ActiveState ActiveTcl 8.4.2 (fresh install, also seen
  with previous version, 8.4.0.1?)
  WinXP Home, ver 2002, sp1
  Mobile Athlon XP 1500+, 1.33 GHz
  240 MB Ram

  Taking the Colliding Balls script from the wiki, 

  http://wiki.tcl.tk/8573

  I appended the following code to add and delete balls
  on button presses:

  # Maximum ball number
  set State(ballCount) [llength $State(ballList)]

  # Create a new ball on right-click
  bind $State(canvas) <Button-3> {
  incr State(ballCount)
  set ball ball$State(ballCount)
  createBall $ball
  lappend State(ballList) $ball
  }

  # Delete the closest ball on left-click
  bind $State(canvas) <Button-1> {
  set id [$State(canvas) find closest %x %y]
  set ball [lindex [$State(canvas) gettags $id] 0]
  set idx [lsearch $State(ballList) $ball]
  if { $idx >= 0 } {
  set State(ballList) \
                        [lreplace $State(ballList) $idx $idx]
  $State(canvas) delete $id
  }
  }

  I also added the following to the end of proc moveBalls
  { } :

  # Remove slow balls
       foreach ball $State(ballList) {
           foreach {xvel yvel} $State(vel,$ball) {}
           set vel [expr {sqrt( $xvel*$xvel + $yvel*$yvel )}]
           if {$vel < 0.5} {
               set id [$State(canvas) find withtag $ball]
               set idx [lsearch $State(ballList) $ball]
               set State(ballList) [lreplace
  $State(ballList) $idx $idx]
               $State(canvas) delete $id
           }
       }


  After a while of creating balls and letting the slow
  ones be removed, the canvas froze and the wish84
  application shows 99% CPU utilization and progressively
  increasing mem usage until ~150MB then drops to between
  ~20-40 MB (fluctuating) while the commit charge
  continues to increase.  Eventually a "Fatal Error in
  Wish" box pops up stating "unable to alloc n bytes"
  (where in my case n was ~100660000 first, 2400 second).  
  The windows error the first time showed:

  AppName: wish.exe AppVer: 8.4.2.2 ModName: ntdll.dll
  ModVer: 5.1.2600.1106 Offset: 000267cd

  appcompat.txt attached


tkt_uuid: 721030ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Invalid
title: memory leak caused by color usage
comment:
  set ::id ""
  proc incrLineColor {win i} {
    $win delete $::id
    set col [format {%12.12x} $i]
    set ::id [$win create rect 0 4 200 200 -fill "#$col"]
    incr i 
    after 1 [list incrLineColor $win $i]
  }
  proc main {} {
    pack [canvas .c]; tk appname SEEME; update
    incrLineColor .c 1
  }
  main

  This code causes a memory leak.  It doesn't help if
  delete all is used, or a specified tag is used instead.
   If a -fill color is used that is the same throughout
  the loop, such as "red" or "#FF0000" then the leak
  isn't noticable.  

  When drawing gradients the Tk canvas is unusable,
  because it uses far too much memory, despite the lines
  of the gradient being deleted before each redraw on
  <Configure>.  As the number of redraws on <Configure>
  increases, so too does the memory usage.

  I've tested this with Tcl/Tk 8.0.5 and 8.4.1 in Windows
  XP.  I also asked Arjen Markus to help test some
  similar code.  He reported that it leaked on a Solaris
  system, and in XP using 8.4.1.


tkt_uuid: 721514ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: tk:tkWinMenuKey is redundant name
comment:
  A recent commit to the HEAD revised
  Win menu bindings to bind to a new
  private command exposed at the
  script level by the name tk::tkWinMenuKey.

  This is a very good change, placing more
  configurability at the script level.  Good work.

  My only quibble is that the string "tk" doesn't
  need to be in the command name twice.

  How about tk::WinMenuKey ?

  That alternative would also follow Style
  Guide conventions for private command
  names.


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: 723856ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: cannot use menu names with spaces
comment:
  Consider the following code:

    set W {.menu test}
    toplevel $W
    set menu "$W.menu"
    menu $menu -relief flat -bd 0
    $W configure -menu $menu
    $menu add cascade -label File -underline 0 -menu
  $menu.file
    menu $menu.file
    $menu.file add command -label Exit -command exit

  Note that if there is a space anywhere in the menu
  name, it causes the following error when posting the menu:

  invalid command name ".menu"
      while executing
  ".menu test.#menu test#menu.#menu test#menu#file post
  593 57"
      invoked from within
  "$menu postcascade active"
      (procedure "tk::MenuMotion" line 15)
      invoked from within
  "tk::MenuMotion .menu\ test.#menu\ test#menu 18 17 256"
      (command bound to event)

  I *believe* that the problem is in the use of
  Tcl_VarEval in line 1001 of tk8.4.2/generic/tkMenuDraw.c :

  result = Tcl_VarEval(interp, name, " post ", string,
  (char *) NULL);

  which does not account for spaces. I totally hacked the
  following replacement line:

  result = Tcl_VarEval(interp, "{", name, "} post ",
  string, (char *) NULL);

  which fixes the problem, but I'm sure there's a proper
  way to do this. Line 978 also suffers from this problem
  ("unpost"), and I expect there may be other places too.

  What's the correct way to fix this? (I'm trying to
  learn more C) Thanks!


tkt_uuid: 725941ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 7 High
foundin: obsolete: 8.5a4
resolution: Fixed
title: [puts] called from a thread on win doesn't go to the console
comment:
  % package require Thread
  2.5
  (bin) 5 % set t [thread::create {thread::wait}]
  756
  (bin) 6 % thread::send $t {puts "hi there"}
  can not find channel named "stdout"
  (bin) 7 % 


tkt_uuid: 726351ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: None
title: Toplevel menu doesn't request height.
comment:
  Has been observed with Linux + KDE and Linux + 
  WindowMaker.

  [code]
  global var lbvar
  set lbvar 
  {}
  listbox .lstbx -height 20 -listvar lbvar
  for {set z 0} {$z < 19} 
  {incr z} {lappend lbvar $z}
  lappend lbvar "Try to make me 
  smaller"
  pack .lstbx

  if {$argc} {
   menu .foo
   .foo 
  add cascade -label "Bar" -menu .bar
   menu .bar -type normal -
  tearoff 0
   .bar add command -label "Barian" -command {}
   . 
  configure -menu .foo
  }

  update

  wm minsize . 
  [winfo reqwidth .] [winfo reqheight .]
  [/code]


tkt_uuid: 726861ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Duplicate
title: tk_getOpenFile ignores extension/fork choice
comment:
  tk_getOpenFile dialogue lists all files regardless of filename 
  extension and/or resource fork data specified for the 
  selected filetype 
   
  This can be seen with the example code in the doc page for 
  Tk_getOpenFile 
   
  I'm using TclTkAqua BI 8.4.2 


tkt_uuid: 728952ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 9 Immediate
foundin: obsolete: 8.4.2
resolution: Fixed
title: Missing documentation on formats
comment:
  The man pages do not appear to document that a valid
  photo format is a list of lists containing RGB values
  in the form #RRGGBB. The only reference I could even
  find to #RRGGBB was in the GetColor manpage, but
  nothing about the list format.


tkt_uuid: 730124ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Fixed
title: build fails
comment:
  Building from CVS for Mac OS X fails with the following error.

  tkMacOSXButton.c:486: structure has no member named 
  `stippledGC'

  Maybe it's a simple typo. Changing this to 'stippleGC' fixes the 
  problem and build goes well.


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: 733581ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: XSetSelectionOwner called with CurrentTime
comment:
  Hello, 
   
  This is a bug report for tk-8.3.4.  According to the
  Inter-client 
  communication conventions manual (ICCCM, version 2.0), 
   
    The timestamp passed to XSetSelectionOwner must come
  from an event received from the X server. 
   
  Violating this rule could cause race conditions.  The
  routine Tk_OwnSelection (from generic/TkSelect.c)
  violates that rule: 
  it passes CurrentTime, instead. 

  Submitted by Glenn Ammons (ammons@cs.wisc.edu).

  --glenn


tkt_uuid: 733603ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: None
resolution: Invalid
title: XGetSelectionOwner bug in wish8.3
comment:
  This is a bug report for wish8.3.  According to the
  Inter-client  
  communication conventions manual (ICCCM, version 2.0),  
    
    After calling \code{XSetSelectionOwner}, selection
  ownership must be verified by calling
  \code{XGetSelectionOwner}. 
    
  Violating this rule could cause the user to be misled
  about which 
  window owns the selection.  The routine Tk_OwnSelection
  (from generic/tkSelect.c) violates the rule: 
  it doesn't call XGetSelectionOwner. 
   
  Submitted by Glenn Ammons (ammons@cs.wisc.edu).


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: 734361ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: None
resolution: Duplicate
title: crash in PolygonToPostscript with 2 identical points
comment:
  Forwarded bug report from Debian Project, submitted
  (with patch) by  Andreas Wilm
  <wilm@rubin.biophys.uni-duesseldorf.de> (for original
  report, see http://bugs.debian.org/192302):

  "Create a polygon with two identical points and no
  outline color (I know this seems to be nonsense, but in
  my case it was absolutely needed). Do a postscript
  command on the canvas and you get the core dump (a
  color NULL pointer is passed on from
  PolygonToPostscript to Tk_PostscriptColor, where it is
  referenced)."

  To reproduce:

  % canvas .c
  % pack .c
  % .c create polygon 10 20 10 20
  % .c postscript

  Debian maintainer comments: I can reproduce the crash
  on 8.3.5 and 8.4.2. I haven't tested the patch, but it
  looks straightforward enough.  The scenario may seem
  odd, but it's the kind of thing that could easily arise
  programatically, i,.e., graphing some data that
  includes some degenerate cases.  Arguably a minor
  problem, but it should not segfault!


tkt_uuid: 734498ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: canvas postscript command core dumps on special polygon
comment:
  Hi,

  there is a bug in tkCanvPoly.c:PolygonToPostscript in 
  recent Tk Versions (tested 8.3.5, 8.4.2).


  Create a polygon with two identical points and no
  outline color (I know this seems to be nonsense,
  but in my case it was absolutely needed).
  Do a postscript command on the canvas and you get the
  core dump (a color
  NULL pointer is passed on from PolygonToPostscript to
  Tk_PostscriptColor, where it is referenced)


  15:09[wilm@rubin:ConStruct3]$ wish
  .wishrc .wishrc .wishrc ...
  % canvas .c
  .c
  % pack .c
  % .c create polygon 10 20 10 20
  1
  % .c postscript
  Segmentation fault




  Setting the outline sets the color pointer to non-NULL:

  15:41[wilm@rubin:ConStruct3]$  wish
  .wishrc .wishrc .wishrc ...
  %  canvas .c
  .c
  % pack .c
  % .c create polygon 10 20 10 20 -outline black
  1
  % .c postscript
  %!PS-Adobe-3.0 EPSF-3.0
  ...



  To avoid this create a polygon with 3 points (using two
  different points
  activates expansion to three points and cirumvents the
  faulty if-clause as well):

  16:04[wilm@rubin:ConStruct3]$ wish
  .wishrc .wishrc .wishrc ...
  % canvas .c
  .c
  % pack .c
  % .c create polygon 10 20 10 20 10 20 
  1
  % .c postscript
  %!PS-Adobe-3.0 EPSF-3.0
  ...



  To patch this just check if color==NULL in case
  polyPtr->numPoints==2 and return TCL_OK
  See attachment.

  Andreas Wilm


tkt_uuid: 734625ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: Output the contents of a text widget to a (PostScript) file
comment:
  Just like the canvas widget the text widget should be
  able to output its contents to an external text file,
  such as a PostScript file or maybe an HTML file. 


tkt_uuid: 736371ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: None
title: _XInitImageFuncPtrs - undocumented function
comment:
  _XInitImageFuncPtrs is not documented, nor an official
  xlib function.

  This link points out the LSB discussion on whether to
  include this function:

  http://sourceforge.net/tracker/index.php?func=detail&aid=567489&group_id=1107&atid=101107

  It looks like it relates to running tcl on a machine of
  one endiannes, and  displaying it on a different
  endianness machine.  Before eliminating it, I suppose
  it would be wise to run some tests in these circumstances.

  Should the function itself prove necessary... since the
  endianness check in C is probably faster than doing a
  lookup on the Tcl variable, maybe Tcl should have a C
  interface to this test, which could be used in both
  places - here, as well as the place where the tcl
  variable is set.


tkt_uuid: 738143ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 9 Immediate
foundin: obsolete: 8.4.2
resolution: Fixed
title: Vertical paned window demo on Windows
comment:
  If I run the 'vertical paned window demo' all I can 
  see is the horizontal line of the control, which I can 
  click on and drag up and down by a couple of 
  pixels, but I can't actually see either the top or 
  bottom pane at all -- they seem to be of zero 
  height.

  This is on Windows 2000.


tkt_uuid: 739833ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: if S variable is set, mkLinks fails
comment:
  If S variable is set, mkLinks fails to cross link
  man-pages.

  Fix: Add following line to top of mkLinks script:

  S=""

  This problem is valid for both tcl and tk 8.4.2


tkt_uuid: 739954ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: textImage.test failures
comment:
  on the HEAD, tests textImage-1.2
  and textImage-1.14 fail, apparently
  due to a change in the error message
  text.


tkt_uuid: 739957ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: None
title: menuDraw-15.3 fails
comment:
  ==== menuDraw-15.3 TkPostTearoffMenu - post command FAILED
  ==== Contents of test case:

      catch {destroy .m1}
      catch {unset foo}
      menu .m1 -postcommand "set foo .m1"
      .m1 add command -label "foo"
      list [catch {tk::TearOffMenu .m1 40 40}] [set foo]
  [unset foo] [destroy .m1]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: can't read "foo": no such variable
      while executing
  "set foo"
      invoked from within
  "list [catch {tk::TearOffMenu .m1 40 40}] [set foo]
  [unset foo] [destroy .m1]"
      ("uplevel" body line 6)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== menuDraw-15.3 FAILED

  looks like event management is not robust.


tkt_uuid: 739965ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: numerous text test failures (TIP 113?)
comment:
  starting with today's HEAD (after TIP 113 commit)
  many (~40) tests begin to fail, all with the same
  "bad switch" error, for example:

  ==== text-20.2 TextSearchCmd procedure, -backwards
  option FAILED
  ==== Contents of test case:

      .t search -backwards xyz 1.4

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad switch "": must be --, -all,
  -backward, -count, -elide, -exact, -forward, -nocase,
  -nolinestop, or -regexp
      while executing
  ".t search -backwards xyz 1.4"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== text-20.2 FAILED

  looks like a bug in option parsing for [$text search] ?


tkt_uuid: 740558ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a0
resolution: Fixed
title: test failures
comment:
  text.test

  ==== text-20.3 TextSearchCmd procedure, -forwards
  option FAILED
  ==== Contents of test case:

      .t search -forwards xyz 1.4

  ---- Result was:
  1.1
  ---- Result should have been (exact matching):
  1.5
  ==== text-20.3 FAILED


  ==== text-20.36 TextSearchCmd procedure, regexp finds
  empty lines FAILED
  ==== Contents of test case:

      # Test for fix of bug #1643
      .t insert end "\n"
      tk::TextSetCursor .t 4.0
      .t search -forward -regexp {^$} insert end

  ---- Result was:

  ---- Result should have been (exact matching):
  4.0
  ==== text-20.36 FAILED


  ==== text-20.106 TextSearchCmd, multiline regexp
  matching FAILED
  ==== Contents of test case:

      # Practical example which crashes Tk, but only
  after the
      # search is complete.  This is memory corruption
  caused by
      # a bug in Tcl's handling of string objects.
      # (Tcl bug 635200)
      deleteWindows
      pack [text .t2]
      .t2 insert 1.0 {static int         
  SetFsPathFromAny _ANSI_ARGS_((Tcl_Interp *interp,
                              Tcl_Obj *objPtr));
  static Tcl_Obj*         FSNormalizeAbsolutePath 
                              _ANSI_ARGS_((Tcl_Interp*
  interp, Tcl_Obj *pathPtr));}
      set markExpr "^(\[A-Za-z0-9~_\]+\[
  \t\n\r\]*\\(|(\[^ \t\(#\n\r/@:\*\]\[^=\(\r\n\]*\[
  \t\]+\\*?)?"
      append markExpr
  "(\[A-Za-z0-9~_\]+(<\[^>\]*>)?(::)?(\[A-Za-z0-9~_\]+::)*\[-A-Za-z0-9~_+
  <>\|\\*/\]+|\[A-Za-z0-9~_\]+)"
      append markExpr "\[ \n\t\r\]*\\()"
      .t2 search -forwards -regexp $markExpr 1.41 end

  ---- Result was:
  1.0
  ---- Result should have been (exact matching):

  ==== text-20.106 FAILED


  Tests ended at Tue May 20 12:05:16 PM EDT 2003
  all.tcl:        Total   358     Passed  354     Skipped
  1       Failed  3
  Sourced 2 Test Files.
  Files with failing tests: text.test
  Number of tests skipped for each constraint:
          1       macOrPc
  Font Courier -12 still in cache.


tkt_uuid: 740565ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 5 Medium
foundin: None
resolution: None
title: focus.test failures
comment:
  platform: sparc solaris 8 sunblade 100, sun c compiler,
  2003-05-19 cvs head snapshot from activestate ftp site
  tcl compiled with enable-shared enable-symbols
  enable-threads
  tk compiled with enable-shared enable-symbols

  focus.test

  ==== focus-5.1 ChangeXFocus procedure, don't take focus
  unless have it FAILED
  ==== Contents of test case:

      focusSetup
      focus -force .t
      update
      set result [focus]
      send [dobg {tk appname}] {focus -force .; update}
      lappend result [focus]
      focus .t.b2
      update
      lappend result [focus]

  ---- Result was:
  .t .t {}
  ---- Result should have been (exact matching):
  .t {} {}
  ==== focus-5.1 FAILED

  ==== focus-6.2 miscellaneous - embedded application in
  different process FAILED
  ==== Contents of test case:

      eval interp delete [interp slaves]
      catch {destroy .t}
      setupbg
      toplevel .t
      wm geometry .t +0+0
      frame .t.f1 -container 1
      frame .t.f2
      pack .t.f1 .t.f2
      entry .t.f2.e1 -bg red
      pack .t.f2.e1
      bind all <FocusIn> {lappend x "focus in %W %d"}
      bind all <FocusOut> {lappend x "focus out %W %d"}
      setupbg -use [winfo id .t.f1]
      dobg {
          entry .e1 -bg lightBlue
          pack .e1
          bind all <FocusIn> {lappend x "focus in %W %d"}
          bind all <FocusOut> {lappend x "focus out %W %d"}
          set x {}
      }

      # Claim the focus and wait long enough for it to
  really arrive.

      focus -force .t.f2.e1
      after 300 {set timer 1}
      vwait timer
      set x {}
      lappend x [focus] [dobg focus]

      # See if a "focus" command will move the focus to
  the embedded
      # application.

      dobg {focus .e1}
      after 300 {set timer 1}
      vwait timer
      lappend x |
      dobg {lappend x |}

      # Bring the focus back to the main application.

      focus .t.f2.e1
      after 300 {set timer 1}
      vwait timer
      set result [list $x [dobg {set x}]]
      cleanupbg
      set result

  ---- Result was:
  {.t.f2.e1 {} {focus out .t.f2.e1 NotifyNonlinear}
  {focus out .t.f2 NotifyNonline
  arVirtual} {focus in .t.f1 NotifyNonlinear} {focus out
  .t.f1 NotifyAncestor} {fo
  cus out .t NotifyVirtual} |} {{focus in .
  NotifyVirtual} {focus in .e1 NotifyAnc
  estor} {focus out .e1 NotifyAncestor} {focus out .
  NotifyVirtual} {focus in . No
  tifyVirtual} {focus in .e1 NotifyAncestor} | {focus out
  .e1 NotifyAncestor} {foc
  us out . NotifyVirtual}}
  ---- Result should have been (exact matching):
  {.t.f2.e1 {} {focus out .t.f2.e1 NotifyNonlinear}
  {focus out .t.f2 NotifyNonline
  arVirtual} {focus in .t.f1 NotifyNonlinear} | {focus
  out .t.f1 NotifyNonlinear} 
  {focus in .t.f2 NotifyNonlinearVirtual} {focus in
  .t.f2.e1 NotifyNonlinear}} {{f
  ocus in . NotifyVirtual} {focus in .e1 NotifyAncestor}
  | {focus out .e1 NotifyAn
  cestor} {focus out . NotifyVirtual}}
  ==== focus-6.2 FAILED


tkt_uuid: 740568ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Duplicate
title: listbox.test failure
comment:
  platform: sparc solaris 8 sunblade 100
  compiler: sun c compiler
  source: 2003-05-19 cvs head from activestate ftp site
  tcl configured as --enable-shared --enable-symbols
  --enable-threads
  tk configured as --enable-shared --enable-symbols 

  make test results in

  listbox.test

  ==== listbox-13.3 ListboxScanTo procedure FAILED
  ==== Contents of test case:

      .l yview moveto 1.0
      .l xview moveto 1.0
      .l scan mark 10 20
      .l scan dragto 5 10
      update
      set x [list [.l xview] [.l yview]]
      .l scan dragto [expr 5+$width] [expr 10+$height]
      update
      lappend x [.l xview] [.l yview]

  ---- Result was:
  {0.8 1} {0.75 1} {0.64 0.84} {0.25 0.5}
  ---- Result should have been (exact matching):
  {0.8 1} {0.75 1} {0.62 0.82} {0.25 0.5}
  ==== listbox-13.3 FAILED


tkt_uuid: 740570ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 7 High
foundin: obsolete: 8.5a4
resolution: Duplicate
title: window-2.9 hang on unix with threads
comment:
  platform: sparc solaris 8 sunblade 100
  compiler: sun c compiler
  source: 2003-05-19 cvs head from activestate ftp site
  tcl configured as --enable-shared --enable-symbols
  --enable-threads
  tk configured as --enable-shared --enable-symbols

  window.test starts, but never ends.  when I do a truss,
  I see:
  $ truss -p 10320
  lwp_sema_wait(0x0002AD10)       (sleeping...)
  signotifywait()                 (sleeping...)
  door_return(0x00000000, 0, 0x00000000, 0) (sleeping...)
  poll(0xFEA0BA90, 1, -1)         (sleeping...)
  lwp_cond_wait(0xFECC5550, 0xFECC5560, 0xFECBEDB8)
  (sleeping...)

  If I kill the hanging process,
  I get this error:

  ==== window-2.9 Tk_DestroyWindow, Destroy bindings
          evaluated after exit FAILED
  ==== Contents of test case:

      set script [makeFile {
          toplevel .t1
          toplevel .t2
          update
          bind .t2 <Destroy> {puts "Destroy .t2" ; exit 1}
          bind .t1 <Destroy> {puts "Destroy .t1" ; exit 0}
          destroy .t2
      } script]
      if {[catch {exec [interpreter] $script -geometry
  10x10+0+0} msg]} {
          set error 1
      } else {
          set error 0
      }
      removeFile script
      list $error $msg

  ---- Result was:
  1 {Destroy .t2
  Destroy .t1
  child killed: software termination signal}
  ---- Result should have been (exact matching):
  0 {Destroy .t2
  Destroy .t1}
  ==== window-2.9 FAILED


tkt_uuid: 741179ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: text-15.* fails to clear font
comment:
  $ make test TESTFLAGS="-file text.test -match text-15.*"
  TCL_LIBRARY=/local/src/tcl/library; export TCL_LIBRARY; \
  TK_LIBRARY=/local/src/tk/library; export TK_LIBRARY; \
  ./tktest /local/src/tk/unix/../tests/all.tcl -geometry
  +0+0 \
  -file text.test -match text-15.* 
  Tests running in interp:  /local/src/tk/solaris/tktest
  Tests located in:  /local/src/tk/tests
  Tests running in:  /local/src/tk/solaris
  Temporary files stored in /local/src/tk/solaris
  Test files sourced into current interpreter
  Running tests that match:  text-15.*
  Skipping test files that match:  l.*.test
  Only running test files that match:  text.test
  Tests began at Wed May 21 11:11:07 AM EDT 2003
  text.test

  Tests ended at Wed May 21 11:11:08 AM EDT 2003
  all.tcl:        Total   358     Passed  2       Skipped
  356     Failed  0
  Sourced 2 Test Files.
  Font Courier -12 still in cache.


  Note the final line.


tkt_uuid: 742260ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Works For Me
title: tk_getpixmap returns 0 with multiple apps open
comment:
  tk_getpixmap returns 0 when I open the 5th instance of 
  my application.

  Each application allocates 2 102x1536 pixmaps and maps 
  them on a canvas.


tkt_uuid: 742660ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 69. Events
priority: 7 High
foundin: None
resolution: Fixed
title: execute XCreateIC twice when "TK_XIM_SPOT" is enabled
comment:
  The over-the-spot mode of XIM (X Input Method) was
  applied on 05-Apr-2002, (tkEvent.c : CVS version 1.9,
  2002/04/05 08:41:07) by Jeff Hobbs. This is truly
  exciting improvement for people who needs character
  conversion when typing characters on the widgets, such
  as for Chinese, Japanese and Korean.

  But, in the middle of June 2002, just before releasing
  8.4b1, I found the over-the-spot mode of XIM did not
  work, but only the root-window mode of XIM worked.

  I've investigated the reason why the XIM is not working
  well. Indeed we, Japanese needs this feature.

  Recently, I've found the reason. Alas, this is very
  very small mistake caused by the modification on
  06-Jun-2002, (tkEvent.c : CVS version 1.13, 2002/06/15
  01:09:36).

  The reason why the over-the-spot mode of XIM is not
  enabled is:

  when TK_XIM_SPOT is enabled, the following two
  XCreateICs are executed in order, this is because of
  inappropriate #if and #endif directives in tkEvent.c.
  In fact, the later XCreateIC is for the root-window
  mode of XIM!

  winPtr->inputContext = XCreateIC(dispPtr->inputMethod,
  XNInputStyle, XIMPreeditPosition|XIMStatusNothing,
  XNClientWindow, winPtr->window,
  XNFocusWindow, winPtr->window,
  XNPreeditAttributes, preedit_attr,
  NULL);

  winPtr->inputContext = XCreateIC(dispPtr->inputMethod,
  XNInputStyle, XIMPreeditNothing|XIMStatusNothing,
  XNClientWindow, winPtr->window,
  XNFocusWindow, winPtr->window,
  NULL);

  The attached patch corrects these directives.

  If this patch is applied, all input contexts (ICs) are
  cleanly destroyed when exiting application. and no more
  aborting error can be seen when exiting.

  The improvement has been proved on Red Hat Linux 9,
  XFree86-4.3.0-2 and Tcl/Tk 8.4.3. Thanks.

  Keiichi


tkt_uuid: 742773ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.4.3
resolution: None
title: 10,000 widgets leaves some undisplayed
comment:
  This may be a Windows-specific bug.  Consider the
  following two scripts:

  GRID VERSION:  (warning: slow)

  for {set i 0} {$i < 80} {incr i} {
    for {set j 0} {$j < 125} {incr j} {
      frame .x${i}y${j} -width 5 -height 5 -background red
      grid .x${i}y${j} -row $i -column $j -padx 1 -pady 1
    }
  }

  PACK VERSION:

  for {set i 0} {$i < 80} {incr i} {
    frame .x$i
    for {set j 0} {$j < 125} {incr j} {
      frame .x${i}.y${j} -width 5 -height 5 -background red
      pack .x${i}.y${j} -side right -padx 1
    }
    pack .x$i -side bottom -pady 1
  }

  On both ActiveTcl 8.4.3 and the Cygwin's Tcl/Tk 8.4.x
  build, these scripts leave some of the last
  (upper-left) frames undisplayed on my Windows box
  (Pentium III 1.2GHz with 640 MB of RAM).  These frames
  seem to be mapping to the upper-left corner of the
  screen (not the window!).  See the attached screenshot.
   There may be a memory-related issue here, but it seems
  reproducible by several people on #tcl.

  The same behavior occurs with buttons instead of
  frames; it's just easier to make frames small.

  As a side note, the grid version of the code is
  excessively slow, and can take a minute or more to
  display.  See bug 220200.


tkt_uuid: 742852ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 81. Portability
priority: 5 Medium
foundin: None
resolution: None
title: Tk 8.4 head Windows/CE port patch
comment:
  Attached is a full patch that adds support for 
  Windows/CE to Tcl. It is based off Rainer Keuchel's 
  original port and requires his celib for building.

  Known issues:
   * [X] in the corner doesn't close app
   * Menus don't work correctly
   * Scrollbar always scrolls to end

  The sources are set up in such that they coexist in the 
  regular win/ subdir, you just configure like so: 

  $ /cygdrive/z/cvs/tk/tk8.4ce/win/configure \
  --prefix=C:/build/inst/tclce \
  --enable-wince=300,ARM \
  --with-celib=/cygdrive/z/src/celib-palm-3.0 \
  --with-tcl=../tcl84ce

  Also, they require changes to the default celib devel stuff 
  from Rainer Keuchel (http://www.rainer-
  keuchel.de/software.html - thanks for the porting library
  Rainer!), in order to be more WinCE3.0 compliant. I also 
  want to fix the known issues (at least the first two) 
  before creating a mega-patch for others to test from 
  source. 

  The changes necessary for TEA extensions are already 
  commited to the sampleextension source base. I've 
  compiled and tested the sampleextension and tktable 
  successfully. Porting of extensions to WinCE3.0 should 
  be rather easy.


tkt_uuid: 742882ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: Potential division by zero in gridded wm geometry
comment:
  % wm grid . 100 100 0 0
  % Floating point exception (core dumped)

  Stack backtrace:

  Program received signal SIGFPE, Arithmetic exception.
  0x0806d396 in GetMaxSize (wmPtr=0x81cfec0,
  maxWidthPtr=0xbffff634,
      maxHeightPtr=0xbffff630) at
  /usr/local/src/tk/unix/tkUnixWm.c:5839
  5839                tmp = wmPtr->reqGridWidth
  (gdb) where
  #0  0x0806d396 in GetMaxSize (wmPtr=0x81cfec0,
  maxWidthPtr=0xbffff634,
      maxHeightPtr=0xbffff630) at
  /usr/local/src/tk/unix/tkUnixWm.c:5839
  #1  0x0806b7d8 in UpdateSizeHints (winPtr=0x81cfdd0,
  newWidth=200,
      newHeight=200) at
  /usr/local/src/tk/unix/tkUnixWm.c:4235
  #2  0x0806b4db in UpdateGeometryInfo (clientData=0x81cfdd0)
      at /usr/local/src/tk/unix/tkUnixWm.c:4079
  #3  0x08164257 in TclServiceIdle ()
  #4  0x08153e02 in Tcl_DoOneEvent ()


  Bug present in CVS HEAD, 8.4, 8.3, and probably earlier.


tkt_uuid: 745189ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.3
resolution: Works For Me
title: tkfbox causes error on fork
comment:
  I think lines 849 and 853 of tkfbox.tcl need a catch
  round them (otherwise "configure -state" can be, and
  is,  called on a label).  Anyway, when the catch is
  added it fixes the problem and our existing code works
  fine again. Was their a change here? Platform is Linux
  kernel 2.4.20 (SuSE 8.2 Pro). Seems to work fine when
  there are no children.


tkt_uuid: 745965ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Potential read of deallocated mem?
comment:
  As I was building a test version of Tk, I noticed that
  in (version 1.16 of) tkTextDisp.c the variable 'flags'
  at line 2247 was unused in the function DisplayText. 
  Further investigation of that code suddenly had an
  unused variable indicated to me that there seems to be
  a potential for trying to read from a deallocated
  structure, which could happen if the Tcl_Release call
  at line 2253, when testing for whether a delete had
  happened on line 2254.  Is this really the case?  It
  seems unfortunate if it is so, but if it can be proved
  to be not a problem, then perhaps the Tcl_Preserve /
  Tcl_Release pair are not needed (though I suspect they
  are, given that they are around something that can
  trigger events/callbacks...)


tkt_uuid: 746267ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 4
foundin: None
resolution: Duplicate
title: Possible focus bug in Aqua Tk 8.4.2
comment:
  There is an apparent focus bug in Aqua Tk 8.4.2 running on MacOS X 10.2.6.

  - Run the following code (which started as a pop-up help system
    but has been stripped down to just show the bug).
  - Click on the entry widget, so it received focus
  - Move the mouse a bit within the entry widget,
    so the pop-up help window is displayed.
    (Make sure the mouse is not over where the help window
    pops up else it will go away instantly.)
  - Type one or more characters.
  - On MacOS X the code *claims* that the entry widget .e still has focus
    but this is a lie. Keystrokes are actually ignored,
    and it seems likely they are going to the pop-up help window
    instead of the entry widget that allegedly still has focus.

  Notes:
  - Adding code that tells Tk to return the focus to the entry
    does not help. One still cannot type in the entry widget.
    Maybe this is not surprising, since tcl/tk seems to think
    the entry widget already has focus.
  - The code runs fine under my unix setup:
    (unix Tcl/Tk 8.4.1, MacOS X 10.2.6, Apple's X11 beta 3),
    BUT it starts failing in a similar way if I remove the
    "wm overrideredirect" command.
  - Thus perhaps the bug is more pervasive than MacOS,
    and/or it's not a bug and I'm going about this all wrong.
   

  entry .e
  pack .e

  bind .e "<Motion>" {
  destroy .t
  puts "show help; focus is [focus]"
  toplevel .t
  wm overrideredirect .t 1
  wm transient .
  message .t.m -text "this is a help msg"
  pack .t.m
  puts "help is showing; focus is [focus]"
  }

  bind .e "<Leave>" {
  puts "leave"
  destroy .t
  }

  bind .e "<KeyPress>" {
  puts "keypress"
  destroy .t
  }


tkt_uuid: 747464ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 3 Low
foundin: obsolete: 8.5a0
resolution: Fixed
title: AA-fonts break build when disabled
comment:
  My dev box doesn't have have all the bits for xft
  support present, so I configured with --disable-xft but
  an attempt to make tkUnixRFont.o was still done and
  that failed horribly (the first error is the lack of a
  declaration for XftFont, but that's a symptom of the
  fact that the file should never have been built.)  This
  is critical since it has completely broken my build (I
  have a very old version of autoconf so fixes are more
  than a bit awkward.)

  When I try building with it enabled, I get these
  messages from configure (segment, wrapped)
    [...]
    checking for X... libraries /usr/X11R6/lib, headers
    /usr/X11R6/include
    checking for main in -lXbsd... no
    checking for xft configuration... ./configure:
    pkg-config: command not found
    ./configure: pkg-config: command not found
    configure: WARNING: Can't find xft configuration
    checking whether char is unsigned... no
    [...]
  (That's more info than is present in config.log, BTW)

  'uname -a' output:
    Linux cpipc 2.4.9-34 #1 Sat Jun 1 06:25:16 EDT 2002
    i686 unknown

  Contents of /etc/issue:
    Red Hat Linux release 7.2 (Enigma)
    Kernel 2.4.9-34 on an i686

  (As a side note, when building with xft support
  disabled, I don't get a message during configure to
  confirm this.  It'd be nice if it said that support was
  not being built because of the cmdline option so that
  it is obvious that things aren't getting unfortunately
  ignored.  :^)


tkt_uuid: 747814ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Typographical error in panedwindow man page
comment:
  The panedwindow man page appears to have a minor 
  typograpical error.  In the string quoted below, the 
  word "and" is probably intended to be just "an".

     When adding a new window that has not 
     yet been mapped, and update idletasks 
     call is required for that window 


tkt_uuid: 748277ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4.3
resolution: Fixed
title: Last pane don't shrink
comment:
  When paned window shrink, last pane don't shrink, but 
  is clipped.

  Panedwindow handles extra space when it grows and 
  clip last pane when it shrink. However, the last pane 
  size is adjusted when the sash is moved.

  Should be last pane{Width|Height} be updated on 
  ConfigureEvent or negative "extra" space handled ?


tkt_uuid: 748859ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.4.3
resolution: None
title: tk8.4.3 test failures on Tru64Unix 5.1A
comment:
  I have some pending bugs on the tcl side for this
  platform, so those might be the underlying problem ...
  I cannot judge. Here's what I got. Could anyone help?
  Thanks!


  ==== focus-5.1 ChangeXFocus procedure, don't take focus
  unless have it FAILED
  ==== Contents of test case:

      focusSetup
      focus -force .t
      update
      set result [focus]
      send [dobg {tk appname}] {focus -force .; update}
      lappend result [focus]
      focus .t.b2
      update
      lappend result [focus]

  ---- Result was:
  .t .t {}
  ---- Result should have been (exact matching):
  .t {} {}
  ==== focus-5.1 FAILED


  ==== listbox-4.1 ConfigureListbox procedure FAILED
  ==== Contents of test case:

      catch {destroy .l}
      listbox .l -setgrid 1 -width 25 -height 15
      pack .l
      update
      set x [getsize .]
      .l configure -setgrid 0
      update
      list $x [getsize .]

  ---- Result was:
  25x15 26x16
  ---- Result should have been (exact matching):
  25x15 185x263
  ==== listbox-4.1 FAILED


  ==== listbox-9.2 ListboxCmdDeletedProc procedure,
  disabling -setgrid FAILED
  ==== Contents of test case:
      catch {destroy .top}
      toplevel .top
      wm geom .top +0+0
      listbox .top.l -setgrid 1 -width 20 -height 10
      pack .top.l
      update
      set x [wm geometry .top]
      rename .top.l {}
      update
      lappend x [wm geometry .top]
      destroy .top
      set x

  ---- Result was:
  20x10+0+0 21x11+0+0
  ---- Result should have been (exact matching):
  20x10+0+0 150x178+0+0
  ==== listbox-9.2 FAILED


  ==== listbox-13.3 ListboxScanTo procedure FAILED
  ==== Contents of test case:

      .l yview moveto 1.0
      .l xview moveto 1.0
      .l scan mark 10 20
      .l scan dragto 5 10
      update
      set x [list [.l xview] [.l yview]]
      .l scan dragto [expr 5+$width] [expr 10+$height]
      update
      lappend x [.l xview] [.l yview]

  ---- Result was:
  {0.8 1} {0.75 1} {0.64 0.84} {0.25 0.5}
  ---- Result should have been (exact matching):
  {0.8 1} {0.75 1} {0.62 0.82} {0.25 0.5}
  ==== listbox-13.3 FAILED


  ==== spinbox-5.7 ConfigureSpinbox procedure FAILED
  ==== Contents of test case:

      catch {destroy .e}
      spinbox .e -font $fixed -width 4 -xscrollcommand scroll
      pack .e
      .e insert end "01234567890"
      update
      .e configure -width 5
      set scrollInfo

  ---- Result was:
  0.315789 0.842105
  ---- Result should have been (exact matching):
  0 0.363636
  ==== spinbox-5.7 FAILED


  ==== spinbox-7.1 InsertChars procedure FAILED
  ==== Contents of test case:

      .e delete 0 end
      .e insert 0 abcde
      .e insert 2 XXX
      update
      list [.e get] $contents $scrollInfo

  ---- Result was:
  abXXXcde abXXXcde {0.315789 0.842105}
  ---- Result should have been (exact matching):
  abXXXcde abXXXcde {0 1}
  ==== spinbox-7.1 FAILED


  ==== spinbox-17.4 SpinboxUpdateScrollbar procedure FAILED
  ==== Contents of test case:

      destroy .e
      set x "Background error did not happen"
      proc bgerror msg {
          global x
          set x $msg
      }
      spinbox .e -width 5 -xscrollcommand thisisnotacommand
      pack .e
      update
      rename bgerror {}
      list $x $errorInfo

  ---- Result was:
  {Background error did not happen} {bad spinbox index "1xyz"
      while executing
  ".e index 1xyz"}
  ---- Result should have been (exact matching):
  {invalid command name "thisisnotacommand"} {invalid
  command name "thisisnotacommand"
      while executing
  "thisisnotacommand 0 1"
      (horizontal scrolling command executed by .e)}
  ==== spinbox-17.4 FAILED


  ==== spinbox-19.8 spinbox widget validation FAILED
  ==== Contents of test case:

      focus -force .e
      # update necessary to process FocusIn event
      update
      set ::vVals

  ---- Result was:

  ---- Result should have been (exact matching):
  .e -1 -1 abcd abcd {} focus focusin
  ==== spinbox-19.8 FAILED


  ==== spinbox-19.9 spinbox widget validation FAILED
  ==== Contents of test case:

      focus -force .
      # update necessary to process FocusOut event
      update
      set ::vVals

  ---- Result was:

  ---- Result should have been (exact matching):
  .e -1 -1 abcd abcd {} focus focusout
  ==== spinbox-19.9 FAILED

  text.test

  ==== text-15.2 TextCmdDeletedProc procedure, disabling
  -setgrid FAILED
  ==== Contents of test case:

      catch {destroy .top}
      toplevel .top
      wm geom .top +0+0
      text .top.t -setgrid 1 -width 20 -height 10
      pack .top.t
      update
      set x [wm geometry .top]
      rename .top.t {}
      update
      lappend x [wm geometry .top]
      destroy .top
      set x

  ---- Result was:
  20x10+0+0 21x11+0+0
  ---- Result should have been (exact matching):
  20x10+0+0 150x140+0+0
  ==== text-15.2 FAILED

  textBTree.test
  textDisp.test
  choutextImage.test
  textIndex.test
   jatextMark.test
  textTag.test

  ==== 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.2 3.2
  ---- Result should have been (exact matching):
  3.2 3.1
  ==== textTag-16.2 FAILED

  textWind.test
  tk.test
  unixButton.test
  unixEmbed.test

  ==== unixEmbed-5.1 EmbedFocusProc procedure, FocusIn
  events FAILED
  ==== Contents of test case:

      deleteWindows
      frame .f1 -container 1 -width 200 -height 50
      pack .f1
      dobg "set w1 [winfo id .f1]"
      dobg {
          eval destroy [winfo child .]
          toplevel .t1 -use $w1
          bind .t1 <FocusIn> {lappend x "focus in %W"}
          bind .t1 <FocusOut> {lappend x "focus out %W"}
          set x {}
      }
      focus -force .f1
      update
      dobg {set x}

  ---- Result was:

  ---- Result should have been (exact matching):
  {focus in .t1}
  ==== unixEmbed-5.1 FAILED


  ==== unixEmbed-5.3 EmbedFocusProc procedure, FocusOut
  events FAILED
  ==== Contents of test case:

      deleteWindows
      frame .f1 -container 1 -width 200 -height 50
      pack .f1
      dobg "set w1 [winfo id .f1]"
      dobg {
          eval destroy [winfo child .]
          toplevel .t1 -use $w1
          bind .t1 <FocusIn> {lappend x "focus in %W"}
          bind .t1 <FocusOut> {lappend x "focus out %W"}
          set x {}
      }
      focus -force .f1
      update
      set x [dobg {update; set x}]
      focus .
      update
      list $x [dobg {update; set x}]

  ---- Result was:
  {} {}
  ---- Result should have been (exact matching):
  {{focus in .t1}} {{focus in .t1} {focus out .t1}}
  ==== unixEmbed-5.3 FAILED


  ==== unixEmbed-7.2 TkpRedirectKeyEvent procedure, don't
  forward keystroke width FAILED
  ==== Contents of test case:

      deleteWindows
      frame .f1 -container 1 -width 200 -height 50
      pack .f1
      dobg "set w1 [winfo id .f1]"
      dobg {
          eval destroy [winfo child .]
          toplevel .t1 -use $w1
      }
      update
      focus -force .f1
      update
      bind . <KeyPress> {lappend x {key %A}}
      set x {}
      set y [dobg {
          update
          bind .t1 <KeyPress> {lappend y {key %A}}
          set y {}
          event generate .t1 <KeyPress> -keysym b
          set y
      }]
      update
      bind . <KeyPress> {}
      list $x $y

  ---- Result was:
  {{key b}} {}
  ---- Result should have been (exact matching):
  {} {{key b}}
  ==== unixEmbed-7.2 FAILED


  ==== unixEmbed-8.1 TkpClaimFocus procedure FAILED
  ==== Contents of test case:

      deleteWindows
      frame .f1 -container 1 -width 200 -height 50
      frame .f2 -width 200 -height 50
      pack .f1 .f2
      dobg "set w1 [winfo id .f1]"
      dobg {
          eval destroy [winfo child .]
          toplevel .t1 -use $w1 -highlightthickness 2 -bd
  2 -relief sunken
      }
      focus -force .f2
      update
      list [dobg {
          focus .t1
          set x [list [focus]]
          update
          after 500
          update
          lappend x [focus]
      }] [focus]

  ---- Result was:
  {{} {}} .f1
  ---- Result should have been (exact matching):
  {{} .t1} .f1
  ==== unixEmbed-8.1 FAILED


  ==== unixEmbed-8.2 TkpClaimFocus procedure FAILED
  ==== Contents of test case:

      catch {interp delete child}
      deleteWindows
      frame .f1 -container 1 -width 200 -height 50
      frame .f2 -width 200 -height 50
      pack .f1 .f2
      interp create child
      child eval "set argv {-use [winfo id .f1]}"
      load {} Tk child
      child eval {
          . configure -bd 2 -highlightthickness 2 -relief
  sunken
      }
      focus -force .f2
      update
      list [child eval {
          focus .
          set x [list [focus]]
          update
          lappend x [focus]
      }] [focus]

  ---- Result was:
  {{} {}} .f1
  ---- Result should have been (exact matching):
  {{} .} .f1
  ==== unixEmbed-8.2 FAILED

  unixFont.test
  unixMenu.test

  ==== unixMenu-18.1 GetTearoffEntryGeometry FAILED
  ==== Contents of test case:

      catch {destroy .m1}
      menubutton .mb -text "test" -menu .mb.m
      menu .mb.m
      .mb.m add command -label test
      pack .mb
      raise .
      list [catch {tk::MbPost .mb} msg] $msg
  [tk::MenuUnpost .mb.m] [destroy .mb]

  ---- Result was:
  1 {grab failed: window not viewable} {} {}
  ---- Result should have been (exact matching):
  0 {} {} {}
  ==== unixMenu-18.1 FAILED




  Tests ended at Wed Jun 04 15:44:11 MEST 2003
  all.tcl:        Total   8373    Passed  7538    Skipped
  818     Failed  17
  Sourced 182 Test Files.
  Files with failing tests: focus.test listbox.test
  spinbox.test text.test textTag.test unixEmbed.test
  unixMenu.test
  Number of tests skipped for each constraint:
          14      altDisplay
          16      colorsFree
          5       emptyTest
          1       knownBug
          310     macOnly
          20      macOrPc
          113     nonPortable
          35      nt
          233     pcOnly
          4       pseudocolor
          4       pseudocolor8
          11      testmetrics
          1       userInteraction
          51      winSend


tkt_uuid: 748977ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Duplicate
title: tktest from current cvs dumps core
comment:
  [...]
  TCL_LIBRARY=/mnt/tcl/library; export TCL_LIBRARY; \
  TK_LIBRARY=/mnt/tk/library; export TK_LIBRARY; \
  ./tktest /mnt/tk/unix/../tests/all.tcl -geometry +0+0 \
   
  /bin/sh: 157334 Abort - core dumped
  make: *** [test] Error 134
  $ dbx ./tktest ./core
  dbx version 5.1
  Type 'help' for help.
  Core file created by program "tktest"

  signal IOT/Abort trap at >*[__kill, 0x3ff800e9658]    
   beq     a3, 0x3ff800e9670
  (dbx) where
  >  0 __kill(0x0, 0x1, 0x3ff800ddcc8, 0x300400a25b8,
  0x3ff801c53a4) [0x3ff800e9658]
     1 (unknown)() [0x3ff8020c148]
     2 __tis_raise(0x3ff801c53a4, 0x102b8, 0x3ff8013b4d8,
  0x100000006, 0x3ff801a20d4) [0x3ff8013b4d4]
     3 raise(0x3ff8013b4d8, 0x100000006, 0x3ff801a20d4,
  0x0, 0x3ff801c53d4) [0x3ff801a20d0]
     4 abort(0x3ffbff4869c, 0x300400b9a78, 0x0, 0x0,
  0x3ff00000000) [0x3ff801c53d0]
     5 Tk_MainEx(argc = 4, argv = 0x11fffc018,
  appInitProc = 0x120003214, interp = 0x140008b00)
  ["/mnt/tk/unix/../generic/tkMain.c":119, 0x3ffbff48698]
     6 main(argc = 4, argv = 0x11fffc018)
  ["/mnt/tk/unix/tkAppInit.c":68, 0x1200031f4]
  (dbx) 


  Tested on Tru64Unix 5.1A, used cc/cxx from vendor.


tkt_uuid: 748992ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: canvImg.test fails
comment:
  I built current tk cvs against tcl8.4.3 and this fails.
  I did not fail under tk8.4.3 on same machine.

  ==== canvImg-5.1 DeleteImage procedure FAILED
  ==== Contents of test case:

      image create test xyzzy -variable z
      .c delete all
      .c create image 50 100 -image xyzzy -tags i1
      update
      set names [lsort [image names]]
      image delete xyzzy
      set z {}
      set names2 [lsort [image names]]
      .c delete i1
      update
      list $names $names2 $z [lsort [image names]]

  ---- Result was:
  {foo foo2 xyzzy} {foo foo2 xyzzy} {} {foo foo2}
  ---- Result should have been (exact matching):
  {foo foo2 xyzzy} {foo foo2} {} {foo foo2}
  ==== canvImg-5.1 FAILED


tkt_uuid: 748999ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: focus.test fails
comment:
  This test fails on Tru64UNix 5.1A - current cvs
  checkout linked against *tcl8.4.3*! And also in tk8.4.3
  linked with tcl8.4.3.

  ==== focus-5.1 ChangeXFocus procedure, don't take focus
  unless have it FAILED
  ==== Contents of test case:

      focusSetup
      focus -force .t
      update
      set result [focus]
      send [dobg {tk appname}] {focus -force .; update}
      lappend result [focus]
      focus .t.b2
      update
      lappend result [focus]

  ---- Result was:
  .t .t {}
  ---- Result should have been (exact matching):
  .t {} {}
  ==== focus-5.1 FAILED


tkt_uuid: 749006ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: listbox.test fails
comment:
  This test fails on Tru64Unix 5.1A with tcl8.4.3/tk8.4.3
  and tcl8.4.3/tk-cvs:


  ==== listbox-4.1 ConfigureListbox procedure FAILED
  ==== Contents of test case:

      catch {destroy .l}
      listbox .l -setgrid 1 -width 25 -height 15
      pack .l
      update
      set x [getsize .]
      .l configure -setgrid 0
      update
      list $x [getsize .]

  ---- Result was:
  25x15 26x16
  ---- Result should have been (exact matching):
  25x15 185x263
  ==== listbox-4.1 FAILED


  ==== listbox-9.2 ListboxCmdDeletedProc procedure,
  disabling -setgrid FAILED
  ==== Contents of test case:

      catch {destroy .top}
      toplevel .top
      wm geom .top +0+0
      listbox .top.l -setgrid 1 -width 20 -height 10
      pack .top.l
      update
      set x [wm geometry .top]
      rename .top.l {}
      update
      lappend x [wm geometry .top]
      destroy .top
      set x

  ---- Result was:
  20x10+0+0 21x11+0+0
  ---- Result should have been (exact matching):
  20x10+0+0 150x178+0+0
  ==== listbox-9.2 FAILED


  ==== listbox-13.3 ListboxScanTo procedure FAILED
  ==== Contents of test case:

      .l yview moveto 1.0
      .l xview moveto 1.0
      .l scan mark 10 20
      .l scan dragto 5 10
      update
      set x [list [.l xview] [.l yview]]
      .l scan dragto [expr 5+$width] [expr 10+$height]
      update
      lappend x [.l xview] [.l yview]

  ---- Result was:
  {0.8 1} {0.75 1} {0.64 0.84} {0.25 0.5}
  ---- Result should have been (exact matching):
  {0.8 1} {0.75 1} {0.62 0.82} {0.25 0.5}
  ==== listbox-13.3 FAILED


tkt_uuid: 749010ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: panedwindow.test fails
comment:
  This test fails on Tru64Unix 5.1A with tcl8.4.3/tk-cvs
  but NOT tcl8.4.3/tk8.4.3(maybe it's expected when
  messing up versions):

  ==== panedwindow-23.2 PanedWindowReqProc, react to
  slave geometry changes FAILED
  ==== Contents of test case:

      panedwindow .p -orient horizontal -sashpad 0
  -sashwidth 2
      .p add [frame .f1 -width 10] [frame .f2 -width 10]
      set result [winfo reqwidth .p]
      .f1 configure -width 20
      lappend result [winfo reqwidth .p]
      destroy .p .f1 .f2
      set result

  ---- Result was:
  32 32
  ---- Result should have been (exact matching):
  32 42
  ==== panedwindow-23.2 FAILED


tkt_uuid: 749011ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 51. [place]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: None
title: place.test fails
comment:
   This test fails on Tru64Unix 5.1A with tcl8.4.3/tk-cvs
   but NOT tcl8.4.3/tk8.4.3(maybe it's expected when
   messing up versions):

  ==== place-4.2 ConfigureSlave procedure, bad -in option
  FAILED
  ==== Contents of test case:

      place forget .t.f2
      list [winfo manager .t.f2]  [catch {place .t.f2 -in
  .t.f2} err] $err  [winfo manager .t.f2]

  ---- Result was:
  {} 1 {can't place .t.f2 relative to itself} place
  ---- Result should have been (exact matching):
  {} 1 {can't place .t.f2 relative to itself} {}
  ==== place-4.2 FAILED


tkt_uuid: 749014ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: scale.test fails
comment:
   This test fails on Tru64Unix 5.1A with tcl8.4.3/tk-cvs
   but NOT tcl8.4.3/tk8.4.3(maybe it's expected when
   messing up versions):


  ==== scale-15.5 ScaleVarProc procedure, variable
  deleted FAILED
  ==== Contents of test case:

      catch {destroy .s}
      set y 6
      scale .s -from 10 -to 0 -variable y -orient
  horizontal -length 150  -command "set x"
      pack .s
      update
      set x untouched
      unset y
      update
      list [catch {set y} msg] $msg [.s get] $x

  ---- Result was:
  0 6 6 6
  ---- Result should have been (exact matching):
  0 6 6 untouched
  ==== scale-15.5 FAILED


  ==== scale-15.6 ScaleVarProc procedure, don't call
  -command FAILED
  ==== Contents of test case:

      catch {destroy .s}
      set y 6
      scale .s -from 0 -to 100 -variable y -orient
  horizontal -length 150  -command "set x"
      pack .s
      update
      set x untouched
      set y 60
      update
      list $x [.s get]

  ---- Result was:
  60 60
  ---- Result should have been (exact matching):
  untouched 60
  ==== scale-15.6 FAILED


