# ticket

tkt_uuid: 220914ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Duplicate
title:
  When a toplevel is grabbed, and the mouse pointer is not on top of the toplevel, the ButtonRelease event is lost

comment:
  OriginalBugID: 5381 Bug
  Version: 2.0b8
  SubmitDate: '2000-05-05'
  LastModified: '2000-09-03'
  Severity: LOW
  Status: UnAssn
  Submitter: kuchler
  ChangedBy: sven
  RelatedBugIDs: 4695 5310
  OS: All Windows


  In two different situations, when a toplevel has grab, and the mouse button
  (in this case mouse button 1) is pressed down, and then moved onto the
  windows desktop and released, the button release event is not sent to the
  window that has the grab.

  When doing a BWidget drag, if you drop onto the desktop, the button release
  is never sent to the toplevel that has the grab.  This means that the toplevel that you are dragging, continues to think you are dragging even
  though you released the mouse button.  Clicking a second time on the
  desktop will then drop the toplevel (make it disappear)

  The second situation is where you have a dialog with a grab that contains
  a ScrolledWindow with a text widget inside of it.  When the text in the
  text widget in the ScrolledWindow is selected and you continue the mouse
  drag off the text widget and onto the desktop before releasing the mouse
  button, and then move the mouse back up over the text widget, the text
  selection continues to change even though the mouse button has been
  released.  This is because no button release event was ever recieved by
  the toplevel.

  See the related bugs for more details.



  Probably can't be changed by Connect2.0 because this would require a
  patched core or new release of the core. 
  -- 05/05/2000 kuchler


tkt_uuid: 725941ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 7 High
foundin: obsolete: 8.5a4
resolution: Fixed
title: [puts] called from a thread on win doesn't go to the console
comment:
  % package require Thread
  2.5
  (bin) 5 % set t [thread::create {thread::wait}]
  756
  (bin) 6 % thread::send $t {puts "hi there"}
  can not find channel named "stdout"
  (bin) 7 % 


tkt_uuid: 220620ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: Tk does not build Windows help files
comment:
  OriginalBugID: 3542 RFE
  Version: 8.2.2
  SubmitDate: '1999-11-10'
  LastModified: '1999-12-08'
  Severity: LOW
  Status: Released
  Submitter: wart
  ChangedBy: wart
  OS: All Windows
  FixedDate: '1999-12-08'
  FixedInVersion: 8.3b1


  Neither Tcl nor Tk builds Windows .hlp files when "make install" is done.  Instead the user has to go into the "tools" directory of the source distribution and build them through another set of configure/make steps.

  Things would be much simpler if Tk had a "make doc" target that built the help files.



  Useful workaround:  Both Tcl and Tk now have a "winhelp" target in the Makefile that will produce these helpfiles.  The winhelp generated from Tcl contains only the Tcl-specific help pages.  The help generated from Tk contains both the Tcl and Tk help pages. 
  -- 12/08/1999 wart


tkt_uuid: 1571737fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: None
title: PRIMARY sel handlers and non-Latin-1 encodings
comment:
  Installing a custom PRIMARY selection handler for the
  STRING target on Text and Entry widgets don't work as
  expected: the characters in the pasted string get
  substituted by "?" (question marks) for both 8-bit and
  UTF-8 applications.

  The system is Linux/X11R6 with KOI8-R locale.
  Tcl 8.4.9/Tk 8.4.9

  The string that is tried to be returned from selection
  handlers is the Russian word "тест"
  (0xD4, 0xC5, 0xD3, 0xD4 in KOI8-R).

  All the test cases are typed into tkcon (freshly
  started for each test).

  I. Just setting a handler for PRIMARY/STRING:

  % text .t
  .t
  % selection handle .t sh
  % proc sh {args} {return тест}
  % selection own .t
  % encoding system
  koi8-r
  % selection get -type TARGETS
  MULTIPLE TARGETS TIMESTAMP TK_APPLICATION TK_WINDOW
  UTF8_STRING STRING

  Then, in other apps we get pasted
  ????
  (four question marks).

  While in the same tkcon we get "тест" pasted (what's
  expected).

  II. Just setting a handler for UTF8_STRING:

  % text .t
  .t
  % selection handle -type UTF8_STRING .t sh
  % proc sh {args} {return тест}
  % selection own .t
  % selection get -type TARGETS
  MULTIPLE TARGETS TIMESTAMP TK_APPLICATION TK_WINDOW
  UTF8_STRING STRING

  Then we get the same results as for the first case.

  III. Setting handler for STRING, but convert the text
  to KOI8-R:

  ...as before, but the handler is:
  % proc sh {args} {return [encoding convertto тест]}

  This pastes the correct string to any 8-bit apps,
  but some 4-character gibberish gets pasted to
  UTF-8-enabled programs:
  ÔÅÓÔ
  which are: \u00d4\u00c5\u00d3\u00d4
  That's just the codes of KOI8-R symbols of the source
  word "тест".

  IV: Clearing STRING handler first, then installing
  UTF8_STRING handler:

  % text .t
  .t
  % selection handle .t {}
  % selection handle -type UTF8_STRING .t sh
  % proc sh {args} {return тест}
  % selection own .t
  % selection get -type TARGETS
  MULTIPLE TARGETS TIMESTAMP TK_APPLICATION TK_WINDOW
  UTF8_STRING

  Then we get that "????" again in either koi8-r and
  utf-8 programs.

  IV. Clearing UTF8_STRING handler first, then installing
  the handler for STRING:

  % text .t
  .t
  % selection handle -type UTF8_STRING .t {}
  % selection own .t
  % selection get -type TARGETS
  MULTIPLE TARGETS TIMESTAMP TK_APPLICATION TK_WINDOW STRING
  % selection handle .t sh
  % proc sh {args} {return тест}
  % selection get -type TARGETS
  MULTIPLE TARGETS TIMESTAMP TK_APPLICATION TK_WINDOW
  UTF8_STRING STRING

  In this case we get the correct string pasted ("тест")
  in any application
  (so this works).


tkt_uuid: 471727ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: TIP Implementation
resolution: Rejected
title: TIP 64 - Expose system, desktop fonts
comment:
  A follow-up to patch 461442 which was created by "nobody".

  This patch exposes all the fonts configurable in the 'Windows desktop 
  properties sheet as well as "defaultgui" which should be used for most
  user interface elements.  

  This patch does NOT (yet) address dynamic reconfiguration of fonts as
  described in the TIP.


tkt_uuid: 220543ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Must click twice on menus of inactive windows
comment:
  OriginalBugID: 2272 Bug
  Version: 8.0.4
  SubmitDate: '1999-06-21'
  LastModified: '2000-04-14'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '2000-04-14'
  FixedInVersion: 8.3.1


  Name:
  Brian Griffin

  CVS:
  core-8-0-4

  Extensions:
  Tix4.1, [incrTcl]3.0, gdi, printer

  CustomShell:
  Several.  Don't recall exactly which ones.

  Comments:
  This is a bug only for menus and not other Tk widgets because the menu
      is not under Tk's control.  By delaying the window activation, the mouse
      down event gets consumed by Tk and the Menu never sees it.  This can
      also be a problem with any other widgets that are implemented in the
      native form.
      
      The stated reason for delaying the window activation event is so that a
      test for active grabs can be done.  This must be done immediately
      otherwise the native widgets will not work correctly.

  ReproducibleScript:
  # Execute the following in wish
      # Try to select the Test (or Test2) menu in the inactive window
      # The first mouse click will activate the window, but will not activate
      the
      # menu.  The second mouse click will activate the menu.
      # Then try this same experiment with any non-Tk based Windows
      application.
      menu .mbar
      . configure -menu .mbar
      .mbar add cascade -label Test -menu .mbar.test
      menu .mbar.test
      .mbar.test add command -label Echo -command {puts test}
      toplevel .foo
      menu .foo.mbar
      .foo configure -menu .foo.mbar
      .foo.mbar add cascade -label Test2 -menu .foo.mbar.test2
      menu .foo.mbar.test2
      .foo.mbar.test2 add command -label Echo2 -command {puts test2}

  ObservedBehavior:
  This is a Windows only problem:
      Selecting a menu in an inactive Tk toplevel window requires two mouse
      clicks.  This is not the case for any other non-Tk based Windows
      application.

  DesiredBehavior:
  A single mouse click should both activate the window and select the
      menu.

  Patch:
  cvs diff tkWinWm.c      
  Index: tkWinWm.c
  ===================================================================
  RCS file: /cvsroot/tk/win/tkWinWm.c,v
  retrieving revision 1.5
  diff -r1.5 tkWinWm.c
  4007a4008,4012
  >               if (winPtr && (TkGrabState(winPtr) != TK_GRAB_EXCLUDED)) {
  >                       result = DefWindowProc(hwnd, message, wParam, lParam);
  >                       goto done;
  >               }
  > 
  4009,4010c4014,4015
  <            * Don't activate the window yet since there may be grabs
  <            * that should take precedence.  Instead we need to queue
  ---
  >            * Don't activate the window yet since there is a grab
  >            * that takes precedence.  Instead we need to queue

  PatchFiles:
  tkWinWm.c



  Although the patch line indicators point to the WM_CHITTEST
  message, this seems to work correctly when placed in the
  WM_MOUSEACTIVATE switch (which seem logical anyway).  Perhaps
  a blooper based on other changes in the file.

  This has been added for 8.3.1. 
  -- 04/14/2000 hobbs


tkt_uuid: 220568ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.2b1
resolution: Fixed
title: Syntax error in menu.tcl
comment:
  OriginalBugID: 2425 Bug
  Version: 8.2b1
  SubmitDate: '1999-07-21'
  LastModified: '1999-07-22'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: redman
  OS: Other
  Machine: NA
  FixedDate: '1999-07-22'


  Name:
  Jeffrey Hobbs

  Comments:
  This exists in 8.1.1 as well.

  ReproducibleScript:
  I am not able to reproduce this, but it is as reported by
      Michael Capito (mikec at tgf.tc.faa.gov) on c.l.tcl, and
      is an obvious syntax error.

  Patch:
  ib-service [~/src/tk8.2b1/library] 271 % diff -c menu.tcl~ menu.tcl
  *** menu.tcl~   Fri May  7 22:05:40 1999
  --- menu.tcl    Wed Jul 21 09:44:34 1999
  ***************
  *** 934,940 ****
                          [$child cget -underline]]
                  if {![string compare $char [string tolower $char2]]
                          || ![string compare $char ""]} {
  !                   if {[string compare [$child cget $i -state] "disabled"]} {
                          return $child
                      }
                  }
  --- 934,940 ----
                          [$child cget -underline]]
                  if {![string compare $char [string tolower $char2]]
                          || ![string compare $char ""]} {
  !                   if {[string compare [$child cget -state] "disabled"]} {
                          return $child
                      }
                  }

  PatchFiles:
  library/menu.tcl



  Applied patch, fixed in 8.2b2. 
  -- 07/22/1999 redman


tkt_uuid: 1954968fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: None
resolution: Invalid
title: [clipboard] takes selection ownership but has no lost event
comment:
  Using an example:

  % proc lostc {} {puts "Lost Clipboard"}
  % selection own -selection CLIPBOARD -command lostc .
  % clipboard append "."
  Lost Clipboard

  At this point the procedure lost is called.  But
  really the app still owns it, but now there's no
  way to trigger on the lost event.

  I'd like to propose a -command option to the clipboard
  command, which is identical to what selection -command does.   The first time clipboard takes ownership if
  the -command option is present, it is applied.

  Attached patch is a start.


tkt_uuid: 3607248fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: Patch for Aqua keyboard/mouse bindings
comment:
  The patch fixes these three bugs:

  1. Removal of duplicate <<ContextMenu>> binding for misconfigured X servers.

  2. Correction of typo - "Control" had been used in place of "Command" in a few places.

  3. Allowance for the perversity of Mac keyboard bindings:

  (a) The following events fire in response to the obvious keystrokes:

    <Control-Key-f>
    <Lock-Control-Key-F>
    <Shift-Control-Key-F>
    <Shift-Lock-Control-Key-F>

    <Command-Key-f>
    <Lock-Command-Key-F>
    <Shift-Command-Key-f>
    <Shift-Lock-Command-Key-f>

  (b) Commands can be bound to the following distinct events, but they never fire:

    <Control-Key-F>
    <Lock-Control-Key-f>
    <Shift-Control-Key-f>
    <Shift-Lock-Control-Key-f>

    <Command-Key-F>
    <Lock-Command-Key-f>
    <Shift-Command-Key-F>
    <Shift-Lock-Command-Key-F>

  The relevant bindings in tk.tcl have been corrected.  Some other bindings have been changed, although this is not strictly necessary: some bindings without "Shift" are sufficiently general to capture the intended event, but by adding "Shift" the intention of the command is clearer.


tkt_uuid: 959973ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Fixed
title: wm title bug
comment:
  At placed UTF-8 locale are incorrectly displayed
  non-Latin1 characters in titles of windows (wm title,
  wm iconname, etc.).


tkt_uuid: 1532273fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: core dump on HP-UX using [font measure]
comment:
  Hi *,

  all Tcl/Tk versions from 8.4.0 up to and including
  8.4.13 dump core on HP-UX 11.11 (11i v1) and 11.23 (11i
  v2) PARISC, when doing:

  % set fixed
  -adobe-courier-medium-r-normal--12-120-75-75-m-*-iso8859-1
  -adobe-courier-medium-r-normal--12-120-75-75-m-*-iso8859-1
  % font measure $fixed \u4e4e
  Bus error(coredump)

  In case that looks somewhat familiar to you, that is
  what happens in tk8.4/tests/entry.test between
  entry-2.5 and entry-3.1. Thus a "make test" for Tk
  always dumps core.

  Tcl and Tk where build from plain sources using CC="aCC
  -Ae +DAportable". The used aCC versions were

  HP-UX 11.11: HP ANSI C++ B3910B A.03.45
  HP-UX 11.23: HP ANSI C++ B3910B A.03.60

  The core (from 8.4.12 wish) itself stays here:

  #0  0x181fe8 in Tcl_UtfToUniChar (str=0x7f7f1b1c
  "\344\260\200\004", 
      chPtr=0x7f7f1b1f)
      at [...]/tcl8.4/unix/../generic/tclUtf.c:339
  339                 *chPtr = (Tcl_UniChar) (((byte &
  0x0F) << 12) 

  #1  0x128470 in UtfToUcs2beProc (clientData=0x0, 
      src=0x7f7f1b1c "\344\260\200\004", srcLen=3,
  flags=7, statePtr=0x7f7f1bb4, 
      dst=0x7f7f1b1f "\004", dstLen=14,
  srcReadPtr=0x7f7f1bb8, 
      dstWrotePtr=0x7f7f1bbc, dstCharsPtr=0x7f7f1bc0)
      at [...]/tk8.4/unix/tkUnixFont.c:616
  #2  0x143ff4 in Tcl_UtfToExternal (interp=0x0,
  encoding=0x4005baf8, 
      src=0x7f7f1b1c "\344\260\200\004", srcLen=3,
  flags=7, statePtr=0x7f7f1bb4, 
      dst=0x7f7f1b1f "\004", dstLen=14,
  srcReadPtr=0x7f7f1bb8, 
      dstWrotePtr=0x7f7f1bbc, dstCharsPtr=0x7f7f1bc0)
      at [...]/tcl8.4/unix/../generic/tclEncoding.c:1179
  #3  0x12af90 in FontMapLoadPage (subFontPtr=0x7f7f1a28,
  row=19)
      at [...]/tk8.4/unix/tkUnixFont.c:2095
  #4  0x12ac58 in FontMapLookup (subFontPtr=0x7f7f1a28,
  ch=20046)
      at [...]/tk8.4/unix/tkUnixFont.c:1985
  #5  0x12b8c0 in CanUseFallback (fontPtr=0x40086510, 
      faceName=0x40077468 "courier", ch=20046,
  fixSubFontPtrPtr=0x7f7f15cc)
      at [...]/tk8.4/unix/tkUnixFont.c:2429
  #6  0x12a8a4 in FindSubFontForChar (fontPtr=0x40086510,
  ch=20046, 
      fixSubFontPtrPtr=0x7f7f15cc)
      at [...]/tk8.4/unix/tkUnixFont.c:1858
  #7  0x128cc8 in Tk_MeasureChars (tkfont=0x40086510, 
      source=0x40075c70 "\344\271\216", numBytes=3,
  maxLength=-1, flags=0, 
      lengthPtr=0x7f7f1550)
      at [...]/tk8.4/unix/tkUnixFont.c:992
  #8  0x4c610 in Tk_TextWidth (tkfont=0x40086510, 
      string=0x40075c70 "\344\271\216", numBytes=3)
      at [...]/tk8.4/unix/../generic/tkFont.c:1722
  #9  0x4a86c in Tk_FontObjCmd (clientData=0x40059238,
  interp=0x4003ff70, 
      objc=4, objv=0x40040c24)
      at [...]/tk8.4/unix/../generic/tkFont.c:681
  #10 0x13b1f0 in TclEvalObjvInternal (interp=0x4003ff70,
  objc=4, 
      objv=0x40040c24, command=0x0, length=0, flags=0)
      at [...]/tcl8.4/unix/../generic/tclBasic.c:3085
  #11 0x1dde90 in TclExecuteByteCode (interp=0x4003ff70,
  codePtr=0x40077278)
      at [...]/tcl8.4/unix/../generic/tclExecute.c:1419
  #12 0x1dc920 in TclCompEvalObj (interp=0x4003ff70,
  objPtr=0x400406f8)
      at [...]/tcl8.4/unix/../generic/tclExecute.c:981
  #13 0x13cbe8 in Tcl_EvalObjEx (interp=0x4003ff70,
  objPtr=0x400406f8, 
      flags=131072)
      at [...]/tcl8.4/unix/../generic/tclBasic.c:4049
  #14 0x150078 in Tcl_RecordAndEvalObj
  (interp=0x4003ff70, cmdPtr=0x400406f8, 
      flags=131072)
      at [...]/tcl8.4/unix/../generic/tclHistory.c:142
  #15 0x14fe9c in Tcl_RecordAndEval (interp=0x4003ff70, 
      cmd=0x40046868 "font measure $fixed \\u4e4e\n",
  flags=131072)
      at [...]/tcl8.4/unix/../generic/tclHistory.c:62
  #16 0x33e18 in StdinProc (clientData=0x40066b10, mask=2)
      at [...]/tk8.4/unix/../generic/tkMain.c:368
  #17 0x15eb30 in Tcl_NotifyChannel (channel=0x40066b10,
  mask=2)
      at [...]/tcl8.4/unix/../generic/tclIO.c:6904
  #18 0x19515c in FileHandlerEventProc (evPtr=0x40060298,
  flags=-3)
      at [...]/tcl8.4/unix/tclUnixNotfy.c:633
  #19 0x1706d4 in Tcl_ServiceEvent (flags=-3)
      at [...]/tcl8.4/unix/../generic/tclNotify.c:640
  #20 0x170d54 in Tcl_DoOneEvent (flags=-3)
      at [...]/tcl8.4/unix/../generic/tclNotify.c:945
  #21 0x48890 in Tk_MainLoop ()
      at [...]/tk8.4/unix/../generic/tkEvent.c:1501
  #22 0x33c5c in Tk_MainEx (argc=-1, argv=0x7f7f07a8, 
      appInitProc=0x400383da <Tcl_AppInit>,
  interp=0x4003ff70)
      at [...]/tk8.4/unix/../generic/tkMain.c:297
  #23 0x33568 in main (argc=1, argv=0x7f7f07a4)
      at [...]/tk8.4/unix/tkAppInit.c:68

  I'll happily provide more information, do testing etc.
  - just let me know.

  kind regards -- Matthias Kraft


tkt_uuid: 1924761fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 8
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Accented characters appearing at the end of the line
comment:
  Whenever a Tcl/Tk program that has a text widget in it freezes, all input characters that have been typed with a dead key appear at the end of the line upon unfreezing of the program, regardless of where they were actually typed. Furthermore, all the characters that appear are equal to the last accented character typed.
  For example (assuming the acute and grave accents require dead keys for input): typing "déjà-vu" while the program is frozen, would result in "dj-vuàà" appearing upon unfreezing.

  I have reported this bug again since it appears that the previous bug cannot be updated.


tkt_uuid: 1094328fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Works For Me
title: initialization failure on amd64
comment:
  I tried running aMSN 0.94 and it immediately crashed  
  with this error:  
    
  (cronus)~> amsn  
  Application initialization failed: this isn't a Tk  
  applicationunknown color name "Black"  
  Error in startup script: can't invoke "wm" command:   
  application has been destroyed  
      while executing  
  "wm state . withdraw"  
      (file "/usr/bin/amsn" line 43)  
    
  Out of curiosity I ran wish interactively and got this:  
    
  (cronus)~> wish  
  Application initialization failed: this isn't a Tk  
  applicationunknown color name "Black"  
  % (cronus)~>  
    
    


tkt_uuid: 1919791fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: XIM reorganization and cleanup
comment:
  Attached patch reorganizes and attempts to streamline Tk's XIM processing.

  It does not (to my knowledge) fix any of the outstanding XIM-related bugs in Tk, but I'd like to get it into Tk 8.5.2 anyway in the hopes of making those easier to debug in future.


tkt_uuid: 1566418fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: pkgIndex.tcl needs Tcl version guard
comment:
  After installing Tk 8.5a5,
  when using Tcl 8.4 I see:

  error reading package index file
  /home/dgp/sparc/solaris2/lib/tk8.5/pkgIndex.tcl:
  expected version number but got "8.5a5"

  The installed pkgIndex.tcl file
  needs another guard line that older
  Tcl versions can eval without error:

  if {[package vcompare [package provide Tcl] 8.5] != 0}
  { return }


tkt_uuid: 1285983fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 44. Generic Fonts
priority: 6
foundin: None
resolution: None
title: Fix incorrect text height calculation
comment:
  Currently Tk_MeasureChars () calculate only the width of
  characters, and callers of that function
  (Tk_DrawTextLayout in tkFont.c and MeasureChars in
  tkTextDisp.c) assumes that the ascent and descent and the
  same as those of Tk_Font.  But, implementations of
  Tk_MeasureChars (e.g. in tkUnixRFont.c) may use different
  fonts (subfonts of Tk_Font).

  This leads to in incorrect text line height.

  My patch fixes this problem by introducing a new structure
  Tk_TextMetrics (members are ascent, descent, and width)
  and using a pointer to that structure instead of a pointer
  to (int).  Could you please consider this change?

  Once the patch is accepted, I'll post another patch (yet
  another implementation of tkUnixRfont) that utilizes the
  m17n-lib <http:/www.m17n.org/m17n-lib> to provide
  multilingual rendering facility to tk.  The attached image
  is an example of using that for rendering multilingual
  text by Tcl/Tk.

  The attached tar.gz file contains these files:

  tk.diff -- patch to the current CVS code of tk
  sample.png --  the sample image file mentioned above


tkt_uuid: 693512ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: make install fails with spaces in winhelp path
comment:
  After 'nmake -f makefile.vc TCLDIR=../../tcl8.4 
  winhelp', I try to install, and I get this:

  ..\library\msgs\ru.msg
  10 File(s) copied
          xcopy /i /y ".\Release\tk84.hlp" "C:\Program 
  Files\Tcl\doc\"
  .\Release\TK84.HLP
  1 File(s) copied
          xcopy /i /y ".\Release\tk84.cnt" "C:\Program 
  Files\Tcl\doc\"
  .\Release\tk84.cnt
  1 File(s) copied
          "..\..\tcl8.4\win\Release\tclsh84.exe" 
  C:\WINNT\Profiles\VinceD\LOCALS~1
  \Temp\nma00476.
  Installing tk's helpfile contents into Tcl's ...
  expected integer but got "a"
      while executing
  "open C:/Program Files/Tcl/doc/tcl84.cnt a"
      invoked from within
  "set f [open C:/Program Files/Tcl/doc/tcl84.cnt a]"
      (file "C:\WINNT\Profiles\VinceD\LOCALS~1
  \Temp\nma00476." line 16)
  NMAKE : fatal error U1077: '"..\..\tcl8.4
  \win\Release\tclsh84.exe"' : return cod
  e '0x1'
  Stop.


tkt_uuid: 1217762fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.4.10
resolution: Invalid
title: panedwindow geom manager bug when sash was moved
comment:
  I try to make a button visible at all times at the bottom 
  of a window containing a panedwindow with two panes 
  and a frame containing a button.

  When I resize the window by dragging its lower border, 
  everything seems to go well *if the sash was not moved 
  before*. Otherwise the button gets clipped.

  I read in the man panedwindow that the panedwindow 
  resizes its last pane to fill its allocated space, and this 
  is what's actually happening *only when the sash was 
  never moved before*. If the sash has been moved, then 
  the wm clips first the button and only after that it 
  resizes the last pane.

  I believe this is a bug of the geometry manager.

  Here is a snippet to reproduce:

  #########
  wm resizable . 1 1
  panedwindow .pw -orient vertical
  label .pw.x1 -text Upper -fg orange -bg black
  label .pw.x2 -text Lower -fg white -bg red
  .pw add .pw.x1 -minsize 150
  .pw add .pw.x2 -minsize 100
  pack .pw -fill both -expand yes
  frame .f
  button .f.b -text "hello!"
  pack .f.b
  pack .f
  update
  wm minsize . [winfo width .] [winfo height .]
  set initminh [lindex [wm minsize .] 1]
  bind . <Configure> { \
    set sashcoord [.pw sash coord 0];\
    set madedown [expr [lindex $sashcoord 1] - 154];\
    set newminheight [expr $initminh + $madedown];\
    wm minsize . 200 $newminheight; \
  }
  #########

  Run this in a wish session, and try to resize the 
  window -> the button is never clipped.

  Now move the sash down, then move it up, and try to 
  resize again -> the button gets clipped!!

  The geometry manager should first remove the extra 
  space in .pw.x2 before it clips the frame. I found no way 
  to manually set the height of .pw.x2

  Note that I use Tcl/Tk 8.4.10 (patch 1124198 is 
  therefore already in use).

  Francois


tkt_uuid: 220260ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Under Enlightenment, calls to 'raise toplevel' are very slow
comment:
  OriginalBugID: 3777 Bug
  Version: 8.3b1
  SubmitDate: '1999-12-06'
  LastModified: '2000-04-12'
  Severity: SER
  Status: Closed
  Submitter: key
  ChangedBy: ericm
  RelatedBugIDs: 2581 2478
  OS: Linux-Red Hat
  ClosedDate: '2000-04-12'


  steps to reproduce:
  1) Start wish
  2) type "toplevel .t"
  3) type "raise .t"

  expected result:
  command returns quickly

  actual result:
  command returns after about 2 seconds


  Scott Stanton, Jeff and I tracked this down to a problem in TkWmRestackToplevel in tkUnixWm.c.  Basically here's the problem:  that function wants to find the user-level window (ie, the thing with the window border/decorations).  To do this on most wm's, you can walk to the top of the x window hierarchy, then go down one.  In enlightenment, there is an extra "pseudo-root" window in place, so we get the wrong window.  This ultimately leads to a timeout in WaitForEvent when it is waiting for a configure event to come through.  The timeout is the cause of the slowness.

  Graphically, here's the hierarchy we are expecting:

  root
  user window
  application (tk)

  here's what we have:

  root
  enlightenment
  user window
  application

  Unfortunately, Scott says we can't just go up one from the application window either, because there may be intervening windows there as well.  So it seems that we need a better algorithm for finding the user window, but I don't know what that is.  Donal Fellows may have sent Jeff a partial patch that is Enlightenment specific, but it has not been examined at all.

  - eric

  -- 12/07/1999 ericm

  At long last we have determined that this is in fact an Enlightenment bug.  The version of Enlightenment installed with Redhat 6.0 is version 0.15.5, and it exhibits this bug.  On upgrading to the latest release of Enlightenment, 0.16.4, the problem went away.

  - eric

  -- 04/12/2000 ericm


tkt_uuid: 1275237fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 6
foundin: obsolete: 8.4.11
resolution: Fixed
title: modified flag not managed when undoing certain text inserts
comment:
  The modified flag of the text widget is not well managed 
  by Tk when certain changes are undone.

  Example 1 (works OK):
  text .t -undo 1
  pack .t
  .t insert 1.0 "Hello world!   "
  .t edit reset
  .t edit modified false
  .t insert 1.14 "Goodbye!"
  puts [.t edit modified]
  .t edit undo
  puts [.t edit modified]

  The output in the console is:
  1
  0
  which is correct: the modified flag has been reset to 
  false by the undo.

  Example 2 (wrong results):
  text .t -undo 1
  pack .t
  .t insert 1.0 "Hello world!   "
  .t edit reset
  .t edit modified false
  .t insert 1.14 ""
  puts [.t edit modified]
  .t edit undo
  puts [.t edit modified]

  The only difference is that instead of 
  inserting "Goodbye!" the script inserts an empty 
  string "".

  The output in the console is in this case:
  1
  1
  i.e. the modified flag was not reset by the undo 
  operation.

  The undo has been correctly performed since a further .t 
  edit undo spits:
  nothing to undo

  This problem therefore concerns only the modified flag.


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

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

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

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


  This probably means that tk wasn't installed properly.

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

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


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

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


  This probably means that tk wasn't installed properly.

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


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

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


  This probably means that tk wasn't installed properly.

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


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

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


  This probably means that tk wasn't installed properly.

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


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

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


  This probably means that tk wasn't installed properly.

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


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

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


  This probably means that tk wasn't installed properly.

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


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

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


  This probably means that tk wasn't installed properly.

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


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

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


  This probably means that tk wasn't installed properly.

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

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


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

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


  This probably means that tk wasn't installed properly.

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

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


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

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


  This probably means that tk wasn't installed properly.

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

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


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

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


  This probably means that tk wasn't installed properly.

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

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


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

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


  This probably means that tk wasn't installed properly.

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

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

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


tkt_uuid: 2900121fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 9 Immediate
foundin: obsolete: 8.6b1
resolution: Fixed
title: LineDeleteCoords has an inverted test
comment:
  In the LineDeleteCoords function, the test to decide whether or not to do an optimized refresh (TK_ITEM_DONT_REDRAW) is inverted. 
  It is currently:

    if ((first1 < 2) && (last1 >= length-2)) { don't redraw }

  it should read the converse:

    if (!(first1 < 2) && (last1 >= length-2))) { don't redraw }

  Note that this is not easy to exhibit in a script. But thanks to bug 2899685 (imove) it became conspicuous.

  Attaching the obvious patch. Prio9 because trivial.


tkt_uuid: 220955ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Fixed
title: Under AIX, configure --enable-gcc produces a nonworking Makf
comment:
  OriginalBugID: 6302 Bug
  Version: 8.3.2
  SubmitDate: '2000-09-22'
  LastModified: 
  Severity: CRIT
  Status: UnAssn
  Submitter: techsupp
  OS: AIX


  Comments:
  Sorry I'm not sending a better patch!

  ReproducibleScript:
  configure --enable-gcc

  ObservedBehavior:
  Using /bin/ld, libgcc.a isn't found.  Different compile options use
  -Wl,-b... while others use -b... - these two forms cannot be mixed

  DesiredBehavior:
  If --enable-gcc is supplied, /bin/ld should not be called, and all
  loader-specific flags should use the -Wl,-b form

  Patch:
  --- Makefile    Fri Sep 22 16:49:44 2000
  +++ Makefile.good       Fri Sep 22 16:52:56 2000
  @@ -204,7 +204,7 @@
   # libraries.  See configure.in for a description of what it means.
   # The values of the symbolis normally set by the configure script.

  -SHLIB_LD               = /usr/local/trilogy/download/src/tcltk/tcl8.3.2/unix/ldAix /bin/ld -bhalt:4 -bM:SRE -bE:lib.exp -H512 -T512 -bnoentry
  +SHLIB_LD               = /usr/local/trilogy/download/src/tcltk/tcl8.3.2/unix/ldAix $(CC) -Wl,-bhalt:4 -Wl,-bM:SRE -Wl,-bE:lib.exp -Wl,-H512 -Wl,-T512 -Wl,-bnoentry
   SHLIB_LD_LIBS          = ${LIBS}

   # Additional search flags needed to find the various shared libraries
  @@ -391,23 +391,23 @@

   wish: $(WISH_OBJS) $(TK_LIB_FILE) $(TK_STUB_LIB_FILE)
          $(CC)  $(WISH_OBJS)  -               -bI:/usr/local/trilogy/download/src/tcltk/tk8.3.2/unix/A.powerpc-ibm-aix4.3.3.0/lib.exp  +               -Wl,-bI:/usr/local/trilogy/download/src/tcltk/tk8.3.2/unix/A.powerpc-ibm-aix4.3.3.0/lib.exp  $(WISH_LIBS) $(TK_CC_SEARCH_FLAGS) -o wish

   # This rule is executed if the user tried to run tktest without first
   # building tcltest in the Tcl bin directory. Just do it for them.
   ${TCL_BIN_DIR}/tcltest:
          cd ${TCL_BIN_DIR} ;  -       make tcltest
  +       $(MAKE) tcltest

   tktest: ${TCL_BIN_DIR}/tcltest $(TKTEST_OBJS) $(TK_LIB_FILE)
          ${CC}  $(TKTEST_OBJS)  -               -bI:/usr/local/trilogy/download/src/tcltk/tk8.3.2/unix/A.powerpc-ibm-aix4.3.3.0/lib.exp  +               -Wl,-bI:/usr/local/trilogy/download/src/tcltk/tk8.3.2/unix/A.powerpc-ibm-aix4.3.3.0/lib.exp  $(WISH_LIBS) $(TK_CC_SEARCH_FLAGS) -o tktest

   xttest: test.o tkTest.o tkSquare.o $(TK_LIB_FILE)
          ${CC}  test.o tkTest.o tkSquare.o  -               -bI:/usr/local/trilogy/download/src/tcltk/tk8.3.2/unix/A.powerpc-ibm-aix4.3.3.0/lib.exp  +               -Wl,-bI:/usr/local/trilogy/download/src/tcltk/tk8.3.2/unix/A.powerpc-ibm-aix4.3.3.0/lib.exp  $(WISH_LIBS) $(TK_LD_SEARCH_FLAGS) -lXt -o xttest

   # Note, in the target below TCL_LIBRARY needs to be set or else

  PatchFiles:
  I suspect configure.in and Makfile.in


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: 703787ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: Tk 8.4.2 test on Solaris 7 unauthorizes DISPLAY :0.0
comment:
  Running on Solaris 7, using GCC 3.2.1 and Tcl/Tk 8.4.2,
  I can run quite a lot of tests, but then the DISPLAY is
  disabled so that neither Tk testing nor other
  applications (eg Netscape) can connect any more:


  tk.test
  unixButton.test
  unixEmbed.test
  Error in startup script: unexpected EOF from
  "/work4/open.source/Tcl/tk8.4.2/unix/tktest"
      while executing
  "error "unexpected EOF from \"[interpreter]\"""
      (procedure "setupbg" line 10)
      invoked from within
  "setupbg"
      (file
  "/work4/open.source/Tcl/tk8.4.2/tests/unixEmbed.test"
  line 18)
      invoked from within
  "::source
  /work4/open.source/Tcl/tk8.4.2/tests/unixEmbed.test"
      ("uplevel" body line 1)
      invoked from within
  "uplevel 1 [list ::source $file]"
      (procedure "tcltest::runAllTests" line 57)
      invoked from within
  "tcltest::runAllTests"
      (file
  "/work4/open.source/Tcl/tk8.4.2/unix/../tests/all.tcl"
  line 19)
  make: *** [test] Error 1


  ...let's try again...


  Anubis JL: make test
  TCL_LIBRARY=/work4/open.source/Tcl/tcl8.4.2/library;
  export TCL_LIBRARY; \
  TK_LIBRARY=/work4/open.source/Tcl/tk8.4.2/library;
  export TK_LIBRARY; \
  ./tktest
  /work4/open.source/Tcl/tk8.4.2/unix/../tests/all.tcl
  -geometry +0+0 \
   
  Xlib: connection to ":0.0" refused by server
  Xlib: Client is not authorized to connect to Server
  Application initialization failed: this isn't a Tk
  applicationcouldn't connect to display ":0.0"
  Tests running in interp: 
  /work4/open.source/Tcl/tk8.4.2/unix/tktest
  Tests located in:  /work4/open.source/Tcl/tk8.4.2/tests
  Tests running in:  /work4/open.source/Tcl/tk8.4.2/unix
  Temporary files stored in
  /work4/open.source/Tcl/tk8.4.2/unix
  Test files sourced into current interpreter
  ...

  I have to logout to get things back to normal again! 
  There's one minor failure earlier:

  listbox.test

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

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

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

  macEmbed.test


tkt_uuid: 915350ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 8
foundin: obsolete: 8.4.6
resolution: Fixed
title: Tk sets min, max size in WM_HINTS when it shouldn't
comment:
  (See also: http://bugs.kde.org/show_bug.cgi?id=67577)

  Problem: Tk toplevels always set the min_width,
  min_height, max_width, and max_height fields in the
  WM_NORMAL_HINTS property, even when the user has not
  called [wm minsize] or [wm maxsize].   

  The default minimum size is 1x1 (which is redundant),
  and the default maximum is taken from the size of the
  screen (which is not even correct in the context of
  multi-head displays). 

  This causes recent versions of KWM (and possibly other
  WMs) to disable maximization.  In any event, Tk
  shouldn't specify these fields unless explicitly
  instructed to.


tkt_uuid: 559437ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 64. Graphic Contexts
priority: 5 Medium
foundin: None
resolution: None
title: Fix for Bug 559435
comment:
  TkUnixFont.c: Tk_DrawChars doesn't handle non-ascii
  characters properly (esp. in the end of line). AFAIK,
  with this patch the problem is gone.


tkt_uuid: 3558535fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 9 Immediate
foundin: obsolete: 8.5.12
resolution: Fixed
title: Error when entering file pattern containing special chars
comment:
  In wish, execute
   tk_getOpenFile

  In "File name" type a pattern like "*.j[g" and hit enter.

  Expected behavior: Only files matching "*.j[g" are shown (if any such files exist)
  Actual behavior: "Application Error" "Error: missing close-bracket" and the contents of the file dialog are corrupted

  Note that this is also an opportunity to enter arbitrary Tcl code, like "*[exit]", which will be evaluated on hitting enter.


tkt_uuid: 1723622fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 8
foundin: obsolete: 8.5a6
resolution: Fixed
title: Tcl_InitStubs calls demand lockstep with Tcl
comment:
  All the Tcl_InitStubs() calls
  in the Tk HEAD look like this:

    Tcl_InitStubs(interp, TCL_PATCH_LEVEL, 1)

  Even ignoring the controversy over how
  -exact matching has been revised (Tcl
  Bug 1578344), this call results in too
  tight a demand for Tcl release compatibility.
  If no changes are made to the way the codes are currently written, we will one day compile some
  Tk source code against an 8.5.1 tcl.h file, and
  the resulting shared library will only be able
  to [load] into an interp in the range 8.5.1-8.5.2.
  In particular, this shared library would 
  not [load] into a Tcl 8.5.2 interp, which
  by tradition would be the next release of Tcl.

  The implication is that a Tk build is only
  good for a single release of Tcl, which
  means the use of stubs is pretty nearly
  pointless.

  I think the proper calls that would take
  advantage of the special provisions
  made for -exact matching ought to be:

    Tcl_InitStubs(interp, TCL_VERSION, 1)

  Combining that call with the special -exact
  matching rules would produce a shared library
  that will [load] into any Tcl 8.5* interp, which
  is the level of release compatibility we have
  supported between Tk and Tcl up to now.

  Feel free to drop in the chat if further
  discussion is needed to understand me.

  If it's really intended to lockdown each
  Tk release to exactly one Tcl release, we
  really ought to publicize that.  I'll
  try my best to talk you out of it.


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: 767176ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 8
foundin: obsolete: 8.4.3
resolution: Fixed
title: Bad winPtr->window pointer causes crash in Tk_GetHWND
comment:
  This is a somewhat obscure and intermitted crash,
  demonstrated by the attached script which requires
  Bryan Oakley's combobox implementation (demonstrated
  with version 2.2.1).  An access violation occurs when
  WmProc() in tkWinWm.c gets called with a WM_ACTIVATEAPP
  event.  This isn't in the switch so it goes on to get
  winPtr:

  winPtr = GetTopLevel(hwnd);

  Unfortunately, the value sometimes comes up bogus
  (filled with bad pointers and such) and when it
  subsequently calls Tk_GetHWND(winPtr), it crashes from
  winPtr->window being a bad pointer when attempting to
  get winPtr->window.handle.

  After lots of experimentation, I was able to cause the
  crash with a straight wish running the script (as
  opposed to the extended wish plus other Tcl code for my
  application, which originally seemed partly involved
  due to the intermittent nature of the crash) .

  For convenience I've made the buttons take up the huge
  area of the main toplevel (.), but that doesn't matter
  for demonstrating the crash -- it just keeps you from
  having to move the mouse around a bunch.  The crash
  does, however, seem to involve some of the geometry
  operations going on to center and size the various
  windows, combined with the combobox and the window
  icon.  Commenting out any one of these *seems* to stop
  the crash from happening, but since it's intermittent
  it is hard to be sure.  In case it matters, I'm also
  attaching the icon I'm using.

  To demonstrate, after launching the script, click the
  button that says "Combo".  A new toplevel will be
  created, centered on the screen, with a combobox in it.
   Close the window (click the [X] icon).  It seems to
  occur more often if you repeat this (click the "Combo"
  button, close the window that pops up) a couple times.
   Then click exit.  Often, but not always, this will
  crash (with an invalid page fault or an access
  violation depending on whether or not 
  you're running wish from within DevStudio).  After
  rebuilding wish with debugging symbols and running from
  DevStudio I was able to track the crash to the WmProc()
  and Tk_GetHWND().


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: 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: 219946ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: final: 8.0.5
resolution: Duplicate
title: Tk widgets do not work correctly if the filename is a reserved word
comment:
  OriginalBugID: 1566 Bug
  Version: 8.0.5
  SubmitDate: '1999-03-19'
  LastModified: '1999-09-13'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2691
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-09-13'


  From: Rolf Schroedter <Rolf.Schroedter@dlr.de>
  Newsgroups: comp.lang.tcl
  Subject: Re: Strange button.tcl bug?
  Date: Mon, 15 Mar 1999 10:35:34 +0100
  Organization: DLR, Inst.f.Planetenerkundung
  Message-ID: <36ECD466.2E25CAA9@dlr.de>
  References: <36EB1540.C550575C@mail.netanya.ac.il>

  This is a funny kind of bug that has already been reported 
  several times.

  Don't use 'reserved' filenames like "button.tcl", "menu.tcl",...
  Otherwise Tk's option data base will not be configured properly.

  The only conclusion for me is to use only nonsense filenames
  as "gnlfkr.tcl".

  Regards,
  Rolf.

  Samy Zafrany wrote:
  > 
  > I have handed my students a file called "button.tcl"
  > with the famous button example:
  > 
  >      button .b -text Hello -command {puts "Hello World!"}
  >      pack .b
  > ...
  > (Tcl is installed in c:\tcl on our college labs)
  > So at the DOS prompt we write
  >     D:\SOMEDIR\> wish button.tcl
  > A very starnge thing happened!
  > The button shows up ok, but when I enter the "Hello" button, I get the
  > following error message: "Error: unknown option -state".
  > 
  > I have renamed the "button.tcl" file to "but.tcl" and everything worked
  > fine!
  > This is ver strange to me!?!?! Can someone explain this weird behaviour?
  > 
  > I suspect it has to do with the c:\tcl\lib\tk8.0\button.tcl file
  > but I still don't see how.
  > Samy.


  The problem occurs when confusion arises over class names.
   A script takes the root filename of the script as the class
   name for the primary toplevel.  Tk will then tie that in
   to known classes when creating the toplevel, so a toplevel
   will try to be configured with class Radiobutton...  
  -- 09/13/1999 hobbs


tkt_uuid: 546910ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 06. Canvas PostScript
priority: 8
foundin: None
resolution: Accepted
title: International postscript output
comment:
  This patch enables postscript output for characters
  that are neither in latin1 nor in system encoding. It's
  based on Victor Wagner's patch (encoding vector
  generation for unibyte system encoding). With my patch,
  characters that are not  in system encoding are
  displayed using "glyphshow". It also works fine when
  system encoding is multibyte (e.g. *_*.UTF-8 locales)


tkt_uuid: 1083838fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 02. Appearance
priority: 6
foundin: obsolete: 8.5a3
resolution: Fixed
title: Selectcolor is on when checkbutton and radiobutton are off
comment:
  I'm using Tk 8.5.0.0 beta 3 in ActiveTcl on Linux (Mandrake 
  10.0), and I find that the -selectcolor option remains "on" even 
  when a checkbutton or radiobutton is "off." When the -foreground 
  and -selectcolor are both fairly dark colors, the little check or dot 
  in the indicator is hard to see. I can fix this by setting 
  -selectcolor to a light color when -foreground is dark, or vice 
  versa, but this isn't how it's supposed to work according to the 
  Tk 8.5 documentation. Of course, maybe only the 
  *documentation* needs to be changed, to say that "selectcolor" 
  now means the background color of the indicator, which displays 
  a check in the foreground color when the checkbutton is on? 


tkt_uuid: 2966299fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: Text Widget Tab key inserts wrong spacing
comment:
  in Text widget, using a monospace font like "courier new", after the first Tab width of a line, i.e. if Tab width is 8 characters then after the first 8 characters in a line, and/or you inserted characters equal or more than the tab width, no matter where you're standing if you insert a Tab and the preceding character was not a Tab the Tab spacing produced is a single space, this behaviour is not correct, if I'm standing exactly at the Tab width the spacing entered should be a full Tab's width not a single space, and if I am standing a character or more to the right of the Tab width a Tab should enter a spacing enough to make me stand at the next Tab Width of the Widget, this behavior can be proven to be wrong by being inconsistent with Vi, Vim, Emacs, Notepad, and even Firefox behavior, see the attached script for a live demonstration.
  this happens always on wish 8.5 and in wish 8.4 if you changed the tab width to the width of any no. of characters using the "font measure" command to acquire the width, I've included the second case in the demo with commented lines,


tkt_uuid: 1080205fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Invalid
title: libtk8.4 link on sparc solaris fails
comment:
  Something in the past 3 days has changed regarding the
  linking for  libtk - on sparc solaris today I get this
  on the cvs head:

  /usr/ccs/bin/ld -G -z text -o libtk8.5g.so  tk3d.o
  tkArgv.o tkAtom.o tkBind.o tk
  Bitmap.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o
  tkConsole.o tkCursor.o tkEr
  ror.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o
  tkGeometry.o tkGrab.o tkGrid.o
   tkMain.o tkObj.o tkOldConfig.o tkOption.o tkPack.o
  tkPlace.o tkSelect.o tkStyle
  .o tkUndo.o tkUtil.o tkVisual.o tkWindow.o tkUnix.o
  tkUnix3d.o tkUnixButton.o tk
  UnixColor.o tkUnixConfig.o tkUnixCursor.o tkUnixDraw.o
  tkUnixEmbed.o tkUnixEvent
  .o tkUnixFocus.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o
  tkUnixMenubu.o tkUnixScal
  e.o tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o
  tkUnixWm.o tkUnixXId.o tkStubInit
  .o tkStubLib.o tkUnixFont.o tkButton.o tkEntry.o
  tkFrame.o tkListbox.o tkMenu.o 
  tkMenubutton.o tkMenuDraw.o tkMessage.o tkPanedWindow.o
  tkScale.o tkScrollbar.o 
  tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o
  tkCanvLine.o tkCanvPoly.o tkCanv
  Ps.o tkCanvText.o tkCanvUtil.o tkCanvWind.o
  tkRectOval.o tkTrig.o tkImage.o tkIm
  gBmap.o tkImgGIF.o tkImgPPM.o tkImgPhoto.o tkText.o
  tkTextBTree.o tkTextDisp.o t
  kTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o
  tkTextWind.o -lpthread -L/us
  r/openwin/lib -lX11  -ldl  -lsocket -lpthread -lm
  -L/vol/tclsrcsol/tcl85/tcl/uni
  x -ltclstub8.5g  
  -Wl,-R,/volws/lwv28/ldatae/lib:/usr/openwin/lib
  /usr/ccs/bin/ld: illegal option -- W
  usage: ld
  [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?]
  file(s)


tkt_uuid: 1882011fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Fixed
title: reorder ttk_notebook man page
comment:
  The section labelled 'Identifiers' should appear before the 'Widget Command' section, since it defines the 'tabid' used by most of the widget commands.

  That would be consistent with e.g. the canvas man page which defines 'tagorid' before it is used.

  Clearly a show stopper. ;-)


tkt_uuid: 1851526fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 27. Objects
priority: 8
foundin: None
resolution: None
title: 8.5 breaks some Tkinter text widgets
comment:
  8.5 is causing the Tkinter EditorWindow class to break for some unknown reason.  When the user clicks <1> the event is delivered, but for some reason the Tk code isn't behaving properly.  Therefore you can't select text for copying and pasting.

  This is this code that seems to break with 8.5, and I'm not sure why yet:
  Python-2.5.1/Lib/idlelib/EditorWindow.py

  The same code works fine with Python 2.5.1 using Tcl/Tk 8.4.

  Here's what I've done so far:
  I've verified that the events are being delivered with this code:
  print(text.bind_class ("Text", "<1>", None, None)) 
  cmd = text.bind_class("Text", "<1>", None, None)
  cmd = 'puts TextB1;' + cmd
  text.bind_class ("Text", "<1>", cmd)

  I've gone hunting in various other places for the bug, with little success.

  You can run: /path/to/8.5/using/python EditorWindow.py 

  Whatever this bug is breaks IDLE (the standard Python editor that uses Tkinter).

  In a related note: they are using MacOSX private symbols, so it may already be broken on Mac OS X if those are MODULE_SCOPEd. Some sort of better cooperation is needed between the Tkinter and Tk developers.


tkt_uuid: 220861ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: None
resolution: Fixed
title: [image copy] doesn't handle transparent areas correctly
comment:
  OriginalBugID: 2658 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-10-22'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: RedHat 6.0
  Machine: Other


  Name:
  Q. Alex Zhao

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  Suppose there's an image "myImage" already loaded:
      canvas .c
      pack .c
      .c create image 100 100 -image myImage
      image create photo blankImage -width 100 -height 100
      blankImage blank
      myImage copy blankImage

  ObservedBehavior:
  Since "blankImage" is transparent, "myImage copy blankImage" should
      create a transparent hole in "myImage". But the actual result was that
      it created a BLACK hole.

  DesiredBehavior:
  Since "blankImage" is transparent, "myImage copy blankImage" should
      create a transparent hole in "myImage". But the actual result was that
      it created a BLACK hole.


tkt_uuid: 877950ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 9 Immediate
foundin: obsolete: 8.4.5
resolution: Fixed
title: wish crash using [image]
comment:
  The following code does not make much sense, but it
  crashes wish8.4.5 for me (on linux) if called with the
  attached gif.

  set image [image create photo]
  $image read $argv
  $image copy $image \
      -from 0 0 [image width $image] [image height $image] \
      -to [expr {[image width $image] / 2}] 0

  Expected behavior: tcl error msg or TCL_OK (with
  whatever sideeffect on the picture), not seg fault.

  Valgrind says:
  ==26779== Invalid read of size 1
  ==26779==    at 0x402E8115: Tk_PhotoPutBlock
  (/home/rolf/tcltk/tk8.4.5/generic/tkImgPhoto.c:4340)
  ==26779==    by 0x402E85B9: Tk_PhotoPutZoomedBlock
  (/home/rolf/tcltk/tk8.4.5/generic/tkImgPhoto.c:4542)
  ==26779==    by 0x402E1B50: ImgPhotoCmd
  (/home/rolf/tcltk/tk8.4.5/generic/tkImgPhoto.c:887)
  ==26779==    by 0x403480A2: TclEvalObjvInternal
  (../generic/tclBasic.c:3087)
  ==26779==    Address 0x42C6D027 is not stack'd,
  malloc'd or free'd
  ==26779== 
  etc.


tkt_uuid: 2957244fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 8
foundin: obsolete: 8.5.9
resolution: None
title: Tearoffs not showing for deep cascades
comment:
  Consider the following example:

  menu .main
  menu .main.submain
  menu .main.submain.subsub
  . configure -menu .main
  .main add cascade -label submain -menu .main.submain
  .main.submain add cascade -label subsub -menu .main.submain.subsub
  .main.submain.subsub add command -label subsubcmd -command {puts "subsubcmd executed"}

  Now open "subsub" cascade and tear it off - nothing happens. Well, not exactly, but it looks so - the torn-off menu is invisible.

  Try something different - first tear the "submain" off, and then tear the "subsub" off from it (not from the main window). This works as expected.

  It was the latest change in tearoff.tcl that causes it (2010-01-03  Pat Thoyts  <patthoyts@users.sourceforge.net> - "tearoff menus should be transient and use the toolwindow style on Windows").

  The attached patch contains a proposed fix for this.


tkt_uuid: 835832ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: None
title: tearoff menu add's should return index
comment:
  When I have code like this, I would like to be able to
  store the index number of particular options for later use.

      menu .mbar
      . config -menu .mbar

      .mbar add cascade -label "File" -underline 0 \
  -menu [menu .mbar.file -tearoff 0]
      .mbar add cascade -label "Help" -underline 0 \
  -menu [menu .mbar.help -tearoff 0]

      set m .mbar.file
      $m add command -label "Open Test Suite" -underline 0 \
  -command gui::opentestsuite

  This simple patch does what I need.  There is probably
  extra work/thinking to do to make sure that everything
  is consistent...


tkt_uuid: 2088597fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 16. [scrollbar]
priority: 9 Immediate
foundin: None
resolution: Accepted
title: minimum scrollbar slider length (Unix)
comment:
  The scrollbar slider has a minimum length, denoted by "MIN_SLIDER_LENGTH" in the scrollbar code.

  However, this miminum length is not honoured when the slider is right at the bottom, which makes it difficult to pick up with the mouse to drag it.

  I've attached a patch to fix this issue.


tkt_uuid: 3609681fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 99. Other
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: terminal loss of focus involving shortcuts and gitk/wish
comment:
  I recently reported this to gnome: https://bugzilla.gnome.org/show_bug.cgi?id=695561 . In some circumstances, when wish exits, keyboard events are no longer received/processed in the terminal window from which wish was started. (I described this as a "loss of focus", but I am not sure if window focus is the issue.)

  In gnome-shell, I can only reproduce with the wish application gitk. If I try to simplify gitk, the issue appears only sporadically (e.g. once in 10 times).

  But in fallback mode (gsettings set org.gnome.desktop.session
  session-name 'gnome-fallback') it can be reproduced easily and reliably by doing either one of:

  echo 'after idle { exit }' | wish
  echo 'bind . <Control-q> { exit }' | wish

  I failed to reproduce this with a small program doing XOpenDisplay, XCreateSimpleWIndow, XSelectInput, XMapWindow, XNextEvent, XCloseDisplay. What might Tk be doing differently?


tkt_uuid: 1032982fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: Add fullscreen wm state
comment:
  This patch implements a new fullscreen state for the
  wm state command. A TIP will be created for it very
  soon. Note that this patch currently applies to Windows
  only.


tkt_uuid: 853412ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Out of Date
title: scrolling incompatibilities
comment:
  [text] changes in the HEAD
  cause the arguments passed to
  the -yscrollcommand to have
  more precision than in prior Tk
  releases, and this can cause
  incompatibilities in existing scripts.

  One example is that AutoScroll
  detection is no longer working
  correctly in tkchat withTk 8.5.
  See tcllib Bug 849829.

  Whether the real bug is tkChat's
  or Tk 8.5's might need some
  more analysis, but if this change
  caught one script, it may well catch
  others.


tkt_uuid: 220650ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: Transient windows should not be mapped if they where withdrawn right after creation.
comment:
  OriginalBugID: 4019 Bug
  Version: 8.3b1
  SubmitDate: '2000-01-13'
  LastModified: '2000-01-17'
  Severity: MED
  Status: Released
  Submitter: sven
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-01-17'
  FixedInVersion: 8.3b2


  If I withdraw a window immediately after creating it, then setting it to be transient, the window will still get mapped.



  This was fixed in the 8.3b2 release such that the state of the
  transient was not effected at all by the transient call (we leave
  it to the wm to decide what to do). 
  -- 01/17/2000 hobbs


tkt_uuid: 3082049fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Fixed
title: Bracket typo in Makefile.in
comment:
  In file win/Makefile.in, line 706, there is opening parenthesis and closing brace.

  genstubs:
   $(TCL_EXE) "$(TCL_TOOL_DIR}\genStubs.tcl" \ 


tkt_uuid: 220651ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: Transient windows sometimes do not get iconfied with the master.
comment:
  OriginalBugID: 4020 Bug
  Version: 8.3b1
  SubmitDate: '2000-01-13'
  LastModified: '2000-01-26'
  Severity: SER
  Status: Released
  Submitter: sven
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-01-26'


  If the transient state is set before the master window was created internally (because I never entered the event loop), the transient window will not iconify when I iconify the master.



  The following test script was assumed from the description:
     toplevel .t;toplevel .t2;wm transient .t2 .t

  where then clicking on .t would not cause .t2 to disappear as well.
  This problem no longer exists as of CVS 26 Jan. 
  -- 01/26/2000 hobbs


tkt_uuid: 220927ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 5 Medium
foundin: obsolete: 8.4a1
resolution: Accepted
title: Value clipped on horizontal scale
comment:
  OriginalBugID: 5874 Bug
  Version: 8.4a1
  SubmitDate: '2000-06-12'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Windows NT


  Name:
  Bob Halpin

  ReproducibleScript:
  scale .s -sliderlength 8 -orient horizontal
  .s set 100
  pack .s

  ObservedBehavior:
  The scale's value display is clipped on the right when the scale value approaches the 'to' value
  and the sliderwidth is less than the width of the displayed digits (all depending on the font, of course.)

  DesiredBehavior:
  The value to be centered above the slider only untill it 'hits' the point past which it will be clipped.


tkt_uuid: 220719ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: scale -variable option does not create variable immediately
comment:
  OriginalBugID: 4833 Bug
  Version: 8.3
  SubmitDate: '2000-04-03'
  LastModified: '2000-04-14'
  Severity: MED
  Status: Released
  Submitter: ericm
  ChangedBy: hobbs
  OS: All Unix
  FixedDate: '2000-04-14'
  FixedInVersion: 8.3.1


  wish8.3
  % scale .s     
  .s
  % .s get
  0
  % .s configure -variable x
  % set x
  can't read "x": no such variable
  % 

  If a scale is configured to have a variable and the variable does not exist, it should be created with the current value of the scale.  If you pack the scale and then slide the slider, x will get set.

  - eric



  The scale widget got some rework with regard to variable handling
  in 8.3.1 to cover this case. 
  -- 04/14/2000 hobbs


tkt_uuid: 1358663fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 4
foundin: None
resolution: Fixed
title: wm geometry -x-y
comment:
  Specifying:

  wm geometry . -0-0

  is documented as placing the bottom right corner of the window at the 
  bottom right corner of the screen.

  Testing on Mac OSX 10.3.9, the beta 8.5 release from the ActiveState 
  site (info patchlevel shows 8.5a4) running under Wish, puts the window 
  off screen (-30-30 shows just the upper left corner of the window at 
  the bottom right portion of the screen).

  I noticed this in 8.4.9, probably always been this way.  I don't know if it 
  is Mac specific or more generic.

  Incidentally, the change to (I guess to make more consistent with other 
  platforms) make +0+0 put the content at the upper left corner of the 
  screen is a step backwards - it is almost NEVER what is intended, you 
  want the WINDOW to be there, including decorations.  This should be 
  changed on other platforms, not make it work incorrectly on the Mac.  
  If it is really intended to put the content there, then offsetting it by the 
  size of the window decoration (there is a way to find that out, right?) 
  makes more sense than to make everyone else do it backwards.


tkt_uuid: 220166ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_EventuallyFree API
comment:
  OriginalBugID: 1860 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-28'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: kenj
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-28'




  04/28/1999 14:00 - kenj - Former Tk function now incorporated in Tcl. Tcl API documented in the Tcl man pages. Tk usage deprecated.


tkt_uuid: 1023551fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: None
title: Add default right-button menu for entry and text widgets.
comment:
  Most modern GUI system have a convention that
  right-click of mouse on the widget brings up a menu
  with context-related operations on this widget.

  At least user expect Cut/Copy/Paste operations
  availible on such menu of any editable widget.

  Tk core doesn't provide such menus on entry and text
  widgets.

  Since incorporation of undo stack into core, undo and
  redo operations should be added into this menu as well.

  Attached file provides such bindings for Entry and Text
  bindtags along with code which enables and disables
  certain operation according to widget and system
  clipboard state.

  This file is a proper tcl package with namespace, but I
  think that this feature really should go into Tk core.


tkt_uuid: 220812ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.1b3
resolution: Remind
title: Docs missing for Tk_UpdatePointer API
comment:
  OriginalBugID: 1890 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-22'
  Severity: MED
  Status: Assigned
  Submitter: surles
  ChangedBy: hershey
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


tkt_uuid: 983920ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Accepted
title: tkEvent.c refactoring
comment:
  Tk_HandleEvent has been refactored to be easier to
  understand and maintain. 

  During this refactoring a bug was found by Joe English
  that would cause ClientMessage handlers to conflict
  with GenericHandlers in some cases.  

  Code was added to keep the TkDisplay in sync if the
  event involved button 4 or 5.

  No new test failures occur with this patch on my NetBSD
  system.


tkt_uuid: 1086917fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 8
foundin: obsolete: 8.4.9
resolution: Fixed
title: Segfault with .canvas create bitmap
comment:
  The original bugreport was submitted by Wolfgang Laun and
  was spotted in Perl/Tk. To reproduce the failure in Tcl/Tk,
  try:

      pack [canvas .c]
      .c create bitmap 100 100 -bitmap info -state disabled

  The patch (untested) 

  --- tkCanvBmap.c.oldWed Nov 24 11:13:10 2004
  +++ tkCanvBmap.cWed Dec 15 07:03:17 2004
  @@ -382,7 +382,7 @@
   }
       }
   
  -    if (state==TK_STATE_DISABLED || bitmap == None) {
  +    if (bitmap == None) {
   ComputeBitmapBbox(canvas, bmapPtr);
   return TCL_OK;
       }


  Regards,
      Slaven


tkt_uuid: 222027ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Works For Me
title: "event generate .myentry <KeyPress-bracketleft>" fails
comment:
  Some of the special keys don't work with event generate, e.g., backslash, brackets, braces, @, $ etc.

  Take a look at this code:

       console show
       entry .e
       pack .e
       focus -force .e
       update idle

       bind .e <KeyPress> {puts "keypress %K %k"}

       after 1000 {
           event generate .e <KeyPress-A>
           event generate .e <KeyRelease-A>
           event generate .e <KeyPress-bracketleft>
           event generate .e <KeyRelease-bracketleft>
           event generate .e <KeyPress-B>
           event generate .e <KeyRelease-B>
           event generate .e <KeyPress-greater>
           event generate .e <KeyRelease-greater>
           event generate .e <KeyPress-C>
           event generate .e <KeyRelease-C>
       }

  It produces "AB>C" - no bracketleft.

  Platform:
     tcl_platform(byteOrder) = littleEndian
     tcl_platform(machine)   = intel
     tcl_platform(os)        = Windows NT
     tcl_platform(osVersion) = 5.0
     tcl_platform(platform)  = windows
     tcl_patchLevel: 8.3.2

  See also thread on comp.lang.tcl on 2 November 2000.


tkt_uuid: 232741ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: put command corrupt (with -format and -to option)
comment:
  Bug report:
  ===========

  File "generic/tkImgPhoto.c", function "ImgPhotoCmd":

  "imageName put" command does not work correctly,
  when used in conjunction with "-format" and "-to" option.

  Bug fix:
  ========

  Line 966:
  0, 0, imageWidth, imageHeight, options.toX, options.toY)

  should be changed to:
  options.toX, options.toY, imageWidth, imageHeight, 0, 0)

  Applicable Tk versions:
  =======================

  Noticed this bug in tk8.3.2 as well as tk8.4a2.
  Seems to be introduced with the Img patch in 8.3.


tkt_uuid: 1597249fffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: None
title: TCL_PATCHLEVEL not set in Makefile.vc
comment:
  When using Makefile.vc to build Tk, package require Tk fails in a tclsh. I have built Tcl 8.5a6 and Tk 8.5a6 thus:

  Build Tcl

  nmake -f Makefile.vc OPTS=threads INSTALLDIR=c:\tcl
  nmake -f Makefile.vc OPTS=threads INSTALLDIR=c:\tcl install

  build Tk
  nmake -f Makefile.vc OPTS=threads INSTALLDIR=c:\tcl TCLDIR=..\..\tcl
  nmake -f Makefile.vc OPTS=threads INSTALLDIR=c:\tcl TCLDIR=..\..\tcl install

  tclsh85t

  % package require Tk
  can't find package Tk
  %

  After building like this the generated pkgIndex.tcl contains no patchlevel because of the undefined TCL_PATCHLEVEL in the Makefile.vc:

  if {![package vsatisfies [package provide Tcl] 8.5]} { return }
  if {[package vcompare [package provide Tcl] 8.5] != 0} { return }
  package ifneeded Tk 8.5 [list load [file join $dir .. .. bin tk85t.dll] Tk]

  Everything loads correctly if TCL_PATCHLEVEL is set to a6 when building Tk. This results in the following pkgIndex.tcl

  if {![package vsatisfies [package provide Tcl] 8.5]} { return }
  if {[package vcompare [package provide Tcl] 8.5a6] != 0} { return }
  package ifneeded Tk 8.5a6 [list load [file join $dir .. .. bin tk85t.dll] Tk]

  After which, Tk loads succesfully from tclsh:

  > tclsh85t
  % package require Tk
  8.5a6
  %


tkt_uuid: 220776ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 6
foundin: obsolete: 8.0.3
resolution: None
title: update idletasks does not update repacked widgets on Windows
comment:
  OriginalBugID: 674 Bug
  Version: 8.0.3
  SubmitDate: '1998-09-02'
  LastModified: '2000-04-09'
  Severity: LOW
  Status: Assigned
  Submitter: lfb
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


  button .foo -text "Hello World!"
  pack .foo -expand yes
  pack propagate . 0
  . configure -width 200 -height 200
  foreach anchor {center n ne e se s sw w nw center } {
      pack .foo -anchor $anchor

      # update the display
      update idletasks

      # wait half a sec
      after 500
  }

  Notice how the update idletasks does not remove the image of the button after it has been repacked.  Ick.



  Reported on c.l.t by  davisjf@gte.net (John F. Davis)
  (lfb)

  This is a code fragment taken from Brent's book!
  --
  The work-around is to use 'update' instead of 'update idle'.
  The problem is that the redraw of the of the button is
  occurring within an idle callback, but evidently the redraw
  of the underlying frame isn't.  Problem still in 8.2. 
  -- 12/14/1999 hobbs


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

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

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

  -jcw


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

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

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

  --
  JJM


tkt_uuid: 2920409fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 12. Unix Menus
priority: 7 High
foundin: TIP Implementation
resolution: Accepted
title: TIP#360: Modernize menus on X11
comment:
  The following patches are intended to make Tk menus on X Windows function more like GNOME menus. The first patch makes the dropdown menus follow the mouse once they have initially been activated. This is the behaviour seen on Windows menus and is also used by GNOME. Currently a user must click to open every cascade menu. If the original functionality is desired, the *Menu.clickToFocus option can be set (or call tk::classic:;restore menu).
  The second stops pinning the Help menu to the extreme right of the menubar. Again the old behaviour can be restored. This time by setting the *Menu.useMotifHelp option or by calling tk::classic::restore menu.

  The patches are based on core-8-5-branch and these versions incorporate suggestions from tcl-core (delayed post cascade, option database override)


tkt_uuid: 521436ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: panedwindow patch
comment:
  As mentionned ealier in comp.lang.tcl,
  [panedwindow paneconfigure] lacks an "objc"
  checking in function PanedWindowWidgetObjCmd().
  Also, return statements in this function makes
  miss the call to Tcl_Release() at the end of
  the function.

  The patch attached resolves both these issue.


tkt_uuid: 220829ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: None
title: new event substitution %e to get all event information
comment:
  OriginalBugID: 1303 RFE
  Version: 8.1b1
  SubmitDate: '1999-02-25'
  LastModified: '2000-04-03'
  Severity: MED
  Status: UnAssn
  Submitter: pat
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: 4
  Machine: X86


  Name:
  Bryan Oakley

  DesiredBehavior:
  I would like a new substitution to be available to event scripts. %e
  would return a list of all relevent event information, suitable to be
  handed to "event generate". It would have all of the event information
  specific for the type of event. 

  This could be useful for capturing events for later playback in an
  automated testing tool. Or perhaps to pass events on to other windows
  without modification. Right now it is very tedious to capture all of the
  right values for various event types.

  It might also be nice to have a % substitution to get the event that
  triggered the script. For example, in a ButtonPress event script perhaps
  %? could return "<ButtonPress>". This could then be used as the first
  argument to an event generate command.





  We're gearing up for 8.4, and Tk will be the main focus (new widgets, megawidget support, etc).  This looks like it might go along well with that work, but if we had a patch, it'd be that much easier.

  - eric 
  -- 04/03/2000 ericm


tkt_uuid: 3487136fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: None
resolution: Accepted
title: TkpMeasureCharsInContext bugs in Tk Cocoa
comment:
  For Chinese and other text where a UTF character is more than one byte, TkpMeasureCharsInContext returns "1" when called by the text widget to determine tag-under-mouse whether mouse is in fact over first or second character.  (The attached script demonstates.)  Tracing revealed this was because CTTypesetterSuggestClusterBreak() refuses to return a zero, even if the cluster break goes past the max.  Added code to detect and correct this.  While debugging a couple of other apparent errors were found and fixed.

  Finally, some special code to ignore user-specified threshold and disable antialiasing for fixed-width fonts below 10-point was disabled.  If this is going to be present, it should be exposed through a ::tk::mac variable so the user or application can turn it off, since this behavior is nonstandard.


tkt_uuid: 1449550fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 8
foundin: obsolete: 8.5a4
resolution: None
title: access violation crash in Tk_AttachHWND
comment:
  In this portion of code:

      if (twdPtr == NULL) {
  twdPtr = (TkWinDrawable *) ckalloc(sizeof(TkWinDrawable));
  twdPtr->type = TWD_WINDOW;
  twdPtr->window.winPtr = (TkWindow *) tkwin;
  >>>    } else if (twdPtr->window.handle != NULL) {
  entryPtr = Tcl_FindHashEntry(&tsdPtr->windowTable,
  (char *)twdPtr->window.handle);
  Tcl_DeleteHashEntry(entryPtr);
      }

  the 'twdPtr' has value 0x000001.

  Here's the stack trace:

  Tk_AttachHWND(Tk_Window_ * 0x02d510d8, HWND__ *
  0x00031b18) line 73 + 5 bytes
  TkpMakeWindow(TkWindow * 0x02d510d8, unsigned long
  0x00000000) line 279 + 13 bytes
  Tk_MakeWindowExist(Tk_Window_ * 0x02d510d8) line 1684 +
  13 bytes
  MenuSelectEvent(TkMenu * 0x02d35350) line 2868 + 11 bytes
  RecursivelyClearActiveMenu(TkMenu * 0x02d35350) line
  1285 + 9 bytes
  RecursivelyClearActiveMenu(TkMenu * 0x022103c0) line
  1295 + 17 bytes
  RecursivelyClearActiveMenu(TkMenu * 0x0235c930) line
  1295 + 17 bytes
  RecursivelyClearActiveMenu(TkMenu * 0x0206d6a8) line
  1295 + 17 bytes
  TkWinHandleMenuEvent(HWND__ * * 0x0026f60c, unsigned
  int * 0x0026f610, unsigned int * 0x0026f614, long *
  0x0026f618, long * 0x0026f600) line 1010 + 9 bytes
  WmProc(HWND__ * 0x001015f6, unsigned int 0x00000116,
  unsigned int 0x00210805, long 0x00000000) line 7834 +
  25 bytes
  USER32! 77d48734()

  This tends to happen when my computer is running a
  variety of other intensive processes and I haven't used
  this particular Tk application for a while.  When I
  then click on its menubar to activate it and try to
  open a menu, *boom*.  [Speculation: perhaps some
  resource has been cleaned up by the OS and Tk doesn't
  realise that?]

  Vince.


tkt_uuid: 2834776fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: ttk::spinbox spins up/down when disabled
comment:
  ttk::spinbox::MouseWheel generates <<Increment>>  and <<Decrement>> 
  events even when the widget is disabled.


tkt_uuid: 220826ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: None
title: reentrancy and tk_messageBox
comment:
  OriginalBugID: 569 Bug
  Version: 8.0
  SubmitDate: '1998-04-15'
  LastModified: '1998-04-15'
  Severity: LOW
  Status: UnAssn
  Submitter: hershey
  ChangedBy: hershey
  OS: Windows NT
  OSVersion: 4.0
  Machine: NA
  FixedInVersion: NA


  >Reply-To: tromey@cygnus.com
  >From: Tom Tromey <tromey@creche.cygnus.com>
  >Date: 10 Feb 1998 17:02:14 -0700
  >Lines: 50
  >X-Mailer: Red Gnus v0.34/Emacs 19.34
  >X-Rcpt-To: ouster@scriptics.com
  >X-Mozilla-Status: 8003
  >
  >I'm using Tcl/Tk 8.0 on Windows NT 4.
  >
  >tk_messageBox doesn't provide the most helpful interface in terms of
  >reentrancy.  This probably won't bite most people, but it did bite us.
  >
  >Here's the scenario: we have several communicating applications.
  >Certain actions (e.g., shutting down the whole project) can be
  >confirmed by different applications; that way the action can be
  >globally aborted if it is locally a "bad time" for it to happen.
  >
  >In one our apps, trying to close the main window can also cause this
  >confirmation to happen.  In this case the confirmer asks the user
  >whether he really meant to exit.
  >
  >This boils down to a call to tk_messageBox.  However, while the
  >message box is visible, the user can try to exit the whole suite of
  >applications, resulting in a reentrant call to tk_messageBox, with the
  >same "question".
  >
  >So far, so good.
  >
  >
  >But what we'd really like to do is have the dialog up just once.  But
  >there is no way to do this!  The problem is that the standard dialogs
  >are manipulable like ordinary Tk windows; they don't have names, etc.
  >Bummer.
  >
  >
  >Try #2 is to have a wrapper for the tk_messageBox call.  The wrapper
  >keeps a list of questions currently being asked, and, if called
  >reentrantly, just does a "vwait" waiting for the answer.
  >
  >Of course, this won't work either, because the variable we're waiting
  >for won't get set until the earlier call finishes (which it can't,
  >since we're waiting in vwait).
  >
  >Sigh.
  >
  >One proposed solution: have tk_messageBox accept a `-variable' option.
  >If set, the result from the message box will be stored into the named
  >variable.  Then the vwait solution would work.  This is what I'm going
  >to do in our sources, since it seems relatively easy.  (I can send you
  >the resulting patch, if you want.)
  >
  >
  >I admit this is an obscure case.  But I do think the fact that the
  >standard dialogs aren't real Tk objects is likely to cause other
  >problems for other people.
  >
  >Tom


tkt_uuid: 1627732fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 7 High
foundin: obsolete: 8.5a6
resolution: Fixed
title: CONST: tkButton.c: optionSpecs with TkpButtonSetDefaults
comment:
  The recent change to the const'ness of optionSpecs seems to be causing issues:

  ..\generic\tkButton.c(639) : error C2220: warning treated as error - no 'object' file generated
  ..\generic\tkButton.c(639) : warning C4090: 'function' : different 'const' qualifiers


tkt_uuid: 870281ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Duplicate
title: Errors testing tk 8.4.5
comment:
  Hi,

  I compiled tk 8.4.5 without problem,
  but for the make test I got these errors :

  $ gmake test
  TCL_LIBRARY=/tmp/tcl8.4.5/library; export TCL_LIBRARY; \
  TK_LIBRARY=/tmp/tk8.4.5/library; export TK_LIBRARY; \
  ./tktest /tmp/tk8.4.5/unix/../tests/all.tcl -geometry
  +0+0 \
    
  Tests running in interp:  /tmp/tk8.4.5/unix/tktest
  Tests located in:  /tmp/tk8.4.5/tests
  Tests running in:  /tmp/tk8.4.5/unix
  Temporary files stored in /tmp/tk8.4.5/unix
  Test files sourced into current interpreter
  Running tests that match:  *
  Skipping test files that match:  l.*.test
  Only running test files that match:  *.test
  Tests began at Sun Jan 04 08:53:25 CET 2004
  bell.test
  Bell should ring now ...
  bgerror.test
  bind.test
   
  ==== bind-22.10 HandleEventGenerate FAILED
  ==== Contents of test case:
   
      setup
      bind .b.f <Key> {set x "%s %K"}
      set x {}
      event gen .b.f <Control-Key-1>
      set x
   
  ---- Result was:
  5 1
  ---- Result should have been (exact matching):
  4 1
  ==== bind-22.10 FAILED
   
  bitmap.test
  border.test
  button.test
  canvImg.test
  canvPs.test
  canvRect.test
  canvText.test
  canvWind.test
  canvas.test
  choosedir.test
  clipboard.test
  clrpick.test
  cmds.test
  color.test
  config.test
  cursor.test
  dialog.test
  embed.test
  entry.test
  event.test
  filebox.test
  focus.test
  focusTcl.test
  font.test
  frame.test
  geometry.test
  get.test
  grab.test
  grid.test
  id.test
  image.test
   
  ==== image-1.7 Tk_ImageCmd procedure, "create" option
  FAILED
  ==== Contents of test case:
   
      image delete myimage
      image create test myimage -variable x
      .c create image 100 50 -image myimage
      .c create image 100 150 -image myimage
      update
      set x {}
      image create test myimage -variable x
      update
      set x
   
  ---- Result was:
  {myimage free} {myimage free} {myimage delete} {myimage
  get} {myimage get} {myimage display 0 0 13 15 30 30}
  {myimage display 0 0 13 15 30 130}
  ---- Result should have been (exact matching):
  {myimage free} {myimage free} {myimage delete} {myimage
  get} {myimage get} {myimage display 0 0 30 15 30 30}
  {myimage display 0 0 30 15 30 130}
  ==== image-1.7 FAILED
   
   
  ==== image-1.8 Tk_ImageCmd procedure, "create" option
  FAILED
  ==== Contents of test case:
   
      .c delete all
      image create test myimage -variable x
      .c create image 100 50 -image myimage
      .c create image 100 150 -image myimage
      image delete myimage
      update
      set x {}
      image create test myimage -variable x
      update
      set x
   
  ---- Result was:
  {myimage get} {myimage get} {myimage display 0 0 13 15
  30 30} {myimage display 0 0 13 15 30 130}
  ---- Result should have been (exact matching):
  {myimage get} {myimage get} {myimage display 0 0 30 15
  30 30} {myimage display 0 0 30 15 30 130}
  ==== image-1.8 FAILED
   
  imgBmap.test
  imgPPM.test
  imgPhoto.test
  listbox.test
  macEmbed.test
  macFont.test
  macMenu.test
  macWinMenu.test
  macscrollbar.test
  main.test
  menu.test
  menuDraw.test
  menubut.test
  message.test
  msgbox.test
  obj.test
  oldpack.test
  option.test
  pack.test
  panedwindow.test
  place.test
  raise.test
  safe.test
  scale.test
  scrollbar.test
  select.test
  send.test
  spinbox.test
  text.test
  textBTree.test
  textDisp.test
  textImage.test
   
  ==== textImage-4.3 alignment and padding checking FAILED
  ==== Contents of test case:
   
      catch {
          image create photo small -width 5 -height 5
          small put red -to 0 0 4 4
          image create photo large -width 50 -height 50
          large put green -to 0 0 50 50
      }
      catch {destroy .t}
      text .t -font test_font -bd 0 -highlightthickness 0
  -padx 0 -pady 0
      pack .t
      .t image create end -image large
      .t image create end -image small -padx 5 -pady 10
      .t insert end test
      update
      set result ""
      lappend result default:[.t bbox small]
      foreach i {top bottom center baseline} {
          .t image configure small -align $i
          update
          lappend result $i:[.t bbox small]
      }
      set result
   
  ---- Result was:
  {default:55 22 5 5} {top:55 10 5 5} {bottom:55 35 5 5}
  {center:55 22 5 5} {baseline:55 23 5 5}
  ---- Result should have been (exact matching):
  {default:55 22 5 5} {top:55 10 5 5} {bottom:55 35 5 5}
  {center:55 22 5 5} {baseline:55 22 5 5}
  ==== textImage-4.3 FAILED
   
  textIndex.test
  textMark.test
  textTag.test
  textWind.test
  tk.test
  unixButton.test
  unixEmbed.test
  unixFont.test
  unixMenu.test
  unixSelect.test
  unixWm.test
   
  ==== unixWm-4.3 moving window while withdrawn FAILED
  ==== Contents of test case:
   
          wm withdraw .t
          sleep 200
          wm geom .t $geom
          update
          wm deiconify .t
          wm geom .t
       
  ---- Result was:
  100x150+0+30
  ---- Result should have been (exact matching):
  100x150+0+0
  ==== unixWm-4.3 FAILED
   
   
  ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a
  toplevel, x-coords FAILED
  ==== Contents of test case:
   
      deleteWindows
      toplevel .t -width 300 -height 400 -bg green
      wm geom .t +40+0
      tkwait visibility .t
      toplevel .t2 -width 100 -height 80 -bg red
      wm geom .t2 +140+200
      tkwait visibility .t2
      raise .t2
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing [expr $x - 30] [expr $y +
  250]]  [winfo containing [expr $x - 1] [expr $y + 250]]
   [winfo containing $x [expr $y + 250]]  [winfo
  containing [expr $x + 99] [expr $y + 250]]  [winfo
  containing [expr $x + 100] [expr $y + 250]]  [winfo
  containing [expr $x + 199] [expr $y + 250]]  [winfo
  containing [expr $x + 200] [expr $y + 250]]  [winfo
  containing [expr $x + 220] [expr $y + 250]]
   
  ---- Result was:
  {} {} .t {} {} {} {} .t
  ---- Result should have been (exact matching):
  {} {} .t {} .t2 .t2 {} .t
  ==== unixWm-50.1 FAILED
   
   
  ==== unixWm-50.8 Tk_CoordsToWindow procedure, more
  basics FAILED
  ==== Contents of test case:
   
      catch {destroy .t}
      toplevel .t -width 400 -height 300 -bg green
      wm geom .t +0+0
      frame .t.f -width 200 -height 100 -bd 2 -relief raised
      place .t.f -x 100 -y 100
      frame .t.f.f -width 200 -height 100 -bd 2 -relief
  raised
      place .t.f.f -x 100 -y 0
      update
      set x [winfo rooty .t]
      set y [expr [winfo rooty .t] + 150]
      list [winfo containing [expr $x + 50] $y]  [winfo
  containing [expr $x + 150] $y]  [winfo containing [expr
  $x + 250] $y]  [winfo containing [expr $x + 350] $y] 
  [winfo containing [expr $x + 450] $y]
   
  ---- Result was:
  .t.f .t.f .t {} {}
  ---- Result should have been (exact matching):
  .t .t.f .t.f.f .t {}
  ==== unixWm-50.8 FAILED
   
  util.test
   
  ==== util-1.3 Tk_GetScrollInfo procedure FAILED
  ==== Contents of test case:
   
      .l yview 0
      .l yview moveto .5
      .l yview
   
  ---- Result was:
  0.5 0.5
  ---- Result should have been (exact matching):
  0.5 0.75
  ==== util-1.3 FAILED
   
   
  ==== util-1.7 Tk_GetScrollInfo procedure FAILED
  ==== Contents of test case:
   
      .l yview 0
      .l yview scroll 2 pages
      .l nearest 0
   
  ---- Result was:
  2
  ---- Result should have been (exact matching):
  6
  ==== util-1.7 FAILED
   
   
  ==== util-1.8 Tk_GetScrollInfo procedure FAILED
  ==== Contents of test case:
   
      .l yview 15
      .l yview scroll -2 pages
      .l nearest 0
   
  ---- Result was:
  13
  ---- Result should have been (exact matching):
  9
  ==== util-1.8 FAILED
   
  visual.test
  visual_bb.test
  winButton.test
  winClipboard.test
  winDialog.test
  winFont.test
  winMenu.test
  winSend.test
  winWm.test
  window.test



  and then it timeouts...


tkt_uuid: 2997657fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 4
foundin: obsolete: 8.5.8
resolution: Wont Fix
title: Labelframe loses border and title when it's a container
comment:
  This happened with Tk 8.5.8 from the Debian repositories. Labelframes created with "-container true" and I passed their [winfo id] as values for argv {-use} while creating slave interpreters. The slaves windows were embedded in the labelframes areas, but they lost their borders and titles. I don't know how labelframe widgets are designed, but it seems that [winfo id] on a labelframe returns the ID of its "outer", container frame, not of its interior as expected.

  Thanks!

  Fabricio Rocha
  Brasilia, Brasil
  rocha_fabricio@yahoo.com.br


tkt_uuid: 415415ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 15. [scale]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: None
title: Long callback: One click -> Two steps
comment:
  Evaluate the demo script in wish.

  Click once in the trough of the scale.  Do
  not hold the button down.

  Watch the scale advance two steps.

  This problem can be worked around by configuring
  the -repeatdelay of the scale, but that's not
  obvious from the documentation pages.

  Documentation improvements are probably sufficient
  to close this bug.


tkt_uuid: 1151523fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 6
foundin: None
resolution: Fixed
title: Documentation error: NULL interp parameters
comment:
  Contrary to the documentation, it is not safe to pass a
  NULL pointer as the 'interp' parameter to
  Tk_AllocFontFromObj.  If you do so, and the object
  contains an illegal font name,   ParseFontNameObj uses
  the interp anyway, leading to a crash.

  There are probably a number of other Tk routines that
  have the same problem.


tkt_uuid: 1072868fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 4
foundin: None
resolution: None
title: TkAqua: overrideredirect is permanent
comment:
  wm withdraw .
  wm overrideredirect . 1
  update idletasks
  wm deiconify .
  update
  after 1000
  wm withdraw .
  wm overrideredirect . 0
  update idletasks
  wm deiconify .

  Running the above script, the window should appear
  without a titlebar for a second, then quickly disappear
  and reappear with a titlebar.  Instead, at the end of
  the script, there is still no titlebar.


tkt_uuid: 1883418fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Fixed
title: negative button width not documented
comment:
  On Windows, a button can be created/configured with a negative width, which specifies a mimimum value for the width. It seems this is not documented.


tkt_uuid: 833819ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Fixed
title: large directory support
comment:
  tk_get*File has difficulties with a directory of 25000
  elements.

  Using [file isdir ./$f] is a factor of 10 slower than
  [file isdir $f] for Tcl 8.4.2 on IRIX64 6.5, as the
  following example shows:

  (bfd) 68 % time { foreach f [glob *] { file isdir $f } } 5
  317112 microseconds per iteration
  (bfd) 69 % time { foreach f [glob *] { file isdir ./$f
  } } 5
  3496268 microseconds per iteration
  (bfd) 97 % llength [glob *]
  2113

  The problem is less severe (only a factor of 3) on
  Debian Linux 2.4.20-xfs:

  (bfd) 53 % time { foreach f [glob *] { file isdir $f } } 5
  220577 microseconds per iteration
  (bfd) 54 % time { foreach f [glob *] { file isdir ./$f
  } } 5
  597074 microseconds per iteration
  (bfd) 56 % llength [glob *]
  2000

  The attached patch replace ./$f with $f, and only calls
  isdir once rather than twice.

  The call to IconList_Add with the resulting file list
  is also slow, but this patch does not address that issue.

  ::tk::IconList_Add $data(icons) $file $matchList


tkt_uuid: 220017ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Duplicate
title: GetCursorFromObj called with non-existent cursor!
comment:
  OriginalBugID: 2675 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-08-31'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2562
  OS: All
  Machine: X86
  FixedInVersion: 8.2.1
  ClosedDate: '1999-08-31'


  Name:
  Nick Reingold

  Comments:
  This behavior occurs on UNIX (SGI) and NT.  It does not happen for 8.1
      on SGI.

  ReproducibleScript:
  Start Wish and execute these lines:
      
        menu .mb
        string length [.mb cget -cursor]
        exit
      
      Wish aborts with error message "GetCursorFromObj called with
      non-existent cursor!"

  ObservedBehavior:
  Wish crashes on exit.

  DesiredBehavior:
  Wish should not crash on exit.



  Already fixed by previous bug report, set for 8.2.1/8.3 release. 
  -- 08/31/1999 hobbs


tkt_uuid: 566605ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Fixed
title: Underline position in translated labels.
comment:
  This patch is an alternative to #563140 that I consider
  more suitable. With this patch, texts for all labels
  and buttons in standard dialogs are specified in the
  form like "File &name:", then translated via msgcat.
  Underline is specified by ampersand position. 


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: 975481ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Invalid
title: Bad Path Names For X11 Directory
comment:
  When building tk8.4.6 on Unix, I was met with several 
  error messages stating that various files from the X11 
  directory could not be found. 
   
  I modified the paths for the files that couldn't be found 
  (basically every file with the X11 Directory), in the 
  header files which referenced them (tk.h, Xlib.h, 
  tkIntXlibDecls.h, tkUnixPort.h, and keysym.h) 
  from "X11/filename"  to "../xlib/X11/filename". 
   
  After typing "make" again, it found most of the files, but 
  the tkUnixPort.h file referenced two files that weren't 
  included in the download package (Xpronto.h, and 
  Xresource.h) and thus the package would still 
  not compile.

  Any help with the problem would be greatly appreciated.
  Jason (jdeast@bu.edu)


tkt_uuid: 922666ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.4.3
resolution: Invalid
title: scrollbar: -jump option appears to not work on Windows 2000
comment:
  Hi,

  The -jump option for a scrollbar does not work on the
  Windows 2000 platform. 

  Thanks,

  Greg Pierce


tkt_uuid: 659218ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 49. [grid]
priority: 9 Immediate
foundin: None
resolution: Accepted
title: make column/row configure easier
comment:
  When I use the grid tool, I don't care about what
  columns or rows get certain options.  I care about the
  widgets.  It would make my life easier to let Tk figure
  things out for me.  This is what I had in mind, more or
  less:

  grid columnconfigure .foo.bar -weight 1

  where .foo.bar is a widget, not a 'master'.

  Maybe there is another way to do it that is cleaner.

  Thankyou,
  Dave


tkt_uuid: 809157ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 4
foundin: obsolete: 8.4.4
resolution: Accepted
title: partially transparent images don't display correctly.
comment:
  When using "partial transparency of images with non-
  trivial alpha channels", the renderer always assumes a 
  grey background. This means that if the image has any 
  areas that are partially transparent instead of fully 
  transparent they will be rendered as grey pixels. This 
  precludes using any shape such as a rounded edge, 
  circles, ovals, triangles, polygons, etc (anything other 
  than a normalized, non-rotated rectangle) that require 
  anti-aliasing in an image as the edges will appear jagged 
  with grey pixels instead of smooth and blended with the 
  background pixels. The correct behaviour is to instead 
  sample the underlying background pixel and combine it 
  with the partially transparent pixel of the foreground 
  image to create a new "result" pixel. According to dkf 
  the issue appears to be a bug in the renderer code 
  in "tkImgPhoto.c".


tkt_uuid: 220739ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title:
  Mouse glide over words that are too long to be fully displayed (mclistbox, tree, etc.) should display bubble help with full text.

comment:
  OriginalBugID: 5468 RFE
  Version: 2.0b9
  SubmitDate: '2000-05-11'
  LastModified: '2000-09-03'
  Severity: MED
  Status: Released
  Submitter: kuchler
  ChangedBy: sven
  OS: All
  FixedDate: '2000-09-03'
  FixedInVersion: 2.0b10


  This was a request from Hilen Amin from Integral

  The request was that when the mouse has glided over a word that is too
  long to be fully displayed (a long variable name, a long action name,
  the name of the DOM/dtd in the variable tree, etc. that a bubble pop
  up over the text that the mouse is over, that displays the full string
  that the mouse is over.

  This way when your mouse is over a phrase like 
  "DOM:cfoWebConnect.dtd (cfoWebConnect)" in the variable tree,
  the bubble will show that whole phrase even though the phrase is
  clipped by the edge of the variable box (if it is of a normal size)
  at about "DOM:cfoWebConnct" or so (depending on your resolution, etc.)

  Doubt this can be done for 2.0.

  This would be awesome, but I think that the new core widgets will need to provide enough support to deal with this. 
  -- 05/12/2000 redman

  I got a version of this working in my development tree this weekend.
  It isn't as polished as I would like yet, but it is possible that it
  could be done (at least for the Tree's and the Mclistbox's).

  It wasn't too hard to do, but it would have been easier if there was
  better core support for mega widgets.  In particular when I bind to
  the megawidget (the bwidget Tree or the mclistbox) for things like
  <Motion> it would be nice if the component widgets (the listboxes, and
  the canvas respectively) would see and respect that binding.  Currently
  I have hacks in my code for these widget classes that add the binding
  to these child widgets in these two specific cases, and then I check my
  list of registered widgets for the widget that causes that bound function
  to be called.

  If the widget isn't in the list of registered widgets, then I look for the
  [winfo parent] of the widget, and I continue until I find the 'real' widget.

  It would be nice if it were possible to link together the child widgets in
  such a way that the main megawidget's bindings affect the children, but
  when they call the bound function %W is still the path of the megawidget. 
  -- 05/14/2000 kuchler

  The original request has now been satisfied with the changes that I checked
  into the core today, but the core team should still consider the hoops
  that I jumped through when they work more on the megawidget support to
  see if there is better support that can be given by the core so that multiple widgts can act as one (with respect to the bindings). 
  -- 05/15/2000 kuchler

  Integrate this... 
  -- 09/03/2000 sven


tkt_uuid: 3487138fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Let GetThemeColor() use screen-specific colorspace
comment:
  In GetThemeColor() there is code to use the colorspace of the main display when creating a color from RGBA, however it is commented out in favor of one that uses a generic RGB colorspace.  On a Macbook Pro the generic looks fine, but on a desktop with calibrated color monitors it results in significant distortion.  Allocating for X name "blue" for example would produce something purplish.  Switching to the code that uses main display cured this, and did not make things look any worse on the Macbook Pro.  This patch makes the change, though as it says a further improvement should be made to detect which display the color is being requested for.  I'm also a little fuzzy on how the system remaps colors when dragging a window onto another display (whether it results in a new request to GetThemeColor() or not).


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

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

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

  This behaviour makes code like:

          if { [.entry selection present] } {

  return an error, complaining about a non boolean operand.



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

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



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

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



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

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

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

  -- end of reproducible script --


  Erik Leunissen.

  -- end of bug report --


tkt_uuid: 686329ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 87. Logos
priority: 5 Medium
foundin: None
resolution: Out of Date
title: extended Tk icon for Win32
comment:
  The current Tk icon (tk.ico) contains only a few resolutions and colr depths.  Most notably, 48x48 icons are missing.  These are used to produce much nicer-looking (read: professional) icons on newer Windows releases (actually, I think as far back as Win98).

  It would be very useful to extend the icons included in Tk so Win32 builds would have a better look in Windows Explorer.

  The second reason for doing this, is that it enables a way to patch executables and replace built-in icons.  These "resources" are fixed size, but can be patched to change the icon.  Such changes are important for standalone versions of Wish, and derived single-file apps such as Tclkit and custom-made Starpacks.

  The file submitted below contains 6 icon images, the current 48x48 versions were created by stretching 32x32 versions (not perfect, but enough to support replacement later).  The resolutions are:
     16x16, 32x32, 48x48 - 16 and 256 colors each

  I dropped the 1-bit (monochrome) version.  It was probably a Win3.x/Win32s leftover.

  This same icon is currently in Tclkit.  It can be replaced by the SDX utility when creating Win32 Starpacks.  The presence of 6 known resolutions is essential for developers to be able to create a replacement .ico file.

  -jcw


tkt_uuid: 1224983fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 7 High
foundin: obsolete: 8.4.11
resolution: Fixed
title: Tk_AllocBitmapFromObj() prototype missing from GetBitmap.3
comment:
  The GetBitmap.3 page is missing the function prototype for
  Tk_AllocBitmapFromObj() in the SYNOPSIS section, even
  though it is the first function mentioned in the NAME
  section
  and it is mentioned profusely throughout the rest of
  the page.

  This is an historical problem, not something new with
  8.4.11rcX.


tkt_uuid: 1464918fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a4
resolution: Fixed
title: significant test suite failures
comment:
  This one is going to be tough to describe. Where to
  start? Okay, let's start here.

  Platform: Windows XP SP2, Exceed 10, connecting to
  SPARC Solaris 8
  Latest CVS head for Tcl and Tk.
  Compiled with Sun's c compiler on SPARC Solaris 8.

  text.test results in a core dump and termination of the
  test suite.  Note that before this point, quite a
  number of tests failed.  I will attach the output to
  this report.

  At the point of the core dump, here is the output:

  text.test

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

          set result {}
          lappend result [catch {.t2 configure [lindex
  $test 0] [lindex $test 3]}]
          .t2 configure [lindex $test 0] [lindex $test 1]
          lappend result [.t2 cget [lindex $test 0]]
      
  ---- Result was:
  0 fixed
  ---- Result should have been (exact matching):
  1 fixed
  ==== text-1.10 FAILED

  TkBTreeFindLine ran out of lines
  Abort - core dumped
  gmake: *** [test] Error 134


tkt_uuid: 2790615fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 8
foundin: obsolete: 8.5.7
resolution: None
title: [update] performs Tk callbacks in its own stack frame
comment:
  The [update] command may cause certain callbacks to be executed at its own level in the call stack, not the global level.

  The following script demonstrates the issue:

  proc upd {level} {
      # Perform an update somewhere deep in the call stack
      if {[incr level -1] == 0} {update} else {upd $level}
  }
  pack [text .text -yscrollcommand {apply {args {puts [info level]}}}]
  upd 7

  This prints:
  8
  8

  Note that this does not happen with [after idle] or [after $time] events, so it seems restricted to some specific Tk callbacks.


tkt_uuid: 1115816fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Out of Date
title: Minor bug in Widget Tour: fix included
comment:
  The bug is in the Tk Widget Demo, and I see it when
  running ActiveTcl 8.4.9.0 on Linux (Fedora Core 3).

  When the "Menu Demonstration" produces a tk_dialog, and
  the "Widget Demonstration" root window is not
  minimised, the dialog may appear underneath the "Menu
  Demonstration" toplevel.  I attach a patch to the file
  "demos/Tk/menu.tcl" that fixes this bug.


tkt_uuid: 219921ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Duplicate
title: simple three line wish script cause core dump.
comment:
  OriginalBugID: 1265 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-23'
  LastModified: '1999-08-20'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2316
  OS: AIX
  OSVersion: AIX 4.2
  Machine: RS6000
  ClosedDate: '1999-08-20'


  Name:
  Marc Schwarzschild

  Extensions:
  see above comments

  CustomShell:
  None

  ReproducibleScript:
  text .a
  pack .a
  .a insert end foo





  ObservedBehavior:
  core dump




  DesiredBehavior:
  the string foo should be inserted into the text widget




  I have just built tcl8.1 and tk8.1.  Then I tried a simple wish session
  and got
  a core dump.

  The following is a complete listing of the build of both tcl8.1 and
  tk8.1.
  Followed by the core dump session.  Followed by the core stack trace
  from dbx.

  Please let me know that you have received this and what I should do
  now.

  Thank you,
  Marc Schwarzschild

  ---------------------------- starts here

  [snipped by surles -- it was just a bunch of junk]


  Cannot reproduce this bug.  User error?
  03/25/1999 15:36 - surles -

  AIX has an outstanding reoccuring problem with the text widget.
  It works for some, but in some magic compiler/version combo
  there seems to be an error.  This might be related to the fact
  that AIX is the only Unix we know that cores on ckalloc(0). 
  -- 08/20/1999 hobbs


tkt_uuid: 220161ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: calling exit() early in program gives Access violation
comment:
  OriginalBugID: 1805 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-14'
  LastModified: '1999-04-20'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: rjohnson
  OS: Windows 95
  Machine: X86
  ClosedDate: '1999-04-20'


  Name:
  James Hemmerle

  CustomShell:
  None

  Comments:
  My real application checks the command line arguments and calls exit
      on invalid input.  If the user had valid input the program runs and
      exits properly.

  ReproducibleScript:
  Add an exit() call as first line of main() in winMain.c.
      Compile program and run.

  ObservedBehavior:
  As the program executes the exit() call, you get an report in the
      VC++ debugger of:
      First-chance exception in wishc81d.exe (Tk81d.dll): 0xC0000005: Access
      violation (I compiled with NODEBUG=0).
      
      It seems to occur when the .dll is being unloaded.  DllMain()
      (tkWin32Dll.c) calls TkWinXCleanup() which calls TkWinWmCleanup()
      which bombs on the line:
          ThreadSpecificData *tsdPtr = (ThreadSpecificData *) 
                  Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));

  DesiredBehavior:
  No access violation.



  Tcl was not designed to work that way.  Simply calling exit(0 will not clean up nicely on any version of Tcl.  04/20/1999 15:34 - rjohnson -


tkt_uuid: 533519ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Fixed
title: Window placement with multiple screens
comment:
  Using multiple screens under MS Windows there are a
  number of minor issues to do with window placement.

  Firstly there is no way to find out from Tk the real
  screen area. Windows arranges multiple monitors as a
  single large desktop. In my case I have two 1152x864
  screens. The primary monitor to the right and the
  secondary monitor to the left. With this setup my
  available desktop geometry goes from -1152 to +1152 and
  0 to 864. In other words under MS Windows and window
  may have a negative placement. This is currently
  handled OK by the wm geometry command. To place a
  toplevel on the left hand monitor I can do wm geometry
  . 100x100+-1152+0 and it is placed in the top lefthand
  corner of the secondary monitor.

  However, placing . on monitor 2 and creating a second
  toplevel (.t) places the new window on the primary
  monitor. Calling tk::PlaceWindow .t widget . places .t
  at the corrent vertical position but on the wrong monitor.
  This is because of the bounds checking in the
  PlaceWindow function. We can fix this by not doing the
  bounds checking for Windows except that it would be
  better to do the bounds checking. But we cannot find
  out the extent of the desktop from Tk. The attached
  program (multimon.c) shows a Windows way to get the
  information but I'm not sure where within Tk it should
  be placed. Possibly the winfo vrootwidth and
  vrootheight but that doesn't give us the offsets. In my
  case vrootwidth is going to be 2*1152 but I need to be
  able to find out that my coordinates go from -1152 to
  +1152.


tkt_uuid: 483832ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 4
foundin: obsolete: 8.4a4
resolution: Wont Fix
title: clipboard.test failure
comment:
  I am seeing the following failure when running the test
  suite with the latest Tk on SPARC Sun Solaris 2.6 and
  Sun's compiler and CDE window manager.

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

      setupbg
      clipboard clear
      clipboard append -f INTEGER -t TEST "16"
      set result [dobg {clipboard get 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


tkt_uuid: 220279ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Invalid
title: tk_chooseDirectory Crashes
comment:
  OriginalBugID: 4177 Bug
  Version: 8.3
  SubmitDate: '2000-02-14'
  LastModified: '2000-04-12'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows 95
  OSVersion: Win 95 4.00.950 C
  Machine: 90 MHz Pentium, Intel motherboard (Gateway)
  ClosedDate: '2000-04-12'


  Name:
  John Blattner

  Extensions:
  none

  CustomShell:
  While I have made minor mods in the version which generates debug info (redefined the lib search path, removed the "info body" command, the same problem occurs with downloaded Scriptics executable.

  ReproducibleScript:
  tk_chooseDirectory works fine on one machine (Win98)

  On another machine (Win95 - 4.00.950 C), it crashes when I simply start wish, and enter "tk_chooseDirectory" in the console window.  I took the following precautions to make sure that other tcl versions / builds on the machine wouldn't interfere with the tcl/tk installation.

  1. Checked the registry to make sure that no HKEY_LOCAL_MACHINE/SOFTWARE/Scripts keys previously existed.

  2. Installed tcl/tk 8.3.0 from the Scriptics self-installing executable.  At this point, the registry now contained HKEY_LOCAL_MACHINE/SOFTWARE/Scripts values.

  3. Modified autoexec.bat.  The Wise installation script added the tcl/tk path to the end of my path.  I modified autoexec.bat to place the tcl/tk path at the beginning of the path (restarted machine, verified with "puts $env(PATH)").

  4. Started Wish.  Entered "tk_chooseDirectory".  Crash occured.

  ObservedBehavior:
  The following debug information was generated by compiling (a very slightly modified) version of tcl/tk 8.3.0 in debug mode using MSVC6.0, and then clicking on debug when the Access Violation message appeared at runtime.  If it would be helpful, I can back out our mods and recompile / rerun.

  CALL STACK =================

  ChooseDirectoryHookProc(HWND__ * 0x0000081c, unsigned int 273, unsigned int 16778377, long 2072) line 1172 + 6 bytes
  KERNEL32! bff7241d()
  ChooseDirectoryHookProc(HWND__ * 0x41180041, unsigned int 135797495, unsigned int 76087552, long 136053009) line 1096

  LOCAL VARIABLES ============

  - cdPtr0x000017a7
        interpCXX0017: Error: symbol "" not found
        lastCtrlCXX0030: Error: expression cannot be evaluated
        lastIdxCXX0030: Error: expression cannot be evaluated
  +    path0x000017b3 ""
              idCtrl1161

  FILE EDITOR  (tkWinDIalog.c, line 1172) =================

  if ((idCtrl != IDOK) || (notifyCode != BN_CLICKED)) {
      /*
       * OK Button wasn't clicked.  Do the default.
       */
      if ((idCtrl == lst2) || (idCtrl == edt10)) {
  cdPtr->lastCtrl = idCtrl; <============== PROBLEM LINE
      }
      return 0;
  }

  DesiredBehavior:
  On the Win98 machine, on starting wish and entering "tk_chooseDirectory", the directory selection widget appears, appropriately.



  (from the newsgroup)

  I played around with this in a previous version, and found that Win95 is changing the lCustData field, which is where cdPtr comes from:

  cdPtr = (ChooseDir *) ofnPtr->lCustData;

  I never reported it because tk_chooseDirectory wasn't supported at the time,
  and I upgraded to Win98 since then, and it works fine on 98 as you said.

  -- Tim Baker
  dbaker@direct.ca 
  -- 02/15/2000 ericm
  Verified on Win95 (only Win95 affected). 
  -- 04/07/2000 hobbs

  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.

  You can work around this 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.

  Of course, this may cause other problems, and you should check with Microsoft before making this sort of change to your system.  Or, you could upgrade to Windows 98/NT/2000.

  - eric

  -- 04/12/2000 ericm


tkt_uuid: 2496162fffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 7 High
foundin: None
title: test suite segfault
comment:
  Running the entire Tk test suite
  I frequently (as in more than once)
  get a segfault in the test notebook-6.

  It doesn't happen every time, and
  I've occasionally seen the segfault
  elsewhere by varying platform or
  time of day or phase of moon.

  I suspect the real trouble is some
  memory corruption somewhere.

  Sorry to be vague, but the data is
  vague.

  Useful info is that the trouble
  has just appeared, so check recent commits.


tkt_uuid: 1032300fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Fixed
title: wish crashes with canvas
comment:
  when I try to save the canvas created using 
  tkpiechart package to a post script file wish crashes.
  wish: 8.4.7
  platform: windows XP home edition

  package require stooop 4.1
  namespace import stooop::*
  package require switched 2.2
  package require tkpiechart
   
  set canvas [canvas .c -highlightthickness 0]
  pack $canvas -fill both -expand 1
  set pie1 [new pie\
      $canvas 0 0 -height 150 -thickness 20 -
  background gray\
      -labeler [new pieBoxLabeler $canvas -justify 
  center -offset 10]\
      -title "this is pie #1" -titlefont fixed -titleoffset 6 -
  selectable 1\
  ]
  # create a few slices
  set slice11 [pie::newSlice $pie1 test]
  pie::sizeSlice $::pie1 $slice11 0.5 100
  set slice12 [pie::newSlice $pie1 yaha]
  pie::sizeSlice $::pie1 $slice12 0.4
  set slice13 [pie::newSlice $pie1 hello]
  pie::sizeSlice $::pie1 $slice13 0.1
  update idletasks
  #
  # this causes the crash
  #
  $canvas postscript -file test.pst


tkt_uuid: 1806613fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5b1
resolution: Duplicate
title: text widget name with "-" causes error in tk::TextSelectTo
comment:
  Having a "-" (dash) in a text widget name causes some standard bindings to throw errors. For example, run the following code then double click on some text:

  pack [text .t-1]
  .t-1 insert 1.0 "Double click on this text"

  You will get the following error:

  bad text index "tk::anchor.t-1 - 1c"
  bad text index "tk::anchor.t-1 - 1c"
      while executing
  "$w compare $cur < $first"
      (procedure "tk::TextSelectTo" line 33)
      invoked from within
  "tk::TextSelectTo .t-1 59 13"
      (command bound to event)

  The error seems to be related to the use of a mark that looks like "tk::anchor$w". If you change ".t-1" to ".t_1" the problem goes away. 

  I don't think it's a good idea to use a mark that contains the widget name since the name may contain characters that can confuse the index expression parser.


tkt_uuid: 226357ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 7 High
foundin: obsolete: 8.4a3
resolution: Fixed
title: Overlapping with Polygon objects wrong
comment:
  According to the man page a point inside the polygon should return the polygon id when calling [canvas find overlapping]. Don´t know when this changed, it worked well under 8.0.5, and does not work with 8.4a1 and 8.4a2.


tkt_uuid: 220538ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Cannot compile on HP-UX 10.20
comment:
  OriginalBugID: 2222 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-15'
  LastModified: '1999-10-29'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2221
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  FixedDate: '1999-10-29'
  FixedInVersion: 8.2.1


  Name:
  Hank van Bekkem

  ReproducibleScript:
  1. cc: "../generic/../unix/tkUnixPort.h", line 94: warning 525:
         Redeclaration of identifier "fd_mask".
         - Uncomment line 94 of ../unix/tkUnixPort.h
      2. cc: "../generic/tkEvent.c", line 424: error 1705: Function prototypes
         are an ANSI feature.
         - Could only get it to compile by adding compiler option "-Aa" for
           this file.
      3. cc: "../generic/tkSelect.c", line 914: error 1705: Function
         prototypes are an ANSI feature.
         - Could only get it to compile by adding compiler option "-Aa" for
           this file.



  Headers were fixed in 8.2.1, and compiles fine on HP 10.20.
  gcc is recommended, as the default compiler for HP is not ANSI
  compliant (although it will work). 
  -- 10/21/1999 hobbs


tkt_uuid: 481219ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Fixed
title: Cascaded menus and arrow keys
comment:
  There is hard to use arrow keys in cascaded menus 
  (X11 environment). For example, run standard tk 
  demos, choose "Menus and cascades" and try to reach
  "Cascades"/"Radio buttons" submenu using arrow keys. 
  I can't.

  After applying attached patch, X11 menus works like 
  Windows menus.


tkt_uuid: 3573447fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: obsolete: 8.6b3
resolution: None
title: [tk busy] causes crash on OS X/Cocoa
comment:
  Per a bug reported on c.l.t by Christian Gollwitzer, the following code eventually causes a lockup and segfault on Tk-Aqua trunk. "The crash is triggered by first pressing the button, after it has  'finished', selecting the entry in the pulldown list of the combobox,  maybe twice. Sometimes, this must be repeated several times."

  package require Tk 
  pack [ttk::combobox .cbx1 -values {"Select to crash"}] 
  pack [ttk::frame .fr -width 200 -height 200] 
  pack [ttk::button .fr.button -text "Press me for processing" -command Doit] 
  pack [ttk::label .fr.prog -textvariable progress] 

  proc Doit {} { 
          tk busy hold . 
          for {set ::progress 0} {$::progress<100} {incr ::progress} { 
                  after 10 
                  update 
          } 
          tk busy forget . 
  } 

  Considering that busy is supposed to be no-op on Aqua, this is very strange indeed. 


tkt_uuid: 220615ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: Capturing embedded Windows in postscript
comment:
  OriginalBugID: 3386 RFE
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '1999-12-13'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  FixedDate: '1999-12-13'
  FixedInVersion: 8.3b1


  Name:
  Peter J Turner

  CustomShell:
  Nitjans Dash patch plus mod to make it read data from the pix24 buffer instead of the X screen

  DesiredBehavior:
  I would like to be able to print photo images embedded in a canvas. I
      have 
      used the dash patch but found that it reads the image back from screen.
      I have patched the dash patch to read the colour data from the pix24
      buffer in
      tkImgPhoto.c. This seems to make the patch machine independent for this
      type of embedded window. Are there any plans to do something about this
      weakness
      with Tk?  I have not sent you my patch because it relies on the nijtmans
      dash
      patch that seems more aimed at dashed lines than the postscript problem.
      I may be interested in fixing this thing properly if there is some
      chance that the
      changes can be included in the distribution.

      Information and comments please!

      Regards

      Peter Turner



  in 8.3b1. 
  -- 12/13/1999 hobbs


tkt_uuid: 1717479fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Only GIF's appear correctly in menu
comment:
  Using the new custom MDEF under development in CVS HEAD for 8.5 and 8.4.15, it appears that only GIF's appear correctly. I tried to use PNG's via the tkpng and tkimg extensions and saw only white squares. 


tkt_uuid: 1965966fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: LAYOUTS doc missing some options
comment:
  Playing with ttk::style layout I noticed it accepts the options -side, -sticky, -children, -expand, -border and -unit. But only the first three are documented, any chance to get some description about the others ?

  Thanks.


tkt_uuid: 873613ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 8
foundin: obsolete: 8.4.14
resolution: Fixed
title: tearoff-menus : can't select submenu twice (win)
comment:
  1. tearoff menu with submenus
  2. open submenu
  3. select entry in submenu (submenu disapear, function
  called)
  4. open submenu again ->  did not popup  !!!!!
   
  after opening another submenu I can open that submenu again

  Works fpr UNIX


tkt_uuid: 228588ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 8
foundin: obsolete: 8.3.1
resolution: Out of Date
title: grid crashes on resizing when window is too wide
comment:
  For the following code, running on Tcl 8.3.1:

  proc setup {row col} {

      for {set i 1} {$i <= $row} {incr i 1} {
  for {set j 1} {$j <= $col} {incr j 1} {

      set id ""
      append id r $i c $j
      grid [label .$id -text "--" -relief ridge -width 100] -row $i -column $j 

  }
      }
  }

  setup 4 4

  When the window appears, and an attempt is made to resize the window,
  the window disappears, and tcl goes into a loop.

  I tried this on Linux and SunOS 5.7, both giving the same problem.

  The problem seems to be related to the width of the window. If I reduce 
  the width of the label widgets, then I can get more widgets on the window
  before resizing becomes a problem.


tkt_uuid: 852949ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: Infinite loop in tabstop calculations
comment:
  To replicate the problem:

  pack [text .t -tabs "100 50"]
  .t insert end "a\tb\t"

  This locks up Tcl.  The root of the problem is that the
  last tab is smaller than the second-to-last tab, which
  makes tabArrayPtr->increment negative and the
  extrapolation loop in SizeOfTab() never terminates.


tkt_uuid: 833606ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: TkAqua: mousewheel binding incorrect
comment:
  The text.tcl binding:

  bind Text <MouseWheel> {
      %W yview scroll [expr {- (%D / 120) * 4}] units
  }

  isn't right.  If '%D' is a smallish positive number
  (e.g. 100), then the whole expression is rounded down
  to zero and no scrolling takes place.  This is
  different to the case where %D is a smallish negative
  number, where the expression will always be rounded
  down to -1 * 4, and scrolling will take place.

  I believe we should use something like:

  if {%D < 0} {
      %W yview scroll [expr {- (%D / 120) * 4}] units
  } else {
      %W yview scroll [expr { (-%D / 120) * 4}] units
  }

  On a separate note, I believe the magnitudes of %D
  between the Windows and MacOS X implementations of this
  binding are totally different.  The documentation says
  the smallest value on Windows is 120.  On MacOS X it
  has a smallest value of 1, I believe.  This suggests
  something like this would be correct:

  if {[tk windowingsystem] eq "aqua"} {
      bind Alpha <MouseWheel> {
  %W yview scroll [expr {-%D * 4}] units
      }
  } else {
      bind Alpha <MouseWheel> {
  if {%D < 0} {
      %W yview scroll [expr {- (%D / 120) * 4}] units
  } else {
      %W yview scroll [expr { (-%D / 120) * 4}] units
  }
      }
  }


tkt_uuid: 2310660fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 1 Zero
foundin: obsolete: 8.4.13
resolution: Out of Date
title: Tk tests produce FMR in Purify on Linux
comment:
  Parts of the Tk test suite from release 8.4.13 produces an Free Memory Read (FMR) when run with Purify. The specific tests are event-double-click-drag-1.1, textTag-15.2, and textTag-15.3. I've included a minimal test case derived from those tests that demonstrates the problem, and the log file from running with Purify.

  I ran this test on Redhat Enterprise Linux 4.0 U6, using gcc 4.2.2. I built Tcl 8.4.13 from source with a shared library, then built Tk 8.4.13 from source with a shared library and based off the Tcl I'd built. Then I rebuilt wish8.4 with IBM Rational Purify 7.0.0.0-008.P and ran the attached test file.

  Notes from my own debugging: the FMR occurs in SortTags called from line 1355 in tkTextTag.c, happens whether the fast sort or qsort is used, seems to happen on a tag named "sel" (the other members are "x" and "y"), happens on the 2nd call when SortTags is called twice in a row with the same tagArrayPtr pointer (first time in the entire Tk test suite that happens).


tkt_uuid: 220600ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: missing symbol in windows binary tk82.lib
comment:
  OriginalBugID: 2963 Bug
  Version: 8.2
  SubmitDate: '1999-09-28'
  LastModified: '1999-11-16'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0 SP4
  Machine: X86
  FixedDate: '1999-11-16'
  FixedInVersion: 8.2.2


  Name:
  Christopher Volpe

  ReproducibleScript:
  I'm building a 3rd party application that links with theTcl/Tk
      libraries. This is the first time I have tried it with Tcl/Tk 8.2. Using
      the library file tk82.lib that ships with the MS Windows binary
      distribution, the linker complains about the missing symbol
      "_TkWinChildProc@16". I used the cygwin "nm" command to check for
      symbols in tk82.lib and confirmed that this symbol is indeed not in the
      library. But then I downloaded the source distributions for Tcl and Tk
      8.2, built each of them, and discovered that the symbol
      "_TkWinChildProc@16" does appear in the tk82.lib file that I built.
      Using this file solves my problem, but I don't think it was intended
      that the library you shipped as part of the binary distribution would be
      missing this symbol.



  8.2.2 shows this symbol, as seen with NT's Explorer QuickView
  of tk82.dll. 
  -- 11/16/1999 hobbs


tkt_uuid: 220645ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: Tk shared library needs -fPIC on NetBSD/SPARC
comment:
  OriginalBugID: 3960 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-29'
  LastModified: '2000-01-03'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: BSD
  OSVersion: NetBSD/SPARC 1.4
  Machine: Sun SPARCstation IPX
  FixedDate: '2000-01-03'
  FixedInVersion: 8.3b2


  Name: Andreas Gustafsson

  CustomShell:
  Some NetBSD specific changes to the configuration scripts, described in a separate

  Comments:
  The Tk Makefile currently specifies the "-fpic" compiler option when
  building a shared library on NetBSD.  However, on NetBSD 1.4.1 for Sun
  SPARC, this will lead to a Global Offset Table overflow due to the
  size of the Tk library. 

  The enclosed patch changes the compiler option to -fPIC (note the
  all-caps PIC).  This fixes the problem on the SPARC, and should be
  harmless on other platforms.  The patch is currently needed only for the
  Tk library, not the Tcl library,  but it makes sense to apply it to Tcl, too,
  to prevent future problems as the Tcl library grows.

  ReproducibleScript:
  configure --enable-shared
  make

  ObservedBehavior:
  Normal configure and make output, then:

  ld -Bshareable -x -o libtk82.so.1.0 tk3d.o [...] -rpath
  /usr/local/lib:/usr/X11R6/lib -L/home/gson/tcl/tcl8.2.3/unix
  -L/usr/X11R6/lib -lX11 -lm -lc
  ld: Global Offset Table overflow (use `-fPIC')
  ld: tkCanvText.o: GOT overflow for relocation at 0x25b4

  DesiredBehavior:
  Successful linking.

  Patch:
  --- aclocal.m4.old      Sun Dec 26 04:23:17 1999
  +++ aclocal.m4  Sun Dec 26 04:24:25 1999
  @@ -729,7 +729,8 @@
          NetBSD-*|FreeBSD-[[1-2]].*|OpenBSD-*)
              # Not available on all versions:  check for include file.
              AC_CHECK_HEADER(dlfcn.h, [
  -               SHLIB_CFLAGS="-fpic"
  +               # NetBSD/SPARC needs -fPIC, -fpic will not do.
  +               SHLIB_CFLAGS="-fPIC"
                  SHLIB_LD="ld -Bshareable -x"
                  SHLIB_LD_LIBS=""
                  SHLIB_SUFFIX=".so"

  PatchFiles:
  aclocal.m4



  Hmmm, I'd say that's a bug in the compiler, since most accept either
  case, but it's easy enough to fix (will be in 8.3b2).  Tcl's tcl.m4
  was changed as well. 
  -- 01/03/2000 hobbs


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

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

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

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


tkt_uuid: 219419ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Fixed
title: Canvas stippled line bugs
comment:
  OriginalBugID: 6368 Bug
  Version: 8.3.2
  SubmitDate: '2000-10-16'
  LastModified: '2000-10-16'
  Severity: SER
  Status: UnAssn
  Submitter: angie
  ChangedBy: angie
  OS: All
  OSVersion: all
  FixedDate: '2000-10-25'
  ClosedDate: '2000-10-25'


  Tk 8.3.2 Bug

  Support:  None
  Severity:  2
  OperatingSystem:  All
  Synopsis:  Canvas stippled line bugs

  ObservedBehavior:
  1. Option "disabledwidth" is not taken into account for drawing.
  2. Options "activewidth" and "disabledwidth" are taken into account only when bigger than the normal width.
  3. Stippled lines with width 1 are not (or not completely) drawn on Windows.

  Patch:
  1. Change "activeWidth" to "disabledWidth" in line 880 of tkCanvLine.c (tk8.3.2)
  2. Change ">linewidth" to "!=linewidth" in lines 872 and 879 of tkCanvLine.c (tk8.3.2)
  3. Delete lines 751 and 756 of tkWinDraw.c (tk8.3.2).
  4. Apply similar patches to tk8.4a1.
  Posted To comp.lang.tcl: Posted Successfully


tkt_uuid: 935242ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: namespace ::twapi lingers under Linux (Unix?)
comment:
  Observed
  ========

  > tclsh
  % set tcl_platform(os)
  Linux
  % namespace exists ::twapi
  0
  % package require Tk
  8.4
  % namespace exists ::twapi
  1

  Expected
  ========

  No traces of platform-specific extensions on platforms
  where they are useless.

  Erik Leunissen


tkt_uuid: 437149ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Duplicate
title: clipboard,event click, focus tests fail
comment:
  3 different test suite scripts show failures in
  the recent release.

  Platform: SPARC Solaris 2.6
  Compiler: SPARC Sun 5.1
  Configure arguments: --prefix=/usr/tcl84
  Window manager: CDE


  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 {clipboard get 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


  event.test

  ==== event-click-drag-1.2  click and drag in an entry
  widget, this
                              tests tkEntryMouseSelect in
  entry.tcl  FAILED
  ==== Contents of test case:

      destroy .t
      set t [toplevel .t]
      set e [entry $t.e]
      pack $e
      tkwait visibility $e
      focus -force $e
      _keypress_string $e "A Tcl/Tk selection test!"
      set anchor 6
      set selend 18

      set result [list [$e get]]

      # Get the x,y coords of the second T in "Tcl/Tk"
      foreach {anchor_x anchor_y} [_text_ind_to_x_y $e
  $anchor] break

      # Click down to set the insert cursor position
      event generate $e <Enter>
      event generate $e <ButtonPress-1> -x $anchor_x -y
  $anchor_y

      # Save the position of the insert cursor
      lappend result [$e index insert]
      
      # Now drag until selend is highlighted, then click
  up

      set current $anchor
      while {$current <= $selend} {
          foreach {current_x current_y} [_text_ind_to_x_y
  $e $current] break
          event generate $e <B1-Motion> -x $current_x -y
  $current_y
          incr current
          _pause 50
      }

      event generate $e <ButtonRelease-1> -x $current_x
  -y $current_y
      _pause 200

      # Save the position of the insert cursor
      lappend result [$e index insert]

      # Save the highlighted text
      lappend result [selection get]

      # Now click and click and drag to the left, over
  "Tcl/Tk selection"

      event generate $e <ButtonPress-1> -x $current_x -y
  $current_y

      while {$current >= ($anchor - 4)} {
          foreach {current_x current_y} [_text_ind_to_x_y
  $e $current] break
          event generate $e <B1-Motion> -x $current_x -y
  $current_y
          incr current -1
          _pause 50
      }

      event generate $e <ButtonRelease-1> -x $current_x
  -y $current_y
      _pause 200

      # Save the position of the insert cursor
      lappend result [$e index insert]

      # Save the highlighted text
      lappend result [selection get]


  ---- Result was:
  {A Tcl/Tk selection test!} 6 18 {Tk selection} 4 {l/Tk
  selection}
  ---- Result should have been:
  {A Tcl/Tk selection test!} 6 18 {Tk selection} 2
  {Tcl/Tk selection}
  ==== event-click-drag-1.2 FAILED

  filebox.test
  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


tkt_uuid: 2110385fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 9 Immediate
foundin: obsolete: 8.5.4
resolution: Duplicate
title: tk:messageBox OSX -title -icon defunct
comment:
  on Max OS X 10.5.4 i found the -title and -icon options defunct.

  in wish try this:
  tk_messageBox -title title -icon error -message message -detail detail

  will result in 
  - no title
  - standard icon



  kind regards,
  uwe


tkt_uuid: 3505358fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 29. Colormaps and Visuals
priority: 6
foundin: obsolete: 8.5.10
resolution: Fixed
title: invalid color name "#f75df642f527"
comment:
  Environment openSuse Linux 11.2, TclTk 8.5.11 latest trunk;
  In windows the bug is not existent.

  I see the bug when creating a tabnotebook which throws the error:
  invalid color name "#f75df642f527"
  (processing "-fill" option)
  invoked from within
  "$itk_component(canvas) create line [expr {floor(0 + ($itk_option(-borderwidth)/2.0))}] [expr {floor(0 + ($itk_option(-borderwidth)/2.0))}] $wid [e..."
  (object "::.cCMainWindow0.shellchildsite.eFrame.workFrame" method "::iwidgets::Tabnotebook::_redrawBorder" body line 14)
  invoked from within
  "_redrawBorder $wid $hgt"

  The color name comes from:
  - procedure [topShadow {bgColor}]
  - which calls [set hsb [rgbToHsb [winfo rgb . $bgColor]]]
  - ... and a lot more ...

  There is no bug in fossil checkout c309fddc73

  thx


tkt_uuid: 865082ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Introspect available photo write formats
comment:
  When writing a photo image to a file:

  $photo write $fileName -format $format

  the supported values for $format are
  determined by the run-time state of the
  interpreter (what packages are loaded,
  etc.)

  Given that, we should have a way to
  introspect the current list of acceptable
  values.


tkt_uuid: 703090ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 86. Test Tools
priority: 5 Medium
foundin: None
resolution: Works For Me
title: multiple segmentation errors and failures
comment:
  Tcl/Tk 8.4.2
  Solaris 8 [SPARC]
  gcc 3.2.2

  8.4.1. currently installed

  tcl8.4.2 makes without errors amd make tests produces
  no errors [failures from 8.4.1 fixed]

  However although tk8.4.2 makes without errors make test
  fails spectacularly

  bind.test
  Segmentation Fault - core dumped

  panedwindow.test
  Segmentation Fault - core dumped

  textDisp.test
  Segmentation Fault - core dumped


  Tests ended at Wed Mar 12 21:35:36 GMT 2003
  all.tcl:        Total   7107    Passed  6281    Skipped
  800     Failed  26
  Sourced 174 Test Files.
  Files with failing tests: canvRect.test canvText.test
  canvas.test entry.test image.test listbox

  If I remake the 8.4.1 versions the tests behave as
  before so I dont think anything significant has chaned
  on our build system.

  Any suggestions?

  ps this is user ignorance but how is the verion detemined ?

  /usr/local/src/tcl_tk/tcl8.4.2/unix/tclsh
  % info patchlevel
  8.4.1

  iain.morrison@mrc-cbu.cam.ac.uk


tkt_uuid: 219843ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: porting problem between 7.6 and 8.0 in Tk_CoordsToWindow
comment:
  OriginalBugID: 568 Bug
  Version: 8.0p2
  SubmitDate: '1998-04-15'
  LastModified: '1999-08-14'
  Severity: SER
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  RelatedBugIDs: 716
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-10-30'
  FixedInVersion: NA
  ClosedDate: '1999-08-14'


  >I moved from tk7.6 to tk8.0p2 within my graphical application.
  >My application consist of an opengl widget within Tk.
  >
  >When interacting with my widget, I sometimes get the message :
  >
  >"Tk_CoordsToWindow got False return from XTranslateCoordinates"
  >
  >which makes my application abort.
  >I never got this message with tk7.6.
  >
  >Looking into the sources (in tk8.0/unix/tkUnixWm.c) I found that the
  >implementation
  >of Tk_CoordsToWindow has changed from tk7.6 near the call to
  >XTranslateCoordinates.
  >A call to the "panic" function is made when something is wrong, which
  >makes my program abort. 
  >I have intentionally removed the "panic" line to observe that my program
  >again works
  >correctly. It seems like the implementation of Tk_CoordsToWindow is more
  >robust in
  >tk7.6.
  >-- 
  >Michel Pottiez
  >NUMECA International s.a.
  >Avenue F. Roosevelt, 5
  >B-1050 Brussels  -  BELGIUM
  >Tel    : 32 2 647 83 11
  >Fax    : 32 2 647 93 98
  >e-mail : michel@numeca.be


tkt_uuid: 1633089fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Works For Me
title: tk crash on windows - load related
comment:
  Tested on win2k using Tcl/Tk cvs checkout from 2006-12-06

  The following script causes a tclsh or wish process to exit without displaying any error message.

  package require Tk
  package require BWidget
  NoteBook .n -side top
  .n insert end tab1 -text tab1
  pack .n -side top -fill both -expand 1
  wm state . zoomed


tkt_uuid: 1011234fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: None
resolution: Fixed
title: Better handling of up/down in text widgets
comment:
  This is in regards to the tk text windows.

  I find that the up/down keys do not work as one would
  expect in a text box that includes wrapped lines. It
  does not go to the character immediately above, rather
  goes to the character at the same index in the 'line'
  above which could actually be a number of lines up.

  Therefore I recommend changing the ::tk::TextUpDownLine
  to something more along the lines of below.

  Just a quick note it is not fully complete. I have not
  added the ::tk::Priv as before (which should be added)
  and there is a small bug with it when the cursor is at
  the very end of the line, although I believe that bug
  is due possibly to a bug in the return of [$inputbox
  bbox insert] when the character is at the end of the line.
  I also have it as 2 fucntions which could be
  reorganised to be 1 function as the old code.

  #///////////////////////////////////////////////////////////////////////////////
  # UpKeyPressed (inputbox)
  # Called by a window when the user uses the up key in
  a text box. It returns
  # the index of the character 1 line above the
  insertion cursor
  proc UpKeyPressed { inputbox } {
  $inputbox see insert

  set bbox [$inputbox bbox insert]
  set xpos [expr [lindex $bbox 0]+[lindex $bbox 2]/2]
  set ypos [lindex $bbox 1]
  set height [lindex $bbox 3]
  if { $ypos > $height } {
  return [$inputbox index "@$xpos,[expr $ypos-$height]"]
  } else {
  $inputbox yview scroll -1 units
  update
  set ypos [lindex [$inputbox bbox insert] 1]
  set height [lindex [$inputbox bbox insert] 3]
  if { $ypos > $height } {
  return [$inputbox index "@$xpos,[expr $ypos-$height]"]
  }
  }
  return [$inputbox index insert]
  }
  #///////////////////////////////////////////////////////////////////////////////


  #///////////////////////////////////////////////////////////////////////////////
  # DownKeyPressed (inputbox)
  # Called by a window when the user uses the down key
  in a text box. It returns
  # the index of the character 1 line below the
  insertion cursor
  proc DownKeyPressed { inputbox } {
  $inputbox see insert

  set bbox [$inputbox bbox insert]
  set xpos [expr [lindex $bbox 0]+[lindex $bbox 2]/2]
  set ypos [lindex $bbox 1]
  set height [lindex $bbox 3]
  set inputboxheight [lindex [$inputbox configure
  -height] end]
  if { [expr $ypos+$height] < [expr
  $inputboxheight*$height] } {
  return [$inputbox index "@$xpos,[expr $ypos+$height]"]
  } else {
  $inputbox yview scroll +1 units
  update
  set ypos [lindex [$inputbox bbox insert] 1]
  set height [lindex [$inputbox bbox insert] 3]
  set inputboxheight [lindex [$inputbox configure
  -height] end]
  if { [expr $ypos+$height] < [expr
  $inputboxheight*$height] } {
  return [$inputbox index "@$xpos,[expr $ypos+$height]"]
  }
  }
  return [$inputbox index insert]
  }
  #///////////////////////////////////////////////////////////////////////////////


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: 220947ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4a1
resolution: Invalid
title: Event binding bug where events are not triggerd when then sh
comment:
  OriginalBugID: 6217 Bug
  Version: 8.4a1
  SubmitDate: '2000-09-06'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Windows 98
  OSVersion: Microsoft Windows 98
  Machine: Pentium III 600EB


  Name:
  Mark Murawski

  Extensions:
  none

  CustomShell:
  none

  Comments:
  This dosnt bug dosnt seem to exist in unix/linux, but yet, i only tested
      this with one window manager. And I have no idea about mac, since I dont
      own or have access to one.

  ReproducibleScript:
  commandline: wish tclbug.tcl

  A canvas is set up to contain a red square withen the canvas when moved, and then when the mouse is released from dragging, put the square back in its origional position.  Drag the square so that your mouse cursor is off of the canvas, then click the RIGHT mouse button in the parent tk window while still holding the left mouse button, now release both buttons.  What happens? The square is stuck there, because the release event was not triggered

  Third parties have verified this bug
  # ----code----

  pack [text .text -wrap word -height 6]

  .text insert end "Tk canvas or event binding bug:\nThis canvas is set up to contain the red square withen the canvas when moved, and then when the mouse is released from dragging, put the square back in its origional position.  Drag the square so that your mouse cursor is off of the canvas, then click the RIGHT mouse button in the parent tk window while still holding the left mouse button, now release both buttons.  What happens? The square is stuck there, because the release event was not triggered"

  set w .canvas
  pack [canvas $w -width 450 -height 200] -padx 10 -pady 10
  set image [$w create rec 50 50 100 100 -fill red]

  pack [text .echo -height 2 -width 80 -height 10] -expand 1 -fill y

  proc echo {text} {
      .echo insert end "$text\n"
      .echo see end
  }

  $w bind $image <B1-Motion> [list mouse move $image %x %y]
  $w bind $image <B1-ButtonRelease-1> [list mouse release $image %x %y]

  proc mouse {type item x y} {
      set w .canvas

      switch -- $type {
          move {
              set coords [$w coords $item]

              set x2 [lindex $coords 2]
              set y2 [lindex $coords 3]

      set cx [winfo width $w]
      set cy [winfo height $w]

      if {$x < 0} {set x 0}
      if {$y < 0} {set y 0}

              set x2 [expr $x + 50]
              set y2 [expr $y + 50]

      if {[expr $x + 50] > $cx} {set x2 $cx; set x [expr $x2 - 50]}
      if {[expr $y + 50] > $cy} {set y2 $cy; set y [expr $y2 - 50]}

      $w coords $item $x $y $x2 $y2
              return
  }
          release {
              echo "mouse release!"
              $w coords $item 50 50 100 100
          }
      }
  }

  ObservedBehavior:
  The undesirable behavior is that the <B1-ButtonRelease-1> event is not triggered in any manner.

  DesiredBehavior:
  The square will not return to its origional position that would have been handled by <B1-ButtonRelease-1>.  Since <B1-ButtonRelease-1> is not triggered, the square will remain in the last position before the mouse buttons were released


tkt_uuid: 1852332fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.5b3
resolution: Duplicate
title: test suite window-2.9 test hangs
comment:
  sparc solaris 9, sun c compiler, sun's gnome desktop distribution.

  tcl/tk rc4 snapshot configured with options \"'--prefix=/projects/sprs_lwv/tcl85' '--enable-shared' '--enable-symbols' '--enable-stubs' '--enable-64bit' '--enable-threads' '--prefix=/tmp/.lwv/tcl85' '--with-tcl=/tmp/.lwv/tcl85/lib' 'CC=cc'\"

  This test begins displaying some windows - then doesn't progress. When, after 5 minutes, I issue a kill -15 against the process, I see:

  window.test

  ==== window-2.9 Tk_DestroyWindow, Destroy bindings
          evaluated after exit FAILED
  ==== Contents of test case:

      set code [loadTkCommand]
      append code {
          toplevel .t1
          toplevel .t2
          update
          bind .t2 <Destroy> {puts "Destroy .t2" ; exit 1}
          bind .t1 <Destroy> {puts "Destroy .t1" ; exit 0}
          destroy .t2
      }
      set script [makeFile $code script]
      if {[catch {exec [interpreter] $script -geometry 10x10+0+0} msg]} {
          set error 1
      } else {
          set error 0
      }
      removeFile script
      list $error $msg

  ---- Result was:
  1 {Destroy .t2
  Destroy .t1
  child killed: software termination signal}
  ---- Result should have been (exact matching):
  0 {Destroy .t2
  Destroy .t1}
  ==== window-2.9 FAILED


  For some reason, the Destroy doesn't appear to be running.


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: 747464ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 3 Low
foundin: obsolete: 8.5a0
resolution: Fixed
title: AA-fonts break build when disabled
comment:
  My dev box doesn't have have all the bits for xft
  support present, so I configured with --disable-xft but
  an attempt to make tkUnixRFont.o was still done and
  that failed horribly (the first error is the lack of a
  declaration for XftFont, but that's a symptom of the
  fact that the file should never have been built.)  This
  is critical since it has completely broken my build (I
  have a very old version of autoconf so fixes are more
  than a bit awkward.)

  When I try building with it enabled, I get these
  messages from configure (segment, wrapped)
    [...]
    checking for X... libraries /usr/X11R6/lib, headers
    /usr/X11R6/include
    checking for main in -lXbsd... no
    checking for xft configuration... ./configure:
    pkg-config: command not found
    ./configure: pkg-config: command not found
    configure: WARNING: Can't find xft configuration
    checking whether char is unsigned... no
    [...]
  (That's more info than is present in config.log, BTW)

  'uname -a' output:
    Linux cpipc 2.4.9-34 #1 Sat Jun 1 06:25:16 EDT 2002
    i686 unknown

  Contents of /etc/issue:
    Red Hat Linux release 7.2 (Enigma)
    Kernel 2.4.9-34 on an i686

  (As a side note, when building with xft support
  disabled, I don't get a message during configure to
  confirm this.  It'd be nice if it said that support was
  not being built because of the cmdline option so that
  it is obvious that things aren't getting unfortunately
  ignored.  :^)


tkt_uuid: 1151064fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 4
foundin: None
resolution: None
title: Aqua: XDrawLine draws nothing with Tk_GCForColor
comment:
  The line width for the GC returned by Tk_GCForColor is
  zero.  This results in XDrawLine drawing nothing under
  Aqua, where other platforms a line is drawn with a
  default width of 1.

  Reference Tile Bug #1115785 for more details.


tkt_uuid: 700316ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Fixed
title: OS X Aqua: Preferences menu item disabled in app menu
comment:
  Even if you provide the appropriate
  ::tk::mac::ShowPreferences procedure for handling
  preferences, the 'Preferences...' menu item in the
  application menu will not be enabled unless you have an

          EnableMenuCommand(NULL, kHICommandPreferences);

  call in your Tk interpreter.

  This should probably only be called if the
  ::tk::mac::ShowPreferences proc is defined.


tkt_uuid: 1473475fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Works For Me
title: Runtime error in Windows
comment:
  I've just downloaded the last CVS version (8.5a4) and
  compiled it without problems using mingw32.

  Everything seems to work fine until I try to close the
  application, then I get a runtime error:

  "This application has requested the Runtime to
  terminate it in an unusual way"

  Here is a script that reproduces the problem:

  wm title . "Test Script"
  wm protocol . WM_DELETE_WINDOW "exit"

  Looking a little bit through google I found a workaround:

  wm title . "Test Script"
  wm protocol . WM_DELETE_WINDOW "ExitProc"

  proc ExitProc {} {
    destroy .

    exit
  }

  Until now I was running the ActiveTcl 8.5 version
  without problems, so I imagine is something in my
  compilation or in the code.

  Cheers,
  Carlos.


tkt_uuid: 1189899fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4.11
resolution: Fixed
title: Crash on Windows during TkFinalize with threads
comment:
  A crash occurs during the TkFinalize routine becase the 
  main thread is exiting the application, and the Tk exit 
  handler "assumes" that the exit handlers are valid for all 
  threads.  The DeleteWindowsExitProc proc sends the 
  thread specific data pointer as ClientData 
  [tkWindow.c:363]. Inside of the DeleteWindowsExitProc 
  function a call to Tcl_DestroyWindow 
  [tkWindow.c:2729,2740] and TkCloseDisplay 
  [tkWindow.c:1601] which calls TkpCloseDisplay 
  [tkWindow.c:281] These windows specific functions 
  LOOKUP the thread specific data instead of using the 
  passed ClientData. Since a different thread is 
  calling "TkFinalize" the lists become corrupted.


tkt_uuid: 223313ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
resolution: Fixed
title: many uses of 'glob [file join $dir $pat]' in Tcl and Tk
comment:
  Almost all uses of 'glob [file join $dir $pat]' are bugs.  (Does procheck report an error for these statements?).  If the directory '$dir' contains glob sensitive characters, the command will either fail or return bad results.

  The correct version is:

  glob -dir $dir $pat

  or for 'glob [file join $dir * $pat]' we need:

  glob -dir $dir -join * $pat

  (or variants on that theme).  A search through my 'lib' hierarchy shows the following instances, all of which are bugs.  These are in Tcl's library, Tk's library and in some iwidgets code.

  Vince.

  C:/Program Files/Tcl/lib/iwidgets3.0.0/demos/catalog
  "catalog";                                   Line 392:
  foreach file [lsort [glob [file join ${iwidgets::library} demos *]]] {

  C:/Program Files/Tcl/lib/iwidgets3.0.0/scripts/extfileselectionbox.itk
  "extfileselectionbox.itk";                   Line 791:
      set files [lsort [glob -nocomplain [file join $_pwd $mask]]]

  C:/Program Files/Tcl/lib/iwidgets3.0.0/scripts/fileselectionbox.itk
  "fileselectionbox.itk";                      Line 749:
      set files [lsort [glob -nocomplain [file join $_pwd $mask]]]

  C:/Program Files/Tcl/lib/tcl8.4/package.tcl
  "package.tcl";                               Line 440:
      foreach x [glob -nocomplain [file join $dir *.shlb]] {

  C:/Program Files/Tcl/lib/tcl8.4/package.tcl
  "package.tcl";                               Line 480:
      foreach file [glob -nocomplain [file join $dir * pkgIndex.tcl]] {

  C:/Program Files/Tcl/lib/tcl8.4/package.tcl
  "package.tcl";                               Line 512:
      foreach x [glob -nocomplain [file join $dir *]] {

  C:/Program Files/Tcl/lib/tcl8.4/safe.tcl
  "safe.tcl";                                  Line 499:
  foreach sub [glob -nocomplain -- [file join $dir *]] {

  C:/Program Files/Tcl/lib/tcl8.4/tcltest1.0/tcltest.tcl
  "tcltest.tcl";                               Line 1579:
      [glob -nocomplain [file join $directory $match]]]

  C:/Program Files/Tcl/lib/tcl8.4/tcltest1.0/tcltest.tcl
  "tcltest.tcl";                               Line 1585:
  [glob -nocomplain [file join $directory $skip]]]

  C:/Program Files/Tcl/lib/tk8.4/demos/image2.tcl
  "image2.tcl";                                Line 23:
      foreach i [lsort [glob [file join $dirName *]]] {


tkt_uuid: 1922466fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 31. Cursor Names
priority: 9 Immediate
foundin: obsolete: 8.5.1
resolution: Accepted
title: Segfault setting a cursor with a four parameter list (X11)
comment:
  this small script makes wish segfault on X11

  . configure -cursor {@file.xbm file_mask.xbm black white}

  The problem resides in the file tkUnixCursor.c, line 496,  function CreateCursorFromTableOrFile. According to the comments at the begining and the inTkTable definition, if tkCursorPtr is non NULL then inTkTable is true, otherwise false. Thus the line 496

  if ((!inTkTable && (argc == 2)) || (tkCursorPtr->mask == NULL)) { 

  should be 

  if ((!inTkTable && (argc == 2)) || (inTkTable && tkCursorPtr->mask == NULL)) { 

  to prevent the dereference of tkCursorPtr if it's NULL.

  There is also a logic error in line 535

  if ((maskWidth != width) && (maskHeight != height)) {

  should be 

  if ((maskWidth != width) || (maskHeight != height)) {


  A small patch is attached


tkt_uuid: 748992ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: canvImg.test fails
comment:
  I built current tk cvs against tcl8.4.3 and this fails.
  I did not fail under tk8.4.3 on same machine.

  ==== canvImg-5.1 DeleteImage procedure FAILED
  ==== Contents of test case:

      image create test xyzzy -variable z
      .c delete all
      .c create image 50 100 -image xyzzy -tags i1
      update
      set names [lsort [image names]]
      image delete xyzzy
      set z {}
      set names2 [lsort [image names]]
      .c delete i1
      update
      list $names $names2 $z [lsort [image names]]

  ---- Result was:
  {foo foo2 xyzzy} {foo foo2 xyzzy} {} {foo foo2}
  ---- Result should have been (exact matching):
  {foo foo2 xyzzy} {foo foo2} {} {foo foo2}
  ==== canvImg-5.1 FAILED


tkt_uuid: 404197ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 8
foundin: obsolete: 8.4a2
resolution: Fixed
title: unix/mkLinks bug: incorrect symlink
comment:
  The Tk_Offset.3 manpage is created twice by the mkLinks
  script.

  First, it is created as a symlink to the ConfigWidg.3
  manpage,
  and later on in the script it is created as a symlink
  to the SetOptions.3
  manpage.

  I'm not sure which of these two is the correct symlink,
  but the
  script should be fixed to only create one of these.


tkt_uuid: 1456397fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 86. Test Tools
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Fixed
title: winDialog.test hangs on german windows xp
comment:
  WinDialog.test file hangs on Windows XP SP 2 german.

  It runs with failures through 3.1 and 4.1 (expecting
  Cancel and getting Abbrechen).
  Then the file selection dialog pops up and the bgerror
  message box appears with the following error:

      while executing
  "testwinevent $::tk_dialog $button WM_LBUTTONDOWN 1
  0x000a000b"
      (procedure "Click" line 2)
      invoked from within
  "Click cancel"
      ("eval" body line 2)
      invoked from within
  "eval $command"
      invoked from within
  "set dialogresult [eval $command]"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 {set dialogresult [eval $command]}"
      (procedure "afterbody" line 10)
      invoked from within
  "afterbody"
      ("after" script)


tkt_uuid: 2809525fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 9 Immediate
foundin: obsolete: 8.6b1
resolution: Fixed
title: Abort on overlong color name
comment:
  . configure -bg [string repeat x 65536]

  causes the interpreter to abort with:

  X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
    Major opcode of failed request:  92 (X_LookupColor)
    Serial number of failed request:  3231
    Current serial number in output stream:  3231


tkt_uuid: 1716117fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Accepted
title: improve genstubs/checkstubs
comment:
  With current HEAD of Tcl and Tk:

  $ cd tcl/unix
  $ ./configure
  $ make
  $ cd ../../tk/unix
  $ ./configure --disable-shared --with-tcl=../../tcl/unix
  $ make
  gcc -O2  -pipe    -Wl,--export-dynamic  tkAppInit.o -L/home/dgp/cvs/tk/unix -ltk8.5 \
                  -L/home/dgp/cvs/tcl/unix -ltcl8.5  -lX11 -lXss -lXext -lXft -lXrender -lfontconfig -lfreetype -lX11   -ldl  -lieee -lm  -Wl,-rpath,/home/dgp/i686/linux/lib -o wish
  /home/dgp/cvs/tk/unix/libtk8.5.a(tkStubLib.o): In function `Tk_InitStubs':
  tkStubLib.c:(.text+0x1f): undefined reference to `tclStubsPtr'
  collect2: ld returned 1 exit status
  make: *** [wish] Error 1

  If this is supposed to work, well,
  it doesn't.

  If it's not supposed to work, seems
  to me that Tk's configure script
  would be better off at least warning
  about the incompatible configure options.


tkt_uuid: 219963ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Duplicate
title: wish core dump with scale.test
comment:
  OriginalBugID: 1686 Bug
  Version: 8.1b2
  SubmitDate: '1999-04-01'
  LastModified: '1999-04-19'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: rjohnson
  RelatedBugIDs: 1748  1768
  OS: Digital Unix
  OSVersion: 4.0B
  Machine: Other
  ClosedDate: '1999-04-19'


  CVS: Apr.1, tk8.1, 1.1.4.12
  Extensions: none

  ReproducibleScript:
      ./configure --prefix=/usr/new/src/tk/tk8.1b/Tobedel/installc  --disable-shared --enable-64bit

      make ; make test

      ./configure --prefix=/usr/new/src/tk/tk8.1b/Tobedel/installc  --disable-shared --enable-symbols

      make ; make test

  ObservedBehavior:
      On Digital-Unix-4.0B, up to tcl/tk8.1b1 wish 
      worked fairly well, although thread support 
      was not mature.  However, tcl/tk8.1b2 and 
      cvs versions show many starange behaviours, 
      and crash (core dump). 

      (1) cvs(apr.1) tcl

      make test
      Tests ended at Thu Apr 01 10:35:27 JST 1999
      all.tcl:        Total   8382    Passed  7673    Skipped 701     Failed
      8
      Sourced 115 Test Files.
      Files with failing tests: clock.test if-old.test ioCmd.test safe.test
      Number of tests skipped for each constraint:
              15      95
              16      doTestsWithRemoteServer
              48      emptyTest
              2       hasIsoLocale
              7       installedTcl
              1       japanese
              14      knownBug
              122     macOnly
              151     nonPortable
              16      nt
              302     pcOnly
              1       testthread
              1       umask2
              5       xdev
      /bin/sh: 15581 Bus error - core dumped
      make: *** [test] Error 138

      (2) cvs (apr.1) tk

      make ; make test
      scale.test makes tktest core dump

      dbx tktest core
      dbx version 3.11.10
      Type 'help' for help.
      Core file created by program "tktest"

      signal Floating point exception at   [TkRoundToResolution:1150
      +0x20,0x120095ea0]       new = scalePtr->resolution *
      floor(value/scalePtr->resolution);
      (dbx) where
      >  0 TkRoundToResolution(scalePtr = 0x140323a00, value = Denormalized
      number 0x4022b190) ["./../generic/tkScale.c":1150, 0x120095ea0]
         1 ConfigureScale(interp = 0x14005b200, scalePtr = 0x140323a00, objc =
      8, objv = 0x140061748) ["./../generic/tkScale.c":635, 0x1200951c0]
         2 Tk_ScaleObjCmd(clientData = 0x1401a5520, interp = 0x14005b200, objc
      = 10, objv = 0x140061738) ["./../generic/tkScale.c":323, 0x12009485c]
         3 TclExecuteByteCode(0x10000000a, 0x14005b200, 0x1401310d0,
      0x14011af30, 0x1200e0788) [0x1201224fc]
         4 Tcl_EvalObjEx(0x14005b200, 0x6, 0x14005b200, 0x0, 0x100000000)
      [0x1200e0a68]
         5 Tcl_UplevelObjCmd(0x1200e3c04, 0x14005b200, 0x1, 0x140109e84,
      0x120122458) [0x120120914]
         6 TclExecuteByteCode(0x100000002, 0x1, 0x100000000, 0x14005b200,
      0x1200e0788) [0x1201224fc]
         7 Tcl_EvalObjEx(0x14001b740, 0x2, 0x5, 0x11fffdbb0, 0x0)
      [0x1200e0a68]
         8 TclObjInterpProc(0x140020e70, 0x14038dabd, 0x1200e70f4,
      0x14005b200, 0x0) [0x120121118]
         9 (unknown)() [0x12010e1c0]
        10 (unknown)() [0x1200e74b0]
        11 Tcl_EvalEx(0x1200fbd54, 0x14005b200, 0x1200fbd78, 0x14005b200,
      0x140147220) [0x1200e7dd4]
        12 Tcl_EvalFile(0x0, 0x14005b200, 0x1200e3c04, 0x14005b200,
      0x120137be0) [0x1200fbd94]
        13 Tcl_SourceObjCmd(0x1200e3c04, 0x14005b200, 0x120137be0,
      0x14005b200, 0x120122500) [0x120137bf4]
        14 TclExecuteByteCode(0x100000002, 0x14005b200, 0x14011a600,
      0x1401a2320, 0x1200e0788) [0x1201224fc]
        15 Tcl_EvalObjEx(0x14005b200, 0x2, 0x14011a5d0, 0x0, 0x140020e70)
      [0x1200e0a68]
        16 Tcl_CatchObjCmd(0x120122500, 0x140065800, 0x70597, 0x14010e859,
      0x140061700) [0x12012c190]
        17 TclExecuteByteCode(0x100000003, 0x14005b200, 0x140070d40, 0x1,
      0x1200e0788) [0x1201224fc]
        18 Tcl_EvalObjEx(0x1, 0x1, 0x11fffec58, 0x0, 0x14013e180)
      [0x1200e0a68]
        19 Tcl_ForeachObjCmd(0x1200e70f4, 0x14005b200, 0x0, 0x184, 0x4)
      [0x12012e998]
        20 (unknown)() [0x1200e74b0]
        21 Tcl_EvalEx(0x1200fbd54, 0x14005b200, 0x1200fbd78, 0x14005b200,
      0x11ffff358) [0x1200e7dd4]
        22 Tcl_EvalFile(0x11ffff470, 0x3, 0x120029964, 0x14005b200,
      0x1200321f8) [0x1200fbd94]
        23 Tk_MainEx(argc = 3, argv = 0x11ffff470, appInitProc = 0x12002983c,
      interp = 0x14005b200) ["./../generic/tkMain.c":228, 0x120032244]
        24 main(argc = 4, argv = 0x11ffff468) ["./tkAppInit.c":54,
      0x120029818]

      I've tried tk8.1b2 and cvs with several 
      combinations of thread, 64bit, gcc, shared, 
      without success. 

  DesiredBehavior:
      no core dump

  Comments:

      If you need more information, please ask me. 
      I think there are many users of Digital-unix/
      Tru64-Unix waiting for the fix. 

      I didn't have any problems with tk8.1b1. 



  This bug is reflected in 1748.
  04/07/1999 16:11 - hershey -

  Can't recreate bug this works on all the platforms we have. We really can't address
  this with out a patch or a machine.   04/16/1999 18:27 - rjohnson -


tkt_uuid: 220912ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3b1
resolution: Wont Fix
title: Fix for --disable-shared
comment:
  OriginalBugID: 5299 Bug
  Version: 8.3b1
  SubmitDate: '2000-04-28'
  LastModified: '2000-04-28'
  Severity: LOW
  Status: UnAssn
  Submitter: angie
  ChangedBy: angie
  OS: SunOS
  OSVersion: SunOS
  Machine: Sun Sparc


  Tk 8.3b1 Bug

  Name:  Scott Weikart
  email:  scott@igc.apc.org
  Support:  None
  OperatingSystem:  SunOS
  OperatingSystemVersion:  SunOS 4.1.3, fully patched
  Machine:  Sun Sparc
  Synopsis:  Fix for --disable-shared

  ReproducibleScript:
  Can't build static.


  Patch:
  After running configure --disable-shared, I had to do
     sed 's/ -ldl / /g; s/ -fPIC//g' unix/Makefile > unix/Makefile+ &&
     ln unix/Makefile unix/Makefile- && mv unix/Makefile+ unix/Makefile
  Posted To comp.lang.tcl: Posted Successfully


tkt_uuid: 3091872fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Invalid
title: grid size&rowconfigure memory after destroying all children
comment:
  Issues:
  - grid size does not report "0 0" when all children are destroyed
  - there is a row without widgets occupying space

  Demo:
  newly started wish 8.5.9 on windows vista 32 bit:
  % grid size .
  0 0
  % grid [frame .f1 -bg yellow -width 10 -height 10] -sticky news
  % grid [frame .f2 -bg red -width 10 -height 10] -sticky news
  % grid rowconfigure . all -weight 1
  Resize the window to test
  % destroy {*}[winfo children .]
  % grid size .
  0 2
  This should say "0 0"
  % grid rowconfigure . 1 -weight
  1
  Should this be forgottn ?
  % grid [frame .f1 -bg yellow -width 10 -height 10] -sticky news
  If you resize the window now, the yellow bar does not go to the end.
  A cell without a widget is placed there.


tkt_uuid: 414033ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Fixed
title: jisx0201 encoding
comment:
  A simple typo prevents tk from choosing a font with
  jis0201 encoding to display Japanese strings.

  The typo appears to still exist in the head revision of
  tkUnixFont.c

  the following script should show the problem:
  button .b -text \uFF80
  pack .b


tkt_uuid: 220480ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Windows: entry with -show option copies visible text
comment:
  OriginalBugID: 1687 Bug
  Version: 8.1b2
  SubmitDate: '1999-04-01'
  LastModified: '1999-04-05'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: Linux-SuSE
  OSVersion: SuSE6.0
  Machine: Other
  FixedDate: '1999-04-05'
  FixedInVersion: 8.1b3


  Name:

  Christian Krone


  ReproducibleScript:

      # This script should display in *both* entries five stars.

      # Instead it displays in the second entry the magic word...


      pack [entry .e -show *]

      pack [entry .e2]

      tkwait visibility .e


      .e insert 0 magic

      .e selection range 0 end

      event generate .e <<Copy>>

      event generate .e2 <<Paste>>


  ObservedBehavior:

      On Windows (exactly on systems, where the <<Cut>>, <<Copy>> and

      <<Paste>>

      events are active) the user can make hidden (by means of the -show

      option)

      text visible. She has simple copy (or cut) it into the clipboard and

      then

      paste it into any application (another Tk entry or maybe the Notepad.


  DesiredBehavior:

      The clipboard should see exactly the same text as it is visible on the

      display: The show character and nothing else.


  Patch:

  *** entry.tcl.org       Wed Sep 30 04:17:32 1998

  --- entry.tcl   Thu Apr  1 17:45:14 1999

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

  *** 32,47 ****

    # The code below creates the default class bindings for entries.

    #-------------------------------------------------------------------------

    bind Entry <<Cut>> {

  !     if {![catch {set data [string range [%W get] [%W index sel.first]\

  !           [expr {[%W index sel.last] - 1}]]}]} {

          clipboard clear -displayof %W

          clipboard append -displayof %W $data

          %W delete sel.first sel.last

        }

    }

    bind Entry <<Copy>> {

  !     if {![catch {set data [string range [%W get] [%W index sel.first]\

  !           [expr {[%W index sel.last] - 1}]]}]} {

          clipboard clear -displayof %W

          clipboard append -displayof %W $data

        }

  --- 32,45 ----

    # The code below creates the default class bindings for entries.

    #-------------------------------------------------------------------------

    bind Entry <<Cut>> {

  !     if {![catch {set data [tkEntryGetSelection %W]}]} {

          clipboard clear -displayof %W

          clipboard append -displayof %W $data

          %W delete sel.first sel.last

        }

    }

    bind Entry <<Copy>> {

  !     if {![catch {set data [tkEntryGetSelection %W]}]} {

          clipboard clear -displayof %W

          clipboard append -displayof %W $data

        }

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

  *** 608,610 ****

  --- 606,623 ----

        return $pos

    }


  + # tkEntryGetSelection --

  + #

  + # Returns the selected text of the entry with respect to the -show option.

  + #

  + # Arguments:

  + # w -         The entry window from which the text to get

  +

  + proc tkEntryGetSelection {w} {

  +     set entryString [string range [$w get] [$w index sel.first] \

  +                        [expr [$w index sel.last] - 1]]

  +     if {[$w cget -show] != ""} {

  +       regsub -all . $entryString [string index [$w cget -show] 0] entryString

  +     }

  +     return $entryString

  + }


  PatchFiles:

      entry.tcl




      The patch applies to tk8.0.3, too.
      


tkt_uuid: 2978410fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: tk HEAD fails on HP-UX
comment:
  cc: ".../unix/tkUnixRFont.c", line 90: error 1521: Incorrect initialization.
  cc: "../unix/tkUnixRFont.c", line 90: error 1521: Incorrect initialization.
  cc: ".../unix/tkUnixRFont.c", line 90: error 1521: Incorrect initialization.
  cc: ".../unix/tkUnixRFont.c", line 90: error 1521: Incorrect initialization.

  this is just one line.


tkt_uuid: 1186042fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Rejected
title: Child Process Wish.exe Refuses to Close STDIO Channels
comment:
  Report from m_schrumpf:

  The problem lies in tkConsole/Tk_InitConsoleChannels()
  within ShouldUseConsoleChannel(). When wish.exe is
  started by double-clicking in Windows Explorer, or by
  typing "wish" on the command line, it is detached from
  the calling process' stdio channels. When
  ShouldUseConsoleChannel() is called, it returns 1,
  bailing out early at handle==INVALID_HANDLE_VALUE, ==0,
  or FILE_TYPE_UNKNOWN.

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

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

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


tkt_uuid: 3580194fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 2
foundin: obsolete: 8.5.12
resolution: Wont Fix
title: Width too narrow on MacOS X
comment:
  The -width option on tk_optionMenu results in a widget that is far too narrow to display that many characters on MacOS X. If -indicatoron is 1 the result is even worse (even less of the text is displayed). For example:

  tk_optionMenu .om omVar DC1 DC2 DC3
  .om configure -width 3
  pack .om

  this displays as expected on Linux, but the widget is far too narrow on MacOS X.


tkt_uuid: 220060ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Duplicate
title: naming a TCL script "button.tcl" causes run time error
comment:
  OriginalBugID: 4094 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-26'
  LastModified: '2000-01-26'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2691
  OS: Windows 95
  ClosedDate: '2000-01-26'


  Name:
  paul battersby

  ReproducibleScript:
  I place the following text in a file called "button.tcl"

    .button myButton -text "hello"
     pack .button

  I run this by typing 

     wish83 button.tcl

  When I move the mouse in to the window continaing the button, I get the following error:

     Error: unknown option "-state"

  What I have discovered is that the problem is the name of the TCL script. I cannot name the file "button.tcl" If I rename it to something else, there is no error.

  ObservedBehavior:
  Stack trace:

  unknown option "-state"
      while executing
  "$w cget -state"
      (procedure "tkButtonEnter" line 3)
      invoked from within
  "tkButtonEnter .
  "
      (command bound to event)

  DesiredBehavior:
  I don't expect to see any error simply because of the name of my ".tcl" script.



  The problem occurs when confusion arises over class names.
  A script takes the root filename of the script as the class
  name for the primary toplevel.  Tk will then tie that in
  to known classes when creating the toplevel, so a toplevel
  will try to be configured with class Radiobutton... 
   
  -- 01/26/2000 hobbs


tkt_uuid: 3610491fffffffffffffffffffffffffffffffff
type: Patch
status: Deleted
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: Keyboard is ignored with SCIM
comment:
  This is a continuation of 905830 and, maybe, 1919791.
  If there is environment variable XMODIFIERS is equal to "@im=SCIM" and scim is running, then in quite often Tk ignores keyboard input.
  I am attaching a simple Tk testcase.  It fails with wish 8.4 and 8.5.  OS is Red Hat 5.3, desktop is Gnome.
  We had several ways to reproduce the problem, but I selected a shortest one, using tool tips.  I am attaching a script implementing tool tips that
  I found years ago and modified a little bit for us.
  To reproduce the problem:
  1) Find Gnome on Red Hat or possible other Linux.
  2) copy both files to any place.
  3) setenv XMODIFIERS "@im=SCIM"
  4) wish s.tcl
  5) move mouse to entry or text widget and wait till a tool tip appears
  6) try to type
  7) you may need to move mouse in and out the area to update tool tips.
  That's it.
  Clicking on other window and then back helps to restore input for a while.


tkt_uuid: 940220ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 62. Geometry Functions
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: None
title: wm geometry contradictions (and inadequately documented
comment:
  The documentation of "wm geometry $win" doesn't make
  clear whether the quantities referred to are relative
  to the toplevel window's border or the window manager
  decoration (titlebar, menubar with configure -menu, etc).

  In fact on windows, the returned value is:

  contentsWidth x contentsHeight
  + decorationLeft + decorationTop

  which is rather surprising.  This means to find the
  total number of vertical pixels covered by the
  toplevel, including any menubar/titlebar/border, we
  must perform a complex calculation (and must actually
  assume the bottom edge and right edge decoration are
  the same thickness as the left edge decoration).  So,
  here's a function to determine, as best possible, the
  total geometry covered by a window:

  proc default::totalGeometry {{w .}} {
      set geom [wm geometry $w]
      regexp -- {([0-9]+)x([0-9]+)\+([0-9]+)\+([0-9]+)}
  $geom -> \
        width height decorationLeft decorationTop
      set contentsTop [winfo rooty $w]
      set contentsLeft [winfo rootx $w]
      
      # Measure left edge, and assume all edges except
  top are the
      # same thickness
      set decorationThickness [expr {$contentsLeft -
  $decorationLeft}]
      
      # Find titlebar and menubar thickness
      set menubarThickness [expr {$contentsTop -
  $decorationTop}]
      
      incr width [expr {2 * $decorationThickness}]
      incr height $decorationThickness
      incr height $menubarThickness
      
      return [list $width $height $decorationLeft
  $decorationTop]
  }

  Nowhere in the documentation are these issues/terms
  made clear.  So, while I know the above works on
  Windows, I really cannot be sure it works on other
  platforms.  The documentation should be fixed (and this
  proc could be used as an example, perhaps).


tkt_uuid: 1189938fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Fixed
title: Can't get active menu index
comment:
  Tk: v8.5a3
  OS: WinXPsp2
  Built with makefile.vc using VC7.1


  After the change to tkWinMenu.c on 18-01-2005 
  the 'active' menu index is no longer returned.

  [.menu.foo index active] will now always return none.

  this in itself probably isn't fatal, but if a script 
  attempts [.menu.foo entrycget active -label] things 
  can start going a bit crazy :)

  removing the extra condition check on line 1242 fixes 
  this, but re-introduces the bug it was put there to 
  stop.


tkt_uuid: 749353ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 8
foundin: obsolete: 8.4.3
resolution: Fixed
title: Tk crash on exit in tkImage.c
comment:
  Please use the following steps to reproduce the problem:

  #1. Run the attached game script on a Windows 
  machine (not sure if the bug manifests itself on Unix).
  #2. The game has been modified so that it will 
  continuously cascade. Simply swap two of the pieces 
  and watch the action fly for a while.
  #3. Attempt to exit the game by closing the window.

  This bug works equally well with 8.4.x and the current 
  CVS HEAD.

  Tk will crash upon calling Tcl_DeleteHashEntry in 
  tkImage.c near line #680:

      if ((masterPtr->typePtr == NULL) && (masterPtr-
  >instancePtr == NULL)) {
          Tcl_DeleteHashEntry(masterPtr->hPtr);
  ckfree((char *) masterPtr);
      }

  Based on my research, it appears that Tk is attempting 
  to delete an already deleted hash entry.

  If you change the code to the following, the crash is not 
  seen:

      if ((masterPtr->typePtr == NULL) && (masterPtr-
  >instancePtr == NULL)) {
          if (!masterPtr->deleted) {
             Tcl_DeleteHashEntry(masterPtr->hPtr);
          }
  ckfree((char *) masterPtr);
      }

  Since I am not an expert in Tk, I am not sure if this 
  slight modification gets to the "heart" of the actual 
  problem.  For example, why would Tk attempt to delete 
  the same hash entry twice?

  Here is the stack trace:

  Tcl_DeleteHashEntry(Tcl_HashEntry * 0x00dc8f28) line 
  518 + 3 bytes
  Tk_FreeImage(Tk_Image__ * 0x00db0680) line 680 + 19 
  bytes
  DeleteImage(Tk_Canvas_ * 0x00dd04b8, Tk_Item * 
  0x00e2c9b0, _XDisplay * 0x009c32c0) line 412 + 12 
  bytes
  DestroyCanvas(char * 0x00dd04b8) line 1951 + 24 bytes
  Tcl_Release(void * 0x00dd04b8) line 241 + 7 bytes
  CanvasBindProc(void * 0x00dd04b8, _XEvent * 
  0x00e2ccb8) line 4537 + 16 bytes
  Tk_HandleEvent(_XEvent * 0x00e2ccb8) line 1010 + 17 
  bytes
  WindowEventProc(Tcl_Event * 0x00e2ccb0, int -3) line 
  1414 + 12 bytes
  Tcl_ServiceEvent(int -3) line 625 + 11 bytes
  Tcl_DoOneEvent(int -3) line 930 + 9 bytes
  Tk_MainLoop() line 1472 + 13 bytes
  Tk_MainEx(int 1, char * * 0x00866e20, int (Tcl_Interp *)
  * 0x004010b9 Tcl_AppInit(Tcl_Interp *), Tcl_Interp * 
  0x0086ade8) line 284
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 
  0x00000000, char * 0x001335d5, int 1) line 130 + 26 
  bytes
  WinMainCRTStartup() line 330 + 54 bytes


tkt_uuid: 1938774fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Duplicate
title: disable send -> X error on exit
comment:
  dgpHas something changed from Tk 8.4 -> Tk 8.5 when the [send] command is deleted?
  dgpI have a "big wish" program.
  dgpWhen I build it with Tcl/Tk 8.4.18, I can [rename send {}], and things work fine
  dgpWhen I build with core-8-5-branch, and enter [rename send {}; exit] at the interactive prompt, I get an X error....

  dgp$ ./omfsh
  X Error of failed request:  RenderBadPicture (invalid Picture parameter)
    Major opcode of failed request:  155 (RENDER)
    Minor opcode of failed request:  7 (RenderFreePicture)
    Picture id in failed request: 0x260003f
    Serial number of failed request:  1525
    Current serial number in output stream:  1582
  dgplook familiar to any Tk experts?


tkt_uuid: 1069137fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: None
resolution: Fixed
title: WinXP: scrollbar test failure patch [Bug 1067249]
comment:
  The failure is in the calculation of delta for 
  scrollbars. Changing this affects a couple of tests 
  that have incorrect calculations (delta and 
  fraction). Also unix's scrollbar calculates an 
  incorrect sliderLast. This patch fixes these but 
  doesn't touch other hard-coded results in 
  scrollbar.test that are inaccurate, due to the test 
  scrollbar being generated having a possible variable 
  size.


tkt_uuid: 1243318fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: evt.x, y sometimes very wrong on Aqua
comment:
  evt.x and evt.y are often very wrong when binding to <B1-Motion> at 
  least. I see this on a canvas, where I automtically show information 
  about the pixel under the mouse. It usually works but sometimes is 
  way off (e.g. half a screen or so; it varies).

  Details:
  - I only have seen this is after I switch from my tcl/tk application to a 
  different application and then back again. Unfortunately, that does 
  not always make it happen so it has been hard to study.
  - While it is happening, not only are <...Motion> mouse coordinates 
  way off, but pop-up menus are also shown in the wrong location on 
  the screen. However, other things continue work just fine, such as 
  clicking in an entry field, selecting text and pressing buttons.
  - Once it happens, it appears that simply moving the toplevel 
  window resets the mouse coordinates.

  This is almost certainly caused by the same bug that causes PR [ 
  1032941 ] menu bar menus sometimes in wrong place under aqua.

  If there is any way to get this bumped up in priority it would be a big 
  help. It causes a LOT of trouble on MacOS X on my application and 
  it is by far the most noticeable and serious Aqua Tk bug that my 
  users run into. A fix or a workaround would be much appreciated.

  -- Russell


tkt_uuid: 969230ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 4
foundin: obsolete: 8.4.6
resolution: Out of Date
title: Mac-Problem with AppleScript in tkMacOSXHIEvents.c
comment:
  I have a problem with the "do script" command in AppleScript, for 
  a TCL/TK application (aMSN)

  Can someone look at this web page? My problem is exactly the 
  same.

  http://frontier-osx.userland.com/discuss/msgReader$1028

  I get  that error when I try to execute an AppleScript 
  "AEDoScriptHandler: invalid script type 'UTXT', must be 'alis' or 
  'TEXT'", with my iTunes Script. I think it can be fixed with the 
  solution #3 on the userland webpage, but I'm not good either to 
  make the fix by my self. The fix should be do in 
  tkMacOSXHLEvents.c
  Thanks :-)

  -- by Edgar C. Rodriguez, Daniel Buenfil and Jérôme Gagnon-Voyer
  --iTunes script to get Path and Name of current track playing, write 
  to a text file, and change the nick in aMSN


  tell application "System Events"
  set iTunes to ((application processes whose (name is equal to 
  "iTunes")) count)
  end tell

  if iTunes is greater than 0 then
  tell application "iTunes"
  --if iTunes is playing, return the artist, the song name and 
  the path (in Unix)
  set newSong to path to application "aMSN" as Unicode text
  set fSong to newSong & "Contents:Resources:Scripts:
  Utils:" & "SongInfo"

  open for access fSong with write permission
  set eof of the fSong to 0
  write "iTunes" & return to fSong starting at eof

  if player state is playing then
  write "Play" & return to fSong starting at eof
  if class of current track is URL track then
  set aSong to name of current track
  set finalpath to 0
  write aSong & return & finalpath & return to fSong 
  starting at eof
  else if class of current track is shared track then
  set aSong to name of current track
  set aArt to artist of current track
  set finalpath to 0
  write aSong & "-" & aArt & return & finalpath & 
  return to fSong starting at eof
  else if class of current track is audio CD track then
  set aSong to name of current track
  set aArt to artist of current track
  set finalpath to 0
  write aSong & "-" & aArt & return & finalpath & 
  return to fSong starting at eof
  else if class of current track is file track then
  set aSong to name of current track as text
  set aArt to artist of current track
  set firstpath to current track's location
  if firstpath is not missing value then
  set finalpath to POSIX path of firstpath
  else
  set finalpath to 0
  end if
  write aSong & "-" & aArt & return to fSong as 
  string starting at eof
  write finalpath & return to fSong starting at eof
  close access fSong
  set fuckingscript to "::MSN::changeName" & 
  aSong as string
  tell application "Wish Shell-soon-final"

  do script fuckingscript as Unicode text
  end tell
  end if


  --if iTunes is paused, return that message
  else if player state is paused then
  write "0" & return to fSong starting at eof
  close access fSong
  --if iTunes is stopped, return that message
  else if player state is stopped then
  write "0" & return to fSong starting at eof
  close access fSong
  end if
  end tell
  --if iTunes is not open
  else
  --i'm not able to do this thing work??!!!
  --set newSong to path to application "aMSN" as Unicode text
  --set fSong to newSong & "Contents:Resources:Scripts:Utils:" 
  & "SongInfo"
  --open for access fSong with write permission
  --set eof of the fSong to 0
  --write "iTunes" & return to fSong starting at eof
  ---write "0" & return to fSong starting at eof
  --close access fSong

  end if


tkt_uuid: 1724460fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 60. [tk_setPalette]
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Fixed
title: tk_setPalette background fails
comment:
  I tested a prerelease of TkAqua provided by Daniel Steffen which included some very welcome improvements to Aqua support. The one bug I found was this (running from wish):

  % tk_setPalette background white
  unknown color name ""

  Repeating the command gives a different error:

  % tk_setPalette background white
  window name "___tk_set_palette" already exists in parent


tkt_uuid: 1821939fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5b2
resolution: Duplicate
title: scroll wheel not working in ttk::treeview on OSX
comment:
  This is in Aqua only:  Using the widget demo, the tree view example ("A directory browser tree") shows incorrect behavior with the scroll wheel.  The widget & scrollbar will scroll down, but not up.  The scroll wheel works correctly for all other demos.  It also works correctly when the pointer is over the scrollbar.


tkt_uuid: 1171762fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Works For Me
title: prepare variable like TCL_PACKAGE_PATH in tcl.
comment:
  I don't know whether this is the problem of Fedora
  Core, tk, or blt.

  On Fedora Core and Red Hat Enterprise and its clone
  distributions, tk is made as 
    make TK_LIBRARY=/usr/share/tk8.4.9

  As a result, pkgIndex.tcl is installed to
  /usr/lib/tk8.4.9/ and other stuff installed to
  /usr/share/tk8.4.9/.

  And then, build BLT from source, bltwish cannot find
  tk.tcl.
  So I request to add a mechanism like TCL_PACKAGE_PATH
  in tcl.


tkt_uuid: 435660ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: Mac code changes up-port from 8.3.3 Tk
comment:
  Attached the patch bringing forward the mac specific 
  code changes from Tk 8.3.3 and adding some new changes 
  for 8.4.  A detailed ChangeLog is included.

  New 8.4 changes include a mac resource reorganization 
  and a fix to tkMacButton.c.

  The changes from 8.3.3 have already been looked at 
  briefly by Jeff Hobbs when he checked them in for 8.3.3, 
  but I am grateful for more code review. 

  new files and modified binary files are attached 
  separately.

  The following file can be removed from the repository 
  when committing this patch: (in tk/mac/) tkMacShLib.exp

  one file affected by this patch is in an area that I 
  don't co-maintain; a trivial, mac conditionalized change 
  to tkPointer.c

  Approval for committing this patch is thus needed from 
  the maintainers of the following areas:

  63.Generic Window Operations - JH - generic/tkPointer.c


tkt_uuid: 778893ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: None
resolution: Fixed
title: opaqueresize option does nothing
comment:
  The documentation for the panedwindow widget claims
  that the opaqueresize option "Specifies whether panes
  should be resized as a sash is moved (true), or if
  resizing should be deferred until the sash is placed
  (false)."

  In fact, under X and Win32 this option has no effect.
  Examination of the source code shows that this option
  is never used.

  Either the documentation should be fixed or this
  feature should be implemented.


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

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


tkt_uuid: 2983824fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Image output format autodetection broken
comment:
  When writing to any popular image format (PNG, GIF, BMP, TIFF) an image containing antialiased text (for example one from a canvas captured through img::window), the 256-entry color palette overflows quickly, and the [$im write $file] command errors with "too many colors".
  So, bottom line, it is impossible to save a canvas's contents to any practical image format, even with [package require Img].
  By "practical" I mean, something that a typical Windows end-user could manipulate and/or paste into Word...

  I acknowledge the fact that this is 50% of the "Printing in Tcl" issue. However, it is much simpler since it doesn't go all the way to the printer.

  Note that this impossibility could be attenuated by a workaround like disabling antialiasing in the canvas, but I don't know how to.
  Alternatively, supporting truecolor (instead of indexed palette) in just one of these formats would do.


tkt_uuid: 1516950fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Fixed
title: keyboard shortcut command-q only works when menu is open
comment:
  The by-default-existing keyboard shortcut command-q only works
  when any menu is open.

  How to reproduce:
  Start Wish.app. (Do not move the focus to the console.)
  Press <Command-q>.
  Nothing happens.
  Open the Wish menu.
  Press <Command-q> again.
  Wish quits.

  I expected Wish to quit on the first use of <Command-q>, since
  the keyboard shortcut is displayed in the menu.

  Explicitly binding to <Command-q> works. The Problem is, that
  the keyboard shortcut is displayed in the Wish menu from the
  beginning but not working properly.


tkt_uuid: 2859912fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: error recovery from multiple managers
comment:
  If a master window has slave widgets managed by [pack], it won't accept slaves managed by [grid]
  Trying to do so not only returns an error (the desired behaviour) but also creates graphical artifacts, and the offending widget will be incorrectly returned in [grid slaves]
  The same happens with vice-versa: first [grid] and then [pack].

  Example:
  C:\>tclsh
  % package require Tk
  8.6b1.1
  % pack [button .b -text btn]
  % grid [label .l -text lbl]
  cannot use geometry manager grid inside . which already has slaves managed by pack
  % #at this point main window starts flickering
  % pack slaves .
  .b
  % grid slaves . ;# should return empty string
  .l


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: 2191960fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: Fixed
title: tests use identity encoding
comment:
  A few tests in unixSelect.test
  make use of the "identity"
  encoding.

  Test winClipboard-1.5 uses the
  command [tcltest::bytestring]
  which is based on the "identity"
  encoding.

  These tests are old.  Hoping there's
  someone who can comment on what
  they're meant to test.  Furthermore
  whether the same testing objective
  can be met using some part of Tcl
  that we actually want to keep around. :)


tkt_uuid: 801011ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: Rejected
title: Wish should remain resident
comment:
  Wish should remain resident on Mac OS X. There's a fairly 
  significant startup overhead for Aqua applications, and on 
  my G3/400 it takes several seconds to launch. This makes 
  it too "heavy" for casual applications (for example, in 
  OnMyCommand scripts). Running a "Wish" in the 
  background doesn't help, because it launches a separate 
  instance for each application.


tkt_uuid: 227980ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: None
title: double-click doesn't trigger any event on Korean WIN98/NT
comment:
  ReproducibleScript:
  SCRIPT:
  bind . <Double-1> {puts  2}
   
  command line : wish82.exe <scriptname> > <outfile> 
   
  ObservedBehavior:
  On the Korean (Windows 95/98/NT) systems, double-click does not seem to trigger any event (output file is empty). This behaviour was not detected on other language systems.


tkt_uuid: 531658ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: None
title: ButtonRelease on Grab Window
comment:
  I have a problem with the ButtonRelease bind on a 
  window that has the grab if I move off the window with 
  the button depressed and then release it.
  Platform: Windows 2000

  Steps to reproduce:
  1. Create a window:

      toplevel .testWindow -class Toplevel
      wm focusmodel .testWindow passive
      wm geometry .testWindow 406x312+254+250
      wm title .testWindow "Login"
      entry .testWindow.userId
      place .testWindow.userId -in .testWindow \
            -x 145 -y 80
      grab .testWindow
      # Done

  NOTE: You must make sure the window has the grab.

  2. Place the cursor in the entry widget and type
     the "123456789"

  3. Hold down the LMB and highlight what you just typed.
     Without releasing the LMB, move the mouse over 
     to the Windows Desktop and then release the LMB.

  4. Move the mouse back over the .testWindow. TK acts 
     like the LMB is still depressed. If you start
     typing with everything highlight, input appears to
     the left because it acts like you have the first
     character highlighted.


tkt_uuid: 1013520fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 2
foundin: None
resolution: Fixed
title: spelled docs
comment:
  Affected files:
  ConfigWidg.3 CrtItemType.3 FontId.3 GetBitmap.3 
  GetDash.3 GetHWND.3 GetVRoot.3 MeasureChar.3 
  SetClassProcs.3 SetOptions.3 

  Question:
  GetCursor.3, lines 119-121:
  In addition, Tk will load Macintosh cursor resources of 
  the types crsr (color) and CURS (black and white) by 
  the name of the of the resource.
  ???
  1) by the name of the resource.
  2) by the name of the (something? e.g. file, class ...) of 
  the resource.


tkt_uuid: 865842ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Accepted
title: Patch to fix Win32 disabled cascade menus
comment:
  There is a problem with disabled Win32 cascade menu
  items in Tk. Regular Windows application will show
  a gray right facing arrow for a cascade menu item
  that is disabled. Tk instead shows the little arrow
  painted black. This is really confusing because it
  makes the cascade look selectable.

  I have attached a file named menu.c that shows
  the Win32 code for an example menu. It demonstrates
  how Tk should operate. I have also attached a file
  named menu.tcl, it should look and function the
  same as the menu.c example, but it does not. If
  you open up the Tk version, you will see that the
  cascade menu item is drawn with a black color
  even though the cascade is disabled.

  The bug is actually in the Win32 code, it should
  draw the arrow gray. so we need to work around
  that. First, we avoid telling the OS that the
  Window is a popup type, that way it will not
  draw an arrow for us. Then, when we get
  the callback to draw the contents of the menu,
  we draw the arrow on our own. This is all made
  a little tricky because we don't know exactly
  where to put the arrow, and it is not the same
  on 95 vs XP systems, but the patch deals with
  those issues.


tkt_uuid: 222018ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
resolution: Invalid
title: grid does not always honor -sticky
comment:
  When building two frames that are packed to expand to
  fit their container, and filling them with different 
  numbers of widgets, grid .frame$x.widget$y -sticky nw,
  the widgets in the less filled frame cling to the bottom
  instead of the top.

  This code (perhaps too complex) demonstrates the behavior.
  The pack commands do what I expected the grid commands
  to do - stack the widgets from top to bottom in both 
  windows.  The grid command fills the left frame, and the
  widgets cluster to the bottom in the right hand frame.

  ########## Demonstrate unexpected grid behavior
  ########## pack and grid code should generate equivalent
  ########## displays, but do not.

  catch {destroy .c} 

  canvas  .c -height 200 -width 100 -background white
  pack .c
  frame .c.f
  .c create window 1 1 -anchor nw -window .c.f

  frame .c.f.f1 -background pink
  frame .c.f.f2 -background yellow

  grid .c.f.f1 -row 0 -column 0 -sticky news
  grid .c.f.f2 -row 0 -column 1 -sticky news

  for {set i 0} {$i < 10} {incr i} {
    checkbutton .c.f.f1.b$i -text $i -textvar foo1
    grid .c.f.f1.b$i -row $i -column 1 -sticky nw 
  #   pack .c.f.f1.b$i -side top -anchor w
  }
   
  for {set i 0} {$i < 8} {incr i} {
    checkbutton .c.f.f2.b$i -text $i -textvar foo2
    grid .c.f.f2.b$i -row $i -column 1 -sticky nw 
  #   pack .c.f.f2.b$i -side top -anchor w
  }
   


tkt_uuid: 714956ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 7 High
foundin: obsolete: 8.5a0
resolution: Fixed
title: window-2.9 hangs when threads enabled
comment:
  With a --enable-threads build of Tcl,
  running `make test` for Tk leads to
  test window-2.9 hanging.

  Solaris 8, using a Forte compiler.


tkt_uuid: 1719278fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: select test cases fail
comment:
  Platform: sparc solaris 9, latest tcl/tk cvs head, sun compiler, sun gnome desktop, windows xp exceed 10 x server

  The following errors are occurring:

  ==== select-10.1 ConvertSelection procedure, race with selection clear FAILED
  ==== Contents of test case:

      setup
      proc Ready {fd} {
          variable x
          lappend x [gets $fd]
      }
      set fd [open "|[list [interpreter] -geometry +0+0 -name tktest]" r+]
      puts $fd "puts foo; [loadTkCommand]; flush stdout"
      flush $fd
      gets $fd
      fileevent $fd readable [list Ready $fd]
      set selValue "Just a simple test"
      set selInfo ""
      selection handle .f1 {handler STRING}
      update
      puts $fd {puts "[catch {selection get} msg] $msg"; puts **DONE**; flush stdo
  ut}
      flush $fd
      after 200
      selection own .
      set x {}
      vwait [namespace which -variable x]
      puts $fd {exit}
      flush $fd
      # Don't understand why, but the [loadTkCommand] above causes
      # a "broken pipe" error when Tk was actually [load]ed in the child.
      catch {close $fd}
      lappend x $selInfo

  ---- Result was:
  {1 PRIMARY selection doesn't exist or form "STRING" not defined} {STRING 0 4000}
  ---- Result should have been (exact matching):
  {1 PRIMARY selection doesn't exist or form "STRING" not defined} {}
  ==== select-10.1 FAILED

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

      setup
      setupbg
      set selValue [string range $longValue 0 3999]
      set selInfo ""
      selection handle .f1 {handler STRING}
      set result ""
      lappend result [dobg {selection get}]
      cleanupbg
      lappend result $selInfo

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

      setup
      setupbg
      set selValue $longValue
      set selInfo ""
      selection handle -type TEST .f1 { handler TEST }
      selection handle -type STRING .f1 { reallyBadHandler .f1 STRING }
      set result ""
      set pass 0
      lappend result [dobg {selection get}]
      cleanupbg
      lappend result $selInfo

  ---- Result was:
  {PRIMARY selection doesn't exist or form "STRING" not defined} {.f1 STRING 0 400
  0 .f1 STRING 4000 4000 .f1 STRING 8000 4000 .f1 STRING 12000 4000 .f1 STRING 160
  00 4000 .f1 STRING 0 4000 .f1 STRING 4000 4000}
  ---- Result should have been (exact matching):
  {selection owner didn't respond} {.f1 STRING 0 4000 .f1 STRING 4000 4000 .f1 STR
  ING 8000 4000 .f1 STRING 12000 4000 .f1 STRING 16000 4000 .f1 STRING 0 4000 .f1 
  STRING 4000 4000}
  ==== select-11.1 FAILED


tkt_uuid: 2825888fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: Off-by-one errors in overlap computation of text items
comment:
  The semantics of the right and bottom edges of the rectangle passed to [find overlapping] are off by one for text items in a canvas.
  Comparing text and rect:

  % .c create rect 100 100 150 150
  1
  % .c create text 100 100 -text abc -anchor nw
  2
  % .c bbox 1
  99 99 151 151
  % .c bbox 2
  99 100 121 115
  % .c find overlapping 0 0 99 300
  2

  So, for rect (and other item types as well), the right and bottom edges of the test rectangle are considered outside, while for text items they are considered inside.
  IOW, the "normal" semantics of the rectangle is a cartesian product of two half-closed intervals:
   [left,right[ * [top,bottom[
  while for text items it uses closed intervals:
   [left,right] * [top,bottom]

  This can be traced to surprising use of < and <= in tkFont.c in the Tk_IntersectTextLayout function:

  if ((right < x1) || (left >= x2)
  || (bottom < y1) || (top >= y2)) {

                 [CONSIDER "OUTSIDE"]

  here I would replace the two strict "<" by "<=".

  One thing to note is that the above behavior has changed rather recently in Tcl history (absent in 8.5.5), while that part of the code has not changed since the beginning. Maybe changing contracts in the rest of the code...

  Also note this is *not* a consequence of the 2328657 fixes; but I detected the behavior while analysing that bug.


tkt_uuid: 3285355fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 7 High
foundin: obsolete: 8.6b1
resolution: Fixed
title: Active Tcl/Tk 8.6b5 hangs for simple example
comment:
  When selecting Open in the attached Tcl/Tk script an error message should appear and report that procWhichDoesNotExist does not exist. However, Tcl/Tk seems to hand, displaying a white rectangle (where the error message should be) in front of all other windows. Even switching to other Mac applications does not make the rectangle disappear; only killing Wish works (using Force Quite for example).

  The bug appears on a MacPro Intel Xeon 6-core processor using the latest Active Tcl/Tk 8.6b5. 
  This bug is an example for a variety of similar issues which currently make Tcl/Tk unusable on the Mac (at least for our application). I believe that 8.5.9.2 has the same problem (Active Tcl 8.5.9.0 works perfectly).

  This bug was previously posted as bug #89715 to http://bugs.activestate.com.


tkt_uuid: 1479587fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: Tk_Init deadlocks when called twice
comment:
  When Tcl and Tk are compiled with --enable-threads,
  Tk_Init deadlocks the second time when it failed to
  create a top level window the first time, as
  demonstrated with the program:

  #include <tcl.h>
  #include <tk.h>

  int main(void) {
      Tcl_Interp *trp;
      unsetenv("DISPLAY");
      trp = Tcl_CreateInterp();
      printf("%d\n", Tk_Init(trp));
      printf("%d\n", Tk_Init(trp));
      return 0;
  }

  On Debian, this prints 1, then deadlocks.

  Attached patch fixes the problem; the second missing
  unlock call was found by source inspection. I haven't
  checked whether other resources also need to be cleaned
  up in case of error.


tkt_uuid: 1513517fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 4
foundin: obsolete: 8.4.15
resolution: Wont Fix
title: .text search -regexp wraps despite stopIndex is specified
comment:
  The help page for the text widget states that (.text 
  search command):

  If stopIndex is omitted, the entire text will be 
  searched: when the beginning or end of the text is 
  reached, the search continues at the other end until 
  the starting location is reached again; if stopIndex 
  is specified, no wrap-around will occur.

  However, the following demonstrates that wraparound 
  occurs when start and stop indices are both equal to 
  [.t index end]

  text .t
  pack .t
  .t insert end "hello1\n"
  .t insert end "hello2\n"
  .t insert end "hello3\n"
  .t insert end "hello4\n"
  set ind [.t index end]

  # WRONG: returns 1.0 -> it wraps!
  .t search -regexp -- "^" $ind $ind

  # CORRECT: returns 5.0
  .t search -regexp -- "^" $ind-1c $ind

  # WRONG: returns 1.2 -> it wraps!
  .t search -- "llo" $ind $ind           

  # CORRECT: returns ""
  .t search -- "llo" $ind-1c $ind


  Therefore, contrary to the claims of the manual, the 
  search wraps if the start and stop indices are both 
  equal to [.t index end] (which is not so uncommon 
  during a search for all the occurrences of a string 
  in a text).


  Francois


tkt_uuid: 2778846fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Duplicate
title: -underline 1 for font create does not work in 8.5.x
comment:
  I have not been able to create an underlined font.  I changed the button.tcl demo (in demos/Tk8.5) so that it has this line:

  button $w.b1 -text "Peach Puff" -font [font create -family helvetica -size 20 -underline 1] -width 10 \

  instead of 

  button $w.b1 -text "Peach Puff" -width 10 \

  (attached is the changed file)
  and the "Peach Puff" button changes size but it does not have the underline in the font.  I am running CentOS 5.2

  does anyone have any idea how to get the underline text on Tk Buttons?

  Thanks,

  Blaine


tkt_uuid: 3561016fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 9 Immediate
foundin: obsolete: 8.5.12
resolution: Fixed
title: -type tearoff segfault
comment:
  ---a.tcl------8<---------
  menu .mb -type tearoff
  ------------8<---------

  $ wish a.tcl
  Segmentation fault (core dumped)


tkt_uuid: 1201494fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Duplicate
title: Aqua Tk 8.4.x CVS entry widgets too big
comment:
  The entry widgets  new TclTkAqua 8.4.9.1 installer are too big. 
  There is a large margin (5 or so) pixels around the text.

  This bug did NOT appear in TclTkAqua 8.4.9.0 installer. The 8.4.9.1 
  installer used the CVS head for 8.4.x, so some bug has crept 
  into tk aqua since the 8.4.9 release.

  (I suspect I got the group wrong; I didn't see any entry for post-8.4.9 
  CVS and I doubt this is an 8.5 prerelease, but I don't know the how 
  you're labeling the current trunk).


tkt_uuid: 458124ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Duplicate
title: Dialog box doesn't return after button
comment:
  In Tk 8.4a3, a tk_dialog box never pops down when
  a button is pressed. This is because the buttons
  are initialized so that they set a different
  variable than the dialog code is waiting for --
  this must be a result of the Tk internal stuff
  being moved into its own namespace earlier on.

  On line 107 of lib/tk8.4/dialog.tcl there is a
  reference to »Priv(button)« which should be amended
  to »::tk::Priv(button)«. If this is done everything
  works fine.


tkt_uuid: 3089640fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: Improve squeezing of notebook tabs
comment:
  The current squeezing algorithm for ttk::notebook tabs adjusts each tab by the same number of pixels. As a result, the smaller tabs disappear quickly, There is also a -mintabwidth style option, but this doesn't work well either: first all tabs are reduced to the minimum width, but if there is still not enough place, the rightmost tabs will disappear again.
  The fact that tabs can disappear has been reported as a problem numerous times on comp.lang.tcl. An ideal solution would allow the tabs to be scrolled, but this seems to be quite hard. A different squeezing algorithm, which squeezes each tab relative to its width, can however also improve the current behavior.
  Attached is a patch with this modified squeezing algorithm. Note that it ignores -mintabwidth completely, as this does not make much sense anymore in the new algorithm. (The mintabwidth did not work well anyway, because it was already ignored in TabRowSize().)


tkt_uuid: 564146ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Works For Me
title: Russian translation file
comment:
  This file contains russian translation for Tk messages.
  However, inclusion of this file is DANGEROUS while
  patch #563140 is not applied - this will make tk less
  usable for russian users. This may be true for other
  translation files as well - without #563140, binding
  accelerator keys in msgbox.tcl triggers error for any
  button having label with the first char being non-ascii.


tkt_uuid: 220744ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: Add scrolling for long error messages
comment:
  OriginalBugID: 5782 RFE
  Version: 8.4a1
  SubmitDate: '2000-06-01'
  LastModified: '2000-06-19'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-06-19'
  FixedInVersion: 8.4a2


  Name:
  Don Porter

  CVS:
  $Id: bgerror.tcl,v 1.9 2000/05/31 23:28:46 ericm Exp $

  DesiredBehavior:
  $ wish
  % after 0 [list error [string repeat a\n 50]]
    <error dialog appears.
     however, it is so tall that both top and
     bottom are off the screen.  The buttons
     are also off the screen.>

  Since improvements to the default error
  dialog are underway anyway, I request that
  error messages of many lines be detected,
  and scrolling be provided for their display
  when they grow so long the window would
  extend off the screen.



  I enhanced the dialog such that the error message is truncated at the first point that it is either more than 30 characters on a line or more than 4 lines long.  The entire error message is then repeated in the "details" text box.  The dialog thus remains a manageable size.  This fix is in CVS now and will go out with 8.4a2.

  - eric

  -- 06/19/2000 ericm


tkt_uuid: 220218ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 1 Zero
foundin: obsolete: 8.2b1
resolution: Invalid
title: bind cannot distinguish between some keys
comment:
  OriginalBugID: 2487 Bug
  Version: 8.2b1
  SubmitDate: '1999-08-03'
  LastModified: '2000-04-14'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 870
  OS: Windows NT
  OSVersion: All Windows versions
  Machine: X86
  ClosedDate: '2000-04-14'


  Name:
  Ingemar Hansson

  ReproducibleScript:
  bind all <KeyPress> {puts "%K %N"}

  ObservedBehavior:
  Pressing both left and right Ctrl keys results in "Control_L 65507"
      Pressing both left and right Shift keys results in "Shift_L 65505"
      Pressing figure keys (0-9) on keys above letters or on the pad to the
      right results in same figure showed. (E.g. "1 49")
      Plus some more.

  DesiredBehavior:
  Pressing the right Ctrl key should of course result in Control_R and a
      different keysym number. There should also be different keysym numbers
      for the figure keys above the letter keys and the right keypad.



  The first of these (left vs. right keys) was fixed with #870.

  I am unable to reproduce the second problem on NT with 8.2 or 8.3.

  - eric
   
  -- 04/14/2000 ericm


tkt_uuid: 1814999fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.5b1
resolution: None
title: photo data -grayscale broken
comment:
  In 8.5b1, the -grayscale option of the [photo data] command yields a dark but not-quite-black image (variation in the grayscale image can be seen by increasing the -gamma value).

  The following code works as expected in 8.4.16 but not in 8.5b1:

  package require Img
  set img1 [image create photo -file c:/myimage.jpg]
  set img2 [image create photo]
  $img2 put [$img1 data -grayscale]
  set l1 [label .l1 -image $img1]
  set l2 [label .l2 -image $img2]
  grid $l1 $l2


tkt_uuid: 552366ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 7 High
foundin: obsolete: 8.4a4
resolution: Fixed
title: Priv(repeated) undefined in checkbutton
comment:
  When you click then release the mouse button on a
  checkbutton in OS X, you get an error reading:

  can't read "Priv(repeated)": no such variable
      while executing
  "if { $Priv(repeated) == 0 } {
          uplevel #0 [list $w invoke]
  }"
      (procedure tk::ButtonUp" line 18)
      invoked from within
  "tk::ButtonUp .editdlog/style.client.fr.fontchk"
      (command bound to event)

  I looked at the standard TCL library button.tcl file
  and noticed that for the Mac ::tk::ButtonDown
  procedure, the line:

      set Priv(repeated) 0

  was only inside the -repeatdelay check.  But in
  ::tk::ButtonUp, the check for Priv(repeated) was NOT
  inside a -repeatdelay check.  I moved the 'set
  Priv(repeated) 0' line to just before the after
  statement in ::tk::ButtonDown and everything started
  working correctly.


tkt_uuid: 223689ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 6
resolution: Fixed
title: Problem when changing no of colours on Windows
comment:
  (This was done using Tcl/Tk 8.3.2 on Windows 2000.)

  Use 32 bit colours. Run wish. Change to 16 bit colours. This results problems with colours in the console.


tkt_uuid: 1176610fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 02. Appearance
priority: 9 Immediate
foundin: obsolete: 8.4.11
resolution: Fixed
title: Aqua Entry widgets too big
comment:
  In CVS 8.5a3, the new Aqua-ized entry widgets are way
  bigger than similar widgets in other applications.

  To bring the widget into parity with entry type widgets from
  other Aqua apps, the default DEF_ENTRY_BORDER_WIDTH
  and MAC_OSX_ENTRY_BORDER #defines need to be reduced
  to 1 or 2.

  A borderwidth of 1 makes the entry widget the same height as,
  for example, the one in the System Preferences->Sharing
  control panel, but has the text one pixel closer to the left side.

  A borderwidth of 2 maked the entry widget 2 pixels taller, but
  has the text at the same horizontal spacing.

  I recommend a borderwidth of 1.


tkt_uuid: 2847381fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Undocumented -help (or -h) option causes init failure
comment:
  Hi!

  Looks like wish has an undocumented option -help (or -h) which prints usage info. Usually, after printing usage info an application exits with non-zero status, but wish tries to continue and exits with "Application initialization failed" error or even further with some other error indicating the Tk isn't loaded.

  For example, starting Tk 8.6 widgets demo by
  wish8.6 /usr/share/doc/tk8.6/examples/widget -h

  gives the following:
  Application initialization failed: Command-specific options:
   -colormap: Colormap for main window
   -display:  Display to use
   -geometry: Initial geometry for window
   -name:     Name to use for application
   -sync:     Use synchronous mode for display server
   -visual:   Visual for main window
   -use:      Id of window in which to embed application
   --:        Pass all remaining arguments through to script
  Error in startup script: Command-specific options:
   -colormap: Colormap for main window
   -display:  Display to use
   -geometry: Initial geometry for window
   -name:     Name to use for application
   -sync:     Use synchronous mode for display server
   -visual:   Visual for main window
   -use:      Id of window in which to embed application
   --:        Pass all remaining arguments through to script
      (processing arguments in argv variable)
      invoked from within
  "load /usr/lib/libtk8.6.so.0 Tk"
      ("package ifneeded Tk 8.6b1" script)
      invoked from within
  "package require Tk     8.5"
      (file "/usr/share/doc/tk8.6/examples/widget" line 16)

  wish8.6 -h /usr/share/doc/tk8.6/examples/widget
  gives the following:

  Application initialization failed: Command-specific options:
   -colormap: Colormap for main window
   -display:  Display to use
   -geometry: Initial geometry for window
   -name:     Name to use for application
   -sync:     Use synchronous mode for display server
   -visual:   Visual for main window
   -use:      Id of window in which to embed application
   --:        Pass all remaining arguments through to script

  I think that there could be two ways to fix this bug:
  1) Make wish exit right after printing command line options and document -help option.
  2) Remove -help option completely.


tkt_uuid: 220806ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 7 High
foundin: obsolete: 8.1b3
resolution: Out of Date
title: Docs missing for Tk_MacTurnOffMenus API
comment:
  OriginalBugID: 1874 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-22'
  Severity: MED
  Status: Assigned
  Submitter: surles
  ChangedBy: hershey
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


tkt_uuid: 818489ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Fixed
title: Incorrect image on disabled button
comment:
  Using Tk-8.4.4 on HP-UX11i, buttons displaying an image 
  are not correctly shown when the button is disabled 
  (unless disabledforeground' is set to an empty string).

  The stipple is offset several pixels to the northeast.

  The attached file contains 'button.tcl' example 
  code, 'square.xbm' example bitmap and 'dump.tif' - 
  screen dump from HP-UX.

  This was originally observed using Python 2.3 + Tkinter + 
  Tk-8.4.4 on both HP-UX and Windows 2000. It doesn't 
  happen on Linux.

  It also happens with Tk-8.4.3, but not with Tk-8.3.4.


tkt_uuid: 3163893fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: -initialdir option bug for tk_chooseDirectory under XP
comment:
  How to reproduce :
  1- test under XP
  2- Pull CVS HEAD as of 22 January 2011.
  3- Start wish
  4- Type : tk_chooseDirectory -initialdir c:\
   => the dialog does not open in c:\.
  5- Recompile wish with -DUNICODE -D_UNICODE removed (you have to tweak the tk generated makefile)
  6- Type : tk_chooseDirectory -initialdir c:\
   => the dialog correctly opens in c:\.

  It was working OK in august 2010. -DUNICODE has been added later, and Win32 API calls also have been modified in tkWinDialog.c.

  Note : this bug might not be reproducible under Vista / 7.


tkt_uuid: 3077329fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Set background and opacity of Tk-Cocoa textured windows
comment:
  The attached patch allows you to set the background and opacity of textured ("metal") windows with Tk-Cocoa using the tk::unsupported::MacWindowStyle command. The current configuration of metal/textured windows does not integrate well with Tk widgets because the non-opacity of the window's background color causes the color to flicker through or "flash" severely during redraws of Tk widgets; it also does not allow Tk widgets to blend in seamlessly with the background because it is a gradient. This patch allows one to set the textured background to opaque, to set it to a standard NSColor, and then set the Tk widget to a corresponding hex color; this reduces the "flash" and allows the Tk widgets to blend in.

  Here is an example:

  toplevel .f
  tk::unsupported::MacWindowStyle style .f document {metal light opacity closeBox collapseBox resizable standardDocument }

  pack [label .f.f -bg #ababab -text "This is a textured window\nwith opacity and a gray background\nsimilar to other Mac applications"] -fill both -expand yes

  The patch updates both tkOSXWm.c and the README file, with documentation.


tkt_uuid: 220115ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: need command for text & canvas tags that don't apply to any items
comment:
  OriginalBugID: 876 RFE
  Version: 8.0.3
  SubmitDate: '1998-11-25'
  LastModified: '2000-02-25'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: All
  ClosedDate: '2000-02-25'


  From: John Ousterhout <ouster@scriptics.com>
  Subject: RFE: need more introspection in Tcl and Tk

  This is another problem pointed out by Kevin Kenny in his Tcl/Tk
  Conference paper.

  Tcl and Tk are missing several pieces of introspection that are
  meeting to find memory leaks.  Right now there are no Tcl commands
  that can be invoked to find out about the following things:

  - text and canvas tags that don't apply to any items in the widget

  The "text tag names" returns all tags, and then "text tag ranges <name>"
  will return empty if no items have the tag.  On the canvas, this is
  moot because they are UIDs which can't be deallocated and have no other
  info associated with them (unlike text tags). 
  -- 02/25/2000 hobbs


tkt_uuid: 1936238fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 73. Argv Parsing
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Fixed
title: Tk_ParseArgv fails with wish8.5 -h
comment:
  This was originally reported on comp.lang.tcl by Simon Bachmann.

  To duplicate the problem run:
  $ wish8.5 -h
  or if you're using the HEAD:

  $ wish8.6 -h

  Tk_ParseArgv loops until it runs out of memory.

  kbk provided a patch that may fix the problem:
  http://paste.tclers.tk/857

  kbk said it needs a test case, and Tk_ParseArgv is currently not tested.


tkt_uuid: 2933099fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 02. Appearance
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: Cocoa Tk wraps text when no wrapping specified
comment:
  Cocoa Tk 8.6 Jan 8, 2010 cvs source code sometimes draws text wrapping the last letter of the text line and drawing the wrapped text outside the bounds of the Tk widget.  It appears that the Mac Cocoa text drawing is doing the wrapping rather than Tk code since the Tk widget specifies no wrapping (wrap = 0) and the drawn wrapped single letter appears outside the bounds of the widget.

  I have only observed this using Tix 8.4.3, not native Tk widgets so it is possible it is a Tix bug.  But this bug does not occur with Tix 8.4.3 and Tk 8.5.8 on Mac Carbon Tk, Linux Tk or WIndows Tk.  So it looks more likely to be a bug in the new Tk Cocoa implementation.

  If the Tix widget text width is increased by one pixel from what is returned by Tk_ComputeTextLayout() then the wrapping bug does not occur.  (Tested this with a patch to Tix generic/tixUtils.c).  The reported text size from Tk_ComputeTextLayout() however is the same between Tk 8.5.8 Carbon which does not exhibit the wrapping bug and Tk 8.6 Cocoa cvs which does exhibit the bug (77 pixels for "icosahedron" in helvetica font).  So the wrapping appears to be caused by the Tk Cocoa text drawing code, and is not due to a miscomputation of the text width.

  The following Tcl script produces the bug with the result showed in the attached image.  The text widget is given a red background and the image shows the wrapped letter "n" at the end of icosahedron below the red box where Tk believes the text should be drawn.

  tixHList .h
  tixDisplayStyle text -stylename s -background red
  .h add i -itemtype text -text icosahedron -style s
  pack .h

  Sorry I do not have a native Tk widget demonstration of the bug.


tkt_uuid: 477740ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 6
foundin: obsolete: 8.4a4
resolution: Fixed
title: Incorrect display of disabled compound buttons
comment:
  Wish seems to crash on my system (windows XP but
  probably under all windows versions)
  when a button is displayed the is in the disabled
  state and has both an image + text with the
  -compound option set to other than none.
  This bug does not exist under unix and seems
  to exist in the latest CVS sources (tk8.4a4).

  A simple script to reproduce the bug is:

  image create photo empty -width 24 -height 24
  pack [button .b -text {Crash Tk} -image empty \
                  -compound left -state disabled \
                  -command exit]

  After doing a little debugging, it seems that
  the gc used to draw the message does not has
  a valid font (fontptr == NULL). Perhaps a
  problem during the configuration of the button?
  What follows is the stack trace:

  MultiFontTextOut(HDC__ * 0x5001086c, WinFont * 
  0x00000000, const char * 0x00c5d508, int 8, int 32, 
  int 24) line 948 + 3 bytes
  Tk_DrawChars(_XDisplay * 0x00af4d60, unsigned long 
  12210792, XGCValues * 0x00c1b6b0, Tk_Font_ * 
  0x00c18f08, const char * 0x00c5d508, int 8, int 32, 
  int 24) line 883 + 29 bytes
  Tk_DrawTextLayout(_XDisplay * 0x00af4d60, unsigned 
  long 12210792, XGCValues * 0x00c1b6b0, Tk_TextLayout_ 
  * 0x00c1bb08, int 32, int 11, int 0, int 100000000) 
  line 2198 + 57 bytes
  TkpDisplayButton(int * 0x00c18bb0) line 520 + 48 bytes
  TclServiceIdle() line 692 + 12 bytes


tkt_uuid: 219931ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: "Save" button in tk_getSaveFile displays "Open"
comment:
  OriginalBugID: 1369 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '1999-04-05'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: stanton
  RelatedBugIDs: 1640
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  ClosedDate: '1999-04-05'


  Name:
  Frank J. Leitner

  CustomShell:
  Plus-Patches applied

  ReproducibleScript:
  Within the tk_getOpenFile Dialog there is a Button named "Save". Click on
  a directory, and it shows "Open". Click on a file and it will display "Save"
  again. BUT: Open a directory (double-click)...




  ObservedBehavior:
  After building the contents of the new directory, the Button still displays
  "Open".



  DesiredBehavior:
  The Button should display "Open" only whenever there is a directory highlighted
  that you would want to open, and read "Save" in any other case.



  Patch:
  *** tkfbox.tcl.orig     Tue Nov  3 07:03:50 1998
  --- tkfbox.tcl  Wed Feb  3 17:06:57 1999
  ***************
  *** 1067,1072 ****
  --- 1067,1080 ----
        #
        cd $appPWD
    
  +     # Restore the Open/Save Button
  +     #
  +     if {![string compare $data(type) open]} {
  +       $data(okBtn) config -text "Open"
  +     } else {
  +       $data(okBtn) config -text "Save"
  +     }
  + 
        # turn off the busy cursor.
        #
        $data(ent) config -cursor $entCursor




  PatchFiles:
  library/tkfbox.tcl




  see bug 1640 for more details


tkt_uuid: 3080953fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 8
foundin: None
resolution: Fixed
title: Malformed Unicode characters in %A substitution
comment:
  %A substitute in bind scripts is broken, contains the unicode character, but in wrong encoding.
  For example "\u015b" (letter ś) becomes two-character string "\x5b\x01"

  System is Windows XP, tcl/tk is latest from CVS. Version from 2010-09-21 doesn't have bug.


tkt_uuid: 1663527fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: typos in tksection n man pages found
comment:
  A few nitpick typos were found in a dozen or so tk man pages. I am attaching a patch to this bug report that shows where the problems are located, and my suggested fix.  I doubt I found all problems, and some of the suggestions may not consider alternative spellings.


tkt_uuid: 3531085fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: Invalid
title: safe-5.2 fails with an error
comment:
  ==== safe-5.2 multi-level Tk loading with clearance FAILED
  ==== Contents of test case:

      # No error shall occur in that test and no window shall remain at the end.
      set i [safe::interpCreate]
      set j [list $i x]
      set j [safe::interpCreate $j]
      safe::loadTk $j
      interp eval $j {
          button .b -text Ok -command {destroy .}
          pack .b
  #       tkwait window . ; # for interactive testing/debugging
      }

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: can't source init.tcl into slave interp0 x (script error)
      while executing
  "InterpInit $slave $access_path $staticsok $nestedok $deletehook"
      (procedure "InterpCreate" line 12)
      invoked from within
  "InterpCreate $slave $accessPath  [InterpStatics] [InterpNested] $deleteHook"
      (procedure "safe::interpCreate" line 3)
      invoked from within
  "safe::interpCreate $j"
      ("uplevel" body line 5)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-5.2 FAILED


tkt_uuid: 1247835fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: tabs: wordprocessor vs tabular interpretation
comment:
  Platform Windows XP/SV2

  Tab positions of a Text widget is incorrect in Tk85a3.

  Try the following:

  text .t
  .t config -tab {0.5i 1.0i 1.5i 2.0i 2.5i 3.0i 3.5i 4.0i 4.5i}
  pack .t

  Type into the text widget the following text line:

  This is a line of text for testing tabs.  It seems that tab 
  position of a text widget in Tk 85 is not correct.

  An inserted tab will make multiple spaces in almost any 
  position in the above text line even after its specified 
  position.

  The correct behavior is: a tab may make mutiple spaces 
  if it is inserted before the specified tab position.  If it is 
  inserted after its specified position, it should only make 
  one space. The first tab only add one space after 0.5i 
  and the second tab only add one space after 1.0i, and 
  so on so forth.

  This bug may make text tab displays incompatible to 
  previous Tk text wigets, i.e., 8.4 and below. Any text file 
  that uses tabs in formating and saved by a previous 
  Tcl/Tk may be display incorrectly in Tk 853a.


tkt_uuid: 220839ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: final: 8.0.5
resolution: None
title: several wm geometry bugs
comment:
  OriginalBugID: 1961 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-29'
  LastModified: '1999-10-22'
  Severity: MED
  Status: UnAssn
  Submitter: pat
  ChangedBy: hobbs
  OS: Other
  Machine: NA


  Name:
  Don Libes

  Extensions:
  Tk 8.0.5 and Tk 8.1b3

  ReproducibleScript:
  Three problems:
      
      1) Documentation problem:  wm(1) says:
      
        When gridded geometry management is enabled ... interactive resizing
        is carried out in even numbers of grid units rather than pixels.
      
      As far as I can tell this is false on Windows and MacOS.  To the
      contrary, they let me interactively resize to any pixel.  I imagine
      this is simply a deficiency of the window managers on those systems,
      however the documentation should be corrected to explain that you
      cannot depend on interactive resizing working the way you describe -
      perhaps suggesting that it's necessary to fix up fractional grid units
      left by the window manager.
      
      [wm geometry] returns integral grid units, seemingly ignorant of the
      screen slop.  This means that you have to take explicit action to
      repair the defective interactive resizing.  Alas, you can't tell that
      you have to take action (since there's no query to do so) so that
      means you ALWAYS have to resize the window in response to a configure
      event if you want to prevent slop from creeping in.
      
      This wouldn't be so bad except that if you try to "fix" the geometry
      to get rid of the slop, you run into different problems ...
      
      2) This one was an attempt to fix the slop (as above).  Run it on a PC
      (to be specific, I'm using NT 4.0).  Following the instructions below,
      you will see the wm geometry returns bogus widths (such as -3939732).
      
      # To run this script, first change the socket command to point to a
      socket
      # on which someone is listening or save result to a file.
      # (You have to save it somewhere else beside the screen since this app
      #  will take over the whole screen.)
      # Then, run the app with wish (either 8.0.5 or 8.1b3 is fine).
      # Once running, hit the maximize button.  Then hit the normal-size
      button.
      # wm geom will then report totally ridiculous widths.
      
      set fid [socket host someval]
      fconfigure $fid -buffering line
      
      listbox .from -height 1 -width 80 -setgrid 1
      grid .from
      
      bind . <Configure> {
          set s [wm geometry .]
          puts $fid "geometry = $s"
          scan $s "%%dx%%d" w h
          .from configure -width $w
          wm geometry . ""
      }
      
      3) In an effort to reduce jitter, I introduced a delay before
      responding to <Configure> events.  Try this example:
      
        bind . <Configure> {
            puts "<Configure>"
            catch {after cancel $cid}
            set cid [after 500 configure]
        }
      
        proc configure {} {
            scan [wm geometry .] "%dx%d" w h
            wm geometry . [set w]x[set h]
        }
      
      When using UNIX (twm)
        3a) if you wait a little before dragging, the window stays where you
           moved it and then hops over a couple of pixels.
        3b) if you drag the window within a couple of seconds, the window
      moves
           back to where it started.  This behavior repeats if you drag within
           a couple of seconds of the previous drag.
      When using UNIX (olwm)
        3c) same behavior as (3b) above
      When using UNIX (kde)
        3d) produces infinite stream of configure events.
      When using NT
        3e) same behavior as (3d) above
      When using MacOS
        3f) works correctly!
      
      (In case you're wondering why I'm calling "wm geometry" to set the
      width/height to the value it should already be, it's because when the
      window is gridded, this will get rid of the slop (extra pixels).  When
      I add back a gridded widget to make this a real example, it misbehaves
      the same way I've described above.)
      
      By the way, to make it clear about (3b), what's going wrong is not
      just the width/height but the *position*!  And that's not even
      mentioned in the script!  So it doesn't matter how you calculate width
      and height.
      
      I doubt it has anything to do with not being updated in time.  If I
      skip the "after" delay, the configure WORKS (on UNIX).  Bottom line:
      
      - if no delay, new geometry is seen immediately
      - if delay, the old geometry returns (for a little while)


tkt_uuid: 2328657fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: None
title: test failures
comment:
  not certain, but I think these
  are new:

  ==== canvText-18.1 bug fix 2525, find enclosed on text with newlines FAILED
  ==== Contents of test case:

      pack [canvas .c]
      .c create text 100 100 -text Hello\n -anchor nw
      set bbox [.c bbox 1]
      set x2 [lindex $bbox 2]
      set y2 [lindex $bbox 3]
      incr y2
      update
      .c find enclosed 99 99 [expr $x2 + 1] [expr $y2 + 1]

  ---- Result was:

  ---- Result should have been (exact matching):
  1
  ==== canvText-18.1 FAILED



  ==== canvText-20.1 angled text bounding box FAILED
  ==== Contents of test case:

      .c create text 2 2 -tag t -anchor center -text 0 -font {Helvetica 24}
      set bb0 [.c bbox t]
      .c itemconf t -angle 90
      set bb1 [.c bbox t]
      .c itemconf t -angle 180
      set bb2 [.c bbox t]
      .c itemconf t -angle 270
      set bb3 [.c bbox t]
      list [expr {$bb0 eq $bb2 ? "ok" : "$bb0,$bb2"}]  [expr {$bb1 eq $bb3 ? "ok" : "$bb1,$bb3"}]  [expr {$bb0 eq [transpose $bb1] ? "ok" : "$bb0,$bb1"}]
  ---- Result was:
  {-7 -22 12 27,-8 -23 11 26} {-22 -8 27 11,-23 -7 26 12} {-7 -22 12 27,-22 -8 27 11}
  ---- Result should have been (exact matching):
  ok ok ok
  ==== canvText-20.1 FAILED


tkt_uuid: 657835ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Postponed
title: changes to makefile.vc & rules.vc
comment:
  I've made a couple of changes to these files while 
  building Tcl and Tk, hopefully they can be of use to 
  someone other than me :)
  Included in the zip file are both the diffs and full versions 
  of these files.
  Any feedback is welcome...

  makefile.vc v1.66
      -- made to conform with Tcl's makefile better
      -- added support for 'Global Optimisation'
         (ie. whole program optimisation) (VC++ 7.0)
      -- added variable 'libflags'
      -- added progress messages
      -- corrected some long filename quoting
      -- corrected some references to $(CPY)
      -- removed some '/=\' conversions (these are already
         corrected in rules.vc)
      -- modified 'release' to build 'winhelp' as well
      -- modified to use $(MKDIR) & $(RMDIR) which are
         now declared in rules.vc
      -- modified 'clean' to remove 'DOCTMP_DIR'
      -- renamed 'console-wish' to 'con-wish' to make
         instructions line up better
      -- moved 'install-doc' to installation section
      -- renamed helpfile main window text to
         'Tk Reference Manual'
      -- modified to change title to
         'Tcl\Tk Reference Manual' if merged with
         'Tcl Reference Manual'
      -- cleaned up screen output
      -- cleaned up style to match majority already used
      -- corrected some spelling errors

  rules.vc v1.4
      -- added support for 'Global Optimisation'
         (ie. whole program optimisation) (VC++ 7.0)
      -- added $(MKDIR) & $(RMDIR) macros
      -- modified logic for decoding options
      -- cleaned up screen output
      -- cleaned up style to match majority already used


tkt_uuid: 1794786fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: None
resolution: Duplicate
title: Modify widget state before generating <<Modified>> event
comment:
  When a widget .t generates a <<Modified>> event, it does so with the equivalent of
    event generate .t <<Modified>> -when now

  The <<Modified>> event is therefore processed immediately.  In most cases the binding to <<Modified>> will use "after idle" or "event generate" to schedule code to be executed at an appropriate later time.

  However, it is unhelpful that at the instant when <<Modified>> is generated, [.t get 1.0 end] is up to date if characters have been added to .t, but not if characters have been removed.

  Demonstration code is here:
  http://groups.google.co.uk/group/comp.lang.tcl/browse_thread/thread/ec786deb854b4194/

  It would be helpful if the widget state were always up to date when the <<Modified>> event is generated.


tkt_uuid: 1021812fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 9 Immediate
foundin: obsolete: 8.5a2
resolution: Fixed
title: crash with user_data field of XVirtualEvent
comment:
  When testing 'tile' today with cvs head, I got a crash
  when cleaning up an event because the user_data field
  was garbage.

  It appears TIP#165 didn't update these three sets of code:

  "tkMacOSXMenu.c";                            Line 3663:
      XVirtualEvent event;
  "tkMacOSXMenus.c";                           Line 226:
      XVirtualEvent event;

  "tkWinMenu.c";                               Line 2794:
      XVirtualEvent event;

  To null out the user_data field.


tkt_uuid: 220466ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Tk_DestroyWindow deletes images after fonts; it shouldn't
comment:
  OriginalBugID: 1603 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-23'
  LastModified: '1999-03-30'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-03-30'
  FixedInVersion: 8.1b3


  Name:  Bruce Stephens
  email:  b.stephens@isode.com
  Support:  None
  Severity:  3
  OperatingSystem:  Linux (Red Hat 5.0+ on Intel)
  Extensions:  Tix
  CustomShell:  no
  Synopsis:  Tk_DestroyWindow deletes images after fonts; it shouldn't

  ReproducibleScript:
      Images are flexible things, and might reasonably contain fonts.  Tix's
      compound image type, for example, allows an image to contain other
      images, text, and other things.
      
      However, if an image master contains a reference to a font, then when
      Tk_DestroyWindow is called for the last window of the application, then
      TkFontPkgFree will be called before TkDeleteAllImages, which causes a
      coredump (on Unix).
      

  ObservedBehavior:
      With tixwish4.1.8.1:
      
      set i [image create compound -window .]
      $i add text -text Hello
      exit
      
      causes a failure:
      TkFontPkgFree: all fonts should have been freed already
      
      

  DesiredBehavior:
      Well, no problems with fonts: the image delete/free procs ought to get
      the opportunity to clean up.
      

  Patch:
  *** tkWindow.c.old      Tue Mar 23 12:09:31 1999
  --- tkWindow.c  Tue Mar 23 12:10:04 1999
  ***************
  *** 1315,1322 ****
                    
              Tcl_DeleteHashTable(&winPtr->mainPtr->nameTable);
              TkBindFree(winPtr->mainPtr);
  -           TkFontPkgFree(winPtr->mainPtr);
              TkDeleteAllImages(winPtr->mainPtr);
    
                /*
                 * When embedding Tk into other applications, make sure 
  --- 1315,1322 ----
                    
              Tcl_DeleteHashTable(&winPtr->mainPtr->nameTable);
              TkBindFree(winPtr->mainPtr);
              TkDeleteAllImages(winPtr->mainPtr);
  +           TkFontPkgFree(winPtr->mainPtr);
    
                /*
                 * When embedding Tk into other applications, make sure 


  PatchFiles:
      tkWindow.c
      

  Comments:
      Tix's implementation of compound images is broken in other ways, too.
      Even with the above patch, it doesn't work properly.  However, changing
      the order of deletion would make a correct implementation possible.
      
      A workaround is for applications to ensure that the images are deleted
      before exiting.
      
  Posted To comp.lang.tcl: Posted Successfully



  Applied patch

  03/30/1999 13:14 - stanton -


tkt_uuid: 748977ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Duplicate
title: tktest from current cvs dumps core
comment:
  [...]
  TCL_LIBRARY=/mnt/tcl/library; export TCL_LIBRARY; \
  TK_LIBRARY=/mnt/tk/library; export TK_LIBRARY; \
  ./tktest /mnt/tk/unix/../tests/all.tcl -geometry +0+0 \
   
  /bin/sh: 157334 Abort - core dumped
  make: *** [test] Error 134
  $ dbx ./tktest ./core
  dbx version 5.1
  Type 'help' for help.
  Core file created by program "tktest"

  signal IOT/Abort trap at >*[__kill, 0x3ff800e9658]    
   beq     a3, 0x3ff800e9670
  (dbx) where
  >  0 __kill(0x0, 0x1, 0x3ff800ddcc8, 0x300400a25b8,
  0x3ff801c53a4) [0x3ff800e9658]
     1 (unknown)() [0x3ff8020c148]
     2 __tis_raise(0x3ff801c53a4, 0x102b8, 0x3ff8013b4d8,
  0x100000006, 0x3ff801a20d4) [0x3ff8013b4d4]
     3 raise(0x3ff8013b4d8, 0x100000006, 0x3ff801a20d4,
  0x0, 0x3ff801c53d4) [0x3ff801a20d0]
     4 abort(0x3ffbff4869c, 0x300400b9a78, 0x0, 0x0,
  0x3ff00000000) [0x3ff801c53d0]
     5 Tk_MainEx(argc = 4, argv = 0x11fffc018,
  appInitProc = 0x120003214, interp = 0x140008b00)
  ["/mnt/tk/unix/../generic/tkMain.c":119, 0x3ffbff48698]
     6 main(argc = 4, argv = 0x11fffc018)
  ["/mnt/tk/unix/tkAppInit.c":68, 0x1200031f4]
  (dbx) 


  Tested on Tru64Unix 5.1A, used cc/cxx from vendor.


tkt_uuid: 1171961fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 44. Generic Fonts
priority: 7 High
foundin: obsolete: 8.4.9
resolution: None
title: "font measure" parsed incorrectly
comment:
  The command

      font measure "Courier -12" "-display"

  should return the width of the string "-display" in
  pixels. Instead, it raises an error, because the string
  "-display" is interpreted as the abbreviation of the
  optional "-displayof" switch.  This is a very
  long-standing bug in parsing the "font measure"
  command, whose syntax is

      font measure font ?-displayof window? text

  If the "font" argument is followed by a single string
  then the correct behavior should be to interpret that
  string as the "text" argument, regardless of what
  string was passed to the command.


tkt_uuid: 779559ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 15. [scale]
priority: 3 Low
foundin: obsolete: 8.4.4
resolution: Duplicate
title: scale widget triggering on enter/leave events (LINUX only)
comment:
  The following occurs on LINUX only. I tried many Linux 
  systems with differing O/S versions. All failed. May be a 
  compiler bug, but I'll report and see if anyone else has 
  seen this problem.

  With the -resolution parameter set to a decimal value 
  (.1 for example) , the widget triggers and executes 
  the  -command when the cursor enters and leaves the 
  the slider area (and with tk_strictMotif set, the entire 
  widget).

  The problem appears to be that TkRoundToResolution() 
  returns a value with digits way beyond the end of the 
  specified resolution. Then when -configure events 
  occur, this value is then rounded again producing a 
  slightly different value, so the command is triggered, 
  even though the event was a simple background change 
  as the result of an Enter/Leave event.

  My solution (HACK), was to use the "new" value 
  calculated within TkRoundToResolution() within a dummy 
  print statement. I have no idea why this removes the 
  extra junk, but it does, and the results are that the 
  scale widget works as it should.

  I've attached a two line example which demonstrates 
  the problem. When the example starts, things work as 
  expected, but once the slider has been moved. Moving 
  the cursor thru the slider area triggers the command.


tkt_uuid: 220911ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Out of Date
title: Mac: File dialog box is empty
comment:
  OriginalBugID: 5298 Bug
  Version: 8.3
  SubmitDate: '2000-04-28'
  LastModified: '2000-05-04'
  Severity: CRIT
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  Machine: Power Macintosh 8500/120


  Name: Richard Campbell

  Comments:
  This behavior was observed on two systems with MacOS 8.5.1 (Power
      Macintosh 8500/120). 

      Tcl/Tk 8.2.1 works correctly on the same systems.

      Tcl/Tk 8.3.0 worked correctly on a MacOS 8.6 system and on a MacOS 9
      system.

  ReproducibleScript:
  Select File/Source from the Wish menu
   or
  run the tk_getOpenFile builtin command

  ObservedBehavior:
  The common file dialog box is empty. There is no file list, buttons or anything.
  Just a window frame.

  DesiredBehavior:
  A file dialog with a list of files.


tkt_uuid: 456732ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
title: make TK_NO_SECURITY runtime switchable
comment:
  I've been asked several times and wondered myself 
  about making the TK_NO_SECURITY switch something that 
  happens at runtime, not compile time.  Attached is a 
  patch which effects this by adding a 'tk securesend' 
  command that operates on a per-display basis.  This 
  has to be called in the receiving app (the sending one 
  doesn't actually care).

  This one is set up to switch back and forth, although 
  the docs should note that once off, turning it on can 
  only give you a false sense of security.


tkt_uuid: 220205ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: Text centering problem
comment:
  OriginalBugID: 2304 Bug
  Version: 8.0.3
  SubmitDate: '1999-06-28'
  LastModified: '1999-08-05'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  Machine: Other
  ClosedDate: '1999-08-05'


  Name:
  Eric Yeh

  ReproducibleScript:
  I create a canvas and do a create text.  The text is not multi-lined and
      so it won't center.  According to the man page, it clearly states that
      only multi-lined text will have an affect on the justify option.  Why
      not just have it center for single-line too??

  DesiredBehavior:
  Just like the old versions.  You do a -justify center and it centers no
      matter how many lines of text exist.



  This is a misunderstanding of the options.  The user needs to look
  at the -anchor switch.  This will allow you to center about the
  point you chose for the text to be placed at. 
  -- 08/05/1999 hobbs


tkt_uuid: 219902ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: bug in tk_getOpenFile when called before adding widgets to the "." window
comment:
  OriginalBugID: 715 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-13'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: admin
  ChangedBy: hobbs
  RelatedBugIDs: 1212
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-10-31'
  FixedInVersion: NA
  ClosedDate: '1999-08-20'


  # BUG:
  # This code demonstrates an apparent bug in the grab handling of
  # tk_getOpenFile, if run at the start of a program.  If tk_getOpenFile
  # is run before adding any widgets to the "." window, the widgets in
  # the "." window will fail to respond to any events other than 
  # WM_DESTROY and resizing.  Note that this behavior is only exhibited
  # on Windows, not on Unix or MacOS.
  #
  # AFFECTED PLATFORMS:
  # - Tcl 8.0p2 & 8.0.3 on Win NT4 (SP3), Win 98, Win 95 (OSR2.5)
  #
  # UNAFFECTED PLATFORMS:
  # - Tcl 8.0p2 on Solaris 2.5
  # - Tcl 8.0.3 on Linux (Redhat 5.0)
  # - Tcl 8.0.3 on MacOS
  #
  # WORKAROUND:
  # This can be worked around by doing the tk_getOpenFile after windows
  # have been mapped, using an "after idle" as shown in the lower section
  # of this program.

  set demonstrate_bug 1

  if {$demonstrate_bug} {
      set inputFile [tk_getOpenFile -title "Choose a URL-Mapping Text File"  -filetypes {{{Text Files} {.txt}}} -initialdir [pwd]]
      label .l1 -text "Selected:" -justify left -anchor w
      label .l2 -textvariable inputFile -justify left -anchor w
      button .b -text Ok -command exit
      pack .l1 .l2 .b -side top -fill x
  } else {
      label .l1 -text "Selected:" -justify left -anchor w
      label .l2 -textvariable inputFile -justify left -anchor w
      button .b -text Ok -command exit
      pack .l1 .l2 .b -side top -fill x
      after idle {
          set inputFile [tk_getOpenFile -title "Choose a URL-Mapping Text File"  -filetypes {{{Text Files} {.txt}}} -initialdir [pwd]]
      }
  }


tkt_uuid: 220700ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: entry goes nuts when textvariable and validation are on
comment:
  OriginalBugID: 4320 Bug
  Version: 8.3
  SubmitDate: '2000-03-06'
  LastModified: '2000-03-07'
  Severity: SER
  Status: Released
  Submitter: kuchler
  ChangedBy: hobbs
  OS: Linux
  OSVersion: rh linux 6.1 (x86)
  Machine: badajoz
  FixedDate: '2000-03-07'
  FixedInVersion: 8.3.1


  proc foo {w v V p} {
  puts "validate: $w $v $V $p"
  after 100
          if {![string is digit $p]} {
                  return 0
          }
          set ::e [string range 0$p end-1 end]
          after idle [list $w configure -validate $v]
          return 1
  }
  pack [entry .e -validate focus -textvar ::e -vcmd [list foo %W %v %V %P]]
  # if you don't see the entry go ape and print a bunch of garbage, set e
  # some more
  set e 0
  set e 0
  set e 0
  set e 0
  set e 0


  Needed to make copy of value in EntrySetValue as it could become
  invalid during validation (like in above case), sending us into
  a loop in some cases. 
  -- 03/07/2000 hobbs


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

  Build Tcl:

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

  Build Tk:

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

  Try to run wish:

      ./wish
      Tcl_InitNotifier: unable to start notifier thread
      Abort


tkt_uuid: 3109856fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 6
foundin: obsolete: 8.5.9
resolution: None
title: canvas itemconfigure memory leak - Tk_Uid
comment:
  The attached script indicates a memory leak with canvas itemconfigure (possibly with just color handling).  Memory leak seen on both Windows and Linux.  This was first reported via Tkinter-discuss list.


tkt_uuid: 1600621fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Duplicate
title: icon display in menu
comment:
  the following example will not display the icon in the menuentry.
  it shows only the text "(image)" and removes also the item text of the menuentry.
  this example works fine on linux and windows but not on the mac.


  package require Img

  image create photo p_quit -data {
    iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABGdBTUEAALGPC/xhBQAAAAZi
    S0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALiAAAC4gB5Y4pSQAAAAd0SU1FB9EMHwAdGDQ8O6gA
    AALvSURBVHicTZJfaNZlFMc/55zn+e337n3f2eZ6l272blQUG27lGoQW2YV0lXfhRXrXBhZE
    kFdhXQRFBUWQRcyorCDCbqIUjAIp+rNESxNdNGnpmHM2W25ue3/b73m6eMfocA6cm8+XL+d8
    BeBQWzoYs3y4ua+HsFQjApLn5ESIAfIIBEIOmghzYxP4xoah3ZPzB+VQWzrY1NU13PvcE1z5
    +hiSpogB6lCDiGBOCKpgivOehsp6zrzwIfncjSH5oNnH+z96jXOvvkRycwXxhjmPOKVyzzZU
    jaujJ1HzqDMwQ52nfEeVk/vexN3U283fP31P0tqKFQsUyi30791P2rOV/9f86eOc//w9VrJF
    xIx8YYF0Qysu1jLi8gqSeArlFrYdOApAbXSEiRPHaWhaR8eDOyn1bWeg+15Ovf40y1mNiBBr
    GRoB8YI5T//e/QBc+uwAP7/9PJXNAxQrHfzw8pNMHn0ffInbduxCnEdFIUZU8hzUUWq/lbRn
    K7XREca//QJxjnLnXTR39yPOcXHkGMxdYd2WHYgpUZUQApoTUYPixirAGixmIAIIYoaYMfPb
    CADltg7EeQgBJQYigqrVr6W2BoDU2wxxCaICgC81I+pWBfKIOWHx2hQA7QMPrQIOBBCpw6a0
    9NY/szhzGa9GHnIUAkGVhZlpmJ2k1LedSs8AYsbytWmuXziLmFK972FoXE/252nUp+SrDlzI
    WQ2H8eu7L3L3vre4fc+zVMfPMHV2BFFhy+5nsPZuIGP8uyPgHOa0LqCJooA4x+LsNKdeeZzN
    u57Cd/ayqbN3LUhh6g/GvjrMcp6RFJvIV5ZAwc2NXaLQcQvZP/N121mNXz55g6RUpqV6JzjP
    9YkLqE/BOXxjiWK1i4tffkq+BPZoS+Pk1R/PP7Jp5wNY4rBCAz5NwAm1xX+p3ZjFOyOYYE6x
    xhKXvznC7+8cJmkqDwnAxxvLgytLS8PphlZiLYMYCSHA6uQhX9sjgZApSVNx6LG/Zg/+B3yO
    Cy8hh4B0AAAAAElFTkSuQmCC
  }

  set mb .menubar
  menu $mb
  . config -menu $mb

  set mn $mb.file
  $mb add cascade -label [msgcat::mc File] -menu $mn -underline 0
  menu $mn -tearoff 0

  $mn add command -label [msgcat::mc Quit] -underline 1 -state normal \
    -image p_quit -compound left -command Gpx::Quit -accelerator [msgcat::mc Ctrl]+q


tkt_uuid: 1085451fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: None
title: flickering with -alpha transparency manipulations
comment:
  The attached script makes windows (WinXP) smoothly
  transition from -alpha 0.0 to -alpha 1.0 (in fact a
  little bit larger than 1.0 which might be the root of
  the problem), and at the last step the entire window
  suddenly flickers horribly.

  i.e. the transition from 0.0 to 0.99 is really nice and
  then just as the window reaches 1.0 or thereabouts,
  there's a horrible flicker..


tkt_uuid: 1080646fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 86. Test Tools
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: None
title: test suite failures
comment:
  latest 8.4.9 candidate

  platform: sparc solaris 8, using sun gnome desktop,
  tcl/tk configured with
  --prefix=/tmp/tcl --enable-shared --enable-symbols
  --enable-stubs

  The following test suite failures occurred:

  focus.test

  ==== focus-5.1 ChangeXFocus procedure, don't take focus
  unless have it FAILED
  ==== Contents of test case:

      focusSetup
      focus -force .t
      update
      set result [focus]
      send [dobg {tk appname}] {focus -force .; update}
      lappend result [focus]
      focus .t.b2
      update
      lappend result [focus]

  ---- Result was:
  .t .t {}
  ---- Result should have been (exact matching):
  .t {} {}
  ==== focus-5.1 FAILED

  focusTcl.test
  font.test

  ==== font-45.4 TkFontGetAliasList: match FAILED
  ==== Contents of test case:

      # can fail on Unix systems that have a real "times
  new roman" font
      font actual {{times new roman} 10} -family

  ---- Result was:
  times new roman
  ---- Result should have been (exact matching):
  times
  ==== font-45.4 FAILED

  frame.test

  ==== frame-3.9 TkCreateFrame procedure, -use option FAILED
  ==== Contents of test case:

      catch {destroy .t}
      catch {destroy .x}
      toplevel .t -container 1 -width 300 -height 120
      wm geometry .t +0+0
      toplevel .x -width 140 -height 300 -use [winfo id
  .t] -bg green
      tkwait visibility .x
      set result "[expr [winfo rootx .x] - [winfo rootx
  .t]] [expr [winfo rooty .x] - [winfo rooty .t]] [winfo
  width .t] [winfo height .t]"
      destroy .t
      set result

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: window ".x" was deleted before its
  visibility changed
      while executing
  "tkwait visibility .x"
      ("uplevel" body line 7)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== frame-3.9 FAILED


  ==== frame-3.10 TkCreateFrame procedure, -use option FAILED
  ==== Contents of test case:

      catch {destroy .t}
      catch {destroy .x}
      toplevel .t -container 1 -width 300 -height 120
      wm geometry .t +0+0
      option add *x.use [winfo id .t]
      toplevel .x -width 140 -height 300 -bg green
      tkwait visibility .x
      set result "[expr [winfo rootx .x] - [winfo rootx
  .t]] [expr [winfo rooty .x] - [winfo rooty .t]] [winfo
  width .t] [winfo height .t]"
       destroy .t
      option clear
      set result

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: window ".x" was deleted before its
  visibility changed
      while executing
  "tkwait visibility .x"
      ("uplevel" body line 8)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== frame-3.10 FAILED

  unixWm.test

  ==== unixWm-4.3 moving window while withdrawn FAILED
  ==== Contents of test case:

          wm withdraw .t
          sleep 200
          wm geom .t $geom
          update
          wm deiconify .t
          wm geom .t
      
  ---- Result was:
  100x150+0+40
  ---- Result should have been (exact matching):
  100x150+0+0
  ==== unixWm-4.3 FAILED


  ==== unixWm-48.13 ParseGeometry procedure, resize
  causes window to move FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200
      wm geom .t +0+0
      update
      wm geom .t -0-0
      update
      set x [winfo x .t]
      set y [winfo y .t]
      wm geometry .t 150x300
      update
      list [expr [winfo x .t] - $x] [expr [winfo y .t] -
  $y]  [winfo width .t] [winfo height .t]

  ---- Result was:
  33 -100 150 300
  ---- Result should have been (exact matching):
  50 -100 150 300
  ==== unixWm-48.13 FAILED
  ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a
  toplevel, x-coords FAILED
  ==== Contents of test case:

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

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


  ==== unixWm-50.5 Tk_CoordsToWindow procedure, handling
  menubars FAILED
  ==== Contents of test case:

      deleteWindows
      toplevel .t -width 300 -height 400 -bd 2 -relief raised
      frame .t.f -width 150 -height 120 -bg green
      place .t.f -x 10 -y 150
      wm geom .t +0+50
      frame .t.menu -width 100 -height 30 -bd 2 -relief
  raised
      frame .t.menu.f -width 40 -height 20 -bg purple
      place .t.menu.f -x 30 -y 10
      testmenubar window .t .t.menu
      tkwait visibility .t.menu
      update
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing $x [expr $y - 31]]  [winfo
  containing $x [expr $y - 30]]  [winfo containing [expr
  $x + 50] [expr $y - 19]]  [winfo containing [expr $x +
  50] [expr $y - 18]]  [winfo containing [expr $x + 50]
  $y]  [winfo containing [expr $x + 11] [expr $y + 152]]
   [winfo containing [expr $x + 12] [expr $y + 152]]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: window ".t.menu" was deleted before its
  visibility changed
      while executing
  "tkwait visibility .t.menu"
      ("uplevel" body line 11)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== unixWm-50.5 FAILED

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

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

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


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

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

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


tkt_uuid: 561452ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 26. Conversions from String
priority: 5 Medium
foundin: None
resolution: Fixed
title: encoding problems with Mac OSX
comment:
  The system encoding is not set correctly (cause the
  path to the encodings is not expanded) and the internal
  encoding is not converted when making buttons.

  setting of the right system encoding is a tcl patch but
  belongs to the other ones.

  When debugging with Project Builder the console works
  in utf-8 but the system encoding (for making buttons)
  is still macRoman.  When working from the Terminal the
  encoding can be choosen by the user but normally is
  macRoman (or for the unix guys iso8859-1).  The
  encoding of the tcl-console is macRoman.  So when
  testing, one needs to change the encoding for the input
  channel, if it is not macRoman (cause macRoman is the
  system encoding!)
    fconfigure stdin encoding utf-8

  The internal strings have to be converted if a native
  widget (called control by apple) is used.

  The attached patches are against the repository and the
  branch macosx-8-4-branch.


tkt_uuid: 220233ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: None
resolution: Invalid
title: tktext widget insertion cursor looks bad when very wide
comment:
  OriginalBugID: 2712 Bug
  Version: 8.2
  SubmitDate: '1999-09-10'
  LastModified: '1999-09-10'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0sp5
  Machine: X86
  ClosedDate: '1999-09-10'


  Name:

  Vince Darley


  Comments:

  The above patch leaves the behaviour unmodified for narrow cursors (0-2

      pixels),

      and for larger widths makes the flashing insertion cursor extend to the

      right only.  It has no other effect.


  ReproducibleScript:

  text .t -font "Monaco 20" -insertwidth 20 -insertbackground red

      pack .t

      .t insert 1.0 "Here's some text to test out the large\

        cursor on.  It floats peculiarly half over two different\

        characters.  Most text editors, if you switch a 'block cursor'\

        on, will highlight the character just after the insertion point."


  ObservedBehavior:

  A wide insertion cursor (the same width as the current font, for

      instance), looks bad.


  DesiredBehavior:

  I think it would be better to make a wide flashing

      cursor extend to the right of the default position only, so that

      a wide insertion cursor will cover a single character, not half of 

      two different characters.


  Patch:

  diff -C 3 -X tktext-ignore -I *Copyright* tk8.2orig/generic/tkText.c tk8.2/generic/tkText.c

  *** tk8.2orig/generic/tkText.cSun Sep 05 15:11:10 1999

  --- tk8.2/generic/tkText.cSun Sep 05 15:21:13 1999

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

  *** 1515,1522 ****

        }

        TkTextMarkSegToIndex(textPtr, textPtr->insertMarkPtr, &index);

        TkTextCharBbox(textPtr, &index, &x, &y, &w, &h);

  !     TkTextRedrawRegion(textPtr, x - textPtr->insertWidth / 2, y,

  !     textPtr->insertWidth, h);

    }

    

    /*

  --- 1515,1527 ----

        }

        TkTextMarkSegToIndex(textPtr, textPtr->insertMarkPtr, &index);

        TkTextCharBbox(textPtr, &index, &x, &y, &w, &h);

  !     if (textPtr->insertWidth > 2) {

  ! TkTextRedrawRegion(textPtr, x - 1, y,

  ! textPtr->insertWidth, h);

  !     } else {

  ! TkTextRedrawRegion(textPtr, x - textPtr->insertWidth / 2, y,

  ! textPtr->insertWidth, h);

  !     }

    }

    

    /*

  diff -C 3 -X tktext-ignore -I *Copyright* tk8.2orig/generic/tkTextMark.c tk8.2/generic/tkTextMark.c

  *** tk8.2orig/generic/tkTextMark.cThu Apr 15 19:51:24 1999

  --- tk8.2/generic/tkTextMark.cSun Sep 05 15:28:39 1999

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

  *** 522,530 ****

     * corresponds to y. */

    {

        TkText *textPtr = (TkText *) chunkPtr->clientData;

  !     int halfWidth = textPtr->insertWidth/2;


  !     if ((x + halfWidth) < 0) {

    /*

     * The insertion cursor is off-screen.  Just return.

     */

  --- 522,530 ----

     * corresponds to y. */

    {

        TkText *textPtr = (TkText *) chunkPtr->clientData;

  !     int leftSideWidth = (textPtr->insertWidth > 2 ? 1 : textPtr->insertWidth/2);


  !     if ((x + textPtr->insertWidth - leftSideWidth) < 0) {

    /*

     * The insertion cursor is off-screen.  Just return.

     */

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

  *** 542,552 ****


        if (textPtr->flags & INSERT_ON) {

    Tk_Fill3DRectangle(textPtr->tkwin, dst, textPtr->insertBorder,

  ! x - textPtr->insertWidth/2, y, textPtr->insertWidth,

    height, textPtr->insertBorderWidth, TK_RELIEF_RAISED);

        } else if (textPtr->selBorder == textPtr->insertBorder) {

    Tk_Fill3DRectangle(textPtr->tkwin, dst, textPtr->border,

  ! x - textPtr->insertWidth/2, y, textPtr->insertWidth,

    height, 0, TK_RELIEF_FLAT);

        }

    }

  --- 542,552 ----


        if (textPtr->flags & INSERT_ON) {

    Tk_Fill3DRectangle(textPtr->tkwin, dst, textPtr->insertBorder,

  ! x - leftSideWidth, y, textPtr->insertWidth,

    height, textPtr->insertBorderWidth, TK_RELIEF_RAISED);

        } else if (textPtr->selBorder == textPtr->insertBorder) {

    Tk_Fill3DRectangle(textPtr->tkwin, dst, textPtr->border,

  ! x - leftSideWidth, y, textPtr->insertWidth,

    height, 0, TK_RELIEF_FLAT);

        }

    }


  PatchFiles:

  tkText.c

      tkTextMark.c




  The text widget cursor is only designed as an 'insertion' cursor,
  and not as a block cursor.  That would require a different style
  of drawing (instead of a filled rect, it would have to be unfilled
  over the boundary of a char). 
  -- 09/10/1999 hobbs


tkt_uuid: 3294450fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 8
foundin: obsolete: 8.5.9
resolution: Fixed
title: Ttk label does not show multiline text if widget clipped
comment:
  Given a ttk label widget with two text lines like:
  "ABCDEF
  ABC"
  The widget is packed in such a way, theat the x space is not sufficient and the last character of the first line is not shown.
  In this case, the output is:
  "ABCDE
  "
  thus the second row is empty.
  IMHO it should be:
  "ABCDE
  ABC"

  Test code:
  % pack [ttk::label .l -text [string repeat 1234567890 10]\nrow2\nrow3]
  % wm resizable . 1 1
  Resize the window in x direction until the first text line is clipped.

  Platform: Windows Vista Pro 32 bit
  wish 8.5.9 self compiled with MSVC6


tkt_uuid: 220254ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Invalid
title: tk_getOpenFile -initialdir option not working
comment:
  OriginalBugID: 3506 Bug
  Version: 8.2
  SubmitDate: '1999-11-08'
  LastModified: '1999-11-16'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: P-II pc clone.
  ClosedDate: '1999-11-16'


  Name: C. Allen Flick

  ReproducibleScript:
  source the following into a wish.

  cd /work ; # this is where my script resides
  for {set ctr 0} {$ctr < 10} {incr ctr} {
  set fname [ tk_getOpenFile -initialdir c:\WHATEVER -title "Getting It \#$ctr" ]
  }

  ObservedBehavior:
  With each iteration of the loop, the directory that is brought up with tk_getOpenFile is the one in
  which I was working, i.e. c:/work, regardless what is put into the -initialdir option.

  DesiredBehavior:
  I would expect the file selection dialog to come up in WHATEVER directory is specified within
  the -initialdir option.



  Could not verify this on Win98 or NT.  It is likely that the
  user is giving a non-existent directory (note that C:\Whatever
  is C:hatever after substitution), which doesn't complain, but
  instead uses pwd. 
  -- 11/16/1999 hobbs


tkt_uuid: 1004508fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: Fixed
title: array expansion can remove user's text
comment:
  There's an annoying little problem in the way that 
  wish8.5 and tkcon 2.4 expand environment variables:

  Given a text 'env(HO', ESCAPE (wish) or TAB (tkcon)
  expands it to env(HOME). However, if you press
  the expansion key twice, through mistake or impatience,
  the text becomes env().

  The problem is in ::tk::console::ExpandVariable
  in Console.tcl. It deals with multiple matches and
  then does:

     } else {
        set match $ary\($match\)
     }

  this should be:

     } elseif {[llength $match] == 1} {
        set match $ary\($match\)
     }

  unmatched array elements are then left untouched.

  Problem seen in self built 8.4.3 and in ActiveTcl 8.5a1 on
  Windows XP.


tkt_uuid: 1056161fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a2
resolution: Fixed
title: Sporadic crashes in text widget
comment:
  From time to time, wish8.5 crashes with the panic
  message "LayoutDLine couldn't place any characters on a
  line".   Stack trace atttached.

  I can't reliably replicate the problem, but it tends to
  happen in tkchat while scrolling the log window.


tkt_uuid: 3141377fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 65. Generic Window Operations
priority: 6
foundin: obsolete: 8.5.9
resolution: None
title: [winfo screenwidth/height] fail to track resolution changes
comment:
  Hi!

  After I change a screen resolution on my Debian GNU/Linux system (by xrandr, e.g. xrandr -s 800x600) [winfo screenwidth .] and [winfo screenheight .] are still reporting the old width and height values.

  I've tried 8.4.19 and 8.5.9 (didn't 8.6 or HEAD though).


tkt_uuid: 1088810fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 52. [clipboard]
priority: 2
foundin: obsolete: 8.5a3
resolution: None
title: Aqua: tests fail
comment:
  ==== clipboard-4.1 ClipboardLostSel procedure FAILED
  ==== Contents of test case:

      clipboard clear
      clipboard append "Test"
      selection clear -s CLIPBOARD
      list [catch {clipboard get} msg] $msg

  ---- Result was:
  1 {CLIPBOARD GetScrapFlavorSize failed.}
  ---- Result should have been (exact matching):
  1 {CLIPBOARD selection doesn't exist or form "STRING"
  not defined}
  ==== clipboard-4.1 FAILED

  ---- clipboard-4.2 start

  ==== clipboard-4.2 ClipboardLostSel procedure FAILED
  ==== Contents of test case:

      clipboard clear
      clipboard append "Test"
      clipboard append -t TEST "Test2"
      selection clear -s CLIPBOARD
      list [catch {clipboard get} msg] $msg  [catch
  {clipboard get -t TEST} msg] $msg

  ---- Result was:
  1 {CLIPBOARD GetScrapFlavorSize failed.} 1 {CLIPBOARD
  selection doesn't exist or form "TEST" not defined}
  ---- Result should have been (exact matching):
  1 {CLIPBOARD selection doesn't exist or form "STRING"
  not defined} 1 {CLIPBOARD selection doesn't exist or
  form "TEST" not defined}
  ==== clipboard-4.2 FAILED

  ---- clipboard-4.3 start
  ==== clipboard-4.3 ClipboardLostSel procedure FAILED
  ==== Contents of test case:

      clipboard clear
      clipboard append "Test"
      clipboard append -t TEST "Test2"
      clipboard append "Test3"
      selection clear -s CLIPBOARD
      list [catch {clipboard get} msg] $msg  [catch
  {clipboard get -t TEST} msg] $msg

  ---- Result was:
  1 {CLIPBOARD GetScrapFlavorSize failed.} 1 {CLIPBOARD
  selection doesn't exist or form "TEST" not defined}
  ---- Result should have been (exact matching):
  1 {CLIPBOARD selection doesn't exist or form "STRING"
  not defined} 1 {CLIPBOARD selection doesn't exist or
  form "TEST" not defined}
  ==== clipboard-4.3 FAILED
  ==== clipboard-6.2 Tk_ClipboardAppend procedure FAILED
  ==== Contents of test case:

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

  ---- Result was:
  CLIPBOARD selection doesn't exist or form "TEST" not
  defined
  ---- Result should have been (exact matching):
  0x10
  ==== clipboard-6.2 FAILED


tkt_uuid: 1288677fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a4
resolution: Fixed
title: elide removes more than just text
comment:
  Fix:-
  Revert line 1352 in tkTextDisp.c 1.52 from
  if (!elide && chunkPtr->numBytes > 0) {
  to
  if (chunkPtr->numBytes > 0) {

  This causes no new test failures on WinXP


  From the man pages:-

  Elide specifies whether the data should be elided. 
  Elided data is not displayed and takes no space on 
  screen, but further on behaves just as normal data. 

  However after the changes in tkTextDisp.c from 1.16 
  to 1.17, elide no longer allows the formatting 
  information from the tag to be used.

  example text dump:-
  tagon NICK-ivany 7.1 tagon STAMP 7.1 text 
  {[18:39]    } 7.1 tagoff STAMP 7.9 tagon NICK 7.9 
  text {ivany    } 7.9 tagoff NICK 7.15 tagon MSG 7.15 
  text /see 7.15 tagoff MSG 7.19 tagon NICK 7.19 text {
  } 7.19 tagoff NICK 8.0 tagoff NICK-ivany 8.0

  If the STAMP tag has a -lmargin value of 20 then the 
  output should be (approx.)
    [18:39]    ivany    /see

  If STAMP is then elided we get this in 8.4.11
    ivany    /see

  in 8.5 we get (without the initial indent)
  ivany    /see


tkt_uuid: 666346ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 9 Immediate
foundin: obsolete: 8.4.1
resolution: Fixed
title: Selection handling crashes under KDE 3.0
comment:
  Consider the following simple script:

      set win .f
      label $win -text "I am the selection owner.\nClick
  on <Close>."
      selection own $win
      selection handle $win [list fetchSelection $win]

      button .b -text "Close" -command exit
      pack $win .b -padx 10 -pady 5

      proc fetchSelection {win offset maxChars} {
          return ""
      }

  Running the script with wish8.4 under KDE 3.0 and
  clicking on the
  "Close" button raises the message "Segmentation fault".

  The abnormal termination seems to be caused by a bug in
  the C-code
  related to the "selection handle" command.  After
  experiencing the
  problem using the ActiveState binary distribution, I
  compiled Tcl and
  Tk 8.4.1 with the TCL_MEM_DEBUG flag and ran the script
  again.
  The result was a premature termination of the program
  with the
  message

      unable to alloc 1633771903d bytes,
      /home/csaba/tcltk/tk8.4.1/generic/tkSelect.c line 1382

  (BTW:  The "d" appended to the erronously huge number
  of bytes
  above is due to the incorrect use of the format
  descriptor "%ud"
  instead of just "%u" in the file "generic/tclCkalloc.c".)

  By replacing "exit" with "destroy .", or even just
  [list destroy $win],
  the behavior remains unchanged.

  I have also checked out the newest CVS version of Tcl
  and Tk, and got
  the same segmentation fault.

  I suspect that the new (objectified) version of
  tkSelect.c (or of some
  other C file related to selection handling) has a bug
  that causes the
  crash under KDE 3.0.  Note that the attempt to allocate
  1.6 GB
  memory occurs still before the window could become
  completely
  visible.  This is probably because the first attempt to
  retrieve the
  selection occurs within a very short time (of one or
  two seconds). 

  Bryan Oakley's mclistbox and my Tablelist package make
  use of the
  "selection own" and "selection handle" commands to
  implement the
  "-exportselection" option.  Unfortunately, this bug
  makes it necessary
  to set the "-exportselection" option of all tablelist
  and mclistbox
  widgets to false (at least when created with Tk 8.4
  under KDE 3.0).


tkt_uuid: 220086ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Duplicate
title:
  various windows fonts (e.g., fixedsys, ms sans serif) don't display correctly in italic and bold forms

comment:
  OriginalBugID: 5305 Bug
  Version: 8.3
  SubmitDate: '2000-05-01'
  LastModified: '2000-05-10'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2583
  OS: Windows 95
  ClosedDate: '2000-05-10'


  Name:
  keith lea

  ReproducibleScript:
  set f [eval font create [font actual systemfixed] -weight bold -slant italic]
  pack [text .x -font $f -width 40 -height 7 -wrap word] -expand 1 -fill both

  .x insert end {Some random sample text.
  Here is more data
  some more data here: blaf blaasd asd asd asd asd asdasd asd.}

  set len [string length [.x get 1.0 end]]

  focus .x

  for {set i 0} {$i < $len} {incr i} {
      .x tag remove sel 1.0 end
      .x tag add sel "1.0 + $i char" "1.0 + [expr {$i + 5}] char"
      update
      after 100
  }

  ObservedBehavior:
  the textbox displays with large spaces on the borders of the selection


tkt_uuid: 843752ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: two new test failures
comment:
  In the latest HEAD, these failures
  are new (on Linux/Alpha):

  ==== textDisp-27.7 SizeOfTab procedure, center
  alignment, wrap -none (potential
  numerical problems) FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t configure -tabs {1c 2c center 3c 4c} -wrap none
  -width 40
      .t insert 1.0
  a\tb\tc\td\te\n012345678934567890a\tbb\tcc\tdd
      update
      .t bbox 2.24

  ---- Result was:
  187 18 7 13
  ---- Result should have been (exact matching):
  200 18 7 13
  ==== textDisp-27.7 FAILED


  ==== textDisp-29.2.5 miscellaneous: can show last
  character FAILED
  ==== Contents of test case:

      catch {destroy .t2}
      toplevel .t2
      wm geometry .t2 121x141+200+200
      text .t2.t -width 5 -height 5 -font {Arial 10} 
  -wrap none -xscrollcommand "
  .t2.s set"  -bd 2 -highlightthickness 0 -padx 1
      .t2.t insert end "WWWWWWWWWWWWi"
      scrollbar .t2.s -orient horizontal -command ".t2.t
  xview"
      grid .t2.t -row 0 -column 0 -sticky nsew
      grid .t2.s -row 1 -column 0 -sticky ew
      grid columnconfigure .t2 0 -weight 1
      grid rowconfigure .t2 0 -weight 1
      grid rowconfigure .t2 1 -weight 0
      update ; update
      set xv [.t2.t xview]
      set xd [expr {[lindex $xv 1] - [lindex $xv 0]}]
      .t2.t xview moveto [expr {1.0-$xd}]
      set iWidth [lindex [.t2.t bbox end-2c] 2]
      .t2.t xview scroll 2 units
      set iWidth2 [lindex [.t2.t bbox end-2c] 2]

      if {($iWidth == $iWidth2) && $iWidth > 2} {
          set result "correct"
      } else {
          set result "not correct"
      }

  ---- Result was:
  not correct
  ---- Result should have been (exact matching):
  correct
  ==== textDisp-29.2.5 FAILED


  Also, tests textDisp-33.* take a long time to
  complete, as if they're waiting for some
  timeout to expire?


tkt_uuid: 546333ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: message catalogs not namespaced
comment:
  The [mcset] command of the msgcat package uses
  its namespace context to keep message catalogs
  from different packages from conflicting with
  one another.  In order for this to work, the
  message catalogs provided by each package need
  to be evaluated in the namespace of that package.

  This means each file matching tk/library/msgs/*msg
  ought to have its contents enclosed in a

  namespace eval ::tk { ... }

  If desired, the catalogs could be broken down
  further according to the internal namespaces of
  Tk, but the simple step above is sufficient.


tkt_uuid: 220640ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: Tk make install fails
comment:
  OriginalBugID: 3896 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-17'
  LastModified: '1999-12-20'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: QNX 4.25
  Machine: i586
  FixedDate: '1999-12-20'
  FixedInVersion: 8.3b1


  Name:
  Bruce Edge

  ReproducibleScript:
  A test in the makefile does not execute as expected under QNX. This is similar to the bug report I submitted for tcl.

  ObservedBehavior:
  # //8/usr/local/src/tk8.2.3/unix> make install
  Installing libtk8.2g.a
  chmod +x //8/usr/local/src/tk8.2.3/unix/install-sh
  chmod +x //8/usr/local/src/tk8.2.3/unix/mkLinks
  Installing wish
  Installing tkConfig.sh
  make: *** [install-binaries] Error 1

  Patch:
  *** Makefile    Fri Dec 17 10:09:17 1999
  --- Makefile.new        Fri Dec 17 11:46:16 1999
  ***************
  *** 42,48 ****
    TK_LIBRARY =          $(prefix)/lib/tk$(VERSION)

    # Path name to use when installing library scripts:
  ! SCRIPT_INSTALL_DIR =  $(INSTALL_ROOT)/$(TK_LIBRARY)

    # Directory in which to install the .a or .so binary for the Tk library:
    LIB_INSTALL_DIR =     $(INSTALL_ROOT)$(exec_prefix)/lib
  --- 42,48 ----
    TK_LIBRARY =          $(prefix)/lib/tk$(VERSION)

    # Path name to use when installing library scripts:
  ! SCRIPT_INSTALL_DIR =  $(INSTALL_ROOT)$(TK_LIBRARY)

    # Directory in which to install the .a or .so binary for the Tk library:
    LIB_INSTALL_DIR =     $(INSTALL_ROOT)$(exec_prefix)/lib
  ***************
  *** 446,457 ****
          @$(INSTALL_PROGRAM) wish $(BIN_INSTALL_DIR)/wish$(VERSION)
          @echo "Installing tkConfig.sh"
          @$(INSTALL_DATA) tkConfig.sh $(LIB_INSTALL_DIR)/tkConfig.sh
  !       @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
  !       @if test "$(TK_STUB_LIB_FILE)" != "" ; then  echo "Installing $(TK_STUB_LIB_FILE)";  $(INSTALL_DATA) $(STUB_LIB_FILE)  $(LIB_INSTALL_DIR)/$(TK_STUB_LIB_FILE);  --- 446,457 ----
          @$(INSTALL_PROGRAM) wish $(BIN_INSTALL_DIR)/wish$(VERSION)
          @echo "Installing tkConfig.sh"
          @$(INSTALL_DATA) tkConfig.sh $(LIB_INSTALL_DIR)/tkConfig.sh
  ! #     @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
  !       if test "$(TK_STUB_LIB_FILE)" != "" ; then  echo "Installing $(TK_STUB_LIB_FILE)";  $(INSTALL_DATA) $(STUB_LIB_FILE)  $(LIB_INSTALL_DIR)/$(TK_STUB_LIB_FILE);  
  PatchFiles:
  Makefile



  The SCRIPT_INSTALL_DIR fix is correct and has been made for 8.3b1.
  The other fix looks like a problem with 'test' on the platform,
  because it should be able to check "" != "". 
  -- 12/20/1999 hobbs


tkt_uuid: 220757ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: Italian message catalog
comment:
  OriginalBugID: 6012 RFE
  Version: 8.4a1
  SubmitDate: '2000-07-14'
  LastModified: '2000-07-17'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Linux
  FixedDate: '2000-07-17'
  FixedInVersion: 8.4a2


  Name:
  Paolo Brutti

  CVS:
  July 14 2000

  DesiredBehavior:
  Italian message catalog for Tk localization

  PatchFiles:
  ::msgcat::mcset it "Abort" "Interrompi"
      ::msgcat::mcset it "About..." "Informazioni ..."
      ::msgcat::mcset it "All Files" "Tutti i file"
      ::msgcat::mcset it "Application Error" "Errore dell' applicazione"
      ::msgcat::mcset it "Blue" "Blu"
      ::msgcat::mcset it "Cancel" "Annulla"
      ::msgcat::mcset it "Cannot change to the directory
      \"%1\$s\".\nPermission denied." "Impossibile accedere alla directory
      \"%1\$s\".\nPermesso negato."
      ::msgcat::mcset it "Choose Directory" "Scegli directory"
      ::msgcat::mcset it "Clear" "Azzera"
      ::msgcat::mcset it "Color" "Colore"
      ::msgcat::mcset it "Console"
      ::msgcat::mcset it "Copy" "Copia"
      ::msgcat::mcset it "Cut" "Taglia"
      ::msgcat::mcset it "Delete" "Incolla"
      ::msgcat::mcset it "Details >>" "Dettagli >>"
      ::msgcat::mcset it "Directory \"%1\$s\" does not exist." "La directory
      \"%1\$s\" non esiste."
      ::msgcat::mcset it "Directory:"
      ::msgcat::mcset it "Error: %1\$s" "Errore: %1\$s"
      ::msgcat::mcset it "Exit" "Esci"
      ::msgcat::mcset it "File \"%1\$s\" already exists.\nDo you want to
      overwrite it?" "Il file \"%1\$s\" esiste gi\u00e0.\nVuoi
      sovrascriverlo?"
      ::msgcat::mcset it "File \"%1\$s\" already exists.\n\n" "Il file
      \"%1\$s\" esiste gi\u00e0.\n\n"
      ::msgcat::mcset it "File \"%1\$s\" does not exist." "Il file \"%1\$s\"
      non esiste."
      ::msgcat::mcset it "File name:" "Nome del file:"
      ::msgcat::mcset it "File names:" "Nomi dei file:"
      ::msgcat::mcset it "Files of type:" "File di tipo:"
      ::msgcat::mcset it "Files:" "File:"
      ::msgcat::mcset it "Filter" "Filtro"
      ::msgcat::mcset it "Filter:" "Filtro:"
      ::msgcat::mcset it "Green" "Verde"
      ::msgcat::mcset it "Hi" "Salve"
      ::msgcat::mcset it "Hide Console" "Nascondi la console"
      ::msgcat::mcset it "Ignore" "Ignora"
      ::msgcat::mcset it "Invalid file name \"%1\$s\"." "Nome di file non
      valido \"%1\$s\"."
      ::msgcat::mcset it "Log Files" "File di log"
      ::msgcat::mcset it "No"
      ::msgcat::mcset it "OK"
      ::msgcat::mcset it "Ok"
      ::msgcat::mcset it "Open" "Apri"
      ::msgcat::mcset it "Open Multiple Files" "Apri file multipli"
      ::msgcat::mcset it "Paste" "Incolla"
      ::msgcat::mcset it "Quit" "Esci"
      ::msgcat::mcset it "Red" "Rosso"
      ::msgcat::mcset it "Replace existing file?" "Sostituisci il file
      esistente?"
      ::msgcat::mcset it "Retry" "Riprova"
      ::msgcat::mcset it "Save" "Salva"
      ::msgcat::mcset it "Save As" "Salva come"
      ::msgcat::mcset it "Save To Log" "Salva il log"
      ::msgcat::mcset it "Select Log File" "Scegli un file di log"
      ::msgcat::mcset it "Select a file to source" "Scegli un file da
      eseguire"
      ::msgcat::mcset it "Selection:" "Selezione:"
      ::msgcat::mcset it "Skip Messages" "Salta i messaggi"
      ::msgcat::mcset it "Source..." "Esegui..."
      ::msgcat::mcset it "Tcl Scripts" "Scripts Tcl"
      ::msgcat::mcset it "Tcl for Windows" "Tcl per Windows"
      ::msgcat::mcset it "Text Files" "File di testo"
      ::msgcat::mcset it "Yes" "Si"
      ::msgcat::mcset it "abort" "interrompi"
      ::msgcat::mcset it "blue" "blu"
      ::msgcat::mcset it "cancel" "annulla"
      ::msgcat::mcset it "extension" "estensione"
      ::msgcat::mcset it "extensions" "estensioni"
      ::msgcat::mcset it "green" "verde"
      ::msgcat::mcset it "ignore" "ignora"
      ::msgcat::mcset it "ok"
      ::msgcat::mcset it "red" "rosso"
      ::msgcat::mcset it "retry" "riprova"
      ::msgcat::mcset it "yes" "si"



  Thanks for the message catalog.  I added it to the CVS repository, and it will go out with 8.4a2.  Thanks!

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

  -- 07/17/2000 ericm


tkt_uuid: 1114977fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 9 Immediate
foundin: obsolete: 8.4.9
resolution: Fixed
title: tkCanvas.c thread-unsafe UID usage!
comment:
  WHEN:
  When multiple threads of execution in same process have
  their own TCL vm's with canvas widgets instances.
  WHAT:
  canvas's "tags" functionality gets totally screwed. For
  example, IWidget::calendar crashes
  HOW:
  tkCanvas.c contains definitions of various variables
  for uid caching. For example: "static Tk_Uid allUid;"
  (line 21). These variables get assigned their
  respective values when first instance of canvas in
  _whole_ _process_ (!) is being instantiated. This is
  done in "Tk_CanvasObjCmd" by means of function
  "CanvasInit" call (line 370). "allUid", and other
  similar variables get their values as return values
  from Tk_GetUid function call (line 2781).
  All values that are to be compared with several special
  words (like "all" is) are compared with said variables
  (code like: if( Tk_GetUid( "something ) == allUid))
  However, Tk_GetUid uses dictionary (hash table) which
  gets allocated per-thread, not per-process. That means
  that values of "allUid" and similar variables will get
  initialized with keys from dictionary belonging to
  first thread that ever creates canvas! All subsequently
  created canvasses will use these values (from first
  thread's UID dictionary). Suppose that canvas belonging
  to other thread of execution wants to compare
  "something" with such keys. It will use "Tk_Uid(
  "something" ) == allUid" and this will always fall,
  regardless of "something"'s value.
  FIX:
  Quick and dirty fix is to uncomment line "#define
  USE_OLD_TAG_SEARCH 1" (line 19 in tkCanvas.c), since
  old search algorithm uses no global data. This works,
  althought I'm not aware of other consequences it may
  have. Nice fix would be to change either these global
  variables to per-thread (or per-instance) ones or make
  Tk_GetUid use global dictionary. Alas, I don't know
  enough about TCL/TK source code to make such changes on
  my own. However, should someone experienced give me
  advice on what to do, I'll try to find time to fix it.
  Best regards
  Michal Adamczak (ma<NOSPAM>@ant-iss.com)


tkt_uuid: 232499ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Duplicate
title: support vertical text in canvas
comment:
  We use a Tk extension to create Vertical text (e.g. for Graph axis).  This extension is provided by a file called tkSticker.c

  Usage example:

  .c create sticker 10 20 100 120 -anchor center -bar {} -color red -fill {} 

  We have this xtn working in Tk 8.0, but not in v8.3
  Should we try, or can we do this (vertical text) another way in v8.3?

  Does anybody know anything about this - or want any further information?

   thanks & regards,  Thomas.


tkt_uuid: 1639824fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: Setting -sashwidth to 0 makes wish abort on X11
comment:
  In X11, setting the -sashwidth option of panedwindow to 0 makes
  wish abort with a bad X request when Tk try to create a proxy window.
  Apparently in X is invalid to create a window of width 0.

  emiliano@erizo:~$ wish8.4 
  % pack [panedwindow .pw -sashwidth 0]
  % .pw add [label .l1 -text Hello]
  % .pw add [label .l2 -text world]
  % 

  and after resizing the pane I get:

  X Error of failed request:  BadValue (integer parameter out of range for operation)
    Major opcode of failed request:  1 (X_CreateWindow)
    Value in failed request:  0x0
    Serial number of failed request:  232
    Current serial number in output stream:  234
  emiliano@erizo:~$

  The same problem occurs if the proxy window is created by the script:

  emiliano@erizo:~$ wish8.4 
  % pack [panedwindow .pw -sashwidth 0]
  % .pw add [label .l1 -text Hello]
  % .pw add [label .l2 -text world]
  % .pw proxy place 0 0
  X Error of failed request:  BadValue (integer parameter out of range for operation)
    Major opcode of failed request:  1 (X_CreateWindow)
    Value in failed request:  0x0
    Serial number of failed request:  152
    Current serial number in output stream:  154
  emiliano@erizo:~$


tkt_uuid: 220223ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Invalid
title: not enough event handling in tk widgets
comment:
  OriginalBugID: 2574 RFE
  Version: 8.1
  SubmitDate: '1999-08-18'
  LastModified: '1999-08-19'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: 6.0
  Machine: Other
  ClosedDate: '1999-08-19'


  Name:
  Jeff Chan

  Extensions:
  tk

  DesiredBehavior:
  I would like the ability to have more control over tk widgets for
      the purposes of the plugin in netscape especially (unix/win/mac).
      I need to validate data onfocus, onblur, onenter, onthis, onthat
      etc.  I also need to be able to enter nonmutable data into a 
      text field say (  )  -   for phone and also define maxlength.
      this is very important to our applications. How can we achieve this
      functionality and when do you plan on providing it?



  This functionality is already available in some way.  The full range
  of events (FocusIn, FocusOut, Enter, Leave, ...) is defined under
  the 'bind' man page.  The ability to validate data in an entry
  widget can be found in the Tk Usage FAQ:
      http://www.purl.org/net/hobbs/tcl/faqs/tk/

  We are also looking to make some of that support native, but the
  ability is already there. 
  -- 08/19/1999 hobbs


tkt_uuid: 1660759fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: Duplicate
title: called Tcl-FindHashEntry on deleted table
comment:
  Sometimes I have troubles "destroy"ing the main toplevel widget - the application crashes - but I was not able to draw it down to a small application.
  Today - when exiting the application I got a fatal error in wish: "called Tcl-FindHashEntry on deleted table".

  thanks


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: 2797260fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: wm attributes -fullscreen conflicts with menu
comment:
  If a toplevel has a menu and is set to full screen, the following issues arise:
  - after an update, the window is shown in full screen but this state is not reflected by "wm attribute -fullscreen"
  - it is not possible to leave full screen mode

  -Test script started with wish fullscreen_error.tcl-
    console show
    . config -menu [menu .m]
    wm attributes . -fullscreen 1
    puts [wm attributes . -fullscreen]
    update
    puts [wm attributes . -fullscreen]
  -EOF-
  The console output is : 1 0
  A manual "wm attributes . -fullscreen 0" will not return to a decorated normal window.

  Platform: Windows Vista German SP1 Classic skin
  Tcl/Tk 8.5.7, compiled by MS-VC 6, Platform SDK Win2003

  This issue does not arise on Linux with Tk 8.5.5


tkt_uuid: 1693649fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Fixed
title: More Canvas Text Orientations
comment:
  [Refiling of mis-filed Tcl FRQ 1689339]

  Canvas text items should have an option -rotation (0, 90, 180, 270) to specify orthogonal angles to render the text.

  Text rotated on these orientations is common in documentation tools used in many disciplines. The lack of such a feature in the Tk canvas makes it impossible to accurately provide Tk canvas representations of many datasets in engineering and business.

  A related option would also be useful -mirror (boolean) which would cause the text to be reflected. This is also common in engineering drawings where text is to be displayed as if you are looking at the page from the "back side".

  Ken
  neq-design@att.net


tkt_uuid: 220224ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: final: 8.1.1
resolution: Remind
title: Incorrect SHLIB_LD for SunOS4 & gcc
comment:
  OriginalBugID: 2576 Bug
  Version: 8.1.1
  SubmitDate: '1999-08-18'
  LastModified: '2000-04-14'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: SunOS
  Machine: Sparc
  ClosedDate: '2000-04-14'


  Name:
  David Wilson

  ReproducibleScript:
  When building on Tk 8.1.1. on SunOS 4 using gcc 2.7.2 (having specified
      --enable-gcc --enable-shared to configure) the tk shared library failed
      to
      build with unresolved symbols. This is probably because SHLIB_LD was set
      to
      'ld', while it should be gcc -shared when using gcc (and probably ld -G
      when
      using other compilers on a number of platforms).

  ObservedBehavior:
  Does not build

  DesiredBehavior:
  The Makefile created by configure should set the correct options.



  We need a specific patch that is known to work correctly for
  the SunOS env, as we have no access to one and don't want to
  potentially break a build. 
  -- 04/14/2000 hobbs


tkt_uuid: 220760ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.3.2
resolution: Fixed
title: Patch to correct menu checkboxes on Win2K
comment:
  OriginalBugID: 6134 Bug
  Version: 8.3.2
  SubmitDate: '2000-08-14'
  LastModified: '2000-08-29'
  Severity: MED
  Status: Released
  Submitter: ericm
  ChangedBy: ericm
  RelatedBugIDs: 6177
  OS: Windows 2000
  FixedDate: '2000-08-29'
  FixedInVersion: 8.4a2


  Erik,



  first please excuse me sending this personally, but though

  I'm a registered member at the Tcl Developer Exchange the

  bug database simply does not run here...



  Attached you will find some very small patches (actually it's just

  three lines) against the current Tk CVS version. A ChangeLog

  entry follows below as well.



  These fix the following things:



    - under Windows 2000, menu checkboxes are plain wrong

      (not enought space, some times only some pixels visible)



    - while debugging a program with Purify I've found the need

      for an additonal memset() 



  As I'm no real Windows guru I'd ask to double check. Of course,

  it works fine for me (TM).



  Best Regards,

  Markus





  2000-08-09  Markus F.X.J. Oberhumer  <markus.oberhumer@jk.uni-linz.ac.at>



          * win/tkWinMenu.c (DrawWindowsSystemBitmap): Use scratchDC

          for determining the source's logical coordinates.



          * win/tkWinMenu.c (SetDefaults): Compute the indicatorDimensions[]

          under Windows NT/2000 in the same way as under Windows 95/98.



          * win/tkWinFont.c (GetScreenFont): Added a memset() to

          pacify memory checkers.





  diff -ur win.orig/tkWinFont.c win/tkWinFont.c

  --- win.orig/tkWinFont.cWed May 17 02:34:35 2000

  +++ win/tkWinFont.cWed Aug  9 02:13:38 2000

  @@ -1931,6 +1931,7 @@

       HFONT hFont;

       LOGFONTW lf;

   

  +    memset(&lf, 0, sizeof(lf));

       lf.lfHeight= -pixelSize;

       lf.lfWidth= 0;

       lf.lfEscapement= 0;

  diff -ur win.orig/tkWinMenu.c win/tkWinMenu.c

  --- win.orig/tkWinMenu.cSat Jul 29 14:51:56 2000

  +++ win/tkWinMenu.cWed Aug  9 02:14:58 2000

  @@ -1449,7 +1449,7 @@

       DPtoLP(hdc, &ptSize, 1);

   

       ptOrg.y = ptOrg.x = 0;

  -    DPtoLP(hdc, &ptOrg, 1);

  +    DPtoLP(scratchDC, &ptOrg, 1);

   

       if (alignFlags & ALIGN_BITMAP_TOP) {

   topOffset = 0;

  @@ -2715,7 +2715,7 @@

        * documented.

        */

   

  -    if (TkWinGetPlatformId() == VER_PLATFORM_WIN32_WINDOWS) {

  +    if (TkWinGetPlatformId() >= VER_PLATFORM_WIN32_WINDOWS) {

   indicatorDimensions[0] = GetSystemMetrics(SM_CYMENUCHECK);

   indicatorDimensions[1] = ((GetSystemMetrics(SM_CXFIXEDFRAME) +

   GetSystemMetrics(SM_CXBORDER) 



  Thanks for the patch.  I've applied it and committed the change to CVS.  The fix will be included in Tcl/Tk 8.4a2.  Nice work!

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

  -- 08/29/2000 ericm


tkt_uuid: 742773ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.4.3
resolution: None
title: 10,000 widgets leaves some undisplayed
comment:
  This may be a Windows-specific bug.  Consider the
  following two scripts:

  GRID VERSION:  (warning: slow)

  for {set i 0} {$i < 80} {incr i} {
    for {set j 0} {$j < 125} {incr j} {
      frame .x${i}y${j} -width 5 -height 5 -background red
      grid .x${i}y${j} -row $i -column $j -padx 1 -pady 1
    }
  }

  PACK VERSION:

  for {set i 0} {$i < 80} {incr i} {
    frame .x$i
    for {set j 0} {$j < 125} {incr j} {
      frame .x${i}.y${j} -width 5 -height 5 -background red
      pack .x${i}.y${j} -side right -padx 1
    }
    pack .x$i -side bottom -pady 1
  }

  On both ActiveTcl 8.4.3 and the Cygwin's Tcl/Tk 8.4.x
  build, these scripts leave some of the last
  (upper-left) frames undisplayed on my Windows box
  (Pentium III 1.2GHz with 640 MB of RAM).  These frames
  seem to be mapping to the upper-left corner of the
  screen (not the window!).  See the attached screenshot.
   There may be a memory-related issue here, but it seems
  reproducible by several people on #tcl.

  The same behavior occurs with buttons instead of
  frames; it's just easier to make frames small.

  As a side note, the grid version of the code is
  excessively slow, and can take a minute or more to
  display.  See bug 220200.


tkt_uuid: 220936ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Accepted
title: conceal Tk's privates :)
comment:
  OriginalBugID: 6016 RFE
  Version: 8.4a1
  SubmitDate: '2000-07-17'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: All


  Name:
  Don Porter

  CVS:
  2000-07-16 state of CVS repository

  Comments:
  Please note that this patch does not move
      any of Tk's *public* commands into ::tk as
      I've been advocating recently in comp.lang.tcl.
      
      It moves only private commands and variables,
      which should be harmless to those who've
      resisted the temptation to directly access
      Tk's privates.
      
      I expect to submit another patch offering
      a compatibility interface to support those
      who have their code broken by this patch
      because they relied on undocumented private
      interfaces.  Stay tuned.

  DesiredBehavior:
  In addition to the commands and variables which
  comprise Tk's public interface, Tk defines many
  other commands and variables intended for its
  own private use only.  It is a legacy from
  Tk 4 that many of these private commands and
  variables are defined in the global namespace.

  I request that Tk's privates be placed in
  the ::tk namespace or its child namespaces.
  I include a patch which I think does the job,
  but this is a big task, so it would be good
  to have others check my work -- especially
  on other platforms.

  On my Linux/x86 box, the Tk test suite shows
  no failed tests both before and after this
  patch is applied.

  Patch:
  The patch is too large (584kB) to inflict on
  the web form / newsgroup.  Instead, download
  it from:

  http://math.nist.gov/~DPorter/tcltk/patches/tk84a1private.txt

  PatchFiles:
  File: tkvars.n          Status: Locally Modified
      File: tkBind.c          Status: Locally Modified
      File: tkMenu.c          Status: Locally Modified
      File: tkTextDisp.c      Status: Locally Modified
      File: bgerror.tcl       Status: Locally Modified
      File: button.tcl        Status: Locally Modified
      File: choosedir.tcl     Status: Locally Modified
      File: clrpick.tcl       Status: Locally Modified
      File: comdlg.tcl        Status: Locally Modified
      File: console.tcl       Status: Locally Modified
      File: dialog.tcl        Status: Locally Modified
      File: entry.tcl         Status: Locally Modified
      File: focus.tcl         Status: Locally Modified
      File: listbox.tcl       Status: Locally Modified
      File: menu.tcl          Status: Locally Modified
      File: msgbox.tcl        Status: Locally Modified
      File: optMenu.tcl       Status: Locally Modified
      File: palette.tcl       Status: Locally Modified
      File: scale.tcl         Status: Locally Modified
      File: scrlbar.tcl       Status: Locally Modified
      File: spinbox.tcl       Status: Locally Modified
      File: tclIndex          Status: Locally Modified
      File: tearoff.tcl       Status: Locally Modified
      File: text.tcl          Status: Locally Modified
      File: tk.tcl            Status: Locally Modified
      File: tkfbox.tcl        Status: Locally Modified
      File: xmfbox.tcl        Status: Locally Modified
      File: tkMacMenu.c       Status: Locally Modified
      File: all.tcl           Status: Locally Modified
      File: clrpick.test      Status: Locally Modified
      File: filebox.test      Status: Locally Modified
      File: macMenu.test      Status: Locally Modified
      File: menu.test         Status: Locally Modified
      File: menuDraw.test     Status: Locally Modified
      File: msgbox.test       Status: Locally Modified
      File: text.test         Status: Locally Modified
      File: textDisp.test     Status: Locally Modified
      File: unixMenu.test     Status: Locally Modified
      File: winMenu.test      Status: Locally Modified
      File: xmfbox.test       Status: Locally Modified
      File: tkUnixDialog.c    Status: Locally Modified


tkt_uuid: 574128ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 68. Win Window Operations
priority: 7 High
foundin: None
resolution: Fixed
title: 'wm iconbitmap' for Windows.
comment:
  The attached smallpatch allows 'wm iconbitmap' to 
  work with Tk's ordinary bitmaps on WinTk.  
  (Currently only .ico or .icr files are supported).

  Now 'wm iconbitmap . hourglass' works, for 
  example.


tkt_uuid: 513688ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 1 Zero
foundin: obsolete: 8.4a4
resolution: Wont Fix
title: Updating button config -bg.
comment:
  After a button has been packed and made visible
  changing the background
  colour of the parent does not change the "invisible"
  component of the button background.

  For example:

  button .b  -text "test"
  pack .b
  update
  .b configure -bg green


tkt_uuid: 1841991fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: None
resolution: Invalid
title: Missing message box
comment:
  TCL has a askyesnocancel msgbox,
  The define are made in tkMessageBox,
  but there is no function askyesnocancel

  Could be a two minute good add for a next version


tkt_uuid: 219906ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Duplicate
title: tk_getOpenFile disturbs the event loop
comment:
  OriginalBugID: 830 Bug
  Version: 8.0.3
  SubmitDate: '1998-11-16'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1212
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-20'


  Script to reproduce the problem:

  button .b -text "Open" -command {puts $x}
  pack .b

  set x [tk_getOpenFile]

  This script will hang if running from the command line as follows:

  prowish80 test.tcl

  But if the same script is sourced into the same interpreter, it works fine. This problem happens on both Unix and Windows.

  Another test case:

  > The following code runs fine from the console, but when I run in from a
  > file the button never becomes usable.  It gets created but never seems
  > to get any events sent to (i.e I can't click on it).  Is there something
  > wrong with the following code, or is this a bug?
  > By the way I'm running this on Windows NT, and versions 8.0.2 and 8.0.3
  > have the same result.
  > 
  > namespace eval Junk {
  >    proc createWidgets {b l} {
  >       variable junkvar [cmd]   ;# can call cmd from this procedure
  >       button $b -text hello -command ::Junk::cmd
  >       label $l -textvariable ::Junk::junkvar
  >       pack $b $l
  >    }
  >    proc cmd {} {tk_messageBox -message "cmd called"}
  > }
  > Junk::createWidgets .b .l
  > focus .b



  The workaround Brent gave is to add an update command before calling tk_getOpenFile.


tkt_uuid: 568861ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Fix for wm minsize and maxsize commands
comment:
  This patch is fixes problems with the wm minsize
  and wm maxsize commands. The basic problem is
  that one can use wm geom to set sizes that should
  not be allowed. There was also a bug where
  the window would not be resized when the minsize
  or maxsize was changed and a resize was required.

  I have added a number of test cases to the wm.test
  file. I have also removed tests from the unixWm.test
  file that were marked with the nonPortable constraint.
  These tests would fail, they were not being run
  by default, and in addition my tests are more complete.
  My tests also cover gridded windows.

  I see two possible arguments against my patch. First,
  that there is a conflict between the docs for minsize
  and maxsize and the implementation. The docs state
  that these method should be a no-op when the wm
  resizable command has been used to turn off the
  resizable prop. Thing is, the resizable docs
  only mention what the user can do interactively.
  My patch will make the window resize to the new
  min or max size and then not allow resizing after
  that. In addition, this is violated by the wm geom
  command which can resize a window even if the
  wm resizable prop is turned off.

  The other argument against the test cases is that
  they might not work on other window managers. For
  example, I had to take care to use windows that
  would not be too small under Win32, since it has
  a lower limit for window widths. It is possible
  that tests might fail under some window managers.
  Those problems will have to be dealt with as they
  come up. The benefit of actually testing the wm
  code across multiple platforms should outweigh
  the cost of touching up the tests so they work
  for some specific (meaning buggy) wm.


tkt_uuid: 569952ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 24. Relief
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: Implementation of TIP #82
comment:
  The attached diff is the initial implementation
  of TIP #82.  This bug is submitted for tracking
  purposes only and will be closed as soon as the
  changes are committed.


tkt_uuid: 1185699fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Out of Date
title: Aqua scrollbar causes visual shimmer
comment:
  William Poser originally reported a hang resulting from
  a more complex version of this.  In the minimal script
  prepared by Michael Kirkham, there is a simple visual
  shimmer, as the window resizes itself in a endless
  cycle; the right-hand side moving continually in and out.

  He reports the following exact scenario:

  frame .top
  frame .cf
  scrollbar .cf.sbarright
  text .cf.out
  pack .cf.sbarright -side right -fill y
  pack .cf.out -side right
  pack .cf -fill both -side top -in .top
  pack .top

  That does it for me (MacOS X 10.3.9, Tk 8.4.9).  It
  doesn't do it if I do either of the following:

  1. Remove the -in .top on packing .cf.  (It does still
  do it if I remove the -in .top but change all the .cf's
  to .top.cf.)

  2. Add -padx 1 to the pack .top, the pack .cf, or the
  pack .cf.sbarright.

  3. Remove the -fill both on pack .cf.

  Jim Ingham comments:

  We play some games to get the scrollbar and the resize
  rectangle to magically line up properly, and I bet we
  are off by a pixel somewhere in this code.  Shouldn't
  be too hard to fix...


tkt_uuid: 1477426fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 33. Generic Dialog Support
priority: 7 High
foundin: TIP Implementation
resolution: Fixed
title: TIP #324: standard font selection dialog
comment:
  This patch implements a new standard dialog box as a
  new command: tk_chooseFont

  There is a Tk-only implementation and a Win32
  implementation. The Mac implementation is missing :-(

  The Win32 implementation uses the Win32 API function
  ChooseFont.

  Input parameters: none at this time

  Output parameters: Font description as a list "family
  size ?style...?"

  style is bold, italic

  The label description of the generic Tk implementation
   is currently in German but stored in a array inside
  tk_choosefont.

  The Win32 implementation is build with the Borland Free
  Command Line Tools

  Greetings from Leipzig
  G"oran 


tkt_uuid: 2875562fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Static compling of 8.6 in msys/mingw
comment:
  I tried compiling 8.6 from the cvs in a msys/mingw enviroment using the --disable-shared option.

  Tcl went well but compiling Tk failed with the message:

  gcc -O2 -fomit-frame-pointer winMain.o "/c/tmp/TclKitLite/tcl-8.6/tcl/win/libtcl86ss.a" libtk86s.a -lws2_32 -lgdi32 -lcomdlg32 -limm32 -lcomctl32 -lshell32 -luuid -lole32 -loleaut32 \
          wish.res.o -o wish86s.exe -mwindows 
  libtk86s.a(tkWindow.o):tkWindow.c:(.text+0x18): undefined reference to `tclStubsPtr'
  libtk86s.a(tkWindow.o):tkWindow.c:(.text+0x4f): undefined reference to `tclStubsPtr'
  [...]

  Should it be trying to use stubs in a static build?


tkt_uuid: 220810ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 8
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_TopCoordsToWindow API
comment:
  OriginalBugID: 1887 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-22'
  Severity: MED
  Status: Assigned
  Submitter: surles
  ChangedBy: hershey
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


tkt_uuid: 220464ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Fatal FPE in [scale] on Linux/Alpha
comment:
  OriginalBugID: 1589 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-22'
  LastModified: '2000-06-02'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Other
  OSVersion: RedHat Linux 5.x on Alpha XL 300
  Machine: NA
  FixedDate: '2000-06-02'
  FixedInVersion: 8.3


  Name:
  Don Porter

  CVS:
  Updated from CVS on 1999 Mar 22

  ObservedBehavior:
      $ wish8.1
      % scale .s
      .s
      % .s configure -variable x
      
      Program received signal SIGFPE, Arithmetic exception.
      0x15555716f4c in TkRoundToResolution (scalePtr=0x12019a770,
      value=7.2430898922756634e-312) at ./../generic/tkScale.c:1147
      (xxgdb) info stack
      #0  0x15555716f4c in TkRoundToResolution (scalePtr=0x12019a770,
      value=7.2430898922756634e-312) at ./../generic/tkScale.c:1147
      #1  0x15555715ffc in ConfigureScale (interp=0x1201016f0,
      scalePtr=0x12019a770, objc=2, objv=0x120102ee0) at
      ./../generic/tkScale.c:632
      #2  0x155557157d8 in ScaleWidgetObjCmd (clientData=0x12019a770,
      interp=0x1201016f0, objc=4, objv=0x120102ed0) at
      ./../generic/tkScale.c:397
      #3  0x15555914920 in TclExecuteByteCode (interp=0x1201016f0,
      codePtr=0x12019da30) at ./../generic/tclExecute.c:843
      #4  0x155558e2194 in Tcl_EvalObjEx (interp=0x1201016f0,
      objPtr=0x120111930, flags=131072) at ./../generic/tclBasic.c:2719
      #5  0x15555927758 in Tcl_RecordAndEvalObj (interp=0x1201016f0,
      cmdPtr=0x120111930, flags=131072) at ./../generic/tclHistory.c:142
      #6  0x15555927510 in Tcl_RecordAndEval (interp=0x1201016f0,
      cmd=0x12010d878 ".s configure -variable x\n", flags=131072) at
      ./../generic/tclHistory.c:62
      #7  0x155556c6734 in StdinProc (clientData=0x12014e890, mask=2) at
      ./../generic/tkMain.c:349
      #8  0x15555934b48 in Tcl_NotifyChannel (channel=0x12014e890, mask=2) at
      ./../generic/tclIO.c:5597
      #9  0x15555979d9c in FileHandlerEventProc (evPtr=0x1201992e0, flags=-3)
      at ./../unix/tclUnixNotfy.c:572
      #10 0x155559484ac in Tcl_ServiceEvent (flags=-3) at
      ./../generic/tclNotify.c:573
      #11 0x15555948ab8 in Tcl_DoOneEvent (flags=-3) at
      ./../generic/tclNotify.c:875
      #12 0x155556b3038 in Tk_MainLoop () at ./../generic/tkEvent.c:1102
      #13 0x155556c6528 in Tk_MainEx (argc=1, argv=0x11ffff7d8,
      appInitProc=0x120000a88 <Tcl_AppInit>, interp=0x1201016f0) at
      ./../generic/tkMain.c:278
      #14 0x120000a5c in main (argc=1, argv=0x11ffff7d8) at ./tkAppInit.c:54
      



  DesiredBehavior:
      No crash
      





      Adding -mieee to CFLAGS before compiling makes the problem
      go away.  Not sure if that's the proper bug fix, though.
      
  --

  This is reported not to happen using 8.3 on Linux/Alpha.
  Several scale widget fixes have gone in since 8.1b2, so
  one of those likely resolved this issue. 
  -- 06/02/2000 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: 995291ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: ctrl+v problem
comment:
  On my linux box ctrl+v fires correctly the Paste
  binding (using the script bellow) but paste nothing in
  the text widget. ctrl+y fires the Paste binding too and
  paste the clipboard buffer in the text widget.

   #!/usr/bin/env wish
   package require Tk
   pack [text .t]
   bind .t <<Copy>> { puts copy }
   bind .t <<Cut>> { puts cut }
   bind .t <<Paste>> { puts paste }


tkt_uuid: 1410279fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 9 Immediate
foundin: None
resolution: Fixed
title: in Tk8.4.12, wish84 fails to start up
comment:
  When Tk 8.4.12 is configured with CC="gcc -mno-cygwin"
  the MACHINE variable is not set, so the
  wish.exe.manifest file is generated with an empty
  processorArchitecture
  field.  Windows then refuses to start wish84 (cygwin's
  bash says "permission denied", Command Prompt says "The
  system cannot execute the specified program.") and
  generates a several SideBySide events in the System
  event log.  The attached patch is one possible workaround.


tkt_uuid: 410389ffffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 56. [grab]
priority: 7 High
foundin: obsolete: 8.3.2
resolution: None
title: grab with multiple interpreter
comment:
  I am running an application with multiple interpreter.

  If I make a local grab on one window in an 
  interpreter, and I ask on another interpreter who is 
  grabbing, it reports the name of the window the other 
  interpreter is grabbing.
  This is creating a problem, particularly because the 
  menu posting, as is in the tk library file menu.tcl, 
  is looking for this and trying to remove the old grab 
  on an unexisting window


tkt_uuid: 220883ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Out of Date
title: Mac scrollbar 'moveto' fraction computed wrong
comment:
  OriginalBugID: 3698 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-29'
  LastModified: '2000-01-29'
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: Mac OS 9
  Machine: PowerCenter Pro 210


  Name:
  John Seal

  Extensions:
  Tcl/Tk 8.2.1

  CustomShell:
  Modified Tk8.2.shlb to allow

  ReproducibleScript:
  Run this script and drag the scrollbar thumbs, observing the "moveto" fraction 
  in relation to where you are in the scrollbar trough:

  proc report {where action amount args} {
      $where configure -text [format "%s %f %s" $action $amount $args]
      $where set $amount $amount
  }

  scrollbar .vsb -orient vertical -command [list report .vmsg]
  pack .vsb -side right -fill y
  scrollbar .hsb -orient horizontal -command [list report .hmsg]
  label .h -text "Horizontal:" -height 2 -anchor sw
  label .hmsg -width 30
  label .v -text "Vertical:" -height 2 -anchor sw
  label .vmsg -width 30
  pack .h .hmsg .v .vmsg .hsb -fill x

  ObservedBehavior:
  The Mac OS Appearance control panel allows the user to specify where the scroll 
  arrows appear in scrollbars: one arrow at each end (the default), both arrows at 
  one end only, or both arrows at both ends (my preference). Tk apparently always 
  computes the "moveto" fraction based on the assumption that there is one arrow 
  at each end. If they are both at one end, or both at both ends, you sometimes 
  have to drag into the scroll arrow areas in order to get to 0.0 or 1.0.

  Note: If you have Mac OS set to display both arrows at both ends, you can test 
  this behaviour without having to change the Appearance control panel settings. 
  Just make the window small enough, and the extra arrows will go away. I think 
  the vertical scrollbar will come up this way by default; making the window 
  bigger will cause it to get the extra arrows, if that's your pref setting.

  Also, the thumb is not proportional, even though I have set that pref, too, and 
  other scrollbars in other apps are pro

  DesiredBehavior:
  I expect the "moveto" fraction to reflect the thumb's position in the visible 
  trough, taking into account the scroll arrow preferences, and that the thumb be 
  proportional when the corresponding pref is set.

  This is on a PowerCenter Pro 210 running Mac OS 9 with 96MB RAM and VM off


tkt_uuid: 220932ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.3.1
resolution: None
title: unable to display image [2048x1536] with graphics board using 32 bit
comment:
  OriginalBugID: 5978 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-06'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: Windows 98
  Machine: P III 500


  Name:
  Michael Lukaschek

  Comments:
  I downloaded the img-binary and it crashed too.
      Message:
      Fatal Error in Wish: tried to delete photo image when instances still
      exist

  ReproducibleScript:
  we try to load an image and to display it with tk
  image size is 2048x1536
  tk crashes...
  But: it is no problem to display images  
  1.) having the other orientation 1536x2048 or
  2.) having a slightly different size: 2047x1536, 2049x1536, 2048x1537 or
  3.) using color depth 16 bit or 24 bit

  DesiredBehavior:
  display image of requested size


tkt_uuid: 548726ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: resizing problems
comment:
  panedwindow .pw -orient v
  label .pw.l1 -text 12345
  label .pw.l2 -text ABCDE
  pack .pw -fill both -expand 1
  .pw add .pw.l1 -sticky nsew -minsize 1
  .pw add .pw.l2 -sticky nsew -minsize 1
   
  remember the configuration
   
  now resize "." to be bigger.
  now resze "." to be smaller (back to original size 
  roughly)
  things should look ok
   
  now resize "." to be bigger.
  drag the sash down and release
  drag the sash back up and release
  now resize "." to be smaller --- notice bottom pane 
  does not behave as it did before --- it does not 
  shrink.
   
  One way that kind of gets around it to add a another 
  sash
   
  frame .phantom
  .pw add .phantom
  bind .pw <Configure> {
    .pw sash place 1 0 30000
  }
   


tkt_uuid: 220497ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: text & entry cursor blink continues when disabled
comment:
  OriginalBugID: 1807 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-14'
  LastModified: '2000-01-06'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Other
  OSVersion: openVMS V7.1
  Machine: NA
  FixedDate: '2000-01-06'
  FixedInVersion: 8.3b2


  Name:
  Roy Lane

  CVS:
  tktext.c,tkentry.c

  CustomShell:
  minor modifications for openVMS support

  ObservedBehavior:
  Particularly with text widget, but also applies to entry widget.  When
      text widget is in "disabled" state (used for read-only text), there
      should be no calls to TextBlinkProc().  There is a noticeable drag in
      performance.  When the recommended patch is applied, performance
      improves greatly.

  Patch:
  (generation 2 is 8.0.5 release; generation 3 contains modifications)

  Files Compared By LANE On 14-APR-1999 08:36:06
     (1)  Element TKTEXT.C Generation 2
     (2)  Element TKTEXT.C Generation 3

  (in TextBlinkProc())
  + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
  Element TKTEXT.C(2) Line 1514
        1)    if (!(textPtr->flags & GOT_FOCUS) || (textPtr->insertOffTime == 0))*

  Element TKTEXT.C(3) Line 1514
        2)    if ((textPtr->state == tkTextDisabledUid) ||
        2)            !(textPtr->flags & GOT_FOCUS) || (textPtr->insertOffTime ==*
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Files Compared By LANE On 14-APR-1999 08:37:23
     (1)  Element TKENTRY.C Generation 2
     (2)  Element TKENTRY.C Generation 3

  (in EntryBlinkProc())
  + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
  Element TKENTRY.C(2) Line 2198
        1)    if (!(entryPtr->flags & GOT_FOCUS) || (entryPtr->insertOffTime == 0*

  Element TKENTRY.C(3) Line 2198
        2)    if ((entryPtr->state == tkDisabledUid) ||
        2)            !(entryPtr->flags & GOT_FOCUS) || (entryPtr->insertOffTime *
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  PatchFiles:
  tkText.c
      tkEntry.c



  4/22/99 - redman - a little late for 8.1.0, try for 8.1.1.
  --
  Added to 8.3b2 as specified. 
  -- 01/06/2000 hobbs


tkt_uuid: 3016181fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
severity: Minor
foundin: current: 8.6.0
resolution: Accepted
title: Crash after scrollbar destroyed, Tk Cocoa
comment:
  After deleting a Tk scrollbar a crash sometimes occurs on a mouse down click in the pane associated with the former scrollbar.  Happens with Tk 8.6 source code from May 10, 2010 with the Mac Cocoa build.  This was hard to debug because it requires about 100 mouse clicks and scrollbar deletions done by hand to generate the crash in a molecular visualization program UCSF Chimera.  But I reproduced a few dozen times.  Using the Tcl/Tk debugging libraries produced the attached stack trace showing an invalid interpreter pointer from a TkScrollbar is being used and that it came from a Mac NSScroller object.  It appears that the scrollbar has been destroyed and the NSScroller released but a call to tkScroller() in tkMacOSXScrlbr.c occurs later and uses the invalid TkScrollbar pointer in NSScroller.  I'll attach a patch that fixed this problem by setting the NSScroller copy of the TkScrollbar pointer to null.


tkt_uuid: 220672ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: tk_getOpenFile does not work with a default extension!
comment:
  OriginalBugID: 4117 Bug
  Version: 8.3b2
  SubmitDate: '2000-02-03'
  LastModified: '2000-02-10'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Unix
  FixedDate: '2000-02-10'
  FixedInVersion: 8.3


  Name:

  Mo DeJong



  CVS:

  Today



  Extensions:

  Tcl/Tk from the CVS



  CustomShell:

  NONE



  ReproducibleScript:

  Run this command



  tk_getOpenFile -defaultextension .exe



  In the dialog type "/tmp", this will print

  the following error message with an OK box.



  File "/tmp.exe" does not exist.



  This should have done a cd to the directory! It would have if there

  was no -defaultextension given!



  ObservedBehavior:

  Error is generated!



  DesiredBehavior:

  It should do a CD!



  Patch:

  This patch fixes the problem, it should be

  applied to tk/library/tkfbox.tcl



  Index: tkfbox.tcl

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

  RCS file: /cvsroot/tk/library/tkfbox.tcl,v

  retrieving revision 1.1.4.3

  diff -u -r1.1.4.3 tkfbox.tcl

  --- tkfbox.tcl  1998/11/25 21:16:34     1.1.4.3

  +++ tkfbox.tcl  2000/02/03 00:00:22

  @@ -1155,7 +1155,7 @@

   

       set path [tkFDialog_JoinFile $context $text]

   

  -    if {[file ext $path] == ""} {

  +    if {![file isdirectory $path] && [file ext $path] == ""} {

          set path "$path$defaultext"

       }



  PatchFiles:

  tk/library/tkfbox.tcl





  Good find, and thanks for the patch.  I applied this to the 8.3 final sources.  It's worth saying that on systems that allow multiple "." characters in a filename, the default extension will often not work because of the naievity of [file extension].  For example, if the default extension is .so and I specify "libtcl8.3" in the dialog box, I will get an error that libtcl8.3 does not exist, because [file extension] returns ".3" as the extension.  The test that determines if the extension should be added could be followed (if there already is an extension) by an attempt to find the file with the default extension attached.  I think the whole function would have to be tweaked to deal with this though.

  - eric

  -- 02/07/2000 ericm


tkt_uuid: 454861ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Invalid
title: incorrect X masks used on Windows
comment:
  This is a little complicated.  Let me know if I need to
  clarify anything.

  On Windows, Tk draws images onto the screen with
  TkPutImage, which is an emulation of XPutImage. 
  TkPutImage blits it as a DIB so the XImage data format
  on Windows is DIB format.  In 32-bit mode, the first
  four bytes (the first pixel) of a DIB looks like this:

  BB GG RR 00

  Now if you look at this from the point of view of an
  XImage, this is an XImage in ZPixmap format in LSBFirst
  byte order (as specified by Tk).  With X, you can read
  the 32-bit pixel directly as a 32-bit integer.  Since
  you're on a little-endian processor, you'd get:

  0x00RRGGBB

  Therefore, the values of the Z bit masks are supposed
  to be:

  red_mask = 0xFF0000
  green_mask = 0xFF00
  blue_mask = 0xFF

  Tk 8.3.3 has these values:

  red_mask = 0xff
  green_mask = 0xff00
  blue_mask = 0xff0000

  So why does the color work ok?  As far as I can tell,
  the only code that accesses the pixels directly is the
  image code.  The ImageGetPixel and PutPixel routines
  inadvertantly swap things around so it actually matches
  the incorrect masks.  The code looks correct, but it's
  not.  The Windows GetRValue, GetGValue, and GetBValue
  macros are intended for COLORREF format, which is
  0x00BBGGRR.

  The same problem occurs with 24-bit images too.  The
  only difference is there's no zero padding for 24 bit.

  We discovered this bug because our software manipulates
  XImages directly, in a platform independent manner.

  Luckily, this bug seems pretty isolated from the rest
  of Tk.  The patches below are fairly simple.  I ran the
  fixed code through the Tk test suite and did not see
  any new errors.  I tested the fixed code with images
  and with colored buttons at 8, 16, 24, and 32 bit
  depths.

  Note that the new code is slightly faster in 32-bit
  mode because it copies pixels as 32-bit ints (like
  you're supposed to be able to do) instead of swapping
  bytes around.


  --- tkWinX.c.old        Mon Aug 20 14:35:22 2001
  +++ tkWinX.c    Thu Aug 23 21:38:37 2001
  @@ -388,9 +388,9 @@
          } else if (screen->root_depth >= 24) {
              screen->root_visual->class = TrueColor;
              screen->root_visual->map_entries = 256;
  -           screen->root_visual->red_mask = 0xff;
  +           screen->root_visual->red_mask = 0xff0000;
              screen->root_visual->green_mask = 0xff00;
  -           screen->root_visual->blue_mask = 0xff0000;
  +           screen->root_visual->blue_mask = 0xff;
          }
       }
       screen->root_visual->bits_per_rgb =
  screen->root_depth;


  --- tkWinImage.c.old    Mon Jul  9 12:46:10 2001
  +++ tkWinImage.c        Thu Aug 23 21:38:37 2001
  @@ -75,8 +75,11 @@
   
       switch (image->bits_per_pixel) {
          case 32:
  +           pixel = (*(DWORD*)srcPtr);
  +           break;
          case 24:
  -           pixel = RGB(srcPtr[2], srcPtr[1],
  srcPtr[0]);
  +           pixel = (srcPtr[0] | ((WORD) srcPtr[1] <<
  8)
  +                   | ((DWORD) srcPtr[2] << 16));
              break;
          case 16:
              pixel = RGB(((((WORD*)srcPtr)[0]) >> 7) &
  0xf8,
  @@ -124,18 +127,19 @@
       switch  (image->bits_per_pixel) {
          case 32:
              /*
  -            * Pixel is DWORD: 0x00BBGGRR
  +            * Pixel is DWORD: 0x00RRGGBB
               */
   
  -           destPtr[3] = 0;
  +           (*(DWORD*)destPtr) = pixel;
  +           break;
          case 24:
              /*
  -            * Pixel is triplet: 0xBBGGRR.
  +            * Pixel is triplet: 0xRRGGBB.
               */
   
  -           destPtr[0] = (unsigned char)
  GetBValue(pixel);
  -           destPtr[1] = (unsigned char)
  GetGValue(pixel);
  -           destPtr[2] = (unsigned char)
  GetRValue(pixel);
  +           destPtr[0] = (unsigned char) pixel;
  +           destPtr[1] = (unsigned char) (((WORD)
  (pixel)) >> 8);
  +           destPtr[2] = (unsigned char) ((pixel) >>
  16);
              break;
          case 16:
              /*
  @@ -245,9 +249,9 @@
                  + (bitmap_pad - 1)) >> 3) &
  ~((bitmap_pad >> 3) - 1);
       }
   
  -    imagePtr->red_mask = 0;
  -    imagePtr->green_mask = 0;
  -    imagePtr->blue_mask = 0;
  +    imagePtr->red_mask = visual->red_mask;
  +    imagePtr->green_mask = visual->green_mask;
  +    imagePtr->blue_mask = visual->blue_mask;
   
       imagePtr->f.put_pixel = PutPixel;
       imagePtr->f.get_pixel = ImageGetPixel;


tkt_uuid: 3477449fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: None
resolution: Fixed
title: Patch - segfault when mark out of -startline/-endline range
comment:
  The attached patch fixes item 1630271:

  https://sourceforge.net/tracker/?func=detail&aid=1630271&group_id=12997&atid=112997

  The patch is against the latest core-8-5-branch (from today).


tkt_uuid: 2949297fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: macosx 10.6 build errors, deprecated APIs
comment:
  I'm getting a build error on my iMac 11,1 running OSX 10.6.2 with xcode 3.2.1 newly installed.
  1. APIs called from tkMacOSXBitmap.c.
  These APIs are marked as deprecated as of OSX 10.4 and they don't seem to be in the Carbon.h default include path
  (I confess I have not tried to hack past the Carbon.h include).
  There are about 10 such API failures; see attached. For example, I see the declaration and deprecation of PaintRect in
  ./ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/Headers/QuickdrawAPI.h

  2. undeclared type CIconHandle, also from tkMacOSXBitmap.c (this is where the compile fails outright) but it is present in
  ./ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/Icons.h.

  I'm hopelessly confused. H E L P


tkt_uuid: 1409140fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 8
foundin: obsolete: 8.4.11
resolution: Fixed
title: Tk_PhotoPutBlock 4 times slower than 8.4.4
comment:
  I have a C function which draws a freehand trace into 
  a photo using a series of calls to Tk_PhotoPutBlock().

  Each block contains a single 1 X 1 pixel 32-bit 
  (RGBA) value. A is always 255, and I'm using 
  TK_PHOTO_COMPOSITE_OVERLAY as the type.

  Tk use to be able to keep up with a users interactive 
  tracing, even on fairly slow machines. Since we've 
  upgraded to 8.4.11, the tracings are way behind, even 
  on FAST machines.

  I have not tested our other ports, only Windows, but 
  I suspect similiar results.

  Is the slowness a bug, or the results of adding too 
  many features? Is there a better way of writing 
  single pixels into a photo. I've tried manipulating 
  the photo memory directly, but have had trouble using 
  Tk_ImageChanged() to indicate what should be redrawn. 
  It core dump, probably because I'm not sure what to 
  pass as the imageMaster argument.


tkt_uuid: 891141ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 6
foundin: obsolete: 8.4.13
resolution: Fixed
title: Entry/Leave events cause variable writes
comment:
  I've report a similiar problem, which was LINUX specific 
  and eventually blamed on the compiler. This time, it 
  occurs on multiple platforms.

  If a trace is set up to watch writes to a variable, and 
  the variable is also used as the -variable parameter to a 
  scale widget, the variable gets written, even though it's 
  contents remains unchanged, during Leave and Enter 
  events (NOTE: Depends on value, for example 3.5 is OK, 
  but 3.4 causes a variable write on all Leave/Enters)

  I've attached an example.


tkt_uuid: 2504402fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 8
foundin: obsolete: 8.5.5
resolution: Accepted
title: wm iconphoto fails on many Windows display setups
comment:
  On Windows the wm iconphoto command only works with 32-bit color
  displays. Other display settings produce a black icon.  Even today not
  all Windows displays are 32-bit.  I discovered the problem connecting to
  a server using Microsoft's Remote Desktop Connection protocol, which
  gives a 24-bit color display.

  The problem is that 32-bit image data is being passed to the win32
  CreateIcon() function.  According to MSDN that function requires the
  data in a device-dependent format, so it only works when the device
  format happens to be 32-bits, matching the given data.  Using
  CreateIconIndirect() instead solves the problem, as it accepts bitmaps
  in device-independent format, and converts them as required.

  I attach updated versions of win/tkWinWm.c, for Tk 8.5.6 and for the
  current 8.6 CVS HEAD.  Tested on Windows-XP & Windows-2003.


