# ticket

tkt_uuid: 220288ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: text widget 'dump' bugs with multi-byte characters
comment:
  OriginalBugID: 4419 Bug
  Version: 8.3
  SubmitDate: '2000-03-21'
  LastModified: '2000-03-21'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  OSVersion: 4.0sp5
  ClosedDate: '2000-03-21'


  Name:
  Vince Darley

  ReproducibleScript:
  # Script to show bug.
  text .t
  .t tag configure green -foreground green -background red
  pack .t
  .t insert 1.0 "X abc\n\u2022 abc"
  .t tag add green 1.2 "1.2 lineend"
  .t tag add green 2.2 "2.2 lineend"
  console show
  puts stdout ".t get 1.2 2.0 is"
  puts stdout [.t get 1.2 2.0]
  puts stdout ".t get 2.2 3.0 is"
  puts stdout [.t get 2.2 3.0]

  puts stdout ".t dump -tag 1.0 2.0 is"
  puts stdout [.t dump -tag 1.0 2.0]

  puts stdout ".t dump -tag 2.0 3.0 is"
  puts stdout [.t dump -tag 2.0 3.0]

  puts stdout "Notice how the last one is 2 indices off!"

  ObservedBehavior:
  The '.t dump -tag ...' works when a line contains no multi-byte characters, but returns incorrect text indices when multibyte characters are present.

  In the above example the bullet '\u2022' seems to be counted as 3 characters...



  This was fixed in 8.3.0.  As you stated in comp.lang.tcl:

  You're absolutely right.  Sorry about the false alarm.  I somehow reset
  my machine to use Tk 8.2.3 instead of 8.3, the bug has indeed been
  fixed.


  - eric
   
  -- 03/21/2000 ericm


tkt_uuid: 220289ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: scale test fails
comment:
  OriginalBugID: 4433 Bug
  Version: 8.3
  SubmitDate: '2000-03-21'
  LastModified: '2000-06-02'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: HP-UX 11.00, 32 bit kernel
  ClosedDate: '2000-06-02'


  Name:

  ed foltz


  CustomShell:

  tcl compile warnings corrected:


  Comments:

  Test 6.11. When .0001 is the argument to log10() the result is not 4.0~,

      it is 4.000000000000009. So floor() returns 5 instead of 4.


  ObservedBehavior:

  Fromsupplied regression  test suite:

  scale.test


  ==== scale-6.12 ComputeFormat procedure FAILED

  ==== Contents of test case:


      .s configure -from .00001 -to .0001 -resolution .00001

      .s set .00006

      .s get


  ---- Result was:

  6e-05

  ---- Result should have been:

  0.00006

  ==== scale-6.12 FAILED

  ==== scale-6.14 ComputeFormat procedure FAILED

  ==== Contents of test case:


      .s configure -to .00001 -from .0001 -resolution .00001

      .s set .00006

      .s get


  ---- Result was:

  6e-05

  ---- Result should have been:

  0.00006

  ==== scale-6.14 FAILED


  Also, test 6.11 fails with returned result 0.00060, expected 0.0006

  test scale-6.11 {ComputeFormat procedure} {

      .s configure -from .0001 -to .001 -resolution .0001

      .s set .0006

      .s get

  } {0.0006}


  DesiredBehavior:

  Result from 6.12 and 6.14 is valid because ComputeFormat() returns the shortest string representation.


  Expected 6.11 to return 0.0006.


  Patch:

  scale.test

  357c357

  < } {6e-05} 

  ---

  > } {0.00006}

  366,367c366,367

  <       .s get

  < } {6e-05} 

  ---

  >     .s get

  > } {0.00006}


  tkScale.c


  837c837

  <           leastSigDigit = (int) floor(log10f((float)scalePtr->resolution));

  ---

  >           leastSigDigit = (int) floor(log10(scalePtr->resolution));


  PatchFiles:

  scale.test

      tkScale.c




  This is a minor platform dependent difference on HP's part, and
  has no overall effect on the code, because 6e-05 == .00006.
  We could mark it non-portable (as we have to do because Windows
  has similar quirks), but it'd be better for the core team to
  see these tests run in general. 
  -- 06/02/2000 hobbs


tkt_uuid: 220290ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: info exists does not see image create photo
comment:
  OriginalBugID: 4498 Bug
  Version: 8.3
  SubmitDate: '2000-03-23'
  LastModified: '2000-03-23'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: BSD
  OSVersion: BSDi BSD/OS 4.1
  Machine: PC Pentium-class
  ClosedDate: '2000-03-23'


  Name: Richard Ross-Langley

  Comments:
  Same bug was found on Tcl/Tk 8.0
      Workaround is to 'set flag 1' when 'catch' succeeds, and test [info
      exists flag]
      Maybe an image as created by Tk is not a normal variable?

  ReproducibleScript:
  BSDi % wish test2.tcl

  # where test2.tcl is

  puts "Tcl patchlevel [info patchlevel]"
  set picname "f1bar.gif"
  if {[catch [list  image create photo pic -format "gif" -file "$picname"  ] ] == 0} {
    puts "image create to variable pic (from $picname) succeeded! "
  } else {
    puts "*** image create FAILED "
  }
  if {[info exists pic]} {
    puts "Photo variable pic from $picname exists! "
  } else {
    puts "*** Photo variable pic (from $picname) does NOT exist "
  }
  exit

  ObservedBehavior:
  Image was created but [info exists] says it is not a variable.

  Output from the test program -

  Tcl patchlevel 8.3.0
  image create to variable pic (from f1bar.gif) succeeded! 
  *** Photo variable pic (from f1bar.gif) does NOT exist

  DesiredBehavior:
  Tcl patchlevel 8.3.0
  image create to variable pic (from f1bar.gif) succeeded! 
  Photo variable pic from f1bar.gif exists!



  Pilot error: image create creates a command, not a var. 
  -- 03/23/2000 hobbs


tkt_uuid: 220291ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: text widget index current returned value bug
comment:
  OriginalBugID: 4643 Bug
  Version: 8.3
  SubmitDate: '2000-03-28'
  LastModified: '2000-03-28'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Other
  OSVersion: OpenBSD 2.6
  Machine: Intel Pentium II (Klamath) (
  ClosedDate: '2000-03-28'


  Name:
  George P. Staplin

  Extensions:
  Img 1.2.3

  ReproducibleScript:
  #!/usr/local/bin/wish8.3
  text .test
  pack .test
  bind .test <KeyPress> {puts [.test index current]}

  ObservedBehavior:
  When the Enter/Return key is held down it randomly outputs the same value, despite the fact that the text widget index is different.

  $ ./tk_bug.tcl
  1.0
  2.0
  3.0
  4.0
  5.0
  6.0
  7.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  9.0
  10.0
  11.0
  12.0
  13.0
  14.0
  15.0
  16.0
  17.0
  18.0
  19.0
  20.0
  21.0
  22.0
  23.0
  24.0
  25.0
  26.0
  27.0
  28.0
  29.0
  30.0
  ^C
  $

  This is the log when set tcl_traceExec 2 is enabled, which shows that 5 repeats:
  Calling proc tkScreenChanged
  2: (8) invoking string
  2: (33) invoking string
  2: (60) invoking uplevel
  2: (67) invoking global
  2: (74) invoking global
  2: (83) invoking info
  2: (97) invoking return
  Calling proc tkTextButton1
  2: (4) invoking global
  2: (44) invoking tkTextClosestGap
  Calling proc tkTextClosestGap
  3: (14) invoking .test
  3: (25) invoking .test
  3: (38) invoking string
  3: (62) invoking lindex
  3: (71) invoking lindex
  3: (83) invoking return
  2: (46) invoking .test
  2: (59) invoking .test
  2: (72) invoking .test
  2: (76) invoking string
  2: (85) invoking focus
  Calling proc tkTextSelectTo
  2: (6) invoking global
  2: (17) invoking tkTextClosestGap
  Calling proc tkTextClosestGap
  3: (14) invoking .test
  3: (25) invoking .test
  3: (38) invoking string
  3: (62) invoking lindex
  3: (71) invoking lindex
  3: (83) invoking return
  2: (33) invoking .test
  2: (68) invoking .test
  2: (83) invoking .test
  2: (131) invoking switch
  3: (12) invoking .test
  2: (159) invoking string
  Calling proc tkCancelRepeat
  1.0
  2: (4) invoking global
  2: (16) invoking after
  Calling proc tkTextInsert
  2.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  3.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  4.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  6.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  7.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  8.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  9.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  10.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  11.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  12.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  13.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  14.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  15.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  16.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  17.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert

  DesiredBehavior:
  I expect the returned value from index current to be accurate and consistent.



  From the text widget manual entry:

         Two marks have  special  significance.   First,  the  mark
         insert   is  associated  with  the  insertion  cursor,  as
         described under THE INSERTION CURSOR below.   Second,  the
         mark  current  is associated with the character closest to
         the mouse and is adjusted automatically to track the mouse
         position  and  any  changes to the text in the widget (one
         exception:  current is not updated in  response  to  mouse
         motions  if  a  mouse  button is down;  the update will be
         deferred until all  mouse  buttons  have  been  released).
         Neither of these special marks may be deleted.

  Note that the "current" mark indicates the character closest to the mouse
  pointer; *not*, as you seem to expect, the character at the insertion
  cursor.  To retrieve that value, you should use ".test index insert".

  You can verify that current gives you the character closest to the mouse
  by moving the mouse around in between keypresses with this example:

  pack [text .test]
  bind .test <KeyPress> {puts "[.test index current]; [.test index insert]"}

  - eric

   
  -- 03/28/2000 ericm


tkt_uuid: 220292ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: None
resolution: Invalid
title: winfo parent window ?depth?
comment:
  OriginalBugID: 4800 RFE
  Version: 8.3
  SubmitDate: '2000-04-03'
  LastModified: '2000-06-02'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  ClosedDate: '2000-06-02'


  Name:
  keith lea

  DesiredBehavior:
  this would be nice:

  % winfo parent .pneu.mono.ul.tra.mic.ro.sco.pic 1
  .pneu.mono.ul.tra.mic.ro.sco
  % winfo parent .pneu.mono.ul.tra.mic.ro.sco.pic 3
  .pneu.mono.ul.tra.mic

  just for convenience



  It's not clear where this would be useful.  We want to avoid
  unnecessary creeping featurism (after all, at some level Tcl/Tk
  is a language with traditional loop language constructs).  Is
  there some strong argument for the above? 
  -- 06/02/2000 hobbs


tkt_uuid: 220294ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Invalid
title: tk_chooseDir requires two clicks on OK after entering a non-existent directory name
comment:
  OriginalBugID: 4889 Bug
  Version: 8.3
  SubmitDate: '2000-04-06'
  LastModified: '2000-04-12'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: Win NT 4.0 SP 5
  Machine: Hewlett-Packard Vectra VL (Pentium II)
  ClosedDate: '2000-04-12'


  Name:
  Tim Wilson

  Extensions:
  Tk 8.3.0

  ReproducibleScript:
  <Start wish>
  % tk_chooseDir
  <Now type a name of a file that does *not* exists into the "Directory name" box.  Click OK.>
  <Nothing happens!>
  <Click OK a second time... and tk_chooseDir returns:>
  %

  ObservedBehavior:
  Two clicks required on OK instead of the usual one.

  DesiredBehavior:
  Only one click on OK needed.



  Unfortunately, this behavior is required.  The problem is that the dialog has no way of differentiating between the case where the user has intentionally entered a non-existant directory name and the case where the user has accidentally entered a non-existant directory name (due to misspelling, for example).

  Imagine how irritating it would be if the dialog always dismissed when you
  accidentally mistyped a directory name and hit OK.  Because of this problem, I don't think there's anything we can do about this.

  Note also that the behavior exhibited by the tk_chooseDirectory dialog is in line with the Windows standard behavior for that dialog, AFAIK.

  - eric

  -- 04/11/2000 ericm

  ---
  From Tim Wilson:

      Eric> I was under the impression that this was the normal behavior
      Eric> of this dialog on NT.  Is that not correct?

  1. I don't think so:

  (a) The save-as dialogue, which has a very similar function (returning
      a new file name instead of a new directory name) only requires one
      click/return. 

  (b) On Visual C 6, if you File -> New -> Projects, then type a new
      directory name into the location box, then press the Browse "..."
      button, it only requires one click/return to choose the new
      directory name. 

  (c) However, I can't find a Microsoft app on my machine which asks you
      to choose a new directory name using *only* a dialogue.  (In the VC
      example above you have to use the entryfield too.)  Perhaps this
      is against some Windows GUI guideline.

  (d) Nevertheless, as an experienced Windows user, I think the fact
      that I was surprised by the "standard" dialogue's behaviour (and I
      wasn't the only one) is itself evidence that this is not normal
      behaviour for Windows. 

  2. You could suggest that a second click/return is desirable to help
     users avoid accidentally choosing a new name when they really meant
     to choose an existing name.

     But surely the case of accidentally typing a non-existent directory
     name is covered by the "-mustexist" flag?  And exactly the same
     argument would apply to tk_getSaveFile, which doesn't require a
     separate confirmation.

  3. If we do want a confirmation phase when choosing a new directory
     name, I think there should be a visual indication of the change in
     interal state (a basic GUI design principle, I think).  In this
     case, the obvious choice would be an "are you sure" dialogue.  (But
     I'd still ask: why are tk_getSaveFile and tk_chooseDir different?) 

  Does anyone have more definitive information?

  Tim

  ---
  From Jeff:

  I'd say intuitively it may seem odd, but actually using VC5, I find
  that our behavior is exactly the same as theirs (not one click, as
  you say).  If you go to File -> New, Projects tab, then click on
  the "..." (Browse for directory), it pops up by default with
          Z:\cvs\tk8.3\win
  I think edit the entry box by hand to say:
          Z:\cvs\tk8.3\generic

  I click OK, and it *cd's* to the directory, it doesn't go away, just
  as our behavior has.  If I put in a bogus directory, it complains that
  no such thing exists, so I can't tell what their behavior is exactly
  allowing for non-existent directories, but from the above, I'm fairly
  sure it's the same (as it would follow the exact same message path).

  -- 
     Jeffrey Hobbs                          The Tcl Guy
     jeffrey.hobbs at scriptics.com         Scriptics Corp.

  -- 04/12/2000 ericm


tkt_uuid: 220295ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: canvas drawn on a button
comment:
  OriginalBugID: 5002 Bug
  Version: 8.3
  SubmitDate: '2000-04-11'
  LastModified: '2000-04-14'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  OSVersion: Windows 98
  ClosedDate: '2000-04-14'


  Name:
  Boris Gontar

  ReproducibleScript:
  set h 12
  button .b -width $h -height $h -bitmap gray25 
  canvas .b.c -width $h -height $h -bg [.b cget -bg] 
  .b.c create line 1 1 $h $h
  pack propagate .b no
  pack .b.c
  pack .b

  ObservedBehavior:
  This script works ok on Unix. On Windows when mouse leaves the button, the underlying bitmap "gray25" becomes visible.

  DesiredBehavior:
  On Windows: same as on Unix, which is the expected behaviour.



  This is not supported behavior.  On Windows, we really on some
  native calls for buttons which just won't allow this.  Buttons
  are not meant to be containers, that is left to widgets like frames,
  toplevels, texts, canvases, and other widgets designed for that
  purpose. 
  -- 04/14/2000 hobbs


tkt_uuid: 220296ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Invalid
title: tk_chooseDirectory does not work.
comment:
  OriginalBugID: 5146 Bug
  Version: 8.3
  SubmitDate: '2000-04-18'
  LastModified: '2000-04-18'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: Pentium III 300
  ClosedDate: '2000-04-18'


  Name: Peter Onesti

  ReproducibleScript:
  To reproduce, invoke tk_chooseDirectory in a wish command console.

  ObservedBehavior:
  The command produces an 'illegal operation performed' error when invoked by the wish interpreter.

  DesiredBehavior:
  I should see a directory selection window.



  This is a bug in Win95, and can be fixed by upgrading to a newer
  version of comdlg32.dll (you can grab the one from Win98). 
  -- 04/18/2000 hobbs


tkt_uuid: 220297ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: Can't find a usable tk.tcl i
comment:
  OriginalBugID: 5173 RFE
  Version: 8.3
  SubmitDate: '2000-04-19'
  LastModified: '2000-04-19'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: solaris 7
  Machine: sun ultra 5
  ClosedDate: '2000-04-19'


  Name: WArren Dodge

  DesiredBehavior:
  Better searching for components needed by tcl/tk

  tcl built this way
  /configure  --prefix=/vol/tcltk/tcl8.3.0/sun5.7 --enable-gcc --verbose --enable-shared

  tk built this way
  ./configure  --prefix=/vol/tcltk/tk8.3.0/sun5.7 --with-tcl=/vol/tcltk/tcl/sun5.7/lib --enable-gcc --verbose --enable-shared

  This all built but when I run wish this comes out

  wish
  Application initialization failed: Can't find a usable tk.tcl in the following directories: 
      /vol/tcltk/tcl8.3.0/sun5.7/lib/tk8.3 /lib/tk8.3 /lib/tk8.3 /library /library /tk8.3/library /tk8.3/library

  This probably means that tk wasn't installed properly.

  It seems odd that wish didn't look in the tk path for the file.



  You just need to install Tk first, or set the TK_LIBRARY path
  in your shell temporarily to test.  The 'make test' will do
  this for you.  Tk is built such that it looks by default in
  the directory you would install it in. 
  -- 04/19/2000 hobbs


tkt_uuid: 220298ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: libtk8.3.so.1 fails on sunos 4.1.4
comment:
  OriginalBugID: 5180 Bug
  Version: 8.3
  SubmitDate: '2000-04-19'
  LastModified: '2000-04-20'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: SunOS
  OSVersion: sunos 4.1.4 y2k patched
  Machine: sparc 20
  ClosedDate: '2000-04-20'


  Name:
  Warren Dodge

  ReproducibleScript:
  doing  these configures
  ./configure  --prefix=/vol/tcltk/tcl8.3.0_tk8.3.0/sun5.7 --enable-gcc --verbose --enable-shared
  ./configure  --prefix=/vol/tcltk/tcl8.3.0_tk8.3.0/sun5.7 --with-tcl=/vol/tcltk/tcl8.3.0_tk8.3.0/sun5.7/lib --enable-gcc --verbose --enable-shared

  tcl goes fine
  tk goes fine up to libtk8.3.so.1

  ld -o libtk83.so.1.0 tk3d.o tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkClipboard.o tkCmds.o  tkColor.o tkConfig.o tkConsole.o tkCursor.o tkError.o tkEvent.o  tkFocus.o tkFont.o tkGet.o tkGC.o tkGeometry.o tkGrab.o tkGrid.o  tkMain.o tkObj.o tkOldConfig.o tkOption.o tkPack.o tkPlace.o  tkSelect.o tkUtil.o tkVisual.o tkWindow.o   tkUnix.o tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o  tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o  tkUnixFocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o  tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o  tkUnixSend.o tkUnixWm.o tkUnixXId.o tkStubInit.o tkStubLib.o tkButton.o tkEntry.o tkFrame.o tkListbox.o  tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o tkScale.o  tkScrollbar.o tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o  tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o  tkCanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o tkImgGIF.o tkImgPPM.o tkImgPhoto.o tkText.o tkTextBTree.o tkTextDis!
  p.o tkTextImage.o tkTextIndex.o  tkTextMark.o tkTextTag.o tkTextWind.o -L/vol/tcltk/tcl8.3.0_tk8.3.0/sun4/lib -L/vol/X.V11R6/R6_sun4/lib -lX11 -ldl -lm -lc

  All the -L and -l are not needed. They seem to cause a bunch of errors.
  tcl did not have them



  There are no errors provided in the report...  What is it that
  isn't working?  Does the ld succeed or not? 
  -- 04/20/2000 hobbs


tkt_uuid: 220299ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: block insertion cursor of text widget
comment:
  OriginalBugID: 5217 Bug
  Version: 8.3
  SubmitDate: '2000-04-20'
  LastModified: '2000-04-20'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2811
  OS: All
  ClosedDate: '2000-04-20'


  Name:
  Boris Gontar

  ReproducibleScript:
  text .t -width 40 -height 20 -font fixed
  set w [font measure fixed 0]
  .t config -insertbackground red -insertwidth $w -insertofftime 0 -insertborderwidth 0
  pack .t

  ObservedBehavior:
  The block insertion cursor does not fit to character cells, especially in the beginning of line

  DesiredBehavior:
  insertion cursor should cover the character cell



  The text widget insertion cursor is just that - an insertion
  cursor.  We have another RFE for a true blockcursor in 2811. 
  -- 04/20/2000 hobbs


tkt_uuid: 220300ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: Test suite failures may indicate serious series of problems in latest patched Tk
comment:
  OriginalBugID: 5399 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-09'
  LastModified: '2000-06-02'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: Solaris 2.6
  Machine: Ultra 5
  ClosedDate: '2000-06-02'


  Name:
  Larry W. Virden

  CVS:
  May 9, 2000, 10:16 am EDT

  Extensions:
  Tk

  CustomShell:
  Mirrored the CVS for tcl and tk.

  Comments:
  I'm using Solaris 2.6's CDE environment.

  ReproducibleScript:
  make test
  clipboard.test

  ==== clipboard-6.2 Tk_ClipboardAppend procedure FAILED
  ==== Contents of test case:

      setupbg
      clipboard clear
      clipboard append -f INTEGER -t TEST "16"
      set result [dobg {selection get -s CLIPBOARD TEST}]
      cleanupbg
      set result

  ---- Result was:
  CLIPBOARD selection doesn't exist or form "TEST" not defined
  ---- Result should have been:
  0x10
  ==== clipboard-6.2 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:
  .t {} {}
  ==== focus-5.1 FAILED

  unixEmbed.test
  X Error of failed request:  BadValue (integer parameter out of range for operati
  on)
    Major opcode of failed request:  53 (X_CreatePixmap)
    Value in failed request:  0x8
    Serial number of failed request:  117539
    Current serial number in output stream:  117542

  At this point, the test suite hangs...

  make: *** [test] Error 1
  ~

  DesiredBehavior:
  all test cases pass



  I cannot repeat these on our Solaris8 CDE environment. 
  -- 06/02/2000 hobbs


tkt_uuid: 220301ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: PHOTO images (GIF) load very slowly into widgets
comment:
  OriginalBugID: 5443 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-11'
  LastModified: '2000-05-18'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  OSVersion: 4.2.1
  Machine: RS/6000 Model R50  (200 Mhz x 8 cpu, 2 Gig memory)
  ClosedDate: '2000-05-18'


  Name: Bernie Ott

  Comments:
  Everything else in TCL and TK works great.

  ReproducibleScript:
  Loading a photo image (PPM or GIF) into a button or label widget takes a long time.
  A 640x480 256 color GIF image takes approximately 1.5 minutes to load.

  ObservedBehavior:
  Loading a photo image (PPM or GIF) into a button or label widget takes a long time.
  A 640x480 256 color GIF image takes approximately 1.5 minutes to load.

  DesiredBehavior:
  Loading of a photo image of size 640x480 should only take 1 or 2 seconds.



  I'm unable to reproduce such a slowdown here on AIX or other
  machines.  It's possible that the lack of -O by default for
  the Tk compile really slows things down.  You can actually
  use -O2, but -O reveals a bug in IBM's compiler. 
  -- 05/18/2000 hobbs


tkt_uuid: 220302ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: tk_getOpenFile won't cope with files with leading spaces
comment:
  OriginalBugID: 5478 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-12'
  LastModified: '2000-05-17'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0sp5
  ClosedDate: '2000-05-17'


  Name:
  Vince Darley

  Extensions:
  winico

  ReproducibleScript:
  # For Windows
  set desktop [file join $env(USERPROFILE) Desktop]
  # Create a file on the desktop with a leading space
  close [open [file join $desktop " leading-space"] w]
  # Select the file.  You get an error saying the file doesn't exist.
  set file [tk_getOpenFile -initialdir $desktop]

  ObservedBehavior:
  When the user tries to select the file with a space at the beginning of the name in the file chooser, an error message is given that the file doesn't exist.

  DesiredBehavior:
  I expect to be able to select the file named " leading-space" in the dialog.



  You'll have to complain to Microsoft about that, as it is a problem
  in the native dialog.  You'll see the same behavior using the dialog
  in Write or anything else.  The best thing to do is to never create
  a file with leading or trailing spaces on Windoze. 
  -- 05/17/2000 hobbs


tkt_uuid: 220303ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: strange namespace/upvar interaction.
comment:
  OriginalBugID: 5505 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-15'
  LastModified: '2000-05-15'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0sp5
  ClosedDate: '2000-05-15'


  Name:
  Vince Darley

  ReproducibleScript:
  # weird namespace/upvar problem

  namespace eval foo {}
  namespace eval bar {}
  namespace eval cow {}

  set cow::one 2
  set bar::one 1

  # multiply, ensuring var exists.
  proc safemultiply {var by} { 
      upvar 1 $var local
      if {![info exists local]} { set local 1 }
      set local [expr {$local *$by}] 
  }

  proc foo::test {} { 
      global bar::one cow::one
      safemultiply bar::one 5
      puts "$bar::one $cow::one" 
  }

  # this works fine
  foo::test
  # result is '5 2' printed to stdout
  foo::test
  # result is '25 2' printed to stdout

  # Now unset the variable, and try again.
  # We expect to get '5 2' again, since
  # safemultiply ensures the variable is set.
  unset cow::one
  foo::test
  # but we get an error: 'can't read "cow::one": no such variable'

  ObservedBehavior:
  Behaviour is described in comments above.  I don't really know if it is a bug or not, but it is definitely rather confusing (and occured in my code, where I unfortunately had two variables named global::prefs and alpha::prefs).

  DesiredBehavior:
  I expected the final 'foo::test' to complete successfully.  Can someone explain this (and/or clarify whether it is a bug or not)?



  This is correct.  The user first mis-types the unset of bar::one,
  but even so, always referencing them relatively is the bug in the
  program. 
  -- 05/15/2000 hobbs


tkt_uuid: 220304ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: canvas command "postscript" generates almost-empty files
comment:
  OriginalBugID: 5523 Bug
  Version: 8.3
  SubmitDate: '2000-05-16'
  LastModified: '2000-05-17'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: HP-UX hpp020 B.10.20 A 9000/712
  ClosedDate: '2000-05-17'


  Name:
  Paul Sievers

  Extensions:
  tix.4.1.0

  CustomShell:
  None

  ReproducibleScript:
  set w .w5
  wm withdraw .
      toplevel $w
      wm title $w "data5"

      wm geometry   $w =600x600

  canvas .w5.msc    -width 288 -height 51        -background white 

  .w5.msc create rectangle 0 3 436 17 -fill lightyellow -outline lightyellow
  .w5.msc create text 2  4 -anchor nw -text "CB121VF\CP_P_EXEC_SFF_TRANSITION         CSF513D" -font -misc-fixed-bold-r-normal--15-120-100-100-c-90-iso8859-1 -fill black
  .w5.msc create rectangle 138 18 142 32 -fill white -outline white
  .w5.msc create text 140  19 -anchor nw -text "" -font -misc-fixed-bold-r-normal--15-120-100-100-c-90-iso8859-1 -fill black
  .w5.msc create line 189 38 90 38  -width 3  -arrow last -arrowshape {9 9 4} -fill black
  pack $w.msc  -side top    -fill both
      $w.msc postscript    -file "/tmp/bad12" -pagex 0.i -pagey 10.i -pageanchor nw
  The command line was: wish tiny.tcl

  ObservedBehavior:
  The generated postscript file  "/tmp/bad12"  is "almost-empty"
  The text "CB121VF\CP_P_EXEC_SFF_ ..." does not appear in the file.
  The bounding box has only 2x3 pixels, as can be seen from the line:
  %%BoundingBox: 0 719 1 721
  in file  "/tmp/bad12".

  DesiredBehavior:
  When printing the postscript file, I'd like to see graphics that look like the canvas on the screen.




  After customer submitted this bug he sent another reply:

  Ok. It's not really a bug. Using options -width and -heigth
  solves the problem.

  Bye
  Paul Sievers
   
  -- 05/16/2000 angie

  A note for using the above is also recommended in the docs
  of the canvas postscript command, so that's probably what
  the user needs to use more liberally. 
  -- 05/17/2000 hobbs


tkt_uuid: 220305ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: load image into tk: 2048x1536 with graphics board (using 32 bit)
comment:
  OriginalBugID: 5630 Bug
  Version: 8.0.3
  SubmitDate: '2000-05-22'
  LastModified: '2000-05-30'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  Machine: P III 500
  ClosedDate: '2000-05-30'


  Name:
  Michael Lukaschek

  ReproducibleScript:
  we try to display an image (2048x1536) 
  when calling the routine 'ImgPhotoSetSize(masterPtr, width, height)' in the file 'tkImgPhoto.c' 
  one of the next calls will be the loop:
      for (instancePtr = masterPtr->instancePtr; instancePtr != NULL;
      instancePtr = instancePtr->nextPtr) {
  ImgPhotoInstanceSetSize(instancePtr);
      }. 

  Inside this it crashes with the following messages:

  SCANWARE verursachte einen Fehler durch eine ungültige Seite
  in Modul TK80.DLL bei 0167:0041870f.
  Register:
  EAX=00000000 CS=0167 EIP=0041870f EFLGS=00010202
  EBX=00000000 SS=016f ESP=0070cb20 EBP=0070cb30
  ECX=00000000 DS=016f ESI=8193baf9 FS=1347
  EDX=005290a0 ES=016f EDI=00000000 GS=0000
  Bytes bei CS:EIP:
  83 39 02 75 4b 8b 55 fc 8b 42 08 89 45 f0 8b 4d 
  Stapelwerte:
  00000000 000017ae 004e04fc 00000000 0070cb58 00418865 005290a0 00000000 0070cb48 000017ae bff7b9c5 00000000 78037ca8 00000756 0070cbb8 0045e146 

  SCANWARE verursachte einen Fehler durch eine ungültige Seite
  in Modul TK80.DLL bei 0167:00449c5c.
  Register:
  EAX=00001777 CS=0167 EIP=00449c5c EFLGS=00010206
  EBX=10000000 SS=016f ESP=0070f88c EBP=0070f894
  ECX=0070fbbc DS=016f ESI=00000000 FS=1347
  EDX=00001777 ES=016f EDI=00000001 GS=0000
  Bytes bei CS:EIP:
  8b 48 08 3b 4d fc 75 0a 8b 55 f8 c7 42 08 00 00 
  Stapelwerte:
  00001777 005b2ee8 0070f918 0048dd2c 005a98e4 00000000 00010001 c8c40000 17870088 00000011 00000203 00000000 005290a0 00561010 00561010 0013019f 

  It is no problem to display an image of the same size having the other orientation (1536x2048) or
  to display the original image (2048x1536) running another color depth (16 bit)

  DesiredBehavior:
  display images of requested size



  This would have to be verified with 8.3.1, which has a rewritten
  image mechanism.  Also, it would be helpful if the offending
  image were made available on the web to verify on other machines. 
  -- 05/22/2000 hobbs
  This turned out to occur only in proprietary extension code.
  Img loaded the image just fine. 
  -- 05/30/2000 hobbs


tkt_uuid: 220306ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: None
resolution: Invalid
title: winfo enhancement request
comment:
  OriginalBugID: 5717 RFE
  Version: 8.3.1
  SubmitDate: '2000-05-25'
  LastModified: '2000-05-27'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  ClosedDate: '2000-05-27'


  Name:

  George Petasis



  DesiredBehavior:

  Two things:



  1) winfo istoplevel win

  Currently there is no easy way to find out if a window is a toplevel or not.

  I now use "if {[string equal [winfo toplevel $win] $win]} {-->> toplevel...",

  which is kind ackward...



  2) winfo toplevels

  An easy way to get all toplevels...





  It seems simple enough to say:
       if {[winfo toplevel $w] == $w} ...

  What is the purpose in getting all the toplevels? 
  -- 05/27/2000 hobbs


tkt_uuid: 220307ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: wish83 error for gets command
comment:
  OriginalBugID: 5828 Bug
  Version: 8.3
  SubmitDate: '2000-06-06'
  LastModified: '2000-06-06'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NT4.0 SP4
  Machine: Pentium
  ClosedDate: '2000-06-06'


  Name:
  Chang LI

  Extensions:
  Tcl/Tk 8.3

  Comments:
  wish82/83 has a problem to deal with the stdin 
      under windows. I guess it used a fake console
      on Win32 which can only do stdout. These may
      related to the new Tcl/Tk kernel for Windows.

  ReproducibleScript:
  wish82 and wish83 has an error to execute the command:

  %gets stdin
  %

  ObservedBehavior:
  it immediately returned without waiting the input characters.

  DesiredBehavior:
  in tclsh82/83 it is correctly waiting for the input characters
  and accept the character after the return key.



  This is a known issue, and relates to the fact that Window GUI
  apps don't have std console channels.  If you recompile with
  the console flags, it will work, but always pop up a DOS prompt
  to go with this.  There is just a fundamental incompatibility
  between using GUI apps and CLI driven apps. 
  -- 06/06/2000 hobbs


tkt_uuid: 220308ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.4a1
resolution: Invalid
title: Wish doesn't close cleanly when exited with the X box on the window manager
comment:
  OriginalBugID: 5932 Bug
  Version: 8.4a1
  SubmitDate: '2000-06-21'
  LastModified: '2000-09-05'
  Severity: LOW
  Status: Closed
  Submitter: shawn
  ChangedBy: hobbs
  OS: Windows 2000
  ClosedDate: '2000-09-05'


  Whe I run this - and close using the X widget on the window - the process keeps running - 

  To reproduce (Jeff - I will send you the app - or try /home/shawn/tktest/tktest.tcl - it very transient right now) run tktest.tcl and kill the app using the X box (typical windows stuff).  The process will still be running if viewed with the task manager. 

  So it eats a ton of resouces and hampers the machine. 

  I have to go and kill it - but if I execute an explcit exit command - it goes away 

  Workaround - use the WM DELETE binding and explicitly exit the program. 



  In thinking about this - I am wondering if this is the correct behavior - I have a loop that would continue running in the event loop - and I wonder if this might be more useful than my original thinking.  It could be useful in the case were I want to have a gui interface to a program that I wanted to keep running - such as the gui on tclhttpd - where I might want to close the gui but have the server continue to run. 

  -- 06/22/2000 shawn

  This sounds like the [X] box in questions isn't for the main toplevel,
  but a child one.  If it isn't '.', then wish won't exit. 
  -- 09/05/2000 hobbs


tkt_uuid: 220309ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: images can't be read
comment:
  OriginalBugID: 5961 Bug
  Version: 8.3.1
  SubmitDate: '2000-06-28'
  LastModified: '2000-06-30'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Digital Unix
  OSVersion: OSF1 alpha V4.0 1091
  ClosedDate: '2000-06-30'


  Name:
  Uwe Traum

  ReproducibleScript:
  It was not possible to load images into tk.
  (Example filebox: make test fails)

  Error: Cannot recognize image data

  This only occurs for Digital-Unix. SunOS works

  ObservedBehavior:
  Error: Cannot recognize image data



  The C compiler on Digital Unix does not properly recognize the hexadecimal syntax used to #define the GIF87a and GIF89a header strings.  We have already addressed this issue in the source code; that fix will go out with Tcl/Tk 8.3.2.  In the meantime, you can fix the problem locally by specifying the "-std" flag to the C compiler and recompiling Tk.

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

  -- 06/30/2000 ericm


tkt_uuid: 220310ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: App gives "Tk_FreeCursor called before Tk_GetCursor" and core dumps on exit.
comment:
  OriginalBugID: 5962 Bug
  Version: 8.3
  SubmitDate: '2000-06-28'
  LastModified: '2000-06-30'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: HP-UX
  OSVersion: HP-UX 10.20
  ClosedDate: '2000-06-30'


  Name:
  John McNeill

  Extensions:
  DMH

  Comments:
  The application was developed using Visual Tcl on Windows NT and ftp'ed
      to the HP-UX.  Another application developed and transferred the same
      way does not display this error.

  ReproducibleScript:
  We invoke wish8.3 to run an application. (wish8.3 <app name> from the command line)

  ObservedBehavior:
  On exit, the application displays "Tk_FreeCursor called before Tk_GetCursor" and core dumps.

  DesiredBehavior:
  No message; no core dump



  There was a particular bug in 8.3.0 relating to configuring the cursor of a listbox, and then destroying the listbox, which caused a core dump and may cause a message like the one you see.  The workaround was to unconfigure the cursor, ie:

  listbox .l
  .l configure -cursor crosshair
  .l configure -cursor {}
  exit

  will not cause the coredump.  The bug was fixed in 8.3.1; I recommend you upgrade to that version, or wait for 8.3.2, which should be released in 2-3 weeks.

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

  -- 06/30/2000 ericm


tkt_uuid: 220311ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 57. [option]
priority: 1 Zero
foundin: None
resolution: Invalid
title: option clear command apparently reads the ~/.Xdefaults file
comment:
  OriginalBugID: 5963 Bug
  Version: 8.3
  SubmitDate: '2000-06-29'
  LastModified: '2000-08-14'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows NT
  Machine: Dell OptiPlex GX1
  ClosedDate: '2000-08-14'


  Name:
  Allen Flick

  Comments:
  Although, in my example under Windows, TclTk is accessing the
      ~/.Xdefaults file, which is a Unix
      thing, I'd like to see it remain in future releases.  This would make Tk
      truly platform independent,
      and if Tk under Unix accesses this file a second time (since X does it
      in Unix) and that's deemed
      to be a problem for some reason, it wouldn't be too hard to check the
      platform type.  That's built
      right into TclTk anyway.

  ReproducibleScript:
  Within a *wish8.3*, at the console.

  % pack [button .b1 -text Button1]
  % pack [button .b2 -text Button2 -bg red]
  % pack [button .b3 -text Button3]
  % option add *Button.background blue
  % option add *Button.foreground yellow
  % pack [button .b4 -text Button4]
  % option clear
  % pack [button .b5 -text Button5]
  % option clear

  At this point I had to rename my ~/.Xdefaults file, so it wouldn't be reread.

  % pack [button .b6 -text Button6]
  % pack [button .b7 -text Button7]
  % option clear
  % pack [button .b8 -text Button8]
  %

  ObservedBehavior:
  After each *option clear* command, the default background was apparently taken from the
  ~/.Xdefaults file, as it was always reset to cyan except for the one time I renamed the
  ~/.Xdefaults file, temporarily.

  DesiredBehavior:
  I would expect to see the option database all cleared as manual states, and if
  the ~/.Xdefaults file is to be accessed as described in the manual (for Unix)
  then it do so as the manual states, the *next* time the database is accessed.



  The option database is implicitly accessed whenever a widget is created.  The behavior you are seeing is therefore consistent with the documentation:  [option clear] clears the database, and the next time the database is accessed (when the next widget is created), .Xdefaults is reread.

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

  -- 08/14/2000 ericm


tkt_uuid: 220312ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: Compiling fails for Tk 8.3.1
comment:
  OriginalBugID: 5976 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-06'
  LastModified: '2000-08-14'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Linux
  OSVersion: TurboLinux 6.x
  Machine: custom built AMD K6/450 64 MB RAM, 2 IDE 2 SCSI hard drives, SiS
  ClosedDate: '2000-08-14'


  Name:
  John Buell

  ReproducibleScript:
  Tcl 8.3.1 is already compiled, cannot compile Tk 8.3.1.
  System is TurboLinux 6.x running 2.2.14 kernel and 2.95.3 gcc. 
  Ran this command for configuration:
  ./configure --with-tcl=/root/Software/tcl8.3.1/unix/ --enable-gcc
  then invoked GNU make (3.78.1) with 'make'

  ObservedBehavior:
  received this a couple of times:
  gcc -pipe -c -O -D__NO_STRING_INLINES -D__NO_MATH_INLINES -Wall -Wconversion -Wno-implicit-int -fPIC -I/root/Software/tk8.3.1/unix -I/root/Software/tk8.3.1/unix/../generic -I/root/Software/tk8.3.1/unix/../bitmaps -I/root/Software/tcl8.3.1/generic -I/usr/X11R6/include -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1      -DTCL_NO_DEPRECATED   /root/Software/tk8.3.1/unix/../generic/tkCanvPs.c
  {standard input}: Assembler messages:
  {standard input}:4160: Error: no such 386 instruction: `filds'
  {standard input}:4165: Error: no such 386 instruction: `filds'
  {standard input}:4170: Error: no such 386 instruction: `filds'
  {standard input}:4278: Error: no such 386 instruction: `filds'
  {standard input}:4283: Error: no such 386 instruction: `filds'
  {standard input}:4288: Error: no such 386 instruction: `filds'
  {standard input}:4441: Error: no such 386 instruction: `filds'
  {standard input}:4446: Error: no such 386 instruction: `filds'
  {standard input}:4451: Error: no such 386 instruction: `filds'
  make: *** [tkCanvPs.o] Error 1

  This error also crops up if I do NOT specify the --enable-gcc flag for 'configure'

  DesiredBehavior:
  A compiled working copy of Tk 8.3.1 :)



  This looks like a compiler problem, because there is no inlined assembly code in the Tcl/Tk core.  It looks like the compiler is producing bad assembly.  We use gcc 2.91.66 to do our compiles on Linux and we have no problems with that.  I suggest that you try that compiler.

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

  -- 08/14/2000 ericm


tkt_uuid: 220313ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: wm deiconify doesn't preserve stacking order of windows not directly involved
comment:
  OriginalBugID: 5977 Bug
  Version: 8.2
  SubmitDate: '2000-07-06'
  LastModified: '2000-07-20'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: 4.0 SP4
  Machine: Compaq Armada M700
  ClosedDate: '2000-07-20'


  Name:
  Shaun Lowry

  Extensions:
  none needed

  Comments:
  I don't think this is standard for window managers on any platform

  ReproducibleScript:
  toplevel .first
  toplevel .second
  wm deiconify .second

  ObservedBehavior:
  .first goes behind . when .second is deiconified

  DesiredBehavior:
  .second should come to the top, the relative stacking order of all other windows should remain the same



  I am unable to reproduce this behavior with Windows NT4, with either Tcl 8.2.3 or 8.3.0.  You specified version 8.2, by which I assume you mean 8.2.0, which I don't have handy for testing.  It seems this problem was corrected by 8.2.3 in any case.

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

  -- 07/20/2000 ericm


tkt_uuid: 220314ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: tkimage copy -subsample ... does not work
comment:
  OriginalBugID: 5979 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-06'
  LastModified: '2000-08-21'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows 98
  Machine: P II 500
  ClosedDate: '2000-08-21'


  Name:
  Michael Lukaschek

  ReproducibleScript:
  mZI copy DstImg -subsample $samplex $samplex -to  [expr ([image width mZI]-[image width DstImg]/$samplex)/2]  [expr ([image height mZI]-[image height DstImg]/$samplex)/2]

  ObservedBehavior:
  the result is an image having mixed channels

  maybe this is a conflict with the old 3 band image handling and the new 4-band one

  DesiredBehavior:
  Another command does work on the new tkimage format:
  DstImg copy ZI -zoom $ZIF -from $ZIXS $ZIYS $ZIXE $ZIYE

  Maybe the subsample option is not maintained any longer?



  I am unable to reproduce this problem.  If possible, please send us a copy of the image you are using and the exact values you are using with the -subsample option (that is, the value of the samplex variable in your sample script).  Thanks,

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

  -- 08/21/2000 ericm


tkt_uuid: 220315ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.4a1
resolution: Invalid
title: Tk accepts invalid window name!
comment:
  OriginalBugID: 5980 Bug
  Version: 8.4a1
  SubmitDate: '2000-07-06'
  LastModified: '2000-09-26'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  ClosedDate: '2000-09-26'


  Name:

  Mo DeJong



  CVS:

  Mon Jul  3



  Comments:

  I also bumped up the FIXED_SIZE, used it in both places and

      undefined it when done. This one should be a no-brainer.



  ReproducibleScript:

  toplevel .t

  button .t.



  DesiredBehavior:

  The button window name is not valid, Tk should report an error.



  Patch:

  Index: generic/tkWindow.c

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

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

  retrieving revision 1.18

  diff -u -r1.18 tkWindow.c

  --- tkWindow.c2000/05/29 01:43:141.18

  +++ tkWindow.c2000/07/03 13:58:19

  @@ -747,6 +747,7 @@

       Tcl_SetHashValue(hPtr, winPtr);

       winPtr->pathName = Tcl_GetHashKey(&parentPtr->mainPtr->nameTable, hPtr);

       return TCL_OK;

  +#undef FIXED_SIZE

   }

   

   /*

  @@ -1004,8 +1005,8 @@

    * new window;  window will be a top-level

    * window. */

   {

  -#define FIXED_SPACE 5

  -    char fixedSpace[FIXED_SPACE+1];

  +#define FIXED_SIZE 200

  +    char fixedSpace[FIXED_SIZE+1];

       char *p;

       Tk_Window parent;

       int numChars;

  @@ -1016,17 +1017,19 @@

        * copy the parent's name somewhere else to avoid modifying

        * the pathName string (for large names, space for the copy

        * will have to be malloc'ed);  (b) must special-case the

  -     * situation where the parent is ".".

  +     * situation where the parent is "."; (c) Watch out for the

  +     * other spacial case where the child window is named ".",

  +     * this can happen if a button is named ".t." for instance.

        */

   

       p = strrchr(pathName, '.');

  -    if (p == NULL) {

  +    if (p == NULL || ((p[0] == '.' && p[1] == '\0') && (p != pathName))) {

   Tcl_AppendResult(interp, "bad window path name \"", pathName,

   "\"", (char *) NULL);

   return NULL;

       }

       numChars = p-pathName;

  -    if (numChars > FIXED_SPACE) {

  +    if (numChars > FIXED_SIZE) {

   p = (char *) ckalloc((unsigned) (numChars+1));

       } else {

   p = fixedSpace;

  @@ -1082,6 +1085,7 @@

   return CreateTopLevelWindow(interp, parent, pathName+numChars+1,

   screenName);

       }

  +#undef FIXED_SIZE

   }

   

   /*

  Index: tests/window.test

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

  RCS file: /cvsroot/tk/tests/window.test,v

  retrieving revision 1.4

  diff -u -r1.4 window.test

  --- window.test1999/04/16 01:51:441.4

  +++ window.test2000/07/03 13:58:20

  @@ -41,6 +41,26 @@

   "button .t.b -text hello"

       (command bound to event)}}

   

  +

  +test window-1.2 {Tk_CreateWindowFromPath procedure, invalid window name} {

  +    catch {destroy .t}

  +    toplevel .t

  +    list [catch {button .t.} err] $err

  +} {1 {bad window path name ".t."}}

  +

  +test window-1.3 {Tk_CreateWindowFromPath procedure, invalid window name} {

  +    catch {destroy .t}

  +    toplevel .t

  +    list [catch {button .t..} err] $err

  +} {1 {bad window path name ".t.."}}

  +

  +test window-1.4 {Tk_CreateWindowFromPath procedure, invalid window name} {

  +    list [catch {button ..} err] $err

  +} {1 {bad window path name ".."}}

  +

  +

  +catch {destroy .t}

  +

   # Most of the tests below don't produce meaningful results;  they

   # will simply dump core if there are bugs.



  PatchFiles:

  generic/tkWindow.c

      tests/window.test





  While admittedly odd, there is nothing wrong with this.  Simple
  tests show that using the empty string for a name works:

  >Main< () 49 % toplevel .t
  .t
  >Main< () 50 % button .t.
  .t.
  >Main< () 51 % pack .t.
  >Main< () 52 % .t. configure -text hello
  >Main< () 53 % .t. cget -text
  hello

  I believe this is OK, as we also allow things like variables to
  be the empty string.  Unless this specifically breaks some element
  of Tk, we should just leave it.  Hmmm, to think of the obfuscation
  possibilities of create some window named ..... 
  -- 09/26/2000 hobbs


tkt_uuid: 220316ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: Cannot load gif files with the "image create photo" command
comment:
  OriginalBugID: 6010 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-13'
  LastModified: '2000-07-17'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Digital Unix
  OSVersion: Tru64 Unix V4.0F
  Machine: Compaq Professional Workstation XP1000
  ClosedDate: '2000-07-17'


  Name:
  Mario Vincent

  CVS:
  RCS: @(#) $Id: tkImgGIF.c,v 1.14 2000/03/30 19:44:41 ericm Exp

  ReproducibleScript:
  I compiled tk on Tru64 Unix V4.0F. ( Digital Unix is now called Tru64 Unix)
  This bug is in the code of tkImgGIF.c.
  Look at lines 75 and 76
  #  define GIF87a         "\x47\x49\x46\x38\x37\x61" /* ASCII GIF87a */
  #  define GIF89a         "\x47\x49\x46\x38\x39\x61" /* ASCII GIF89a */
  Apparently the \xnn representation is not being converted into proper strings, so the strncmp (later)
  fails.

  I replaced by the octal representation, recompiled and it works.
  //#  define GIF87a         "\x47\x49\x46\x38\x37\x61" /* ASCII GIF87a */
  #  define GIF87a         "\107\111\106\070\067\141" /* ASCII GIF87a */
  //#  define GIF89a         "\x47\x49\x46\x38\x39\x61" /* ASCII GIF89a */
  #  define GIF89a         "\107\111\106\070\071\141" /* ASCII GIF89a */

  Maybe theres a hook u can pass to the compiler or something which will make this kind of string
  acceptible.. I dont know. 
  Thanks and regards,
  Mario



  We are aware of this problem, and the code has been fixed in 8.4; the defines were replaced with static character arrays:

  static CONST char GIF87a[] =
          { 0x47, 0x49, 0x46, 0x38, 0x37, 0x61, 0x00 }; /* ASCII GIF87a */
  static CONST char GIF89a[] =
          { 0x47, 0x49, 0x46, 0x38, 0x39, 0x61, 0x00 }; /* ASCII GIF89a */

  Thanks,

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

  -- 07/17/2000 ericm


tkt_uuid: 220317ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: bug on TkFontPkgFree()--tkFont.c:290
comment:
  OriginalBugID: 6030 Bug
  Version: 8.0.5
  SubmitDate: '2000-07-20'
  LastModified: '2000-07-20'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Solaris
  ClosedDate: '2000-07-20'


  Name:
  Frank Shi

  ReproducibleScript:
  This bug was captured when running graphics-intensive applications(wriiten in tcl/tk).

  ObservedBehavior:
  painc: all fonts should have been freed already

  core dump

  DesiredBehavior:
  When the applications exit, there should be such warning and core dump.



  We need a little more information than this if we are to be able to debug the problem at all.  The most helpful thing would be for you to distill the problem down to a relatively small script which reliably demonstrates the bug.  Barring that, any information you can provide regarding the application (what it was does, particularly with respect to fonts, specifically what it was doing at the time of the core dump, etc.) will be helpful.

  Thanks,

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



  -- 07/20/2000 ericm


tkt_uuid: 220318ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Invalid
title: Prepare geometry managers for labeled frames.
comment:
  OriginalBugID: 6059 RFE
  Version: 8.4a1
  SubmitDate: '2000-07-26'
  LastModified: '2000-09-05'
  Severity: LOW
  Status: Closed
  Submitter: angie
  ChangedBy: ericm
  OS: Windows 98
  ClosedDate: '2000-09-05'


  Tk 8.4a1 Request

  Name:  Peter Spjuth
  email:  peter.spjuth@space.se
  Support:  None
  CVS:  2000-07-25
  OperatingSystem:  Windows 98
  Synopsis:  Prepare geometry managers for labeled frames.

  DesiredBehavior:

  This patch adds support for having different internalBorderWidths on
  different sides of a window. It includes changes to the TkWindow struct
  and to geometry managers and other users of that information.

  This is a preparation for adding labels to frames, and I have made it
  a separate patch since it involves seperate files from the other
  changes, and since it involves a backward incompatibility and thus
  needs some extra thinking.

  The patch adds a new function to TkGeometry.c, Tk_SetInternalBorderEx.
  This function also needs to be added to tk.decls and tkDecls.h, and that
  change is not included in the patch since I don't know the proper way to
  do that.

  To be as backward compatible as possible, I have avoided moving things
  around in TkWindow by keeping the old internalBorderWidth field where it was,
  and added the new fields to the end.
  I have marked the old field as deprecated, but was not sure what to do
  with it. I choose to change its name to internalBorderWidthOld to keep
  anyone from accidentally using it.

  The man pages probably need some work, since I'm far from good at such stuff.


  Patch:
  The diffs can be found at:
  http://www.dtek.chalmers.se/~d1peter/borderpatch.zip

  Patched versions of the files can be found at:
  http://www.dtek.chalmers.se/~d1peter/borderpatch2.zip



  From the submitter:

  Hi!

  I'd just like to say that you can throw out RFE 6059 (and
  the related RFE which I don't have a number on).
  Paul's proposal in c.l.t. is better and I'll prepare
  a new patch for that.

  --

  - eric
   
  -- 09/05/2000 ericm


tkt_uuid: 220319ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: Photos render very slowly into widgets
comment:
  OriginalBugID: 6089 Bug
  Version: 8.3.1
  SubmitDate: '2000-08-09'
  LastModified: '2000-08-09'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Digital Unix
  OSVersion: Digital Unix OSF1 Version 4.0
  Machine: Digital Alpha
  ClosedDate: '2000-08-09'


  Name:
  Thomas Wu

  CustomShell:
  None

  Comments:
  I noted a related bug #5443 in your database.  I compiled Tcl/Tk 8.3.1
      using the flags "-O -std".  I tried smaller photos, and found that the
      times were roughly proportional to the number of pixels, averaging about
      330 microseconds per pixel  (example data: a 128 x 128 PPM takes 3692156
      microseconds, a 256 x 256 PPM takes  18611448 microseconds).  Displaying
      images on a Tk canvas widget is also similarly slow.

  ReproducibleScript:
  ruby> wish8.3
  % image create photo foo -file twocolor.gif
  foo
  % image height foo
  475
  % image width foo
  608
  % time {label .l1 -image foo}
  102508884 microseconds per iteration
  % 
  % image create photo bar -file twocolor.ppm
  bar
  % time {label .l2 -image bar}
  93178827 microseconds per iteration

  ObservedBehavior:
  Operation requires over a minute to run.  Occurs for both PPM and GIF files.

  DesiredBehavior:
  Operation should take only a few seconds, especially on a fast (DEC Alpha) Unix machine.



  I have an update to this bug posting.  It appears that the speed of
  photo rendering depends on the speed of the X server.  The slow speed
  came from an X server on a Macintosh connected to a Unix machine over
  a DSL line.

  When I connect using a direct Ethernet connection, the rendering speed 
  is much faster (a few seconds).

  Thanks,
   
  -- 08/09/2000 angie

  Sounds like the user solved his own problem.

  - eric
   
  -- 08/09/2000 ericm


tkt_uuid: 220320ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 1 Zero
foundin: obsolete: 8.4a1
resolution: Invalid
title: tk_chooseDir causes Invalid Page Fault
comment:
  OriginalBugID: 6091 Bug
  Version: 8.4a1
  SubmitDate: '2000-08-09'
  LastModified: '2000-08-09'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows 95
  Machine: Pentium/200, K6-2/400
  ClosedDate: '2000-08-09'


  Name:
  Malcom Terry

  Extensions:
  Tk

  Comments:
  The problem occurs on Tcl/Tk version 8.3 as well. Upgrading to Windows
      98 appears to fix the problem. However, there are hundreds of PC's in
      our factory that would need an upgrade. A fix of Tcl/Tk would be
      preferred.

  ReproducibleScript:
  On a Windows 95 system, enter tk_chooseDir in the wish console. This will cause the wish to crash with an invalid page fault. Sometimes requires a re-boot.

  ObservedBehavior:
  WISH84 caused an invalid page fault in
  module TK84.DLL at 0137:00419fe4.
  Registers:
  EAX=0000180f CS=0137 EIP=00419fe4 EFLGS=00010246
  EBX=0072d53a SS=013f ESP=0072d3ac EBP=0072d4dc
  ECX=0000180f DS=013f ESI=0072d55e FS=0d1f
  EDX=00000489 ES=013f EDI=00020000 GS=0000
  Bytes at CS:EIP:
  89 51 04 33 c0 e9 ea 01 00 00 8b 45 e0 81 78 04 
  Stack dump:
  0000000a 00000010 00000001 0072d40c 00515998 0072d734 
  00008758 0072d6e8 63de0f34 207e0fb9 00000102 00000000 
  6400030f 02f78717 bff74277 04426261 

  WISH84 caused an invalid page fault in
  module TK84.DLL at 0137:004616f6.
  Registers:
  EAX=0072fac0 CS=0137 EIP=004616f6 EFLGS=00010202
  EBX=10000000 SS=013f ESP=0072faf4 EBP=0072fb00
  ECX=00000002 DS=013f ESI=00000000 FS=0d1f
  EDX=00000002 ES=013f EDI=00000001 GS=0000
  Bytes at CS:EIP:
  8b 42 08 3b 45 f8 75 0a 8b 4d f4 c7 41 08 00 00 
  Stack dump:
  00000002 00596fe0 005036c8 0072fb88 004b3d9d 00969a54 
  00000000 bff7928f 0096ae54 00000000 00000011 000002da 
  00000000 005430e8 00597980 00597980



  This is definately a Win95 bug.  According to the MSDN documentation for the functions used to make the dialog, the lCustData field is to be used by the application for application-specific data that must be passed between the dialog display and the message handler for the dialog.  Win95 is plainly violating that by overwriting the field.

  There is no way to work around this problem from Tk; the Windows API is simply broken.  You can fix it by upgrading to Windows 98/NT/2000, as you have already discovered, or by getting a new version of the common dialog files.  On our test machines, I was able to copy c:\windows\comdlg32.* from a Windows 98 machine to our Windows 95 machine, and this solved the problem.

  Alternatively, you could use the UNIX version of the choose directory dialog.  This dialog is implemented in pure Tk.  Add the following code to enable this:

  rename tk_chooseDirectory ""
  proc tk_chooseDirectory {args} {
      return [eval ::tk::dialog::file::chooseDir::tkChooseDirectory $args]
  }

  I'm sorry we can't be of more assistance.

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

  -- 08/09/2000 ericm


tkt_uuid: 220321ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: dialog does not appear if . withdrawn
comment:
  OriginalBugID: 6094 Bug
  Version: 8.3.1
  SubmitDate: '2000-08-09'
  LastModified: '2000-08-09'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  Machine: Pentium II
  ClosedDate: '2000-08-09'


  Name:
  Bjoern Ruff

  CVS:
  30-July-2000

  Extensions:
  itcl

  ReproducibleScript:
  proc dia {} {
  set dialog [iwidgets::messagedialog .deleteTracks -title "Messagedialog" -text "Hi!"  -bitmap questhead -modality application]

  $dialog center
  update idletasks
  $dialog activate
  destroy $dialog
  }

  # change 30 to 31 or vice versa
  load itcl31
  load itk31
  package require Iwidgets 3.0
  namespace import itcl::*
  namespace import itk::*

  toplevel .top

  button .top.b -text Dialog -command dia
  button .top.e -text End -command "destroy ."

  pack .top.b
  pack .top.e

  #
  # wm withdraw .   works with 8.0.5 but not with 8.3.1
  # if . withdrawn the messagedialog will not appear
  #
  wm withdraw .

  focus .top
  wm deiconify .top
  update

  ObservedBehavior:
  When pressing the Dialog Button the Dialog does not appear
  when using 8.3.1
  ok when using 8.0.5



  8.3 corrected the behavior of transients in Tk to correctly
  follow the style for MS Windows transients - if the parent is
  not shown, the child should not be shown.  This requires more
  correct coding in your applications (it is no longer acceptable to
  expect a transient of a withdrawn window to be visible).

     Eric Melski                            The Other Tcl Guy
     ericm at ajubasolutions.com            Ajuba Solutions
   
  -- 08/09/2000 ericm


tkt_uuid: 220322ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.3.2
resolution: Invalid
title: wish logs me out
comment:
  OriginalBugID: 6136 Bug
  Version: 8.3.2
  SubmitDate: '2000-08-16'
  LastModified: '2000-08-16'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: AIX
  OSVersion: AIX 4.3.3.0
  Machine: IBM SP2
  ClosedDate: '2000-08-16'


  Name:
  Tony Curtis

  ReproducibleScript:
  $ wish

  ObservedBehavior:
  Running wish from login shell brings up main window but causes immediate logout.

  But...starting a new xterm, and running wish there, works fine

  Compiled with IBM cc compiler, default configure (no threads)

  DesiredBehavior:
  $ wish
  [ window appears ]
  % exit
  $



  There is nothing in the core code that would cause this.  I suspect that there is some problem with your system configuration.  You should talk to your system administrator for assistance.

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

  -- 08/16/2000 ericm


tkt_uuid: 220323ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: menu entrycget and entrycofigure failw above separator
comment:
  OriginalBugID: 6139 Bug
  Version: 8.3
  SubmitDate: '2000-08-16'
  LastModified: '2000-08-16'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows 98
  OSVersion: work; NT 4.00.1381  home:?
  Machine: work: Fujitsu  home: Siemens Gujitsu
  ClosedDate: '2000-08-16'


  Name:
  Agnar Renolen

  CVS:
  May/June 2000.

  ReproducibleScript:
  wm withdraw .
  console show

  toplevel .w -menu .w.mb
  menu .w.mb
  .w.mb add cascade -label MyMeny -menu .w.mb.m1
  menu .w.mb.m1 -tearoff 0
  .w.mb.m1 add command -label "Hello" -command {puts [.w.mb.m1 entrycget  0 -label]}
  .w.mb.m1 add command -label "World" -command {puts [.w.mb.m1 entrycget  1 -label]}
  .w.mb.m1 add separator
  .w.mb.m1 add command -label "My" -command {puts [.w.mb.m1 entrycget  3 -label]}
  .w.mb.m1 add command -label "Name" -command {puts [.w.mb.m1 entrycget  4 -label]}
  .w.mb.m1 add command -label "is" -command {puts [.w.mb.m1 entrycget  5 -label]}
  .w.mb.m1 add command -label "Agnar" -command {puts [.w.mb.m1 entrycget  7 -label]}
  .w.mb.m1 add separator
  .w.mb.m1 add command -label "Exit" -command {exit}

  ObservedBehavior:
  When selecting the "Agnar" menu item, i get:
   Error: Unknown option "-label"

  Stack trace:

  unknown option "-label"
      while executing
  ".w.mb.m1 entrycget  7 -label"
      (menu invoke)

  An application I'm developing at home, generated an error for all menu items above separator lines.  I have Window 98 at home.

  I have Windows NT at work, and here I only got an error for the "Agnar" item. The "World" item works correctly(??)

  This makes it pretty hard to disable the "Agnar" menu item, as the entryconfigure command produced the exact same result.



  This is likely because in the command for the "Agnar" entry, you have
  indicated entry number 7, which corresponds to the separator entry,
  instead of entry number 6, which corresponds to the "Agnar" entry.  When I
  modified the command for the "Agnar" entry like this:

  .w.mb.m1 entryconfigure 6 -command {puts [.w.mb.m1 entryconfigure 6 -label]}

  It works as expected.

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

   
  -- 08/16/2000 ericm


tkt_uuid: 220324ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 59. [tk_focus*]
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: Option -takefocus doesn't work if option parameter is a command with parameter(s)
comment:
  OriginalBugID: 6209 Bug
  Version: 8.3.1
  SubmitDate: '2000-09-05'
  LastModified: '2000-09-05'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 5372
  OS: Windows NT
  Machine: Pentium II 450MHz, NT 4.0
  ClosedDate: '2000-09-05'


  Name:
  Jostein Bo

  Comments:
  I hope to get a feedback on this report, with a confirmation that this
      bug is registered and information whether there exists a workaround. I
      have based my code on this logic and have to do a redesign if I cannot
      use a takefocus command with a callback scripts including parameters.

  ReproducibleScript:
  proc focusB2 { first widget } {
     puts $first
     puts $widget
     return 1
  }

  button .b1 -text "Dummy"
  button .b2 -text "Exit" -takefocus "focusB2 first" -command exit
  pack .b1 .b2

  ObservedBehavior:
  When using TAB key to set focus to the Exit-button, the following error occurs:

  invalid command name "focusB2 first"
      while executing
  "{focusB2 first} .b2"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list $value $w"
      (procedure "tkFocusOK" line 9)
      invoked from within
  "tkFocusOK $cur"
      (procedure "tk_focusNext" line 36)
      invoked from within
  "tk_focusNext .b1"
      invoked from within
  "tkTabToWindow [tk_focusNext .b1]"
      (command bound to event)

  DesiredBehavior:
  I should get no error. The scripts runs as expected on Unix with Tcl/Tk 8.2.
  If I remove the parameter "first" in focusB2 it works OK.



  From Nemethi:

  This bug was introduced in Tk 8.3.1 (see Bug Report #5372) and is
  fixed in Tk 8.3.2.  If you don't want to upgrade to the new version,
  just replace line 139 of the library file "focus.tcl" with

       set value [uplevel #0 $value [list $w]] 
  -- 09/05/2000 hobbs


tkt_uuid: 220325ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 50. [pack]
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: Button never gets created if it is initially off-screen
comment:
  OriginalBugID: 6299 Bug
  Version: 8.0.5
  SubmitDate: '2000-09-22'
  LastModified: '2000-09-24'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Linux-Red Hat
  OSVersion: RedHat Linux 6.2
  Machine: Custom assembled Dual Intel Xeons or Micron Intel Pentium II
  ClosedDate: '2000-09-24'


  Name:
  Charles Shartsis

  Extensions:
  As you can see from the sample script, none.

  CustomShell:
  None

  ReproducibleScript:
  Test Script:

  #!/bin/sh
  # Run wish from the PATH  exec wish -f "$0" ${1+"$@"}

  #set height 30
  set height 200

  listbox .scrollBox -width 70 -height $height
  button .ok -text OK -command exit
  pack .scrollBox .ok

  Copy above to test.tcl and run test.tcl.  On most resolutions, the bottom of the window will appear below the screen.  Manually resize to fit within screen boundaries and note that  no OK button appears.  Switch the comment symbol on the "set height" statements so that height gets set to 30 and run it again.  On most resolutions the window will fit within the screen boundaries and the OK button will appear.

  ObservedBehavior:
  When the initial window fits within screen boundaries, the OK button appears and works fine.  When the initial window extends below the bottom of the screen, the OK button is not visible even when the window is manually resized to fit within screen boundaries.

  DesiredBehavior:
  All widgets should be visible when their containing window is resized to fit within the screen boundaries.  The OK button should be visible when the window is resized.



  This is not a bug, but a misunderstanding of how geometry management works in Tk.

  What you have done in your sample script is request that the listbox be very large; too large, in fact, to be displayed in its entirety.  Tk draws as much of the listbox as possible, and "clips" the rest.  The button, since it is drawn below the listbox, is not visible:  the listbox has "pushed" it off the visible screen.

  When you resize the window containing these widgets, you are just changing the visible space, not necessarily resizing the widget.

  Typically, people will set minimum height and width values for their widgets, and then, when [pack]ing them, they will specify that the widget should grow to fill an extra space that is made available.  When you do this, the widgets will resize themselves in the manner you expect as you resize the window containing them.  Try the following:

  listbox .scrollbox -width 10 -height 5
  button .ok -text OK -command exit
  pack .scrollbox -expand yes -fill both
  pack .ok

  Now, when you resize the window, the listbox will grow and shrink accordingly.  Note that the listbox will not shrink smaller than the width and height specified.  If you try to make the window smaller than that, the listbox will again be clipped by the borders of the window.

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

  -- 09/24/2000 ericm


tkt_uuid: 220326ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.3.2
resolution: Invalid
title: X server hangs when doing make test
comment:
  OriginalBugID: 6325 Bug
  Version: 8.3.2
  SubmitDate: '2000-09-29'
  LastModified: '2000-10-18'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Digital Unix
  OSVersion: 4.0f + patch (duv40f0004)
  Machine: DMCC - Alpha
  ClosedDate: '2000-10-18'


  Name:
  Tupone Alfredo

  Comments:
  I think the X server shipped with the O.S. is bugged

  ReproducibleScript:
  Just run make test!
  The last line is 
  unixMenu

  ObservedBehavior:
  When the script create a menu with the font "Helvectica 72" (I thing is a typo), and try that => tkTearOffMenu .m1 40 40

  the X server stays in a dead loop (consuming CPU, 97-98 %) and the only way to resume it is to kill the X server from another terminal.



  From comp.lang.tcl:

  Andreas Leitgeb wrote:

  > >ObservedBehavior:
  > >When the script create a menu with the font "Helvectica 72"
  > > (I thing is a typo), and try that => tkTearOffMenu .m1 40 40
  >
  > 72 is indeed quite large, but not too large.
  >
  > I once used large fonts in Tcl/Tk (size 256 !), and it took my X-server
  > almost a minute to display them. (until that it was not responsive, and
  > likely ate a lot of CPU-percentage ...)
  >
  > how long did you wait, before you killed it, and how fast is your machine ?

  I wait a long time, before killing the X-Server.  My machine is an Alpha 500 Mhz.  I saw that the procedure consuming that large amount of CPU are the one related to the graphic board - Elsa 8 Mb.  I have another machine with a different kind of board, a PowerStorm 4D20T, and all seems ok.

                                                                      Alfredo
  ---------------

  This does sound like a buggy X Server.  Contact the OS vendor to report the bug.

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

  -- 10/18/2000 ericm


tkt_uuid: 220327ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 1 Zero
foundin: obsolete: 8.3.2
resolution: Invalid
title: -cursor "c:/my temp/mycursor.cur" fails due to space in path
comment:
  OriginalBugID: 6343 Bug
  Version: 8.3.2
  SubmitDate: '2000-10-06'
  LastModified: '2000-10-11'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  ClosedDate: '2000-10-11'


  Name:
  Christian Heide Damm

  ReproducibleScript:
  Run wish and type
      . configure -cursor "@c:/my temp/mycursor.cur"

  (assuming, of course, that there are directories and files called "my temp" and 
  "mycursor.cur")

  ObservedBehavior:
  bad cursor spec "@c:/my temp/mycursor.cur"
     (processing "-cursor" option)
     invoked from within
  ". configure -cursor "@c:/my temp/mycursor.cur""
     (file "myfile.tcl" line X)



  As discussed on comp.lang.tcl, this is not a bug, but a sensitive configuration issue.  -cursor is expecting a list, and 
  "@c:/my temp/mycursor.cur" is a two element list.  According to Tk_GetCursor, that means it will try to interpret it as "@sourcename fgColor".  On the other hand, "@c:/my\ temp/mycursor.cur" is a one element list.  Unfortunately the [list] command doesn't do the right thing in this case, because it just wants to add {}s in places that Tk_GetCursor doesn't understand.  So you can either do the -shortname, or specific '\ ' on spaces.

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

  -- 10/11/2000 ericm


tkt_uuid: 220328ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Winfo interp doesn't return anything on Win98 -using wish8.2
comment:
  OriginalBugID: 3681 Bug
  Version: 1.0b1
  SubmitDate: '1999-11-24'
  LastModified: '2000-06-20'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: key
  OS: Windows NT
  OSVersion: win98
  Machine: Ibm compatible   - Asus PB2B - dual pentium2 350MHZ - 256 MB ram
  ClosedDate: '2000-06-20'


  Name: Shawn Kielty

  ReproducibleScript:
  start wish82  and  execute "set a [winfo interps];puts $a"

  ObservedBehavior:
  "puts $a" returns an empty string

  DesiredBehavior:
  I expect to see  the current interpreteer   - like I might in Unix



  'send' and the mechanism behind it are not available on Windows
  (noted in docs), which is why 'winfo interps' returns nothing.
  On Windows, one has to use dde. 
  -- 11/29/1999 hobbs
  not a bug.  integrated 2023. 
  -- 06/20/2000 key


tkt_uuid: 220329ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: main application window does not come to foreground if action editor is open (XML Processor)
comment:
  OriginalBugID: 4745 Bug
  Version: 2.0b3
  SubmitDate: '2000-03-30'
  LastModified: '2000-05-17'
  Severity: MED
  Status: Released
  Submitter: key
  ChangedBy: angie
  RelatedBugIDs: 4017
  OS: All Unix
  ClosedDate: '2000-05-17'


  steps to reproduce:
  1)  start author
  2)  open project with XML Processor
  3)  open editor for XML Processor
  4)  move XML processor over the main application window (the one with the menu bar and tool bar)
  5)  click on the title bar of the main application window

  expected result:
  the main application window comes to foreground

  actual result:
  the main application window doesn't come to foreground.

  note:
  the main application window also doesn't come to the foreground when you switch to author "task"



  This is the standard behavior for transient windows. We can only fix this if we add the (already requested) Tk "wm style" command that allows us to be more specific as to which features we want to enable/diable for the window title.  
  -- 03/30/2000 sven
  Closed as bug.  RFE is in 4017. 
  -- 04/07/2000 hobbs
  setting this to duplicate so can track this for connect as well as tk 
  -- 04/12/2000 key


tkt_uuid: 220330ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: Stack trace in Job Action gui - from spinbox
comment:
  OriginalBugID: 4900 Bug
  Version: 2.0b4
  SubmitDate: '2000-04-06'
  LastModified: '2000-04-13'
  Severity: LOW
  Status: Released
  Submitter: shawn
  ChangedBy: shawn
  OS: Windows NT
  FixedDate: '2000-04-06'
  FixedInVersion: 2.0b5


  To reproduce - 

  Open a new project and schedule a job in the project enable action - and the error could appear.  I must have been pushing the start hour button.   

  can't read "tkPriv(relief)": no such element in array
      while executing
  "$w configure -$tkPriv(element)relief $tkPriv(relief)"
      (procedure "::tk::spinbox::ButtonUp" line 9)
      invoked from within
  "::tk::spinbox::ButtonUp .mdi1.leftRight.f1.frame.frame.apptFrm.f.timeFrm.starthour 22 13
  "
      (command bound to event)

  I have tried to reproduce this and haven't been able to - this is a new install and was run locally - by a new user - and the error appeared the first time the job action was opened, but wouldn't reappear after that.  

  I tried to reproduce it on a completely clean environment and wasn't able to .  

  Shawn



  Could this be a problem with the our build?

  I don't think this should happen normally.

  Jeff, any ideas on why this fails? 
  -- 04/06/2000 kuchler
  Fixed in CVS 6 Apr 2000.  The problem was the same as applied
  to the button previously - the Windows native dialogs go away
  on the buttonpress, leaving a stray buttonrelease to be interp'd
  by Tk. 
  -- 04/06/2000 hobbs

  Integrated in Qa build 2011 2.0 b5 
   
  -- 04/13/2000 shawn


tkt_uuid: 220331ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: tk_getOpenFile does not iconify properly when its parent is iconified as a transient window.
comment:
  OriginalBugID: 5117 Bug
  Version: 2.0b5
  SubmitDate: '2000-04-17'
  LastModified: '2000-05-03'
  Severity: SER
  Status: Released
  Submitter: kuchler
  ChangedBy: key
  RelatedBugIDs: 5115
  OS: All Unix
  ClosedDate: '2000-05-03'


  steps to reproduce with tk8.3 (4/17 build)

  wish8.3
  toplevel .t
  toplevel .t.o
  wm transient .t .
  wm transient .t.o .
  tk_getOpenFile -parent .t.o

  Now iconify the toplevel (.)

  Results:

  The three toplevels . .t and .t.o all iconify, but the tk_getOpenFile
  dialog remains open.

  Expected Results:

  Since the tk_getOpenFile dialog will iconify if you simply iconify .t.o
  it should also become iconified when . becomes iconified because the
  toplevel .t.o is transient and its parent is .


  This bug is not specific to tk_getOpenFile.  With further exploration
  I have discovered that it is true of all transient toplevels due to the
  following behavior:

  toplevel .t
  toplevel .t.o
  toplevel .t.o.f
  wm transient .t .
  wm transient .t.o .t
  wm transient .t.o.f .t.o

  When you iconify any toplevel only its direct child (the toplevel that has
  declared itself to be transient relative to it) will iconify.

  I would expect the iconification of that toplevel to cause the next child
  to iconify, etc. until all four toplevels are iconified.

  As far as I can tell a window can only be transient with respect to one
  other window, so I think you *have* to have this behavior to have a multiple-toplevel application behave properly. 
  -- 04/17/2000 kuchler
  This works on Exceed and WindowMaker as expected.  This is really a
  window manager issue, as we set bits (hints) for the window manager
  to do something with.  You might try 'wm group' in addition to the
  transient settings to see if that makes things work. 
  -- 04/18/2000 hobbs
  when this bug is fixed please remember to check 5115 
  -- 04/18/2000 key
  this bug ended up in the closed state for some reason that wasn't recorded.  5115 which depends on this bug being fixed, was marked integrated, which theoretically isn't possible unless this bug was fixed?
  scott, huh? 
  -- 05/03/2000 key
  It's a core bug, Jeff please look into it.
  -- 05/03/2000 redman
  This bug was closed because as Jeff stated it is not a bug.  Tk sets
  the transcience bits for windows when it is specified that those windows
  are supposed to be transient.  Some window managers choose to ignore
  those transcience bits or just don't handle them properly in all cases (fvwm2,CDE, etc.)  I filed this bug because I thought there was a tk bug
  because my window manager (fvwm) doesn't handle this properly.  The
  transcience of the windows and dialogs (bug 5115) were all checked and should be setup properly.
  -- 05/03/2000 kuchler
  marked integrated 2014.  agreed closed. 
  -- 05/03/2000 key


tkt_uuid: 220332ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: author gets into bad state with exceptional project name
comment:
  OriginalBugID: 5181 Bug
  Version: 2.0b5
  SubmitDate: '2000-04-19'
  LastModified: '2000-05-12'
  Severity: CRIT
  Status: Released
  Submitter: key
  ChangedBy: angie
  OS: Solaris
  FixedDate: '2000-04-19'
  FixedInVersion: 2.0b7


  steps to reproduce:
  1)  create a new project named "foobar\"
  2)  create URL action
  3)  create XML generator attached to URL action

  expected result:
  nothing exceptional

  actual result:
  get error message:
  An error occurred in the XMLGenerator setValue method:
  no files match glob pattern "$pwd/foobar\/dtd"

  after dismissing the dialog there is a stacktrace.  at this point the author looks locked up.

  note:
  nt doesn't allow this kind of filename/projectname



  This bug is actually a bug in tk_getOpenFile when it is started with
  an '-initialdir' that has the backslash at the end of a directory
  like this one does. 
  -- 04/19/2000 kuchler
  This is fixed for the 8.3.1 release (putback before Connect 2.0b7).
  An extra glob was being done on -initialdir, although we had already
  done a file isdir check.  This was removed. 
  -- 04/19/2000 hobbs

  Integrated on Solaris/Linux/NT build 2015 
  -- 05/12/2000 angie


tkt_uuid: 220333ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.4a2
resolution: Fixed
title: linking to tk84.lib fails
comment:
  OriginalBugID: 5849 Bug
  Version: 8.4a1
  SubmitDate: '2000-06-07'
  LastModified: '2000-07-28'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: shawn
  RelatedBugIDs: 6062
  OS: Windows 95
  FixedDate: '2000-07-28'
  ClosedDate: '2000-07-28'


  Name:
  Don Porter

  Comments:
  The disk is not full.

      cl == Microsoft(R) 32-Bit Optimizing Compiler Version 11.00.7022 for
      80x86

      The same sequence of operation succeeds with Tcl/Tk 8.3.1.

  ReproducibleScript:
  /* FILE: test.c
   */
  #include <tcl.h>
  #include <tk.h>

  int 
  Tcl_AppInit(Tcl_Interp *interp)
  {
      if (Tcl_Init(interp) != TCL_OK) {
          return TCL_ERROR;
      }
      if (Tk_Init(interp) != TCL_OK) {
          return TCL_ERROR;
      }
      Tcl_StaticPackage(interp, "Tk", Tk_Init, Tk_SafeInit);

      return TCL_OK;
  }

  int main(int argc, char **argv)
  {
    // Turn over control to the Tk library.
    Tk_Main(argc, argv, Tcl_AppInit);

    // Make picky compilers happy.
    return 0;
  }

  ObservedBehavior:
  C:> cl /nologo /c /IC:/PROGRA~1/TCL/include /Fotest.obj test.c
  test.c

  C:> link /nologo test.obj C:/PROGRA~1/TCL/lib/tk84.lib C:/PROGRA~1/TCL/lib/tcl84.lib /OUT:test.exe
  C:/PROGRA~1/TCL/lib/tk84.lib: fatal error LNK1106: invalid file or disk full: cannot seek to 0x393f800d

  DesiredBehavior:
  I should be able to statically link
  my C apps to tk84.lib.



  Dave Gravereaux suggests that this is because the distribution was built with VC 6.0, which produces library files that are incompatible with VC 5.0.
  We should either use VC 5.0 to build our distribution, or specify "/compat50lib" on the link line, so that the binaries produced are VC 5.0 compatible.

  - eric

  -- 06/19/2000 ericm

  Is a duplicate of 6062  
  -- 07/28/2000 shawn


tkt_uuid: 220334ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: Keypress binding keystrokes appear in text widget
comment:
  OriginalBugID: 5943 Bug
  Version: 8.4a1
  SubmitDate: '2000-06-24'
  LastModified: '2000-06-25'
  Severity: LOW
  Status: Released
  Submitter: shawn
  ChangedBy: shawn
  OS: Windows 2000
  ClosedDate: '2000-06-25'


  I have a binding a binding on a toplevel widget that causes the focus to enter an entry widget - where I anticipate entering some text - the binding is <KeyPress-:> so that I expect the ":" not to appear in the text widget - and I also don't expect to see it in the entry widget (i explicitly put in in the entry widget with this code). 

  This behavior doesn't change if I change the binding to be explicitly on the text widget. 

  Perhaps this is the expected result- since I find that if I bind explicitly to the text widget and break out of the binding it gives the expected behavior. 

  To reproduce execute this code: 

  set env(command) ""
  set win [toplevel .t ]
  set env(dialog) [text $win.a -width 40]
  pack $env(dialog) -fill both -expand true 
  set env(commandWin) [entry $win.b -textvariable env(command)]

  pack $win.b -fill x -expand true 
  bind $env(dialog) <Escape> {

      bind $win <KeyPress-:> {
          focus -force $env(commandWin)
          bind $win <KeyPress-:> {}
          $env(commandWin) insert end :
          bind <FocusOut> $env(commandWin) { 
              switch -regexp $env(command)  {
                  {^:w } {
                       # assumes filename is the balance of the command 
                       set filename [regsub {^:w } $env(command) ""]
                       saveFile $filename 
                  }

                  * {} 
             }
             bind <FocusOut> $env(commandWin) {}      
         }
  #       focus $env(dialog)
      }

      bind $win <KeyPress-/> {
          focus $env(commandWin)
          # Put bindings for searches here 
          bind $win <KeyPress-/> {}
          $env(commandWin) insert end /
          bind <FocusOut> $env(commandWin) {}      
   #      focus $env(dialog)
      }
  }

  #eof

  Force focus on the text widget by clicking in the window with the mouse.  strike the <escape> key and then type a slash {/} to trigger the bindings. Notice that the / appears in the text widget - 

  Expected result:  I expect not to see the slash in the text widget - but instead just to have that keystroke trigger the binding.  

  This binding will give the expected result:

  #
    bind $env(dialog) <KeyPress-/> {
          focus $env(commandWin)
          # Put bindings for searches here 
          bind $win <KeyPress-/> {}
          $env(commandWin) insert end /
          bind <FocusOut> $env(commandWin) {}      
   #      focus $env(dialog)
          break
      }
  #eof



  This is the expected behavior.  From the bind manpage:

  MULTIPLE MATCHES
         It  is  possible  for  several bindings to match a given X
         event.  If the  bindings  are  associated  with  different
         tag's,  then  each  of  the  bindings will be executed, in
         order.  By default, a binding for the widget will be  exe-
         cuted  first,  followed  by a class binding, a binding for
         its toplevel, and an all binding.   The  bindtags  command
         may  be  used to change this order for a particular window
         or to associate additional binding tags with the window.

         The continue and break commands may be used inside a bind-
         ing  script to control the processing of matching scripts.
         If continue is invoked, then the current binding script is
         terminated but Tk will continue processing binding scripts
         associated with other tag's.   If  the  break  command  is
         invoked  within  a binding script, then that script termi-
         nates and no other scripts will be invoked for the  event.

  This is exactly what you have already discovered; when multiple bindings match an event, and each is attached to a different bindtag, then all of the bindings are executed.  In this case, your custom binding and the default text widget KeyPress binding (which inserts the typed character) are both firing.  As you noted, you can use break to change this behavior.

  - eric

  -- 06/25/2000 ericm

  I am happy 

  -- 06/25/2000 shawn


tkt_uuid: 220335ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title:
  I'd like to see an additional state in a text widget - with a cursor display and a keypad navigation with arrows

comment:
  OriginalBugID: 5952 RFE
  Version: 8.4a1
  SubmitDate: '2000-06-26'
  LastModified: '2000-09-06'
  Severity: LOW
  Status: Released
  Submitter: shawn
  ChangedBy: shawn
  OS: All
  ClosedDate: '2000-09-06'


  This would be a state that displays a cursor, is not editable, but allows keyboard navigation using the up, down, left and right arrows - a sort of partially enabled state - but without editing.  Additionally I would like this to allow modification of the text through the program - but not through the user interface. Does any one else think this might be useful - I know the Disabled state is very "netscape" like and seems a good model. I'd prefer something in between - since I like  to use the keyboard more than the mouse.



  This can be done with the current text widget, if the user applies
  focus to the widget first, and makes sure to enable the state of
  the text widget when editing. 
  -- 09/06/2000 hobbs

  This can be accomplished by overwriting the default bindings for the enabled text widget 

  Integrated  
  -- 09/06/2000 shawn


tkt_uuid: 220336ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title:
  I have problem using the 4 and 6 number keys on the keypad when the Num Lock is on. They behave as Left and Right arrow keys.

comment:
  OriginalBugID: 6029 Bug
  Version: 8.2.2
  SubmitDate: '2000-07-20'
  LastModified: '2000-07-21'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: shawn
  RelatedBugIDs: 6028
  OS: SunOS
  Machine: SUN m/c
  FixedDate: '2000-07-20'
  ClosedDate: '2000-07-21'


  Name:
  Meetu Sharma

  Extensions:
  Using Tcl 7.6 and Tk 4.2

  ReproducibleScript:
  I am coding in TK4.2 on Sun Solaris 2.6. The problem i am facing is that when i bring up the view on a SUN m/c and put the NUM LOCK key on, the 4 and 6 keys on the keypad behave as left and right arrow keys. On setting the NUM LOCK to off they behave properly (as arrow keys). However, all other number keys behave perfectly fine. 
  Instead if i make a telnet session to the same SUN m/c from a WIN-NT  machine, the keypad keys work perfectly fine. There is no problem in that case.

  I tried the same thing with TK-8.2 on Sun Solaris and it behaves the same as with TK-4.2 on Sun.

  Could you pl. help me out on this.

  ObservedBehavior:
  The 4 and 6 keys on the keypad on the right of the keyboard behave as left and right arrow keys even if the NUM LOCK is ON.

  DesiredBehavior:
  The 4 and 6 key when pressed with NUM Lock set to ON, in a Tk Widger should show the numbers 4 and 6 instead of moving the cursor to the left and right.



  Exact Duplicate of 6028 
  -- 07/21/2000 shawn


tkt_uuid: 220337ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: prowish not as fast as tcl8.0p2
comment:
  OriginalBugID: 212 Bug
  Version: 1.0b4
  SubmitDate: '1998-07-23'
  LastModified: '1999-12-14'
  Severity: LOW
  Status: Fix/AA
  Submitter: hershey
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-12-14'
  FixedInVersion: 1.3


  I discovered that standard WISH80.EXE runs my code at a good speed, 
  however running PROWISH.EXE slowed my program by about 5 times, 
  compiling it with PROCOMP and running "PROWISH source.TBC" was 
  same as uncompiled.


  (ems 8/28/98) set the OS field to "All Windows", this is not a generic problem

  (ems 8/28/98) There is definitely a performance degradation in protclsh, although not necessarily 5 times slower (other users have reported twice as slow, and that is consistent with a quick-and-dirty bekchmark I did). The reason is that we switched to VC++ 5.0 from Borland, and decided not to tighten the optimization flags for fear that the optimizer would generate bad code. I ran the following test script on a number of platforms, see results below:

  proc f {i} {
      set x [expr {$i * $i}]
      return $x
  }
  puts [time {f 2} 50000]

  8.0.3 with default VC++ flags  :                         12 microseconds per iteration
  8.0.3 with maximum optimization (-O2) :         7 microseconds per iteration
  8.0p2 with default VC++ flags :                        10 microseconds per iteration
  8.0p2 with Borland compiler  :                            6 microseconds per iteration
  tclpro  :                                                                   12 microseconds per iteration
  tclpro with maximum optimization (-O2)   :     7 microseconds per iteration

  (ems 8/28/98) Also, compiling a .tcl script into .tbc won't change runtime performance: the .tbc file contains the same bytecodes that the .tcl file would generate. There may be an improvement in loading performance if the .tbc file is smaller enough than the .tcl file that I/O gains overshadow the added expense of decoding the .tbc file.

  (pat 9/2/98) Under Windows, Tcl code executed by the Tclpro shells (protclsh80.exe and
  prowish80.exe) will run slower than if it were executed in 8.0p2 shells.

  This is because TclPro switched from Borland to VC++ as the compiler of
  choice with the Tcl/Tk builds. The optimization flags for VC++ were left at a
  somewhat loose level, because we were worried that more aggressive optimization
  would generate bad codes, and there wasn't enough time to do extensive
  testing to make sure that the optimizer behaved.

  As a consequence, the TclPro interpreters are slower than 8.0p2. Note that
  protclsh80.exe and prowish80.exe are NOT slower than 8.0.3 interpreters built
  with VC++ and the makefile.vc in the win directories. They will be slower than
  8.0.3 interpreters built with -O2, however; for example, if someone creates
  a DevStudio project, sets it to "Maximize Speed", generates the DLL and the
  EXE, those interpreters will be faster than ours.
  --
  work-arounds:

  This is a possible workaround:

  1) rebuild the Tcl 8.0.3 DLL from the source distribution, using VC++ 5.0
     with optimization flags set to -O2. For example, this can be done from
     the Developer Studio IDE by selecting the C/C++ tab in "Settings", the
     "Optimizations" category, and the "Maximize Speed" drop-down choice.

  2) replace tcl80.dll in win32-ix86/bin with the one you built in step 1.
     Don't forget to make a copy of the original in case you want to switch
     back.

  The TclPro-generated tcl80.dll was built from the same distribution as the
  8.0.3 tcl80.dll, so replacing it should be OK. The unknown here is how well
  the code optimizer in VC++ works, in particular will it generate bad code.
  --
  More recent versions of Tcl (and TclPro) use -O2, as well as newer
  versions of VC++. 
  -- 12/14/1999 hobbs


tkt_uuid: 220338ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.1a1
resolution: Fixed
title: cascade menus cannot be disabled properly, and sometimes disappear
comment:
  OriginalBugID: 547 Bug
  Version: 8.1a1
  SubmitDate: '1998-03-18'
  LastModified: '2000-01-07'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  FixedDate: '2000-01-07'
  FixedInVersion: 8.3b1


  > I reported this to this newsgroup a month or so ago for a1, but here
  > it is again.  Disabling/enabling the state of a submenu label in a
  > menubar is completely incorrect.
  > 
  > Wish8.1a1 or Wish8.1a2:
  > 

  menu .menubar
  .menubar add cascade -menu .menubar.m -label "Test"
  menu .menubar.m
  .menubar.m add cascade -menu .menubar.m.buggy -label "Buggy state"
  . configure -menu .menubar
  menu .menubar.m.buggy
  .menubar.m.buggy add command -label "Blah"

  # now test the menu; it works fine
  # Here's where the bugs start

  .menubar.m entryconfigure 1 -state disabled
  > unknown option "menu"
   
  # That's an odd bug.  No idea where that error comes from
  # Let's try again:
  .menubar.m entryconfigure 1 -state disabled

  # It works now!  However it does the wrong thing
  # Look at the menu.  The 'submenu triangle thing'
  # has vanished!  Let's try to enable the item again

  .menubar.m entryconfigure 1 -state normal

  # Oops.  Our submenu has gone.  We have to rebuild the
  # menu from scratch.
   
  >  Vince. <darley@fas.harvard.edu>


  There are two bugs here.  One is a typo, where the string "menu" is hardcoded instead of the string "menus", causing the error message
  'unknown option "menu"'.  Once that's fixed, other problems crop up for which there's no easy fix...
  ----
  First bug is fixed.
  Second bug needs to be verified.  It did not appear on NT or Solaris, but should be tested iin Win98 with large fonts enabled.  03/26/1999 11:07 - surles -
  ---
  This no longer is a problem in 8.3b1, and was likely fixed earlier. 
  -- 01/07/2000 hobbs


tkt_uuid: 220339ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 60. [tk_setPalette]
priority: 2
foundin: obsolete: 8.0
resolution: Fixed
title: tk_setPalette dies with a confusing and obscure error
comment:
  OriginalBugID: 551 Bug
  Version: 8.0
  SubmitDate: '1998-03-18'
  LastModified: '1999-08-14'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-14'
  FixedInVersion: 8.2


  tk 8.0's tk_setPalette dies with a confusing and obscure error if you try

  it on a black-and-white display.  (It says:





  unknown color name ""

      while executing

  "winfo rgb . [lindex $value 3]"

      (procedure "tkRecolorTree" line 10)

      invoked from within

  "tkRecolorTree $child c"

      (procedure "tkRecolorTree" line 22)

      invoked from within

  "tkRecolorTree $child c"

      (procedure "tkRecolorTree" line 22)

      invoked from within

  "tkRecolorTree . new"

      (procedure "tk_setPalette" line 64)

      invoked from within

  "tk_setPalette gray80"





  which, at first glance, looks like an evil scary complex bug).





  tk 4.1's tk_setPalette didn't fail like this.  I took the easy way out

  and just made tk_setPalette return if it was called on a 1-bit

  display.  I dunno if you want to come up with a better solution.





    Bill





  --- palette.tcl Thu Mar  5 20:40:29 1998

  +++ palette.tcl.fixed   Thu Mar  5 20:40:09 1998

  @@ -26,6 +26,10 @@

  proc tk_setPalette {args} {

       global tkPalette

  +    if {[winfo depth .] == 1} {

  +   return

  +    }

  +

       # Create an array that has the complete new palette.  If some colors

       # aren't specified, compute them from other colors that are specified.



  This is in the 8.2.1 release. 
  -- 08/14/1999 hobbs


tkt_uuid: 220340ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: compiling 64 Bit binaries causes problems in the Tcl_HashEntry function
comment:
  OriginalBugID: 553 Bug
  Version: 8.1a2
  SubmitDate: '1998-03-31'
  LastModified: '1999-03-26'
  Severity: SER
  Status: Released
  Submitter: hershey
  ChangedBy: redman
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-03-26'
  FixedInVersion: NA


  From: Fuad Abdallah <abdallah@nazgul.mpiz-koeln.mpg.de>
  Newsgroups: comp.lang.tcl
  Subject: Tcl8.1a2 error on irix6.2 64 bit ?
  Date: 26 Mar 1998 20:30:29 GMT
  Organization: GWDG, Goettingen
  Lines: 19
  Message-ID: <6fedt5$sbh$1@gwdu19.gwdg.de>
  NNTP-Posting-Host: nazgul.mpiz-koeln.mpg.de
  User-Agent: tin/pre-1.4-980202 (UNIX) (IRIX64/6.2 (IP28))
  Xref: nntp2.ba.best.com comp.lang.tcl:70051


  Hi,


  i have just compiled tcl8.1a2 under irix 6.2. It seems that
  compiling 64 Bit binaries causes problems in the function
  static Tcl_HashEntry *OneWordCreate
  resulting in coredumps.
  I used the irix cc 7.2 and gcc 2.8.1, both giving the same
  result.



  Regards,
  Fuad

  03/26/1999 18:43 - redman - Should be fixed now.  The hash code for XIDs was forced to use the single word hashing on 64bit systems.


tkt_uuid: 220341ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: change in font configuration nolonger redisplays all widgets using this font
comment:
  OriginalBugID: 560 Bug
  Version: 8.1a2
  SubmitDate: '1998-04-14'
  LastModified: '1999-03-29'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: stanton
  RelatedBugIDs: 1144
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-03-29'
  FixedInVersion: 8.1b3


  Hello,

  In Tk8.0 a configuration of a font triggered a redisplay
  of all widgets using this font. This doesn't work for me
  with Tk8.1a2 (on Linux and WinNT).

  An example script, which works with Tk8.0, but fails with Tk8.1:

  font create f -family Helvetica -size 8
  button .b -font f -text "Helvetica 8" -command exit]
  pack .b
  after 2000 {
      font configure f -family Times -size 12
      .b configure -text "Times 12"
  }

  Thanks in advance, Krischan
  --
  Christian Krone, SQL Datenbanksysteme GmbH
  Mail mailto:krischan@sql.de


  Tested.  This is a bug.  The behavior is different between 8.0 and 8.1.  03/25/1999 10:43 - surles -

  This has been fixed 
  03/29/1999 19:58 - stanton -


tkt_uuid: 220342ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: tk_getOpenFile with -initialdir flag fails if path has a space in it
comment:
  OriginalBugID: 561 Bug
  Version: 8.1a2
  SubmitDate: '1998-04-15'
  LastModified: '1999-03-25'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: surles
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-03-25'
  FixedInVersion: NA


  From: Daniel Wiesmann <danielw@alier.com>
  Subject: tk_getOpenFile bug
  Newsgroups: comp.lang.tcl
  Date: Thu, 02 Apr 1998 15:38:26 -0800
  Organization: Alier, Inc.
  Path: nntp2.ba.best.com!not-for-mail
  Lines: 22
  Message-ID: <35242172.1B6EC452@alier.com>
  NNTP-Posting-Host: 206.14.19.91
  Mime-Version: 1.0
  Content-Type: text/plain; charset=us-ascii
  Content-Transfer-Encoding: 7bit
  X-Trace: 891560454 4698 (none) 206.86.0.12
  X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
  Xref: nntp2.ba.best.com comp.lang.tcl:70481

  Hello all,

  I have noticed a bug in tk_getOpenFile with the -initialdir flag.
  If the
  path
  given to the initialdir argument has a space in it, the widget
  will
  fail...

  % pwd
  /home/this_user/space directory
  % set dir [pwd]
  % tk_getOpenFile -initialdir $dir  ###THIS WILL FAIL


  However, if one is in the space directory, and lauches the
  tk_getOpenFile without
  the initialdir flag, it will all work...

  I have only tested this on Unix, where spaces in directories are
  not
  very common. I
  would hope that the same does not happend in Windows...

  Daniel




  This was fixed in 8.0 for TclPro Debugger and must have been brought forward since this bug was logged.  Tested and verified on Unix.  It was never a bug on Windows.  03/25/1999 15:31 - surles -


tkt_uuid: 220343ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.0
resolution: Fixed
title: unintuitive focus behavior
comment:
  OriginalBugID: 565 Bug
  Version: 8.0
  SubmitDate: '1998-04-15'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: NA
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  >To: John Ousterhout <ouster@best.com>
  >Subject: Tk bug with <FocusOut>
  >X-Zippy:  So this is what it feels like to be potato salad
  >X-Attribution:  Tom
  >Reply-To: tromey@cygnus.com
  >From: Tom Tromey <tromey@creche.cygnus.com>
  >Lines: 21
  >X-Mailer: Red Gnus v0.34/Emacs 19.34
  >Date: 23 Jan 1998 15:01:23 -0700
  >
  >Here's a little script to demonstrate a problem I found:
  >
  >toplevel .z
  >bind .z <FocusIn> {puts in}
  >bind .z <FocusOut> {puts out}
  >
  >
  >Here's how to reproduce the bug:
  >
  >* Run the script
  >* Click on the toplevel; you should see "in" printed wherever things
  >  are printed (for me, the console I'm using)
  >* Click on the desktop (note nothing happens)
  >* Move the mouse over the "z" window; you should see "out" printed.
  >
  >I think the FocusOut handler should be run as soon as the user clicks
  >on the desktop.
  >
  >Tom

  With 8.2b2, this works as expected (you get the out triggered
  when you click on the desktop), so this was fixed somewhere
  along the way. 
  -- 08/06/1999 hobbs


tkt_uuid: 220344ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.0
resolution: Fixed
title: Bounding box of 'arc' items with '-style
comment:
  OriginalBugID: 570 Bug
  Version: 8.0
  SubmitDate: '1998-04-15'
  LastModified: '1998-07-27'
  Severity: LOW
  Status: Released
  Submitter: rjohnson
  ChangedBy: rjohnson
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: 8.0.3
  ClosedDate: '1998-07-27'


  >Arc items on a canvas with '-style chord' have bounding boxes that are
  >far
  >too generous, because they include the center of the circle.
  >
  >Test script:

  pack [canvas .c -width 510 -height 120]
  .c create text 50 0 -text "Arc" -anchor n
  .c create arc -100 10 100 210 -start 10 -extent 50 -style arc -tags arc1
  eval .c create rectangle [.c bbox arc1]
  .c create text 250 0 -text "Chord" -anchor n
  .c create arc 100 10 300 210 -start 10 -extent 50 -style chord -tags arc2
  eval .c create rectangle [.c bbox arc2]
  .c create text 450 0 -text "Pieslice" -anchor n
  .c create arc 300 10 500 210 -start 10 -extent 50 -style pieslice -tags arc3
  eval .c create rectangle [.c bbox arc3]

  Suggested patch is to tkCanvArc.c (patch applies to 8.0 base, may need to be relocated for other revisions):

  >*** tkCanvArc.c        1998/02/16 21:58:32     1.1
  >--- tkCanvArc.c        1998/02/16 21:59:10
  >***************
  >*** 545,551 ****
  >      TkIncludePoint((Tk_Item *) arcPtr, arcPtr->center2);
  >      center[0] = (arcPtr->bbox[0] + arcPtr->bbox[2])/2;
  >      center[1] = (arcPtr->bbox[1] + arcPtr->bbox[3])/2;
  >!     if (arcPtr->style != arcUid) {
  >       TkIncludePoint((Tk_Item *) arcPtr, center);
  >      }
  >  
  >--- 545,551 ----
  >      TkIncludePoint((Tk_Item *) arcPtr, arcPtr->center2);
  >      center[0] = (arcPtr->bbox[0] + arcPtr->bbox[2])/2;
  >      center[1] = (arcPtr->bbox[1] + arcPtr->bbox[3])/2;
  >!     if (arcPtr->style == pieSliceUid) {
  >       TkIncludePoint((Tk_Item *) arcPtr, center);
  >      }

  >  
  >
  >-- 
  >73 de ke9tv/2, Kevin KENNY     GE Corporate R&D, Niskayuna, New York, USA
  >
  >--------------67AEE1CC724594FB55EEDA47--
  >


tkt_uuid: 220345ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.0
resolution: Fixed
title: Typing Alt-X, where X is some letter, always results in a beep
comment:
  OriginalBugID: 571 Bug
  Version: 8.0
  SubmitDate: '1998-04-15'
  LastModified: '1998-08-04'
  Severity: LOW
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: Windows NT
  OSVersion: 4.0
  Machine: NA
  FixedInVersion: 8.0.3
  ClosedDate: '1998-08-04'


  >Reply-To: tromey@cygnus.com
  >From: Tom Tromey <tromey@creche.cygnus.com>
  >Date: 18 Feb 1998 15:29:59 -0700
  >
  >I'm using Tk 8.0 on Windows NT 4.
  >
  >Typing Alt-X, where X is some letter, always results in a beep for me,
  >even if I have an <Alt-KeyPress> binding.
  >
  >This is because these events are translated into WM_MENUCHAR messages
  >by Windows.  The Tk code only handles certain WM_MENUCHAR events.
  >
  >I fixed this by changing Tk_TranslateWinEvent and GenerateXEvent to
  >handle WM_MENUCHAR messages.  I can send a patch if you'd like it.
  >
  >Tom

  fixed by handling WM_SYSKEYDOWN, WM_SYSKEYUP, and synthesizing WM_SYSCHAR


tkt_uuid: 220346ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: wm transient does not map window correctly
comment:
  OriginalBugID: 572 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-11'
  LastModified: '2000-01-06'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: hobbs
  RelatedBugIDs: 2710
  OS: All Windows
  FixedDate: '2000-01-06'
  FixedInVersion: 8.3b2


  From: Mark Gammon <m.gammon@fegs.co.uk> 

  I think I have found a bug in the "wm transient" command.
  Try the following:

     toplevel .t
     wm withdraw .t
     wm transient .t .

  The "wm transient" command causes the toplevel to be mapped !

  The culprit seems to be a line of code in tkWInWm.c that
  handles the "wm transient" command:

  line 2056:
      /*
      * Ensure that the transient window is either mapped or 
      * unmapped like its master.
      */


      TkpWmSetState(winPtr, NormalState);

  Commenting this out seems to stop the unwanted mapping and doesn't
  have any bad side-effects as far as I can see.

  The proposed fix is incorrect also.  The correct solution should ensure that the parent state overrides the child state, but that the child state is honored if possible.  For example, if the parent is iconified or unmapped, the child should also be iconified or unmapped.  If the parent is normal, the child should use its own state to determine how to display itself.
  --
  A correct fix is in place for 8.3b2.  If the master is mapped, then
  the transient keeps its state, unless it was Iconic, in which case
  it will become Withdrawn.  If the master is not mapped, the state
  for the transient window will become Withdrawn. 
  -- 01/06/2000 hobbs


tkt_uuid: 220347ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Linking and 'make test' errors for tk8.0p2
comment:
  OriginalBugID: 577 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1999-04-16'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hershey
  OS: Solaris
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-04-16'
  FixedInVersion: 8.1


  When I build Tcl 8.1 or Tcl8.0p2 followed by the tk of the same
  version
  like this for solaris-x86:

  configure --enable-shared --enable-gcc ; make

  I end up getting this error, when attempting to create
  libtk8.X.so:

  /usr/ccs/bin/ld -G -z text -o libtk8.0.so tk3d.o tkArgv.o tkAtom.o

  tkBind.o tkBitmap.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o
  tkCursor.o tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o
  tkGeometry.o tkGrab.o tkGrid.o tkMain.o tkOption.o tkPack.o
  tkPlace.o
  tkSelect.o tkUtil.o tkVisual.o tkWindow.o tkUnix.o tkUnix3d.o
  tkUnixButton.o tkUnixColor.o tkUnixCursor.o tkUnixDialog.o
  tkUnixDraw.o
  tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o tkUnixFont.o
  tkUnixInit.o
  tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o
  tkUnixSelect.o
  tkUnixSend.o tkUnixWm.o tkUnixXId.o tkButton.o tkEntry.o tkFrame.o

  tkListbox.o tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o
  tkScale.o
  tkScrollbar.o tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o
  tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o tkCanvUtil.o
  tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o
  tkImgGIF.o
  tkImgPPM.o tkImgPhoto.o tkText.o tkTextBTree.o tkTextDisp.o
  tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o tkTextWind.o
  -R
  /usr/local/lib -L/export/nv3/tapi/pvm/8.0/tcl8.0/unix -ltcl8.0
  -lsocket
  -lnsl -lX11 -ldl -lm -lc
  Text relocation remains                       referenced
      against symbol                  offset      in file
  __ctype                             0x1d4       tkGet.o
  __ctype                             0x1b8       tkGet.o
  __ctype                             0x4ac       tkCanvPs.o
  ld: fatal: relocations remain against allocatable but non-writable

  sections
  make: *** [libtk8.0.so] Error 1

  man ld gives:

       -z text     In dynamic mode only, force a fatal error if any
                   relocations  against  non-writable,  allocatable
                   sections remain.

  If I take out the -z option to the ld linker or take out the
  --enable-shared option to configure, everything works fine, and I
  get
  the libtk8.1.so that I want, and it goes on to create the wish
  executable too.

  For tk8.0p2, these are the `make test` errors I get, but they
  don't
  really seem related to the -z text option. Anyone know what I'm
  doing
  wrong?

  I'm using CDE and the std. solaris-x86 X-server.

  menubut.test


  ==== menubutton-4.5 ConfigureMenuButton procedure
  ==== Contents of test case:

      catch {destroy .mb1}
      button .mb1 -text "Sample text" -width 10 -height 2
      pack .mb1
      set result "[winfo reqwidth .mb1] [winfo reqheight .mb1]"
      .mb1 configure -bitmap questhead
      lappend result [winfo reqwidth .mb1] [winfo reqheight .mb1]

  ==== Result was:
  100 44 20 12
  ---- Result should have been:
  102 46 20 12
  ---- menubutton-4.5 FAILED


  ==== menubutton-7.13 ComputeMenuButtonGeometry procedure
  ==== Contents of test case:

      catch {destroy .mb}
      menubutton .mb -text String -bd 2 -relief raised
  -highlightthickness 1 -indicatoron 1
      pack .mb
      list [winfo reqwidth .mb] [winfo reqheight .mb]

  ==== Result was:
  75 28
  ---- Result should have been:
  78 28
  ---- menubutton-7.13 FAILED
  msgbox.test
  oldpack.test
  option.test
  pack.test
  place.test
  raise.test
  safe.test
  scale.test


  ==== scale-7.1 ComputeScaleGeometry procedure
  ==== Contents of test case:

      catch {destroy .s}
      scale .s -from 0 -to 10 -label "Short" -orient vertical
  -length 5i
      pack .s
      update
      list [winfo reqwidth .s] [winfo reqheight .s]

  ==== Result was:
  88 434

  Seeya,---- Result should have been:
  88 458
  ---- scale-7.1 FAILED


  ==== scale-7.5 ComputeScaleGeometry procedure
  ==== Contents of test case:

      catch {destroy .s}
      scale .s -from 0 -to 10 -label "Short" -orient horizontal
  -length 5i
      pack .s
      update
      list [winfo reqwidth .s] [winfo reqheight .s]

  ==== Result was:
  434 61
  ---- Result should have been:
  458 61
  ---- scale-7.5 FAILED
  scrollbar.test
  select.test
  send.test
  Your X server is insecure, so "send" can't be used; skipping
  "send"
  tests.
  text.test
  textBTree.test
  textDisp.test
  textImage.test
  textIndex.test


  ==== textIndex-5.1 TkTextGetIndex, "@"
  ==== Contents of test case:

      .t index @12,9

  ==== Result was:
  1.0
  ---- Result should have been:
  1.1
  ---- textIndex-5.1 FAILED
  textMark.test
  textTag.test


  :-)

  Peter Morch

  Manager - Automated Testing Development
  GN Nettest Canada
  E-mail   : pmorch@nettestca.gn.com
  Telephone: (+1) 905-479-8090 Ext. 455
  FAX      : (+1) 905-475-6524



  These tests are all marked nonPortable in Tk8.1
  04/16/1999 13:35 - hershey -


tkt_uuid: 220348ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Reliably free image color table
comment:
  OriginalBugID: 586 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1999-08-15'
  Severity: SER
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-15'
  FixedInVersion: 8.2


  In Tk8.0p2, when you free an photo image, the DisposeInstance call

  will call FreeColorTable.  That function will schedule an idle call to

  free the color table for the image.


  However, if you are shutting down Tcl, then there won't be any more

  idle calls, so the color table will never be freed.


  Here is a patch to force a color table to be freed immediately when

  disposing of an instance.


  Ian Taylor

  ian@cygnus.com


  *** /5g/ian/tk8.0p2/generic/tkImgPhoto.c        Fri Aug  8 14:32:47 1997

  --- tkImgPhoto.c        Tue Apr 14 14:26:34 1998

  *************** static int              IsValidPalette _ANSI_ARGS_((

  *** 361,367 ****

                              char *palette));

    static int            CountBits _ANSI_ARGS_((pixel mask));

    static void           GetColorTable _ANSI_ARGS_((PhotoInstance *instancePtr));

  ! static void           FreeColorTable _ANSI_ARGS_((ColorTable *colorPtr));

    static void           AllocateColors _ANSI_ARGS_((ColorTable *colorPtr));

    static void           DisposeColorTable _ANSI_ARGS_((ClientData clientData));

    static void           DisposeInstance _ANSI_ARGS_((ClientData clientData));

  --- 361,368 ----

                              char *palette));

    static int            CountBits _ANSI_ARGS_((pixel mask));

    static void           GetColorTable _ANSI_ARGS_((PhotoInstance *instancePtr));

  ! static void           FreeColorTable _ANSI_ARGS_((ColorTable *colorPtr,

  !                           int force));

    static void           AllocateColors _ANSI_ARGS_((ColorTable *colorPtr));

    static void           DisposeColorTable _ANSI_ARGS_((ClientData clientData));

    static void           DisposeInstance _ANSI_ARGS_((ClientData clientData));

  *************** ImgPhotoConfigureInstance(instancePtr)

  *** 1486,1492 ****


          if (colorTablePtr != NULL) {

              colorTablePtr->liveRefCount -= 1;

  !           FreeColorTable(colorTablePtr);

          }

          GetColorTable(instancePtr);


  --- 1487,1493 ----


          if (colorTablePtr != NULL) {

              colorTablePtr->liveRefCount -= 1;

  !           FreeColorTable(colorTablePtr, 0);

          }

          GetColorTable(instancePtr);


  *************** ImgPhotoGet(tkwin, masterData)

  *** 1646,1652 ****


                  Tcl_CancelIdleCall(DisposeInstance, (ClientData) instancePtr);

                  if (instancePtr->colorTablePtr != NULL) {

  !                   FreeColorTable(instancePtr->colorTablePtr);

                  }

                  GetColorTable(instancePtr);

              }

  --- 1647,1653 ----


                  Tcl_CancelIdleCall(DisposeInstance, (ClientData) instancePtr);

                  if (instancePtr->colorTablePtr != NULL) {

  !                   FreeColorTable(instancePtr->colorTablePtr, 0);

                  }

                  GetColorTable(instancePtr);

              }

  *************** GetColorTable(instancePtr)

  *** 2484,2498 ****

     */


    static void

  ! FreeColorTable(colorPtr)

        ColorTable *colorPtr;     /* Pointer to the color table which is

                                   * no longer required by an instance. */

    {

        colorPtr->refCount--;

        if (colorPtr->refCount > 0) {

          return;

        }

  !     if ((colorPtr->flags & DISPOSE_PENDING) == 0) {

          Tcl_DoWhenIdle(DisposeColorTable, (ClientData) colorPtr);

          colorPtr->flags |= DISPOSE_PENDING;

        }

  --- 2485,2506 ----

     */


    static void

  ! FreeColorTable(colorPtr, force)

        ColorTable *colorPtr;     /* Pointer to the color table which is

                                   * no longer required by an instance. */

  +     int force;                        /* Force free to happen immediately. */

    {

        colorPtr->refCount--;

        if (colorPtr->refCount > 0) {

          return;

        }

  !     if (force) {

  !       if ((colorPtr->flags & DISPOSE_PENDING) != 0) {

  !           Tcl_CancelIdleCall(DisposeColorTable, (ClientData) colorPtr);

  !           colorPtr->flags &= ~DISPOSE_PENDING;

  !       }

  !       DisposeColorTable((ClientData) colorPtr);

  !     } else if ((colorPtr->flags & DISPOSE_PENDING) == 0) {

          Tcl_DoWhenIdle(DisposeColorTable, (ClientData) colorPtr);

          colorPtr->flags |= DISPOSE_PENDING;

        }

  *************** DisposeInstance(clientData)

  *** 2958,2964 ****

          ckfree((char *) instancePtr->error);

        }

        if (instancePtr->colorTablePtr != NULL) {

  !       FreeColorTable(instancePtr->colorTablePtr);

        }


        if (instancePtr->masterPtr->instancePtr == instancePtr) {

  --- 2966,2972 ----

          ckfree((char *) instancePtr->error);

        }

        if (instancePtr->colorTablePtr != NULL) {

  !       FreeColorTable(instancePtr->colorTablePtr, 1);

        }


        if (instancePtr->masterPtr->instancePtr == instancePtr) {




  This patch was integrated sometime before 8.2.0. 
  -- 08/15/1999 hobbs


tkt_uuid: 220349ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: focus -force works poorly on Windows
comment:
  OriginalBugID: 587 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-06-12'
  Severity: LOW
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1998-06-12'


  With Tk8.0p2 and Tk8.1a2 on Windows, the focus -force option only
  calls SetFocus.  This is OK, but when focus -force is used in practice
  on Windows I think the user really wants to make the window the new
  foreground window, particularly since Tk doesn't provide any other
  mechanism to set the foreground window.

  The appended patch implements this suggested change.

  Ian Taylor
  ian@cygnus.com


  *** /5g/ian/tk8.0p2/win/tkWinPointer.c  Fri Oct 31 11:40:05 1997
  --- tkWinPointer.c      Wed Apr 15 15:13:30 1998
  *************** TkpChangeFocus(winPtr, force)
  *** 409,414 ****
  --- 409,419 ----
        if (winPtr->window == None) {
          panic("ChangeXFocus got null X window");
        }
  + 
  +     if (force) {
  +       SetForegroundWindow(Tk_GetHWND(winPtr->window));
  +     }
  + 
        XSetInputFocus(dispPtr->display, winPtr->window, RevertToParent,
              CurrentTime);
    



  The supplied patch seems to work correctly, so I have integrated it. (SS)


tkt_uuid: 220350ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: focus -force if the window already has focus
comment:
  OriginalBugID: 588 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-05'
  Severity: LOW
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: 8.0.3
  ClosedDate: '1998-08-05'


  The focus -force option is supposed to make the application take the
  focus if some other application currently has it.  However, in Tk8.0p2
  this doesn't work if the new focus window is already the current focus
  window for the application.  Basically, the focus optimization does
  not consider the case when it must take input focus away from another
  application.

  The following trivial patch fixes the problem.

  Ian Taylor
  ian@cygnus.com

  *** /5g/ian/tk8.0p2/generic/tkFocus.c   Fri Oct 31 12:55:25 1997
  --- tkFocus.c   Tue Apr 14 13:06:25 1998
  *************** SetFocus(winPtr, force)
  *** 550,556 ****
        int allMapped, serial;
    
        displayFocusPtr = FindDisplayFocusInfo(winPtr->mainPtr, winPtr->dispPtr);
  !     if (winPtr == displayFocusPtr->focusWinPtr) {
          return;
        }
    
  --- 550,556 ----
        int allMapped, serial;
    
        displayFocusPtr = FindDisplayFocusInfo(winPtr->mainPtr, winPtr->dispPtr);
  !     if (winPtr == displayFocusPtr->focusWinPtr && ! force) {
          return;
        }
    


tkt_uuid: 220351ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Fix wm frame on Windows
comment:
  OriginalBugID: 589 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-05'
  Severity: LOW
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: 8.0.3
  ClosedDate: '1998-08-05'


  On Windows, using tk8.0p2, if you call wm frame immediately after

  creating a window, you are liable to get a segmentation violation.

  The Tk code does not check whether a window exists before getting the

  window identifier.



  The appended patch fixes this problem.  This patch appears to be

  required in Tk8.1a2 as well.



  Ian Taylor

  ian@cygnus.com





  *** /5g/ian/tk8.0p2/win/tkWinWm.c       Fri Oct 31 12:57:07 1997

  --- tkWinWm.c   Wed Apr 15 15:58:45 1998

  *************** Tk_WmCmd(clientData, interp, argc, argv)

  *** 1354,1359 ****

  --- 1354,1362 ----

                      argv[0], " frame window\"", (char *) NULL);

              return TCL_ERROR;

          }

  +       if (Tk_WindowId((Tk_Window) winPtr) == None) {

  +           Tk_MakeWindowExist((Tk_Window) winPtr);

  +       }

          hwnd = wmPtr->wrapper;

          if (hwnd == NULL) {

              hwnd = Tk_GetHWND(Tk_WindowId((Tk_Window) winPtr));





  applied patch 8/5/98 (SS)


tkt_uuid: 220352ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Handle ALT keys on Windows
comment:
  OriginalBugID: 590 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-05'
  Severity: LOW
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: 8.0.3
  ClosedDate: '1998-08-05'


  On Windows, ALT accelerator keys will arrive as WM_MENUCHAR messages.

  Tk8.0p2 and Tk8.1a2 ignore such messages.



  I have appended a patch to fix this.  This patch is due to Tom Tromey.



  Ian Taylor

  ian@cygnus.com



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

  --- tkWinX.c    Wed Apr 15 16:16:17 1998

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

  *** 16,21 ****

  --- 16,30 ----

    #include "tkWinInt.h"

    

    /*

  +  * MNC_CLOSE is not defined on Windows NT 3.5, but the value 1 is

  +  * the right thing to use.

  +  */

  + 

  + #ifndef MNC_CLOSE

  + #define MNC_CLOSE 1

  + #endif

  + 

  + /*

     * Definitions of extern variables supplied by this file.

     */

    

  *************** Tk_TranslateWinEvent(hwnd, message, wPar

  *** 593,598 ****

  --- 602,612 ----

          case WM_KEYUP:

              GenerateXEvent(hwnd, message, wParam, lParam);

              return 1;

  + 

  +       case WM_MENUCHAR:

  +           GenerateXEvent(hwnd, message, wParam, lParam);

  +           *resultPtr = MAKELONG (0, MNC_CLOSE);

  +           return 1;

        }

        return 0;

    }

  *************** GenerateXEvent(hwnd, message, wParam, lP

  *** 693,698 ****

  --- 707,713 ----

              event.xselectionclear.time = TkpGetMS();

              break;

              

  +       case WM_MENUCHAR:

          case WM_CHAR:

          case WM_SYSKEYDOWN:

          case WM_SYSKEYUP:

  *************** GenerateXEvent(hwnd, message, wParam, lP

  *** 765,770 ****

  --- 780,793 ----

                      event.xkey.keycode = wParam;

                      event.xkey.nchars = 0;

                      break;

  + 

  +               case WM_MENUCHAR:

  +                   /*

  +                    * For a WM_MENUCHAR message, the character code

  +                    * is only the low word.

  +                    */

  +                   wParam = LOWORD (wParam);

  +                   /* Fall through.  */

    

                  case WM_CHAR:

                      /*





  this patch has been applied


tkt_uuid: 220353ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Tk on Windows handles destroying menus poorly
comment:
  OriginalBugID: 591 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-03'
  Severity: SER
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: 8.0.3
  ClosedDate: '1998-08-03'


  In Tk8.0p2 on Windows, destroying a menu does not free some

  information, causing a memory leak.  It can also leave modalMenuPtr

  set to a bad value.



  Here is a simple patch to fix these problems.



  Ian Taylor

  ian@cygnus.com



  *** /5g/ian/tk8.0p2/win/tkWinMenu.c     Wed Oct 29 16:09:10 1997

  --- tkWinMenu.c Wed Apr 15 13:52:59 1998

  *************** TkpDestroyMenu(menuPtr)

  *** 343,351 ****

  --- 343,363 ----

                  }

              }

          } else {

  +           Tcl_HashEntry *hashEntryPtr;

  + 

  +           /* Remove the menu entry from the hash table.  */

  +           hashEntryPtr = Tcl_FindHashEntry(&winMenuTable,

  +                               (char *) winMenuHdl);

  +           if (hashEntryPtr != NULL) {

  +               Tcl_DeleteHashEntry(hashEntryPtr);

  +           }

              DestroyMenu(winMenuHdl);

          }

          menuPtr->platformData = NULL;

  +     }

  + 

  +     if (menuPtr == modalMenuPtr) {

  +       modalMenuPtr = NULL;

        }

    }

    





  Applied patch 8/3/98 (SS).


tkt_uuid: 220354ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: On Windows, don't let the mouse timer interfere with a size/move
comment:
  OriginalBugID: 592 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1999-08-15'
  Severity: SER
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-15'
  FixedInVersion: 8.2


  Tk8.0p2 on Windows uses a timer procedure to keep track of the mouse.

  This interacts badly with the Windows size or move commands.  A

  Windows size or move uses a Windows mouse capture.  If the Tk mouse

  timer fires, it will release the capture, which look bizarre.



  This does not normally affect Tk programs, since normally when a size

  or move command is started, the mouse is not actually inside the Tk

  window, and so Tk does not have a timer procedure running.  However,

  if you write C code to create a resize box inside your Tk window, and

  thus invoke the resizing from C, the Tk mouse timer may be running.



  The appended patch fixes this problem by turning off any pending mouse

  timer during a size or move operation.



  Tk8.1a2 appears to have the same problem.



  Ian Taylor

  ian@cygnus.com



  *** /5g/ian/tk8.0p2/win/tkWinPointer.c  Fri Oct 31 11:40:05 1997

  --- tkWinPointer.c      Wed Apr 15 14:59:42 1998

  *************** MouseTimerProc(clientData)

  *** 237,242 ****

  --- 237,267 ----

        GetCursorPos(&pos);

        Tk_PointerEvent(NULL, pos.x, pos.y);

    }

  + 

  + /*

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

  +  *

  +  * TkWinCancelMouseTimer --

  +  *

  +  *    If the mouse timer is set, cancel it.

  +  *

  +  * Results:

  +  *    None.

  +  *

  +  * Side effects:

  +  *    May cancel the mouse timer.

  +  *

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

  +  */

  + 

  + void

  + TkWinCancelMouseTimer()

  + {

  +     if (mouseTimerSet) {

  +       Tcl_DeleteTimerHandler(mouseTimer);

  +       mouseTimerSet = 0;

  +     }

  + }

    

    /*

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

  *** /5g/ian/tk8.0p2/win/tkWinWm.c       Fri Oct 31 12:57:07 1997

  --- tkWinWm.c   Wed Apr 15 15:01:23 1998

  *************** WmProc(hwnd, message, wParam, lParam)

  *** 3929,3934 ****

  --- 3929,3942 ----

    

          case WM_ENTERSIZEMOVE:

              inMoveSize = 1;

  + 

  +           /*

  +            * Cancel any current mouse timer.  If the mouse timer

  +            * fires during the size/move mouse capture, it will

  +            * release the capture, which is wrong.

  +            */

  +           TkWinCancelMouseTimer();

  + 

              oldMode = Tcl_SetServiceMode(TCL_SERVICE_ALL);

              break;

    





  This patch was integrated sometime before 8.2.0. 
  -- 08/15/1999 hobbs


tkt_uuid: 220355ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Fixed
title: Pressing Return in a message box does not honor button selection
comment:
  OriginalBugID: 593 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1999-08-15'
  Severity: SER
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-15'
  FixedInVersion: 8.2


  If you invoke tk_messageBox in Tk8.0p2 with a -default option, and use

  the tab key to move around between buttons, then when you press return

  you get the default button rather than the button which you have

  selected.



  This patch fixes that problem.



  Ian Taylor

  ian@cygnus.com



  *** /5g/ian/tk8.0p2/library/msgbox.tcl  Mon Aug  4 13:38:04 1997

  --- msgbox.tcl  Tue Apr 14 17:02:17 1998

  *************** proc tkMessageBox {args} {

  *** 200,205 ****

  --- 200,209 ----

              bind $w <Alt-[string tolower $key]>  "$w.$name invoke"

              bind $w <Alt-[string toupper $key]>  "$w.$name invoke"

          }

  + 

  +       # Bind all buttons so that <Return> activates them

  +       bind $w.$name <Return> "tkButtonInvoke $w.$name; break"

  + 

          incr i

        }



  This works as desired in 8.2, so was fixed in/before that release. 
  -- 08/15/1999 hobbs
  Clarification.  This worked as expected on Windows (system was
  not specified).  On Unix, this had the undesired behavior.  The
  fix is made for 8.2.1 to respond to <Return> in the same behavior
  as Windows does (that's what it was modelled on).

  To reiterate that behavior:

  With -default, the selected default has focus.  If you tab, the
  focus ring moves to a different button, and that is the one that
  will be triggered when you hit <Return>.

  Without -default, on Windows it defaults to the first button,
  and on Unix it defaults to neither (the first tab causes the
  first button to be selected).  Hitting <Return> will trigger
  the button with the current focus ring. 
  -- 08/15/1999 hobbs


tkt_uuid: 220356ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: On Windows, paste is Shift-Insert, not Insert
comment:
  OriginalBugID: 594 Bug
  Version: 8.0.3
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-05'
  Severity: LOW
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1998-08-05'


  On Windows, the Insert key does not do a paste operation.  The

  Shift-Insert key combination does.  In Tk8.0p2, entries bind Insert,

  but this is wrong, and it makes it awkward to bind Insert for anything

  else.



  The appended patch will fix this problem.



  Ian



  *** /5g/ian/tk8.0p2/library/entry.tcl   Thu Oct  9 13:39:36 1997

  --- entry.tcl   Tue Apr 14 16:39:05 1998

  *************** if {$tcl_platform(platform) == "macintos

  *** 206,213 ****

          bind Entry <Command-KeyPress> {# nothing}

    }

    

  ! bind Entry <Insert> {

  !     catch {tkEntryInsert %W [selection get -displayof %W]}

    }

    

    # Additional emacs-like bindings:

  --- 206,217 ----

          bind Entry <Command-KeyPress> {# nothing}

    }

    

  ! # On Windows, paste is done using Shift-Insert.  Shift-Insert already

  ! # generates the <<Paste>> event, so we don't need to do anything here.

  ! if {$tcl_platform(platform) != "windows"} {

  !     bind Entry <Insert> {

  !       catch {tkEntryInsert %W [selection get -displayof %W]}

  !     }

    }

    

    # Additional emacs-like bindings:



  applied patch 8/5/98 (SS)


tkt_uuid: 220357ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: On Windows, don't use a maximize box if the Windows is not resizable
comment:
  OriginalBugID: 595 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1999-03-17'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-03-17'
  FixedInVersion: 8.1b2


  On Windows, if a window is not resizable (because of a call to wm

  resizable), there is really no reason to have a maximize box or a

  sizing frame.  In fact, it's better to omit them, because they suggest

  to Windows users that the window can be resized, even though it can't.



  The appended patch makes this change in Tk8.0p2.  It should also apply

  to Tk8.1a2.



  Ian Taylor

  ian@cygnus.com



  *** /5g/ian/tk8.0p2/win/tkWinWm.c       Fri Oct 31 12:57:07 1997

  --- tkWinWm.c   Wed Apr 15 15:52:20 1998

  *************** UpdateWrapper(winPtr)

  *** 668,673 ****

  --- 668,678 ----

              wmPtr->exStyle = EX_TOPLEVEL_STYLE;

          }

    

  +       if ((wmPtr->flags & WM_WIDTH_NOT_RESIZABLE)

  +           && (wmPtr->flags & WM_HEIGHT_NOT_RESIZABLE)) {

  +           wmPtr->style &= ~ (WS_MAXIMIZEBOX | WS_SIZEBOX);

  +       }

  + 

          /*

           * Compute the geometry of the parent and child windows.

           */





  03/17/1999 15:05 - stanton - applied patch


tkt_uuid: 220358ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Report errors from menu invocations on Windows
comment:
  OriginalBugID: 596 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-04'
  Severity: SER
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1998-08-04'


  In Tk8.0p2, the Windows menu code does not report errors from

  TkPreprocessMenu or TkInvokeMenu.  Since both of those commands can

  run user written code, they need to report errors using

  Tcl_BackgroundError.



  Here is a patch which fixes this.  It also preserves the interpreter

  while invoking the user code.



  In Tk8.1a2, errors are correctly reported from TkInvokeMenu, but the

  interpreter is not preserved.  Errors are still not reported from

  TkPreprocessMenu.  I don't know if preserving the interpreter is

  important here; I did it because that is what other similar code does

  elsewhere.



  Ian Taylor

  ian@cygnus.com



  *** /5g/ian/tk8.0p2/win/tkWinMenu.c     Wed Oct 29 16:09:10 1997

  --- tkWinMenu.c Wed Apr 15 14:22:47 1998

  *************** TkWinHandleMenuEvent(phwnd, pMessage, pw

  *** 883,889 ****

                      ReconfigureWindowsMenu((ClientData) menuPtr);

                  }

                  if (!inPostMenu) {

  !                   TkPreprocessMenu(menuPtr);

                  }

                  TkActivateMenuEntry(menuPtr, -1);

                  *plResult = 0;

  --- 883,900 ----

                      ReconfigureWindowsMenu((ClientData) menuPtr);

                  }

                  if (!inPostMenu) {

  !                   Tcl_Interp *interp;

  !                   int code;

  ! 

  !                   interp = menuPtr->interp;

  !                   Tcl_Preserve((ClientData)interp);

  !                   code = TkPreprocessMenu(menuPtr);

  !                   if (code != TCL_OK && code != TCL_CONTINUE

  !                               && code != TCL_BREAK) {

  !                       Tcl_AddErrorInfo(interp, "\n    (menu preprocess)");

  !                       Tcl_BackgroundError(interp);

  !                   }

  !                   Tcl_Release((ClientData)interp);

                  }

                  TkActivateMenuEntry(menuPtr, -1);

                  *plResult = 0;

  *************** TkWinHandleMenuEvent(phwnd, pMessage, pw

  *** 904,909 ****

  --- 915,922 ----

                      if (mePtr != NULL) {

                          TkMenuReferences *menuRefPtr;

                          TkMenuEntry *parentEntryPtr;

  +                       Tcl_Interp *interp;

  +                       int code;

    

                          /*

                           * We have to set the parent of this menu to be active

  *************** TkWinHandleMenuEvent(phwnd, pMessage, pw

  *** 934,941 ****

                              }

                          }

    

  !                       TkInvokeMenu(mePtr->menuPtr->interp,

  !                               menuPtr, mePtr->index);

                      }

                      *plResult = 0;

                      returnResult = 1;

  --- 947,961 ----

                              }

                          }

    

  !                       interp = mePtr->menuPtr->interp;

  !                       Tcl_Preserve((ClientData)interp);

  !                       code = TkInvokeMenu(interp, menuPtr, mePtr->index);

  !                       if (code != TCL_OK && code != TCL_CONTINUE

  !                               && code != TCL_BREAK) {

  !                           Tcl_AddErrorInfo(interp, "\n    (menu invoke)");

  !                           Tcl_BackgroundError(interp);

  !                       }

  !                       Tcl_Release((ClientData)interp);

                      }

                      *plResult = 0;

                      returnResult = 1;





  Added patch 8/4/98 (SS)


tkt_uuid: 220359ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Use correct character widths on Windows
comment:
  OriginalBugID: 601 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-05'
  Severity: LOW
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: 8.0.3
  ClosedDate: '1998-08-05'


  The following comment appears in both Tk8.0p2 and Tk8.1a2 in the

  Tk_MeasureChars function in tkWinFont.c:


      /*

       * On the authority of the Gates Empire, Windows does not use kerning

       * or fractional character widths when displaying text on the screen.

       * So that means we can safely measure individual characters or spans

       * of characters and add up the widths w/o any "off-by-one pixel" 

       * errors.  

       */


  This comment is unfortunately not correct.  At least on Windows NT

  4.0, for at least some fonts, Windows does use kerning.  You can see

  this most obviously by creating a window which holds text in a bold

  font, and selecting characters with the mouse.  As you drag the mouse

  over characters, they will shift slightly.  This is because Tk is not

  computing the character widths consistently with how they are being

  displayed on the screen.


  The appended patch fixes this problem.


  This patch is for Tk8.0p2.  The code in Tk8.1a2 has changed fairly

  substantially, but, as far as I can tell, the code continues to have

  the same bug.  I hope this patch will indicate how Tk8.1a2 should be

  changed.  I can help port the patch to Tk8.1a2 if necessary.


  Ian Taylor

  ian@cygnus.com


  *** /5g/ian/tk8.0p2/win/tkWinFont.c     Thu May 15 20:15:03 1997

  --- tkWinFont.c Thu Apr 16 15:06:28 1998

  *************** typedef struct WinFont {

  *** 26,32 ****

        HFONT hFont;              /* Windows information about font. */

        HWND hwnd;                        /* Toplevel window of application that owns

                                   * this font, used for getting HDC. */

  -     int widths[256];          /* Widths of first 256 chars in this font. */

    } WinFont;


    /*

  --- 26,31 ----

  *************** Tk_MeasureChars(tkfont, source, numChars

  *** 332,345 ****

        HFONT hFont;

        int curX, curIdx;


  -     /*

  -      * On the authority of the Gates Empire, Windows does not use kerning

  -      * or fractional character widths when displaying text on the screen.

  -      * So that means we can safely measure individual characters or spans

  -      * of characters and add up the widths w/o any "off-by-one pixel" 

  -      * errors.  

  -      */

  - 

        fontPtr = (WinFont *) tkfont;


        hdc = GetDC(fontPtr->hwnd);

  --- 331,336 ----

  *************** Tk_MeasureChars(tkfont, source, numChars

  *** 351,425 ****

        } else if (maxLength <= 0) {

          SIZE size;


  !       GetTextExtentPoint(hdc, source, numChars, &size);

          curX = size.cx;

          curIdx = numChars;

        } else {

  !       int newX, termX, sawNonSpace;

  !       CONST char *term, *end, *p;

  !       int ch;


  !       ch = UCHAR(*source);

  !       newX = curX = termX = 0;

  !       

  !       term = source;

  !       end = source + numChars;


  !       sawNonSpace = !isspace(ch);

  !       for (p = source; ; ) {

  !           newX += fontPtr->widths[ch];

  !           if (newX > maxLength) {

  !               break;

              }

  !           curX = newX;

  !           p++;

  !           if (p >= end) {

  !               term = end;

  !               termX = curX;

  !               break;

              }


  !           ch = UCHAR(*p);

  !           if (isspace(ch)) {

  !               if (sawNonSpace) {

  !                   term = p;

  !                   termX = curX;

  !                   sawNonSpace = 0;

  !               }

  !           } else {

  !               sawNonSpace = 1;

  !           }

          }


  !       /*

  !        * P points to the first character that doesn't fit in the desired

  !        * span.  Use the flags to figure out what to return.

  !        */


  -       if ((flags & TK_PARTIAL_OK) && (p < end) && (curX < maxLength)) {

              /*

  !            * Include the first character that didn't quite fit in the desired

  !            * span.  The width returned will include the width of that extra

  !            * character.

               */

  ! 

  !           curX = newX;

  !           p++;

  !       }

  !       if ((flags & TK_AT_LEAST_ONE) && (term == source) && (p < end)) {

  !           term = p;

  !           termX = curX;

  !           if (term == source) {

  !               term++;

  !               termX = newX;

  !           }

  !       } else if ((p >= end) || !(flags & TK_WHOLE_WORDS)) {

  !           term = p;

  !           termX = curX;

          }


  !       curX = termX;

  !       curIdx = term - source; 

        }


        SelectObject(hdc, hFont);

  --- 342,411 ----

        } else if (maxLength <= 0) {

          SIZE size;


  !       GetTextExtentPoint32(hdc, source, numChars, &size);

          curX = size.cx;

          curIdx = numChars;

        } else {

  !       int max;

  !       int *partials;

  !       SIZE size;


  !       partials = (int *) ckalloc(numChars * sizeof (int));

  !       GetTextExtentExPoint(hdc, source, numChars, maxLength, &max,

  !                   partials, &size);


  !       if ((flags & TK_WHOLE_WORDS) && max < numChars) {

  !           int i;

  ! 

  !           /*

  !            * We need to back up through the word that fits at the

  !            * end of the line, and then back through any space

  !            * characters that may precede that word.  We start

  !            * backing up at MAX, because if MAX is a space we can

  !            * stop at MAX - 1.

  !            */

  !           i = max;

  !           while (i >= 0 && !isspace(source[i])) {

  !               --i;

              }

  !           while (i >= 0 && isspace(source[i])) {

  !               --i;

              }


  !           /*

  !            * We must have executed at least one --i, so this will

  !            * not set MAX larger than the original value.

  !            */

  !           max = i + 1;

          }


  !       if (max == 0) {

  !           curX = 0;

  !       } else {

  !           curX = partials[max - 1];

  !       }

  ! 

  !       if (((flags & TK_PARTIAL_OK)

  !            && max < numChars

  !            && curX < maxLength)

  !           || ((flags & TK_AT_LEAST_ONE)

  !               && max == 0

  !               && numChars > 0)) {


              /*

  !            * We want to include the first character that didn't

  !            * quite fit.  Call the function again to include the

  !            * width of the extra character.

               */

  !           GetTextExtentExPoint(hdc, source, max + 1, 0, NULL, partials,

  !                       &size);

  !           curX = partials[max];

  !           ++max;

          }


  !       ckfree((char *) partials);

  ! 

  !       curIdx = max;

        }


        SelectObject(hdc, hFont);

  *************** AllocFont(tkFontPtr, tkwin, hFont)

  *** 613,619 ****

        hFont = SelectObject(hdc, hFont);

        GetTextFace(hdc, sizeof(buf), buf);

        GetTextMetrics(hdc, &tm);

  -     GetCharWidth(hdc, 0, 255, fontPtr->widths);


        fontPtr->font.fid = (Font) fontPtr;


  --- 599,604 ----


tkt_uuid: 220360ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: tk_getOpenFile -multiple
comment:
  OriginalBugID: 604 RFE
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '2000-06-23'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: ericm
  RelatedBugIDs: 5496
  OS: All
  FixedDate: '2000-06-23'
  FixedInVersion: 8.4a2


  This patch adds support for a -multiple option to tk_getOpenFile.  If

  tk_getOpenFile is used with the argument -multiple 1, then it permits

  multiple files to be selected, and returns a list of all selected

  files.


  This patch only adds support for Unix and Windows.  I don't know how

  to do this on the Mac.  The Unix support is only implemented when

  Tk_StrictMotif is false.  It should be straightforward to extend it to

  the Motif style file dialog.


  This patch is due to Stephen Peters and Khamis Abuelkomboz.


  Ian Taylor

  ian@cygnus.com


  *** /5g/ian/tk8.0p2/doc/getOpenFile.n   Mon Dec  9 19:37:06 1996

  --- doc/getOpenFile.n   Fri Apr 17 12:49:13 1998

  *************** end user to override the application def

  *** 68,73 ****

  --- 68,78 ----

    Specifies a filename to be displayed in the dialog when it pops

    up. This option is ignored by the \fBtk_getOpenFile\fR command.

    .TP

  + \fB\-multiple\fR \fIboolean\fR

  + Specifies whether multiple files can be selected in the dialog

  + box.  \fIBoolean\fR may have any proper boolean value, such as

  + \fB1\fR or \fBno\fR.  Defaults to 0.

  + .TP

    \fB\-parent\fR \fIwindow\fR

    Makes \fIwindow\fR the logical parent of the file dialog. The file

    dialog is displayed on top of its parent window.

  *************** option is not specified, then a default 

  *** 78,85 ****

    option is ignored on the Macintosh platform.

    .PP

    If the user selects a file, both \fBtk_getOpenFile\fR and

  ! \fBtk_getSaveFile\fR return the full pathname of this file. If the

  ! user cancels the operation, both commands return the empty string.

    .SH "SPECIFYING FILE PATTERNS"


    The \fIfilePatternList\fR value given by the \fB\-filetypes\fR option

  --- 83,91 ----

    option is ignored on the Macintosh platform.

    .PP

    If the user selects a file, both \fBtk_getOpenFile\fR and

  ! \fBtk_getSaveFile\fR return the full pathname of this file. If the 

  ! \fB-multiple\fR option is used, a list of full pathnames will be returned.

  ! If the user cancels the operation, both commands return the empty string.

    .SH "SPECIFYING FILE PATTERNS"


    The \fIfilePatternList\fR value given by the \fB\-filetypes\fR option

  *** /5g/ian/tk8.0p2/library/tkfbox.tcl  Thu Oct  9 13:39:42 1997

  --- library/tkfbox.tcl  Fri Apr 17 12:48:11 1998

  *************** proc tkIconList_Config {w argList} {

  *** 52,57 ****

  --- 52,58 ----

        set specs {

          {-browsecmd "" "" ""}

          {-command "" "" ""}

  +       {-multiple "" "" "0"}

        }


        # 2: parse the arguments

  *************** proc tkIconList_Create {w} {

  *** 95,100 ****

  --- 96,102 ----


        bind $data(canvas) <1>         "tkIconList_Btn1 $w %x %y"

        bind $data(canvas) <B1-Motion> "tkIconList_Motion1 $w %x %y"

  +     bind $data(canvas) <Shift-1>   "tkIconList_ShiftBtn1 $w %x %y"

        bind $data(canvas) <Double-1>  "tkIconList_Double1 $w %x %y"

        bind $data(canvas) <ButtonRelease-1> "tkCancelRepeat"

        bind $data(canvas) <B1-Leave>  "tkIconList_Leave1 $w %x %y"

  *************** proc tkIconList_SelectAtXY {w x y} {

  *** 373,378 ****

  --- 375,392 ----

          [$data(canvas) canvasx $x] [$data(canvas) canvasy $y]]

    }


  + proc tkIconList_AddSelectAtXY {w x y {no_delete 0}} {

  +     upvar #0 $w data

  + 

  +     if {$data(-multiple) && [info exists data(selected)]} {

  +       tkIconList_AddSelect $w [$data(canvas) find closest \

  +               [$data(canvas) canvasx $x] [$data(canvas) canvasy $y]] \

  +               1 $no_delete

  +       return

  +     }

  +     tkIconList_SelectAtXY $w $x $y

  + }

  + 

    proc tkIconList_Select {w rTag {callBrowse 1}} {

        upvar #0 $w data

        upvar #0 $w:itemList itemList

  *************** proc tkIconList_Select {w rTag {callBrow

  *** 385,390 ****

  --- 399,410 ----

        set text   [lindex $itemList($rTag) 2]

        set serial [lindex $itemList($rTag) 3]


  +     if {$data(-multiple) && [info exists data(rect)]} {

  +       foreach r $data(rect) {

  +           $data(canvas) delete $r

  +       }

  +       unset data(rect)

  +     }

        if ![info exists data(rect)] {

            set data(rect) [$data(canvas) create rect 0 0 0 0 \

              -fill #a0a0ff -outline #a0a0ff]

  *************** proc tkIconList_Select {w rTag {callBrow

  *** 394,404 ****

        eval $data(canvas) coords $data(rect) $bbox


        set data(curItem) $serial

  !     set data(selected) $text


        if {$callBrowse} {

          if [string compare $data(-browsecmd) ""] {

  !           eval $data(-browsecmd) [list $text]

          }

        }

    }

  --- 414,492 ----

        eval $data(canvas) coords $data(rect) $bbox


        set data(curItem) $serial

  !     

  !     if {$data(-multiple)} {

  !       set data(selected) [list $text]

  !     } else {

  !       set data(selected) $text

  !     }

  !     

  !     if {$callBrowse} {

  !       if [string compare $data(-browsecmd) ""] {

  !           eval $data(-browsecmd) [list $data(selected)]

  !       }

  !     }

  ! }

  ! 

  ! proc tkIconList_AddSelect {w rTag {callBrowse 1} {no_delete 0}} {

  !     upvar #0 $w data

  !     upvar #0 $w:itemList itemList

  ! 

  !     if ![info exists itemList($rTag)] {

  !       return

  !     }

  !     set iTag   [lindex $itemList($rTag) 0]

  !     set tTag   [lindex $itemList($rTag) 1]

  !     set text   [lindex $itemList($rTag) 2]

  !     set serial [lindex $itemList($rTag) 3]

  ! 

  !     if {[lsearch -exact $data(selected) $text] != -1} {

  !       if {$no_delete} {

  !           return

  !       }

  !        

  !       # we've clicked on an existing item, so we need to remove it

  !       set i [lsearch -exact $data(selected) $text]

  !       set data(selected) [lreplace $data(selected) $i $i]

  !       

  !       # find the appropriate coordinates and remove the

  !       # corresponding rectangle.

  !       set tmpbbox [$data(canvas) bbox $tTag]

  !       for {set i 0} {$i<[llength $data(rect)]} {incr i} {

  !           set rectTag [lindex $data(rect) $i]

  !           set testbbox [$data(canvas) coords $rectTag]

  !           # test first two coordinates; if they're the same the

  !           # entire box should match

  !           if {[lindex $testbbox 0]==[lindex $tmpbbox 0] && \

  !                   [lindex $testbbox 1]==[lindex $tmpbbox 1]} {

  !               $data(canvas) delete $rectTag

  !               set data(rect) [lreplace $data(rect) $i $i]

  !               break

  !           }

  !       }

  ! 

  !       if {$callBrowse} {

  !           if [string compare $data(-browsecmd) ""] {

  !               eval $data(-browsecmd) [list $data(selected)]

  !           }

  !       }

  !       return

  !     }

  ! 

  !     set tmprect [$data(canvas) create rect 0 0 0 0 \

  !           -fill #a0a0ff -outline #a0a0ff]

  !     lappend data(rect) $tmprect

  ! 

  !     $data(canvas) lower $tmprect

  !     set bbox [$data(canvas) bbox $tTag]

  !     eval $data(canvas) coords $tmprect $bbox

  ! 

  !     set data(curItem) $serial

  !     lappend data(selected) $text


        if {$callBrowse} {

          if [string compare $data(-browsecmd) ""] {

  !           eval $data(-browsecmd) [list $data(selected)]

          }

        }

    }

  *************** proc tkIconList_Unselect {w} {

  *** 407,413 ****

        upvar #0 $w data


        if [info exists data(rect)] {

  !       $data(canvas) delete $data(rect)

          unset data(rect)

        }

        if [info exists data(selected)] {

  --- 495,503 ----

        upvar #0 $w data


        if [info exists data(rect)] {

  !       foreach r $data(rect) {

  !           $data(canvas) delete $r

  !       }

          unset data(rect)

        }

        if [info exists data(selected)] {

  *************** proc tkIconList_Btn1 {w x y} {

  *** 436,441 ****

  --- 526,538 ----

        tkIconList_SelectAtXY $w $x $y

    }


  + proc tkIconList_ShiftBtn1 {w x y} {

  +     upvar #0 $w data

  + 

  +     focus $data(canvas)

  +     tkIconList_AddSelectAtXY $w $x $y

  + }

  + 

    # Gets called on button-1 motions

    #

    proc tkIconList_Motion1 {w x y} {

  *************** proc tkIconList_Motion1 {w x y} {

  *** 443,449 ****

        set tkPriv(x) $x

        set tkPriv(y) $y


  !     tkIconList_SelectAtXY $w $x $y

    }


    proc tkIconList_Double1 {w x y} {

  --- 540,546 ----

        set tkPriv(x) $x

        set tkPriv(y) $y


  !     tkIconList_AddSelectAtXY $w $x $y 1

    }


    proc tkIconList_Double1 {w x y} {

  *************** proc tkFDialog_Config {w type argList} {

  *** 746,751 ****

  --- 843,851 ----

          {-parent "" "" "."}

          {-title "" "" ""}

        }

  +     if {![string compare $type open]} {

  +       lappend specs {-multiple "" "" "0"}

  +     }


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

        #

  *************** proc tkFDialog_Config {w type argList} {

  *** 772,778 ****

        #

        if [string compare $data(-initialdir) ""] {

          if [file isdirectory $data(-initialdir)] {

  !           set data(selectPath) [glob $data(-initialdir)]

          } else {

              error "\"$data(-initialdir)\" is not a valid directory"

          }

  --- 872,879 ----

        #

        if [string compare $data(-initialdir) ""] {

          if [file isdirectory $data(-initialdir)] {

  !           # Use lindex in case the pathname has an embedded space.

  !           set data(selectPath) [lindex [glob $data(-initialdir)] 0]

          } else {

              error "\"$data(-initialdir)\" is not a valid directory"

          }

  *************** proc tkFDialog_Config {w type argList} {

  *** 786,791 ****

  --- 887,902 ----

        if ![winfo exists $data(-parent)] {

          error "bad window path name \"$data(-parent)\""

        }

  + 

  +     # Set -multiple to a one or zero value (not other boolean types

  +     # like "yes") so we can use it in tests more easily.

  +     if {![string compare $type save]} {

  +       set data(-multiple) 0

  +     } else {

  +       if {$data(-multiple)} { 

  +           set data(-multiple) 1 

  +       }

  +     }

    }


    proc tkFDialog_Create {w} {

  *************** static char updir_bits[] = {

  *** 826,837 ****

        #

        set data(icons) [tkIconList $w.icons \

          -browsecmd "tkFDialog_ListBrowse $w" \

  !       -command   "tkFDialog_ListInvoke $w"]


        # f2: the frame with the OK button and the "file name" field

        #

        set f2 [frame $w.f2 -bd 0]

        label $f2.lab -text "File name:" -anchor e -width 14 -under 5 -pady 0

        set data(ent) [entry $f2.ent]


        # The font to use for the icons. The default Canvas font on Unix

  --- 937,952 ----

        #

        set data(icons) [tkIconList $w.icons \

          -browsecmd "tkFDialog_ListBrowse $w" \

  !       -command   "tkFDialog_ListInvoke $w" \

  !       -multiple  "$data(-multiple)"]


        # f2: the frame with the OK button and the "file name" field

        #

        set f2 [frame $w.f2 -bd 0]

        label $f2.lab -text "File name:" -anchor e -width 14 -under 5 -pady 0

  +     if {$data(-multiple)} {

  +       $f2.lab config -text "File names:"

  +     }

        set data(ent) [entry $f2.ent]


        # The font to use for the icons. The default Canvas font on Unix

  *************** proc tkFDialog_EntFocusOut {w} {

  *** 1225,1237 ****

    }


  ! # Gets called when user presses Return in the "File name" entry.

    #

  ! proc tkFDialog_ActivateEnt {w} {

        upvar #0 [winfo name $w] data


  !     set text [string trim [$data(ent) get]]

  !     set list [tkFDialogResolveFile $data(selectPath) $text \

                    $data(-defaultextension)]

        set flag [lindex $list 0]

        set path [lindex $list 1]

  --- 1340,1351 ----

    }


  ! # Verification procedure.

    #

  ! proc tkFDialog_VerifyFileName { w fname } {

        upvar #0 [winfo name $w] data


  !     set list [tkFDialogResolveFile $data(selectPath) $fname \

                    $data(-defaultextension)]

        set flag [lindex $list 0]

        set path [lindex $list 1]

  *************** proc tkFDialog_ActivateEnt {w} {

  *** 1245,1251 ****

                  $data(ent) delete 0 end

              } else {

                  tkFDialog_SetPathSilently $w $path

  !               set data(selectFile) $file

                  tkFDialog_Done $w

              }

          }

  --- 1359,1369 ----

                  $data(ent) delete 0 end

              } else {

                  tkFDialog_SetPathSilently $w $path

  !               if {$data(-multiple)} {

  !                   lappend data(selectFile) $file

  !               } else {

  !                   set data(selectFile) $file

  !               }

                  tkFDialog_Done $w

              }

          }

  *************** proc tkFDialog_ActivateEnt {w} {

  *** 1262,1268 ****

                  $data(ent) icursor end

              } else {

                  tkFDialog_SetPathSilently $w $path

  !               set data(selectFile) $file

                  tkFDialog_Done $w

              }

          }

  --- 1380,1390 ----

                  $data(ent) icursor end

              } else {

                  tkFDialog_SetPathSilently $w $path

  !               if {$data(-multiple)} {

  !                   lappend data(selectFile) $file

  !               } else {

  !                   set data(selectFile) $file

  !               }

                  tkFDialog_Done $w

              }

          }

  *************** proc tkFDialog_ActivateEnt {w} {

  *** 1292,1297 ****

  --- 1414,1435 ----

        }

    }


  + # Gets called when user presses Return in the "File name" entry.

  + #

  + proc tkFDialog_ActivateEnt {w} {

  +     upvar #0 [winfo name $w] data

  + 

  +     set text [$data(ent) get]

  +     if {$data(-multiple)} {

  +       set data(selectFile) ""

  +       foreach fname $text {

  +           tkFDialog_VerifyFileName $w $fname

  +       }

  +     } else {

  +       tkFDialog_VerifyFileName $w $text

  +     }

  + }

  + 

    # Gets called when user presses the Alt-s or Alt-o keys.

    #

    proc tkFDialog_InvokeBtn {w key} {

  *************** proc tkFDialog_OkCmd {w} {

  *** 1332,1341 ****


        set text [tkIconList_Get $data(icons)]

        if [string compare $text ""] {

  !       set file [tkFDialog_JoinFile $data(selectPath) $text]

  !       if [file isdirectory $file] {

  !           tkFDialog_ListInvoke $w $text

  !           return

          }

        }


  --- 1470,1481 ----


        set text [tkIconList_Get $data(icons)]

        if [string compare $text ""] {

  !       if {!$data(-multiple)} {

  !           set file [tkFDialog_JoinFile $data(selectPath) $text]

  !           if [file isdirectory $file] {

  !               tkFDialog_ListInvoke $w $text

  !               return

  !           }

          }

        }


  *************** proc tkFDialog_ListInvoke {w text} {

  *** 1386,1392 ****

          return

        }


  !     set file [tkFDialog_JoinFile $data(selectPath) $text]


        if [file isdirectory $file] {

          set appPWD [pwd]

  --- 1526,1536 ----

          return

        }


  !     if {$data(-multiple)} {

  !       set file [tkFDialog_JoinFile $data(selectPath) [lindex $text 0]]

  !     } else {

  !       set file [tkFDialog_JoinFile $data(selectPath) $text]

  !     }


        if [file isdirectory $file] {

          set appPWD [pwd]

  *************** proc tkFDialog_ListInvoke {w text} {

  *** 1399,1405 ****

              set data(selectPath) $file

          }

        } else {

  !       set data(selectFile) $file

          tkFDialog_Done $w

        }

    }

  --- 1543,1553 ----

              set data(selectPath) $file

          }

        } else {

  !       if {$data(-multiple)} {

  !           set data(selectFile) [list $file]

  !       } else {

  !           set data(selectFile) $file

  !       }

          tkFDialog_Done $w

        }

    }

  *************** proc tkFDialog_Done {w {selectFilePath "

  *** 1417,1424 ****

        global tkPriv


        if ![string compare $selectFilePath ""] {

  !       set selectFilePath [tkFDialog_JoinFile $data(selectPath) \

  !               $data(selectFile)]

          set tkPriv(selectFile)     $data(selectFile)

          set tkPriv(selectPath)     $data(selectPath)


  --- 1565,1579 ----

        global tkPriv


        if ![string compare $selectFilePath ""] {

  !       if {$data(-multiple)} {

  !           set selectFilePath {}

  !           foreach f $data(selectFile) {

  !               lappend selectFilePath [file join $data(selectPath) $f]

  !           }

  !       } else {

  !           set selectFilePath [tkFDialog_JoinFile $data(selectPath) \

  !                   $data(selectFile)]

  !       }

          set tkPriv(selectFile)     $data(selectFile)

          set tkPriv(selectPath)     $data(selectPath)


  *** /5g/ian/tk8.0p2/tests/filebox.test  Fri Oct 10 20:04:51 1997

  --- tests/filebox.test  Fri Apr 17 12:49:13 1998

  *************** if {$tcl_platform(platform) == "unix"} {

  *** 92,99 ****

        set modes 1

    }


  - set unknownOptionsMsg {1 {unknown option "-foo", must be -defaultextension, -filetypes, -initialdir, -initialfile, -parent or -title}}

  - 

    foreach mode $modes {


        #

  --- 92,97 ----

  *************** foreach mode $modes {

  *** 110,115 ****

  --- 108,119 ----

        #


        foreach command "tk_getOpenFile tk_getSaveFile" {

  + 

  +       if {$command == "tk_getOpenFile" && $mode == 0} {

  +           set unknownOptionsMsg {1 {unknown option "-foo", must be -defaultextension, -filetypes, -initialdir, -initialfile, -multiple, -parent or -title}}

  +       } else {

  +           set unknownOptionsMsg {1 {unknown option "-foo", must be -defaultextension, -filetypes, -initialdir, -initialfile, -parent or -title}}

  +       }


          test filebox-1.1 "$command command" {

              list [catch {$command -foo} msg] $msg

  *** /5g/ian/tk8.0p2/win/tkWinDialog.c   Tue Oct 28 11:37:34 1997

  --- win/tkWinDialog.c   Fri Apr 17 12:51:21 1998

  *************** GetFileName(clientData, interp, argc, ar

  *** 483,502 ****

         * 3. Process the results.

         */

        if (winCode) {

  !       char *p;

  !       Tcl_ResetResult(interp);

  ! 

  !       for (p = custData->szFile; p && *p; p++) {

              /*

  !            * Change the pathname to the Tcl "normalized" pathname, where

  !            * back slashes are used instead of forward slashes

               */

  !           if (*p == '\\') {

  !               *p = '/';

              }

          }

  -       Tcl_AppendResult(interp, custData->szFile, NULL);

  -       tclCode = TCL_OK;

        } else {

          tclCode = ProcessCDError(interp, CommDlgExtendedError(),

                  ofnPtr->hwndOwner);

  --- 483,553 ----

         * 3. Process the results.

         */

        if (winCode) {

  !       if (ofnPtr->Flags & OFN_ALLOWMULTISELECT) {

              /*

  !            * The result in custData->szFile contains many items,

  !            * separated with null characters.  It is terminated with

  !            * two nulls in a row.  The first element is the directory

  !            * path.

               */

  !           char *dir;

  !           int dirlen;

  !           char *p;

  !           Tcl_DString fullname;

  !           Tcl_ResetResult(interp);

  ! 

  !           /* Get directory */

  !           dir = custData->szFile;

  !           for (p = custData->szFile; p && *p; p++) {

  !               /*

  !                * Change the pathname to the Tcl "normalized" pathname, where

  !                * back slashes are used instead of forward slashes

  !                */

  !               if (*p == '\\') {

  !                   *p = '/';

  !               }

  !           }

  ! 

  !           if (p[1] == '\0') {

  !               /*

  !                * Only one file was returned.

  !                */

  !               Tcl_AppendElement(interp, dir);

  !           } else {

  !               while (*(++p)) {

  !                   char *filname = p;

  !                   for (; p && *p; p++) {

  !                       if (*p == '\\') { *p = '/'; }

  !                   }

  !                   Tcl_DStringInit(&fullname);

  !                   Tcl_DStringAppend(&fullname, dir, -1);

  !                   Tcl_DStringAppend(&fullname, "/", -1);

  !                   Tcl_DStringAppend(&fullname, filname, -1);

  !                   Tcl_AppendElement(interp, Tcl_DStringValue(&fullname));

  !                   Tcl_DStringFree(&fullname);

  !               }

              }

  +           tclCode = TCL_OK;

  +       } else {

  +           /*

  +            * Not a multiple-selection box; just treat it as a single

  +            * element.

  +            */

  +           char *p;

  +           Tcl_ResetResult(interp);

  +           

  +           for (p = custData->szFile; p && *p; p++) {

  +               /*

  +                * Change the pathname to the Tcl "normalized" pathname, where

  +                * back slashes are used instead of forward slashes

  +                */

  +               if (*p == '\\') {

  +                   *p = '/';

  +               }

  +           }

  +           Tcl_AppendResult(interp, custData->szFile, NULL);

  +           tclCode = TCL_OK;

          }

        } else {

          tclCode = ProcessCDError(interp, CommDlgExtendedError(),

                  ofnPtr->hwndOwner);

  *************** ParseFileDlgArgs(interp, ofnPtr, argc, a

  *** 639,644 ****

  --- 690,706 ----

              if (v==argc) {goto arg_missing;}


              ofnPtr->lpstrTitle = argv[v];

  +       }

  +       else if (strncmp(argv[i], "-multiple", len)==0) {

  +           int tmp;

  +           if (v==argc) {goto arg_missing;}

  + 

  +           if (Tcl_GetBoolean(interp, argv[i+1], &tmp) != TCL_OK) {

  +               return TCL_ERROR;

  +           }

  +           if (tmp) {

  +               ofnPtr->Flags |= OFN_ALLOWMULTISELECT;

  +           }

          }

          else {

              Tcl_AppendResult(interp, "unknown option \"", 




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

  - eric

  -- 06/22/2000 ericm


tkt_uuid: 220361ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 77. Square Demo
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: bug in Tk8.1 tkSquare.c example
comment:
  OriginalBugID: 613 Bug
  Version: 8.1a2
  SubmitDate: '1998-05-21'
  LastModified: '1998-11-19'
  Severity: SER
  Status: Released
  Submitter: hershey
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-19'
  FixedInVersion: 8.1b1


  Bug Report:
  Versions Affected: Tk 8.1a1 and 8.1a2
  Platforms: All

  There appears to be a typo in tkSquare.c for Tk8.1a[12]:

  tkSquare.c: line
      {TK_OPTION_BOOLEAN, "-dbl", "doubleBuffer", "DoubleBuffer",
              "1", Tk_Offset(Square, doubleBufferPtr) -1,},

                                          ^^^^

  The last "-1" and "," are transposed.  The code compiles, but leads to
  memory corruption.  Transposing them back seems to fix it.

  --mark

  -- 
  Mark A. Monheit                 direct: 650-858-6080
  Motorola, Lexicus Division      fax:    650-494-1143
  3145 Porter Drive               page:   800-SKYTEL2 id# 858-6080
  Palo Alto, CA  94304            email:  markm@lexicus.mot.com


tkt_uuid: 220362ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Typo in tkWinMenu.c causes bad window geoms
comment:
  OriginalBugID: 618 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1998-08-03'
  Severity: LOW
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: 8.0.3
  ClosedDate: '1998-08-03'



  Found a typo bug in tkWinMenu.c that causes incorrect geometry
  calculations for toplevels that have system menubars.  Symptoms of
  the bug are flickering size changes during mapping a toplevel.

  File: tkWinMenu.c
  Line: 541
  Routine: ReconfigureWindowsMenu
  Code:

      if ((menuPtr->menuType == MENUBAR)
              && (menuPtr->parentTopLevelPtr != NULL)) {
          width = Tk_Width(menuPtr->parentTopLevelPtr);
  //BUG   height = Tk_Width(menuPtr->parentTopLevelPtr);
          height = Tk_Height(menuPtr->parentTopLevelPtr);
      }


tkt_uuid: 220363ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: lost error messages for widget calls with bad args
comment:
  OriginalBugID: 619 Bug
  Version: 8.1a2
  SubmitDate: '1998-05-25'
  LastModified: '1998-11-30'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-30'
  FixedInVersion: 8.1b1


  The other day I noted that under some cirumstances I do not get

  any

  error message when using illegal arguments to widgets. The

  simplest

  way to see this is to start wish8.1 and give the command:

          checkbutton .c -varieble foo

  This gives no error message, which isn't what I had expected.

  The patch below fixes this problem.



          /MaF





  *** generic/tkButton.c.old      Mon Apr 27 23:51:05 1998

  --- generic/tkButton.c  Mon Apr 27 23:54:14 1998

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

  *** 983,988 ****

  --- 983,989 ----

        Tcl_Obj *CONST objv[];    /* Argument values. */

    {

        Tk_SavedOptions savedOptions;

  +     Tcl_Obj *errorResult;

        int error;

        Tk_Image image;



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

  *** 1024,1029 ****

  --- 1025,1032 ----

               * Second pass: restore options to old values.

               */



  +           errorResult = Tcl_GetObjResult(interp);

  +           Tcl_IncrRefCount(errorResult);

              Tk_RestoreSavedOptions(&savedOptions);

          }



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

  *** 1205,1211 ****

        }



        TkButtonWorldChanged((ClientData) butPtr);

  !     return (error) ? TCL_ERROR : TCL_OK;

    }



    /*

  --- 1208,1220 ----

        }



        TkButtonWorldChanged((ClientData) butPtr);

  !     if (error) {

  !       Tcl_SetObjResult(interp, errorResult);

  !       Tcl_DecrRefCount(errorResult);

  !       return TCL_ERROR;

  !     } else {

  !       return TCL_OK;

  !     }

    }



    /*


tkt_uuid: 220364ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: memory leaks in the menu code
comment:
  OriginalBugID: 620 Bug
  Version: 8.1a2
  SubmitDate: '1998-05-25'
  LastModified: '1998-11-24'
  Severity: SER
  Status: Released
  Submitter: hershey
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-19'
  FixedInVersion: 8.1b1


  The attached patch fixes a couple of memory leaks in the menu

  code of tk8.1a2.



          /MaF



  *** generic/tkMenu.c.old        Tue Mar 31 20:49:17 1998

  --- generic/tkMenu.c    Tue Mar 31 23:29:14 1998

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

  *** 1423,1428 ****

  --- 1423,1440 ----

        TkpDestroyMenuEntry(mePtr);

        TkMenuEntryFreeDrawOptions(mePtr);

        Tk_FreeConfigOptions((char *) mePtr, mePtr->optionTable,

  menuPtr->tkwin);

  +     if (mePtr->indicatorOnPtr != NULL) {

  +       Tcl_DecrRefCount(mePtr->indicatorOnPtr);

  +     }

  +     if (mePtr->hideMarginPtr != NULL) {

  +       Tcl_DecrRefCount(mePtr->hideMarginPtr);

  +     }

  +     if (mePtr->columnBreakPtr != NULL) {

  +       Tcl_DecrRefCount(mePtr->columnBreakPtr);

  +     }

  +     if (mePtr->statePtr != NULL) {

  +       Tcl_DecrRefCount(mePtr->statePtr);

  +     }

        ckfree((char *) mePtr);

    }





  11/24/1998 12:01 - stanton - This fix masked a more fundamental problem in the menu code.  The correct fix is to not allocate objects in the first place.


tkt_uuid: 220365ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: mac problem in tkOpenDocument
comment:
  OriginalBugID: 623 Bug
  Version: 8.1a2
  SubmitDate: '1998-05-25'
  LastModified: '2000-01-07'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: Japanese 8.1
  Machine: NA
  FixedDate: '2000-01-07'
  FixedInVersion: 8.3b1


  I am using MacTk 8.1a2 on Japanese MacOS8.1.

  I have tried to create an application by using "Drag & Drop Tclets",
  but the target application is not correctly created.

  Therefore I have examined "Drag & Drop Tclets", and found that
  "tkOpenDocument" passes the argument which contains invalid characters
  if the path name of the file dropped from finder contains international
  characters (i.e. shiftjis).

  I would like to modify the source of MacTk, but I have no compiler
  for Macintosh.

  I wish you to modify tkMacHLEvents.c in future version of MacTk
  like following.

  Thanks.

  -----------------------------------------------------------------------------
  [tkMacHLEvents.c, line 230-257]

      Tcl_DStringInit(&command);
  -    Tcl_DStringInit(&pathName);
      Tcl_DStringAppend(&command, "tkOpenDocument", -1);
      for (index = 1; index <= count; index++) {
          int length;
          Handle fullPath;

  -        Tcl_DStringSetLength(&pathName, 0);
          err = AEGetNthPtr(&fileSpecList, index, typeFSS,
                  &keyword, &type, (Ptr) &file, sizeof(FSSpec), &actual);
          if ( err != noErr ) {
              continue;
          }

          err = FSpPathFromLocation(&file, &length, &fullPath);
          HLock(fullPath);
  -        Tcl_DStringAppend(&pathName, *fullPath, length);
  +        Tcl_ExternalToUtfDString(NULL, *fullPath, length, &pathName );
          HUnlock(fullPath);
          DisposeHandle(fullPath);

          Tcl_DStringAppendElement(&command, pathName.string);
  +        Tcl_DStringFree( &pathName );
      }

      Tcl_GlobalEval(interp, command.string);

      Tcl_DStringFree(&command);
  -    Tcl_DStringFree(&pathName);
      return noErr;

  This got patched in as mentioned, but separately, somewhere along
  the way, and is in 8.3b1. 
  -- 01/07/2000 hobbs


tkt_uuid: 220366ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0
resolution: Fixed
title: bug with checkbutton on main menu frame
comment:
  OriginalBugID: 630 Bug
  Version: 8.0
  SubmitDate: '1998-05-25'
  LastModified: '2000-04-17'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-04-17'
  FixedInVersion: 8.3.1


  Ulrich Lauther <lauther@mchp.siemens.de> wrote:
  There seems to be a big problem when a checkbutton is added to a menubar.
  This becomes visible, when you add the two marked lines
  to the menu.tcl script in tk8.0/demos:

  menu .m
  foreach i {red orange yellow green blue} {
    .m add command -label $i -background $i  -command [list puts "You invoked \"$i\""]
  }

  .m add command -label "cmd" -command {puts cmd}
  .m add checkbutton -label "check"

  . configure -menu .m

  The first added line creates a button, as intended.
  The second one creates havoc!

  PS: This was under Unix. Under Windows, a checkbutton in the menubar
  appears, but the indicator is not displayed.



  Verified with 8.3b1.  There does seem to be some confusion when

  putting these on the main cascade, although they work in the

  drop-down cascades.  There could be some undoc'ed prohibition

  against this (or someone just forgot to code that case...). 

  -- 01/07/2000 hobbs


  .menu.menu invoke cmd

  .menu.menu invoke check


  both work; this might just be a binding problem.


  - eric


  -- 04/03/2000 ericm


  Yes, as I investigate further it seems to be just a binding problem.  However, on Windows, we allow the system to draw the menubar portion of the menu system, so the checkbutton does not get draw correctly.  It does work, however, in the sense that it toggles values appropriately.  I imagine it is probably an OS restriction that disallows checkbuttons/radiobuttons in menubars.


  I have a fix for the bindings:


  diff -c -r1.11 menu.tcl

  *** menu.tcl    2000/03/31 09:24:11     1.11

  --- menu.tcl    2000/04/14 20:46:11

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

  *** 655,661 ****

          tkMenuUnpost $w

        } elseif {[string equal [$w cget -type] "menubar"]} {

          $w postcascade none

  !       $w activate none

          event generate $w <<MenuSelect>>

          tkMenuUnpost $w

        } else {

  --- 655,666 ----

          tkMenuUnpost $w

        } elseif {[string equal [$w cget -type] "menubar"]} {

          $w postcascade none

  !       set active [$w index active]

  !       if { [$w type $active] == "cascade" } {

  !           $w activate none

  !       } else {

  !           uplevel #0 [list $w invoke $active]

  !       }

          event generate $w <<MenuSelect>>

          tkMenuUnpost $w

        } else {


  This needs some extra testing before it gets committed, though.


  - eric


  -- 04/14/2000 ericm


  I have committed this fix to CVS, and it will go out with 8.3.1.  It's important to note that because of system differences, the indicators may not be drawn on all platforms.  For example, Windows does not draw indicators for check/radiobuttons in menubars, although they still work correctly.  This fact is noted in the menu manual entry.


  - eric


  -- 04/17/2000 ericm


tkt_uuid: 220367ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: positionning tk_ dialog boxes
comment:
  OriginalBugID: 631 Bug
  Version: 8.0
  SubmitDate: '1998-05-25'
  LastModified: '1999-11-12'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-11-12'
  FixedInVersion: 8.3b1


  The option -parent associated with the standard dialogs
  (tk_messageBox, tk_getOpenFile ...) doesn't influence
  the positionning on Unix (solaris).
  The dialog box is always displayed in the middle
  of the virtual X window (a large one) in which our application 
  is running and not in the middle of the parent window (the application)
  while the option parent is specified as follows : "-parent ."

  thanks in advance for a solution

  Jean-Marie Condom

  |---------------------------------------------- 
  | Equipe Informatique Appliquee  
  | Universite de Pau et des Pays de l'Adour         
  | Avenue de l'universite        
  | 64000 Pau             
  | FRANCE
  | Email : condom@univ-pau.fr

  All fixed for 8.3b1. 
  -- 11/12/1999 hobbs


tkt_uuid: 220368ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0
resolution: Fixed
title: menubar problems
comment:
  OriginalBugID: 633 Bug
  Version: 8.0
  SubmitDate: '1998-05-25'
  LastModified: '1999-09-13'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-09-13'
  FixedInVersion: 8.2


  In my app I have a menubar constructed from a frame and a collection
  of menubuttons packed horizontally.

  In Tk8.0 on NT I have a problem when I press the mouse on a menubutton
  (say "File") and then run the mouse across the rest of the menubar.
  What happens is that the first pull-down menu appears under "File",
  but as the mouse (with button 1 down) moves out of the "File" menubutton
  into the next one, "Edit", the "File" pull-down stays posted.
  None of the other pull-downs get posted as the mouse passes over
  their menubutton. Only when I release the mouse does the original
  "File" menu disappear.

  On UNIX this doesn't happen, and it didn't happen in Tk4.2.

  Any ideas what is going on and how I can get the correct behaviour ?

  The big difference I have noticed between Tk8.0 on UNIX and NT seems
  to be that on NT the menu "post" command does not return until the menu
  is actually unposted! This can be seen because the -postcommand is not
  executed on posting but on unposting!

  Mark
  ----

  PS
  I have tried switching over to using the new -menu option on
  toplevel widgets combined with a "-type menubar" menu. This solves
  the problem so long as the toplevel is not marked as "wm transient".
  If the toplevel is transient then the menubar is displayed as usual
  but when the contents of the toplevel are packed they are packed
  over the top of the menubar making it disappear! I need the transient
  behaviour to ensure certain toplevels stay on top of the main toplevel.
  -- 

  ========================================================================
  Mark Gammon                                  Tel: int+44 (0) 1223 237111
  Principal Applications Engineer              Fax: int+44 (0) 1223 234192
  FEGS Ltd, Oakington House                    e-mail: m.gammon@fegs.co.uk
  Oakington, Cambridge CB4 5AF                 web:  http://www.fegs.co.uk
  England

  This was fixed in later versions of Tk, and works for sure in 8.2 
  -- 09/13/1999 hobbs


tkt_uuid: 220369ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: fix for tk menu bugs
comment:
  OriginalBugID: 636 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1998-08-04'
  Severity: SER
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1998-08-04'


  Viktor Dukhovni <Viktor-Dukhovni@deshaw.com>


  Fix list:


      TRANSPARENT_GIF_COLOR is obsolete.


      Use SHLIB_PATH on HP-UX.


      Raise background error when menu commands fail.


  Index: tcl/vspecific/tk/library/tkfbox.tcl

  diff -c tcl/vspecific/tk/library/tkfbox.tcl:1.1.1.1 tcl/vspecific/tk/library/tkfbox.tcl:1.1.1.1.2.1

  *** tcl/vspecific/tk/library/tkfbox.tcl:1.1.1.1 Thu Jan 29 13:55:21 1998

  --- tcl/vspecific/tk/library/tkfbox.tcl Thu Jan 29 14:03:18 1998

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

  *** 955,961 ****

          catch {unset data(updateId)}

        }


  -     set TRANSPARENT_GIF_COLOR [$w cget -bg]

        if ![info exists tkPriv(folderImage)] {

          set tkPriv(folderImage) [image create photo -data {

    R0lGODlhEAAMAKEAAAD//wAAAPD/gAAAACH5BAEAAAAALAAAAAAQAAwAAAIghINhyycvVFsB

  --- 955,960 ----

  Index: tcl/vspecific/tk/unix/Makefile.in

  diff -c tcl/vspecific/tk/unix/Makefile.in:1.1.1.1 tcl/vspecific/tk/unix/Makefile.in:1.1.1.1.2.1

  *** tcl/vspecific/tk/unix/Makefile.in:1.1.1.1   Thu Jan 29 13:55:27 1998

  --- tcl/vspecific/tk/unix/Makefile.in   Thu Jan 29 14:03:30 1998

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

  *** 320,325 ****

  --- 320,327 ----

    test: tktest

          LD_LIBRARY_PATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH}; \

          export LD_LIBRARY_PATH; \

  +       SHLIB_PATH=`pwd`:${TCL_BIN_DIR}:${SHLIB_PATH}; \

  +       export SHLIB_PATH; \

          TCL_LIBRARY=@TCL_SRC_DIR@/library; export TCL_LIBRARY; \

          TK_LIBRARY=$(TOP_DIR)/library; export TK_LIBRARY; \

          ( echo cd $(TOP_DIR)/tests\; source all\; exit ) \

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

  *** 330,335 ****

  --- 332,339 ----

    runtest:

          LD_LIBRARY_PATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH}; \

          export LD_LIBRARY_PATH; \

  +       SHLIB_PATH=`pwd`:${TCL_BIN_DIR}:${SHLIB_PATH}; \

  +       export SHLIB_PATH; \

          TCL_LIBRARY=@TCL_SRC_DIR@/library; export TCL_LIBRARY; \

          TK_LIBRARY=$(TOP_DIR)/library; export TK_LIBRARY; \

          ./tktest

  Index: tcl/vspecific/tk/win/tkWinMenu.c

  diff -c tcl/vspecific/tk/win/tkWinMenu.c:1.1.1.1 tcl/vspecific/tk/win/tkWinMenu.c:1.1.1.1.2.1

  *** tcl/vspecific/tk/win/tkWinMenu.c:1.1.1.1    Thu Jan 29 13:55:29 1998

  --- tcl/vspecific/tk/win/tkWinMenu.c    Thu Jan 29 14:04:14 1998

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

  *** 1,7 ****

    /* 

     * tkWinMenu.c --

     *

  !  *    This module implements the Mac-platform specific features of menus.

     *

     * Copyright (c) 1996-1997 by Sun Microsystems, Inc.

     *

  --- 1,7 ----

    /* 

     * tkWinMenu.c --

     *

  !  *    This module implements the Windows specific features of menus.

     *

     * Copyright (c) 1996-1997 by Sun Microsystems, Inc.

     *

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

  *** 904,909 ****

  --- 904,910 ----

                      if (mePtr != NULL) {

                          TkMenuReferences *menuRefPtr;

                          TkMenuEntry *parentEntryPtr;

  +                       int code;


                          /*

                           * We have to set the parent of this menu to be active

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

  *** 934,941 ****

                              }

                          }


  !                       TkInvokeMenu(mePtr->menuPtr->interp,

  !                               menuPtr, mePtr->index);

                      }

                      *plResult = 0;

                      returnResult = 1;

  --- 935,948 ----

                              }

                          }


  !                       code = TkInvokeMenu(mePtr->menuPtr->interp,

  !                                           menuPtr, mePtr->index);

  !                       if (code != TCL_OK && code != TCL_CONTINUE

  !                           && code != TCL_BREAK) {

  !                         Tcl_AddErrorInfo(mePtr->menuPtr->interp, 

  !                                          "\n    (menu invoke)");

  !                         Tcl_BackgroundError(mePtr->menuPtr->interp);

  !                       }

                      }

                      *plResult = 0;

                      returnResult = 1;




  Applied all patches 8/4/98 (SS)


tkt_uuid: 220370ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Tk_GetPixmap() broken on WinNT
comment:
  OriginalBugID: 638 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1999-11-02'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Windows NT
  FixedDate: '1999-11-02'
  FixedInVersion: 8.0.5


  kirka@analogy.com

     I am trying to print color images on NT, and I have just finished
  emulating XGetImage() and would like to test it.  But I crash when I
  call Tk_GetPixmap().  The code doesn't seem like it could work on NT.
  To  parallel the UNIX side, where Tk_GetPixmap() is just the thinest
  wrapper around XGetPixmap(), the second parameter is a Drawable.  But
  the windows code tries to cast that XID into a pointer to a
  TkWinDrawable.  That just doesn't seem like it is going to work.  And I
  don't see why one would want to  create all these new Windows drawable
  struct types.  A plain X window struct has a palette an any of other
  things one would need.  I don't see why the deviation from X.

    I would appreciate any information on how I could implement printing
  of color images on NT, or what the future of Tk_GetPixmap() will be, so
  I could stay compatible with future releases.

   Thanks, Kirk

  Tk_GetPixmap works as necessary on 8.0.5 and the 8.1+ Tk versions. 
  -- 11/02/1999 hobbs


tkt_uuid: 220371ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.0
resolution: Fixed
title: canvas tags bug
comment:
  OriginalBugID: 640 Bug
  Version: 8.0
  SubmitDate: '1998-05-25'
  LastModified: '1999-09-14'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-09-14'
  FixedInVersion: 8.2
  ClosedDate: '1999-09-13'


      I just found a very irritating bug in binding
  Tk canvas tags.  Asking for a binding for a non-existant
  canvas tag causes an error, but not an error message,
  making it very hard to track down a related bug.
  Strangely, Tk lets you create bindings to non-existant
  tags without complaint, which is very useful.

  netscape is very stupid and I have no middle mouse
  button so I have to type this in by hand, so forgive
  any errors

  plato% wish8.0
  % canvas .c
  % .c bind fred <Enter>
  % set errorInfo

      while executing
  ".c bind fred <Enter>"
  % .c bind fred <Enter> "puts hello"
  % .c bind fred <Enter>
  puts hello
  %

  -peter.
  pfl@fmsc.com.au

  Testing this in 8.2, I get:

  (tkcon) 54 % catch {.c bind bogus <Enter>}
  0

  which means that an error is not getting generated. 
  -- 09/13/1999 hobbs


tkt_uuid: 220372ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Bug in tkWinWm.c
comment:
  OriginalBugID: 641 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1999-08-06'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  Found a bug in tkWinWm.c that causes system menubars to disappear
  from toplevel widgets if the toplevel style is changed,
  e.g. by using wm transient or wm overrideredirect.

  File: tkWinWm.c
  Line: 734
  Routine: UpdateWrapper
  Code:

      if (oldWrapper && (oldWrapper != wmPtr->wrapper) 
              && (oldWrapper != GetDesktopWindow())) {
          SetWindowLong(oldWrapper, GWL_USERDATA, (LONG) NULL);

  /* bug fix: Must remove any system menubar before deleting wrapper
   *          else the menubar gets deleted too !
   */
          SetMenu(oldWrapper,NULL);


          DestroyWindow(oldWrapper);
      }


  This fix exists in the 8.2b2 code. 
  -- 08/06/1999 hobbs


tkt_uuid: 220373ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Fixed
title: bug in msgbox.tcl
comment:
  OriginalBugID: 644 Bug
  Version: 8.0
  SubmitDate: '1998-05-25'
  LastModified: '1999-08-14'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-14'
  FixedInVersion: 8.2


  The documentation for tk_messageBox -icon (7.6) says that

  - icon
  Specifies an icon to display. Icon must be one of the
  following: error, info, question or warning. If this option is not specified, then no icon will be displayed.

  However, for both 7.6 and 8.0, the default icon is info.  It looks 
  like "" would be acceptable except in line 51 of 8.0 version which
  checks for the possible values but not for "".  Inserting "" in that
  lsearch line gives no icon at all (which is what I am looking for).

  So something should be changed, although I am not sure which is the
  desired default: info or nothing.

  Thank you

  Bob Johnson
  johnsonb@gav.gat.com



  This was a documentation error, as info was always programmed
  as the default icon.  It is possible to not have a default
  icon by changing tkMessageBox on Unix and Tk_MessageBoxObjCmd
  on Windows (no ORing of the icon flag will cause no icon to
  be displayed).  I would have to check on the Mac.  You could
  make an RFE of this if you like. 
  -- 08/14/1999 hobbs


tkt_uuid: 220374ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: disable canvas text drawing without deleting item
comment:
  OriginalBugID: 648 RFE
  Version: 8.0p1
  SubmitDate: '1998-05-25'
  LastModified: '1999-12-13'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-12-13'
  FixedInVersion: 8.3b1


  Is this a bug fix or a feature? Let the team at Sun decide ...



  This fix allows one to disable canvas text item drawing (e.g., at

  certain zoom levels) without deleting the item, consistent with what

  is already possible for lines and other canvas items.



  Note that if you don't want transparent items to be selectable,

  bind something alongside the following procedure to them:



  proc select {x y} {

      set x [.pad canvasx $x]

      set y [.pad canvasy $y]

      set startpid [.pad find withtag current]

      set pid $startpid

      while {1} {

          if {[.pad itemcget $pid -fill]!=""} {

              dowhateveryouwant $pid

              break

          }

          set pid [.pad find closest $x $y 0 $pid]

          if {$pid==$startpid} break

      }

  }



  Regards,

  Sebastian Wangnick

  --

  Sebastian Wangnick <sebastian.wangnick@eurocontrol.be>

  Office: Eurocontrol Maastricht UAC, Horsterweg 11, NL-6191RX Beek,

          Tel: +31-433661370, Fax: ~300

  Home:   Lammersdorfer Str. 61, D-52159 Rott, Tel: +49-2471-2301,

          Fax: ~2313, Email: familie.wangnick@t-online.de



  ---

  diff -rc tk8.0p1.orig/doc/canvas.n tk8.0p1/doc/canvas.n

  *** tk8.0p1.orig/doc/canvas.n   Fri Oct 31 20:58:54 1997

  --- tk8.0p1/doc/canvas.n        Fri Nov 14 14:45:16 1997

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

  *** 1446,1451 ****

  --- 1446,1453 ----

    \fB\-fill \fIcolor\fR

    \fIColor\fR specifies a color to use for filling the text characters;

    it may have any of the forms accepted by \fBTk_GetColor\fR.

  + If \fIcolor\fR is an empty string then the text will be

  + transparent.

    If this option isn't specified then it defaults to \fBblack\fR.

    .TP

    \fB\-font \fIfontName\fR

  diff -rc tk8.0p1.orig/generic/tkCanvText.c tk8.0p1/generic/tkCanvText.c

  *** tk8.0p1.orig/generic/tkCanvText.c   Sat Oct 11 01:04:57 1997

  --- tk8.0p1/generic/tkCanvText.c        Thu Nov 13 13:47:55 1997

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

  *** 86,92 ****

          "center", Tk_Offset(TextItem, anchor),

          TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_COLOR, "-fill", (char *) NULL, (char *) NULL,

  !       "black", Tk_Offset(TextItem, color), 0},

        {TK_CONFIG_FONT, "-font", (char *) NULL, (char *) NULL,

          DEF_CANVTEXT_FONT, Tk_Offset(TextItem, tkfont), 0},

        {TK_CONFIG_JUSTIFY, "-justify", (char *) NULL, (char *) NULL,

  --- 86,92 ----

          "center", Tk_Offset(TextItem, anchor),

          TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_COLOR, "-fill", (char *) NULL, (char *) NULL,

  !       "black", Tk_Offset(TextItem, color), TK_CONFIG_NULL_OK},

        {TK_CONFIG_FONT, "-font", (char *) NULL, (char *) NULL,

          DEF_CANVTEXT_FONT, Tk_Offset(TextItem, tkfont), 0},

        {TK_CONFIG_JUSTIFY, "-justify", (char *) NULL, (char *) NULL,



  8.3 has a -state field (with hidden) for all item types. 
  -- 12/13/1999 hobbs


tkt_uuid: 220375ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: mac error of type 2
comment:
  OriginalBugID: 649 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1999-09-13'
  Severity: CRIT
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-09-13'
  FixedInVersion: 8.2


  As I run my 8.0p2 wish application on MAC OS 8,
  invariably at some point I'll get the message from the
  system that wish has caused an error of type 2.... please
  save and reboot. This happens on different machines
  and the code is all native tcl/tk. Is there a known way
  around this. I increase memory allocation to a preferred
  8000, but it didn't stop it.

  From: Robert Karen <robert@namsi.com>
  ----

  PPS. I'm using 8.1 on a G3 Powerbook, but had the same problem with system 8.0.
  I increased memory to 25,000k but that didn't help either.

  Uwe Behrens <behrens@acm.org>

  No reports of this type appear for 8.2, so we can assume it has
  been fixed.  However, 8.2 must be compiled with a large stack
  size to avoid an exploding regexp stack (to be fixed in 8.3 hopefully). 
  -- 09/13/1999 hobbs


tkt_uuid: 220376ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: entry box look and feel
comment:
  OriginalBugID: 655 Bug
  Version: 8.0p1
  SubmitDate: '1998-05-25'
  LastModified: '1999-09-13'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-09-13'
  FixedInVersion: 8.2


  The LOOK of a disable (-state disable) vs. enabled (-state normal)
  widget varies from widget to widget and from platform to platform and,
  in some cases, is broken.  I haven't monkeyed with menus.  I can tell
  you that entry widgets don't follow native look and feel on UNIX (Motif)
  and NT.  I've attached an entry sub-class which fixes this in Tcl.  I
  wouldn't ordinarily post such a long script but I've tried to upload
  this to the Neosoft archives and failed so here it is for whoever can
  make good use of it.

  ---
  # entry.tcl --
  #
  # Fix-up native look-and-feel of entry widgets for NT and UNIX.
  #
  # Chris Nelson (nelson@pinebush.com)  28 Apr 1998
  #
  #------------------------------------------------------------------------
  # Widgets sub-classed from [entry] to deal with a problem with native
  # look-and-feel regarding the coloring of disabled entries.
  #
  # In Motif, the background of entries is always the same (generally
  # the same as the window background) and disabled entries have their
  # foreground greyed out.
  #
  # In Windows NT, the foreground of entries is always the same
  # (generally the same as the window text color) and the background
  # changes when an entry is enabled or disabled.  Generally, the
  # background is white for enabled entries, and the same color as the
  # window background for disabled entries.  (This tends to give stronger
  # visual feedback about the state of the UI.)
  #
  # In Tk 8.0, entries do not change colors at all when they are
  # disabled.
  #
  # This script "sub-classes" [entry] by replacing the default widget proc
  # with a wrapper which takes special actions on state change.  Thanks
  # to Bryan Oakley for the basic technique which he also implemented in
  # his supertext widget; a sub-class of [text] which include undo
  # commands.
  #
  # The general sub-classing technique is:
  #
  #    proc newEntry { w args } {
  #        set e [entry $w $args]
  #        rename $e ${e}_base
  #        bind $e <Destroy> {+ rename ${e}_base {}}
  #        proc $e { args }  #            "set w $e;set baseProc ${e}_base;[info body wrapperProc]"
  #    }
  #
  # You could then replace all calls to [entry] with [newEntry].  An
  # alternative might be to have start up code like:
  #
  #    rename entry tkEntry
  #    proc entry { w args } {
  #       set e [tkEntry $w $args]
  #       ...
  #    }
  #
  # Then the sub-classed entry is used by default everywhere.  This
  # second technique is implemented in this script.
  #
  #
  # NOTE: we CANNOT just have wrapperProc figure out the base proc
  # and/or widget name with introspection like:
  #
  #     set baseProc "[lindex [info level] 0]_base"
  # 
  # because the new proc we create as $e might have been renamed AGAIN.
  # For example, if the entry widget for <path>.e proc is renamed
  # .<path>.e so the above would set baseProc to .<path>.e_orig (not
  # <path>.e_orig), which would be either undefined or not the proc we
  # want.
  #
  # Since we can't rely in [info] or other introspection routines to
  # tell us what we want to know at run time, we need to bind this
  # information when we know it -- as the proc is created -- we do this
  # by pre-pending two lines to the body of the wrapper as shown.
  #
  #------------------------------------------------------------------------

  # Remember how to get to the core function.
  rename entry tkEntry

  # A proc to create the new, sub-classed widget
  proc entry {w args} {
      # Create the basic entry
      uplevel 1 [list tkEntry $w] $args

      # Put our own proc on the widget
      #
      # It would be safer to do something like:
      #    for { set baseName ${w}_base }  #             { [catch {rename $w $baseName}] }  #             { set baseName "${baseName}_" } {
      #       # Empty - work done in test
      #    }
      # but ...
      rename $w ${w}_base
      # Sometimes <Destroy> event handlers get called twice so we 
      # [catch] the rename so it doesn't fail the second time.
      bind $w <Destroy> [list + catch [list rename ${w}_base {}]]
      proc $w { args }  "set w $w;set baseProc ${w}_base;[info body EntryProc]"

      return $w
  }
  # entry

  # A replacement for the entry widget proc which deals with colors for
  # state change for better native look-and-feel.
  #
  # Never, EVER call this directly.  entry creates a derived widget
  # proc by using [info body] to get EntryProc's body and prepending
  # the setting of w and baseProc.  See detailed comments on
  # sub-classing above.
  proc EntryProc { args } {
      set stateIndex [lsearch -exact $args "-state"]
      if { $stateIndex != -1 } {
          incr stateIndex
          set state [lindex $args $stateIndex]
          switch -- $state {
              normal -
              disabled {
                  EntryState $w $baseProc $state
              }
              default {
                  # Don't error here because command might be "$e cget -state"
                  # Original proc will catch other errors
              }
          }
          # switch
      }
      # If state control
      eval $baseProc $args
  }
  # EntryProc

  # Respond to state change for an entry
  proc EntryState { w baseProc state } {
      global EntryStateInited
      if { ! [info exists EntryStateInited] } {
          InitEntryState $w
          set EntryStateInited 1
      }

      switch -- $state {
          normal {
              $baseProc configure  -foreground [option get $w *Entry.Foreground Foreground]  -background [option get $w *Entry.Background Background]
          }
          disabled {
              $baseProc configure  -foreground  [option get $w *Entry.DisabledForeground DisabledForeground]  -background  [option get $w *Entry.DisabledBackground DisabledBackground]
          }
          default {
              error "incorrect state $state for entry"
          }
      }
      # switch
  }
  # EntryState

  #
  # Adjust entry colors so that disabled entries are deemphasized.
  # Season to taste. ;-)
  proc InitEntryState { w } {
      global tcl_platform

      # If we've been here before, get on with it.
      if { [option get $w *Entry.DisabledForeground DisabledForeground] != "" } {
          return
      }

      # Create a button and an entry (that we'll never pack)
      # so we can query their attributes
      set b [button .b11111111]
      set e [entry  .e22222222]

      # Set options to be used by proc that disables entries
      if {$tcl_platform(platform) == "unix"} {
          # Put the default entry foreground in the option db for later use.
          option add  *Entry.Foreground [$e cget -foreground] widgetDefault

          # The entry foreground should work like the button foreground
          option add  *Entry.DisabledForeground   [$b cget -disabledforeground]   widgetDefault

          # An entry background doesn't change on UNIX.
          option add  *Entry.Background [$e cget -background] widgetDefault
          option add  *Entry.DisabledBackground  [$e cget -background] widgetDefault
      } else {
          # An entry foreground doesn't chage on NT.
          option add  *Entry.Foreground [$e cget -foreground] widgetDefault
          option add  *Entry.DisabledForeground  [$e cget -foreground] widgetDefault

          # Put the default entry background in the option db for later use.
          option add  *Entry.Background  [$e cget -background] widgetDefault

          # The entry background is like the button background when disabled.
          option add  *Entry.DisabledBackground  [$b cget -background] widgetDefault
      }

      # Get rid of the widgets we queried
      destroy $b
      destroy $e
  }
  # InitEntryState

  #------------------------------------------------------------------------
  # Ugly little proc to show what the "patch" does
  proc entryColorTest { } {
      foreach cmd { tkEntry entry } label { Core Patched } {
          set f [frame .$cmd -relief ridge -borderwidth 2]
          pack $f -side top -padx 1m -pady 1m

          label $f.l -text $label
          pack $f.l -side top

          foreach n { 0 1 } {
              frame $f.$n
              pack $f.$n -side top -padx 1m

              global EntryState$cmd$n
              checkbutton $f.$n.cb -variable EntryState$cmd$n
              $cmd $f.$n.e
              $f.$n.e insert end "Some text"
              pack $f.$n.cb $f.$n.e -side left

              trace variable EntryState$cmd$n w [list ChangeEntryState $f.$n.e]
              set EntryState$cmd$n $n
          }
          # foreach
      }
      #foreach

      button .b -text "Exit" -command "exit"
      pack .b -padx 2m -pady 2m
  }
  # entryColorTest

  # Helper for entryColorTest - enabled and disables the entry
  # associated with a check button.
  proc ChangeEntryState { entry name1 name2 op } {
      upvar #0 $name1 state
      if { $state } {
          $entry configure -state normal
      } else {
          $entry configure -state disabled
      }
  }



  The entry widgets follow basic native LAF, and can be better
  configured by the user through the use of available options. 
  -- 09/13/1999 hobbs


tkt_uuid: 220377ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Menubar keystroke access in Linux
comment:
  OriginalBugID: 656 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1999-09-13'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Linux
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-09-13'
  FixedInVersion: 8.0.5


          I am slowly bringing myself into version 8, and hitting a snag
  with the menubar.  We have an application that has the new menubar
  style stuff working fine under Wiundows NT, but when I run it 
  under LInux, and try to use the keypress, I get the following error.

  BACKGROUND ERROR:
  grab failed: window not viewable

  ERRORCODE = NONE

  ERRORINFO =
  grab failed: window not viewable
          while executing
  "grab -global $w"
          (procedure "tkTraverseToMenu" line 21)
          invoked from within
  "tkTraverseToMeny .foo f"
          (command bound to event)

          The code for tkTraverse... is in lib/tk8.0/menu.tcl.

          The code we use to start the menu bar is..
  [snip]
  set m [menu $foo.menu -tearoff 0 -type menubar]

  #
  ########## FILE MENU
  #

  menu $m.file -tearoff 0

  $m add cascade -label "File" -menu $m.file -underline 0
  $m.file add separator
  $m.file add command -label "Quit "  -command "foo_Quit $foo" -underline 0

          Is this common?  Is there something that is WinNT dependant
  that I can switch off in the initialization of the menubar?
  Inside menu.tcl, they do some unix dependant switching.. so maybe
  I need to do something during init.

  From: Joshua Lamorie <jlamorie@engsoc.carleton.ca>

  This problem was fixed in a patch release. 
  -- 09/13/1999 hobbs


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


  From: Sandeep Pathak <sandeep@gti.com>

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

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

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


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

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


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

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

  -sandeep
  sandeep@gti.com

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


tkt_uuid: 220379ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Windows doesn't have keysyms for the context menu and start keys
comment:
  OriginalBugID: 666 Bug
  Version: 8.0p2
  SubmitDate: '1998-07-06'
  LastModified: '1998-08-05'
  Severity: SER
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: 8.0.3
  ClosedDate: '1998-08-05'


  From: "Martin Lemburg" <lembur-m@rzbt.fh-hamburg.de>
  Subject: [WinTcl] An idea how to use the Window and Context-Menu-Keys?

  I'tried to use the left and right Windows-Key and the Context-Menu-Key in binding sequences, but I'm not able to use the keycodes of those keys in these binding sequences.

  If I use following code than following informations about the mentioned keys are returned:

  % bind . <KeyPress> { puts "%A - %k - %K" }

  Left Window-Key:  {} - 91 - ??
  Right Window-Key: {} - 92 - ??
  Context-Menu-Key: {} - 93 - ??

  I want to use the keys with virtual events generated by the event-command.

  Does anybody know in which way a key could be mentioned in a binding sequence if the key doesn't have a keysym?

  The only way I know to use the keys is with following code (a kind of eventhandler):

  % bind . <KeyPress> {+
  >switch %k {
  >91{ puts "Left WindowsKey" }
  >92{ puts "Right WindowsKey" }
  >93{ puts "ContextMenuKey" }
  >}
  >}



  We need to add keysyms for these three keys under Windows


tkt_uuid: 220380ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: UNIX cascade menus auto-posted
comment:
  OriginalBugID: 676 Bug
  Version: 8.0.3
  SubmitDate: '1998-09-09'
  LastModified: '2000-03-06'
  Severity: LOW
  Status: Released
  Submitter: lfb
  ChangedBy: ericm
  RelatedBugIDs: 691 1320
  OS: All Unix
  FixedDate: '2000-03-06'
  FixedInVersion: 8.3.1


  When a menu containing a cascade is entered under UNIX, the cascade menu is automatically posted, and the focus redirected to that cascade menu.  With nested cascades, entering a top level menu can instantly summon a distant child. (lfb)

  e.g.: Run this script, and enter the File menu with the mouse or keyboard

  menu .menu
  .menu add cascade -label "File" -menu .menu.f -underline 0

  menu .menu.f
  .menu.f add cascade -label "New" -menu .menu.f.new -underline 0

  menu .menu.f.new
  .menu.f.new add cascade -label "File" -underline 0

  . configure -menu .menu



  This is verified "quirk".  The problem is that if you take away
  the piece that auto-posts cascades like the above, then when
  you move left/right in the menubar, you will not autopost those
  menus either (instead having to arrow down into it, as you
  expect one to arrow right in the above case).  To look for a
  better solution, edit tkMenuNextEntry in menu.tcl. 
  -- 08/13/1999 hobbs

  This is fixed in 8.3.1.  I changed tkMenuFirstEntry to only post a first entry that is a cascade if the current menu is a menubar, thus avoiding the cascading cascades effect.

  - eric

  -- 03/06/2000 ericm


tkt_uuid: 220381ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: display popup window in center of screen rather than left corner
comment:
  OriginalBugID: 687 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-02'
  LastModified: '1999-08-13'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-13'
  FixedInVersion: 8.1.1


  Hi,
          For what your information when running on Windows NT 4.0 Service
  Pack 3 I have found that the files dialog.tcl and msgbox.tcl need to
  have the following mods made for the popup window to be displayed in the
  center of the screen as intended rather than the upper left corder:

  bash-2.01$ diff dialog.tcl dialog.tcl.orig
  134,136d133
  <     if {$tcl_platform(platform) == "windows"} {
  <          update idletasks
  <     }

  bash-2.01$ diff msgbox.tcl msgbox.tcl.orig
  224,226d223
  <     if {$tcl_platform(platform) == "windows"} {
  <          update idletasks
  <     }

  I believe this same detail was in prior Versions of Tcl/Tk and has
  perhaps been reported by others but is is still there and is annoying.

  Thanks
  Kevin

  This was fixed in or before 8.1.1. 
  -- 08/13/1999 hobbs


tkt_uuid: 220382ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Tk envent loop is too slow on Mac
comment:
  OriginalBugID: 688 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-02'
  LastModified: '1999-11-30'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-11-30'
  FixedInVersion: 8.2.1


  > >This is basically a bug.  Mac Tk just updates too slowly.  The event loop
  > >& "update" mechanism in Tk needs to be redone to better handle the
  > >exteremly slow event loop on the Mac.


  Tested the 8.2.1 version on a PPC machine with tetris at
  level 17, and it moves the pieces at least as fast as my
  NT machine at the same level (as in, it moves along). 
  -- 11/30/1999 hobbs


tkt_uuid: 220383ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: incompatibility betw. Tix and 8.0.3 (with patch)
comment:
  OriginalBugID: 716 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-13'
  LastModified: '1999-12-21'
  Severity: SER
  Status: Released
  Submitter: admin
  ChangedBy: hobbs
  RelatedBugIDs: 720 1355 1376 2492
  OS: All Unix
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-12-21'
  FixedInVersion: 8.3b1


  A while ago I noticed a problem when we first tried to convert to 8.0,

  and that was that the application would crash with the following error:


  > X Error of failed request:  BadWindow (invalid Window parameter)

  >   Major opcode of failed request:  40 (X_TranslateCoords)

  >   Resource id in failed request:  0x1400246

  >   Serial number of failed request:  15956

  >   Current serial number in output stream:  15956


  It seemed to be related to including Tix calls, and so I sent a message

  to the Tix mailing list to see if anyone else had encountered it.

  Other people had, and I was sent the attached patch to tkUnixWm.c.

  I applied the patch, and it worked fine.  Now, with 8.0.3, it is 

  dumping again with the same error.


  *** tkUnixWm.c.org      Thu Aug 14 00:24:53 1997

  --- tkUnixWm.c  Tue Aug 26 08:31:09 1997

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

  *** 3377,3382 ****

  --- 3377,3383 ----

                  if (root == None) {

                      root = RootWindowOfScreen(Tk_Screen((Tk_Window)winPtr));

                  }

  +

                  XTranslateCoordinates(winPtr->display, winPtr->window,

                      root, 0, 0, &rootX, &rootY, &dummyChild);

                  x += rootX;

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

  *** 3434,3439 ****

  --- 3435,3441 ----

        int x, y, childX, childY, tmpx, tmpy, bd;

        WmInfo *wmPtr;

        TkWindow *winPtr, *childPtr, *nextPtr;

  +     Tk_ErrorHandler handler;


        /*

         * Step 1: scan the list of toplevel windows to see if there is a

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

  *** 3472,3483 ****

  --- 3474,3494 ----

         *    the toplevel.

         */


  +     handler = Tk_CreateErrorHandler(Tk_Display(tkwin), -1, -1, -1,

  +           (Tk_ErrorProc *) NULL, (ClientData) NULL);

  +

        while (1) {

  +

          if (XTranslateCoordinates(Tk_Display(tkwin), parent, window,

                  x, y, &childX, &childY, &child) == False) {

  +

  +           fprintf (stderr, "Tk_CoordsToWindow got False return from

  XTranslateCoordinates\n");

  +           fflush (stderr);

  +           return NULL;

              panic("Tk_CoordsToWindow got False return from XTranslateCoordinates");

          }

          if (child == None) {

  +           Tk_DeleteErrorHandler(handler);

              return NULL;

          }

          for (wmPtr = firstWmPtr; wmPtr != NULL; wmPtr = wmPtr->nextPtr) {

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

  *** 3499,3504 ****

  --- 3510,3517 ----

        }


        gotToplevel:

  +

  +     Tk_DeleteErrorHandler(handler);

        winPtr = wmPtr->winPtr;

        if (winPtr->mainPtr != ((TkWindow *) tkwin)->mainPtr) {

          return NULL;




  The same translate problem is seen, always with Tix involved,
  from the following people:
  alan.davis@convergys.com robert.r.ratcliff@boeing.com danny.bach@boeing.com gustin@uia.ua.ac.be david.tillman@jhuapl.edu
  See related ids for more. 
  -- 08/14/1999 hobbs
  Fixed for 8.3b1. 
  -- 12/21/1999 hobbs


tkt_uuid: 220384ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: text selection highlight bug on Windows
comment:
  OriginalBugID: 721 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-13'
  LastModified: '1999-08-06'
  Severity: MED
  Status: Released
  Submitter: admin
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-06'
  FixedInVersion: 8.0.4


  ReproducibleScript:  text .t -width 40 -height 20
  pack .t
  .t insert 0.0 "this is such\na fun story\n"
  .t insert end "really?"

  button .b -text select -command {.t tag add sel 2.0 2.end}
  button .c -text remove -command {.t tag remove sel 2.0 2.end}
  button .e -text exit -command {exit}
  pack .b .c .e

  #focus .t

  ObservedBehavior: after script is started, click on "select", nothing
  will be highlighted.

  DesiredBehavior: if i click on "select", line 2 should be highlighted,
  "remove" will remove the highlight.

  Comments: it worked great on UNIX, but failed in Windows NT.  however,
  it'll work on NT if i uncomment the focus command.


  This works as expected with 8.0.4. 
  -- 08/06/1999 hobbs


tkt_uuid: 220385ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Tk8.0.3 'wm iconname' memory leak
comment:
  OriginalBugID: 728 Bug
  Version: 8.0.4
  SubmitDate: '1998-10-13'
  LastModified: '1998-10-13'
  Severity: MED
  Status: Released
  Submitter: admin
  ChangedBy: rjohnson
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-10-13'
  FixedInVersion: NA


  This was fixed by a patch someone else submitted. (RJ)


  There is a memory leak in 'wm iconname', so that the following
  self-reposting code continuously increases the heap size of the
  process:

  #! /bin/sh
  # exec wish $0

  wm geometry . 0x0+0+0
  wm iconify .
  proc daemon {} {
  wm iconname . gag
  after 10 daemon ;# so that heap grows faster !!!
  }
  daemon


tkt_uuid: 220386ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Null color means transparent for all objects except text.
comment:
  OriginalBugID: 738 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-15'
  LastModified: '1998-10-15'
  Severity: LOW
  Status: Released
  Submitter: welch
  ChangedBy: rjohnson
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-10-15'
  FixedInVersion: 8.0.4


  Jan Nijtmans says:

  The following bug has been submitted to me for inclusion
  in the dash-patch in May 1998. I fulfilled this request.
  In my opinion it is important enough to bring it to the
  attention of Scriptics again, hoping it will be put into
  Tk8.0.4. The attached "tkCanvText.txt" contains a
  newly generated diff in respect to Tk8.0.3.

  The effect of this bug can be seen by this code:
       canvas .c
       pack .c
       .c create text 100 100 -text abc
       .c itemconfig 1 -fill {}
  Although the canvas man-page doesn't specify what
  happens if the fill option is given an empty
  string, the most logical thing to do (compared with
  all other canvas widgets) is to make the text invisible.
  Currently the text will be black.

  In the functions ConfigureText(), DeleteText() and
  TextToPostscript(), explicit tests are done if
  the fill option (the variable "color") holds a NULL
  pointer. Currently that is impossible, because the
  lack of the TK_CONFIG_NULL_OK flag already forbids
  this. It looks as if this behavior is unintentional,
  otherwise there would be no need to perform such check.
  This was enough evidence for me to consider the
  current behavior a bug.

  Strictly speaking, this patch introduces a
  "Potention incompatibility". However, because the
  initial value of the "-color" option is "black"
  and setting it to "" has no effect now, it just
  makes no sense for any application to set this
  option to the empty string. I don't know any
  application that does this, except applications
  that expect the text to become invisible (as the
  referenced discussion in comp.lang.tcl suggests).
  After including it in the dash-patch, I never received
  any complaint about this "potential incompatability".
  Therefore I see no danger putting it into the core.


  This is a one-bit patch.



  diff -rc tk8.0p1.orig/doc/canvas.n tk8.0p1/doc/canvas.n

  *** tk8.0p1.orig/doc/canvas.n   Fri Oct 31 20:58:54 1997

  --- tk8.0p1/doc/canvas.n        Fri Nov 14 14:45:16 1997

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

  *** 1446,1451 ****

  --- 1446,1453 ----

    \fB\-fill \fIcolor\fR

    \fIColor\fR specifies a color to use for filling the text characters;

    it may have any of the forms accepted by \fBTk_GetColor\fR.

  + If \fIcolor\fR is an empty string then the text will be

  + transparent.

    If this option isn't specified then it defaults to \fBblack\fR.

    .TP

    \fB\-font \fIfontName\fR

  diff -rc tk8.0p1.orig/generic/tkCanvText.c tk8.0p1/generic/tkCanvText.c

  *** tk8.0p1.orig/generic/tkCanvText.c   Sat Oct 11 01:04:57 1997

  --- tk8.0p1/generic/tkCanvText.c        Thu Nov 13 13:47:55 1997

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

  *** 86,92 ****

          "center", Tk_Offset(TextItem, anchor),

          TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_COLOR, "-fill", (char *) NULL, (char *) NULL,

  !       "black", Tk_Offset(TextItem, color), 0},

        {TK_CONFIG_FONT, "-font", (char *) NULL, (char *) NULL,

          DEF_CANVTEXT_FONT, Tk_Offset(TextItem, tkfont), 0},

        {TK_CONFIG_JUSTIFY, "-justify", (char *) NULL, (char *) NULL,

  --- 86,92 ----

          "center", Tk_Offset(TextItem, anchor),

          TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_COLOR, "-fill", (char *) NULL, (char *) NULL,

  !       "black", Tk_Offset(TextItem, color), TK_CONFIG_NULL_OK},

        {TK_CONFIG_FONT, "-font", (char *) NULL, (char *) NULL,

          DEF_CANVTEXT_FONT, Tk_Offset(TextItem, tkfont), 0},

        {TK_CONFIG_JUSTIFY, "-justify", (char *) NULL, (char *) NULL,

  --


tkt_uuid: 220387ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: wish crashes in scrollbar code if locale is not
comment:
  OriginalBugID: 744 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-19'
  LastModified: '1999-10-22'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-10-22'
  FixedInVersion: 8.2


  I would like to report a bug, which affects the wish program, if
  the character-type locale is set to something other than C.

  Reproduce-by:

  setenv LC_CTYPE de_DE

  and execute following script:

  === snip ===
  #!/usr/bin/wish -f

  frame .main
  listbox .list -yscrollcommand ".sb set" 
  scrollbar .sb
  pack .list -side left -in .main
  pack .sb -side left -fill y -in .main

  pack .main 
  === snip ===

  The program reports:

  Error: unknown floating-point error, errno = 84

  and the stack trace is

  unknown floating-point error, errno = 84
      while executing
  ".sb set 0 1"
      (vertical scrolling command executed by listbox)


  Environment:

  Linux 2.1.125
  glibc 2.0.7
  Tcl/Tk 8.0.3

  Errno 84 is
  #define EILSEQ          84      /* Illegal byte sequence */

  which is probably a bit confusing - I suspect something
  like reading errno when no error was returned from the
  syscall or something like this.

  Regards
  --
  Stanislav Meduna



  Tcl is not designed to run in anything but "C" locale, so this isn't a critical problem.  That said, it still shouldn't crash.
  ---
  This is no longer pertinent in 8.2, as code exists to maintain
  "acceptable" locales for use with X and i18n. 
  -- 10/22/1999 hobbs


tkt_uuid: 220388ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: F10 does not post a menu on Win NT
comment:
  OriginalBugID: 746 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-21'
  LastModified: '1999-08-06'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  Test script:

  wm title . "Solitaire"

  frame .mbar -borderwidth 2 -relief raised
  pack .mbar -side top -fill x

  menubutton .mbar.game -text "Game" -menu .mbar.game.menu
  pack .mbar.game -side left -padx 4

  menu .mbar.game.menu
  .mbar.game.menu add command -label "Deal" -command {
      exit
  }
  .mbar.game.menu add separator
  .mbar.game.menu add command -label "Quit" -command {
      exit
  }

  Run this script on Solaris and press F10. The first menu button is activated. This does not happen on Win NT. However, if the menu is created by assigning it to the toplevel window with -menu, the F10 key seems to work fine. The new menu is created as follows:

  wm title . "Solitaire"

  menu .mbar 
  . configure -menu .mbar

  .mbar add cascade -label "Game" -menu .mbar.game
  menu .mbar.game
  .mbar.game add command -label "Deal" -command {
      exit
  }
  .mbar.game add command -label "Quit" -command {
      exit
  }



  8.2 (fixed somewhere earlier) has the bindings for F10 and
  regular menubuttons in core now. 
  -- 08/06/1999 hobbs


tkt_uuid: 220389ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: underlines don't map to character offsets in unicode strings
comment:
  OriginalBugID: 747 Bug
  Version: 8.1a2
  SubmitDate: '1998-10-21'
  LastModified: '1999-03-29'
  Severity: LOW
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  RelatedBugIDs: 1060
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-03-29'
  FixedInVersion: 8.1b3


  menu .m
  .m add command -label foo\u00c3bar -underline 4
  .m post 1 1

  The underline doesn't show up

  Here is an additional manifestation:

  From: Ben Elliston <bje@cygnus.com>
  Cc: tcl-i18n@egroups.com
  Subject: [tcl-i18n] i18n bug in Tk menus
  Newsgroups: comp.lang.tcl

  The following message is a courtesy copy of an article
  that has been posted to comp.lang.tcl as well.

  I feel I have found a bug in the underline handling for menu buttons
  in Tcl/Tk 8.1a2--in relation to encoding support for i18n.

  Here is a tiny uuencoded file that contains two Kanji characters (ShiftJIS
  encoded) followed by the menu hotkey, as is typically shown in
  Japanised applications.  Suppose our two Kanji characters are `#' and
  `*' respectively.  The string in the file is:

  #*(V)

  (for a total of 5 characters).

  begin 644 shiftjis.str
  )E5R.IBA;5BD*
  `
  end

  First, we'll use wish to read this string into a variable:

  set f [open shiftjis.str r]
  fconfigure $f -encoding shiftjis
  set jstring [read $f]

  # Verify it. Tcl will translate Kanji chars to `?' for your
  # Western terminal.
  puts stdout $jstring

  Next, we'll create a menu button and label it with our string:

  menubutton .mb -text $jstring
  pack .mb

  Since we have five characters, you would expect that underlining index
  0 of the menu button label to underline `#' and index 3 to underline `V'.
  Underlining `V' is what I want to do.

  Interesting things happen if you manually underline each index in turn
  and observe:

  .mb configure -underline 0
  .mb configure -underline 1
  .mb configure -underline 2
  .mb configure -underline 3
  .mb configure -underline 4
  .mb configure -underline 5
  .mb configure -underline 6
  .mb configure -underline 7

  The underlining appears for index 0, but not 1 or 2, 3 but not 4 or
  5.  It appears for 6 and 7.  Underlining position 7 is what is
  required to underline `V'.


  Tk_UnderlineChars is passing character indices to Tk_MeasureChars instead of byte offsets. (fixed)

  There is still some other problem that manifests for the Japanese characters in question.

  03/25/1999 18:49 - stanton -
  It appears that menubuttons still aren't I18N clean.

  All of the font API's have been standardized.
  03/29/1999 19:56 - stanton -


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


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



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


tkt_uuid: 220391ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: Compilation on DEC Alpha with MS VC++ 4.2-5.0 failed
comment:
  OriginalBugID: 763 Bug
  Version: 8.1a2
  SubmitDate: '1998-10-27'
  LastModified: '1998-12-10'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-12-10'
  FixedInVersion: 8.1b1


  Subject: Alpha-specific bug in Tk/winMain.c/WishPanic (MSVC++)
  From: petteri.kettunen@picker.fi

  Tk 8.1a2 Bug
  email:  petteri.kettunen@picker.fi
  Severity:  1
  Support:  None
  OperatingSystem:  Windows NT
  Extensions:  N/A
  CustomShell:  N/A
  Synopsis:  Alpha-specific bug in Tk/winMain.c/WishPanic (MSVC++)

  ReproducibleScript:
  Take source distribution and compile in DEC Alpha with MS VC++ 4.2-5.0.
  We have encountered this problem with 8.0p2/8.1a2.

  ObservedBehavior:
  Compilation fails (line 203)

  DesiredBehavior:
  Clean compilation.

  Patch:
  C:\tk\tmp>diff winMain.c.old winMain.c
  202c202
  < #ifdef _MSC_VER
  ---
  > #if defined(_MSC_VER) && defined(_X86_)


  12/10/1998 10:41 - stanton - The _asm statement has been replaced with the more portable DebugBreak() call.


tkt_uuid: 220392ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Performance problem in Tk: hidden windows do excessive redisplay
comment:
  OriginalBugID: 791 Bug
  Version: 8.0.4
  SubmitDate: '1998-11-04'
  LastModified: '1999-12-14'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-12-14'
  FixedInVersion: 8.2.2


  There's a problem with the entry widget, try this:

          pack [entry .e -textvariable foo]
          set foo abcdefgh
          foreach i {0 1 2 3 4 5 6 7 8 9} {set foo $foo$foo}
          focus .e
          update
          # this is what ^E does
          puts [time [tkEntrySetCursor .e end; update]]

  The window with the letters in pops up almost immediately, but I've
  typed all this and the simulated ^E still hasn't come back.  Actually,
  the reported time was 127 microseconds, but in that 127 microseconds I
  started up wish4.2 to see if the bug was there as well.  It is.

  There's a possibly related problem with geometry management.  If I
  have a stack of text widgets all the same size managed by the placer
  (basically these windows are all on top of each other), then a change
  in geometry of the enclosing window seems to take an age.  It gets
  up to a second or two when I get to 25 windows which seems a trifle
  excessive.  I get the impression that all these text widgets are busily
  re-configuring and re-drawing themselves even though they aren't
  actually visible.  I don't have anything more concrete than this I'm
  afraid.



  The entry widget problem is likely due to an overaggressive
  accuracy check (in a while loop) in the entry widget bindings.
  This was solved in 8.2.2. 
  -- 12/14/1999 hobbs


tkt_uuid: 220393ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: Patch to display Unicode in title bars and menubars
comment:
  OriginalBugID: 819 Bug
  Version: 8.1a2
  SubmitDate: '1998-11-12'
  LastModified: '1999-05-20'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: hershey
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-19'
  FixedInVersion: 8.1b1


  Contributed patch from Syd Polk.
  "Here are patches to display japanese correctly in title bars and menubars."

  Patch on the website as
  /patches/tk8.1a2/tkWinWm.c.txt


tkt_uuid: 220394ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: alternate font syntaxes do not work on some X servers
comment:
  OriginalBugID: 846 Bug
  Version: 8.0.3
  SubmitDate: '1998-11-24'
  LastModified: '1998-11-24'
  Severity: SER
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-24'
  FixedInVersion: 8.0.5


  The following script fails to display correctly on some X servers (e.g. Exceed v6) because the servers claim to find a font for any string, even if it doesn't really match anything:

  label .l -text foobar -font {Courier 36}
  pack .l



  The TkpGetNativeFont routine on Unix needs to weed out suspicious font names so Tk gets a chance to parse them.


tkt_uuid: 220395ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: hidemargin broken in tk8.1a2 under UNIX
comment:
  OriginalBugID: 859 Bug
  Version: 8.1a2
  SubmitDate: '1998-11-25'
  LastModified: '1998-11-25'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-25'
  FixedInVersion: 8.1b1


          the -hidemargin option for menu items is broken in tk8.1
  under UNIX.  Menu items have a margin added to them even when
  '-hidemargin 1' is used on all items in a menu.

  Patch included in patches page


tkt_uuid: 220396ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: Disabled menu entries gets enabled
comment:
  OriginalBugID: 860 Bug
  Version: 8.1a2
  SubmitDate: '1998-11-25'
  LastModified: '1998-12-10'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: admin
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-25'
  FixedInVersion: 8.1b1


  In tk8.1a2 disabled menu entries gets reenabled as soon as you pass
  the cursor over them. The attached patch fixes this.

  Patch on the website as
  /patches/tk8.1a2/tkMenu.c.2.txt


tkt_uuid: 220397ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: listbox extended mode script bug
comment:
  OriginalBugID: 866 Bug
  Version: 8.0.3
  SubmitDate: '1998-11-25'
  LastModified: '1999-08-06'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  Date: Wed, 4 Nov 1998 12:01:45 -0800 (PST)

  To: tclsupport@scriptics.com

  Subject: listbox extended mode script bug

  From: rembleton@hilbertsoft.com



  Tk 8.0.3 Bug



  email:  rembleton@hilbertsoft.com

  Support:  None

  Severity:  2

  OperatingSystem:  Windows NT

  OperatingSystemVersion:  4.0 SR3

  Synopsis:  listbox extended mode script bug



  ReproducibleScript:

  ## enter the following in the wish console



  entry .e

  listbox .lb -selectmode extended

  pack .e .lb

  .lb insert end 1

  .lb insert end 2



  ## set the focus in .e

  ## tab to .lb

  ## press Shift-Down





  ObservedBehavior:

  Since there is no selection, the tk code fails and generates the following:



  bad listbox index "": must be active, anchor, end, @x,y, or a number

      while executing

  "$w selection clear $i $el"

      ("extended" arm line 7)

      invoked from within

  "switch [$w cget -selectmode] {

  browse {

      $w selection clear 0 end

      $w selection set $el

      set tkPriv(listboxPrev) $el

  }

  extended {

      ..."

      (procedure "tkListboxMotion" line 7)

      invoked from within

  "tkListboxMotion $w [$w index active]"

      (procedure "tkListboxExtendUpDown" line 7)

      invoked from within

  "tkListboxExtendUpDown .lb -1"

      (command bound to event)





  DesiredBehavior:

  the system should select the first two elements of the listbox





  Fixed in 8.2b3 release. 
  -- 08/06/1999 hobbs


tkt_uuid: 220398ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: tkOpenDocument is not internationalized
comment:
  OriginalBugID: 869 Bug
  Version: 8.1a2
  SubmitDate: '1998-11-25'
  LastModified: '1999-05-20'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: hershey
  OS: Macintosh
  OSVersion: 8.1
  Machine: NA
  FixedDate: '1998-11-25'
  FixedInVersion: 8.1b1


  I am using MacTk 8.1a2 on Japanese MacOS8.1.

  I have tried to create an application by using "Drag & Drop Tclets",
  but the target application is not correctly created.

  Therefore I have examined "Drag & Drop Tclets", and found that
  "tkOpenDocument" passes the argument which contains invalid characters
  if the path name of the file dropped from finder contains international
  characters (i.e. shiftjis).


  see the patch at /patches/tk8.1a2/tkMacHLEvents.c.txt


tkt_uuid: 220399ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Missing keysyms on Windoze (Bug)
comment:
  OriginalBugID: 870 Bug
  Version: 8.0.3
  SubmitDate: '1998-11-25'
  LastModified: '2000-04-13'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: ericm
  RelatedBugIDs: 1160 947 2487
  OS: All
  FixedDate: '2000-04-13'
  FixedInVersion: 8.3.1


  From: "DUPERVAL, LAURENT" <laurent.duperval@bellsygma.com>
  Subject: Missing keysyms on Windoze (Bug)
  Date: Wed, 21 Oct 1998 13:26:39 -0400

  I tested keysyms on Linux and on WinNT with the following code:

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

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

  I didn't find anything to this effect in Dejanews. Looking in win/tkWinKey.c, it looks like the {Shift|Alt|Control}_R keys are undefined, but I dunno for what reason (not explained in source code). I'm guessing that Windows can't make a difference between left and right keys (which would be stoopid but not surprising) or that a conscious decision was made not to support this on Windoze (which is a bad decision IMHO). As for the
  Menu/App difference, I'm at a lost.



  The Linux problems are likely all due to key mapping.  They are
  unlikely to recognize the new Win* name, and use Meta* as a good
  replacement.

  The problem with *_L and *_R seems to be a Windows quirk or bug. 
  -- 10/21/1999 hobbs

  --

  The problem on Windows is that Windows only gives us an undifferentiated "Control is pressed" message -- it does not distinguish between left and right keys.  However, we can query this information explicitly ourselves, if we see that Control (or Shift, or Alt) is pressed.  I added the code to do this; the fix will go out with 8.3.1.

  - eric

  -- 04/13/2000 ericm


tkt_uuid: 220400ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Problems using exec with the Tk Console
comment:
  OriginalBugID: 872 Bug
  Version: 8.0.3
  SubmitDate: '1998-11-25'
  LastModified: '1999-10-21'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-10-21'
  FixedInVersion: 8.2


  Date: Sun, 18 Oct 1998 20:46:32 -0700 (PDT)
  To: tclsupport@scriptics.com
  Subject: Problems using exec with the Tk Console
  From: dr@cs.cmu.edu
  Status: O

  Support From Submission filled out by:  dr@cs.cmu.edu

  BugOrRFE:  Bug
  Product:  Tcl
  Version:  8.0.3
  Severity:  2
  Support:  None
  OperatingSystem:  Linux
  OperatingSystemVersion:  also using NT
  Extensions:  no extensions
  CustomShell:  I have done some small modifications to tkConsole.c, but they don't affect this.
  Synopsis:  Problems using exec with the Tk Console

  ReproducibleScript:
  I have been developing a neural network system that uses Tcl for its scripting language.  Originally I had been using a standard Tcl shell for the non-graphical user interaction.  This was fine in unix.  However, it appears that when I port it to NT I will need to use a Tk Console to serve as the shell.  So I have been trying to get the console working right.

  The problem is with exec'ing commands.  Ordinarily, when an interactive command is exec'ed, I would do something like the following:
  exec >&@stdout <@stdin $cmd $args

  However, when using the console, stdout and stdin have been replaced by console1 and console0.  These do not have true file handlers associated with them so that can't be used by exec.

  DesiredBehavior:
  What I would like to be able to do is to exec an interactive command that will receive its stdin from whatever is typed in the console and print its stdout to the console.  Is there a way to do this?  What is the intended behavior of exec in a console?



  tclsh on NT can handle this, as of sometime before 8.2.
  wish still uses special console handling, but not tclsh. 
  -- 10/21/1999 hobbs


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


  From: Jeff David <jldavid@enteract.com>

  Try this simple chunk of code in 8.0.3:

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

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

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

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

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

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

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


tkt_uuid: 220402ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: send crashes and dde probs under Win98
comment:
  OriginalBugID: 891 Bug
  Version: 8.1a2
  SubmitDate: '1998-12-03'
  LastModified: '1999-03-31'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: redman
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-03-31'
  FixedInVersion: NA


  Name:  Roland De Bie
  email:  rol@myself.com
  Support:  None
  Severity:  1
  OperatingSystem:  Windows 98
  OperatingSystemVersion:  4.10.1998
  CustomShell:  None!

  I use two running Wish81 and try to communicate with each other, using only command lines in the console.

  Synopsis:  send crashes and dde probs under Win98

  ObservedBehavior:
  send, whatever are the arguments, always crash the master TclTk program

  dde execute send the command string but append garbage (missing 0 byte at the end of string?)

  dde request correctly gets the variable from the host, but again the variable's content is trashed.

  DesiredBehavior:
  No more garbage characters, no more crashes!



  03/31/1999 15:47 - redman - Fixed, DDE doesn't give the correct data length on Win95/98.


tkt_uuid: 220403ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Man page for tk_messageBox uses deprecated 'case' command
comment:
  OriginalBugID: 901 Bug
  Version: 8.0.4
  SubmitDate: '1998-12-04'
  LastModified: '1999-04-09'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: surles
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-04-09'
  FixedInVersion: 8.1b3


  Name:
  Don Porter

  Comments:
  [auto_execok] hasn't returned 0 or 1 since Tcl 7.5, but the
      documentation
      has never caught up.
      
      Going back to Tcl 7.4, I can't find any evidence that [unknown] used the
      global variable 'unknown_active'.  That must be lost in the mists of
      history.  [unknown] uses the global variable 'unknown_pending'.
      
      This patch should be applied to the 8.0.x branch as well.

  Patch:
  Index: library.n
  ===================================================================
  RCS file: /cvsroot/tcl/doc/library.n,v
  retrieving revision 1.1.2.2
  diff -c -r1.1.2.2 library.n
  *** library.n   1998/11/11 04:08:14     1.1.2.2
  --- library.n   1999/04/06 22:47:33
  ***************
  *** 60,70 ****
    The following procedures are provided in the Tcl library:
    .TP
    \fBauto_execok \fIcmd\fR
  ! Determines whether there is an executable file by the name \fIcmd\fR.
    This command examines the directories in the current search path
  ! (given by the PATH environment variable) to see if there is an
  ! executable file named \fIcmd\fR in any of those directories.
  ! If so, it returns 1;  if not it returns 0.  \fBAuto_exec\fR
    remembers information about previous searches in an array
    named \fBauto_execs\fR;  this avoids the path search in
    future calls for the same \fIcmd\fR.  The command \fBauto_reset\fR
  --- 60,76 ----
    The following procedures are provided in the Tcl library:
    .TP
    \fBauto_execok \fIcmd\fR
  ! Determines whether there is an executable file or shell builtin
  ! by the name \fIcmd\fR.
  ! If so, it returns a list of arguments to be passed to \fBexec\fR 
  ! to execute the executable file or shell builtin named by \fIcmd\fR.
  ! If not, it returns an empty string.  
    This command examines the directories in the current search path
  ! (given by the PATH environment variable) in its search for an
  ! executable file named \fIcmd\fR.  On Windows platforms, the search
  ! is expanded with the same directories and file extensions as used
  ! by \fBexec\fR.
  ! \fBAuto_exec\fR
    remembers information about previous searches in an array
    named \fBauto_execs\fR;  this avoids the path search in
    future calls for the same \fIcmd\fR.  The command \fBauto_reset\fR
  ***************
  *** 276,283 ****
    Unix, words are comprised of numbers, letters or underscores.
    .VE
    .TP
  ! \fBunknown_active\fR
  ! This variable is set by \fBunknown\fR to indicate that it is active.
    It is used to detect errors where \fBunknown\fR recurses on itself
    infinitely.
    The variable is unset before \fBunknown\fR returns.
  --- 282,290 ----
    Unix, words are comprised of numbers, letters or underscores.
    .VE
    .TP
  ! \fBunknown_pending\fR
  ! Used by \fBunknown\fR to record the command(s) for which it is
  ! searching.
    It is used to detect errors where \fBunknown\fR recurses on itself
    infinitely.
    The variable is unset before \fBunknown\fR returns.

  PatchFiles:
  library.n



  04/09/1999 14:03 - surles - Updated to use switch.


tkt_uuid: 220404ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: 3 small bug fixes (Tk8.0.3, UNIX)
comment:
  OriginalBugID: 908 Bug
  Version: 8.0.3
  SubmitDate: '1998-12-04'
  LastModified: '1999-02-03'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Other
  OSVersion: Linux Redhat 4.2 (Intel)
  Machine: NA
  FixedDate: '1999-02-03'
  FixedInVersion: 8.0.5


  Name:
  Jan Nijtmans

  ObservedBehavior:
  1) typo on line 25: "tkl_ok" should be "tk_ok". Because this is the first
  time the "tk_ok" variable is used it doesn't have any adverse affect.
  But that doesn't change the fact that it clearly is a typo.

  2)  LIB_RUNTIME_DIR is set incorrectly for Tk if Tcl and Tk are installed
       in different directories. The "/lib" part is missing.

  3) long-standing bug: TK_LD_SEARCH_FLAGS is set incorrectly if  SHLIB_LD_LIBS='${LIBS}', and shared linking is performed through
  the C compiler. Systems affected are Linux, MP-RAS and NEXTSTEP,
  but also with gcc on many more systems. Currently SHLIB_LD_LIBS
  is empty for most sytem, but this is the real reason why shared linking
  fails  when SHLIB_LD_LIBS is set to '${LIBS}' (as it should be).

  Patch:
  *** unix/configure.in.origThu Nov 12 08:49:14 1998
  --- unix/configure.inThu Nov 12 08:51:30 1998
  ***************
  *** 21,27 ****

    AC_PROG_RANLIB
    AC_ARG_ENABLE(gcc, [  --enable-gcc            allow use of gcc if available],
  !     [tk_ok=$enableval], [tkl_ok=no])
    if test "$tk_ok" = "yes"; then
        AC_PROG_CC
    else
  --- 21,27 ----

    AC_PROG_RANLIB
    AC_ARG_ENABLE(gcc, [  --enable-gcc            allow use of gcc if available],
  !     [tk_ok=$enableval], [tk_ok=no])
    if test "$tk_ok" = "yes"; then
        AC_PROG_CC
    else
  ***************
  *** 92,98 ****
    # search path to reflect this.

    if test "$TCL_EXEC_PREFIX" != "$exec_prefix"; then
  !     LIB_RUNTIME_DIR="${LIB_RUNTIME_DIR}:${TCL_EXEC_PREFIX}"
    fi

    #--------------------------------------------------------------------
  --- 92,98 ----
    # search path to reflect this.

    if test "$TCL_EXEC_PREFIX" != "$exec_prefix"; then
  !     LIB_RUNTIME_DIR="${LIB_RUNTIME_DIR}:${TCL_EXEC_PREFIX}/lib"
    fi

    #--------------------------------------------------------------------
  ***************
  *** 249,255 ****
    # variable LIB_RUNTIME_DIR.

    eval "TK_CC_SEARCH_FLAGS=\"$TCL_LD_SEARCH_FLAGS\""
  ! TK_LD_SEARCH_FLAGS=`echo ${TK_CC_SEARCH_FLAGS} |sed -e "s|-Wl,||g" -e "s|,| |g"`

    #--------------------------------------------------------------------
    #Check for the existence of various libraries.  The order here
  --- 249,262 ----
    # variable LIB_RUNTIME_DIR.

    eval "TK_CC_SEARCH_FLAGS=\"$TCL_LD_SEARCH_FLAGS\""
  ! case $SHLIB_LD in
  !     *ld*)
  ! TK_LD_SEARCH_FLAGS=`echo ${TK_CC_SEARCH_FLAGS} |sed -e "s|-Wl,||g" -e "s|,| |g"`
  ! ;;
  !     *)
  ! TK_LD_SEARCH_FLAGS="${TK_CC_SEARCH_FLAGS}"
  ! ;;
  ! esac

    #--------------------------------------------------------------------
    #Check for the existence of various libraries.  The order here

  PatchFiles:
  configure.in



  2) and 3) are already solved in the plus-patches for a long time. These
  fixes are required to turn Tk into a dynamical loadable package tclsh.
  Because 8.0.4 is especially aimed at bug solving, it would be
  valuable to fix at least these 3 small bugs in the core now.


tkt_uuid: 220405ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: tk_dialog's font is hardcoded to a non-system-default one (Times 18) on Unix and Windows
comment:
  OriginalBugID: 911 RFE
  Version: 8.0.3
  SubmitDate: '1998-12-04'
  LastModified: '1999-08-15'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  FixedDate: '1999-08-15'
  FixedInVersion: 8.2


  Name:

  Akos Polster


  Extensions:

  [incr Tcl], TclX


  CustomShell:

  No


  DesiredBehavior:

  Do not explicitly set the dialog's 

  font if not running on Macintosh.


  Patch:

  *** dialog.tcl.old      Tue Nov 17 12:28:51 1998

  --- dialog.tcl.new      Tue Nov 17 12:29:14 1998

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

  *** 68,75 ****

        label $w.msg -justify left -text $text

        if {$tcl_platform(platform) == "macintosh"} {

          $w.msg configure -font system

  -     } else {

  -       $w.msg configure -font {Times 18}

        }

        pack $w.msg -in $w.top -side right -expand 1 -fill both -padx 3m -pady 3m

        if {$bitmap != ""} {

  --- 68,73 ----


  PatchFiles:

  library/dialog.tcl




  This was changed to use the option mechanism so the font can be
  overridden by the programmer.  The class value is *Dialog.msg.font. 
  -- 08/15/1999 hobbs


tkt_uuid: 220406ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Hardcoded non-system-default font in msgbox.tcl
comment:
  OriginalBugID: 912 RFE
  Version: 8.0.3
  SubmitDate: '1998-12-04'
  LastModified: '1999-08-15'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  FixedDate: '1999-08-15'
  FixedInVersion: 8.2


  Name:

  Akos Polster


  Extensions:

  [incr Tcl], TclX


  CustomShell:

  No.


  DesiredBehavior:

  Remove the explicit font specification

  from msgbox.tcl


  Patch:

  *** msgbox.tcl.old      Tue Nov 17 12:52:07 1998

  --- msgbox.tcl.new      Tue Nov 17 12:52:52 1998

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

  *** 161,169 ****


        option add *Dialog.msg.wrapLength 3i widgetDefault

        label $w.msg -justify left -text $data(-message)

  -     catch {$w.msg configure -font \

  -               -Adobe-Times-Medium-R-Normal--*-180-*-*-*-*-*-*

  -     }

        pack $w.msg -in $w.top -side right -expand 1 -fill both -padx 3m -pady 3m

        if {$data(-icon) != ""} {

          label $w.bitmap -bitmap $data(-icon)

  --- 161,166 ----


  PatchFiles:

  library/msgbox.tcl




  This has been changed to use the option databases *Dialog.msg.font
  value, which is a new Tk8 font style value. 
  -- 08/15/1999 hobbs


tkt_uuid: 220407ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Tk's send code uses an uninitialized field
comment:
  OriginalBugID: 919 Bug
  Version: 8.0.4
  SubmitDate: '1998-12-04'
  LastModified: '1999-02-03'
  Severity: CRIT
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '1999-02-03'
  FixedInVersion: 8.0.5


  Name:
  Larry W. Virden

  Extensions:
  tk

  CustomShell:
  none

  Patch:
  --- tkUnixSend.c-dist   Tue Nov 24 09:34:34 1998
  +++ tkUnixSend.c        Tue Nov 24 09:39:06 1998
  @@ -257,3 +257,3 @@
    *     the registry, so that we can write back the registry if
  - *     neeeded, unlock the server if needed, and free memory.
  + *     needed, unlock the server if needed, and free memory.
    *
  @@ -783,2 +783,3 @@
              riPtr->nextPtr = registry;
  +           riPtr->name = NULL;
              registry = riPtr;
  @@ -797,4 +798,6 @@
   
  -           RegDeleteName(regPtr, riPtr->name);
  -           ckfree(riPtr->name);
  +           if (riPtr->name) {
  +               RegDeleteName(regPtr, riPtr->name);
  +               ckfree(riPtr->name);
  +           }
              break;




  PatchFiles:
  tkUnixSend.c





  riPtr->name is used later but not
  initialized and RegDeleteName was
  being called without ensuring that
  the riPtr->name was non-null.


tkt_uuid: 220408ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: tkMenuFind walks through menus in other toplevels
comment:
  OriginalBugID: 924 Bug
  Version: 8.0.3
  SubmitDate: '1998-12-04'
  LastModified: '1999-02-03'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  FixedDate: '1999-02-03'
  FixedInVersion: 8.0.5


  Name:

  Frank J. Leitner


  ReproducibleScript:

  Create two toplevel widgets, each having a menubar. Hide/iconify one toplevel.

  Trigger the key binding (alt-underline) for the menu in the hidden toplevel.


  #!/usr/local/bin/wish


  toplevel .a

  menu .a.m -tearoff 0

  menu .a.m.a

  .a configure -menu .a.m

  .a.m add cascade -menu .a.m.a -label 1 -underline 0

  .a.m.a add command -label exit -command exit


  menu .m -tearoff 0

  menu .m.a

  . configure -menu .m

  .m add cascade -menu .m.a -label 2 -underline 0

  .m.a add command -label exit -command exit


  ObservedBehavior:

  All menubars are searched for the  keybindings (underline), even if they are in a different toplevel.

  If the toplevel is hidden/iconified the following error is created:


  grab failed: window not viewable

      while executing

  "grab -global $w"

      (procedure "tkTraverseToMenu" line 21)

      invoked from within

  "tkTraverseToMenu . 1"

      (command bound to event)


  DesiredBehavior:

  Only the menubar of the current toplevel (the one having focus) should be able to open menus on key bindings.


  Patch:

  *** menu.tcl.orig       Thu Jul  2 20:03:44 1998

  --- menu.tcl    Thu Dec  3 15:51:23 1998

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

  *** 885,890 ****

  --- 885,891 ----

        set windowlist [winfo child $w]


        foreach child $windowlist {

  +         if {[winfo toplevel [focus]] != [winfo toplevel $child] } continue

          switch [winfo class $child] {

              Menu {

                  if {[$child cget -type] == "menubar"} {

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

  *** 911,916 ****

  --- 912,918 ----

        }


        foreach child $windowlist {

  +         if {[winfo toplevel [focus]] != [winfo toplevel $child] } continue

          switch [winfo class $child] {

              Menubutton {

                  set char2 [string index [$child cget -text] \


  PatchFiles:

  library/menu.tcl


tkt_uuid: 220409ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Can't select fast-drawing (width 0) canvas lines
comment:
  OriginalBugID: 925 Bug
  Version: 8.0.4
  SubmitDate: '1998-12-04'
  LastModified: '1999-02-03'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Other
  Machine: NA
  FixedDate: '1999-02-03'
  FixedInVersion: 8.0.5


  Name:

  Sebastian Wangnick


  ReproducibleScript:

  Try the following wish script:


  canvas .c -closeenough 0; pack .c

  .c create line 30 50 170 50

  .c create line 30 100 170 100 -width 0

  .c bind all <Button-1> {puts Gotcha}


  ObservedBehavior:

  The first and the second line look equal, width 0 indicating fast-drawing mode.


  However, you wont be able to select the second line!


  Patch:

  diff -brc ../tk8.0.4.orig/generic/tkCanvLine.c ./generic/tkCanvLine.c

  *** ../tk8.0.4.orig/generic/tkCanvLine.cMon Sep 14 18:23:05 1998

  --- ./generic/tkCanvLine.cWed Dec  2 07:31:14 1998

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

  *** 814,820 ****

        double *coordPtr, *linePoints;

        double staticSpace[2*MAX_STATIC_POINTS];

        double poly[10];

  !     double bestDist, dist;

        int numPoints, count;

        int changedMiterToBevel;/* Non-zero means that a mitered corner

     * had to be treated as beveled after all

  --- 814,820 ----

        double *coordPtr, *linePoints;

        double staticSpace[2*MAX_STATIC_POINTS];

        double poly[10];

  !     double bestDist, dist, width;

        int numPoints, count;

        int changedMiterToBevel;/* Non-zero means that a mitered corner

     * had to be treated as beveled after all

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

  *** 843,848 ****

  --- 843,853 ----

    linePoints = linePtr->coordPtr;

        }


  +     width = (double) linePtr->width;

  +     if (width < 1.0) {

  + width = 1.0;

  +     }

  + 

        /*

         * The overall idea is to iterate through all of the edges of

         * the line, computing a polygon for each edge and testing the

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

  *** 863,869 ****

    || ((linePtr->joinStyle == JoinRound)

    && (count != numPoints))) {

        dist = hypot(coordPtr[0] - pointPtr[0], coordPtr[1] - pointPtr[1])

  !     - linePtr->width/2.0;

        if (dist <= 0.0) {

    bestDist = 0.0;

    goto done;

  --- 868,874 ----

    || ((linePtr->joinStyle == JoinRound)

    && (count != numPoints))) {

        dist = hypot(coordPtr[0] - pointPtr[0], coordPtr[1] - pointPtr[1])

  !     - width/2.0;

        if (dist <= 0.0) {

    bestDist = 0.0;

    goto done;

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

  *** 879,885 ****

     */


    if (count == numPoints) {

  !     TkGetButtPoints(coordPtr+2, coordPtr, (double) linePtr->width,

        linePtr->capStyle == CapProjecting, poly, poly+2);

    } else if ((linePtr->joinStyle == JoinMiter) && !changedMiterToBevel) {

        poly[0] = poly[6];

  --- 884,890 ----

     */


    if (count == numPoints) {

  !     TkGetButtPoints(coordPtr+2, coordPtr, width,

        linePtr->capStyle == CapProjecting, poly, poly+2);

    } else if ((linePtr->joinStyle == JoinMiter) && !changedMiterToBevel) {

        poly[0] = poly[6];

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

  *** 887,893 ****

        poly[2] = poly[4];

        poly[3] = poly[5];

    } else {

  !     TkGetButtPoints(coordPtr+2, coordPtr, (double) linePtr->width, 0,

        poly, poly+2);


        /*

  --- 892,898 ----

        poly[2] = poly[4];

        poly[3] = poly[5];

    } else {

  !     TkGetButtPoints(coordPtr+2, coordPtr, width, 0,

        poly, poly+2);


        /*

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

  *** 911,927 ****

        }

    }

    if (count == 2) {

  !     TkGetButtPoints(coordPtr, coordPtr+2, (double) linePtr->width,

        linePtr->capStyle == CapProjecting, poly+4, poly+6);

    } else if (linePtr->joinStyle == JoinMiter) {

        if (TkGetMiterPoints(coordPtr, coordPtr+2, coordPtr+4,

  !     (double) linePtr->width, poly+4, poly+6) == 0) {

    changedMiterToBevel = 1;

  ! TkGetButtPoints(coordPtr, coordPtr+2, (double) linePtr->width,

    0, poly+4, poly+6);

        }

    } else {

  !     TkGetButtPoints(coordPtr, coordPtr+2, (double) linePtr->width, 0,

        poly+4, poly+6);

    }

    poly[8] = poly[0];

  --- 916,932 ----

        }

    }

    if (count == 2) {

  !     TkGetButtPoints(coordPtr, coordPtr+2, width,

        linePtr->capStyle == CapProjecting, poly+4, poly+6);

    } else if (linePtr->joinStyle == JoinMiter) {

        if (TkGetMiterPoints(coordPtr, coordPtr+2, coordPtr+4,

  !     width, poly+4, poly+6) == 0) {

    changedMiterToBevel = 1;

  ! TkGetButtPoints(coordPtr, coordPtr+2, width,

    0, poly+4, poly+6);

        }

    } else {

  !     TkGetButtPoints(coordPtr, coordPtr+2, width, 0,

        poly+4, poly+6);

    }

    poly[8] = poly[0];

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

  *** 942,948 ****


        if (linePtr->capStyle == CapRound) {

    dist = hypot(coordPtr[0] - pointPtr[0], coordPtr[1] - pointPtr[1])

  ! - linePtr->width/2.0;

    if (dist <= 0.0) {

        bestDist = 0.0;

        goto done;

  --- 947,953 ----


        if (linePtr->capStyle == CapRound) {

    dist = hypot(coordPtr[0] - pointPtr[0], coordPtr[1] - pointPtr[1])

  ! - width/2.0;

    if (dist <= 0.0) {

        bestDist = 0.0;

        goto done;

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

  *** 1015,1020 ****

  --- 1020,1026 ----

        LineItem *linePtr = (LineItem *) itemPtr;

        double staticSpace[2*MAX_STATIC_POINTS];

        double *linePoints;

  +     double width;

        int numPoints, result;


        /*

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

  *** 1042,1049 ****

         * Check the segments of the line.

         */


        result = TkThickPolyLineToArea(linePoints, numPoints, 

  !     (double) linePtr->width, linePtr->capStyle, linePtr->joinStyle,

        rectPtr);

        if (result == 0) {

    goto done;

  --- 1048,1060 ----

         * Check the segments of the line.

         */


  +     width = (double) linePtr->width;

  +     if (width < 1.0) {

  + width = 1.0;

  +     }

  + 

        result = TkThickPolyLineToArea(linePoints, numPoints, 

  !     width, linePtr->capStyle, linePtr->joinStyle,

        rectPtr);

        if (result == 0) {

    goto done;


  PatchFiles:

  tkCanvLine.c




  Note that this patch is also available for Tk8.0p2 at http://www.scriptics.com/resource/software/patches/tk80p2.


tkt_uuid: 220410ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: Copying and pasting from Tk Windows to other applications mangles double-byte text
comment:
  OriginalBugID: 935 Bug
  Version: 8.1a2
  SubmitDate: '1998-12-04'
  LastModified: '1998-12-08'
  Severity: SER
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Windows NT
  OSVersion: 4.0 Japanese
  Machine: X86
  FixedDate: '1998-12-08'
  FixedInVersion: 8.1b1


  Name:

  Syd Polk


  CVS:

  win/tkWinClipboard.c 1.1.4.2


  ReproducibleScript:

  On Windows NT4.0J, copy some text with Japanese in it from Notepad and paste it into a text widget.


  ObservedBehavior:

  The characters are mangled. Same thing the other direction.


  DesiredBehavior:

  The same text in both Notepad and the text widget.


  Patch:

  *** tkWinClipboard.cFri Dec  4 16:06:36 1998

  --- tkWinClipboard.c.newFri Dec  4 16:06:15 1998

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

  *** 50,55 ****

  --- 50,56 ----

        ClientData clientData;/* Arbitrary value to pass to proc. */

    {

        char *data, *buffer, *destPtr;

  +     Tcl_DString selDString;

        HGLOBAL handle;

        int result, length;


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

  *** 72,79 ****

    *destPtr = '\0';

    GlobalUnlock(handle);

    CloseClipboard();

  ! result = (*proc)(clientData, interp, buffer);

    ckfree(buffer);

    return result;

        }

        CloseClipboard();

  --- 73,83 ----

    *destPtr = '\0';

    GlobalUnlock(handle);

    CloseClipboard();

  ! Tcl_ExternalToUtfDString(NULL, buffer, -1, &selDString);

    ckfree(buffer);

  + result = (*proc)(clientData, interp, 

  + Tcl_DStringValue(&selDString));

  + Tcl_DStringFree(&selDString);

    return result;

        }

        CloseClipboard();

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

  *** 162,169 ****

        TkClipboardTarget *targetPtr;

        TkClipboardBuffer *cbPtr;

        HGLOBAL handle;

  !     char *buffer, *p, *endPtr;

        int length;


        for (targetPtr = dispPtr->clipTargetPtr; targetPtr != NULL;

        targetPtr = targetPtr->nextPtr) {

  --- 166,174 ----

        TkClipboardTarget *targetPtr;

        TkClipboardBuffer *cbPtr;

        HGLOBAL handle;

  !     char *buffer, *p, *rawText, *endPtr;

        int length;

  +     Tcl_DString selDString;


        for (targetPtr = dispPtr->clipTargetPtr; targetPtr != NULL;

        targetPtr = targetPtr->nextPtr) {

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

  *** 183,193 ****

        }

    }

        }

  !     handle = GlobalAlloc(GMEM_MOVEABLE|GMEM_DDESHARE, length+1);

  !     if (!handle) {

  ! return;

  !     }

  !     buffer = GlobalLock(handle);

        if (targetPtr != NULL) {

    for (cbPtr = targetPtr->firstBufferPtr; cbPtr != NULL;

    cbPtr = cbPtr->nextPtr) {

  --- 188,194 ----

        }

    }

        }

  !     buffer = rawText = ckalloc(length + 1);

        if (targetPtr != NULL) {

    for (cbPtr = targetPtr->firstBufferPtr; cbPtr != NULL;

    cbPtr = cbPtr->nextPtr) {

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

  *** 201,207 ****

  --- 202,219 ----

    }

        }

        *buffer = '\0';

  +     Tcl_UtfToExternalDString(NULL, rawText, -1, &selDString);

  +     ckfree(rawText);

  +     handle = GlobalAlloc(GMEM_MOVEABLE|GMEM_DDESHARE, 

  +     Tcl_DStringLength(&selDString)+1);

  +     if (!handle) {

  + return;

  +     }

  +     buffer = GlobalLock(handle);

  +     memcpy(buffer, Tcl_DStringValue(&selDString), 

  +     Tcl_DStringLength(&selDString) + 1);

        GlobalUnlock(handle);

  +     Tcl_DStringFree(&selDString);

        SetClipboardData(CF_TEXT, handle);

        return;

    }


  PatchFiles:

  win/tkWinClipboard.c


tkt_uuid: 220411ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: add the itemconfigure command to listboxes
comment:
  OriginalBugID: 936 RFE
  Version: 8.1a2
  SubmitDate: '1998-12-04'
  LastModified: '1999-11-19'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: ericm
  OS: All
  Machine: Other
  FixedDate: '1999-11-19'
  FixedInVersion: 8.3b1


  Name:

  Wayne Christopher


  CVS:

  1.1.4.2 /cvsroot/tk/generic/tkListbox.c,v


  DesiredBehavior:

  I added a itemconfigure command that allows individual entries of listboxes to

  have their own foreground and background colors.


  Patch:

  *** tkListbox.c.orig    Fri Dec  4 18:07:33 1998

  --- tkListbox.c Fri Dec  4 18:18:40 1998

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

  *** 18,23 ****

  --- 18,25 ----

    #include "default.h"

    #include "tkInt.h"


  + #define ITEMCONFIGURE

  + 

    /*

     * One record of the following type is kept for each element

     * associated with a listbox widget:

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

  *** 33,38 ****

  --- 35,44 ----

                                   * it isn't. */

        struct Element *nextPtr;  /* Next in list of all elements of this

                                   * listbox, or NULL for last element. */

  + #ifdef ITEMCONFIGURE

  +     Tk_3DBorder selBorder;    /* Background color for selected element. */

  +     Tk_3DBorder normalBorder; /* Background color for normal element. */

  + #endif

        char text[4];             /* Characters of this element, NULL-

                                   * terminated.  The actual space allocated

                                   * here will be as large as needed (> 4,

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

  *** 263,268 ****

  --- 269,285 ----

          (char *) NULL, 0, 0}

    };


  + #ifdef ITEMCONFIGURE

  + static Tk_ConfigSpec itemConfigSpecs[] = {

  +     {TK_CONFIG_BORDER, "-background", "background", "Background",

  +       NULL, Tk_Offset(Element, normalBorder), TK_CONFIG_COLOR_ONLY},

  +     {TK_CONFIG_BORDER, "-selectbackground", "selectBackground", "Foreground",

  +       NULL, Tk_Offset(Element, selBorder), TK_CONFIG_COLOR_ONLY},

  +     {TK_CONFIG_END, (char *) NULL, (char *) NULL, (char *) NULL,

  +       (char *) NULL, 0, 0}

  + };

  + #endif

  + 

    /*

     * Forward declarations for procedures defined later in this file:

     */

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

  *** 274,279 ****

  --- 291,301 ----

    static int            ConfigureListbox _ANSI_ARGS_((Tcl_Interp *interp,

                              Listbox *listPtr, int argc, char **argv,

                              int flags));

  + #ifdef ITEMCONFIGURE

  + static int            ConfigureListboxItem _ANSI_ARGS_((Tcl_Interp *interp,

  +                           Listbox *listPtr, Element *elPtr, int argc,

  +                           char **argv, int flags));

  + #endif

    static void           DeleteEls _ANSI_ARGS_((Listbox *listPtr, int first,

                              int last));

    static void           DestroyListbox _ANSI_ARGS_((char *memPtr));

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

  *** 281,288 ****

  --- 303,316 ----

    static int            GetListboxIndex _ANSI_ARGS_((Tcl_Interp *interp,

                              Listbox *listPtr, char *string, int endIsSize,

                              int *indexPtr));

  + #ifdef ITEMCONFIGURE

  + static void           InsertEls _ANSI_ARGS_((Tcl_Interp *interp,

  +                           Listbox *listPtr, int index,

  +                           int argc, char **argv));

  + #else

    static void           InsertEls _ANSI_ARGS_((Listbox *listPtr, int index,

                              int argc, char **argv));

  + #endif

    static void           ListboxCmdDeletedProc _ANSI_ARGS_((

                              ClientData clientData));

    static void           ListboxComputeGeometry _ANSI_ARGS_((Listbox *listPtr,

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

  *** 671,677 ****

  --- 699,744 ----

                  != TCL_OK) {

              goto error;

          }

  + #ifdef ITEMCONFIGURE

  +       InsertEls(interp, listPtr, index, argc-3, argv+3);

  + #else

          InsertEls(listPtr, index, argc-3, argv+3);

  + #endif

  + #ifdef ITEMCONFIGURE

  +     } else if ((c == 'i') && (strncmp(argv[1], "itemconfigure", length) == 0)

  +           && (length >= 2)) {

  +         int itemnum, i;

  +       Element *elPtr;

  +         if (argc < 3) {

  +           Tcl_AppendResult(interp, "wrong # args: should be \"",

  +                   argv[0], " itemconfigure item [ name value ... ]\"",

  +                   (char *) NULL);

  +           goto error;

  +       }

  +       if (Tcl_GetInt(interp, argv[2], &itemnum) != TCL_OK) {

  +           goto error;

  +       }

  +       for (elPtr = listPtr->firstPtr, i = 0; i < itemnum;

  +               i++, elPtr = elPtr->nextPtr) {

  +           /* Empty loop body. */

  +       }

  +       if (!elPtr) {

  +           Tcl_AppendResult(interp, "item number \"",

  +                   argv[1], " out of range",

  +                   (char *) NULL);

  +           goto error;

  +       }

  +       if (argc == 3) {

  +           result = Tk_ConfigureInfo(interp, listPtr->tkwin, itemConfigSpecs,

  +                   (char *) elPtr, (char *) NULL, 0);

  +       } else if (argc == 4) {

  +           result = Tk_ConfigureInfo(interp, listPtr->tkwin, itemConfigSpecs,

  +                   (char *) elPtr, argv[3], 0);

  +       } else {

  +           result = ConfigureListboxItem(interp, listPtr, elPtr,

  +                                         argc-3, argv+3, TK_CONFIG_ARGV_ONLY);

  +       }

  + #endif

        } else if ((c == 'n') && (strncmp(argv[1], "nearest", length) == 0)) {

          int index, y;

          char buf[TCL_INTEGER_SPACE];

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

  *** 930,935 ****

  --- 997,1005 ----

                  "\": must be activate, bbox, cget, configure, ",

                  "curselection, delete, get, index, insert, nearest, ",

                  "scan, see, selection, size, ",

  + #ifdef ITEMCONFIGURE

  +               "itemconfigure, ",

  + #endif

                  "xview, or yview", (char *) NULL);

          goto error;

        }

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

  *** 1058,1063 ****

  --- 1128,1176 ----

        return TCL_OK;

    }


  + #ifdef ITEMCONFIGURE

  + /*

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

  +  *

  +  * ConfigureListboxItem --

  +  *

  +  *    This procedure is called to process an argv/argc list, plus

  +  *    the Tk option database, in order to configure (or reconfigure)

  +  *    a listbox item.

  +  *

  +  * Results:

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

  +  *    returned, then interp->result contains an error message.

  +  *

  +  * Side effects:

  +  *    Configuration information, such as colors, border width,

  +  *    etc. get set for elPtr;  old resources get freed,

  +  *    if there were any.

  +  *

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

  +  */

  + 

  + static int

  + ConfigureListboxItem(interp, listPtr, elPtr, argc, argv, flags)

  +     Tcl_Interp *interp;               /* Used for error reporting. */

  +     Listbox *listPtr;         /* Information about widget;  may or may

  +                                * not already have values for some fields. */

  +     Element *elPtr;           /* Information about item;  may or may

  +                                * not already have values for some fields. */

  +     int argc;                 /* Number of valid entries in argv. */

  +     char **argv;              /* Arguments. */

  +     int flags;                        /* Flags to pass to Tk_ConfigureWidget. */

  + {

  +     if (Tk_ConfigureWidget(interp, listPtr->tkwin, itemConfigSpecs,

  +           argc, argv, (char *) elPtr, flags) != TCL_OK) {

  +       return TCL_ERROR;

  +     }

  + 

  +     ListboxWorldChanged((ClientData) listPtr);

  +     return TCL_OK;

  + }

  + #endif

  + 


    /*

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

     *

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

  *** 1201,1211 ****

                  + listPtr->inset;

          gc = listPtr->textGC;

          if (elPtr->selected) {

              gc = listPtr->selTextGC;

              width = Tk_Width(tkwin) - 2*listPtr->inset;

              Tk_Fill3DRectangle(tkwin, pixmap, listPtr->selBorder, x, y,

                      width, listPtr->lineHeight, 0, TK_RELIEF_FLAT);

  ! 

              /*

               * Draw beveled edges around the selection, if there are visible

               * edges next to this element.  Special considerations:

  --- 1314,1332 ----

                  + listPtr->inset;

          gc = listPtr->textGC;

          if (elPtr->selected) {

  + #ifdef ITEMCONFIGURE

  +           Tk_3DBorder col = listPtr->selBorder;

  +           if (elPtr->selBorder) col = elPtr->selBorder;

  + #endif

              gc = listPtr->selTextGC;

              width = Tk_Width(tkwin) - 2*listPtr->inset;

  + #ifdef ITEMCONFIGURE

  +           Tk_Fill3DRectangle(tkwin, pixmap, col, x, y,

  +                   width, listPtr->lineHeight, 0, TK_RELIEF_FLAT);

  + #else

              Tk_Fill3DRectangle(tkwin, pixmap, listPtr->selBorder, x, y,

                      width, listPtr->lineHeight, 0, TK_RELIEF_FLAT);

  ! #endif

              /*

               * Draw beveled edges around the selection, if there are visible

               * edges next to this element.  Special considerations:

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

  *** 1244,1249 ****

  --- 1365,1382 ----

                          TK_RELIEF_RAISED);

              }

          }

  + #ifdef ITEMCONFIGURE

  +       else {

  +           if (elPtr->normalBorder) {

  +               gc = listPtr->selTextGC;

  +               width = Tk_Width(tkwin) - 2*listPtr->inset;

  +               Tk_Fill3DRectangle(tkwin, pixmap, elPtr->normalBorder, x, y,

  +                                  width, listPtr->lineHeight, 0,

  +                                  TK_RELIEF_FLAT);

  +           }

  +       }

  +       gc = listPtr->textGC;

  + #endif

          Tk_GetFontMetrics(listPtr->tkfont, &fm);

          y += fm.ascent + listPtr->selBorderWidth;

          x = listPtr->inset + listPtr->selBorderWidth - elPtr->lBearing

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

  *** 1394,1400 ****

  --- 1527,1538 ----

     */


    static void

  + #ifdef ITEMCONFIGURE

  + InsertEls(interp, listPtr, index, argc, argv)

  +     Tcl_Interp *interp;               /* Used for error reporting. */  

  + #else

    InsertEls(listPtr, index, argc, argv)

  + #endif

        register Listbox *listPtr;        /* Listbox that is to get the new

                                   * elements. */

        int index;                        /* Add the new elements before this


  PatchFiles:

  tkListbox.c




  I added itemconfigure and itemcget commands to the listbox.  These allow you to change, for each item in the listbox, the foreground, background, selectforeground and selectbackground.

  - eric

  -- 11/19/1999 ericm


tkt_uuid: 220412ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: tkconsole fails to return result from ConsoleCmd
comment:
  OriginalBugID: 973 Bug
  Version: 8.0p2
  SubmitDate: '1998-12-15'
  LastModified: '1999-02-04'
  Severity: LOW
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Windows 95
  OSVersion: 4.0 sr4
  Machine: X86
  FixedDate: '1999-02-04'
  FixedInVersion: 8.0.5


  Name:

  tom wilkason


  CustomShell:

  None


  ReproducibleScript:

  Run the script from the tk console window


  proc {CheckConsole} {} {

     global  tcl_platform

     if {$tcl_platform(platform) == "windows" } {

        set ConsoleState [console eval {wm state .}]    ;# need updated tkconsole.c

        set Children [winfo children .]   ;# Null for none

        set TopState [wm state .]         ;# withdrawn for hidden

        if {$Children =="" && $TopState=="withdrawn" && $ConsoleState=="withdrawn"} {


           exit

        }

        after 1000 CheckConsole

     }

  }

  wm withdraw .

  CheckConsole

  console hide


  ObservedBehavior:

  You would expect the wish application to terminate because all the windows are withdrawn. (look in the task manager and wish80.exe is still there). However it doesn't terminate because the console eval {wm state .} command is not returning withdrawn. With the patch below applied, the console eval command returns the result of the command passed to it (not just this example).


  DesiredBehavior:

  When the console window is truly withdrawn the console eval {wm state .} command should return withdrawn and the script above will terminate wish80.exe.


  Patch:

  ********

    Tcl_Eval(info->consoleInterp, "wm deiconify .");

        } else if ((c == 'e') && (strncmp(argv[1], "eval", length)) == 0) {

    if (argc == 3) {

  407c407,412

  <     Tcl_Eval(info->consoleInterp, argv[2]);

  ---

  >          if (Tcl_Eval(info->consoleInterp, argv[2]) == TCL_ERROR) {

  >             Tcl_AppendResult(interp,"Eval error: ",consoleInterp->result, (c

  >             return TCL_ERROR;

  >          } else {

  >             Tcl_AppendResult(interp,consoleInterp->result, (char *) NULL);

  >          }

    } else {

        Tcl_AppendResult(interp, "wrong # args: should be \"", argv[0],

        " eval command\"", (char *) NULL);


  PatchFiles:

  TkConsole.c


tkt_uuid: 220413ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Tk 8.0.4 entry widget crashes on NT4.0/J service pack 3 or less
comment:
  OriginalBugID: 1006 Bug
  Version: 8.0.4
  SubmitDate: '1998-12-22'
  LastModified: '1999-02-03'
  Severity: CRIT
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Windows NT
  OSVersion: 4.00.1381 (Japanese)
  Machine: X86
  FixedDate: '1999-02-03'
  FixedInVersion: 8.0.5


  Name:

  Jim Inham


  Extensions:

  Tcl 8.0.4, Tk 8.0.4


  CustomShell:

  This is the plain Scriptics Binary version.


  ReproducibleScript:

  entry .e -font windows-message

  pack .e

  .e insert end "A really long string that will overflow the entry widget"


  ObservedBehavior:

  It crashes with an access violation


  DesiredBehavior:

  The text should be inserted in the widget.  It should not crash.


  Patch:

  *** tkWinFont.c.orig    Thu Dec 17 14:59:50 1998

  --- tkWinFont.c Thu Dec 17 15:10:20 1998

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

  *** 391,404 ****


          if (((flags & TK_PARTIAL_OK) && max < numChars && curX < maxLength)

                  || ((flags & TK_AT_LEAST_ONE) && max == 0 && numChars > 0)) {

              /*

               * We want to include the first character that didn't

               * quite fit.  Call the function again to include the

               * width of the extra character.

                 */


  !           GetTextExtentExPoint(hdc, source, max + 1, 0, NULL, partials,

  !                        &size);

              curX = partials[max];

              ++max;


  --- 391,415 ----


          if (((flags & TK_PARTIAL_OK) && max < numChars && curX < maxLength)

                  || ((flags & TK_AT_LEAST_ONE) && max == 0 && numChars > 0)) {

  + 

  +           /*

  +            * MS BUG ALERT - We have to pass the bogus length, and

  +            * the dummyMax parameter, because without them the call crashes on

  +            * NT/J Service Pack 3 and less.  This is documented in the

  +            * Microsoft Knowledge Base.

  +            */

  +         

  +           int dummyMax;

  +           

              /*

               * We want to include the first character that didn't

               * quite fit.  Call the function again to include the

               * width of the extra character.

                 */


  !           GetTextExtentExPoint(hdc, source, max + 1, INT_MAX, &dummyMax,

  !                   partials, &size);

  ! 

              curX = partials[max];

              ++max;


  PatchFiles:

  tk8.0/win/tkWinFont.c




  According to MS, Service Pack 4 fixes this bug, but I have not tried it.  Many of our customers are not willing to upgrade to Service Pack 4, so the work-around is needed.

  This bug does not affect Tk8.1, because for some other reasons the 8.1 code does not use the GetTextExtentExPoint function in the equivalent place...


tkt_uuid: 220414ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Double Click selection in Text widget does not select the word if text is not english
comment:
  OriginalBugID: 1048 RFE
  Version: 8.1b1
  SubmitDate: '1999-01-15'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  Name:
  Petasis George

  DesiredBehavior:
  When you double click in a text widget, the word under cursor is selected.
  But this works fine only if the text beneath cursor is in english. If the text under the curson is in another language (greek for example) then the whole range of characters is selected, from the previous english character to the next one.
  It would be nice if in other languages, words were selected depending on spaces or other punctual symbols (apostrophes, slashes, etc.)
  Also this request is related with the wordstart and wordend tags of the text document.



  This appears to work in 8.2b2, was probably fixed before 8.1 went
  final.  Required Unicode awareness for the helper procedures.
  This works with German texts. 
  -- 08/06/1999 hobbs


tkt_uuid: 220415ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: TK8.1b1 won't compile using Borland 4.52
comment:
  OriginalBugID: 1052 Bug
  Version: 8.1b1
  SubmitDate: '1999-01-15'
  LastModified: '1999-04-16'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: Windows NT
  OSVersion: NT 4, service pack 3
  Machine: X86
  FixedDate: '1999-04-16'
  FixedInVersion: 8.1


  Name:
  Mark Elfield

  ReproducibleScript:
  Copy makefile.bc to makefile and run Borland 4.52 make.

  ObservedBehavior:
  1.  No zmouse.h (workaround is to create one that defines WM_MOUSEWHEEL)

  2.  After avoiding zmouse.h, the fails with this message:

  MAKE Version 3.7  Copyright (c) 1987, 1994 Borland International
          c:\bc45\bin\brcc32 -ic:\bc45\include;..\generic;..\bitmaps;..\xlib;..\wi
  n;..\..\tcl8.1b1\generic rc\tk.rc
  Borland 32-bit Resource Compiler  Version 4.5
  Copyright (c) 1990, 1994 Borland International.  All rights reserved.

  Error ctype.h 18: #error directive encountered: ERROR: Only Mac or Win32 targets
   supported!

  ** error 18 ** deleting rc\tk.res

  3.  Lots of warnings.

  DesiredBehavior:
  The make should run without errors or warnings.



  Borland is no longer supported.  The makefile should be removed from the distribiution.
  03/26/1999 11:11 - surles -


tkt_uuid: 220416ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: My patch of 12/30 to fix drawing of underlines was bogus.
comment:
  OriginalBugID: 1053 Bug
  Version: 8.1b1
  SubmitDate: '1999-01-15'
  LastModified: '1999-03-29'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: Windows NT
  OSVersion: 4.0J
  Machine: X86
  FixedDate: '1999-03-29'
  FixedInVersion: 8.1b3


  Name:
  Syd Polk

  CVS:
  generic/tkFont.c 1.1.4.5

  ReproducibleScript:
  Tk_UnderlineTextLayout was screwing up with double-byte text. This patch fixes this, as well as the problem with my original patch of underlining the first character even when there was not supposed to be any underlining at all.

  Patch:
  Index: tkFont.c
  ===================================================================
  RCS file: /cvsroot/tk/generic/tkFont.c,v
  retrieving revision 1.1.4.5
  diff -c -r1.1.4.5 tkFont.c
  *** tkFont.c1998/11/25 23:06:421.1.4.5
  --- tkFont.c1999/01/01 00:28:02
  ***************
  *** 2191,2208 ****
        int underline;/* Index of the single character to
     * underline, or -1 for no underline. */
    {
  !     TextLayout *layoutPtr;
        TkFont *fontPtr;
  !     int xx, yy, width, height;

  !     if ((Tk_CharBbox(layout, underline, &xx, &yy, &width, &height) != 0)
  !     && (width != 0)) {
  ! layoutPtr = (TextLayout *) layout;
  ! fontPtr = (TkFont *) layoutPtr->tkfont;

  ! XFillRectangle(display, drawable, gc, x + xx, 
  ! y + yy + fontPtr->fm.ascent + fontPtr->underlinePos,
  ! (unsigned int) width, (unsigned int) fontPtr->underlineHeight);
        }
    }
    
  --- 2191,2211 ----
        int underline;/* Index of the single character to
     * underline, or -1 for no underline. */
    {
  !     TextLayout *layoutPtr = (TextLayout *) layout;
        TkFont *fontPtr;
  !     int xx, yy, width, height, underlineByte;

  !     if (underline > -1) {
  ! underlineByte = Tcl_UtfAtIndex(layoutPtr->string, underline) 
  ! - layoutPtr->string;
  ! if ((Tk_CharBbox(layout, underlineByte, &xx, &yy, &width, &height) != 0)
  ! && (width != 0)) {
  !     fontPtr = (TkFont *) layoutPtr->tkfont;

  !     XFillRectangle(display, drawable, gc, x + xx, 
  !     y + yy + fontPtr->fm.ascent + fontPtr->underlinePos,
  !     (unsigned int) width, (unsigned int) fontPtr->underlineHeight);
  ! }
        }
    }
    

  PatchFiles:
  generic/tkFont.c



  The patch is incorrect, but the problem was present.  The Layout apis are character oriented, but the lower level font apis are byte oriented.  This has been clarified and their usage standardized.
  03/29/1999 20:00 - stanton -


tkt_uuid: 220417ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Cannot configure a font after assigning it to a widget
comment:
  OriginalBugID: 1055 Bug
  Version: 8.1b1
  SubmitDate: '1999-01-15'
  LastModified: '1999-04-19'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: surles
  OS: Solaris
  OSVersion: 5.6
  Machine: Other
  FixedDate: '1999-04-19'
  FixedInVersion: 8.1b3


  Name:
  Petasis George

  ObservedBehavior:
  You create a font with the "font create command"
  You assign this font in a widget (let's say a text widget)
  You configure the font with the "font configure"
  The changes are rejected. The font of the widget does not change, nor does change what you get from "font actual" command. You cannot even change the underline or overstrike option. This happened under Solaris 5.6 with more than
  1000 fonts installed and under windows NT 4.0 SP4.

  DesiredBehavior:
  The command "font configure" to change the properties of a font, previously created with the "font create" command.



  this may be fixed, but should be verified
  04/16/1999 14:54 - stanton -
  ---
  04/19/1999 19:02 - surles - The fix has been verified and works.


tkt_uuid: 220418ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Text widget search problem - CharNu has wrong value if characters are not english
comment:
  OriginalBugID: 1056 Bug
  Version: 8.1b1
  SubmitDate: '1999-01-15'
  LastModified: '1999-04-02'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  RelatedBugIDs: 1148  1666
  OS: Solaris
  OSVersion: 5.6
  Machine: Other
  FixedDate: '1999-04-02'
  FixedInVersion: 8.1b3


  Name:
  Petasis George

  Extensions:
  none

  ReproducibleScript:
  encoding system iso8859-7
  set pattern [${win}.entry get]
  set index [$widget search -forwards -regexp -count CharNu --  $pattern 1.0 end]
  puts $CharNu

  ObservedBehavior:
  if you enter in the entry some greek characters, lets say 3 chars, CharNu has the value of 6. If you type 3 english characters in the entry widget, CharNu has the correct value (3).

  DesiredBehavior:
  CharNu having always value 3, if you type 3 characters, no matter which language you use...



  The text widget was returning byte counts instead of character counts.
  04/02/1999 15:49 - stanton -


tkt_uuid: 220419ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: send and DDE don't work on Windows
comment:
  OriginalBugID: 1058 Bug
  Version: 8.1b1
  SubmitDate: '1999-01-15'
  LastModified: '1999-03-31'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: redman
  OS: Windows 95
  OSVersion: 4.00.950 B
  Machine: X86
  FixedDate: '1999-03-31'


  Name:
  Kevin B. Kenny

  Extensions:
  None relevant

  CustomShell:
  Identical failures on "out-of-the-box"

  ReproducibleScript:
  # This is a dummy test of the 'send' command

  console show
  set d [file dirname [info script]]
  set fn [file join $d script2.tcl]
  set f [open $fn w]
  puts $f {
      console show
      set parent [lindex $argv 0]
      if {[catch {
  send $parent {puts "it worked"}
      } result]} {
  puts "send failed: $result"
      }
  }
  close $f
  exec [info nameof] $fn [tk appname] &




  ObservedBehavior:
  Virtually any use of the 'dde' or 'send' commands under Windows results
  in errors.  When I spoke to Scott Stanton and Syd Polk about this issue
  in September in San Diego, Syd led me to believe that the problem was that
  the internationalization changes cause incorrect string lengths to be
  presented to the DDE calls.  In particular, the script above causes
  the child process to print:

  send failed: invalid data returned from server

  One clue is that the after the script executes, the parent process's
  errorInfo variable contains the string:

  extra characters after close-quote
      while compiling
  "puts "it worked"



  DesiredBehavior:
  I kind of expect 'send' to work...  8-)





  The symptoms differ slightly on Win98 and Win-NT 4.0, but the failure is
  present on those platforms as well.
  03/31/1999 15:53 - redman - Fixed, DDE doesn't give the correct data length.


tkt_uuid: 220420ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Improve support for AIX shared libraries.
comment:
  OriginalBugID: 1111 Bug
  Version: 8.0.4
  SubmitDate: '1999-01-26'
  LastModified: '1999-03-05'
  Severity: SER
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Other
  Machine: NA
  FixedDate: '1999-03-05'
  FixedInVersion: 8.0.6


  Name:
  Paul Duffin

  ReproducibleScript:
  The problem is that at the moment Tcl and Tk are built as archives containing
  a shared object which means that Tk in particular is not dynamically loadable
  and neither is any other extension which is also a library. The solution is to
  build shared libraries on AIX as shared objects and to use an export / import
  file to manage the linking.

  The patch can be applied directly to Tk8.1b1 although the configure file will
  need regenerating.

  This patch does require the related patch for Tcl to have also been applied.

  Patch:
  *** tk8.0/unix/.configureThu Jan 14 11:14:34 1999
  --- tk8.0/unix/configureThu Jan 14 11:14:35 1999
  ***************
  *** 2362,2374 ****
    # AIX remembers this path and will attempt to use it at run-time to look
    # up the Tcl library.

  ! if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
  !     TK_LIB_FLAG="-ltk${VERSION}\${TK_DBGX}"
    else
  !     TK_LIB_FLAG="-ltk`echo ${VERSION} | tr -d .`\${TK_DBGX}"
    fi
  - TK_BUILD_LIB_SPEC="-L`pwd` ${TK_LIB_FLAG}"
  - TK_LIB_SPEC="-L${exec_prefix}/lib ${TK_LIB_FLAG}"

  --- 2362,2382 ----
    # AIX remembers this path and will attempt to use it at run-time to look
    # up the Tcl library.

  ! if test $TK_SHARED_BUILD = 0 -o $TCL_NEEDS_EXP_FILE = 0; then
  !     if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
  ! TK_LIB_FLAG="-ltk${VERSION}\${TK_DBGX}"
  !     else
  ! TK_LIB_FLAG="-ltk`echo ${VERSION} | tr -d .`\${TK_DBGX}"
  !     fi
  !     TK_BUILD_LIB_SPEC="-L`pwd` ${TK_LIB_FLAG}"
  !     TK_LIB_SPEC="-L${exec_prefix}/lib/tk${VERSION} ${TK_LIB_FLAG}"
    else
  !     TK_BUILD_EXP_FILE="lib.exp"
  !     eval "TK_EXP_FILE=libtk${TCL_EXPORT_FILE_SUFFIX}"
  !     
  !     TK_BUILD_LIB_SPEC="-bI:`pwd`/${TK_BUILD_EXP_FILE}"
  !     TK_LIB_SPEC="-bI:${exec_prefix}/lib/tk${VERSION}/${TK_EXP_FILE}"
    fi

  ***************
  *** 2407,2412 ****
  --- 2415,2422 ----

  + 
  + 
    trap '' 1 2 15
    cat > confcache <<\EOF
    # This file is a shell script that caches the results of configure
  ***************
  *** 2564,2569 ****
  --- 2574,2581 ----
    s%@TK_LD_SEARCH_FLAGS@%$TK_LD_SEARCH_FLAGS%g
    s%@TK_LIB_FILE@%$TK_LIB_FILE%g
    s%@TK_LIB_FLAG@%$TK_LIB_FLAG%g
  + s%@TK_BUILD_EXP_FILE@%$TK_BUILD_EXP_FILE%g
  + s%@TK_EXP_FILE@%$TK_EXP_FILE%g
    s%@TK_LIB_SPEC@%$TK_LIB_SPEC%g
    s%@TK_MAJOR_VERSION@%$TK_MAJOR_VERSION%g
    s%@TK_MINOR_VERSION@%$TK_MINOR_VERSION%g
  *** tk8.0/unix/.configure.inThu Jan 14 11:14:36 1999
  --- tk8.0/unix/configure.inThu Jan 14 11:14:36 1999
  ***************
  *** 398,410 ****
    # AIX remembers this path and will attempt to use it at run-time to look
    # up the Tcl library.

  ! if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
  !     TK_LIB_FLAG="-ltk${VERSION}\${TK_DBGX}"
    else
  !     TK_LIB_FLAG="-ltk`echo ${VERSION} | tr -d .`\${TK_DBGX}"
    fi
  - TK_BUILD_LIB_SPEC="-L`pwd` ${TK_LIB_FLAG}"
  - TK_LIB_SPEC="-L${exec_prefix}/lib ${TK_LIB_FLAG}"

    AC_SUBST(CFLAGS_DEBUG)
    AC_SUBST(CFLAGS_DEFAULT)
  --- 398,418 ----
    # AIX remembers this path and will attempt to use it at run-time to look
    # up the Tcl library.

  ! if test $TK_SHARED_BUILD = 0 -o $TCL_NEEDS_EXP_FILE = 0; then
  !     if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
  ! TK_LIB_FLAG="-ltk${VERSION}\${TK_DBGX}"
  !     else
  ! TK_LIB_FLAG="-ltk`echo ${VERSION} | tr -d .`\${TK_DBGX}"
  !     fi
  !     TK_BUILD_LIB_SPEC="-L`pwd` ${TK_LIB_FLAG}"
  !     TK_LIB_SPEC="-L${exec_prefix}/lib/tk${VERSION} ${TK_LIB_FLAG}"
    else
  !     TK_BUILD_EXP_FILE="lib.exp"
  !     eval "TK_EXP_FILE=libtk${TCL_EXPORT_FILE_SUFFIX}"
  !     
  !     TK_BUILD_LIB_SPEC="-bI:`pwd`/${TK_BUILD_EXP_FILE}"
  !     TK_LIB_SPEC="-bI:${exec_prefix}/lib/tk${VERSION}/${TK_EXP_FILE}"
    fi

    AC_SUBST(CFLAGS_DEBUG)
    AC_SUBST(CFLAGS_DEFAULT)
  ***************
  *** 432,437 ****
  --- 440,447 ----
    AC_SUBST(TK_LD_SEARCH_FLAGS)
    AC_SUBST(TK_LIB_FILE)
    AC_SUBST(TK_LIB_FLAG)
  + AC_SUBST(TK_BUILD_EXP_FILE)
  + AC_SUBST(TK_EXP_FILE)
    AC_SUBST(TK_LIB_SPEC)
    AC_SUBST(TK_MAJOR_VERSION)
    AC_SUBST(TK_MINOR_VERSION)
  *** tk8.0/unix/.Makefile.inThu Jan 14 11:14:38 1999
  --- tk8.0/unix/Makefile.inThu Jan 14 11:14:38 1999
  ***************
  *** 166,173 ****
    TK_LIB_FLAG = @TK_LIB_FLAG@
    #TK_LIB_FLAG = -ltk

  ! TCL_LIB_FLAG = @TCL_LIB_FLAG@
  ! #TCL_LIB_FLAG = -ltcl

    # The symbol below provides support for dynamic loading and shared
    # libraries.  See configure.in for a description of what it means.
  --- 166,173 ----
    TK_LIB_FLAG = @TK_LIB_FLAG@
    #TK_LIB_FLAG = -ltk

  ! TK_EXP_FILE = @TK_EXP_FILE@
  ! TK_BUILD_EXP_FILE = @TK_BUILD_EXP_FILE@

    # The symbol below provides support for dynamic loading and shared
    # libraries.  See configure.in for a description of what it means.
  ***************
  *** 365,371 ****
    # some ranlibs write to current directory, and this might not always be
    # possible (e.g. if installing as root).

  ! install-binaries: $(TK_LIB_FILE) wish
    @for i in $(LIB_INSTALL_DIR) $(BIN_INSTALL_DIR) ;  do  if [ ! -d $$i ] ; then  --- 365,371 ----
    # some ranlibs write to current directory, and this might not always be
    # possible (e.g. if installing as root).

  ! install-binaries: $(TK_LIB_FILE) $(TK_BUILD_EXP_FILE) wish
    @for i in $(LIB_INSTALL_DIR) $(BIN_INSTALL_DIR) ;  do  if [ ! -d $$i ] ; then  ***************
  *** 379,384 ****
  --- 379,389 ----
    @$(INSTALL_DATA) $(TK_LIB_FILE) $(LIB_INSTALL_DIR)/$(TK_LIB_FILE)
    @(cd $(LIB_INSTALL_DIR); $(RANLIB) $(TK_LIB_FILE))
    @chmod 555 $(LIB_INSTALL_DIR)/$(TK_LIB_FILE)
  + @if test "$(TK_BUILD_EXP_FILE)" != ""; then  +     echo "Installing $(TK_EXP_FILE)";  +     $(INSTALL_DATA) $(TK_BUILD_EXP_FILE)  + $(LIB_INSTALL_DIR)/$(TK_EXP_FILE);  +     fi
    @echo "Installing wish"
    @$(INSTALL_PROGRAM) wish $(BIN_INSTALL_DIR)/wish$(VERSION)
    @echo "Installing tkConfig.sh"

  PatchFiles:
  tk8.0/unix/configure
  tk8.0/unix/configure.in
  tk8.0/unix/Makefile.in



  03/02/1999 17:20 - pat -duplicate of bug 1110
  03/05/1999 16:23 - stanton - This is not a duplicate.  The patch applies to Tk instead of Tcl.


tkt_uuid: 220421ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Patch to add "replace" option to listbox widget command
comment:
  OriginalBugID: 1112 RFE
  Version: 8.0.4
  SubmitDate: '1999-01-26'
  LastModified: '1999-12-04'
  Severity: LOW
  Status: Released
  Submitter: welch
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: SunOS einstein 5.5.1 Generic_103640-18 sun4u sparc SUNW,Ultra-En
  Machine: Other
  FixedDate: '1999-12-04'
  FixedInVersion: 8.3b1


  Name:

  Walker Mangum


  CVS:

  Dec 10 07:33 tk8.0.4.tar.gz


  Extensions:

  TestTool (in-house extension package)


  CustomShell:

  This patch adds "replace" to listbox widget command


  DesiredBehavior:

  Patch to add "replace" option to listbox widget command.


  We use listbox widgets for real-time data display.  Without "replace", you must do a .lb delete, then .lb insert to update an item.  Additionally, you must query the widget to get active and selected item status and must restore active or selected if you update an active or selected item.  Also, you have to maintain the listbox position if it is scrolled, since the delete operation may change it.


  With the "replace" option, you do not have to be aware of selection, active status, or position.  This makes code simpler and much faster.


  For instance, these two code segments produce the same result:


  Without "replace" --


  set active [.l.lb index active]

  set top [lindex [.l.lb yview] 0]

  set select [.l.lb selection includes $i]

  .l.lb delete $i

  .l.lb insert $i "string..."

  if $select {.l.lb selection set $i}

  .l.lb yview moveto $top

  .l.lb activate $active


  With "replace" --

  .l.lb replace $i $i "string..."


  replace syntax is:

    pathName replace first last ?element element ...?


  Patch:

  265a266,267

  > static voidReplaceEls _ANSI_ARGS_((Listbox *listPtr, int first, int last,

  >     int argc, char **argv));

  668c670,699

  <     } else if ((c == 'n') && (strncmp(argv[1], "nearest", length) == 0)) {

  ---

  >     }

  > 

  > else if (   (c == 'r')

  >  && (strncmp(argv[1], "replace", length) == 0))

  > {

  > int first;

  > int last;

  > 

  > if (argc < 4)

  > {

  >     Tcl_AppendResult(interp, "wrong # args: should be \"",

  >     argv[0], " replace first last ?element element ...?\"",

  >     (char *) NULL);

  >     goto error;

  > }

  > if (GetListboxIndex(interp, listPtr, argv[2], 0, &first) != TCL_OK)

  > goto error;

  > 

  > if (GetListboxIndex(interp, listPtr, argv[3], 0, &last) != TCL_OK)

  >     goto error;

  > if (last < first)

  > {

  >     Tcl_AppendResult(interp, "invalid listbox index ", argv[2],

  >     (char *) NULL);

  >     goto error;

  > }

  >     ReplaceEls(listPtr, first, last, argc-4, argv+4);

  > }

  > 

  > else if ((c == 'n') && (strncmp(argv[1], "nearest", length) == 0)) {

  914c945

  < "scan, see, selection, size, ",

  ---

  > "replace, scan, see, selection, size, ",

  1466a1498,1710

  > 

  > /*

  >  *----------------------------------------------------------------------

  >  *

  >  * ReplaceEls --

  >  *

  >  *Replace elements in a listbox widget

  >  *

  >  * Results:

  >  *None.

  >  *

  >  * Side effects:

  >  *contents of listPtr get updated;  it will be redisplayed

  >  *soon, but not immediately.

  >  *

  >  *----------------------------------------------------------------------

  >  */

  > 

  > static void

  > ReplaceEls(listPtr, first, last, argc, argv)

  >     register Listbox *listPtr;

  >     int first;/* first item to be replaced */

  >     int last;/* last item to be replaced */

  >     int argc;/* Number of new elements to add. */

  >     char **argv;/* New elements (one per entry). */

  > {

  >     register Element *prevPtr, *newPtr, *oldPtr;

  >     int length, i;

  >     int count;

  > int end;

  > 

  > if (first < 0)

  > first = 0;

  > if (first > listPtr->numElements)

  > first = listPtr->numElements;

  > if (last < 0)

  > last = 0;

  > if (last > listPtr->numElements)

  > last = listPtr->numElements;

  > 

  > end = last;

  > if (end == listPtr->numElements)

  > --end;

  > 

  > if (first < listPtr->numElements)

  >     count = last + 1 - first;

  > else

  > count = 0;

  > 

  > /* locate first element being replaced */

  >     if (first == 0)

  > prevPtr = NULL;

  >     else

  > {

  > for (i = first-1, prevPtr = listPtr->firstPtr; i > 0; i--)

  > prevPtr = prevPtr->nextPtr;

  >     }

  > 

  > /* replace elements, one at a time */

  >     for (i = count; i > 0; i--)

  > {

  > if (argc)

  > {

  > length = strlen(*argv);

  > newPtr = (Element *) ckalloc(ElementSize(length));

  > newPtr->textLength = length;

  > strcpy(newPtr->text, *argv);

  > newPtr->pixelWidth = Tk_TextWidth(listPtr->tkfont, newPtr->text,

  >   newPtr->textLength);

  > newPtr->lBearing = 0;

  > if (newPtr->pixelWidth > listPtr->maxWidth)

  > {

  > listPtr->maxWidth = newPtr->pixelWidth;

  > listPtr->flags |= UPDATE_H_SCROLLBAR;

  > }

  > ++argv;

  > --argc;

  > --count;

  > }

  > else

  > newPtr = NULL;

  > if (prevPtr == NULL)

  > {

  >     oldPtr = listPtr->firstPtr;

  > if (newPtr)

  > listPtr->firstPtr = newPtr;

  > else

  > {

  >     listPtr->firstPtr = oldPtr->nextPtr;

  >     if (listPtr->firstPtr == NULL)

  > listPtr->lastPtr = NULL;

  > }

  > }

  > else

  > {

  >     oldPtr = prevPtr->nextPtr;

  > if (newPtr)

  >     prevPtr->nextPtr = newPtr;

  > else

  >     prevPtr->nextPtr = oldPtr->nextPtr;

  >     }

  > if (newPtr)

  > {

  > newPtr->nextPtr = oldPtr->nextPtr;

  > newPtr->selected = oldPtr->selected;

  > prevPtr = newPtr;

  > }

  > else

  > {

  > if (oldPtr->pixelWidth == listPtr->maxWidth)

  > listPtr->flags |= UPDATE_H_SCROLLBAR;

  > if (oldPtr->selected)

  > --listPtr->numSelected;

  > }

  > ckfree((char *) oldPtr);

  >     }

  > 

  > if (argc > 0)

  > {

  >     /* insert remaining elements */

  >     for (i = argc ; i > 0; i--, argv++, prevPtr = newPtr)

  > {

  > length = strlen(*argv);

  > newPtr = (Element *) ckalloc(ElementSize(length));

  > newPtr->textLength = length;

  > strcpy(newPtr->text, *argv);

  > newPtr->pixelWidth = Tk_TextWidth(listPtr->tkfont, newPtr->text,

  >   newPtr->textLength);

  > newPtr->lBearing = 0;

  > if (newPtr->pixelWidth > listPtr->maxWidth)

  > {

  > listPtr->maxWidth = newPtr->pixelWidth;

  > listPtr->flags |= UPDATE_H_SCROLLBAR;

  > }

  > newPtr->selected = 0;

  > if (prevPtr == NULL)

  > {

  >     newPtr->nextPtr = listPtr->firstPtr;

  >     listPtr->firstPtr = newPtr;

  > }

  > else

  > {

  >     newPtr->nextPtr = prevPtr->nextPtr;

  >     prevPtr->nextPtr = newPtr;

  > }

  > prevPtr = newPtr;

  >     }

  >     listPtr->numElements += argc;

  > 

  > if (first <= listPtr->selectAnchor)

  > listPtr->selectAnchor += argc;

  > 

  > if (first < listPtr->topIndex)

  > listPtr->topIndex += argc;

  > 

  >     if (first <= listPtr->active)

  > {

  > listPtr->active += argc;

  > if (   listPtr->active >= listPtr->numElements

  > && listPtr->numElements > 0)

  > listPtr->active = listPtr->numElements-1;

  > }

  > listPtr->flags |= UPDATE_V_SCROLLBAR;

  > end = listPtr->numElements - 1;

  > }

  > 

  > if (   prevPtr != NULL

  > && prevPtr->nextPtr == NULL)

  > listPtr->lastPtr = prevPtr;

  > 

  > if (count)

  > {

  > /* some items were deleted */

  > listPtr->numElements -= count;

  > 

  > if (first <= listPtr->selectAnchor)

  > {

  > listPtr->selectAnchor -= count;

  > if (listPtr->selectAnchor < first)

  >     listPtr->selectAnchor = first;

  >     }

  >     if (first <= listPtr->topIndex)

  > {

  > listPtr->topIndex -= count;

  > if (listPtr->topIndex < first)

  >     listPtr->topIndex = first;

  >     }

  >     if (listPtr->topIndex > (listPtr->numElements - listPtr->fullLines))

  > {

  > listPtr->topIndex = listPtr->numElements - listPtr->fullLines;

  > if (listPtr->topIndex < 0)

  >     listPtr->topIndex = 0;

  > }

  > if (listPtr->active > last)

  > listPtr->active -= count;

  >     else

  > if (listPtr->active >= first)

  > {

  > listPtr->active = first;

  > if (   listPtr->active >= listPtr->numElements

  > && listPtr->numElements > 0)

  > listPtr->active = listPtr->numElements-1;

  > }    

  > listPtr->flags |= UPDATE_V_SCROLLBAR;

  > end = listPtr->numElements - 1;

  > }

  > 

  > ListboxComputeGeometry(listPtr, 0, 

  >   (listPtr->flags | UPDATE_H_SCROLLBAR) != 0, 0);

  > if (end >= listPtr->numElements)

  > end = listPtr->numElements - 1;

  > ListboxRedrawRange(listPtr, first, end);

  > }


  PatchFiles:

  tkListbox.c




  8.3 adds a -listvar option to the listbox, so users can
  use a Tcl list object and the Tcl list commands on it. 
  -- 12/04/1999 hobbs


tkt_uuid: 220422ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: clicking a menubutton that doesn't have an associated menu generates an error
comment:
  OriginalBugID: 1116 Bug
  Version: 8.1b1
  SubmitDate: '1999-01-26'
  LastModified: '1999-03-26'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: surles
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '1999-03-26'


  Name:

  Bryan Oakley


  ReproducibleScript:

  menubutton .mb -text "Press Me"

  pack .mb


  # press the button, and you'll get the error 'invalid command name ""'


  ObservedBehavior:

  Pressing the button gives the error 'invalid command name ""'


  This is caused by code in menu.tcl, procedure tkMbButtonUp, which attempts to get the menu type without first checking that a menu actually exists. Shame, shame, shame. :-)


  DesiredBehavior:

  Nothing should happen.


  Patch:

  *** menu.tcl.oldFri Jan 22 12:56:05 1999

  --- menu.tclFri Jan 22 12:58:32 1999

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

  *** 490,497 ****

        global tkPriv

        global tcl_platform


        set tearoff [expr {($tcl_platform(platform) == "unix") \

  !      || ([[$w cget -menu] cget -type] == "tearoff")}]

        if {($tearoff != 0) && ($tkPriv(postedMb) == $w) 

        && ($tkPriv(inMenubutton) == $w)} {

    tkMenuFirstEntry [$tkPriv(postedMb) cget -menu]

  --- 490,498 ----

        global tkPriv

        global tcl_platform


  +     set menu [$w cget -menu]

        set tearoff [expr {($tcl_platform(platform) == "unix") \

  !     || ($menu != "" && [$menu cget -type] == "tearoff")}]

        if {($tearoff != 0) && ($tkPriv(postedMb) == $w) 

        && ($tkPriv(inMenubutton) == $w)} {

    tkMenuFirstEntry [$tkPriv(postedMb) cget -menu]


  PatchFiles:

  lib/tk8.1/menu.tcl




  Applied the supplied patch.  Fixed.  03/26/1999 11:43 - surles -


tkt_uuid: 220423ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Upating Tk libraries speed issues
comment:
  OriginalBugID: 1118 RFE
  Version: 8.1b1
  SubmitDate: '1999-01-26'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Released
  Submitter: welch
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 5.5.1
  Machine: Other
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  Name:
  Jeffrey Hobbs

  CustomShell:
  elide

  DesiredBehavior:
  As mentioned on the newsgroup, the Tcl/Tk libraries aren't up to
  "spec" on capturing all expr's in {}s, and is not the most efficient
  in its use of == for string comparisons (in terms of speed).

  I have taken the stock Tk8.1b1 libraries and updated all necessary
  instances of == and != string comparisons to use the string command
  for speed (between 0 and 25% speed improvement per case).  OK, it
  isn't always a gain, but it makes a point.  I have also put in a
  few more [list ...] where appropriate, changed a couple configs to
  cgets, and added a <<ListboxSelect>> virtual event.  The last does
  not affect backwards compatibility (unless someone uses the same
  named virtual event).  What it provides, parallel to the alread core
  <<MenuSelect>>, is a generated event anytime the selection changes
  in a listbox via the Tk bindings.



  Patch:
  http://www.purl.org/net/hobbs/tcl/tk81b1-update.txt
  (made with diff -c, size 100+K)



  PatchFiles:
  tk8.1b1/library/*.tcl





  This does not touch related issues with Tcl8.1b1.
  To apply this patch, cd to <sources>/tk8.1b1/ and execute
  patch < tk81b1-update.txt

  This appear to have been included somewhere along the way.
  There are other things that could use updating, and I will
  look into that for 8.3. 
  -- 08/06/1999 hobbs


tkt_uuid: 220424ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Compile Tk with Cygwin B20.1
comment:
  OriginalBugID: 1139 RFE
  Version: 8.0.4
  SubmitDate: '1999-02-02'
  LastModified: '1999-12-22'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  FixedDate: '1999-12-22'
  FixedInVersion: 8.3b1


  Name:
  Jan Nijtmans

  DesiredBehavior:
  Here are a number of trivial changes to Tk, which make Tk
  compilable with CygWin B20.1. All of those involve portability
  problems which don't show up with Borland and VC++, but they
  show up very clearly with gcc and egcs.
  - egcs and borland don't have the "zmouse.h" header file. This
    is very easy to escape, by puting in the definition of
    WM_MOUSEWHEEL directly.
  - The function GetCurrentTime() is obsolete, and replaced by
    GetTickCount(). egcs only supports the newer function.
  - TkFontAttributes is defined both in tkFont.h and tkWinInt.h
    cygwin complains about that.
  - in tkFont.c, stricmp() is used in stead of strcasecmp().
    Cygwin only supports strcasecmp()
  - The definition of Status conflicts with some cygwin headers
    changing this to a typedef solves this problem.



  Patch:
  *** win/tkWinX.c.origSat Oct 10 02:30:37 1998
  --- win/tkWinX.cWed Jan 27 08:17:44 1999
  ***************
  *** 20,26 ****
     * The zmouse.h file includes the definition for WM_MOUSEWHEEL.
     */
    
  ! #include <zmouse.h>
    
    /*
     * Definitions of extern variables supplied by this file.
  --- 20,26 ----
     * The zmouse.h file includes the definition for WM_MOUSEWHEEL.
     */
    
  ! #define WM_MOUSEWHEEL (WM_MOUSELAST+1)
    
    /*
     * Definitions of extern variables supplied by this file.
  ***************
  *** 1057,1061 ****
    unsigned long
    TkpGetMS()
    {
  !     return GetCurrentTime();
    }
  --- 1057,1061 ----
    unsigned long
    TkpGetMS()
    {
  !     return GetTickCount();
    }
  *** win/tkWinInt.h.origMon Sep 14 20:24:00 1998
  --- win/tkWinInt.hWed Jan 27 08:17:43 1999
  ***************
  *** 36,42 ****
    #define WS_EX_TOOLWINDOW0x00000080L 
    #endif
    
  ! typedef struct TkFontAttributes TkFontAttributes;
    
    /*
     * The TkWinDCState is used to save the state of a device context
  --- 36,42 ----
    #define WS_EX_TOOLWINDOW0x00000080L 
    #endif
    
  ! /*typedef struct TkFontAttributes TkFontAttributes;*/
    
    /*
     * The TkWinDCState is used to save the state of a device context
  *** win/tkWinFont.c.origWed Jan 27 10:54:47 1999
  --- win/tkWinFont.cWed Jan 27 10:55:24 1999
  ***************
  *** 179,192 ****
         * Windows likes.
         */
    
  !     if ((stricmp(lf.lfFaceName, "Times") == 0)
  !     || (stricmp(lf.lfFaceName, "New York") == 0)) {
    strcpy(lf.lfFaceName, "Times New Roman");
  !     } else if ((stricmp(lf.lfFaceName, "Courier") == 0)
  !     || (stricmp(lf.lfFaceName, "Monaco") == 0)) {
    strcpy(lf.lfFaceName, "Courier New");
  !     } else if ((stricmp(lf.lfFaceName, "Helvetica") == 0)
  !     || (stricmp(lf.lfFaceName, "Geneva") == 0)) {
    strcpy(lf.lfFaceName, "Arial");
        }
    
  --- 179,192 ----
         * Windows likes.
         */
    
  !     if ((strcasecmp(lf.lfFaceName, "Times") == 0)
  !     || (strcasecmp(lf.lfFaceName, "New York") == 0)) {
    strcpy(lf.lfFaceName, "Times New Roman");
  !     } else if ((strcasecmp(lf.lfFaceName, "Courier") == 0)
  !     || (strcasecmp(lf.lfFaceName, "Monaco") == 0)) {
    strcpy(lf.lfFaceName, "Courier New");
  !     } else if ((strcasecmp(lf.lfFaceName, "Helvetica") == 0)
  !     || (strcasecmp(lf.lfFaceName, "Geneva") == 0)) {
    strcpy(lf.lfFaceName, "Arial");
        }
    
  *** xlib/X11/Xlib.h.origWed Apr  1 12:03:08 1998
  --- xlib/X11/Xlib.hWed Jan 27 08:49:21 1999
  ***************
  *** 58,64 ****
  --- 58,70 ----
    typedef char *XPointer;
    
    #define Bool int
  + /* The Status define conflicts with some Cygwin headers.  So on
  +    Windows we use a typedef instead.  */
  + #if defined(__WIN32__) || defined(_WIN32)
  + typedef int Status;
  + #else
    #define Status int
  + #endif
    #define True 1
    #define False 0
    




  PatchFiles:
  tkWinX.c tkWinInt.h tkWinFont.c Xlib.h




  These are all handled in 8.3b1 except for zmouse, which we
  still expect to be included. 
  -- 12/22/1999 hobbs


tkt_uuid: 220425ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: wish crashes when searching for text in a text widget
comment:
  OriginalBugID: 1148 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-02'
  LastModified: '1999-04-02'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  RelatedBugIDs: 1056  1666
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '1999-04-02'
  FixedInVersion: 8.1b3


  Name:
  Petasis George

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  I have an entry field that accepts the text to be searched in a text widget.
  I set the system encoding to iso8859-7 (Greek). I select with mouse some greek
  text from an external source (xterm or vim). I paste the text in the entry field. Although the system encoding is iso8859-7, the characters appear in the isoo8859-1 encoding. If i get the contents of the entry widget and use them for searching text using "text search" command, wish crashes. If, instead of pasting with mouse, write some greek characters in the entry field, everything work as expected.



  Related bud ID 1056.

  I have not been able to reproduce the problem, but it probably a side effect of bug 1056/1666 where the text widget was operating in bytes instead of characters.
  04/02/1999 15:50 - stanton -


tkt_uuid: 220426ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: Arugments on the wish command line do not have their character set translated.
comment:
  OriginalBugID: 1154 Bug
  Version: 8.1a2
  SubmitDate: '1999-02-02'
  LastModified: '1999-05-20'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hershey
  OS: Windows NT
  OSVersion: NT4.0J
  Machine: X86
  FixedDate: '1999-03-26'


  Name:
  Syd Polk

  CVS:
  1.1.4.2 generic/tkMain.c

  ReproducibleScript:
  On a Japanese machine, write a script. Use wish to call the script and give it Japanese command line arguments. The arguments are mangled. This bug is not present in tclMain.c, just in tkMain.c

  Patch:
  *** tkMain.c    Fri Dec 11 14:33:26 1998
  --- tkMain.c.new        Fri Dec 11 14:34:00 1998
  ***************
  *** 133,139 ****

        args = Tcl_Merge(argc-1, argv+1);
        Tcl_ExternalToUtfDString(NULL, args, -1, &argString);
  !     Tcl_SetVar(interp, "argv", args, TCL_GLOBAL_ONLY);
        Tcl_DStringFree(&argString);
        ckfree(args);
        sprintf(buf, "%d", argc-1);
  --- 133,139 ----

        args = Tcl_Merge(argc-1, argv+1);
        Tcl_ExternalToUtfDString(NULL, args, -1, &argString);
  !     Tcl_SetVar(interp, "argv", Tcl_DStringValue(&argString), TCL_GLOBAL_ONLY);
        Tcl_DStringFree(&argString);
        ckfree(args);
        sprintf(buf, "%d", argc-1);

  PatchFiles:
  generic/tkMain.c



  That patch was already applied as of 03/26/1999 13:40 - surles -


tkt_uuid: 220427ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Errors using tkfbox dialogs on different windows
comment:
  OriginalBugID: 1156 Bug
  Version: 8.0p2
  SubmitDate: '1999-02-02'
  LastModified: '1999-11-30'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: SunOS 5.5.1
  Machine: Other
  FixedDate: '1999-11-30'
  FixedInVersion: 8.2


  Name:
  Nancy Aten

  Extensions:
  (Symptom occurs in vanilla wish). Our product includes blt tktable img.

  CustomShell:
  (Symptom occurs in vanilla wish). In our product version, yes, I have applied plus-patch and redefined things like puts.

  ReproducibleScript:
  wish
  toplevel .test1
  toplevel .test2
  tk_getSaveFile -parent .test1 -filetypes {{all *}}
  tk_getSaveFile -parent .test2 
  destroy .test2
  tk_getSaveFile -parent .test1 -filetypes {{all *}}
  Error: invalid command name ".test2.__tk_filedialog.f3.menu.m"

  ObservedBehavior:
  Tk is unable to raise the save (or open) file dialog and gives an error message.
  This problem did not exist in 8.0 earlier versions, but in 8.0p2, tkfbox uses parent-window-specific __tk_filedialog data, rather than always using .__tk_filedialog. The problem I'm seeing is at line 663 of tkfbox.tcl - in tkFDialog, step (5. Initialize the file types menu), $data(typeMenu) is still pointing at the last-used-dialog, which in the example above no longer exists because its parent was destroyed.

  DesiredBehavior:
  Re-accessing an existing file dialog for that parent window needs to reset the relevant data fields to its own context.
  The dialog should open normally in the above script.



  I cannot repeat this in 8.2, so I'll assume it was fixed
  along the way. 
  -- 11/30/1999 hobbs


tkt_uuid: 220428ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Wrong modifiers detected on NT keyboards
comment:
  OriginalBugID: 1160 Bug
  Version: 8.0.3
  SubmitDate: '1999-02-02'
  LastModified: '2000-04-18'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 947 5088 5144
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '2000-04-18'
  FixedInVersion: 8.3.1


  Name:
  Marco R. Gazzetta

  Extensions:
  None

  CustomShell:
  None

  ReproducibleScript:
  pack [ canvas .c ]
  foreach Mod {Shift Control Alt M1 M2 M3 M4 M5} {
  bind .c <$Mod-Button-1> " puts $Mod "
  }

  ObservedBehavior:
  depending on the keyboard, wrong modifier keys are detected. On my HP Kayak keyboard, for instance, the mapping is:
  Shift    -> Shift
  Control    -> Control
  Alt    -> M2
  NumLock    -> M1
  ScrollLock -> M3

  DesiredBehavior:
  Modifier mapping should be correct



  NumLock and ScrollLock are not really modifiers, and should not be used as such; however, Tk understands additional modifiers past Shift, Control, and Alt (namely M1-M5).  As a convenience, we provided mappings for some of them.  These are arbitrary, of course -- M1 for NumLock, M3 for ScrollLock.  I don't know what you expect to see when you press NumLock + Button1, but the existing behavior seems reasonable.

  There was a problem with the Alt modifier and button presses on Windows -- it just didn't work (at least not in 8.3.0).  I corrected this, and the fix will go out with 8.3.1.  I was unable to determine how to prevent Tk from interpreting Alt as M2 for Button presses, so if you have both an <Alt-Button-1> and a <M2-Button-1> binding, the most recently declared one will be matched and executed.  I think this is better than the original 8.3.0 behavior, though.

  - eric

  -- 04/18/2000 ericm


tkt_uuid: 220429ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Windows menu separators do not reflect the menu background color
comment:
  OriginalBugID: 1166 Bug
  Version: 8.0.4
  SubmitDate: '1999-02-04'
  LastModified: '2000-04-13'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: ericm
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-04-13'
  FixedInVersion: 8.3.1


  Sample script:

  menu .m -bg blue
  .m add separator
  .m add command -label foobar
  .m post 0 0

  Note that the tearoff and command label are in blue, but the separator is still in the system background color.



  Verified with 8.2 on NT for both old and new style menus. 
  -- 10/22/1999 hobbs

  The problem was that we were letting the system draw the separator entries on the menus, rather than drawing it ourselves (as we do for every other kind of menu item).  Thus the separator was being drawn with the system background color rather than with the widget background.  Oddly, the code to draw the separator ourselves was already there, but due to the way we were creating the menu item on windows, it was never being used.  I corrected this and the problem is now fixed.  This fix will go out with 8.3.1.

  - eric

  -- 04/13/2000 ericm


tkt_uuid: 220430ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: The focus -force command does not work if the window has been iconized
comment:
  OriginalBugID: 1176 Bug
  Version: 8.0.5
  SubmitDate: '1999-02-10'
  LastModified: '1999-08-15'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-15'
  FixedInVersion: 8.2


  Test script:

  after 6000 reraise

  proc reraise {} {
      after 6000 reraise

      wm deiconify .
      raise .
      focus -force .
  }

  Run this test script and minimize the window. Notice that it will not pop up above all other ones as it should. When it does pop up, it does not have the focus.



  This works as expected in 8.2.0.  A change was made to deiconify
  for Windows in 8.2b3 that makes raise and focus superfuous. 
  -- 08/15/1999 hobbs


tkt_uuid: 220431ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Event loop freezes on standard dialogs
comment:
  OriginalBugID: 1212 Bug
  Version: 8.0.4
  SubmitDate: '1999-02-16'
  LastModified: '2000-02-01'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 715 830 2892
  OS: All Windows
  Machine: X86
  FixedDate: '2000-02-01'
  FixedInVersion: 8.3


  Name:
  Kevin B. Kenny

  Extensions:
  Tk 8.0.4 ; no other relevant extensions

  CustomShell:
  Script fails on an unmodified core release.

  ReproducibleScript:
  # If any of the standard dialogs comes up before the main window, the
  # Tk application's event loop on Win95/98 fails to handle events on the
  # main window and its children.  The following script illustrates the problem:

  set fileTypes {
      {{All Files} *}
  }
  grid [text .t -font {Courier}]
  grid [button .ok -text OK -command exit]
  set fileName [tk_getOpenFile  -filetypes $fileTypes  -title "Select file to display"]
  set f [open $fileName r]
  while {[gets $f line] >= 0} {
      .t insert end $line {} \n
  }
  close $f

  ObservedBehavior:
  The main window is "dead."  Mouse clicks and keyboard actions anywhere
  within the window and its descendants are ignored; for instance, clicking
  the "OK" button does nothing.

  DesiredBehavior:
  The main window should respond normally after the file selection dialog
  is dismissed.



  Verified on 8.2.0. 
  -- 08/20/1999 hobbs
  A work-around is to call 'update' before the first call to
  the dialog.  Problem only reproducable on Windows 
  -- 08/20/1999 hobbs
  The problem is actually restricted to the parent of the dialog
  that pops up, and only when the dialog is created before the
  parent is ever first mapped.  Windows would set it to disabled,
  then Tk would create a new wrapper, for which Windows wouldn't
  be aware, and you were left with a "disabled" toplevel.  This is
  fixed in 8.3.0, for all native Windows dialogs. 
  -- 02/01/2000 hobbs


tkt_uuid: 220432ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Crash on exit due to Tcl_Eval(consoleInterp, "tkConsoleExit");
comment:
  OriginalBugID: 1253 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-22'
  LastModified: '1999-04-05'
  Severity: CRIT
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '2019-06-01'
  FixedInVersion: 8.1b3


  Name:
  Petteri Kettunen

  CVS:
  Yes, February 19, 1999

  Extensions:
  N/A

  CustomShell:
  N/A

  ReproducibleScript:
  Open wish and do some graphics. I loaded some of my own extensions that
  operate on files and used simple routines to plot on canvas. 

  ObservedBehavior:
  When you finish the application by "exit 0" the program crashes. The
  same happens if you shut down the program by mouse.

  DesiredBehavior:
  Clean exit, no crash.

  Patch:
  See 11) below first. This is the patch for 8.1a2 sources, although the same applies to 8.1b1 (tkConsole.c revision 1.3).

  C:\oke\src\pntk>diff tkConsole.c c:\tmp\tkConsole.c
  542,544c542
  <       Tcl_DString dString;
  <
  <       consoleInterp = info->consoleInterp;
  ---
  >         consoleInterp = info->consoleInterp;
  557,561c555
  <
  <       Tcl_DStringInit(&dString);
  <       Tcl_DStringAppend(&dString, "tkConsoleExit", -1);
  <       Tcl_Eval(consoleInterp, Tcl_DStringValue(&dString));
  <       Tcl_DStringFree(&dString);
  ---
  >       Tcl_Eval(consoleInterp, "tkConsoleExit");

  PatchFiles:
  generic/tkConsole.c



  03/26/1999 18:42 - redman - Fixed, applied patch and fixed all other cases in tkConsole.c.  Couldn't find any instances outside of that file (not directly calling Tcl_Eval).

  I found the bug first from 8.1a2 (compiled with the Redmond compiler v.
  6.0). The program crashes in Tcl_ParseCommand (string[numBytes] = 0) and
  the string contains "tkConsoleExit". This comes when Tcl_Eval is called
  from tkConsole.c:

  Tcl_Eval(consoleInterp, "tkConsoleExit");

  Some compilers may store constant string to read-only memory. Hence it
  crashes. This is an old bug that I have seen before many times in my own
  extensions but it is still hidden in your 8.1b1 sources (tkConsole.c
  rev. 1.3).


tkt_uuid: 220433ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Tcl unloads library (package) before all events have been handled.
comment:
  OriginalBugID: 1273 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-23'
  LastModified: '1999-03-30'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  RelatedBugIDs: 989  1573  1593
  OS: Windows NT
  Machine: X86
  FixedDate: '1999-03-30'
  FixedInVersion: 8.1b3


  Name:
  George A. Howlett

  Extensions:
  BLT

  ReproducibleScript:
  Under Windows, dynamically load a package that calls
  Tk_CreateEventHandler 
  using a callback routine within its package.  Then exit Tcl.  Tcl will
  first
  unload the library and then handle pending Tk events.  This causes a
  fault
  Tcl attempts to execute a handlerPtr->proc that no longer is loaded.




  ObservedBehavior:
  Coredump. In Tk_HandleEvent where invoking winPtr->handlerPtr->proc.

  Note that this routine is successfully called many times earlier (before
  the library has been unloaded).





  DesiredBehavior:
  No fault.






  Any dynamically loaded package calling Tk_CreateEventHandler will fail in this way.
  ---
  Related to 989, 1573, 1593

  Unloading of libraries is deferred until all exit handlers have been invoked.
  03/30/1999 14:26 - stanton -


tkt_uuid: 220434ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: dde execute doesn't clear data after error
comment:
  OriginalBugID: 1277 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-23'
  LastModified: '1999-03-31'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: redman
  OS: Windows 98
  Machine: X86
  FixedDate: '1999-03-31'


  Name:
  Christopher Nelson

  ReproducibleScript:
  # The following fails because asdf isn't a valid topic
  dde execute NETSCAPE asdf www.scriptics.com
  # The following doesn't output what you'd expect
  dde execute Tk wish81 "puts foo"





  ObservedBehavior:
  The output in the console was:

  fooptics.com

  followed by some dark, fat, verticle bars from what I guess is binary
  data.




  DesiredBehavior:
  dde needs to clean up after each operation.





  03/31/1999 15:51 - redman - fixed, DDE doesn't give the correct data length on win95/98.


tkt_uuid: 220435ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: tk_messageBox underlines 1st char of buttons but doesn't act when that char is pressed
comment:
  OriginalBugID: 1292 Bug
  Version: 8.0.5
  SubmitDate: '1999-02-24'
  LastModified: '1999-08-15'
  Severity: LOW
  Status: Released
  Submitter: admin
  ChangedBy: hobbs
  RelatedBugIDs: 1293
  OS: All Unix
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-15'
  FixedInVersion: 8.2


  I can't find any way to press 'y' to invoke the "Yes" button in the following example:

      tk_messageBox -type yesno -default no

  After moving my mouse over the messageBox window, I tried ctrl-y, shift-y, ctrl-shift-y, alt-y, alt-shift-y, and tabbing to the "Yes" button.  Since "No" is the default, pressing return after any of these actions invoked "no".  If I remove the default,

      tk_messageBox -type yesno

  the same behavior occurs, except that the returns are ignored too.



  This functionality works as expected in 8.2.0 message boxes
  on Windows and Unix using Alt-<char>. 
  -- 08/15/1999 hobbs


tkt_uuid: 220436ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Core dump on fconfigure -blocking 0
comment:
  OriginalBugID: 1319 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '1999-09-13'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: Solaris 2.5
  Machine: Other
  FixedDate: '1999-09-13'
  FixedInVersion: 8.2


  Name:
  David W. Smith

  Extensions:
  None

  CustomShell:
  None

  ReproducibleScript:
  prowish80
  fconfigure stdin -blocking 0
  parray env




  ObservedBehavior:
  Panic in FlushChannel due to write(-1) with EAGAIN error code. Stdout is
  non-blocking (declared blocking). 




  DesiredBehavior:
  That the env works (as it does for protclsh80) and no panic.






  This is really confusing behavior. Works fine on NT but NOT Unix.
  --
  This has been fixed in TclPro 1.3 (or newer versions of wish). 
  -- 09/13/1999 hobbs


tkt_uuid: 220437ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: GPF occurs by bind %a
comment:
  OriginalBugID: 1321 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-02'
  LastModified: '1999-04-02'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: redman
  OS: Windows NT
  OSVersion: 4.0SP4
  Machine: X86
  FixedDate: '1999-04-02'
  FixedInVersion: 8.1b3


  Name:
  Satoshi Imai

  ReproducibleScript:
      GPF occurs by execution of the following commands. 
      
      button .b -text {Don't Push} -command exit
      pack .b
      
      bind .b <Enter> {
          set foo %a ;# GPF occurs by %a
      }
      




  Crashes on Windows.  03/25/1999 15:39 - surles -

  04/02/1999 18:53 - redman - %a is only valid during configure events, not during EnterLeave events.  But a check around the offending code. Fixed


tkt_uuid: 220438ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: binding to <Destroy> does not work in Windows 95
comment:
  OriginalBugID: 1351 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-07'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  FixedDate: '1999-08-07'
  FixedInVersion: 8.2


  Name:
  Chris Alfeld

  Extensions:
  None

  CustomShell:
  No modification.

  ReproducibleScript:
  In windows 95 (4.00.950a)
  Run the script:

  proc HandleDestroy {} {tk_messageBox -message "Bang!"}
  bind . <Destroy> HandleDestroy

  and then click on the closs window button.  

  ObservedBehavior:
  Wish will page fault.
  I have another, more complex program, that generates two page faults.  My guess is that inside that code run inside a destroy handler isn't being run correctly.  The more complex program binds to destroy in order to prompt the user to save the file and involves tk_messageBox, tk_getSaveFile, file io, and extensive variable manipulation.

  DesiredBehavior:
  In the example script, a tk_messageBox saying "Bang!"



  This doesn't page fault with 8.2.  However, the user may want
  to use:
     wm protocol . WM_DELETE_WINDOW HandleDestroy
  if they want to intercept the destroy call for the [X] close
  window button on Windows. 
  -- 08/07/1999 hobbs


tkt_uuid: 220439ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Button command does not respond when clicked
comment:
  OriginalBugID: 1359 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-07'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: WIN NT 4.0
  Machine: X86
  FixedDate: '1999-08-07'
  FixedInVersion: 8.1.1


  Name:
  Lloyd M. Uhler Jr.

  ReproducibleScript:
  #
  # Example 18-1
  # "Hello, World!" Tk program.
  #

  #!/usr/local/bin/wish
  button .hello -text Hello  -command {puts stdout "Hello, World!"}
  pack .hello -padx 20 -pady 10

  ObservedBehavior:
  the "-command" does not operate when the button clicked; the text should
  list in the DOS Window

  DesiredBehavior:
  "Hello, World!" should list to screen






  Is there anything I missed in my setup?

  Various versions of 8.0 didn't handle stdout output the same as
  tclsh (they were not console apps).  This has been fixed in newer
  versions of wish (the above works in 8.2).  In general, the std
  channels should not be relied on in wish apps on windows, but
  you are able to do a 'puts' for interactive testing. 
  -- 08/07/1999 hobbs


tkt_uuid: 220440ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: wm geometry refuses to move a toplevel until told to do it a second time
comment:
  OriginalBugID: 1360 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '1999-12-14'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 3687
  OS: Windows NT
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-12-14'
  FixedInVersion: 8.3b1


  #
  # Tcl script provided to demonstrate this bug was distilled from many
  # thousands of lines of machine generated calls to the tcl interp.
  # (Could possibly have been distilled further, but for no gain?)
  #
  # Broken into four separate files to be sourced from the console
  # (because this is the timing of the machine generated calls), plus a 
  # fifth for cleanup to allow go-around-again iterations.
  #
  # Run the console and source part0, part1, part2a, and part2b, in
  # that order.  Sourcing part2b refuses to position toplevel b (the 
  # one with the button on it).
  #
  # But sourcing it a second time will!
  #
  # (Try moving toplevel b manually and sourcing part2b.  Nothing 
  # happens unless you do it a second time.  Then the window moves!)
  #
  # Note that running the pieces together as one countinuous source 
  # works! (i.e. toplevel .b is successfully positioned at +400+425 
  # the first time)
  #

  # part0 ---------------------------------------------------------

  toplevel .a
  frame .a.child
  wm withdraw .a

  toplevel .b
  frame .b.child
  button .b.child.button -text Button
  wm withdraw .b

  wm deiconify .a

  pack .a.child -expand true -fill both

  # part1 ---------------------------------------------------------

  wm deiconify .a
  wm geometry .a 7x27+300+100
  raise .a

  # part2a --------------------------------------------------------

  pack .b.child.button -fill x
  pack .b.child -expand true -fill both

  wm deiconify .b

  # part2b --------------------------------------------------------

  wm geometry .b +400+425

  #
  # for some reason, commenting out this raise causes the first 
  # execution of this position to work!
  #

  raise .b

  # clean up to go around again -----------------------------------

  pack forget .b.child.button
  destroy .b.child.button
  pack forget .b.child
  destroy .b.child
  wm withdraw .b
  destroy .b
  pack forget .a.child
  destroy .a.child
  wm withdraw .a
  destroy .a

   8.  Described the undesired behavior you observed
   
   The window manager geometry command refuses to position a toplevel 
  until the command is executed a second time.

   9.  Described the behavior you expect to see
   
   I expect to see the toplevel positioned properly with the first call 
  to wm!

   10. If you have created a patch, please include it in the email or
       provide a URL of a patch file and list affected files.
   
   No patch file.

  This was due to a lack of an update call before deiconifying.
  The work-around was to add 'update idle' before the wm deiconify
  call.  In 8.3b1 this is fixed. 
  -- 12/14/1999 hobbs


tkt_uuid: 220441ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: "grid .b ^" works, "grid .b ^ ^" fails
comment:
  OriginalBugID: 1386 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '2000-01-20'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-01-20'
  FixedInVersion: 8.3


  Name:
  John Ellson

  ReproducibleScript:
  works as expected:

  grid [button .b11] [button .b12] [button .b13] -sticky ns
  grid [button .b22] ^

  fails:

  grid [button .b11] [button .b12] [button .b13] -sticky ns
  grid [button .b22] ^ ^




  ObservedBehavior:
  $ wish bug 
  Error in startup script: can't find slave to extend with "^".
      while executing
  "grid [button .b22] ^ ^"
      (file "bug" line 2)




  DesiredBehavior:
  Should be able to rowspan any number of columns




  This bug was due to the manner in which the gridder intrepreted consecutive ^'s.  Previously, ^ ^ was interpreted as meaning that there must be a 2-column widget above to extend, neglecting the case where there was actually 2 1-column widgets above.  Now, ^ ^ is interpreted as a possible width; the gridder will consume as many ^'s as there are columns in the widget, and leave the rest for the extension of other widgets.

  This is fixed in 8.3.

  - eric

  -- 01/20/2000 ericm


tkt_uuid: 220442ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: text widget manpage wrong about Windows word definition
comment:
  OriginalBugID: 1388 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '2000-01-18'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2132
  OS: Windows NT
  OSVersion: 4.0 sp 3
  Machine: X86
  FixedDate: '2000-01-18'
  FixedInVersion: 8.3


  Name:

  Christopher Hylands



  Extensions:

  Itcl3.0/Tcl8.0.3/Tk8.0.3



  CustomShell:

  None



  ReproducibleScript:

  Double clicking on a word in a text widget includes the punctuation under

  windows.  The text man page does not mention that the definition of a

  word differs between Windows and Unix.







  ObservedBehavior:

  The online Tcl help shipped with Itcl3.0/Tcl8.0.3/Tk8.0.3 and

  the tk8.0.5 page at ~ptdesign/src/tcltk/tk8.0.5/doc/text.n

  both say:

  --start--

    In the descriptions below, ``word'' refers to a contiguous group

    of letters, digits, or ``_'' characters, or any single character

    other than these.

  ...

    Double-clicking with mouse button 1 selects the word under the mouse

    and positions the insertion cursor at the beginning of the word.

    Dragging after a double click will stroke out a selection consisting

    of whole words.

  --end--



  D:/Program Files/Tcl/lib/tk8.0/text.tcl says:

  --start--

    bind Text <Double-1> {

       set tkPriv(selectMode) word

       tkTextSelectTo %W %x %y

       catch {%W mark set insert sel.first}

    }

  --end--

  In text.tcl tkTextSelectTo includes the following code frag that

  is used when we are searching for a word

  --start--

        word {

        if {[$w compare $cur < anchor]} {

           set first [tkTextPrevPos $w "$cur + 1c" tcl_wordBreakBefore]

               set last [tkTextNextPos $w "anchor" tcl_wordBreakAfter]

                   } else {

                     set first [tkTextPrevPos $w anchor tcl_wordBreakBefore]

                  set last [tkTextNextPos $w "$cur - 1c" tcl_wordBreakAfter]

              }

  --end--



  tcl_wordBreakBefore and tcl_wordBreakAfter are defined in

  D:/Program Files/Tcl/lib/tcl8.0/word.tcl



  They use the following variables that are also set in word.tcl

  --start--

    # The following variables are used to determine which characters are

    # interpreted as white space.



    if {$tcl_platform(platform) == "windows"} {

        # Windows style - any but space, tab, or newline

        set tcl_wordchars "\[^ \t\n\]"

        set tcl_nonwordchars "\[ \t\n\]"

    } else {

        # Motif style - any number, letter, or underscore

        set tcl_wordchars {[a-zA-Z0-9_]}

        set tcl_nonwordchars {[^a-zA-Z0-9_]}

    }

  --end--



  So, the definition of a word is platform dependent.  This should be

  mentioned in the docs







  DesiredBehavior:

  The text man page should mention that the definition of a word is

  platform dependent







  tcl_(non)wordchars is now in tclvars.n, with a reference for that
  in the text widget docs.  The value has also been changed to the
  8.1+ unicode \[sS] and \[Ww]. 
  -- 01/18/2000 hobbs


tkt_uuid: 220443ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: "missing export TK80.DLL:_Tk_CreateWindowFromPath
comment:
  OriginalBugID: 1402 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '1999-04-16'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: Windows 98
  Machine: X86
  FixedDate: '1999-04-16'
  FixedInVersion: 8.1b3


  Name:
  Bill Tovrea

  ReproducibleScript:
  Re-made a previously successful program ( under TK 8.0) which uses Tk_CreateWindowFrom Path. After downloading/updating to TK 8.0.3, received the following link error message "project.exe is linked to missing export TK80.DLL:_Tk_CreateWindowFromPath"

  ObservedBehavior:
  Unlinkable -> unexecutable

  DesiredBehavior:
  same successful link as with tk 8.0



  Tk now exports everything via the stubs mechanism
  04/16/1999 13:31 - stanton -


tkt_uuid: 220444ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Tk tests fail due to Makefile problem
comment:
  OriginalBugID: 1409 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-13'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 957 1951 1896 2195
  OS: Digital Unix
  Machine: Other
  FixedDate: '1999-08-13'
  FixedInVersion: 8.1


  Name:
  James Bonfield

  Extensions:
  4.0

  ReproducibleScript:
  The Makefile links with -rpath /usr/local/lib, which means the tests will fail
  (and indeed the pogram crashes) as even specifying LD_LIBRARY_PATH will not
  prevent tktest from using whatever version of libtk.so is installed in /usr/local/lib. This is probably not an issue when generating static libraries.

  Note that _RLD_LIST can be specified instead to ensure preloading of the correct
  library. This requires Makefile changes, so I haven't submitted a patch (I do
  not know enough about autoconf etc).

  I changed the LD_LIBRARY_PATH line in the makefile with something like:

  _RLD_LIST=`pwd`/libtk8.0.so:${TCL_BIN_DIR}/libtcl8.0.so:DEFAULT

  ObservedBehavior:
  Tests appear to fail, but this is very misleading.

  DesiredBehavior:
  Tests work.



  This problem should be alleviated with the rework of the configure
  scripts for 8.1. 
  -- 08/13/1999 hobbs


tkt_uuid: 220445ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Macintosh: Checkbutton & radiobutton menu entries with -accelerator option
comment:
  OriginalBugID: 1416 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '2000-01-27'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Macintosh
  Machine: Power PC
  FixedDate: '2000-01-27'
  FixedInVersion: 8.3b2


  Name:
  Hemang Lavana

  ReproducibleScript:
  #################
  # testmenus.tcl for Mac
    set w .

  # Create a menubar in the window
    pack [menubutton [set m ${w}m] -text Menubar  -menu [set frmeMenu $m.frme]]

    menu $frmeMenu -tearoff 0
    $frmeMenu add radiobutton -label "(1) First Item"  -accelerator "Alt-1"  ;
    $frmeMenu add radiobutton -label "(2) Second Item"
    $frmeMenu add separator
    $frmeMenu add checkbutton -label "(3) Third Item"  -accelerator "Alt-3"  ;
    $frmeMenu add checkbutton -label "(4) Fourth Item"  -variable ::vars(FourthItem)
    $frmeMenu add separator
    $frmeMenu add command -label Exit -command exit

  ##################

  ObservedBehavior:
  Menu entries that have the -accelerator option specified
  cannot be unchecked once these are checked, on MacOS 8.5.
  In this example, it is possible to uncheck items 2 and 4
  but not 1 and 3 which have the -accelerator option.
  Thus it is possible to have all the four entries to be
  checked when clicked in the sequence 1, 2, 3 & 4 even
  though 1 & 2 are radiobuttons.

  DesiredBehavior:
  Only one item should be checked at any time for radiobuttons 
  such as 1 & 2. For checkbutton 3, we should be able to uncheck
  the item by clicking on it. 



  Works correctly on Unix (Solaris 2.5.1).
  --
  There was a patch to fix this that is in the 8.3 beta sources
  (no 8.3 beta build for mac). 
  -- 01/27/2000 hobbs


tkt_uuid: 220446ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: On exit, fonts are deleted before images
comment:
  OriginalBugID: 1421 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '1999-11-17'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux-Red Hat
  Machine: Other
  FixedDate: '1999-11-17'
  FixedInVersion: 8.2


  Name:
  D. Richard Hipp

  CustomShell:
  Plus patches applied

  ReproducibleScript:
  I'm extending the "bitmap" image handler so that it holds a Tk_Font.
  You have to load my extension, then create a bitmap for the problem
  to occur.



  ObservedBehavior:
  When you type "exit", you get this error:

  TkFontPkgFree: all fonts should have been freed already
  IOT trap/Abort




  DesiredBehavior:
  I don't expect to get the error.





  The problem appears to be in the file tkWindow.c on or about line 1230.
  When tk is shutting down, it deletes all fonts first.  Then it tries to
  delete images.  But my image extension tries to delete its font when it
  is deleted, even though the font is already deleted.  Reversing the order
  of the calls to TkFontPkgFree() and TkDeleteAllImages() seems to clear
  the problem up.

  Is there a better way to fix this?  Is there something I can do within my
  extension to work around the problem?
  --
  Fonts are deleted after images in the 8.2 version of Tk. 
  -- 11/17/1999 hobbs


tkt_uuid: 220447ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: sockets,files not closed on program termination
comment:
  OriginalBugID: 1437 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-04'
  LastModified: '1999-10-19'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '1999-10-19'
  FixedInVersion: 8.2


  Name:
  David Maggiano

  ObservedBehavior:
  When running tk applications on NT 4.0, sockets do not appear to be closed
  for you when you close the window to exit the application.  This causes
  an error the next time the program is executed, indicating that the requested
  port is already in use.  I see no way other than a shut down to reset the 
  port.



  DesiredBehavior:
  I would expect sockets to be closed when the parent application is terminated.




  The socket driver code was rewritten in 8.2.0.  A quick test of:
     proc foo args {puts [info level 0]}
     socket -server foo 12345
  run through consecutive invocations of wish where wish was ended
  with the [X] worked, so it appears this was fixed with 8.2. 
  -- 10/19/1999 hobbs


tkt_uuid: 220448ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Tear-off menus don't respect vertical task bar
comment:
  OriginalBugID: 1465 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-08'
  LastModified: '2000-01-07'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  FixedDate: '2000-01-07'
  FixedInVersion: 8.3b1


  Name: Christopher Nelson

  ObservedBehavior:
      When working with a task bar down the left side of the screen, tear-off
      menus appear at (0,0), under the task bar and out of sight. A button
      appears on the task bar corresponding to the tear-off but clicking it
      does not bring the tear-off to the top.

  DesiredBehavior:
      The tear-off should not always appear at (0,0) but should at least not
      appear under the task bar.


  With 8.3b1, verified that while they still appear at 0,0 all the
  time, with the task bar on the left side, the 0,0 start justs to
  the right of the task bar, so the menu won't be obscured.  This
  was with NTsp4. 
  -- 01/07/2000 hobbs


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


  Name:
  Bob Fletcher

  Extensions:
  expect

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



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





  PatchFiles:
      TkCanvasArc.c
      





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


tkt_uuid: 220452ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: tk_getOpenFile doesn't work
comment:
  OriginalBugID: 1490 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-11'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Other
  OSVersion: SCO5.0.4
  Machine: NA
  FixedDate: '1999-08-20'
  FixedInVersion: 8.0.5


  Name:
  Luca

  ReproducibleScript:
      Try the following code under Tcl/Tk 8.0.4 (I'm working on a SCO5.0.4
      machine).
      
      #!/bin/sh
      # The next line restarts using wish8.0  exec wish "$0" ${1+"$@"}
      
      wm withdraw .
      tk_getOpenFile -title "I don't work" -initialdir / 
      exit
      



  ObservedBehavior:
      Wherever you click the selected entry is the top-left one!!!!
      
      





      It works under Tcl/Tk 8.0.3
      
  --
  This works as expected under 8.0.5 and 8.2.0. 
  -- 08/20/1999 hobbs


tkt_uuid: 220453ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: International fonts not found automatically
comment:
  OriginalBugID: 1492 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-11'
  LastModified: '2000-04-16'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: osr2, US English
  Machine: X86
  FixedDate: '2000-04-16'
  FixedInVersion: 8.3.1


  Name: Bill Schongar

  ReproducibleScript:
      pack [canvas .c -width 400 -height 400]
      .c create text 100 100 -text
      "\u6a29\u5229\u306e\u5236\u9650\u306b\u3064\u3044\u3066\uff1a"
      
      Ran wish from default 8.01b1 install
      
      
      Kanji font installed - Bitstream Cyberbit
      Original encoding    - ShiftJIS
      Conversion method    - native2ascii
      Text translation(EN) - "Restricted Rights Notice"
      
  ObservedBehavior:
      There is a 'hang' delay (3-5 seconds of complete unresponsiveness), then
      non-printable ASCII chars appear in the canvas.
      
      If the supporting font is specified directly, response is near immediate
      and the correct local characters appear. Release notes for 8.1 indicate
      that "Tk guarantees to find a way to display any Unicode character
      regardless of the font you selected, as long as there is some font in
      the system that contains the Unicode character." 
      



  DesiredBehavior:
      When characters drawn from the installed BitStream Cyberbit Font, such
      as are shown with:
      
      .c create text 100 100 -font {{Bitstream Cyberbit} 8} -text
      "\u6a29\u5229\u306e\u5236\u9650\u306b\u3064\u3044\u3066\uff1a"
      
      Then the characters appear correctly with no other environment
      (encoding, locale, etc) changes.
      





  The system is probably returning something confusing when describing the font.  We need to write a test program for the user to run that will dump the font attributes so we can see what we are getting.
  03/29/1999 20:51 - stanton -
  --
  Note that 8.3b1 adds "Bitstream Cyberbit" into the default font
  fallback list, so it should be found quickly.  This should be
  tested again with 8.3+ to see if that solves the problem. 
  -- 01/07/2000 hobbs
  8.3 added "bitstream cyberbit" to the fallback which should fix
  the problem in general, but on NT there was a bug that caused fonts
  longer than 16 chars in name length to not get loaded.  This should
  all work as expected for 8.3.1. 
  -- 04/16/2000 hobbs


tkt_uuid: 220454ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: spawning wish or tktest with pipe on windows causes parent wish/tktest to hang on closing pipe
comment:
  OriginalBugID: 1495 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-12'
  LastModified: '1999-04-02'
  Severity: SER
  Status: Released
  Submitter: redman
  ChangedBy: redman
  RelatedBugIDs: 1594
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-04-02'
  FixedInVersion: 8.1b3


  This sample script, when run from wish81.exe or it's variants, or tktest.exe, causes it to hang on closing the pipe.  It appears to be a problem with either detecting that the pipe is closed (the child process's fault) or not killing off the child (the parent's fault) if it's supposed.  Verified to be in 8.1b1 and 8.1b2, should fix this before the final 8.1 release.

  Sample script:

  set tcltest [info nameofexecutable]
  puts $tcltest
  update
  puts "goodbye"
  flush stdout

  catch {
      file delete -force tmp
      set f [open tmp w]
      puts $f {
  exit
      }
      close $f
      set f [open "|[list $tcltest tmp]" r]
      close $f
  }
  catch {file delete -force tmp}



  Related bug ID 1594.

  04/02/1999 18:54 - redman - Should be fixed now, removed the send code.


tkt_uuid: 220455ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: rework Tk 8.1 winDialog test to keep it from hanging the test suite
comment:
  OriginalBugID: 1498 Bug
  Version: 8.1
  SubmitDate: '1999-03-13'
  LastModified: '2000-04-07'
  Severity: LOW
  Status: Released
  Submitter: admin
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-04-07'
  FixedInVersion: NA


  The following test in tk8.1/tests/winDialog.test is currently skipped
  because otherwise it hangs the test suite by causing a message dialog
  to pop up, requiring a user to click OK to continue.  Note that this
  test cannot be run by itself--it needs to be run inside the file...

  set a aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
  append a $a
  append a $a
  append a $a
  append a $a
  test winDialog-5.16 {GetFileName: initial file: long name} {knownBug} {
      start {set x [tk_getSaveFile -initialfile $a -title Long]}
      then {
  Click 1
      }
      set x
  } [string range [file join [pwd] $a] 0 257]


  This test wasn't being called for a while, but it also doesn't
  hang (nor is it a bug) for 8.3.1. 
  -- 04/07/2000 hobbs


tkt_uuid: 220456ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: make test errors for Tk 8.0.5
comment:
  OriginalBugID: 1503 Bug
  Version: 8.0.5
  SubmitDate: '1999-03-15'
  LastModified: '1999-08-31'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '1999-08-31'
  FixedInVersion: 8.2


  Name:
  Larry W. Virden

  Extensions:
  Tk 8.0.5

  CustomShell:
  none

  ReproducibleScript:
      on my Ultra 5 Solaris 2.6 (CDE) system, I did a configure, make all, and
      then a
      make test.  I got a series of failures during the test.
      



  ObservedBehavior:
      canvText.test
      
      ==== canvText-6.1 ComputeTextBbox procedure
      ==== Contents of test case:
      
          .c itemconfig test -font $font -text 0
          .c coords test 0 0
          set x {}
          lappend x [.c itemconfig test -anchor n; .c bbox test]
          lappend x [.c itemconfig test -anchor nw; .c bbox test]
          lappend x [.c itemconfig test -anchor w; .c bbox test]
          lappend x [.c itemconfig test -anchor sw; .c bbox test]
          lappend x [.c itemconfig test -anchor s; .c bbox test]
          lappend x [.c itemconfig test -anchor se; .c bbox test]
          lappend x [.c itemconfig test -anchor e; .c bbox test]
          lappend x [.c itemconfig test -anchor ne; .c bbox test]
          lappend x [.c itemconfig test -anchor center; .c bbox test]
      
      ==== Result was:
      {-6 0 6 19} {-1 0 11 19} {-1 -9 11 10} {-1 -19 11 0} {-6 -19 6 0} {-11
      -19 1 0} 
      {-11 -9 1 10} {-11 0 1 19} {-6 -9 6 10}
      ---- Result should have been:
      {-6 0 6 19} {-1 0 11 19} {-1 -10 11 9} {-1 -19 11 0} {-6 -19 6 0} {-11
      -19 1 0} 
      {-11 -10 1 9} {-11 0 1 19} {-6 -10 6 9}
      ---- canvText-6.1 FAILED
      
      clipboard.test
      
      ==== clipboard-6.2 Tk_ClipboardAppend procedure
      ==== Contents of test case:
      
          setupbg
          clipboard clear
          clipboard append -f INTEGER -t TEST "16"
          set result [dobg {selection get -s CLIPBOARD TEST}]
          cleanupbg
          set result
      
      ==== Result was:
      CLIPBOARD selection doesn't exist or form "TEST" not defined
      ---- Result should have been:
      0x10
      ---- clipboard-6.2 FAILED
      
      grid.test
      
      ==== grid-6.9 location: check updates pending
      ==== Contents of test case:
      
              set a ""
              foreach i {0 1 2} {
                  frame .$i -width 120 -height 75 -bg red
                  lappend a [grid location . 150 90]
                  grid .$i -row $i -column $i
              }
              set a
      
      ==== Result was:
      {0 0} {0 1} {1 1}
      ---- Result should have been:
      {0 0} {1 1} {1 1}
      ---- grid-6.9 FAILED
      
      and
      
      textIndex.test
      
      ==== textIndex-5.1 TkTextGetIndex, "@"
      ==== Contents of test case:
      
          .t index @12,9
      
      ==== Result was:
      1.0
      ---- Result should have been:
      1.1
      ---- textIndex-5.1 FAILED
      



  DesiredBehavior:
      No failures
      





      I am uncertain about the severity rating for this report, since I don't
      know how much problem this will cause my users...
  --
  None of these errors comes up for 8.2, with the possible exception
  of the clipboard one for Larry, but I can't reproduce it. 
  -- 08/31/1999 hobbs


tkt_uuid: 220457ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: compiler errors with MSVC vers. 6 / tkWinWm.c
comment:
  OriginalBugID: 1519 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-18'
  LastModified: '1999-04-05'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: Windows NT
  Machine: X86
  FixedDate: '2019-06-01'
  FixedInVersion: 8.1b3


  Name:
  Petteri Kettunen

  Extensions:
  N/A

  CustomShell:
  N/A

  ReproducibleScript:
      1) Download sources from Scriptics FTP.
      2) unzip tk81b2.zip
      3) cd win
      4) copy makefile.vc makefile & edit paths.
      5) nmake
      



  ObservedBehavior:
              "c:\visualstudio\vc98\bin\cl.exe" -DDLL_BUILD -DBUILD_tk -Z7 -Od
      -WX -c
      -W3 -nologo -Fp.\Debug\ -YX -D_X86_=1 -DWIN32 -D_WIN32 -MDd
      -I"c:\visualstudio\v
      c98\include"  -I..\win -I..\generic -I..\bitmaps -I..\xlib
      -I..\..\tcl\generic
      -DTCL_MEM_DEBUG -DUSE_TCL_STUBS -Fo.\Debug\ ..\win\tkWinWm.c
      tkWinWm.c
      ..\win\tkWinWm.c(1148) : warning C4700: local variable 'winPtr' used
      without hav
      ing been initialized
      ..\win\tkWinWm.c(1148) : error C2220: warning treated as error - no
      object file
      generated
      NMAKE : fatal error U1077: '"c:\visualstudio\vc98\bin\cl.exe"' : return
      code '0x
      2'
      Stop.
      
      
      



  DesiredBehavior:
      Succesful compilation without errors.
      



  Patch:
  See Tk_WmCmd in win/TkWinWm.c. I commented out the troublesome lines. 



  PatchFiles:
      N/A
      





  03/26/1999 18:42 - redman - Fixed.

      "log" of nmake test is below:

      E:\ngs\devtools\tcl\tk\win>nmake test

      Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
      Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

              set TCL_LIBRARY=..\..\tcl/library
              set
      PATH=..\..\tcl\win\Debug;c:\bin;C:\WINNT\system32;C:\WINNT;;C:\SQL\B
      INN;C:\SQL\DLL;C:\PICKER\BINNT;C:\PICKER\BIN;C:\PICKER\CVAB\DLL;C:\PICKER
      \CVAB\P
      ROG;C:\PROGRA~1\MICROS~1\Office;C:\WIN32APP\TOOLKIT;c:\win32app\toolkit;C
      :\Visua
      lStudio\Common\Tools\WinNT;C:\VisualStudio\Common\MSDev98\Bin;C:\VisualSt
      udio\Co
      mmon\Tools;C:\VisualStudio\VC98\bin;c:\bin;c:\binnt\gnu;c:\binnt;c:\pvcs nt;c:\r
      si\idl50;C:\VisualStudio\VJ98;Y:.;U:.;S:.
              .\Debug\tktest.exe ../tests/all.tcl | .\Debug\cat32.exe

  This code looks broken. 
  04/05/1999 20:27 - stanton -


tkt_uuid: 220458ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: test suite failures
comment:
  OriginalBugID: 1523 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-18'
  LastModified: '1999-04-16'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hershey
  OS: Solaris
  Machine: Other
  FixedDate: '1999-04-02'
  FixedInVersion: 8.1b3


  Name:  Don Porter
  Many test suite failures.  I'll summarize:
      ==== canvText-6.1 FAILED
      ==== config-8.9 FAILED
      ==== grid-6.9 FAILED
      ==== grid-14.3 FAILED
      ==== main-1.1 FAILED
      ==== safe-5.1 FAILED
      ==== scale-3.29 FAILED
      ==== scale-3.30 FAILED
      ==== scale-3.31 FAILED
      ==== send-10.19 FAILED
      ==== send-12.2 FAILED
      ==== textDisp-2.22 FAILED
      ==== textDisp-2.23 FAILED
      ==== textDisp-24.9 FAILED
      ==== unixEmbed-1.3 FAILED
      ==== unixEmbed-1.4 FAILED
      ==== unixfont-5.4 FAILED
      ==== unixfont-5.5 FAILED
      ==== unixfont-5.6 FAILED
      ==== unixfont-5.7 FAILED
      ==== unixfont-5.8 FAILED
      ==== unixfont-5.10 FAILED
      ==== unixfont-5.11 FAILED
      ==== unixfont-5.12 FAILED
      ==== unixfont-8.3 FAILED
      ==== unixfont-8.4 FAILED
      ==== unixfont-8.6 FAILED
      ==== unixSend-10.19 FAILED
      ==== unixSend-12.2 FAILED
      ==== unixWm-2.1 FAILED
      ==== unixWm-2.2 FAILED
      ==== unixWm-2.7 FAILED
      ==== unixWm-2.8 FAILED
      ==== unixWm-2.9 FAILED
      ==== unixWm-3.1 FAILED
      ==== unixWm-3.2 FAILED
      ==== unixWm-3.7 FAILED
      ==== unixWm-3.8 FAILED
      ==== unixWm-3.9 FAILED
      ==== winfo-3.4 FAILED
      
      all.tcl:Total6054Passed5851Skipped163Failed40
      Sourced 68 Test Files.
      Files with failing tests: canvText.test config.test grid.test main.test
      safe.test scale.test send.test textDisp.test unixEmbed.test
      unixFont.test unixSend.test util.test winfo.test
      
      Several tests report that an integer is expected,
      but what looks like a floating point value is seen.

  Here's how I handled the failures:
      ==== canvText-6.1 FAILED:  marked nonPortable
      ==== config-8.9 FAILED:  marked nonPortable
      ==== grid-6.9 FAILED:  marked nonPortable
      ==== grid-14.3 FAILED:  marked nonPortable
      ==== main-1.1 FAILED: can't reproduce this one
      ==== safe-5.1 FAILED: fixed bug in safe interp deletion.
      ==== scale-* FAILED:  fixed a bug in the scale command.
       The ScaleWidgetObjCmd was not checking the result of the
       Tcl_GetIndexFromObj call, so it didn't always error out correctly.
      ==== send-10.19 FAILED-fixed bad reference to tcltest namespace variable
      ==== send-12.2 FAILED-fixed bad reference to tcltest namespace variable
      ==== textDisp-* FAILED: could not reporduce
      ==== unixEmbed-* FAILED: marked nonPortable
      ==== unixfont-5.* FAILED: cannot reproduce
      ==== unixfont-8.3 FAILED: fixed bad test
      ==== unixfont-8.* FAILED: cannot reproduce
      ==== unixSend-10.19 FAILED-fixed bad reference to "fd"
      ==== unixSend-12.2 FAILED-fixed bad reference to "fd"
      ==== unixWm-* FAILED: can't reproduce
      ==== winfo-3.4 FAILED: can't reproduce


tkt_uuid: 220459ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Tk hangs if compiled with --enable-threads
comment:
  OriginalBugID: 1527 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-18'
  LastModified: '1999-03-26'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: surles
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '1999-04-15'
  FixedInVersion: 8.1


  Name:
  Petasis Georgios

  ReproducibleScript:
      If you compile both tcl and tk with --enable-threads, wish just hangs
      after
      a while. Also, although I have download tk8.1b2, the directory created
      after unataring was named tk8.1b2, tk_patchLevel reports 8.1b1!
      (There is NO other version installed on machine). This happens under 
      Solaris 2.6.
      




  4/15/99 - redman - the patch level problem was a known bug in b2, fixed in b3.  I've already fixed two problems in Tk regarding hanging, one was for the Notifier locking itself up which is probably the case for this bug.  There is not enough information to figure this out for sure, though.


tkt_uuid: 220460ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Stub Entries
priority: 2
foundin: None
resolution: Fixed
title: Hooks for new Smooth methods
comment:
  OriginalBugID: 1540 RFE
  Version: 8.1b2
  SubmitDate: '1999-03-18'
  LastModified: '1999-12-13'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Other
  Machine: NA
  FixedDate: '1999-12-13'
  FixedInVersion: 8.3b1


  Name:

  Jan Nijtmans


  DesiredBehavior:

      This patch allows more smooth methods to be registered for the

      line and poly canvas items. This feature originated originally

      in the dash-patch, and it is developed by Jan Nijtmans in

      cooperation with John Ellson.


      For a complete description of this enhancement request, see:


      http://www.scriptics.com/live/showurl?i=software%2epatches%2etk803&url=%2

      fpatches%2ftk8%2e0%2e3%2ftkTrig%2etxt


      The patch below is regenerated using Tk8.1b2, but further on nothing

      changed.


  Patch:

  *** generic/tk.decls.origThu Mar 18 10:55:55 1999

  --- generic/tk.declsThu Mar 18 10:59:26 1999

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

  *** 1035,1040 ****

  --- 1035,1043 ----

        Tk_SavedOptions *savePtr, int *maskPtr)

    }


  + declare 215 generic {

  +     void  Tk_CreateSmoothMethod (Tcl_Interp *interp, Tk_SmoothMethod *method)

  + }


    # Define the platform specific public Tk interface.  These functions are

    # only available on the designated platform.

  *** generic/tk.h.origThu Mar 18 08:31:56 1999

  --- generic/tk.hThu Mar 18 10:55:11 1999

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

  *** 765,770 ****

  --- 765,780 ----

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

     */


  + typedef struct Tk_SmoothMethod {

  +     char *name;

  +     int (*coordProc) _ANSI_ARGS_((Tk_Canvas canvas,

  + double *pointPtr, int numPoints, int numSteps,

  + XPoint xPoints[], double dblPoints[]));

  +     void (*postscriptProc) _ANSI_ARGS_((Tcl_Interp *interp,

  + Tk_Canvas canvas, double *coordPtr,

  + int numPoints, int numSteps));

  + } Tk_SmoothMethod;

  + 

    /*

     * For each item in a canvas widget there exists one record with

     * the following structure.  Each actual item is represented by

  *** generic/tkCanvLine.c.origThu Mar 18 08:31:57 1999

  --- generic/tkCanvLine.cThu Mar 18 11:24:23 1999

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

  *** 16,21 ****

  --- 16,22 ----

    #include <stdio.h>

    #include "tkInt.h"

    #include "tkPort.h"

  + #include "tkCanvas.h"


    /*

     * The structure below defines the record for each line item.

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

  *** 60,66 ****

     * point in line (PTS_IN_ARROW points, first

     * of which is tip).  Malloc'ed.  NULL means

     * no arrowhead at last point. */

  !     int smooth;/* Non-zero means draw line smoothed (i.e.

     * with Bezier splines). */

        int splineSteps;/* Number of steps in each spline segment. */

    } LineItem;

  --- 61,67 ----

     * point in line (PTS_IN_ARROW points, first

     * of which is tip).  Malloc'ed.  NULL means

     * no arrowhead at last point. */

  !     Tk_SmoothMethod *smooth;/* Non-zero means draw line smoothed (i.e.

     * with Bezier splines). */

        int splineSteps;/* Number of steps in each spline segment. */

    } LineItem;

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

  *** 125,130 ****

  --- 126,134 ----

    static Tk_CustomOption tagsOption = {Tk_CanvasTagsParseProc,

        Tk_CanvasTagsPrintProc, (ClientData) NULL

    };

  + static Tk_CustomOption smoothOption = {TkSmoothParseProc,

  +     TkSmoothPrintProc, (ClientData) NULL

  + };


    static Tk_ConfigSpec configSpecs[] = {

        {TK_CONFIG_UID, "-arrow", (char *) NULL, (char *) NULL,

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

  *** 138,145 ****

    "black", Tk_Offset(LineItem, fg), TK_CONFIG_NULL_OK},

        {TK_CONFIG_JOIN_STYLE, "-joinstyle", (char *) NULL, (char *) NULL,

    "round", Tk_Offset(LineItem, joinStyle), TK_CONFIG_DONT_SET_DEFAULT},

  !     {TK_CONFIG_BOOLEAN, "-smooth", (char *) NULL, (char *) NULL,

  ! "0", Tk_Offset(LineItem, smooth), TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_INT, "-splinesteps", (char *) NULL, (char *) NULL,

    "12", Tk_Offset(LineItem, splineSteps), TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_BITMAP, "-stipple", (char *) NULL, (char *) NULL,

  --- 142,150 ----

    "black", Tk_Offset(LineItem, fg), TK_CONFIG_NULL_OK},

        {TK_CONFIG_JOIN_STYLE, "-joinstyle", (char *) NULL, (char *) NULL,

    "round", Tk_Offset(LineItem, joinStyle), TK_CONFIG_DONT_SET_DEFAULT},

  !     {TK_CONFIG_CUSTOM, "-smooth", (char *) NULL, (char *) NULL,

  ! "0", Tk_Offset(LineItem, smooth),

  ! TK_CONFIG_DONT_SET_DEFAULT, &smoothOption},

        {TK_CONFIG_INT, "-splinesteps", (char *) NULL, (char *) NULL,

    "12", Tk_Offset(LineItem, splineSteps), TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_BITMAP, "-stipple", (char *) NULL, (char *) NULL,

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

  *** 250,256 ****

        linePtr->arrowShapeC = (float)3.0;

        linePtr->firstArrowPtr = NULL;

        linePtr->lastArrowPtr = NULL;

  !     linePtr->smooth = 0;

        linePtr->splineSteps = 12;


        /*

  --- 255,261 ----

        linePtr->arrowShapeC = (float)3.0;

        linePtr->firstArrowPtr = NULL;

        linePtr->lastArrowPtr = NULL;

  !     linePtr->smooth = (Tk_SmoothMethod *) NULL;

        linePtr->splineSteps = 12;


        /*

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

  *** 715,721 ****

         */


        if ((linePtr->smooth) && (linePtr->numPoints > 2)) {

  ! numPoints = 1 + linePtr->numPoints*linePtr->splineSteps;

        } else {

    numPoints = linePtr->numPoints;

        }

  --- 720,728 ----

         */


        if ((linePtr->smooth) && (linePtr->numPoints > 2)) {

  ! numPoints = linePtr->smooth->coordProc(canvas, (double *) NULL,

  ! linePtr->numPoints, linePtr->splineSteps, (XPoint *) NULL,

  ! (double *) NULL);

        } else {

    numPoints = linePtr->numPoints;

        }

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

  *** 727,733 ****

        }


        if ((linePtr->smooth) && (linePtr->numPoints > 2)) {

  ! numPoints = TkMakeBezierCurve(canvas, linePtr->coordPtr,

    linePtr->numPoints, linePtr->splineSteps, pointPtr,

    (double *) NULL);

        } else {

  --- 734,740 ----

        }


        if ((linePtr->smooth) && (linePtr->numPoints > 2)) {

  ! numPoints = linePtr->smooth->coordProc(canvas, linePtr->coordPtr,

    linePtr->numPoints, linePtr->splineSteps, pointPtr,

    (double *) NULL);

        } else {

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

  *** 818,831 ****

         */


        if ((linePtr->smooth) && (linePtr->numPoints > 2)) {

  ! numPoints = 1 + linePtr->numPoints*linePtr->splineSteps;

    if (numPoints <= MAX_STATIC_POINTS) {

        linePoints = staticSpace;

    } else {

        linePoints = (double *) ckalloc((unsigned)

        (2*numPoints*sizeof(double)));

    }

  ! numPoints = TkMakeBezierCurve(canvas, linePtr->coordPtr,

    linePtr->numPoints, linePtr->splineSteps, (XPoint *) NULL,

    linePoints);

        } else {

  --- 825,840 ----

         */


        if ((linePtr->smooth) && (linePtr->numPoints > 2)) {

  ! numPoints = linePtr->smooth->coordProc(canvas, (double *) NULL,

  ! linePtr->numPoints, linePtr->splineSteps, (XPoint *) NULL,

  ! (double *) NULL);

    if (numPoints <= MAX_STATIC_POINTS) {

        linePoints = staticSpace;

    } else {

        linePoints = (double *) ckalloc((unsigned)

        (2*numPoints*sizeof(double)));

    }

  ! numPoints = linePtr->smooth->coordProc(canvas, linePtr->coordPtr,

    linePtr->numPoints, linePtr->splineSteps, (XPoint *) NULL,

    linePoints);

        } else {

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

  *** 1019,1032 ****

         */


        if ((linePtr->smooth) && (linePtr->numPoints > 2)) {

  ! numPoints = 1 + linePtr->numPoints*linePtr->splineSteps;

    if (numPoints <= MAX_STATIC_POINTS) {

        linePoints = staticSpace;

    } else {

        linePoints = (double *) ckalloc((unsigned)

        (2*numPoints*sizeof(double)));

    }

  ! numPoints = TkMakeBezierCurve(canvas, linePtr->coordPtr,

    linePtr->numPoints, linePtr->splineSteps, (XPoint *) NULL,

    linePoints);

        } else {

  --- 1028,1043 ----

         */


        if ((linePtr->smooth) && (linePtr->numPoints > 2)) {

  ! numPoints = linePtr->smooth->coordProc(canvas, (double *) NULL,

  ! linePtr->numPoints, linePtr->splineSteps, (XPoint *) NULL,

  ! (double *) NULL);

    if (numPoints <= MAX_STATIC_POINTS) {

        linePoints = staticSpace;

    } else {

        linePoints = (double *) ckalloc((unsigned)

        (2*numPoints*sizeof(double)));

    }

  ! numPoints = linePtr->smooth->coordProc(canvas, linePtr->coordPtr,

    linePtr->numPoints, linePtr->splineSteps, (XPoint *) NULL,

    linePoints);

        } else {

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

  *** 1487,1495 ****

        if ((!linePtr->smooth) || (linePtr->numPoints <= 2)) {

    Tk_CanvasPsPath(interp, canvas, linePtr->coordPtr, linePtr->numPoints);

        } else {

  ! if (linePtr->fillStipple == None) {

  !     TkMakeBezierPostscript(interp, canvas, linePtr->coordPtr,

  !     linePtr->numPoints);

    } else {

        /*

         * Special hack: Postscript printers don't appear to be able

  --- 1498,1506 ----

        if ((!linePtr->smooth) || (linePtr->numPoints <= 2)) {

    Tk_CanvasPsPath(interp, canvas, linePtr->coordPtr, linePtr->numPoints);

        } else {

  ! if ((linePtr->fillStipple == None) && linePtr->smooth->postscriptProc) {

  !     linePtr->smooth->postscriptProc(interp, canvas,

  !     linePtr->coordPtr, linePtr->numPoints, linePtr->splineSteps);

    } else {

        /*

         * Special hack: Postscript printers don't appear to be able

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

  *** 1504,1516 ****

        double *pointPtr;

        int numPoints;


  !     numPoints = 1 + linePtr->numPoints*linePtr->splineSteps;

        pointPtr = staticPoints;

        if (numPoints > MAX_STATIC_POINTS) {

    pointPtr = (double *) ckalloc((unsigned)

    (numPoints * 2 * sizeof(double)));

        }

  !     numPoints = TkMakeBezierCurve(canvas, linePtr->coordPtr,

        linePtr->numPoints, linePtr->splineSteps, (XPoint *) NULL,

        pointPtr);

        Tk_CanvasPsPath(interp, canvas, pointPtr, numPoints);

  --- 1515,1529 ----

        double *pointPtr;

        int numPoints;


  !     numPoints = linePtr->smooth->coordProc(canvas, (double *) NULL,

  !     linePtr->numPoints, linePtr->splineSteps, (XPoint *) NULL,

  !     (double *) NULL);

        pointPtr = staticPoints;

        if (numPoints > MAX_STATIC_POINTS) {

    pointPtr = (double *) ckalloc((unsigned)

    (numPoints * 2 * sizeof(double)));

        }

  !     numPoints = linePtr->smooth->coordProc(canvas, linePtr->coordPtr,

        linePtr->numPoints, linePtr->splineSteps, (XPoint *) NULL,

        pointPtr);

        Tk_CanvasPsPath(interp, canvas, pointPtr, numPoints);

  *** generic/tkCanvPoly.c.origThu Mar 18 08:31:57 1999

  --- generic/tkCanvPoly.cThu Mar 18 11:25:00 1999

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

  *** 15,20 ****

  --- 15,21 ----

    #include <stdio.h>

    #include "tkInt.h"

    #include "tkPort.h"

  + #include "tkCanvas.h"


    /*

     * The structure below defines the record for each polygon item.

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

  *** 37,43 ****

        XColor *fillColor;/* Foreground color for polygon. */

        Pixmap fillStipple;/* Stipple bitmap for filling polygon. */

        GC fillGC;/* Graphics context for filling polygon. */

  !     int smooth;/* Non-zero means draw shape smoothed (i.e.

     * with Bezier splines). */

        int splineSteps;/* Number of steps in each spline segment. */

        int autoClosed;/* Zero means the given polygon was closed,

  --- 38,44 ----

        XColor *fillColor;/* Foreground color for polygon. */

        Pixmap fillStipple;/* Stipple bitmap for filling polygon. */

        GC fillGC;/* Graphics context for filling polygon. */

  !     Tk_SmoothMethod *smooth;/* Non-zero means draw shape smoothed (i.e.

     * with Bezier splines). */

        int splineSteps;/* Number of steps in each spline segment. */

        int autoClosed;/* Zero means the given polygon was closed,

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

  *** 48,53 ****

  --- 49,57 ----

     * Information used for parsing configuration specs:

     */


  + static Tk_CustomOption smoothOption = {TkSmoothParseProc,

  +     TkSmoothPrintProc, (ClientData) NULL

  + };

    static Tk_CustomOption tagsOption = {Tk_CanvasTagsParseProc,

        Tk_CanvasTagsPrintProc, (ClientData) NULL

    };

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

  *** 57,64 ****

    "black", Tk_Offset(PolygonItem, fillColor), TK_CONFIG_NULL_OK},

        {TK_CONFIG_COLOR, "-outline", (char *) NULL, (char *) NULL,

    (char *) NULL, Tk_Offset(PolygonItem, outlineColor), TK_CONFIG_NULL_OK},

  !     {TK_CONFIG_BOOLEAN, "-smooth", (char *) NULL, (char *) NULL,

  ! "0", Tk_Offset(PolygonItem, smooth), TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_INT, "-splinesteps", (char *) NULL, (char *) NULL,

    "12", Tk_Offset(PolygonItem, splineSteps), TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_BITMAP, "-stipple", (char *) NULL, (char *) NULL,

  --- 61,69 ----

    "black", Tk_Offset(PolygonItem, fillColor), TK_CONFIG_NULL_OK},

        {TK_CONFIG_COLOR, "-outline", (char *) NULL, (char *) NULL,

    (char *) NULL, Tk_Offset(PolygonItem, outlineColor), TK_CONFIG_NULL_OK},

  !     {TK_CONFIG_CUSTOM, "-smooth", (char *) NULL, (char *) NULL,

  ! "0", Tk_Offset(PolygonItem, smooth),

  ! TK_CONFIG_DONT_SET_DEFAULT, &smoothOption},

        {TK_CONFIG_INT, "-splinesteps", (char *) NULL, (char *) NULL,

    "12", Tk_Offset(PolygonItem, splineSteps), TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_BITMAP, "-stipple", (char *) NULL, (char *) NULL,

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

  *** 194,200 ****

        polyPtr->fillColor = NULL;

        polyPtr->fillStipple = None;

        polyPtr->fillGC = None;

  !     polyPtr->smooth = 0;

        polyPtr->splineSteps = 12;

        polyPtr->autoClosed = 0;


  --- 199,205 ----

        polyPtr->fillColor = NULL;

        polyPtr->fillStipple = None;

        polyPtr->fillGC = None;

  !     polyPtr->smooth = (Tk_SmoothMethod *) NULL;

        polyPtr->splineSteps = 12;

        polyPtr->autoClosed = 0;


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

  *** 637,650 ****

     * spline points rather than the original points.

     */


  ! numPoints = 1 + polyPtr->numPoints*polyPtr->splineSteps;

    if (numPoints <= MAX_STATIC_POINTS) {

        pointPtr = staticPoints;

    } else {

        pointPtr = (XPoint *) ckalloc((unsigned)

        (numPoints * sizeof(XPoint)));

    }

  ! numPoints = TkMakeBezierCurve(canvas, polyPtr->coordPtr,

    polyPtr->numPoints, polyPtr->splineSteps, pointPtr,

    (double *) NULL);

    if (polyPtr->fillGC != None) {

  --- 642,657 ----

     * spline points rather than the original points.

     */


  ! numPoints = polyPtr->smooth->coordProc(canvas, (double *) NULL,

  ! polyPtr->numPoints, polyPtr->splineSteps, (XPoint *) NULL,

  ! (double *) NULL);

    if (numPoints <= MAX_STATIC_POINTS) {

        pointPtr = staticPoints;

    } else {

        pointPtr = (XPoint *) ckalloc((unsigned)

        (numPoints * sizeof(XPoint)));

    }

  ! numPoints = polyPtr->smooth->coordProc(canvas, polyPtr->coordPtr,

    polyPtr->numPoints, polyPtr->splineSteps, pointPtr,

    (double *) NULL);

    if (polyPtr->fillGC != None) {

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

  *** 705,718 ****

     * for comparison.

     */


  ! numPoints = 1 + polyPtr->numPoints*polyPtr->splineSteps;

    if (numPoints <= MAX_STATIC_POINTS) {

        coordPtr = staticSpace;

    } else {

        coordPtr = (double *) ckalloc((unsigned)

        (2*numPoints*sizeof(double)));

    }

  ! numPoints = TkMakeBezierCurve(canvas, polyPtr->coordPtr,

    polyPtr->numPoints, polyPtr->splineSteps, (XPoint *) NULL,

    coordPtr);

    distance = TkPolygonToPoint(coordPtr, numPoints, pointPtr);

  --- 712,727 ----

     * for comparison.

     */


  ! numPoints = polyPtr->smooth->coordProc(canvas, (double *) NULL,

  ! polyPtr->numPoints, polyPtr->splineSteps, (XPoint *) NULL,

  ! (double *) NULL);

    if (numPoints <= MAX_STATIC_POINTS) {

        coordPtr = staticSpace;

    } else {

        coordPtr = (double *) ckalloc((unsigned)

        (2*numPoints*sizeof(double)));

    }

  ! numPoints = polyPtr->smooth->coordProc(canvas, polyPtr->coordPtr,

    polyPtr->numPoints, polyPtr->splineSteps, (XPoint *) NULL,

    coordPtr);

    distance = TkPolygonToPoint(coordPtr, numPoints, pointPtr);

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

  *** 769,782 ****

         */


        if (polyPtr->smooth) {

  ! numPoints = 1 + polyPtr->numPoints*polyPtr->splineSteps;

    if (numPoints <= MAX_STATIC_POINTS) {

        coordPtr = staticSpace;

    } else {

        coordPtr = (double *) ckalloc((unsigned)

        (2*numPoints*sizeof(double)));

    }

  ! numPoints = TkMakeBezierCurve(canvas, polyPtr->coordPtr,

    polyPtr->numPoints, polyPtr->splineSteps, (XPoint *) NULL,

    coordPtr);

        } else {

  --- 778,793 ----

         */


        if (polyPtr->smooth) {

  ! numPoints = polyPtr->smooth->coordProc(canvas, (double *) NULL,

  ! polyPtr->numPoints, polyPtr->splineSteps, (XPoint *) NULL,

  ! (double *) NULL);

    if (numPoints <= MAX_STATIC_POINTS) {

        coordPtr = staticSpace;

    } else {

        coordPtr = (double *) ckalloc((unsigned)

        (2*numPoints*sizeof(double)));

    }

  ! numPoints = polyPtr->smooth->coordProc(canvas, polyPtr->coordPtr,

    polyPtr->numPoints, polyPtr->splineSteps, (XPoint *) NULL,

    coordPtr);

        } else {

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

  *** 947,958 ****

         */


        if (polyPtr->fillColor != NULL) {

  ! if (!polyPtr->smooth) {

        Tk_CanvasPsPath(interp, canvas, polyPtr->coordPtr,

        polyPtr->numPoints);

    } else {

  !     TkMakeBezierPostscript(interp, canvas, polyPtr->coordPtr,

  !     polyPtr->numPoints);

    }

    if (Tk_CanvasPsColor(interp, canvas, polyPtr->fillColor) != TCL_OK) {

        return TCL_ERROR;

  --- 958,969 ----

         */


        if (polyPtr->fillColor != NULL) {

  ! if (!polyPtr->smooth || !polyPtr->smooth->postscriptProc) {

        Tk_CanvasPsPath(interp, canvas, polyPtr->coordPtr,

        polyPtr->numPoints);

    } else {

  !     polyPtr->smooth->postscriptProc(interp, canvas, polyPtr->coordPtr,

  !     polyPtr->numPoints, polyPtr->splineSteps);

    }

    if (Tk_CanvasPsColor(interp, canvas, polyPtr->fillColor) != TCL_OK) {

        return TCL_ERROR;

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

  *** 978,989 ****

        if (polyPtr->outlineColor != NULL) {

    char string[32 + TCL_INTEGER_SPACE];


  ! if (!polyPtr->smooth) {

        Tk_CanvasPsPath(interp, canvas, polyPtr->coordPtr,

    polyPtr->numPoints);

    } else {

  !     TkMakeBezierPostscript(interp, canvas, polyPtr->coordPtr,

  ! polyPtr->numPoints);

    }


    sprintf(string, "%d setlinewidth\n", polyPtr->width);

  --- 989,1000 ----

        if (polyPtr->outlineColor != NULL) {

    char string[32 + TCL_INTEGER_SPACE];


  ! if (!polyPtr->smooth || !polyPtr->smooth->postscriptProc) {

        Tk_CanvasPsPath(interp, canvas, polyPtr->coordPtr,

    polyPtr->numPoints);

    } else {

  !     polyPtr->smooth->postscriptProc(interp, canvas, polyPtr->coordPtr,

  ! polyPtr->numPoints, polyPtr->splineSteps);

    }


    sprintf(string, "%d setlinewidth\n", polyPtr->width);

  *** generic/tkCanvas.h.origThu Mar 18 11:14:44 1999

  --- generic/tkCanvas.hThu Mar 18 11:13:13 1999

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

  *** 255,259 ****

  --- 255,265 ----


    extern intTkCanvPostscriptCmd _ANSI_ARGS_((TkCanvas *canvasPtr,

        Tcl_Interp *interp, int argc, char **argv));

  + extern intTkSmoothParseProc _ANSI_ARGS_((ClientData clientData,

  +     Tcl_Interp *interp, Tk_Window tkwin,

  +     char *value, char *recordPtr, int offset));

  + extern char *TkSmoothPrintProc _ANSI_ARGS_((ClientData clientData,

  +     Tk_Window tkwin, char *recordPtr, int offset,

  +     Tcl_FreeProc **freeProcPtr));


    #endif /* _TKCANVAS */

  *** generic/tkDecls.h.origThu Mar 18 11:00:18 1999

  --- generic/tkDecls.hThu Mar 18 11:05:22 1999

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

  *** 742,747 ****

  --- 742,751 ----

    int objc, Tcl_Obj *CONST objv[], 

    Tk_Window tkwin, Tk_SavedOptions * savePtr, 

    int * maskPtr));

  + /* 215 */

  + EXTERN voidTk_CreateSmoothMethod _ANSI_ARGS_((

  + Tcl_Interp * interp, 

  + Tk_SmoothMethod * method));


    typedef struct TkStubHooks {

        struct TkPlatStubs *tkPlatStubs;

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

  *** 969,974 ****

  --- 973,979 ----

        void (*tk_MainEx) _ANSI_ARGS_((int argc, char ** argv, Tcl_AppInitProc * appInitProc, Tcl_Interp * interp)); /* 212 */

        void (*tk_RestoreSavedOptions) _ANSI_ARGS_((Tk_SavedOptions * savePtr)); /* 213 */

        int (*tk_SetOptions) _ANSI_ARGS_((Tcl_Interp * interp, char * recordPtr, Tk_OptionTable optionTable, int objc, Tcl_Obj *CONST objv[], Tk_Window tkwin, Tk_SavedOptions * savePtr, int * maskPtr)); /* 214 */

  +     void (*tk_CreateSmoothMethod) _ANSI_ARGS_((Tcl_Interp * interp, Tk_SmoothMethod * method)); /* 215 */

    } TkStubs;


    extern TkStubs *tkStubsPtr;

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

  *** 1838,1843 ****

  --- 1843,1852 ----

    #ifndef Tk_SetOptions

    #define Tk_SetOptions(interp, recordPtr, optionTable, objc, objv, tkwin, savePtr, maskPtr) \

    (tkStubsPtr->tk_SetOptions)(interp, recordPtr, optionTable, objc, objv, tkwin, savePtr, maskPtr) /* 214 */

  + #endif

  + #ifndef Tk_CreateSmoothMethod

  + #define Tk_CreateSmoothMethod(interp, method) \

  + (tkStubsPtr->tk_CreateSmoothMethod)(interp, method) /* 215 */

    #endif


    #endif /* defined(USE_TK_STUBS) && !defined(USE_TK_STUB_PROCS) */

  *** generic/tkInt.decls.origThu Mar 18 11:00:03 1999

  --- generic/tkInt.declsThu Mar 18 11:01:57 1999

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

  *** 254,260 ****


    declare 50 generic {

        void TkMakeBezierPostscript (Tcl_Interp *interp, \

  !     Tk_Canvas canvas, double *pointPtr, int numPoints)

    }


    declare 51 generic {

  --- 254,260 ----


    declare 50 generic {

        void TkMakeBezierPostscript (Tcl_Interp *interp, \

  !     Tk_Canvas canvas, double *pointPtr, int numPoints, int numSteps)

    }


    declare 51 generic {

  *** generic/tkIntDecls.h.origThu Mar 18 11:00:12 1999

  --- generic/tkIntDecls.hThu Mar 18 11:05:27 1999

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

  *** 194,200 ****

    /* 50 */

    EXTERN voidTkMakeBezierPostscript _ANSI_ARGS_((

    Tcl_Interp * interp, Tk_Canvas canvas, 

  ! double * pointPtr, int numPoints));

    /* 51 */

    EXTERN voidTkOptionClassChanged _ANSI_ARGS_((TkWindow * winPtr));

    /* 52 */

  --- 194,201 ----

    /* 50 */

    EXTERN voidTkMakeBezierPostscript _ANSI_ARGS_((

    Tcl_Interp * interp, Tk_Canvas canvas, 

  ! double * pointPtr, int numPoints, 

  ! int numSteps));

    /* 51 */

    EXTERN voidTkOptionClassChanged _ANSI_ARGS_((TkWindow * winPtr));

    /* 52 */

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

  *** 425,431 ****

        int (*tkLineToArea) _ANSI_ARGS_((double end1Ptr[], double end2Ptr[], double rectPtr[])); /* 47 */

        double (*tkLineToPoint) _ANSI_ARGS_((double end1Ptr[], double end2Ptr[], double pointPtr[])); /* 48 */

        int (*tkMakeBezierCurve) _ANSI_ARGS_((Tk_Canvas canvas, double * pointPtr, int numPoints, int numSteps, XPoint xPoints[], double dblPoints[])); /* 49 */

  !     void (*tkMakeBezierPostscript) _ANSI_ARGS_((Tcl_Interp * interp, Tk_Canvas canvas, double * pointPtr, int numPoints)); /* 50 */

        void (*tkOptionClassChanged) _ANSI_ARGS_((TkWindow * winPtr)); /* 51 */

        void (*tkOptionDeadWindow) _ANSI_ARGS_((TkWindow * winPtr)); /* 52 */

        int (*tkOvalToArea) _ANSI_ARGS_((double * ovalPtr, double * rectPtr)); /* 53 */

  --- 426,432 ----

        int (*tkLineToArea) _ANSI_ARGS_((double end1Ptr[], double end2Ptr[], double rectPtr[])); /* 47 */

        double (*tkLineToPoint) _ANSI_ARGS_((double end1Ptr[], double end2Ptr[], double pointPtr[])); /* 48 */

        int (*tkMakeBezierCurve) _ANSI_ARGS_((Tk_Canvas canvas, double * pointPtr, int numPoints, int numSteps, XPoint xPoints[], double dblPoints[])); /* 49 */

  !     void (*tkMakeBezierPostscript) _ANSI_ARGS_((Tcl_Interp * interp, Tk_Canvas canvas, double * pointPtr, int numPoints, int numSteps)); /* 50 */

        void (*tkOptionClassChanged) _ANSI_ARGS_((TkWindow * winPtr)); /* 51 */

        void (*tkOptionDeadWindow) _ANSI_ARGS_((TkWindow * winPtr)); /* 52 */

        int (*tkOvalToArea) _ANSI_ARGS_((double * ovalPtr, double * rectPtr)); /* 53 */

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

  *** 699,706 ****

    (tkIntStubsPtr->tkMakeBezierCurve)(canvas, pointPtr, numPoints, numSteps, xPoints, dblPoints) /* 49 */

    #endif

    #ifndef TkMakeBezierPostscript

  ! #define TkMakeBezierPostscript(interp, canvas, pointPtr, numPoints) \

  ! (tkIntStubsPtr->tkMakeBezierPostscript)(interp, canvas, pointPtr, numPoints) /* 50 */

    #endif

    #ifndef TkOptionClassChanged

    #define TkOptionClassChanged(winPtr) \

  --- 700,707 ----

    (tkIntStubsPtr->tkMakeBezierCurve)(canvas, pointPtr, numPoints, numSteps, xPoints, dblPoints) /* 49 */

    #endif

    #ifndef TkMakeBezierPostscript

  ! #define TkMakeBezierPostscript(interp, canvas, pointPtr, numPoints, numSteps) \

  ! (tkIntStubsPtr->tkMakeBezierPostscript)(interp, canvas, pointPtr, numPoints, numSteps) /* 50 */

    #endif

    #ifndef TkOptionClassChanged

    #define TkOptionClassChanged(winPtr) \

  *** generic/tkTrig.c.origThu Mar 18 08:32:06 1999

  --- generic/tkTrig.cThu Mar 18 10:55:12 1999

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

  *** 1060,1065 ****

  --- 1060,1073 ----

        int numCoords = numPoints*2;

        double control[8];


  +     if (!pointPtr) {

  + /* Of pointPtr == NULL, this function returns an upper limit.

  +  * of the array size to store the coordinates. This can be

  +  * used to allocate storage, before the actual coordinates

  +  * are calculated. */

  + return 1 + numPoints * numSteps;

  +     }

  + 

        /*

         * If the curve is a closed one then generate a special spline

         * that spans the last points and the first ones.  Otherwise

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

  *** 1204,1210 ****

     */


    void

  ! TkMakeBezierPostscript(interp, canvas, pointPtr, numPoints)

        Tcl_Interp *interp;/* Interpreter in whose result the

     * Postscript is to be stored. */

        Tk_Canvas canvas;/* Canvas widget for which the

  --- 1212,1218 ----

     */


    void

  ! TkMakeBezierPostscript(interp, canvas, pointPtr, numPoints, numSteps)

        Tcl_Interp *interp;/* Interpreter in whose result the

     * Postscript is to be stored. */

        Tk_Canvas canvas;/* Canvas widget for which the

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

  *** 1212,1217 ****

  --- 1220,1226 ----

        double *pointPtr;/* Array of input coordinates:  x0,

     * y0, x1, y1, etc.. */

        int numPoints;/* Number of points at pointPtr. */

  +     int numSteps;/* Not used */

    {

        int closed, i;

        int numCoords = numPoints*2;

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

  *** 1465,1467 ****

  --- 1474,1675 ----

    }

        }

    }

  + 

  + 

  + /*

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

  +  *

  +  * Tk_CreateSmoothMethod --

  +  *

  +  *This procedure is invoked to add additional values

  +  *for the "-smooth" option to the list.

  +  *

  +  * Results:

  +  *A standard Tcl return value.

  +  *

  +  * Side effects:

  +  *In the future "-smooth <name>" will be accepted as

  +  *smooth method for the line and polygon.

  +  *

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

  +  */

  + 

  + static Tk_SmoothMethod tkBezierSmoothMethod = {

  +     "1",

  +     TkMakeBezierCurve,

  +     TkMakeBezierPostscript,

  + };

  + 

  + static void SmoothMethodCleanupProc _ANSI_ARGS_((ClientData clientData,

  + Tcl_Interp *interp));

  + 

  + typedef struct SmoothAssocData {

  +     struct SmoothAssocData *nextPtr;/* pointer to next SmoothAssocData */

  +     Tk_SmoothMethod smooth;/* name and functions associated with this

  +  * option */

  + } SmoothAssocData;

  + 

  + void

  + Tk_CreateSmoothMethod(interp, smooth)

  +     Tcl_Interp *interp;

  +     Tk_SmoothMethod *smooth;

  + {

  +     SmoothAssocData *method, *typePtr2, *prevPtr, *ptr;

  +     method = (SmoothAssocData *) Tcl_GetAssocData(interp, "smoothMethod",

  +     (Tcl_InterpDeleteProc **) NULL);

  + 

  +     /*

  +      * If there's already a smooth method with the given name, remove it.

  +      */

  + 

  +     for (typePtr2 = method, prevPtr = NULL; typePtr2 != NULL;

  +     prevPtr = typePtr2, typePtr2 = typePtr2->nextPtr) {

  + if (!strcmp(typePtr2->smooth.name, smooth->name)) {

  +     if (prevPtr == NULL) {

  + method = typePtr2->nextPtr;

  +     } else {

  + prevPtr->nextPtr = typePtr2->nextPtr;

  +     }

  +     ckfree((char *) typePtr2);

  +     break;

  + }

  +     }

  +     ptr = (SmoothAssocData *) ckalloc(sizeof(SmoothAssocData));

  +     ptr->smooth.name = smooth->name;

  +     ptr->smooth.coordProc = smooth->coordProc;

  +     ptr->smooth.postscriptProc = smooth->postscriptProc;

  +     ptr->nextPtr = method;

  +     Tcl_SetAssocData(interp, "smoothMethod", SmoothMethodCleanupProc,

  + (ClientData) ptr);

  + }

  + 

  + /*

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

  +  *

  +  * SmoothMethodCleanupProc --

  +  *

  +  *This procedure is invoked whenever an interpreter is deleted

  +  *to cleanup the smooth methods.

  +  *

  +  * Results:

  +  *None.

  +  *

  +  * Side effects:

  +  *Smooth methods are removed.

  +  *

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

  +  */

  + 

  + static void

  + SmoothMethodCleanupProc(clientData, interp)

  +     ClientData clientData;/* Points to "smoothMethod" AssocData

  +  * for the interpreter. */

  +     Tcl_Interp *interp;/* Interpreter that is being deleted. */

  + {

  +     SmoothAssocData *ptr, *method = (SmoothAssocData *) clientData;

  + 

  +     while (method != NULL) {

  + method = (ptr = method)->nextPtr;

  + ckfree((char *) ptr);

  +     }

  + }

  + 

  + /*

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

  +  *

  +  * TkSmoothParseProc --

  +  *

  +  *This procedure is invoked during option processing to handle

  +  *the "-smooth" option.

  +  *

  +  * Results:

  +  *A standard Tcl return value.

  +  *

  +  * Side effects:

  +  *The smooth option for a given item gets replaced by the value

  +  *indicated in the value argument.

  +  *

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

  +  */

  + 

  + int

  + TkSmoothParseProc(clientData, interp, tkwin, value, widgRec, offset)

  +     ClientData clientData;/* some flags.*/

  +     Tcl_Interp *interp;/* Used for reporting errors. */

  +     Tk_Window tkwin;/* Window containing canvas widget. */

  +     char *value;/* Value of option. */

  +     char *widgRec;/* Pointer to record for item. */

  +     int offset;/* Offset into item. */

  + {

  +     register Tk_SmoothMethod **smoothPtr = (Tk_SmoothMethod **) (widgRec + offset);

  +     Tk_SmoothMethod *smooth = NULL;

  +     int b, length;

  +     SmoothAssocData *method;

  + 

  +     if(value == NULL || *value == 0) {

  + *smoothPtr = (Tk_SmoothMethod *) NULL;

  + return TCL_OK;

  +     }

  +     length = strlen(value);

  +     method = (SmoothAssocData *) Tcl_GetAssocData(interp, "smoothMethod",

  +     (Tcl_InterpDeleteProc **) NULL);

  +     while (method != (SmoothAssocData *) NULL) {

  + if (strncmp(value, method->smooth.name, length) == 0) {

  +     if (smooth != (Tk_SmoothMethod *) NULL) {

  + Tcl_AppendResult(interp, "ambigeous smooth method \"", value,

  + "\"", (char *) NULL);

  + return TCL_ERROR;

  +     }

  +     smooth = &method->smooth;

  + }

  + method = method->nextPtr;

  +     }

  +     if (smooth) {

  + *smoothPtr = smooth;

  + return TCL_OK;

  +     }

  + 

  +     if (Tcl_GetBoolean(interp, (char *) value, &b) != TCL_OK) {

  + return TCL_ERROR;

  +     }

  +     *smoothPtr = b ? &tkBezierSmoothMethod : (Tk_SmoothMethod*) NULL;

  +     return TCL_OK;

  + }

  + 

  + /*

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

  +  *

  +  * TkSmoothPrintProc --

  +  *

  +  *This procedure is invoked by the Tk configuration code

  +  *to produce a printable string for the "-smooth"

  +  *configuration option.

  +  *

  +  * Results:

  +  *The return value is a string describing the smooth option for

  +  *the item referred to by "widgRe


  PatchFiles:

      tkTrig.c tk.decls tkInt.decls tkCanvas.h tkCanvLine.c tkCanvPoly.c




      For a complete demonstration of this new feature, download and
      install the Tkspline extension (version 0.2). This extension can
      be downloaded from:
          http://www.tcltk.com/ftp/ellson/
      
      Currently, the Tkspline extension requires the dash-patch. But
      it would be nice if the Tk core had this functionality, preferably
      before the Tk8.1 release. It doesn't matter which slot is reserved
      for the function Tk_CreateSmoothMethod()  (I chose 215 because it
      is the first empty slot available). If Scriptics doesn't have
      enough time to evaluate it, I hope at least a slot is reserved
      for this function in the Stub table. Anyway, the dash-patch
      will continue to support Tkspline, no matter what happens.
      
  In 8.3b1 
  -- 12/13/1999 hobbs


