# ticket

tkt_uuid: 2507326fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: build problem with amsn and 8.6b1
comment:
  This artifact is meant to fix the build problem in amsn,
  as discussed in:
  <http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/3685995>

  After studying the aMSN code, aMSN assumes that Tk makes
  an internal copy of formatPtr->name, although Tk documents
  that formatPtr->name must be available during the full
  lifetime of the thread.

  Making a copy, as Tk 8.5.5 and earlier did, adds only
  4 lines of code to Tk, so it is much simpler to implement
  than any other solution. Will do that.


tkt_uuid: 220738ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: core dump for menus using two screens
comment:
  OriginalBugID: 5454 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-11'
  LastModified: '2000-05-11'
  Severity: CRIT
  Status: Released
  Submitter: hobbs
  ChangedBy: hobbs
  OS: All Unix
  FixedDate: '2000-05-11'
  FixedInVersion: 8.4a1


  Tk8.3.1 cores on the following script:


    toplevel .one

    menu .one.m

    toplevel .two -screen :1

    menu .two.m

    destroy .one


  The output of this script is:


    Tk_Get3DBorderFromObj called with non-existent border!

    Aborted (core dumped)


  You have to have two X servers running for this to work,

  of course.  Change the -screen option as appropriate.  Before

  running the script above I did this:


      Xnext -geometry 640x480 :1 & fvwm -display :1 &


  Patch: generic/{tk3d.c,tkColor.c,tkCursor.c} tests/menu.test

  diff -c -r tk8.3.1/generic/tk3d.c tk8.3.1.mod/generic/tk3d.c

  *** tk8.3.1/generic/tk3d.cTue Dec 21 18:55:10 1999

  --- tk8.3.1.mod/generic/tk3d.cThu May 11 15:20:47 2000

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

  *** 501,506 ****

  --- 501,507 ----

        Tcl_Obj *objPtr;/* The Tcl_Obj * to be freed. */

    {

        Tk_Free3DBorder(Tk_Get3DBorderFromObj(tkwin, objPtr));

  +     FreeBorderObjProc(objPtr);

    }

    

    /*

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

  *** 1263,1299 ****

    InitBorderObj(objPtr);

        }


  !     borderPtr = (TkBorder *) objPtr->internalRep.twoPtrValue.ptr1;

  !     if (borderPtr != NULL) {

  ! if ((borderPtr->resourceRefCount > 0)

  ! && (Tk_Screen(tkwin) == borderPtr->screen)

  ! && (Tk_Colormap(tkwin) == borderPtr->colormap)) {

  !     /*

  !      * The object already points to the right border structure.

  !      * Just return it.

  !      */


  !     return (Tk_3DBorder) borderPtr;

  ! }

  ! hashPtr = borderPtr->hashPtr;

  ! FreeBorderObjProc(objPtr);

  !     } else {

  ! hashPtr = Tcl_FindHashEntry(&dispPtr->borderTable, 

  !                 Tcl_GetString(objPtr));

  ! if (hashPtr == NULL) {

  !     goto error;

  ! }

        }


        /*

  !      * At this point we've got a hash table entry, off of which hang

  !      * one or more  TkBorder structures.  See if any of them will work.

         */

  ! 

        for (borderPtr = (TkBorder *) Tcl_GetHashValue(hashPtr);

        (borderPtr != NULL); borderPtr = borderPtr->nextPtr) {

    if ((Tk_Screen(tkwin) == borderPtr->screen)

    && (Tk_Colormap(tkwin) == borderPtr->colormap)) {

        objPtr->internalRep.twoPtrValue.ptr1 = (VOID *) borderPtr;

        borderPtr->objRefCount++;

        return (Tk_3DBorder) borderPtr;

  --- 1264,1311 ----

    InitBorderObj(objPtr);

        }


  !     /*

  !      * If we are lucky (and the user doesn't use too many different

  !      * displays, screens, or colormaps...) then the  TkBorder 

  !      * structure we need will be cached in the internal

  !      * representation of the Tcl_Obj.  Check it out...

  !      */


  !     borderPtr = (TkBorder *) objPtr->internalRep.twoPtrValue.ptr1;

  !     if ((borderPtr != NULL)

  !     && (borderPtr->resourceRefCount > 0)

  !     && (Tk_Screen(tkwin) == borderPtr->screen)

  !     && (Tk_Colormap(tkwin) == borderPtr->colormap)) {

  ! /*

  !  * The object already points to the right border structure.

  !  * Just return it.

  !  */

  ! return (Tk_3DBorder) borderPtr;

        }


  + 

  + 

  + 

        /*

  !      * If we make it here, it means we aren't so lucky.  Either there

  !      * was no cached TkBorder in the Tcl_Obj, or the TkBorder that was

  !      * there is for the wrong screen/colormap.  Either way, we have

  !      * to search for the right TkBorder.  For each color name, there is

  !      * linked list of TkBorder structures, one structure for each 

  !      * screen/colormap combination.  The head of the linked list is

  !      * recorded in a hash table (where the key is the color name)

  !      * attached to the TkDisplay structure.  Walk this list to find

  !      * the right TkBorder structure.

         */

  !     hashPtr = Tcl_FindHashEntry(&dispPtr->borderTable, Tcl_GetString(objPtr));

  !     if (hashPtr == NULL) {

  ! goto error;

  !     }

        for (borderPtr = (TkBorder *) Tcl_GetHashValue(hashPtr);

        (borderPtr != NULL); borderPtr = borderPtr->nextPtr) {

    if ((Tk_Screen(tkwin) == borderPtr->screen)

    && (Tk_Colormap(tkwin) == borderPtr->colormap)) {

  +      FreeBorderObjProc(objPtr);

        objPtr->internalRep.twoPtrValue.ptr1 = (VOID *) borderPtr;

        borderPtr->objRefCount++;

        return (Tk_3DBorder) borderPtr;

  Only in tk8.3.1.mod/generic: tk3d.c.orig

  diff -c -r tk8.3.1/generic/tkColor.c tk8.3.1.mod/generic/tkColor.c

  *** tk8.3.1/generic/tkColor.cFri Nov 19 17:00:02 1999

  --- tk8.3.1.mod/generic/tkColor.cThu May 11 15:20:46 2000

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

  *** 540,545 ****

  --- 540,546 ----

        Tcl_Obj *objPtr;/* The Tcl_Obj * to be freed. */

    {

        Tk_FreeColor(Tk_GetColorFromObj(tkwin, objPtr));

  +     FreeColorObjProc(objPtr);

    }

    

    /*

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

  *** 646,682 ****

    InitColorObj(objPtr);

        }


        tkColPtr = (TkColor *) objPtr->internalRep.twoPtrValue.ptr1;

  !     if (tkColPtr != NULL) {

  ! if ((tkColPtr->resourceRefCount > 0)

  ! && (Tk_Screen(tkwin) == tkColPtr->screen)

  ! && (Tk_Colormap(tkwin) == tkColPtr->colormap)) {

  !     /*

  !      * The object already points to the right TkColor structure.

  !      * Just return it.

  !      */


  !     return (XColor *) tkColPtr;

  ! }

  ! hashPtr = tkColPtr->hashPtr;

  ! FreeColorObjProc(objPtr);

  !     } else {

  ! hashPtr = Tcl_FindHashEntry(&dispPtr->colorNameTable, 

  !                 Tcl_GetString(objPtr));

  ! if (hashPtr == NULL) {

  !     goto error;

  ! }

        }


        /*

  !      * At this point we've got a hash table entry, off of which hang

  !      * one or more TkColor structures.  See if any of them will work.

         */

  ! 

        for (tkColPtr = (TkColor *) Tcl_GetHashValue(hashPtr);

        (tkColPtr != NULL); tkColPtr = tkColPtr->nextPtr) {

    if ((Tk_Screen(tkwin) == tkColPtr->screen)

    && (Tk_Colormap(tkwin) == tkColPtr->colormap)) {

        objPtr->internalRep.twoPtrValue.ptr1 = (VOID *) tkColPtr;

        tkColPtr->objRefCount++;

        return (XColor *) tkColPtr;

  --- 647,687 ----

    InitColorObj(objPtr);

        }


  +     /*

  +      * First check to see if the internal representation of the object

  +      * is defined and is a color that is valid for the current screen

  +      * and color map.  If it is, we are done.

  +      */

        tkColPtr = (TkColor *) objPtr->internalRep.twoPtrValue.ptr1;

  !     if ((tkColPtr != NULL)

  !     && (tkColPtr->resourceRefCount > 0)

  !     && (Tk_Screen(tkwin) == tkColPtr->screen)

  !     && (Tk_Colormap(tkwin) == tkColPtr->colormap)) {

  ! /*

  !  * The object already points to the right TkColor structure.

  !  * Just return it.

  !  */


  ! return (XColor *) tkColPtr;

        }


        /*

  !      * If we reach this point, it means that the TkColor structure

  !      * that we have cached in the internal representation is not valid

  !      * for the current screen and colormap.  But there is a list of

  !      * other TkColor structures attached to the TkDisplay.  Walk this

  !      * list looking for the right TkColor structure.

         */

  !     hashPtr = Tcl_FindHashEntry(&dispPtr->colorNameTable, 

  !     Tcl_GetString(objPtr));

  !     if (hashPtr == NULL) {

  ! goto error;

  !     }

        for (tkColPtr = (TkColor *) Tcl_GetHashValue(hashPtr);

        (tkColPtr != NULL); tkColPtr = tkColPtr->nextPtr) {

    if ((Tk_Screen(tkwin) == tkColPtr->screen)

    && (Tk_Colormap(tkwin) == tkColPtr->colormap)) {

  +     FreeColorObjProc(objPtr);

        objPtr->internalRep.twoPtrValue.ptr1 = (VOID *) tkColPtr;

        tkColPtr->objRefCount++;

        return (XColor *) tkColPtr;

  Only in tk8.3.1.mod/generic: tkColor.c.orig

  diff -c -r tk8.3.1/generic/tkCursor.c tk8.3.1.mod/generic/tkCursor.c

  *** tk8.3.1/generic/tkCursor.cThu Sep  2 13:02:28 1999

  --- tk8.3.1.mod/generic/tkCursor.cThu May 11 15:38:35 2000

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

  *** 561,566 ****

  --- 561,567 ----

        Tcl_Obj *objPtr;/* The Tcl_Obj * to be freed. */

    {

        FreeCursor(GetCursorFromObj(tkwin, objPtr));

  +     FreeCursorObjProc(objPtr);

    }

    

    /*

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

  *** 696,723 ****

    InitCursorObj(objPtr);

        }


        cursorPtr = (TkCursor *) objPtr->internalRep.twoPtrValue.ptr1;

  !     if (cursorPtr != NULL) {

  ! if (Tk_Display(tkwin) == cursorPtr->display) {

  !     return cursorPtr;

  ! }

  ! hashPtr = cursorPtr->hashPtr;

  !     } else {

  ! hashPtr = Tcl_FindHashEntry(&dispPtr->cursorNameTable, 

  !                 Tcl_GetString(objPtr));

  ! if (hashPtr == NULL) {

  !     goto error;

  ! }

        }


        /*

  !      * At this point we've got a hash table entry, off of which hang

  !      * one or more TkCursor structures.  See if any of them will work.

         */

  ! 

        for (cursorPtr = (TkCursor *) Tcl_GetHashValue(hashPtr);

        cursorPtr != NULL; cursorPtr = cursorPtr->nextPtr) {

    if (Tk_Display(tkwin) == cursorPtr->display) {

        objPtr->internalRep.twoPtrValue.ptr1 = (VOID *) cursorPtr;

        cursorPtr->objRefCount++;

        return cursorPtr;

  --- 697,726 ----

    InitCursorObj(objPtr);

        }


  +     /*

  +      * The internal representation is a cache of the last cursor used

  +      * with the given name.  But there can be lots different cursors

  +      * for each cursor name; one cursor for each display.  Check to

  +      * see if the cursor we have cached is the one that is needed.

  +      */

        cursorPtr = (TkCursor *) objPtr->internalRep.twoPtrValue.ptr1;

  !     if ((cursorPtr != NULL) && (Tk_Display(tkwin) == cursorPtr->display)) {

  ! return cursorPtr;

        }


        /*

  !      * If we get to here, it means the cursor we need is not in the cache.

  !      * Try to look up the cursor in the TkDisplay structure of the window.

         */

  !     hashPtr = Tcl_FindHashEntry(&dispPtr->cursorNameTable,

  !     Tcl_GetString(objPtr));

  !     if (hashPtr == NULL) {

  ! goto error;

  !     }

        for (cursorPtr = (TkCursor *) Tcl_GetHashValue(hashPtr);

        cursorPtr != NULL; cursorPtr = cursorPtr->nextPtr) {

    if (Tk_Display(tkwin) == cursorPtr->display) {

  +     FreeCursorObjProc(objPtr);

        objPtr->internalRep.twoPtrValue.ptr1 = (VOID *) cursorPtr;

        cursorPtr->objRefCount++;

        return cursorPtr;

  diff -c -r tk8.3.1/tests/menu.test tk8.3.1.mod/tests/menu.test

  *** tk8.3.1/tests/menu.testThu Apr 15 21:51:39 1999

  --- tk8.3.1.mod/tests/menu.testThu May 11 16:00:17 2000

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

  *** 2438,2457 ****


    # menu-34 MenuInit only called at boot time


    # cleanup

    deleteWindows

    ::tcltest::cleanupTests

    return

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  --- 2438,2458 ----


    # menu-34 MenuInit only called at boot time


  + # creating menus on two different screens then deleting the

  + # menu from the first screen crashes Tk8.3.1

  + #

  + test menu-35.1 {menus on multiple screens - crashes tk8.3.1} {

  +   if {[info exists ::env(TK_ALT_DISPLAY)]} {

  +     toplevel .one

  +     menu .one.m

  +     toplevel .two -screen $::env(TK_ALT_DISPLAY)

  +     menu .two.m

  +     destroy .one

  +     destroy .two

  +   }

  + } {}

  + 

    # cleanup

    deleteWindows

    ::tcltest::cleanupTests

    return




  This does correct the problem (fixing the 3DBorder showed cascading
  problems with Cursor and Color).  Verified with TK_ALT_DISPLAY
  through tests, and all is still OK on Windows.  This is in 8.4a1. 
  -- 05/11/2000 hobbs


tkt_uuid: 1432915fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 02. Appearance
priority: 5 Medium
foundin: obsolete: 8.4.12
resolution: None
title: Widget borders in canvas wrong with OS X
comment:
  There seems to be some 'leakage' in graphical elements when widgets 
  are involved in a canvas and the surrounding border is thus not 
  updated properly.

  I have attached an example where you can clearly see what has 
  resulted when I moved this group of items around the screen. The 
  border of the tk_optionMenu has become messed up with what 
  appears to be elements of the graphics around it.

  In the same example you can also see how a button with a small font 
  size looks like it is missing something. The bottom of the bottom 
  appears as if it has just been cut out. It lacks the natural border around 
  the button.

  The optionMenu was created without any later tweaking and the button 
  was created with -highlightthickness 0 and -borderwidth 0. The 
  options for the button do not effect the appearance of the actual 
  button in this case.

  The platform is OS X 10.4.4 / Aqua.


tkt_uuid: 513219ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: wm buttons drawn wrongly
comment:
  The x, - and + buttons at the top left of every 
  window do not automatically highlight themselves 
  to reveal the x, - and + text whenever the mouse 
  moves over them (unlike other MacOS X windows).


tkt_uuid: 749016ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Duplicate
title: spinbox.test fails
comment:
  This test fails on Tru64Unix 5.1A with tcl8.4.3/tk8.4.3
  and tcl8.4.3/tk-cvs:


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

      catch {destroy .e}
      spinbox .e -font $fixed -width 4 -xscrollcommand scroll
      pack .e
      .e insert end "01234567890"
      update
      .e configure -width 5
      set scrollInfo

  ---- Result was:
  0.315789 0.842105
  ---- Result should have been (exact matching):
  0 0.363636
  ==== spinbox-5.7 FAILED


  ==== spinbox-7.1 InsertChars procedure FAILED
  ==== Contents of test case:

      .e delete 0 end
      .e insert 0 abcde
      .e insert 2 XXX
      update
      list [.e get] $contents $scrollInfo

  ---- Result was:
  abXXXcde abXXXcde {0.315789 0.842105}
  ---- Result should have been (exact matching):
  abXXXcde abXXXcde {0 1}
  ==== spinbox-7.1 FAILED


  ==== spinbox-17.4 SpinboxUpdateScrollbar procedure FAILED
  ==== Contents of test case:

      destroy .e
      set x "Background error did not happen"
      proc bgerror msg {
          global x
          set x $msg
      }
      spinbox .e -width 5 -xscrollcommand thisisnotacommand
      pack .e
      update
      rename bgerror {}
      list $x $errorInfo

  ---- Result was:
  {Background error did not happen} {bad spinbox index "1xyz"
      while executing
  ".e index 1xyz"}
  ---- Result should have been (exact matching):
  {invalid command name "thisisnotacommand"} {invalid
  command name "thisisnotacommand"
      while executing
  "thisisnotacommand 0 1"
      (horizontal scrolling command executed by .e)}
  ==== spinbox-17.4 FAILED


  ==== spinbox-19.8 spinbox widget validation FAILED
  ==== Contents of test case:

      focus -force .e
      # update necessary to process FocusIn event
      update
      set ::vVals

  ---- Result was:

  ---- Result should have been (exact matching):
  .e -1 -1 abcd abcd {} focus focusin
  ==== spinbox-19.8 FAILED


  ==== spinbox-19.9 spinbox widget validation FAILED
  ==== Contents of test case:

      focus -force .
      # update necessary to process FocusOut event
      update
      set ::vVals

  ---- Result was:

  ---- Result should have been (exact matching):
  .e -1 -1 abcd abcd {} focus focusout
  ==== spinbox-19.9 FAILED


tkt_uuid: 679892ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: Dialog-box crashes on Tcl/Tk Aqua 8.4.1 / Iwidgets
comment:
  Version: Tcl/Tk Aqua 8.4.1 
  OS: OS X 10.2 (Jaguar)
  Extensions: Itcl/Itk/Iwidgets supplied with Aqua version

  Many of my dialog boxes that were created using 
  iwidgets dialogshell and contain other iwidgets crash 
  sometime during the activation process (e.g., "$ds 
  activate" where $ds is the variable assigned the dialog 
  box widget).  The dialog box itself appears, but it seems 
  to crash during the drawing of its component widgets.
  There is no core dump file, the application just closes 
  inexplicably.  It occurs on virtually all such dialog boxes 
  in the scripts that I have tried.   I have tried setting the 
  dialog boxes to be both modal and modeless, with no 
  change in behavior.

  The file in which this occurs is quite large, but it is from 
  another SourceForge-hosted project OpenSoundWorld, I 
  am happy to send to whomever is handling this request.

  I have tried unsuccessfully to isolate the problem using 
  puts statements and strategic "commenting out" of 
  lines to no avail.

  Since it appears to happen in Tcl scripts and I can't 
  isolate it to a particular Tk issue, I'll try here first.  If 
  someone knows this to be a Tk issue, I'll happily refer it 
  on to that project.

  Any help would be appreciated!  Thanks!
  -Amar
  peoplestank@users.sourceforge.net


tkt_uuid: 220540ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Resize window causes X error
comment:
  OriginalBugID: 2244 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-16'
  LastModified: '2000-01-07'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: FreeBSD 2.2.6-RELEASE
  Machine: NA
  FixedDate: '2000-01-07'
  FixedInVersion: 8.3b1


  Name:
  Ken Schmidt

  CustomShell:
  I applied FreeBSD patches that altered "Makefile.in" and "configure" in the unix directory, so that both a shared library and a static library are created.

  Comments:
  This has something to do with the new (tk >= 8.0) menu building features
      under unix.  "33" seems to be the height of the menubar itself (when I
      set the height to 150, the actual height of the window is 183).

      When I run this under Windows, it won't let me resize the window shorter
      than the menu bar, so there's no problem.  I can also set the minsize to
      >0, and there's no problem (my workaround).

  ReproducibleScript:
  #!/usr/local/bin/wish
      menu .mbar -type menubar
      . configure -menu .mbar
      .mbar add cascade -label "File" -underline 0 -menu .mbar.file
      menu .mbar.file -activeborderwidth 1 -borderwidth 1 -tearoff 0
      frame .main -borderwidth 1
      pack .main -side top -fill both -expand yes
      wm geometry . 300x150

      After I run the script above, I resize the Tcl/Tk window to 300x33.

  ObservedBehavior:
  I get the following:

      X Error of failed request:  BadValue (integer parameter out of range for
      operation)  Major opcode of failed request:  12 (X_ConfigureWindow)
        Value in failed request:  0x0
        Serial number of failed request:  127
        Current serial number in output stream:  128

  DesiredBehavior:
  I expected the window to resize properly, not crash.



  Not verifiable with 8.3b1 on Solaris7 - may have been fixed. 
  -- 01/03/2000 hobbs
  This was indeed fixed in 8.3b1 on a related bug.  The panic
  was removed in favor of proper X error surpression for this case. 
  -- 01/07/2000 hobbs


tkt_uuid: 220560ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2b1
resolution: Fixed
title: Incorrect TK_MINOR_VERSION macro
comment:
  OriginalBugID: 2379 Bug
  Version: 8.2b1
  SubmitDate: '1999-07-16'
  LastModified: '1999-07-16'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: redman
  OS: Other
  Machine: NA
  FixedDate: '1999-07-16'


  Name:
  Don Porter

  Patch:
  Index: tk.h
  ===================================================================
  RCS file: /cvsroot/tk/generic/tk.h,v
  retrieving revision 1.27
  diff -c -r1.27 tk.h
  *** tk.h        1999/06/25 23:47:57     1.27
  --- tk.h        1999/07/16 01:38:00
  ***************
  *** 44,50 ****
     */
    
    #define TK_MAJOR_VERSION   8
  ! #define TK_MINOR_VERSION   1
    #define TK_RELEASE_LEVEL   TCL_BETA_RELEASE
    #define TK_RELEASE_SERIAL  1
    
  --- 44,50 ----
     */
    
    #define TK_MAJOR_VERSION   8
  ! #define TK_MINOR_VERSION   2
    #define TK_RELEASE_LEVEL   TCL_BETA_RELEASE
    #define TK_RELEASE_SERIAL  1

  PatchFiles:
  tk.h



  Fixed in 8.2b2 
  -- 07/16/1999 redman


tkt_uuid: 3608963fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 9 Immediate
foundin: current: 8.6.0
resolution: None
title: Crash on MoutainLion with negative offset to wm geometry
comment:
  The following script crashes on MountainLion (10.8.3). It works on SnowLeopard and Lion (and other OS). 
  Used Tcl version is ActiveTcl 8.6.0. Crash report attached.

  package require Tk

  toplevel .top
  label .top.l -text "BallonHelp"
  pack .top.l

  #wm geometry .top [format "+%d+%d" -40 -40] ; # This works
  wm geometry .top [format "+%d+%d" -50 -50] ; # This fails  


tkt_uuid: 220483ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Disabled menubuttons display improperly
comment:
  OriginalBugID: 1735 Bug
  Version: 8.1b2
  SubmitDate: '1999-04-06'
  LastModified: '1999-04-06'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: lfb
  RelatedBugIDs: 1703
  OS: Digital Unix
  Machine: Other
  FixedDate: '1999-04-06'


  Name:

  James Hemmerle



  ReproducibleScript:

  menubutton .m -text test

      pack .m

      .m configure -state disabled



  ObservedBehavior:

  When the menubutton is disabled, the text is unreadable.  The

      button appears completely in the disabledForeground color.



  DesiredBehavior:

  The menubutton should display in the disabledForeground and background

      colors.  (The way it displayed in Tk4.2 and the way disabled buttons

      appear in Tk8.1.)



  Patch:

  146,147c146,147

  <     if (((mbPtr->state == STATE_DISABLED) && (mbPtr->disabledFg != NULL) )

  <           || (mbPtr->image != NULL)) {

  ---

  >     if ((mbPtr->state == STATE_DISABLED) 

  >       && ((mbPtr->disabledFg == NULL) || (mbPtr->image != NULL))) {



  PatchFiles:

  tkUnixMenubu.c


tkt_uuid: 1997293fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Mistake in manual page
comment:
  Description for tag option -relief has been corrected to being dependant on -borderwidth, but -borderwidth is still saying "is ignored unless the -background option has been set", which is incorrect.


tkt_uuid: 3601601fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 6
severity: Minor
foundin: current: 8.6.0
resolution: Invalid
title: tk_textCopy copies elided text
comment:
  The tk_textCopy (and tk_textCut) commands copy elided text from a text widget. While there are certainly some cases where this is desirable, I would imagine they are the minority. It's very minor to change the behaviour, just requires adding the -displaychars option to [$textWidget get].


tkt_uuid: 505616ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: listbox-13.3 fails
comment:
  After the 2002-01-16 commit to tkListBox.c, test
  listbox-13.3 began failing on both Solaris/CDE
  and Linux/Alpha/GNOME.

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

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

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


tkt_uuid: 219923ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Duplicate
title: core dump when using text widget under Tk8.1b1
comment:
  OriginalBugID: 1300 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-25'
  LastModified: '1999-03-25'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: surles
  RelatedBugIDs: 991
  OS: Linux
  OSVersion: Linux Debian 1.3
  Machine: Other
  ClosedDate: '1999-03-25'


  Name:
  Claude BARRAS

  ReproducibleScript:
  $  wish8.1

  # Following 5 lines script fails for Tcl/Tk 8.1b1 under Linux (Debian
  1.3)
  text .t
  pack .t
  .t insert insert "\n"
  .t window create insert -window [button .t.b]
  .t index insert-1c





  ObservedBehavior:
  Program received signal SIGSEGV, Segmentation fault.
  0x4008a19f in TkTextPrintIndex ()

  (it also fails with embedded images instead of embedded windows)





  DesiredBehavior:
  it correctly works with Tcl/Tk 8.0.4; it should also work for Tcl/Tk 8.1





  Duplicate 991.


tkt_uuid: 3152603fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: Cascade entry stops working if reconfigured with same -menu
comment:
  When a cascade menu entry is reconfigured with its current value for -menu, the
  submenu is no longer responsive to mouse actions. The problems seems to be that
  the -menu option on the cloned menu gets updated to the non-cloned submenu. The
  following code demonstrates the problem:

  . configure -menu [menu .menu]
  .menu add cascade -label Sub -menu [menu .menu.sub]
  .menu.sub add command -label Foo
  .menu.sub add command -label Bar
  # At this point the submenu works as expected
  puts [.#menu entrycget end -menu]
  # -> .#menu.#menu#sub
  .menu entryconfigure end -menu .menu.sub
  puts [.#menu entrycget end -menu]
  # -> .menu.sub
  # The submenu does not respond to mouse actions.

  Linux 2.6.34.7 x86_64 with Tcl/Tk compiled from sources. 
  I found the problem on Tk 8.5.9, but could reproduce on a fairly recent 8.6b1.2.

  This is a different issue from bug #1723059


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: 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: 758100ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: None
title: Borland patches for 8.5
comment:
  Hello out there,
  enclosed are the patches necessary to succesfully build
  Tk (8.5) with Borland (well, it requires that Tcl can
  be built with Borland, too, but these patches are at SF
  as well).
  Best regards
  Helmut Giese


tkt_uuid: 1461501fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.12
resolution: Wont Fix
title: text search fails on line with elided text
comment:
  Hi,
  I found a bug, <george> from #tcl on IRC.freenode.net 
  helped me understand the problem and I'm filling a bug 
  report so it can stay in the archives.
  The bug is reproduced on the 8.4 versions (tested on 8.
  4.11 and 8.4.12), but seems to be fixed in the cvs HEAD 
  of tk (as of date March 30th, 2006).
  If a text widget has elided text in it, then a search 
  will fail in some cases. To be more precise, if we have 
  X chars elided in a text, and we do a search after 
  these chars, then the offset by which the search should 
  begin is X chars off. In other words, if the string 
  "test" is located at 1.10 in the widget and we have at 
  least 1 char elided in the range 1.0 to 1.9. the search 
  for "test" will fail if the start position of the 
  search is 1.10, it will work for 1.9 if we had only 1 
  char elided, if we have 3 chars elided in the range 1.0 
  to 1.9, then the search will fail for start index 1.10, 
  1.9, 1.8, and it will succeed at 1.7.
  Here's an execution trace :
  (bin) 1 % pack [text .t]
  (bin) 2 % .t tag configure el -elide true
  (bin) 3 % .t insert end hello
  (bin) 4 % .t insert end world el
  (bin) 5 % .t insert end worldtest
  (bin) 6 % .t get 1.0 end
  helloworldworldtest

  (bin) 7 % .t search test 1.0 end
  1.15
  (bin) 8 % .t search test 1.15 end
  (bin) 9 % .t search test 1.11 end
  (bin) 10 % .t search test 1.10 end
  1.15

  Please note that in this case, we need to add 'end' as 
  the last index to search for, if not, for this example, 
  the search will work, but that's only because the 
  search gets wrapped to the beginning of the widget. If 
  we had a lot of lines in the widget, we could have done 
  for example a [.t search test 22.15] and it would have 
  returned '1.15' instead of '22.15'

  p.s.: it seems that if I do [.t search test 1.15 end] 
  it returns the right answer. In my case, it's not 
  acceptable because I really want to skip elided text, 
  I'll manage a workaround.

  Thanks,
  KaKaRoTo


tkt_uuid: 220569ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Edit/Preferences/Appearance/Font/Size generates "Error in Tcl Script"
comment:
  OriginalBugID: 2428 Bug
  Version: 8.2
  SubmitDate: '1999-07-21'
  LastModified: '1999-10-20'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-SuSE
  OSVersion: SuSE6.1 with Linux 2.2.5
  Machine: Other
  FixedDate: '1999-10-20'
  FixedInVersion: 8.3b1


  Name:
  Christian Krone

  Extensions:
  None

  ReproducibleScript:
  First call Edit/Preferences... and select the tab Appearance.
      Then click on the arrow button next to the font size, don't
      release the button yet. Move the mouse pointer over the scrollbar
      of the listbox with the font sizes. Now release the button.
      A Tcl error with the following message will appear:
        can't read "tkPriv(relief)": no such element in array

  ObservedBehavior:
  can't read "tkPriv(relief)": no such element in array
          while executing
      "$w configure -activerelief $tkPriv(relief)"
          (procedure "tkScrollButtonUp" line 4)
          invoked from within
      "tkScrollButtonUp
      .prefDbgWin.tabWin.appFrm.fontFrm.titleFrm.subFrm.sizeBox_tl.frm.yscroll
      7 54
      "
          (command bound to event)



  Melissa says:

  i've discussed this bug with Brent, and he thing it's a bug in the X  server (on many different machines), and that the most reasonable fix  would be in tk core, rather than in our tools.

  -- 07/30/1999 jenn

  The problem is that this piece of code for the scrollbar expects
  that it has a matching ButtonPress for the ButtonRelease (otherwise
  we see the error).  The complication is that sometimes widgets that
  are over the scrollbar can be deleted on a ButtonPress (the widget
  will then go away), and the scrollbar receives the ButtonRelease,
  since it was underneath.  You can work around this by having the
  overlying dialog go away on a ButtonRelease instead.  The fix was
  to also protect this case for the scrollbar itself, but this can
  occur for other widgets that expect a matching ButtonPress to the
  ButtonRelease. 
  -- 10/20/1999 hobbs


tkt_uuid: 3609131fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
severity: Minor
foundin: None
resolution: Wont Fix
title: Aqua/Cocoa: deadlock when a menu accelerator posts a dialog
comment:
  Re: 3608904

  The deadlocked process is sometimes unkillable, and although it does not use much CPU or memory it retains a display and hogs the event loop, slowing down all other interactive applications on the machine (e.g. it takes a minute to open a terminal).  It can be terminated only by a reboot.

  I am sorry to create a duplicate bug for this; however comments have been disabled for 3608904 which makes it impossible to add this information there.

  IMHO "Wont Fix" bugs should not be closed or have comments disabled - if we are lucky someone else might provide useful information or even a fix.


tkt_uuid: 2914943fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 57. [option]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: Man page is misleading
comment:
  The manpage gives the following example:

  option add *button.foreground red startupFile

  claiming to change the look for all buttons. I tried a similar line:

  option add *entry.font "-size 14" startupFile

  On at least OS X this has no affect. Changing the option to *Entry.font" works. So the name is case sensitive and should be capital. Additionally the manpage really should describe the option syntax without referring to "usual X format", as this is not relevant on Windows and OS X.


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: 219990ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 1 Zero
foundin: final: 8.1.1
resolution: Duplicate
title: image on Menubutton
comment:
  OriginalBugID: 2171 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-03'
  LastModified: '1999-09-15'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2084 2564
  OS: HP-UX
  OSVersion: HP-UX10.20
  Machine: Other
  ClosedDate: '1999-09-15'


  Name:

  Nobumasa Akasaka



  CustomShell:

  nothing



  Comments:

  It was ok with tk8.0, but it went wrong with tk8.1.



  ReproducibleScript:

  image create photo logo64   -file {logo64.gif} -format {gif}  

      menubutton .mb  -image {logo64}

      pack .mb

      menu .mb.m

      .mb configure -menu .mb.m



  ObservedBehavior:

  The image on the menubutton is grayed out, but it's working normally.



  DesiredBehavior:

  The image should be displayed normally.



  Patch:

  --- tkUnixMenubu.c.clnFri Apr 30 04:38:38 1999

  +++ tkUnixMenubu.cThu May  6 20:53:13 1999

  @@ -143,8 +143,8 @@

        * foreground color, generate the stippled effect.

        */

   

  -    if (((mbPtr->state == STATE_DISABLED) 

  -            && (mbPtr->disabledFg == NULL)) || (mbPtr->image != NULL)) {

  +    if ((mbPtr->state == STATE_DISABLED) 

  +            && ((mbPtr->disabledFg == NULL) || (mbPtr->image != NULL))) {

   XFillRectangle(mbPtr->display, pixmap, mbPtr->disabledGC,

   mbPtr->inset, mbPtr->inset,

   (unsigned) (Tk_Width(tkwin) - 2*mbPtr->inset),



  PatchFiles:

  unix/tkUnixMenubu.c


tkt_uuid: 3519111fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: None
priority: 5 Medium
foundin: None
resolution: None
title: Problem with horizontal scroll of treeview
comment:
  The horizontal scrollbar for a ttk::treeview does not work as expected (and as it does for a text widget). While initially the scrollbar appears fine and a corresponding fraction of the tree is displayed, this changes after the tree has been displayed once in its full width. Afterwards the scrollbar is and remains forever at 100%, no matter how small a tree width is chosen.
  The scroll command specified with the –xscrollcommand option is then always called with additional arguments 0.0 and 1.0.

  Problem occurs with Tcl/Tk 8.5.11 on Windows 7 and SuSE Linux.

  The following piece of code demonstrates the problem (If you replace ttk::treeview by text everything looks great):

  # purpose: test horizontal treeview scrolling

  wm withdraw .
  toplevel .ft -takefocus 0
  wm geometry .ft =80x300+80+80 
  ttk::frame .ft.lf
  pack .ft.lf -expand yes -fill both
  ttk::scrollbar .ft.lf.hs -orient horiz -command ".ft.tf xview"
  ttk::scrollbar .ft.lf.vs -command ".ft.tf yview"
  ttk::treeview .ft.lf.tf -show tree -xscrollcommand "hscrollf .ft.lf" -yscrollcommand "vscrollf .ft.lf"
  grid .ft.lf.tf -row 0 -column 0 -sticky nsew
  grid .ft.lf.vs -row 0 -column 1 -sticky ns
  grid .ft.lf.hs -row 1 -column 0 -sticky we
  grid rowconfig .ft.lf 0 -weight 1
  grid columnconfig .ft.lf 0 -weight 1

  # populate tree   
  foreach node [list " Entry0 " " Entry111111111111 " " Entry22222222222222222222 " " Entry3333333333333333333333333 "] {
      .ft.lf.tf insert {} end -text $node
  }

  # Vertical scrolling
  proc vscrollf {mw first last} {
      if {[expr {$first > 0.0}] || [expr {$last < 1.0}]} {
          grid $mw.vs -row 0 -column 1 -sticky ns
          $mw.vs set $first $last
      } else {catch {after idle grid remove $mw.vs}}
  }

  # Horizontal scrolling
  proc hscrollf {mw first last} {
      puts "f=$first, l=$last"
      if {[expr {$first > 0.0}] || [expr {$last < 1.0}]} {
          grid $mw.hs -row 1 -column 0 -sticky we
          $mw.hs set $first $last
      } else {catch {after idle grid remove $mw.hs}}
  }


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


  Name:
  Vince Darley

  Extensions:
  winico

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

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

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



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


tkt_uuid: 3000002fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: ttk::scrollbar doesnt use Appearance settings for size
comment:
  On Windows Vista and possibly Win7, the width of a ttk::scrollbar is fixed at 17 pixels. Changing the scrollbar size in Appearance settings has no effect. This worked fine in 8.5.7. The TK scrollbar behaves correctly on Vista.

  Interestingly, on XP both scrollbar and ttk::scrollbar have the same correct size matching the system scrollbar size.


tkt_uuid: 3609727fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 51. [place]
priority: 5 Medium
foundin: current: 8.5.14
resolution: None
title: place-14.1 fail - MEMLEAK!
comment:
  Testing a --enable-symbols=all build of Tk 8.5.14
  revealed that place-14.1 fails:

  ==== place-14.1 memory leak testing FAILED
  ==== Contents of test case:

      # Test all manners of forgetting a slave
      frame .f
      frame .f.f
      stress {
          place .f.f -x [expr {1 + 1}] -y [expr {2 + 2}]
          place forget .f.f
      } {
          place .f.f -x [expr {1 + 1}] -y [expr {2 + 2}]
          pack .f.f
      } {
          place .f.f -x [expr {1 + 1}] -y [expr {2 + 2}]
          destroy .f
          frame .f
          frame .f.f
      }

  ---- Result was:
  0 0 104
  ---- Result should have been (exact matching):
  0 0 0
  ==== place-14.1 FAILED

  This failure indicates a memory leak.

  Further testing revealed that 8.5.13 has the same
  leak.  Since this is not a regression, it will not
  block 8.5.14 release, but it's still a serious bug
  we should hunt down and kill.


tkt_uuid: 1567681fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: None
title: Trying to post a CLONE menu makes wish crash
comment:
  ~$ wish
  % menu .m
  % . configure -menu .m
  % bind . <3> {tk_popup .#m %X %Y}

  press button 3 on the . toplevel result in

  % Tk_MoveToplevelWindow called with non-toplevel window
  Abort trap (core dumped)
  ~$

  Same behaviour on 8.4.13 and 8.5a4.
  Tested on NetBSD and OpenBSD
  Can't reproduce in win, tested on latest
  tclkit-win32.exe (8.5a4)


tkt_uuid: 1032907fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 4
foundin: obsolete: 8.4.7
resolution: None
title: menubutton fg color changes unexpectedly under Aqua Tk
comment:
  I noticed the following bizarre behavior under MacOS X  
  10.3.4 with Tcl/Tk Aqua 8.4.7: if I have a button using a 
  gray50 bitmap and I change its foreground color, the color 
  of the text of all menubuttons on the same toplevel also 
  changes to that same new color!

  Here is a procedure to see this:

  menubutton .mb -text sometext
  pack .mb
  button .b -bitmap gray50
  pack .b
  .b configure -fg blue

  * Click on the title bar of the topevel window to bring it to 
  the front.
  * Move the mouse over the menubutton (without clicking!)
  * Observe that the color of the menubutton's text changes 
  to blue! Why???

  I sure hope this is a bug and not a feature. I can't imagine 
  why this behavior should be normal, and I don't see this 
  strange behavior under unix (nor, I think, under some 
  earlier versions of aqua Tcl/Tk but I've not tried reverting to 
  find out for sure).

  On the other hand, under aqua Tk I've not found any 
  *proper* way to change the color of the text or the 
  background for a menubutton, which has been a great 
  source of grief. Pity that this bug doesn't make a useful 
  workaround for that problem.     


tkt_uuid: 2024595fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.6a1
resolution: Fixed
title: 2 button.test failures on WinXP
comment:
  Windows XP, compiled using MSVC:

  ==== button-5.5 ConfigureButton - image handling FAILED
  ==== Contents of test case:

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

  ---- Test cleanup failed:
  image "image1" doesn't exist
  ---- errorInfo(cleanup): image "image1" doesn't exist
      while executing
  "image delete image1 image2"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $cleanup"
  ---- errorCode(cleanup): NONE
  ==== button-5.5 FAILED



  ==== button-11.1 ButtonImageProc procedure FAILED
  ==== Contents of test case:

      .l configure -image image1 -padx 0 -pady 0 -bd 0
      pack .l
      set result "[winfo reqwidth .l] [winfo reqheight .l]"
      image1 changed 0 0 0 0 80 100
      lappend result [winfo reqwidth .l] [winfo reqheight .l]

  ---- Result was:
  34 19 84 104
  ---- Result should have been (exact matching):
  30 15 80 100
  ==== button-11.1 FAILED


tkt_uuid: 220862ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Duplicate
title: blanking part of an image
comment:
  OriginalBugID: 2659 RFE
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-11-03'
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: RedHat 6.0
  Machine: Other


  Name:
  Q. Alex Zhao

  DesiredBehavior:
  Since the image has the "blank" widget command which makes the entire
      image transparent, why not support blanking a part of the image?
      
      E.g.
      myImage blank -to 10 10 60 60


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

  The problem is here:

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

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

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

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

  I could have sworn this used to work.


tkt_uuid: 455468ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: selecting text (shift up arrow)
comment:
  There is small mistake in file "tk/library.text.tcl" at
  line 111.

  tkT::extKeySelect %W [tk::TextUpDownLine %W -1]
   ^^^^^^

  may be

  tk::TextKeySelect %W [tk::TextUpDownLine %W -1]

  Michal


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

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


tkt_uuid: 220786ffffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Out of Date
title: no global grab on Windows
comment:
  OriginalBugID: 1158 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-02'
  LastModified: '1999-10-22'
  Severity: MED
  Status: Assigned
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1268 1510
  OS: Windows NT
  Machine: X86


  Name:
  Dr. David Alan Gilbert

  CVS:
  tcl/tk 8.1b1 on NT(the field above wont let me type the version in or select it!)

  ReproducibleScript:
  Bring up the widget demonstration; there are two similar bugs:
   1) The global grab demon doesnt global grab - I can still interact with the rest of the system.

   2) The local grab seems to work - but there is a bug.  If I bring up the local grab demonstration I now have two windows, the main widget demo window and the window for the local grab. If I now click on the title bar of the main widget demo window and then the OK button of the local grab window, the button depresses but doesn't do anything. Clicking again completes it correctly.



  1 is verified, 2 is not reproducible on NT with 8.2.0. 
  -- 08/20/1999 hobbs


tkt_uuid: 220873ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Invalid
title: Making the Tk toplevel window a child windows of my Win32 app
comment:
  OriginalBugID: 3381 RFE
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-01-27'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0 sp3


  Name:
  Joris J. Röling

  Extensions:
  none

  DesiredBehavior:
  We would like to have the Tk toplevel window to be a child window of a
      (native) Win32 app. I did experiment with the '-use 0x<window handle>'
      argument of Wish, with my Win32 window as target, or another Wish
      instance (even with a frame that had the '-container' flag set), but it
      all left me in the dark. Let me tell you what we want:
      
      Like the Tclsh (which is perfectly embedable), we would like to use Tk
      as *part* of the (user extendible) UI of our applications. So our
      application does the main UI itself (native Win32), but should offser
      our end-user the option to extend the I using Tcl/Tk. In our idea, a
      child window should be made by our Win32 app, a thread be started (so
      that Tk can do it's MainLoop), and the window handle should be given to
      Tk, so it knows its parent window. From there on, the end-user can start
      Tcl/Tk scripts that will reflect it's UI on this parent window. I'm sure
      this must be possible, but the documentation is (as far as I know) not
      very elaborate on this subject.
      
      To sum it up: We would like to use Tk without it being a 'toplevel'
      window.
      
      (Please ask if I have explained myself badly, I'll rephrase the
      question)
      
      Cheers,
      Joris


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

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


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



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

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

  Integrated  
  -- 09/06/2000 shawn


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


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

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

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

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

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

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

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

  man ld gives:

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

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

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

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

  menubut.test


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

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

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


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

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

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


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

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

  ==== Result was:
  88 434

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


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

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

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


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

      .t index @12,9

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


  :-)

  Peter Morch

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



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


tkt_uuid: 1499862fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Duplicate
title: 8.5 ActiveTcl tabs irregular
comment:
  ActiveTcl only - tclkit tabs are ok.

  Inserting tabs into a text window a few tab stops in 
  from left edge visually inserts spaces until it reaches 
  before a tab stop, where it visually inserts 2 spaces, 
  after which it visually inserts tabs.

  Solaris 5.8 on Sun.


tkt_uuid: 1833775fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: None
resolution: Fixed
title: font measure error when text starts like -displayof
comment:
  Observed by KaKaRoTo on Tcl Chat

  Font measure will give an error if -displayof is not specified and the text is a substring of displayof.

  % font measure Courier "-d"
  value for "-displayof" missing

  If objc==4 the displayof value should not be checked. This can be fixed by the following change in tkFont.c

   diff tkFont.c tkFont.c.orig
  724,727c724
  <       skip = 0 ;
  <       if (objc==6) {
  <           skip = TkGetDisplayOf(interp, objc - 3, objv + 3, &tkwin);
  <       }
  ---
  >       skip = TkGetDisplayOf(interp, objc - 3, objv + 3, &tkwin);


tkt_uuid: 1892159fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Rejected
title: Add message catalog information for months and days of weeks
comment:
  http://wiki.tcl.tk/1816 is a internationalized date chooser megawidget. Within the code is a series of message catalog entries for the month names, day of week names, etc.

  It would be beneficial to at least ensure that all of these were available from tk. It would even be nicer if a date selector megawidget similar to this one were available as either a widget demo or as a usable widget in the Tk distribution.


tkt_uuid: 220231ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: TK Build failes on Solaris X86 5.7
comment:
  OriginalBugID: 2651 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '2000-02-07'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3905
  OS: Solaris
  OSVersion: X86 5.7
  Machine: Other
  ClosedDate: '2000-02-07'


  Name:
  Jay J. Rohr

  ReproducibleScript:
  ./configure --enable-gcc --enable-shared
      make

  ObservedBehavior:
  #./configure --enable-gcc --enable-shared
      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... no
      checking for Tcl configuration... found
      /usr5/local/src/tcl8.2.0/unix/tclConfig.sh
      checking for existence of /usr5/local/src/tcl8.2.0/unix/tclConfig.sh...
      loading
      checking if 64bit support is enabled... no
      checking system version (for dynamic loading)... SunOS-5.7
      checking for dlopen in -ldl... yes
      checking for build with symbols... no
      checking for sin... no
      checking for main in -lieee... no
      checking stdlib.h... yes
      checking fd_set and sys/select... yes
      checking for ANSI C header files... yes
      checking for mode_t... yes
      checking for pid_t... yes
      checking for size_t... yes
      checking for uid_t in sys/types.h... yes
      checking for sys/time.h... yes
      checking whether time.h and sys/time.h may both be included... yes
      checking pw_gecos in struct pwd... yes
      checking for X... libraries /usr/openwin/lib, headers
      /usr/openwin/include
      checking for main in -lXbsd... no
      checking for connect... no
      checking for main in -lsocket... yes
      checking for gethostbyname... no
      checking for main in -lnsl... yes
      checking for sin... (cached) no
      checking for main in -lieee... (cached) no
      checking whether char is unsigned... no
      checking for strtod... yes
      checking for Solaris 2.4 strtod bug... ok
      checking how to build libraries... shared
      updating cache ./config.cache
      creating ./config.status
      creating Makefile
      creating tkConfig.sh
      
      #make
      ....
      
      /usr/ccs/bin/ld -G -z text -o libtk8.2.so tk3d.o tkArgv.o tkAtom.o
      tkBind.o tkBitmap.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o
      tkConsole.o tkCursor.o tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o
      tkGC.o tkGeometry.o tkGrab.o tkGrid.o tkMain.o tkObj.o tkOldConfig.o
      tkOption.o tkPack.o tkPlace.o tkSelect.o tkUtil.o tkVisual.o tkWindow.o
      tkUnix.o tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o
      tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o
      tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o tkUnixMenubu.o
      tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o
      tkUnixXId.o tkStubInit.o tkStubLib.o tkButton.o tkEntry.o tkFrame.o
      tkListbox.o tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o tkScale.o
      tkScrollbar.o tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o
      tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o tkCanvUtil.o
      tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o tkImgGIF.o
      tkImgPPM.o tkImgPhoto.o tkText.o tkTextBTree.o tk!
      TextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o
      tkTextWind.o -R /usr/local/lib:/usr/openwin/lib
      -L/usr5/local/src/tcl8.2.0/unix  -lsocket -lnsl -L/usr/openwin/lib -lX11
      -ldl -lm -lc
      Text relocation remains                         referenced
          against symbol                  offset      in file
      __ctype                             0x1cc       tkGet.o
      __ctype                             0x1e8       tkGet.o
      __ctype                             0x2a04      tkCanvPs.o
      ld: fatal: relocations remain against allocatable but non-writable
      sections

  DesiredBehavior:
  Correct build



  I believe this has to do with the extra '-z text' flag that
  is used.  This is correct for Solaris Sparc, but not Sol x86. 
  -- 10/21/1999 hobbs
  On a freshly setup Solaris5.7 x86 machine with gcc 2.95.2, both
  8.2.3 and 8.3b2 build and test OK.  This also has the -z text
  option specified.  Perhaps the newer gcc fixed this? 
  -- 02/07/2000 hobbs


tkt_uuid: 1652598fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: None
title: Free memory read tkOption.c SetupStacks
comment:
  In tkOption.c:SetupStacks (lines 1343-1374 v1.18) there is a free memory read. I'm not familiar with this code so I don't fancy checking it in and haven't done so before.

  The cause appears to be access to system stacks element pointers that have been reallocated within the same loop the pointer was assigned.

  I tried the following changes and it prevented the free memory read and there was no noticeable strangeness happening in my fairly complex GUI:

  Changed section in tkOption.c:SetupStacks:

      for (iPtr = searchOrder; *iPtr != -1; iPtr++) {
  register Element *elPtr;
  int count, current; /* current added */
  Tk_Uid id;

  i = *iPtr;
  if (i & CLASS) {
      id = winPtr->classUid;
  } else {
      id = winPtr->nameUid;
  }
  #if 0 /* removed */
  elPtr = tsdPtr->stacks[i]->els;
  count = levelPtr->bases[i];
  #endif
          current = 0; /* current added */
  count = tsdPtr->stacks[i]->numUsed; /* count initialised from current stacks */

  /*
   * For wildcard stacks, check all entries;  for non-wildcard
   * stacks, only check things that matched in the parent.
   */

  if (!(i & WILDCARD)) {
  #if 0 /* removed */
      elPtr += levelPtr[-1].bases[i];
  #endif
              current = levelPtr[-1].bases[i]; /* I think level above should not change in this loop */
      count -= current;
  }
          /* Always get elPtr anew after ExtendStacks() is called. */
  for ( elPtr = tsdPtr->stacks[i]->els + current; count > 0;
                current++, elPtr = tsdPtr->stacks[i]->els + current, count-- ) {
      if (elPtr->nameUid != id) {
  continue;
      }
      ExtendStacks(elPtr->child.arrayPtr, leaf);
  }
      }


  It didn't fix my crash, but hey that's life.


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: 220827ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.0p2
resolution: Invalid
title: inconsistency in menu handling
comment:
  OriginalBugID: 578 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-05-21'
  Severity: LOW
  Status: UnAssn
  Submitter: hershey
  ChangedBy: hershey
  OS: Windows NT
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


  I believe the following illustrates an inconsistency in menu handling
  under NT, Tk8.0p2:

  menu .m -tearoff 0
  . configure -menu .m
  menu .m.m -tearoff 0
  .m add cascade -label foo -under 0 -menu .m.m

  Now if I do:

  .m.m add command -label bar -command {puts bar}
  bind .m.m <<MenuSelect>> {if {[%W index active] == 0} {%W invoke 0}}

  and select (not activate) .m.m[bar], the command fires and 'bar' is printed.

  But if instead I do:

  .m.m add cascade -label bar -menu .m.m.m
  menu .m.m.m -tearoff 0
  .m.m.m add command -label goo -command {puts goo}
  bind .m.m <<MenuSelect>> {if {[%W index active] == 0} {%W postcascade 0}}

  and again select .m.m[bar], the sub-menu is NOT posted.

  Bug or feature?

  This is of course an artificially simplifed example:  I have an
  application which constructs a rich set of cascading menus from a
  database, and in case a sub-menu is ever posted with only one entry, I
  want to post its sub-sub-menu automagically, (as tkMenuFirstEntry does
  under UNIX), but I've so far been completely unable to invoke
  postcascade successfully under WIN32.  Note for instance that given
  the above setup

  .m postcascade 0

  doesn't work either.

  ht


tkt_uuid: 1309587fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.4.11
resolution: Invalid
title: Transparent images on disabled buttons display incorrectly
comment:
  If a transparent image is assigned to a button, and
  later the button's -bg is changed, the transparent
  portions of the image become visible when the button is
  in a disabled state.  It seems that the stippling done
  for the disabled image is somehow based on the original
  -bg color, and is not updated when the -bg is changed.

  The problem can be seen in the following code snippet.

  image create photo play -file trans.gif
  button .b1 -image play
  pack .b1
  .b1 configure -state disabled
  .b1 configure -bg red

  Jeff Godfrey


tkt_uuid: 220614ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: TK_SHARED_BUILD incorrect in tkConfig.sh
comment:
  OriginalBugID: 3385 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-01-11'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: Redhat 4.2
  FixedDate: '2000-01-11'
  FixedInVersion: 8.3b2


  Name:
  Jan Nijtmans

  ReproducibleScript:
  Just build Tk from the source distribution on any UNIX machine.

  ObservedBehavior:
  tkConfig.sh contains the line:
          TK_SHARED_BUILD=

  DesiredBehavior:
  Either
        TK_SHARED_BUILD=1
      or
        TK_SHARED_BUILD=0
      depending whether Tk is built as shared or static library

  Patch:
  *** unix/configure.in.origMon Oct 18 20:27:43 1999
  --- unix/configure.inMon Oct 18 20:34:16 1999
  ***************
  *** 379,384 ****
  --- 379,385 ----
        TK_BUILD_LIB_SPEC="-bI:`pwd`/${TK_BUILD_EXP_FILE}"
        TK_LIB_SPEC="-bI:${exec_prefix}/lib/${TK_EXP_FILE}"
    fi
  + TK_SHARED_BUILD=${SHARED_BUILD}
    
    #--------------------------------------------------------------------
    # The statements below define various symbols relating to creating

  PatchFiles:
  configure.in



  added to 8.3b2 
  -- 01/11/2000 hobbs


tkt_uuid: 3607215fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 5 Medium
severity: Minor
foundin: current: 8.6.0
resolution: None
title: ./configure --enable-aqua=carbon
comment:
  `./configure --help` describes an option "--enable-aqua=carbon".

  Is this option still supported?  ./configure fails when looking for files in a non-existent directory named "carbon".


tkt_uuid: 1093631fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a2
resolution: Fixed
title: long single lines aren't displayed
comment:
  In Windows, Tclkit 8.5a2:
  Long paragraphs (logical lines) aren't displayed.

  grid [text .t -bg white -yscrollcommand {.s set} -wrap
  char] -row 0 -column 0 -sticky nswe
  grid [scrollbar .s -orient vertical -command {.t
  yview}] -row 0 -column 1 -sticky nsw
  grid rowconfigure . 0 -weight 1
  grid columnconfigure . 0 -weight 1
  .t insert 1.0 [string repeat a 10000]
  causes the text window to display no text

  If you ask it, it has the data:
  .t get 1.0 1.10
  aaaaaaaaaa

  .t get 1.9970 1.10000
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

  On a likely related note, a shorter, but still kinda
  long line:
  .t insert 1.0 [string repeat a 4000]

  mostly works, but up and down arrow keys are VERY slow
  to respond. Left-right arrows, scrollbar scrolling, and
  drag selecting are fine if the window is wide. If you
  make the window narrow, you get progressive (it gets
  worse the more narrow you make the window) scrolling
  errors. Scrolling with the scrollbar can also cause an
  infinite loop of jiggling the text up and down 1 line.


  tip 155 seems to still need some work.


tkt_uuid: 815118ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: None
resolution: Fixed
title: package require Tk addition
comment:
  now that Tk is a loadable package, it would be useful
  to add the
  package require statement to the various demos.  In
  that way, people
  could be using tclsh or tclkit to run the demos, and Tk
  would be 
  loaded as appropriate.


tkt_uuid: 480862ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 7 High
foundin: obsolete: 8.4a4
resolution: Fixed
title: UNIX Ignores Bitmap Changes
comment:
  If I create a bitmap image with some image data,
  display it, and then reconfigure it to have some
  different data (see the example code below) then this
  change in the data is not displayed *on UNIX/X only*.
  This works correctly on Windows (though it is slow as
  the size of the bitmap increases...)

  set e {#define empty_width 4
  #define empty_height 4
  static char empty_bits[] = {
     0x00, 0x00, 0x00, 0x00};}
  set f {#define full_width 4
  #define full_height 4
  static char full_bits[] = {
     0x0f, 0x0f, 0x0f, 0x0f};}
  image create bitmap b -data $e
  pack [label .l -image b]
  after 3000 {b configure -data $f}

  I originally noticed the problem using the script
  http://www.cs.man.ac.uk/~fellowsd/tcl/bitsandpieces/bitmap.tcl
  (recombine URL?)


tkt_uuid: 220074ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Duplicate
title: scale regression test fails
comment:
  OriginalBugID: 4397 Bug
  Version: 8.3
  SubmitDate: '2000-03-17'
  LastModified: '2000-03-23'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4433
  OS: HP-UX
  OSVersion: 11.00
  ClosedDate: '2000-03-23'


  Name:
  ed foltz

  ReproducibleScript:
  scale.test

  ==== scale-6.11 ComputeFormat procedure FAILED
  ==== Contents of test case:

      .s configure -from .0001 -to .001 -resolution .0001
      .s set .0006
      .s get

  ---- Result was:
  0.00060
  ---- Result should have been:
  0.0006
  ==== scale-6.11 FAILED


  ==== scale-6.12 ComputeFormat procedure FAILED
  ==== Contents of test case:

      .s configure -from .00001 -to .0001 -resolution .00001
      .s set .00006
      .s get

  ---- Result was:
  6e-05
  ---- Result should have been:
  0.00006
  ==== scale-6.12 FAILED


  ==== scale-6.14 ComputeFormat procedure FAILED
  ==== Contents of test case:

      .s configure -to .00001 -from .0001 -resolution .00001
      .s set .00006
      .s get

  ---- Result was:
  6e-05
  ---- Result should have been:
  0.00006
  ==== scale-6.14 FAILED

  DesiredBehavior:
  regression test should pass


tkt_uuid: 1999084fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Duplicate
title: focus bug during window activation (Aqua)
comment:
  Toplevel widows do not get focus when brought back from a minimized state
     
  To produce the bug:
  toplevel .t
  pack [text .t.t1]
  toplevel .t2

  1 click into .t2
  2 Minimize .t with the yellow button.
  3. when you deiconify the minimized window from the dock, the text box has no cursor, and also has no focus ring around it. It responds to button events but doesn't set a cursor.
  4. If you click into .t2, then back, the text box is activated again, has a cursor and a focus ring.

  if the console window is the next window down in the stack, so that it gets focus on minimizing, the bug doesn't happen.

  This bug was previously submitted, but marked obsolete without resolution. It still exists in the latest Aqua 8.5.2


tkt_uuid: 3475627fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: Test text-31.11 fails
comment:
  ==== text-31.11 peer widget -start, -end FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      for {set i 1} {$i < 100} {incr i} {
          .t insert end "Line $i\n"
      }
      set res [.t index end]
      lappend res [catch {.t configure -start 5 -end 15}]
      lappend res [.t index end]
      lappend res [catch {.t configure -start 10 -end 40}]
      lappend res [.t index end]
      .t configure -start {} -end {}
      lappend res [.t index end]
      set res

  ---- Result was:
  101.0 0 97.0 0 92.0 101.0
  ---- Result should have been (exact matching):
  101.0 0 11.0 0 31.0 101.0
  ==== text-31.11 FAILED


  Happens on both core-8-5-branch and trunk


tkt_uuid: 477955ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 76. Widget Tour
priority: 2
foundin: None
resolution: Fixed
title: Some little missspell in demos...
comment:
  Hi,

  I post sam little mistakes in demos...

  File
  tk/library/demos/Dilaog2.tcl:                                                           
                                                                                               
  set i [tk_dialog .dialog2 "Dialog with local grab"
  {This dialog ...                          
                                                                                               
  may
  be                                                                                       
                                                                                               
  set i [tk_dialog .dialog2 "Dialog with global grab"
  {This dialog ...                         
                                                                                               
                                                                                               
                                                                                               
                                                                                               
  In
  files                                                                                     
  tk/library/demos/rolodex                                                                     
  tk/library/demos/ixset                                                                       
  tk/library/demos/browse                                                                      
                                                                                               
  after install things as
  below:                                                               
                                                                                               
  #!/bin/sh                                                                                    
  # the next line restarts using wish
  \                                                        
  exec wish8.48.4 "$0" ${1+"$@"} || exec wish "$0"
  ${1+"$@"}                                   
                                                                                               
  and in
  CVS:                                                                                   
                                                                                               
  #!/bin/sh                                                                                    
  # the next line restarts using wish
  \                                                        
  exec wish8.4 "$0" ${1+"$@"} || exec wish "$0"
  ${1+"$@"}                                      
                                                                                               
  After instaling are appended another
  "8.4".                                                  
  (onother demos have only exec wish "$0" ${1+"$@"})

  Michal wohnivec@iol.cz


tkt_uuid: 1717475fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Mac-native bitmaps do not display under Aqua
comment:
  tkMacOSXBitmap.c defines several Mac-specific bitmaps that should display, but they do not. Sample code (tested under Wish-Aqua 8.4.14):

  label .a -bitmap questhead
   pack .l
  label .b -bitmap folder
  % pack .b
  label .c -bitmap stop
  pack .c


  This will display three labels. "questhead" displays properly. "folder," a Mac-specific color bitmap, does not display at all--the label is blank. "stop," a Mac-specific monochrome bitmap, displays correctly.

  It appears the color bitmaps under OS X are the ones that do not display correctly. 


tkt_uuid: 2155335fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.6a2
resolution: None
title: tests substantively changed. Why?
comment:
  The 2008-07-22 commit to entry.test has
  the simple log message "Update to tcltest2".

  But that's not all that happened.  Several
  tests were re-named/re-numbered, which is
  bad, but I believe I can correct that.

  Some other tests were changed in substantive
  ways without any comment about why.  As one
  example, test entry-2.3 was:

  test entry-2.3 {Tk_EntryCmd procedure} {
      catch {destroy .e}
      entry .e
      list [winfo exists .e] [winfo class .e] [info commands .e]
  } {1 Entry .e}


  And now it is:

  test entry-2.3 {Tk_EntryCmd procedure} -body {
      entry .e
      pack .e
      update
      list [winfo exists .e] [winfo class .e] [info commands .e]
  } -cleanup {
      destroy .e
  } -result {1 Entry .e}

  I like the improved formatting and use
  of features of tcltest 2.  But what are
  those additions of [pack] and [update]
  doing in there?  Adding those changes
  the nature of what is being tested.  This
  is only one simple example.

  I want to change these back to remain
  consistent with what's been tested in
  the past, but I do not know whether making
  such changes will undo some bug fix which
  is behind making the change in the first
  place.  This is why good commit comments
  are so important.  It's not only good
  to have a record of what changed, but also
  why it was changed.


tkt_uuid: 220804ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 25. Built-in Bitmaps
priority: 7 High
foundin: obsolete: 8.1b3
resolution: Duplicate
title: Docs missing for Tk_GetBitmapFromData API
comment:
  OriginalBugID: 1861 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '2000-04-25'
  Severity: MED
  Status: Assigned
  Submitter: surles
  ChangedBy: ericm
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


  .

  04/28/1999 14:38 - kenj - Function appears in the NAME section of GetBitmap.3 man page, but is not documented.

  --

  According to the function header for Tk_GetBitmapFromData, this is a deprecated API.  Should we really document it?

  - eric

  -- 04/25/2000 ericm


tkt_uuid: 220536ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Boo boos in the tk_messageBox help page
comment:
  OriginalBugID: 2218 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-15'
  LastModified: '2000-04-27'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 2219
  OS: Windows 98
  Machine: X86
  FixedDate: '2000-04-27'
  FixedInVersion: 8.4a1


  Name:
  Christopher Nelson

  ObservedBehavior:
  In the .HLP file for Tk 8.1.1, the -default option of tk_messageBox says
  "if this option is not specified, there won't be any default button".
  At least on Windoze 98, the default button is always the first button if
  none is specified.  Maybe there isn't one on UNIX (I can't check right
  now).
      
  Also, there are useless links from the -icon option to [error] and [info].



  Part 1 verified with 8.3.1; part 2 was fixed between 8.1 and 8.3.

  I corrected the Unix dialog implementation to comply with the Windows one (since we can't change the Windows behavior) and updated the documentation.  This fix will go out with 8.4a1.

  - eric

  -- 04/27/2000 ericm


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: 3414695fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: None
title: Error when "parent" destroyed first
comment:
  I think, there is a need for a fix in tk_chooseDirectory, tk_getOpenFile, tk_getSaveFile. Consider the situation, when toplevel dialog has been brought, and there is an entry for file (or directory) name, and associated button, which allows selection using mouse, instead of typing. Below is much simplified example, which will show the problem:

  #v+
    package require Tk
    toplevel .foo
    pack [button .foo.button -command [list tk_getOpenFile -parent .foo] \
         -text "Pick file"]
  #v-

  Now, if you click "Pick file" to select the wanted file with mouse, then you'll change your mind, and decide to abort the whole operation just by closing .foo (and _not_ by closing selection window first, then .foo), an error will be raised:

  #v+
  bad window path name ".foo.__tk_filedialog"
  bad window path name ".foo.__tk_filedialog"
      while executing
  "wm withdraw $grab"
      (procedure "::tk::RestoreFocusGrab" line 13)
      invoked from within
  "::tk::RestoreFocusGrab $w $data(ent) withdraw"
      (procedure "::tk::dialog::file::" line 122)
      invoked from within
  "::tk::dialog::file:: open -parent .foo"
      invoked from within
  ".foo.button invoke"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list $w invoke]"
      (procedure "tk::ButtonUp" line 22)
      invoked from within
  "tk::ButtonUp .foo.button"
      (command bound to event)
  #v-

  Of course, I made this "not quite elegant" way, not closing selection window first - but pay attention, that only in this example the parent toplevel was smaller than its child; in real applications usually it'll be much larger, and we can expect such action from the side of the (lazy) user. IMHO there should be such (mis)use foreseen and silently handled.

  Tested on Linux using TCL/Tk 8.6b2.


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


  Name:
  Uwe Traum

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

  Error: Cannot recognize image data

  This only occurs for Digital-Unix. SunOS works

  ObservedBehavior:
  Error: Cannot recognize image data



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

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

  -- 06/30/2000 ericm


tkt_uuid: 739954ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: textImage.test failures
comment:
  on the HEAD, tests textImage-1.2
  and textImage-1.14 fail, apparently
  due to a change in the error message
  text.


tkt_uuid: 869305ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: None
title: phantom events with tk_popup
comment:
  with Tcl/Tk 8.4.2 on Microsoft Windows Platforms 
  the attached file "popup.tcl" will demonstrate 
  the generation of phantom events to unterlying 
  toplevel. 
   
  I verified this a least for the ButtonRelease 
  and BottonMotion type of events. 
   
  The BottonMotion events will always be generated, 
  the ButtonRelease only, if you hold Button-1 
  pressed while moving around in the popup. 
   
  I think these events should not be generated 
  (in fact they trigger false actions in my 
  programs), and in X11 they are correctly suppressed. 
   
  I also checked the "tk_popup" code in 
  lib/tk8.4.2/menu.tcl. Adding addional grabs there 
  help in the case of the Motion Events, but the 
  (most annoying) ButtonRelease keeps fooling me. 
   


tkt_uuid: 509387ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: Clipboard doesn't work.
comment:
  The command "selection get -selection 
  CLIPBOARD" doesn't work if receiving the 
  clipboard from another application. It works 
  internally, but not from another application. The 
  older 8.0b2 version work... However, newer version 
  has never work since then.

  I was hoping the newer version is using the Mac 
  OS X Project Builder, so I could possibly fix it, but 
  appears still using Code Warrior which I do not 
  have the latest version (i.e., 3).


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


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

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

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

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

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


tkt_uuid: 1832015fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: canvas scale documentation cryptic
comment:
  The canvas documentation states for scale:

  Rescale all of the items given by tagOrId in canvas coordinate space.

  This seems unnecessary cryptic to me. I think the following would be clearer:

  Rescale the coordinates of all the items given by tagOrId.


tkt_uuid: 220900ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Works For Me
title: textDisp test fails
comment:
  OriginalBugID: 4398 Bug
  Version: 8.3
  SubmitDate: '2000-03-17'
  LastModified: '2000-05-17'
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: 11.00


  Name:
  ed foltz

  Comments:
  test always fails when executed from all.test test suite. test fails
      sometimes when executed as ./tktest ../tests/textDisp.test

  ReproducibleScript:
  ==== textDisp-11.2 TkTextSetYView FAILED
  ==== Contents of test case:

      .t yview 30.0
      update
      .t yview 32.0
      update
      list [.t index @0,0] $tk_textRedraw

  ---- Result was:
  32.0 {borders 32.0 33.0 34.0 35.0 36.0 37.0 38.0 39.0 40.0 41.0}
  ---- Result should have been:
  32.0 {40.0 41.0}
  ==== textDisp-11.2 FAILED

  DesiredBehavior:
  regression test pass


tkt_uuid: 931324ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 4
foundin: None
resolution: None
title: Bwidget&TKAqua&Tabs--Mistake betwen tabs
comment:
  Hi!

  I have another big problem with TKAqua and Bwidget on Mac OS X.
  The problem is with ScrolledFrame, ScrolledWindow and Tabs (I 
  don't have this problem without scrolledframe&scrolledwindow).
  See my example script.
  After showing the tabs, if I switch to another application or another 
  window (in the same program), the tabs get mistaken. Items from 
  tabs1 go to tabs2, etc.
  Sometimes, after a big delay (or after scrolling), the window get 
  reloaded and the window is ok.
  This is the biggest bug...

  Another bug is, at the first time we click on Tab2, the ***Test label 
  in tab 2*** start at the left at the window and get center AFTER. 
  When we have a tab with like 20 items, we all see them moving!!

  **Linux and Windows users don't have theses bugs.

  ---begin tabstest.tcl---

  package require BWidget

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


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


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

  .nb compute_size
  .nb raise tab1
  pack .nb
  }

  test_tabs

  ---end tabstest.tcl---


tkt_uuid: 2964992fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: None
title: ttk::combobox::post config problem?
comment:
  The ConfigureListbox grids or removes the scrollbar before the height of the list changes in Placepopdown - so you might end up having a listbox with no scrollbar having to many elements in it ...

  thx


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: 1520897fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Invalid
title: menu index fails if label contains square bracket
comment:
  e.g.,

  $ wish
  % pack [menubutton .mb -text Play... -relief raised
  -menu .mb.m]
  % menu .mb.m -tearoff 0
  .mb.m
  % .mb.m add command -label ywgevfyuw
  % .mb.m add command -label {p[q}
  % .mb.m index {p[q}
  bad menu entry index "p[q"
  % .mb.m entrycget 1 -label
  p[q
  %

  (TclTk 8.4.13 on FC5 x86-64)


tkt_uuid: 1641536fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: None
title: raise does nothing on x86-64 linux
comment:
  If I create a few top level windows and place them so they overlap each other, typing the 'raise' command to the console does not affect their stacking order. However, 'lower' does work although the lowered window goes right to the bottom of the stack even if a 2nd arg is given. This is on KDE; if I swicth to Gnome neither raise or lower do anything.

  Platform is a Macbook Mk2 running Fedora Core 6 for x86-64. Problem verified with ActiveState's TclTk 8.4.14 and with Fedora's own distributions of TclTk 8.4.13 for x86-64 and i386.

  The problem does *not* occur on an i386 running FC5 with TclTk 8.4.13


tkt_uuid: 220167ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 26. Conversions from String
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_GetMMFromObj API
comment:
  OriginalBugID: 1864 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '2000-04-25'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: ericm
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '2000-04-25'


  .

  This function is already documented (man Tk_GetMMFromObj).

  - eric
   
  -- 04/25/2000 ericm


tkt_uuid: 220713ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Lowering very large value with the "lower" arrowbutton on a spinbox does not use the "-to" option.
comment:
  OriginalBugID: 4610 Bug
  Version: 8.3
  SubmitDate: '2000-03-27'
  LastModified: '2000-03-30'
  Severity: LOW
  Status: Released
  Submitter: mroe
  ChangedBy: hobbs
  OS: Solaris
  FixedDate: '2000-03-30'
  FixedInVersion: 8.3.1


  Description:
  jaen:main> myWish
  % package require vu 
  2.0
  % spinbox .sp -from 1 -to 100000
  .sp
  % pack .sp

      Behaviour #1
          Type in 15 9's (999999999999999).
          Hit the "lower" arrowbutton.

      Expected result for #1.
          Entry widget shows "100000".
      Actual result for #1.
          Entry widget shows "999999999999998"

      Behaviour #2
          Type in 16 9's (99999999999999999).
          Hit the "lower" arrowbutton.

      Expected result for #1.
          Entry widget shows "100000".
      Actual result for #1.
          Entry widget shows "10000000000000000"





  As a side note, the BWidgets spinbox has a similar, but diferent, bug (#4565).



  This is vu, and not core, but this has been fixed to constrain
  more intuitively. 
  -- 03/30/2000 hobbs


tkt_uuid: 1641721fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: None
title: tk_getOpenFile shows symlinks to directories twice
comment:
  Create a directory with a symlink to a directory:
  $ mkdir zot
  $ cd zot
  $ ln -s / x

  Run tk_getOpenFile on that location:
  $ wish
  % tk_getOpenFile

  "x" appears twice, once as a directory and once as a file.

  This bug has been observed in: tk8.4-8.4.9-1build1 (Ubuntu 5.10)
  This bug was not present in: tk-8.3.5 (RedHat 9)

  From inspection of the source, I believe the problem is still present in the CVS versions of tk8.4 and tk8.5, but I have not tested those versions.

  I think the problem is around http://tktoolkit.cvs.sourceforge.net/tktoolkit/tk/library/tkfbox.tcl?revision=1.58&view=markup#l_1300
  because a symlink to a directory will match both [glob -type d] and [glob -type l]:
  $ tclsh
  % glob -type d *
  x
  % glob -type l *
  x

  Removing l from the list of glob types would fix this problem, and would also remove dangling symlinks which give an error when selected anyway.


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

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

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

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

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


tkt_uuid: 653895ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Mac: scrollbar set:slider wrong
comment:
  On Tk-Aqua the scrollbar slider size and position is 
  not corectly configured by the scrollbar set command.
  Bug can be demonstrated by:

  grid [scrollbar .s] -row 0 -column 0 -sticky ns
  grid rowconfigure . 0 -weight 1
  .s set .1 .9

  the slider is positioned between ~.25 and ~.75

  try
  .s set .0001 .9999
  -there is no way using set to make a slider that is 
  longer than 0.5 the height of the scrollbar.

  now try 
  .s set .1 .99
  .s set .01 .9

  the slider jumps to the bottom then the top of the 
  scroll bar.
   In the sources it appears that the middle of the 
  scrollbar is being set to first_fraction/(first_fraction+1-
  last_fraction), when it appears to me that it would be 
  more appropriate to set the middle of the scrollbar to 
  (first_fraction+last_fraction)/2

  I'm not sure where the bug in the slider length comes 
  in.

  This may be a bug in the non-Aqua versions for the 
  Mac as well.

  -wayne@eatworms.swmed.edu


tkt_uuid: 1204469fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 8
foundin: obsolete: 8.4.9
resolution: Duplicate
title: labels prevent keyboard input to entry and text widgets
comment:
  After upgrading to Tcl/Tk 8.4.9 on Suse 9.3, I find the
  following strange behavior.  Certain Tk applications
  now refuse to take any input from the keyboard. 
  Buttons and Menus work fine, but when I give a text or
  entry widget the focus, none of my keystrokes seem to
  get through.  

  Here is a script that illustrates the problem:

  #!/usr/local/bin/wish

  text .en
  label .status -text "Hello World"
  pack .en
  pack .status

  Strangely, if you switch the order of the "pack .en"and
  "pack .status" commands, it works fine.

  I have tried this with different window managers to no
  effect. However, if I Iog in remotely (using SSH) to a
  machine running tcl/tk 8.4.6, it runs fine.  Similarly,
  if from a different machine I log in to the machine
  using 8.4.9 and run this script, it works fine over
  remote X.

  Thanks for any help.

  Robert Marmorstein
  rmmarm@cs.wm.edu


tkt_uuid: 3480634fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: PNG Images missing in menus on Mac
comment:
  The TK function ImgPhotoDisplay is used to display transparent or non-transparent images. If an image is transparent, the code combines it with a window background. It first calls XGetImage to get the background (presumably another image) then combines the results with the image. Using XQuartz  2.6.3 (Mac OS X 10.7) many PNG images are not displayed in TK menus because XGetImage fails (10.6 with an older version of XQuartz seems to work). PNG images frames seem to work fine. Perhaps this is a timing issue since TK menus are mapped and them immediately drawn (?). This appears to be a bug in XQuartz. To work around the problem, I changed ImgPhotoDisplay to check for an error and use the non-transparent section of the code. This means the background will not be combined with the image. However, for our use case (TK menus), there is no background image (it is just a solid background) so this seems to solve the problem. We are build tcl/tk 8.5.6 for Unix (not Coco or Carbon) on Mac OS.


tkt_uuid: 3181181fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Torn-off sub menus no longer show on XP !
comment:
  Regression is in Tk HEAD as of Feb 13, 2011.
  Regression also appeared between 8.5.8 and 8.5.9.
  Code to reproduce : http://paste.tclers.tk/2356

  It appears that 
    1. Cascaded torn-off menus will not show up anymore when selected with the ------ line;
    2. Non cascaded torn-off menus will not show up if their "parent" toplevel is withdrawn.

  Looks OK with Linux. XP issue.


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

  Results:

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

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

  After this, Tk 8.4b1 compiles and works fine.


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


  Name: Shawn Kielty

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

  ObservedBehavior:
  "puts $a" returns an empty string

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



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


tkt_uuid: 220697ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: infinite loop when forcing focus to an entry in a nested frame
comment:
  OriginalBugID: 4267 Bug
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-03-01'
  Severity: CRIT
  Status: Released
  Submitter: kuchler
  ChangedBy: ericm
  OS: All
  OSVersion: rh 6.1 x86
  Machine: badajoz and chester
  FixedDate: '2000-03-01'


  (this is a simplification of a bug that was originally classified as a BWidgets bug):

  Say that we have an entry that we don't want to allow the user to leave (for example, we don't want them to move on to the next one unless they have a valid string in the current one).  On FocusOut, we force the focus back to that entry.  Now suppose that the two entries are actually each nested inside a frame, and that the frame redirects focus to its entry.  Now when we are in the first entry and we try to tab to the second one, instead of just being stuck in the first one, we get an infinite loop in which the focus bounces between the two entries and the application is unusable.  Some sample code that demonstrates the problem:

  ###########################################################################
  # the after 100 slows things down enough for us to watch
  bind all <FocusIn> {puts "focusIn %W"; after 100}

  frame .s -takefocus 0 
  entry .s.e
  frame .t -takefocus 0
  entry .t.e

  bind .s.e <FocusOut> {focus -force %W}
  # frames redirect focus to their nested entries
  bind Frame <FocusIn> {focus %W.e}

  pack .s.e .t.e .s .t
  ###########################################################################

  Bummer!

  - eric

  When validating SpinBoxes on focusout and one SpinBox has a valid value and the other SpinBox has an invalid value and the validatecommand does a [focus -force $widget] when an invalid value is found, the program enters an infinite loop.  This doesn't happen with the entry or with the BWidget Entry

  package require BWidget
  proc validCheck {w} {
      puts "validCheck $w"
      if {[string equal $w ".s.e"]} {
          focus -force $w
          return 0
      }
      return 1
  }
  bind all <FocusIn> {puts "focusIn %W"; after 100}
  pack [SpinBox .s -validate focusout -vcmd {validCheck %W}]
  pack [SpinBox .t -validate focusout -vcmd {validCheck %W}]

  To reproduce, click in the spinbox (.s) and tab to the other SpinBox.  The
  app will enter an infinite loop.  You will not be able to get focus at this
  point, so you will have to kill the app remotely, or use xkill from one of
  your window manager menus to stop it.



  Need this fix for Connect 2.0 release

  OK, due to the way in which focus in/focus out events are dropped on the event queue, and the way that a focus in event for a subwidget causes focus in events for all its ancestors, the set of bindings shown actually is responsible for the looping.

  The fix is to delay the focus redirect from the frames:

  bind Frame <FocusIn> {after idle {dofocus %W %W.e}}
  proc dofocus {w c} {
          if { [string equal $w [focus]] } { 
                  focus $c
          }
  }

  This extra delay and the check in the dofocus proc prevents the looping.

  I made this change in BWidgets.

  - eric

  -- 03/01/2000 ericm


tkt_uuid: 3612814fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: None
title: font configure causes crash
comment:
  Using Tcl/Tk 8.5.13 I get a bus error (tested with OSX 10.6.2 and 10.8.3) if I type the following test lines:

  package require Tk
  font configure TkDefaultFont -size 10
  ttk::label .status -relief sunken
  menu .mbar
  menu .mbar.apple
  .mbar add cascade -menu .mbar.apple
  .mbar.apple add command -label hello
  . configure -menu .mbar
  font configure TkDefaultFont -size 12

  The console log shows amongst others:

  Thread 0 Crashed: Dispatch queue: com.apple.main-thread
  0 com.tcltk.tklibrary 0x000d333b TkpConfigureMenuEntry + 2251
  1 com.tcltk.tklibrary 0x00049948 MenuWorldChanged + 69
  2 com.tcltk.tklibrary 0x0001f05d RecomputeWidgets + 42
  3 com.tcltk.tklibrary 0x0001f069 RecomputeWidgets + 54
  4 com.tcltk.tcllibrary 0x001f5605 TclServiceIdle + 61
  5 com.tcltk.tcllibrary 0x001d79a3 Tcl_DoOneEvent + 342
  6 com.tcltk.tklibrary 0x0001d4c0 Tk_MainLoop + 37
  7 com.tcltk.tklibrary 0x0002b612 Tk_MainEx + 2041
  8 wish 0x00004590 main + 41
  9 wish 0x000044b9 start + 53

  The complete log file is attached. Tcl/Tk 8.5.9 worked fine.


tkt_uuid: 220425ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: wish crashes when searching for text in a text widget
comment:
  OriginalBugID: 1148 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-02'
  LastModified: '1999-04-02'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  RelatedBugIDs: 1056  1666
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '1999-04-02'
  FixedInVersion: 8.1b3


  Name:
  Petasis George

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  I have an entry field that accepts the text to be searched in a text widget.
  I set the system encoding to iso8859-7 (Greek). I select with mouse some greek
  text from an external source (xterm or vim). I paste the text in the entry field. Although the system encoding is iso8859-7, the characters appear in the isoo8859-1 encoding. If i get the contents of the entry widget and use them for searching text using "text search" command, wish crashes. If, instead of pasting with mouse, write some greek characters in the entry field, everything work as expected.



  Related bud ID 1056.

  I have not been able to reproduce the problem, but it probably a side effect of bug 1056/1666 where the text widget was operating in bytes instead of characters.
  04/02/1999 15:50 - stanton -


tkt_uuid: 1623922fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Add wm attribute -blankscreen (TIP pending)
comment:
  This patch adds the -blankscreen attribute for the
  Win32 wm command. This attribute is set to 0 to
  disable the screen saver and APM for the system.
  This is needed for display applications that
  require the screen but don't expect user input
  for a period of time. This patch will be included
  in a TIP shortly.


tkt_uuid: 1191809fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 3 Low
foundin: None
resolution: Fixed
title: Colors on named cursors do not work on MS Windows
comment:
  The following always produce a white cursor with a
  black outline on Windows XP under 8.4.6:

   . configure -cursor {left_ptr red green}
   . configure -cursor {left_ptr red green}

  The documentation pages for options -cusor and
  Tk_GetCursor do not list a MS Windows restriction, only
  Mac restrictions.

  I beleive this is a documentaion bug.


tkt_uuid: 775806ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: None
title: text.test fails on Tru64Unix 5.1A
comment:
  Hi,
    The following fails(I have installed current tcl/tk
  from cvs):

  $ ./tktest ../tests/all.tcl -geometry +0+0 -file
  text.test -match text-15.*
  [...]

  ==== text-15.2 TextCmdDeletedProc procedure, disabling
  -setgrid FAILED
  ==== Contents of test case:

      catch {destroy .top}
      toplevel .top
      wm geom .top +0+0
      text .top.t -setgrid 1 -width 20 -height 10
      pack .top.t
      update
      set x [wm geometry .top]
      rename .top.t {}
      update
      lappend x [wm geometry .top]
      destroy .top
      set x

  ---- Result was:
  20x10+0+0 21x11+0+0
  ---- Result should have been (exact matching):
  20x10+0+0 150x140+0+0
  ==== text-15.2 FAILED


tkt_uuid: 220756ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: Bug in text search -backward
comment:
  OriginalBugID: 6007 Bug
  Version: 8.2.2
  SubmitDate: '2000-07-12'
  LastModified: '2000-07-19'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-07-19'
  FixedInVersion: 8.4a2


  Name:
  Chris Oliver

  ReproducibleScript:
  text .t
  .t search -backward -- "" 1.0

  ObservedBehavior:
  Causes prowish82 to crash in TextSearchCmd in tkText.c, line  1829



  Verified in 8.4a1, Linux.

  - eric

  -- 07/18/2000 ericm

  Thanks for finding this bug.  I fixed it by putting a check for a NULL segment pointer in the search routine.  The fix will go out with Tcl/Tk 8.4a2.  Thanks again for the find!

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

  -- 07/19/2000 ericm


tkt_uuid: 1800744fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Accepted
title: updated en.msg for tk 8.4
comment:
  updated en.msg for tk 8.4
  + added missing "Show &Hidden Directories" and "Show &Hidden Files and Directories" messages
  + changed message: "Ok" to "OK"


tkt_uuid: 1700065fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: None
resolution: None
title: error in trace proc on textvariable doesn't trigger bgerror
comment:
  If a write trace is set on a textvariable for a entry widget, an error in this proc will not call bgerror and will be discarder.

  The same behaviour occurs on 8.4.13 and 8.5a6

  Example script:
  trace variable a w tr
  proc tr args {error $args}
  entry .e -textvariable a
  pack .e
  # typing in the entry will not give any error, a set on the var will, using after a bgerror will be shown
  after 10 {set a 4)

  ::ttk::entry does call the bgerror


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

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

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

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


tkt_uuid: 3529885fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 15. [scale]
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: None
title: negative resolution confuses scale widget
comment:
  A negative resolution is used to indicate that the value should not be rounded, but then clicking in the trough causes the slider to move away from the mouse pointer instead of towards it.


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: 1010607fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 2
foundin: None
resolution: Fixed
title: widgets docs spelling
comment:
  see attached patch
  affected files are:
  button.n entry.n listbox.n message.n panedwindow.n 
  scale.n scrollbar.n spinbox.n


  where is 'screenful' from? does 'screen' is not enough?

  is 'readonly' acceptable, or is 'read-only' better?


tkt_uuid: 1450270fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: None
resolution: None
title: make a window ask for attention
comment:
  Hi,

  In our case we have an instant messaging app. When a
  new message comes in we would like to have the window
  blink in the taskbar (think MSN client on windows). For
  windows we had a solution for a long time, but recently
  we added support for KDE and Gnome as well. So while we
  are covered by our home-made extensions, it might be a
  good idea to implement this into TK itself.
  for documention for KDE/Gnome and some others:
  http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2511314

  our home made libs are here:
  http://cvs.sourceforge.net/viewcvs.py/amsn/msn/utils/linux/linflash/
  http://cvs.sourceforge.net/viewcvs.py/amsn/msn/utils/windows/winflash/

  for windows:
  just get the dll, load it and do:
  winflash $window -count -1

  for linux:
  download source, compile, load it and do:
  linflash $window

  Although this works perfectly it would be nice to have
  something like wm state $window attention or wm
  attention $window

  Sander


tkt_uuid: 220363ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: lost error messages for widget calls with bad args
comment:
  OriginalBugID: 619 Bug
  Version: 8.1a2
  SubmitDate: '1998-05-25'
  LastModified: '1998-11-30'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-30'
  FixedInVersion: 8.1b1


  The other day I noted that under some cirumstances I do not get

  any

  error message when using illegal arguments to widgets. The

  simplest

  way to see this is to start wish8.1 and give the command:

          checkbutton .c -varieble foo

  This gives no error message, which isn't what I had expected.

  The patch below fixes this problem.



          /MaF





  *** generic/tkButton.c.old      Mon Apr 27 23:51:05 1998

  --- generic/tkButton.c  Mon Apr 27 23:54:14 1998

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

  *** 983,988 ****

  --- 983,989 ----

        Tcl_Obj *CONST objv[];    /* Argument values. */

    {

        Tk_SavedOptions savedOptions;

  +     Tcl_Obj *errorResult;

        int error;

        Tk_Image image;



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

  *** 1024,1029 ****

  --- 1025,1032 ----

               * Second pass: restore options to old values.

               */



  +           errorResult = Tcl_GetObjResult(interp);

  +           Tcl_IncrRefCount(errorResult);

              Tk_RestoreSavedOptions(&savedOptions);

          }



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

  *** 1205,1211 ****

        }



        TkButtonWorldChanged((ClientData) butPtr);

  !     return (error) ? TCL_ERROR : TCL_OK;

    }



    /*

  --- 1208,1220 ----

        }



        TkButtonWorldChanged((ClientData) butPtr);

  !     if (error) {

  !       Tcl_SetObjResult(interp, errorResult);

  !       Tcl_DecrRefCount(errorResult);

  !       return TCL_ERROR;

  !     } else {

  !       return TCL_OK;

  !     }

    }



    /*


tkt_uuid: 835010ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Unused variable warning in tkTextDisp.c
comment:
  Compiling with GCC 2.96 on Linux/*x86

  /home/fellowsd/lang/tcl/cvs/maintenance/8.5/tk/unix/../generic/tkTextDisp.c:In
  function `DlineXOfIndex':
  /home/fellowsd/lang/tcl/cvs/maintenance/8.5/tk/unix/../generic/tkTextDisp.c:5736:warning:
  unused variable `dInfoPtr'


tkt_uuid: 220097ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 1 Zero
foundin: obsolete: 8.0
resolution: Invalid
title: Scrollbar display -- jitters
comment:
  OriginalBugID: 543 Bug
  Version: 8.0
  SubmitDate: '1998-03-12'
  LastModified: '1999-11-17'
  Severity: CRIT
  Status: Closed
  Submitter: rjohnson
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-11-17'


  The scrollbar appears to jitter under some window configuations.  Specifically when the scollbar is placed is a space that is small (like 15 or 16 pixels).



  Not reproducible with 8.2.1 build for PPC Mac. 
  -- 11/17/1999 hobbs


tkt_uuid: 1520118fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: None
title: -validate set to none incorrectly
comment:
  If -from and -to are set, -validate is reset to 'none'
  when -invalidatecommand returns false.
  -invalidatecommand is never evaluated.

  Test case:

    proc test {} {
      puts "test"
      return 0
    }
    pack [spinbox .works -validate all -vcmd test -invcmd
  {puts "invalid"}]
    pack [spinbox .broken -from 1 -to 10 -validate all
  -vcmd test -invcmd {puts "invalid"}]

  Try typing in both. The top one should trigger the
  validation on every keypress. The bottom one won't do
  anything because -validate was reset to 'none' when the
  window was created.


tkt_uuid: 477949ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 57. [option]
priority: 5 Medium
foundin: obsolete: 8.4a1
resolution: None
title: option readfile cannot use multibytes
comment:
  since 'option readfile' doesn't convert encodings
  of the target resource file,
  multibyte characters in such resource files
  (mainly for Japanese TrueType font name on MS-win32)
  are not interpretted correctly.

  on MS-Win32 environment, I wrote a resource file:

  *Label*Font: {Times New Roman} 40 normal

  goes well, but when I use Japanese TrueType font
  names replacing above 'Times New Roman',
  the font is not loaded, and the output of
  [.label cget -font] is in some binary(unreadable)
  characters.


tkt_uuid: 1067249fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: Out of Date
title: WinXP: scrollbar test failure
comment:
  One test fails in cvs head:


  ==== scrollbar-6.22 ScrollbarPosition procedure FAILED
  ==== Contents of test case:

      .s identify [expr [winfo width .s] / 2] [expr
  int(.2 / [.s delta 0 1])  + [t
  estmetrics cyvscroll]]

  ---- Result was:
  trough1
  ---- Result should have been (exact matching):
  slider
  ==== scrollbar-6.22 FAILED


tkt_uuid: 494789ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Fixed
title: spinup, spindown s.b. buttonup, ...down
comment:
  spinbox.n talks about spinup and spindown in the identify and invoke subcommands.  The source 
  uses buttonup and buttondown.


tkt_uuid: 664787ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 3 Low
foundin: obsolete: 8.4.1
resolution: Fixed
title: SGI warning: TkPostscriptImage
comment:
  cc-1552 cc: WARNING File =
  /home/fs3c/dgp/tk8.4.1/unix/../generic/tkCanvPs.c, Line
  = 1212
    The variable "depth" is set but never used.

        int i, depth, ncolors;
               ^


tkt_uuid: 915330ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 7 High
foundin: obsolete: 8.5a1
resolution: Fixed
title: Crash w/checkbutton when colors stressed
comment:
  (unix only)

  When using a display where the colors are stressed and
  exhausted, a crash will occur when rendering a
  checkbutton or radio button.

  The attatched patch will fix the problem.

  -Brian


tkt_uuid: 220746ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Fixed
title: If tk_messageBox is first call in script, no subsequent widgets take input
comment:
  OriginalBugID: 5792 Bug
  Version: 8.2
  SubmitDate: '2000-06-02'
  LastModified: '2000-06-02'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT4 SP4
  Machine: Compaq Armada 7400 laptop
  FixedDate: '2000-06-02'
  FixedInVersion: 8.3


  Name:
  Shaun Lowry

  Comments:
  This can be worked around by including a call to 'update' before the
      call to tk_messageBox

  ReproducibleScript:
  tk_messageBox
  button .f -text hello -command {tk_messageBox}
  pack .f

  Command line:

  prowish82 bug.tcl

  ObservedBehavior:
  the button won't take input

  DesiredBehavior:
  Clicking the button should bring up another blank messagebox



  Already fied in 8.3.0 (8.3.1 is current stable). 
  -- 06/02/2000 hobbs


tkt_uuid: 220366ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0
resolution: Fixed
title: bug with checkbutton on main menu frame
comment:
  OriginalBugID: 630 Bug
  Version: 8.0
  SubmitDate: '1998-05-25'
  LastModified: '2000-04-17'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-04-17'
  FixedInVersion: 8.3.1


  Ulrich Lauther <lauther@mchp.siemens.de> wrote:
  There seems to be a big problem when a checkbutton is added to a menubar.
  This becomes visible, when you add the two marked lines
  to the menu.tcl script in tk8.0/demos:

  menu .m
  foreach i {red orange yellow green blue} {
    .m add command -label $i -background $i  -command [list puts "You invoked \"$i\""]
  }

  .m add command -label "cmd" -command {puts cmd}
  .m add checkbutton -label "check"

  . configure -menu .m

  The first added line creates a button, as intended.
  The second one creates havoc!

  PS: This was under Unix. Under Windows, a checkbutton in the menubar
  appears, but the indicator is not displayed.



  Verified with 8.3b1.  There does seem to be some confusion when

  putting these on the main cascade, although they work in the

  drop-down cascades.  There could be some undoc'ed prohibition

  against this (or someone just forgot to code that case...). 

  -- 01/07/2000 hobbs


  .menu.menu invoke cmd

  .menu.menu invoke check


  both work; this might just be a binding problem.


  - eric


  -- 04/03/2000 ericm


  Yes, as I investigate further it seems to be just a binding problem.  However, on Windows, we allow the system to draw the menubar portion of the menu system, so the checkbutton does not get draw correctly.  It does work, however, in the sense that it toggles values appropriately.  I imagine it is probably an OS restriction that disallows checkbuttons/radiobuttons in menubars.


  I have a fix for the bindings:


  diff -c -r1.11 menu.tcl

  *** menu.tcl    2000/03/31 09:24:11     1.11

  --- menu.tcl    2000/04/14 20:46:11

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

  *** 655,661 ****

          tkMenuUnpost $w

        } elseif {[string equal [$w cget -type] "menubar"]} {

          $w postcascade none

  !       $w activate none

          event generate $w <<MenuSelect>>

          tkMenuUnpost $w

        } else {

  --- 655,666 ----

          tkMenuUnpost $w

        } elseif {[string equal [$w cget -type] "menubar"]} {

          $w postcascade none

  !       set active [$w index active]

  !       if { [$w type $active] == "cascade" } {

  !           $w activate none

  !       } else {

  !           uplevel #0 [list $w invoke $active]

  !       }

          event generate $w <<MenuSelect>>

          tkMenuUnpost $w

        } else {


  This needs some extra testing before it gets committed, though.


  - eric


  -- 04/14/2000 ericm


  I have committed this fix to CVS, and it will go out with 8.3.1.  It's important to note that because of system differences, the indicators may not be drawn on all platforms.  For example, Windows does not draw indicators for check/radiobuttons in menubars, although they still work correctly.  This fact is noted in the menu manual entry.


  - eric


  -- 04/17/2000 ericm


tkt_uuid: 220149ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Invalid
title: threading problem in 8.1b1 provoked by tkcvs
comment:
  OriginalBugID: 1582 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-22'
  LastModified: '1999-03-22'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: pat
  OS: Solaris
  OSVersion: 2.6, fully patched
  Machine: Other
  ClosedDate: '1999-03-22'


  Name:
  Andreas Mueller

  Extensions:
  tcl 8.1b1, tk 8.1b1

  ReproducibleScript:
      I've installed tkcvs 6.0 and successfully run it with 8.0.
      Under 8.1b1 it works also some of the time, but stops working
      on a fast (Sun Ultra 60 type) machine when you move the mouse
      over the buttons at the bottom of the main window. Starting
      tkcvs under truss does not show this behaviour (machine seems
      to be more busy then, and thread locking seems not to be a problem).
      



  ObservedBehavior:
      As the problem does not show under truss, I'm quite out of
      luck to send you a trace.
      



  DesiredBehavior:
      tkcvs should not stop working
      




  03/22/1999 08:23 - pat - Problem resolved in 8.1b2
  From: Dr Andreas F Muller <afm@othello.ch>
  Date: Sun, 21 Mar 99 23:24:58 +0100
  To: support@scriptics.com
  Subject: Re: [Bug Tk 8.1b1] threading problem in 8.1b1 provoked by tkcvs
  Status: O

  Just checked with 8.1b2, problem did not show any longer.  Thanks
  for the fine software. Best regards

                                          Andreas Mueller


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

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

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

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


tkt_uuid: 1850888fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: None
resolution: None
title: Dead code: [testfont subfont], TkpGetSubFonts
comment:
  Each of macosx/tkMacOSXFont.c, unix/tkUnixFont.c, unix/tkUnixRFont.c, and win/tkWinFont.c contain a routine TkpGetSubFonts().  This is only called from  TestfontObjCmd() in generic/tkTest.c to implement the [testfont subfonts] command.

  However, [testfont subfonts] is not called anywhere in the test suite.  Can this go away?


tkt_uuid: 220369ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: fix for tk menu bugs
comment:
  OriginalBugID: 636 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1998-08-04'
  Severity: SER
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1998-08-04'


  Viktor Dukhovni <Viktor-Dukhovni@deshaw.com>


  Fix list:


      TRANSPARENT_GIF_COLOR is obsolete.


      Use SHLIB_PATH on HP-UX.


      Raise background error when menu commands fail.


  Index: tcl/vspecific/tk/library/tkfbox.tcl

  diff -c tcl/vspecific/tk/library/tkfbox.tcl:1.1.1.1 tcl/vspecific/tk/library/tkfbox.tcl:1.1.1.1.2.1

  *** tcl/vspecific/tk/library/tkfbox.tcl:1.1.1.1 Thu Jan 29 13:55:21 1998

  --- tcl/vspecific/tk/library/tkfbox.tcl Thu Jan 29 14:03:18 1998

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

  *** 955,961 ****

          catch {unset data(updateId)}

        }


  -     set TRANSPARENT_GIF_COLOR [$w cget -bg]

        if ![info exists tkPriv(folderImage)] {

          set tkPriv(folderImage) [image create photo -data {

    R0lGODlhEAAMAKEAAAD//wAAAPD/gAAAACH5BAEAAAAALAAAAAAQAAwAAAIghINhyycvVFsB

  --- 955,960 ----

  Index: tcl/vspecific/tk/unix/Makefile.in

  diff -c tcl/vspecific/tk/unix/Makefile.in:1.1.1.1 tcl/vspecific/tk/unix/Makefile.in:1.1.1.1.2.1

  *** tcl/vspecific/tk/unix/Makefile.in:1.1.1.1   Thu Jan 29 13:55:27 1998

  --- tcl/vspecific/tk/unix/Makefile.in   Thu Jan 29 14:03:30 1998

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

  *** 320,325 ****

  --- 320,327 ----

    test: tktest

          LD_LIBRARY_PATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH}; \

          export LD_LIBRARY_PATH; \

  +       SHLIB_PATH=`pwd`:${TCL_BIN_DIR}:${SHLIB_PATH}; \

  +       export SHLIB_PATH; \

          TCL_LIBRARY=@TCL_SRC_DIR@/library; export TCL_LIBRARY; \

          TK_LIBRARY=$(TOP_DIR)/library; export TK_LIBRARY; \

          ( echo cd $(TOP_DIR)/tests\; source all\; exit ) \

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

  *** 330,335 ****

  --- 332,339 ----

    runtest:

          LD_LIBRARY_PATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH}; \

          export LD_LIBRARY_PATH; \

  +       SHLIB_PATH=`pwd`:${TCL_BIN_DIR}:${SHLIB_PATH}; \

  +       export SHLIB_PATH; \

          TCL_LIBRARY=@TCL_SRC_DIR@/library; export TCL_LIBRARY; \

          TK_LIBRARY=$(TOP_DIR)/library; export TK_LIBRARY; \

          ./tktest

  Index: tcl/vspecific/tk/win/tkWinMenu.c

  diff -c tcl/vspecific/tk/win/tkWinMenu.c:1.1.1.1 tcl/vspecific/tk/win/tkWinMenu.c:1.1.1.1.2.1

  *** tcl/vspecific/tk/win/tkWinMenu.c:1.1.1.1    Thu Jan 29 13:55:29 1998

  --- tcl/vspecific/tk/win/tkWinMenu.c    Thu Jan 29 14:04:14 1998

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

  *** 1,7 ****

    /* 

     * tkWinMenu.c --

     *

  !  *    This module implements the Mac-platform specific features of menus.

     *

     * Copyright (c) 1996-1997 by Sun Microsystems, Inc.

     *

  --- 1,7 ----

    /* 

     * tkWinMenu.c --

     *

  !  *    This module implements the Windows specific features of menus.

     *

     * Copyright (c) 1996-1997 by Sun Microsystems, Inc.

     *

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

  *** 904,909 ****

  --- 904,910 ----

                      if (mePtr != NULL) {

                          TkMenuReferences *menuRefPtr;

                          TkMenuEntry *parentEntryPtr;

  +                       int code;


                          /*

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

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

  *** 934,941 ****

                              }

                          }


  !                       TkInvokeMenu(mePtr->menuPtr->interp,

  !                               menuPtr, mePtr->index);

                      }

                      *plResult = 0;

                      returnResult = 1;

  --- 935,948 ----

                              }

                          }


  !                       code = TkInvokeMenu(mePtr->menuPtr->interp,

  !                                           menuPtr, mePtr->index);

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

  !                           && code != TCL_BREAK) {

  !                         Tcl_AddErrorInfo(mePtr->menuPtr->interp, 

  !                                          "\n    (menu invoke)");

  !                         Tcl_BackgroundError(mePtr->menuPtr->interp);

  !                       }

                      }

                      *plResult = 0;

                      returnResult = 1;




  Applied all patches 8/4/98 (SS)


tkt_uuid: 220063ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Duplicate
title: I have to click twice to bring up a menubar menu when another window has focus
comment:
  OriginalBugID: 4164 Bug
  Version: 8.3
  SubmitDate: '2000-02-14'
  LastModified: '2000-02-25'
  Severity: LOW
  Status: Closed
  Submitter: sven
  ChangedBy: hobbs
  RelatedBugIDs: 2272
  OS: All Windows
  ClosedDate: '2000-02-25'


  In the SCAuthor IDE, the user has to click twice to bring up a menu from the menubar when another window than the menu window has the focus.

  To reproduce:
  1. Start the IDE
  2. click on the project window to get the focus there
  3. Click on the file menubutton in the main window

  Result:
  The window gets the focus, but I have to click again to bring up the menu

  Expected behavior:
  The window gets the focus, and the menu pops up


tkt_uuid: 3417012fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 15. [scale]
priority: 5 Medium
foundin: None
resolution: None
title: Segfault if [scale]'s -digits parameter value too large.
comment:
  Example:
  scale .s -digits 1000 will segfault
  or
  scale .s -digits <somelargenumber> ; .s get will segfault


tkt_uuid: 1048942fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: text.tcl: Mousewheel binding output to stderr
comment:
  Tcl/Tk: v8.5a2
  OS: WinXPsp2
  Built with makefile.vc using VC7

  When trying to use the scrollwheel in wish all I get 
  are a stream of numbers printed in red. These appear 
  to be test indicators for scroll speed for both up 
  (positive numbers) and down (negative numbers) 
  directions.


tkt_uuid: 1024742fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: None
resolution: None
title: better support for Type 1 fonts on WinXP
comment:
  Tk has a rather clever method of font substitution; 
  however, it doesn't work well with Type 1 fonts on 
  WinXP.

  The trouble seems to be in tkWinFont.c, in the function 
  LoadFontRanges().  It uses GetFontData() from the 
  Win32 API, but the platform SDK states "If an application 
  attempts to use this function to retrieve information for 
  a non-TrueType font, an error occurs."

  I wrote a little program (source available on request) to 
  try this out, and indeed

    n = GetFontData(hdc, cmapKey, 0, &cmapTable, sizeof
  (cmapTable));

  returns GDI_ERROR with a Type 1 font selected into 
  hdc.  (I cut-and-pasted this from tkWinFont.c, along 
  with what I thought was enough of the preceding code 
  to declare the tables and whatnot.)  Perhaps this isn't 
  saying much, since even for TrueType fonts I get 
  GDI_ERROR.  Maybe using

    hdc = CreateCompatibleDC(NULL);

  to create a device context isn't the right way; maybe I 
  need to write a "real" Windows program with WinMain 
  and a HWND so I can get a real HDC instead of plain 
  main.  But we will assume the docs to be true, so that 
  Type 1 fonts return GDI_ERROR.

  So, I check

    if (GetTextCharset(hdc) == ANSI_CHARSET)

  as tkWinFont.c does, and this comes up true for every 
  font I throw in, Type 1 or TrueType.  The code in 
  LoadFontRanges() would then declare that the character 
  range for the font is 0x00 to 0xff, which means that for 
  a Type 1 font any character outside of that range will 
  be substituted for, as is the case.

  Now, WinXP (and Win2K) has a function 
  GetFontUnicodeRanges() that accurately reports what 
  glyphs are available in a Type 1 font.  It also works for 
  TrueType fonts.  I propose that this function be used in 
  tkWinFont.c instead of GetFontData() for those ports of 
  Tk to versions of Windows that support it.  TextOut() 
  works with Type 1 fonts (from personal experience), so I 
  would assume GetTextExtentPoint32() would also, 
  meaning that very little of the rest of tkWinFont.c would 
  have to be touched.

  I suppose I should submit a patch.  Why don't I?

  1) I've never submitted a patch before.
  2) I don't know the protocol for patching something to 
  work on only some versions of Windows.


tkt_uuid: 411893ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Duplicate
title: font names returned as single chars
comment:
  In a statically linked TK application (built with TCL 
  PRO 1.4.1), on Windows/NT, font names returned by the 
  [font families] command consist only of the first 
  character of each name.

  I have debugged the code, and it appears that 
  TkpFontPkgInit is called before TkWinXInit; the latter 
  initialises the tkPlatformId variable which is used 
  indirectly by the former.  This all means that 
  systemEncoding does not get set on NT systems, and the 
  TkpGetFontFamilies function does not decode the font 
  list returned by NT correctly.


tkt_uuid: 1060155fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4.8
resolution: Works For Me
title: raise-* failures on Windows
comment:
  Building 8.4-head of 04Nov2004 11:30 GMT on Windows XP
  we get a pile of errors from raise.test. A sampling:

  ==== raise-1.2 preserve creation order FAILED
  ==== Contents of test case:

      raise_setup
      testmakeexist .raise.a
      update
      raise_getOrder

  ---- Result was:
  tktest tktest tktest tktest tktest tktest tktest tktest
  ---- Result should have been (exact matching):
  d d d b c e e e
  ==== raise-1.2 FAILED


tkt_uuid: 220506ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 28. Utility Functions
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: Docs missing for Tk_GetScrollInfoObj API
comment:
  OriginalBugID: 1866 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '2000-04-25'
  Severity: MED
  Status: Released
  Submitter: surles
  ChangedBy: ericm
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-04-25'
  FixedInVersion: 8.3.1


  .

  I added a manual entry for this API for 8.3.1.

  - eric
   
  -- 04/25/2000 ericm


tkt_uuid: 3147952fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: Out of Date
title: smarter updating of ttk::treeview display
comment:
  I propose some combination of visible set determination, a better search structure, and throttled GUI updates be implemented for a reasonable balance between keeping the GUI responsive and inserting a large data set into a ttk::treeview widget (and perhaps other data display widgets).

  The cost of updating the display for a ttk::treeview appears to be proportional to the number of non-detached items.  This is a problem if you want to load a large data set (hundreds of thousands or millions of items) and start seeing things right away.  Maybe the treeview is not designed for this purpose, but I didn't find the multicolumn widget that is.  So far I have found the following options, all at least somewhat unsatisfactory:

  1. Don't update.  This gets everything inserted in the minimum amount of time, but locking up the GUI for several seconds is not really acceptable.
  2. Update after every insertion.  This keeps the GUI responsive but it takes orders of magnitude too long to insert all the items, even for a very moderate number of items (tens of thousands).
  3. Update only after some time elapsed or number of insertions, or some adaptive scheme involving both.  A huge improvement over (2) but still way too slow for large data sets.  Also, I don't think "post redisplay" is something I should have to implement myself.
  4. Insert everything as a child of a detached item and make them the children of {} only at the very end.  The GUI remains responsive and the insertions complete in a reasonable amount of time as long as you implement (3), but nothing is displayed until all the items are inserted.
  5. Insert and update normally until the visible area is full and then switch to (4).  But what if the user changes the viewport before everything is inserted?

  If we could maintain the visible set of items and insert items and compute their geometry without actually realizing them, then updates could basically take constant time as long as the viewport remains constant.  If we maintained better search structures, then inserting at arbitrary locations and viewport changes could be handled nicely as well.  That would also address the (undocumented?) quadratic running time of inserting all items at the end.  And if GUI updates were throttled in general then I maybe would simply be able to use plain old update instead of workaround (3)?


tkt_uuid: 842952ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: scrollbar dragging jumps and is too slow
comment:
  When dragging the TkAqua scrollbar, the new scrollbar
  position is calculated based upon the mouse's absolute
  position within the scrollbar-control.

  This is not how scrollbars should work, however.  The
  position should be calculated as if the user were
  actually dragging the bar physically with the mouse --
  i.e. a pixel offset should be calculated of the current
  mouse position relative to the original mouse-click
  position, and that pixel offset should then be
  reflected onto the scrollbar's coordinate system and
  applied directly.  Then a range-check should be made to
  ensure the value remains within [0,1.0]

  Furthermore, the moment the mouse strays a pixel
  outside the scrollbar control, the scrollbar position
  is reset!!  This is totally against the HIG. In fact
  the way Aqua works is to allow the mouse to be anywhere
  on screen at all, and still maniplate the scrollbar as
  long as the button is still held down (WinXP is
  slightly different and provides about an inch of leeway
  around the control).

  The first of these problems is quite clear, here:

                  if (scrollPtr->vertical == true) {
                      newFirstFraction =  (1.0 -
  thumbWidth) *
                          ((double) (currentPoint.v -
  trackBarPin) / trackBarSize);
                  } else {
                      newFirstFraction =  (1.0 -
  thumbWidth) *
                          ((double) (currentPoint.h -
  trackBarPin) / trackBarSize);
                  }

  But I'm not really knowledgeable enough to fix it.


tkt_uuid: 409566ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Out of Date
title: tcl/tk on MacOS-Japanese
comment:
  I can't start up WISH application.

  When start up, It display dialog with no text and 
  button.

  this is same result if I use OS started with no-
  extension( shift-key start up )

  environment:
     8500/G3-300 MacOS9.1(J)
     G3(B/W) 400 MacOS9.04(J)


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: 2925561fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: Reopen of 2834772; ttk::combobox receives focus when disable
comment:
  I still get the a <FocusIn> event with latest ActiveState 8.5.8.
  Fresh download from 4.1.2010.

  OS: Sparc Solaris 10
  Tk_Patchlevel 8.5.8

  How to reproduce

  ttk::combobox .c -state disabled
  pack .c
  bind all <FocusIn> {puts "%W focus in"}

   ...click inside combox entry field..

  I see the message of the bind

  Maybe it is an OS specific issue with focus


tkt_uuid: 219926ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Duplicate
title: Strange file dialog behaviour on Windows
comment:
  OriginalBugID: 1339 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-12'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2111 2312
  OS: Windows NT
  OSVersion: 4.0 SP3
  Machine: X86
  ClosedDate: '1999-08-12'


  Name:
  Peter Spjuth

  ReproducibleScript:
      button .b -text Dialog -command tk_getOpenFile
      pack .b
      checkbutton .c -text aaaaa -relief raised
      pack .c -expand 1 -fill both
      -------
      Resize the window to make the checkbutton larger
      Press the Dialog button to bring up the file selector
      Move the file selector to place one of the files listed over the
      checkbutton.
      Double click on the file. The dialog disappears and the checkbox is
      selected.
      
      



  ObservedBehavior:
      It seems that the second click goes through to the main window when the
      dialog disappears, which is very annoying. 
      
      I have tested this with 8.0p2 under Solaris and there it works as it
      should.
      
      




  This was answered here:
      http://x23.deja.com/[ST_rn=ps]/getdoc.xp?AN=496001244

  This is more of a Windows native dialog problem, but requires
  that the Tk user be aware of the quirk with that dialog.  
  -- 08/12/1999 hobbs


tkt_uuid: 1721393fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Duplicate
title: tk/unix/README typo
comment:
  In section (d) of the README, after talking about Tk, the verbage talks about running a configure that configures Tcl for your system. It should say Tk.

  Also, I suspect that in the Note: in section (d), the text should read

  It is not safe to change the Makefile to use cc after configure is run. 

  The previous sentence was emphasizing that one now has to set the CC environment variable if they want to use cc instead of gcc - this change would be more consistent with what seems to be the intent of the note.

  In section (g), the word "directoryies" should be "directories".


tkt_uuid: 1916280fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Duplicate
title: text widget large load and scrollbar weirdness
comment:
  The following script demonstrates weirdness in 8.5
  with the scrollbar wherein a large load appears normally
  (as in 8.4/3), BUT if <Control-1> is used in the middle of the scrollbar, the scrollbar continuously adjusts
  for 45 seconds as though a load is still in progress.  

  However, using <Control-Next>, to immediately go to EOF shows that all the data is already loaded.

  (Tested on Linux i86 and x64)

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

  text .n -yscrollcommand ".s set"
  pack [scrollbar .s -command ".n yview"] -fill y -side left
  pack .n -fill both -expand y -side left
  .n conf -tabs {20 120}
  for {set i 0} {$i<10000} {incr i} {
      set nn [.n insert end "\tNODE $i\n"]
          for {set j 0} {$j<10} {incr j} {
              .n insert end "\t  SUBNODE $i.$j\n"
          }
  }


tkt_uuid: 559078ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: Spinbox: -from overwrites -textvariable
comment:
  When I create a spinbox-widget with both options (from 
  and textvariable) like this:
  set t 8
  spinbox .sb -from 1 -to 16 -textvariable t
  Than spinbox shows "1" and sets t to 1.
  I would have expected that the option "textvariable" has 
  precedence over option "from".

  A workaround is:
  spinbox .sb -textvariable 5
  .sb configure -from 1 -to 16
  which works as expected.


tkt_uuid: 1800192fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 8
foundin: None
resolution: Duplicate
title: make test: many failures
comment:
  Linux Suse-10.1 x86_64
  tk 8.5 cvs version 22 september 2007
  tcl and tk are built withouit problem
  make test succeds for tcl but may tests fail for tk

  The test hangs on the window test, I had to abort it 
  with Control-C.

  Failure also on a very simple tk script that I use for years (freezes instead onf exiting)

  I attach config.log.gz
  and the gzipped output of make test


tkt_uuid: 1014213fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Fixed
title: text -exportselection 0 stills clears 'sel'
comment:
  If a text widget has a selection, but is configured
  with -exportselection 0, and the widget loses the focus
  (e.g. click on another window), the previously-selected
  text becomes unselected in the display (the information
  is still remembered on Win/MacOS X, but is not displayed).

  This seems to be contrary to the documentation for
  '-exportselection', and contrary to the behaviour of
  other widgets (e.g. listbox) with -exportselection 0.

  It seems to me there are two possible solutions:

  (i) This is a bug and should be fixed.

  or 

  (ii) This is considered desirable, but the opposite
  behaviour should be possible under user control. Then
  we should add a 'inactiveselectionbackground' (or some
  other name?) configuration option to the widget which
  is applied to the "sel" tag to specify a colour to use
  when the selection doesn't have the focus.

  I think (i) is probably the preferable fix.


tkt_uuid: 1475865fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 8
foundin: obsolete: 8.5a3
resolution: Fixed
title: Crash in font families
comment:
  Althought I have been unable to reproduce this, a
  customer of ours reported a crash on a new RedHat
  system that I've tracked down to the code below from
  tkUnixFont.c.  This is in 8.4.9, but the code is the
  same in the current HEAD (8.5).  The crash is in
  strchar() and my theory is that ListFonts() is
  returning a font name that does not contain a '-' or
  contains only 1 '-'.  In any event, good programming
  practice would dictate that a test for a NULL return
  value would be in order here.  

  void
  TkpGetFontFamilies(interp, tkwin)
      Tcl_Interp *interp;/* Interp to hold result. */
      Tk_Window tkwin;/* For display to query. */
  {
      int i, new, numNames;
      char *family;
      Tcl_HashTable familyTable;
      Tcl_HashEntry *hPtr;
      Tcl_HashSearch search;
      char **nameList;
      Tcl_Obj *resultPtr, *strPtr;

      resultPtr = Tcl_GetObjResult(interp);    

      Tcl_InitHashTable(&familyTable, TCL_STRING_KEYS);
      nameList = ListFonts(Tk_Display(tkwin), "*",
  &numNames);
      for (i = 0; i < numNames; i++) {
  family = strchr(nameList[i] + 1, '-') + 1;
  strchr(family, '-')[0] = '\0';
  Tcl_CreateHashEntry(&familyTable, family, &new);
      }
      XFreeFontNames(nameList);

      hPtr = Tcl_FirstHashEntry(&familyTable, &search);
      while (hPtr != NULL) {
  strPtr = Tcl_NewStringObj(Tcl_GetHashKey(&familyTable,
  hPtr), -1); 
  Tcl_ListObjAppendElement(NULL, resultPtr, strPtr);
  hPtr = Tcl_NextHashEntry(&search);
      }

      Tcl_DeleteHashTable(&familyTable);
  }


tkt_uuid: 220721ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: some fonts cannot be selected
comment:
  OriginalBugID: 4931 Bug
  Version: 8.3
  SubmitDate: '2000-04-07'
  LastModified: '2000-04-07'
  Severity: SER
  Status: Released
  Submitter: hobbs
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4
  FixedDate: '2000-04-07'
  FixedInVersion: 8.3.1


  Reproducible script:
  pack [text .t -font {{Bitstream Cyberbit} 10}]
  .t insert end "This should be [.t cget -font]"

  Observed behavior:
  The font is NOT Cyberbit (which should look Times-like on Latin
  alphabet), but some Arial-like default font. Similar behavior when
  selecting Bookman Old Style, Djerba simplified, Lucida Sans Unicode,
  which are all installed and listed by the font families command.

  Desired behavior:
  Get them fonts back! (They worked up to Tcl 8.2.3).


  The problem was due to an badly made correction in adjusting for

  the max face size of a font in Windows.  For NT, we weren't adjusting

  for the fact that the string is wide chars, thus the input string

  could be twice as long.  Thus any font over 16 chars in length

  (== 32 since they're wide, which is the value of LC_FACESIZE) was

  not being correctly found (dumped back to default Arial).  The fix

  is below and will be in 8.3.1.



  RCS file: /home/cvs/external/tk/win/tkWinFont.c,v

  retrieving revision 1.9

  diff -c -r1.9 tkWinFont.c

  *** tkWinFont.c 2000/03/31 09:24:27     1.9

  --- tkWinFont.c 2000/04/07 20:35:53

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

  *** 1947,1961 ****

    

        Tcl_UtfToExternalDString(systemEncoding, faceName, -1, &ds);

    

  -     /*

  -      * We can only store up to LF_FACESIZE characters

  -      */

  -     if (Tcl_DStringLength(&ds) >= LF_FACESIZE) {

  -       Tcl_DStringSetLength(&ds, LF_FACESIZE);

  -     }

  - 

        if (TkWinGetPlatformId() == VER_PLATFORM_WIN32_NT) {

          Tcl_UniChar *src, *dst;

          src = (Tcl_UniChar *) Tcl_DStringValue(&ds);

          dst = (Tcl_UniChar *) lf.lfFaceName;

          while (*src != '\0') {

  --- 1947,1961 ----

    

        Tcl_UtfToExternalDString(systemEncoding, faceName, -1, &ds);

    

        if (TkWinGetPlatformId() == VER_PLATFORM_WIN32_NT) {

          Tcl_UniChar *src, *dst;

  + 

  +       /*

  +        * We can only store up to LF_FACESIZE wide characters

  +        */

  +       if (Tcl_DStringLength(&ds) >= (LF_FACESIZE * sizeof(WCHAR))) {

  +           Tcl_DStringSetLength(&ds, LF_FACESIZE);

  +       }

          src = (Tcl_UniChar *) Tcl_DStringValue(&ds);

          dst = (Tcl_UniChar *) lf.lfFaceName;

          while (*src != '\0') {

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

  *** 1964,1969 ****

  --- 1964,1975 ----

          *dst = '\0';

          hFont = CreateFontIndirectW(&lf);

        } else {

  +       /*

  +        * We can only store up to LF_FACESIZE wide characters

  +        */

  +       if (Tcl_DStringLength(&ds) >= LF_FACESIZE) {

  +           Tcl_DStringSetLength(&ds, LF_FACESIZE);

  +       }

          strcpy((char *) lf.lfFaceName, Tcl_DStringValue(&ds));

          hFont = CreateFontIndirectA((LOGFONTA *) &lf);

        }


tkt_uuid: 220382ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Tk envent loop is too slow on Mac
comment:
  OriginalBugID: 688 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-02'
  LastModified: '1999-11-30'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-11-30'
  FixedInVersion: 8.2.1


  > >This is basically a bug.  Mac Tk just updates too slowly.  The event loop
  > >& "update" mechanism in Tk needs to be redone to better handle the
  > >exteremly slow event loop on the Mac.


  Tested the 8.2.1 version on a PPC machine with tetris at
  level 17, and it moves the pieces at least as fast as my
  NT machine at the same level (as in, it moves along). 
  -- 11/30/1999 hobbs


tkt_uuid: 691774ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 41. Photo Images
priority: 8
foundin: None
resolution: None
title: Photo Image Rotation
comment:
  Add a subcommand to photo images to allow for rotation
  of them.  You can do this partially using code on the
  Wiki, but it is slow (especially due to colour
  reparsing, I believe) and can't handle the alpha
  channel at all.


tkt_uuid: 1183841fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Invalid
title: Window item only shows if widget created after canvas
comment:
  A window item on a canvas will not appear if its widget
  is created before the canvas is created. Here is a
  simple example, showing both possible orders.

  $ wish
  % info patchlevel
  8.5a2
  % button .b -text "Hi there"
  .b
  % pack [canvas .c]
  % .c create window 100 100 -window .b
  1
  % # cannot see button
  % exit

  $ wish
  % pack [canvas .c]
  % button .b -text "Hi there"
  .b
  % .c create window 100 100 -window .b
  1
  % # Now I can see the button !!!
  %


tkt_uuid: 476176ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 4
foundin: None
resolution: Fixed
title: wish core dump with frame -container on
comment:
  From: David Gravereaux <davygrvy@pobox.com>
  Newsgroups: comp.lang.tcl
  Subject: Re: wish core dump with frame -container on NT

  pat@porky.home.net (Pat Thoyts) wrote:
          
  >Ralf Fassel <ralfixx@gmx.de> wrote:
  >>Can anybody confirm this with wish on Windows NT:
  >>
  >>    $ wish
  >>    % frame .f -container 1
  >>    % exit
  >>    Segmentation fault (core dumped)
  >>
  >>This is with cygnus tcl/tk 8.0 and a customized wish
  8.3.3.
  >>Unfortunately I don't have a plain windows wish
  installed.
  >>
  >>R'
  >
  >Well I can confirm that this crashes on Windows 98
  with Tcl and Tk
  >8.3.4. As I havn't built the debug version yet I don't
  have any
  >more info. l8r

  here's the fix for it.  Please post this into the
  sourceforge BugDB.  I'm not
  much for following-up on bugs I don't consider my own,
  sorry..


  Index: tkWinEmbed.c
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/win/tkWinEmbed.c,v
  retrieving revision 1.4
  diff -c -r1.4 tkWinEmbed.c
  *** tkWinEmbed.c        2000/07/06 03:17:44     1.4
  --- tkWinEmbed.c        2001/10/27 09:43:53
  ***************
  *** 632,637 ****
  --- 632,638 ----

        prevPtr = NULL;
        containerPtr = tsdPtr->firstContainerPtr;
  +     if (containerPtr == NULL) return;
        while (1) {
          if (containerPtr->embeddedPtr == winPtr) {
              containerPtr->embeddedHWnd = NULL;


  --
  David Gravereaux <davygrvy@pobox.com>

  $ make war
  make: *** No rule to make target `war'.  Stop.  Try
  `love' instead.


tkt_uuid: 2000509fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 71. Error Handling
priority: 5 Medium
foundin: None
resolution: None
title: Segmentation fault
comment:
  Hello there,
  I am a new user of Python.
  I have installed Python packages TK & TCL (Version 8.5) and Python (Version 2.5) on Sun OS Version 5.8 Generic i386 machine.
  For installation I have used compiled source code from www.sunfreeware.com.
  I have also installed all dependent packages for Python.
  I am getting segmentation fault when I am trying to execute python gui which uses Tkinter widgets Button Label.

  Could you please advice me how to make Tkinter work on sun OS.

  Regards, Rinku


tkt_uuid: 220547ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: None
resolution: Fixed
title: Request for "-visible" canvas item option
comment:
  OriginalBugID: 2297 RFE
  Version: 8.1.1
  SubmitDate: '1999-06-28'
  LastModified: '1999-12-13'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: 4.00.951
  Machine: X86
  FixedDate: '1999-12-13'
  FixedInVersion: 8.3b1


  Name:
  John Nakulski

  DesiredBehavior:
  It is not possible to hide a canvas item (such as a line or a photo
      image) temporarily.
      My current work-around is to either:
      (a) Move the item off-screen. This is dangerous, because the user might
      scroll to that section of the canvas.
      (b) Delete the item, and store its attributes in a buffer (or to a Tcl
      command string) to later recreate the item.
      I would like a "-visible" option for every canvas item that allows me to
      show/hide canvas items easily:
      # Sample program with requested feature
      canvas .c
      pack .c
      .c create line 0 0 10 10
      .c configure -visible 0 ;# hide the line
      .c configure -visible 1 ;# show the line



  in 8.3b1 (-state hidden for items) 
  -- 12/13/1999 hobbs


tkt_uuid: 707778ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: None
title: canvas/scrollbar/text return wrong configure synonym info
comment:
  Most widgets return configure information with synonyms
  pointing to the associated configure option switch. The
  canvas, scrollbar and text widgets return synonyms
  pointing to the database name. e.g.

  % button .b
  .b
  % join [lsort [.b configure]] \n
  ...
  -background background Background #d9d9d9 #d9d9d9
  -bd -borderwidth
  -bg -background
  -bitmap bitmap Bitmap {} {}
  -borderwidth borderWidth BorderWidth 2 2
  ...
  -fg -foreground
  -foreground foreground Foreground Black Black
  ...

  (Note how -bg maps to -background and -bd to -borderwidth)

  % text .t
  .t
  % join [lsort [.t configure]] \n
  ...
  -background background Background #d9d9d9 #d9d9d9
  -bd borderWidth
  -bg background
  -borderwidth borderWidth BorderWidth 2 2
  ...
  -fg foreground
  -foreground foreground Foreground Black Black
  ...

  (Here -bg maps to background and -bd to borderWidth}

  In 8.3.5, the frame, message and toplevel widgets also
  suffered from this bug, but appear fixed in 8.4.


tkt_uuid: 220088ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Duplicate
title: Main Window in Author doesn't raise when clicked
comment:
  OriginalBugID: 5482 RFE
  Version: 2.0b9
  SubmitDate: '2000-05-12'
  LastModified: '2000-05-27'
  Severity: MED
  Status: Closed
  Submitter: shawn
  ChangedBy: hobbs
  RelatedBugIDs: 4016
  OS: Windows NT
  ClosedDate: '2000-05-27'


  to reproduce - Hide the main author window partially with another connect window - 

  click on the window - and it doesn't raise - 

  I expect it to raise to the front of the other windows 



  Duplicate, this is a Tk problem. 
  -- 05/12/2000 redman
  This is just an incorrect assumption, if I understand the desc (which
  is just too short).  Connect makes toplevels transients of the main
  window, and transients always maintain stay-on-top behavior. 
  -- 05/12/2000 hobbs

  I guess that I don't agree that this is not a bug - if it's not a bug in tk (which I don't agree with either - really the stay on top behavior of transients should be optional), I still expect to raise the main window in Author to the front by clicking in the window - so that I can access the main controls in that window, even if it's obsured by another Author window.    
  -- 05/12/2000 shawn

  If I can expand on this a little - The behavior of a transient window is excellent in the case of a small error message serving a big window - in that case the transient behavior of popping up the error message serves us really well - it's easy to find the error window that way. Another model that works well is to use a toplevel without the transient behavior for the error message - then it can be found using the window manager in the OS - although the transient model is still much better. 

  This fails miserably however if you set a grab on the window - because if the window gets obscured by another application - suddenly - it is impossible to find the window and it can't be raised by clicking in the main application window - and the transient window can't be found using the window manager. It would be really nice if a single click in any of the application windows would raise the whole set of windows to the front - yet still require that the window with the grab get the attention.  

  The model I am thinking of is more like parents - where the three windows in the IDE toplevel share the same responsibility (they are like partners) for the children windows - and for each other.  Each one raises all the windows in the application - each one is fully functional, and can be raises itself  to the front - and we don't get the accumulation of icons that we would see in the .toplevel (without the transient behavior) model. Each of the three windows would behave the way a transient does now - without any window having to be "less" important by always having to stay behind. 

  This would be a good enhancement to the core, and would give the gui programmer more flexibility.  And it would make Ajuba easier to use.  

  -- 05/15/2000 shawn

  Finer grained control of toplevels is already specified by 4016.
  There should also be a Connect ticket opened linking to that. 
  -- 05/27/2000 hobbs


tkt_uuid: 3055902fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Invalid
title: Control-a key binding for text widget is broke
comment:
  The <Control-a> binding for text widgets doesn't work properly with regards to the sel tag.
  <Control-o> works fine. 

  It seems to be related to newlines somehow, as even the Control-o binding (below) inserts extra newlines.
  Tested on 8.4 and 8.5. Hope i'm not missing something...
  -----------------
  pack [text .t]
  .t insert end {some text
  and more}
  bind .t <Control-a> {.t tag add sel 0.0 end-1c}
  bind .t <Control-o> {.t tag add sel 0.0 end-1c}


tkt_uuid: 1452419fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Text widget with space in its name
comment:
  In the Tk-8.4.12 text widget, the undo/redo does not
  work when the text widget has a space in its name:

  % set t [text {.sp ace} -undo 1]
  .sp ace
  % $t insert insert test
  % $t edit undo
  bad option "ace": must be bbox, cget, compare,
  configure, debug, delete, dlineinfo, dump, edit, get,
  image, index, insert, mark, scan, search, see, tag,
  window, xview, or yview

  Attached patch fixes this problem.


tkt_uuid: 2001072fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Works For Me
title: tk_messageBox causes text entry to become unselectable
comment:
  Running this on windows:

  entry .e -textvariable foo
  pack .e
  set foo foo
  tk_messageBox -message hi 

  Cannot select the text in the entry. It WILL select if a console window is opened (so to reproduce, put code in a file and run via a command line - e.g. wish test.tcl - or tclkit test.tcl - if you open up a console and type in the commands it does NOT reproduce the error).

  I run on windows 2000, but others have reproduced this on xp and vista.


tkt_uuid: 219976ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: Need to click twice on menus to post on Windows
comment:
  OriginalBugID: 1949 RFE
  Version: 8.0.3
  SubmitDate: '1999-04-27'
  LastModified: '2000-01-27'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2272
  OS: Windows NT
  Machine: X86
  ClosedDate: '2000-01-27'


  Name:
  Laurent Duperval

  DesiredBehavior:
  On WinNT, if a window contains a menu bar and you click on one of the menu items, the window is raised but the menu is not posted. You must click on the menu a second time to post it. All other MS apps post the menu when the window is raised.


tkt_uuid: 220718ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: text widget dramatically slows down execution of unrelated commands on HP-UX
comment:
  OriginalBugID: 4731 Bug
  Version: 8.2.3
  SubmitDate: '2000-03-30'
  LastModified: '2000-04-20'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: HP-UX 10.20
  Machine: J7000 J2240 J282 715/100
  FixedDate: '2000-04-20'
  FixedInVersion: 8.3.1


  Name:
  Ludwig Callewaert

  ReproducibleScript:
  run the following script through wish and watch the printed times.

  proc isLessThan {i1 i2} {
     scan "$i1 $i2" "%d.%d %d.%d" line1 char1 line2 char2
     if { $line1 < $line2} {
        return 1
     } elseif { $line1 > $line2} {
        return 0
     } else {
        if {$char1 < $char2} {
           return 1
        } else {
           return 0
        }
     }
  }

  proc SlowDown {} {
     .t insert end "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
     .t insert 1.0 "aa" "tag2"
  }

  proc test {} {
     pack [text .t]
     update idletasks
     for {set i 0} {$i < 100} {incr i} {
        for {set j 0} {$j < 100} {incr i} {
           puts [time {isLessThan $i.$j $j.$i}]
           SlowDown
        }
     }
  }

  test

  ObservedBehavior:
  The execution time of the isLessThan instruction increases depending on the content of the text widget. In this case a slowdown of 2x is observed.
  In our real application, a slowdown of > 10x was observed making the application
  unusable. This only happens on HP-UX. Solaris and NT are fine.

  DesiredBehavior:
  The execution time of the isLessThan routine should not depend on the state
  of the text widget, as it is on other platforms.



  This turns out to likely be a problem with the system allocator
  (replacing that fixed the problem, or also using Tcl's replacement
  of USE_TCLALLOC worked).  8.3.1 has a few patches so that USE_TCLALLOC
  will work OK on Unix (needed a couple of #defs). 
  -- 04/20/2000 hobbs


tkt_uuid: 1686210fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 9 Immediate
foundin: obsolete: 8.4.15
resolution: Fixed
title: editorial nits
comment:
  I'm attaching a patch file for about 8 of the .n man pages, fixing small typos either in spelling or, in at least one case, spacing.

  None of these are critical, but hopefully will contribute to improving the releases.


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

  After downloading from the CVS tk and wish builds well.


tkt_uuid: 220730ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: creating a simple button crashes Wish shell.
comment:
  OriginalBugID: 5240 Bug
  Version: 8.3
  SubmitDate: '2000-04-24'
  LastModified: '2000-04-24'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: MacOS 8.6
  Machine: Mac 8500 with G3
  FixedDate: '2000-04-24'
  FixedInVersion: 8.3.1


  Name:
  Rob Barris

  Extensions:
  Stock 8.3.0 download

  ReproducibleScript:
  Launch the "Wish" shell.
  Enter this code (from Osterhout's book "Tcl and the Tk Toolkit", page 9)

   button .b -text "Hello World" -command exit
   pack .b

  ObservedBehavior:
  Program crashes with an access fault in GenerateKeyEvent.  At this time a 
  button with the proper text has appeared, drawn in the Wish window, but this 
  crash occurs immediately following the appearance of the button.  The 
  dereference that fails is off of R3 which holds 7fff7fff. A MacsBug stdlog 
  follows - this is on an 8500+G3 with 192MB of RAM (VM=800MB) and MacOS 8.6.

    MacsBug 6.5.4a6, Copyright Apple Computer, Inc. 1981-98

  PowerPC unmapped memory exception at 3D57C444 GenerateKeyEvent+0014C

    21-Apr-2000 5:48:17 PM (since boot = 6 hours, 28 minutes)
    Current application is Wish
    Machine = 69 (PowerMac8500), System $0850, sysu = $01008000
    ROM version $077D, $28F1, $0001 (ROMBase $FFC00000)
    VM is on; paging is currently safe
    NIL^ = $FFC10000
    Stack space used = +793678690
   Address 3D57C444 is in VM file-mapped logical memory space
   It is in the CFM fragment tk8.3 at 3D55B000
   It is 00021444 bytes from the start of the fragment
    and 00017F74 bytes into a non-writeable code section at 3D5644D0
   PowerPC 740/750 Registers
                           CR0  CR1  CR2  CR3  CR4  CR5  CR6  CR7
    PC  = 3D57C444     CR  0010 1010 0000 0000 0000 1000 1000 1010
    LR  = 3D57C428         <>=O XEVO
    CTR = 004883F8
    MSR = 00000000         SOC Compare Count
    Int = 0            XER 000   00     00                     MQ  = FFC3C6A2

    R0  = 0024000D     R8  = 000000ED      R16 = 00000000      R24 = 00000001
    SP  = 2F0F8DA0     R9  = 000000ED      R17 = 00000000      R25 = 2F0F9178
    TOC = 2ED108E0     R10 = 00000000      R18 = 00000000      R26 = 2ED1E40C
    R3  = 7FFF7FFF     R11 = 004C517C      R19 = 00000000      R27 = 2ED0457C
    R4  = 00000000     R12 = 3D57C40C      R20 = 00000000      R28 = 2F0F8F34
    R5  = 00000000     R13 = 00000000      R21 = 00000000      R29 = 00000000
    R6  = 2F0F8E40     R14 = 00000000      R22 = 00000000      R30 = 24D92478
    R7  = 2F0F8E44     R15 = 00000000      R23 = 00000000      R31 = 00000000
   Disassembling PowerPC code from 3D57C41C
    GenerateKeyEvent
       +00124 3D57C41C   addi       r6,SP,0x00A0                            | 
  38C100A0
       +00128 3D57C420   addi       r7,SP,0x00A4                            | 
  38E100A4
       +0012C 3D57C424   bl         Tk_TopCoordsToWindow       ; 0x3D57FA70 | 
  4800364D
       +00130 3D57C428   lwz        r3,0x0002(r28)                          | 
  807C0002
       +00134 3D57C42C   li         r4,0x0000                               | 
  38800000
       +00138 3D57C430   lbz        r0,0x007C(SP)                           | 
  8801007C
       +0013C 3D57C434   insrwi     r0,r29,0x08,0x10                        | 
  53A0442E
       +00140 3D57C438   rlwimi     r0,r3,0x08,0x08,0x0F                    | 
  5060421E
       +00144 3D57C43C   stw        r0,0x00B4(SP)                           | 
  900100B4
       +00148 3D57C440   lwz        r3,0x0000(r30)                          | 
  807E0000
       +0014C 3D57C444  *lwz        r0,0x005C(r3)                           | 
  8003005C
       +00150 3D57C448   stw        r0,0x0084(SP)                           | 
  90010084
       +00154 3D57C44C   lwz        r0,0x0014(r30)                          | 
  801E0014
       +00158 3D57C450   stw        r0,0x0090(SP)                           | 
  90010090
       +0015C 3D57C454   lwz        r0,0x0000(r30)                          | 
  801E0000
       +00160 3D57C458   stw        r0,0x008C(SP)                           | 
  9001008C
       +00164 3D57C45C   lwz        r3,0x0000(r30)                          | 
  807E0000
       +00168 3D57C460   bl         XRootWindow                ; 0x3D583C8C | 
  4800782D
       +0016C 3D57C464   stw        r3,0x0094(SP)                           | 
  90610094
       +00170 3D57C468   bl         Button                     ; 0x3D608790 | 
  4808C329
   Heap zones
    #1  Mod       17148K  00002800 to 010C184F  SysZone^
    #2  Mod           6K    0001C020 to 0001DBBF  ROM read-only zone
    #3  Mod          64K    00B52D10 to 00B62D0F
    #4  Mod         256K    00B62D20 to 00BA2D1F
    #5  Mod          64K    00BAFE30 to 00BBFE2F
    #6  Mod      791916K  010C1850 to 3161CA9F  Process Manager zone
    #7  Mod       20006K    2D93D440 to 2ECC6D1F  MT-NewsWatcher 2.4.0
    #8  Mod        3157K    2ECDFC50 to 2EFF534F  Wish  ApplZone^  TheZone^  
  TargetZone
    #9  Mod        4057K    2F2D7510 to 2F6CDC0F  Internet Explorer 4.5
    #10 Mod        1026K      2F397C90 to 2F49848F
    #11 Mod         398K    2F80AD20 to 2F86E6AF  AppleCD Audio Player
    #12 Mod        2493K    2F878D30 to 2FAE842F  AOL Instant Messenger
    #13 Mod       14833K    2FB04540 to 30980C3F  CodeWarrior IDE 4.0.4
    #14 Mod        6025K    309C4D50 to 30FA744F  Eudora Pro 3.0.1
    #15 Mod         410K    31246D70 to 312AD71F  Stickies
    #16 Mod          18K    312C8DA0 to 312CD65F
    #17 Mod         942K    312E3360 to 313CEE5F  Finder
    #18 Mod          83K    313E36F0 to 313F85EF  Time Synchronizer
    #19 Mod         753K    3142FE10 to 314EC50F  PGPnetService
    #20 Mod         361K    31500DA0 to 3155B49F  Folder Actions
    #21 Mod          89K    315AC050 to 315C274F  Control Strip Extension
    #22 Mod         112K    315D4FE0 to 315F12DF  Application Switcher
    #23 Mod        4095K  32000000 to 323FFFBF
    #24 Mod         288K    32061370 to 320A936F
    #25 Mod          27K    3210D450 to 3211417F
  Checking all heaps
   The System heap at 00002800 is ok
   The ROM read-only heap at 0001C020 is ok
   The heap at 00B52D10 is ok
   The heap at 00B62D20 is ok
   The heap at 00BAFE30 is ok
   The Process Manager heap at 010C1850 is ok
   The MT-NewsWatcher 2.4.0 heap at 2D93D440 is ok
   The Wish heap at 2ECDFC50 is ok
   The Internet Explorer 4.5 heap at 2F2D7510 is ok
   The heap at 2F397C90 is ok
   The AppleCD Audio Player heap at 2F80AD20 is ok
   The AOL Instant Messenger heap at 2F878D30 is ok
   The CodeWarrior IDE 4.0.4 heap at 2FB04540 is ok
   The Eudora Pro 3.0.1 heap at 309C4D50 is ok
   The Stickies heap at 31246D70 is ok
   The heap at 312C8DA0 is ok
   The Finder heap at 312E3360 is ok
   The Time Synchronizer heap at 313E36F0 is ok
   The PGPnetService heap at 3142FE10 is ok
   The Folder Actions heap at 31500DA0 is ok
   The Control Strip Extension heap at 315AC050 is ok
   The Application Switcher heap at 315D4FE0 is ok
   Totaling the Wish heap at 2ECDFC50
                                   Total Blocks    Total of Block Sizes
    Free                           0023      #35   00140DF0     #1314288
    Nonrelocatable                 0073     #115   000402BC      #262844
    Relocatable                    0137     #311   00194610     #1656336
      Locked                       0036      #54   00180AE0     #1575648
      Purgeable and not locked     0006       #6   0000DDF0       #56816
    Heap size                      01CD     #461   003156BC     #3233468
   The target heap is the System heap at 00002800
   Totaling the System heap at 00002800
                                   Total Blocks    Total of Block Sizes
    Free                           005E      #94   00206320     #2122528
    Nonrelocatable                 0A5A    #2650   0072AF4C     #7515980
    Relocatable                    0AFF    #2815   0078DDA0     #7921056
      Locked                       01FA     #506   005B4740     #5982016
      Purgeable and not locked     00B2     #178   00126A90     #1206928
    Heap size                      15B7    #5559   010BF00C    #17559564
   The target heap is the Wish heap at 2ECDFC50
   Displaying File Control Blocks
    fRef File                   Vol         Type Fl Fork     LEof
    0002 System                 Borg        zsys dW rsrc #6428544
    0060 **** EXTENTS B-TREE    Borg         dw data #4194304
    00BE **** CATALOG B-TREE    Borg         Dw data #25165824
    011C **** VOLUME BITMAP     Borg         dw data  #258048
    017A **** EXTENTS B-TREE    Net          dw data #4194304
    01D8 **** CATALOG B-TREE    Net          dw data #8388608
    0236 **** VOLUME BITMAP     Net          dw data  #262144
    0294 **** EXTENTS B-TREE    OldSchool    dw data #4194304
    02F2 **** CATALOG B-TREE    OldSchool    dw data #16777216
    0350 **** VOLUME BITMAP     OldSchool    dw data   #32768
    03AE **** EXTENTS B-TREE    Huge         dw data #4194304
    040C **** CATALOG B-TREE    Huge         dw data #25165824
    046A **** VOLUME BITMAP     Huge         dw data  #516096
    04C8 VM Storage             OldSchool   ZSYS DW data #843055104
    0526 System Resources       Borg        zsyr dw rsrc  #727502
    1144 System                 Borg        zsys dw data #4072175
    11A2 Platinum Sounds        Borg        tsnd dW rsrc #1094612
    1200 Open Tpt AppleTalk Li
   Borg        libr dw rsrc  #502792
    125E Open Transport Library Borg        libr dw rsrc  #524771
    12BC OpenTransportLib       Borg        otsl dw data  #501392
    131A Shared Library Manage
   Borg        INIT dw rsrc  #211694
    1378 Open Transport Library Borg        libr dw rsrc  #524771
    13D6 Open Tpt AppleTalk Li
   Borg        libr dw rsrc  #502792
    1434 Open Tpt Internet Lib
   Borg        libr dw rsrc  #461056
    1492 OpenTpt Remote Access  Borg        libr dw rsrc #1083183
    14F0 OpenTptAppleTalkLib    Borg        otsl dw data   #48738
    154E OpenTpt Modem          Borg        libr dw rsrc   #91506
    15AC OpenTpt Remote Access  Borg        libr dw rsrc #1083183
    160A Remote Access Log      Borg        lzlg dW data  #135168
    1668 Serial (Built-in)      Borg        libr dw rsrc   #63254
    16C6 Open Transport Library Borg        libr dw rsrc  #524771
    1724 OpenTpt Serial Arbitr
   Borg        libr dw rsrc    #7974
    1782 OpenTpt Serial Arbitr
   Borg        libr dw rsrc    #7974
    17E0 ATI Resource Manager   Borg        shlb dw data   #98582
    183E Users & Groups Data F
   Borg        BTFL dW data   #69632
    189C Apple Guide            Borg        INIT dw data  #417352
    18FA ColorSync Extension    Borg        appe dw data  #301152
    1958 Contextual Menu Exten
   Borg        INIT dw data   #66663
    19B6 SOMobjects for Mac OS Borg        shlb dw data  #129152
    1A14 QuickTime             Borg        INIT dw data  #454020
    1A72 Sound Manager          Borg        INIT dw data   #19522
    1AD0 Timbuktu Extension     Borg        appe dw data  #209020
    1B2E Speech Manager         Borg        INIT dw data    #4000
    1B8C ScreenShare Host Drop
   Borg        dTB2 dw data  #185604
    1BEA Application Switcher   Borg        appe dW rsrc    #6198
    1C48 Control Strip Extensi
   Borg        appe dW rsrc   #67084
    1CA6 Stickies               Borg        APPL dW rsrc  #103586
    1D04 Control Strip Extensi
   Borg        appe dw data    #3160
    1D62 Folder Actions         Borg        appe dW rsrc    #4877
    1DC0 PGPnetService          Borg        appe dW rsrc    #3311
    1E1E Desktop DB             Net         BTFL dW data  #135168
    1E7C Time Synchronizer      Borg        appe dW rsrc    #6319
    1EDA Finder                 Borg        FNDR dw rsrc  #638602
    1F38 QuickTime PowerPlug   Borg        INIT dw data  #224542
    1F96 Finder                 Borg        FNDR dw data #1870234
    1FF4 Color Picker           Borg        INIT dw data    #6400
    2052 File Sharing Library   Borg        shlb dw data   #91214
    20B0 File Sharing Library   Borg        shlb dw rsrc    #3190
    210E Finder Preferences     Borg        pref dW rsrc     #922
    216C PGPmenu                Borg        INIT dw data  #194746
    21CA Open Tpt Internet Lib
   Borg        libr dw rsrc  #461056
    2228 Desktop DB             Borg        BTFL dW data  #675840
    2286 Desktop DF             Borg        DTFL dW data #4289506
    22E4 OpenTptInternetLib     Borg        otsl dw data  #257182
    2342 OTModl$Proxy           Borg        shlb dw data   #33440
    23A0 Time Synchronizer      Borg        appe dw data   #37169
    23FE PrintingLib            Borg        shlb dw data #1103024
    245C Desktop DF             Net         DTFL dW data  #384946
    24BA Desktop DB             OldSchool   BTFL dW data  #626688
    2518 Desktop DF             OldSchool   DTFL dW data #4286130
    2576 Desktop DB             Huge        BTFL dW data  #516096
    25D4 Desktop DF             Huge        DTFL dW data #3788690
    2632 Find CM Items          Borg        cmpi dw data   #21987
    2690 Folder Actions Menus   Borg        cmpi dw data   #10205
    26EE PGPcontextmenu         Borg        cmpi dw data   #44476
    274C Folder Actions         Borg        appe dw data   #17331
    27AA AppleScriptLib         Borg        shlb dw data   #22636
    2808 Eudora Pro 3.0.1       Borg        APPL dW rsrc #1200404
    2866 AOL Instant Messenger Borg        APPL dW rsrc  #933230
    28C4 AOL Instant Messenger Borg        APPL dw data #2187451
    2922 AIM Prefs              Borg        Pref dW rsrc   #15434
    2980 Application Switcher   Borg        appe dw data   #80825
    29DE PGPnetService          Borg        appe dw data   #81941
    2A3C PGPsdkLib              Borg        shlb dw data  #967104
    2A9A PGPsdkNetworkLib       Borg        shlb dw data  #279397
    2AF8 Internet Config Exten
   Borg        thng dw data   #27708
    2B56 PGPclientLib           Borg        shlb dw data  #993683
    2BB4 PGPsdkUILib            Borg        shlb dw data  #427846
    2C12 PGPnetModule           Borg        shlb dw data  #163297
    2C70 AppleTalk Switch       Borg        sdev dw data    #5066
    2CCE File Sharing Strip     Borg        sdev dw data    #8634
    2D2C File Sharing Library   Borg        shlb dw rsrc    #3190
    2D8A Monitor BitDepth       Borg        sdev dw data    #4794
    2DE8 Monitor Resolution     Borg        sdev dw data    #9750
    2E46 Sound Volume           Borg        sdev dw data    #4154
    2EA4 Video Mirroring        Borg        sdev dw data    #4426
    2F02 Web Sharing CS         Borg        sdev dw data   #21334
    2F60 Eudora Pro 3.0.1       Borg        APPL dw data #1035305
    2FBE Eudora Pro Help        Borg        EuHl dw rsrc  #282138
    301C Help Data.IC           Borg        rsrc dw rsrc    #1318
    307A Eudora Settings        Borg        PREF dW rsrc    #6674
    30D8 CodeWarrior IDE 4.0.4  Borg        APPL dW rsrc  #875600
    3136                        rbarris      dw data       #0
    3194 CodeWarrior IDE 4.0.4  Borg        APPL dw data #5320501
    31F2 MWCore                 Borg        shlb dw data  #225903
    3250 MWMacOSCOM             Borg        shlb dw data   #26350
    32AE PluginLib4             Borg        shlb dw data   #95717
    330C FLEXlm                 Borg        shlb dw data  #248961
    336A Tailor notes           Borg        TEXT dW data    #2859
    33C8                        Audio CD 4   dw data       #0
    3426 AppleCD Audio Player   Borg        APPL dW rsrc  #141436
    3484 Text Encoding Convert
   Borg        shlb dw data  #155168
    34E2 IDEResources           Borg        rsrc dw rsrc   #13772
    3540 license.dat            Borg        TEXT dw data     #110
    359E CD Remote Programs     Borg        ProG dW rsrc   #76059
    35FC CPlusSourceGen         Borg        COM  dw data  #544231
    365A MWRADUtils             Borg        shlb dw data   #98118
    36B8 MWComHelpers           Borg        COM  dw data  #157931
    3716 CVSymbolics            Borg        MWDP dw data  #112032
    3774 Disassemble68K         Borg        MWDP dw data  #154980
    37D2 DisassemblePPC         Borg        MWDP dw data   #55491
    3830 Disassemblex86         Borg        MWDP dw data   #48236
    388E JavaSymbolics          Borg        MWDP dw data  #119158
    38EC MetroNub Plugin        Borg        MWDP dw data  #100569
    394A MetroNub Plugin        Borg        MWDP dw rsrc    #9619
    39A8 SymSymbolics           Borg        MWDP dw data   #80765
    3A06 x86 Plugin             Borg        MWDP dw data  #113278
    3A64 x86 Plugin             Borg        MWDP dw rsrc    #2518
    3AC2 Internet Explorer 4.5  Borg        APPL dW rsrc  #722115
    3B20 Internet Explorer 4.5  Borg        APPL dw data #2492933
    3B7E Chinese Encodings      Borg        ecpg dw data   #14872
    3BDC Japanese Encodings     Borg        ecpg dw data   #14952
    3C3A Korean Encodings       Borg        ecpg dw data   #10488
    3C98 Unicode Encodings      Borg        ecpg dw data   #16872
    3CF6 MS C++ Library (PPC)   Borg        shlb dw data  #112628
    3D54 Microsoft Internet Li
   Borg        shlb dw data #1879233
    3DB2 Network Setup Extensi
   Borg        shlb dw data  #408503
    3E10 Network Setup Extensi
   Borg        shlb dw rsrc   #26989
    3E6E Network Setup Extensi
   Borg        shlb dw rsrc   #26989
    3ECC Microsoft Component L
   Borg        shlb dw data   #55552
    3F2A Microsoft Internet Li
   Borg        shlb dw rsrc  #281258
    3F88 cache.lck              Borg        LOCK dW data      #16
    3FE6 cache.waf              Borg        WAFF dW data #5275497
    4044 Microsoft Internet Li
   Borg        shlb dw rsrc  #281258
    40A2 MS Parser Library (PP
   Borg        shlb dw data   #50751
    4100 MS Font Embed Library
   Borg        shlb dw data  #227825
    415E Download Cache         Borg        LOCK dW data       #0
    41BC Download Cache         Borg        WAFF dW data #1633238
    421A Wish                   Borg        APPL dW rsrc    #4700
    4278 Wish                   Borg        APPL dw data   #35942
    42D6 Tcl8.3.shlb            Borg        shlb dw data  #806487
    4334 MRJLib                 Borg        shlb dw data #2327473
    4392 Tk8.3.shlb             Borg        shlb dw data  #865437
    43F0 Tcl8.3.shlb            Borg        shlb dw rsrc   #71323
    444E Tk8.3.shlb             Borg        shlb dw rsrc  #216746
    44AC MT-NewsWatcher 2.4.0   Borg        APPL dW rsrc #1152042
    450A MT-NewsWatcher 2.4.0   Borg        APPL dw data  #847866
    4568 StdLog                 Borg        TEXT dW data   #17093
    #242 FCBs, #190 in use (including #32 fonts not listed), #52 free
   Displaying Driver Control Entries
    No drivers are busy.
   Displaying resource information:
    >   Map $2ECDFDA8, flags $8000, file $444E = Tk8.3.shlb
        Map $2ECDFDB8, flags $8000, file $43F0 = Tcl8.3.shlb
        Map $2ECDFDD8, flags $0000, file $421A = Wish
     +  Map $00003274, flags $801A, file $0003 = ROM resources that override 
  System
      S Map $0000336C, flags $200D, file $0002 = System
        Map $000031D4, flags $0014, file $0526 = System Resources
        [Skipped $0020 maps belonging to font files]
   Calling chain using A6/R1 links
    Back chain  ISA  Caller
    00000000    PPC  3F407240  
    2F0F9180    PPC  3F4070A0  
    2F0F9140    PPC  3D5D3B9C  Tk_MainEx+0035C
    2F0F8FF0    PPC  3D5B17E4  Tk_MainLoop+00014
    2F0F8FB0    PPC  3D67B194  Tcl_DoOneEvent+00118
    2F0F8F60    PPC  3D641D20  Tcl_WaitForEvent+00130
    2F0F8EF0    PPC  3D57B9F8  TkMacConvertEvent+0014C
   Return addresses on the stack
    Stack Addr  Frame Addr   ISA   Caller
     2F0F9188                PPC   3F407240
     2F0F9164                PPC   00488530 NewRoutineDescriptor+000A0
     2F0F9148    2F0F9140    PPC   3F4070A0
     2F0F9124                68K   003FD2FA 'scod BFAF 0002'+05A0A
     2F0F90F8    2F0F90F0    PPC   3F406F04
     2F0F90D8    2F0F90D0    PPC   3D649754 Tcl_CreateInterp+00378
     2F0F90D4    2F0F90D0    68K   003FD2CC 'scod BFAF 0002'+059DC
     2F0F9098    2F0F9090    PPC   3D66B488 TclInterpInit+00088
     2F0F9088    2F0F9080    PPC   3D6B4FD8 Tcl_InitStubs+0008C
     2F0F9048    2F0F9040    PPC   3D64B5F4 Tcl_Alloc+00018
     2F0F903C                68K   2EFE84D2
     2F0F9008    2F0F9000    PPC   3D68B6D4 Tcl_SetVar2Ex+00048
     2F0F8FF8    2F0F8FF0    PPC   3D5D3B9C Tk_MainEx+0035C
     2F0F8FC8                PPC   3D68C9D4 TclLookupVar+00378
     2F0F8FB8    2F0F8FB0    PPC   3D5B17E4 Tk_MainLoop+00014
     2F0F8F78                68K   3D5FD2DA Tk_GetNumMainWindows+00016
     2F0F8F68    2F0F8F60    PPC   3D67B194 Tcl_DoOneEvent+00118
     2F0F8F3A                68K   00155C68 newSyncCache+0008C
     2F0F8F18    2F0F8F10    PPC   3D63CCAC Tcl_PidObjCmd+00438
     2F0F8EF8    2F0F8EF0    PPC   3D641D20 Tcl_WaitForEvent+00130
     2F0F8EB8                68K   FFD4334A WaitNextEvent+0002A
     2F0F8EA8    2F0F8EA0    PPC   3D57B9F8 TkMacConvertEvent+0014C
     2F0F8E88                PPC   3D641F9C Tcl_SetTimer+00228
     2F0F8E78    2F0F8E70    PPC   3FA35C84 NQDRectRgn+0005C
     2F0F8E68    2F0F8E60    PPC   3FC2BB10 FrontNonFloatingWindow+00034
     2F0F8DC8    2F0F8DC0    PPC   3FC2BBA0 FrontNonFloatingWindow+000C4
     2F0F8DA8    2F0F8DA0    PPC   3D57C424 GenerateKeyEvent+0012C
   Displaying memory from 0
    00000000  FFC1 0000 FFC1 0000  003F 7946 003F 7948  <caron>¡<caron>¡?yF?yH
    00000010  003F 794A 003F 794C  0089 6BC8 0089 6BC8  ?yJ



  This has been fixed for 8.3.1. 
  -- 04/24/2000 hobbs


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

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

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

  # During a file transfer

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

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

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

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

  Windows ME for what it's worth.


tkt_uuid: 3460976fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Fix for menus stopping working
comment:
  This is a patch to fix priority 9 bug #3235256.

  For long-running applications which over time create &
  destroy many windows with menubars, eventually the menus
  stop working, leaving the application in an unusable state.

  The problem was that menu item ids were being created
  which conflicted with the predefined identifiers used by the
  window system menu & the WM_SYSCOMMAND message.  The
  MSDN pages on WM_SYSCOMMAND & GetSystemMenu() have
  some info.

  The patch is for the released 8.5.11 version of tkWinMenu.c


tkt_uuid: 861330ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: wish.exe cannot be loaded under WinXP
comment:
  It seems that Windows XP is particularly picky about
  the format of the version value in the manifest
  resource. It MUST be 4 numbers separated by dots (and
  maybe commas?). "8.5.a0" and "8.5.0" both result in an
  executable that Windows refuses to load. tktest is ok
  because it is not called wish.

  Bizzare.


tkt_uuid: 1591485fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: font test suite failures 21.8, 28.6
comment:
  Tk cvs head build on sparc solaris 2.9, using sun c
  compiler , test suite run displaying back through
  windows xp exceed 10.0.0.12 .

  The following font test suite failed. I'm uncertain
  whether this is a unix specific font failure or a
  generic failure.

  font.test

  ==== font-21.8 Tk_PostscriptFontName procedure: spaces
  FAILED
  ==== Contents of test case:

      set x [font actual {{lucida bright} 10} -family]
      if {[string match lucida*bright $x]} {
          psfontname "{lucida bright} 10"
      } else {
          set x {LucidaBright}
      }

  ---- Result was:
  Lucidabright
  ---- Result should have been (exact matching):
  LucidaBright
  ==== font-21.8 FAILED

  ==== font-38.5 ParseFontNameObj procedure: begins with
  * FAILED
  ==== Contents of test case:

      lindex [font actual
  *-times-xyz-*-*-*-*-*-*-*-*-*-*-*] 1

  ---- Result was:
  fixed
  ---- Result should have been (exact matching):
  times
  ==== font-38.5 FAILED

  ==== font-38.6 ParseFontNameObj procedure: begins with
  * FAILED
  ==== Contents of test case:

      font actual *-times-xyz -family
  ---- Result was:
  fixed
  ---- Result should have been (exact matching):
  times
  ==== font-38.6 FAILED

  ==== font-40.2 TkFontParseXLFD procedure: no initial
  dash FAILED
  ==== Contents of test case:

      font actual *-times-*-*-*-*-*-*-*-*-*-*-*-xyz -family

  ---- Result was:
  fixed
  ---- Result should have been (exact matching):
  times
  ==== font-40.2 FAILED

  ==== font-40.3 TkFontParseXLFD procedure: not enough
  fields FAILED
  ==== Contents of test case:

      font actual -xyz-times-*-*-* -family

  ---- Result was:
  fixed
  ---- Result should have been (exact matching):
  times
  ==== font-40.3 FAILED

  ==== font-40.5 TkFontParseXLFD procedure: all fields
  specified FAILED
  ==== Contents of test case:


      lindex [font actual
  -foundry-times-weight-slant-setwidth-addstyle-10-10-10-1
  0-spacing-avgwidth-registry-encoding] 1

  ---- Result was:
  fixed
  ---- Result should have been (exact matching):
  times
  ==== font-40.5 FAILED


tkt_uuid: 219943ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.0.5
resolution: Duplicate
title: prowish80 -h generates Dr. Watson Error
comment:
  OriginalBugID: 1472 Bug
  Version: 8.0.5
  SubmitDate: '1999-03-08'
  LastModified: '1999-10-19'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 3052
  OS: Windows NT
  OSVersion: NT4.0SP4
  Machine: X86
  ClosedDate: '1999-10-19'


  Name:
  Steve Hurrell

  Extensions:
  Just protcl 1.2 invoked from a DOS box.

  CustomShell:
  Nothing

  ReproducibleScript:
      Type "prowish80 -h" then click on the OK button. Dr. Watson fires up a
      reports as below. This is on a NT4.0sp4 box that has never seen any tcl
      product before.
      Thanks. Steve
      
      



  ObservedBehavior:
      Exception: hardcoded breakpoint(0x80000003), Address:0x004014eb
      




  03/08/1999 11:42 - pat -the problem also occurs when you use -help


tkt_uuid: 220073ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Duplicate
title: Extending the current selection of a Text widget produces unexpected results
comment:
  OriginalBugID: 4375 RFE
  Version: 8.0p2
  SubmitDate: '2000-03-15'
  LastModified: '2000-04-16'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4253
  OS: Solaris
  OSVersion: Solaris 2.6
  Machine: SunOS 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-Enterprise
  ClosedDate: '2000-04-16'


  Name:
  Mark A. Wege

  ReproducibleScript:
  Execute the following code in an interactive session of wish, double-click in the middle of the word "selection", and then attempt
  to extend the selection by holding down the Shift key and pressing the Left arrow key.

  text .t
  pack .t
  .t insert end "Testing the selection of text"

  ObservedBehavior:
  When you double-click on the word "selection", the entire word is selected and the insert cursor moves to the beginning of the
  word.  When you extend the selection, however, all selected text in the word to the right of the initial insert point (where you
  double-clicked) is de-selected.

  A similar behavior occurs if you use the Right arrow key.

  DesiredBehavior:
  The text to the right of initial insert point should stay selected (as it does when you perform the same actions using an Entry
  widget).



  This has always been the behavior of the text widget selection
  routines.  I've changed this to an RFE, because the text widget
  should probably do more "intuitive" selection handling. 
  -- 03/23/2000 hobbs


tkt_uuid: 780490ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Multi-Line buttons under Mac OSX
comment:
  Multiple line buttons fail on my MacOSX port. The 
  buttons appear to get larger to accomadate the extra 
  lines, but only the first line text will appear.

  The documentation for the button command doesn't 
  suggest any restrictions that I can find.

  Ex.
      pack [button .a -text "Two\nLines"]

  Creates a larger than normal button, but only the
  word "Two" appears (centered).


tkt_uuid: 220624ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: Applescript and special characters
comment:
  OriginalBugID: 3644 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-23'
  LastModified: '1999-12-20'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: MacOS 8.6
  Machine: Performa 5300
  FixedDate: '1999-12-20'
  FixedInVersion: 8.3b1


  Name:
  Henk-Jan Kooiman

  Comments:
  The tclMacOSA fix is for the communication from Tcl/Tk to Applescript,
  the tkMacHLEvents-fix is for the communication from Applescript to Tcl/Tk.

  In fact: all text-communication between the OS and Tcl should be converted.

  ReproducibleScript:
  tell application "Wish"
  do script "cd één"
  end tell

  ObservedBehavior:
  Doesn't change to directory één

  DesiredBehavior:
  Do change to directory één

  Patch:
  tkMacHLEvents.c

  procedure ScriptHandler

  declare:
   Tcl_DString encodedText;

  Change:
  tclErr = Tcl_GlobalEval(interp, *theDesc.dataHandle);

  To:
  Tcl_ExternalToUtfDString(NULL, *theDesc.dataHandle, length, &encodedText);
  tclErr = Tcl_GlobalEval(interp, Tcl_DStringValue(&encodedText));
  Tcl_DStringFree(&encodedText);

  tclMacOSA.c

  Declare:
  Tcl_DString encodedText;

  Change:
  sysErr = AECreateDesc(typeChar, Tcl_DStringValue(scrptData), Tcl_DStringLength(scrptData), scrptDesc);

  To:
  Tcl_UtfToExternalDString(NULL, Tcl_DStringValue(scrptData), Tcl_DStringLength(scrptData), &encodedText);
  sysErr = AECreateDesc(typeChar, Tcl_DStringValue(&encodedText), Tcl_DStringLength(&encodedText), scrptDesc);
  Tcl_DStringFree(&encodedText);

  PatchFiles:
  tkMacHLEvents.c, tclMacOSA.c



  fixed in 8.3b1. 
  -- 12/20/1999 hobbs


tkt_uuid: 220562ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.2b1
resolution: Fixed
title: Bug in MacTk header file
comment:
  OriginalBugID: 2389 Bug
  Version: 8.2b1
  SubmitDate: '1999-07-19'
  LastModified: '1999-08-01'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  Machine: Power PC
  FixedDate: '1999-08-01'
  FixedInVersion: 8.2b2


  Name:
  vince darley

  ReproducibleScript:
  When compiling extensions which use stubs, if you first include "tk.h",
      and then later decide to include tkInt.h/tkPort.h/tkMacPort.h (because
      the extension requires some internals), the stub-#defines cause the
      following
      line (in tkMacPort.h) to turn into garbage (=> compiler errors):
      
      extern void panic  _ANSI_ARGS_(TCL_VARARGS(char *, string));
      
      I suggest it be either removed or wrapped in the following #ifdef
      
      #ifndef panic
      extern void panic  _ANSI_ARGS_(TCL_VARARGS(char *, string));
      #endif
      
      to avoid this problem.



  Unable to test properly, since it is in the mac headers. 
  -- 08/01/1999 hobbs


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: 3517228fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: None
title: Endless loop inside Tk library
comment:
  I have the following case:
  1. Mapping a modal window (with local grab)
  2. Mapping a subwindow of the modal window
  3. Mouse click into the subwindow
  The result is a frozen screen. With debugging I discovered that an endless call of function TkPointerEvent() is freezing the screen. I made a patch to this function (see attached file; possibly a better patch is required) and my application is working. Unfortunately I couldn't build a simple test application with the same behavior.


tkt_uuid: 1620826fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: Fixed
title: The event <<MenuSelect>> is never fired on Mac OSX
comment:
  Hi guys,

  We've the next problem using tk_popup.

  Menu:  The event <<MenuSelect>> is never fired on Mac OSX

  Here is the description:

  Do:
      Run the script. Press the button, and move the mouse over the cascade element.


  set ::menu1 [menu .menu1 -tearoff 0]
  set ::menu2 [menu .menu2 -tearoff 0]

  proc fill_menu2 {menu} {
      if {[$menu type active] == "cascade"} {
          $::menu2 add command -label "I am fill!!!" -state disabled
      }
  }

  proc show_popup {} {
      $::menu1 add command -label "This is menu 1, select the cascade" -state disabled
      $::menu1 add cascade -label "This is cascade, that will be filled when the mouse enters" -menu $::menu2
      bind $::menu1 <<MenuSelect>> "fill_menu2 %W"
      tk_popup $::menu1 [winfo rootx .b] [winfo rooty .b]
  }

  button .b -text "press me for popup" -command "show_popup"
  pack .b


  Happens:
      In Mac OSX, the cascade is never displayed. The reason, the <<MenuSelect>> is never fired.

  Expected:
     That the <<MenuSelect>> event is fired. In Windows, and Linux, is working properly.


  Another issue: In Windows, and Linux, we can have images inside the tk menu. In Mac, if an image is specified, it doesn't appear, and  a text like this:<<image>> is placed instead.


  Best Regards,
  Carlos Tasada


tkt_uuid: 2989842fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: Notebook: optional TabPosition
comment:
  It would be nice if I can determine the position of the tab in the tkk::notebook

  e.g:  -tabpos [e|s|w|n]

  I need this to have many tabs and to use the lage width of the screen.


tkt_uuid: 220123ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Invalid
title: Tk file dialogue boxes crash with permission errors
comment:
  OriginalBugID: 1161 Bug
  Version: 8.0.4
  SubmitDate: '1999-02-02'
  LastModified: '1999-11-12'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux
  OSVersion: 2.034
  Machine: Other
  ClosedDate: '1999-11-12'


  Name: Lindsay Marshall

  ReproducibleScript:
  The internals of the file dialog code use a proc called 
  tkFDialogResolveFile. Use a file dialog inside a directory where you do not have access permission.

  ObservedBehavior:
  The internals of the file dialog code use a proc called 
  tkFDialogResolveFile. This proc calls pwd. If the pwd call fails then a tcl error results rather than the dialogue box code handling it cleanly.

  error getting working directory name: permission denied
      while executing
  "pwd"
      (procedure "tkFDialogResolveFile" line 41)
      invoked from within
  "tkFDialogResolveFile $data(selectPath) $text  $data(-defaultextension)"
      (procedure "tkFDialog_ActivateEnt" line 5)
      invoked from within
  "tkFDialog_ActivateEnt .__tk_filedialog"
      (command bound to event)

  DesiredBehavior:
  Clean error handling by the dialogue box code.



  Doing some tests, this seems to be valid behavior.  The dialog
  will pop up a message when you try and enter a non-readable
  directory, and this error is received when the -initialdir
  specified is non-readable.  Since the programmer has to specify
  this explicitly, they should check for [file readable] first. 
  -- 11/12/1999 hobbs


tkt_uuid: 803060ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: None
resolution: Accepted
title: Enhance the man page
comment:
  Please add another section to the image man page:

     [start of text]
  Additional image commands
  --------------------------
  Additional opearations (e.g. configure, read, write)
  may be available for different image types. See the
  respective manual entries (bitmap, photo) for more
  information.
     [end of text]

  Rational: Could well be, this seems obvious to anybody
  familiar with the (internal) structure of Tk's handling
  of images:
  - top level: [image] command
  - inermediate: type handler (e.g. photo)
  - low-level: specific formats (e.g. gif) in the Img
  extension

  Not being familiar with it, I spent a lot of time
  searching at the top (image) and the bottom (Img::gif)
  for information on how to save an image to file. The
  proposed addition might help the next guy save some time.

  Best regards
  Helmut Giese


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: 3381288fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: winWm-9.2 bg error during test
comment:
  When testing an RC for Tk 8.6b2 on a Centos
  Linux system on x86_64, I get an "Application Error"
  popup window with the message:

  Error: bad window path name ".t.f.x"

  bad window path name ".t.f.x"
  bad window path name ".t.f.x"
      while executing
  "winfo rooty .t.f.x"
      ("after" script)

  Examining the test suite, this is
  apparently coming from test winWm-9.2.


tkt_uuid: 1030445fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Works For Me
title: Topmost window changes with wm attributes -alpha
comment:
  In tkchat I added a slider on a dialog to play with the
  -alpha transparency gimmick :)

  However, when we transition to or from opaque to
  transparent the main toplevel always becomes topmost.

  In the slider command handler I fixed it by adding a
  [raise $dlgname]


tkt_uuid: 982248ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Fixed
title: Hidden Canvas Window Objects
comment:
  Canvas Window objects can be created as hidden, but 
  once visible, their state can not be configured to be 
  hidden again. Here's a sample script (thanks to Slaven 
  Rezic for converting it from Perl to Tcl):

  pack [canvas .c]
  set w [.c create window 50 50 -window [ label .c.label 
  -text Hello ] 
  -state hidden]
  set l [.c create line 30 60 70 60 -state hidden]

  set i 0

  proc repeatproc {} {
      global i w l
      incr i
      if { $i%2 == 0 } {
  .c itemconfigure $w -state hidden
  .c itemconfigure $l -state hidden
      } else {
  .c itemconfigure $w -state normal
  .c itemconfigure $l -state normal
      }
      after 1000 repeatproc
  }

  after 1000 repeatproc


tkt_uuid: 546607ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: problem with cursor change
comment:
  I have a problem with cursor change using Tkogl (opengl extension) under Windows.
     Tkogl creates Tk_Window-window (A) and opengl-window (B) as a child of A.
     B is not Tk_Window. B just posts some messages to its parent (A) so I have no
     problem with bindings and with cursor change. But I can see the desired cursor (over B)
     only when I move the mouse or press the button. As soon as I stop moving or release the button 
  -   the cursor changes to IDC_ARROW.

      It happens because of "mouseTimer" that is created in Tk_PointerEvent(hwnd, x, y) 
  (tkWinPointer.c line 149).
      MouseTimerProc calls Tk_PointerEvent(NULL, pos.x, pos.y) (tkWinPointer.c line 239).

      Note that hwnd is NULL, so Tk_PointerEvent "must" find hwnd.

       hwnd = WindowFromPoint(pos); (tkWinPointer.c line 139).

      WindowFromPoint returns hwnd of B (rightly) which is not Tk_Window.
      When
   
       tkwin = Tk_HWNDToWindow(hwnd); (tkWinPointer.c line 141)

      so tkwin is NULL now.

      After this
       Tk_UpdatePointer(tkwin, pos.x, pos.y, state); (tkWinPointer.c line 145)
      with tkwin==NULL will change cursor to "None".
      
      I see two simple ways to avoid this problem - 
       1. Not to change cursor to "None" in UpdateCursor(winPtr) (TkPointer.c line 546) when 
  winPtr==NULL.
       2. Replace 
        tkwin = Tk_HWNDToWindow(hwnd); (tkWinPointer.c line 141)
       with
        tkwin = NULL;
        while (tkwin==NULL && hwnd!=NULL) {
         tkwin = Tk_HWNDToWindow(hwnd);
         hwnd = GetParent(hwnd);
        }


tkt_uuid: 220422ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: clicking a menubutton that doesn't have an associated menu generates an error
comment:
  OriginalBugID: 1116 Bug
  Version: 8.1b1
  SubmitDate: '1999-01-26'
  LastModified: '1999-03-26'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: surles
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '1999-03-26'


  Name:

  Bryan Oakley


  ReproducibleScript:

  menubutton .mb -text "Press Me"

  pack .mb


  # press the button, and you'll get the error 'invalid command name ""'


  ObservedBehavior:

  Pressing the button gives the error 'invalid command name ""'


  This is caused by code in menu.tcl, procedure tkMbButtonUp, which attempts to get the menu type without first checking that a menu actually exists. Shame, shame, shame. :-)


  DesiredBehavior:

  Nothing should happen.


  Patch:

  *** menu.tcl.oldFri Jan 22 12:56:05 1999

  --- menu.tclFri Jan 22 12:58:32 1999

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

  *** 490,497 ****

        global tkPriv

        global tcl_platform


        set tearoff [expr {($tcl_platform(platform) == "unix") \

  !      || ([[$w cget -menu] cget -type] == "tearoff")}]

        if {($tearoff != 0) && ($tkPriv(postedMb) == $w) 

        && ($tkPriv(inMenubutton) == $w)} {

    tkMenuFirstEntry [$tkPriv(postedMb) cget -menu]

  --- 490,498 ----

        global tkPriv

        global tcl_platform


  +     set menu [$w cget -menu]

        set tearoff [expr {($tcl_platform(platform) == "unix") \

  !     || ($menu != "" && [$menu cget -type] == "tearoff")}]

        if {($tearoff != 0) && ($tkPriv(postedMb) == $w) 

        && ($tkPriv(inMenubutton) == $w)} {

    tkMenuFirstEntry [$tkPriv(postedMb) cget -menu]


  PatchFiles:

  lib/tk8.1/menu.tcl




  Applied the supplied patch.  Fixed.  03/26/1999 11:43 - surles -


tkt_uuid: 220627ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: tk input widgets are crashing .
comment:
  OriginalBugID: 3685 Bug
  Version: 8.1.1
  SubmitDate: '1999-11-24'
  LastModified: '1999-11-29'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  FixedDate: '1999-11-29'
  FixedInVersion: 8.2


  Name:

  seema



  ReproducibleScript:

  =========script=================

  proc fact {x} {        

  set result 1           

  if {$x <=0} {           

  return $result

  }

  while {$x > 1} {             

  set result  [ expr $result * $x]    

  set x [expr $x-1]

  }

  return $result                               

  }

  entry .e -width 8 -relief sunken -textvariable entry

  #ssdfs

  label .l1 -text " The factorial is "   

  #fsddg

  label .result -textvariable result

  # dg

  pack .e  .l1 .result  -side left -padx 1m -pady 2m    

  #dfdfg

  bind .e <Return> {set result [fact $entry]}     

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

  as soon as user types input value the application crashes . 

  the crash lands in tcl81.dll



  ObservedBehavior:

  - do-



  DesiredBehavior:

  # This script will calculate the factorial of no not greater then 19

  # After running the script a window will popup and ask form the user to

  # give some input with  and press Enter key the  factorial crossponding  to

  # the entered value is displayed........

  the user should type in the number and get back the factorial of the number.



  Patch:

  TCL.H

  =====

  typedef struct Tcl_Parse {

      char *commentStart;/* Pointer to # that begins the first of

   * one or more comments preceding the

   * command. */

      int commentSize;/* Number of bytes in comments (up through

   * newline character that terminates the

   * last comment).  If there were no

   * comments, this field is 0. */

      char *commandStart;/* First character in first word of command. */

      int commandSize;/* Number of bytes in command, including

   * first character of first word, up

   * through the terminating newline,

   * close bracket, or semicolon. */

      int numWords;/* Total number of words in command.  May

   * be 0. */

      Tcl_Token *tokenPtr;/* Pointer to first token representing

   * the words of the command.  Initially

   * points to staticTokens, but may change

   * to point to malloc-ed space if command

   * exceeds space in staticTokens. */

      int numTokens;/* Total number of tokens in command. */

      int tokensAvailable;/* Total number of tokens available at

   * *tokenPtr. */

      int errorType;/* One of the parsing error types defined

   * above. */



      /*

       * The fields below are intended only for the private use of the

       * parser.They should not be used by procedures that invoke

       * Tcl_ParseCommand.

       */



      char *string;/* The original command string passed to

   * Tcl_ParseCommand. */

      char *end;/* Points to the character just after the

   * last one in the command string. */

      Tcl_Interp *interp;/* Interpreter to use for error reporting,

   * or NULL. */

      char *term;/* Points to character in string that

   * terminated most recent token.  Filled in

   * by ParseTokens.  If an error occurs,

   * points to beginning of region where the

   * error occurred (e.g. the open brace if

   * the close brace is missing). */

      int incomplete;/* This field is set to 1 by Tcl_ParseCommand

   * if the command appears to be incomplete.

   * This information is used by

   * Tcl_CommandComplete. */

      Tcl_Token staticTokens[NUM_STATIC_TOKENS];

  /* Initial space for tokens for command.

   * This space should be large enough to

   * accommodate most commands; dynamic

   * space is allocated for very large

   * commands that don't fit here. */



  //yes_debugger

  int errorLine; //smishi



  } Tcl_Parse;



  TCLINT.h

  ========

  typedef struct Proc {

      struct Interp *iPtr;  /* Interpreter for which this command

     * is defined. */

      int refCount;  /* Reference count: 1 if still present

     * in command table plus 1 for each call

     * to the procedure that is currently

     * active. This structure can be freed

     * when refCount becomes zero. */



  /* Addition Start */

  int linenumber;

  char filename[256];

  int numLevel;

  /* Additon End */



  PatchFiles:

  tcl.h

      tclint.h

      tclproc.c

      tclcompile.c

      tclparse.c

      tclexecute.c

      tclbasic.c





  This works as expected on NT and 98 with 8.2.2. 
  -- 11/29/1999 hobbs


tkt_uuid: 3476090fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 73. Argv Parsing
priority: 5 Medium
foundin: None
resolution: None
title: -help does not work in tk 8.5.11 on MacOs
comment:
  When one uses the "-help" option win tk 8.5.11 on MacOs, the program crashes with a Segmentation Fault  11 

  On Linux with Tcl 8.4 it works fine.

  An example is included:

  On Mac, tk 8.5.11:

  $.> ./a.out -help
  Segmentation fault: 11


  On Linux, tk 8.4:

  $.> ./a.out -help
  Command-specific options:
   -myoption1: Explain myoption1
   -myint2:    Explain myint2
  Generic options for all commands:
   -help:      Print summary of command-line options and abort


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: 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: 219961ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: Caps Lock light failure
comment:
  OriginalBugID: 1656 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-29'
  LastModified: '1999-08-07'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2493
  OS: Windows 95
  OSVersion: OSR2
  Machine: X86
  ClosedDate: '1999-08-07'


  Name:
  Robert Embleton

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
      No script necessary.  Just start Wish80 on Win95 or Win98 and press the
      Caps Lock button.  See, no indication on the keyboard that caps lock is
      enabled.
      



  ObservedBehavior:
      Win 95/98 platform.  If the Caps Lock key is pressed to enable caps lock
      mode, the indicator light on the keyboard flashes on then turns off.
      The caps lock mode is enabled, but the light is off.  Pressing the Caps
      Lock again toggles the caps lock mode off.  The indicator light remains
      off.  FYI:  This does not occur on a NT platform
      



  DesiredBehavior:
      One would expect the indicator light to remain lit while thecaps lock
      mode is enabled.
      


tkt_uuid: 220126ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: grab misbehaves on W98
comment:
  OriginalBugID: 1268 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-23'
  LastModified: '2000-04-03'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  RelatedBugIDs: 1158 1510
  OS: Windows 98
  Machine: X86
  ClosedDate: '2000-04-03'


  Name:
  Christopher Nelson

  ReproducibleScript:
  button .b1 -text button1
  button .b2 -text button2
  pack .b1 .b2
  grab set -global .b1





  ObservedBehavior:
  Clicking on b2 causes b1 to be changed to sunken relief and never come
  back.




  DesiredBehavior:
  b1 should invoke normally or ignore the button click outside it's
  borders.






  Fails on all versions of Windows.  03/25/1999 15:37 - surles -
  Related bug IDs 1158 1510

  --

  This seems to have been fixed by 8.3.0.  I cannot reproduce it.

  - eric
   
  -- 04/03/2000 ericm


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: 220573ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Caps Lock light goes off on some Win95-98
comment:
  OriginalBugID: 2493 Bug
  Version: 8.0.3
  SubmitDate: '1999-08-03'
  LastModified: '2000-02-09'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 683 1656
  OS: Windows 95
  OSVersion: 95 - 98 and NT
  Machine: X86
  FixedDate: '2000-02-09'
  FixedInVersion: 8.3


  Name:
  Dany Ayotte

  Comments:
  Do you have any simple work around for that?

  ReproducibleScript:
  wish

  ObservedBehavior:
  Create annoyance for customer, especially when typing password, user
  don't have indication whatever Caps Lock is active or not.

  DesiredBehavior:
  Normal Caps Lock light behaviour.



  Reported to only affect Win95/98, not NT. 
  -- 08/07/1999 hobbs
  This was fixed for 8.3.0 (patch from Spjuth). 
  -- 02/09/2000 hobbs


tkt_uuid: 1909931fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Fixed
title: send and xauth problem on Fedora 8
comment:
  [send] doesn't work on Fedora 8 with stock setup due to the auth setup checks [send] does.

  There was a bug filed against Fedora regarding this issue: https://bugzilla.redhat.com/show_bug.cgi?id=349071 which was closed with the resolution "not a bug" and the explanation attached from which it's clear that Fedora is not about changing its policy regarding X auth setup. This implies [send] will continue not to work properly on future versions of Fedora (and who knows -- may be RHEL also).

  I'm not an expert in X auth so it would be cool if someone with enough expertise in this field analyzed the situation -- may be [send] worth fixing to lax its rules regarding checking of X auth settings or so.


tkt_uuid: 1603501fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Fixed
title: AA fonts not rendering even though --enable-xft is default
comment:
  AA fonts not rendering even though xft support is default in 8.5a6. Supplying --enable-xft on the ./configure line enables a build that renders AA fonts properly. I note that the compile output for the failed build only has -DHAVE_LIBXFT=1 but not -DHAVE_XFT=1 as well.

  -Steve


tkt_uuid: 220266ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: final: 8.2.3
resolution: Invalid
title: make install fails to install wish in any system directory
comment:
  OriginalBugID: 3946 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-27'
  LastModified: '2000-01-03'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  Machine: ibm clone pentium 75 cpu
  ClosedDate: '2000-01-03'


  Name:
  kevin

  ReproducibleScript:
  ./configure ; make ; make install

  DesiredBehavior:
  i expect to find wish installed in a system directory after i rm-fr the compiling directory



  Was there no error message given?  In the default case, wish will
  be installed into /usr/local/bin - WITH THE VERSION NUMBER, so you
  can have multiple versions of wish at the same time.  Look for
  /usr/local/bin/wish8.2 and /usr/local/lib/{tcl8.2,tk8.2} 
  -- 01/03/2000 hobbs


tkt_uuid: 1538205fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Duplicate
title: double click "leak"
comment:
  On all Windows XP installations, double clicking on a
  file (to select it) with the "open file dialog" will
  result in the second mouse click "leaking" onto the
  widget behind it.


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: 694532ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Tk test suite failuers...
comment:
  =================================
  =================================
  =============
  *** Compiler has 'Optimizations'
  *** Compiler has 'Pentium 0x0f fix'
  *** Linker has 'Win98 alignment problem'
  *** Doing threads
  *** Doing symbols
  *** Doing profile
  *** Doing thrdalloc
  *** Doing memdbg
  *** Doing compdbg
  *** Intermediate directory will 
  be '.\Debug\tk_ThreadedDynamic'
  *** Output directory will be '.\Debug'
  *** Suffix for binaries will be 'td'
  *** Optional defines are '-DTCL_MEM_DEBUG -
  DTCL_COMPILE_DEBUG -DTCL_COMPILE_STAT
  S -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1'
  *** Dependency rules are not being used.

          set TCL_LIBRARY=..\..\tcl\library
          set PATH=..\..\tcl\win\Debug
          ".\Debug\tktest.exe" ..\tests\all.tcl  
  | ".\Debug\cat32.exe"
  Tests running in interp:  
  F:/tcl/pure/8.4.2/tk/win/Debug/tktest.exe
  Tests located in:  F:/tcl/pure/8.4.2/tk/tests
  Tests running in:  F:/tcl/pure/8.4.2/tk/win
  Temporary files stored in F:/tcl/pure/8.4.2/tk/win
  Test files sourced into current interpreter
  Running tests that match:  *
  Skipping test files that match:  l.*.test
  Only running test files that match:  *.test
  Tests began at Thu Feb 27 10:33:05 AM Pacific 
  Standard Time 2003
  bell.test
  Bell should ring now ...
  bgerror.test
  bind.test
  bitmap.test
  border.test
  button.test
  canvImg.test
  canvPs.test
  canvRect.test
  canvText.test
  canvWind.test
  canvas.test
  choosedir.test
  clipboard.test
  clrpick.test
  cmds.test
  color.test
  config.test
  cursor.test
  dialog.test
  embed.test
  entry.test
  event.test
  filebox.test
  focus.test
  focusTcl.test
  font.test
  frame.test
  geometry.test
  get.test
  grab.test
  grid.test
  id.test
  image.test
  imgBmap.test
  imgPPM.test
  imgPhoto.test
  listbox.test
  macEmbed.test
  macFont.test
  macMenu.test
  macWinMenu.test
  macscrollbar.test
  main.test
  menu.test
  menuDraw.test
  menubut.test
  message.test
  msgbox.test
  obj.test
  oldpack.test
  option.test
  pack.test
  panedwindow.test
  place.test
  raise.test
  safe.test
  scale.test
  scrollbar.test
  select.test
  send.test
  spinbox.test
  text.test
  textBTree.test
  textDisp.test
  textImage.test
  textIndex.test
  textMark.test
  textTag.test
  textWind.test

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

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

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


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

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

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


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

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

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


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

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

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


  ==== textWind-13.1 EmbWinBboxProc procedure 
  FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 5 -height 5 -bg $color
      .t window create 1.2 -window .f -align top -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

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


  ==== textWind-13.2 EmbWinBboxProc procedure 
  FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 5 -height 5 -bg $color
      .t window create 1.2 -window .f -align center -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

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


  ==== textWind-13.9 EmbWinBboxProc procedure, 
  spacing options FAILED
  ==== Contents of test case:

      .t configure -spacing1 5 -spacing3 2
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 5 -height 5 -bg $color
      .t window create 1.2 -window .f -align center -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

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


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

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

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


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

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

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

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

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

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

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


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

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

  ---- Result was:
  icon normal normal icon
  ---- Result should have been (exact matching):
  icon normal withdrawn icon
  ==== unixWm-27.6 FAILED


  ==== unixWm-27.7 Tk_WmCmd 
  procedure, "iconwindow" option, withdrawing icon 
  FAILE
  D
  ==== Contents of test case:

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

  ---- Result was:
  couldn't send withdraw message to window 
  manager
  ---- Result should have been (exact matching):
  normal 1 icon 0
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== unixWm-27.7 FAILED


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

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

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


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

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

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


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

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

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


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

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

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


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

  ==== Contents of test case:

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

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


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

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

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

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

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


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

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

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

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

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

  util.test
  visual.test
  visual_bb.test
  winButton.test
  winClipboard.test
  winDialog.test
  winFont.test
  winMenu.test
  winSend.test
  winWm.test

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

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

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

  window.test
  winfo.test

  ==== winfo-4.5 "winfo containing" command 
  FAILED
  ==== Contents of test case:

      winfo containing [winfo rootx .t.f] [winfo 
  rooty .t.f]

  ---- Result was:
  .
  ---- Result should have been (exact matching):
  .t.f
  ==== winfo-4.5 FAILED

  wm.test
  xmfbox.test

  Tests ended at Thu Feb 27 10:35:59 AM Pacific 
  Standard Time 2003
  all.tcl:        Total   8317    Passed  6871    Skipped 
  1425    Failed  21
  Sourced 182 Test Files.
  Files with failing tests: textWind.test unixWm.test 
  winWm.test winfo.test
  Number of tests skipped for each constraint:
          7       altDisplay
          16      colorsFree
          7       emptyTest
          265     fonts
          2       knownBug
          310     macOnly
          17      macOrUnix
          80      nonPortable
          79      nonUnixUserInteraction
          3       pseudocolor
          4       pseudocolor8
          71      secureserver
          1       tempNotPc
          1       tempNotWin
          5       testmenubar
          301     unix
          186     unixOnly
          19      userInteraction
          51      winSend
  stderr32

  This is on Windows NT 4 Service Pack 6a+.

  Not sure how many of these are "known bugs".

  JJM


tkt_uuid: 1025871fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: text-1.42 fails
comment:
  ==== text-1.42 text options FAILED
  ==== Contents of test case:

      set result {}
      foreach i [.t2 configure] {
          lappend result [lindex $i 4]
      }
      set result

  ---- Result was:
  1 blue {} {} 0 7 watch {} 0 {} fixed #012 5 #123 #234 0
  #c3c3c3 green 45 100 47 2 5 3 82 raised #ffff01234567
  21 yellow 0 0 0 0 {} disabled {1i 2i 3i 4i} {any old
  thing} 1 73 word {x scroll command} {test command}
  ---- Result should have been (exact matching):
  1 blue {} {} 0 7 watch {} 0 {} fixed #012 5 #123 #234 0
  {} green 45 100 47 2 5 3 82 raised #ffff01234567 21
  yellow 0 0 0 0 {} disabled {1i 2i 3i 4i} {any old
  thing} 1 73 word {x scroll command} {test command}
  ==== text-1.42 FAILED


tkt_uuid: 3497848fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 27. Objects
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Fixed
title: GetPixelsFromObjEx error for doubleObjs
comment:
      % info patchlevel
      8.5.11
      % canvas .c
      .c
      % set x 573.8
      573.8
      % .c canvasx $x
      574.0
      % set x [expr $x+0.0]
      573.8
      % .c canvasx $x
      573.0

  Note how the first result 574 differs from the second 573.

  this is due to the code in tkObj.c which converts numbers to pixels
  and does a rounding in one case and none in the other:

  tk/generic/tkObj.c, static int GetPixelsFromObjEx(...), 

     #206ff
      if (objPtr->typePtr != &pixelObjType) {
  ThreadSpecificData *tsdPtr = GetTypeCache();

  if (objPtr->typePtr == tsdPtr->doubleTypePtr) {
      (void) Tcl_GetDoubleFromObj(interp, objPtr, &d);
      if (dblPtr != NULL) {
  *dblPtr = d;
      }
      *intPtr = (int) d;
      return TCL_OK;
              
  Note this simply casts the double to int, no rounding.

  However, in the same routine, if the obj is not double or int:

      if (objPtr->typePtr != &pixelObjType) {
  result = SetPixelFromAny(interp, objPtr);
       ...
       if ((pixelPtr->tkwin != tkwin)||dblPtr) {
      d = pixelPtr->value;
       --<snip-snip>--
      if (d < 0) {
  pixelPtr->returnValue = (int) (d - 0.5);
      } else {
  pixelPtr->returnValue = (int) (d + 0.5);
      }
      --<snip-snip>--
  }
  *intPtr = pixelPtr->returnValue;

  Note the rounding in this case.

  Proposed patch:

  This seems to be related to
      2011-11-01  Donal K. Fellows  <dkf@users.sf.net>
              * generic/tkObj.c (GetPixelsFromObjEx): [Bug 3431491]: Use a bit of
              type hackery to allow numbers to be interpreted as coordinates (most
              notably on a canvas) without reinterpreting via a string.

  Proposed patch:

  --- tk/generic/tkObj.c2011/11/08 14:59:181.1
  +++ tk/generic/tkObj.c2012/03/06 18:15:36
  @@ -211,7 +211,11 @@
       if (dblPtr != NULL) {
   *dblPtr = d;
       }
  -    *intPtr = (int) d;
  +    if (d < 0) {
  +*intPtr = (int) (d - 0.5);
  +    } else {
  +*intPtr = (int) (d + 0.5);
  +    }
       return TCL_OK;
   } else if (objPtr->typePtr == tsdPtr->intTypePtr) {
       (void) Tcl_GetIntFromObj(interp, objPtr, intPtr);


tkt_uuid: 1246947fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 65. Generic Window Operations
priority: 3 Low
foundin: obsolete: 8.5a4
resolution: None
title: tk-6.5 fails
comment:
  On a linux/alpha/gnome system (quite old),
  test tk-6.5 fails.

  probing reveals that on this system
  [tk inactive] is returning 0, which
  the test seems unprepared for.


tkt_uuid: 420861ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 5 Medium
foundin: TIP Implementation
resolution: None
title: Tip#18 (labelframe) changes, part 1.
comment:
  This patch is part of the work with TIP#18, adding a labelframe widget.
  It consists of two main parts.

  The first is a general polish of the frame, the biggest change being an upgrade from the old 
  TK_CONFIG style option management to the newer TK_OPTION style. It also fixes a potential mem 
  leak.

  The second part implements the changes to geometry management, as described in TIP#18.

  These changes are the foundation on which the changes doing the actual labelframe stand so I 
  would appreciate some feedback on these parts now while finishing the rest of the work.

  The patch is made against the CVS head on 2 May 2001.


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

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

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

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



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

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

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

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

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

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


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

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

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


tkt_uuid: 220655ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: text widget bugs
comment:
  OriginalBugID: 4036 Bug
  Version: 8.2.3
  SubmitDate: '2000-01-18'
  LastModified: '2000-01-19'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0sp5
  FixedDate: '2000-01-19'
  FixedInVersion: 8.3


  Name:
  Vince Darley

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  I was looking through the contents of text.test, and some of the
  supposed 'correct' results seem to be wrong to me (some very minor,
  some more important):

  text-20.11, 20.12

  wrong # args: should be ".t search ?switches? pattern index ?stopIndex?

  Here we are missing a trailing "

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

  text-20.65 TextSearchCmd, unicode with non-text segments 
  (and some earlier tests seem to have similar problems)

  1.3 3

  Surely the result should be 1.3 2, since we are searching for a
  2 character string: 

  set result [list [.t search -count n \u30c9\u30ca 1.0] $n]

  Here, and in other tests, the search string is split in the window by
  an embedded widget.  But surely embedded widgets don't count as
  a 'count' of 1??!!

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

  Lastly:

  % text .i
  .i
  % .i dummy
  bad option "dummy": must be bbox, cget, compare, configure, debug, delete, dlineinfo, get, image, index, insert, mark, scan, search, see, tag, window, xview, or yview
  % .i dump
  Usage: .i dump ?-all -image -text -mark -tag -window? ?-command script? index ?index2?
  % 

  Why isn't "dump" in the list of options returned by an error?



  The first and last problems are fixed for 8.3.0, and the middle
  one (incorrect counting of bytes vs. chars for search) was fixed
  in 8.3b1 or b2 already. 
  -- 01/19/2000 hobbs


tkt_uuid: 1884667fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Wont Fix
title: search broken in help menu on leopard
comment:
  If you add a help menu on Leopard, it automatically contains a search box; however, you can't type into it at all, which certainly leaves the impression the program isn't working right.


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

  The comment in tkUnixEvent.c is:

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

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

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


tkt_uuid: 446129ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Out of Date
title: patch for FreeBSD 2.2.x
comment:
  This patch corresponds to the patch submitted for Tcl bug #443170.

  --- aclocal.m4.old      Mon Jul 30 13:49:33 2001
  +++ aclocal.m4  Mon Jul 30 13:50:59 2001
  @@ -775,18 +775,20 @@
                  DL_OBJS="tclLoadDl.o"
                  DL_LIBS=""
                  LDFLAGS=""
  -               LD_SEARCH_FLAGS=""
                  AC_MSG_CHECKING(for ELF)
                  AC_EGREP_CPP(yes, [
   #ifdef __ELF__
          yes
   #endif
  -               ],
  +               ], [
                      AC_MSG_RESULT(yes)
  -                   SHARED_LIB_SUFFIX='${TCL_TRIM_DOTS}\$\{DBGX\}.so',
  +                    LD_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
  +                   SHARED_LIB_SUFFIX='${TCL_TRIM_DOTS}\$\{DBGX\}.so'
  +                ], [
                      AC_MSG_RESULT(no)
  +                    LD_SEARCH_FLAGS='-Wl,-L${LIB_RUNTIME_DIR}'
                      SHARED_LIB_SUFFIX='${TCL_TRIM_DOTS}\$\{DBGX\}.so.1.0'
  -               )
  +               ])
              ], [
                  SHLIB_CFLAGS=""
                  SHLIB_LD="echo tclLdAout $CC \{$SHLIB_CFLAGS\} | `pwd`/tclsh -r"


tkt_uuid: 1585824fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: None
title: Tcl/Tk crashes while using logic canvas-tag expressions
comment:
  Hello,

  if I run the following script Tcl/Tk crashes.

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

  proc objbbox { canvas tag } {

    #
    # following line leads to the crash
    #
    switch -- [$canvas type   ($tag)&&!@text&&!
  @stemline&&!@gridrow&&!@gridcolumn] {

      rectangle{
        # ...do something...
      }

      default {
        # ...do something else...
      }
    }/* end of switch */
  }/* end of proc */

  canvas .canv
  pack .canv
  .canv create rectangle 1 1 100 100 -tags myRect
  objbbox .canv myRect

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


  Simple logic expressions like 

   .canvas type tag1&&tag2&&tag3&&....and so on

  never crash but if I use a logic expression that  
  includes brackets as follows

   .canvas type ($tag)&&tag2&&tag3&&tag4&&tag5

  a memory overrun occurs and causes Tcl/Tk to crash.

  The reason is a wrong if-statement embedded in a while-
  loop inside the function "TagSearchScanExpr.
  The function is part of "./tk8.4.14/generic/tkCanvas.c"

  A possible fix is:

  static int
  TagSearchScanExpr(interp, searchPtr, expr)
  Tcl_Interp *interp; /* Current interpreter. */
  TagSearch *searchPtr; /* Search data */
  TagSearchExpr *expr; /* compiled expression result */
  {
  ...
  if (expr->allocated == expr->index) {
  ...
  }

  should be changed into

  static int
  TagSearchScanExpr(interp, searchPtr, expr)
  Tcl_Interp *interp; /* Current interpreter. */
  TagSearch *searchPtr; /* Search data */
  TagSearchExpr *expr; /* compiled expression result */
  {
  ...
  // e.g
  if (expr->allocated <= expr->index+1) {
  ...
  }


  I hope this helps.

  Regards, Ayd


tkt_uuid: 1714535fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: panedwindow geometry propagation
comment:
  It seems a [panedwindow] doesn't notice
  if the geometry requests from its panes 
  change, which can lead to surprises if 
  interactively writing commands for creating 
  a layout.

  The following procedure demonstrates the 
  problem in Tk 8.5a6 aqua (although I first 
  observed it in Tk 8.4.10 aqua):

  proc layout {} {
      set t [toplevel .test]
      pack [
         panedwindow $t.panes -orient vertical
      ] -expand true -fill both
      $t.panes add [frame $t.f1] -sticky nsew -minsize 50
      $t.panes add [frame $t.f2] -sticky nsew -minsize 50
      update
      canvas $t.f1.c  -width 200 -height 150 -relief solid -borderwidth 1
      canvas $t.f2.c  -width 200 -height 150 -relief solid -borderwidth 1
      pack $t.f1.c -expand true -fill both
      pack $t.f2.c -expand true -fill both
  }

  After calling [layout], the .test toplevel starts 
  out with a width of about 5 and a height of 
  about 100. In particular, [winfo reqwidth .test.f1] 
  is a bit over 200 as one would expect, but 
  [winfo width .test.f1] is 1.

  Removing the [update] makes the window open 
  with a more normal geometry, but e.g. when 
  debugging there may well be some trips through 
  the event loop between adding a frame as a pane 
  and completing its contents. I don't recall other 
  forms of geometry management being this 
  fragile.


tkt_uuid: 1161543fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: Strange panewindow resize behavior
comment:
  With Tk 8.5 (including CVS HEAD for at least the last
  few months), try:

  option add *Listbox.height 5
  panedwindow .pw -opaqueresize true -orient vertical
  .pw add [listbox .pw.f1]
  .pw add [listbox .pw.f2]
  .pw add [listbox .pw.f3]
  .pw add [listbox .pw.f4]
  pack .pw -expand true -fill both -side top


  Now drag one of the sashes up and down -- the results
  are very strange.  The entire window shrinks, even
  faster than the sash is moved.

  After resizing the toplevel by hand to prevent geometry
  propagation, the results are still very strange;
  dragging one sash causes other, unrelated sashes to
  move also.


tkt_uuid: 1122757fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: None
title: various tests fail with -use/container etc
comment:
  The recent changes to the Windows support of embedded
  windows over the last few months seem to have
  introduced a number of test failures:

  embed 1.4, 1.5
  frame 2.5
  wm-deiconify 1.5, 2.4

  The details follow.... (this is on WinXP-sp2)

  embed.test

  ==== embed-1.4 TkpUseWindow procedure, -container must
  be set FAILED
  ==== Contents of test case:

      deleteWindows
      toplevel .container
      list [catch {toplevel .embd -use [winfo id
  .container]} err] $err

  ---- Result was:
  1 {the window to use is not a Tk container}
  ---- Result should have been (exact matching):
  1 {window ".container" doesn't have -container option set}
  ==== embed-1.4 FAILED


  ==== embed-1.5 TkpUseWindow procedure, -container must
  be set FAILED
  ==== Contents of test case:

      deleteWindows
      frame .container
      list [catch {toplevel .embd -use [winfo id
  .container]} err] $err

  ---- Result was:
  1 {the window to use is not a Tk container}
  ---- Result should have been (exact matching):
  1 {window ".container" doesn't have -container option set}
  ==== embed-1.5 FAILED

  frame.test

  ==== frame-2.5 toplevel configuration options FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 100
      wm geometry .t +0+0
      list [catch {.t configure -use 0x44022} msg] $msg
  [.t configure -use]

  ---- Result was:
  1 {window "0x44022" doesn't exist} {-use use Use {} {}}
  ---- Result should have been (exact matching):
  1 {can't modify -use option after widget is created}
  {-use use Use {} {}}
  ==== frame-2.5 FAILED

  wm.test

  ==== wm-deiconify-1.5 usage FAILED
  ==== Contents of test case:

      frame .t.f -container 1
      toplevel .embed -use [winfo id .t.f]
      wm deiconify .embed

  ---- Result was:
  can't deiconify .embed: the container does not support
  the request
  ---- Result should have been (exact matching):
  can't deiconify .embed: it is an embedded window
  ==== wm-deiconify-1.5 FAILED


  ==== wm-iconify-2.4 Misc errors FAILED
  ==== Contents of test case:

      frame .t.f -container 1
      toplevel .t2 -use [winfo id .t.f]
      wm iconify .t2

  ---- Result was:
  can't iconify .t2: the container does not support the
  request
  ---- Result should have been (exact matching):
  can't iconify .t2: it is an embedded window
  ==== wm-iconify-2.4 FAILED


tkt_uuid: 3584471fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 9 Immediate
foundin: obsolete: 8.5.13
resolution: Fixed
title: `make dist` fail
comment:
  Cannot make a Tk 8.5.13 distribution due to failure
  of the `make dist` target:

  mkdir /tmp/dist/tk8.5.13/macosx
  cp -p /home/dgp/fossil/tk8.5/unix/../macosx/GNUmakefile /home/dgp/fossil/tk8.5/unix/../macosx/README \
                  /home/dgp/fossil/tk8.5/unix/../macosx/Tk.* /home/dgp/fossil/tk8.5/unix/../macosx/*.[ch] \
                  /home/dgp/fossil/tk8.5/unix/../macosx/*.in /home/dgp/fossil/tk8.5/unix/../macosx/*.ac \
                  /home/dgp/fossil/tk8.5/unix/../macosx/*.xcconfig /home/dgp/fossil/tk8.5/unix/../macosx/*.sdef \
                  /home/dgp/fossil/tk8.5/unix/../macosx/configure /tmp/dist/tk8.5.13/macosx
  cp: omitting directory `/home/dgp/fossil/tk8.5/unix/../macosx/Tk.xcode'
  cp: omitting directory `/home/dgp/fossil/tk8.5/unix/../macosx/Tk.xcodeproj'

  Looks like some kind of Cocoa backport confusion over
  whether macosx subdirs are named Tk.xcode* or Wish.xcode*.

  I imagine I can eventually puzzle it out, but I assume this is easy
  for those immersed in the xcode machinery.


tkt_uuid: 220755ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: Tk_InitImageArgs never omits argument conversion
comment:
  OriginalBugID: 5990 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-06'
  LastModified: '2000-07-17'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Linux
  OSVersion: Debian GNU/Linux 2.2
  Machine: Generic Intel-based PC
  FixedDate: '2000-07-17'
  FixedInVersion: 8.4a2


  Name:

  Anselm Lingnau


  Extensions:

  None.


  CustomShell:

  No.


  ObservedBehavior:

  The Tk_InitImageArgs procedure in the stub library is supposed to convert Tcl_Obj* arguments

  to an image createProc to char* arguments for the benefit of functions such as Tk_ConfigureWidget,

  in the new »objectified« interface introduced in Tk 8.3. It does this by checking whether the

  »image« command is itself an objectified command or not; if it is, then it is assumed to pass

  Tcl_Obj* arguments to the createProc, which need to be converted.


  Tk_InitImageArgs looks at the »image« command only on the first call and caches the result

  in the variable »useNewImage«. The result should be either 0 or 1, but »useNewImage« is

  only set to 1 if the »image« command is indeed objectified -- it is never actually set to 0

  if it isn't, but stays at its original value of -1 (which really denotes that the check needs to

  be done). Since -1 is »true« from the C language's point of view, the argument conversion

  is always done instead of only when the objectified interface is in use. A minor side effect is

  that the procedure re-checks the »image« command on every call if it is not objectified, which

  is a teeny performance hit.


  DesiredBehavior:

  The Tk_InitImageArgs shouldn't try to convert char* arguments to char* arguments by misinterpreting

  them as Tcl_Obj*s.


  Patch:

  *** tkStubImg.c.orig    Thu Jul  6 18:42:55 2000

  --- tkStubImg.c Thu Jul  6 18:43:39 2000

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

  *** 59,67 ****

          if (!tclStubsPtr->tcl_GetCommandInfo(interp,"image", &cmdInfo)) {

              tclStubsPtr->tcl_Panic("cannot find the \"image\" command");

          }

  !       if (cmdInfo.isNativeObjectProc == 1) {

  !           useNewImage = 1; /* Tk uses the new image interface */

  !       }

        }

        if (useNewImage && (argc > 0)) {

          int i;

  --- 59,65 ----

          if (!tclStubsPtr->tcl_GetCommandInfo(interp,"image", &cmdInfo)) {

              tclStubsPtr->tcl_Panic("cannot find the \"image\" command");

          }

  !       useNewImage = (cmdInfo.isNativeObjectProc == 1);

        }

        if (useNewImage && (argc > 0)) {

          int i;


  PatchFiles:

  tkStubImg.c




  I made the correction suggested by your patch and committed the change to the CVS source repository.  The fix will go out with Tcl/Tk 8.4a2.  Thanks for finding this, and nice work!

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

  -- 07/17/2000 ericm


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

  winButton.test

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

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

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


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

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

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


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

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

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

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


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

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

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


tkt_uuid: 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: 220513ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: Can't delete Tk from safe interp on W98
comment:
  OriginalBugID: 1939 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-27'
  LastModified: '2000-04-16'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  FixedDate: '2000-04-16'
  FixedInVersion: 8.3.1


  Name:
  Christopher Nelson

  ReproducibleScript:
  ::safe::interpCreate bar -statics 1
      ::safe::loadTk bar
      # Click on Delete button in new top level

  ObservedBehavior:
  invalid command name "none"
          while executing
      "none"
          (procedure "disallowTk" line 4)
          invoked from within
      "disallowTk $slave"
          (procedure "::safe::tkDelete" line 18)
          invoked from within
      "::safe::tkDelete .safe4.fc .safe4 bar"
          (command bound to event)
      
      While displaying stack trace, another error is displayed:
      
      can't unset "tkInit(bar)": no such element in array
          while executing
      "unset tkInit($interpPath)"
          (procedure "disallowTk" line 3)
          invoked from within
      "disallowTk $slave"
          (procedure "::safe::tkDelete" line 18)
          invoked from within
      "::safe::tkDelete .safe5 .safe5 bar"
          invoked from within
      ".safe5.fc.fb.b invoke"
          ("uplevel" body line 1)
          invoked from within
      "uplevel #0 [list $w invoke]"
          (procedure "tkButtonUp" line 8)
          invoked from within
      "tkButtonUp .safe5.fc.fb.b
      "
          (command bound to event)

  DesiredBehavior:
  No errors.



  This is fidxed for 8.3.1.  The safetk.tcl code for this proc was
  doing some odd stuff and was completely rewritten. 
  -- 04/16/2000 hobbs


tkt_uuid: 219972ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Duplicate
title: Docs missing for Tk_InitStubs API
comment:
  OriginalBugID: 1870 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-22'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: hershey
  RelatedBugIDs: 1843
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-22'




  04/16/1999 15:06 - surles - Duplicate to 1843.


tkt_uuid: 845772ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: Infinite recursion on [cd]
comment:
  Under Windows 2000, with tclsh8.5 snapshot 20031119:
    cd g:
    cd c:
  crash with an infinite recursion.

  Here is the stack:

  Tcl_FSGetPathType(Tcl_Obj * 0x00912458) line 242 + 
  13 bytes

  Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, 
  Tcl_Obj * 0x00912458) line 1219 + 9 bytes
  TclFSEnsureEpochOk(Tcl_Obj * 0x00912458, 
  Tcl_Filesystem * * 0x0003321c) line 1444 + 11 bytes
  Tcl_FSGetFileSystemForPath(Tcl_Obj * 0x00912458) line 
  3718 + 13 bytes
  Tcl_FSGetCwd(Tcl_Interp * 0x00000000) line 2349 + 12 
  bytes

  Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, 
  Tcl_Obj * 0x00912458) line 1244 + 9 bytes
  TclFSEnsureEpochOk(Tcl_Obj * 0x00912458, 
  Tcl_Filesystem * * 0x000332f0) line 1444 + 11 bytes
  Tcl_FSGetFileSystemForPath(Tcl_Obj * 0x00912458) line 
  3718 + 13 bytes
  Tcl_FSGetCwd(Tcl_Interp * 0x00000000) line 2349 + 12 
  bytes

  Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, 
  Tcl_Obj * 0x00912458) line 1244 + 9 bytes
  TclFSEnsureEpochOk(Tcl_Obj * 0x00912458, 
  Tcl_Filesystem * * 0x000333c4) line 1444 + 11 bytes
  Tcl_FSGetFileSystemForPath(Tcl_Obj * 0x00912458) line 
  3718 + 13 bytes
  Tcl_FSGetCwd(Tcl_Interp * 0x00000000) line 2349 + 12 
  bytes

  ...


tkt_uuid: 220894ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.3b2
resolution: None
title: trouble with canvas imaging
comment:
  OriginalBugID: 4172 Bug
  Version: 1.3
  SubmitDate: '2000-02-14'
  LastModified: '2000-02-25'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT 4 service pack 6
  Machine: PII 400 128mb RAM


  Name:
  Richard Croft

  ReproducibleScript:
  2 windows each with a canvas and an image on the canvas.

  ObservedBehavior:
  Moving the windows around makes the images disappear and they only reappear when the windows are resized

  DesiredBehavior:
  the images not to disappear


tkt_uuid: 220444ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Tk tests fail due to Makefile problem
comment:
  OriginalBugID: 1409 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-13'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 957 1951 1896 2195
  OS: Digital Unix
  Machine: Other
  FixedDate: '1999-08-13'
  FixedInVersion: 8.1


  Name:
  James Bonfield

  Extensions:
  4.0

  ReproducibleScript:
  The Makefile links with -rpath /usr/local/lib, which means the tests will fail
  (and indeed the pogram crashes) as even specifying LD_LIBRARY_PATH will not
  prevent tktest from using whatever version of libtk.so is installed in /usr/local/lib. This is probably not an issue when generating static libraries.

  Note that _RLD_LIST can be specified instead to ensure preloading of the correct
  library. This requires Makefile changes, so I haven't submitted a patch (I do
  not know enough about autoconf etc).

  I changed the LD_LIBRARY_PATH line in the makefile with something like:

  _RLD_LIST=`pwd`/libtk8.0.so:${TCL_BIN_DIR}/libtcl8.0.so:DEFAULT

  ObservedBehavior:
  Tests appear to fail, but this is very misleading.

  DesiredBehavior:
  Tests work.



  This problem should be alleviated with the rework of the configure
  scripts for 8.1. 
  -- 08/13/1999 hobbs


tkt_uuid: 2226093fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 9 Immediate
foundin: obsolete: 8.6a4
resolution: Fixed
title: const changes not all correct
comment:
  The last set of changes (Nov 2) introduced a bug in tkUnixFont.c:2551.  You declare nameList as:

      const char *const *nameList;

  but that defies the assignment it receives at 2551.  mjanssen noticed this with gcc4, but my gcc3 glossed over it.  Please use gcc4 for const changes in the future to prevent const poisoning issues.


tkt_uuid: 220633ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: wish8.2 crashes when creating images on aix-4.1.5.
comment:
  OriginalBugID: 3799 Bug
  Version: 8.2
  SubmitDate: '1999-12-07'
  LastModified: '1999-12-09'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  OSVersion: aix 4.1.5
  Machine: rs6000
  FixedDate: '1999-12-09'
  FixedInVersion: 8.2.2


  Name:
  MArkus Pietrek

  Comments:
  a simple patch would be in Tcl_Alloc, to allocate at least 1 byte on AIX

  ReproducibleScript:
  set image {
  R0lGODlh9AFDAbMAAAAAAADW1gDW74z/////////////////////////////////////////
  /////////ywAAAAA9AFDAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//A
  oHBILBqPyKSyJVg6n9CodHpsUqwALHXL7Xq/4KxgTB5PtOG0es1uw9BXt3xOr9s18Lt+z+8H
  yVlxfoOEhYYsVolnh4yNjo+CihJ5kJWWl2uSWJSYnZ6fTmVanKClpqdEpKirrK0zqq6xsrMZ
  iaO0uLm6i4G9vrvAwaeavMLGx5fEk8jMzY1mv7DO09R30tXY2WrX2t3eU9zf4uMpAebn6Onq
  6+YC7O/w5+Tz9AABS/f1+t75Sf37AKn9OzIwoMFjBYskPMhQ18IhDxtKjBUxSMWJGE9d/LEx
  o8dD/pIodOwx8qPJPiEnlNyx8qTLNtB6bZLQMkfNlzi/KAt580bPnEDBVVCk5WcNo0GTLkFj
  q+gLeSiQKp1qhOkyX1Ir9EOalapXIDuv2otq7gLXr2h1zvRlxehWC2fTyp3jFkPZqHPztuF6
  VyveMzEXibIA6Jfewza6FozLVlCxYikRS+4gqrLlwiXejqX516pYsSEjTx7Ngu8/qCfyefY8
  FDLp16XxfZbZmrBr2LhTyzYcOc9aw7mDf+gKQ/WkJikp/Q4nvDnxp7ejYVjevLqH5y7+AaLu
  GDNz67mxt7j4HTh4nINbp78CDY342ByYlz9/8NZj4GudKrnMHzN9vawF/gjaZ++t0F9//yG2
  Wm0M/lagCgfyl+BhCzrWXTEPljPhfxXeN6BYUg0wwQAkrpDhhi51aF5jILIgogQv/oWidfZJ
  dwF3m50Q44gqnDjjR+t9CFlM+ulowY4m+PhjUOUVacKOJfa45I/y+YUCkgBgSYKSUyoV4WUh
  Hilll0t+aVmYWfKoIZlUmikKmllGuSabdHLA5ZZ15qnBnSPwqadefoYQ6J9yDTocoYhypoSh
  iVLFaAePNppUpBtQKmlOlmaQ6aUubWoWp3l6CheodYpqJalkmioSqmyqqhKrqe4G65KuKjrr
  j7XmeCuKuea6az29/jpjPMSu406xyPYl7K7z/i0rLCfNOvurctJW64FlHlqr7bXbdgtCtN5K
  KuFs4ZbLoLnoZpvusr+tuC6zDb5rrYDyVhskuPVyim++4vJb7r7+IgpwwH8OTHCeBh9MZ8IK
  N+zwwxBHLPHEFFds8cUYZ6zxxhx37PHHIIfs0zoid+lryRKdjDJDKq9sUMsuBwRzzOQQS/PN
  OAuT0Mw5V7Nzz9bZDDR4PA/dTdFGZ4N00j4zveHSTjfzTtRUV2110ulcHd6pWk/2c9defwq2
  ZF+PjdhAUJtNETpqt+322/UKDffZc5+ddt2o3I23KcrujZbefn/Sd+COEl5oPIYnrnjZfSo+
  D+MiAO44F3I3Prk4/thJfvkjdY26Od8qDS6obp5/LvirtloeOeKmn27rT523vopmukYuu9Ko
  1z466faIfjskqMWO5+u/C8Q77cUzEzvyyQNfFmPD56h582PmI/yWfU1PvYzM7749QrnD/j0y
  tIufGsnjN2J96qoP3336hWTNu/urwt9JsvjDE37u9vNR4PL8698eUGOiv7xPgHog4PwyQxPf
  IdB/DjzUA40RQTtNEBgKbB8IIqK9C1aqghuMXu066EG4gNB27UNbCevwPxGqcIV0yKCMvDdC
  GN5BhiIMYQBJaEOznLBSLuRaD29oPhSyj4dDFMkP94Q9/SVRDjjU4BMxEUUGTtETLbyi/jaQ
  qEV/dBF3X5wGO8JIQTIaz4zO4CIahaDGNVrEjTpjHRzn+C7I0bEVdrwj3+SoRzz28Y91HCMg
  cdHGQSbGkIREJC0KqcgYMLKR51MHJCdJSQTKr5KuCyAmK5HHTapPbJ7kJChDCTwhkpJzbDul
  KleJt9MskZUxrJ/uYOk/rj2SlrJM3S1xqUtT8tIOp/HlL2O5w2H2YX25NGYCXanMZjrzmdCM
  pjSnSc1qWvOa2MymNrfJzW56Eyid1JQmv6mDwa3kgOT0SQ11OMt0qvOFDQwmye6RSnceUlfl
  C50slbVLPeZznfCEpz1n8M8XBlSYAx1P/ZCJuoMmM6HQWRVD/hXl0HFCFD6vmuhmKsq+iypU
  K/9cp0g9mp1REhBtz0MoSVfK0q/0U5ovjWZMoTnTZ9bUmTdtZk6VuVNj9nSYP/1lUHk5VFwW
  lZZH3V4eW1JEQQmShqFUoUAlmEOqzjCqfpnqdZJUVSueUqq27Fsq6wlVq9rlpFAhqydDGkzi
  NZSrUrRlL9uJSbYWc5ZN3SD6ADpKUtr1iB3daP4GK0lI3SWcda2hKy9Zz7ya1YQMbSws6ZnV
  h4rNsVsVp2U16lfFJvNrmIUUEzcbWKyWbn9zDa0FNdvA1CK1r/EEafZeaVnD7pVtWwkebUma
  VFb2dpW/VWVwv9rSKQy3s8WNwnFNgZvcJyx3rc2FwnM3Od3ERtcJ1V3jJVWXXRhqlardLSFi
  R0vX6xpRU/zMqjzoWUXzrtYuqH1ray3qXtuedqNWYl54Lxi8/PoXsPVdk0H/O9IAi9ZzA17o
  XQ2cWQJTlMDfZTBr5yo9JbqVvhL2YQYViNvYRjjDIA6xiEdM4hKb2BgRAAA7
  }

  set img [image create photo -data $image]
  canvas .a
  pack .a
  .a create image 0 0 -image $img

  ObservedBehavior:
  malloc(0) returns NULL on AIX

  #0  0xd007b418 in raise ()
  #1  0xd001b36c in abort ()
  #2  0xd08592c4 in Tcl_PanicVA ()
  #3  0xd0859340 in Tcl_Panic ()
  #4  0xd0858cec in Tcl_Alloc ()
  #5  0xd09e4634 in ImgPhotoSetSize ()
  #6  0xd09e381c in ImgPhotoConfigureMaster ()
  #7  0xd09e1f54 in ImgPhotoCreate ()
  #8  0xd09dcf7c in Tk_ImageCmd ()
  #9  0xd0871350 in TclInvokeStringCommand ()

  DesiredBehavior:
  wish8.0, wish8.1 run correctly



  This has already been addressed in the 8.2.2+ builds, which
  are already available. 
  -- 12/09/1999 hobbs


tkt_uuid: 220377ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Menubar keystroke access in Linux
comment:
  OriginalBugID: 656 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1999-09-13'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Linux
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-09-13'
  FixedInVersion: 8.0.5


          I am slowly bringing myself into version 8, and hitting a snag
  with the menubar.  We have an application that has the new menubar
  style stuff working fine under Wiundows NT, but when I run it 
  under LInux, and try to use the keypress, I get the following error.

  BACKGROUND ERROR:
  grab failed: window not viewable

  ERRORCODE = NONE

  ERRORINFO =
  grab failed: window not viewable
          while executing
  "grab -global $w"
          (procedure "tkTraverseToMenu" line 21)
          invoked from within
  "tkTraverseToMeny .foo f"
          (command bound to event)

          The code for tkTraverse... is in lib/tk8.0/menu.tcl.

          The code we use to start the menu bar is..
  [snip]
  set m [menu $foo.menu -tearoff 0 -type menubar]

  #
  ########## FILE MENU
  #

  menu $m.file -tearoff 0

  $m add cascade -label "File" -menu $m.file -underline 0
  $m.file add separator
  $m.file add command -label "Quit "  -command "foo_Quit $foo" -underline 0

          Is this common?  Is there something that is WinNT dependant
  that I can switch off in the initialization of the menubar?
  Inside menu.tcl, they do some unix dependant switching.. so maybe
  I need to do something during init.

  From: Joshua Lamorie <jlamorie@engsoc.carleton.ca>

  This problem was fixed in a patch release. 
  -- 09/13/1999 hobbs


tkt_uuid: 220230ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: XIO: fatal IO error 0 on X server
comment:
  OriginalBugID: 2641 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-08-31'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: Linux 2.2.6 - slackware 4.0
  Machine: Other
  ClosedDate: '1999-08-31'


  Name:
  Aadt A.Jansen

  Extensions:
  tcl 8.2 tk 8.2

  ReproducibleScript:
  make test dies with
      XIO:  fatal IO error 0 (Success) on X server ":0.0"
            after 36 requests (34 known processed) with 1 events remaining
      
      No such behaviour with release 8.1.1



  This looks like a problem in connecting to the X server, not in
  Tk itself. 
  -- 08/31/1999 hobbs


tkt_uuid: 672362ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 3 Low
foundin: None
resolution: Wont Fix
title: No flash when tk_strictMotif is 1
comment:
  [.button flash] has no effect when tk_strictMotif is
  set to 1.
  If this behaviour is intentional, it should be mentioned
  in the manpage, if not, it should be fixed ;)


tkt_uuid: 220575ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.2b2
resolution: Fixed
title: crash when destroying window
comment:
  OriginalBugID: 2513 Bug
  Version: 8.2b2
  SubmitDate: '1999-08-10'
  LastModified: '2000-01-19'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0sp5
  Machine: X86
  FixedDate: '2000-01-19'
  FixedInVersion: 8.3


  Name:

  vince darley



  CustomShell:

  my glob patch has been applied



  Comments:

  I guess there is a workaround, which is to make sure to never do both

      of: (i) destroy the toplevel, and (ii) throw an error, in a script used

      in the above way.   Unfortunately for my code this requires complicating

      things a bit.

      

      It seems a possible solution to avoid the crash is to modify

      Tk_GetAtomName so

      that if the dispPtr is set incorrectly, it returns the string "?atom not

      known, since window destroyed?", in a similar fashion to how it

      currently returns the string "?bad atom?"  if the atom doesn't exist on

      tkwin's display.



  ReproducibleScript:

  invoke the following commands in wish (WindowsNT):

      

      toplevel .t

      wm protocol .t WM_DELETE_WINDOW foo

      bind .t <<Destroy>> foo

      proc foo {} { destroy .t ; error "crash" }

      

      Now click on the 'close box' (the X) in the .t toplevel.  Wish will

      crash.



  ObservedBehavior:

  Here's where the error occurs in the C code (Windows Tk)

      In TkWmProtocolEventProc(winPtr, eventPtr):

      

          result = Tcl_GlobalEval(interp, protPtr->command);

          if (result != TCL_OK) {

      Tcl_AddErrorInfo(interp, "\n    (command for \"");

      Tcl_AddErrorInfo(interp,

      Tk_GetAtomName((Tk_Window) winPtr, protocol));

      

      

      After the script I've bound to 'wm protocol .win WM_DELETE_WINDOW'

      returns an

      error, Tk crashes in trying to create the error message.  The crash

      occurs

      in the 'Tk_GetAtomName' method, right at the beginning:

      

         register TkDisplay *dispPtr;

          register Tcl_HashEntry *hPtr;

      

          dispPtr = ((TkWindow *) tkwin)->dispPtr;

          if (!dispPtr->atomInit) {

      

      dispPtr seems to set badly, and so 'dispPtr->atomInit' causes an access

      violation.

      

      Other circumstances: this occurs as the window is being destroyed (since

      it is something bound to 'WM_DELETE_WINDOW'), so that presumably

      contributes to the problem.





  This seems to be related to the use of <<Destroy>>, which is not
  what the user wants anyway (they really should us <Destroy>).  This
  virtual event call is causing a crash though, which must be
  investigated. 
  -- 08/19/1999 hobbs
  The problem was in tkWinWm.c:TkWmProtocolEventProc where an atom
  name was requested using the tkwin after the window was destroyed.
  This is fixed for 8.3.0. 
  -- 01/19/2000 hobbs


tkt_uuid: 1911011fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Postponed
title: cscroll.tcl MouseWheel scrolling only works on Mac
comment:
  Hi guys.

  I was hoping to use the cscroll.tcl demo to sort out why the scrollframe by Ulis at http://wiki.tcl.tk/9223 (a similar canvas implimentation) wasn't accepting and acting on MouseWheel events.

  However, on testing with both X11 and Windows, the Tk demo cscroll.tcl's MouseWheel events are only acted on if the platform is Mac (Aqua). Elsewhere, MouseWheel events are ignored.


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: 220901ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Widgets
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Native balloon-help
comment:
  OriginalBugID: 4403 RFE
  Version: 8.3
  SubmitDate: '2000-03-20'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: All
  OSVersion: 8.x
  Machine: PowerMac


  Name:
  Q. Alex Zhao

  Extensions:
  none

  CustomShell:
  none

  Comments:
  Please. Please.. Please...

  DesiredBehavior:
  Native balloon-help or tool-tips. This is a very common feature in desktop
  applications these days. Using native widgets should make people's (especially
  mine) lives much simpler, not to mention their programs much more robust.

  Especially on Macs -- no way to implement balloon-help in Tk; don't know how to
  write an extension to access the MacOS balloons. Help!


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

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

  Added basic Cygwin support.

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

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

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

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

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

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


tkt_uuid: 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: 220732ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: menu 'separators' take up too much vertical space
comment:
  OriginalBugID: 5303 Bug
  Version: 8.3
  SubmitDate: '2000-05-01'
  LastModified: '2000-05-09'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  OSVersion: 4.0sp5
  FixedDate: '2000-05-09'
  FixedInVersion: 8.4a1


  Name:
  Vince Darley

  CVS:
  latest 8.3.1

  Comments:
  '8.3.1' is not a version you can select in the bug form...

  ReproducibleScript:
  Menu separators in Tk 8.3.1 now take up as much vertical space as a regular menu item.  This is different to Tk 8.2 or any common windows application, for which separators are 2-4 pixels smaller in height.  Visually this makes Tk's menus look not quite as nice.

  I assume this was introduced in:

  2000-04-13  Eric Melski  <ericm@scriptics.com>
  * win/tkWinMenu.c: Corrected code that created separator items on
  menus; originally, it requested that the system be responsible for
  drawing those items, so it would ignore configuration items like
  the widget background.  Now, we draw the separators ourselves (as
  we do with every other kind of menu item already). [Bug: 1166].

  DesiredBehavior:
  This is obviously only a cosmetic issue, but I'd like to see separators in Tk menus look the same as in other applications.



  Verified with 8.3.1.  The place to fix this is in GetMenuSeparatorGeometry in tkWinMenu.c.  Currently we use the menu font linespace as the height of the separator space.  Instead it should be

  linespace - (2 * descent)

  The menu drawing code could stand some more geometry tweaking as well, but I fixed the separator issue as best I could given the minor inaccuracies in the other code.  At least it looks correct with the default Windows system menu font.  This fix will go out with 8.4a1.

  - eric

  -- 05/09/2000 ericm


tkt_uuid: 220384ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: text selection highlight bug on Windows
comment:
  OriginalBugID: 721 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-13'
  LastModified: '1999-08-06'
  Severity: MED
  Status: Released
  Submitter: admin
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-06'
  FixedInVersion: 8.0.4


  ReproducibleScript:  text .t -width 40 -height 20
  pack .t
  .t insert 0.0 "this is such\na fun story\n"
  .t insert end "really?"

  button .b -text select -command {.t tag add sel 2.0 2.end}
  button .c -text remove -command {.t tag remove sel 2.0 2.end}
  button .e -text exit -command {exit}
  pack .b .c .e

  #focus .t

  ObservedBehavior: after script is started, click on "select", nothing
  will be highlighted.

  DesiredBehavior: if i click on "select", line 2 should be highlighted,
  "remove" will remove the highlight.

  Comments: it worked great on UNIX, but failed in Windows NT.  however,
  it'll work on NT if i uncomment the focus command.


  This works as expected with 8.0.4. 
  -- 08/06/1999 hobbs


tkt_uuid: 1997299fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.5.2
resolution: None
title: Tag borderwidth is leaking horizontally
comment:
  Observed behavior: when setting -relief non-flat and -borderwidth greater than tag width then relief border extends from left and right side over the area of tagged characters.

  Desired behavior: border being clipped horizontally the same way as it is clipped vertically, not extending the tagged area.

  Code example:

  font configure TkFixedFont -size 20
  pack [text .t -font TkFixedFont -height 5 -width 5]
  .t tag configure relief -relief solid -borderwidth 100
  .t insert 1.0 {
   ooo
   o} {} x relief {o
   ooo
  }


tkt_uuid: 1446843fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.12
resolution: Out of Date
title: Macintosh scrolling touchpads do not work
comment:
  Despite a binding to the MouseWheel event, no events are reported for 
  the Macintosh two-finger style scrolling system on laptops. I also 
  noticed that the MightyMouse's mousebutton is not supported. No 
  events get dispatched, no matter what direction I roll it in. A normal 
  mouse, with a normal mouse wheel, worked as expected. This is a 
  severe limitation in Tk at the moment.


tkt_uuid: 2996165fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Duplicate
title: wish fails to start if $DISPLAY contains ::
comment:
  Hi!

  If $DISPLAY environment variable contains ::, which could be possible with IPv6 like DISPLAY=::1:0.0, wish immediately crashes at start with the following messages:

  % DISPLAY=::1:2 wish8.6
  Application initialization failed: Can't find a usable tk.tcl in the following directories: 
      ../tk8.6 ../../tk8.6 /usr/share/tcltk/tcl8.6/tk8.6 /usr/lib/tk8.6 /usr/local/lib/tcltk/tk8.6 /usr/local/share/tc
  ltk/tk8.6 /usr/lib/tcltk/tk8.6 /usr/share/tcltk/tk8.6 /usr/lib/tcltk/tcl8.6/tk8.6 /lib/tk8.6 /usr/library

  /usr/share/tcltk/tk8.6/tk.tcl: can't access "::tk::Priv.::1:2": parent namespace doesn't exist
  can't access "::tk::Priv.::1:2": parent namespace doesn't exist
      while executing
  "upvar #0 ::tk::Priv.::1:2 ::tk::Priv"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 upvar #0 ::tk::Priv.$disp ::tk::Priv"
      (procedure "tk::ScreenChanged" line 9)
      invoked from within
  "tk::ScreenChanged [winfo screen .]"
      (file "/usr/share/tcltk/tk8.6/tk.tcl" line 288)
      invoked from within
  "source /usr/share/tcltk/tk8.6/tk.tcl"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  %

  The problem is in ::tk::ScreenChanged which uses the value of $DISPLAY as a variable name, so :: in it is treated as namespace delimiter. Simple mapping of :: to some safe string (which never occurs in $DISPLAY values)  will solve the bug.


tkt_uuid: 1596662fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: None
title: Menu behaviour at screen bottom
comment:
  If a Tk toplevel is moved near the bottom of the screen and a menu item is selected from the menubar with a short mouse click, and if the menu pops up under the pointer, then a menu item is accidentaly selected. This can be easily reproduced by any Tk script using menus, e.g. the widget demonstration: open the "Menus and cascades" demonstration, move the created window near to the screen bottom, and click on any of the menus.

  Other toolkits (i.e. Gtk) seem to solve this problem by popping the menu *above* the pointer in these situations.

  Attached is a naive Perl/Tk hack around Tk::Menu::post to implement just this behaviour. It would be nice if tkMenuDraw.c:TkPostSubmenu had something similar.

  Regards,
      Slaven


tkt_uuid: 1618604fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 8
foundin: obsolete: 8.5a6
resolution: Fixed
title: Runtime Check failure on Win/VC8 - uninitialized locals
comment:
  The TkpDisplayButton function in "win/tkWinButton.c", near line 469 defines and uses the "width" and "height" variables, which in some cases never get properly initialized before being used.  This results in a RTC (runtime check) failure on Windows with VC8.

      /*
       * Display image or bitmap or text for button.
       */

      if (butPtr->image != None) {
  Tk_SizeOfImage(butPtr->image, &width, &height);
  haveImage = 1;
      } else if (butPtr->bitmap != None) {
  Tk_SizeOfBitmap(butPtr->display, butPtr->bitmap, &width, &height);
  haveImage = 1;
      }
      imageWidth = width; // <-- was never initialized
      imageHeight = height; // <-- was never initialized

  In the above code, when both the image and bitmap fields of the button are NULL, width and height never receive a valid value.  Assigning imageWidth and imageHeight from them will result in a runtime check error on Windows with the VC8 compiler.

  Changing the following code near line 352 from:

  int width, height, haveImage = 0, haveText = 0, drawRing = 0;

  to the following code seems to fix the issue:

  int width = 0, height = 0, haveImage = 0, haveText = 0, drawRing = 0;

  It appears that "unix/tkUnixButton.c" has the same issue (which may cause something more nasty than a runtime check error).


tkt_uuid: 3137232fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: spinbox error after destroying toplevel from widget
comment:
  #!/bin/sh
  #\
  exec vmwish "$0" ${1+"$@"}

  ################################################################################
  # Fehlerbeschreibung:
  #   1. <Button-1> auf dem "Pfeil oben"-Knopf gedrückt halten bis Spinbox automatisch hochgezählt wird. 
  #   2. Dann mit gedrückter Maustaste den Knopf verlassen. (Endlosschleife in ::tk::spinbox::Invoke)
  #   3. dann die Maustaste ausserhalb los lassen und dann den Knopf "Zerstöre Toplevel" drücken.
  #   4 . nach Abschluss der for-Schleife => Applikationsfehler da Spinbox in der Schleife ::Invoke 
  #       nicht mehr existiert.
  ################################################################################

  ################################################################################
  # Bug in spinbox.tcl
  #1. Hold mouse button over the "buttonup arrow" till the spinner automatically increment the value. 
  #2. Then move the mouse cursor while hold Button-1 pressed away from the "buttonup arrow" and now button release.
  #3. Then TK enter a loop ::tk::spinbox::Invoke in /usr/lib/tcl/tk8.5/spinbox.tcl
  #4. Now press the button "Destroy Toplevel" while -command "todo" proc is computing.
  #5  After finishing the -command todo proc a Application Error occurs.
  #
  #6. Sorry for my english...
  #invalid command name ".t.sp"
  #invalid command name ".t.sp"
  #    while executing
  #"$w cget -repeatinterval"
  #    (procedure "::tk::spinbox::Invoke" line 8)
  #    invoked from within
  #"::tk::spinbox::Invoke .t.sp buttonup"
  #    ("after" script)
  #


  ################################################################################
  # use this example-code to test the error.

  wm withdraw .
  toplevel .t
  set sp [spinbox .t.sp \
               -validate key \
               -command todo \
               -width 2 \
               -from 1 \
               -to 99 \
               -increment 1]
  pack $sp
  pack [button .t.b -text "Destroy Toplevel" -command beenden]

  ################################################################################ 
  proc todo {} {
     for {set i 0 } {$i < 2500} {incr i} {
        puts "$i Datum: >>[exec date]<<"
     }
     return
  }
  ################################################################################
  proc beenden {} {
     destroy .t
     return
  }


tkt_uuid: 219981ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Duplicate
title: Segv when moving pointer over text in text-widget on AIX
comment:
  OriginalBugID: 2044 Bug
  Version: 8.1
  SubmitDate: '1999-05-10'
  LastModified: '1999-08-20'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2316
  OS: AIX
  OSVersion: 3.4
  Machine: RS6000
  ClosedDate: '1999-08-20'


  Name:
  Adrian Wallaschek

  Extensions:
  None, pure wish8.1

  ReproducibleScript:
  # This script creates just a text widget.
      # To cause the error just type some chars and move the mouse over them
      ... bang!
      # This happens for me on AIX 3.4

      # Create a callback log in the main window
      wm title . "CLS API Probe Callbacklog"

      text .cbl -yscrollcommand ".yscroll set"  -xscrollcommand ".xscroll set"  -width 80 -height 24

      scrollbar .yscroll -command ".cbl yview" -orient vertical
      scrollbar .xscroll -command ".cbl xview" -orient horizontal

      button .clear -text "Clear log" -command ".cbl delete 1.0 end"

      grid .cbl .yscroll -sticky news
      grid .xscroll -sticky ew
      grid .clear -sticky ew
      grid rowconfigure . 0 -weight 1
      grid columnconfigure . 0 -weight 1

      proc x11_cls_callback_log {varname index op} {
              upvar $varname v
              set x "[clock format [lindex $v 0]]: [lindex $v 2] [lindex $v
      3]\n"
              .cbl insert end $x
      #       update
      }

      trace variable ::cls::callback wu x11_cls_callback_log

  ObservedBehavior:
  On AIX 3.4 the tcl/tk crashes when running above script (the trace is
      not
      necessary, just supplied my whole script.) typing some chars into the
      text 
      and move to mouse over them. I use Xceed instead of a AIX X-server just
      in 
      case this makes a difference, which I don't think.
      The core dump then show this stack:
      (dbx) where
      signal.pthread_kill(??, ??) at 0xd43e8df4
      signal._p_raise(??) at 0xd43e83ac
      raise.raise(??) at 0xd418280c
      abort.abort() at 0xd41af7b0
      _Insight_signal_handler(int)(0xb), line 381 in "trap.cc"
      TkTextPixelIndex() at 0x101ffda4
      TkTextPickCurrent() at 0x102022a0
      tkTextDisp.DisplayText() at 0x101fd04c
      TclServiceIdle(), line 692 in "tclTimer.c"
      Tcl_DoOneEvent(0xffffffff), line 889 in "tclNotify.c"
      TclEventLoop::Perform()(this = 0x200d2f10), line 49 in
      "cls_papi_probe.cpp"
      OnCall()(0x200d2f10), line 63 in "cls_papi_timer.cpp"
      TimerCallback(void*)(0x200d2ea0), line 12 in "cls_mapi_timer.cpp"
      Call(const CTS_Event&)(0x200dce48, 0x2ff1ef74), line 85 in
      "cls_ccli.cpp"
      OnSysEvent__8CTS_BaseFRC9CTS_Event() at 0x10045bb8
      OnSysEvent__8CTS_UtabFRC9CTS_Event() at 0x10045894
      CTSOO_ar_utab_event() at 0x10047140
      FSM_process() at 0xd325d474
      FSM_process_sys_event() at 0xd3261860
      FSM_process_event2() at 0xd326174c
      FSM_process() at 0xd325d338
      FSM_handle_cb() at 0xd325c37c
      CALL_call_callback() at 0xd3233bd8
      CAPP_loop_main() at 0xd32350b4
      CAPP_main() at 0xd32352c4
      FSM_main_loop() at 0xd3264228
      CTS_run(), line 630 in "cts_init.h"
      CACHE_Run(0x20048d40), line 121 in "cls_ccli.cpp"
      CLSRunInitAPI(0x2004d290), line 48 in "cls_mapi.cpp"
      main(argc = 1, argv = 0x2ff22580), line 114 in "cls_papi_probe.cpp"
      (dbx) 

      First I thought my own app with a split-up event-handling, etc. was the
      cause
      but then I could reproduce it with a locally compiled out-of-the-box
      wish8.1.

      Compiler is xlc rsp. cc
      on AIX ... 3 4 000290854C00

      The problem is persistent and makes the text-widget unusable, other
      widgets seem
      no to be affected but I didn't test other wery well (not beyond the
      demos).
      The program cores when moving over the text or traversing between title
      bar
      and text-widget. (I still can leave the widget with the mouse and enter
      the
      window title from the top but not directly from the text-widget !?!?)

  DesiredBehavior:
  Well ... no core-dump ;-)



  This looks to be the common AIX-text widget problem. 
  -- 08/20/1999 hobbs


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


  Name:
  Michael Lukaschek

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

  Inside this it crashes with the following messages:

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

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

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

  DesiredBehavior:
  display images of requested size



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


tkt_uuid: 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: 1599877fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 8
foundin: obsolete: 8.4.13
resolution: Fixed
title: error using alt-key Windows menus with multibyte characters
comment:
  error in Windows menus with multibyte characters, like japanese strings, e.g: 名前を付けて保存(&A) 

  if using the character index, the submenu will underline the right letter, but it doesn't work, and if using the byte intex, it works (using <alt>-character), but the appropiated character won't be underlined. 

  this error is located at tkWinMenu.c (at least until tcl 8.4.13)
  in the procedure
  TkWinHandleMenuEvent(phwnd, pMessage, pwParam, plParam, plResult)
  case WM_MENUCHAR:
      
  instead 
  label[underline]
  *Tcl_UtfAtIndex(label, underline) 
  must be used for multibyte character strings


  escolano@cimne.upc.es


tkt_uuid: 219966ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Duplicate
title: OS/390 has no passwd.pw_gecos field
comment:
  OriginalBugID: 1724 Bug
  Version: 8.1b2
  SubmitDate: '1999-04-05'
  LastModified: '1999-04-05'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: pat
  OS: Other
  OSVersion: OS/390 4.0
  Machine: NA
  ClosedDate: '1999-04-05'


  Name:
  Christian Krone

  Extensions:
  Expect 5.28

  ReproducibleScript:
  Compilation error on OS/390 for tkCanvPs.c,
      since the passwd struct has no pw_gecos field.

  Patch:
  *** unix/configure.in.orgWed Mar 17 04:29:03 1999
  --- unix/configure.inTue Mar 23 13:10:54 1999
  ***************
  *** 199,204 ****
  --- 199,216 ----
    AC_CHECK_HEADERS(sys/time.h)
    AC_HEADER_TIME

  + #-------------------------------------------
  + #In OS/390 struct pwd has no pw_gecos field
  + #-------------------------------------------
  + 
  + AC_MSG_CHECKING([pw_gecos in struct pwd])
  + AC_TRY_COMPILE([#include <pwd.h>],
  + [struct passwd pwd; pwd.pw_gecos;], tk_ok=yes, tk_ok=no)
  + AC_MSG_RESULT($tk_ok)
  + if test $tk_ok = yes; then
  +     AC_DEFINE(HAVE_PW_GECOS)
  + fi
  + 
    #--------------------------------------------------------------------
    #Locate the X11 header files and the X11 library archive.  Try
    #the ac_path_x macro first, but if it doesn't find the X stuff
  *** unix/configure.orgWed Mar 17 04:29:03 1999
  --- unix/configureTue Mar 23 13:12:11 1999
  ***************
  *** 1434,1439 ****
  --- 1434,1471 ----
    fi

  + #-------------------------------------------
  + #In OS/390 struct pwd has no pw_gecos field
  + #-------------------------------------------
  + 
  + echo $ac_n "checking pw_gecos in struct pwd""... $ac_c" 1>&6
  + echo "configure:1505: checking pw_gecos in struct pwd" >&5
  + cat > conftest.$ac_ext <<EOF
  + #line 1507 "configure"
  + #include "confdefs.h"
  + #include <pwd.h>
  + int main() {
  + struct passwd pwd; pwd.pw_gecos;
  + ; return 0; }
  + EOF
  + if { (eval echo configure:1514: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
  +   rm -rf conftest*
  +   tk_ok=yes
  + else
  +   echo "configure: failed program was:" >&5
  +   cat conftest.$ac_ext >&5
  +   rm -rf conftest*
  +   tk_ok=no
  + fi
  + rm -f conftest*
  + echo "$ac_t""$tk_ok" 1>&6
  + if test $tk_ok = yes; then
  +     cat >> confdefs.h <<\EOF
  + #define HAVE_PW_GECOS 1
  + EOF
  + 
  + fi
  + 
    #--------------------------------------------------------------------
    #Locate the X11 header files and the X11 library archive.  Try
    #the ac_path_x macro first, but if it doesn't find the X stuff
  *** generic/tkCanvPs.c.orgWed Sep 30 04:16:44 1998
  --- generic/tkCanvPs.cTue Mar 23 13:22:09 1999
  ***************
  *** 711,717 ****

        Tcl_AppendResult(canvasPtr->interp, "%!PS-Adobe-3.0 EPSF-3.0\n",
        "%%Creator: Tk Canvas Widget\n", (char *) NULL);
  ! #if !(defined(__WIN32__) || defined(MAC_TCL))
        if (!Tcl_IsSafe(interp)) {
    struct passwd *pwPtr = getpwuid(getuid());/* INTL: Native. */
    Tcl_AppendResult(canvasPtr->interp, "%%For: ",
  --- 711,717 ----

        Tcl_AppendResult(canvasPtr->interp, "%!PS-Adobe-3.0 EPSF-3.0\n",
        "%%Creator: Tk Canvas Widget\n", (char *) NULL);
  ! #ifdef HAVE_PW_GECOS
        if (!Tcl_IsSafe(interp)) {
    struct passwd *pwPtr = getpwuid(getuid());/* INTL: Native. */
    Tcl_AppendResult(canvasPtr->interp, "%%For: ",
  ***************
  *** 719,725 ****
    (char *) NULL);
    endpwent();
        }
  ! #endif /* __WIN32__ || MAC_TCL */
        Tcl_AppendResult(canvasPtr->interp, "%%Title: Window ",
        Tk_PathName(canvasPtr->tkwin), "\n", (char *) NULL);
        time(&now);
  --- 719,725 ----
    (char *) NULL);
    endpwent();
        }
  ! #endif /* HAVE_PW_GECOS */
        Tcl_AppendResult(canvasPtr->interp, "%%Title: Window ",
        Tk_PathName(canvasPtr->tkwin), "\n", (char *) NULL);
        time(&now);

  PatchFiles:
  configure.in
      configure
      tkCanvPs.c



  04/05/1999 12:04 - pat -duplicate of 1604


tkt_uuid: 1592235fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: Add elide option to tag nextrange/prevrange
comment:
  The "tag nextrange" and "tag prevrange" commands are very handy for 
  finding tagged text, but a way to ignore elided text would be very 
  handy. Thus adding an "elide" option that is like the one for the search 
  command would be a big win.

  A clumsier alternative (though possibly quite useful for other tasks) 
  would be some easy way to determine what text in a range is visible or 
  elided. One could then feed the result from "tag nextrange" through 
  that command to decide which portions of the found range (if any) were 
  actually visible.


tkt_uuid: 1450800fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Fixed
title: TkAqua creates window with "temp" as title
comment:
  This script:

  destroy .tt ; toplevel .tt ; wm title .tt "" ; wm transient .tt . ; wm title .tt ""

  results in a window with 'temp' as the name in the titlebar!

  As well as this peculiarity, doing [wm title $toplevel ""] on any window has 
  no effect at all. On other platforms this sets the title to the empty string 
  (so there is no title shown). On MacOS X it is just a no-op.


tkt_uuid: 2978063fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: None
title: Localizing application first menu entries
comment:
  The hardcoded menu entries in the first application menu are localized by :NSLocalizedString(@"string", nil), e.g.

   [NSString stringWithFormat:NSLocalizedString(@"About %@", nil), aboutName]

  so that the file Localizable.strings in the language folder /Resources/<lang>.lproj can substitute the menu entries

  In the attachment there is a numbered extract with the changed lines in  tkMacOSXMenus.c

  I will look into other files, too, but what is done is done ...

  Great project!

  Zbigniew


tkt_uuid: 525111ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Works For Me
title: Bug in menu delete
comment:
  The followin code shows a bug in the windows menu
  implementation:

  menu .menu

  for {set i 0} {$i < 20} {incr i} {
    .menu add command -label "Entry $i" -command \
    "tk_messageBox -message \"Entry $i!\""
  }
  .menu delete 10
  pack [menubutton .m -menu .menu -text Menu]

  Menu entries below the deleted item are not 
  selectable. If clicked, the last entry
  before the deleted one is executed.


tkt_uuid: 219997ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: final: 8.1.1
resolution: Duplicate
title: Tk segmentation fault on AIX 4.2
comment:
  OriginalBugID: 2261 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-21'
  LastModified: '1999-08-20'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2316
  OS: AIX
  OSVersion: 4.2
  Machine: RS6000
  ClosedDate: '1999-08-20'


  Name:
  John Severs

  Comments:
  I have tried the script line by line and it is the insert that causes
      the crash. I should say that this is a new install of tcl/tk. We haven't
      had it running on any AIX system before and this is the first script I
      have tried. The install procedure was successful with no error messages.

  ReproducibleScript:
  I am running the following script on AIX 4.2

      wm title . "Netview Log"

      frame .t
      set xlog [text .t.xlog -width 80 -height 10  -borderwidth 2 -relief raised -setgrid true  -yscrollcommand {.t.scroll set}]
      scrollbar .t.scroll -command {.t.xlog yview}
      pack .t.scroll -side right -fill y
      pack .t.xlog -side left -fill both -expand true
      pack .t -side top -fill both -expand true

      .t.xlog insert insert "text"

      I start wish then source the file which crashes when it hits the insert.

  ObservedBehavior:
  # wish
      % source test.tcl
      % Segmentation fault(coredump)
      # tclsh
      % echo $tcl_patchLevel
      8.1.1

  DesiredBehavior:
  It should insert some text into the text widget



  The text widget-AIX problem rears its ugly head again. 
  -- 08/20/1999 hobbs


tkt_uuid: 659129ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 72. Atoms
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: Tk_Uids clean up incorrectly w/ threads
comment:
  From Christian Werner (chw ch-werner de)

  While playing around with Tk 8.4.1 and multi-threading 
  on Win32
  I observed some strange behaviour w.r.t. Tk_Uids:

  1. Tk_ConfigureWidget() converts the name/class/default 
  values
  in the given Tk_ConfigSpec to UIDs.

  2. Tk_GetUid() installs a per-thread exit handler
  (FreeUidThreadExitProc()) which destroys the per-thread 
  UID
  table (and the UIDs, too) on thread termination, i.e.
  after the thread using Tk exited, some Tk_ConfigSpec 
  fields
  point to free'd memory.

  3. When Tk is re-animated later (Tk_Init()) in a new 
  thread,
  arbitrary Bad Things happen as consequence to 
  invalidated UIDs
  from point 2.

  Questions:

  - Is it really necessary to convert name/class/default 
  values to
  UIDs in Tk_ConfigureWidget ?
  - Is it really necessary to have a per-thread UID table ? 
  ---
  In the meantime I tried to temporarily fix it by:

  1. Making dbName/dbClass/defValue fields in 
  Tk_ConfigSpec
  to normal char pointer instead of Tk_Uids
  2. Using a mutex locked global (= per process) Uid table
  3. Making a temporary copy of the Tk_ConfigSpec array 
  in
  Tk_ConfigureWidget

  See the attached patch. However, this isn't perfect since 
  the
  TK_CONFIG_OPTION_SPECIFIED bit is not reflected to 
  callers
  of Tk_ConfigureWidget for threaded builds of Tk. 
  ---
  And attached patch.


tkt_uuid: 553212ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: None
title: Background images for widgets
comment:
  It'd be nice if all Tk widgets (or at least as many as
  possible) could support background images.  This was a
  feature that Barry Wegman <wegmanb@issi-hsv.com>
  mentioned (in email discussion) to me that he was
  looking for.  I don't know how well this ties in with
  native widgets...


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: 220146ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Invalid
title: make runtest: missing dependency
comment:
  OriginalBugID: 1565 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-19'
  LastModified: '1999-03-25'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: surles
  OS: Other
  Machine: NA
  ClosedDate: '1999-03-25'


  Name:
  Don Porter

  ReproducibleScript:
      $ cd tk8.1b2/unix
      $ ./configure --enable-gcc --enable-shared
      $ make
      $ make runtest

  ObservedBehavior:
      ...
      ./tktest
      /bin/sh: ./tktest: not found
      make: *** [runtest] Error 1

  DesiredBehavior:
      make runtest should start the testing shell tktest
      with all the path variable nonsense taken care of.

      A dependency should make sure ./tktest exists.

  Patch:
  Index: sun/tk/unix/Makefile.in
  diff -c sun/tk/unix/Makefile.in:1.1.1.8 sun/tk/unix/Makefile.in:1.2
  *** sun/tk/unix/Makefile.in:1.1.1.8     Wed Mar 17 12:02:48 1999
  --- sun/tk/unix/Makefile.in     Fri Mar 19 19:17:03 1999
  ***************
  *** 406,412 ****
          ./tktest $(TOP_DIR)/tests/all.tcl -geometry +0+0

    # Useful target to launch a built tktest with the proper path,...
  ! runtest:
          LD_LIBRARY_PATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH};  export LD_LIBRARY_PATH;  SHLIB_PATH=`pwd`:${TCL_BIN_DIR}:${SHLIB_PATH};  --- 406,412 ----
          ./tktest $(TOP_DIR)/tests/all.tcl -geometry +0+0

    # Useful target to launch a built tktest with the proper path,...
  ! runtest: tktest
          LD_LIBRARY_PATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH};  export LD_LIBRARY_PATH;  SHLIB_PATH=`pwd`:${TCL_BIN_DIR}:${SHLIB_PATH};  

  PatchFiles:
      unix/Makefile.in



  Looking at the comment directly above the runtest target, it notes that this target is for
  ease of use.  It assumes that tcltest has been built and is up to date.  It's sole purpose
  is to set all of the env variables and launch tcltest the same way that the test target does.

  Since this is what runtest was designed to do, and the comments back this up, I'm closing 
  this bug.  03/25/1999 15:21 - surles -


tkt_uuid: 220193ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 48. Geometry Management
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: Tcl/Tk spins
comment:
  OriginalBugID: 2109 Bug
  Version: 8.1
  SubmitDate: '1999-05-20'
  LastModified: '1999-06-29'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: redman
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-06-29'


  Name:
  Ralf Scheidhauer

  ReproducibleScript:
  toplevel .0
      frame .0.1  
      frame .0.1.2  
      pack .0.1
      pack .0.1.2
      button .0.1.3  
      grid .0.1.3

  ObservedBehavior:
  If you feed the script under 6) into wish (do not feed it line by line
      but load it as a whole from a file) then wish will hang and eat up all
      CPU 
      time. This happens both under Windows and Linux both with 8.0.5 and 8.1



  Correct behavior, don't mix layout managers in a single frame. 
  -- 06/29/1999 redman


tkt_uuid: 220393ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: Patch to display Unicode in title bars and menubars
comment:
  OriginalBugID: 819 Bug
  Version: 8.1a2
  SubmitDate: '1998-11-12'
  LastModified: '1999-05-20'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: hershey
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-19'
  FixedInVersion: 8.1b1


  Contributed patch from Syd Polk.
  "Here are patches to display japanese correctly in title bars and menubars."

  Patch on the website as
  /patches/tk8.1a2/tkWinWm.c.txt


tkt_uuid: 220704ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: '-state disabled' items in menubars are not displayed as dimmed
comment:
  OriginalBugID: 4372 Bug
  Version: 8.3
  SubmitDate: '2000-03-13'
  LastModified: '2000-07-28'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: 4.0sp5
  FixedDate: '2000-07-28'
  FixedInVersion: 8.4a2


  Name:
  Vince Darley

  ReproducibleScript:
  menu .menubar
  menu .menubar.first
  menu .menubar.second
  .menubar.first add command -label "test-item"
  .menubar.second add command -label "test-item"
  .menubar add cascade -menu .menubar.first -label "Disabled" -state disabled
  .menubar add cascade -menu .menubar.second -label "Enabled"
  label .l -text "Both menus look the same, even though the first should be dimmed"
  pack .l -fill both -expand 1
  . configure -menu .menubar

  ObservedBehavior:
  The first menu will not post, since it is disabled (which is good), but since it isn't shown as disabled (it isn't dimmed or otherwise visually different to the second menu), it is rather confusing to the user...

  DesiredBehavior:
  Menus with '-state disabled' should be visually differentiated from those with '-state normal'.  Note that _submenus_ are displayed correctly and intuitively when dimmed.



  The menu entry did not have the MF_GRAYED bit set, which is separate from the MF_DISABLED bit (which apparently disables but does not gray the entry).  Thus entries that were drawn by the system (and not directly by Tk) did not get drawn grayed.  I added this bit, and this has fixed the problem.  This fix will be included with Tcl/Tk 8.4a2.  Thanks for the bug report!

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

  -- 07/28/2000 ericm


tkt_uuid: 220054ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 1 Zero
foundin: obsolete: 8.3b1
resolution: Duplicate
title: Give control of the appearance of a toplevel in the window list.
comment:
  OriginalBugID: 4017 RFE
  Version: 8.3b1
  SubmitDate: '2000-01-13'
  LastModified: '2000-05-27'
  Severity: LOW
  Status: Closed
  Submitter: sven
  ChangedBy: hobbs
  RelatedBugIDs: 4745 4016
  OS: All Windows
  ClosedDate: '2000-05-27'


  Instead of just having transient windows not show up in the Windows window list, it would be nice to have the ability to explicitly turn that off for any toplevel.



  when/if this bug/rfe is addressed, then bug 4745 needs to be integrated 
  -- 04/12/2000 key


tkt_uuid: 504229ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: compiler warnings
comment:
  gcc -pipe -c -O -D__NO_STRING_INLINES
  -D__NO_MATH_INLINES -Wall -Wconversion
  -Wno-implicit-int -fPIC -I/home/dgporter/cvs/tk/unix
  -I/home/dgporter/cvs/tk/unix/../generic
  -I/home/dgporter/cvs/tk/unix/../bitmaps
  -I/home/dgporter/cvs/tcl/generic -I/usr/X11R6/include
  -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1
  -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1
  -DHAVE_PW_GECOS=1 -DSTATIC_BUILD=1
  -DTCL_NO_DEPRECATED  
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c: In function
  `DrawMenuEntryLabel':
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c:710: warning:
  `textHeight' might be used uninitialized in this function
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c:710: warning:
  `textWidth' might be used uninitialized in this function
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c: In function
  `GetMenuLabelGeometry':
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c:1476: warning:
  unused variable `haveText'


tkt_uuid: 220472ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: starting line missed when searching in text widget
comment:
  OriginalBugID: 1643 Bug
  Version: 8.0.5
  SubmitDate: '1999-03-26'
  LastModified: '2000-01-21'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-01-21'
  FixedInVersion: 8.3


  Name:
  Stephan Uyttebroeck

  ReproducibleScript:
      text .t
      pack .t
      .t insert end "\n"
      .t insert end "line 2\n"
      .t insert end "\n"
      .t insert end "line 4\n"
      .t insert end "\n"
      .t insert end "line 6\n"
      tkTextSetCursor .t 1.0
      .t search -forward -regexp {^$} insert end
      



  ObservedBehavior:
      This regular expression should find 'empty' lines.
      The first line found is however not line 1, but line 3.
      





  The search fails (at least) with Tcl/Tk versions 8.0.4, 8.0.5 and 8.1b2.

  Problem still exists in 8.2b2. 
  -- 08/07/1999 hobbs

  The text widget was not properly handling the somewhat special case in which the comparison text was zero length after removing the trailing newline.  I corrected this in 8.3.

  - eric

  -- 01/21/2000 ericm


tkt_uuid: 220814ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Tcl widget suggestion
comment:
  OriginalBugID: 1910 RFE
  Version: 8.0p2
  SubmitDate: '1999-04-20'
  LastModified: '2000-04-16'
  Severity: MED
  Status: Assigned
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1159
  OS: Linux-SuSE
  Machine: Other


  Name:
  Michael Thayer

  Extensions:
  Tix

  DesiredBehavior:
  A couple of ways in which Tk might be improved:
      1) include directly a more powerful widget system (such as
        the mega-widget system of Tix).
      2) (Unix specific:) make Tk widgets more interoperable with
        other GUI's such as Motif, Gnome, KDE


tkt_uuid: 532022ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 51. [place]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: place info -in not returned in parent
comment:
  The 'place info' command should return all
  configuration options for a widget managed by 'place'.
  If the widget is 'place'd in its parent (the default)
  the 'place info' does not return the '-in widget'
  option-value pair in the list of returned values. This
  is inconsistent with the pack and grid managers. It
  does however return this option if the widget is
  'place'd in a widget other than its parent.

  Workaround:
  set w [button .b]
  place $w -x 0 -y 0 -width 50 -height 20
  set info(-in) [winfo parent $w]
  array set info [place info $w]
  set place [array get info]
  place forget $w
  % eval place $w $place


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

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

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

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

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

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

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


tkt_uuid: 220270ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: create 'wish' during installation
comment:
  OriginalBugID: 4045 RFE
  Version: 8.0.5
  SubmitDate: '2000-01-19'
  LastModified: '2000-01-26'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: WinLinux 2000 Final Beta
  Machine: i586 Pentium
  ClosedDate: '2000-01-26'


  Name:
  David M. Elton

  DesiredBehavior:
  After installing 8.0, wish8.0 is created in /usr/local/bin. However, several programs try to execute wish instead of wish8.0. Many people new to *nix operating systems may have trouble fixing this problem. What I did to fix it was simply type the command "ln -s wish8.0 wish" to create a link to wish8.0. Just suggesting that maybe that line is placed in the installation scripts.



  The decision not to do this was made when Tcl started versioning
  itself, because it can potentially cause compatibility problems
  when users do the traditional
    #!/bin/sh
    # exec wish ...

  Because you may be inserting a new version of wish into someones
  path.  If the user required special extensions for a particular
  version, this would then likely cause the script to no longer work
  until the 'exec wish' hard-coded the full path. 
  -- 01/26/2000 hobbs


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: 1695507fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: Works For Me
title: ::tk::panedwindow::Motion fails
comment:
  ::tk::panedwindow::Motion fails when there is no frame inside and mouse is moved. My current workaround solution is to catch the identify and return:

  if {[catch {set id [$w identify $x $y]}]} {return}


tkt_uuid: 220265ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: final: 8.2.3
resolution: Invalid
title:
  A Tcl command invokes whenever  a mouse pointer enter the scale widget without changing the value of the variable.

comment:
  OriginalBugID: 3908 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-20'
  LastModified: '2000-01-14'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 6339
  OS: Linux-Red Hat
  OSVersion: RedHat 5.0
  ClosedDate: '2000-01-14'


  Name:
  Josephine Ng

  Extensions:
  Tcl/Tk

  Comments:
  The script is tested on both Tcl8.02p and Tcl8.2.3 on both windows 95 and Linux.
  While the script doesn't behave as expected in Linux, it behaves correctly in Windows 95.

  ReproducibleScript:
  set bandtest [scale .bt -orient horizontal  -from 410.8 -to 956.1  -resolution 0.1  -length 128 -width 5 -tickinterval [expr 956.1 - 410.8]  -digits 4 -showvalue 1 -troughcolor blue -command updateBandTest"]
  pack $bandtest

  proc updateBandTest { value } {
      puts "updateBandTest!! $value"

  }

  ObservedBehavior:
  The Tcl command will be invoked whenever the mouse pointer enter the scale widget without pressing
  any buttons of the mouse.

  DesiredBehavior:
  The Tcl command should only be invoked when the mouse button is pressed over the slider.



  This is verifed with 8.3b1 on Linux.  It does not occur on Windows
  or Solaris, so this seems to be Linux only at the moment (RH6). 
  -- 12/22/1999 hobbs

  Minimal case:

  --------------------------------
  proc foo {val} {puts "foo $val"}
  pack [scale .s -resolution 0.1 -command foo]
  .s set 0.3
  --------------------------------

  - eric

  -- 01/13/2000 ericm

  This seems to be a compiler bug.  On a sample RH 6.0 Linux install (which uses egcs-2.91.66), I found that adding diagnostic "printf" calls to the TkpSetScaleValue funciton in tkUnixScale.c made the problem go away.  Then I found that compiling the original code with neither optimization nor debugging enabled also made the problem go away.  These are classic signs of a C compiler bug.

  - eric

  -- 01/13/2000 ericm 
  -- 01/14/2000 ericm


tkt_uuid: 220703ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Tk's bgerror hangs - an innocent bug of Tk8.3.0
comment:
  OriginalBugID: 4370 Bug
  Version: 8.3
  SubmitDate: '2000-03-13'
  LastModified: '2000-04-10'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  OSVersion: All windows
  Machine: P133 Windows 95
  FixedDate: '2000-04-10'
  FixedInVersion: 8.3.1


  Name:
  Chengye Mao

  Comments:
  I found the same problem in Tk8.3.0. This problem was rooted from Tk's
      bgerror, but never happened due to an innocent "bug" of "wm transient"
      implementation. Tk8.3.0 of Windows seems to partially fix the bug, and
      the problem of bgerror starts to show.   

      Tk's bgerror handles the error during scripts evaluation. The "bgerror"
      procedure invokes a "tk_dialog" procedure to start posting the error
      information. The "tk_dialog" sets the dialog window to be transient with
      the Tk main window (using "wm transient"). According to the
      documentation of "wm transient", this dialog window should be
      synchronized with the Tk main window, i.e., it will not show if the Tk
      main window is either hiden or iconified. This was not true in all Tk's
      before 8.3.0. I refere this as an innocent "bug" since it had never
      caused any problem to me in previous Tk (8.2 or lower). However, it does
      cause a problem in Tk8.3.0, i.e., blocking the normal script evaluation
      when error occurs and the Tk's main window is either hidden or
      iconified.

  ReproducibleScript:
  If the Tk's main window is either hidden or iconified, "bgerror" will hang up.

  ObservedBehavior:
  Invoking of bgerror should not be blocked in any cases during script evaluation, but in Tk8.3.0, it does if the main window is either hidden or iconfied.

  DesiredBehavior:
  bgerror should display the error any time it is invoked.

  Patch:
  proc bgerror err {
      global errorInfo tcl_platform

      # reset the dialog window so that it would not be blocked 
      after idle wm transient .bgerrorDialog "{}"

      # save errorInfo which would be erased in the catch below otherwise.
      set info $errorInfo ;

      # For backward compatibility :
      # Let's try to execute "tkerror" (using catch {tkerror ...} 
      # instead of searching it with info procs so the application gets
      # a chance to auto load it using its favorite "unknown" mecanism.
      # (we do the default dialog only if we get a TCL_ERROR (=1) return
      #  code from the tkerror trial, other ret codes are passed back
      #  to our caller (tcl background error handler) so the called "tkerror"
      #  can still use  return -code break, to skip remaining messages
      #  in the error queue for instance)

      set ret [catch {tkerror $err} msg];
      if {$ret != 1} {return -code $ret $msg}

      # Ok the application's tkerror either failed or was not found
      # we use the default dialog then :
      if {$tcl_platform(platform) == "macintosh"} {
  set ok Ok
      } else {
  set ok OK
      }
      set button [tk_dialog .bgerrorDialog "Error in Tcl Script"  "Error: $err" error 0 $ok "Skip Messages" "Stack Trace"]
      if {$button == 0} {
  return
      } elseif {$button == 1} {
  return -code break
      }

      set w .bgerrorTrace
      catch {destroy $w}
      toplevel $w -class ErrorTrace
      wm minsize $w 1 1
      wm title $w "Stack Trace for Error"
      wm iconname $w "Stack Trace"
      button $w.ok -text OK -command "destroy $w" -default active
      if {![string compare $tcl_platform(platform) "macintosh"]} {
        text $w.text -relief flat -bd 2 -highlightthickness 0 -setgrid true  -yscrollcommand "$w.scroll set" -width 60 -height 20
      } else {
        text $w.text -relief sunken -bd 2 -yscrollcommand "$w.scroll set"  -setgrid true -width 60 -height 20
      }
      scrollbar $w.scroll -relief sunken -command "$w.text yview"
      pack $w.ok -side bottom -padx 3m -pady 2m
      pack $w.scroll -side right -fill y
      pack $w.text -side left -expand yes -fill both
      $w.text insert 0.0 $info
      $w.text mark set insert 0.0

      bind $w <Return> "destroy $w"
      bind $w.text <Return> "destroy $w; break"

      # Center the window on the screen.

      wm withdraw $w
      update idletasks
      set x [expr {[winfo screenwidth $w]/2 - [winfo reqwidth $w]/2  - [winfo vrootx [winfo parent $w]]}]
      set y [expr {[winfo screenheight $w]/2 - [winfo reqheight $w]/2  - [winfo vrooty [winfo parent $w]]}]
      wm geom $w +$x+$y
      wm deiconify $w

      # Be sure to release any grabs that might be present on the
      # screen, since they could make it impossible for the user
      # to interact with the stack trace.

      if {[string compare [grab current .] ""]} {
  grab release [grab current .]
      }
  }

  PatchFiles:
  bgerror.tcl



  Yes, this was definately an unintended side effect of fixing the behavior of transient windows on Windows.

  I applied your patch, with a slight modification:  rather than blindly undoing the transient bit of the .bgerrorDialog, I do the following:

      after idle {
  if { ![winfo viewable .bgerrorDialog] } {
      wm transient .bgerrorDialog {}
  }
      }

  This way, if "." _is_ viewable, we will retain the transient status of the dialog, which I think is beneficial.  If "." is not viewable, then the dialog will have the transient bit unset, so the dialog will be shown.

  This fix will go out with 8.3.1.

  - eric

  -- 04/10/2000 ericm


tkt_uuid: 220524ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: MacOS 68k -> Bus Error
comment:
  OriginalBugID: 2061 Bug
  Version: 8.0.4
  SubmitDate: '1999-05-13'
  LastModified: '1999-10-22'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: 7.5.5
  Machine: Power PC
  FixedDate: '1999-10-22'
  FixedInVersion: 8.2.1


  Name: Kyle Daniels

  Extensions: standard set from Tcl/Tk install

  Comments:
  SpecTcl: I would also like to ask y'all to provide a 68k version of
      SpecTcl. I can't afford TclPro right now, else I'd gladly make the
      purchase.

  ObservedBehavior:
  Wish app and D&D Tklets crashes the system w/ mssg = "Bus Error". This
      happens when Wish or D&D Tklets is launched once, successfully executes,
      terminates, then launched for a second time.



  The user should pick up new binaries for the mac from
  ftp://ftp.scriptics.com/pub/tcl/mac/ as several Mac fixes
  have occured since 8.0.4. 
  -- 10/22/1999 hobbs


tkt_uuid: 3609872fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 69. Events
priority: 7 High
foundin: None
resolution: None
title: Wrong handling of button events 8.5.13
comment:
  tkWinButton.c handles BN_CLICKED message. BN_SLIDER == WM_NULL and some browser (namely chromium) send a WM_NULL message periodically to check if the plugin is still alive. When using Tk via the Tcl plugin, this causes all buttons to fire regularly in a one-second interval. I have added an additional check in the event handler which avoids treatment of WM_NULL with 0 wParam/lParam as a button event in tkWinButton.c:ButtonProc. Without this modification, buttons are unusable in the Tcl/Tk plugin in some browsers since the command fire regularly without user interaction.

      case BN_CLICKED:
        /*
         * OOPS: chromium fires WM_NULL regularly to ping if plugin is still
         * alive. When using an external window (i.e. via th etcl plugin), this
         * causes all buttons to fire once a second, so we need to make sure
         * that we are not dealing with the chromium life check.
         */
        if(!(message == WM_NULL && wParam == 0 && lParam == 0)) {
    int code;
    Tcl_Interp *interp = butPtr->info.interp;
    
    if (butPtr->info.state != STATE_DISABLED) {
        Tcl_Preserve((ClientData)interp);
        code = TkInvokeButton((TkButton*)butPtr);
        if (code != TCL_OK && code != TCL_CONTINUE
    && code != TCL_BREAK) {
    Tcl_AddErrorInfo(interp, "\n    (button invoke)");
    Tcl_BackgroundError(interp);
        }
        Tcl_Release((ClientData)interp);
    }
    Tcl_ServiceAll();
    return 0;
        }


tkt_uuid: 220670ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Windows font bug in tk8.2
comment:
  OriginalBugID: 4108 Bug
  Version: 8.2
  SubmitDate: '2000-01-31'
  LastModified: '2000-02-01'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  FixedDate: '2000-02-01'
  FixedInVersion: 8.3


  Name:
  Jeremy Birch

  ReproducibleScript:
  The Windows version of Tk8.2 suffers an access violation when handling
  fonts with long names
  ie the name of the font is greater than 32 characters (my Python application
  that sits on top of Tk wanted
  to use "*lucidatypewriter-medium-*-*-*-*-140*", for instance). The LOGFONT
  datastructure only has a
  32 byte area for putting the font name into, and the GetScreenFont function
  in tkWinFont.c quite happily
  stomps over the back end of the structure, thus causing a failure later on.
  Obviously truncating the font name may
  risk getting the wrong font, but this is generally better than a SEGV!

  I have changed lines 1961-1965 to be as follows:
  count=31; /*max number of real chars allowed here*/
  while (*src != '\0') {
      *dst++ = *src++;
      if(--count==0) break;
  }

  Hope this is the best way.

  DesiredBehavior:
  ok


  Fixed to use a more general:

      /*
       * We can only store up to LF_FACESIZE characters
       */
      if (Tcl_DStringLength(&ds) >= LF_FACESIZE) {
          Tcl_DStringSetLength(&ds, LF_FACESIZE);
      }

  which goes before the platform check, to operate on Win9* as well. 
  -- 02/01/2000 hobbs


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: 1474465fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 55. [focus]
priority: 2
foundin: obsolete: 8.5a4
resolution: None
title: TkAqua focus test failures
comment:
  The following tests fail (and given the serious 'lost focus' bug in 
  TkAqua, it is plausible that something here is important):

  focus.test

  ==== focus-1.1 Tk_FocusCmd procedure FAILED
  ==== Contents of test case:

      focusClear
      focus

  ---- Result was:
  .t
  ---- Result should have been (exact matching):

  ==== focus-1.1 FAILED


  ==== focus-1.3 Tk_FocusCmd procedure FAILED
  ==== Contents of test case:

      focusClear
      focus .t.b3
      focus

  ---- Result was:
  .t.b3
  ---- Result should have been (exact matching):

  ==== focus-1.3 FAILED


  ==== focus-1.12 Tk_FocusCmd procedure, -displayof option FAILED
  ==== Contents of test case:

      focusClear
      focus .t
      focus -displayof .t.b3

  ---- Result was:
  .t
  ---- Result should have been (exact matching):

  ==== focus-1.12 FAILED


  ==== focus-1.19 Tk_FocusCmd procedure, -force option FAILED
  ==== Contents of test case:

      focusClear
      focus .t.b1
      set x  [list [focus]]
      focus -force .t.b1
      lappend x [focus]

  ---- Result was:
  .t.b1 .t.b1
  ---- Result should have been (exact matching):
  {} .t.b1
  ==== focus-1.19 FAILED


tkt_uuid: 3315643fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: allow to disable hidden files in Unix/Linux
comment:
  Tweaking the file tkfbox.tcl allows to make displaying hidden files in Linux/Unix optional by changing lines:
    set ::tk::dialog::file::showHiddenVar 0
    set ::tk::dialog::file::showHiddenBtn 1
  It should be set like this for Linux/Unix by default. It would give much better experience to the user.


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: 220174ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_Release API
comment:
  OriginalBugID: 1883 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-28'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: kenj
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-28'




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


tkt_uuid: 480158ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 55. [focus]
priority: 5 Medium
foundin: final: 8.2.3
resolution: None
title: initial focus fails in child interp
comment:
  I was trying to create a child interpreter which could
  create a set of widgets and embed that within a frame
  in the main interpreter.  Most widgets work fine but
  anything that depends on getting focus won't work
  reliably on different platforms or with different
  window managers.

  To reproduce, create an interp within the main
  interpreter and create a Tk text widget within the
  child.  It is difficult to get the text widget to take
  the focus by clicking.  This means that the "I" cursor
  does not get inserted and the black line indicating
  that the text area is ready for editing does not
  appear.  I played around with varying configurations
  including packing and depth within the window hierarchy
  with different results.  

  The following example always failed for me on Windows
  2000 but seemed to work more often on Solaris using
  CDE.  

  interp create child
  toplevel .t
  frame .t.f -container 1
  pack .t.f -fill both -expand yes
  interp eval child "lappend argv -use [winfo id .t.f]"
  interp eval child {
      load {} Tk
      text .text
      pack .text -fill both -expand yes
  }


tkt_uuid: 1687486fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 57. [option]
priority: 5 Medium
foundin: None
resolution: None
title: tk is not robust in the face of bad xrdb settings
comment:
  % echo "*background: stupid-broken-desktop-setting" | xrdb -merge
  % wish
  Application initialization failed: this isn't a Tk applicationunknown color name "stupid-broken-desktop-setting"

  Apparently many linux desktop systems try to set xrdb entries to make old applications look a little more like other desktop applications (details on this are thin, and of course vary between different desktops).  Unfortunately, some of the time this makes all wish applications break.

  While the true blame lies at the feet of these desktop environments, it would be nice if Tk was robust in the face of this type of problem.


tkt_uuid: 3107390fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: None
title: Tk 8.5.9 fails to build "wish" on FreeBSD 8.1
comment:
  Tk 8.5.9 and possibly others, build "libtk85.so.1", and then try to link "wish" against it using "-ltk85".  This fails.  Copying "libtk85.so.1" to "libtk85.so" after "gmake" fails and re-running "gmake" yields a working "wish"

  Build log attached


tkt_uuid: 1968592fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Works For Me
title: Double-clicking title bar doesn't minimize wish
comment:
  Double-clicking the titlebar should minimize apps on Mac OS X.

  In Tcl 8.5, double-clicking the Wish's titlebar does nothing.
  Note that this used to work a while back. For example in tcl 8.4.13.

  I don't know of any decent workaround.


tkt_uuid: 1771594fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: icursor @x,y fails for negative scrollregions
comment:
  The normal method of locating where a button click  happens on a canvas TEXT item would be:

  set cx [.c canvasx $x]
  set cy [.c canvasy $y]

  set id [.c find closest $cx $cy]
  .c focus $id
  .c icursor $id @$cx,$cy

  If however the scrollregion is configured as:
  .c configure -scrollregion {0 -100 600 800}

  Then to position the ibeam in the text widget would  require:

  .c icursor $id @$cx,[expr {$cy+100}]

  That is: If the x1 or y1 coordinate is negative the indexing is wrong by that ammount.

  This bug may affect all canvas items as each item type has its own index procedure.

  Verified on tk 8.4 and 8.5a6


tkt_uuid: 3279221fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: None
title: Popup menu disappears immediately
comment:
  Consider the following code:
    pack [label .l -text label]
    menu .m
    .m add command -label foo
    bind .l <3> {after 500; tk_popup .m %X %Y}
  Now, when right-clicking on the label, the popup menu appears but disappears immediately. The "after 500" is there to simulate some work that needs to be done before the menu can be drawn.
  Investigation shows that the menu disappears when the mouse button is released before the menu is drawn. This is caused by the fact that, even though the menu is not yet drawn, the <ButtonRelease> event is directed to it, and it comes before the <Enter> event which sets the Priv(window) variable in menu.tcl.
  I would propose to set Priv(window) also when the popup is drawn. This seems correct since, when drawing a popup menu, you at least want it to stay visible initially, event when the mouse cursor is not over it (note that this behavior is also consistent with Windows). See the attached patch, which solves this issue.


tkt_uuid: 1030541fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.4.4
resolution: Fixed
title: $imageName configure fails with pure list.
comment:
  If I attempt to switch frames on an animated GIF
  with

      $imageName configure -format [list GIF -index $index]

  it appears to revert to frame 0; [$imageName cget -format]
  returns the empty string.

  On the other hand

      $imageName configure -format "GIF -index $index"

  works as expected.

  Is something reaching directly into the string rep that
  isn't there, rather than doing Tcl_GetStringFromObj?


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

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


tkt_uuid: 220138ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: tk_textPaste
comment:
  OriginalBugID: 1445 Bug
  Version: 8.0p2
  SubmitDate: '1999-03-04'
  LastModified: '1999-09-18'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux-SuSE
  Machine: Other
  ClosedDate: '1999-09-18'


  Name:

  Joe Acosta


  ReproducibleScript:

  in the tk_textPaste function there is some code for unix that prevents pasting over a aselection.


  ObservedBehavior:

  If I create a text widget, and I I select some text and copy it using tk_textCopy, then I select some more text to paste over and then paste the original copied text using tk_textPaste under UNIX,  the pasted text does not overwrite the selected text.


  DesiredBehavior:

  there should not be a line in the tk_textPaste function of text.tcl that says

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




  That is there to better follow "Unix style", where the sense of a
  clipboard like on Windows is foreign.  In general on Unix, a widget
  owns the selection, and whatever is selected is what would be
  exported. 
  -- 09/18/1999 hobbs


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

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

  Changes have been made to TkWinDialog.c


tkt_uuid: 3594478fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: HAVE_VSSYM32_H not known in nmake build
comment:
  The define to choose between tmschema.h and vssym32.h in ttkWinXPTheme.c is not working when building with nmake. HAVE_VSSYM32_H is set from the configure script, not from makefile.vc.

  A solution would be to select on compiler version:

  #if defined(HAVE_VSSYM32_H) || _MSC_VER > 1500
  #   include <vssym32.h>
  #else
  #   include <tmschema.h>
  #endif


tkt_uuid: 573681ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: tkConfig.sh.in substitution error
comment:
  On my HP-UX 11.00 system the configure script for tk
  results in a tkConfig.sh file that contains the
  following line.

  TK_XINCLUDES='# no special path needed'

  I believe this entry should be

  TK_XINCLUDES=''

  I down loaded tk from
  ftp://ftp.tcl.tk/pub/tcl/nightly-cvs/


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: 3609871fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 74. Application Embedding
priority: 7 High
foundin: None
resolution: None
title: Tk 8.5.13 shall not complain about non-container widget
comment:
  Under Windows, Tk complains when using an external widget (via -use) and raises a dialog to allow the user to use/abandon the usage. This may be fine for the general case, but it is useless when Tk is used via th eTcl plugin. I am currently working on a massive update of the tcl plugin using TclTk 8.5.13+ in latest firefix/chromium/... browsers and this dialog is annoying. Here is a patch to fix the behaviour in win/tkWinEmbed.c:TkpUseWindow that avoids to open the dialog when Tk is run inside the plugin. The test is simple but works fine. 

      if (id == PTR2INT(hwnd)) {
  if (!SendMessage(hwnd, TK_INFO, TK_CONTAINER_ISAVAILABLE, 0)) {
          Tcl_AppendResult(interp, "The container is already in use", NULL);
      return TCL_ERROR;
  }
      } else if (id == -PTR2INT(hwnd)) {
  Tcl_AppendResult(interp, "the window to use is not a Tk container",
  NULL);
  return TCL_ERROR;
      } else {
  /* wke: perform check only when not in plugin! */
  if(!Tcl_GetVar2(interp,"plugin","patchLevel",TCL_GLOBAL_ONLY)) {
      /*
       * Proceed if the user decide to do so because it can be a legacy
       * container application. However we may have to return a TCL_ERROR in
       * order to avoid bug 1096074 in future.
       */
      
      char msg[256];
      
      sprintf(msg, "Unable to get information of window \"%.80s\".  Attach to this\nwindow may have unpredictable results if it is not a valid container.\n\nPress Ok to proceed or Cancel to abort attaching.", string);
      if (IDCANCEL == MessageBox(hwnd, msg, "Tk Warning",
         MB_OKCANCEL | MB_ICONWARNING)) {
  Tcl_SetResult(interp, "Operation has been canceled", TCL_STATIC);
  return TCL_ERROR;
      }
  }
      }


tkt_uuid: 1123042fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 42. Photo Image|GIF
priority: 7 High
foundin: obsolete: 8.5.0
resolution: None
title: Images are blank via Remote Desktop
comment:
  On Windows boxes when the Remote Desktop Client 
  application is used with 256 colors, images such as 
  those in the TK Demo "Image Demonstration #1" script 
  do not appear. 
  Closing the Image Demonstration #1 toplevel causes 
  a "Fatal Error in Wish" The message text is "Tried to 
  free a color which isn't allocated".
  The wish application was running on the server with a 
  color depth >= 16 bit
  This may be followed by another fatal error:
  "Tk_FreeGC received unknown gc argument"


tkt_uuid: 219905ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: wm protocol does not support WM_TAKE_FOCUS or WM_SAVE_YOURSELF on Windows
comment:
  OriginalBugID: 789 RFE
  Version: 8.0.4
  SubmitDate: '1998-11-04'
  LastModified: '2000-05-22'
  Severity: MED
  Status: Closed
  Submitter: stanton
  ChangedBy: hobbs
  RelatedBugIDs: 1644
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '2000-05-22'


  These protocols are supported under X, but not Windows.  They have natural mappings onto Windows events, but Tk doesn't forward the information.



  We have to double check what these are supposed to do and find out what the appropriate mapping is for windows.

  - eric

  -- 04/03/2000 ericm


tkt_uuid: 418664ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Fixed
title: grid config rejects initial "x" and "^"
comment:
  According to grid(n):

    grid configure slave ?slave ...? ?options?
      The arguments consist of the names of one or more
      slave windows followed by pairs of arguments that
      specify how to manage the slaves.  The characters
      -, x and ^, can be specified instead of a window
      name to alter the default location of a slave, as
      described in the ``RELATIVE  PLACEMENT'' section,
      below.

  However:

      % grid configure x [label .l]
      bad argument "x": must be name of window

  Furthermore this is a bizarre inconsistency with
  the "shortcut" form of [grid configure]:

      % grid x [label .l]
      # No error!

  I attach a patch that corrects the bug and clarifies
  the documentation.


tkt_uuid: 220516ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 43. Photo Image|PPM
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: Colour errors writing ppm format images
comment:
  OriginalBugID: 1963 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-30'
  LastModified: '2000-01-05'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT and 98
  Machine: X86
  FixedDate: '2000-01-05'
  FixedInVersion: 8.3b1


  Name:
  Bernard Tiddeman

  ReproducibleScript:
  from the Tcl prompt on windows NT or 98:
      image create photo img
      label .l -image img
      img read logoLarge.gif
      pack .l
      img write logoLarge.ppm
      img read logoLarge.ppm

  ObservedBehavior:
  Colours of image have changed, probably from RGB to GBR. 
      In 8.0.4 the alignment of rows were out, probaply due to not opening the
      output file in binary mode. 
      This bug looks like an additional character or two have been output.

  DesiredBehavior:
  image colours should not change.



  Just tested this in 8.3b1 and it works as expected.  This was
  likely fixed earlier (somewhere in 8.1). 
  -- 01/05/2000 hobbs


