# ticket

tkt_uuid: 220908ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: Clicking application windows fails to raise dialogs when a g
comment:
  OriginalBugID: 5040 RFE
  Version: 8.3
  SubmitDate: '2000-04-12'
  LastModified: '2000-09-06'
  Severity: MED
  Status: UnAssn
  Submitter: shawn
  ChangedBy: hobbs
  RelatedBugIDs: 4609
  OS: Windows NT


  When a dialog has a local grab and the window is hidden clicking in other toplevel windows doesn't raise the dialog.  I understand that this is that this is by design - as I understand it from reading the help.  It would be nice however if a mouse event(click - I am thinking - possibly enter) in other parts of the application would raise the application.  

  to reproduce: 

  Run tkerror at the command line in an interactive shell - Hide the popup dialog.  Click on the main window for the application - nothing happens.  

  I expect the dialog to raise.


tkt_uuid: 220909ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: final: 8.2.3
resolution: Fixed
title: Text in KOI8 encoding displayed incorrectly by text-wdigets
comment:
  OriginalBugID: 5068 Bug
  Version: 8.2.3
  SubmitDate: '2000-04-13'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: BSD
  OSVersion: FreeBSD


  Name:
  Mikhail Teterin

  Comments:
  I observed this on 3 different machines -- with X-servers being
      Xaccel-3.0, Xaccel-5.0.3 and
      XFree86 running FreeBSD 3.4 and 4.0.

  ReproducibleScript:
  I tried to come up with a script, but the bug is quite elusive :( The only time it reproduces reliably
  is when I use Postilion mailer... So debugging it will be somewhat involved );

  You'll need to install the postilion from http://www.postilion.org/ . Once it is installed,
  create /usr/local/lib/postilion/postilionrc and put the following line into it:

  AddFont koi8-r 14 {} -cronyx-fixed-medium-r-normal--20-200-75-75-c-100-koi8-r

  Start postilion and ensure that Info->Preferences->General->CharacterSize is set to 14...

  Then -- try to read an e-mail in KOI8 encoding (I can send one, when you are ready, with
  the description of how the text should look like by means of xwd(1)).

  ObservedBehavior:
  All of the characters from ASCII half of the table look fine, but the Cyrillic ones appear as so they
  are displayed using a similar (in sizes), but different font.

  The part of Postilion that displays the message's body is fairly simple, and I tried reproducing
  the bug in a simpler script, but failed...

  The tk83 has the same problem as 8.2.3.

  DesiredBehavior:
  I'd blame this on something Postilion does, but the postilion using tk80 displays properly (with the same
  config files, on the same X-server).


tkt_uuid: 220910ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Invalid
title: Canvas index @x,y uses wrong coordinates
comment:
  OriginalBugID: 5207 Bug
  Version: 8.3
  SubmitDate: '2000-04-20'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: All


  Name:

  Sebastian Wangnick


  ReproducibleScript:

  canvas .c

  pack .c

  .c configure -scrollregion {-200 -200 200 200}

  .c create text 100 100 -text FooBar -tag text

  puts [.c index text @100,100]

  puts [.c index text @300,300]


  ObservedBehavior:

  The script prints

  0

  2

  This indicates that the first invocation of index @x,y which uses the unmodified canvas coordinates @100,100 fails, whereas the second invocation at @300,300, where the topleft corner of the scrollregion was substracted from the text center position, delivers the correct result.


  DesiredBehavior:

  2

  6

  This being in line with the documentation, which specifies: 

  @x,y    Refers to the character or coordinate at the point given by x and

              y, where x and y are specified in the coordinate system of the

              canvas.


  Patch:

  *** tkCanvText.c.orig   Tue Dec 21 23:55:10 1999

  --- tkCanvText.c        Thu Apr 20 06:50:16 2000

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

  *** 1286,1293 ****

          }

          y = (int) ((tmp < 0) ? tmp - 0.5 : tmp + 0.5);

          *indexPtr = Tk_PointToChar(textPtr->textLayout,

  !               x + canvasPtr->scrollX1 - textPtr->leftEdge,

  !               y + canvasPtr->scrollY1 - textPtr->header.y1);

        } else if (Tcl_GetIntFromObj((Tcl_Interp *)NULL, obj, indexPtr) == TCL_OK) {

          if (*indexPtr < 0){

              *indexPtr = 0;

  --- 1286,1293 ----

          }

          y = (int) ((tmp < 0) ? tmp - 0.5 : tmp + 0.5);

          *indexPtr = Tk_PointToChar(textPtr->textLayout,

  !               x - textPtr->leftEdge,

  !               y - textPtr->header.y1);

        } else if (Tcl_GetIntFromObj((Tcl_Interp *)NULL, obj, indexPtr) == TCL_OK) {

          if (*indexPtr < 0){

              *indexPtr = 0;


  PatchFiles:

  tkCanvText.c


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: 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: 220913ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Fixed
title: wm resizable . 0 0 removes custom 'winico icon'
comment:
  OriginalBugID: 5324 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-02'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: Windows NT
  OSVersion: 4.0sp5


  Name:
  Vince Darley

  Extensions:
  Winico 0.3

  ReproducibleScript:
  # type this into a wish shell
  package require Winico
  # you need a .ico file
  set icon [winico create myIcon.ico]
  winico setwindow . $icon
  # Now the window has a nice icon
  wm resizable . 0 0
  # Not any more!

  ObservedBehavior:
  The standard Tk icon replaces 'myIcon'.

  Note that there are other related 'icon replacement' problems.  For example, the following script, when double-clicked on, fails to set the window's icon:

  package require Winico
  set icon [winico create myIcon.ico]
  winico setwindow . $icon

  Or for a similar effect, type this into a shell:

  toplevel .t ; winico setwindow .t $icon

  DesiredBehavior:
  I expect setting a toplevel's icon to be a permanent change, and not for Tk to reset the icon when it sees fit...

  I don't think these bug existed in, e.g., Tk 8.1 but I'm not sure.


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: 220915ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 7 High
foundin: obsolete: 8.5a4
resolution: Fixed
title: Canvas Item documentation
comment:
  OriginalBugID: 5397 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-09'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Linux-Red Hat
  Machine: P II - 350,  384M ram, ATI expert 8M running at 1280x1024


  Name:
  Spiros J Boucouris

  Extensions:
  none

  ReproducibleScript:
  For custom canvas items to use the the object interface, alwaysRedraw must be or'ed
  with TK_CONFIG_OBJS.  I did not find that documented anywhere.  Or'ing TK_CONFIG_OBJS
  with flags is documented in the header.  In short, the object interface requires multiple "configurations"
  in the user's code.

  ObservedBehavior:
  Provide a reasonably complete (point form) guide for using the object interface with canvas items.  Presently, even the header files do not have all the information.  One has to dig into tkCanvas.c.

  DesiredBehavior:
  I would like to see a cleaner object interface for custom canvas items (similar to the dual
  cmd / objcmd used in Tcl.  Presently the code does all sorts of casts based on information
  the user must provide at multiple places.  In short I would like an interface no less robust
  than the previous (ono-object) one.


tkt_uuid: 220916ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Fixed
title: Tk commands callable before Tk_Init bombs accessing Tcl stub table
comment:
  OriginalBugID: 5494 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-15'
  LastModified: '2000-05-15'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2269
  OS: All Windows


  Name:
  Per Mildner

  ReproducibleScript:
  There are Tk_ routines that can reasonably be called before Tk_Init (and thus Tcl_InitStubs) is called. In particular Tk_GetNumMainWindows (should return zero) and Tk_MainWindow (explicitly documented as callable on non-Tk interpreters), perhaps there are more.

  When Tk is built using TCL stubs (always the case on Windows) these routines will crash while trying to access Tcl_GetThreadData trough the (NULL) Tcl stub table.

  The patch for Bug DB ticket#2269 solves this problem in another context and could be adapted. (explicitly check for tclStubsPtr==NULL)


tkt_uuid: 220917ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Invalid
title: stack trace from motion binding
comment:
  OriginalBugID: 5663 Bug
  Version: 2.0b10
  SubmitDate: '2000-05-23'
  LastModified: '2000-09-06'
  Severity: SER
  Status: UnAssn
  Submitter: shawn
  ChangedBy: hobbs
  OS: SunOS


  I have no id ea how to repruduce this 
  Mouse movement - but I really dont know where the motion was 


  can't read "tkPriv(element)": no such variable
      while executing
  "string equal "entry" $tkPriv(element)"
      (procedure "::tk::spinbox::Motion" line 5)
      invoked from within
  "::tk::spinbox::Motion .post.frame.repeatFrame.delay 24 12
  "
      (command bound to event)

  Hmmm... 
  -- 05/23/2000 redman

  Sorry to punt on this, but this is coming from within the spinbox widget's
  bindings and functions (I believe).  I think Jeff will be better suited
  to look at this.

  Jeff, if you think it is something I am doing wrong (how I am setting
  up the bindings etc.) let me know.  Since the bug report isn't very
  specific, hopefully you will be able to catch this one from inspection
  of the code and the stack trace.

  If I can do anything to help, let me know.

  --Dan 
  -- 05/23/2000 kuchler

  This has a simple work-around, but I don't know if it's worth
  putting into the vu tag for Ajuba2.
  --
  This should apply to vu and the 8.4 spinbox.
  -- Jeff (via Scott)

  Hard to reproduce, fix in 2.1. 
  -- 05/30/2000 redman

  Let it wait until 3.0.
   
  -- 07/27/2000 redman 
  -- 09/06/2000 hobbs


tkt_uuid: 220918ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 62. Geometry Functions
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Request for additional public stub entry points
comment:
  OriginalBugID: 5757 RFE
  Version: 8.3.1
  SubmitDate: '2000-05-31'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: All


  Name:
  John Ellson

  DesiredBehavior:
  Request stubs for:
   TkBezierPoints
           TkBezierScreenPoints
           TkMakeBezierCurve
           TkMakeBezierPostscript

  These routines can be reused by alternative line smoothing methods.

  (i.e. Tkspline from http://www.graphviz.org/pub/ )


tkt_uuid: 220919ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Need 2 more stubs for TkWin* functions
comment:
  OriginalBugID: 5761 RFE
  Version: 8.3.1
  SubmitDate: '2000-05-31'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: Windows NT
  OSVersion: NT 4.0 (doesn't matter)


  Name:
  Lothar Linhard

  Extensions:
  We provide a Tcl/Tk extension

  CustomShell:
  No, our Tcl/Tk extenstion must run

  Comments:
  On Windows, our Tk extension calls TkWinGetDrawableDC()
      and TkWinReleaseDrawableDC() before and after painting
      to the HDC.  We'd like to support the Stubs interface
      in future also for Windows (everything is perfect on UNIX),
      and for that, we need to call those TkWin functions via
      stubs.

  DesiredBehavior:
  Need tk stubs for the following two functions:
          TkWinGetDrawableDC()
          TkWinReleaseDrawableDC()


tkt_uuid: 220920ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Fixed
title: Tk WindowsLib not loaded properly (8.3.1)
comment:
  OriginalBugID: 5762 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-31'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: Macintosh
  OSVersion: 8.1
  Machine: PowerMac 8200/120


  Name:
  Raphael Leplae

  Extensions:
  itcl3.1, itk3.1,iwidgets3.0.0, QuickTimeTcl2.1, Tclapplescript1.1.shlb

  CustomShell:
  executed in Tclsh:

  ReproducibleScript:
  Dble clicking on TkCon, Widget or Wish icons generate the error message.

  ObservedBehavior:
  Error message: The application "..." could not be started because WindowsLib could not be loaded.


tkt_uuid: 220921ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Fixed
title: AIX --enable-shared passes illegal options (-Wl,...) to ld and (-bI:) to gcc
comment:
  OriginalBugID: 5767 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-31'
  LastModified: '2000-05-31'
  Severity: CRIT
  Status: UnAssn
  Submitter: angie
  ChangedBy: angie
  RelatedBugIDs: 6206
  OS: AIX


  Tk 8.3.1 Bug

  Name:  Per Mildner
  email:  per.mildner@sics.se
  Support:  None
  Severity:  1
  OperatingSystem:  AIX
  Synopsis:  AIX --enable-shared passes illegal options (-Wl,...) to ld and (-bI:) to gcc

  ReproducibleScript:
  (using gcc)
  ./configure --enable-shared && make
  ...

  ObservedBehavior:
  (This is for 8.3.0 but 8.3.1 behaves the same)

  /src/sicstus/install/src/tcl8.3.0/unix/ldAix /bin/ld -bhalt:4 -bM:SRE -bE:lib.exp -H512 -T512 -bnoentry -o libtk8.3.so tk3d.o tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o tkConsole.o tkCursor.o tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o tkGeometry.o tkGrab.o tkGrid.o tkMain.o tkObj.o tkOldConfig.o tkOption.o tkPack.o tkPlace.o tkSelect.o tkUtil.o tkVisual.o tkWindow.o tkUnix.o tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o tkUnixXId.o tkStubInit.o tkStubLib.o tkButton.o tkEntry.o tkFrame.o tkListbox.o tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o tkScale.o tkScrollbar.o tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o tkCanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o tkIma!
  ge.o tkImgBmap.o tkImgGIF.o tkImgPPM.o tkImgPhoto.o tkText.o tkTextBTree.o tkTextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o tkTextWind.o -L/src/sicstus/install/rs6000-aix-4.3/lib -L/src/sicstus/install/src/tcl8.3.0/unix  -lX11 -ldl -Wl,-bI:/src/sicstus/install/src/tcl8.3.0/unix/lib.exp -L/src/sicstus/install/src/tcl8.3.0/unix -lm -lc
  noDotA="libtk8.3.so"
  ld: 0706-012 The -W flag is not recognized.
  ld: 0706-006 Cannot find or open library file: -l ,-bI:/src/sicstus/install/src/tcl8.3.0/unix/lib.exp
  ld:open(): A file or directory in the path name does not exist.

  Patch:
  1. configure.in should probably define MAKE_LIB to use SHLIB_LD_LIBS instead of LIBS
  2. Whatever is used needs to be massaged to convert -Wl,OPTION1,OPTION2,... in the same manner as is done for TK_LD_SEARCH_FLAGS (also in configure.in)
  3. TK_BUILD_LIB_SPEC has the opposite problem. It is set (on AIX) to -bI:.... which is a linker option but it is used in Makefile as a $CC argument so it probably should look like -Wl,-bI:...

  I hacked the Makefile (after running configure) and then build tk without problem.
  Posted To comp.lang.tcl: Posted Successfully


tkt_uuid: 220922ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Fixed
title: radiobuttons are not visible in static wish built from scratch
comment:
  OriginalBugID: 5827 Bug
  Version: 1.3
  SubmitDate: '2000-06-06'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: Windows NT
  OSVersion: Service pack 5, IE 5
  Machine: HP Vectra, 400MHZ


  Name:
  Mircea Draghicescu

  Comments:
  The button is there, but it is not visible (it will execute a command
      bound to it).
      If I replace tk82s.lib with tk82.lib, the button appears OK.

  ReproducibleScript:
  I built wish in Visual Studio 6.0 from proTkWinMain.c, proWrapTkMain.c, linked with tcl82s.lib, tk82s.lib, wrapper10s.lib, tbcload13s.lib,
  with /D "STATIC_BUILD" /MT, etc. I got 0 errors, 0 warnings during the build.
  I then started wish (starts OK) and run the following program:
  radiobutton .b
  pack .b

  ObservedBehavior:
  The button is not displayed.

  DesiredBehavior:
  See the button.


tkt_uuid: 220923ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4a1
resolution: Invalid
title: tk's ./configure --with-tcl opt behavior changed
comment:
  OriginalBugID: 5846 Bug
  Version: 8.4a1
  SubmitDate: '2000-06-07'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: Other
  OSVersion: QNX 4.25
  Machine: PII 300


  Name:
  Bruce Edge

  ReproducibleScript:
  With tcl/tk 8.3, I used the same ./configure options for both tcl and tk.
  With 8.4a1 I tried to use:
  ./configure --prefix=/usr/local/tcl8.4a1  --disable-threads --disable-load --disable-shard --enable-gcc --with-tcl=/usr/local/tcl8.4a1  --with-tk=/usr/local/tcl8.4a1

  Tcl built OK, but when running ./configure for tk I got the following error:
   ./configure --prefix=/usr/local/tcl8.4a1  --disable-threads --disable-lo
  od --disable-shard --enable-gcc --with-tcl=/usr/local/tcl8.4a1  --with-tk=/usr/local/tcl8.4a1
  creating cache ./config.cache
  checking for ranlib... ranlib
  checking for gcc... gcc
  checking whether the C compiler (gcc  ) works... yes
  checking whether the C compiler (gcc  ) is a cross-compiler... no
  checking whether we are using GNU C... yes
  checking whether gcc accepts -g... yes
  checking for gcc... (cached) gcc
  checking whether the C compiler (gcc -g -O2 ) works... yes
  checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no
  checking whether we are using GNU C... (cached) yes
  checking whether gcc accepts -g... (cached) yes
  checking how to run the C preprocessor... gcc -E
  checking for unistd.h... yes
  checking for limits.h... yes
  checking for building with threads... no (default)
  checking if the compiler understands -pipe... yes
  checking for Tcl configuration... configure: error: /usr/local/tcl8.4a1 directory doesn't contain tclConfig.sh

  I had to use
  ./configure --prefix=/usr/local/tcl8.4a1  --disable-threads --disable-load --disable-shard --enable-gcc --with-tcl=/usr/local/tcl8.4a1/lib  --with-tk=/usr/local/tcl8.4a1

  note the addition of /lib on the end of the --with-tcl opt.

  ObservedBehavior:
  I felt that I should not have to specify the ./lib dir under the tcl install path.
  I did not have to do so in prev versions.


tkt_uuid: 220924ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Fixed
title: Incorrect multibyte characters are displayed
comment:
  OriginalBugID: 5850 Bug
  Version: 8.2.1
  SubmitDate: '2000-06-07'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: Digital Unix
  Machine: Compaq Alpha machine


  Name:

  Wai-man Long


  Comments:

  In the FontMapLoadPage() routine, an assumption is made that the

      character being tested has the same number of byte as the font being

      checked against. This is simply not true. In case, a one-byte font

      covering the 0x80-0xff range is put in front of the 2-byte font, as in

      the case of the SJIS locale, a 2-byte value will falsely match

      character in the one-byte font because of the dropping of the second

      byte in the hi/lo assignment code.


      To fix this problem, we need to look at the actual size of the

      multibyte string generated instead of whether the current font is a

      1-byte or 2-byte font. The byte length of the converted string can be

      retrieved from the second last argument of the Tcl_UtfToExternal()

      call.


  ReproducibleScript:

  This problem happens when multiple fonts are used by the Tcl/Tk

  application to display characters, as in the case for most Asian

  languages. In my case, the font list contains


  1. A single-byte PCF font containing glyphs for ASCII and SJIS narrow kana

     characters.

  2. A 2-byte fonts containing JISX0208 characters.


  ObservedBehavior:

  When a button containing 2-byte SJIS characters are displayed, some

  narrow kana and control characters are displayed instead.


  DesiredBehavior:

  I expected the 2-byte SJIS characters to be displayed correctly.


  Patch:

  [ ./Tcl/tk8.2/unix/tkUnixFont.c ]

   Diffs between Tcl/tk8.2/unix/tkUnixFont.c and Tcl/tk8.2/unix/tkUnixFont.c (Chec

  kout branch)

  *** 1906,1918 ****

  --- 1906,1939 ----

        end = (row + 1) << FONTMAP_SHIFT;

        for (i = row << FONTMAP_SHIFT; i < end; i++) {

          int hi, lo;

  + #ifndef       NO_DEC_I18N

  +       /*

  +        * QAR 80235 is caused by the presence of a one-byte font covering

  +        * the 0x80-0xff range in front of the 2-byte font, as in the case

  +        * of the SJIS locale. In this case, a 2-byte value will falsely

  +        * match character in the one-byte font because of the dropping of

  +        * the second byte in the hi/lo assignment code. To fix this problem,

  +        * we need to look at the actual size of the multibyte string

  +        * generated instead of whether the current font is a 1-byte or

  +        * 2-byte font.

  +        */

  +       int len;        /* Length of the destination multibyte string */

  + #endif


          if (Tcl_UtfToExternal(NULL, encoding, src, Tcl_UniCharToUtf(i, src),

                  TCL_ENCODING_STOPONERROR, NULL, buf, sizeof(buf), NULL,

  + #ifndef       NO_DEC_I18N

  +               &len, NULL) != TCL_OK) {

  + #else

                  NULL, NULL) != TCL_OK) {

  + #endif

              continue;

          }

  + #ifndef       NO_DEC_I18N

  +       if (len > 1) {

  + #else

          if (isTwoByteFont) {

  + #endif

              hi = ((unsigned char *) buf)[0];

              lo = ((unsigned char *) buf)[1];

          } else {


  PatchFiles:

  tk8.2/unix/tkUnixFont.c


tkt_uuid: 220925ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: -compund option for menu items (as exists in buttons, etc.)
comment:
  OriginalBugID: 5860 RFE
  Version: 8.4a1
  SubmitDate: '2000-06-08'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: All


  Name:
  Bruce Stephens

  DesiredBehavior:
  buttons (command, radio-, and check-) and labels now have the option 
  -compound, to allow both an image (or bitmap) and text to be displayed.  The
  analogous menu items don't.  

  I think menu items should also have this feature.


tkt_uuid: 220926ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: obsolete: 8.4a1
resolution: Fixed
title: tk v8.4a1 (and v8.3.1) fails test color-2.6 under both CDE and OW
comment:
  OriginalBugID: 5873 Bug
  Version: 8.4a1
  SubmitDate: '2000-06-12'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Solaris
  OSVersion: Solaris 7 (with 11/99 patches)
  Machine: Sun Ultra5


  Name:
  David R. Linn

  Extensions:
  whatever is in the Tcl/Tk v8.4a1 bundle

  CustomShell:
  no changes

  Comments:
  Test color=2.6 was added between Tk v8.3.0 and Tk v8.3.1 and Tk v8.3.1
      fails in the same
      way as Tk v8.4a1.

  ReproducibleScript:
  cd tk*/unix
  setenv TBD ../../tcl*/unix
  make TCL_BIN_DIR=$TBD test

  ObservedBehavior:
  output from the above command includes

  ...
  clrpick.test
  cmds.test
  color.test

  ==== color-2.6 Tk_GetColor procedure FAILED
  ==== Contents of test case:

      winfo rgb .t red

  ---- Result was:
  64000 4864 16384
  ---- Result should have been:
  65535 0 0
  ==== color-2.6 FAILED

  config.test
  cursor.test
  ...
  Tests ended at Sat Jun 10 11:10:19 CDT 2000
  all.tcl:Total7025Passed6599Skipped425Failed1
  Sourced 86 Test Files.
  Files with failing tests: color.test
  Number of tests skipped for each constraint:
  2altDisplay
  3colorsLeftover
  2emptyTest
  44macOnly
  15macOrPc
  132nonPortable
  226pcOnly
  1userInteraction

  DesiredBehavior:
  ...
  Tests ended at Sat Jun 10 11:10:19 CDT 2000
  all.tcl:Total7025Passed6600Skipped425Failed0

  i.e. Tk should pass all of its bundled tests or there should be a note telling the installer that
  this test will fail and that it's okay to put a release into production with a failed test.


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: 220928ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Out of Date
title: tk_popup locks up BWidget notebook
comment:
  OriginalBugID: 5899 Bug
  Version: 8.3
  SubmitDate: '2000-06-14'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: All Windows
  OSVersion: Windows 98, Windows NT 4 SP3


  Name:
  Stefan Koch

  Extensions:
  BWidget, Tk

  ReproducibleScript:
  ########################################################################
  #
  #   File:       Example code tk_popup lock up problem of Bwidget notebook
  #
  #
  #   Required:   tcl/tk8.3, BWidget
  #
  #   Created:    15.06.2000 - SCENTECH AG sk
  #
  #   EMAIL: stefan.koch@scentech.ch 
  #   URL:   http://www.scentech.ch
  #
  ########################################################################
  #
  # Description
  #############
  #
  # 1. Start Script
  # 2. Click on button of notebook page 1
  # 3. Open mouse menu and select "close"
  # 4. Check if notebook pages can be selected
  #
  # Observed behaviour
  ####################
  #
  # -open the popup menu will lock up the notebook page (happens every second time)
  # -lock up happens only if grab is used
  # -invoking any other popup menu will resolve the lock up (not implemented in this example)
  # -clicking on the window frame ".appl" will allow a selection once
  #
  ####################
  # MAIN
  ####################
  package require BWidget

  # dispose .
  wm withdraw .

  # create new toplevel
  toplevel .appl

  # create and pack bwidget notebook
  set notebook [NoteBook .appl.nb]
  pack $notebook -fill both -expand true

  # create page 1 
  ##################
  set p1 [$notebook insert end page1 -text "Page 1"]
  # create frame for page content
  set p1f [TitleFrame $p1.f -text "Page 1"]
  # add a button
  set butt [button [$p1.f getframe].butt -text "Click here to open new toplevel"  -command {do_it}]
  # and pack
  pack $butt
  pack $p1f -fill both

  # create page 2
  ###################
  set p2 [$notebook insert end page2 -text "Page 2"]
  # create frame for page content
  set p2f [TitleFrame $p2.f -text "Page 2"]
  # add a label
  set lab [label [$p2.f getframe].lab -text "some dummie text"]
  # and pack
  pack $lab
  pack $p2f -fill both

  # raise first page
  $notebook raise page1

  # cleanup when exit
  wm protocol .appl WM_DELETE_WINDOW "exit"

  ####################
  # END MAIN
  ####################

  # proc to create toplevel window
  # with grab and a popup
  ####################
  proc do_it {} {

      # create a toplevel with some label text
      toplevel .appl.something
      set lab [label .appl.something.lab  -text "Click on right mouse button to activate the popup
  use the close menu to close this window 
  and then try to select a new page within the notebook

  Observation:
  ============
  notebook pages can only be selected properly every 
  second time the tk_popup is invoked"]
      pack $lab

      bind $lab <3> {call_popup %X %Y}

      # set the grab to our new toplevel
      grab set .appl.something
  }

  # proc to create a popup menu
  ####################
  proc call_popup {rootx rooty} {

      set m .appl.popup

      # create popup
      catch {destroy $m}
      menu $m -tearoff false
      $m add command -label "close"   -command "call_close"

      tk_popup $m $rootx $rooty
  }

  # proc to close and release grab
  ####################
  proc call_close {} {

      # release grab
      grab release .appl.something
      # destroy toplevel
      destroy .appl.something
  }

  ObservedBehavior:
  # Observed behaviour
  ####################
  #
  # -open the popup menu will lock up the notebook page (happens every second time)
  # -lock up happens only if grab is used
  # -invoking any other popup menu will resolve the lock up (not implemented in this example)
  # -clicking on the window frame ".appl" will allow a selection once

  DesiredBehavior:
  no lock up


tkt_uuid: 220929ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 5 Medium
foundin: obsolete: 8.4a1
resolution: Fixed
title: Application Error dialog text widget isnt enabled
comment:
  OriginalBugID: 5933 RFE
  Version: 8.4a1
  SubmitDate: '2000-06-21'
  LastModified: '2000-09-07'
  Severity: LOW
  Status: UnAssn
  Submitter: shawn
  ChangedBy: shawn
  RelatedBugIDs: 4329 6249
  OS: All Windows
  FixedDate: '2000-09-06'


  I want it enabled so I can copy from it - can you do this for me? 

  produce an error with a stack trace - and try to copy it - and you wont be able to... 



  This was under dialogs, but is actually just pertinent to the text
  widget, and a dup of 4329. 
  -- 09/06/2000 hobbs

  This is not what I am talking about (4329) First, the text widget functionality in 8.4 is what I expect.  I can copy from a disabled text widget.  What I am referring to is specific to the "Application Error" dialog box, which was modified in 8.4.

  To reproduce do the following 

  Start Wish83 (8.3.2) in the console and generate an error dialog using bgerror *string* - view the stack trace.  In this stack trace cut and paste the error and type into the box.  The text widget there is enabled for cut copy and paste - and text entry.  

  Start Wish84 - in the console generate an error dialog using bgerror *string* - view the stack trace (now using the details button).  In this stack trace cut and paste the error and type into the box.  The copy functionality doesn't exist.  

  Expected result:  

  I expect to be able to copy a stack trace and paste it into another application, as I could in 8.3.2. 

  Actual result: 

  I can't copy the stack trace. 

  Moved back to new --  
  -- 09/07/2000 shawn


tkt_uuid: 220930ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: Discovering the transparent area of a photo image
comment:
  OriginalBugID: 5947 RFE
  Version: 8.4a1
  SubmitDate: '2000-06-26'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: All Unix


  Name:
  Donal K. Fellows

  Comments:
  This will allow me to create a version of my shaped-window extension
      where windows are shaped to the outlines specified in transparent photo
      images, a feature that would make writing advanced drag-and-drop support
      much easier.  While it is possible to hack the info needed out of the
      relevant internal structure, this would be highly fragile and liable to
      break if anyone ever changed the implementation of photo images at all.

  DesiredBehavior:
  A function (to be in the tkInt interface due to typing restrictions) to allow extensions to discover what parts of a photo image are transparent.

  Patch:
  http://www.cs.man.ac.uk/~fellowsd/tcl/validRegion.patch

  PatchFiles:
  tkImgPhoto.c
      tkInt.decls
      tkIntDecls.h
      tkStubInit.c


tkt_uuid: 220931ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 57. [option]
priority: 3 Low
foundin: obsolete: 8.3
resolution: None
title: option get command responding to invalid input
comment:
  OriginalBugID: 5957 Bug
  Version: 8.3
  SubmitDate: '2000-06-27'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Windows NT
  Machine: Dell OptiPlex GX1


  Name:
  Allen Flick

  ReproducibleScript:
  Within ~/.Xdefaults.....                      *Button.background: cyan
  then within Wish Console

  % pack [button .b -text Button]
  % option get .b background Button
  cyan
  % option get .b background Width
  cyan
  % option get .b background Relief
  cyan
  % pack [button .b -text Button]
  % option get .b background Button
  cyan
  % option get .b background Label
  cyan
  % option get .b background Text
  cyan

  ObservedBehavior:
  No matter what is put in for "class" of option database value, the response is only for the "name"
  of the option database value.

  DesiredBehavior:
  If the "name" option with the given "class" does not exist, I'd expect to get an
  empty string as the response.  Or some error code & message.


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: 220933ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 4
foundin: obsolete: 8.3.1
resolution: None
title: making tearoff-menus transient
comment:
  OriginalBugID: 5981 RFE
  Version: 8.3.1
  SubmitDate: '2000-07-06'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: All
  OSVersion: different UNIX


  Name:
  Uwe Traum

  DesiredBehavior:
  calling tearoffcommand before posting menu. Otherwise
  'wm transient' fails on some window manager.

  Patch:
  move line 91-97 to line 76

  PatchFiles:
  tk8.3.1/library/tearoff.tcl


tkt_uuid: 220934ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Invalid
title: Canvas item active and Enter fail if mouse moves quickly
comment:
  OriginalBugID: 5989 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-06'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: Windows NT
  OSVersion: NT 4.0 SP5 Server
  Machine: 600MHz, 256KRAM


  Name:
  Roy E. Terry

  ReproducibleScript:
  package require Tk
  canvas .c
  set rid [.c create rectangle 10 10 100 100]
  .c itemconfigure $rid -activefill yellow
  # .c bind $rid <Enter> {puts "Entered [incr eCnt]"}
  pack .c

  ObservedBehavior:
  when the mouse moves *slowly* into the rectangle it becomes active and 
  turns yellow. When the mouse is quickly moved to the center area of the
  rectancle (not point to its border) then the rectangle never turns yellow.

  DesiredBehavior:
  Mouse over a canvas item should (eventually) always be detected and standard behavior should be then executed. In this case the rectangle should eventually
  turn yellow as long as the pointer remains in the rectangle.


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: 220937ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Invalid
title: Access Violation
comment:
  OriginalBugID: 6027 Bug
  Version: 8.3
  SubmitDate: '2000-07-19'
  LastModified: '2000-07-19'
  Severity: CRIT
  Status: UnAssn
  Submitter: shawn
  ChangedBy: shawn
  OS: Windows 2000


  Also winNT

  To Reproduce: 

  Run the code in /home/bugs/tcltk/6027/tktest.tcl 

  Work in a directory structure with *.test files in it - below lib. 

  It takes a minute to load or so - If there are no test files listed you can open one from the file menu > open. 

  If there are - double click on a test file from the list to load it in to the window above -

  Select the top of the file down to the end of the first test - 

  Select run from the buttons at the top right of the app - with the idea being to execute the selected code. 

  Wish blows chunks - 

  I don't know if this is also true in unix - or just specific to windows. 
  m
  I think it blows out when it tries to source tcltest for the second time - so I am thinking that it is important to select the setup stuff from the file.  But not positive. 


tkt_uuid: 220938ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.2
resolution: Works For Me
title:
  entry widget is not accepting  numerals 4 and 6 from right side numerals pad even after Num Lock. Instead of printing numerals , those keys actiing as  left arrow and right row.

comment:
  OriginalBugID: 6028 Bug
  Version: 8.2
  SubmitDate: '2000-07-20'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  RelatedBugIDs: 6029
  OS: Solaris
  OSVersion: 5.5.1
  Machine: Sun Solaris


  Name:
  Kotha Harinath Babu

  Extensions:
  Tk8.2  / wish8.2

  ReproducibleScript:
  1. Create one entry widget using Tk .
  2. Num Lock ON
  3. type numerals 4 or 6 
  4. Observe non printing of numerals on entry widet.

  DesiredBehavior:
  1.  Create one entry widget using Tk .
  2. Num Lock ON
  3. type numerals 4 or 6 
  4. Operator should see numerals 4 and 6 from the entry widget


tkt_uuid: 220939ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 7 High
foundin: obsolete: 8.3.1
resolution: Wont Fix
title: Tk 8.3.1 send transmits data in wrong encoding to older Tk i
comment:
  OriginalBugID: 6031 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-20'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: Solaris
  OSVersion: 2.6
  Machine: ultra sparc 5


  Name:
  Larry W. Virden

  CVS:
  July 19, 2000 13:00 EDT

  Extensions:
  not applicable

  CustomShell:
  I've built the netcvs versions of the code and installed them

  ReproducibleScript:
  I reported this last year with 8.2 and the problem was reported fixed.  I would give you a bug number - but I have never had a success in searching the bug database.  I wish I could just get at the plain text data...

  anyways, here is the scripts - unshar these in their own directory.

  #!/bin/sh
  # This is a shell archive (produced by GNU sharutils 4.2.1).
  # To extract the files from this archive, save it to some FILE, remove
  # everything before the `!/bin/sh' line above, then type `sh FILE'.
  #
  # Made on 2000-07-20 13:33 EDT by <lwv26@lwv26awu>.
  # Source directory was `/tmp/t'.
  #
  # Existing files will *not* be overwritten unless `-c' is specified.
  #
  # This shar contains:
  # length mode       name
  # ------ ---------- ------------------------------------------
  #    932 -rwxr-xr-x fakemde76
  #    927 -rwxr-xr-x fakemde83
  #   3224 -rwxr-xr-x tclmdebug76
  #   3216 -rwxr-xr-x tclmdebug83
  #
  save_IFS="${IFS}"
  IFS="${IFS}:"
  gettext_dir=FAILED
  locale_dir=FAILED
  first_param="$1"
  for dir in $PATH
  do
    if test "$gettext_dir" = FAILED && test -f $dir/gettext  && ($dir/gettext --version >/dev/null 2>&1)
    then
      set `$dir/gettext --version 2>&1`
      if test "$3" = GNU
      then
        gettext_dir=$dir
      fi
    fi
    if test "$locale_dir" = FAILED && test -f $dir/shar  && ($dir/shar --print-text-domain-dir >/dev/null 2>&1)
    then
      locale_dir=`$dir/shar --print-text-domain-dir`
    fi
  done
  IFS="$save_IFS"
  if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED
  then
    echo=echo
  else
    TEXTDOMAINDIR=$locale_dir
    export TEXTDOMAINDIR
    TEXTDOMAIN=sharutils
    export TEXTDOMAIN
    echo="$gettext_dir/gettext -s"
  fi
  if touch -am -t 200112312359.59 $$.touch >/dev/null 2>&1 && test ! -f 2001123123
  59.59 -a -f $$.touch; then
    shar_touch='touch -am -t $1$2$3$4$5$6.$7 "$8"'
  elif touch -am 123123592001.59 $$.touch >/dev/null 2>&1 && test ! -f 12312359200
  1.59 -a ! -f 123123592001.5 -a -f $$.touch; then
    shar_touch='touch -am $3$4$5$6$1$2.$7 "$8"'
  elif touch -am 1231235901 $$.touch >/dev/null 2>&1 && test ! -f 1231235901 -a -f
   $$.touch; then
    shar_touch='touch -am $3$4$5$6$2 "$8"'
  else
    shar_touch=:
    echo
    $echo 'WARNING: not restoring timestamps.  Consider getting and'
    $echo "installing GNU \`touch', distributed in GNU File Utilities..."
    echo
  fi
  rm -f 200112312359.59 123123592001.59 123123592001.5 1231235901 $$.touch
  #
  if mkdir _sh10746; then
    $echo 'x -' 'creating lock directory'
  else
    $echo 'failed to create lock directory'
    exit 1
  fi
  # ============= fakemde76 ==============
  if test -f 'fakemde76' && test "$first_param" != -c; then
    $echo 'x -' SKIPPING 'fakemde76' '(file already exists)'
  else
    $echo 'x -' extracting 'fakemde76' '(text)'
    sed 's/^X//' << 'SHAR_EOF' > 'fakemde76' &&
  #! /usr/tcl76/sun4/bin/wish
  X
  ### under this font, octal character \222 is a subscript 2
  X
  label .l -text "Fake MDE 76"
  pack .l
  X
  label .l1 -text "no encoding"
  pack .l1
  button .b1 -font key12b -command exit
  pack .b1
  button .b2 -font key12b -command exit
  pack .b2
  button .b3 -font key12b -command exit
  pack .b3
  X
  label .l2 -text "pre-encoding"
  pack .l2
  button .b4 -font key12b -command exit
  pack .b4
  button .b5 -font key12b -command exit
  pack .b5
  button .b6 -font key12b -command exit
  pack .b6
  X
  label .l3 -text "post-encoding"
  pack .l3
  button .b7 -font key12b -command exit
  pack .b7
  button .b8 -font key12b -command exit
  pack .b8
  button .b9 -font key12b -command exit
  pack .b9
  X
  proc ClearButtons {} {
  X   .b1 configure -text ""
  X   .b2 configure -text ""
  X   .b3 configure -text ""
  X   .b4 configure -text ""
  X   .b5 configure -text ""
  X   .b6 configure -text ""
  X   .b7 configure -text ""
  X   .b8 configure -text ""
  X   .b9 configure -text ""
  }
  SHAR_EOF
    (set 20 00 07 20 12 21 39 'fakemde76'; eval "$shar_touch") &&
    chmod 0755 'fakemde76' ||
    $echo 'restore of' 'fakemde76' 'failed'
    if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
      md5sum -c << SHAR_EOF >/dev/null 2>&1  || $echo 'fakemde76:' 'MD5 check failed'
  7cd0f9c9095cf82b868f0ce554863955  fakemde76
  SHAR_EOF
    else
      shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'fakemde76'`"
      test 932 -eq "$shar_count" ||
      $echo 'fakemde76:' 'original size' '932,' 'current size' "$shar_count!"
    fi
  fi
  # ============= fakemde83 ==============
  if test -f 'fakemde83' && test "$first_param" != -c; then
    $echo 'x -' SKIPPING 'fakemde83' '(file already exists)'
  else
    $echo 'x -' extracting 'fakemde83' '(text)'
    sed 's/^X//' << 'SHAR_EOF' > 'fakemde83' &&
  #! /usr/tcl83/bin/wish
  X
  ### under this font, octal character \222 is a subscript 2
  X
  label .l -text "Fake MDE 83"
  pack .l
  X
  label .l1 -text "no encoding"
  pack .l1
  button .b1 -font key12b -command exit
  pack .b1
  button .b2 -font key12b -command exit
  pack .b2
  button .b3 -font key12b -command exit
  pack .b3
  X
  label .l2 -text "pre-encoding"
  pack .l2
  button .b4 -font key12b -command exit
  pack .b4
  button .b5 -font key12b -command exit
  pack .b5
  button .b6 -font key12b -command exit
  pack .b6
  X
  label .l3 -text "post-encoding"
  pack .l3
  button .b7 -font key12b -command exit
  pack .b7
  button .b8 -font key12b -command exit
  pack .b8
  button .b9 -font key12b -command exit
  pack .b9
  X
  proc ClearButtons {} {
  X   .b1 configure -text ""
  X   .b2 configure -text ""
  X   .b3 configure -text ""
  X   .b4 configure -text ""
  X   .b5 configure -text ""
  X   .b6 configure -text ""
  X   .b7 configure -text ""
  X   .b8 configure -text ""
  X   .b9 configure -text ""
  }
  SHAR_EOF
    (set 20 00 07 20 12 21 45 'fakemde83'; eval "$shar_touch") &&
    chmod 0755 'fakemde83' ||
    $echo 'restore of' 'fakemde83' 'failed'
    if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
      md5sum -c << SHAR_EOF >/dev/null 2>&1  || $echo 'fakemde83:' 'MD5 check failed'
  579b2780731bab6114f182a97722fa2e  fakemde83
  SHAR_EOF
    else
      shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'fakemde83'`"
      test 927 -eq "$shar_count" ||
      $echo 'fakemde83:' 'original size' '927,' 'current size' "$shar_count!"
    fi
  fi
  # ============= tclmdebug76 ==============
  if test -f 'tclmdebug76' && test "$first_param" != -c; then
    $echo 'x -' SKIPPING 'tclmdebug76' '(file already exists)'
  else
    $echo 'x -' extracting 'tclmdebug76' '(text)'
    sed 's/^X//' << 'SHAR_EOF' > 'tclmdebug76' &&
  #! /usr/tcl76/sun4/bin/wish
  X
  ### illustrating special character problems (subscripts as octals)
  X
  label .l -text "Tcl Version: [info tclversion]"
  pack .l
  button .b1 -text "Start/Clear Fake MDEs" -command StartFakeMde
  button .b2 -text "Send Test Command" -command SendTestCommands
  pack .b1
  pack .b2
  X
  proc StartFakeMde {} {
  X
  X   if { [catch {send fakemde76 {set dummyvar "Hi"}} error]} {
  X      exec ./fakemde76 &
  X      exec ./fakemde83 &
  X   } else {
  X      send fakemde76 {ClearButtons}
  X      send fakemde83 {ClearButtons}
  X   }
  }
  X
  proc SendTestCommands {} {
  X
  X   ### first, after double-quoting within Tk app
  X
  X   set cmd ".b1 configure -text C\222H\222"
  X   send fakemde76 $cmd
  X   send fakemde83 $cmd
  X
  X   ### second, after command substitution
  X
  X   send fakemde76 [list .b2 configure -text C\222H\222]
  X   send fakemde83 [list .b2 configure -text C\222H\222]
  X
  X   ### third, without evaluation in sending Tk
  X
  X   send fakemde76 {.b3 configure -text C\222H\222}
  X   send fakemde83 {.b3 configure -text C\222H\222}
  X
  X   ### now with encoding command in sending app...
  X
  X   set systemo iso8859-1
  X
  X   ### first, after double-quoting within Tk app
  X
  X   if { [catch {send fakemde76 [encoding convertto $systemo ".b4 configure -tex
  t C\222H\222"]} error] } {send fakemde76 ".b4 configure -text Error"}
  X   if {[catch {send fakemde83 [encoding convertto $systemo ".b4 configure -text
   C\222H\222"]} error]} {send fakemde83 ".b4 configure -text Error"}
  X
  X   ### second, after command substitution
  X
  X   if {[catch {send fakemde76 [encoding convertto $systemo [list .b5 configure 
  -text C\222H\222]]} error]} {send fakemde76 [list .b5 configure -text Error]}
  X   if {[catch {send fakemde83 [encoding convertto $systemo [list .b5 configure 
  -text C\222H\222]]} error]} {send fakemde83 [list .b5 configure -text Error]}
  X
  X   ### third, without evaluation in sending Tk
  X
  X   if {[catch {send fakemde76 [encoding convertto $systemo {.b6 configure -text
   C\222H\222}]} error]} {send fakemde76 {.b6 configure -text Error}}
  X   if {[catch {send fakemde83 [encoding convertto $systemo {.b6 configure -text
   C\222H\222}]} error]} {send fakemde83 {.b6 configure -text Error}}
  X
  X   ### now with encoding command in receiving app
  X
  X   set encodestring {
  X      proc Encode {string button} {
  X        set buttontext [encoding convertto iso8859-1 $string]
  X        $button configure -text $buttontext
  X      }
  X   }
  X
  X   send fakemde76 $encodestring
  X   send fakemde83 $encodestring
  X
  X   ### first, after double-quoting within Tk app
  X
  X   if {[catch {send fakemde76 "Encode C\222H\222 .b7"} error]} {send fakemde76 
  ".b7 configure -text Error"}
  X   if {[catch {send fakemde83 "Encode C\222H\222 .b7"} error]} {send fakemde83 
  ".b7 configure -text Error"}
  X
  X   ### second, after command substitution
  X
  X   if {[catch {send fakemde76 [list Encode C\222H\222 .b8]} error]} {send fakem
  de76 [list .b8 configure -text Error]}
  X   if {[catch {send fakemde83 [list Encode C\222H\222 .b8]} error]} {send fakem
  de83 [list .b8 configure -text Error]}
  X
  X   ### third, without evaluation in sending Tk
  X
  X   if {[catch {send fakemde76 {Encode C\222H\222 .b9}} error]} {send fakemde76 
  {.b9 configure -text Error}}
  X   if {[catch {send fakemde83 {Encode C\222H\222 .b9}} error]} {send fakemde83 
  {.b9 configure -text Error}}
  X
  }
  SHAR_EOF
    (set 20 00 07 20 12 24 02 'tclmdebug76'; eval "$shar_touch") &&
    chmod 0755 'tclmdebug76' ||
    $echo 'restore of' 'tclmdebug76' 'failed'
    if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
      md5sum -c << SHAR_EOF >/dev/null 2>&1  || $echo 'tclmdebug76:' 'MD5 check failed'
  01f440ea359d5e50deefc0c95609de9a  tclmdebug76
  SHAR_EOF
    else
      shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'tclmdebug76'`"
      test 3224 -eq "$shar_count" ||
      $echo 'tclmdebug76:' 'original size' '3224,' 'current size' "$shar_count!"
    fi
  fi
  # ============= tclmdebug83 ==============
  if test -f 'tclmdebug83' && test "$first_param" != -c; then
    $echo 'x -' SKIPPING 'tclmdebug83' '(file already exists)'
  else
    $echo 'x -' extracting 'tclmdebug83' '(text)'
    sed 's/^X//' << 'SHAR_EOF' > 'tclmdebug83' &&
  #! /usr/tcl83/bin/wish
  X
  ### illustrating special character problems (subscripts as octals)
  X
  label .l -text "Tcl Version: [info tclversion]"
  pack .l
  button .b1 -text "Start/Clear Fake MDEs" -command StartFakeMde
  button .b2 -text "Send Test Command" -command SendTestCommands
  pack .b1
  pack .b2
  X
  proc StartFakeMde {} {
  X
  X   if {[catch {send fakemde76 {set dummyvar "Hi"}} error]} {
  X      exec ./fakemde76 &
  X      exec ./fakemde83 &
  X   } else {
  X      send fakemde76 {ClearButtons}
  X      send fakemde83 {ClearButtons}
  X   }
  }
  X
  proc SendTestCommands {} {
  X
  X   ### first, after double-quoting within Tk app
  X
  X   set cmd ".b1 configure -text C\222H\222"
  X   send fakemde76 $cmd
  X   send fakemde83 $cmd
  X
  X   ### second, after command substitution
  X
  X   send fakemde76 [list .b2 configure -text C\222H\222]
  X   send fakemde83 [list .b2 configure -text C\222H\222]
  X
  X   ### third, without evaluation in sending Tk
  X
  X   send fakemde76 {.b3 configure -text C\222H\222}
  X   send fakemde83 {.b3 configure -text C\222H\222}
  X
  X   ### now with encoding command in sending app...
  X
  X   set systemo iso8859-1
  X
  X   ### first, after double-quoting within Tk app
  X
  X   if {[catch {send fakemde76 [encoding convertto $systemo ".b4 configure -text
   C\222H\222"]} error]} {send fakemde76 ".b4 configure -text Error"}
  X   if {[catch {send fakemde83 [encoding convertto $systemo ".b4 configure -text
   C\222H\222"]} error]} {send fakemde83 ".b4 configure -text Error"}
  X
  X   ### second, after command substitution
  X
  X   if {[catch {send fakemde76 [encoding convertto $systemo [list .b5 configure 
  -text C\222H\222]]} error]} {send fakemde76 [list .b5 configure -text Error]}
  X   if {[catch {send fakemde83 [encoding convertto $systemo [list .b5 configure 
  -text C\222H\222]]} error]} {send fakemde83 [list .b5 configure -text Error]}
  X
  X   ### third, without evaluation in sending Tk
  X
  X   if {[catch {send fakemde76 [encoding convertto $systemo {.b6 configure -text
   C\222H\222}]} error]} {send fakemde76 {.b6 configure -text Error}}
  X   if {[catch {send fakemde83 [encoding convertto $systemo {.b6 configure -text
   C\222H\222}]} error]} {send fakemde83 {.b6 configure -text Error}}
  X
  X   ### now with encoding command in receiving app
  X
  X   set encodestring {
  X      proc Encode {string button} {
  X        set buttontext [encoding convertto iso8859-1 $string]
  X        $button configure -text $buttontext
  X      }
  X   }
  X
  X   send fakemde76 $encodestring
  X   send fakemde83 $encodestring
  X
  X   ### first, after double-quoting within Tk app
  X
  X   if {[catch {send fakemde76 "Encode C\222H\222 .b7"} error]} {send fakemde76 
  ".b7 configure -text Error"}
  X   if {[catch {send fakemde83 "Encode C\222H\222 .b7"} error]} {send fakemde83 
  ".b7 configure -text Error"}
  X
  X   ### second, after command substitution
  X
  X   if {[catch {send fakemde76 [list Encode C\222H\222 .b8]} error]} {send fakem
  de76 [list .b8 configure -text Error]}
  X   if {[catch {send fakemde83 [list Encode C\222H\222 .b8]} error]} {send fakem
  de83 [list .b8 configure -text Error]}
  X
  X   ### third, without evaluation in sending Tk
  X
  X   if {[catch {send fakemde76 {Encode C\222H\222 .b9}} error]} {send fakemde76 
  {.b9 configure -text Error}}
  X   if {[catch {send fakemde83 {Encode C\222H\222 .b9}} error]} {send fakemde83 
  {.b9 configure -text Error}}
  X
  }
  SHAR_EOF
    (set 20 00 07 20 12 24 35 'tclmdebug83'; eval "$shar_touch") &&
    chmod 0755 'tclmdebug83' ||
    $echo 'restore of' 'tclmdebug83' 'failed'
    if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
      md5sum -c << SHAR_EOF >/dev/null 2>&1  || $echo 'tclmdebug83:' 'MD5 check failed'
  a0fc486dd7dc078debe8a98a2caccae2  tclmdebug83
  SHAR_EOF
    else
      shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'tclmdebug83'`"
      test 3216 -eq "$shar_count" ||
      $echo 'tclmdebug83:' 'original size' '3216,' 'current size' "$shar_count!"
    fi
  fi
  rm -fr _sh10746
  exit 0

  ObservedBehavior:
  I don't know if the above scripts will survive the cut and paste...

  However, if they do, mark them all as executable and change the first line to point to a wish from the tcl 7.6 environment and 8.3 environment.  Run the tclmdebug83 and
  press the "Start/Clear Fake MDEs" button.  This starts up the fakemde76 and fakemde83 windows.  Then, press the Send Test Command.  This sends data to each
  of these interpreters.  The data to the 8.3 interpreter gets there as expected,
  resulting in standard and superscript characters being displayed.  However, the data sent to the tcl 7.6 based interpreter do not work correctly.  An extra character is being sent, causing the resulting display to be incorrect.

  DesiredBehavior:
  I would like to see the data being sent properly to either interpreter.


tkt_uuid: 220940ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 4
foundin: obsolete: 8.4a1
resolution: Fixed
title: test suite corrections
comment:
  OriginalBugID: 6040 RFE
  Version: 8.4a1
  SubmitDate: '2000-07-24'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: All


  Name:

  Don Porter


  DesiredBehavior:

  This patch replaces all instances of


  [load {} tk]


  in Tk's test suite with


  [load {} Tk]


  This makes Tk robust against application

  of my submitted Tcl patch with the 

  synopsis:


  [info loaded] should return real package names.


  Patch:

  Index: tests/focus.test

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

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

  retrieving revision 1.6

  diff -c -r1.6 focus.test

  *** focus.test  2000/05/11 22:36:32     1.6

  --- focus.test  2000/07/22 01:22:33

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

  *** 572,578 ****

        bind all <FocusOut> {lappend x "focus out %W %d"}

        interp create child

        child eval "set argv {-use [winfo id .t.f1]}"

  !     load {} tk child

        child eval {

          entry .e1 -bg lightBlue

          pack .e1

  --- 572,578 ----

        bind all <FocusOut> {lappend x "focus out %W %d"}

        interp create child

        child eval "set argv {-use [winfo id .t.f1]}"

  !     load {} Tk child

        child eval {

          entry .e1 -bg lightBlue

          pack .e1

  Index: tests/macEmbed.test

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

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

  retrieving revision 1.4

  diff -c -r1.4 macEmbed.test

  *** macEmbed.test       1999/04/16 01:51:38     1.4

  --- macEmbed.test       2000/07/22 01:22:33

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

  *** 216,222 ****

        pack .f1 .f2

        interp create child

        child eval "set argv {-use [winfo id .f1]}"

  !     load {} tk child

        child eval {

          . configure -bd 2 -highlightthickness 2 -relief sunken

        }

  --- 216,222 ----

        pack .f1 .f2

        interp create child

        child eval "set argv {-use [winfo id .f1]}"

  !     load {} Tk child

        child eval {

          . configure -bd 2 -highlightthickness 2 -relief sunken

        }

  Index: tests/macMenu.test

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

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

  retrieving revision 1.3

  diff -c -r1.3 macMenu.test

  *** macMenu.test        1999/04/16 01:51:39     1.3

  --- macMenu.test        2000/07/22 01:22:34

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

  *** 852,858 ****

        catch {destroy .m1}

        catch {interp delete testinterp}

        interp create testinterp

  !     load {} tk testinterp

        menu .m1

        . configure -menu .m1

        raise .

  --- 852,858 ----

        catch {destroy .m1}

        catch {interp delete testinterp}

        interp create testinterp

  !     load {} Tk testinterp

        menu .m1

        . configure -menu .m1

        raise .

  Index: tests/menu.test

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

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

  retrieving revision 1.4

  diff -c -r1.4 menu.test

  *** menu.test   2000/05/11 22:37:05     1.4

  --- menu.test   2000/07/22 01:22:35

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

  *** 2300,2306 ****

    test menu-27.1 {GetMenuHashTable} {

        catch {interp destroy testinterp}

        interp create testinterp

  !     load {} tk testinterp

        list [catch {interp eval testinterp {menu .m1}} msg] $msg [interp delete testinterp]

    } {0 .m1 {}}


  --- 2300,2306 ----

    test menu-27.1 {GetMenuHashTable} {

        catch {interp destroy testinterp}

        interp create testinterp

  !     load {} Tk testinterp

        list [catch {interp eval testinterp {menu .m1}} msg] $msg [interp delete testinterp]

    } {0 .m1 {}}


  Index: tests/unixEmbed.test

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

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

  retrieving revision 1.7

  diff -c -r1.7 unixEmbed.test

  *** unixEmbed.test      1999/04/21 21:53:30     1.7

  --- unixEmbed.test      2000/07/22 01:22:35

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

  *** 550,556 ****

        pack .f1 .f2

        interp create child

        child eval "set argv {-use [winfo id .f1]}"

  !     load {} tk child

        child eval {

          . configure -bd 2 -highlightthickness 2 -relief sunken

        }

  --- 550,556 ----

        pack .f1 .f2

        interp create child

        child eval "set argv {-use [winfo id .f1]}"

  !     load {} Tk child

        child eval {

          . configure -bd 2 -highlightthickness 2 -relief sunken

        }

  Index: tests/unixWm.test

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

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

  retrieving revision 1.12

  diff -c -r1.12 unixWm.test

  *** unixWm.test 2000/03/29 00:09:07     1.12

  --- unixWm.test 2000/07/22 01:22:36

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

  *** 1832,1838 ****

        wm geometry .t +0+0

        tkwait visibility .t

        interp create slave

  !     load {} tk slave

        slave eval {wm geometry . 200x200+0+0; tkwait visibility .}

        set result [list [winfo containing 100 100] \

              [slave eval {winfo containing 100 100}]]

  --- 1832,1838 ----

        wm geometry .t +0+0

        tkwait visibility .t

        interp create slave

  !     load {} Tk slave

        slave eval {wm geometry . 200x200+0+0; tkwait visibility .}

        set result [list [winfo containing 100 100] \

              [slave eval {winfo containing 100 100}]]


  PatchFiles:

  tests/focus.test

      tests/macEmbed.test

      tests/macMenu.test

      tests/menu.test

      tests/unixEmbed.test

      tests/unixWm.test


tkt_uuid: 220941ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 50. [pack]
priority: 8
foundin: obsolete: 8.3.1
resolution: Wont Fix
title: If a single widget is destroyed, the frame shrinks to a size
comment:
  OriginalBugID: 6058 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-26'
  LastModified: '2000-07-26'
  Severity: SER
  Status: UnAssn
  Submitter: angie
  ChangedBy: angie
  OS: Windows 2000
  Machine: Dell Dimension XPS T700r


  Tk 8.3.1 Bug

  Name:  Rick Hedin
  email:  rhedin@aquifer.geology.uiuc.edu
  Support:  None
  Severity:  2
  OperatingSystem:  Windows 2000
  Machine:  Dell Dimension XPS T700r
  Extensions:  no extensions
  CustomShell:  none.
  Synopsis:  If a single widget is destroyed, the frame shrinks to a size too small to show the remaining widgets.

  ReproducibleScript:
  Here is a script that expresses the problem.  

  # Just wanted to remove something that might resize the window 
  # from the resize handler.  Can be put directly in the resize 
  # handler with the same results. 
  bind all <<removeit>> {
     destroy %W
     puts "Destroyed window %W"  ;# Watch what's going on. 
  }

  bind . <Configure> {
     set framewidth [winfo width .]
     puts "Framewidth = $framewidth"  ;# Watch what's happening. 
     set numentries [llength [winfo children .] ]
     if {$numentries == 0} {
        set entrywidth 100  ;# Initial guess. 
     } else {
        set entrywidth [winfo width .entry0]
     }
     set numwanted [expr $framewidth / $entrywidth]

     if {$numentries < $numwanted} {
        for {set i $numentries} {$i < $numwanted} {incr i} {
           entry .entry$i -width 10
           pack .entry$i -side left
        }
     } elseif {$numentries > $numwanted} {
        for {set i [expr $numentries - 1] } {$i >= $numwanted} {incr i -1} {
           event generate .entry$i <<removeit>> -when tail 
        }
     }
  }

  Source this script into wish.  Draw the right edge of the wish window out to the right.  You should see a string of entries appear as you elongate the window.  Now drag back to the left.  Rather than move smoothly, the right edge of the window leaps back to the left.  

  When the right-most entry is destroyed, the frame's width is given the default value, rather than either shrink-wrapped to the remaining widgets, or being under the control of the user.  

  Patch:
  This is not exactly a patch.  This is a script that does something similar, but works correctly.  This script avoids destroying windows.  Instead, it hides them.  

  bind . <Configure> {
     set framewidth [winfo width .]
     puts "Framewidth = $framewidth"  ;# See what's going on. 
     set numentries [llength [winfo children .] ]
     if {$numentries == 0} {
        set entrywidth 100  ;# Initial guess. 
     } else {
        set entrywidth [winfo width .entry0]
     }
     set numwanted [expr $framewidth / $entrywidth]

     # Want effective number of entries. 
     for {set numshown $numentries} {$numshown > 0} {incr numshown -1} {
        set index [expr $numshown - 1]
        if { [winfo ismapped .entry$index] } {break}
     }

     # Rather than destroy the window, if we don't want it, we just hide it. 
     if {$numshown < $numwanted} {
        for {set i $numshown} {$i < $numwanted} {incr i} {
           if { [winfo exists .entry$i] } {} else {
              entry .entry$i -width 10
           }
           pack .entry$i -side left
        }
     } elseif {$numshown > $numwanted} {
        for {set i [expr $numshown - 1] } {$i >= $numwanted} {incr i -1} {
           pack forget .entry$i
        }
     }
  }

  Comments:
      This error has occupied 1 to 2 man weeks.  

      There is another error, in a more complicated situation, that may be
      related.  It also involves destroying windows.  Perhaps if we can solve
      this problem, the other problem will clear up.  That one has so far
      consumed 6 man weeks.  

      We are a two person staff, and our schedule calls for us to be done in
      August.  I realize that is my problem, but it may give you an idea of
      why I am anxious to resolve this bug.  

  Posted To comp.lang.tcl: Posted Successfully


tkt_uuid: 220942ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 8
foundin: obsolete: 8.3.1
resolution: Duplicate
title: EmbedWindowDeleted dereferences NULL pointer.
comment:
  OriginalBugID: 6065 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-27'
  LastModified: 
  Severity: CRIT
  Status: UnAssn
  Submitter: techsupp
  OS: All


  Name:
  Scott Thibault

  Extensions:
  None

  CustomShell:
  No

  ReproducibleScript:
  During Tcl finialization, the exit handler CleanupContainerWindows is called before EmbedWindowDeleted, so there are no containers left and the EmbedWindowDeleted routine assumes there is at least one item in the container list.

  ObservedBehavior:
  Crashes due to a NULL pointer access.


tkt_uuid: 220943ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4a1
resolution: Accepted
title: Text widget: Bizarre behavior when extending selection initiated by double-clicking
comment:
  OriginalBugID: 6088 Bug
  Version: 8.4a1
  SubmitDate: '2000-08-09'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Solaris
  OSVersion: Solaris 7
  Machine: Sun Ultra-10


  Name:

  Peter Shawhan


  Extensions:

  none


  CustomShell:

  none


  Comments:

  The main change is that double-clicking (and triple-clicking) no

      longer sets the anchor to the beginning of the resulting selection;

      it always stays at the position of the original click.  The anchor's

      gravity attribute is set (in tkTextButton1) to keep track of whether

      the original click was to the left or the right of the gap which became

      the position of the anchor; then, this information is used in

      tkTextSelectTo to guarantee that the letter clicked on stays part

      of the range (lindex to rindex) from which word/line boundaries

      are found to determine the actual selection.


  ReproducibleScript:

  pshawhan@capella> ~/tcl/tcl8.4a1static/bin/wish8.4

  text .text -width 40 -height 10 -font {courier -24}

  .text insert 1.0 "ab c  def g\n"

  .text insert end "Tcl/Tk is great!\n"

  .text insert end "Here is punctuation: . & ? $ ^ _ *\n"

  .text insert end "...One last line for good measure\n"

  pack .text


  ===> Now do the following in the text widget:

  (1)  Double-click on the "e" in "def" in the first line, and keep the

  button down after the second click.  Now, move the mouse by ONE

  PIXEL in any direction.  The two spaces to the left of "def" become

  selected as well.  Now, slowly move the mouse left toward the

  beginning of the line.  The "def" itself is deselcted as you pass the

  "d", then becomes selected once again as you move farther.


  (2)  Double-click on the "c" in the first line, near its RIGHT edge.

  The "c" becomes selected, as it should. Now, double-click on the "c"

  near its LEFT edge, keeping the button down after the second click.

  The space to the left of the "c" is selected, not the "c" itself.  Now,

  move the mouse by ONE PIXEL in any direction.  The "ab" becomes

  selected as well.


  (3) TRIPLE-click on the third line of text, keeping the button down

  after the third click.  That line becomes selected, as it should.  Now,

  move the mouse up to the second line.  The second line becomes

  selected, but the third line becomes deselected.


  ObservedBehavior:

  The behavior described in (1) and (2) is obviously incorrect.  (In the

  case of clicking on the "c" near its left edge, you might argue that

  you are effectively clicking on the gap between the space and the

  "c" and that therefore it is not necessarily incorrect for the space to

  be the thing selected; but it certainly is counterintuitive, since one

  expects the letter clicked on to be part of the selected text.)

  The behavior described in (3) is not so obviously incorrect, but

  is inconsistent with other software (e.g. emacs, xterm windows, 

  and the Netscape text box I am typing this bug report into).


  DesiredBehavior:

  Well, we all know "how it's supposed to work", right?

  I was able to get the behavior I expect by modifying a few things

  in text.tcl, as described below.


  Patch:

  *** tcl8.4a1static/lib/tk8.4/text.tcl   Fri Jul 28 10:26:56 2000

  --- text.tcl    Fri Jul 28 15:59:15 2000

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

  *** 54,66 ****

        set tkPriv(selectMode) word

        tkTextSelectTo %W %x %y

        catch {%W mark set insert sel.last}

  -     catch {%W mark set anchor sel.first}

    }

    bind Text <Triple-1> {

        set tkPriv(selectMode) line

        tkTextSelectTo %W %x %y

        catch {%W mark set insert sel.last}

  -     catch {%W mark set anchor sel.first}

    }

    bind Text <Shift-1> {

        tkTextResetAnchor %W @%x,%y

  --- 54,64 ----

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

  *** 515,520 ****

  --- 513,527 ----

        set tkPriv(pressX) $x

        $w mark set insert [tkTextClosestGap $w $x $y]

        $w mark set anchor insert

  +     ;##- Set the anchor mark's gravity depending on the click position

  +     ;##- relative to the gap

  +     set bbox [$w bbox [$w index anchor]]

  +     if {$x > [lindex $bbox 0]} {

  +       set side right

  +     } else {

  +       set side left

  +     }

  +     $w mark gravity anchor $side

        if {[string equal [$w cget -state] "normal"]} {focus $w}

    }


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

  *** 552,581 ****

              }

          }

          word {

  !           if {[$w compare $cur < anchor]} {

  !               set first [tkTextPrevPos $w "$cur + 1c" tcl_wordBreakBefore]

  !               if { !$extend } {

  !                   set last [tkTextNextPos $w "anchor" tcl_wordBreakAfter]

  !               } else {

  !                   set last anchor

  !               }

              } else {

  !               set last [tkTextNextPos $w "$cur - 1c" tcl_wordBreakAfter]

  !               if { !$extend } {

  !                   set first [tkTextPrevPos $w anchor tcl_wordBreakBefore]

  !               } else {

  !                   set first anchor

  !               }

              }

          }

          line {

  !           if {[$w compare $cur < anchor]} {

  !               set first [$w index "$cur linestart"]

  !               set last [$w index "anchor - 1c lineend + 1c"]

  !           } else {

  !               set first [$w index "anchor linestart"]

  !               set last [$w index "$cur lineend + 1c"]

              }

          }

        }

        if {$tkPriv(mouseMoved) || [string compare $tkPriv(selectMode) "char"]} {

  --- 559,594 ----

              }

          }

          word {

  !           ;##- Set initial range based only on the anchor (1 char min width)

  !           if {[string equal [$w mark gravity anchor] "right"]} {

  !               set lindex "anchor"

  !               set rindex "anchor + 1c"

              } else {

  !               set lindex "anchor - 1c"

  !               set rindex "anchor"

              }

  +           ;##- Extend range (if necessary) based on the current point

  +           if {[$w compare $cur < $lindex]} {

  +               set lindex $cur

  +           } elseif {[$w compare $cur > $rindex]} {

  +               set rindex $cur

  +           }

  +           ;##- Now find word boundaries

  +           set first [tkTextPrevPos $w "$lindex + 1c" tcl_wordBreakBefore]

  +           set last [tkTextNextPos $w "$rindex - 1c" tcl_wordBreakAfter]

          }

          line {

  !           ;##- Set initial range based only on the anchor

  !           set lindex "anchor linestart"

  !           set rindex "anchor - 1c lineend"

  !           ;##- Extend range (if necessary) based on the current point

  !           if {[$w compare $cur < $lindex]} {

  !               set lindex "$cur linestart"

  !           } elseif {[$w compare $cur > $rindex]} {

  !               set rindex "$cur -1c lineend"

              }

  +           set first [$w index $lindex]

  +           set last [$w index "$rindex + 1c"]

          }

        }

        if {$tkPriv(mouseMoved) || [string compare $tkPriv(selectMode) "char"]} {


  PatchFiles:

  lib/tk8.4/text.tcl


tkt_uuid: 220944ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 7 High
foundin: obsolete: 8.3.2
resolution: Fixed
title: Documentation update: Tk_ConfigureWidget deprecation
comment:
  OriginalBugID: 6176 Bug
  Version: 8.3.2
  SubmitDate: '2000-08-29'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: All


  Name:
  Joe English

  CVS:
  $Id: ConfigWidg.3,v 1.6 2000/07/25 21:14:34 jenglish Exp $

  Comments:
  Though I have write permission to the repository, I thought I'd go
      through the
      bug form instead so that the TCT can review the proposed wording.

  ReproducibleScript:
  N/A

  ObservedBehavior:
  Eric Melski recently mentioned on comp.lang.tcl that Tk_ConfigureWidget has been deprecated
  in favor of the new Tcl_Obj-based API  (Tk_SetOptions and friends).
  There is no mention of this in the ConfigWidget man page though.

  DesiredBehavior:
  A notice that Tk_ConfigureWidget is deprecated.  Suggested wording is below.

  Patch:
  Index: ConfigWidg.3
  ===================================================================
  RCS file: /home/cvs/external/tk/doc/ConfigWidg.3,v
  retrieving revision 1.6
  diff -c -r1.6 ConfigWidg.3
  *** ConfigWidg.3        2000/07/25 21:14:34     1.6
  --- ConfigWidg.3        2000/08/28 23:16:33
  ***************
  *** 66,72 ****
  --- 66,78 ----
    order to free up resources.
    .BE
    .SH DESCRIPTION
  + .VS 8.1
    .PP
  + Note: \fBTk_ConfigureWidget\fP should be replaced 
  + with the new \fBTcl_Obj\fP based API \fBTk_SetOptions\fP.
  + The old interface is retained for backward compatibility.
  + .VE
  + .PP
    \fBTk_ConfigureWidget\fR is called to configure various aspects of a
    widget, such as colors, fonts, border width, etc.
    It is intended as a convenience procedure to reduce the amount
  ***************
  *** 612,617 ****
  --- 618,626 ----
    (tkFrame.c) has a simple configuration table, and the library
    implementation of buttons (tkButton.c) has a much more complex
    table that uses many of the fancy \fIspecFlags\fR mechanisms.
  + 
  + .SH "SEE ALSO"
  + Tk_SetOptions

    .SH KEYWORDS
    anchor, bitmap, boolean, border, cap style, color, configuration options,

  PatchFiles:
  tk/doc/ConfigWidg.3


tkt_uuid: 220945ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Out of Date
title: menubutton traversal not working
comment:
  OriginalBugID: 6184 Bug
  Version: 8.3.2
  SubmitDate: '2000-08-30'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Windows 98


  Name:
  James Hemmerle

  Comments:
  This problem also appears using the Tk8.2 release.
      A work around is to not use menubuttons but to use the "<toplevel>
      configure -menu <menu>" feature.

  ReproducibleScript:
  Start up wish83.exe.
  Type in:
  foreach m {mb1 mb2} {
    destroy .$m
    menubutton .$m -menu .$m.m -text $m -underline 2
    menu .$m.m 
    .$m.m add command -command "puts stderr $m" -label $m
    pack .$m -side left
  }

  A number of the default bindings listed in the manual do not seem to work.  These include:
  [4]If button 1 is pressed over a menubutton and then dragged over some other menubutton, the original menubutton unposts itself and the new menubutton posts. 
  [7]If the underline option has been specified for a menubutton then keyboard traversal may be used to post the menubutton: Alt+x, where x is the underlined character (or its lower-case or upper-case equivalent), may be typed in any window under the menubutton's toplevel to post the menubutton. 
  [8]The F10 key may be typed in any window to post the first menubutton under its toplevel window that isn't disabled.

  ObservedBehavior:
  The keyboard traversal of the menubuttons does not work.

  DesiredBehavior:
  I would like them to work as stated in the manual.


tkt_uuid: 220946ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Works For Me
title: Tcl/Tk 8.3.2 on SCO OpenServer.
comment:
  OriginalBugID: 6186 Bug
  Version: 8.3.2
  SubmitDate: '2000-08-31'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: Other
  OSVersion: SCO OpenServer 5.0.5
  Machine: Dell PowerEdge 2300


  Name:
  Krzysztof Hrebeniuk

  Extensions:
  TclX 8.2.0

  ObservedBehavior:
  Tcl/Tk 8.3.2 on SCO OpenServer 5.0.5 - some observations.

  1. Compilation
  ----------
  I use gcc ver. 2.95.2pl1 from Skunkware 99 distribution.

  tclsh and wish compiles OK with --enable-shared (default)
  option, but during compilation phase LD_RUN_PATH
  should be set to /usr/local/lib - if this is the place where
  libtcl8.3.so will be installed (if it was not set, LD_LIBRARY_PATH
  has to be set properly before executing tclsh or wish
  - in other case dynamic linker will complain).

  Before running configure in tk8.3.2 source tree, CC variable
  has to be set to gcc. When configure script finishes, Makefile
  has to be edited and variable X11_LIB_SWITCHES has to be
  changed from -L/usr/lib -lX11, to -lX11. If it's not changed,
  wish will crash with "Memory fault - core dumped" error.
  In this case gdb informs that "Program received signal SIGSEGV,
  segmentation fault (...) from /usr/lib/libc.so.1".

  Compilation with --disable-shared option, makes useable
  executables without any difficulties. But in both cases I received
  warnings concerning "implicit declaration of strcasecmp" and
  strncasecmp.

  Without regard of compilation method (shared or not), wishx 8.2
  dumps core when application main window is destroyed using
  windows manager control menu button ("called Tcl_FindHashEntry
  on deleted table"). Instead of using wishx, I use wish and then
  "package require Tclx 8.2" inside script.

  2. Polish locale and problems with wish
  ----------------------------

  My LANG variable is set to pl_PL.ISO8859-2.

  a) Basic problem

  In this locale, decimal separator is "," (comma).
  The following command is valid under tclsh:

  % expr 4.5 * 3.2
  14.4

  and this one is invalid:

  % expr 4,5 * 3,2
  syntax error in expresion "4,5 * 3,2"

  And this is OK - in other case all known scripts should be
  specially "localized".
  But under wish none of this command is valid!
  I always receive syntax error. wish is completely unusable -
  I'm even not able to drag a slider on a scrollbar:
  "Error: can't use non-numeric string as operand of "+"".
  This behaviour is not specific to 8.3.2 distribution nor compiler
  used - I first observed this in tk 7.4p2 compiled with SCO
  Development System.
  The only way out is to set LANG to another value, for example
  en_US.ISO8859-1 or C_C.C, or at least do the following in the first
  three lines of a script:
  #!/bin/sh
  # LC_NUMERIC=C_C.C;export LC_NUMERIC;exec wish "$0" "$@"

  b) Fonts problem

  Untill now I was using tcl/tk/tclx 8.0.4 and following commands worked
  as expected:

  set helv {-adobe-helvetica-bold-r-normal--12-*-*-*-*-*-iso8859-2}
  button .b -text "Po³±cz" -font $helv -command polaczCB

  In the word "Po³±cz" (in english: Connect) letter ³ has number 0xb3
  and letter ± has number 0xb1 in ISO8859-2 charset.

  Dynamically linked wish
  -----------------

  Now, instead of "³" I see "greater or equal" sign and instead of "±"
  plusminus sign. First I thought that instead of iso8859-2 charset,
  iso8859-1 is used - plusminus sign has 0xb1 number.
  But what charset "greater or equal" sign come from?
  In iso8859-1 charset, there is threesuperior sign on position 0xb3.
  xset -q command shows that in Font Path all my ISO8859-2 characters
  are before ISO8859-1 ones. Command "encoding system" returns "identity"
  (what does it mean?). Executing command: encoding system iso8859-2
  doesn't change anything.

  Statically linked wish
  ---------------

  Everything works as expected. Command: encoding system returns iso8859-2.
  Fonts are displayed corectly assuming that only LC_NUMERIC is set to C_C.C,
  not LANG - in this case I always get "greater or equal".
  There is even no need to specify that iso8859-2 characters have to be used -
  they are used by default.

  DesiredBehavior:
  I would like to be able to use dynamically linked version of tcl/tk
  - it concerns fonts problems described above.
  There should be no need to use a trick with LC_NUMERIC variable
  - i.e. locale pl_PL.ISO8859-2 should be recognized and supported.


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


  Name:
  Rick Hedin

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

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

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

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

  ObservedBehavior:
  Old operation:  

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

  DesiredBehavior:
  New operation:

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

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

  C:\Users\rhedin\work\tk>

  PatchFiles:
  win/tkWinMenu.c


tkt_uuid: 220949ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.2
resolution: Duplicate
title: Stippled text on a canvas drawn in the wrong place using the wrong color
comment:
  OriginalBugID: 6240 Bug
  Version: 8.2
  SubmitDate: '2000-09-11'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: Windows NT


  Name:
  Christopher Nelson

  ReproducibleScript:
  canvas .c -width 100 -height 100 -background white
  pack .c

  set id [.c create text 10 10 -fill green  -text "Text" -anchor nw -stipple gray50]
  set bb [.c bbox $id]

  # On UNIX, this box is around the text, on Win32, it's not.
  eval .c create rectangle $bb

  ObservedBehavior:
  On Win32 platforms (at least WinNT, maybe Win98), the text is not drawn where it should be.  The bounding box rectangle is in the same place on UNIX and 'Windows but the text is not.  Also, setting the color for the text has no effect on 'Windows.

  DesiredBehavior:
  Consistent behavior across platforms


tkt_uuid: 220950ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Accepted
title: [$menu delete $index end] deletes the last index even if it
comment:
  OriginalBugID: 6241 Bug
  Version: 8.3.2
  SubmitDate: '2000-09-11'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Windows 95


  Name:
  keith lea

  ReproducibleScript:
  % menu .f -tearoff 0
  .f
  % .f add command -label Index0
  % .f add command -label Index1
  % .f add command -label Index2
  % eval .f post [winfo pointerxy .f]
  % .f delete 600 end
  % eval .f post [winfo pointerxy .f]
  %

  DesiredBehavior:
  I think nothing should happen if the first index doesn't exist.


tkt_uuid: 220951ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Duplicate
title: Code to set icon under Windows.
comment:
  OriginalBugID: 6244 Bug
  Version: 8.3.2
  SubmitDate: '2000-09-11'
  LastModified: '2000-09-11'
  Severity: MED
  Status: UnAssn
  Submitter: angie
  ChangedBy: angie
  OS: All Windows


  Tk 8.3.2 Bug

  Name:  Rick Hedin
  email:  rhedin@aquifer.geology.uiuc.edu
  Support:  None
  Severity:  3
  OperatingSystem:  All Windows
  Synopsis:  Code to set icon under Windows.

  ReproducibleScript:
  This was discussed in the newsgroup, and it was decided that it would be good to put this in the bug database, so that the code wouldn't be lost.  

  It turns out though, that the main problem isn't setting the window's icon.  The main problem is that the window is recreated when the user requests a change that can't be made to an already existing window, but can only be made at window creation time.  

  1st newgroup entry:
  I have a simple routine that changes the icon in the corner of a Tk window.
  It runs under Windows. I saw in a post by Jeffrey Hobbs last December, that
  the steering committee (correct term?) hopes to put a simplified version of
  winico into 8.4. Perhaps this code will help.

  2nd newsgroup entry:
  This would be a good thing to enter into the bug db so the patch isn't
  lost. The tricky part though is making sure that the icon in the
  corner stays there when the toplevel is manipulated (Tk on Windows
  is constantly having to recreate the wrapper frame to allow you to do
  all that flexible stuff that is just somewhat "unnatural" for Windows).
  For example, see the bug report #5324.

  Patch:
  void SetIcon(char* windowName, int iconId, HINSTANCE hInstance) {

     int result;
     char workString[80];
     int workInteger;
     HWND windowHwnd;
     HWND wrapHwnd;
     static HICON hIcon;
     static int previous_iconId = -1;

     sprintf(workString, "winfo id %s", windowName);
     // We could have used Tk_GetHWND(Tk_WindowId(windowHtk)) instead. 

     result = Tcl_Eval(theInterp, workString);
     if (result != TCL_OK) death("SetIcon - winfo");

     result = Tcl_GetInt(theInterp, theInterp->result, &workInteger);
     if (result != TCL_OK) death("SetIcon - GetInt");

     windowHwnd = (HWND) workInteger;

     wrapHwnd = GetParent(windowHwnd);
     if (!wrapHwnd) death("SetIcon - GetParent");

     // I hate to do a file I/O repeatedly, and we probably are going to use 
     // the same icon for all the dialogs in the application. 
     if (iconId != previous_iconId) {

        previous_iconId = iconId;

        hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(iconId) );
        if (!hIcon) death("SetIcon - LoadIcon");

     }

     SendMessage(wrapHwnd, WM_SETICON, (WPARAM) ICON_BIG, (LPARAM) hIcon);
     // I tried a specifically made small icon, but if you let the system 
     // resize the big icon, you get good results. 
     //      Interesting that passing a NULL icon leaves the old icon 
     // in place.  The documentation says "If this parameter is NULL, 
     // the icon indicated by fType is removed."

  }
  // Often, it will be necessary to precede SetIcon with a call to 
  // Tcl_ServiceAll. 


tkt_uuid: 220952ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Invalid
title: Tcl/Tk 8.3.2 on SCO OpenServer - briefly.
comment:
  OriginalBugID: 6257 Bug
  Version: 8.3.2
  SubmitDate: '2000-09-12'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: Other
  OSVersion: SCO OpenServer 5.0.5
  Machine: Dell PowerEdge 2300


  Name:
  Krzysztof Hrebeniuk

  Comments:
  When tcl/tk is compiled as shared library, but with some extensions
      compiled in staticaly, everything works O.K. - but this is the source
      of further troubles in compilation of the other tcl/tk extensions -
      for example BLT.

  ObservedBehavior:
  Installing Tcl/Tk 8.3.2 on SCO OpenServer 5.0.5 with gcc 2.95.2
  ---------------------------------------------

  Because no one has answered to my bug report till now, I will try to narrow
  the problem:

  1) tcl compiles an runs without any difficulties (./configure, make, make install) with LD_RUN_PATH variable set to /usr/local/lib.

  2) in tclsh prompt the command "encoding system" returns "iso8859-2"
  and string tolower (toupper) commands work as expected -
  LANG is set to pl_PL.ISO8859-2.

  3) tk also compiles and runs - only X11_LIB_SWITCHES parameter
  had to be changed from -L/usr/lib -lX11 to -lX11 in Makefile

  4) in wish prompt the command "encoding system" returns "identity"
  and string tolower (toupper) commands don't work correctly.
  As a result, all letters specific to my language are displayed
  incorrectly in all tk widgets.

  It looks like tk does not cooperate with tcl library properly.
  What to do, if I don't want for some reason to use staticaly
  compiled wish?


tkt_uuid: 220953ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.4a1
resolution: Works For Me
title: font (presentation) problem
comment:
  OriginalBugID: 6287 Bug
  Version: 8.4a1
  SubmitDate: '2000-09-19'
  LastModified: '2000-09-19'
  Severity: CRIT
  Status: UnAssn
  Submitter: angie
  ChangedBy: angie
  OS: Windows 95


  Tk 8.4a1 Bug

  Name:  Frank Mijling
  email:  frank.mijling@siemens.nl
  Support:  None
  Severity:  1
  OperatingSystem:  Windows 95
  Machine:  Siemens Xpert, Siemens Scenic Mobile 710
  Extensions:  Tcl/Tk 8.3.0, Tcl/Tk 8.4a1
  CustomShell:  none
  Synopsis:  font (presentation) problem

  ReproducibleScript:
  any text-widget. changing font-size does not do the job.
  'Redrawing' the widget (e.g.by resizing the window)  shuffles the text and therefore makes text (sometimes/maybe) visible.

  ObservedBehavior:
  textlines seem to overlap each other. up to the point of unreadability. 
  I first used Tcl/Tk 8.3.0, and now I have started withTcl/Tk 8.4a1. Same result.
  This behavior was observed both on my Desktop-PC (Siemens Xpert) as well as my notebook (Scenic Mobile 710).

  DesiredBehavior:
  both under WindowsNT and Linux presentation (of the same script/text-widgets) is fine.
  Only W95 has this problem. (On both, desktop-PC and laptop, multiple-OSs are installed)

  Patch:
  sorry :-), as sort of Newbee I am just scared of looking in the wrong corner already.

  Posted To comp.lang.tcl: Posted Successfully


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: 220956ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 6
foundin: final: 8.0.5
resolution: Invalid
title: Tcl_DeleteInterp produce an illegal Tcl_Eval during window close
comment:
  OriginalBugID: 6311 Bug
  Version: 8.0.5
  SubmitDate: '2000-09-25'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Digital Unix
  OSVersion: 4.0f


  Name:
  Tupone Alfredo

  Comments:
  My work around will be (I hope) calling a destroy . before deleting the
      Interpreter

  ObservedBehavior:
  I got a bgError, while deleting an interpreter, because Tix, for its Balloon widget, has put some binding on the Event destroy of the window. The text on the bgError was something like "Tcl_Eval called with a deleted interpreter".


tkt_uuid: 220957ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Fixed
title: XAllocColor error when creating a menu on the 2nd screen
comment:
  OriginalBugID: 6331 Bug
  Version: 8.3.2
  SubmitDate: '2000-10-02'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: Digital Unix
  OSVersion: 4.0f + patch (duv40f0004)
  Machine: DMCC - Alpha


  Name:
  Tupone Alfredo

  Comments:
  I got a workaround for a local X-server connection specifying, for the
      toplevel to be created on the second screen, instead of 0:0.1,
      localhost:0.1

  ReproducibleScript:
  menu .menu
  toplevel .top1 -menu .menu -screen :0.1

  ObservedBehavior:
  This script make wish exit with an Xlib printout


tkt_uuid: 220958ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Invalid
title: unknown floating-point error, errno = 84
comment:
  OriginalBugID: 6335 Bug
  Version: 8.3.2
  SubmitDate: '2000-10-02'
  LastModified: 
  Severity: CRIT
  Status: UnAssn
  Submitter: techsupp
  OS: Linux-SuSE
  OSVersion: Linux Suse 6.0 (Kernel version 2.0.36)
  Machine: Intel i 386


  Name:
  Dr. Matthias Hammelsbeck

  Extensions:
  BWidget Toolkit

  CustomShell:
  No

  Comments:
  Obviously there is a problem with floating point numbers in the
      combination
      of Linux-Suse (Version 6.0, Kernel version 2.0.36) and tk (8.3.2). Tcl
      seems to be ok!

  ReproducibleScript:
  echo 'puts [expr 7.8 / 8.0]'|wish

  ObservedBehavior:
  Observation of entering the line in point 8:
  unknown floating-point error, errno = 84

  DesiredBehavior:
  0.975


tkt_uuid: 220959ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 3 Low
foundin: obsolete: 8.2
resolution: Duplicate
title: A "return" statement within "bind" Tcl code generates a Tcl error dialog
comment:
  OriginalBugID: 6344 Bug
  Version: 8.2
  SubmitDate: '2000-10-06'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Digital Unix
  OSVersion: Digital Unix V5.1


  Name:
  Rigoberto Corujo

  ReproducibleScript:
  The following reproducer will cause a Tcl error dialog to appear when the "return" statement is executed.

  To reproduce, run this script and click the right mouse button on the "wish" window that comes up.  A Tcl error dialog should come up that has the "OK", "Skip Messages", and "Stack Trace" buttons.  If you proved a string to "return", that string will appear in the error message dialog.

  This did not happen under Tcl/Tk 7.6.

  #!/usr/bin/wish

  bind all <Button-3> {
  puts "Button Was Pressed"
  return
  }

  ObservedBehavior:
  The undesirable behavior I observed is the Tcl Error Dialog box that should not be coming up.

  DesiredBehavior:
  I expect that the "return" statement should not cause the Tcl Error Dialog box to appear.


tkt_uuid: 220960ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: None
title: wish process locks up explorer tool bar
comment:
  OriginalBugID: 6351 Bug
  Version: 8.3.2
  SubmitDate: '2000-10-09'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: Windows NT
  OSVersion: wish.exe  version 8.3.2
  Machine: Dell Dimention XPS, single CPU, NT4.0 pack 6


  Name:
  Jason Liu

  Extensions:
  N/A

  CustomShell:
  N/A

  Comments:
  Is there another option (such as command line argument) to fix this
      problem?

  ReproducibleScript:
  When running wish in background with the -nowindow option on NT4.0 (pack 6), if user press down the windows button(the button that has the MS windows icon on it) and then press key 'E' to start NT explorer, the Start button on the toolbar gets frozen, user cannot start other windows by clicking on the windows icon on the tool bar. The NT explorer.exe version is 4.7 or above. If user tries to start NT explorer by clicking Start|Programs|Windows NT Explorer, the same thing happens. If user kill the wish process from task manager, all the queued up commands get executed by NT. But, when wish is running in windows mode, everything works fine.

  ObservedBehavior:
  The result of locking up the NT windows Tool bar makes the user starting other applications difficult.

  DesiredBehavior:
  wish process, when running with -nowindow option, should not conflict with NT explorer.

  Patch:
  N/A

  PatchFiles:
  N/A


tkt_uuid: 220961ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Fixed
title: Error in generated Makefile.
comment:
  OriginalBugID: 6362 Bug
  Version: 8.3.2
  SubmitDate: '2000-10-16'
  LastModified: 
  Severity: CRIT
  Status: UnAssn
  Submitter: techsupp
  OS: AIX
  OSVersion: 4.3.3
  Machine: IBM RS6000


  Name:
  Joachim Zaers

  Extensions:
  NA

  CustomShell:
  NA

  ReproducibleScript:
  I finally made it to compile the latest stable release under AIX 4.3.3 with gcc-2.95.2. Hurrah!
  But the Makefile for Tk as some faults in the usage of the -Wl, switch of the gcc.
  When using ldAIX.sh we not need that flag to signal that the following option is a linker option.
  There is no gcc running. On the other hand the gcc likes to have this flag when compiling and linking
  the executables.

  ObservedBehavior:
  Well, it did not built.

  Patch:
  *** Makefile    Mon Oct 16 21:03:46 2000
  --- Makefile.save       Mon Oct 16 19:23:33 2000
  ***************
  *** 197,205 ****

    # Libraries to use when linking.  This definition is determined by the
    # configure script.
  ! LIBS =  $(X11_LIB_SWITCHES) -ldl -Wl,-bI:/usr/local/LTA-DEV/src/tcl8.3.2/unix/lib.exp -L/usr/local/LTA-DEV/src/tcl8.3.2/unix -lm -lc
    WISH_LIBS = $(TCL_LIB_SPEC)  $(X11_LIB_SWITCHES) -ldl -Wl,-bI:/usr/local/LTA-DEV/src/tcl8.3.2/unix/lib.exp -L/usr/local/LTA-DEV/src/tcl8.3.2/unix -lm -lc

    # The symbol below provides support for dynamic loading and shared
    # libraries.  See configure.in for a description of what it means.
    # The values of the symbolis normally set by the configure script.
  --- 197,207 ----

    # Libraries to use when linking.  This definition is determined by the
    # configure script.
  ! LIBS =  $(X11_LIB_SWITCHES) -ldl -bI:/usr/local/LTA-DEV/src/tcl8.3.2/unix/lib.exp -L/usr/local/LTA-DEV/src/tcl8.3.2/unix -lm -lc
    WISH_LIBS = $(TCL_LIB_SPEC)  $(X11_LIB_SWITCHES) -ldl -Wl,-bI:/usr/local/LTA-DEV/src/tcl8.3.2/unix/lib.exp -L/usr/local/LTA-DEV/src/tcl8.3.2/unix -lm -lc

  +
  +
    # The symbol below provides support for dynamic loading and shared
    # libraries.  See configure.in for a description of what it means.
    # The values of the symbolis normally set by the configure script.
  ***************
  *** 391,397 ****

    wish: $(WISH_OBJS) $(TK_LIB_FILE) $(TK_STUB_LIB_FILE)
          $(CC)  $(WISH_OBJS)  !               -bI:/usr/local/LTA-DEV/src/tk8.3.2/unix/lib.exp  $(WISH_LIBS) $(TK_CC_SEARCH_FLAGS) -o wish

    # This rule is executed if the user tried to run tktest without first
  --- 393,399 ----

    wish: $(WISH_OBJS) $(TK_LIB_FILE) $(TK_STUB_LIB_FILE)
          $(CC)  $(WISH_OBJS)  !               -Wl,-bI:/usr/local/LTA-DEV/src/tk8.3.2/unix/lib.exp  $(WISH_LIBS) $(TK_CC_SEARCH_FLAGS) -o wish

    # This rule is executed if the user tried to run tktest without first
  ***************                                    
  *** 402,413 ****

    tktest: ${TCL_BIN_DIR}/tcltest $(TKTEST_OBJS) $(TK_LIB_FILE)
          ${CC}  $(TKTEST_OBJS)  !               -bI:/usr/local/LTA-DEV/src/tk8.3.2/unix/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/LTA-DEV/src/tk8.3.2/unix/lib.exp  $(WISH_LIBS) $(TK_LD_SEARCH_FLAGS) -lXt -o xttest

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

    tktest: ${TCL_BIN_DIR}/tcltest $(TKTEST_OBJS) $(TK_LIB_FILE)
          ${CC}  $(TKTEST_OBJS)  !               -Wl,-bI:/usr/local/LTA-DEV/src/tk8.3.2/unix/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  !               -Wl,-bI:/usr/local/LTA-DEV/src/tk8.3.2/unix/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:
  The patch is between the generated Makefile and the changed Makefile
      which allowed a clean
      build.


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

  spinbox.test


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

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

  ---- Result was:

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

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


tkt_uuid: 2218964fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: Duplicate
title: canvas-18.* test failures
comment:
  ==== canvas-18.1 imove method - lines FAILED
  ==== Contents of test case:

      set id [.c create line 0 0 1 1 2 2 3 3]
      .c imove $id 0 4 4
      .c coords $id

  ---- Result was:
  4.0 4.0 0.9999999999999999 0.9999999999999999 1.9999999999999998 1.9999999999999998 3.0 3.0
  ---- Result should have been (exact matching):
  4.0 4.0 1.0 1.0 2.0 2.0 3.0 3.0
  ==== canvas-18.1 FAILED



  ==== canvas-18.2 imove method - lines FAILED
  ==== Contents of test case:

      set id [.c create line 0 0 1 1]
      .c imove $id 0 4 4
      .c coords $id

  ---- Result was:
  4.0 4.0 0.9999999999999999 0.9999999999999999
  ---- Result should have been (exact matching):
  4.0 4.0 1.0 1.0
  ==== canvas-18.2 FAILED



  ==== canvas-18.3 imove method - lines FAILED
  ==== Contents of test case:

      set id [.c create line 0 0 1 1 2 2 3 3]
      .c imove $id @1,1 4 4
      .c coords $id

  ---- Result was:
  0.0 0.0 4.0 4.0 1.9999999999999998 1.9999999999999998 3.0 3.0
  ---- Result should have been (exact matching):
  0.0 0.0 4.0 4.0 2.0 2.0 3.0 3.0
  ==== canvas-18.3 FAILED



  ==== canvas-18.5 imove method - polygon FAILED
  ==== Contents of test case:

      set id [.c create polygon 0 0 1 1 2 2 3 3]
      .c imove $id 0 4 4
      .c coords $id

  ---- Result was:
  4.0 4.0 0.9999999999999999 0.9999999999999999 1.9999999999999998 1.9999999999999998 3.0 3.0
  ---- Result should have been (exact matching):
  4.0 4.0 1.0 1.0 2.0 2.0 3.0 3.0
  ==== canvas-18.5 FAILED



  ==== canvas-18.6 imove method - polygon FAILED
  ==== Contents of test case:

      set id [.c create polygon 0 0 1 1]
      .c imove $id 0 4 4
      .c coords $id

  ---- Result was:
  4.0 4.0 0.9999999999999999 0.9999999999999999
  ---- Result should have been (exact matching):
  4.0 4.0 1.0 1.0
  ==== canvas-18.6 FAILED



  ==== canvas-18.7 imove method - polygon FAILED
  ==== Contents of test case:

      set id [.c create polygon 0 0 1 1 2 2 3 3]
      .c imove $id @1,1 4 4
      .c coords $id

  ---- Result was:
  0.0 0.0 4.0 4.0 1.9999999999999998 1.9999999999999998 3.0 3.0
  ---- Result should have been (exact matching):
  0.0 0.0 4.0 4.0 2.0 2.0 3.0 3.0
  ==== canvas-18.7 FAILED


tkt_uuid: 2219588fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 7 High
foundin: obsolete: 8.6a4
resolution: None
title: ttk::spinbox needs aqua arrow elements
comment:
  I have committed a ttk::spinbox with support in all the core themes except for Aqua. Someone with a Mac needs to add the button elements for that theme and check it all looks ok.


tkt_uuid: 222014ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Duplicate
title: bgerror doesn't skip messages with break
comment:
  OS: Windows, Linux

  According to the documentation:

  "If several background errors accumulate before bgerror is invoked to process them, bgerror will be invoked once for each error, in the order they occurred. However, if bgerror returns with a break exception, then any remaining errors are skipped without calling bgerror."

  In the 8.0 version, "return -code break" works as expected.

  In the 8.3.2 version, the "return -code break" command in the bgerror handlers causes an exception and messages continue to be displayed.

  To reproduce:

  launch wish8.3.2

  button .b -text "Button" -command foobar
  pack .b

  proc bgerror {error} {

     return -code break
  }

  Then click on the button. Notice the message in the standard output:

  bgerror failed to handle background error.
      Original error: invalid command name "foobar"
      Error in bgerror: invoked "break" outside of a loop


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: 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: 222477ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
resolution: Duplicate
title: XIM is not working on RedHat Linux 7J
comment:
  XIM is not working at all on RedHat Linux 7 Japanese Edition with
  tk useinputmethods 1

  I will submit patches to improve XIM on 8.4a2. Thanks.

  Keiichi Takahashi


tkt_uuid: 2225507fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: obsolete: 8.4.19
resolution: None
title: Win32 menu keyboard traversal broken
comment:
  Greetings,

  the Win32 menu keyboard traversal is broken in the
  following way:
  When a menu (from a menubutton) is posted via the
  <Alt-Key> binding (_not_ via the mouse!), the <Escape>
  key closes the menu but leaves the menubutton armed.
  Unfortunately, another <Alt-Key> on the same menu
  then fails! One has to open a different menu before
  being able to open the first menu again.

  The proposed fix from
  http://groups.google.com/groups/search?as_q=Windows+Menu+Keyboard&as_epq=&as_oq=&as_eq=&num=10&scoring=&lr=&as_sitesearch=&as_ugroup=comp.lang.tcl&as_usubject=&as_uauthors=&safe=off

  which boils down to adding the line
  MenuUnpost {}
  to the proc
  ::tk::MenuFirstEntry
  fixes this problem for me.

  kind regards,
  Randolf
  -- 
  http://www.ayam3d.org/  NURBS modelling for the masses.


tkt_uuid: 222575ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 4
foundin: obsolete: 8.3.2
resolution: Works For Me
title: Under windows, root window wrongly lowered
comment:
  I type the following commands in the wish console:

  wm deiconify .
  wm resizable . 0 0

  Expected behaviour: no visible effect: the root window already being raised,
  wm deiconify does nothing; the wm resizable command has no visible effect.

  Actual behaviour: the root window is lowered (put behind all other windows).
  This occurs when the wm resizable command is issued.  Note that this only
  happens when wm resizable is preceeded by wm deiconify.  Note that this
  only happens on windows machines (win 98, win 95).


tkt_uuid: 222677ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: None
title: toplevel with '-use 0x...' doesn't receive <Destroy> e
comment:
  This is on Windows 2000 pro, service pack 1.

  keywords: embedding, -use, -container.

  Start up two copies of wish.  In the first, type:

  % toplevel .t -container 1
  .t
  % winfo id .t
  0x290526
  % bind .t <Destroy> {puts "destroyed %W"}
  % 

  In the second, type:

  % toplevel .s -use 0x290526
  .s
  % bind .s <Destroy> {puts "destroyed %W"}
  % 

  Now, '.s' is embedded inside '.t', which is great!  (very cool functionality!).  However, if I now destroy .t (by, say, clicking on the close-box), a message:

  destroyed .t

  appears in the console of the first wish, but no corresponding 'destroyed .s' message every appears (and in fact '.s' still exists, but is just not shown anywhere):

  % winfo children .
  .s
  % wm geometry .s
  200x200+0+0
  % winfo ismapped .s
  1
  % .s cget -use
  0x290526
  % wm state .s
  withdrawn
  % wm deiconify .s
  can't deiconify .s: it is an embedded window

  Is this the desired behaviour?  Whether it is or not, does anyone know of any workarounds?  How can the interpreter that owns '.s' find out that .s has ceased to be a useful window...?

  cheers,

  Vince.


tkt_uuid: 222909ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 15. [scale]
priority: 6
foundin: obsolete: 8.4.7
resolution: None
title: Scale widget: Last tickmark missing
comment:
  On some machines (in my case Linux 2.4.0-test5) the last
  tickmark of a scale is missing. The following code shows
  this problem:

  wm geometry . 300x100+50+50
  scale .h -orient horizontal -from 0 -to 20 -length 284 \
       -tickinterval 4 -resolution 0.08
  pack .h

  The tickmarks go only up to 16.00 and not up to 20.00.

  As far as I could see this bug is due to a problematic floating point comparison in the functions DisplayVerticalScale() and DisplayHorizontalScale() in
  tkUnixScale.c in mTk/generic (I'm not sure about the exact directory because I only have the perl Tk sources).

  Here are the diffs for a patch for the three files
  tkUnixScale.c, tkScale.c and tkScale.h:

  ############################################################

  *** tkUnixScale.c.origThu Nov 16 09:27:29 2000
  --- tkUnixScale.cThu Nov 16 09:22:16 2000
  ***************
  *** 112,115 ****
  --- 112,116 ----
        Tk_Tile tile;
        GC gc;
  + int numTicks, i;
    
        /*
  ***************
  *** 169,174 ****
    
    if (scalePtr->tickInterval != 0) {
  !     for (tickValue = scalePtr->fromValue; ;
  !     tickValue += scalePtr->tickInterval) {
    /*
     * The TkRoundToResolution call gets rid of accumulated
  --- 170,176 ----
    
    if (scalePtr->tickInterval != 0) {
  ! numTicks = TkCalculateNumberOfTicks(scalePtr);
  !     for (tickValue = scalePtr->fromValue, i = 0; i < numTicks;
  !  tickValue += scalePtr->tickInterval, i++) {
    /*
     * The TkRoundToResolution call gets rid of accumulated
  ***************
  *** 177,189 ****
    
    tickValue = TkRoundToResolution(scalePtr, tickValue);
  - if (scalePtr->toValue >= scalePtr->fromValue) {
  -     if (tickValue > scalePtr->toValue) {
  - break;
  -     }
  - } else {
  -     if (tickValue < scalePtr->toValue) {
  - break;
  -     }
  - }
    DisplayVerticalValue(scalePtr, drawable, tickValue,
    scalePtr->vertTickRightX);
  --- 179,182 ----
  ***************
  *** 417,420 ****
  --- 410,414 ----
        Tk_Tile tile;
        GC gc;
  + int numTicks, i;
    
        /*
  ***************
  *** 438,443 ****
    
    if (scalePtr->tickInterval != 0) {
  !     for (tickValue = scalePtr->fromValue; ;
  !     tickValue += scalePtr->tickInterval) {
    /*
     * The TkRoundToResolution call gets rid of accumulated
  --- 432,438 ----
    
    if (scalePtr->tickInterval != 0) {
  ! numTicks = TkCalculateNumberOfTicks(scalePtr);
  !     for (tickValue = scalePtr->fromValue, i = 0; i < numTicks;
  !  tickValue += scalePtr->tickInterval, i++) {
    /*
     * The TkRoundToResolution call gets rid of accumulated
  ***************
  *** 446,458 ****
    
    tickValue = TkRoundToResolution(scalePtr, tickValue);
  - if (scalePtr->toValue >= scalePtr->fromValue) {
  -     if (tickValue > scalePtr->toValue) {
  - break;
  -     }
  - } else {
  -     if (tickValue < scalePtr->toValue) {
  - break;
  -     }
  - }
    DisplayHorizontalValue(scalePtr, drawable, tickValue,
    scalePtr->horizTickY);
  --- 441,444 ----

  ###########################################################

  *** tkScale.c.origThu Nov 16 09:27:11 2000
  --- tkScale.cThu Nov 16 10:45:08 2000
  ***************
  *** 1173,1176 ****
  --- 1173,1211 ----
    
    /*
  +  *--------------------------------------------------------------
  +  *
  +  * TkCalculateNumberOfTicks --
  +  *
  +  *Calculates the number of ticks needed for the scale, based
  +  *on the scale's resolution setting.
  +  *
  +  * Results:
  +  *The return value is the number of ticks needed.
  +  *
  +  * Side effects:
  +  *None.
  +  *
  +  *--------------------------------------------------------------
  +  */
  + 
  + int
  + TkCalculateNumberOfTicks(scalePtr)
  +     TkScale *scalePtr;/* Information about scale widget. */
  + {
  + double new, rem;
  + double interval = scalePtr->toValue-scalePtr->fromValue;
  + int numTicks;
  + 
  + numTicks = (int) floor(interval / scalePtr->tickInterval) + 1;
  + 
  + if (scalePtr->resolution > 0)
  + while (numTicks * fabs(scalePtr->tickInterval) <
  +    fabs(interval) + scalePtr->resolution / 2)
  + numTicks++;
  + 
  +     return numTicks;
  + }
  + 
  + /*
     *----------------------------------------------------------------------
     *

  ############################################################

  *** tkScale.h.origThu Nov 16 09:27:18 2000
  --- tkScale.hWed Nov 15 09:51:25 2000
  ***************
  *** 218,221 ****
  --- 218,222 ----
    EXTERN doubleTkRoundToResolution _ANSI_ARGS_((TkScale *scalePtr,
        double value));
  + EXTERN intTkCalculateNumberOfTicks _ANSI_ARGS_((TkScale *scalePtr));
    EXTERN TkScale *TkpCreateScale _ANSI_ARGS_((Tk_Window tkwin));
    EXTERN voidTkpDestroyScale _ANSI_ARGS_((TkScale *scalePtr));

  ############################################################

  Please feel free to email me if you need more expanations etc.

                                     Jens

  -- 
          _  _____  _____
         | ||_   _||_   _|         Jens.Toerring@physik.fu-berlin.de
      _  | |  | |    | |           AG Moebius, Institut fuer Molekuelphysik
     | |_| |  | |    | |           Fachbereich Physik, Freie Universitaet Berlin
      \___/ens|_|homs|_|oerring    Tel: ++49 (0)30 838 - 53394 / FAX: - 56046


tkt_uuid: 223112ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 7 High
foundin: obsolete: 8.2.2
resolution: None
title: tkMenuFind doesn't locate cloned menubars
comment:
  [I hesitate to report this, but I'll be damned if I can make it work.  Nor can I find a related bug report].

  Consider the following simple example:

  % wish
     canvas .c -width 256 -height 256
     pack .c
     bind .c <KeyPress-a> {puts "Is RB out of line here?"}

  Pressing the "a" key does not invoke the callback script, under RH 6.2, Tcl/Tk 8.2.2.  More elaborate keyboard bindings also fail.

  I have been unable to make *any* keyboard-oriented events work under this environment, to include "underlined" menu items, menu accelerator commands, etc.  Could be indicative of a larger problem.

  Have been unable to verify other platforms; same phenomena occurs on an IRIX 6.5 client, but the constant is still the stock RH 6.2 X server (XFree86 3.3.??).

  I appreciate any feedback, even if it goes something like: "Look nimrod, you're obviously confused, and the proper way to accomplish this is...."


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: 2236352fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.4.17
resolution: None
title: NULL dereference as result of peculiarly formed font name
comment:
  I'm running Fedora 8; I don't see any changes between tk8.4.17 and tk8.4.19 that would fix this.  If I must run 8.4.19 to have this addressed, please explain to me how I can install 8.4.19 without breaking system dependencies.

  A weird font name, "-misc-????-bold-r-normal--17-120-100-100-p-0-iso8859-1",
  is causing TkFontParseXLFD to return bad results, including a NULL pointer for the font family and a negative number for the font size.  I'd like TkFontParseXLFD to detect bad return values from the functions it calls and return TCL_ERROR when it sees them.

  Here's some of the gdb session where the error occurs:

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread -1208772928 (LWP 18846)]
  0x002866b9 in strcasecmp () from /lib/libc.so.6
  Missing separate debuginfos, use: debuginfo-install python.i386
  (gdb) bt
  #0  0x002866b9 in strcasecmp () from /lib/libc.so.6
  #1  0x00d7bbca in IdentifySymbolEncodings (faPtr=0xbfd4fef4)
      at /usr/src/debug/tk8.4.17/unix/tkUnixFont.c:2857
  #2  0x00d7c4f5 in CanUseFallback (fontPtr=0x8ddb518, 
      faceName=<value optimized out>, ch=20092, fixSubFontPtrPtr=0x0)
      at /usr/src/debug/tk8.4.17/unix/tkUnixFont.c:2361
  #3  0x00d7cea1 in FindSubFontForChar (fontPtr=0x8ddb518, ch=20092, 
      fixSubFontPtrPtr=0x0) at /usr/src/debug/tk8.4.17/unix/tkUnixFont.c:1961
  #4  0x00d7d4be in Tk_MeasureChars (tkfont=0x8ddb518, 
      source=0x93a106a "'(a�\211ΩB�\201\205乼cz):\\n'\n", numBytes=21, 
      maxLength=411, flags=0, lengthPtr=0xbfd50358)
      at /usr/src/debug/tk8.4.17/unix/tkUnixFont.c:1083
  #5  0x00d68e80 in MeasureChars (tkfont=0x8ddb518, 
      source=0x93a106a "'(a�\211ΩB�\201\205乼cz):\\n'\n", 
      maxBytes=<value optimized out>, startX=0, maxX=411, tabOrigin=0, 
      nextXPtr=0xbfd503a4) at /usr/src/debug/tk8.4.17/generic/tkTextDisp.c:5265
  #6  0x00d6905d in TkTextCharLayoutProc (textPtr=0x8c54518, 
      indexPtr=0xbfd50564, segPtr=0x93a1030, byteOffset=46, maxX=411, 
      maxBytes=22, noCharsYet=1, wrapMode=TEXT_WRAPMODE_WORD, chunkPtr=0x93a5e38)
      at /usr/src/debug/tk8.4.17/generic/tkTextDisp.c:4534
  #7  0x00d6a739 in LayoutDLine (textPtr=0x8c54518, 
      indexPtr=<value optimized out>)
      at /usr/src/debug/tk8.4.17/generic/tkTextDisp.c:1017
  #8  0x00d6b068 in UpdateDisplayInfo (textPtr=0x8c54518)
  ---Type <return> to continue, or q <return> to quit---
      at /usr/src/debug/tk8.4.17/generic/tkTextDisp.c:1333
  #9  0x00d6b939 in TkTextPixelIndex (textPtr=0x0, x=1, y=377, 
      indexPtr=0xbfd50698) at /usr/src/debug/tk8.4.17/generic/tkTextDisp.c:4181
  #10 0x00d72b39 in TkTextPickCurrent (textPtr=0x8c54518, eventPtr=0x8c546cc)
      at /usr/src/debug/tk8.4.17/generic/tkTextTag.c:1410
  #11 0x00d6cc47 in DisplayText (clientData=0x8c54518)
      at /usr/src/debug/tk8.4.17/generic/tkTextDisp.c:2281
  #12 0x00441af8 in TclServiceIdle () from /usr/lib/libtcl8.4.so
  #13 0x0042f24f in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so
  #14 0x0012c6ec in ?? () from /usr/lib/python2.5/lib-dynload/_tkinter.so
  #15 0x05e617ed in PyCFunction_Call () from /usr/lib/libpython2.5.so.1.0
  #16 0x05eaec72 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
  #17 0x05eaf6bf in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
  #18 0x05ead844 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
  #19 0x05eadfcd in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
  #20 0x05eaf6bf in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
  #21 0x05ead844 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
  #22 0x05eaf6bf in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
  #23 0x05eaf743 in PyEval_EvalCode () from /usr/lib/libpython2.5.so.1.0
  #24 0x05ec93e6 in ?? () from /usr/lib/libpython2.5.so.1.0
  #25 0x05ec949e in PyRun_FileExFlags () from /usr/lib/libpython2.5.so.1.0
  #26 0x05ecab58 in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.5.so.1.0
  #27 0x05ecb2ba in PyRun_AnyFileExFlags () from /usr/lib/libpython2.5.so.1.0
  #28 0x05ed4e06 in Py_Main () from /usr/lib/libpython2.5.so.1.0
  ---Type <return> to continue, or q <return> to quit---
  #29 0x080485d2 in main ()
  (gdb) frame
  #0  0x002866b9 in strcasecmp () from /lib/libc.so.6
  (gdb) frame 1
  #1  0x00d7bbca in IdentifySymbolEncodings (faPtr=0xbfd4fef4)
      at /usr/src/debug/tk8.4.17/unix/tkUnixFont.c:2857
  2857            if (strcasecmp(faPtr->fa.family, symbolClass[i]) == 0) {
  (gdb) print faPtr->fa.family
  $1 = 0x0
  (gdb) print faPtr->fa
  $2 = {family = 0x0, size = -17, weight = 1, slant = 0, underline = 0, 
    overstrike = 0}
  (gdb) print *faPtr
  $3 = {fa = {family = 0x0, size = -17, weight = 1, slant = 0, underline = 0, 
      overstrike = 0}, xa = {foundry = 0x8c56748 "misc", slant = 0, 
      setwidth = 0, charset = 0x99c07f0 "iso8859-1"}}
  (gdb) frame 2
  #2  0x00d7c4f5 in CanUseFallback (fontPtr=0x8ddb518, 
      faceName=<value optimized out>, ch=20092, fixSubFontPtrPtr=0x0)
      at /usr/src/debug/tk8.4.17/unix/tkUnixFont.c:2361
  2361            IdentifySymbolEncodings(&got);
  (gdb) print got
  $4 = {fa = {family = 0x0, size = -17, weight = 1, slant = 0, underline = 0, 
      overstrike = 0}, xa = {foundry = 0x8c56748 "misc", slant = 0, 
      setwidth = 0, charset = 0x99c07f0 "iso8859-1"}}
  (gdb) p nameList[nameIdx]
  $5 = 0x8d6ee21 "-misc-????-bold-r-normal--17-120-100-100-p-0-iso8859-1"
  (gdb) 


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: 223739ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: final: 8.0.5
resolution: Fixed
title: tkTextDisp.c performs floating point comparisons (if ==)
comment:
  I first ran into this in 8.0.5, but the 8.2.3 code has the same problem
  and I suspect even the newest version has it.

  tkTextDisp.c performs direct equivalence comparisons between floating
  point values within if statments. Everybody should know this isn't valid
  programming. Floating point comparisons need to be (|a-b|>delta).

  Specifically, I have a case where GetYView() is failing on the following
  statement on Linux when built with optimization.

  if ((first == dInfoPtr->yScrollFirst) && (last == dInfoPtr->yScrollLast)) {

  The failure causes Tk to go into on infinite loop.

  While the same test case works on unix (hpux, solaris, etc), Linux is
  running on intel hardware. And intel chips perform 80-bit floating point
  arithemetic even when doubles are stored as 64-bit values. So there
  is more precission in the registers and the optimized code uses more
  registers.

  I've found the following 3 workarounds.
  1. Compile tkTextDisp.c non-optimized (works by accident).
  2. Write a compare function and pass the values of this specific
      if statement to it. The compare function uses the if ==, but
      this causes the register values to go through storage. Hence,
      causing the precission to be set back to 64-bit values.
  3. Force 53-bit arithmetic by with the following code in main().
      (or tk_Main, or ...). This mimics other unix vendor hardware.
      Note the variable 'i' MUST be used.
     #include <fpu_control.h>
     int i = 0x127f;
     _FPU_SETCW(i);

  These are all bandaids and can still fail. The real fix is to fix the
  actual problem. ie Code proper arithmetic tests within Tcl/Tk.


tkt_uuid: 2239034fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 8
foundin: None
resolution: Fixed
title: [wm manage] failure with ttk::frames
comment:
  [wm manage] seems not to work with [ttk::frame]s. (It doesn't seem to be working right for other widgets, actually - see below.) Tk [frame]s work fine. I'm using TclKit 8.5.2 on Windows XP SP3. Example:

  % ttk::frame .f
  .f
  % button .f.b -text "Test"
  .f.b
  % pack .f.b
  % wm manage .f

  At this point, nothing noticable has happened - there isn't a new toplevel window created for .f

  If I then do

  % wm forget .f
  % pack .f

  I see my "Test" button appear in the absolute top left-hand corner of my screen (not in a window - floating loose). If I attempt to interact with it it vanishes instantly. It seems that space is allocated for the frame in . when I try to [pack] it, though - repeat the above with a [text] widget instead of a [button] and you'll see . grow to accomodate it, even though it doesn't actually pack it. (This isn't specific to [pack], either - I first noticed it in a panewindow)

  If I try [wm manage] with other Tk widgets (I've tried [button] and [text]), I still don't get a toplevel, but if I [wm forget $tkWidget] and then [pack $tkWidget], it does pack correctly. Other Ttk widgets seem to have the same issue as a ttk::frame.

  So, it seems like only [frame]s can be successfully [wm manage]'d. (I actually remember reading it that way when I first heard about [wm manage] being added, but it seems not to be what the documentation at http://www.tcl.tk/man/tcl8.5/TkCmd/wm.htm#M39 says, so not sure whether this is a code error or a documentation fault. Though if it is only meant to work for frames, it should probably error for other widgets?)


tkt_uuid: 224002ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 3 Low
foundin: final: 8.2.3
resolution: Wont Fix
title: On Win32, Tk console is always covered at startup
comment:
  After you install wish, run it from the start-menu. Both the . window and the tk console are shown, with the console covered by the . window. This obscures the view of the console and makes it difficult to type into the console.

  Plus, at this point, if you click on the body if the console, it will not raise the console to the top of the . window. You have to click on the title bar of the console.


tkt_uuid: 224066ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 39. Image Basics
priority: 9 Immediate
foundin: None
resolution: Out of Date
title: Tk_PhotoPutBlock speed improvement (w/ patch)
comment:
  Tk_PhotoPutBlock is pretty slow on non-32bit displays.  This is an issue for any program that uses images; but especially bad for those that do dynamic image creation (e.g., animation, interactive graphics, etc).

  I've tweaked the dithering routine for slightly better speed.  Dithering defaults to on (configure with "-dither 1"); but can also be disabled on a per-image basis ("-dither 0").  On 16 bit displays, dithering provides only a marginal visual improvement; while on 8-bit displays, a program may wish to disable dithering so, e.g., their toolbars look better.

  On my AMD K6-3 400/Riva 128/XF86 3.3.5/Linux 2.4.0-test10, the framerate for 640x480 image update/redisplays are:
  <table>
  <tr>
  <td>Framerate</td><b><td>32 bit</td><td>16 bit</td><td>8 bit</td></b>
  </tr><tr>
  <td>Unmodified:</td><td>6.16</td><td>3.32</td><td>4.24</td>
  </tr><tr>
  <td>Modified, "-dither 1"</td><td>6.98</td><td>4.89</td><td>5.56</td>
  </tr><tr>
  <td>Modified, "-dither 0"</td><td>7.09</td><td>11.50</td><td>15.92</td>
  </tr>
  </table>

  generic/tkImgPhoto.c is the only modified source file.  DitherInstance is completely reorganized (moved slow central switch statement outside inner loop using function pointers).  The changes have been extensively tested under Linux in 32, 16, and 8-bit mode (greyscale and pseudocolor); other platforms/depths should work but have not been tested.  A patch against the CVS 11/27/2000 version is available at: 
      <a href="http://charm.cs.uiuc.edu/users/olawlor/tmp/tkImgPhoto.patch">
  http://charm.cs.uiuc.edu/users/olawlor/tmp/tkImgPhoto.patch</a>


  tests/imgPhoto.test is slightly changed for the "-dither" configuration option.  The (trivial) patch is:
  *** imgPhoto.test.orig  Fri Dec  1 13:17:23 2000
  --- imgPhoto.test       Fri Dec  1 13:00:12 2000
  ***************
  *** 149,153 ****
    test imgPhoto-4.6 {ImgPhotoCmd procedure: configure option} {
        llength [p1 configure]
  ! } {7}
    test imgPhoto-4.7 {ImgPhotoCmd procedure: configure option} {
   
       p1 conf -palette 3/4/2
  --- 149,153 ----
    test imgPhoto-4.6 {ImgPhotoCmd procedure: configure option} {
        llength [p1 configure]
  ! } {8}
    test imgPhoto-4.7 {ImgPhotoCmd procedure: configure option} {
        p1 conf -palette 3/4/2


  Orion Sky Lawlor, olawlor@acm.org.


tkt_uuid: 2243962fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 7 High
foundin: None
resolution: Accepted
title: Adding a tk.pc to be used by pkg-config
comment:
  Attached is a patch to configure.in and Makefile.in, and a tk.pc.in.  These will create a tk.pc file at compile-time, which will be added to the system-wide pkgconfig on install.  This lets developers use pkg-config to determine the include paths and linker flags.


tkt_uuid: 224931ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Fixed
title: odd display of german letters using default ansi font
comment:
  Using the windows system font 'ansi', german letters, e.g. ß,ä,ö étc. are displayed with a wrong metric in menue entries, on buttons etc. In an string to be displayed, this letters seem always to be moved to the right. For example, I want to have a button 'Run', where the german expression is 'Ausführen'. Now, when mapping the string 'Ausführen' on the button, the letter 'ü' moves to the right, so there is no space between the 'f' and the 'ü', but there is more space than usual
  between 'ü' and 'r'.
  It looks odd. In none-Tcl/Tk Application I do not see such behavior.


tkt_uuid: 224936ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 3 Low
foundin: obsolete: 8.3.1
resolution: Fixed
title: tk_chooseDirectory crashes in Windows95
comment:
  When I type 'tk_chooseDirectory' on the command-prompt in wish83 on a Windows95 system, wish crashes with the following errormessages:

  PROWISH83 verursachte einen Fehler durch eine ungültige Seite
  in Modul TK83.DLL bei 0137:004198e4.
  Register:
  EAX=00001767 CS=0137 EIP=004198e4 EFLGS=00010246
  EBX=0072df8a SS=013f ESP=0072ddfc EBP=0072df2c
  ECX=00001767 DS=013f ESI=0072dfae FS=0e67
  EDX=00000489 ES=013f EDI=00020000 GS=0000
  Bytes bei CS:EIP:
  89 51 04 33 c0 e9 ea 01 00 00 8b 45 e0 81 78 04 
  Stapelwerte:
  0000000a 00000000 00000001 0072de5c 0051006b 0097c6f0 0097c701 0072e138 004a39fd 0051d1e0 0097a638 00000001 00000000 0000000a bff74277 0442cb6d

  Register:
  EAX=1004da3d CS=0137 EIP=005de12e EFLGS=00010282
  EBX=10000000 SS=013f ESP=008ef84c EBP=008ef858
  ECX=8b944d89 DS=013f ESI=00000000 FS=0f47
  EDX=8b944d89 ES=013f EDI=00000001 GS=0000
  Bytes bei CS:EIP:
  8b 42 08 3b 45 f8 75 0a 8b 4d f4 c7 41 08 00 00 
  Stapelwerte:
  8b944d89 024fc908 006c1b08 008ef8e0 0063054d 024d98f8 00000117 00000984 024d9bf8 4bbbd880 00000011 00000685 00000000 007028e8 02510364 02510364  


tkt_uuid: 225025ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Fixed
title: Listbox doesn't scroll exactly like Text or Entry
comment:
  A Listbox, Textbox, and Entry packed in the same frame and bound to the same horizontal scrollbar will scroll slightly differently even when they include the same text.

  The included script will demonstrate this cosmetic problem. Execute the script and resize the window so the text goes off-screen; try scrolling the scrollbar and note that the text in the different components scrolls at different pixels.

  Textbox and Entry, in their calculations for scrolling, multiply the "xview moveto" fractional parameter by the width of the component (measured in characters) and round to the nearest character. Listbox, on the other hand, multiplies the fractional parameter by the width of the Listbox (measured in pixels) and rounds to the nearest pixel, but then _truncates_ to the nearest character (i.e. nearest xScrollUnit).

  If Listbox is changed to _round_ to the nearest character, it is a better analogue of the other components, in this situation, and offhand I can't think of a reason why it should truncate instead of rounding -- perhaps it is a bug.

  To round instead of truncating, insert the following line as line 2611 of tk8.3.2's generic/tkListbox.c:

  offset += listPtr->xScrollUnit / 2;

  The math still isn't perfect, because of the rounding that has already taken place on offset, but it's close. After the change, the script below should show the scrolling to be better synchronized.




  #!/bin/sh
  #\
  exec wish8.3 -f "$0" ${1+"$@"}

  # settings
  set str "this is a long string which will prove the example"
  set font {#courier-bold-r-*-*-12*}

  # create components
  entry .e -xscrollcommand {.s set} -background green -width 50 -font $font
  listbox .l -height 1 -xscrollcommand {.s set} -background blue -width 50 -font $font
  text .t -height 1 -xscrollcommand {.s set} -background white -width 50 -font $font -wrap none
  scrollbar .s -orient horizontal -command {bindxview {.e .l .t}}

  # insert text
  .e insert end $str
  .l insert end $str
  .t insert end $str

  # add components (same effect with pack or grid)
  grid .e -sticky ew
  grid .l -sticky ew
  grid .t -sticky ew
  grid .s -sticky ew
  grid columnconfigure . 0 -weight 1


  proc bindxview { components args } {
    puts "------------------\n$args\n.s get: [.s get]"
    foreach c $components {
      eval {$c xview} $args
      puts "$c xview: [$c xview]"
    }
  }


tkt_uuid: 225597ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 7 High
foundin: obsolete: 8.4a2
resolution: Fixed
title: no console(n) documentation
comment:
  Requests for documentation of the console command come up fairly frequently on comp.lang.tcl (though the questioners don't always realize this.)  Can we fix this, and stem this tide of FAQs?


tkt_uuid: 2262543fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 15. [scale]
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: None
title: Scale widget unexpectedly fires command callback
comment:
  The Tk scale widget (used through the Python/Tkinter interface) fires its command unexpectedly when it is initialized with a value.  This behavior is different then say, a checkbox, which can be initialized with a value without triggering the command callback.  I'm attaching a script which shows this behavior.

  scale1 is initialized with a value through the variable option.  The command callback for scale1 fires unexpectedly when the mainloop starts.  I say unexpectedly, because the value of the scale is never changed from its initial value (at least from the user/coders point of view).

  scale2 is initialized without a command callback.  The command callback is registered AFTER the value is changed, yet the callback still fires upon entering mainloop.

  Both of these behaviors strike me as unexpected, and contrary to how the command callback is typically used for other widgets.  Also in the test script are two checkbuttons that are initialized in similar fashion to the scale widgets above, and you can see that their command callbacks do not fire.

  This issue was discussed on the Tkinter mailing list: http://mail.python.org/pipermail/tkinter-discuss/2008-November/001714.html and there is additional info in Guilherme Polo's helpful replies.

  Guilherme also supplied this minimal tcl sample of the behavior as well, which I don't understand enough to explain:

  scale .s -command {puts}
  pack .s

  Thanks -

  Dave Giesen


tkt_uuid: 2262711fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: None
title: Regexp search fails with Unicode and elide
comment:
  If searched text is preceded by elided text which is preceded by "above ASCII" character then regexp search fails to count elided characters. Attached code shows this as last [puts] shows index "2.1" instead of "2.4" that is expected.

  Confirmed on Tcl/Tk 8.5.5 Linux 2.6.26.6 Gnome 2.22.3. Similar (yet unconfirmed) behavior seen on Windows with 8.5.4.


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: 2264732fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 8
foundin: None
resolution: Fixed
title: ttk themed widget X11 visual crash & patch
comment:
  Using ttk widgets in a wish toplevel which has
  a different X11 visual to the screen root window
  crashes.

  E.g. on a system with a 24-bit truecolor root
  window, which also supports 8-bit pseudocolor:

  % wish8.5 -visual "pseudocolor 8"
    ttk::label .l -text test
    pack .l

  crashes with:

  X Error of failed request: BadMatch (invalid parameter attributes)
  Major opcode of failed request: 70 (X_PolyFillRectangle)
  Serial number of failed request: 82
  Current serial number in output stream: 83

  The problem is in the double buffering code in
  ttkWidget.c,routine BeginDrawing(). It creates
  a pixmap with depth:

  DefaultDepthOfScreen(Tk_Screen(tkwin))

  which should simply be replaced with

  Tk_Depth(tkwin)

  An updated ttkWidget.c from CVS head revision 1.16
  is attached.  The same fix can be applied to the
  8.5.* series.

  Searching the bug tracker, this appears to be
  identical to the tk panedwindow bug #671122
  in 2003.


tkt_uuid: 226652ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: TK does not handle IME input on English Win2K
comment:
  Win2K now has "multi-lingual" support: e.g., it allows you to input Chinese characters on an English version of win2k. See the following link for details.

  http://www.microsoft.com/windows/ie/features/w2kime.asp

  Tk 8.4a2 and before do not handle this type of situation. If you use English win2k and try to input a Chinese char into a TK window, the char shows up as "?"

  The fix is to handle WM_INPUTLANGCHANGE and WM_IME_COMPOSITION events. I have a fix and I will submit to the SF patch manager shortly.

  After the fix, you can enter chars of any language, as long as the Input Method Editor of the given language is installed on your win2k box.

  The fix is for win2k only, but it's harmless on other versions of windows (95/98 or NT).


tkt_uuid: 226945ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Invalid
title: RGB color built-ins are incorrect
comment:
  If you do a man on colors, you will see the RGB values associated
  with the color names known internally by Tk.  Unfortunately, the
  values in the man page appear to not be typos!  The colors really
  are that bad.  I'm not sure who's rgb.txt file these colors came
  from, but they're horribly incorrect.  I haven't seen RGB values this
  bad in years.  I suggest updating the built-in color definitions.

  I will see about submitting a patch shortly.... ick....they're really
  bad.  I'm curious, where did they come from??


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: 228024ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Remind
title: core dumps with canvas
comment:
  I wrote a little application which uses a canvas
  to display pie charts showing disk usage. I used
  bindings of mouse events so that clicking on a 
  pie would zoom in and show the disk usage for
  that pie segment.  

  This worked fine until 8.3.2, now it occasionally
  causes a core dume (occasionally means about a
  50% chance).

  I think the problem is at least in part due to the
  way I re-build the canvas image.  The function that
  gets executed when a pie segment is clicked destroys
  the canvas and then re-builds it.  I've now fixed
  my code so that it just removes all the items from
  the canvas and the core dumps have stopped happening.

  Below is a fairly minimal example that demonstrates the
  problem.  Note that it does not core dump every time.
  Note also I'm running this on a redhat 6.2 system using
  Freewrap 4.4 (I've also tried it on redhat 7.0 using
  tk 8.3.2, same problems.. so i think FreeWrap is not
  guilty).

  http://home.nycap.rr.com/dlabelle/freewrap/freewrap.html

  Note also I was unable to register / log in to the 
  bug system (filled the form in then get told access 
  denied... )

  If you need further information please contact John Gill at
  jng@renre-europe.com


  #!/usr/bin/wish


  proc do_canvas {win} {
      
      eval destroy [winfo children $win]
      
      set c [canvas $win.c -height 200 -width 200]
      pack $c -fill both -expand yes
      
      $c create rectangle 80 80 120 120 -fill blue -tags blue

      # bind a button press to re-build the canvas
      $c bind blue <B1-ButtonRelease> [list do_canvas $win]

      return
  }

  do_canvas .


tkt_uuid: 2282861fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: Invalid
title: wm overrideredirect on suse11.0/KDE3.5 not working
comment:
  One additional detail (although it should have no effect on the problem): the ATI provided driver pack is installed over the one in the suse distribution (for the ATI Mobile X600 video card).

  The Windows counterpart does not have this problem.

  NJG (on the wiki)


tkt_uuid: 2283282fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: Invalid
title: Event 'Map' is generated also for children
comment:
  Under Unix, when using the:
    bind .any_toplevel <Map>  {some code}

  The code is executed when the window is mapped (ok), but also for each child widget being mapped.

   - Either this behavior is the same on all systems, in which case the man page would benefit in having a comment about this;

   - or this is not the case, then only one mapping event should be generated for the bound widget.


  contact info: christophe [dot] curis [at] free [dot] fr


tkt_uuid: 228444ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Works For Me
title: Can't enumerate font families on Windows NT/2000
comment:
  The initialization of the Tk system creates the application window before calling TkpInit().

  On windows, TkpInit() calls TkWinXInit(), which initialises the tkPlatformId variable. However, the font system is initialised during creation of the application window, and it uses this variable.

  In tkWinFont.c, in function TkpFontPkgInit(), the systemEncoding variable is set to unicodeEncoding, if the value of tkPlatformId is VER_PLATFORM_WIN32_NT. However, since this is done before the tkPlatformId variable is set up, the systemEncoding variable remains set to NULL.

  Later on, if you enumerate the fonts families (which calls TkpGetFontFamilies on windows), it determines that it is on NT (since the value of tkPlatformId is set up by this point), and calls the unicode version of EnumFontFamilies. 

  This calls the callback function with a unicode string, but the systemEncoding variable is still NULL, so the strings don't get decoded properly. What you actually get is the first character of each of the font families.

  This also means that you can't set fonts properly using the form {Courier -size 8}.

  I have patched this on my system as follows (in win/tkWinX.c):

  Near the top:
  > static int tkPlatformId=-1;

  Later on:
  > int TkWinGetPlatformId()
  > {
  > if (tkPlatformId==-1) {
  > OSVERSIONINFO os;
  > GetVersionEx(&os);
  > tkPlatformId = os.dwPlatformId;
  > }
  > return tkPlatformId;
  > }


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: 229191ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 1 Zero
foundin: obsolete: 8.3.2
resolution: Works For Me
title: checkbutton widget does not display checkbutton (WinNT)
comment:
  Win NT 4.0, Tcl/Tk 8.3.2 (binaries from dev.scriptics.com)
  in wish8.3.2, checkbutton widget does not display checkbutton, only button text. Appears to be working correctly otherwise.


tkt_uuid: 229358ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Duplicate
title: Clipping error in postscript output
comment:
  Items in a canvas, which is embedded in another canvas, are
  clipped by the inner canvas. This clipping is not done in
  postscript output of the outer canvas.

  tk-version: I tested it with 8.4a2 and 8.0 (diff is against 8.4a2)

  reproducible script:
  canvas .outer -bg red -width 120 -height 120
  pack .outer
  canvas .inner -bg white -width 100 -height 100
  .outer create window 10 10 -anchor nw -window .inner
  .inner create oval -5 -5 105 105 -fill blue
  update
  .outer postscript -file qqq.ps

  result:
  in the postscript file the oval is an oval.

  desired result:
  The oval should have (due to the clipping) corners as
  in the screen view.
  Second: outer is not drawn in red in the ps-file. I have 
  not yet a patch for this.


tkt_uuid: 230133ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Duplicate
title: tk_chooseDirectory results in page fault on Win 95 B
comment:
  If I enter the command

  tk_chooseDirectory

  in wish (8.3 and 8.4a, all releases), I get a page fault before the dialog window is created, and wish terminates.

  This error does only occur on my Windows 95 B computer at home, not on my Windows NT computer in my office.

  Unfortunately, I can't log in because my internet connection doesn't support ssl, but for feedback, you can reach me as conrad@de.adsanker.com


tkt_uuid: 230135ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: tk_getOpenFile -multiple doesn't work as described
comment:
  If I enter the command

  tk_getOpenFile -multiple

  I get an error message:

  Windows NT:
  value for "-multiple" missing

  Windows 95 B:
  bad option "-multiple": must be ...

  The correct syntax is

  tk_getOpenFile -multiple 1

  (If you want to be able to select multiple files), but it only works on Windows NT, On Windows 95 B, you get the same error message:
  bad option "-multiple": must be ...


tkt_uuid: 230562ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: Mistranslation in tk/library/msgs/de.msg
comment:
  "File names:" is translated with "Nombre de archivos:"
  whereas it should be "Dateinamen:"

  There are two more typesetting mistakes in the file.
  I put a unified diff under 

  http://mathematik.htwm.de/tmp/tcltk/msgs.diff


tkt_uuid: 230648ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Invalid
title: entry widget incorrectly displays international characters
comment:
  Even though one specifies a cyrillic KOI8R font for the
  widget, and inserts a string which has the correct
  character codes, the display is gibberish.   On the
  other hand the string stored in the widget is correct
  as one can see by using 'get':

  example
   entry .jo -font \ -cronyx-fixed-medium-r-normal--20-200-75-75-c-100-koi8-r 
  .jo insert 0 "\302\325"
  pack .jo

  then the display will not show the characters at these
  positions in the font which has been specified.   This
  does work correctly in tcl/tk 8.0   
  [note the russian characters should look like 'by',
  not some A's with hats and squiggles..].  
  Does there exist a font/character combination that makes
  tcl/tk display Russian correctly in tcl/tk 8.3.2 ?  I 
  want the standard international KOI8 encoding not some MS windows specific encoding.

  wfs@math.utexas.edu

  thing..

    


tkt_uuid: 2307387fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 8
foundin: None
resolution: Fixed
title: Spurious test failures on non-US keyboards
comment:
  On my french keyboard, XP SP2, several Tk tests fail:

  ==== bind-22.10 HandleEventGenerate FAILED
  ==== bind-22.10 FAILED
  ==== frame-2.8 toplevel configuration options FAILED
  ==== frame-2.8 FAILED
  ==== text-19.16 DeleteChars procedure, updates affecting topIndex FAILED
  ==== text-19.16 FAILED
  ==== text-33.11 peer widget -start, -end FAILED
  ==== text-33.11 FAILED
  ==== textDisp-29.2 miscellaneous: lines wrap but are still too long FAILED
  ==== textDisp-29.2 FAILED
  ==== textDisp-29.2.1 miscellaneous: lines wrap but are still too long FAILED
  ==== textDisp-29.2.1 FAILED
  ==== textDisp-29.2.2 miscellaneous: lines wrap but are still too long FAILED
  ==== textDisp-29.2.2 FAILED
  ==== textDisp-29.2.3 miscellaneous: lines wrap but are still too long FAILED
  ==== textDisp-29.2.3 FAILED
  ==== textDisp-29.2.4 miscellaneous: lines wrap but are still too long FAILED
  ==== textDisp-29.2.4 FAILED
  ==== textDisp-32.2 elide and tags FAILED
  ==== textDisp-32.2 FAILED
  ==== textImage-3.2 delayed image management FAILED
  ==== textImage-3.2 FAILED
  ==== + winDialog-1.1 hanging (bgerror window saying :

    while executing
  "testwinevent $::tk_dialog $button WM_LBUTTONDOWN 1 0x000a000b"
    (procedure "Click" line 2)


tkt_uuid: 230869ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Duplicate
title: Menues vanished after entryconfigure
comment:
  The following script does not work with tk8.4a2 (and 8.3.2,8.3.1)

  set t .t
  set m1 .t.m1
  set c1 .t.c1
  set c2 .t.c2

  toplevel $t
  menu $m1 -tearoff 1
  menu $c1 -tearoff 1
  $c1 add command -label c1
  menu $c2 -tearoff 1
  $c2 add command -label c2
  $m1 add cascade -label c1 -menu $c1
  update
  puts stderr "$t configure -menu $m1";
  $t configure -menu $m1
  update
  puts stderr "$m1 entryconfigure 1 -menu $c2 -label c2";
  $m1 entryconfigure 1 -menu $c2 -label c2
  update
  puts stderr "check for $c1: [winfo exists $c1]";
  puts stderr "check for $c2: [winfo exists $c2]";
  puts stderr "$t configure -menu \"\"";
  puts stderr "children: [winfo children .t.#t#m1]";
  $t configure -menu ""
  update
  puts stderr "C1: [winfo exists $c1]"
  puts stderr "C2: [winfo exists $c2]"

  The problem is fixed by changing generic/tkMenu.c, function
  ConfigureMenuCloneEntries the line

      cascadeEntryChanged = (strcmp(oldCascadeName, newCascadeName) 
      == 0);

  into

      cascadeEntryChanged = (strcmp(oldCascadeName, newCascadeName));

  Background:
  the variable indicates that the name has changed. Since
  the variable is not set correctly, menues are cloned
  when not changed and not cloned when changed. The sample
  script works fine.
  Here is a sample (correct) output of the script
  after the change (with some debug printout in tkMenu.c):

  /usr2/xxx/bin/wish8.4
  % source /tmp/xx.tcl
  .t configure -menu .t.m1
  duping menu .t.m1 into .t.#t#m1
  duping menu .t.c1 into .t.#t#m1.#t#c1
  .t.m1 entryconfigure 1 -menu .t.c2 -label c2
  ### ConfigureMenuCloneEntries - old=.t.c1, new=.t.c2 ==>-1
  ### ConfigureMenuCloneEntries, cascadeEntryChanged: -1 .t.c2
   destroying .t.#t#m1.#t#c1, master=0x80e1fd0: .t.c1
  duping menu .t.c2 into .t.#t#m1.#t#c2
  check for .t.c1: 1
  check for .t.c2: 1
  .t configure -menu ""
  children: .t.#t#m1.#t#c2
   destroying .t.#t#m1, master=0x80d5778: .t.m1
    destroying .t.#t#m1.#t#c2, master=0x80d6538: .t.c2
  C1: 1
  C2: 1
  % 

  This fix will also me posted to comp.lang.tcl!


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: 231165ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Wont Fix
title: tk_chooseDirectory converts path to uppercase (Windows 98)
comment:
  #Run the following code (Windows 98, Wish 8.3.2)

  set f [tk_chooseDirectory -title "Choose a Directory with lowercase naming"]
  tk_messageBox -message "Directory chosen:$f"

  #the message box will show the uppercase conversion


tkt_uuid: 231251ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: parray can cause X error
comment:
  Running with wish8.4a2 I made a call on parray and passed it (by mistake!)
  a large string rather than the name of an array. This caused wish to crash
  with an X-window system error about resource usage every time I executed the code.


tkt_uuid: 2321708fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: None
title: radiobutton (and checkbutton) behavior question
comment:
  The documentation for radiobutton and checkbutton has, for quite some time, included a paragraph to this effect:

       Command-Line Name:-selectcolor
       Database Name:  selectColor
       Database Class: Background

            Specifies a background color to use when the button is
            selected.  If indicatorOn is true then the color applies to
            the indicator.  Under Windows, this color is used as the
            background for the indicator regardless of the select state.
            If indicatorOn is false, this color is used as the back-
            ground for the entire widget, in place of background or
            activeBackground, whenever the widget is selected.  If
            specified as an empty string then no special color is used
            for displaying when the widget is selected.

  That isn't exactly what Tk is doing, as of Tk 8.5 I think.

  What happens on Solaris is now the same thing as happens on Windows - the background is used regardless of the select state. 

  The original behavior - using the color only when the item is selected - is really the preferred behavior. 

  Of course, an enhancement to provide a -deselectcolor and a -tristatecolor setting would probably be even better.


tkt_uuid: 232213ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 1 Zero
foundin: obsolete: 8.3.2
resolution: Invalid
title: ImgName -data will not take 1 pixel wide/high rectangles
comment:
  ImgName -data fails to select anything if the box provided by x1 y1 x2 y2 has either a height or width of 1 pixel (x1=x2 or y1=y2).  Minimum selection size becomes 2x2 pixels.

  The software should allow a 1 pixel wide selection.

  Ryan P. Casey


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: 2326602fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Incorrect documentation of canvas -width window item option.
comment:
  According to the current version (1.39) of the canvas documentation for the -width option of window items: 'If this option is not specified, or if it is specified as an empty string, then the window is given whatever width it requests internally.'

  However, specifying an empty string gives an error message: 'bad screen distance ""'

  It seems the described result is achieved by specifying a width of 0 instead of an empty string.

  % grid [canvas .c]
  % .c create window 10 10 -window [button .b] -width {}
  bad screen distance ""
  % set errorInfo
  bad screen distance ""
      (processing "-width" option)
      invoked from within
  ".c create window 10 10 -window [button .b] -width {}"

  A similar problem exists for the -height option.


tkt_uuid: 232731ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 6
resolution: Out of Date
title: exec grabs stdin -- wish8x.exe on Win9x only
comment:
  Problem summary:
    The exec command can be used to run a command in a shell [console] window on every platform except Win-95/98 (-ME?).  On Unix this is done with 
  exec xterm -e /bin/sh -c ...
  on Win-NT this is done with 
  exec $env(COMSPEC) /c "start ..."
  On Win-95/98 (I have not tried -ME) if one tries this, the DOS window the keyboard is not connected to stdin. This is not a Windows limitation, but rather a problem in wish (I have tested 8.0.3, 8.2.3 and 8.4a2).

  Example: 
    create a batch file, C:\test\test.bat, that contains three commands:
   
         PAUSE
         DIR
         PAUSE
   
  try to run this file from wish8x.exe using (for example)
  exec start {c:\test\test.bat} &
  the DOS box is created and you see the prompt "Press any key to continue..." but the window is hung. Note this does work from tclsh.exe.

  Details:
    This appears to be a problem with the exec command rather than an inherent limitation in Windows, because it is possible to achieve the correct result using the WINEXEC package (http://www.du.edu/~mschwart/tclextensions.html#WinexecTbl). The winexec command uses a direct call to CreateProcess 
  result = CreateProcess (argv[1],  0,  0, 0, 0, DETACHED_PROCESS, 0, 
  options.dirnameptr,  &si, &pi);
  so the problem must be related to all of the extra stuff that the exec command does.

  It would be good to have this limitation eliminated from wish on the Win-9x platform, rather than require use of a binary package and a non-standard command to achieve equivalence with wish on Unix and Win-NT.

  Brian


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: 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: 2330040fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Fixed
title: doc issues (for html docs) w/partial patch
comment:
  scanning page ../../tk/doc/busy.n
  oops: Copyright (c) 2008, Jos Decoster

  The copyright string is not in a recognized format, see the attached patch for the fix.

  ---------------------------

  scanning page ../../tk/doc/ttk_entry.n
  unbalanced .DS .DE
  ttk_entry: WIDGET COMMAND: output-directive: unexpected .DS format:
  <B>cget</B>     <B>configure</B>        <B>identify</B>
  <B>instate</B>  <B>state</B>

  This can be fixed by including an appropriate ".DE", see the attached patch.

  ---------------------------

  scanning page ../../tk/doc/ttk_spinbox.n
  ttk_spinbox: STANDARD OPTIONS: std-option-toc: missing reference to "-validate" in ttk::entry.n
  ttk_spinbox: STANDARD OPTIONS: std-option-toc: missing reference to "-validatecommand" in ttk::entry.n

  I believe this can be fixed properly by including the -validate and -validatecommand as standard options in ttk_entry.n, see the attached patch.

  ---------------------------

  scanning page ../../tk/doc/CrtItemType.3
  CrtItemType: process-text: uncaught backslash: <I>x&#8242;</I> = <I>originX</I> + <I>scaleX</I> &#215; (<I>x</I> \(mi \fIoriginX\fR)
  \fIy&#8242;\fR = \fIoriginY\fR + \fIscaleY\fR &#215; (\fIy\fR \(mi \fIoriginY\fR)

  The problem here is the "(\mi".  No real idea on how to fix this one.  I'm not sure what the "\(mi"  is supposed to do nor do I understand why the html doc generating tools do not recognize it.  This was a recent addition.


tkt_uuid: 233085ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Works For Me
title: scale widget and update -> bgerror
comment:
  Update and the scale widget seems to behave "more critical" in the recent version (8.3.1 and 8.3.2). The script below works fine under tcl/tk (8.0.5). It seems that the update routine should not be used anymore in connection to the scale widget.   

  Sorry for the rather long sample may be it could be reduced.

  set num_row 1000
  set i 0
  set STOP 0
  for {set i 1} {$i<=$num_row} {incr i} {
  set D_array($i) "0 2 3 0 5 76 756 06"
  } 

  proc Update_pic {Data} {
  foreach element $Data {
  for {set i 0} {$i<1000} {incr i} {}
  update 
  }
  }
  set i 1
  frame .remote
  pack .remote -side top 
  button .remote.fforward  -text ">>"  -fg blue -command {
  set STOP 1
  if {$i == $num_row} {set i 1}
  while {$i<[expr $num_row ]&& $STOP} {
   incr i
   Update_pic $D_array($i) 
   puts "picture updated with i= $i"
   }
  }
  button .remote.forward   -text ">|" -fg yellow -command {
   if {$i < $num_row} {
    incr i
    Update_pic $D_array($i)
   } else {set i 1}
   puts "picture updated with i= $i"
  }

  pack .remote.fforward .remote.forward -side left
  frame .progress
  pack .progress -side bottom
  scale .progress.scale -sliderlength 0.4i -from 1 -to $num_row -orient horizontal -length 10i -variable i -command {
  #Update_pic $D_array($i)
  .remote.forward invoke
  puts "scale 2.: [ .progress.scale get ]"
  puts  "scale callback $i"
  set i}
  puts $i
  pack .progress.scale
  #################################
  greetings,
  K. Lustig


tkt_uuid: 233150ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
resolution: Accepted
title: window flashes on screen when withdrawn/deiconified
comment:
  This problem only seems to show up under Windows.
  The bug exists in Tk 8.3.2, I assume it shows
  up in 8.4, but I have not tested that under Windows.

  This bug actually has two parts. You can sort of
  work around the problem by adding calls to update
  and update idletasks, but that also causes problems.

  Here is a bit of code that brings up a window
  after a delay. Try it out and you will notice
  that the window is initially mapped with a
  geom of 1000x1000, it is then resized down
  to the reqwidth and reqheight of the button.

  if 1 {
  set t [toplevel .t -width 1000 -height 1000 -bg black]
  wm withdraw $t
  update
  pack [button $t.b -text AREALLYLONGSTRING]
  after 4000
  #update idletasks
  wm deiconify $t
  }

  This problem can be "fixed" by uncommenting the
  "update idletasks" call. You might be wondering,
  why is the first call to update in there? Well
  that is because the Window appears on the screen
  for a split second even though it has been withdrawn.
  So, the first call to update keeps the window from
  appearing for a split second initially, but it
  causes another problem. When the window is mapped,
  it shows up at 1000x1000 for a split second and
  then it gets resized to the reqwidth and reqheight
  of the button.

  This second problem can be worked around by
  the "update idletasks", kind of ugly eh?

  What is really odd about this bug is that if
  you don't call update at all (the way it really
  should work) then the window is mapped correctly
  (even though it still flashed before being
  put away).


tkt_uuid: 2336454fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: Fixed
title: new test failures
comment:
  ==== bind-13.1 Tk_BindEvent procedure FAILED
  ==== Contents of test case:

      bind Test <KeyPress> {lappend x "%W %K Test KeyPress"}
      bind all <KeyPress> {lappend x "%W %K all KeyPress"}
      bind Test : {lappend x "%W %K Test :"}
      bind all _ {lappend x "%W %K all _"}
      bind .t.f : {lappend x "%W %K .t.f :"}

      event generate .t.f <Key-:>
      event generate .t.f <Key-+>
      event generate .t.f <Key-_>
      return $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad event type or keysym ":"
      while executing
  "event generate .t.f <Key-:>"
      ("uplevel" body line 8)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-13.1 FAILED



  ==== bind-13.4 Tk_BindEvent procedure FAILED
  ==== Contents of test case:

      bind Test : {lappend x "%W %K Test"}
      bind .t.f : {lappend x "%W %K .t.f"}
      foo
      return $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad event type or keysym ":"
      while executing
  "event generate .t.f <Key-:>"
      (procedure "foo" line 3)
      invoked from within
  "foo"
      ("uplevel" body line 4)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-13.4 FAILED



  ==== bind-13.7 Tk_BindEvent procedure FAILED
  ==== Contents of test case:

      bind .t.f : {lappend x "%W (.t.f binding)"}
      bind Test : {lappend x "%W (Test binding)"}
      bind all : {bind .t.f : {}; lappend x "%W (all binding)"}
      event generate .t.f <Key-:>
      return $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad event type or keysym ":"
      while executing
  "event generate .t.f <Key-:>"
      ("uplevel" body line 5)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-13.7 FAILED



  ==== bind-13.8 Tk_BindEvent procedure FAILED
  ==== Contents of test case:

      bind .t.f : {lappend x "%W (.t.f binding)"}
      bind Test : {lappend x "%W (Test binding)"}
      bind all : {destroy .t.f; lappend x "%W (all binding)"}
      event generate .t.f <Key-:>
      return $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad event type or keysym ":"
      while executing
  "event generate .t.f <Key-:>"
      ("uplevel" body line 5)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-13.8 FAILED



  ==== bind-13.13 Tk_BindEvent procedure: valid key detail FAILED
  ==== Contents of test case:

      bind .t.f <Key> "lappend x Key%K"
      bind .t.f <KeyRelease> "lappend x Release%K"
      event generate .t.f <Key> -keysym :
      event generate .t.f <KeyRelease> -keysym :
      return $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: unknown keysym ":"
      while executing
  "event generate .t.f <Key> -keysym :"
      ("uplevel" body line 4)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-13.13 FAILED



  ==== bind-28.5 keysym names FAILED
  ==== Contents of test case:

          bind .t.f <Key-:> "lappend x \"keysym received\""
          bind .t.f <Key-_> "lappend x {bad binding match}"
          set x [lsort [bind .t.f]]
          event generate .t.f <Key-:> ;# -state 0
          set x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad event type or keysym ":"
      while executing
  "bind .t.f <Key-:> "lappend x \"keysym received\"""
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-28.5 FAILED


tkt_uuid: 2353712fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Duplicate
title: treeview's row height doesn't depend on font size
comment:
  This script demonstrates the problem:

  ----
  package require Tk

  font configure TkDefaultFont -size 24
  ttk::treeview .tree -columns {one two three} -show headings

  .tree insert {} end -values [list one two three]
  .tree insert {} end -values [list one two three]
  grid .tree

  ----

  BTW, I didn't find -rowheight style option 
  documented anywhere.


tkt_uuid: 2353856fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Out of Date
title: compile of TkUnixEvent.c fails fix inside
comment:
  Line 294 of tkUnixEvent.c is a call to Tcl_Panic

      Tcl_Panic("Wild GenericEvent; panic! (extension=%d,evtype=%d)"
      xgePtr->extension, xgePtr->evtype);

  however this fails with a compile error because there is not comma "," after the first string arguement to Tcl_Panic. If the source is modified to include the comma then Tk compiles cleanly on Linux. 
  i.e. 

      Tcl_Panic("Wild GenericEvent; panic! (extension=%d,evtype=%d)",
      xgePtr->extension, xgePtr->evtype);


tkt_uuid: 2356057fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.6a4
resolution: Fixed
title: rotated text with underlined char: underline drawn wrongly
comment:
  sample:

  pack [canvas .c]
  set inr [.c create text 150 100 -text "foo" \
           -font {Helvetica 72} \
           -underline 1 ]
  set tm 100; set d 1
  set x {
     .c itemconf $inr -angle \
        [expr {[.c itemcget $inr -angle] + $d}]
     after $tm $x
  }
  eval $x


  The lower edge of the underline bar rotates 
  in the other direction relativ to the correctly
  placed upper edge. Seemingly just a sign-bug 
  on the angle.

  Also visible in this example: at non-rectangular
  positions, the fill is not entirely solid, but
  this may depend on my config (--enable-xft)


tkt_uuid: 2358543fffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: None
title: spinbox formatting as side effect
comment:
  If a spinbox is formatted with -format %02.0f, when we decrease with arrow we pass from 09 to 00 and when increasing with arrow, it is never possible to go above 09 if we start below 09. If already above 10 and increasing, it works.

  Below sample code works with Tk 8.4.19 but failed with Tk 8.5 (ActiveTcl 8.5.5, Debian Lenny 8.5.3, eTcl 8.5.2 or 8.5.5)

  package require Tk

  set versions ""
  lappend versions "Tcl: $tcl_patchLevel"
  lappend versions "Tk : $tk_patchLevel"
  label .l -text [join $versions \n]
  pack .l

  set second 15
  spinbox .sb -from 0 -to 59 \
    -format %02.0f -width 2 -textvariable second
  pack .sb


tkt_uuid: 2368195fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: None
resolution: None
title: paneconfigure not setting TCL_ERROR for unexisting window
comment:
  Hi,

  When calling paneconfigure for a panedwindow with a non existing window it doesn't set TCL_ERROR.

  Based on the version found here: http://tktoolkit.cvs.sourceforge.net/viewvc/tktoolkit/tk/generic/tkPanedWindow.c?revision=1.37&view=markup I see it doesn't check for tkwin being NULL (line 683) which it could then set TCL_ERROR and be happy since the error message was already set by Tk_NameToWindow.


tkt_uuid: 2378039fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: None
title: treeview custom layout problems
comment:
  I tried unsuccessfully to remove the border on a Treeview. I first tried copying the default layout and changing "-border 1" to "-border 0" but that appears to have no effect (only tested this on the mac).

  If I omit the Treeview.field element entirely, it seems that the Treeview.padding and/or the Treeview.textarea elements aren't properly expanding to fill the cavity. When I remove the field element I've left with one background color surrounding the listbox elements and another that fills up the empty space after the last element.


tkt_uuid: 2381555fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: None
resolution: Fixed
title: ttk::treeview - horizontal scrolling vs headers
comment:
  (Ref: http://bugs.activestate.com/show_bug.cgi?id=81181).

  If a multicolumn treeview widget is scrolled to the right, the rightmost headings are inactive.

  To replicate: run e.g. the "multicolumn list of countries" Tk demo; drag a column separator way off to the right (to force scrolling); scroll right; hover mouse over headings.


tkt_uuid: 2389878fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: ttk::frame doesn't maintain borderwidth spacing
comment:
  ttk::frame doesn't maintain borderwidth spacing when it packs children in, allowing them to draw over the border.


tkt_uuid: 2408101fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: None
title: font sizes limited to integer values
comment:
  I believe this bug applies to fonts on all platforms with antialiased fonts and is present in all current versions of Tk. In tk8.*/generic/tkFont.h, TkFontAttributes.size is an integer.  So tkFont's converting between pixels and point sizes is inaccurate.  Also, with modern Linux font support, the user can type in non-integer point sizes for fonts in the standard font choosers.

  For example, on Fedora 7 with gnome:

  $ gconftool-2 --get /desktop/gnome/interface/font_name
  Nimbus Sans L Condensed 11.5
  $ wish
  % tk scaling
  1.47246376812

  So is that a 16 pixel or 17 pixel high font?  What if it were 11?

  The request is that TkFontAttributes.size be changed to be a float.


tkt_uuid: 2413642fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: ttk::notebook has no -textvariable option
comment:
  ttk::notebook has no -textvariable option. This is really a bug. All other widgets containing text have this option, and without this option multi-language support cannot be provided (I think multi-language support is the most common use of option -textvariable).


tkt_uuid: 2415437fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 9 Immediate
foundin: obsolete: 8.6a3
resolution: Fixed
title: Tcl not in Tk's -rpath when installed to different -prefix
comment:
  Tk's -rpath does not include the Tcl library directory when Tcl and Tk are installed to separate -prefix directories. The attached patch corrected the problem for me.

  (This was formerly Tcl bug 2307398, which I closed because I think it should listed as a Tk bug.  See that bug for commentary.)


tkt_uuid: 2421792fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: None
title: Label with long text draws garbage
comment:
  Label with text exceeding certain limit draws text several times with different horizontal positions, resulting in garbage:

  label .lab -text [string repeat "Abc" 16000]
  pack .lab

  On my system, repeat count 6000 is OK and 7000 and higher draws garbage.

  Tested with 8.5.1 (latest tclkit I found for 32bit Linux) and 8.4.12.

  Looking through existing bug reports, the closest match I found was [ 547593 ] Error creating Label > 32k pixels , which was closed years ago.


tkt_uuid: 2431428fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 1 Zero
foundin: obsolete: 8.5.5
resolution: Fixed
title: core dump "malformed bucket chain in Tcl_DeleteHashEntry"
comment:
  Sometimes I get a core dump with the message "malformed bucket chain in Tcl_DeleteHashEntry" after destroying a toplevel window. This error is not reproducable. Here one backtrace:

  (gdb) where
  #0  0x40398741 in kill () from /lib/libc.so.6
  #1  0x40bf6771 in pthread_kill () from /lib/libpthread.so.0
  #2  0x40bf6a7b in raise () from /lib/libpthread.so.0
  #3  0x403984d4 in raise () from /lib/libc.so.6
  #4  0x40399a08 in abort () from /lib/libc.so.6
  #5  0x400e10f9 in Tcl_PanicVA () from /usr/local/lib/libtcl8.5.so
  #6  0x400e1120 in Tcl_Panic () from /usr/local/lib/libtcl8.5.so
  #7  0x400b90a1 in Tcl_DeleteHashEntry () from /usr/local/lib/libtcl8.5.so
  #8  0x40158de1 in Tk_FreeColor () from /usr/local/lib/libtk8.5.so
  #9  0x4014d748 in Tk_Free3DBorder () from /usr/local/lib/libtk8.5.so
  #10 0x4014d8fa in Tk_Free3DBorderFromObj () from /usr/local/lib/libtk8.5.so
  #11 0x401e3804 in Ttk_ClearCache () from /usr/local/lib/libtk8.5.so
  #12 0x401e3a4d in CacheWinEventHandler () from /usr/local/lib/libtk8.5.so
  #13 0x4015d772 in Tk_HandleEvent () from /usr/local/lib/libtk8.5.so
  #14 0x40178f25 in Tk_DestroyWindow () from /usr/local/lib/libtk8.5.so
  #15 0x40178bf6 in Tk_DestroyWindow () from /usr/local/lib/libtk8.5.so
  #16 0x40178bf6 in Tk_DestroyWindow () from /usr/local/lib/libtk8.5.so
  #17 0x402126f0 in TkWmProtocolEventProc () from /usr/local/lib/libtk8.5.so
  #18 0x4015dafc in Tk_HandleEvent () from /usr/local/lib/libtk8.5.so
  #19 0x4015dfaf in WindowEventProc () from /usr/local/lib/libtk8.5.so
  #20 0x400ddba6 in Tcl_ServiceEvent () from /usr/local/lib/libtcl8.5.so
  #21 0x400dde17 in Tcl_DoOneEvent () from /usr/local/lib/libtcl8.5.so
  #22 0x4015e3cd in Tk_MainLoop () from /usr/local/lib/libtk8.5.so
  #23 0x4016b560 in Tk_MainEx () from /usr/local/lib/libtk8.5.so
  #24 0x08075d89 in main (argc=2, argv=0xbffff754) at src/tkscid.cpp:403

  NOTE:
  I'm not using Tk_* functions except Tk_PhotoGetSize, Tk_PhotoGetImage, Tk_PhotoSetSize, Tk_PhotoPutBlock, Tk_CreatePhotoImageFormat, Tk_Main, Tk_Init.
  I'm not using Tcl_* functions except Tcl_AppendResult, Tcl_SetResult, Tcl_WrongNumArgs, Tcl_Get*FromObj, Tcl_Seek, Tcl_Read, Tcl_Eof, Tcl_PkgProvide, Tcl_ResetResult, Tcl_Eval, Tcl_CreateCommand.


tkt_uuid: 2431507fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: Fixed
title: purge interp->result from docs
comment:
  The Tk documentation remains littered
  with references to interp->result.
  Would be best to correct that in time
  for 8.6.0.


tkt_uuid: 2433781fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: Works For Me
title: button not centering image
comment:
  Try the following code:

  image create photo img -data { R0lGODdhCgAKAIABAMEsLP///ywAAAAACgAKAAACCISPqcvtD2MrADs= }
  button .b -borderwidth 1 -image img -relief solid
  pack .b

  As you can see, the image will not be centered. This makes it impossible to use button as a toolbar button.

  One possible solution: allow 2 values for -ipadx and -ipady; like -padx and -pady.


tkt_uuid: 2439015fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 3 Low
foundin: obsolete: 8.5.5
resolution: Later
title: overlapping rows in ttk::treeview
comment:
  I have a serious problem with ttk::treeview. Please try the following example:

  font configure TkDefaultFont -size 20
  ttk::treeview .tv -columns 1 -show {}
  foreach c {1 2 3} { .tv insert {} end -values {Text} }
  pack .tv

  The rows are overlapping. What I'm doing wrong?


tkt_uuid: 2441817fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Fixed
title: Fencepost error in [selection] man page sample script
comment:
  Due to the inclusive behavior of [string range], the selection handler sample script may return one character more than is requested.  The attached patch fixes the man page to always return the right number of characters.


tkt_uuid: 2441884fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Fixed
title: Incorrect indenting in [selection] man page
comment:
  The second paragraph describing [selection own] is not indented correctly.  The attached patch adds .RS and .RE macros to fix the indenting.  .RS and .RE must bracket all description paragraphs except for the one immediately following a .TP.


tkt_uuid: 2441988fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: Fixed
title: [selection handle] errors are silently discarded
comment:
  If the command registered by [selection handle] returns an error, the error is silently discarded.  The background error handler does not see it.


tkt_uuid: 2442314fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: None
resolution: None
title: Fontchooser - use message catalog for font style
comment:
  The Tcl implementation of fontchooser does not use the message catalog to display font styles.

  Furthermore the label for the Font size uses the same width as the listbox that contains the numbers of the font sizes. This may not be wide enough for some languages like german for example.


tkt_uuid: 2443069fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: None
title: Cannot replace [selection handle] command
comment:
  % package require Tk
  % proc report {string args} {return $string}
  % selection handle . {report 1}
  % selection own .
  % selection get
  1
  % selection get -type UTF8_STRING
  1
  % selection handle . {report 2}
  % selection get
  2
  % selection get -type UTF8_STRING
  1

  When replacing the [selection handle] command, the automatically generated UTF8_STRING handler is *not* updated, only the STRING handler.  The attached patch fixes Tk_CreateSelHandler() to update both.  It also updates the Tk_CreateSelHandler() documentation to describe the automatic UTF8_STRING handler creation, updating, and removal.  I tested the patch successfully on X11.

  Workaround 1: Use [selection handle -type UTF8_STRING] to explicitly set the UTF8_STRING handler in addition to the STRING handler.
  Workaround 2: Use [selection handle $win ""] to clear the handler before changing it.


tkt_uuid: 2472990fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: PNG: format handler doesn't do -gamma
comment:
  TIP#244 specifies that the PNG loader should handle a user-specified -gamma option in conjunction with the gAMA chunk. Currently this is not done. To fix.


tkt_uuid: 2473120fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: Error popup from tk_chooseDirectory: bad option "warning"
comment:
  Trying to navigate to a directory without the proper permissions (e.g.: /root as a regular user) with tk_chooseDirectory results in an error popup window:
  bad option "warning": must be -default, -detail, -icon, -message, -parent, -title, or -type
  bad option "warning": must be -default, -detail, -icon, -message, -parent, -title, or -type
      while executing
  "error "bad option \"$cmdsw\": must be [tclListValidFlags cmd]""
      (procedure "tclParseConfigSpec" line 36)
      invoked from within
  "tclParseConfigSpec $w $specs "" $args"
      (procedure "tk::MessageBox" line 24)
      invoked from within
  "tk::MessageBox {*}$args"
      (procedure "tk_messageBox" line 2)
      invoked from within
  "tk_messageBox -type ok -parent $w -message -icon warning  [mc "Cannot change to the directory \"%1\$s\".\nPermission denied." $file]"
      (procedure "::tk::dialog::file::ListInvoke" line 14)
      invoked from within
  "::tk::dialog::file::ListInvoke $w [list $filenameFragment]"
      (procedure "::tk::dialog::file::chooseDir::DblClick" line 8)
      invoked from within
  "::tk::dialog::file::chooseDir::DblClick .__tk_choosedir"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 $data(-command)"
      (procedure "IconList_Invoke" line 5)
      invoked from within
  "IconList_Invoke $w"
      (procedure "tk::IconList_Double1" line 5)
      invoked from within
  "tk::IconList_Double1 .__tk_choosedir.contents.icons 204 11"
      (command bound to event)


tkt_uuid: 2473895fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: TIP141 not yet implemented
comment:
  When -multiple is given, we still treat -initialfile as a single filename instead of as a list of names. At very least, should use first element.

  Notes: doing more requires deep hacking on Win, unknown for OSX, easy(ish) for Unix.


tkt_uuid: 2475855fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: None
resolution: Accepted
title: Stop grid/pack from handling the same master
comment:
  The attached patch is a way to give an error message
  when grid and pack are used in the same master.
  Currently this can lead to an application and possibly
  the desktop to hang. Such bugs are hard to debug.

  Is there any possibility for a working usage of
  propagating pack and grid in the same master?
  If there are, this could be a compatibility problem,
  but I cannot imagine such a usage.


tkt_uuid: 2479603fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: None
title: listbox aim is off after window gets moved. Mac OSX 10.3.9
comment:
  I'm using 8.5.6 on Mac OSX 10.3.9 on an old iMac G3. I have an app with a listbox, and I've noticed that the listbox reports (and highlights) the wrong entry after I have moved the app window. Initially, if I have not moved the window, the aim is correct, but afterwards the wrong entry is highlighted and reported. It looks as if there is a mapping between screen coordinates relative to the origin of the app window and absolute coordinates, and that mapping gets lost when the window is moved. I have a small test of this which I'm attaching.

  Uwe Hollerbach


tkt_uuid: 2479911fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.6b1
resolution: Works For Me
title: Failure to create PNG image correctly.
comment:
  The following script only seems to read half the attached tkchat48.png file. This file is correctly read by the Img extension. Tested using HEAD of 2009-01-01 00:00:00

  set file /opt/tkchat/tkchat.vfs/bin/tkchat48.png
  frame .f -background red
  image create photo tkchat -format png $file
  label .f.l -image tkchat
  pack .f.l -side top -anchor nw -padx 5 -pady 5
  pack .f -fill both -expand 1

  See http://www.patthoyts.tk/screenshots/tkpng.png  for a shot of what I saw


tkt_uuid: 2484749fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: Duplicate
title: Active tk_messageBox is displayed on top of other Windows pr
comment:
  When a Tcl/Tk program in Windows presents a tk_messageBox to the user and then, while the message box is active, the user switches to another open program, the message box remains on top of the Windows of the other program.

  Alexandre Ferrieux reports that the problem resides in line 2183 of tkWinDialog.c, where the MB_SYSTEMMODAL flag was used rather than the MB_APPLMODAL flag.

  Index: tkWinDialog.c
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/win/tkWinDialog.c,v
  retrieving revision 1.59
  diff -r1.59 tkWinDialog.c
  2183c2183
  <     flags |= icon | type | MB_SYSTEMMODAL;
  >     flags |= icon | type | MB_APPLMODAL; 


tkt_uuid: 2491235fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: None
resolution: Rejected
title: Dictionary's man page [dict] needs better examples
comment:
  I noticed that the man page is very clear about how to insert elements into the dictionary, but it's not clear enough about how to access a whole entry, or how to delete it. In the example, it's also only mentioned how to to insert elements into a nested array, whereas it would be also nice to learn how to insert a single element into an array.


tkt_uuid: 2492179fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 9 Immediate
foundin: obsolete: 8.6b1
resolution: Fixed
title: config.test failures - DoObjConfig
comment:
  Don't recall seeing these before:

  config.test


  ==== config-4.111 DoObjConfig - custom FAILED
  ==== Contents of test case:

      testobjconfig alltypes .foo -custom test

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0
  ---- errorInfo: unknown color name "test"
      (processing "-custom" option)
      invoked from within
  "testobjconfig alltypes .foo -custom test"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== config-4.111 FAILED



  ==== config-4.112 DoObjConfig - custom FAILED
  ==== Contents of test case:

      testobjconfig alltypes .foo -custom test
      .foo cget -custom

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0
  ---- errorInfo: unknown color name "test"
      (processing "-custom" option)
      invoked from within
  "testobjconfig alltypes .foo -custom test"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== config-4.112 FAILED



  ==== config-7.13 Tk_SetOptions - error in DoObjConfig with custom option FAILED
  ==== Contents of test case:

      .a configure -custom bad

  ---- Result was:
  unknown color name "bad"
  ---- Result should have been (exact matching):
  expected good value, got "BAD"
  ==== config-7.13 FAILED



  ==== config-7.14 Tk_SetOptions - error in DoObjConfig with custom option FAILED
  ==== Contents of test case:

      catch {.a configure -custom bad}
      return $errorInfo

  ---- Result was:
  unknown color name "bad"
      (processing "-custom" option)
      invoked from within
  ".a configure -custom bad"
  ---- Result should have been (exact matching):
  expected good value, got "BAD"
      (processing "-custom" option)
      invoked from within
  ".a configure -custom bad"
  ==== config-7.14 FAILED


tkt_uuid: 2495740fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: new test failure
comment:
  ==== button-5.5 ConfigureButton - image handling FAILED
  ==== Contents of test case:

      button .b -image image1
      image delete image1
      .b configure -image image2
      image names

  ---- Result was:
  image2 ::tk::dialog::error::image::stop
  ---- Result should have been (exact matching):
  image2
  ==== button-5.5 FAILED


tkt_uuid: 2496018fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 9 Immediate
foundin: obsolete: 8.5.5
resolution: Fixed
title: Tk needs config option to disable use of XScreenSaver ext.
comment:
  From John Stone johns@ks.uiuc.edu (developer of VMD).

  When developing applications that embed Tcl/Tk interpreters, it is desirable to reduce or restrict the number of dependencies the application has on various system-dependent shared libraries.  This is particularly the case for applications intended for end users that are not technically inclined or are otherwise unable to deal with missing shared libraries or mismatched library versions, etc.  Beginning with Tcl/Tk 8.5.x, it seems that the configure script now detects and enables the use of the XScreenSaver extension by default, and there does not appear to be a mechanism for disabling this behavior 
  (e.g. no option such as --disable-xscreensaver).
  Since not all host machines have the Xss shared libs installed and/or may not have a compatible version, it would be very helpful to add a new configure option to disable this feature at compile time.


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

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

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

     winPtr->mainPtr->tlFocusPtr->focusWinPtr

  and

     displayFocusPtr->focusWinPtr

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

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

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

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


tkt_uuid: 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: 2496329fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Fixed
title: Error in bind.test: bad keysym ":"
comment:
  tests/bind.test contains things like:

      event generate .t.f <Key-:>
      event generate .t.f <Key-+>
      event generate .t.f <Key-_>

  (found in bind-13.1, a few other places).  This fails with the error 'bad event type or keysym ":"'
  X keysyms consist of alphanumeric characters and underscores; see man keysyms(3tk).

  Relevant CVS log entries:

  | revision 1.24
  | date: 2008/11/23 00:47:25;  author: ferrieux;  state: Exp;  lines: +3 -3
  | Re-fixed QWERTY/AZERTY sensitivity of key event generation test (thx to Pat Thoyts)
  | ----------------------------
  | revision 1.23
  | date: 2008/11/22 23:45:54;  author: ferrieux;  state: Exp;  lines: +3 -3
  | Fixed QWERTY/AZERTY sensitivity of key event generation test

  No SF bug # listed, no ChangeLog entry, so no other details available.  I can't imagine that this test ever worked though.


tkt_uuid: 2496867fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: None
title: Img is broken on Windows Vista.
comment:
  I asked a friend of mine to test my program, Ikonikos Image Manager. What we noticed is that many images that open file here, on XP, will not open on Vista (he gets a corruption error reporting).

  You can get my program at: http://wiki.tcl.tk/22208

  The image is larger than 256kb, so I'll link you to my picasa web album.


tkt_uuid: 2501278fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 8
severity: Minor
foundin: current: 8.5.14
resolution: Fixed
title: ttk::scale keyboard binding problem + patch
comment:
  As documented in the ttk::scale man page, the widget supports a
  reversed scale where the -to value is less than the -from value.
  A usage example is the Windows taskbar pop-up volume slider -
  the top end of the scale is 100% and the bottom end of the scale
  is 0%.

  The ttk::scale keyboard bindings don't work with a reversed
  scale, as demonstrated in the attached example.  Pressing the
  up-arrow key moves the slider down, etc.

  The attached patch fixes the problem.  Its is for
  library/ttk/scale.tcl, CVS HEAD revision 1.2


tkt_uuid: 2502020fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: Out of Date
title: tk_getOpenFile
comment:
  the debug version of Tk (8.5.5 or 8.5.6) raises an error when invoking the command tk_getOpenFile

  In the file file tkfilefilter.c it is necessary to initialize the variable ostypeCount before its use:

  ostypeCount=0;


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.


tkt_uuid: 2507417fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: None
resolution: Accepted
title: Fix for image clipping on Windows menus
comment:
  Here is a relatively simple fix for the problems
  displaying images on Windows menus, when menu animation
  effects are turned on. See bugs #1329198 and #456299.

  In TkpDrawMenuEntry the contents for each menu entry are
  drawn to a compatible bitmap first.  The bitmap is then
  copied to the output menu.  This avoids the problems with
  clipping when drawing directly to an animated menu.  The
  draw to compatible bitmap plus copy doesn't appear to be
  a big deal, performance-wise.

  I have removed the previous work-around of 2006-09-21,
  which disabled animation for top-level menus with images.

  I attach updated versions of win/tkWinMenu.c for Tk 8.5.6
  and the current CVS HEAD revision 1.62

  The default setting is animated menus turned on in modern
  windows versions, making Tk apps look poor, so this is an
  important issue to address.


tkt_uuid: 2513104fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: None
resolution: Accepted
title: Fixes for Windows cursor hotspots
comment:
  In win/rc/cursor*.cur Tk includes an implementation of
  all of the standard X-windows cursors in Microsoft
  Windows format, which is very useful for cross-platform
  applications.

  Unfortunately the hotspot is wrong for many of these
  cursors, especially the various corner, side and angle
  indicators.  This is most apparent with graphics drawing
  applications which may use these cursors for object
  positioning, resizing, dragging etc. The action does not
  occur at exactly the spot apparently indicated by the
  cursor.  This can be rather off-putting.

  I have carefully and tediously reviewed all of the
  cursors, apart from some of of the most eccentric ones,
  and fixed the hotspots as necessary.  The modified .cur
  files are in the attached zip, to be applied to win/rc
  CVS in binary mode.


tkt_uuid: 2513186fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: None
title: ttk::entry xview sub-command forces use of update idletasks
comment:
  Before the ttk::entry xview sub-command is invoked, an
  update idletasks command must be executed in order to
  update the entry scrolling information, otherwise the
  sub-command doesn't work correctly e.g. the following
  script is supposed to set an entry field value and
  then scroll it to the end ready for editing:

      pack [ttk::entry .e -width 8]
      .e insert end abcdefghijklmnopqrstuvwxyz
      .e xview [.e index end]

  The field is left unscrolled, unless update idletasks
  is inserted before the xview sub-command.

  The use of update and update idletasks is generally
  discouraged on comp.lang.tcl, unless *absolutely
  necessary*, for well known reasons.  Recursively
  re-entering the event loop can lead to application
  logic problems, the widget may have been destroyed,
  etc.  I don't think that it is desirable for a core
  widget to force use of update idletasks just to
  function correctly.  It is particularly a nuisance if
  a whole form of entry fields is being set ready for
  modification.


  The following change to generic/ttk/ttkEntry.c will
  avoid the problem:

  static int EntryXViewCommand(
      Tcl_Interp *interp, int objc, Tcl_Obj *const objv[], void *recordPtr)
  {
      Entry *entryPtr = recordPtr;
      
      /* If caller has requested that the widget view is
       * adjusted to a given index "pathName xview index",
       * then ensure that the scroll info is up-to-date.
       */
       
      if (objc == 3) {
  EntryDoLayout(recordPtr);
      }

      return TtkScrollviewCommand(interp, objc, objv,
          entryPtr->entry.xscrollHandle);
  }


  Proc ttk::entry::See in library/ttk/entry.tcl can then
  also be modified to remove an update idletasks.


tkt_uuid: 2513753fffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: --with-tk is missing from SVN.
comment:
  Hello, I was trying to build tkImg for windows, and I noticed that it was trying to load the include files from a fixed path. I tried to run ./configure --with-tcl=PATH --with-tk=PATH, but --with-tk simply isn't supported by the current configuration file. 

  Mjanssen said I should file a bug report in the TCL irc channel, because this feature should be supported. According to his own words (in the tcl irc channel):

  "<ijchain> <mjanssen> Megabyte file a bug for the missing --with-tk option, the README refers to it"

  The lack of this option means that I'm having to do some black magic to get TkImg compiled within Windows (using MSYS + Mingw).


tkt_uuid: 2534237fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: None
title: Tk not linking correctly on netbsd
comment:
  NetBSD elf linker don't use /etc/ld.so.conf to find the shared libraries at runtime. As a consequence, the linker option -rpath must be used to hardcode the library search path into the binaries on this platform.
  The following patch address these issues.

  The reversed order of arguments for the X11_LIB_SWITCHES variables in Makefile.in is to allow the library path of the xft library appears in the rpath before the x11 one, as on this platform the xft library can be installed separatedly. If the x11 library path appears first, the xft delivered with the X system will be picked up instead of the choosed one (usually on /usr/pkg/lib).


tkt_uuid: 2538769fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: Control the way tags bleed and are edited in the text widget
comment:
  When using the text widget, it would be nice to have the option to control how tagged text will bleed or if tagged text is user-editable. 

  For instance, I would love to insert formatting code into the body of a text which is elided - but the problem here, is that the user experiences the cursor acting chaotically when he deletes or backspaces over one of the elided characters. It would be good to have the option of either the hidden format mark being silently deleted, without causing a hesitation of the text cursor... or having the format mark pushed back so it remains within the text.

  Also, it would be nice to control how and when the text tags bleed. I have a program, for instance, that highlights the matching curly-braces with different colors, to make tcl code easier to read. But the problem there is that when there are two braces right next to eachother, and you type between them, the text in the middle takes on the color and size of the colored braces. 

  - Laif


tkt_uuid: 2540465fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: Duplicate
title: Tk_MainWindow error message formatting nit
comment:
  If wish is called and DISPLAY is not set (or set incorrectly), Tk_MainWindow returns an error message that looks like this:

  Application initialization failed: this isn't a Tk applicationcouldn't connect to display "srv29:0.0"
  Error in startup script: this isn't a Tk applicationcouldn't connect to display "srv29:0.0"
      while executing
  "load /usr/tcl84/lib/tk8.4g/../libtk8.4g.so Tk"
      ("package ifneeded" script)
      invoked from within
  "package require Tk "
      (file "/ldatae/clearcase/upgrade7/MultiFig/n098/u10k/lib/MFigPGUI/main.tcl" line 2)
      invoked from within
  "source "$u10k/lib/MFigPGUI/main.tcl""
      (file "/cas/bin/sun4/mfigp" line 39)


  A colon at the end of "this isn't a Tk application" would make the error message slightly better.

  I wonder, as well, if the message shouldn't be "this application couldn't instantiate Tk:" ...


tkt_uuid: 2542828fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: None
resolution: Accepted
title: Windows native 'question_arrow' cursor
comment:
  On Windows, Tk uses an ugly built-in bitmap for the 'question_arrow' cursor. This while Windows actually has a native cursor for this: IDC_HELP.
  Attached is a small patch to support the IDC_HELP cursor.


tkt_uuid: 2543460fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.5.6
resolution: None
title: Enter/Leave cnv events not reported while mouse btn is down
comment:
  consider this little testcase:

  pack [canvas .c -width 300 -height 190 -background white]
  # two test items
  .c create rectangle 20 30 40 50 -tags red -fill red
  .c create rectangle 80 30 100 50 -tags black -fill black
  # text items for showing what's happening
  .c create text 20 90 -text {red: } -tags txt1 -anchor nw
  .c create text 20 120 -text {tags: } -tags txt2 -anchor nw
  # bind <Enter> and <Leave>
  .c bind red <Enter> {.c itemconfigure txt1 -text red:\ Enter}
  .c bind red <Leave> {.c itemconfigure txt1 -text red:\ Leave}
  # the workaround: (this fails too)
  bind .c <Motion> {.c itemconfigure txt2 -text tags:\ [.c gettags [.c find withtag current]]}
  # not really needed for this testcase:
  bind .c <ButtonPress> {.c configure -background red}
  bind .c <ButtonRelease> {.c configure -background white}


  item with 'red' tag is bound to <Enter> and <Leave> events.
  but it works only when the bouse button are not pressed.
  if you click in the white area and drag over the red item, it won't send the <Enter>/<Leave> events.

  in addition, an attempt to workaround this issue by using [.canvas find withtag current&&$myTag] would fail too, because tag 'current' is not updated while mouse button is down.

  I don't know if this is expected, or not.
  reading the manual of canvas I'd expect 'current' tag and <Enter>/<Leave> events to work in any condition.

  I'm not filing a bug about documentation though.
  I'd rather want those things working (perhaps enabled by some exotic [canvas] option), because a full workaround on this issue implies various nested loops, to track position and retrieve all the tags,  and match them, and other than awful, I think it could turn into a performance hog.

  Best regards


tkt_uuid: 2546087fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Tk console drops chars after \0
comment:
  The Tk console drops characters after a \0 character. Example:

  (MJanssen) 3 % set a "abcd\0efgh"
  abcd
  (MJanssen) 4 % puts $a
  abcd
  (MJanssen) 5 % string length $a
  9
  (MJanssen) 6 % 

  inserting the same string in a text widget will show all the characters.

  Tk version 8.5.4


tkt_uuid: 2546779fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.5.2
resolution: Fixed
title: ttk::notebook getting an error when disabling tabs.
comment:
  When i'am disabling all displayed tabs of a notebook widget i get the following error:

  bad window path name ""
  bad window path name ""
      while executing
  "winfo viewable $w"
      (procedure "ttk::takesFocus" line 3)
      invoked from within
  "ttk::takesFocus $w"
      (procedure "ttk::focusFirst" line 2)
      invoked from within
  "ttk::focusFirst [$w select]"
      (procedure "ActivateTab" line 7)
      invoked from within
  "ActivateTab $w $index"
      (procedure "ttk::notebook::Press" line 4)
      invoked from within
  "ttk::notebook::Press .nb 32 12 "
      (command bound to event)

  I was using this code:

  ttk::notebook .nb
  ttk::frame .nb.1
  ttk::frame .nb.2
  grid .nb -in . -row 0 -column 0
  .nb add .nb.1 -text "Test"
  .nb add .nb.2 -text "Test2"
  .nb tab .nb.1 -state disabled
  .nb tab .nb.2 -state disabled

  If one of the tabs stays enabled the error doesn't appear.:

  ttk::notebook .nb
  ttk::frame .nb.1
  ttk::frame .nb.2
  grid .nb -in . -row 0 -column 0
  .nb add .nb.1 -text "Test"
  .nb add .nb.2 -text "Test2"
  .nb tab .nb.1 -state disabled

  Best regards


tkt_uuid: 2548661fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 9 Immediate
foundin: obsolete: 8.6b1
resolution: Fixed
title: Crash in GetFontFamilyName (tkMacOSXFont.c) + patch
comment:
  8.6a1, but code is same as now and long before.

  Some of my users are getting a crash in CFStringGetCString invoked
  from GetFontFamilyName (tkMacOSXFont.c).  (There is a comment above
  these lines about a possible crash.)  I cannot replicate it, and the
  circumstances are strange: when MS Word 2008 is running, application
  startup will crash, otherwise not.  My rough guess is that additional
  fonts or font manager are made available when this app is running,
  with some characteristics that trigger the crash.

  I am attaching a user-generated trace.  Looking at the code in
  GetFontFamilyName, several things seem suspicious.  I'm not a
  Carbon programmer so I am not sure though.  I have made a patch
  that addresses the most obvious ones and am sending it off for
  user testing.

  If someone who knows more about Carbon font handling and data types
  could take a look, that would be great.

  Things That Seem Strange But I'm Not A Carbon Programmer:

  1) FontFamilyEnumCallback:
       err = ChkErr(GetFontFamilyName, family, name, sizeof(name));
      !!! converts ATSFontFamilyRef (UInt32) to FMFontFamily (SInt16)
          lossy conversion, and anyway are semantics the same?
          in my trace, this conversion is lossy: 4294961600 -> -5696

  2) GetFontFamilyName:
      encoding = kTextEncodingMacRoman;
     !!! This shouldn't be needed unless next line fails, in which case the rest
         of the function should be aborted.

      ChkErr(FMGetFontFamilyTextEncoding, fontFamily, &encoding);
     !!! This function is deprecated as of 10.4, though no replacement advice
         seems to be given.

      nameencoding = encoding;
     !!! encoding is UInt32 while nameencoding is SInt16
         furthermore are the semantics the same?

      ChkErr(RevertTextEncodingToScriptInfo, encoding, &nameencoding, NULL,
      NULL);
     !!! nameencoding is ScriptCode (SInt16), CFStringEncoding (UInt32) expected

      CFStringGetCString(
      cfString, name, numBytes, kCFStringEncodingUTF8);
     !!! cfString returned is not checked for NULL after previous call


  Stack Trace (some proprietary info removed):

  Program received signal EXC_BAD_ACCESS, Could not access memory.
  Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
  0x962de133 in CFStringGetCString ()
  (gdb) bt
  #0  0x962de133 in CFStringGetCString ()
  #1  0x0b106c4d in GetFontFamilyName (fontFamily=-5696, name=0xbffff0a4 "", numBytes=260) at ../macosx/tkMacOSXFont.c:2136
  #2  0x0b1069b4 in FontFamilyEnumCallback (family=4294961600, refCon=0x0) at ../macosx/tkMacOSXFont.c:2064
  #3  0x9031fe98 in ATSFontFamilyApplyFunction ()
  #4  0x0b10680c in InitFontFamilies () at ../macosx/tkMacOSXFont.c:2018
  #5  0x0b10477b in TkpFontPkgInit (mainPtr=0xf2d10) at ../macosx/tkMacOSXFont.c:288
  #6  0x0b019c6f in TkFontPkgInit (mainPtr=0xf2d10) at ../generic/tkFont.c:389
  #7  0x0b03d646 in TkCreateMainWindow (interp=0xd6c10, screenName=0xb132b54 "", baseName=0xbffff6df "Foo") at ../generic/tkWindow.c:907
  #8  0x0b04b63b in CreateFrame (clientData=0x0, interp=0xd6c10, objc=4, objv=0x30a150, type=TYPE_TOPLEVEL, appName=0xbffff6df "Foo") at ../generic/tkFrame.c:555
  #9  0x0b04b011 in TkCreateFrame (clientData=0x0, interp=0xd6c10, argc=4, argv=0xbffff7a0, toplevel=1, appName=0xbffff6df "Foo") at ../generic/tkFrame.c:437
  #10 0x0b0402e6 in Initialize (interp=0xd6c10) at ../generic/tkWindow.c:3160
  #11 0x0b03fb33 in Tk_Init (interp=0xd6c10) at ../generic/tkWindow.c:2852
  #12 0x0000322b in Tk_myMain (argc=1, argv=0xbffff9fc, myappInitProc=0x33e4 <Tcl_UnixAppInit>) at ../src/myMain.c:160
  #13 0x00003030 in main (argc=1, argv=0xbffff9fc) at ../src/myMain.c:120


  Patch against trunk (though I'm using 8.6a1):

  Index: macosx/tkMacOSXFont.c
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/macosx/tkMacOSXFont.c,v
  retrieving revision 1.43
  diff -u -p -r1.43 tkMacOSXFont.c
  --- macosx/tkMacOSXFont.c10 Dec 2008 05:02:52 -00001.43
  +++ macosx/tkMacOSXFont.c30 Jan 2009 10:32:49 -0000
  @@ -2194,10 +2194,16 @@ GetFontFamilyName(
        */
   
       encoding = kTextEncodingMacRoman;
  -    ChkErr(FMGetFontFamilyTextEncoding, fontFamily, &encoding);
  +    err = ChkErr(FMGetFontFamilyTextEncoding, fontFamily, &encoding);
  +    if (err != noErr) {
  +        return err;
  +    }
       nameencoding = encoding;
  -    ChkErr(RevertTextEncodingToScriptInfo, encoding, &nameencoding, NULL,
  +    err = ChkErr(RevertTextEncodingToScriptInfo, encoding, &nameencoding, NULL,
       NULL);
  +    if (err != noErr) {
  +        return err;
  +    }
   
       /*
        * Note: We could use Tcl facilities to do the re-encoding here. We'd
  @@ -2211,6 +2217,9 @@ GetFontFamilyName(
   
       cfString = CFStringCreateWithPascalStringNoCopy(
       NULL, nativeName, nameencoding, kCFAllocatorNull);
  +    if (cfString == NULL) {
  +        return noErr-1;  /* I have no idea here, just make it not noErr */
  +    }
       CFStringGetCString(
       cfString, name, numBytes, kCFStringEncodingUTF8);
       CFRelease(cfString);


tkt_uuid: 2548722fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.5.6
resolution: Works For Me
title: tk_popup incorrectly placement on Windows
comment:
  This bug has been marked as closed in the past but it is still there. At least in Tk 8.5.4

  commenting the block specific to windows in proc "::tk::PostOverPoint", file menu.tcl seems to fix the problem.

   


tkt_uuid: 2553155fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 8
foundin: obsolete: 8.6b1
resolution: Wont Fix
title: Dead space in torn-off menus
comment:
  In MS-Windows, torn-off menu windows can be wider than the original menu, apparently due to an absolute minimum toplevel width.  When this happens, the extra space at the right of the menu does not respond to mouse movement or clicking.  Yet it lights up when the mouse is moved over the left-hand portion of the menu, giving very counter-intuitive look-and-feel.

  I noticed this while playing with spinbox menubutton (http://wiki.tcl.tk/9648).  Tear off either of the menus and try to use them.  I'm sure you'll see what I mean.


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

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

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

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

  Albrecht Mucha 
  a.mucha<at>NOSPAMmdtec.de


tkt_uuid: 2588919fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: None
resolution: Fixed
title: Replace hideous black/white image of JO in demo
comment:
  Now that Tk has PNG in the core, isn't it time to replace the image of J. Ousterhout in the demo with something that doesn't scream "1992"?  This page has a picture of him:

  http://home.pacbell.net/ouster/

  If we want people to realize that Tk can be good looking, that image in the first thing that people are likely to click on in the demo can't be leaving a good impression.  Also, the text ought to be updated to 'creator' rather than 'proprietor'.


tkt_uuid: 2593177fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 9 Immediate
foundin: obsolete: 8.5.6
resolution: Fixed
title: segfault in XGetICValues
comment:
  The execution of wish or any dependent programme for example gitk ends up with segfault. The funny thing is that it was reproduced only on x86_64 on Gnome and it was running okay on KDE (at least 8.5.5 was running just fine).

  I'm attaching original report:
  ==12781== Memcheck, a memory error detector.
  ==12781== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
  ==12781== Using LibVEX rev 1804, a library for dynamic binary translation.
  ==12781== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
  ==12781== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
  ==12781== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
  ==12781== For more details, rerun with: -v
  ==12781== 
  ==12781== Invalid read of size 8
  ==12781==    at 0x3311052226: XGetICValues (ICWrap.c:292)
  ==12781==    by 0x3311C44188: Tk_HandleEvent (tkEvent.c:365)
  ==12781==    by 0x3311C60125: TkDoConfigureNotify (tkWindow.c:2216)
  ==12781==    by 0x3311CFA6AF: TkUnixSetMenubar (tkUnixWm.c:6884)
  ==12781==    by 0x3311C71899: TkSetWindowMenuBar (tkMenu.c:3228)
  ==12781==    by 0x3311C6A14B: ConfigureFrame (tkFrame.c:951)
  ==12781==    by 0x3311C6A4AB: FrameWidgetObjCmd (tkFrame.c:798)
  ==12781==    by 0x3310C2FDCA: TclEvalObjvInternal (tclBasic.c:3690)
  ==12781==    by 0x3310C78855: TclExecuteByteCode (tclExecute.c:2340)
  ==12781==    by 0x3310CBA385: TclObjInterpProcCore (tclProc.c:1748)
  ==12781==    by 0x3310C2FDCA: TclEvalObjvInternal (tclBasic.c:3690)
  ==12781==    by 0x3310C30813: TclEvalEx (tclBasic.c:4338)
  ==12781==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
  ==12781== 
  ==12781== Process terminating with default action of signal 11 (SIGSEGV)
  ==12781==  Access not within mapped region at address 0x8
  ==12781==    at 0x3311052226: XGetICValues (ICWrap.c:292)
  ==12781==    by 0x3311C44188: Tk_HandleEvent (tkEvent.c:365)
  ==12781==    by 0x3311C60125: TkDoConfigureNotify (tkWindow.c:2216)
  ==12781==    by 0x3311CFA6AF: TkUnixSetMenubar (tkUnixWm.c:6884)
  ==12781==    by 0x3311C71899: TkSetWindowMenuBar (tkMenu.c:3228)
  ==12781==    by 0x3311C6A14B: ConfigureFrame (tkFrame.c:951)
  ==12781==    by 0x3311C6A4AB: FrameWidgetObjCmd (tkFrame.c:798)
  ==12781==    by 0x3310C2FDCA: TclEvalObjvInternal (tclBasic.c:3690)
  ==12781==    by 0x3310C78855: TclExecuteByteCode (tclExecute.c:2340)
  ==12781==    by 0x3310CBA385: TclObjInterpProcCore (tclProc.c:1748)
  ==12781==    by 0x3310C2FDCA: TclEvalObjvInternal (tclBasic.c:3690)
  ==12781==    by 0x3310C30813: TclEvalEx (tclBasic.c:4338)
  ==12781== 
  ==12781== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 1)
  ==12781== malloc/free: in use at exit: 2,890,427 bytes in 24,151 blocks.
  ==12781== malloc/free: 92,394 allocs, 68,243 frees, 12,886,543 bytes allocated.
  ==12781== For counts of detected errors, rerun with: -v
  ==12781== searching for pointers to 24,151 not-freed blocks.
  ==12781== checked 2,556,632 bytes.
  ==12781== 
  ==12781== LEAK SUMMARY:
  ==12781==    definitely lost: 13,985 bytes in 195 blocks.
  ==12781==      possibly lost: 0 bytes in 0 blocks.
  ==12781==    still reachable: 2,876,442 bytes in 23,956 blocks.
  ==12781==         suppressed: 0 bytes in 0 blocks.
  ==12781== Rerun with --leak-check=full to see details of leaked memory.
  Segmentation fault

  $ rpm -q gitk tk tcl libX11
  gitk-1.6.1-2.fc11.x86_64
  tk-8.5.5-4.fc11.x86_64
  tcl-8.5.5-1.fc11.x86_64
  libX11-1.1.99.2-2.fc11.x86_64


tkt_uuid: 2604420fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 6
foundin: obsolete: 8.5.6
resolution: Fixed
title: text lost (?) in ttk_intro manpage
comment:
  The text in the OVERVIEW section of the ttk_intro(n) manpage is cut off in the middle of a sentence.
  (Not fixed in current CVS; same with online html version.)


tkt_uuid: 2609839fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: None
title: tk tutorial similar in nature to the tcl tutorial
comment:
  I would like to request that the Tk experts of the community consider working together to create a Tk tutorial of similar nature to that of the tcl tutorial available at http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html . This is something that would be very useful.


tkt_uuid: 2645457fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 48. Geometry Management
priority: 8
foundin: obsolete: 8.5.6
resolution: Fixed
title: Crash closing application during geometry management
comment:
  This has been originally raised as a gitk crash bug. On startup gitk creates a bunch of windows, waits for the main window to become visible and then launches a subprocess on a pipe to query git information. If the user closes the application while gitk is still reading this subprocess then the application will crash.
  I have reproduced this on Windows using tcl/tk 8.5.6. The crash is always in TkWmMapWindow and in a debug build the wmPtr pointer is marked up with 0xdddddddd which means it has been freed already. Tk_MapWindow has a check for wmPtr->window == None but wmPtr itself is invalid here.
  I believe this is some kind of race between Tk deletion and the map window code that is shown up here because the application is busy reading from this pipe.


tkt_uuid: 2647037fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Crash in event test on OS X 10.5.6
comment:
  make test with fresh cvs checkout  crashes in one of the event tests.

  Fresh build, configured with:
  ../macosx/configure --enable-threads --enable-dtrace --enable-framework --with-tcl=../../tcl/build --enable-aqua --enable-symbols --disable-shared

  the stacktrace is probably pretty useless, as all of the addresses seem to contain only garbage (tried the interp pointers, winPtr, objv, mainWin, all total junk, looks like trashed memory).

  program received signal EXC_BAD_ACCESS, Could not access memory.
  Reason: KERN_INVALID_ADDRESS at address: 0x6574617a
  0x0001c85c in Tk_HandleEvent (eventPtr=0xbfffe8e0) at /Users/schlenk/xcode/tk/macosx/../generic/tkEvent.c:1324
  1324interp = winPtr->mainPtr->interp;

  (gdb) bt
  #0  0x0001c85c in Tk_HandleEvent (eventPtr=0xbfffe8e0) at /Users/schlenk/xcode/tk/macosx/../generic/tkEvent.c:1324
  #1  0x0000f14a in HandleEventGenerate (interp=0x1e1c10, mainWin=0x315010, objc=2, objv=0x7b4df4) at /Users/schlenk/xcode/tk/macosx/../generic/tkBind.c:3796
  #2  0x0000d758 in Tk_EventObjCmd (clientData=0x315010, interp=0x1e1c10, objc=4, objv=0x7b4dec) at /Users/schlenk/xcode/tk/macosx/../generic/tkBind.c:2765
  #3  0x0a00ea00 in NRRunObjProc ()
  #4  0x0a00e86d in TclNRRunCallbacks ()
  #5  0x0a052b3d in TclExecuteByteCode ()
  #6  0x0a00e86d in TclNRRunCallbacks ()
  #7  0x0a013626 in TclEvalEx ()
  #8  0x0a013985 in Tcl_EvalEx ()
  #9  0x0a052064 in TclExecuteByteCode ()
  #10 0x0a00e86d in TclNRRunCallbacks ()
  #11 0x0a013626 in TclEvalEx ()
  #12 0x0a013985 in Tcl_EvalEx ()
  #13 0x0a079d4e in Tcl_FSEvalFileEx ()
  #14 0x0002e9d2 in Tk_MainEx (argc=-1, argv=0xbffff7f8, appInitProc=0x4187 <Tcl_AppInit>, interp=0x1e1c10) at /Users/schlenk/xcode/tk/macosx/../generic/tkMain.c:270
  #15 0x00004180 in main (argc=6, argv=0xbffff7e0) at /Users/schlenk/xcode/tk/macosx/../unix/tkAppInit.c:68

  Running only the event.test file via:
  TESTFLAGS="-singleproc 1 -file event.test" make test 
  does not segfault.


tkt_uuid: 2658821fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.6
resolution: Out of Date
title: tk_getOpenFile uses uninitialized memory
comment:
  On the Windows build (Windows Server 2003, VS 2005), a call to tk_getOpenFile causes an uninitialized variable to be read. In the debug build, this causes a Run-Time Check Failure dialog for each file type pattern. My call to tk_getOpenFile looks like this:

  tk_getOpenFile -parent . -title "Select DAT File" -filetypes { { {DAT Files} {.dat} } { {All Files} {*} } }

  The runtime error occurs in AddClause() in tkfilefilter.c on this line:

  if (ostypeCount > 0 && ostypeList != NULL) {

  I traced through the execution of AddClause() and ostypeCount does not get set anywhere using the Tk code above. I believe simply initializing ostypeCount in the declaration will solve the problem and ensure correct behavior. Changing:

  int globCount, ostypeCount, i, code = TCL_OK;

  to:

  int globCount, ostypeCount = 0, i, code = TCL_OK;

  should solve the problem.

  This is likely an issue on other platforms as well - just not noticed.


tkt_uuid: 2671711fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: None
resolution: Rejected
title: KDE openfiledialog bug
comment:
  When openfiledialog is launched in KDE, it will launch the KDE openfiledialog, and will let you browse dirs and select files. BUT, if dir's name contains special characters like "`" it wont let you open the dir. Example:

  "DirName1" > will let you open the folder and select file(s).

  "DirNáme1" > WONT let you open the folder.


tkt_uuid: 2677890fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5.7
resolution: Fixed
title: Text widgets multi-scrolling problem
comment:
  Hi,

  When running the attached code (tts.tcl), at first both text widget scroll in sync. Now click the Test button, which will re-create the text and scrollbar widgets 100 times. When complete, try scrolling again, the text widgets are no longer in sync. Now try scrolling all the way down, notice how sometimes the slider's size changes while scrolling. When at the bottom, scrolling is in sync again.

  Kind regards,

  Jos.


tkt_uuid: 2687966fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 9 Immediate
foundin: obsolete: 8.5.6
resolution: None
title: wish8.5 hangs up in tkcvs and nVidia driver. wish8.4 working
comment:
  Reproduction
  ==============================================
  While working with tkcvs (8.1-1) that runs wish8.5, wish8.5 hangs up while on non-free nVidia driver.
  Just open tkcvs, move mouse to browser window and point any file. It hangs up immidiatelly.

  IMPORTANT: wish8.4 works perfectly with above tkcvs.

  wish8.5 works correctly with above tkcvs while on nv (nvidia open xorg drivers).

  Attachements:
  =================
  1. strace_wish8.4_ok.txt: strace tkcvs good case 
  2. strace_wish8.5_failed.txt: strace tkcvs bad case

  Configuration
  ================
  Linux ryx 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux

  Graphics: nVidia Corporation NV17 [GeForce4 420 Go] (rev a3)


tkt_uuid: 2710771fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.6
resolution: Works For Me
title: Can't select on disabled text widget on Aqua
comment:
  When a text widget is disabled and it doesn't has the focus its content can't be selected.

  Also, clicking inside the disabled widget doesn't give the focus to it, even with takefocus enabled.

  You can test both with the the script.


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

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

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

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

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

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

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

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


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

  Regards
  Michal


tkt_uuid: 2725308fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: Option to exclude hidden unix files
comment:
  Add an -excludehidden option (or something equivalent) to the tk_getOpenFile and tk_getSaveFile dialogs, so that files whose names begin with "." are excluded from the displayed list of files.  If the option can be implemented in a more general way that works on all platforms (i.e., -exclude pattern), that's great.

  This would prevent the dialogs from displaying the myriad of hidden directories that tend to infest a user's home directory under Unix/Linux, unless of course they were desired.


tkt_uuid: 2727476fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 8
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: [tk fontchooser] displays a wrong-sized dialog
comment:
  The new font dialog pops with a wrong size, too narrow in width so the size column is almost no visible, and too tall, so it has extra space at the bottom. The dialog is resizable (should it be?) but the resize doesn't survive to the next invocation, and it displays incorrectly again.


tkt_uuid: 2739360fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 9 Immediate
foundin: None
resolution: Accepted
title: improved icons for unix file dialogs
comment:
  This patch adds png icons to the unix file dialogs in the same way it's already done for tk_messageBox.
  The source of the icons is the same (http://tango.freedesktop.org/Tango_Desktop_Project , version 0.8.90) and the COPYING file says "The icons in this repository are herefore released into the Public Domain." .
  The only custom icon is the "updir" image, which is simply a composite of the actions/go-up.png and places/folder.png stock icons.


tkt_uuid: 2745650fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Works For Me
title: Quit menu cannot be overridden
comment:
  The standard Quit menu item that appears in the application menu of Aqua Tcl/Tk applications on MacOS X appears to be hard-wired to do something (stop the mainloop?). This presents a real problem when the application needs special behavior to quit.

  My specific problem is that I have a Python/Tkinter application that uses the Twisted networking library. Twisted takes over the tcl/tk event loop in a way that is transparent to tcl/tk, but a nasty side effect is that the Quit menu item has absolutely no effect!!! If I could bind to something to catch the menu item it would be fine, but I've not figured out a binding that works. The root window is not closed, so catching destroy from the window manager is not an option. 

  Please offer some way to modify the behavior of the Quit menu item for MacOS X Aqua Tcl/Tk applications. Or some way to hide that menu item so I can add my own.

  (Note: the problem does not occur on unix and Windows because they don't automatically add a Quit menu item. I have to set my own so I can make it do whatever I like).


tkt_uuid: 2748171fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Fixed
title: fail to create pixmap adding image to canvas
comment:
  On Windows, Adding many images about 400+ to canvas (depending on image size?) causes fatal Tk error 
  "Fail to create pixmap with Tk_GetPixmap in ImgPhotoInstanceSetSize". Simply allocating a like number of images (or even many more) does not cause the error.  This issue exists in all tested versions of Tcl/Tk 8.4.x, 8.5.x, 8.6b1.1

  A demo script with GUI and sample image is attached.

  Possibly (probably?) relevant history:

  G. Howlett on Windows GID object management in same context:
  http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/8526d7d05b33701d/3858f4ce5283b311?hl=en&lnk=gst&q=pixmap+fail#3858f4ce5283b311

  Georgios Petasis has issues in 2004:
  http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/9e446aaf5862d578/dd65b1eb988c7717?hl=en&lnk=gst&q=pixmap+fail#dd65b1eb988c7717

  Possibly related:
  http://objectmix.com/tcl/364908-windows-memory-leak-weird.html


tkt_uuid: 2750849fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: bind-8.2 fails
comment:
  ==== bind-8.2 TkCreateBindingProcedure: new binding FAILED
  ==== Contents of test case:

      catch {destroy .b.f}
      frame .b.f
      testcbind .b.f <1> "lappend x 1" "lappend x bye.1"
      set x {}
      event gen .b.f <1>
      destroy .b.f
      set x

  ---- Result was:
  1 bye.1
  ---- Result should have been (exact matching):
  bye.1
  ==== bind-8.2 FAILED


  This is a regression since Tk 8.5.6, and likely
  more recent than that.


tkt_uuid: 2759119fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: failed conversions to [tailcall] use
comment:
  Last two commits to tk.tcl broke the HEAD.

  Example test failure:

  ==== filebox-3.5-0 tk_getOpenFile command FAILED
  ==== Contents of test case:

              catch {unset tv}
              catch {unset typeName}
              ToPressButton $parent ok
              if {[info exists tv]} {
              } else {
              }
              set choice [tk_getOpenFile -title "Press Ok"  -filetypes $filters($x) -parent $parent  -initialfile $fileName -initialdir $fileDir  -typevariable tv]
              if {[info exists tv]} {
                  regexp {^(.*) \(.*\)$} $tv dummy typeName
              } else {
                  set typeName "-unset-"
              }
              set typeName

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad level "2"
      while executing
  "uplevel 2 [list info exists $data(-typevariable)]"
      (procedure "::tk::dialog::file::" line 75)
      invoked from within
  "::tk::dialog::file:: open -title {Press Ok} -filetypes {
          {"Text files"           {.txt .doc}     }
          {"Text files"           {}              TEXT}
          {"Tcl Scripts"          {.tcl}          TEXT}
          {"C S..."
      invoked from within
  "tk_getOpenFile -title "Press Ok"  -filetypes $filters($x) -parent $parent  -initialfile $fileName -initialdir $fileDir  -typevariable tv"
      ("uplevel" body line 8)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: TCL VALUE LEVEL
  ==== filebox-3.5-0 FAILED


  Appears that conversions of

      return [foo]

  to

      tailcall foo

  failed to account for hardcoded level values
  in [up*] commands in "foo".

  FWIW, I think this is a demonstration that
  any values besides #0, 0, or 1 for the level
  argument to [up*] are just bugs waiting
  to happen.


tkt_uuid: 2763385fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.6
resolution: Invalid
title: segmentation fault in DisplayText
comment:
  Hi,
  this is a weird Tk bug that I'm experiencing with tcl/tk 8.5.6. I don't know exactly how to reproduce, I'm testing video conferencing in aMSN and I keep getting this when I click on the call button (happens maybe once per 15 tries). 
  I have the core file saved on my disk, you can ping me over IRC (KaKaRoTo) if you need it.. I don't want to attach it, it's 175MB...
  It looks like DisplayText is called with some invalid data on the "update idletasks"...
  Here's the bt: 
  #0  0xb7fef975 in DisplayText (clientData=0xbf49ab0) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkTextDisp.c:4020
  4020                if ((dlPtr2->flags & OLD_Y_INVALID)
  (gdb) bt full
  #0  0xb7fef975 in DisplayText (clientData=0xbf49ab0) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkTextDisp.c:4020
          dlPtr2 = (DLine *) 0x30207473
          y = 1769349359
          oldY = 211
          offset = 973519755
          height = 1634872696
          damageRgn = (TkRegion) 0xb48e44e8
          textPtr = (TkText *) 0xbf49ab0
          dInfoPtr = (TextDInfo *) 0xc018d88
          dlPtr = (DLine *) 0xb4cb90ef
          prevPtr = (DLine *) 0x0
          pixmap = 3086096392
          maxHeight = -1078323096
          borders = -1208870904
          bottomY = 0
          interp = (Tcl_Interp *) 0xbf31180
  #1  0xb7eed398 in TclServiceIdle () from /usr/lib/libtcl8.5.so.0
  No symbol table info available.
  #2  0xb7ecea81 in Tcl_DoOneEvent () from /usr/lib/libtcl8.5.so.0
  No symbol table info available.
  #3  0xb7f4e436 in Tk_UpdateObjCmd (clientData=0x9903d00, interp=0x98dd7c0, objc=2, objv=0x9a3b834) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkCmds.c:1108
          flags = 32
          index = 0
          dispPtr = (TkDisplay *) 0x9a3b790
          updateOptions = {0xb80468b5 "idletasks", 0x0}
  #4  0xb7e4d881 in ?? () from /usr/lib/libtcl8.5.so.0



  I also had another similar one (but I lost the core file, sorry), here's its stack trace :
  Program terminated with signal 11, Segmentation fault.
  #0  0xb7f198ce in DisplayText (clientData=0xc2cd830) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkTextDisp.c:4001
  4001            if ((dlPtr->flags & OLD_Y_INVALID)
  (gdb) bt full
  #0  0xb7f198ce in DisplayText (clientData=0xc2cd830) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkTextDisp.c:4001
          dlPtr2 = (DLine *) 0x0
          y = 1
          oldY = 211
          offset = -210
          height = 135
          damageRgn = (TkRegion) 0xb23b8f30
          textPtr = (TkText *) 0xc2cd830
          dInfoPtr = (TextDInfo *) 0xc37e5c8
          dlPtr = (DLine *) 0x2030ef00
          prevPtr = (DLine *) 0x0
          pixmap = 65036849
          maxHeight = 18
          borders = -1209747448
          bottomY = 0
          interp = (Tcl_Interp *) 0xc156c40
  #1  0xb7e17398 in TclServiceIdle () from /usr/lib/libtcl8.5.so.0
  No symbol table info available.
  #2  0xb7df8a81 in Tcl_DoOneEvent () from /usr/lib/libtcl8.5.so.0
  No symbol table info available.
  #3  0xb7e78436 in Tk_UpdateObjCmd (clientData=0x9c78d00, interp=0x9c527c0, objc=2, objv=0x9db0644) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkCmds.c:1108
          flags = 32
          index = 0
          dispPtr = (TkDisplay *) 0x9db05a0
          updateOptions = {0xb7f708b5 "idletasks", 0x0}


tkt_uuid: 2764263fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 86. Test Tools
priority: 2
foundin: None
resolution: Fixed
title: Stray @ in Makefile.in test target.
comment:
  There is a single @ in the test target.

  test: test-classic test-ttk
         @


  After running the tests, OpenBSD's make stops with:
  : not found
  *** Error code 1

  Attached patch against core-8-5-branch removes the @.


tkt_uuid: 2764272fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Accepted
title: Adjustable demo install location.
comment:
  Allow demos to be installed anywhere with overridable Makefile variable DEMO_INSTALL_DIR, defaults to current settings.


tkt_uuid: 2768945fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 26. Conversions from String
priority: 7 High
foundin: obsolete: 8.5.6
resolution: Fixed
title: Unresolved External Symbols (8.5.6)
comment:
  Building our own GUI software on Windows against 8.5.6 release, I came across the error of
  "Unresolved External Symbols" and there are the symbols that are missing from 8.5.6 (they are there inside tk84.dll)

  TkStatePrintProc, TkStateParseProc, TkCanvasDashPrintProc, TkCanvasDashParseProc, TkOffsetPrintProc, TkOffsetParseProc, TkPixelPrintProc, TkPixelParseProc


tkt_uuid: 2777019fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 8
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: bad anchor on postscript rotated text
comment:
  The (new) rotated text on canvas respect the -anchor option on display, but the postscript output is always rotated from the nw corner.

  This sample script shows the (incorrect) behaviour:
  ===================================

  package require Tk 8.6b1.1
  canvas .c -bg white -width 400 -height 400
  pack .c

  for {set i 1} {$i <= 3} {incr i} {
      set y [expr {$i * 100}]
      .c create line 0 $y 400 $y
      set x [expr {$i * 100}]
      .c create line $x 0 $x 400
  }

  foreach anchor {nw n ne w c e sw s se} \
          {x y}  {100 100 200 100 300 100\
                  100 200 200 200 300 200\
                  100 300 200 300 300 300} {
          
      for {set angle 0} {$angle < 360} {incr angle 90} {
  .c create text $x $y \
          -text abc \
          -angle $angle \
          -font {Courier 18 bold} \
          -anchor $anchor
      }
  }

  after 5000 { .c postscript -file output.ps ; exit }

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

  compare the on-display and postscript output


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: 2779910fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: Fixed
title: New choosedir functionality on Windows
comment:
  Attached patch enables the newer style choosedir on Windows that has the "Make New Folder" button.

  It also enables a magic var ::tk::winChooseDirFlags that can be set to a new uint value to specify alternate SHBrowseForFolder behavior.


tkt_uuid: 2782346fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: ttk::notebook configure styles for each tab
comment:
  It would be nice if one could specify a style for each tab in ttk::notebook instead of the default TNotebook.Tab. This would allow to add tab scrolling at script level, create tabs with different buttons (for example, like firefox tabs)   


tkt_uuid: 2782353fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: None
title: add -statevariable option to menus and possibly ttk widgets
comment:
  Many applications change state of menu items and toolbar buttons from normal to disabled and vice versa. Keeping them synchronized is complex. It would be easier to have -statevariable option for menus and ttk widgets, for example
    menu .m
    .m add command -statevariable ::statev0
    ttk::entry .e -statevariable ::statev0
    set ::statev0 disabled
    ... 
    set ::statev0 normal
  Currently this could be implemented using traces and overriding widget commands, but script code becomes very complex.


tkt_uuid: 2784099fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 8
foundin: obsolete: 8.5.7
resolution: None
title: Aqua menus callbacks should not be idle tasks
comment:
  Aqua Tk 8.5.7 invokes menu entry callbacks as idle tasks.  Tk convention requires that user mouse/key event callbacks occurs when the window event is processed, and not later as idle tasks.  This is the behavior on X11 and Windows.  It is necessary so that "update idletasks" is able to redraw windows without invoking mouse/key callbacks in unsafe application code paths (e.g. user deletes data set via a menu entry while "update idletasks" is refreshing a status message for a computation on that data set).  This window updating without user event processing is the only purpose I know of for "update idletasks" and is a critical one for real-time applications.

  It took 10 hours to debug a hang in a Tk-based molecular viewer, UCSF Chimera, caused by unexpected menu entry callbacks within "update idletasks".


tkt_uuid: 2785744fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Incorrect setting of window flags
comment:
  On line 2356 of tkWinWm.c the WM_SYNC_PENDING flag is set with '=' instead of or'ing it with '|=' when a toplevel has a menu. This causes all other window flags (including those set by [wm resizable]) to be forgotten.

      if (wmPtr->hMenu != NULL) {
  wmPtr->flags = WM_SYNC_PENDING;
  SetMenu(wmPtr->wrapper, wmPtr->hMenu);
  wmPtr->flags &= ~WM_SYNC_PENDING;
      }


tkt_uuid: 2787164fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 8
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Windows7 themeing errors
comment:
  On Windows 7 the arrow element is incorrectly sized in the vista theme. This is seen in the combobox dropdown arrow and the toolbar buttons where there is only a few pixels for the arrow element.
  Looks like creating the Combobox.rightdownarrow element with either -margin or -padding {2 2 12 2} might be needed.
  In reality we should be asking the theme engine for the size to be used here as it may change.


tkt_uuid: 2789782fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Duplicate
title: button not centering image
comment:
  This is identical to ID: 2433781. For any reason comments have been closed for #2433781, therefore I add a new bug report:

  Try the following code:

  image create photo img -data {
  R0lGODdhCgAKAIABAMEsLP///ywAAAAACgAKAAACCISPqcvtD2MrADs= }
  button .b -borderwidth 1 -image img -relief solid
  pack .b

  As you can see, the image will not be centered. This makes it impossible to
  use button as a toolbar button.

  Your response to ID 2433781 is:

  > In what way is the image not centered? On Windows I see a read square
  > perfectly surrounded by 1px all around, then the solid outline. When
  > selecting, it shifts down, as is the designed behavior of button images on
  > selection.

  I believe you, but on Linux the image is not centered. I see two 2 px left and above, but 0 px right and below the solid outline. It seems, that the result is different on Linux and Windows.


tkt_uuid: 2790175fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: Wrong directory name is returned by tk_chooseDirectory
comment:
  Consider:

  puts [tk_chooseDirectory]

  if run in a directory (e.g., called parent), containing a sub-directory (e.g., called child), and the user selects the sub-directory and then hits Okay, the name of the parent directory is printed, not that of the selected child. In earlier versions of Tk (e.g., 8.4.13), the name of the selected sub-directory would be returned. This change in behaviour is very confusing.


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: 2791352fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 7 High
foundin: obsolete: 8.5.7
resolution: Fixed
title: font specification error
comment:
  As raised on c.l.t by Adrian Davis:

  It seems there may be a (minor) bug setting the font for a (Tk/ttk)
  label widget, which causes an "expected integer ..." error.

  It appears to happen only in a very specific circumstance...

  When all of the following are true:-

  *) The "-family" option name contains a hyphen/dash.
  *) The "-family" option appears first in the list.
  *) All of the "-size", "-weight", "-slant", "-underline" and "-overstrike" options are specified.

  For Example...

  .mylabel configure -font {-family sans-serif -size 12 -weight bold -slant roman -underline 0 -overstrike 0}

  ...Doesn't work. But...

  .mylabel configure -font {-family times -size 12 -weight bold -slant roman -underline 0 -overstrike 0}

  .mylabel configure -font {-size 12 -family sans-serif -weight bold -slant roman -underline 0 -overstrike 0}

  .mylabel configure -font {-family sans-serif -size 12 -weight bold -slant roman -underline 0}

  ...All work Ok.

  I found this using Tcl/Tk 8.5.7 on Solaris 10.

  This has been reproduced under WinXP using ActiveTcl 8.5.3 and Ubuntu
  using ActiveTcl 8.6b1.1

  (See thread: http://groups.google.co.uk/group/comp.lang.tcl/browse_thread/thread/aa2a4f206c139c42?hl=en#)

  WORKAROUND: Make sure that the "-family" option doesn't appear first
  in the list.

  Best Regards,
     =Adrian=


tkt_uuid: 2791585fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: None
resolution: Fixed
title: Cannot add comments to ID 2433781
comment:
  I cannot add comments to artifact 2433781.
  I see the message "Comments have been closed for this artifact." in my browser, therefore I cannot respond!!
  With other artifacts I do not have this problem!!

  I already added a new artifact (ID 2789782) complaining this problem, but this one is closed without a solution.


tkt_uuid: 2794032fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 9 Immediate
foundin: None
resolution: Accepted
title: enable [load] of Tk 8.5 into Tcl 8.6+
comment:
  Attached patch, when applied to core-8-5-branch
  of Tk will produce a Tk library that no longer refuses
  to [load] into Tcl 8.6 and later.

  Since Tcl 8.6 has not introduced any interface
  incompatibilities that break Tk 8.5, this permits:

  $ tclsh8.6
  % info patch
  8.6b1.1
  % package require Tk 8.5.0-8.6
  8.5.7

  and according to the Tk test suite
  all is "well" (that is, as "well" as the
  test suite runs for matching Tcl/Tk)


tkt_uuid: 2794778fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: Keyboard traversal can crash wish or make it 'unresponsible'
comment:
  When menu is navigated by keyboard (as in: open by alt-key, navigate with arrows, invoke with enter), sometimes wish either dies, or different menus start flickering rapidly closing/opening.

  I have latest 8.6 and 8.5 from ActiveState.

  Waving mouse cursor around already open menus (but without clicking) seems to help reproduce it, also it is much easier to reproduce with big and complex menu, like one that Tkabber has.

  This is the smallest sample I managed to reproduce bug with (after lots of tries though):

  . configure -menu [menu .mb -tearoff 0]
  .mb add cascade -label File -menu .mb.m0 -underline 0 
  menu .mb.m0 -tearoff 0
  .mb.m0 add command -label New -command {puts new} -underline 0
  .mb.m0 add command -label Quit -command {puts quit} -underline 0
  .mb add cascade -label Options -menu .mb.m1 -underline 0 
  menu .mb.m1 -tearoff 0
  .mb.m1 add command -label Test -command {puts test} -underline 0


tkt_uuid: 2797216fffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: wm attribute . -fullscreen 0 not updated on WIndows
comment:
  Main window in full screen mode:
  wm attributes . -fullscreen 1
  -> Window is shown in full screen mode

  wm attributes . -fullscreen 0
  -> Window is still shown in full screen mode without decoration
  wm attributes . -fullscreen
  -> Retruns 0

  Platform: Windows Vista SP1, Windows classic skin
  Tcl/Tk 8.5.7, compiled with MS-VC++ 6 and Platform SDK Win Server 2003


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: 2799589fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: Fixed
title: script crashes Tk on Win systems
comment:
  Chatters on the tkChat confirm that the script
  found at:

  http://paste.tclers.tk/1609?v=raw

  crashes Tk 8.5 programs on Windows systems (XP, Vista).


tkt_uuid: 2799888fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: Underline Text items are not drawn properly in Canvas
comment:
  Execute the next script:

  package require Tk
  canvas .c
  pack .c
  .c create text 100 100 -text "Bold Text" -font {Arial 15 bold}
  .c create text 100 130 -text "Italic Text" -font {Arial 15 italic}
  .c create text 100 160 -text "Underline Text" -font {Arial 15 underline}

  In Windows draws properly the underlined text, but in linux doesn't.

  I've tested with 8.5.4 and 8.5.7


tkt_uuid: 2800684fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: ttk::notebook rendering is slow on Windows platform
comment:
  ttk::notebook rendering is considerably slower than rendering of other widgets on Windows platform. This looks ugly when resizing a window with notebook or paned window. 

  For example, in this code

  package require Tk
  pack [panedwindow .p -orient vertical] -fill both -expand 1
  .p add [text .p.t1]
  .p add [text .p.t2]
  .p add [ttk::notebook .p.nb]
  .p.nb add [text .p.nb.t] -text Text

  moving the upper sash redraws considerably faster, than that when moving the lower sash. This holds both for Tk 8.5 and 8.6, Windows XP and Vista


tkt_uuid: 2804935fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 8
foundin: None
resolution: Fixed
title: MODULE_SCOPE harms easy extension of canvas
comment:
  The Tk canvas has a standard API for adding new item types via Tk_CreateItemType(). For consistency purposes options like -width all allow a variety of units, such as -width 10, -width 10in, -width 10cm, etc.  This is implemented in the pixelOption struct using TkPixelParseProc and TkPixelPrintProc functions.

  From 8.5 onwards however these are defined as MODULE_SCOPE in tkInt.h.

  Hence Tk packages attempting to extend the canvas no longer link if they were modelled on the same methods as employed in the Tk core. The work around is trivial of course (cut and paste the code to duplicate it in the package itself), but I'd suggest for the purposes of making standardisation easy that these functions are made public again.

  In my own code the 4 I use are (from my link lines):

  ../lib/linux-x86_64-binaries/libtk_utils.so: undefined reference to `TkOrientPrintProc'
  ../lib/linux-x86_64-binaries/libtk_utils.so: undefined reference to `TkOrientParseProc'
  ../lib/linux-x86_64-binaries/libtk_utils.so: undefined reference to `TkPixelParseProc'
  ../lib/linux-x86_64-binaries/libtk_utils.so: undefined reference to `TkPixelPrintProc'

  I expect there are some others which could usefully be made public too.

  James


tkt_uuid: 2805061fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: Wont Fix
title: TkMenuFont not used on MS Windows
comment:
  TIP 145 introduced named fonts including TkMenuFont.  However TkMenuFont use gets stomped
  on MS Windows because of some old cruft in tkWinMenu.c:SetDefaults() i.e. menuFontDString.

  Under WinXP and Tk 8.5.7:
  % menu .m
  % .m configure -font
  -font font Font TkMenuFont {Tahoma 10}


tkt_uuid: 2805928fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: wm iconphoto -default in slave interp affects other interps
comment:
  After using the -default switch of the [wm iconphoto] command in a slave interpreter, new toplevels in other interps, including the master, get the icon specified in the slave. This seems at odds with the statement in the interp manual page that "[e]ach interpreter is independent from the others". Also the wm manual page does not mention this contamination between interps.

  The best solution would be if each interp had its own concept of a default icon. But if that's not possible due to restrictions of the involved functions provided by the underlying window manager, there should be a clear warning about this in the wm manual page.

  Tested with Tk 8.5.7 on OpenSuSE 11.1


tkt_uuid: 2806562fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 36. [tk_chooseDirectory]
priority: 8
foundin: None
resolution: None
title: tk_chooseDirectory on Mac freezes when accessing Samba share
comment:
  Mac OS X only.

  Do:
  - On a Windows machine, share a folder to the network
  - On the Mac, open finder, press Command-K and connect to that shared folder
  - Open Wish, paste the following in the console:
  tk_chooseDirectory -initialdir ~ -mustexist 1 -title "hello" -parent .
  - In the dialog, click on the sharing computer in the left pane, then on the shared folder

  Happens:
  - The contents are not shown
  - The dialog is frozen

  Accessing the share through Finder or any other app (e.g. TextMate) that uses similar dialogs works fine.

  Tested on Mac OS X 10.5.6 and 10.5.7, with Tcl/Tk 8.5.4, 8.5.7 and 8.6b1.1 (built from CVS head).
  The Windows machine was using Windows Vista SP2.


tkt_uuid: 2810137fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Problem with "fixed" fonts (Courier)
comment:
  I have just tried the latest beta from ActiveState of 8.6, and I am having a peculiar behavior under vista:

  The problem I have observed is what returned by font actual:

  I have created a font "TextFont" with size 10:

  > font actual TextFont
  -family Arial -size 10 -weight normal -slant roman -underline 0 -overstrike 0
  > font configure TextFont -size 11
  > font actual TextFont
  -family Arial -size 11 -weight normal -slant roman -underline 0 -overstrike 0

  Everything seems normal here. Now lets try Courier New, again with size 10:

  > font configure FixedTextFont -size 10
  > font actual FixedTextFont
  -family {Courier New} -size 12 -weight normal -slant roman -underline 0 -overstrike 0

  I created a size 10 font, and I got a 12 actual size. So, lets set the size to 12:

  > font configure FixedTextFont -size 12
  > font actual FixedTextFont
  -family {Courier New} -size 13 -weight normal -slant roman -underline 0 -overstrike 0

  But now the size is 13? Why? 12 seems to be also available...

  > font configure FixedTextFont -size 13
  > font actual FixedTextFont
  -family {Courier New} -size 15 -weight normal -slant roman -underline 0 -overstrike 0

  The problem does not exist with Tk 8.5.


tkt_uuid: 2810692fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Duplicate
title: tk_getOpenFile exceptions when double clicking on directory
comment:
  On Linux and probably all other unixen if a user does NOT HAVE PERMISSION to enter a directory ( e.g. 666 or drw-rw-rw ) the tk_getOpenFile dialog will cause an error  here is some example code to cause error. Trace back follows code. It looks like a simple fix as there is no message for the -message option in this case (See Trace back ) which causes the "warning" to be seen as an option.  Error was "Error: bad option "warning": must be -default,-de...
  =================START CODE ==================
  #!/bin/sh
   # the next line restarts using wish \
   exec /opt/usr8.6b.1/bin/tclsh8.6  "$0" ${1+"$@"}
    
  if { [ catch {package require Img } err ] != 0 } {
      puts stderr "Unable to find package Img ... adjust your auto_path!";
  }

  proc mkWindow { root } {
      global gStatus gCanvas
      if { $root eq "." } {
  set mf [ frame .frame -width 700 ]
      } else {
  set mf [ frame $root.frame -width 700 ]
      }
      set tf [frame .frame.topframe ]
      set bf [frame .frame.bottomframe ]
      set status [ label $tf.label -textvariable gStatus -width 300 ]
      set gCanvas [ canvas $tf.canvas  ]
      set bclose [button $bf.close -text Close -command { exit } ]
      set bopen  [button $bf.open  -text Open  -command { openProc } ] 
      pack $gCanvas -fill both -expand 1 -side top -anchor c
      pack $status -fill x -expand 1 -side top -anchor w
      pack $tf  -fill both -expand 1 -side top
      pack $bf  -fill x  -side top
      pack $bclose -ipadx 5 -padx 5 -pady 5 -side right -anchor c
      pack $bopen  -ipadx 5 -padx 5 -pady 5 -side right -anchor c
      pack $mf -side top -fill both -expand 1 -anchor c
      
  }

  proc openProc { } {
      global gCanvas env gLabel
      set filename [ tk_getOpenFile -defaultextension .jpg \
         -initialdir [file join $env(HOME) Pictures ] \
         -parent . \
         -title "View Picture?" ]
      if { [string length $filename ] == 0  } {
  return
      }
      catch { rename chuck {} } 
      image create photo chuck -format JPEG -file $filename
      set picid [$gCanvas create image 0 0 -anchor nw -image chuck ]
      $gCanvas bind $picid <Enter> [list set gStatus "id:$picid |filename:$filename" ]
  }

  global gCanvas gStatus
  set gStatus "hello"
  mkWindow .
  wm geometry . 500x500

  ====================== END CODE =============
  =====================START TRACEBACK =======
  bad option "warning": must be -default, -detail, -icon, -message, -parent, -title, or -type
  bad option "warning": must be -default, -detail, -icon, -message, -parent, -title, or -type
      while executing
  "error "bad option \"$cmdsw\": must be [tclListValidFlags cmd]""
      (procedure "tclParseConfigSpec" line 36)
      invoked from within
  "tclParseConfigSpec $w $specs "" $args"
      (procedure "tk::MessageBox" line 24)
      invoked from within
  "tk::MessageBox {*}$args"
      (procedure "tk_messageBox" line 2)
      invoked from within
  "tk_messageBox -type ok -parent $w -message -icon warning  [mc "Cannot change to the directory \"%1\$s\".\nPermission denied." $file]"
      (procedure "ListInvoke" line 14)
      invoked from within
  "ListInvoke $w [list $filename]"
      (procedure "::tk::dialog::file::OkCmd" line 13)
      invoked from within
  "::tk::dialog::file::OkCmd .__tk_filedialog"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 $data(-command)"
      (procedure "IconList_Invoke" line 5)
      invoked from within
  "IconList_Invoke $w"
      (procedure "tk::IconList_Double1" line 5)
      invoked from within
  "tk::IconList_Double1 .__tk_filedialog.contents.icons 30 98"
      (command bound to event)
  =================== END TRACEBACK ====================


tkt_uuid: 2811266fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: tk_dialog spacebar invokes focused button not Enter key
comment:
  On Linux, when using the tk_dialog proc to produce a dialog a two button dialog and using only the keyboard for navigation when a highlighted button is invoked using the enter key the default value is always returned. If the space bar is pressed then the correct value for the focused button is returned.  Test Code follows: When dialog is up tab to the Yes button then press Enter. The value 0 is returned rather than 1. Call it up again this time tab to the yes button and press spacebar. 
  Pressing the Enter key should invoke the button that has focus.  The binding needs to be changed. The binding for spacebar can either be removed or remain. 

  ========================== TEST CODE ===================
  #!/bin/sh
   # the next line restarts using wish \
   exec /opt/usr8.6b.1/bin/tclsh8.6  "$0" ${1+"$@"}
  if { [ catch {package require Tk } err ] != 0 } {
      puts stderr "Unable to find package Tk ... adjust your auto_path!";
  }
  proc mkExitDialog { } {
      return  [ tk_dialog .exit  "Quit or Cancel?" \
      "Are you sure you want to quit?" \
      questhead \
      0 \
      "No,Cancel" "Yes" ]
  }
   
  proc cleanup {} {
      set reply [ mkExitDialog  ]
      switch -exact -- $reply {
  1 {
      puts "reply was $reply"
      exit
  } 
  default {
      puts "reply was $reply";
  }
      }
  }
  wm protocol . WM_DELETE_WINDOW cleanup
  wm geometry . 500x500
  button .b -text "Push me or Close the Window" -command cleanup 
  pack .b -padx 10 -pady 10 -ipadx 5 -ipady 5 

  =============================END TEST CODE ================================


tkt_uuid: 2811373fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 56. [grab]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Rejected
title: global grab on windows xp
comment:
  [grab] manpage says:
  A global grab locks out all applications on the screen, so that only the given subtree of the grabbing application will be sensitive to pointer events (mouse button presses, mouse button releases, pointer motions, window entries, and window exits). During global grabs the window manager will not receive pointer events either.
  [...]
  During a global grab Tk grabs the keyboard so that all keyboard events are always sent to the grabbing application.

  On windows xp it is still possible to interact with the rest of desktop using both mouse and keyboard.


tkt_uuid: 2814003fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: tk_messageBox unresponsive on global grab
comment:
  A message box is inresponsive, if there is a global grab on another widget.

  Example:
  pack [button .b -text t -command "tk_messageBox"]
  focus .b
  raise .
  grab -global .b

  This might be seen as feature, but it might be helpful, to replace the grab of message box by the existing grab, and restore it afterwards.

  On Windows XP, tk 8.5.7


tkt_uuid: 2815625fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: Problem in tkInt.h with "namespace"
comment:
  When Tk is included in a C++ application, the C++ compiler throws an error in tkInt.h, line 1268:

  MODULE_SCOPE Tcl_Command TkMakeEnsemble(Tcl_Interp *interp,
      const char *namespace, const char *name,
      ClientData clientData, const TkEnsemble *map);

  as namespace is a reserved C++ keyword.


tkt_uuid: 2816150fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: Rotated text displays incorrectly on WinXP
comment:
  Run this script:
  ---
  canvas .c
  grid .c 
  set id [.c create text 200 100 -text "Angled text" -angle 15 -font {Courier 42}]
  for {set f 40} {$f>20} {incr f -2} {
      .c itemconfigure $id -font "Courier $f"
      update
      }
  ---
  I see traces of bigger fonts in window. They dissapear on resizing it.


tkt_uuid: 2816331fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Duplicate
title: rendering problem with notebook inside paned window
comment:
  Please try the following code:
  -----------------------------------------------------------------------------------------
  set pw [panedwindow .pw -orient vertical -opaqueresize true -background darkgray]
  set fr [ttk::frame $pw.f -height 100]
  set nb [ttk::notebook $pw.nb]
  $pw add $fr -sticky nsew -stretch never
  $pw add $nb -sticky nsew -stretch always
  $nb add [ttk::frame $nb.f -height 400 -width 400] -sticky nsew -text Test
  $nb add [ttk::frame $nb.g -height 400 -width 400] -sticky nsew -text Test
  pack $pw -fill both -expand yes
  -----------------------------------------------------------------------------------------

  Now watch careful the notebook labels while moving the sash of the paned window.
  Sometimes the labels will be rendered normal, sometimes the relief is too small.

  I have a weak suspicion that the paned window has an error while calculating the
  geometry of the subwindows or while calculating its own geometry. There is a lack
  of two pixels somewhere.

  I have tested this on Linux (that means with x11 windowing system).

  NOTE: with ttk::panedwindow you will get the same result.

  BTW: Who is responsible for the tracker? The description window is quite too small!


tkt_uuid: 2817382fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: rendering problem with ttk::notebook
comment:
  NOTE:
  This is bug item #2816331. I replicated this artifact because
  comments have been closed for  #2816331.

  IMPORTANT NOTE:
  Please try the following example with X11 windowing system.

  IMPORTANT NOTE:
  This rendering problem occurs as well without paned windows, e..g. if the
  frame containing a notebook is too small.

  IMPORTANT NOTE:
  Please be patient, it may take a while until you can see the error.
  I can see the error if the label is showing a value about 250.

  ==============================
  Bug item #2816331
  ==============================

  Please try the following code:
  ---------------------------------------------------------------------------
  --------------
  bind Panedwindow <B1-Motion> {+ .pw.f configure -text %y }
  set pw [panedwindow .pw -orient vertical -opaqueresize true -background
  darkgray]
  set fr [ttk::label $pw.f]
  set nb [ttk::notebook $pw.nb]
  $pw add $fr -sticky nsew -stretch never
  $pw add $nb -sticky nsew -stretch always
  $nb add [ttk::frame $nb.f -height 400 -width 400] -sticky nsew -text Test
  $nb add [ttk::frame $nb.g -height 400 -width 400] -sticky nsew -text Test
  pack $pw -fill both -expand yes
  ---------------------------------------------------------------------------
  --------------

  Now watch careful the notebook labels while moving the sash of the paned
  window.
  Sometimes the labels will be rendered normal, sometimes the relief is too
  small.

  I have a weak suspicion that the paned window has an error while
  calculating the
  geometry of the subwindows or while calculating its own geometry. There is
  a lack
  of two pixels somewhere.

  I have tested this on Linux (that means with x11 windowing system).

  NOTE: with ttk::panedwindow you will get the same result.


tkt_uuid: 2817393fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: core dump after using -setgrid in canvas widget
comment:
  After using "-setgrid 0" in canvas widget I get a core dump. Without this
  option the application works.

  valgrind is reporting the following:
  ------------------------------------------------------
  ==7138== Invalid read of size 4
  ==7138==    at 0x40389B2: Tk_SetBackgroundFromBorder (tk3d.c:594)
  ==7138==    by 0x4099E42: ConfigureCanvas (tkCanvas.c:1901)
  ==7138==    by 0x4096398: Tk_CanvasObjCmd (tkCanvas.c:495)
  ==7138==    by 0x41805D8: TclEvalObjvInternal (in /usr/local/stow/tcl8.5.6/lib/libtcl8.5.so)
  ==7138==    by 0x41C98F2: TclExecuteByteCode (in /usr/local/stow/tcl8.5.6/lib/libtcl8.5.so)
  ==7138==    by 0x420DE42: TclObjInterpProcCore (in /usr/local/stow/tcl8.5.6/lib/libtcl8.5.so)
  ==7138==    by 0x420E082: TclObjInterpProc (in /usr/local/stow/tcl8.5.6/lib/libtcl8.5.so)
  ==7138==    by 0x41F6F98: InvokeImportedCmd (in /usr/local/stow/tcl8.5.6/lib/libtcl8.5.so)
  ==7138==    by 0x41805D8: TclEvalObjvInternal (in /usr/local/stow/tcl8.5.6/lib/libtcl8.5.so)
  ==7138==    by 0x41807E4: Tcl_EvalObjv (in /usr/local/stow/tcl8.5.6/lib/libtcl8.5.so)
  ==7138==    by 0x4182367: TclEvalObjEx (in /usr/local/stow/tcl8.5.6/lib/libtcl8.5.so)
  ==7138==    by 0x420CDB0: Tcl_UplevelObjCmd (in /usr/local/stow/tcl8.5.6/lib/libtcl8.5.so)
  ==7138==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
  ------------------------------------------------------

  With the GNU debugger I see following
  -------------------------------------------------------------
  Tk_SetBackgroundFromBorder (tkwin=0x9e3f6a8, border=0x0)
      at /usr/local/sources/tk8.5.6/unix/../generic/tk3d.c:594
  ---------------------------------------------------------------


tkt_uuid: 2817531fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 08. [(label)frame] and [toplevel]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: "wm manage" is deficient and flickering
comment:
  NOTE:
  I tried the following with x11 windowing system. I don't know
  the behaviour with win32 and aqua.

  Please try the following code:
  ----------------------------------------------------------------------------------------
  wm withdraw .
  frame .f1 -width 800 -height 800
  frame .f2 -width 800 -height 800
  button .f1.l -text Undock -command { Undock .f2 }
  pack .f1.l
  pack .f1 .f2
  ::tk::PlaceWindow . center
  wm deiconify .
  proc Undock {w} {
     pack forget $w
     wm manage $w
     wm overrideredirect $w
     wm protocol $w WM_DELETE_WINDOW [list Dock $w]
     ::tk::PlaceWindow $w center [winfo parent $w]
  }
  proc Dock {w} {
     wm forget $w
     pack $w
  }
  ----------------------------------------------------------------------------------------

  1. I'm using large windows too make it easier too see the problem.
  2. "wm overrideredirect" is not working. It comes too late because
     the (managed)  window is already mapped. But I cannot use this
     before managing.
  3. The popup is flickering a lot. This has two reasons:
     a) In function WmManageCmd (unix/tkUnixWm.c) you see:
            2675: TkWmMapWindow(winPtr);
            2676: Tk_UnmapWindow(frameWin);
         This must flicker. These statements are superfluous.
         I tried this without these two lines and the function
         is working! But it flickers still a bit because:
     b) ::tk::PlaceWindow comes too late because the
         (managed) window is already mapped (normally 
        in the upper left corner). It should help if
        "wm manage" has an option like -unmapped.
        Without such an option the window cannot be placed
        flicker-free. And without such an option you
       cannot use "wm overrideredirect".


tkt_uuid: 2817539fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 59. [tk_focus*]
priority: 5 Medium
foundin: None
resolution: None
title: focus problems during startup of wish application in windows
comment:
  Take any simple Tk application, like --> pack [button .b1 -text "Exit" -command exit] 
  run with 
  wish85.exe simple.tcl 
  When the application starts up, it does not have the system focus.  Before manually focusing the app (with a mouse click), if I press Alt-Tab (Windows task switcher), I see 2 "Tk" tasks.  One is my application, the other is labeled "Console".  But I never asked for a console in my app.  Also, 
  there is no visible console window on the screen, nor is there a console on my task bar or in the Windows "Close Program" dialog. 
  - If I either Alt-Tab my way to the app (which focuses it), or if I mouse click on the app to focus it, the "Console" task goes away and the application reacts normally.  Basically, once the app *is* focused once, all is normal.  It just doesn't receive focus by default for some reason and has this weird "Console" task hanging around until it is focused. 
  I have temporarily fixed the problem by placing a "focus -force ." in my application code, which does seem to work. 

  This happens on Windows 98/NT/XP
  On Vista you still get the focus problem, but you don't get the extra "console" icon in the windows task switcher window.

  It only happens when you run from wish.  Running from tclsh it works fine.


tkt_uuid: 2818455fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: grid doc error
comment:
  In the grid manpage, the example showing a text widget with two scrollbars uses -command {.t.txt xview}  for both vertical and horizontal scrollbars:

  .CS
  # Make the widgets
  toplevel .t
  text .t.txt \-wrap none \-xscroll {.t.h set} \-yscroll {.t.v set}
  scrollbar .t.v \-orient vertical   \-command {.t.txt xview}
  scrollbar .t.h \-orient horizontal \-command {.t.txt xview}


tkt_uuid: 2819620fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: None
resolution: Fixed
title: Improvements in Aqua ttk theme
comment:
  This patch to ttkMacOSXTheme.c: makes two improvements to the Aqua ttk theme:

  1. It fixes the "selected" state of the ttk::treeview column header to render in standard "Aqua" blue only. Previously the "selected" state rendered in the "Aqua" blue and also drew an "up" arrow without a corresponding "down" arrow if the column header were clicked on. This change allows the appropriate  up/down arrow to be implemented at the script level, if necessary. The result is a more-native appearance under Aqua. 

  2. It modernizes the appearance of the notebook tab under Aqua, cf http://www.codebykevin.com/mac-tabs.png, to use the style that became the system standard in Mac OS X 10.3, released in 2003. Previously the notebook tabs were drawn with an older style that is no longer widely used. 


tkt_uuid: 2820123fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Canvas item bindings don't always work.
comment:
  If, in a canvas <Motion> handler, you draw within 2 pels of the cursor hot spot, then <Enter> bindings on canvas items don't work. Happens with 8.5, 8.6b1, and possibly earlier. The example below uses the 'none' cursor, but the bug will also occur with any of the stock cursors.

  -cut here ----------------------------------------
  #NB: THIS WORKS, AS IS, EXHIBITING THE DESIRED BEHAVIOUR (rectangle changes colour
  # on enter/leave).
  #TO EXHIBIT THE BUG, CHANGE 0 TO 1 THREE LINES BELOW THIS.
  package require Tk

  set cursor_style 0
  # space at hot point. Works.
  # set cursor_style to 1 for no space, -> doesn't work

  proc main {} {

     pack [canvas .c -bg white]
     set r [.c create rectangle 40 40 240 140  -fill cyan]
     
     .c bind $r <Enter> [list .c itemconfigure $r -fill pink]
     .c bind $r <Leave> [list .c itemconfigure $r -fill cyan]
     
     .c configure -cursor "none"
     set ::cursor_items ""

     bind .c <Enter> {draw_cursor %x %y}
     bind .c <Motion> {draw_cursor %x %y}
     bind .c <Leave> erase_cursor
  }

  proc erase_cursor {} {

     foreach x $::cursor_items {.c delete $x}
  }

  proc draw_cursor {x y} {

     erase_cursor
     set ::cursor_items ""

     if {$::cursor_style == 0} {set d 2} else {set d 0}
     set s 24
  # s sets cursor size, d is central gap size

     set x1 [expr {$x - $s}]
     set x2 [expr {$x + $s}]
     set y1 [expr {$y - $s}]
     set y2 [expr {$y + $s}]

     lappend ::cursor_items [.c create line $x1 $y  [expr {$x - $d}] $y ]
     lappend ::cursor_items [.c create line [expr {$x + $d}] $y $x2 $y ]
     lappend ::cursor_items [.c create line $x  $y1 $x  [expr {$y - $d}]]
     lappend ::cursor_items [.c create line $x  [expr {$y + $d}] $x  $y2]
  }

  main


tkt_uuid: 2820784fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5b3
resolution: Invalid
title: wm managed listbox core with string inserts
comment:
  in wish8.5 shell
  % wm manage [listbox .test]
  % .test insert end "test"
  Segmentation fault (core dumped)

  (gdb) where
  #0  0x007bd79c in Tcl_NewStringObj () from /usr/local/lib/libtcl8.5.so
  #1  0x007cfa57 in Tcl_SetVar2Ex () from /usr/local/lib/libtcl8.5.so
  #2  0x0034b50b in ListboxWidgetObjCmd () from /usr/local/lib/libtk8.5.so
  #3  0x007373bb in TclEvalObjvInternal () from /usr/local/lib/libtcl8.5.so
  #4  0x0077a7df in TclExecuteByteCode () from /usr/local/lib/libtcl8.5.so
  #5  0x00782584 in TclCompEvalObj () from /usr/local/lib/libtcl8.5.so
  #6  0x00738c7c in TclEvalObjEx () from /usr/local/lib/libtcl8.5.so
  #7  0x00738f0d in Tcl_EvalObjEx () from /usr/local/lib/libtcl8.5.so
  #8  0x0078858e in Tcl_RecordAndEvalObj () from /usr/local/lib/libtcl8.5.so
  #9  0x00788606 in Tcl_RecordAndEval () from /usr/local/lib/libtcl8.5.so
  #10 0x003306aa in StdinProc () from /usr/local/lib/libtk8.5.so
  #11 0x00794e74 in Tcl_NotifyChannel () from /usr/local/lib/libtcl8.5.so
  #12 0x007d959b in FileHandlerEventProc () from /usr/local/lib/libtcl8.5.so
  #13 0x007a9d19 in Tcl_ServiceEvent () from /usr/local/lib/libtcl8.5.so
  #14 0x007aa00f in Tcl_DoOneEvent () from /usr/local/lib/libtcl8.5.so
  #15 0x00323d39 in Tk_MainLoop () from /usr/local/lib/libtk8.5.so
  #16 0x0033028c in Tk_MainEx () from /usr/local/lib/libtk8.5.so
  #17 0x080487b6 in main ()


  RedHat 4.3 Enterprise Edition


tkt_uuid: 2821084fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: WM_DELETE_WINDOW error
comment:
  Under Tk-Cocoa, cancelling the WM_DELETE_WINDOW protocol causes the main window to withdraw, and not to return. 

  The sample code below is a test case. Under Tk 8.4.7, it causes Wish to exit if "yes" is chosen and the command to be cancelled if "no" is chosen, leaving the toplevel mapped. Under Tk-Cocoa, Wish exists if "yes" is chosen, and the toplevel is unmapped if "no" is chosen. The toplevel should remain mapped. 


  wm protocol . WM_DELETE_WINDOW shutDown


  proc shutDown {} {

      global datadir

      set fetchanswer [tk_messageBox -title "Quit" -icon info  -message "Do you really want to quit?" -type yesno -parent . ]
      switch $fetchanswer {
  yes {
      exit
  }
  no {
      destroy $fetchanswer
  }
      }
  }


tkt_uuid: 2821318fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 8
foundin: None
resolution: Fixed
title: tk::mac::iconBitmap crash
comment:
  The new tk::mac::iconBitmap command in Tk-Cocoa causes unpredictable crashes, especially when rendering a large number of images (such as in a file system/directory display). The crashes sometimes take the form of "alloc: invalid block: 0x11283a0c0" and sometimes a simple segfault. The sample script below, when tested with a large directory (163 + items), caused the invalid memory block crash: 

  toplevel .f

  set dir [tk_chooseDirectory]
  set filelist [glob -directory $dir *]


  foreach item $filelist {
       
      #  tk::mac::iconBitmap $item 16 16 -file $item
      if {[file isdir $item] || [file extension $item ] == "" } {
  tk::mac::iconBitmap $item 16 16 -file $item
      } else {

  tk::mac::iconBitmap $item 16 16 -fileType [lindex [split [file tail $item] . ] 1]
      }

      puts "creating iconbitmap for $item..."

      label .f.[lsearch $filelist $item] -bitmap $item -text [file tail $item] -compound left
      pack .f.[lsearch $filelist $item]

  }


tkt_uuid: 2821521fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: scripted file dialogs improvements
comment:
  The attached diff adds a "goto home" button to quickly change to the user's home directory.
  The icon is from the tango-icon-theme (same as other icons) and is in the public domain.


tkt_uuid: 2821962fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Copy & paste images in Unix
comment:
     Hello,

    I have been playing today with copy and paste images in TCL-TK and
  Unix. The origin of the image is Firefox, where I open the contextual
  menu over one image and select "copy image"

  The TCL code for pasting the image is:

  package require img::png
  set data [binary format c* [selection get -selection CLIPBOARD -type
  image/png]]
  set img [image create photo -data $data]

  This code does not work in a standard wish as there is a bug in file
  tkUnixSelect.c

  After a small modification in file "tkUnixSelect.c", it works
  correctly!!

  The modification is the following:

  in function TkSelEventProc

  ...
            if (format != 32 && format != 8) {
                  char buf[64 + TCL_INTEGER_SPACE];

                  sprintf(buf,
                          "bad format for selection: wanted \"32\" or \"8\", got \"%d\"",
                          format);
                  Tcl_SetResult(retrPtr->interp, buf, TCL_VOLATILE);
                  retrPtr->result = TCL_ERROR;
                  return;
              }
              Tcl_DStringInit(&ds);
              if (format == 32) {
                  SelCvtFromX((long *) propInfo, (int) numItems, type,
                              (Tk_Window) winPtr, &ds);
              } else {
                  SelCvtFromX8((char *) propInfo, (int) numItems, type,
                              (Tk_Window) winPtr, &ds);
              }
  ....

  in function SelRcvIncrProc (a similar change)

  new function "SelCvtFromX8":

  static void
  SelCvtFromX8(
      register char *propPtr,     /* Property value from X. */
      int numValues,              /* Number of 8-bit values in property. */
      Atom type,                  /* Type of property Should not be XA_STRING
                                   * (if so, don't bother calling this function
                                   * at all). */
      Tk_Window tkwin,            /* Window to use for atom conversion. */
      Tcl_DString *dsPtr)         /* Where to store the converted string. */
  {
      /*
       * Convert each long in the property to a string value, which is
  either
       * the name of an atom (if type is XA_ATOM) or a hexadecimal
  string. We
       * build the list in a Tcl_DString because this is easier than
  trying to
       * get the quoting correct ourselves; this is tricky because atoms
  can
       * contain spaces in their names (encountered when the atoms are
  really
       * MIME types). [Bug 1353414]
       */

      for ( ; numValues > 0; propPtr++, numValues--) {
          if (type == XA_ATOM) {
              Tcl_DStringAppendElement(dsPtr,
                      Tk_GetAtomName(tkwin, (Atom) *propPtr));
          } else {
              char buf[12];

              sprintf(buf, "0x%x", (unsigned char) *propPtr);
              Tcl_DStringAppendElement(dsPtr, buf);
          }
      } 


tkt_uuid: 2822368fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 53. [selection]
priority: 5 Medium
foundin: None
resolution: None
title: Can't generate binary selection formats
comment:
  Now that 2821962 is fixed, we're stuck with the problem that Tk (on Unix) can't do the reverse operation: deliver binary data as a selection type in 8-bit binary format; the only non-text type that we can deliver is 32-bit binary (or Atoms, but I'll ignore those). This means that if someone selects an image in Tk, it is impossible to copy it to another non-Tk application.


tkt_uuid: 2824378fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 8
foundin: obsolete: 8.5.7
resolution: Fixed
title: new selection test failures
comment:
  Failure is new on the core-8-5-branch tip:

  ==== 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:
  0x10
  ---- Result should have been (exact matching):
  0x10
  ==== clipboard-6.2 FAILED


  Suspect the 2009-07-15 commit to tkUnixSelect.c


tkt_uuid: 2824538fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: None
resolution: Remind
title: Need to track opaque content in textured windows
comment:
  A toplevel Mac window with the "metal" style applied (via tk::unsupported::MacWindowStyle) should be not be dragabble from a widget with an opaque background, just a transparent background. However, it is draggable from any region on the window. Here is a sample script: 

  toplevel .f

  tk::unsupported::MacWindowStyle style .f document { metal toolbarButton  closeBox collapseBox resizable standardDocument}

  label .f.t -text "Should  be able to drag here" -bg systemTransparent
  pack .f.t -side top -fill both -expand yes

  label .f.b -text "Should not be able to drag here" -bg white
  pack .f.b -side bottom -fill both -expand yes


tkt_uuid: 2824541fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: Cannot configure ttk::style -background on Aqua
comment:
  I'm trying to create a custom layout for a ttk::entry widget, but the widget's background cannot be configured on Aqua. Instead of having a matching background with the surrounding widgets/toplevel, the entry displays the default themed background of a ttk::frame. See  http://www.codebykevin.com/pic.png. Code below was tested in the Tcl chatroom by others and they confirmed it works fine under Linux: hence I think it's a Tk-Aqua bug. 

  ---
   set glass {

   R0lGODlhKgAaAOfnAFdZVllbWFpcWVtdWlxeW11fXF9hXmBiX2ZnZWhpZ2lraGxua25wbXJ0
   cXR2c3V3dHZ4dXh6d3x+e31/fH6AfYSGg4eJhoiKh4qMiYuNio2PjHmUqnqVq3yXrZGTkJKU
   kX+asJSWk32cuJWXlIGcs5aYlX6euZeZloOetZial4SftpqbmIWgt4GhvYahuIKivpudmYei
   uYOjv5yem4ijuoSkwIWlwYmlu56gnYamwp+hnoenw4unvaCin4ioxJCnuZykrImpxZmlsoaq
   zI2pv6KkoZGouoqqxpqms4erzaOloo6qwYurx5Kqu5untIiszqSmo5CrwoysyJeqtpOrvJyo
   tZGsw42typSsvaaopZKtxJWtvp6qt4+uy6epppOuxZCvzKiqp5quuZSvxoyx06mrqJWwx42y
   1JKxzpmwwaqsqZaxyI6z1ZqxwqutqpOzz4+01qyuq56yvpizypS00Jm0y5W10Zq1zJa20rCy
   rpu3zqizwbGzr6C3yZy4z7K0saG4yp250LO1sqK5y5660Z+70qO7zKy4xaC806S8zba4taG9
   1KW9zq66x6+7yLi6t6S/1rC8yrm7uLO8xLG9y7q8ubS9xabB2anB07K+zLW+xrO/za7CzrTA
   zrjAyLXBz77BvbbC0K/G2LjD0bnE0rLK28TGw8bIxcLL07vP28HN28rMycvOyr/T38DU4cnR
   2s/RztHT0NLU0cTY5MrW5MvX5dHX2c3Z59bY1dPb5Nbb3dLe7Nvd2t3f3NXh797g3d3j5dnl
   9OPl4eTm4+Ln6tzo9uXn5Obo5eDp8efp5uHq8uXq7ejq5+nr6OPs9Ovu6unu8O3v6+vw8+7w
   7ezx9O/x7vDy7/Hz8O/19/P18vT38/L3+fb49Pf59vX6/fj69/b7/vn7+Pr8+ff9//v9+vz/
   +/7//P//////////////////////////////////////////////////////////////////
   /////////////////////////////////yH/C05FVFNDQVBFMi4wAwEAAAAh+QQJZAD/ACwC
   AAIAKAAWAAAI/gD/CRz4bwUGCg8eQFjIsGHDBw4iTLAQgqBFgisuePCiyJOpUyBDihRpypMi
   Lx8qaLhIMIyGFZ5sAUsmjZrNmzhzWpO2DJgtTysqfGDpxoMbW8ekeQsXzty4p1CjRjUXrps3
   asJsuclQ4uKKSbamMR3n1JzZs2jRkh1HzuxVXX8y4CDYAwqua+DInVrRwMGJU2kDp31KThy1
   XGWGDlxhi1rTPAUICBBAoEAesoIzn6Vm68MKgVAUHftmzhOCBCtQwQKSoABgzZnJdSMmyIPA
   FbCotdUQAIhNa9B6DPCAGbZac+SowVIMRVe4pwkA4GpqDlwuAAmMZx4nTtfnf1mO5JEDNy46
   MHJkxQEDgKC49rPjwC0bqGaZuOoZAKjBPE4NgAzUvYcWOc0QZF91imAnCDHJ5JFAAJN0I2Ba
   4iRDUC/gOEVNDwIUcEABCAgAAATUTIgWOMBYRFp80ghiAQIIVAAEAwJIYI2JZnUji0XSYAYO
   NcsQA8wy0hCTwAASXGOiONFcxAtpTokTHznfiLMNMAkcAMuE43jDC0vLeGOWe2R5o4sn1LgH
   GzkWsvTPMgEOaA433Ag4TjjMuDkQMNi0tZ12sqWoJ0HATMPNffAZZ6U0wLAyqJ62RGoLLrhI
   aqmlpzwaEAAh+QQJZAD/ACwAAAAAKgAaAAAI/gD/CRw40JEhQoEC+fGjcOHCMRAjRkxDsKLF
   f5YcAcID582ZjyBDJhmZZIjJIUySEDHiBMhFghrtdNnRAgSHmzhz6sTZQcSLITx+CHn5bxSk
   Nz5MCMGy55CjTVCjbuJEtSrVQ3uwqDBRQwrFi476SHHxow8qXcemVbPGtm21t3CnTaP27Jgu
   VHtuiIjBsuImQkRiiEEFTNo2cOTMKV7MuLE5cN68QUOGSgwKG1EqJqJDY8+rZt8UjxtNunTj
   cY3DgZOWS46KIFgGjiI0ZIsqaqNNjWjgYMUpx8Adc3v2aosNMAI1DbqyI9WycOb4IAggQEAB
   A3lQBxet/TG4cMpI/tHwYeSfIzxM0uTKNs7UgAQrYL1akaDA7+3bueVqY4NJlUhIcQLNYx8E
   AIQ01mwjTQ8DeNAdfouNA8440GBCQxJY3MEGD6p4Y844CQCAizcSgpMLAAlAuJ03qOyQRBR3
   nEHEK+BMGKIui4kDDAAIPKiiYuSYSMQQRCDCxhiziPMYBgDkEaEaAGQA3Y+MjUPOLFoMoUUh
   cKxRC4ngeILiH8Qkk0cCAUzSDZWpzbLEE1EwggcYqWCj2DNADFDAAQUgIAAAEFDDJmPYqNJF
   F1s4cscTmCDjDTjdSPOHBQggUAEQDAgggTWDPoYMJkFoUdRmddyyjWLeULMMMcAsIw0x4wkM
   IME1g25zyxpHxFYUHmyIggw4H4ojITnfiLMNMAkcAAub4BQjihRdDGTJHmvc4Qo1wD6Imje6
   eILbj+BQ4wqu5Q3ECSJ0FOKKMtv4mBg33Pw4zjbKuBIIE1xYpIkhdQQiyi7OtAucj6dt48wu
   otQhBRa6VvSJIRwhIkotvgRTzMUYZ6xxMcj4QkspeKDxxRhEmUfIHWjAgQcijEDissuXvCyz
   zH7Q8YQURxDhUsn/bCInR3AELfTQZBRt9BBJkCGFFVhMwTNBlnBCSCGEIJQQIAklZMXWRBAR

   RRRWENHwRQEBADs=

  }

  image create photo search1 -data $glass -format "gif -index 0"
  image create photo search2 -data $glass -format "gif -index 1"

      

  ttk::style element create Search.field image {search1  focus search2} \
      -border {22 7 14} -sticky ew 


  ttk::style layout Search.entry {
      Search.field -sticky nswe -border 1 -children {
  Entry.padding -sticky nswe -children {
      Entry.textarea -sticky nswe
  }
      }
  }

  ttk::style configure Search.entry -background #b2b2b2

   . configure -background #b2b2b2
   ttk::entry .e1 -style Search.entry -width 20
   ttk::entry .e2 -style Search.entry -width 20

   grid .e1 -padx 10 -pady 10
   grid .e2 -padx 10 -pady 10


tkt_uuid: 2824550fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Tk crashes after destroying a widget
comment:
  Tk crashes with the following message : 

  malformed bucket chain in Tcl_DeleteHashEntry
  Aborted

  Problem is 100% reproducible with tk 8.5.0-3 Ubuntu build and Tk8.5.7 (stable) version built from the source.
  To reproduce : launch the provided script, and then left click the combobox in the middle of the widget. It always crashes at the 2nd click here.


tkt_uuid: 2824916fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 3 Low
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: again underline with rotated text
comment:
  This is a continuation of #2356057 after the bug mentioned there was indeed
  fixed.  The underline bar now looks almost like a bar.  But especially at certain
  angles, the bar looks rather like a part of a wedge, as visible with the example
  from  #2356057  after changing the values in one line to:
     set tm 5000; set d 45

  Strangely, the effect becomes *more* obvious, if the text of the item is also changed
  to e.g. three o's (rather than "foo").  Why does the shape of the bar depend also on other
  characters than the one it's under?

  PS: This is on Linux/X11, in case it matters.


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: 2827327fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: transparent backgrounds
comment:
  [Transferred from Tcl tracker issue 798887]

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

  KaKaRoTo


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

  wish85.exe core.tcl

  ( If i start the wish and 
  source core.tcl
  there is no coredump.
  For me it seems that althoug there is an "tkwait variable v2" in proc dialog2 the Konsole
  which ist started is still 'active'. )

  I tested the script with the versions 8.4.19 and 8.5.7 on windows and linux.
  The coredump only occurs on windows 8.5.7

  If I add an 'update' before 
     destroy .d1
  there is no core dump.


tkt_uuid: 2829363fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Treeview 'see' function
comment:
  Hi,

  I'm having a problem with the treeview 'see' command. If I create a treeview with several levels of hierarchy and try to see one of them with the see command. however, after issuing the command nothing happens until another event happen in the window. For example, with the following program:

  ttk::treeview .t -show tree 

  pack .t -side left -fill both -expand 1
  .t insert {} end -id a -text a
  .t insert a  end -id b -text b
  .t insert b  end -id c -text c

  after executing with
  > wish8.5
  % source prog.tk
  c
  % .t see c

  Then I need to do something like maximize the window or something like it, so that the item c is visible.

  Any help with this problem is appreciated.

  Best Regards,
  Daniel Barden


tkt_uuid: 2830360fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: ttk::entry looses state invalid at focus events
comment:
  Platforms: Unix X11 and Windows

  Example to reproduce
  %  pack .e
  % bind .e <FocusIn> {puts "%W <FocusIn> %d: [.e state]"}
  %  bind .e <FocusOut> {puts "%W <FocusOut> %d: [.e state]"}
  %  bind .e <Return> {.e state invalid}

  After pressing Return inside the field and focussing outside the entryfield,
  the state invalid is lost.
  It also happens if you set state invalid from  the console and focus into the entryfield.


tkt_uuid: 2830420fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: wm iconphoto under X11 works only for little endian machines
comment:
  OS: Solaris10 sparc

  tk8.6.b1.1 (CVS head)

  It looks like the byteorder for the _NET_WM_ICON property is wrong on big endian machines

  Suggested patch:

  (there may by more efficien ways)
  *** tkUnixWm.c.~1.71.~  Fri Apr  3 22:20:17 2009
  --- tkUnixWm.c  Fri Jul 31 17:55:35 2009
  ***************
  *** 2425,2435 ****
                          y*block.pitch + block.offset[2]);
                  A = *(block.pixelPtr + x*block.pixelSize +
                          y*block.pitch + block.offset[3]);
  !               pixelByte = (unsigned char *) &iconPropertyData[index];
  !               pixelByte[3] = A;
  !               pixelByte[2] = R;
  !               pixelByte[1] = G;
  !               pixelByte[0] = B;
                  index++;
              }
          }
  --- 2425,2437 ----
                          y*block.pitch + block.offset[2]);
                  A = *(block.pixelPtr + x*block.pixelSize +
                          y*block.pitch + block.offset[3]);
  !
  !                 /*
  !                  * Do not handoptimize the multiplications.
  !                  * Let the compiler do its job (think endianess)
  !                  */
  !                 iconPropertyData[index]= (((A*256)+R)*256+G)*256+B;
  !
                  index++;
              }
          }


tkt_uuid: 2830991fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 8
foundin: obsolete: 8.5.7
resolution: Invalid
title: Scrolling problem in Tk-Cocoa
comment:
  Rapid scrolling of a tablelist widget in Tk-Cocoa causes this crash error: 

  2009-08-01 22:10:01.909 Wish[395:10b] *** Assertion failure in +[NSEvent startPeriodicEventsAfterDelay:withPeriod:], /SourceCache/AppKit/AppKit-949.46/AppKit.subproj/NSEvent.m:1765
  2009-08-01 22:10:01.994 Wish[395:10b] An uncaught exception was raised
  2009-08-01 22:10:01.995 Wish[395:10b] Periodic events are already being generated
  2009-08-01 22:10:01.996 Wish[395:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Periodic events are already being generated'
  2009-08-01 22:10:01.997 Wish[395:10b] Stack: (
      140735390297052,
      140735374665935,
      140735390296645,
      140735348771047,
      140735363627265,
      140735364719298,
      140735363200221,
      140735362063667,
      140735361856246,
      4295758353,
      4295759600,
      4296889279,
      4295051574,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296483162,
      4296764007,
      4296481868,
      4296485160,
      4295760884,
      140735362077430,
      140735362077231,
      140735363205617,
      140735364719396,
      140735363200221,
      140735362063667,
      140735361856246,
      4295758353,
      4295759600,
      4296889279,
      4295051574,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296483162,
      4296764007,
      4296481868,
      4296485160,
      4295760884,
      140735362077430,
      140735362077231,
      140735363205617,
      140735363205344,
      140735363200179,
      140735362063667,
      140735361856246,
      4295758353,
      4295759600,
      4296889279,
      4295051574,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296483162,
      4296764007,
      4296481868,
      4296485160,
      4295760884,
      140735362077430,
      140735362077231,
      140735363205617,
      140735363204707,
      140735363200179,
      140735362063667,
      140735361856246,
      4295758353,
      4295759600,
      4296889279,
      4295077955,
      4295127767,
      4294985022,
      4294984940
  )
  terminate called after throwing an instance of 'NSException'

  I believe the issue is with Tk-Cocoa because the same script has normal scrolling with Tk-Carbon (both 8.5.3 and 8.4.7).  


  Below is the script that causes the error:

  package require tablelist


  image create photo folder -data {R0lGODlhEAAMAKEAAAD//wAAAPD/gAAAACH5\
              BAEAAAAALAAAAAAQAAwAAAIghINhyycvVFsB\
              QtmS3rjaH1Hg141WaT5ouprt2HHcUgAAOw==}

  image create photo filename -data {R0lGODlhDAAMAKEAALLA3AAAAP//
  8wAAACH5\
              BAEAAAAALAAAAAAMAAwAAAIgRI4Ha+IfWHsO\
              rSASvJTGhnhcV3EJlo3kh53ltF5nAhQAOw==}


  frame .listframe
  pack .listframe -fill both -expand yes



      tablelist::tablelist .listframe.listbox -columns {20 "File" 20 "Path"} -yscrollcommand [list .listframe.vsb set] -width 100 -height 10 -stretch all -showseparators no  -labelcommand tablelist::sortByColumn

  scrollbar .listframe.vsb -orient vertical -command [list .listframe.listbox yview]

  pack .listframe.listbox -side left -fill both -expand yes
  pack .listframe.vsb -side right -fill y -expand no


  for {set i 1} {$i < 6000} {incr i 1} {
       lappend numberlist [list file_$i path_$i]
  }

  foreach item $numberlist {
      .listframe.listbox insert end $item
   .listframe.listbox cellconfigure end,0 -image filename
   .listframe.listbox cellconfigure end,1 -image folder
  }


tkt_uuid: 2831084fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 1 Zero
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: "configure" lists takefocus twice on some ttk::*buttons
comment:
  Invoking configure on a ttk::button,  ttk::checkbutton or ttk::radiobutton lists the takefocus option twice with different values.

  WIDGET_TAKES_FOCUS is redundant with WIDGET_INHERIT_OPTIONS(BaseOptionSpecs)   in ttkButton.c

  Possible fixes :  
     * WIDGET_INHERIT_OPTIONS(BaseOptionSpecs)  checks for duplicates and does not override existing value.
     * -takefocus should not be in ttkCoreOptionSpecs


tkt_uuid: 2834772fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: Works For Me
title: ttk::combobox claims focus even if disabled
comment:
  There is an unguarded 'focus $w' statement in ::ttk::combobox::Press.
  It should be guarded by $w instate !disabled (see ::ttk::entry::Press).


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: 2837510fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Invalid
title: -displaylines gives unexpected result
comment:
  Please try the following script:
  -------------------------------------------------------
  pack [text .t -width 10 -height 1]
  .t insert end "abc"
  pack [label .l -text [.t count -displaylines 1.0 end]]
  -------------------------------------------------------
  The result "3" is not the number of display lines. The documentation says:
  -------------------------------------------------------
  -displaylines
      count all display lines (i.e. counting one for each time a line wraps) from the line of the first index up to, but not including the display line of the second index. Therefore if they are both on the same display line, zero will be returned. By definition displaylines are visible and therefore this only counts portions of actual visible lines.
  --------------------------------------------------------
  Therefore the result "1" is expected.


tkt_uuid: 2838812fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 68. Win Window Operations
priority: 7 High
foundin: None
resolution: None
title: Multi-purpose patch: fixes bug#1391053, adds wm attrs.
comment:
  Bug#1391053: spurious events generated on Windows after completion of tk_getOpenFile, tk_chooseColor and similar modal dialogs.  This patch, redone against CVS head, provides a real solution for this long-standing problem, instead of the current pseudo-solution that hurts but not helps (see win/tkWinDialog.c:EatSpuriousMessageBugFix).

  Steps to reproduce: (1) bind . <1> "puts Click"; bind . <3> tk_getOpenFile; maximize main window; right-click, then select a file. When the file dialog is closed on click-that-selects-a-file, you'll see the Click reaching the main window. Similar thing for closed Tk non-main toplevel windows by double-clicking on system menu icon: if another tk window happens to be under the click, it receives an event.

  Tk assumes that if a mouse button was released and is now pressed, then it must generate an event (Tk_UpdatePointer). This patch adds a special flag for Tk_UpdatePointer to take exception from this assumption. This modification proven to be useful for many other things during 4 years I maintain it for my projects.

  There is another obscure manifestation of a similar problem, related to non-client clicks (like WM_NCLBUTTONDOWN): tk really shouldn't generate ButtonDown on these events. This patch adds WM_NC* handling to the toplevel window procedure, using special flag for Tk_UpdatePointer to prevent these spurious events too, and another flag to prevent cursor shape changes for non-client areas).

  Unfortunately there are another things in this patch (separating them is not easy): support for wm attr -contexthelp (uses virtual <<Help>> event, no need to worry about event mask bits exhaustion); support for wm attr -shadow (recreates wrapper window with CS_DROPSHADOW). 

  To complicate things even more, this patch includes tkUnixRFont update for -underline and -overstrike support in Xft backed. This part can be separated :)

  I would like to see something done in this direction: while we can live without improvements, though they're discussed and accepted long ago, the bugs addressed by this patch are really annoying. E.g. a user does Menu->File->Open, and his file-selecting click goes directly to toolbar->New file :(
  Should I simply commit this whole thing myself? If it's unacceptable, can anyone provide the directions for refactoring it? Maybe I should wait 4 more years..


tkt_uuid: 2839285fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: MS Windows: Input: chars ĉ, ĝ, ĵ, ... come out as c, g, j...
comment:
  System: Windows XP SP3 on Athlon XP
  Problem occurs with:
  *ActiveTcl 8.5.7.0
  *ActiveTcl 8.4.19.1
  *tclkit-8.5.7-win32.upx.exe
  *tclkit-8.4.17-win32.upx.exe
  *tclkit-8.4.1-win32.upx.exe
  *tclkit-8.4.0-win32.upx.exe
  (Other versions have not been tested but are likely to suffer as well).

  (1) install Esperanto keyboard from http://sites.google.com/site/windowskeyboards/Home
  (2) run this script:
  entry .e
  pack .e
  console show
  bind .e <KeyPress> [list puts %k:%K:%N:%A]
  (3) now change to the newly installed keyboard layout and you will see that when typing "ŝ" into the entry (on your "q" key if you're using a standard english keyboard), Tk will only get a normal "s" instead of a "ŝ".
  This is not a font problem, as it works correctly to paste a ŝ copied from another app like notepad into the entry and copying the wrongly obtained "s" and pasting it into notepad only gives an "s". The problem lies somewhere in the keyboard input.
  See the log of the sample script when consecutively hitting: c, ĉ, g, ĝ, h, ĥ, j, ĵ, s, ŝ, u, ŭ:
  67:c:99:c
  88:c:99:c
  71:g:103:g
  219:g:103:g
  72:h:104:h
  221:h:104:h
  74:j:106:j
  89:j:106:j
  83:s:115:s
  81:s:115:s
  85:u:117:u
  87:u:117:u
  Obviously, the keycodes differ, but for some reason not the characters interpreted by Tk.

  Note that this only happens on Windows; on linux/X with epo keymap it works like a charm.

  Bug #1572922 might be related (but then again, it happens on Linux, and this one on Windows).


tkt_uuid: 2841623fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: None
title: tkMacOSXHLEvents.c update
comment:
  The code in tkMacOSXHLEvents.c hasn't been modernized for Mac OS X and changes in the AppleScript/AppleEvent areas. This package includes replacement code which optionally uses new namespaced handler procs. It will fall through to the old procs and their respective C code handlers if the new procs are not found. It supplies an example application with an AppMain.tcl that will branch for new/old proc handlers and example AppleScripts illustrating the new handler calls. The new code allows Tk application developers to create custom named commands which take an argument list as the direct parameter to the AppleScript command.

  Included are instructions showing how to generate the aete resource from the new style sdef XML files and where to place them in the distribution Wish.app.

  For Tk application developers, there are also instructions for how enable their application to use customized handlers. 


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


tkt_uuid: 2844964fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Invalid
title: (also tcl 2844962) Tcl_UpdateLinkedVar doesn't trigger widge
comment:
  Also tested in 8.5.7, same behavior.
  Also tried ENTRY widgets

  OS Platform & Version WinXP with SP3

  Problem Behavior
  Updates to linked C variables do not trigger widget updates.

  If I update a Tcl variable that is tied to a widget, the widget is
  automatically updated, presumably via hooks similar to the trace mechanism.
  Unfortunately, this does not seem to occur if the variables are tied to C
  variables. Calling Tcl_UpdateLinkedVar() *does* update the Tcl-side, since
  the following proc demonstrates the updates are occurring by displaying the
  Tcl-side values every two seconds when called via "Update 2000":

  proc Update {interval} {
  if {$::Thresh} {
  puts "***************************************************************"
  puts "Red: $::RMax"
  puts "Green: $::GMax"
  puts "Blue: $::BMax"
  puts "Interval $interval"
  update
  }
  after $interval "Update $interval"
  }

  Even though the Tcl variables reflect the updates, the widget values DO NOT
  refresh until I manipulate the widget window (e.g. resize).

  Below are the pertinent code snippets. I originally tried defining
  R/G/BMax as longs, and using them directly, but it occurred to me that
  perhaps the update needed to have string variables since the widgets use
  "-textvariable" options. Changing the code to the below code had the same
  behavior. I also tried calling Tcl_InvalidateStringRep() in the same C
  routine which calls Tcl_UpdateLinkedVar() with no changes to behavior.

  ***tcl***
  label .v2.lrmax.rMax -textvariable ::RMax
  label .v2.lgmax.gMax -textvariable ::GMax
  label .v2.lbmax.bMax -textvariable ::BMax

  ***init***
  sRMax = Tcl_Alloc(256);
  sGMax = Tcl_Alloc(256);
  sBMax = Tcl_Alloc(256);
  Tcl_LinkVar(theInterp, "::RMax", (char *) &sRMax,
  TCL_LINK_STRING | TCL_LINK_READ_ONLY);
  Tcl_LinkVar(theInterp, "::GMax", (char *) &sGMax,
  TCL_LINK_STRING | TCL_LINK_READ_ONLY);
  Tcl_LinkVar(theInterp, "::BMax", (char *) &sBMax,
  TCL_LINK_STRING | TCL_LINK_READ_ONLY);

  ***update***
  sprintf(sRMax, "%lu", RMax);
  Tcl_UpdateLinkedVar(mainInterp, "::RMax");
  sprintf(sGMax, "%lu", GMax);
  Tcl_UpdateLinkedVar(mainInterp, "::GMax");
  sprintf(sBMax, "%lu", BMax);
  Tcl_UpdateLinkedVar(mainInterp, "::BMax");


tkt_uuid: 2847319fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: None
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: 2848897fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 6
foundin: None
resolution: Accepted
title: ODS_NOACCEL flag support
comment:
  One of user-configurable features of win2000 and above is "Hide keyboard navigation indicators until I press the Alt key", and Tk ignored it for a long time. Menu bars, as they are drawn by the system, behaved as configured, but owner-draw entries were underlined independently of this setting.

  This patch adds checking for ODS_NOACCEL flag in the menu window procedure, so the setting referred to above is obeyed by Tk.


tkt_uuid: 2854590fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: TkMacOSXVisableClipRgn typo
comment:
  It is "visible" not "visable".  This is in the stubs table so it should get fixed before extension writers start using it everywhere.


tkt_uuid: 2857300fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 9 Immediate
foundin: obsolete: 8.6b1
resolution: Accepted
title: Tk_MeasureChars rounding error
comment:
  In tkMacOSXFont.c the lround() function is used to convert double -> integer.
  The problem is that lround() will round to the *nearest* integer.  So lround(10.2)
  equals 10 while lround(10.6) equals 11.

  Since the width of the text is needed, ceil() should be used to round up fractional
  numbers.


tkt_uuid: 2858503fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: "end" flag for ttk::combobox current
comment:
  the ttk::combobox widget has a "current" method which allow to choose which item of the list given to the combobox to be displayed. Unfortunatly, this method doesn't accept the "end" mark, specifying the end of the list.
  It would be great to have to "end" indice available in order to avoid computation of the length of the list before invoking <pathname> current method.


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: 2860363fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: None
title: Add a command to list available image handlers
comment:
  There is currently no way to request a list of available image handlers, e.g. for use by [image data -format ___].  This list may vary depending on which extensions are loaded.  A subcommand could be added to produce a list, such as { gif ppm }, listing all valid options to the -format flag.


tkt_uuid: 2860519fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: None
title: canvas polygon -fill default behavior wrong
comment:
  According to the canvas man page, drawing a polygon with option "-fill {}" is supposed to be equivalent to the default behavior (i.e. no fill).  However, when -fill option is not specified, the polygon is filled (incorrect); while when "-fill {}" is specified, the polygon is not filled (correct).

  Example code:

  package require Tk
  canvas .c
  .c create polygon 96 103 121 120 160 115 174 85 99 33 -outline black
  pack .c
  destroy .c
  canvas .c
  .c create polygon 96 103 121 120 160 115 174 85 99 33 -outline black -fill {}
  pack .c

  Tested on Ubuntu Hardy using ActiveTcl 8.5.5

  same behavior in ver 8.4.19


tkt_uuid: 2860827fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 02. Appearance
priority: 4
foundin: obsolete: 8.5.7
resolution: Fixed
title: Rendering text of disabled label widgets on Windows
comment:
  Tk 8.5 on Windows started to paint "shadows" for text in disabled labels, checkboxes, buttons in order to give them 3d look. Tk 8.4 didn't do that. Shadow color is determined by calling GetSysColor(COLOR_3DHILIGHT) (see tkWinButton.c). 

  Such behaviour makes it impossible to fully customize appearance of disabled widgets on Tcl level and leads to horrible widget rendering in cases of non-standard background color. See attached Tkabber screenshot.

  Probably, reasonable solution of this problem would be to add either an additional Tk option for this shadow color value (which defaults to what GetSysColor returns) or an option for switching this look-and- feel trick with shadow on and off.


tkt_uuid: 2863003fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 48. Geometry Management
priority: 6
foundin: None
resolution: None
title: Add a virtual event when GM leaves parent without slaves
comment:
  When trying to build a custom scrolledframe one generally resorts to the <Configure> event to catch the resizing of the scrolled frame [usually a frame inside a canvas] to keep scrollbars in sync. The problem with this approach is that, when the last slave is removed from inside the frame, the geometry managers leave the frame size as-is, and the scrolled frame ends scrolling an empty region.
  This can be noted in this BWidget example:
  ==================================================
  package require BWidget

  set sw [ScrolledWindow .sw]
  set sf [ScrollableFrame .sf]
  $sw setwidget $sf
  set f [$sf getframe]

  pack $sw -expand 1 -fill both -padx 10 -pady 10

  for {set i 0} {$i <= 20} {incr i} {
  grid \
  [label $f.la$i -text "Label a order $i"] \
  [label $f.lb$i -text "Label b order $i"] \
  [label $f.lc$i -text "Label c order $i"]
  }

  after 5000 {destroy {*}[winfo children $sf]}
  =================================================

  A way to note when the GM removes the last slave is to deliver a virtual event to the master.
  This patch adds the virtual event, and is intended as a sketch of the final code (the name of the
  virtual event, and whether to send additional details or not can be changed)


tkt_uuid: 2864685fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: Fixed
title: Compiz animates each menu item as a new window
comment:
  Compiz somehow thinks that the menus of these apps are separate windows and applies window open and close animation to them. Thus each submenu "pulses" like ordinary window when opened and navigating a menu (specially one with zero delay) looks like a firework.


tkt_uuid: 2865578fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: Changin menu in fullscreen mode messes with geometry
comment:
  Summary says it all. Running attached script either increases window size by menu height or leaves the window to maximized state. Observed with Fedora 11, Linux 2.6.29.6, KDE 4.3.1.


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


tkt_uuid: 2874226fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 82. X11 Emulation
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: None
title: polygon don't honor -joinstyle on Windows
comment:
  Under Windows, the following code:

  pack [canvas .c]
  set id [.c create polygon {20.0 20.0 50.0 50.0 30.0 80.0 20.0 50.0 20.0 30.0}]
  .c itemconfigure $id -fill red -outline black -width 10 -joinstyle miter

  shows a polygon with a round close point, while the -joinstyle is miter.

  See the attached image: left is Unix, right is Windows.

  Documentation of XDrawLines() says that it honors joinstyle if first and last point are identical.
  The XDrawLines() implementation in tkWinDraw.c should do the same thing.

  Or is it a limitation of GDI Polygon function?


tkt_uuid: 2874745fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: TEA 3.6 incompatible TK_INCLUDE_SPEC define
comment:
  TEA 3.6 defines  the include path to the Tk header files in TK_INCLUDES .  The Tk configuration file tkConfig.sh does not define TK_INCLUDES but rather TK_INCLUDE_SPEC.  As a result, compiles with TEA 3.6 fail for extensions that want to see TK_INCLUDE in the Makefile.in file. An example that uses TEA 3.6 is itclwidgets4.0.  Solution is to define both in the tkConfig.sh  and update the tcl.m4 file associated with TEA 3.6 to AC_SUBST both.  


tkt_uuid: 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: 2876709fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Recreating menu appends duplicate entries
comment:
  In Tk-Cocoa, I've observed that if one tries to reset/recreate a specified menu, the old menu isn't updated in place, but instead has additional, redundant entries appended to the end of the menu. Here's how I reproduce this step:

  1. Run the Tk widget demo in Wish.
  2. Choose the "menu demonstration" demo.
  3. Select the "see code" button from the menu demonstration. 
  4. The menu has these entries: File, Basic, Cascades, Icons, More, Colors.
  5. Click the "see code" button in the demo window.
  6. The code window pops up; select the "rerun demo" window.
  7. Instead of having the menu re-created in place, the menu now appends these entires: Basic, Icons, Colors. The entire menu looks like this: 
   File, Basic, Cascades, Icons, More, Colors, Basic, Icons, Colors. 

  The menu should not behave this way. 

  I first  observed this behavior in IDLE, a Python/Tkinter application, when it's linked to Tk-Cocoa. I originally thought it was a problem with IDLE's code, but after reproducing the behavior in Tk itself, I believe it's something that needs to be addressed in Tk. 


tkt_uuid: 2878941fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: Tcl_ExternalToUtf(...dst, dstLen,...) writes to dst[dstLen]
comment:
  The docs of Tcl_ExternalToUtf() are unclear on the
  boundaries of the write buffer.  They say "... and up
  to dstLen converted bytes are  stored  in  dst." which
  suggests bytes will be written in dst[0] up 
  to dst[dstLen-1].  And that appears to be an accurate
  description of what the underlying ToUtfProc() does.
  However, then Tcl_ExternalToUtf() appends a terminating
  NUL character, and if the ToUtfProc has used all dstLen
  bytes, T_ETU writes to dst[dstLen].


tkt_uuid: 2879789fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 7 High
foundin: obsolete: 8.6b1
resolution: Fixed
title: Item activating does not work as expected in torn-off menus
comment:
  Consider the following example:


  . configure -menu .m

  menu .m
  .m add cascade -label "test" -menu .m.t

  menu .m.t
  .m.t add cascade -label "one" -menu .m.t.s1
  .m.t add cascade -label "two" -menu .m.t.s2

  menu .m.t.s1
  menu .m.t.s2



  Tear the "test" menu off. Expand the menu window width for better effect. Now move the mouse pointer over the submenu arrows - no item gets activated. Item activation occurs only when you move the mouse pointer between the left edge of the menu and the end of the menu item label, but when the item gets activated, the highlight is as wide as the menu window.

  The attached patch fixes this behaviour to what one would expect from a real menu.


tkt_uuid: 2879927fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 7 High
foundin: obsolete: 8.5.8
resolution: Fixed
title: Wrong color of submenu arrow in torn-off menu
comment:
  When a menu item is not activated, its label is drawn in black, and when activated - in white (given standard Windows settings), but the submenu arrow (if the item is actually a submenu, of course) is drawn in black, whether it is "activated" or "normal". The real menu draws the arrow in white when the item is activated.

  The attached patch fixes this behaviour.


tkt_uuid: 2879930fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Wont Fix
title: Disabled menu items do not get highlighted in torn-off menus
comment:
  Standard Windows behaviour is to highlight a menu item when a mouse moves over it, whether the item is enabled or not. The real menus do so, but when the menu with disabled items is torn-off, these disabled items are not highlighted on mouse move.


tkt_uuid: 2883712fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: ttk::scale and ::progressbar display broken (OS X + x86_64)
comment:
  Running 64-bit, these two widgets don't update their controls: scale is pinned to the left and progressbar never progresses. This behavior happens on the default 10.6 Tk (8.5.7) and git://github.com/das/tcltk.git (de-carbon-8-5), which I gathered is nearly identical to the version included with 10.6.

  Issue looks like it's here at ttkMacOSXTheme.c:579:

      factor = ((double)(LONG_MAX>>1))/(to - from);

  and ttkMacOSXTheme.c:691:

      factor = ((double)(LONG_MAX>>1))/maximum;

  factor then is used to scale min/max/value parameters for HIThemeTrackDrawInfo fields that are typed SInt32. On 64-bit arch, the factor is much larger than SInt32 can represent for many "normal" min/max pairs, which on casting pins min, max, and value to INT_MIN. As a result the controls never update. 

  Suggested solutions: (1) hardcode a static 32-bit max constant in place of LONG_MAX or (2) add __LP64__ ifdef switch to use INT_MAX on 64-bit instead.

  Making such a change restores the ttk::scale and ::progressbar behavior.


tkt_uuid: 2886436fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 4
foundin: obsolete: 8.5.7
resolution: None
title: [.txt delete] still deletes before startindex
comment:
  Consider following code:
  pack [text .t]
  .t insert end foo\nbar
  .t delete 2.0 end

  This should only delete the second line ("bar"), and leave "foo\n" in the text. However, it actually deletes the newline too, leaving only "foo". This is wrong, since [.t delete 2.0 end] should *never* delete anything before index 2.0 !

  I'm here proposing the same patch as in tracker 1854913. That one was closed with a different solution, fixing only the symptoms in interactive mode (<Delete> key deleting backwards), but not the cause.

  Apparently, the proposed patch broke 'text-19.8' of the tk testsuite. In my opininion, that test is wrong. It deletes from index 4.0, and then checks that the selection tag ends at index 3.5. But it should still include the newline at the end of line 3. (Without this patch, that newline did not exist anymore!)

  I've attached a file which includes the original solution for 1854913, and a patch for test-19.8.


tkt_uuid: 2886635fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: tkPlatDecls.h no longer C++ friendly
comment:
  For a few public Tk routines, such as Tk_GetHWND(),
  it is documented that the header file tkPlatDecls.h
  need to be #include-d.

  Appears that a side-effect of some CONST-ifying
  of the stubs machinery was to remove some
  extern "C" wrapping.  The consequence is that
  #include <tkPlatDecls.h> in a C++ compile no
  longer works.

  Attached is a patch from kbk, to review and test.

  Assigning to the source of the tkPlatDecls.h
  revisions so we can check we're not undoing
  anything important with the patch.

  Thanks to Georgios Petasis for reporting
  the problem.


tkt_uuid: 2886983fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Works For Me
title: -indicatoron no effect on menu radiobuttons
comment:
  If a menu is created with multiple radiobutton entries, using "-indicatoron 1" on one of the entries has no effect.  The value of the designated variable overrides the option.  If the designated variable is unset, the flag still has no effect.

  Example:

  unset -nocomplain selectedButton
  set m [menu .m -tearoff 0]
  $m add radiobutton -label Accept -indicatoron 1
  $m add radiobutton -label Reject
  $m add radiobutton -label Undecided
  tk_popup $m 0 0

  The menu that appears has no menu entries selected.

  Example 2:

  destroy .m
  set selectedButton Reject
  set m [menu .m -tearoff 0]
  $m add radiobutton -label Accept -indicatoron 1
  $m add radiobutton -label Reject
  $m add radiobutton -label Undecided
  tk_popup $m 0 0

  the menu that appears has "Reject" selected despite the use of the -indicatoron flag.

  Version 8.5.5 on Ubuntu Hardy.


tkt_uuid: 2886998fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Duplicate
title: -indicatoron no effect on menu radiobuttons
comment:
  When creating a menu with multiple radiobutton entries, using "-indicatoron 1" on one of the entries has no effect.  If the designated variable for the entries is unset, no entries have an indicator on when the menu is displayed.  If the designated variable is set for one of the entries, that entry has its indicator on, even if "indicatoron 1" is set for another entry.

  Example 1:

  set selectedButton Reject
  set m [menu .m -tearoff 0]
  $m add radiobutton -label Accept -indicatoron 1
  $m add radiobutton -label Reject
  $m add radiobutton -label Undecided
  tk_popup $m 0 0

  the menu that appears has the "Reject" entry selected.  The "-indicatoron 1" flag is ignored.

  Example 2:

  destroy .m
  unset selectedButton
  set m [menu .m -tearoff 0]
  $m add radiobutton -label Accept -indicatoron 1
  $m add radiobutton -label Reject
  $m add radiobutton -label Undecided
  tk_popup $m 0 0

  the menu that appears has no entries selected.  The "-indicatoron 1" flag is again ignored.

  version 8.5.5 on Ubuntu Hardy using Gnome.


tkt_uuid: 2887486fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: None
title: Use GTK+/Qt theme on Linux/Unix
comment:
  Please add support for using the current Qt or GTK+ theme in Tk. This would help make Tk look more native under KDE and GNOME.


tkt_uuid: 2891541fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: Fixed
title: Grab on . prevents minimizing app on Windows.
comment:
  For bug #1847002 we added some restrictions for system commands when a grab is present. One of the changes was to prevent grabbed toplevels from being minimized as this can confuse users if the only active window in a Tk app disappears.
  Unfortunately it seems that some applications manage to leave a grab on the main window. This now prevents the application from being minimized although everything else is normal.
  Therefore the previous modification -- deny minimize when a grab is present -- must be changed to deny minimize when a grab is present except when the grab is on the mainwindow (.) and . is the window to be minimized. (This comes out shorter in code).
  The application presenting this problem is 'git gui' and their bug is http://code.google.com/p/msysgit/issues/detail?id=301


tkt_uuid: 2891877fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: 32k pixel limit when viewing a scrolled frame on a canvas
comment:
  I was told at Tcl 2009 that Tk windows on X11 should no longer have a 32k pixel limit, and any such limitations should be reported as bugs.

  A canvas item that is a frame can be much larger than 32k pixels, but the region that can be viewed by scrolling is never much more than 32k.

  The attached file is a test that demonstrates the problem.

  Tested on ActiveTcl 8.5.7.1 and 8.6.0.0b2, Linux x86 with X-server Xorg-1.5.3


tkt_uuid: 2896501fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Windows: Filenames limit with tk_getFileName -multiple 1
comment:
  Platform: Windows-XP:

  The -multiple option for the tk_getFileName command returns 0 if the total length of the filenames a certain threshold:

  Assuming I create 480 files using this oneliner:

  $ perl -e 'for $x (1..480) { open OUT, ">file-longname$x.txt" ; print OUT "Hi\n" ; close OUT ; }'

  If I select all those files:
  llength "[tk_getOpenFile -multiple true -initialdir c:/temp/test_TclTk2/]"

  would return 0

  If I reduce the number of files to 440 the same command would return 440.

  If I use shorter filenames I can select more files.

  For 700 files:
  $ rm *.txt
  $ perl -e 'for $x (1..700) { open OUT, ">file$x.txt" ; print OUT "Hi\n" ; close OUT ; }'

  % llength "[tk_getOpenFile -multiple true -initialdir c:/temp/test_TclTk2/]"
  700

  This behaviour is quite annyoing as the number of files which can be selected depends on the filenname length off the files.

  As tested with a Csharp-Program the native Windows-Dialog allows selection of more files regardless of the filenames length.
  regards,
  dgroth


tkt_uuid: 2896605fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: None
title: Change to grab on windows breaks application behaviour
comment:
  I have discovered that changes to the grab command on windows in tk 8.5.7 have broken some application behaviour, compared to 8.5.6 and all previous versions.

  In my applications I have a home grown "busy" command.  Among other things this sets the wait cursor, and grabs mouse events and directs them to a frame with no mouse bindings.  This may be superceeded at some stage by the tk 8.6 builtin command, but for the moment I use it extensively.

  The busy command is used for any long operations.  This includes initialising some complicated child application windows.  So the sequence is something like:

  # Make busy
  grab set ._busy

  # Create new child application window

  toplevel .app1
  wm withdraw .app1

  # Lots of application window initialisation....
  # Then show new window & unbusy.

  wm deiconify .app1
  grab release ._busy

  Unfortunately the changes to the grab command on windows in tk 8.5.7 mean that the "wm deiconify" forces a raise of the root window, which contains the grab frame.  So this is raised in front of and obscures the new child window the user has just invoked.

  As I said, I use this busy mechanism extensively, including in a command dispatcher system, and I have not been able to think of a practical workaround yet.


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

  thanks
  Ilya


tkt_uuid: 2898255fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 9 Immediate
foundin: None
resolution: Accepted
title: Patch for bug #2896501 (Filenames limit with tk_getOpenFile)
comment:
  This is a proposed patch for bug Windows: Filenames limit with tk_getFileName -multiple 1 (https://sourceforge.net/tracker/?func=detail&aid=2896501&group_id=12997&atid=112997)

  The patch allows to select virtually any number of files in tk_getOpenFile, because it dynamically allocates a buffer of required size to accomodate all selected files. The dialog itself will still return FNERR_BUFFERTOOSMALL, but the selected files are returned in custom buffer and can be retrieved.

  Tested with Windows SDK "include" directory containing 1700+ files - all selected files were returned.


tkt_uuid: 2899685fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 9 Immediate
foundin: obsolete: 8.6b1
resolution: Fixed
title: Artefact line segments with canvas imove
comment:
  Tested on WinXP SP 2 only now.

  The script:
  ---
  canvas .c
  button .b -command {doit} -text "Bug"
  grid .c
  grid .b

  set id [.c create line 10 10 40 10 100 100]

  proc doit {} {
  global id
  .c imove $id 1 200 200
  .c imove $id 1 30 20
  }
  ---

  Launch it. Press "bug" button. I see horizontal line fragment from top left corner.
  Now resize window. The fragment disappears.


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

  wish85.exe core-858.tcl

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

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


tkt_uuid: 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: 2900796fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Wont Fix
title: ttk widgets do not initialize the textvariable
comment:
  % entry .e -textvariable e
  % info exists e
  1
  % ttk::entry .e -textvariable e
  .e
  % info exists e
  0

  This requires you to either initialize it ahead of it's use or requires you to check info exists before any use of the variable.


tkt_uuid: 2901053fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: iconified toplevel cannot be restored (Windows only)
comment:
  The attached example causes the following problem:

  1. Start: wish desktop.tcl
  2. Press Button "Dialog" -> Application modal toplevel appears
  3. Iconify all existing windows using the "Show Desktop"-Button right next to the Start-Button of the Taskbar
  4. Start another Application (eg. firefox)
  5. Try to restore the iconified TK-App using its icon in the taskbar -> nothing happens !!!!


  Workaround:
  The only way to restore the dialog is to push it to the foreground with the Windows Task Manager. 
  But this can mean that it is shown everytime another application is started. 

  Comment:
  The problems only occurs if the dialog is application-modal. The grab command 
  seems to cause the problem.The example has been taken 
  from the Iwidgets Shell Widget class and has beem changed so that it runs without 
  Itk, Itcl and Iwidgets. The implementation is very similar to the TCL script 
  implementation of the tk_messageBox dialog for Unix.


tkt_uuid: 2902081fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 50. [pack]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: pack propagate not working correctly
comment:
  Using Tcl/Tk 8.5.7, I have troubles making pack propagate work correctly. It does not seem to work back and forth. I have to set the width / height property on a packed widget after calling pack propagate xxx to have the pack propagate command effective. I will attach some code demonstrating this. In this code, if you remove the width property setting command, then it no longer works.


tkt_uuid: 2902214fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 70. Event Loop
priority: 8
foundin: obsolete: 8.5.6
resolution: None
title: Crash in X11 input-method handling with chinese locale
comment:
  bug shows here: http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/43fca0b5fbce3398/785ae0ad16e3ca37?pli=1

  I found only one line corrected, we can solve this problem. (maybe just skip, but anyway wish can run):
  line 365  in tkEvent.c :
  XGetICValues(winPtr->inputContext, XNFilterEvents, &im_event_mask, NULL);
  =>    if (winPtr->inputContext != NULL)  XGetICValues(winPtr->inputContext, XNFilterEvents, &im_event_mask, NULL);


tkt_uuid: 2902573fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: new failing tests
comment:
  ==== safe-1.1 Safe Tk loading into an interpreter FAILED
  ==== Contents of test case:

      safe::loadTk [safe::interpCreate a]
      safe::interpDelete a
      set x {}
      return $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk [safe::interpCreate a]"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-1.1 FAILED



  ==== safe-1.2 Safe Tk loading into an interpreter FAILED
  ==== Contents of test case:

      safe::interpCreate a
      safe::loadTk a
      lsort [interp hidden a]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk a"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-1.2 FAILED



  ==== safe-1.3 Safe Tk loading into an interpreter FAILED
  ==== Contents of test case:

      safe::interpCreate a
      safe::loadTk a
      lsort [interp aliases a]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk a"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-1.3 FAILED



  ==== safe-2.1 Unsafe commands not available FAILED
  ==== Contents of test case:

      safe::interpCreate a
      safe::loadTk a
      set status broken
      if {[catch {interp eval a {toplevel .t}} msg]} {
          set status ok
      }
      return $status

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk a"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-2.1 FAILED



  ==== safe-2.2 Unsafe commands not available FAILED
  ==== Contents of test case:

      safe::interpCreate a
      safe::loadTk a
      set status broken
      if {[catch {interp eval a {menu .m}} msg]} {
          set status ok
      }
      return $status

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk a"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-2.2 FAILED



  ==== safe-2.3 Unsafe subcommands not available FAILED
  ==== Contents of test case:

      safe::interpCreate a
      safe::loadTk a
      set status broken
      if {[catch {interp eval a {tk appname}} msg]} {
          set status ok
      }
      list $status $msg

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk a"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-2.3 FAILED



  ==== safe-2.4 Unsafe subcommands not available FAILED
  ==== Contents of test case:

      safe::interpCreate a
      safe::loadTk a
      set status broken
      if {[catch {interp eval a {tk scaling}} msg]} {
          set status ok
      }
      list $status $msg

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk a"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-2.4 FAILED



  ==== safe-3.1 Unsafe commands are available hidden FAILED
  ==== Contents of test case:

      safe::interpCreate a
      safe::loadTk a
      set status ok
      if {[catch {interp invokehidden a toplevel .t} msg]} {
          set status broken
      }
      return $status

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk a"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-3.1 FAILED



  ==== safe-3.2 Unsafe commands are available hidden FAILED
  ==== Contents of test case:

      safe::interpCreate a
      safe::loadTk a
      set status ok
      if {[catch {interp invokehidden a menu .m} msg]} {
          set status broken
      }
      return $status

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk a"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-3.2 FAILED



  ==== safe-4.1 testing loadTk FAILED
  ==== Contents of test case:

      # no error shall occur, the user will
      # eventually see a new toplevel
      set i [safe::loadTk [safe::interpCreate]]
      interp eval $i {button .b -text "hello world!"; pack .b}
      # lets don't update because it might imply that the user has
      # to position the window (if the wm does not do it automatically)
      # and thus make the test suite not runable non interactively
      safe::interpDelete $i

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk [safe::interpCreate]"
      ("uplevel" body line 4)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-4.1 FAILED



  ==== safe-4.2 testing loadTk -use FAILED
  ==== Contents of test case:

      set w .safeTkFrame
      destroy $w
      frame $w -container 1;
      pack .safeTkFrame
      set i [safe::loadTk [safe::interpCreate] -use [winfo id $w]]
      interp eval $i {button .b -text "hello world!"; pack .b}
      safe::interpDelete $i
      destroy $w

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 28)
      invoked from within
  "safe::loadTk [safe::interpCreate] -use [winfo id $w]"
      ("uplevel" body line 6)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-4.2 FAILED



  ==== 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: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk $j"
      ("uplevel" body line 7)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-5.2 FAILED



  ==== safe-6.1 loadTk -use windowPath FAILED
  ==== Contents of test case:

      set w .safeTkFrame
      destroy $w
      frame $w -container 1;
      pack .safeTkFrame
      set i [safe::loadTk [safe::interpCreate] -use $w]
      interp eval $i {button .b -text "hello world!"; pack .b}
      safe::interpDelete $i
      destroy $w

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 28)
      invoked from within
  "safe::loadTk [safe::interpCreate] -use $w"
      ("uplevel" body line 6)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-6.1 FAILED



  ==== safe-6.2 loadTk -use windowPath, conflicting -display FAILED
  ==== Contents of test case:

      set w .safeTkFrame
      destroy $w
      frame $w -container 1;
      pack .safeTkFrame
      set i     [safe::interpCreate]
      catch {safe::loadTk $i -use $w -display :23.56} msg
      string range $msg 0 36

  ---- Result was:
  invalid command name "DeleteHookName"
  ---- Result should have been (exact matching):
  conflicting -display :23.56 and -use
  ==== safe-6.2 FAILED



  ==== safe-7.1 canvas printing FAILED
  ==== Contents of test case:

      set i [safe::loadTk [safe::interpCreate]]
      interp eval $i {canvas .c; .c postscript}

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0
  ---- errorInfo: invalid command name "DeleteHookName"
      while executing
  "DeleteHookName $slave"
      (procedure "safe::loadTk" line 22)
      invoked from within
  "safe::loadTk [safe::interpCreate]"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-7.1 FAILED


