# ticket

tkt_uuid: 3160703fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Add unicode support for tk_chooseDirectory on Windows
comment:
  tk_chooseDirectory does not handle unicode directory names properly on Windows - for example on a Windows box this fails:
  % file mkdir c:/\u2345
  % tk_chooseDirectory -initialdir C:/\u2345 ; # this goes to "My Computer" while "C:/" works

  When choosing directory with non-ansi chars - the following is returned:
  C:/?

  Attached is a sample patch (ported from 8.5a4 patch BitRock used) so it might miss some features added in 8.5 and 8.6 development.

  This can be reimplemented and/or #ifdef-ed to properly support Windows CE, if needed.


tkt_uuid: 873655ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: None
title: Missing event when posting cascade menus
comment:
  Here is an example of the problem found under Linux:

  button .b
  pack .b
  .b configure -activebackground red
  menu .m
  menu .m.c
  .m add cascade -menu ".m.c" -label "cascade"
  .b configure -command {tk_popup .m [winfo rootx .b]
  [expr [winfo rooty .b] + [winfo height .b]]; .m
  activate 1; .m postcascade 1; tk_menuSetFocus .m}

  Use the mouse and click on the button and now move the
  mouse away.  You will see that the buttons state is not
  restored to normal and is left as active.  Without the
  postcascade as soon as you click on the button a
  <Leave> event is generated causing the button state to
  be restored to normal although the mouse is still
  within the widget.  Both of these behaviours appear to
  not be correct.

  I am unable to test the same conditions using
  menubutton as I can't see a way to post the cascade
  within the same event execution.  However menubutton is
  slightly different in that the <Leave> event is not
  generated until the mouse moves outside the widget.


tkt_uuid: 564575ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 3 Low
foundin: obsolete: 8.4b2
resolution: Fixed
title: Tk [console]/demos should be localized.
comment:
  Running wish8.4a4 from ActiveTcl 8.4.0.1 Beta 2 under 
  Win2k generates a funny language mix: the titles in the 
  menu are in english, whereas the commands
  are in german.

  E.g. in wish itself the many looks like this: 
  File: Ausführen..., Konsole unsichtbar machen, Clear 
  Console, Ende
  Edit: Ausschneiden, Kopieren, Einfügen, Löschen
  Help: Über...

  Running default applications in ActiveTcl generates funny 
  effects like this: 
  Running tkv.tcl from Demos/Img generates a window 
  called "Viewer" with english menus and english commands, 
  but running the same from lib/Img1.2 gives a window 
  called "Betrachter" and everything in the menus is in 
  german.

  My system language is set to english (US) and virtually all 
  software is in english. There are a few programs in german 
  and a few, which should be in english but bother me with 
  german nevertheless, one of them now being
  wish ;-)
  There is one indication of german in my system, and that's 
  the keyboard, which is a swiss-german keyboard. But that's 
  all.


tkt_uuid: 1622919fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: man text needs clarification
comment:
  Under the "search" subcommand, man text currently says: 
  "use the $ feature in regular expressions to match the end of a line."

  This should be changed to 
  "use the $ feature in regular expressions to match the end of a line, and ^ to match the beginning of a line."

  I've tested that it works, but the documentation should report that fact too.


tkt_uuid: 3566594fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.5.12
resolution: Fixed
title: ttkLabel does not reset clip mask
comment:
  We encountered strangely clipped text in ttk::buttons and treeviews under AIX and Solaris. On Linux and Windows the problem did not occur. Presumably the difference is related to the presence or absence of the HAVE_XFT macro.

  Inspection revealed that the function TextDraw in ttkLabel.c sets a clipping mask without resetting it at the end. The attached patch seems to fix the problem. 


tkt_uuid: 1936220fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 8
foundin: obsolete: 8.6a2
resolution: Fixed
title: tk_getOpenFile -multiple 1 fails on Linux
comment:
  Using version 8.5.2, built from sources, with --enable-64-bit. OpenSuse version 10.3

  tk_getOpenFile -multiple 1 
  does not work. After selecting a few files (whose names correctly appear in File names listbox), pressing Open button results in failure message (which appears to arise from lines 1663/1664 of tkfbox.tcl.


  No problems with this on Windows, using ActibeState binary.

  Ian Gay
  gay@sfu.ca


tkt_uuid: 485986ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: UTF8 in "Error in startup script"
comment:
  "Error in startup script" dialog
  can't display non-ASCII symbols on Windows.

  Test script (\u0410 - russian letter 'A'):
  ----------
  error \u0410
  ----------

  Result: window with following text:
  --------
  ??
    while executing 
  "error \u0410"
    (file "test.tcl" line 1)
  --------


tkt_uuid: 451777ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Objectify grid and pack.
comment:
  This patch objectifies the grid and pack commands.

  Parts of the patch for bug #418664 are included since there were
  similar changes in this patch and the other version was better.


tkt_uuid: 2080533fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: panedwindow widget crash issue
comment:
  Hi,

  We are having a crash on some Windows XP 32bit machines (using an nVidia graphics card). It looks like it is happening in the panedwindow widget when it is drawing the sash. The crash seems to be related to a large screen resolution (1920X1200).
  Is anyone aware of this issue, and/or have a fix for this?

  We are using Tk version 8.4.13.

  Your replies are appreciated.

  Thanks,
  Mona.


tkt_uuid: 220698ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: None
resolution: Fixed
title: bell resetting of screen savers
comment:
  OriginalBugID: 4279 RFE
  Version: 8.3
  SubmitDate: '2000-03-01'
  LastModified: '2000-05-17'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  Machine: Intel PIII running Solaris x86 v2.7
  FixedDate: '2000-05-17'
  FixedInVersion: 8.4a1


  Name: Richard Duncan

  Comments:
  The patch below adds this option without disturbing the other option,
      "-displayof"
      I apologize in advance for my unfamilarity of the way you usually parse
      arguments, but my 
      cludge below does work.

  DesiredBehavior:
  The Tk_BellObjCmd command has a call to reset the screen saver after ringing the bell. 
  For a biff application that rings a bell when mail arrives, it may be preferable to not reset the screen
  saver so that a blanked monitor will not come back alive at 3:00 in the morning.  So I added an option,
  called "-nice", to the arguments. So in tcl,
     % bell                  (no change in behaviour)
     % bell -nice         (rings the bell but does not call 
                                       XForceScreenSaver(Tk_Display(tkwin), ScreenSaverReset);

  Patch:
  *** tkCmds.c.oldWed Mar  1 11:24:26 2000
  --- tkCmds.c.newWed Mar  1 11:27:15 2000
  ***************
  *** 62,91 ****
        int objc;/* Number of arguments. */
        Tcl_Obj *CONST objv[];/* Argument objects. */
    {
  !     static char *bellOptions[] = {"-displayof", (char *) NULL};
        Tk_Window tkwin = (Tk_Window) clientData;
        char *displayName;
        int index;

  !     if ((objc != 1) && (objc != 3)) {
  ! Tcl_WrongNumArgs(interp, 1, objv, "?-displayof window?");
    return TCL_ERROR;
        }

  !     if (objc == 3) {
    if (Tcl_GetIndexFromObj(interp, objv[1], bellOptions, "option", 0,
    &index) != TCL_OK) {
        return TCL_ERROR;
    }
  ! displayName = Tcl_GetStringFromObj(objv[2], (int *) NULL);
  ! 
  ! tkwin = Tk_NameToWindow(interp, displayName, tkwin);
  ! if (tkwin == NULL) {
  !     return TCL_ERROR;
    }
        }
        XBell(Tk_Display(tkwin), 0);
  !     XForceScreenSaver(Tk_Display(tkwin), ScreenSaverReset);
        XFlush(Tk_Display(tkwin));
        return TCL_OK;
    }
  --- 62,117 ----
        int objc;/* Number of arguments. */
        Tcl_Obj *CONST objv[];/* Argument objects. */
    {
  ! 
  !     int i;
  !     int nice = 0;
  !     int set = 0;
  ! 
  !     static char *bellOptions[] = {"-displayof", "-nice", (char *) NULL};
        Tk_Window tkwin = (Tk_Window) clientData;
        char *displayName;
        int index;

  !     if ((objc < 1) || (objc > 4)) {
  ! Tcl_WrongNumArgs(interp, 1, objv, "?-displayof window? ?-nice?");
    return TCL_ERROR;
        }

  !     if (objc > 1) {
    if (Tcl_GetIndexFromObj(interp, objv[1], bellOptions, "option", 0,
    &index) != TCL_OK) {
        return TCL_ERROR;
    }
  ! for (i = 1; i < objc; i++) {
  !   if ((nice == 0) && (objv[i]->length > 2)
  !       && (strncmp(objv[i]->bytes,"-nice",
  !   (size_t)objv[i]->length) == 0)) {
  !              nice = 1;
  !           }
  !   else if ((objv[i]->length > 2) && (set == 0) 
  !    && (strncmp(objv[i]->bytes,"-displayof", 
  !        (size_t)objv[i]->length) == 0)) {
  !     if (i == (objc - 1)) {
  !       Tcl_WrongNumArgs(interp, 1, objv, "?-displayof window? ?-nice?");
  !       return TCL_ERROR;
  !     }
  !     set = 1;
  !     i++;
  !     displayName = Tcl_GetStringFromObj(objv[i], (int *) NULL);
  !     tkwin = Tk_NameToWindow(interp, displayName, tkwin);    
  !     
  !     if (tkwin == NULL) {
  !       return TCL_ERROR;
  !     }
  !   }
    }
        }
        XBell(Tk_Display(tkwin), 0);
  ! 
  !     if (nice == 0) {
  !       XForceScreenSaver(Tk_Display(tkwin), ScreenSaverReset);
  !     }
  ! 
        XFlush(Tk_Display(tkwin));
        return TCL_OK;
    }

  PatchFiles:
  tk8.3.0/generic/tkCmds.c



  Add option to 8.4a1 (not as patched, but close). 
  -- 05/17/2000 hobbs


tkt_uuid: 220403ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Man page for tk_messageBox uses deprecated 'case' command
comment:
  OriginalBugID: 901 Bug
  Version: 8.0.4
  SubmitDate: '1998-12-04'
  LastModified: '1999-04-09'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: surles
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-04-09'
  FixedInVersion: 8.1b3


  Name:
  Don Porter

  Comments:
  [auto_execok] hasn't returned 0 or 1 since Tcl 7.5, but the
      documentation
      has never caught up.
      
      Going back to Tcl 7.4, I can't find any evidence that [unknown] used the
      global variable 'unknown_active'.  That must be lost in the mists of
      history.  [unknown] uses the global variable 'unknown_pending'.
      
      This patch should be applied to the 8.0.x branch as well.

  Patch:
  Index: library.n
  ===================================================================
  RCS file: /cvsroot/tcl/doc/library.n,v
  retrieving revision 1.1.2.2
  diff -c -r1.1.2.2 library.n
  *** library.n   1998/11/11 04:08:14     1.1.2.2
  --- library.n   1999/04/06 22:47:33
  ***************
  *** 60,70 ****
    The following procedures are provided in the Tcl library:
    .TP
    \fBauto_execok \fIcmd\fR
  ! Determines whether there is an executable file by the name \fIcmd\fR.
    This command examines the directories in the current search path
  ! (given by the PATH environment variable) to see if there is an
  ! executable file named \fIcmd\fR in any of those directories.
  ! If so, it returns 1;  if not it returns 0.  \fBAuto_exec\fR
    remembers information about previous searches in an array
    named \fBauto_execs\fR;  this avoids the path search in
    future calls for the same \fIcmd\fR.  The command \fBauto_reset\fR
  --- 60,76 ----
    The following procedures are provided in the Tcl library:
    .TP
    \fBauto_execok \fIcmd\fR
  ! Determines whether there is an executable file or shell builtin
  ! by the name \fIcmd\fR.
  ! If so, it returns a list of arguments to be passed to \fBexec\fR 
  ! to execute the executable file or shell builtin named by \fIcmd\fR.
  ! If not, it returns an empty string.  
    This command examines the directories in the current search path
  ! (given by the PATH environment variable) in its search for an
  ! executable file named \fIcmd\fR.  On Windows platforms, the search
  ! is expanded with the same directories and file extensions as used
  ! by \fBexec\fR.
  ! \fBAuto_exec\fR
    remembers information about previous searches in an array
    named \fBauto_execs\fR;  this avoids the path search in
    future calls for the same \fIcmd\fR.  The command \fBauto_reset\fR
  ***************
  *** 276,283 ****
    Unix, words are comprised of numbers, letters or underscores.
    .VE
    .TP
  ! \fBunknown_active\fR
  ! This variable is set by \fBunknown\fR to indicate that it is active.
    It is used to detect errors where \fBunknown\fR recurses on itself
    infinitely.
    The variable is unset before \fBunknown\fR returns.
  --- 282,290 ----
    Unix, words are comprised of numbers, letters or underscores.
    .VE
    .TP
  ! \fBunknown_pending\fR
  ! Used by \fBunknown\fR to record the command(s) for which it is
  ! searching.
    It is used to detect errors where \fBunknown\fR recurses on itself
    infinitely.
    The variable is unset before \fBunknown\fR returns.

  PatchFiles:
  library.n



  04/09/1999 14:03 - surles - Updated to use switch.


tkt_uuid: 220529ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: Use of deprecated functions in tkGrid.c
comment:
  OriginalBugID: 2080 Bug
  Version: 8.1
  SubmitDate: '1999-05-17'
  LastModified: '1999-06-30'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: redman
  OS: Linux
  OSVersion: 4.2
  Machine: Other
  FixedDate: '1999-06-30'
  FixedInVersion: 8.2b1


  Name:

  Jan Nijtmans



  Comments:

  I checked all of Tk for any use of this group of deprecated functions

      and symbols. tkGrid.c was the only one reported.



  ObservedBehavior:

  In tkGrid.c the functions Tk_CancelIdleCall() and Tk_EventuallyFree()

      are used, which are deprecated. Lucky enough, tk.h contains macros

      which do the conversion, still it is bad style.



  Patch:

  *** generic/tkGrid.c.origThu Apr 29 21:37:52 1999

  --- generic/tkGrid.cSat May 15 18:26:16 1999

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

  *** 435,441 ****

        slavePtr->iPadX = slavePtr->iPadY = 0;

        slavePtr->doubleBw = 2*Tk_Changes(tkwin)->border_width;

        if (slavePtr->flags & REQUESTED_RELAYOUT) {

  ! Tk_CancelIdleCall(ArrangeGrid, (ClientData) slavePtr);

        }

        slavePtr->flags = 0;

        slavePtr->sticky = 0;

  --- 435,441 ----

        slavePtr->iPadX = slavePtr->iPadY = 0;

        slavePtr->doubleBw = 2*Tk_Changes(tkwin)->border_width;

        if (slavePtr->flags & REQUESTED_RELAYOUT) {

  ! Tcl_CancelIdleCall(ArrangeGrid, (ClientData) slavePtr);

        }

        slavePtr->flags = 0;

        slavePtr->sticky = 0;

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

  *** 522,528 ****

     */

    

    while (masterPtr->flags & REQUESTED_RELAYOUT) {

  !     Tk_CancelIdleCall(ArrangeGrid, (ClientData) masterPtr);

        ArrangeGrid ((ClientData) masterPtr);

    }

    SetGridSize(masterPtr);

  --- 522,528 ----

     */

    

    while (masterPtr->flags & REQUESTED_RELAYOUT) {

  !     Tcl_CancelIdleCall(ArrangeGrid, (ClientData) masterPtr);

        ArrangeGrid ((ClientData) masterPtr);

    }

    SetGridSize(masterPtr);

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

  *** 2007,2013 ****

     *

     * DestroyGrid --

     *

  !  *This procedure is invoked by Tk_EventuallyFree or Tcl_Release

     *to clean up the internal structure of a grid at a safe time

     *(when no-one is using it anymore).   Cleaning up the grid involves

     *freeing the main structure for all windows. and the master structure

  --- 2007,2013 ----

     *

     * DestroyGrid --

     *

  !  *This procedure is invoked by Tcl_EventuallyFree or Tcl_Release

     *to clean up the internal structure of a grid at a safe time

     *(when no-one is using it anymore).   Cleaning up the grid involves

     *freeing the main structure for all windows. and the master structure

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

  *** 2097,2106 ****

    Tcl_DeleteHashEntry(Tcl_FindHashEntry(&dispPtr->gridHashTable,

    (char *) gridPtr->tkwin));

    if (gridPtr->flags & REQUESTED_RELAYOUT) {

  !     Tk_CancelIdleCall(ArrangeGrid, (ClientData) gridPtr);

    }

    gridPtr->tkwin = NULL;

  ! Tk_EventuallyFree((ClientData) gridPtr, DestroyGrid);

        } else if (eventPtr->type == MapNotify) {

    if (!(gridPtr->flags & REQUESTED_RELAYOUT)) {

        gridPtr->flags |= REQUESTED_RELAYOUT;

  --- 2097,2106 ----

    Tcl_DeleteHashEntry(Tcl_FindHashEntry(&dispPtr->gridHashTable,

    (char *) gridPtr->tkwin));

    if (gridPtr->flags & REQUESTED_RELAYOUT) {

  !     Tcl_CancelIdleCall(ArrangeGrid, (ClientData) gridPtr);

    }

    gridPtr->tkwin = NULL;

  ! Tcl_EventuallyFree((ClientData) gridPtr, DestroyGrid);

        } else if (eventPtr->type == MapNotify) {

    if (!(gridPtr->flags & REQUESTED_RELAYOUT)) {

        gridPtr->flags |= REQUESTED_RELAYOUT;



  PatchFiles:

  tkGrid.c





  Applied the patch.
   
  -- 06/30/1999 redman


tkt_uuid: 1538201fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Wont Fix
title: mouse over "balloon" crash when selecting files
comment:
  On some Windows XP installations (it happened on 5 of
  the 15 computers I tested), tk will crash completely if
  you do the following:
  1.) Open a file dialog
  2.) Mouse over a file until the "balloon" pops up with
  file information
  3.) Select that file and close the file dialog
  4.) Open a file dialog (again)
  5.) Mouse over a file until the "balloon" pops up with
  file information (again)

  At this point Tk will suddenly disappear completely. 
  No Windows XP message will appear saying the program
  has crashed.  It simply exits completely.


tkt_uuid: 2902814fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: wm iconphoto broken in 8.5.8 64 bit linux
comment:
  The wm iconphoto command no longer has any effect with Tk 8.5.8. It works fine with Tk 8.5.7 (both 64-bit builds). It also appears to work with a 8.5.8 32-bit build (at least it does with the 32-bit 8.5.8 ActiveState basekit)

  Tested on OpenSuSE 11.2, kernel 2.6.31.5-0.1-default x86_64 with KDE 4.3.1.


tkt_uuid: 450504ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: unicode and 'insert -1l' causes garbage
comment:
  text .t
  pack .t
  # dispay a bullet-space-abc and space-space-def
  .t insert 1.0 "\u2022 abc\n  def\n"
  .t mark set insert 2.2
  .t mark set insert "insert -1l"
  # oops the bullet has been turned into three chars
  # of garbage!

  Generally speaking the text widget's calculation of +/-
   1 line is wrong, since it counts in bytes and not in 
  characters.  This means repeated 'mark set 
  insert "insert -1l"' does not maintain a constant 
  horizontal position.  However the above script shows 
  us this can really result in garbage when the widget 
  tries to place the insertion point in the middle of a 
  multi-byte unicode character!

  The first part of the bug seems to be acknowledged 
  here in tkTextIndex.c (line 724):

  /*
   * This doesn't work quite right if using a 
  proportional font or
   * UTF-8 characters with varying numbers of bytes.  
  The cursor will
   * bop around, keeping a constant number of bytes (not 
  characters)
   * from the left edge (but making sure not to split 
  any UTF-8
   * characters), regardless of the x-position the index 
  corresponds
   * to.  The proper way to do this is to get the x-
  position of the
   * index and then pick the character at the same x-
  position in the
   * new line.
   */

  TkTextMakeByteIndex(indexPtr->tree, lineIndex, 
  indexPtr->byteIndex,
  indexPtr);

  But, apparently the "making sure not to split any UTF-
  8 characters" bit is incorrect.

  (Note: Tcl/Tk 8.4a4 on Windows 2000, but the problem 
  is in the generic code).


tkt_uuid: 1569294fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 4
foundin: obsolete: 8.5a4
resolution: Fixed
title: Images in menus aren't displayed
comment:
  I'm using Tclkit 8.5a4 on Mac OS X 10.4.8. When I add
  images to my menu (under a menubutton), the images
  aren't displayed in the menu. Instead it says '(Image)'
  where the image should be.


tkt_uuid: 220049ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Duplicate
title: 'Dead key' + SHIFT entry/text widget problem
comment:
  OriginalBugID: 3695 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-29'
  LastModified: '1999-11-30'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3359
  OS: Windows 98
  ClosedDate: '1999-11-30'


  Name:
  Ludek Smid

  Extensions:
  BWidgets 1.2.1

  ReproducibleScript:
  When entering text into entry or text widget I cannot enter special national characters. These characters are entered using so called 'dead key' ie you have to press two keys to produce one character. This dead key can be user with modifier  (SHIFT) to produce different character. So if you press 'Dead key' and then E then this is not equal when you press SHIF+'Dead key' and then E. Tk does not recognize SHIFT modifier with 'Dead key' and produces the same character as without SHIFT modifier. Character set is cp1250. This bug prevents to use Tk with national character set.

  ObservedBehavior:
  See above.

  DesiredBehavior:
  See above.


tkt_uuid: 2433260fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Fixed
title: non-critical error in Tk_PhotoPutBlock
comment:
  With the use of valgrind I got the following message:

  ==1806== Source and destination overlap in memcpy(0x1D3FE6A8, 0x1D3FE6A8, 23104)
  ==1806==    at 0x1B907C17: memcpy (mac_replace_strmem.c:113)
  ==1806==    by 0x1BAF6C14: Tk_PhotoPutBlock (tkImgPhoto.c:4411)

  What I have done:
  I fetched an image block with Tk_PhotoGetImage(), did some modifications (recoloring), and used Tk_PhotoPutBlock(). The latter seems to be neccessary although only image pixels has been changed.

  I recommend to use function memmove() instead of function memcpy() inside Tk_PhotoPutBlock(). The documentation of Tk_PhotoPutBlock does not forbid the identity of block.pixelPtr.


tkt_uuid: 2026017fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5.3
resolution: None
title: Event state bit mask is platform dependent
comment:
  When binding on motion events and looking the event %s state value to determine what modifier keys (shift, ctrl, alt, ...) are held down I get different results when Alt is held down on different platforms.  On Mac X11 Tk 8.5.2 the state value is 512 w/o any modifier keys and 512 + 8 with the standard macbook pro keyboard alt key held down.  On Mac Aqua Tk 8.5.2 I get 1024 with no modifiers and 1024 + 16 with Alt key pressed.  On Windows XP Home 32-bit I get 256 w/o any modifier and 256 + 131072 with left alt key pressed (Dell keyboard).

  On these platforms and also linux, the shift and ctrl modifiers use the same mask in the state field (1 for shift, 4 for ctrl).

  When the alt key is held during a motion event the same bit in the event state should be set on all platforms.

  Several messages on the web describe this problem and the contortions others have gone through to work around this problem:

  http://wiki.tcl.tk/4238

  http://www.faqts.com/knowledge_base/view.phtml/aid/4281


tkt_uuid: 219904ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: crashes when top level popup windows are destroyed in a large TCL/TK/Tix program
comment:
  OriginalBugID: 720 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-13'
  LastModified: '1999-08-14'
  Severity: CRIT
  Status: Closed
  Submitter: admin
  ChangedBy: hobbs
  RelatedBugIDs: 716
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-14'


  ReproducibleScript:  This is the same problem I've reported before at http://www.scriptics.com/patches/tk8.0p2/tkUnixWm.c.txt

  I haven't been able to recreate the problem with small test programs yet.
  I did notice that it took up to 3 times of destroying a given popup for the 
  TCL/TK interpretter to crash during execution of a large (30k lines) program.

  This problem has been reported numerous times by other developers on the Tix mailing list.
  ObservedBehavior:  tixwish crashes with:

  X Error of failed request:  BadWindow (invalid Window parameter)
                                      Major opcode of failed request:  40 (X_TranslateCoords)
                                      Resource id in failed request:  0x1400246
                                      Serial number of failed request:  15956
                                      Current serial number in output stream:  15956

  DesiredBehavior:  Popup gets destroyed without any catastrophic side effects.

  CustomShell:  The patch is located at http://www.scriptics.com/patches/tk8.0p2/tkUnixWm.c.txt


tkt_uuid: 220026ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Duplicate
title: wm geometry Unix/Windows discrepancy
comment:
  OriginalBugID: 2856 Bug
  Version: 8.2
  SubmitDate: '1999-09-21'
  LastModified: '2000-01-06'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3687
  OS: Other
  Machine: NA
  FixedInVersion: 8.3b1
  ClosedDate: '2000-01-06'


  Name: Hume Smith

  ReproducibleScript:
  #!/usr/bin/env wish
      
      # this window appears in the upper-left corner on my Win'95 machine,
      # and (almost) centered in Unix
      # wish 8.2
      
      wm overrideredirect . 1
      wm withdraw .
      button .close -text Close -command exit
      pack .close
      update
      wm geometry . +[expr {[winfo screenwidth .]/2}]+[expr {[winfo
      screenheight .]/2}]
      wm deiconify .
      
      # eof

  ObservedBehavior:
  did different things on the two platforms

  DesiredBehavior:
  ought to do the same thing on both platforms

  Patch:


  PatchFiles:




  The patch for this was in 3687 and was applied for 8.3b1. 
  -- 01/06/2000 hobbs


tkt_uuid: 1088814fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 2
foundin: obsolete: 8.5a3
resolution: None
title: embed.test failures
comment:
  ==== 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 ID 0x7a9cc8 does not correspond to a
  valid Tk Window.}
  ---- Result should have been (exact matching):
  1 {window ".container" doesn't have -container option set}
  ==== embed-1.4 FAILED

  ---- embed-1.5 start

  ==== 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 ID 0x1533308 does not correspond to a
  valid Tk Window.}
  ---- Result should have been (exact matching):
  1 {window ".container" doesn't have -container option set}
  ==== embed-1.5 FAILED


tkt_uuid: 2917688fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.5.8
resolution: Fixed
title: ttk::notebook pages don't take focus when tab is selected
comment:
  On Mac OS X 10.5.8, using ActiveTcl 8.5.8, I see the following peculiar behavior; a script that shows the problem is attached.

  The script creates a ttk::notebook with two tabs; each tab contains a text widget.  Do the following to reproduce the error:

  * Start the script.
  * Click in the text widget on tab Text 1.  It will take focus.
  * Click on tab Text 2.
  * The text widget on tab Text 2 does not take the focus (which is OK).
  * Type "Hello, world".
  * Click on tab Text 1.
  * You'll see "Hello, world" in the text widget on tab Text 1.

  In other words, the first text widget is retaining the focus even after it's hidden, and is still responding to keyboard events.  Per Joe English, this isn't what's supposed to happen.


tkt_uuid: 488429ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: on mac, toplevel pulses in this script
comment:
  When I source this file in wish 8.0.5 on macOS 8.0 or 8.5,
  it builds 4 listboxes horzontally aligned and a vertical scrollbar.
  If I don't add '-padx 1' (1 or more) to the grid command of the
  scrollbar or
  one of its parent frames, my toplevel pulses at the point where
  the scrollbar touches it. I was told by das that this is also in current
  8.3.4 and 8.4.a4.


tkt_uuid: 706765ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 7 High
foundin: obsolete: 8.4.2
resolution: Fixed
title: -sliderrelief not honored
comment:
  the sliderelief option is always returned to the raised 
  appearance after being clicked regardless of the 
  prevsion configuration

  pack [scale -sliderrelief flat]

  observe the appearance of the slider before and after 
  clicking on the scale.


tkt_uuid: 1088805fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.5a3
resolution: None
title: Aqua: failed bind-* tests
comment:
  ==== bind-13.13 Tk_BindEvent procedure: invalid key
  detail FAILED
  ==== Contents of test case:

      setup
      bind .b.f <Key> "lappend x Key%K"
      bind .b.f <KeyRelease> "lappend x Release%K"
      set x {}
      event gen .b.f <Key> -keycode 0
      event gen .b.f <KeyRelease> -keycode 0
      set x

  ---- Result was:
  Keya Releasea
  ---- Result should have been (exact matching):
  Key?? Release??
  ==== bind-13.13 FAILED

  ==== bind-15.7 MatchPatterns procedure, ignoring type
  mismatches FAILED
  ==== Contents of test case:

      setup
      bind .b.f <Double-1> {set x 1}
      set x 0
      event gen .b.f <Button-1>
      event gen .b.f <Key-Shift_L>
      event gen .b.f <ButtonRelease-1>
      event gen .b.f <Button-1>
      event gen .b.f <ButtonRelease-1>
      set x

  ---- Result was:
  0
  ---- Result should have been (exact matching):
  1
  ==== bind-15.7 FAILED


tkt_uuid: 220413ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Tk 8.0.4 entry widget crashes on NT4.0/J service pack 3 or less
comment:
  OriginalBugID: 1006 Bug
  Version: 8.0.4
  SubmitDate: '1998-12-22'
  LastModified: '1999-02-03'
  Severity: CRIT
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Windows NT
  OSVersion: 4.00.1381 (Japanese)
  Machine: X86
  FixedDate: '1999-02-03'
  FixedInVersion: 8.0.5


  Name:

  Jim Inham


  Extensions:

  Tcl 8.0.4, Tk 8.0.4


  CustomShell:

  This is the plain Scriptics Binary version.


  ReproducibleScript:

  entry .e -font windows-message

  pack .e

  .e insert end "A really long string that will overflow the entry widget"


  ObservedBehavior:

  It crashes with an access violation


  DesiredBehavior:

  The text should be inserted in the widget.  It should not crash.


  Patch:

  *** tkWinFont.c.orig    Thu Dec 17 14:59:50 1998

  --- tkWinFont.c Thu Dec 17 15:10:20 1998

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

  *** 391,404 ****


          if (((flags & TK_PARTIAL_OK) && max < numChars && curX < maxLength)

                  || ((flags & TK_AT_LEAST_ONE) && max == 0 && numChars > 0)) {

              /*

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

               * quite fit.  Call the function again to include the

               * width of the extra character.

                 */


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

  !                        &size);

              curX = partials[max];

              ++max;


  --- 391,415 ----


          if (((flags & TK_PARTIAL_OK) && max < numChars && curX < maxLength)

                  || ((flags & TK_AT_LEAST_ONE) && max == 0 && numChars > 0)) {

  + 

  +           /*

  +            * MS BUG ALERT - We have to pass the bogus length, and

  +            * the dummyMax parameter, because without them the call crashes on

  +            * NT/J Service Pack 3 and less.  This is documented in the

  +            * Microsoft Knowledge Base.

  +            */

  +         

  +           int dummyMax;

  +           

              /*

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

               * quite fit.  Call the function again to include the

               * width of the extra character.

                 */


  !           GetTextExtentExPoint(hdc, source, max + 1, INT_MAX, &dummyMax,

  !                   partials, &size);

  ! 

              curX = partials[max];

              ++max;


  PatchFiles:

  tk8.0/win/tkWinFont.c




  According to MS, Service Pack 4 fixes this bug, but I have not tried it.  Many of our customers are not willing to upgrade to Service Pack 4, so the work-around is needed.

  This bug does not affect Tk8.1, because for some other reasons the 8.1 code does not use the GetTextExtentExPoint function in the equivalent place...


tkt_uuid: 3584830fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: ttk::entry fails with not-yet-set -textvariable
comment:
  package require Tk
  pack [entry .e -textvariable yourtext] -expand yes -fill x
  pack [button .b -command Doit -text "Press"]
  proc Doit {} {
    variable yourtext
    tk_messageBox -message "You pressed, text is $yourtext"
  }

  Runs as expected, but the same script with ttk (as shown in the 
  example):

  package require Tk
  pack [ttk::entry .e -textvariable yourtext] -expand yes -fill x
  pack [ttk::button .b -command Doit -text "Press"]
  proc Doit {} {
    variable yourtext
    tk_messageBox -message "You pressed, text is $yourtext"
  }

  Throws an error, if there is no text in the entry: 
  can't read "yourtext": no such variable
      while executing
  "tk_messageBox -message "You pressed, text is $yourtext""
      (procedure "Doit" line 3)
      invoked from within
  "Doit"
      invoked from within
  ".b invoke "
      invoked from within
  ".b instate !disabled { .b invoke } "
      invoked from within
  ".b instate pressed { .b state !pressed; .b instate !disabled { .b 
  invoke } } "
      (command bound to event)

  % info patchlevel
  8.5.11
  % parray tcl_platform
  tcl_platform(byteOrder)   = littleEndian
  tcl_platform(machine)     = x86_64
  tcl_platform(os)          = Linux
  ...


tkt_uuid: 220885ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Duplicate
title: Toplevel Sizing stops if a "placed" child is destroyed in the meantime
comment:
  OriginalBugID: 3865 Bug
  Version: 8.2.1
  SubmitDate: '1999-12-13'
  LastModified: '2000-01-03'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2607
  OS: Windows 2000
  OSVersion: 8.2.1, 8.0
  Machine: Pentium ||-350


  Name: Leo Schubert

  Comments:
  my guess: internally this could happen if a SetCapture call is  executed during the  sizing loop

  ReproducibleScript:
  #sizing bug under windows
  # this sample shows that a windows sizing eventloop will be broken
  # if a window is destroyed during sizing 
  catch {console show}
  frame .f -width 380 -height 250 -bg green
  pack .f -fill both -expand 1
  bind .f <Configure> { checksize } 

  message .f.m -text "try to enlarge the toplevel to the right with the mouse ,and make shure that \"Show window contents while dragging\" in ControlPanel->Display->Plus! or ControlPanel->Display->Effects is switched on."

  place .f.m -x 0 -y 0 -relheight 1.0 -width 350
  proc checksize { } {
    set w [winfo width .f]
    set wr [winfo reqwidth .f]
    puts stderr "width is $w,reqwidth=$wr"
    if {$w<400} {
        makebutton
    } else {
        destroybutton
    }
  }
  proc makebutton {} {
    if {![winfo exists .f.br]} {
       puts stderr "create"
       place [button .f.br -text ">" ] -anchor ne -relx 1.0 -y 0 -relheight 1.0
    }
  }
  proc destroybutton {} {
    if {[winfo exists .f.br]} {
       puts stderr "destroy"
       destroy .f.br
    }
  }
  wm geometry . ""

  ObservedBehavior:
  obtained Effect: you can't resize the window to a bigger size, which should be   possible    (the window which will be destroyed 
    during sizing is "placed" and  therefore no geometry propagation  to the master widget happens).
  This bug only appears if "Show window contents while dragging" is on in the control panel (otherwise the window won't destroyed during sizing)
  On Linux this bug doesn't appear

  DesiredBehavior:
  sizing should work like on the Linux platform


tkt_uuid: 220872ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Works For Me
title: focus, send, and unixEmbed test failures on Solaris 2.6
comment:
  OriginalBugID: 3353 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-23'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: jenn
  RelatedBugIDs: 2181
  OS: Solaris
  OSVersion: 2.6


  Name:
  Jim McMaster

  CustomShell:
  My primary tcl/tk application is exmh, which uses "send"  I would like to upgrade from the old version, for which I have no source, but am afraid I would crater exmh.

  ReproducibleScript:
  Compile under Solaris 2.6 with cc: WorkShop Compilers 4.2 30 Oct 1996 C
      4.2.  Run "make test"

  ObservedBehavior:
  The following tests fail:

      focus.test

      ==== focus-5.1 ChangeXFocus procedure, don't take focus unless have it
      FAILED
      ==== Contents of test case:

          focusSetup
          focus -force .t
          update
          set result [focus]
          send [dobg {tk appname}] {focus -force .; update}
          lappend result [focus]
          focus .t.b2
          update
          lappend result [focus]

      ---- Result was:
      .t .t {}
      ---- Result should have been:
      .t {} {}
      ==== focus-5.1 FAILED

      ==== focus-6.1 miscellaneous - embedded application in same process
      FAILED
      ==== Contents of test case:

          eval interp delete [interp slaves]
          catch {destroy .t}
          toplevel .t
          wm geometry .t +0+0
          frame .t.f1 -container 1
          frame .t.f2
          pack .t.f1 .t.f2
          entry .t.f2.e1 -bg red
          pack .t.f2.e1
          bind all <FocusIn> {lappend x "focus in %W %d"}
          bind all <FocusOut> {lappend x "focus out %W %d"}
          interp create child
          child eval "set argv {-use [winfo id .t.f1]}"
          load {} tk child
          child eval {
      entry .e1 -bg lightBlue
      pack .e1
      bind all <FocusIn> {lappend x "focus in %W %d"}
      bind all <FocusOut> {lappend x "focus out %W %d"}
      set x {}
          }

          # Claim the focus and wait long enough for it to really arrive.

          focus -force .t.f2.e1
          after 300 {set timer 1}
          vwait timer
          set x {}
          lappend x [focus] [child eval focus]

          # See if a "focus" command will move the focus to the embedded
          # application.

          child eval {focus .e1}
          after 300 {set timer 1}
          vwait timer
          lappend x |
          child eval {lappend x |}

          # Bring the focus back to the main application.

          focus .t.f2.e1
          after 300 {set timer 1}
          vwait timer
          set result [list $x [child eval {set x}]]
          interp delete child
          set result

      ---- Result was:
      {{} {} |} |
      ---- Result should have been:
      {.t.f2.e1 {} {focus out .t.f2.e1 NotifyNonlinear} {focus out .t.f2
      NotifyNonlinearVirtual} {focus in .t.f1 NotifyNonlinear} | {focus out
      .t.f1 NotifyNonlinear} {focus in .t.f2 NotifyNonlinearVirtual} {focus in
      .t.f2.e1 NotifyNonlinear}} {{focus in . NotifyVirtual} {focus in .e1
      NotifyAncestor} | {focus out .e1 NotifyAncestor} {focus out .
      NotifyVirtual}}
      ==== focus-6.1 FAILED

      send.test

      ==== send-8.1 Tk_SendCmd procedure, options FAILED
      ==== Contents of test case:

          setupbg
          set app [dobg {tk appname}]
          set a 66
          send -async $app [list send [tk appname] set a 77]
          set result $a
          after 200 set x 40
          tkwait variable x
          cleanupbg
          lappend result $a

      ---- Result was:
      66 66
      ---- Result should have been:
      66 77
      ==== send-8.1 FAILED

      unixEmbed.test

      ==== unixEmbed-5.2 EmbedFocusProc procedure, focusing on dead window
      FAILED
      ==== Contents of test case:

          foreach w [winfo child .] {
      catch {destroy $w}
          }
          frame .f1 -container 1 -width 200 -height 50
          pack .f1
          dobg "set w1 [winfo id .f1]"
          dobg {
      eval destroy [winfo child .]
      toplevel .t1 -use $w1
          }
          update
          dobg {
      after 200 {destroy .t1}
          }
          after 400
          focus -force .f1
          update

      ==== Test generated error:
      bad window path name ".f1"
      ---- Result should have been:

      ==== unixEmbed-5.2 FAILED

      Tests ended at Thu Oct 07 15:54:05 MDT 1999
      all.tcl:Total6549Passed6123Skipped422Failed4
      Sourced 84 Test Files.
      Files with failing tests: focus.test send.test unixEmbed.test
      Number of tests skipped for each constraint:
      2altDisplay
      2emptyTest
      44macOnly
      11macOrPc
      1nonPOrtable
      131nonPortable
      230pcOnly
      1userInteraction

  DesiredBehavior:
  All tests complete successfully


tkt_uuid: 422411ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Tab behaviour inconsistent
comment:
  Insertion of \t in a text widget has two different kinds of behaviour, depending on how the tab stops were set.

  a) With the default 8 characters per tab, the effect of inserting \t is to move the insertion point to the next tab stop to the right.

  b) If you set (with -tabs) other tab stops, the effect of the nth \t in a line is to attempt to position the insertion pont at the nth tab stop. If this is not possible (insertion point already to right of nth stop) then \t inserts a single space.

  The behaviour of tabs should be consistent, regardles of how tab stops were set. My personal preference would be for behaviour a), which I think is what most people would expect.

  Illustrative script file attached.


tkt_uuid: 1752151fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 6
foundin: obsolete: 8.4.14
resolution: Accepted
title: ::tk::mac::ShowPreferences documentation
comment:
  A documentation bug...

  Updated info on the consequences of ::tk::mac::ShowPreferences needs to be added to the Apple Menu section of the Menu manual page -- ie, that this command is now used instead of a menu item to handle the 'Preferences' entry in the Apple Menu on the Mac OS X platform.

  This is especially needed since this is apparently a new change in 8.4.14, won't appear in older manual pages, is bound to catch a lot of people out and cause many similar queries unless mentioned explicitly.

  See: http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/8f9880f795ce40a6/8d1671c3079d857b


tkt_uuid: 3005455fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: error with neo keyboard layout input
comment:
  It's not possible to enter left-side fourth level keys from the Neo layout (see http://neo-layout.org/) with X server/GNU Linux. Mod4+v/ü/p should give Backspace/Escape/Return respectively, but give control characters. Mod4+ö works (Tab), the rest does nothing.


tkt_uuid: 3002768fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: new test failures
comment:
  These ttk notebook tests just recently
  started failing for me:

  ==== notebook-5.1 Virtual events FAILED
  ==== Contents of test case:

      toplevel .t
      set ::events [list]
      bind .t <<NotebookTabChanged>> { lappend events changed %W }

      pack [set nb [ttk::notebook .t.nb]] -expand true -fill both; update
      $nb add [frame $nb.f1]
      $nb add [frame $nb.f2]
      $nb add [frame $nb.f3]

      $nb select $nb.f1
      update; set events

  ---- Result was:

  ---- Result should have been (exact matching):
  changed .t.nb
  ==== notebook-5.1 FAILED



  ==== notebook-5.2 Virtual events, continued FAILED
  ==== Contents of test case:

      set events [list]
      $nb select $nb.f3
      update ; set events

  ---- Result was:

  ---- Result should have been (exact matching):
  changed .t.nb
  ==== notebook-5.2 FAILED



  ==== notebook-5.4 Reenable tab FAILED
  ==== Contents of test case:

      set events [list]
      $nb tab $nb.f2 -state normal
      $nb select $nb.f2
      update
      list $events [$nb index current]

  ---- Result was:
  {} 1
  ---- Result should have been (exact matching):
  {changed .t.nb} 1
  ==== notebook-5.4 FAILED


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

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


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

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


tkt_uuid: 220399ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Missing keysyms on Windoze (Bug)
comment:
  OriginalBugID: 870 Bug
  Version: 8.0.3
  SubmitDate: '1998-11-25'
  LastModified: '2000-04-13'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: ericm
  RelatedBugIDs: 1160 947 2487
  OS: All
  FixedDate: '2000-04-13'
  FixedInVersion: 8.3.1


  From: "DUPERVAL, LAURENT" <laurent.duperval@bellsygma.com>
  Subject: Missing keysyms on Windoze (Bug)
  Date: Wed, 21 Oct 1998 13:26:39 -0400

  I tested keysyms on Linux and on WinNT with the following code:

  button .b
  bind .b <KeyPress> {.b configure -text "%K"}
  pack .b -fill x

  When running it on WinNT, pressing The right Alt, Shift and Control keys show Alt_L, Shift_L and Control_L while on Linux, it says _R. The Windows keys appear properly as Win_L and Win_R on WinNT but as Meta_L and Meta_R on Linux; I'm guessing this could be an Xserver issue since I don't have the latest and greatest on my machine (not sure about version #).  The menu key shows as "Menu" on Linux but "App" on WinNT.

  I didn't find anything to this effect in Dejanews. Looking in win/tkWinKey.c, it looks like the {Shift|Alt|Control}_R keys are undefined, but I dunno for what reason (not explained in source code). I'm guessing that Windows can't make a difference between left and right keys (which would be stoopid but not surprising) or that a conscious decision was made not to support this on Windoze (which is a bad decision IMHO). As for the
  Menu/App difference, I'm at a lost.



  The Linux problems are likely all due to key mapping.  They are
  unlikely to recognize the new Win* name, and use Meta* as a good
  replacement.

  The problem with *_L and *_R seems to be a Windows quirk or bug. 
  -- 10/21/1999 hobbs

  --

  The problem on Windows is that Windows only gives us an undifferentiated "Control is pressed" message -- it does not distinguish between left and right keys.  However, we can query this information explicitly ourselves, if we see that Control (or Shift, or Alt) is pressed.  I added the code to do this; the fix will go out with 8.3.1.

  - eric

  -- 04/13/2000 ericm


tkt_uuid: 220474ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Solution for known Stubs problem
comment:
  OriginalBugID: 1650 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-29'
  LastModified: '1999-04-05'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: redman
  OS: Other
  Machine: NA
  FixedDate: '1999-04-05'
  FixedInVersion: 8.1b3


  Name:
  Jan Nijtmans

  CVS:
  27 March 1999

  ReproducibleScript:

      The "ChangeLog" file in the current CVS database writes:
        1999-03-26    <surles@scriptics.com>
      * unix/configure.in: Removed --enable-tcl-stub.  Linking Tk to Tcl
       stubs is causing too many problems when linking executables like wish.
        Until the Tk is a fully loadable extension, linking against the Tcl
       stubs is not supported in Tk.

      Although I agree with the removal of "--enable-tcl-stub" option
      (it should be the normal behavior!!!!), I strongly oppose to the
      argumentation here. Paul Duffin and I never had any problem with
      our Stubs implementation like this, so I was curious about the
      problem described here. Therefor I tried to build a Stub-aware
      Tk version from the current CVS code, and just see what happended.

      Probably, the cause of the problem described here was that tkAppInit.c
      was compiled with the TCL_USE_STUBS flag. This should NEVER be
      done, because at that time the stub table is not initilized yet.

      Recommendations (see patch):
      - #undef TCL_USE_STUBS in winMain.c, tkAppInit.c and tkMacAppInit.c,
        makeing sure that those files are never compiled with this flag.
        This should prevent anyone from making the same mistake.
      - #undef TK_USE_STUBS as well. This prevents extensions writers to
        make the same mistake when linking against Tk's stub table. For
        Tk it has no effect.
      - Use the flag "-DUSE_TCL_STUBS" when compiling shared libraries
        always.

      The last line suggests that it is necessary for Stubs that Tk is
      dynamically loadable. Actually it is reverse: For Tk to be
      dyncamically loadable on all platforms, Stubs are necessary.
      Therefore, Scriptics' attempts should be to concentrate on
      making Stubs work in all situations before trying to make
      Tk dyncamically loadable.

      Final recommendation: If there are problems with Stubs,
      please ask Paul Duffin or me for help. In our implementations,
      what formed the basis of what Scriptics is doing now,
      we think we solved all problems. That including making Tk a
      normal loadable package (for which indeed some more fixes
      are required).

  Patch:
  *** unix/configure.in.origFri Mar 26 12:25:36 1999
  --- unix/configure.inFri Mar 26 12:40:48 1999
  ***************
  *** 435,441 ****
        [ok=$enableval], [ok=yes])
    if test "$ok" = "yes" -a "${SHLIB_SUFFIX}" != ""; then
        TK_SHARED_BUILD=1
  !     TK_SHLIB_CFLAGS="${SHLIB_CFLAGS}"
        TK_LIB_FILE=libtk${TCL_SHARED_LIB_SUFFIX}
        MAKE_LIB="\${SHLIB_LD} -o \${TK_LIB_FILE} \${OBJS} \$(TK_LD_SEARCH_FLAGS) ${SHLIB_LD_LIBS}"
        RANLIB=":"
  --- 435,441 ----
        [ok=$enableval], [ok=yes])
    if test "$ok" = "yes" -a "${SHLIB_SUFFIX}" != ""; then
        TK_SHARED_BUILD=1
  !     TK_SHLIB_CFLAGS="${SHLIB_CFLAGS} -DUSE_TCL_STUBS"
        TK_LIB_FILE=libtk${TCL_SHARED_LIB_SUFFIX}
        MAKE_LIB="\${SHLIB_LD} -o \${TK_LIB_FILE} \${OBJS} \$(TK_LD_SEARCH_FLAGS) ${SHLIB_LD_LIBS}"
        RANLIB=":"
  *** unix/tkAppInit.c.origFri Mar 26 12:07:01 1999
  --- unix/tkAppInit.cFri Mar 26 12:10:04 1999
  ***************
  *** 13,18 ****
  --- 13,21 ----
     * RCS: @(#) $Id: tkAppInit.c,v 1.1.4.3 1999/02/11 04:13:50 stanton Exp $
     */

  + #undef USE_TCL_STUBS
  + #undef USE_TK_STUBS
  + 
    #include "tk.h"
    #include "locale.h"

  *** win/winMain.c.origFri Mar 26 12:34:28 1999
  --- win/winMain.cFri Mar 26 12:36:46 1999
  ***************
  *** 12,17 ****
  --- 12,20 ----
     * RCS: @(#) $Id: winMain.c,v 1.1.4.5 1999/03/10 07:13:52 stanton Exp $
     */

  + #undef USE_TCL_STUBS
  + #undef USE_TK_STUBS
  + 
    #include <tk.h>
    #define WIN32_LEAN_AND_MEAN
    #include <windows.h>
  *** mac/tkMacAppInit.c.origFri Mar 26 12:35:03 1999
  --- mac/tkMacAppInit.cFri Mar 26 12:35:45 1999
  ***************
  *** 12,17 ****
  --- 12,20 ----
     * RCS: @(#) $Id: tkMacAppInit.c,v 1.1.4.5 1999/03/10 07:13:48 stanton Exp $
     */

  + #undef USE_TCL_STUBS
  + #undef USE_TK_STUBS
  + 
    #include <Gestalt.h>
    #include <ToolUtils.h>
    #include <Fonts.h>

  PatchFiles:
      configure.in tkAppInit.c winMain.c tkMacAppInit.c



  04/05/1999 17:54 - redman - Already applied.


tkt_uuid: 1955500fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: 8.4.19 fails windows compile and link with stock vc6.
comment:
  tkWinWm.c
  ..\win\tkWinWm.c(2993) : warning C4013: SetWindowLongPtr' undefined; assuming extern returning int

  ...

     Creating library .\Release\tk84.lib and object .\Release\tk84.exp
  tkWinWm.obj : error LNK2001: unresolved external symbol _SetWindowLongPtr
  .\Release\tk84.dll : fatal error LNK1120: 1 unresolved externals
  NMAKE : fatal error U1077: 'link' : return code '0x460'
  Stop.

  Though most places had been fixed, one was missed out
  in the recent set of fixes.  Diffs w.r.t 8.4.19 are:

  diff -u tkWinWm.c.orig tkWinWm.c 
  --- tkWinWm.c.origThu May  1 08:58:55 2008
  +++ tkWinWm.cThu May  1 08:59:44 2008
  @@ -2990,8 +2990,13 @@
        * translation.  Add the 0.5 to round the value.
        */
       if (!(wmPtr->exStyleConfig & WS_EX_LAYERED)) {
  +#ifdef _WIN64
   SetWindowLongPtr(wmPtr->wrapper, GWL_EXSTYLE,
   *stylePtr);
  +#else
  +SetWindowLong(wmPtr->wrapper, GWL_EXSTYLE,
  +*stylePtr);
  +#endif
       }
       setLayeredWindowAttributesProc((HWND) wmPtr->wrapper,
       wmPtr->colorref, (BYTE) (wmPtr->alpha * 255 + 0.5),


tkt_uuid: 1281183fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 7 High
foundin: obsolete: 8.5a3
resolution: Out of Date
title: Crash with aMSN skinned tabs
comment:
  When you use aMSN CVS version compiled against tcl/tk
  8.5a3 it crashes when using tabbed chatwindows.  These
  are not done with a notebook widget but with
  canvas-skinnable tab-images.  
  How to reproduce ?

  Get 
  http://jaist.dl.sourceforge.net/sourceforge/tcl/tcl8.5a3-src.tar.gz
  http://kent.dl.sourceforge.net/sourceforge/tcl/tk8.5a3-src.tar.gz

  Compile it on Ubuntu Breezy:
  Linux kryptonix.homelinux.org 2.6.8.1-3-386 #1 Tue Oct
  12 12:41:57 BST 2004 i686 GNU/Linux
  scapor@kryptonix:~/Desktop$ gcc -v
  Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
  Configured with: ../src/configure -v
  --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
  --prefix=/usr --mandir=/usr/share/man
  --infodir=/usr/share/info
  --with-gxx-include-dir=/usr/include/c++/3.3
  --enable-shared --with-system-zlib --enable-nls
  --without-included-gettext --enable-__cxa_atexit
  --enable-clocale=gnu --enable-debug
  --enable-java-gc=boehm --enable-java-awt=xlib
  --enable-objc-gc i486-linux
  Thread model: posix
  gcc versie 3.3.5 (Debian 1:3.3.5-8ubuntu2)

  get aMSN's current cvs version (works fine with 8.4/8.3
  ...)
  compile it's extensions against tcl/tk 8.5(a3)

  start aMSN and use tabs (preferences > Session)

  When you open a chat and then open a second chat that
  opens an extra tab, it "crashes".  The panedwindow
  (widget) seems to "bibber" as in the lower frame
  becomes smaller/bigger some pixels the whole time. 
  Wish doesn't react anymore at this stage.

  If you disable aMSN's tabs everything just looks fine,
  with great AA'ed fonts :).


tkt_uuid: 1934272fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: Fixed
title: man2help2.tcl: table macro \w false, invalid continue
comment:
  The script man2help2.tcl is invoked when the winhelp target is build using makefile.vc. Each file in doc is processed by man2tcl and then py this script.

  a) The table macro  (.ta) may contain width of string as table size using \w'Data'. The corresponding regular expression was corrected.

  Example from bind.n:
  .ta \w'\fBButtonPress, Button\0\0\0\fR'u +\w'\fBKeyPress, Key\0\0\0\fR'u
  man2tcl.exe output:
  macro ta \\w'\\fBButtonPress,\ Button\ \ \ \\fR'u +\\w'\\fBKeyPress,\ Key\ \ \ 
  This is now detected.

  b) An errornous "continue" in getTwips caused the script to fail

  c) Table size may have an R behind the unit (Why?).
  This is now honored with a warning

  The patch for tcl8.5.2/tools/man2help2.tcl is attached.

  Please look also to Bug Tcl 1934200 and Tk 1934265.


tkt_uuid: 934524ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Fixed
title: Wish doesn't process fronting clicks
comment:
  When you launch Wish the toplevel appears in front of
  the console.  Under OS 9 I could click and drag on the
  titlebar of the console to move it out from under the
  toplevel.  Under OS X this just raises the console
  window; you have to click and drag again to move the
  window.  OS 9 had a resource flag for whether apps got
  fronting clicks or not, but I don't know if OS X has
  anything equivalent or not.

  This is with TclTkAquaBI 8.4.5 (I think, I'm not at my
  Mac right now) under Panther 10.3.3.

  This was initially reported on the MACTCL mailing list,
  to which Jim Ingham replied:

  On 9 we handled ALL events explicitly in Tk.  But on X,
  there are some events that we let the system take care
  of.  The Title bar is one of these - we had to do this
  to get the stop-lights to work. I'm a little surprised
  that this doesn't "just work", but maybe there is
  something we can tell the standard window handler to
  get it to have this behavior.

  Can you file a bug about this so we don't forget?


tkt_uuid: 2828398fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: Fixed
title: tk crashes when destroying a widget
comment:
  The added script causes an coredump when startet by

  wish85.exe core.tcl

  ( If i start the wish and 
  source core.tcl
  there is no coredump.
  For me it seems that althoug there is an "tkwait variable v2" in proc dialog2 the Konsole
  which ist started is still 'active'. )

  I tested the script with the versions 8.4.19 and 8.5.7 on windows and linux.
  The coredump only occurs on windows 8.5.7

  If I add an 'update' before 
     destroy .d1
  there is no core dump.


tkt_uuid: 220490ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: select to id end - one char missing
comment:
  OriginalBugID: 1777 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-09'
  LastModified: '1999-04-20'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: rjohnson
  OS: Solaris
  Machine: Other
  FixedDate: '1999-04-20'
  FixedInVersion: 8.1


  Name:
  Peter Weigand

  ReproducibleScript:
  The behaviour for text select changed in 8.1.
      The Dummy without y is shown selected in 8.1 in the following example:
      frame .main
      canvas .main.c
      pack .main.c
      pack .main
      update
      set id [.main.c create text 0 0 -text "Dummy" -anchor nw]
      .main.c select from $id 0
      .main.c select to $id end

  DesiredBehavior:
  It should show the whole selection as selected.



  Bug appears to have been caused by diff of bytes & chars in handling text code in canvas.  Changed the test to get the "last selected item" and all appears to be working now.  04/20/1999 15:30 - rjohnson -


tkt_uuid: 1550528fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: Fixed
title: No complaint about non-existing dir (Unix)
comment:
  When tk_chooseDirectory is called with "-mustexist 1", 
  the Unix implementation checks for the existence of the 
  directory, but does not complain if it doesn't. The 
  dialog just silently refuses to accept the choice.

  The attached patch adds a "Directory does not exist" 
  message. (This message already exists in tkfbox.tcl, so 
  no change to the message catalog is necessary.)


tkt_uuid: 2797216fffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: wm attribute . -fullscreen 0 not updated on WIndows
comment:
  Main window in full screen mode:
  wm attributes . -fullscreen 1
  -> Window is shown in full screen mode

  wm attributes . -fullscreen 0
  -> Window is still shown in full screen mode without decoration
  wm attributes . -fullscreen
  -> Retruns 0

  Platform: Windows Vista SP1, Windows classic skin
  Tcl/Tk 8.5.7, compiled with MS-VC++ 6 and Platform SDK Win Server 2003


tkt_uuid: 220456ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: make test errors for Tk 8.0.5
comment:
  OriginalBugID: 1503 Bug
  Version: 8.0.5
  SubmitDate: '1999-03-15'
  LastModified: '1999-08-31'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '1999-08-31'
  FixedInVersion: 8.2


  Name:
  Larry W. Virden

  Extensions:
  Tk 8.0.5

  CustomShell:
  none

  ReproducibleScript:
      on my Ultra 5 Solaris 2.6 (CDE) system, I did a configure, make all, and
      then a
      make test.  I got a series of failures during the test.
      



  ObservedBehavior:
      canvText.test
      
      ==== canvText-6.1 ComputeTextBbox procedure
      ==== Contents of test case:
      
          .c itemconfig test -font $font -text 0
          .c coords test 0 0
          set x {}
          lappend x [.c itemconfig test -anchor n; .c bbox test]
          lappend x [.c itemconfig test -anchor nw; .c bbox test]
          lappend x [.c itemconfig test -anchor w; .c bbox test]
          lappend x [.c itemconfig test -anchor sw; .c bbox test]
          lappend x [.c itemconfig test -anchor s; .c bbox test]
          lappend x [.c itemconfig test -anchor se; .c bbox test]
          lappend x [.c itemconfig test -anchor e; .c bbox test]
          lappend x [.c itemconfig test -anchor ne; .c bbox test]
          lappend x [.c itemconfig test -anchor center; .c bbox test]
      
      ==== Result was:
      {-6 0 6 19} {-1 0 11 19} {-1 -9 11 10} {-1 -19 11 0} {-6 -19 6 0} {-11
      -19 1 0} 
      {-11 -9 1 10} {-11 0 1 19} {-6 -9 6 10}
      ---- Result should have been:
      {-6 0 6 19} {-1 0 11 19} {-1 -10 11 9} {-1 -19 11 0} {-6 -19 6 0} {-11
      -19 1 0} 
      {-11 -10 1 9} {-11 0 1 19} {-6 -10 6 9}
      ---- canvText-6.1 FAILED
      
      clipboard.test
      
      ==== clipboard-6.2 Tk_ClipboardAppend procedure
      ==== Contents of test case:
      
          setupbg
          clipboard clear
          clipboard append -f INTEGER -t TEST "16"
          set result [dobg {selection get -s CLIPBOARD TEST}]
          cleanupbg
          set result
      
      ==== Result was:
      CLIPBOARD selection doesn't exist or form "TEST" not defined
      ---- Result should have been:
      0x10
      ---- clipboard-6.2 FAILED
      
      grid.test
      
      ==== grid-6.9 location: check updates pending
      ==== Contents of test case:
      
              set a ""
              foreach i {0 1 2} {
                  frame .$i -width 120 -height 75 -bg red
                  lappend a [grid location . 150 90]
                  grid .$i -row $i -column $i
              }
              set a
      
      ==== Result was:
      {0 0} {0 1} {1 1}
      ---- Result should have been:
      {0 0} {1 1} {1 1}
      ---- grid-6.9 FAILED
      
      and
      
      textIndex.test
      
      ==== textIndex-5.1 TkTextGetIndex, "@"
      ==== Contents of test case:
      
          .t index @12,9
      
      ==== Result was:
      1.0
      ---- Result should have been:
      1.1
      ---- textIndex-5.1 FAILED
      



  DesiredBehavior:
      No failures
      





      I am uncertain about the severity rating for this report, since I don't
      know how much problem this will cause my users...
  --
  None of these errors comes up for 8.2, with the possible exception
  of the clipboard one for Larry, but I can't reproduce it. 
  -- 08/31/1999 hobbs


tkt_uuid: 1146057fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Fixed
title: TkAqua: encoding problems with [tk_getOpenFile -filetypes]
comment:
  Problem originally reported by Read Roberts <rroberts@adobe.com>

  on TkAqua, tk_get*File uses an incorrect encoding for the -initialfile 
  and -filetypes options leading to gibberish displayed in the dialog for 
  unicode strings. The example script below shows the problem

  #!/bin/sh
  #\
  exec wish $0 "$@"

  set k  [encoding convertfrom utf-8 
  "\345\205\250\343\201\246\343\201\256\343\203\225\343\202\241
  \343\202\244\343\203\253"]
  set t [list [list $k *]]

  set d  [file join ~/Desktop $k]
  file mkdir $d
  close [open [file join $d $k.txt] w]

  set f [tk_getOpenFile -title $k -message $k -initialdir $d -initialfile 
  $k.txt -filetypes $t]
  puts "$f [file exists $f]"

  set f [tk_getSaveFile -title $k -message $k -initialdir $d -initialfile 
  $k.txt -filetypes $t]
  puts "$f [file exists $f]"

  set f [tk_chooseDirectory -title $k -message $k -initialdir $d]
  puts "$f [file exists $f]"

  file delete -force $d


tkt_uuid: 1016385fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Fixed
title: [rename console] doomed to fail
comment:
  TkConsolePrint() makes use
  of Tcl_GetCommandInfo(... "console" ...)
  to get at data it needs to operate.

  After [console] is [rename]d, that will
  no longer work.

  [console] and its supporting cast
  should rely on things less transient
  than command names.


tkt_uuid: 1545984fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: None
title: National language keyboards and Tk
comment:
  Several aMSN users report problems entering non-ASCII
  characters with national language keyboards.

  Full thread here:
  http://amsn.sourceforge.net/forums/viewtopic.php?p=9400


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

  Seen on Windows 2000 with 8.4b1 Tclkit.

  Sample script:

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


tkt_uuid: 220202ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: wish does not work under IRIX 6.5
comment:
  OriginalBugID: 2270 Bug
  Version: 8.1
  SubmitDate: '1999-06-21'
  LastModified: '2000-02-08'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2271
  OS: IRIX
  OSVersion: 6.5.3
  Machine: Other
  ClosedDate: '2000-02-08'


  Name:
  Gary Bliesener

  Comments:
  I'm just the sysadmin - I was planning to start learning Tcl/Tk today,
      but nothing works.

  ReproducibleScript:
  wish

  ObservedBehavior:
  Had to make it setuid to even get a prompt.  Once having gotten a
      prompt, nothing works - command line commands hang. Invoking it with a
      script that worked with version 8.0 hangs, in short, nothing happens
      with any approach.

  DesiredBehavior:
  Smiling happy engineers merrily creating with version 8.1.



  More info is needed on this.  There are known problems with many
  versions of gcc on IRIX, also what was the config that they built
  Tcl on?  If it is the one built in 2271 (threaded), then the user
  must know that while Tcl works with threads, Tk may not be entirely
  thread-safe.  Behavior like that mentioned above would be typical
  of that. 
  -- 09/16/1999 hobbs
  This was a threaded build of Tk, which is not currently supported. 
  -- 02/08/2000 hobbs


tkt_uuid: 701812ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: Message box buttons too wide
comment:
  It's been reported to me that buttons in the tk_messageBox on Unix/X are too wide with 8.4.2 when the 
  text inside the message-box is large.  I've investigated, and I find that this is due to an unneeded -weight 
  1 in the line that configures the grid columns containing the buttons.

  Note 1: Check whether (when the -weight 1 is removed) the -padx of the buttons needs to be boosted.  
  This seems to be the case on Windows, but button size handling varies slightly across platforms.

  Note 2: Check whether this problem is there in other standard dialogs.

  Note 3: Make sure this change goes into the 8.4 branch too!


tkt_uuid: 1071783fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Out of Date
title: winClipboard test failures
comment:
  Windows XP SP2
  Tcl/Tk 8.4.7 with OPTS=threads
  VC++ (from Visual Studio .NET 2003)


  ==== winClipboard-1.2 TkSelGetSelection FAILED
  ==== Contents of test case:

      clipboard clear
      clipboard append {}
      catch {selection get -selection CLIPBOARD} r1
      catch {testclipboard} r2
      list $r1 $r2

  ---- Result was:
  {} {couldn't open clipboard: The operation completed
  successfully.}
  ---- Result should have been (exact matching):
  {} {}
  ==== winClipboard-1.2 FAILED


  ==== winClipboard-1.4 TkSelGetSelection &
  TkWinClipboardRender FAILED
  ==== Contents of test case:

      clipboard clear
      clipboard append "line 1\nline 2"
      catch {selection get -selection CLIPBOARD} r1
      catch {testclipboard} r2
      list $r1 $r2

  ---- Result was:
  {line 1
  line 2} {couldn't open clipboard: The operation
  completed successfully.}
  ---- Result should have been (exact matching):
  {line 1
  line 2} {line 1
  line 2}
  ==== winClipboard-1.4 FAILED


  ==== winClipboard-1.5 TkSelGetSelection &
  TkWinClipboardRender FAILED
  ==== Contents of test case:

      clipboard clear
      clipboard append "line 1\u00c7\nline 2"
      catch {selection get -selection CLIPBOARD} r1
      catch {testclipboard} r2
      list $r1 $r2

  ---- Result was:
  {line 1&#9567;
  line 2} {couldn't open clipboard: The operation
  completed successfully.}
  ---- Result should have been (exact matching):
  {line 1&#9567;
  line 2} {line 1&#9567;
  line 2}
  ==== winClipboard-1.5 FAILED


tkt_uuid: 3588460fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: -typevariable buggy in X11
comment:
  The -typevariable option is buggy in X11. According to TIP 242 the typevariable should hold the type as specified. This script:

  package require tcltest
  package require Tk

  puts [tk_getSaveFile -initialfile foo -typevariable seltype -filetypes {{TEXT *.txt}}]
  puts $seltype

  # behaviour before the patch
  # Win: TEXT
  # Tk/Carbon: TEXT
  # Tk/Cocoa: seltype is undefined
  # X11: TEXT (*.txt)
  #
  # after the patch
  # X11: TEXT

  gives the expected output under Win and Tk/Carbon. The modified result in X11 prevents the use case of switching on the value of typevariable. The attached patch fixes the problem for X11.


tkt_uuid: 792532ffffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 02. Appearance
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Duplicate
title: wrong stipple-area for "state disabled"
comment:
  since 8.4.3 to current cvs:

  having images on buttons with -borderwidth > 0
  and switching to state disabled, the image isn't
  stippled out completly.  You get an unstippled
  border on the left and on downside. Its size
  depends on borderwidth.

  Example Code:

  set img [image create photo -height 32 -width 32]
  $img put red -to 0 0 31 31
  button .b  \
  -borderwidth 5 \
  -state disabled \
          -image $img 
  pack .b

  Platfomr: Unix + Windows


tkt_uuid: 2949648fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: None
title: 'text see' doesn't work when the text is not yet
comment:
  An initial 'text see' command issued just after populating the text often doesn't work. In specific cases of complex layout, and/or when the text contains a lot of lines, doing 'update idletasks' or 'update' before the 'text see' doesn't solve the problem, and neither does performing the see in an 'after idle' or via a custom event sent via 'event generate'.

  The wrong behavior can be seen with the attached example script: the initial call to center_text does not center the line in the text on display. Successive calls via the 'Center' button work.

  A workaround seems to be to add the following lines at the beginning of proc center_text:
  .texts.txt count -update -ypixels 1.0 end
  .texts.lines count -update -ypixels 1.0 end
  and to replace the line center_text with:
  tkwait visibility .texts
  after idle after 5 center_text
  (thanks to Peter Spjuth for this)

  This workaround is quite complicated and basically impossible to find without help. It would be better if an initial 'text see' command worked out of the box, without any need for such a trick.


tkt_uuid: 3606644fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: Static build misses fontconfig
comment:
  After configuring with --disable-shared, compilation fails due to missing symbols provided by fontconfig. The config.log file is attached. The resulting error is:

  gcc -O2  -pipe    -Wl,--export-dynamic  tkAppInit.o -L/home/taylor/Source/Tcl-Tk/tk8.6.0/unix -ltk8.6 -L/home/taylor/Source/Tcl-Tk/tcl8.6.0/unix -ltcl8.6  -lpthread -lXft  -lX11 -lXss -lXext -ldl -lz  -lpthread -lieee -lm  \
          -Wl,-rpath,/usr/local/lib -o wish
  /usr/bin/ld: /home/taylor/Source/Tcl-Tk/tk8.6.0/unix/libtk8.6.a(tkUnixRFont.o): undefined reference to symbol 'FcCharSetDestroy'
  /usr/bin/ld: note: 'FcCharSetDestroy' is defined in DSO /usr/lib/libfontconfig.so.1 so try adding it to the linker command line
  /usr/lib/libfontconfig.so.1: could not read symbols: Invalid operation
  collect2: error: ld returned 1 exit status
  make: *** [wish] Error 1

  Editing the Makefile to add "-lfontconfig" to the definition of XFT_LIBS causes it to work.

  In a non-static build, everything is fine. This is on Arch Linux, with fontconfig 2.10.2 installed.


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

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

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


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


  Name:
  Per Mildner

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

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

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


tkt_uuid: 3138512fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 5 Medium
foundin: None
resolution: None
title: Tk applicatications after grab command (both local/global mo
comment:
  XP SP2,XP SP3,..,Win7 32-64bit
  Tk 8.5.9 ,8.6.0 (but not 8.4.*)

  1) start any application, for example: notepad.exe
  2) start ..>Demos>TK 
       Miscellaneous > 2. A dialog box with a local grab. 
  3) click on Task_Manager/Show_Desktop button
  4) click on Task_Manager/notepad.exe icon (or any others Task_Manager icons)

  Oops.. (Tk application minimized forever)

  Bug #3009450 ?


tkt_uuid: 1067250fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: Duplicate
title: WinXP: test failure with tk_getSaveFile
comment:
  One test fails with cvs head:


  ==== winDialog-5.16 GetFileName: initial file: long
  name FAILED
  ==== Contents of test case:

      start {set x [tk_getSaveFile -initialfile $a -title
  Long]}
      then {
          Click 1
      }
      string totitle $x

  ---- Result was:
  E:/programming/tcl-source/cvs-tk/win/12x 456
  ---- Result should have been (exact matching):
  E:/programming/tcl-source/cvs-tk/win/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
  aaaaaaaaaaaaaaaaaa
  ==== winDialog-5.16 FAILED


tkt_uuid: 967209ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 23. Option Parsing
priority: 5 Medium
foundin: None
resolution: None
title: TK_OPTION_NULL_OK not fully supported
comment:
  Tk_SetOptions() does not recognize the
  TK_OPTION_NULL_OK flag bit for options of type
  TK_OPTION_INT, TK_OPTION_BOOL, and a few others.

  This causes a bug in the Tile widgets (current CVS
  HEAD), which use  null defaults in several places.  For
  example:

  tlabel .l
  .l configure -width [.l cget -width]
  ==> Error 'expected integer but got ""'

  Workaround possible but this should be fixed in the core.


tkt_uuid: 929933ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 4
foundin: None
resolution: None
title: Aqua mac OS X-focus problem in text widget with dock
comment:
  How to reproduce the bug
  Execute that script...click on .t window, try to write something in .f 
  first text widget
  put that window in the dock (.f)
  click in the dock to reveat the window
  You can't write in .f anymore...You can't bring the focus to the text 
  widget. You have to switch to .t and get back to .f

  frame .f -width 300 ;
  update idletasks ;
  text .c1 -background white -width 15 -height 3 -wrap word -font 
  bboldf -borderwidth 0 -relief solid -highlightthickness 0 
  -exportselection 1
  text .c2 -background white -width 15 -height 3 -wrap word -font 
  bboldf -borderwidth 0 -relief solid -highlightthickness 0 
  -exportselection 1
  .c2 configure -state disabled
  pack .f ;
  pack .c1 -side left -expand true -fill both -padx 1 -pady 1;
  pack .c2 -side right -expand true -fill both -padx 1 -pady 1;
  toplevel .t
  entry .t.e
  pack .t.e

  Comment from Jim:
  I put printf in TkMacOSXProcessWindowEvent, which is where we 
  handle window Activation & Deactivation.  What I see is:

  Normal case: when you just click on .t or . to foreground a window 
  you first get the Deactivate event for the window that is going to 
  the background, then the Activate event for the new window.

  Hide/Reveal case: when you hide the window, then on Reveal, you 
  first get the Activate event for the revealed window, THEN the 
  Deactivate window for the previous foreground window.

  So we end up with nobody having the focus...  %$^#$%@#!#@$


tkt_uuid: 2030200fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 3 Low
foundin: obsolete: 8.6a1
resolution: Fixed
title: Vista scrollbar arrows highlighting (tk and ttk)
comment:
  On Vista, the up and down arrows in a scrollbar widget should highlight when the mouse pointer enters the scrollbar, and unhighlight when the pointer leaves it.

  With current Tk scrollbars, the arrows sometimes highlight, but not correctly (i.e. on enter/leave). It seems they (un)highlight after clicking the scrollbar, and depending on whether the mouse button is released inside/outside of the scrollbar.

  With current Ttk scrollbars, the arrows never highlight.


tkt_uuid: 220440ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: wm geometry refuses to move a toplevel until told to do it a second time
comment:
  OriginalBugID: 1360 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '1999-12-14'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 3687
  OS: Windows NT
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-12-14'
  FixedInVersion: 8.3b1


  #
  # Tcl script provided to demonstrate this bug was distilled from many
  # thousands of lines of machine generated calls to the tcl interp.
  # (Could possibly have been distilled further, but for no gain?)
  #
  # Broken into four separate files to be sourced from the console
  # (because this is the timing of the machine generated calls), plus a 
  # fifth for cleanup to allow go-around-again iterations.
  #
  # Run the console and source part0, part1, part2a, and part2b, in
  # that order.  Sourcing part2b refuses to position toplevel b (the 
  # one with the button on it).
  #
  # But sourcing it a second time will!
  #
  # (Try moving toplevel b manually and sourcing part2b.  Nothing 
  # happens unless you do it a second time.  Then the window moves!)
  #
  # Note that running the pieces together as one countinuous source 
  # works! (i.e. toplevel .b is successfully positioned at +400+425 
  # the first time)
  #

  # part0 ---------------------------------------------------------

  toplevel .a
  frame .a.child
  wm withdraw .a

  toplevel .b
  frame .b.child
  button .b.child.button -text Button
  wm withdraw .b

  wm deiconify .a

  pack .a.child -expand true -fill both

  # part1 ---------------------------------------------------------

  wm deiconify .a
  wm geometry .a 7x27+300+100
  raise .a

  # part2a --------------------------------------------------------

  pack .b.child.button -fill x
  pack .b.child -expand true -fill both

  wm deiconify .b

  # part2b --------------------------------------------------------

  wm geometry .b +400+425

  #
  # for some reason, commenting out this raise causes the first 
  # execution of this position to work!
  #

  raise .b

  # clean up to go around again -----------------------------------

  pack forget .b.child.button
  destroy .b.child.button
  pack forget .b.child
  destroy .b.child
  wm withdraw .b
  destroy .b
  pack forget .a.child
  destroy .a.child
  wm withdraw .a
  destroy .a

   8.  Described the undesired behavior you observed
   
   The window manager geometry command refuses to position a toplevel 
  until the command is executed a second time.

   9.  Described the behavior you expect to see
   
   I expect to see the toplevel positioned properly with the first call 
  to wm!

   10. If you have created a patch, please include it in the email or
       provide a URL of a patch file and list affected files.
   
   No patch file.

  This was due to a lack of an update call before deiconifying.
  The work-around was to add 'update idle' before the wm deiconify
  call.  In 8.3b1 this is fixed. 
  -- 12/14/1999 hobbs


tkt_uuid: 220124ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: The raise command works incorrectly on the first window of the app
comment:
  OriginalBugID: 1174 Bug
  Version: 8.0.5
  SubmitDate: '1999-02-10'
  LastModified: '1999-08-15'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 951
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-15'


  Test script:

  after 6000 reraise

  proc reraise {} {
      after 6000 reraise

      wm deiconify .
      raise .
  }

  When running this script, the raise command will raise the window on top of all other windows instead of raising it on top of those from the same app. This happens only if this window is the first one for this app. If I touch the window by clicking at it or moving it, the window will not raise when it should.



  This works as expected and must be considered in conjunction with
  your wm.  Some wms do not actually move the window to front by
  default when you move it (they do just when clicking - I believe
  this is the case with olwm).  Most other unix wms allow you to
  modify this behavior in the rc file. 
  -- 08/15/1999 hobbs


tkt_uuid: 870844ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: None
title: WinTk: many menus in menubar won't popup
comment:
  The attached script recursively creates some submenus
  in a menubar.  Unfortunately, only the first menu
  actually pops up (in any of Tk 8.3/8.4/8.5), and
  attempting to launch two wish processes with this
  script simply fails (subsequent processes don't manage
  to launch, it seems).

  This is on WinXP

  catch {console show}

  proc mr {w count e} {
      for {set i 0} {$i < 5} {incr i} {
  if {$e} {
      $w insert end command \
        -label "entry$count$i" -command "foo $i"
  }
  if {$count > 0} {
      set m $w.m$count$i
      menu $m
      $w insert end cascade \
        -label "sub$count$i" -menu $m
      mr $m [expr {$count -1}] 1
  }
      }
  }
  proc foo {args} {
      puts stderr $args
  }

  menu .mb
  . configure -menu .mb
  mr .mb 5 0
  update


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


tkt_uuid: 840978ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: MacOSX scrollbar limits are off: 0.0 0.9 is about 50%
comment:
  This is on TkAqua:

  toplevel .t
  scrollbar .t.s
  pack .t.s -side left  -fill y

  followed by '.t.s set 0.0 0.5' one would assume to see the 
  scrollbar with the 'bar' occupying the first 50% of the trough. 
  Instead it's about 30%.

  .t.s set 0.0 0.999 ;# occupies about 50%

  I should also point out there's another problem with dragging the 
  scrollbar -- the mouse sort of slips along it, with the scrollbar 
  dragging more slowly than the mouse moves, and you have to 
  drag all the way beyond the double arrow at one end to actually 
  move the whole scrollbar to one extreme. The way the scrollbar 
  should work is that each pixel the mouse moves equates to the 
  same movement of the scrollbar-slider.


tkt_uuid: 540920ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 67. Unix Window Operations
priority: 3 Low
foundin: None
resolution: None
title: Access to 'container' id
comment:
  On my system, if I do
    exec xwininfo -tree -id [wm frame .]
  I get output something like this:

    xwininfo: Window id: 0x3810df9 (has no name)

      Root window id: 0x2a (the root window)
                           (has no name)
      Parent window id: 0x2a (the root window)
                             (has no name)
         10 children:
         0x3810e03 (has no name): ()
                                 200x200+5+24  +312+72
            1 child:
            0x5c00004 "wish8.3": ("wish8.3" "Wish8.3")
                                 200x200+0+0  +312+72
               1 child:
               0x5c00003 (has no name): ()
                                 200x200+0+0  +312+72
         [... rest of output elided ...]

  Now, the window id of the frame, 0x3810df9, is easily
  obtainable with [wm frame] and the window id of the
  drawing area is also easily obtainable with [winfo id],
  but the window id of the window that comes between them
  (present on UNIX/X because the window that implements
  the menubar for a window is a sibling of the toplevel
  drawing area, not a child of it, so an extra container
  is needed to hold them both) is not available without
  doing a hack (rummaging through the output of xwininfo
  or hacking around with XQueryTree.)  Wouldn't it be
  better if there was a way to expose this information at
  the Tcl and C levels in a cleaner way?  (You need it
  when you apply a non-rectangular shaping to a window,
  for example, because window managers only notice
  reshaping events on the container, not its children.)


tkt_uuid: 1871474fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Fixed
title: <<Modified>> does not trigger
comment:
  The <<Modified>> event is sometimes not generated when the text widget changes state, despite what the man states.

  It looks like the fix for bug 1799782 (and 687522) that made it into 8.5.0 at the last minute seems to have created this bug.

  For instance:

  1 % info patchlevel
  8.5.0
  2 % text .t
  .t
  3 % pack .t
  4 % bind .t <<Modified>> {puts "EVENT"}
  5 % .t edit modified
  0
  6 % .t insert end "Hello"
  EVENT
  7 % .t edit modified
  1
  8 % .t edit modified false
  9 % .t edit modified
  0
  10 % 

  The modified flag is correctly automatically set to true when text is inserted.

  Then the modified flag is manually reset to false.

  This latter action should generate a <<Modified>> event, which does not happen. The manual indeed says that "Whenever the flag changes state a <<Modified>> virtual event is generated."


  Francois


tkt_uuid: 700317ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: OS X Aqua: Tk forces quit despite exit handler procedure
comment:
  If the 'exit' command is replaced by a proc, (ie: via
  rename) and that procedure pauses for the results of a
  dialog, the Tk interpreter should NOT force the
  application exit via Tcl_Exit(0) as it does now.

  The Quit command is a request to quit, not an
  imperative.  There may be unsaved files to save,
  confirmation dialogs, etc. that need the user's attention.


tkt_uuid: 220525ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: Problems with Tk 8.1 entry widget.
comment:
  OriginalBugID: 2067 Bug
  Version: 8.1
  SubmitDate: '1999-05-14'
  LastModified: '1999-10-29'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 3150
  OS: Linux-Red Hat
  Machine: Other
  FixedDate: '1999-10-29'
  FixedInVersion: 8.2.2


  Name: Patrick Earl

  Comments:
  Tcl/Tk were compiled with --enable-shared --enable-gcc on pgcc-2.91.60
      (1.1.1)
      
  I have a Tk app (quirc.org) that I frequently paste large pieces of text
  into, and the slow (or frozen) behaviour of the entry box is annoying at
  best.

  ReproducibleScript:
  echo "pack [entry .test]" | wish8.1
      
      There are a number of problems that occur when I do one of the
      following:
      1) Paste a large amount of text into the entry box (ex. >2k) and hit
      End.
      2) Type for an extended period of time into the entry box.
      3) Paste a fair amount of text into an already selected area of text.

  ObservedBehavior:
  1) Freezes the app with 100% CPU usage
      2) The entry box becomes sluggish and does not update itself as it needs
      to.  It becomes slower and slower as one types more text.  I typed a
      couple paragraphs in it, and it was practically unusable for text entry
      at that point.
      3) I took a selection of 80 characters of text, pasted it within the
      entry box a single time.  Then I selected what I had just pasted and
      proceeded to simply paste within the existing selection.  After around 7
      pastes, there was noticeable CPU usage.  The CPU usage disappears when
      the window is not in focus.
      The CPU usage increased up until about 11 pastes where it was taking up
      around 100% CPU.  I did 12 pastes, then changed the focus to another
      window, and then back to this one, and I got the following error (with
      wish dying):
      
      X Error of failed request:  BadLength (poly request too large or
      internal Xlib length error)
        Major opcode of failed request:  74 (X_PolyText8)
        Serial number of failed request:  5800
        Current serial number in output stream:  5808
      
      If I paste a bunch of times after 12 without letting the window leave
      focus, it goes into a state of 100% CPU usage and does not seem to stop
      without killing wish.

  DesiredBehavior:
  1) It should not freeze, but should simply go to the end of the pasted
      text.
      2) Should not slow down, should continue entering text at normal speeds.
      3) It should not freeze or consume large amounts of CPU, but should
      continue to allow pasting and entry of text as normal.



  There is an obvious slowdown in the action wizards using entry widgets when the user types really fast in an entry. This was part of the problems observed in # 3150 (the other issues have been resolved). 
  -- 10/29/1999 sven
  This was do to an overeager while calculation in tkEntrySeeInsert.
  This has been changed for 8.2.2, slightly altering the behavior
  when moving the cursor in the entry widget (for the better, IMO). 
  -- 10/29/1999 hobbs


tkt_uuid: 1327482fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 9 Immediate
foundin: obsolete: 8.4.19
resolution: Accepted
title: Missing <Enter> events for items
comment:
  When a <ButtonPress> (setting LEFT_GRABBED_ITEM), e.g.,
  is bound to tk_popup a menu (triggering <Leave> item
  and <Leave> canvas), leaving the menu with the pointer
  positioned in the original item triggers <Enter>
  canvas, but erroneously not <Enter> item.

  Reproducable on Unix by:
  pack [canvas .c]
  .c create text 50 50 -text X
  .c bind 1 <Enter> {puts "Enter 1"}
  .c bind 1 <Leave> {puts "Leave 1"}
  bind .c <Enter> {puts "Enter .c"}
  bind .c <Leave> {puts "Leave .c"}
  menu .m; .m add command -label Foo
  .c bind 1 <1> {tk_popup .m %X %Y}

  Left press on the X, leave the menu back onto the X,
  and release the left button.

  On Windows the issue can be provoked by replacing the
  last two lines of the script above by:
  toplevel .m -bg grey; wm overrideredirect .m 1; wm
  withdraw .m
  .c bind 1 <1> {wm geometry .m +%X+%Y; wm deiconify .m;
  raise .m; grab .m}


tkt_uuid: 2887486fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: None
title: Use GTK+/Qt theme on Linux/Unix
comment:
  Please add support for using the current Qt or GTK+ theme in Tk. This would help make Tk look more native under KDE and GNOME.


tkt_uuid: 706446ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 6
foundin: obsolete: 8.4.2
resolution: Fixed
title: active button not drawn correctly
comment:
  If a button is configured to the disabled state and then 
  reconfigured to the active state, it still look like a disabled button, 
  even though you can press the button:

  pack [button .b -state disabled]

  .b configure -state active

  Kish Shen
  Imperial College London
  U.K.
  K.Shen@icparc.ic.ac.uk


tkt_uuid: 1576528fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 42. Photo Image|GIF
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: None
title: image read file from co-ords
comment:
  The /image/ read /file/ -from x1 y1 x2 y2 command does
  not work correctly.  The following script uses the
  ActiveTcl example gif of the earth from space.  The
  rectangular region (152,62) to (185,97) encloses
  Madagascar.  The displayed region is from the top-right
  hand corner.

  package require Tk
  set fname C:/Tcl8.4/demos/Tk8.4/images/earth.gif
  canvas .c
  pack .c
  set img [image create photo]
  $img read $fname -from 152 62 185 97
  .c create image 0 0 -anchor nw -image $img


tkt_uuid: 2839285fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: MS Windows: Input: chars ĉ, ĝ, ĵ, ... come out as c, g, j...
comment:
  System: Windows XP SP3 on Athlon XP
  Problem occurs with:
  *ActiveTcl 8.5.7.0
  *ActiveTcl 8.4.19.1
  *tclkit-8.5.7-win32.upx.exe
  *tclkit-8.4.17-win32.upx.exe
  *tclkit-8.4.1-win32.upx.exe
  *tclkit-8.4.0-win32.upx.exe
  (Other versions have not been tested but are likely to suffer as well).

  (1) install Esperanto keyboard from http://sites.google.com/site/windowskeyboards/Home
  (2) run this script:
  entry .e
  pack .e
  console show
  bind .e <KeyPress> [list puts %k:%K:%N:%A]
  (3) now change to the newly installed keyboard layout and you will see that when typing "ŝ" into the entry (on your "q" key if you're using a standard english keyboard), Tk will only get a normal "s" instead of a "ŝ".
  This is not a font problem, as it works correctly to paste a ŝ copied from another app like notepad into the entry and copying the wrongly obtained "s" and pasting it into notepad only gives an "s". The problem lies somewhere in the keyboard input.
  See the log of the sample script when consecutively hitting: c, ĉ, g, ĝ, h, ĥ, j, ĵ, s, ŝ, u, ŭ:
  67:c:99:c
  88:c:99:c
  71:g:103:g
  219:g:103:g
  72:h:104:h
  221:h:104:h
  74:j:106:j
  89:j:106:j
  83:s:115:s
  81:s:115:s
  85:u:117:u
  87:u:117:u
  Obviously, the keycodes differ, but for some reason not the characters interpreted by Tk.

  Note that this only happens on Windows; on linux/X with epo keymap it works like a charm.

  Bug #1572922 might be related (but then again, it happens on Linux, and this one on Windows).


tkt_uuid: 467524ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Fixed
title: GIF images are not read correctly
comment:
  Using "wish", (Tcl/Tk version 8.3.3) reading GIF
  formatted images with
  the "-from" option to the "image read" command results
  in either
  a corrupted image or a segmentation fault.

  Using a small GIF file (307x187) I tried the following:

  % image create photo
  image1
  % image1 read debris1.gif -from 0 0 100 100
  % canvas .c
  .c
  % pack .c
  % .c create image 0 0 -anchor nw -image image1
  1

  The resulting image that is displayed is corrupt.  In
  other instances
  using the "-from" option has resulted in a crash of the
  "wish"
  program due to a segementation fault.

  This problem also shows up under Tcl/Tk 8.3.2.  It has
  been reproduced
  under Solaris 2.6, Solaris 8, Windows NT, and Windows
  2000.  I have also noticed that the same code is used
  in the Tcl/Tk 8.4 Alpha releases.

  The problem seems to be in the the call to
  "ReadImage()" in 
  "tkImgGIF.c":

  1).  The "ReadImage()" function ignores any parameters
  that have been
        passed via the "-from" option.

  2).  Non-interlaced GIF images will load, but they will
  be corrupted.

  3).  Interlaced GIF images will typically cause a
  segmentation fault
        as they are read, but if not they will still be
  corrupted.

  I worked on a fix to prevent the problem, but it is not
  optimal:

  *** /afs/isis.unc.edu/home/m/c/mcknight/tkImgGIF.c     
  Wed Oct  3 11:29:46 2001
  --- tkImgGIF.c  Wed Oct  3 11:31:34 2001
  ***************
  *** 799,805 ****
        register unsigned char *top;
        int codeSize, clearCode, inCode, endCode,
  oldCode, maxCode,
          code, firstCode;
  !     
        /*
         *  Initialize the decoder
         */
  --- 799,805 ----
        register unsigned char *top;
        int codeSize, clearCode, inCode, endCode,
  oldCode, maxCode,
          code, firstCode;
  ! 
        /*
         *  Initialize the decoder
         */
  ***************
  *** 841,848 ****
        GetCode(chan, 0, 1);
    
        /* Read until we finish the image */
  !     for (i = 0, ypos = 0; i < rows; i++) {
  !       for (xpos = 0; xpos < len; ) {
    
              if (top == stack) {
                  /* Bummer -- our stack is empty.  Now
  we have to work! */
  --- 841,849 ----
        GetCode(chan, 0, 1);
    
        /* Read until we finish the image */
  ! 
  !     for (i = 0, ypos = 0; i < height; i++) {
  !       for (xpos = 0; xpos < width; ) {
    
              if (top == stack) {
                  /* Bummer -- our stack is empty.  Now
  we have to work! */
  ***************
  *** 947,955 ****
               * there are more in the file and we will
  be called to read 
               * one of them later)
               */
  !           *pixelPtr++ = cmap[v][CM_RED];
  !           *pixelPtr++ = cmap[v][CM_GREEN];
  !           *pixelPtr++ = cmap[v][CM_BLUE];
              if (transparent >= 0) {
                  *pixelPtr++ = cmap[v][CM_ALPHA];
              }
  --- 948,963 ----
               * there are more in the file and we will
  be called to read 
               * one of them later)
               */
  ! 
  !             if ( (xpos >= srcX) && (xpos < srcX+len)
  &&
  !                  (ypos >= srcY) && (ypos <
  srcY+rows)) {
  ! 
  !               *pixelPtr++ = cmap[v][CM_RED];
  !               *pixelPtr++ = cmap[v][CM_GREEN];
  !               *pixelPtr++ = cmap[v][CM_BLUE];
  ! 
  !             }
  ! 
              if (transparent >= 0) {
                  *pixelPtr++ = cmap[v][CM_ALPHA];
              }
  ***************
  *** 970,976 ****
          } else {
              ypos++;
          }
  !       pixelPtr = imagePtr + (ypos) * len *
  ((transparent>=0)?4:3);
        }
        return TCL_OK;
    }
  --- 978,989 ----
          } else {
              ypos++;
          }
  ! 
  !         if ( i >= (srcY+rows) ) {
  !             break;
  !         }
  ! 
  !       pixelPtr = imagePtr + (ypos-srcY) * len *
  ((transparent>=0)?4:3);
        }
        return TCL_OK;
    }


tkt_uuid: 2677890fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5.7
resolution: Fixed
title: Text widgets multi-scrolling problem
comment:
  Hi,

  When running the attached code (tts.tcl), at first both text widget scroll in sync. Now click the Test button, which will re-create the text and scrollbar widgets 100 times. When complete, try scrolling again, the text widgets are no longer in sync. Now try scrolling all the way down, notice how sometimes the slider's size changes while scrolling. When at the bottom, scrolling is in sync again.

  Kind regards,

  Jos.


tkt_uuid: 2321450fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: Text widget block cursor problem
comment:
  When the -blockcursor option is set to 1, the cursor appears as a blinking bar which expands to the right edge of the widget.

  The problem is there for Tk 8.5.4 on X11 (tested by me) and HEAD (confirmed by dkf on the tcler's chat).


tkt_uuid: 220259ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: menu widget will not pop up during script evaluation from C++- code
comment:
  OriginalBugID: 3774 Bug
  Version: 8.2
  SubmitDate: '1999-12-06'
  LastModified: '1999-12-22'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: Win NT 4.0
  Machine: Pentium III
  ClosedDate: '1999-12-22'


  Name:
  Lutz Newiger

  CVS:
  RCS: @(#) $Id: README.binary,v 1.10.2.1 1999/09/22 04:13:10 hobbs Exp $

  ObservedBehavior:
  Dear Ladies and Gentlemen,

  I've written a Tcl/Tk- script which will be evaluted from an external C++-windows program using ILOG- Views. In this program it is an C++- function which will create a separate thread. And in this thread I call my on MyTk_Main(argc,argv(),TAI ) which will be derived from the origin Tk_Main(...). This MyTk_Main differ from the origin Tk_MainEx(...) only by removing of the last line "Tcl_Exit(0);" to avoid the finishing of the hole program.
  Even if the script evaluation runs in a separate thread, the function Tcl_Exit(0) in Tk_MainEx(...) will end the entire program. The problem is, that after a first script evaluation and finishing, menu entities will not pop up. All the other widgets are working correctly. I'm not really sure if it is a bug or my mistake. If You want more information, please send me a e-mail. 

  I really would appreciate your help on this. Thank you for your effort in advance.

  Best regards

  Lutz Newiger



  The user must note that Tk8 style menus on Windows/Mac use native
  menus, and require working with the native event loops in these
  cases.  It is likely that proper initialization is not done in order
  to get the desired behavior. 
  -- 12/22/1999 hobbs


tkt_uuid: 698571ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: image create failure when mem low
comment:
  [image create photo -file {whaterverfile} ] fails when not 
  enough memory is available. 




  Fe if a whole range of images (+150 1080x1420 images) 


  is already loaded.




  On W32 it shows "Unable to alloc xxxx bytes" and the 
  tcl/tk app shuts down. On Linux it tends to coredump.




  It would be nice to get a error back from Tk so that I can 
  display a warning myself and safely exit my program.


tkt_uuid: 220442ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: text widget manpage wrong about Windows word definition
comment:
  OriginalBugID: 1388 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '2000-01-18'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2132
  OS: Windows NT
  OSVersion: 4.0 sp 3
  Machine: X86
  FixedDate: '2000-01-18'
  FixedInVersion: 8.3


  Name:

  Christopher Hylands



  Extensions:

  Itcl3.0/Tcl8.0.3/Tk8.0.3



  CustomShell:

  None



  ReproducibleScript:

  Double clicking on a word in a text widget includes the punctuation under

  windows.  The text man page does not mention that the definition of a

  word differs between Windows and Unix.







  ObservedBehavior:

  The online Tcl help shipped with Itcl3.0/Tcl8.0.3/Tk8.0.3 and

  the tk8.0.5 page at ~ptdesign/src/tcltk/tk8.0.5/doc/text.n

  both say:

  --start--

    In the descriptions below, ``word'' refers to a contiguous group

    of letters, digits, or ``_'' characters, or any single character

    other than these.

  ...

    Double-clicking with mouse button 1 selects the word under the mouse

    and positions the insertion cursor at the beginning of the word.

    Dragging after a double click will stroke out a selection consisting

    of whole words.

  --end--



  D:/Program Files/Tcl/lib/tk8.0/text.tcl says:

  --start--

    bind Text <Double-1> {

       set tkPriv(selectMode) word

       tkTextSelectTo %W %x %y

       catch {%W mark set insert sel.first}

    }

  --end--

  In text.tcl tkTextSelectTo includes the following code frag that

  is used when we are searching for a word

  --start--

        word {

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

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

               set last [tkTextNextPos $w "anchor" tcl_wordBreakAfter]

                   } else {

                     set first [tkTextPrevPos $w anchor tcl_wordBreakBefore]

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

              }

  --end--



  tcl_wordBreakBefore and tcl_wordBreakAfter are defined in

  D:/Program Files/Tcl/lib/tcl8.0/word.tcl



  They use the following variables that are also set in word.tcl

  --start--

    # The following variables are used to determine which characters are

    # interpreted as white space.



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

        # Windows style - any but space, tab, or newline

        set tcl_wordchars "\[^ \t\n\]"

        set tcl_nonwordchars "\[ \t\n\]"

    } else {

        # Motif style - any number, letter, or underscore

        set tcl_wordchars {[a-zA-Z0-9_]}

        set tcl_nonwordchars {[^a-zA-Z0-9_]}

    }

  --end--



  So, the definition of a word is platform dependent.  This should be

  mentioned in the docs







  DesiredBehavior:

  The text man page should mention that the definition of a word is

  platform dependent







  tcl_(non)wordchars is now in tclvars.n, with a reference for that
  in the text widget docs.  The value has also been changed to the
  8.1+ unicode \[sS] and \[Ww]. 
  -- 01/18/2000 hobbs


tkt_uuid: 220857ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.2b2
resolution: Out of Date
title: Change font selection order for internationalized strings
comment:
  OriginalBugID: 2523 RFE
  Version: 8.2b2
  SubmitDate: '1999-08-11'
  LastModified: '1999-11-16'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: Debian 2.1
  Machine: Other


  Name: Victor Wagner

  CustomShell:
  Locale patch as described in my previous

  DesiredBehavior:
  Problem is that when string, containing both ASCII and non iso8859-1
      characters
      is displayed on tk widget, using font, created with font command,
      ASCII and non-ascii characters often looks differently. It appears
      that Tk first search for best font for ASCII characters, and then for
      non-ASCII
      characters, often finding different fonts, even if all ASCII characters
      are
      available in the font which is used for Cyrillic characters.
      
      Typical workarounds are
      - use font family for which only Cyrillic fonts exist.
      - use old-style X font names.
      
      Both workarounds leads to degradation of portability.
      
      Following change may be suggested:
      1. Search for fonts with iso10646-1 encoding. If one found, it could
      probably
      be used to represent all characters in string.
      2. Search for fonts with encoding equial to current system encoding and
      use
      them for both ASCII charachers and any other characters which present in
      current
      encoding. Most strings with non-ascii characters are probably on the
      local user's language, and so widgets which contain both english and
      local language
      text would look consistent.
      3. Use current search mechanism to find fonts for any other charachers.


tkt_uuid: 1676675fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: new test failures
comment:
  On Solaris 9 /CDE, these
  test failures are new since
  8.5a5. Failures happen
  in both --enable- and --disable-xft
  configurations:

  ==== scale-8.2 ScaleElement procedure FAILED
  ==== Contents of test case:

      catch {destroy .s}
      scale .s -from 0 -to 100 -orient vertical -bd 1 -tick 20 -length 300
      pack .s
      .s set 30
      update
      list [.s identify 60 2] [.s identify 60 3] [.s identify 60 302]  [.s identify 60 3
  03]

  ---- Result was:
  {} trough1 {} {}
  ---- Result should have been (exact matching):
  {} trough1 trough2 {}
  ==== scale-8.2 FAILED



  ==== scale-8.3 ScaleElement procedure FAILED
  ==== Contents of test case:

      catch {destroy .s}
      scale .s -from 0 -to 100 -orient vertical -bd 1 -tick 20 -length 300
      pack .s
      .s set 30
      update
      list [.s identify 60 83] [.s identify 60 84] [.s identify 60 113]  [.s identify 60
   114]
  ---- Result was:
  slider slider trough2 trough2
  ---- Result should have been (exact matching):
  trough1 slider slider trough2
  ==== scale-8.3 FAILED


tkt_uuid: 220676ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: Grab failed in menu, seen in tk_getOpenFile
comment:
  OriginalBugID: 4155 Bug
  Version: 8.3b2
  SubmitDate: '2000-02-10'
  LastModified: '2000-03-10'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Unix
  FixedDate: '2000-03-10'
  FixedInVersion: 8.3.1


  Name:

  Frank J. Leitner


  Comments:

  This was originally found in tk 8.0.4, so appears to have been in tk for

      ages, but he patch is against 8.3b2. I'd guess that more unprotected

      grabs are still to be discovered...


  ReproducibleScript:

  Although the bug apparantly is in the menu bindings, it was discovered through the Unix version of tk_getOpenFile: press the ESC key (for closing the dialog) and simultaniously open (click on) the option menu above the file listing (the menu which has the paths to all parent directories).


  ObservedBehavior:

  Stack trace:


  grab failed: window not viewable

      while executing

  "grab -global $w"

      (procedure "tkMbPost" line 107)

      invoked from within

  "tkMbPost $tkPriv(inMenubutton) 785 594"

      invoked from within

  "if {[string compare $tkPriv(inMenubutton) ""]} {

  tkMbPost $tkPriv(inMenubutton) 785 594

      }

  "

      (command bound to event)


  After closing the error message box, the file dialog box is gone, but the menu is still shown. Choosing any entry of that orphaned menu dumps another error message, but the menu will not go away...


  grab failed: window not viewable

      while executing

  "grab -global $tkPriv(postedMb)"

      (procedure "tkMenuButtonDown" line 10)

      invoked from within

  "tkMenuButtonDown .__tk_filedialog.f1.menu.menu

  "

      (command bound to event)


  DesiredBehavior:

  No error messages, and at least being able to close / remove the orphaned menu, better yet not showing it at all.


  Patch:

  *** menu.tcl.orig       Thu Sep  2 19:02:52 1999

  --- menu.tcl    Thu Feb 10 18:08:40 2000

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

  *** 350,357 ****

        set tkPriv(tearoff) $tearoff

        if {$tearoff != 0} {

          focus $menu

  !       tkSaveGrabInfo $w

  !       grab -global $w

        }

    }


  --- 350,359 ----

        set tkPriv(tearoff) $tearoff

        if {$tearoff != 0} {

          focus $menu

  !       if {[winfo viewable $w]} {

  !           tkSaveGrabInfo $w

  !           grab -global $w

  !       }

        }

    }


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

  *** 561,567 ****

            return

        }

        $menu postcascade active

  !     if {[string compare $tkPriv(postedMb) ""]} {

          grab -global $tkPriv(postedMb)

        } else {

          while {[string equal [$menu cget -type] "normal"] \

  --- 563,569 ----

            return

        }

        $menu postcascade active

  !     if {[string compare $tkPriv(postedMb) ""] && [winfo viewable $tkPriv(postedMb)]} {

          grab -global $tkPriv(postedMb)

        } else {

          while {[string equal [$menu cget -type] "normal"] \


  PatchFiles:

  library/menu.tcl




  Thanks for the patch.  I've applied it and it will go out with Tcl/Tk 8.3.1.

  - eric
   
  -- 03/10/2000 ericm


tkt_uuid: 220436ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Core dump on fconfigure -blocking 0
comment:
  OriginalBugID: 1319 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '1999-09-13'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: Solaris 2.5
  Machine: Other
  FixedDate: '1999-09-13'
  FixedInVersion: 8.2


  Name:
  David W. Smith

  Extensions:
  None

  CustomShell:
  None

  ReproducibleScript:
  prowish80
  fconfigure stdin -blocking 0
  parray env




  ObservedBehavior:
  Panic in FlushChannel due to write(-1) with EAGAIN error code. Stdout is
  non-blocking (declared blocking). 




  DesiredBehavior:
  That the env works (as it does for protclsh80) and no panic.






  This is really confusing behavior. Works fine on NT but NOT Unix.
  --
  This has been fixed in TclPro 1.3 (or newer versions of wish). 
  -- 09/13/1999 hobbs


tkt_uuid: 553283ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: Grab fails in tk_messageBox
comment:
  Under UNIX, if you try to launch two tk_messageBoxes,
  the second one replaces the first.  But when you click
  on the OK button, you get an application error.

  Try running this script under Unix:

    update
    after 1000 {
      tk_messageBox -icon error -type ok -message \
          "Click to get an error"
    }
    after idle {
      tk_messageBox -icon info -type ok -message \
          "Wait a second..."
    }


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

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

  package require Tk

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

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


tkt_uuid: 220139ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: 8.0.3 font crash in Korean NT and other Intl. NT
comment:
  OriginalBugID: 1451 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-04'
  LastModified: '1999-04-16'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: stanton
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-04-16'


  Name:
  Ed Hume

  ReproducibleScript:
  Run wish 8.0.3 or 8.0.4 on Windows NT Korean version patch level 3.  Run the widget demo program and attempt to use an entryfield.  The program will crash from a memory access exception. The problem likely exists on all similar Asian language versions of Windows NT.

  ObservedBehavior:
  The revised tk 8.0.3 win/tkWinFont.c Tk_MeasureChars function crashes during use of an entryfield.  The crash is in GDI during the call to GetTextExtentPoint().   

  Patch:
  The problem is avoided by substituting the patch level 2 win/tkWinFont.c file into Tk patch levels 3 or 4.  



  upgrade to 8.1, which supports international character sets.
  04/16/1999 13:42 - stanton -


tkt_uuid: 1845590fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Later
title: ttk_setPalette wanted
comment:
  tk_setPalette is unable to change the palette used by "themed widgets" - so, there's a need for such counterpart.

  Nowadays the users are expecting the applications with sophisticated "look & feel" - and because of this a demand for "skinnable user interfaces". Although making "skins" could require a lot of work to change every single widget, it could be in some way replaced using present "ttk styled widgets", but *together* with possibility to change the colours - which, unfortunately, currently isn't available for themed widgets.

  I'm not sure - but it seems, that the existing routines used by tk_setPalette, tested during years of development, could be used in suggested ttk_setPalette as well, so it wouldn't require much work to add such command?


tkt_uuid: 561708ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Make transient state mirror master state
comment:
  Here is a patch that changes the way transient windows
  and master windows work. The current implementation
  supports iconify of the transient when the master is
  iconified, but this does not work if you withdraw
  the master. Here is a quick example.

  toplevel .s ; toplevel .m
  wm transient .s .m

  If I run [wm iconify .m] at this point, both windows
  vanish from the display. If I were to instead run
  [wm withdraw .m] only the master window would be
  unmapped. The exact state that the transient is in
  at this point differs under Win32 and X. One might
  expect [wm deiconify .m] to work the same for a
  withdrawn master and an iconified master, but that
  too is broken.

  I have written up a bunch of test cases that deal
  with all of these state changes and the results
  under Win32 and X match exactly after my patch
  is applied. The patch also fixes a number of bugs
  in the current Win32 and X implementations of the
  wm transient command. I would feel much better about
  this change if someone could take a look at it to
  see if anything jumps out at them. I have run the
  full test suite under X and Win32 and the patch
  does not cause any failures.


tkt_uuid: 220574ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 24. Relief
priority: 2
foundin: obsolete: 8.2b1
resolution: Fixed
title: Improve seletion of 3D colors
comment:
  OriginalBugID: 2501 RFE
  Version: 8.2b1
  SubmitDate: '1999-08-04'
  LastModified: '2000-04-13'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All
  Machine: Other
  FixedDate: '2000-04-13'
  FixedInVersion: 8.3.1


  Name:

  D. Richard Hipp



  CVS:

  Aug 1, 1999



  Comments:

  There are constants in the algorithm (ex: to decide when to begin

      using the alternative algorithm) which I have determined empirically.

      I make no claim that the algorithm given is optimal in any way.

      I do, however, think it works better than the existing algorithm.

      

      I'd appreciate a quick e-mail if and when you decide to either

      incorporate or reject this patch.  That will help me plan what

      I need to do to work around this problem.



  DesiredBehavior:

  When the background color is nearly white or nearly black, then Tk

      does a poor job of chosing shadow colors for the 3D borders.  The

      patches given below use the existing shadow-color algorithm for most

      instances, but substitute a different algorithm when the background

      color becomes too bright or too dark.



  Patch:

  *** tkUnix3d.c.orig     Wed Aug  4 13:16:22 1999

  --- tkUnix3d.c  Wed Aug  4 14:15:42 1999

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

  *** 339,344 ****

  --- 339,345 ----

    {

        XColor lightColor, darkColor;

        int stressed, tmp1, tmp2;

  +     int r, g, b;

        XGCValues gcValues;

    

        if (borderPtr->lightGC != None) {

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

  *** 359,401 ****

        if (!stressed && (Tk_Depth(tkwin) >= 6)) {

          /*

           * This is a color display with lots of colors.  For the dark

  !        * shadow, cut 40% from each of the background color components.

           * For the light shadow, boost each component by 40% or half-way

           * to white, whichever is greater (the first approach works

           * better for unsaturated colors, the second for saturated ones).

           */

    

  !       darkColor.red = (60 * (int) borderPtr->bgColorPtr->red)/100;

  !       darkColor.green = (60 * (int) borderPtr->bgColorPtr->green)/100;

  !       darkColor.blue = (60 * (int) borderPtr->bgColorPtr->blue)/100;

          borderPtr->darkColorPtr = Tk_GetColorByValue(tkwin, &darkColor);

          gcValues.foreground = borderPtr->darkColorPtr->pixel;

          borderPtr->darkGC = Tk_GetGC(tkwin, GCForeground, &gcValues);

    

          /*

  !        * Compute the colors using integers, not using lightColor.red

  !        * etc.: these are shorts and may have problems with integer

  !        * overflow.

           */

    

  !       tmp1 = (14 * (int) borderPtr->bgColorPtr->red)/10;

  !       if (tmp1 > MAX_INTENSITY) {

  !           tmp1 = MAX_INTENSITY;

  !       }

  !       tmp2 = (MAX_INTENSITY + (int) borderPtr->bgColorPtr->red)/2;

  !       lightColor.red = (tmp1 > tmp2) ? tmp1 : tmp2;

  !       tmp1 = (14 * (int) borderPtr->bgColorPtr->green)/10;

  !       if (tmp1 > MAX_INTENSITY) {

  !           tmp1 = MAX_INTENSITY;

  !       }

  !       tmp2 = (MAX_INTENSITY + (int) borderPtr->bgColorPtr->green)/2;

  !       lightColor.green = (tmp1 > tmp2) ? tmp1 : tmp2;

  !       tmp1 = (14 * (int) borderPtr->bgColorPtr->blue)/10;

  !       if (tmp1 > MAX_INTENSITY) {

  !           tmp1 = MAX_INTENSITY;

          }

  !       tmp2 = (MAX_INTENSITY + (int) borderPtr->bgColorPtr->blue)/2;

  !       lightColor.blue = (tmp1 > tmp2) ? tmp1 : tmp2;

          borderPtr->lightColorPtr = Tk_GetColorByValue(tkwin, &lightColor);

          gcValues.foreground = borderPtr->lightColorPtr->pixel;

          borderPtr->lightGC = Tk_GetGC(tkwin, GCForeground, &gcValues);

  --- 360,440 ----

        if (!stressed && (Tk_Depth(tkwin) >= 6)) {

          /*

           * This is a color display with lots of colors.  For the dark

  !        * shadow, cut 40% from each of the background color component.

  !        * But if the background is already very dark, make the

  !        * dark color a little lighter than the background by increasing

  !        * each color component 1/4th of the way to MAX_INTENSITY.

  !        *

           * For the light shadow, boost each component by 40% or half-way

           * to white, whichever is greater (the first approach works

           * better for unsaturated colors, the second for saturated ones).

  +        * But if the background is already very bright, instead choose a

  +        * slightly darker color for the light shadow by reducing each

  +        * color component by 10%.

  +        *

  +        * Compute the colors using integers, not using lightColor.red

  +        * etc.: these are shorts and may have problems with integer

  +        * overflow.

  +        */

  + 

  + 

  +       /*

  +        * Compute RGB value for the dark shadow

           */

    

  !       r = borderPtr->bgColorPtr->red;

  !       g = borderPtr->bgColorPtr->green;

  !       b = borderPtr->bgColorPtr->blue;

  !       if (r*0.5*r + g*1.0*g + b*0.28*b < MAX_INTENSITY*0.05*MAX_INTENSITY) {

  !           darkColor.red = (MAX_INTENSITY + 3*r)/4;

  !           darkColor.green = (MAX_INTENSITY + 3*g)/4;

  !           darkColor.blue = (MAX_INTENSITY + 3*b)/4;

  !       } else {

  !           darkColor.red = (60 * r)/100;

  !           darkColor.green = (60 * g)/100;

  !           darkColor.blue = (60 * b)/100;

  !       }

  !   

  !       /*

  !        * Allocate the dark shadow color and its GC

  !        */

          borderPtr->darkColorPtr = Tk_GetColorByValue(tkwin, &darkColor);

          gcValues.foreground = borderPtr->darkColorPtr->pixel;

          borderPtr->darkGC = Tk_GetGC(tkwin, GCForeground, &gcValues);

    

          /*

  !        * Compute the RGB components of the light shadow

           */

    

  !       if (g > MAX_INTENSITY*85/100) {

  !           lightColor.red = (90 * r)/100;

  !           lightColor.green = (90 * g)/100;

  !           lightColor.blue = (90 * b)/100;

  !       } else {

  !           tmp1 = (14 * r)/10;

  !           if (tmp1 > MAX_INTENSITY) {

  !               tmp1 = MAX_INTENSITY;

  !           }

  !           tmp2 = (MAX_INTENSITY + (int) borderPtr->bgColorPtr->red)/2;

  !           lightColor.red = (tmp1 > tmp2) ? tmp1 : tmp2;

  !           tmp1 = (14 * (int) borderPtr->bgColorPtr->green)/10;

  !           if (tmp1 > MAX_INTENSITY) {

  !               tmp1 = MAX_INTENSITY;

  !           }

  !           tmp2 = (MAX_INTENSITY + (int) borderPtr->bgColorPtr->green)/2;

  !           lightColor.green = (tmp1 > tmp2) ? tmp1 : tmp2;

  !           tmp1 = (14 * (int) borderPtr->bgColorPtr->blue)/10;

  !           if (tmp1 > MAX_INTENSITY) {

  !               tmp1 = MAX_INTENSITY;

  !           }

  !           tmp2 = (MAX_INTENSITY + (int) borderPtr->bgColorPtr->blue)/2;

  !           lightColor.blue = (tmp1 > tmp2) ? tmp1 : tmp2;

          }

  ! 

  !       /*

  !        * Allocate the light shadow color and its GC

  !        */

  ! 

          borderPtr->lightColorPtr = Tk_GetColorByValue(tkwin, &lightColor);

          gcValues.foreground = borderPtr->lightColorPtr->pixel;

          borderPtr->lightGC = Tk_GetGC(tkwin, GCForeground, &gcValues);



  PatchFiles:

  The patch above is for unix/tkUnix3d.c.  A similar change will need to

      be

      made to win/tkWin3d.c.  (I don't have VC++6.0, so I have no means to

      test

      such a change.)





  I applied this patch to the sources in CVS; it will go out with 8.3.1.  Thanks for the great patch (contrary to your claim, I applied it virtually unaltered).

  - eric

  -- 04/13/2000 ericm


tkt_uuid: 822002ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Duplicate
title: Clipboard is lost on exit
comment:
  This report is based on the OS/2 port, likely (and
  reportedly) to behave the same in Windows. Unix too???

  The current clipboard code is message based.  When you
  put something to clipboard, Tk claimes itself the owner
  of clipboard.  But it does not put there anything yet
  (somebody thought that this is an optimization?!). 
  When another application requests clipboard contents,
  the owner (Tk) is notified (via a message), and then it
  fills the contents. However, if nobody asks, Tk won't
  put anything when it exits.

  On exit, the owner of the clipboard gets a message
  requesting filling the clipboard.  On OS/2 this is
  WM_RENDERALL (sp?).  Tk throws this message away; it
  should not, and should process it as another message
  requesting clipboard contents.

  Jeff Hobbs writes at c.l.t.:
  "...If you actually do paste the copied data from the
  clipboard once, it will remain there after the app
  exits.  The one thing that is missing is that Tk
  doesn't force the copy onto the
  clipboard at app exit.  The reason Tk is lazy in the
  copy is to prevent large data sets being copied..."

  My personal view is there should be both a "lazy"
  method, to "prevent large data sets being copied", and
  a "force" method, to make sure the new clipboard
  content will be there after an exit. The programmer can
  always check the size of the data currently stored in
  the clipboard and choose between the "lazy" or "force"
  methods on exit.


tkt_uuid: 3002230fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 7 High
foundin: obsolete: 8.5.8
resolution: Fixed
title: tk_chooseDirectory returns garbage on cancel
comment:
  This happens only on Windows 2000.

  Do as follows:
  in the console issue tk_chooseDirectory command, then when the dialog pops up, press the "Cancel" button. The console prints some garbage characters.
  On Windows XP onwards, in the same circumstances, the result is an empty string (or, better said, there's no result, as the user cancelled the dialog).


tkt_uuid: 220852ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: final: 8.1.1
resolution: Fixed
title: Vertical width=1 stippled lines invisible
comment:
  OriginalBugID: 2296 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-28'
  LastModified: '1999-10-22'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: 4.00.951
  Machine: X86


  Name:
  John Nakulski

  ReproducibleScript:
  # Program to demonstrate the Tk "vertical width=1 stippled line" bug
      canvas .c
      pack .c
      .c create line 10 10 30 30 -stipple gray75 ;# diagonal line works fine
      .c create line 10 10 30 10 -stipple gray75 ;# horizontal line doesn't
      show!
      .c create line 10 10 10 30 -stipple gray75 ;# vertical line doesn't
      show!

  ObservedBehavior:
  Vertical and horizontal lines of width=1 that are stippled do not show
      on a canvas! The command executes, but nothing happens on the canvas.
      - Lines of greater width are OK (visible)
      - Lines that are not stippled are OK (visible)
      - Diagonal lines are OK (visible)
      The problem is only with lines that are width=1, stippled, AND not
      diagonal (i.e., horizontal or vertical).

  DesiredBehavior:
  The lines should be visible.


tkt_uuid: 1202181fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: TkAqua: scrollbar thumb position wrong when shown
comment:
  If a scrollbar is currently set to range 0 - 1, so that
  the thumb isn't shown, and then set to any range in
  between (e.g. 0 - 0.5), the thumb is shown at the
  bottom (vertical) or right (horizontal) end, even
  though the range is such that it should be shown at the
  top/left end.  It won't respond to clicks/drags until
  you click the down/right arrows, and then it will jump
  to the top/left side.  Here's a short script to
  demonstrate:

  wm geometry . 40x300
  pack [scrollbar .s -orient vertical] -fill y -expand 1
  .s set 0 1
  .s set 0 .5

  I've isolated the problem to be the order in which the
  Carbon scrollbar is configured for its value and range
  in UpdateControlValues().  Currently, it sets the
  current value, then the maximum, then the minimum.  But
  when the Tk scrollbar range is 0 - 1, it has the Carbon
  scrollbar minimum set to 100000.  When
  SetControl32BitValue() is called, Carbon sees that the
  value being set is out of range and changes the value
  to the same.  Then the maximum/minimum are set, but the
  value is outside the range.

  Moving the call to SetControl32BitValue() down after
  the minimum and maximum are set seems to correct this
  particular one of several weird aqua scrollbar issues
  for me.


tkt_uuid: 3582795fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: Virtual Bindings incompatible with previous versions of Tk
comment:
  Since 8.6b3, bindings do not appear to work the same way as before in applications. See for example this thread on c.l.t about tkcon - 
  https://groups.google.com/forum/?fromgroups=#!searchin/comp.lang.tcl/tkcon$20bindings/comp.lang.tcl/7ki8-TxMNdk/bn7lr7LTmUwJ

  dkf suggested in that thread this might be a result of the new virtual event definitions added for 8.6b3.

  Is this a temporary state of affairs that will be fixed for 8.6 final? If not, is there any document that describes the changes applications will have to make, and does this not spoil Tcl/Tk's great backward compatibility.

  /Ashok


tkt_uuid: 1609465fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.4.14
resolution: Works For Me
title: Zero Page error in tkTextDisp.c
comment:
  Hi,
  I have a crash in my TCL/Tk application because of a corrupted pointer in tkTextDisp.c.  We get this crash on UNIX, when we use a text widget to show our log file.
  The exact location of the corrupted pointer is line 2279 in tkTextDisp.c
   
  Below is source code snippet:
  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
      /*
       * First recompute what's supposed to be displayed.
       */
      
      UpdateDisplayInfo(textPtr);
      dInfoPtr->dLinesInvalidated = 0;
      
      /*
       * See if it's possible to bring some parts of the screen up-to-date
       * by scrolling (copying from other parts of the screen).
       */
      
      for (dlPtr = dInfoPtr->dLinePtr; dlPtr != NULL; dlPtr = dlPtr->nextPtr) {   ----------------------> dlPtr is corrupted after many many iterations
          register DLine *dlPtr2;
          int offset, height, y, oldY;
          TkRegion damageRgn;
      
          if ((dlPtr->oldY == -1) || (dlPtr->y == dlPtr->oldY)
                  || ((dlPtr->oldY + dlPtr->height) > dInfoPtr->maxY)) {
              continue;
          }
      
  +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       
  We are filtering (i.e., hiding, raising) a lot of messages in our text widget using 'elide' option and 'tag raise' command.
  Has anybody seen this kind of problem before ?
  The version of Tk we are using is 8.4.14
   
  Thanks,
   
  Kishore Kollu
  kishore_kollu@mentor.com 
  Mentor Graphics


tkt_uuid: 1669387fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: Out of Date
title: On MacOS X buttons don't show images with alpha transparency
comment:
  When you create a button on Mac with a -image that is a png image with transparency (aMSN uses TkCxImage to get this) a white button is being showed, instead of the actual image. This work normally on windows and linux. Also on Mac, when you use a label with -image it works as expected.


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

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

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

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

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

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

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

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

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

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

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


tkt_uuid: 220520ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Wish has old copyright notice in About Help (1996 Sun Micro)
comment:
  OriginalBugID: 2022 Bug
  Version: 8.1.1
  SubmitDate: '1999-05-10'
  LastModified: '1999-08-08'
  Severity: LOW
  Status: Released
  Submitter: foster
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-08'
  FixedInVersion: 8.2


  Seems like the copyright notice in the About Box under the Help menu in wish should mention Scriptics.



  This is correct in the 8.2b2 release. 
  -- 08/08/1999 hobbs


tkt_uuid: 1785511fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 8
foundin: obsolete: 8.4.15
resolution: None
title: "unknown display passed to Tk_PreserveColormap"
comment:
  This error is hard to reproduce. The number of images
  is not critical. The reuse of the image names when recreating the images may be.

  Basic method.

     create a canvas widget
     create three gif images with "image create photo"
     create three image items on the canvas.

     delete the three images
     re-source the script above.
     do not call update or update idletasks between
     image deletion and re-creation.

  The panic appears to happen at the time the images are recreated and before they are added to the canvas although this cannot be confirmed.
     
  It is likely that the cause of the error is the fact that the original images are deleted via an idle callback which has not fired by the time they are re-created and the new images that are recreated using the same names are being deleted by the idle call back which now fires for the three original images.


tkt_uuid: 2931720fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 1 Zero
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: Cocoa Tk loses double click events
comment:
  In the Mac Cocoa Tk (CVS source code from January 8, 2010) double click events are not produced for toplevel windows with an active button.  The following Wish script illustrates the problem:

  label .l -text filename
  pack .l
  button .b -text Open -default active
  pack .b
  bind .l <Double-ButtonRelease-1> {puts "double click"}
  bind .l <ButtonRelease-1> {puts "single click"}

  Double clicking on the label with text "filename" does not print "double click" as it should (once in a while it does but rarely).  The double click events are not produced in Cocoa Tk but they are produced by Aqua Carbon Tk 8.5.8 and Linux and WIndows Tk.  Removing the "-default active" from the button makes this work on Cocoa Tk.  If instead we bind single and double clicks to the toplevel widget it works correctly in Cocoa.  Binding the mouse events to a child (the label) is needed to produce the bug.

  This problem occurs in a file browser dialog for the UCSF Chimera molecular graphics program where double clicking on a file name is supposed to open the file.  We are working on a 64-bit Cocoa port of this program.


tkt_uuid: 220496ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 82. X11 Emulation
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: Xlib.h not usable together with GNU Win32 header (Windows32/Stuctures.h)
comment:
  OriginalBugID: 1804 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-14'
  LastModified: '1999-05-07'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: Windows NT
  Machine: X86
  FixedDate: '1999-05-07'
  FixedInVersion: 8.1


  Name:
  Jan Nijtmans

  Comments:
  This change is exactly how Cygnus already solved this problem
      in its own Tcl/Tk version. It is not a bug in a GNU-Win32
      header-file, it's simply the fact that "Status" is a valid field
      name in an already existing structure. The macro in <Xlib.h>
      is dangerous because it replaces "Status" with "int"
      everywhere, even if it results in syntactically incorrect
      program code. Changing this in a typedef solves this,
      without any undesired side-effects.

  ReproducibleScript:
  Compile any extension with mingw32 or cygwin, thereby including
      <X11/Xlib.h>
      before <windows.h>. The compiler (gcc or egcs) gives an error-message
      because "int" is not a valid variable name.
      
      The problem comes because "Status" is also a variable name in some
      internal structures in the "Windows32/Stuctures.h" header-file.

  ObservedBehavior:
  Compiler warning: "empty declaration", but in fact this
      warning is fatal in some situations. De compiler tries
      to fix this by splitting an int member-variable into two
      empty int member variables. In this case that is totally
      wrong, which can result in undesired behaviour very
      difficult to track down. Therefore I strongly suggest
      that this is fixed in Tk's <X11/Xlib.h> header file.

  Patch:
  *** Xlib.h.origMon Apr 05 19:48:32 1999
  --- Xlib.hWed Apr 14 16:15:52 1999
  ***************
  *** 58,64 ****
    typedef char *XPointer;
    
    #define Bool int
  ! #define Status int
    #define True 1
    #define False 0
    
  --- 58,64 ----
    typedef char *XPointer;
    
    #define Bool int
  ! typedef int Status;
    #define True 1
    #define False 0

  PatchFiles:
  X11/Xlib.h


tkt_uuid: 403328ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Fix for Bug 229358
comment:
  I submitted this patch at the tcl project (#102472),
  but it belongs here. Can somebody please delete it at 
  the tcl project?

  This patch fixes the clipping of embedded canvas
  (see Bug #129358). 

  It works for me, but I'm not a postscript expert. Could someone with more knowledge please look, if this is the 
  right way and place to do it?

  Peter


tkt_uuid: 220211ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: Unacceptably wide right-margin of menu's (since Tk8)
comment:
  OriginalBugID: 2342 Bug
  Version: 8.0.5
  SubmitDate: '1999-07-07'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: HP-UX
  Machine: Other
  ClosedDate: '1999-08-20'


  Name:
  Ed Knapen

  ReproducibleScript:
  The script can be found at: http://www.knapen.com/ed/tcl_test.tcl
      Example output for Tcl/Tk 7.5/4.1 and TclPro1.2 is given in 
       http://www.knapen.com/ed/tcl_test.gif

  ObservedBehavior:
  Previously (upto Tcl/Tk 7.5/4.1) the righthandside margin of a menu was
  nicely small. Now it is unacceptably big. This example comes from an air
  traffic control application where you want menu's to be as small as possible. Use of options does not decrease this width.

  DesiredBehavior:
  By using some option, the old style margin should be possible.



  I cannot access the above URLs.  With 8.0, a more native LAF was
  added, which not all have favored.  On Unix, this should not have
  changed size, but there may be X resources that are being picked
  up and disturbing the LAF.  A more native menu approach was also
  added, which can be found in the 'menu' docs. 
  -- 08/20/1999 hobbs


tkt_uuid: 220742ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Core Dump When Exiting Wish After Listbox Cursor Change
comment:
  OriginalBugID: 5760 Bug
  Version: 8.3
  SubmitDate: '2000-05-31'
  LastModified: '2000-06-02'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: OpenBSD 2.6 i386
  Machine: Pentium II 266MHz
  FixedDate: '2000-06-02'
  FixedInVersion: 8.3.1


  Name:
  George Peter Staplin

  Comments:
  A core dump does not occur if the listbox is packed into a frame and the
      cursor of the frame is changed.  A core dump also occurs if I use .l
      config -cursor watch instead of specifying it during creation.  So, I
      believe that something is wrong with the listbox.

  ReproducibleScript:
  $ wish8.3
  % listbox .l -cursor watch
  % pack .l

  % exit

  Memory fault (core dumped)

  ObservedBehavior:
  I have observed that when the listbox cursor is changed a core dump occurs when exiting wish.

  DesiredBehavior:
  I expect a core dump to not occur when exiting wish.



  This is already fixed in 8.3.1.  The work-around is to unconfigure
  the cursor before deleting. 
  -- 06/02/2000 hobbs


tkt_uuid: 1731348fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 43. Photo Image|PPM
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Fixed
title: photo man page misleading about base64 support
comment:
  The photo(n) man page says

   -data string
                Specifies the contents of the image as a string.  The string can contain base64 encoded data or binary data. [...]

  But this is only true for GIF images. The PPM handler completely lacks the base64 support.

  kind regards
  -- 
  Matthias Kraft


tkt_uuid: 1460155fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: X11+Cygwin should be okay
comment:
  the more I use X11 at work, the more I need to also to
  use Tcl/Tk within X11
  on cygwin.
  Tcl/Tk coming with cygwin is built with Win32 native
  GUI, but I want
  different approach.

  Tk is actually cleanly builds in such a configuration,
  except for a small
  quirk.

  Attached patch is trivial but relies on fact that X.h
  defines X_PROTOCOL.
  I am very weak at X11/c programming so I could be wrong
  with exact details,
  but please consider solving this problem somehow.

  BTW I tested whether cygwin and win32/msvc++ build okay
  with suggested change.


tkt_uuid: 1712009fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: UnixSend strict-alias
comment:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c: In function ‘RegOpen’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c:293: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c: In function ‘ValidateName’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c:605: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c: In function ‘SendEventProc’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c:1365: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c: In function ‘TkpTestsendCmd’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c:1926: warning: dereferencing type-punned pointer will break strict-aliasing rules


tkt_uuid: 1958848fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 78. Other Demos
priority: 5 Medium
foundin: None
resolution: Fixed
title: Intentionality failure in widget demo
comment:
  On the 'canvas item types' screen of this demo there is a button (embedded widget) that says 'Press Me'. But when you press it it says 'Ouch!!' Since it is asking to be pressed it should say 'Thank you'.


tkt_uuid: 450020ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Invalid
title: Messages for czech language
comment:
  Hi,

  I post file of messages for Tk in czech language.
  I wil be happy to include this i distribution.

  Commenst are welcome.

  Michal


tkt_uuid: 3095112fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.9
resolution: Fixed
title: crash when selecting file from Win7 Library
comment:
  tk_OpenFile crashes when I select file from Windows 7 virtual folders called "Libraries". sometime it display error message saying: "alloc: "invalid block: 0812C188: ef ef 0". ", sometime crashed silenly.
  It reproduces both with latest ActiveTcl 8.5.9 distribution and with self-compiled tcl/tk 8.5.9.


tkt_uuid: 907323ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: None
title: "Modernise" keysyms (PgUp and PgDn)
comment:
  I noticed that some common keys found on most modern
  keyboards are not in the present list of keysyms or
  only under an obbscure synonym.

  Most noticeably these are: PgUp and PgDn.
  They are present under the "old" names Prior and Next,
  which to the average programmer used to PC keyboards
  will not be obvious.


tkt_uuid: 496669ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: None
title: last selected char without selectbg
comment:
  I use Windows 2000.

  When I select a pièce of text in an entry widget the 
  background color of the last char of the selection is 
  wrong.

  All selected char have the good foreground color 
  (selectforegound).
  All selected char but the last have the good 
  background color (selectbackground).
  The last selected char keeps its previous background 
  color.

  ulis


tkt_uuid: 535541ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: None
resolution: Accepted
title: XFree86 Anti-Aliased text patches
comment:
  The following patches are what I received from Keith 
  Packard ( http://www.xfree86.org/~keithp/) that added 
  anti-aliased XFree86 text support to Tk on Unix.  It 
  did it by removing lots of other functionality 
  though.  From Keith:

  ----
  It's entirely a hack at some level.  When you deal 
  with TrueType fonts, 
  you can always get an ISO 10646 (UCS) encoding, so for 
  languages well 
  served using that as a glyph encoding things are 
  really easy.

  It would be better if the hacks were fixed to manage 
  the i18n aspects that 
  tk has done in the past, but I don't understand them 
  well enough to do a 
  good job, nor have I figured out what Xft should do to 
  help solve the 
  problem.
  ----

  I'm attaching his patch, which was likely against 
  8.3.x so it doesn't get lost again.  It is a tgz with 
  two files that belong in tk/unix/.


tkt_uuid: 3553547fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: tk_getOpenFile -multiple 1 on linux, selection behaviour
comment:
  Activestate Tk 8.5.11, also the just released 8.5.12, OpenSuse 11.4 (if it matters)

  While tk_getOpenFile -multiple 1 on windows opens a file dialog which
  behaves as other dialogs allowing multiple selections of items (dragging
  the mouse selects multiple items, Control-mouse adds a single item to
  the selection, Shift-keyboard traversal also selects multiple items),

  on Linux the behaviour is strange IMHO:
  - in order to select multiple items I have to Shift-Drag the mouse
    (would have expected simple drag)
  - multiple selection via keyboard using shfit-up/down is not possible at all
    (would have expected to Shift-Arrow-Up/Down-select files)

  This comes unexpected, since:
  - Control-mouse selects a single item as expected
  - Shift-Mouse also extends the selection as expected

  Even if -multiple 0 is specified, Shift-Mouse-Motion draws a selection
  where it shouldn't.  While it actually selects only a single item, it
  shows multiple as selected.

  Also if the mouse leaves the window, the selected items are no longer
  shown as selected (though the selection still exists and is re-shown if
  changed).


tkt_uuid: 220058ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Duplicate
title: Canvas -stipple and -outline stipple options have no effect with $w create oval
comment:
  OriginalBugID: 4077 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-24'
  LastModified: '2000-03-27'
  Severity: LOW
  Status: Closed
  Submitter: shawn
  ChangedBy: hobbs
  RelatedBugIDs: 1274 4081
  OS: Windows NT
  ClosedDate: '2000-03-27'


  Canvas -stipple and -outline stipple options have no effect with $w create oval.  

  Reproducible script: 

  canvas .a 
  pack .a 
  .a create oval  0 40 20 20 -fill red -stipple gray75 -outline red  -outlinestipple gray75
  .a create rectangle   0 80 20 100 -fill red -stipple gray75 -outline red  -outlinestipple gray75

  expected results: 

  I expect both the rectangle and the oval to be the same - and show the bitmap stipple.


tkt_uuid: 3480471fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.5.10
resolution: Fixed
title: tk_getOpenFile crashes on Win64
comment:
  On Windows x64, when running a 64bit wish 8.5.10 and after allocating and using lots of memory (above 2GB), wish crashes immediately when selecting a File in a tk_getOpenFile dialog. We tracked the problem down to the function OFNHookProcW in  tkWinDialog.c.

  Referencing tk 8.5.10, in line 1035-1040 of tkWinDialog.c, there is the following piece of code:

  SendMessageW(hdlg, CDM_GETFOLDERPATH, dirsize, (int) buffer);
  buffer += dirsize;
  SendMessageW(hdlg, CDM_GETSPEC, selsize, (int) buffer);

  The crash is caught by the debugger in the line
  buffer += dirsize;
  but the mistake resides in the lines above and below:
  The last argument of SendMessageW is declared  as LPARAM
  (see http://msdn.microsoft.com/en-us/library/windows/desktop/ms644950(v=vs.85).aspx), which is defined as LONG_PTR which is defined as __int64 when building with 64bit (see http://msdn.microsoft.com/en-us/library/aa383751(v=VS.85).aspx)

  When buffer starts above 2GB adress (this makes it a little difficult to reproduce this error), the cast to int cuts the upper part of the adress and things become very wrong and wish crashes.

  Changing those lines to 
  SendMessageW(hdlg, CDM_GETFOLDERPATH, dirsize, (__int64) buffer);
  buffer += dirsize;
  SendMessageW(hdlg, CDM_GETSPEC, selsize, (__int64) buffer);

  makes everything fine.
  The correct all-platform fix should cast to (LONG_PTR), imho.

  This error also occours in tk 8.5.11 (although these lines are different, but PTR2INT makes the same mistake as the int-cast) and in tk 8.6b2


tkt_uuid: 874745ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 7 High
foundin: obsolete: 8.5a0
resolution: Accepted
title: Tk accesses Tcl_*StartupScript*() which is private to Tcl
comment:
  DynamicLibrary /Users/espectro/tk/macosx/../../build/tk/
  Tk.framework/Versions/8.5/Tk 

  DynamicLibrary.LinkUsingFileList /Users/espectro/tk/macosx/
  ../../build/tk/Tk.framework/Versions/8.5/Tk 
      /usr/bin/gcc-3.3  -o /Users/espectro/tk/macosx/../../
  build/tk/Tk.framework/Versions/8.5/Tk   "-L/Users/espectro/
  tk/macosx/../../build/tk"  "-F/Users/espectro/tk/macosx/../
  ../build/tk" "-F/Users/espectro/tk/macosx/../../build/tcl"  
  -filelist /Users/espectro/tk/macosx/../../build/tk/
  Development.build/Wish.build/TkLibrary.build/Objects-
  normal/LinkFileList  "-framework" "Tcl" "-framework" 
  "Carbon" "-framework" "ApplicationServices"  "-arch" "ppc" 
  "-prebind" "-Wl,-single_module" "-dynamiclib" "-
  compatibility_version" "8.5" "-current_version" "8.5" "-
  seg1addr" "0xb000000" "-prebind"  -install_name "`echo "/
  Library/Frameworks/Tk.framework/Versions/8.5/Tk" | /usr/
  bin/sed 's!//*!/!g'`" 
  ld: warning prebinding disabled because of undefined 
  symbols
  ld: Undefined symbols:
  _TclUtfToUniChar
  /usr/bin/libtool: internal link edit command failed
  ...failed DynamicLibrary.LinkUsingFileList /Users/espectro/tk/
  macosx/../../build/tk/Tk.framework/Versions/8.5/Tk ...
  ** BUILD FAILED **
  make: *** [develop] Error 1

  8.4.5 compiles fine
  Using OSX Panther

  BTW, pbxbuild doesn't exist anymore. It's xcodebuild now


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


tkt_uuid: 1493260fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Fix for bug 220787 - Stipple patterns don't work in arc/oval
comment:
  Hello all,
     I have a fix for the Windows version.  I will post
  the diff as a file here.

  My tkWinDraw.c reads:

  RCS: @(#) $Id: tkWinDraw.c,v 1.12.2.2 2005/07/28
  04:57:38 hobbs Exp $


tkt_uuid: 854146ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Works For Me
title: focus is lost, preventing dialog interaction (8.5ok, 8.4bug)
comment:
  Here is a simple test case:

  ###
  toplevel .foo -class Dialog
  for {set i 0} {$i < 20} {incr i} {
      lappend items $i
  }
  message .foo.msg -text "Click on the popup\
    menu and make sure you select an item on\
    the menu which falls outside the bounding box\
    of this toplevel, so that when the menu\
    disappears your mouse is hovering over your\
    desktop (or some other app).  Then, without\
    doing anything else, try to click on the\
    button.  This fails!"
  pack .foo.msg -side top
  eval [list tk_optionMenu .foo.m menuvar] $items
  button .foo.b -text "Push" -command {
      tk_messageBox -message yes
      set done 1
  }
  pack .foo.m .foo.b -side left
  wm withdraw .foo
  update idletasks
  wm deiconify .foo
  grab .foo
  tkwait variable done
  grab release .foo
  ###

  On Windows (2000,XP at least), double click on a .tcl
  file containing the above.  You will see a new toplevel
  (dialog, effectively) containing a popup menu and a
  button, and a grab on the toplevel. The problem arises
  (it seems) that when you select an item from the popup,
  on releasing the mouse, the focus is lost and then when
  you move the mouse back over the window and over the
  "Push" button that button doesn't receive 'enter' or
  'leave' events, and the tk::Priv(window) variable is
  therefore not set, and so when you click on the button
  this block of code:

  if {$Priv(window) eq $w && [$w cget -state] ne
  "disabled"} {
      $w configure -state normal

      # Only invoke the command if it wasn't already
  invoked by the
      # auto-repeater functionality
      if { $Priv(repeated) == 0 } {
  uplevel #0 [list $w invoke]
      }
  }

  is never triggered, and so no action is invoked.

  Notice that if you select an item from the popup which
  happens to be on top of the underlying dialog, then
  everything works ok.

  If have no idea how to fix this at all, and don't know
  whether the button.tcl code should be more flexible
  about Priv(window) not being set, or whether the menu
  selection code should be better at setting the focus
  (esp. when there is a grab in place)...


tkt_uuid: 3541305fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Fixed
title: Xfree/Xsync... shoulc not be macros
comment:
  In order to allow win32 extensions that use
  Xfree/Xsync ... to run under Cygwin as well
  (See presentation Eurotcl 2012), they
  should not be macro's but functions.

  In Tk 8.6 that's already done, but in 8.4/8.5
  it's possible to do the same thing, only the
  macro should detect whether the related
  stub functions are available or not.
  (Tk8.5.12+ has it, but not earlier versions)

  The stub entry tkIntStubsPtr->tkBindDeadWindow
  can be used for that. If it's NULL, then
  the stub functions are available (This
  stub entry is purposely removed on Cygwin
  8.4/8.5, and completely in 8.6, just because
  it serves no purpose)

  Solution:
  #ifdef USE_TK_STUBS
  #define XFree(data) (tkIntStubsPtr->tkBindDeadWindow? ((data)? (ckfree((char *) (data)), 0): 0): tkIntXlibStubsPtr->xFree(data))
  #else
  .... original definition
  #elseif


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


  Name:
  Malcom Terry

  Extensions:
  Tk

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

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

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

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



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

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

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

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

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

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

  -- 08/09/2000 ericm


tkt_uuid: 1818441fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.5b2
resolution: Fixed
title: combobox wrong in detached window
comment:
  Run the widget demo. Run the toolbar demo within it. Tear off the toolbar. Now try to use the combobox's drop-down list. Observe the fact that it is now clipped by the toplevel (or is that the combobox?) Kill the toolbar so that it is re-docked. Observe the fact that the drop-down list is still clipped.

  This Is Not Good.


tkt_uuid: 1731734fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Out of Date
title: Aqua preview 8.4.15 menubutton cascade menus don't display
comment:
  In the 8.4.15 Aqua preview from DAS, cascade menus on menubuttons don't display on mouseover. You can't get to the cascaded menus.

  They do work fine on menus in the menubar, only problems are on menus attached to menubuttons.



  contact me at:
  m dot wayne dot davis at gmail tod com
  for any questions

  example:

    grid [menubutton .type -menu .type.menu -textvariable temp_info(type) -font labelfont -width 10] -row 0 -column 2
    menu .type.menu

    set divided_typelist [list A [list 1 2 3 4] B [list 5 6 7 8]] 

    foreach {header types} $divided_typelist {

      .type.menu add cascade -label $header -menu [menu .type.menu.[string tolower $header]]

      foreach type $types {

        .type.menu.[string tolower $header] add radiobutton -label $type -variable temp_info(type) -value $type -command ""

      


tkt_uuid: 830664ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Out of Date
title: README doc bug
comment:
  tk8.3.4 unix/README reads (line 28):
  "(a) Make sure that the Tcl 8.3 release is present in the directory ../../tcl8.3"

  This doesn't work. I have used Tcl 8.3 release tcl 8.3.4 and named the directory tcl8.3 and compilation error resulted in tk. There should probably be:

  "(a) Make sure that the Tcl 8.3.x release is present in the directory ../../tcl8.3.x"


tkt_uuid: 1704708fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Fixed
title: Aqua Tk does not compile; botched macros
comment:
  The new LOG_MSG macro breaks
  the HEAD.  First few error messages
  from a default compile attempt:

  /Users/don/tk/macosx/tkMacOSXButton.c: In function `TkMacOSXInitControl':
  /Users/don/tk/macosx/tkMacOSXButton.c:817: error: parse error before ')' token
  /Users/don/tk/macosx/tkMacOSXButton.c: In function `TkMacOSXDrawControl':
  /Users/don/tk/macosx/tkMacOSXButton.c:962: error: parse error before ')' token


tkt_uuid: 3551777fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Accepted
title: Fix bug that ignored initial menu item disablement
comment:
  Creating menu items under the main menu with -state disabled would result in enabled menu items.  The reason was some code present in TkpConfigureMenuEntry which overzealously tried to rectify situations when an entire menu or submenu is disabled and then reenabled.


tkt_uuid: 1186558fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: obsolete: 8.5a2
resolution: Fixed
title: Bad yscrollcommands generated when resizing word wrapped tex
comment:
  A word-wrapped text widget can generate yscrollcommand
  calls with arguments other than 0 and 1 even when there
  is nowhere near enough text to fill the visible area.
  This happens when wrapping the last word of text onto a
  new line, or back to the end of the last line.

  To demonstrate this go:

  % proc putall {args} {puts $args}
  % text .t -wrap word -yscrollcommand putall
  % pack .t -fill both -expand true

  Now copy a few lines of text into the widget, and drag
  its right border so the number of lines with text
  changes. You will see some values other than 0 and 1
  even when the text is nowhere near filling the widget.

  This causes a problem if you are drawing a scrollbar
  only when  it is needed; the drawing of the bar will
  resize the text widget, causing another yscrollcommand
  to be generated, removing the scrollbar and causing an
  endless loop.

  I've shown it for version 8.5a2 under Linux and Windows XP


tkt_uuid: 220530ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: bad binding scripts can crash prowish
comment:
  OriginalBugID: 2120 Bug
  Version: 8.0.5
  SubmitDate: '1999-05-21'
  LastModified: '1999-10-22'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  FixedDate: '1999-10-22'
  FixedInVersion: 8.2


  Name: Berry Kercheval

  ReproducibleScript:
  If you run this:
         entry .e
         pack .e
         bind .e <KeyPress> {puts "%a"}
      then ProWish on Win 98 crashes hard.  The %a is probably a bogus thing
      for a 
      keypress event, but a hard crash is a rather more severe penalty than I
      expected from a simple typo (I had intended %A)

  ObservedBehavior:
  CRASH!!!

  DesiredBehavior:
  I expect some value, probably meaningless, to be substituted for %a, or
      even for an error to be thrown.



  This works in 8.2 (sub'ing '??' in). 
  -- 10/22/1999 hobbs


tkt_uuid: 1247919fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 8
foundin: None
resolution: Fixed
title: threading flaw in use of DeleteWindowsExitProc
comment:
  Ok.  After quite a bit of research, I have uncovered
  the following issue:

  1. You startup a process and load Tcl.
  2. At some point, you load Tk, and Initialize() gets
  called.
  3. As a result of Initialize() being called, a Tcl exit
  handler is created that points to DeleteWindowsExitProc
  passing the tsdPtr for the current thread.

  RED FLAG HERE: Passing thread specific data to a
  process wide routine.

  First of all, exit handlers have no concept of
  "thread".  They are process wide (they are all called
  by Tcl_Finalize just prior to unloading Tcl/Tk).

  Secondly, the TkCreateExitHandler call in tkWindow.c is
  incorrect because it passes the tsdPtr into a routine
  that will create an exit handler thus creating a
  classic data lifetime issue.

  The root problem with this approach is that the
  "cached" tsdPtr is NOT guaranteed to be valid should
  the thread call Tcl_FinalizeThread() on a thread that
  has Tk loaded prior to calling Tcl_Finalize() because
  TclFinalizeThreadData() is called by Tcl_FinalizeThread
  and that destroys the data pointed to by the "cached"
  tsdPtr passed to DeleteWindowsExitProc.  This is
  contrary to the documented "safe" behavior and
  extremely confusing.

  Once I fix this bug and the somewhat associated bug
  749908 are fixed, I believe that Tk will be a lot more
  capable and "safe" in threaded environments.  Both of
  these fixes should really be backported to 8.4 as well
  and I would really appreciate some help in that regard
  as I have very limited spare time at the moment.

  I'm going to start working on a fix for this and also
  quickly scan for the same class of problems lurking
  elsewhere in the core.


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


  Tk 8.3.2 Bug

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

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

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

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

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

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

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

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

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

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

     windowHwnd = (HWND) workInteger;

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

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

        previous_iconId = iconId;

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

     }

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

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


tkt_uuid: 2907388fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Accepted
title: Entering circumflex '^' into entry crashes TkAqua 8.6b1.1
comment:
  The following script:

  % entry .e
  % pack .e

  will crash TkAqua8.6b1.1 when entering a circumflex (the ^ character) into the entry. This is true for both the i386 and the x86_64 builds. The error message is:

  2009-12-02 11:17:30.936 wish-aqua8.6[6459:903] An uncaught exception was raised
  2009-12-02 11:17:30.939 wish-aqua8.6[6459:903] *** -[NSCFString characterAtIndex:]: Range or index out of bounds
  2009-12-02 11:17:31.023 wish-aqua8.6[6459:903] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFString characterAtIndex:]: Range or index out of bounds'
  *** Call stack at first throw:
  (
          0   CoreFoundation                      0x00007fff85879444 __exceptionPreprocess + 180
          1   libobjc.A.dylib                     0x00007fff8496d0f3 objc_exception_throw + 45
          2   CoreFoundation                      0x00007fff85879267 +[NSException raise:format:arguments:] + 103
          3   CoreFoundation                      0x00007fff858791f4 +[NSException raise:format:] + 148
          4   Foundation                          0x00007fff801803d5 -[NSCFString characterAtIndex:] + 97
          5   Tk                                  0x00000001000c52e0 Tk_SetCaretPos + 674
          6   Tk                                  0x00000001000cb9db Tk_MacOSXSetupTkNotifier + 701
          7   Tcl                                 0x00000001001f4486 Tcl_DoOneEvent + 297
          8   Tk                                  0x000000010001d8e0 Tk_MainLoop + 24
          9   Tk                                  0x000000010002b36a Tk_MainEx + 1491
          10  wish-aqua8.6                        0x000000010000548b 0x0 + 4294988939
          11  wish-aqua8.6                        0x00000001000053d0 0x0 + 4294988752
          12  ???                                 0x0000000000000001 0x0 + 1
  )
  terminate called after throwing an instance of 'NSException'
  Abort trap


tkt_uuid: 1105284fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: Scripting of TkAqua application menu commands
comment:
  The application menu created by the MacOS X system 
  provides (amongst others) "Preferences..." and "Quit" items 
  that should be used by applications in preference to 
  application-specific menus.  For a Tcl/Tk application based 
  on the Wish Shell bundle, it is convenient to allow these 
  menu items to be handled by scripted procedures.

  In Tk 8.4.9, the Quit menu item is handled by evaluating the 
  "exit" command.  The following amended procedure from 
  tkMacOSXHLEvents.c first checks if there is a user-defined 
  command "::tk::mac::Quit", which is evaluated in 
  preference to "exit".  This allows an application-specifc 
  script to be run prior to application shutdown.  (This might, 
  for example, prompt users to save modified documents.)

  Note that on other platforms, the standard application 
  shutdown is peformed using the Exit item on the File menu, 
  which is, of course, defined by the application. 

  static int 
  ReallyKillMe(Tcl_Event *eventPtr, int flags) 
  {
      Tcl_CmdInfo dummy;
      Tcl_Interp *interp = ((KillEvent *) eventPtr)->interp;
      /*
       * Look for user-defined handler in ::tk::mac::Quit
       * or default to "exit"
       */

      if (interp != NULL) {
        if (Tcl_GetCommandInfo(interp, "::tk::mac::Quit", 
  &dummy) != 0) {
              Tcl_GlobalEval(interp, "::tk::mac::Quit");
        } else {
          Tcl_GlobalEval(interp, "exit");
        }
      }
      
      return 1;
  }


  Handling the "Preferences..." menu item, on the other hand, 
  is at present already partially implemented.  The menu item 
  is disabled by default, but if it is enabled (see below) by the 
  user, the user-defined procedure 
  ::tk::mac::ShowPreferences is invoked.

  To enable the "Preferences..." menu item, it is necessary to 
  add a call to the command:

  EnableMenuCommand(NULL, kHICommandPreferences);

  Ideally, a Tcl/Tk script should have access to this command, 
  such as through a procedure called e.g. 
  ::tk::mac::EnablePreferencesMenuItem  This access would 
  complete the implementation of the Tcl/Tk script-level 
  handling of the application menu.


tkt_uuid: 219916ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Duplicate
title: WinNT event loop not entered properly; making a button not respond to mouse clicks
comment:
  OriginalBugID: 1163 Bug
  Version: 8.1b3
  SubmitDate: '1999-02-02'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1212
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  ClosedDate: '1999-08-20'


  Name:
  vince darley

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  # save this in a file 'bug.tcl', and double click 
  # to run it.  Bug happens at least on WinNT, Tk 8.0.3, 8.0.4, 8.1b1
  console show
  button .b -text "This button doesn't respond, even  after you dismiss the file dialog!!" -command exit
  pack .b

  # One workaround is to uncomment these three lines so that Tk enters
  # the event loop properly:
  #after idle {set buggy 1}
  #vwait buggy
  #unset buggy

  # Another workaround is to place the file dialog in an 'after idle'
  if {1} {
      # you must cancel or select a file in the dialog.
      # Obviously the button won't respond while the dialog is there!
      set file [tk_getOpenFile]
  } else {
      # the workaround for the bug.  However requires use of global variable 'file'
      # which is very inconvenient for Itcl code etc.
      after idle {set file [tk_getOpenFile]}
      vwait file
  }
  # the problem is that when the code gets here, the button still
  # won't respond.

  ObservedBehavior:
  Even _after_ you dismiss the file dialog, the button doesn't respond
  to clicks.  Bug exists in Tk 8.0.3, 8.0.4 and 8.1b1

  DesiredBehavior:
  The button should respond,



  04/07/1999 12:05 - redman - Also is in 8.1b3
  04/22/1999 11:14 - redman - Should be easy to workaround, lower priority.
  --
  A work-around is to call 'update' before native dialogs, but
  this is mentioned in several bug ids. 
  -- 08/20/1999 hobbs


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


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

  The following trivial patch fixes the problem.

  Ian Taylor
  ian@cygnus.com

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


tkt_uuid: 2768586fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: Menu posting problem on dual monitors
comment:
  This bug happens on Windows in dual monitor mode, when the second monitor is placed above the primary monitor. Note that this means that the second monitor has negative y coordinates.
  When posting a menu on the second monitor (either from a menubutton or directly with tk_popup), the menu is actually displayed on the primary monitor.

  The reason can be found in the procedures ::tk::MbPost and ::tk::PostOverPoint. These contains checks like:

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

  Which makes it impossible to post menus at negative y coordinates.


tkt_uuid: 2999920fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Rejected
title: Internal Virtual event string operations
comment:
  In tkBind.c, every translation from virtual event
  string to Tk_Uid consists of the stripping of "<<"
  and ">>" from the begin and the end. In the
  translation back, those are added again. This
  is inefficient, just for saving 4 characters for each
  event in the Tk_Uid table.

  So, here is a patch. Advantages:
  - GetAllVirtualEvents does not need a Tcl_DString
    any more
  - GetVirtualEventUid does not longer change its
    virtString argument

  Any objections? Needless to say that all tests
  still pass after applying this patch.


tkt_uuid: 219899ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: The Caps-Lock indicator Led don't function only in Windows 9
comment:
  OriginalBugID: 683 Bug
  Version: 8.0.3
  SubmitDate: '1998-09-24'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2493
  OS: All
  OSVersion: NA
  Machine: X86
  FixedDate: '2000-10-31'
  FixedInVersion: NA
  ClosedDate: '1999-08-06'


  The Caps-Lock led functions normaly in each windows application. If i change to the prowish window, clicking to the Caps-Lock takes no effect to the keyboard led. Windows NT handles the Caps-Lock led correctly. 

  This problem is reproduced in the regular 8.0.3 wish interpreter. When in the interpreter, click the caps lock button and check the caps lock light. It is not on.


tkt_uuid: 220523ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: A few portability problems (Borland, gcc, egcs)
comment:
  OriginalBugID: 2053 RFE
  Version: 8.1
  SubmitDate: '1999-05-12'
  LastModified: '1999-11-18'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0 SP3
  Machine: X86
  FixedDate: '1999-11-18'
  FixedInVersion: 8.2.3


  Name:
  Jan Nijtmans

  Comments:
  All those patches are adapted from the Cygnus version of Tcl/Tk (Thanks
      to Mummit Khan for his assistance!!!!)

  DesiredBehavior:
  The supplied patch fixes the following problems:
      - In tkWinX.c, the header file <zmouse.h> is included, which
        is missing in many development systems. In stead of forcing
        all developers to download this file from MicroSoft, it is
        much easier to supply the definition of WM_MOUSEWHEEL only,
        since that is the only symbol used from the header file.
      - The function GetCurrentTime() is obsolete (according to Microsoft),
        and should be replaced by GetTickCount(). Some other development
        environments (e.g. CygWin) don't even bother to implement
      GetCurrentTime(),
        thereby forcing users to make the switch.
      - The GNU compilers (gcc and egcs) don't support strnicmp() and
      stricmp().
        Use strncasecmp() and strcasecmp() instead.
      - "struct TkFontAttributes" is defined in both tkFont.h and tkWinInt.h.
        This leads to a warning if both tkWinInt.h and tkFont.h are included
        in a C-file. Better remove the definition from the latter; it doesn't
        serve any purpose.

  Patch:
  *** win/tkWinX.c.origThu Apr 29 21:38:44 1999
  --- win/tkWinX.cWed May 12 06:30:33 1999
  ***************
  *** 19,25 ****
     * The zmouse.h file includes the definition for WM_MOUSEWHEEL.
     */
    
  ! #include <zmouse.h>
    
    /*
     * Definitions of extern variables supplied by this file.
  --- 19,25 ----
     * The zmouse.h file includes the definition for WM_MOUSEWHEEL.
     */
    
  ! #define WM_MOUSEWHEEL (WM_MOUSELAST+1)
    
    /*
     * Definitions of extern variables supplied by this file.
  ***************
  *** 1129,1133 ****
    unsigned long
    TkpGetMS()
    {
  !     return GetCurrentTime();
    }
  --- 1129,1133 ----
    unsigned long
    TkpGetMS()
    {
  !     return GetTickCount();
    }
  *** win/tkWinPort.h.origThu Apr 29 21:38:43 1999
  --- win/tkWinPort.hWed May 12 06:30:32 1999
  ***************
  *** 39,46 ****
  --- 39,48 ----
    #    define hypot _hypot
    #endif /* _MSC_VER */
    
  + #ifndef __GNUC__
    #define strncasecmp strnicmp
    #define strcasecmp stricmp
  + #endif
    
    #define NBBY 8
    
  *** win/tkWinInt.h.origThu Apr 29 21:38:42 1999
  --- win/tkWinInt.hWed May 12 07:40:47 1999
  ***************
  *** 41,48 ****
    #define WS_EX_TOOLWINDOW0x00000080L 
    #endif
    
  - typedef struct TkFontAttributes TkFontAttributes;
  - 
    /*
     * The TkWinDCState is used to save the state of a device context
     * so that it can be restored later.
  --- 41,46 ----

  PatchFiles:
  tkWinX.c tkWinPort.h tkWinInt.h



  The mousewheel stuff we'd rather leave to the std headers and not
  import just the one #define.

  GetTickCount now used as specified.

  ifdef GNUC for str*cmp added.

  struct TkFontAttrs removed from tkWinInt.h 
  -- 11/16/1999 hobbs


tkt_uuid: 791500ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 3 Low
foundin: None
resolution: Fixed
title: PanedWindow refresh glitches on X
comment:
  The panedwindow widget does not set the window
  background; this leads to a display glitch on X when
  the window is exposed.   

  Since there is no window background, the X server
  doesn't clear the newly-exposed area.   Attached patch
  fixes that.


tkt_uuid: 947147ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Works For Me
title: win98: page fault when maximizing a window
comment:
  test code:

  grid [canvas .c] -row 0 -column 0 -sticky nswe
  grid rowconfigure . 0 -weight 1
  grid columnconfigure . 0 -weight 1

  now click on the "maximize" button in the upper right 
  corner of "."

  I get a page fault

  this doesn't happen if .c is a text widget, if either the 
  weight of the row or column configure is 0, or if 
  the "sticky" setting is not "nswe".


tkt_uuid: 3046742fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Unknown option "-relief" in [bgerror]
comment:
  The <Return> binding for the standard Tk [bgerror] dialog sets the -relief option of the OK button.  However, the OK button is a [ttk::button] and therefore does not have a -relief option.

  To test, run "bgerror foo", click on the bgerror dialog that pops up, and press Return (or Enter, whatever).  The error text will change to reflect the new problem.


tkt_uuid: 664111ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: tk_getOpenFile on WNT does not see VFS
comment:
  Under the Windows family of OSes (and I suspect Macs) tk_getOpenFile, tk_getSaveFile and 
  tk_chooseDirectory do not see VFS directories and files. 

  Example: 

                                   #!/bin/sh 
                                   # the next line restarts using wish \ 
                                   exec wish "$0" "$@" 

                                   package require vfs 

                                   ## 
                                   ## Mount your favoriate directory as /test 
                                   ## 
                                   ... 

                                   ## 
                                   ## Test should be seen as the initial directory 
                                   ## 
                                   set file [tk_getOpenFile -initialdir {/test}] 


  Please note that this bug was originally submitted as bug 655505 against TclVfs.


tkt_uuid: 2864685fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: Fixed
title: Compiz animates each menu item as a new window
comment:
  Compiz somehow thinks that the menus of these apps are separate windows and applies window open and close animation to them. Thus each submenu "pulses" like ordinary window when opened and navigating a menu (specially one with zero delay) looks like a firework.


tkt_uuid: 220859ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 15. [scale]
priority: 5 Medium
foundin: obsolete: 8.2b2
resolution: None
title: Bad slider updates w/256 color display
comment:
  OriginalBugID: 2567 Bug
  Version: 8.2b2
  SubmitDate: '1999-08-18'
  LastModified: '2000-01-03'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86


  Name:
  Christopher Nelson

  ReproducibleScript:
  namespace eval ::brightness {
          namespace export  main

          # "global" array(s)
          variable Brightness
      }

      proc brightness::main { w } {
          variable Brightness

          #----------------------------------------
          # Control overall brightness
          set brightctrl [frame $w.brightness]
          pack $w.brightness -side top -padx 1m -pady 1m
          Scale $brightctrl.w "" brightness "#000000000000" "#ffffffffffff"
          set brightScale $brightctrl.w
          pack $brightctrl.w -side top -expand 1 -fill x -anchor n
          set Brightness(current,brightness) 0

          #----------------------------------------
          # Control color balance
          set colorctrl [frame $w.balance]
          pack $w.balance -side top -padx 1m -pady 1m
          Scale $colorctrl.r Red   rBalance "#000000000000" "#ffff00000000"
          Scale $colorctrl.g Green gBalance "#000000000000" "#0000ffff0000"
          Scale $colorctrl.b Blue  bBalance "#000000000000" "#00000000ffff"
          pack $colorctrl.r $colorctrl.g $colorctrl.b -side top -expand 1
      -fill x

          foreach balance { r g b }  {
              #set Brightness(current,${balance}Balance) 0
              trace variable brightness::Brightness(current,${balance}Balance)
      w  [namespace code [list TraceBalance  $colorctrl.r.scale $colorctrl.g.scale $colorctrl.b.scale
       $brightScale.scale]]
          }

      }
      # brightness::tab
      #
      # brightness::Scale --
      #
      #     Create a scale and an entry to control one component
      #     (brightness, or red, green, or blue balance).
      # 
      # Arguments:
      #     w        - Frame to create with the scale and entry in it
      #     label    - Label for the scale
      #     variable - Variable to associate with the scale and entry
      #     color    - Color for the scale's trough
      #     balance  - Color balance for the scale's trough
      #
      # Results:
      #     
      proc brightness::Scale { w label index minColor maxColor } {
          variable Brightness

          # Create the outer frame
          frame $w

          set Brightness($w.scale,minColor) $minColor
          set Brightness($w.scale,maxColor) $maxColor
          lappend Brightness(dynamicWidgets) $w.scale

          set color [InterpolateColor -100 $minColor 100 $maxColor 0]

          # Put a scale in it.
          scale $w.scale -from -100 -to 100  -orient horizontal -length 6i -width .25i  -variable brightness::Brightness(current,$index)  -highlightthickness 0  -troughcolor $color  -showvalue 0
          if {[string length $label]} {
              $w.scale configure -label $label
          } else {
              $w.scale configure -tickinterval 100.0
          }
          pack $w.scale -side left -anchor s

          # Whenever the variable changes, update the color of the scale
      trough.
          # Note: the variable may change via scale or entry
          trace variable brightness::Brightness(current,$index) w  [namespace code [list TraceScaleValue $w.scale]]

          # The range on the scale limits the range of the variable so we
          # don't have to do anything to limit the range of the variable when
          # users type in illegal values (e.g, 999)
          # Need room for "-100"
          entry $w.entry  -textvariable brightness::Brightness(current,$index)  -width 4

          # Pack the entry so it lines up with the trough
          if {[$w.scale cget -tickinterval] == 0.0} {
              pack $w.entry -side left -anchor s -pady .5m
          } else {
              set font [$w.scale cget -font]
              pack $w.entry -side left -anchor s  -pady [expr {5+[font metrics $font -linespace]}]
          }
      }
      # brightness::Scale
      #
      proc brightness::TraceScaleValue { scale args } {
          variable Brightness
          # Get min, max, current value of scale
          set from  [$scale cget -from]
          set to    [$scale cget -to]
          set value [$scale get]

          set color [InterpolateColor  $from $Brightness($scale,minColor)  $to   $Brightness($scale,maxColor)  $value]

          $scale configure -troughcolor $color
      }
      #-----------------------------------------------------------------------

      # Turn {r g b} into #rrrrggggbbbb
      proc brightness::MakeColor { rgb } {
          set color "#"
          foreach component $rgb {
              if {$component > 65535.0} {
                  set component 65535.0 
              }
              append color  [format "%04x" [expr {int($component)}]]
          }
          return $color
      }

      # Get the color representing value from a max and min value and their
      # corresponding colors
      proc brightness::InterpolateColor { 
          minValue minColor maxValue maxColor value 
      } {
          set minRGB [winfo rgb . $minColor]
          set maxRGB [winfo rgb . $maxColor]

          # For each component, do a linear interpolation:
          #   minValue       value       maxValue
          #   --------   =   -----   =   --------
          #   minComp          ?         maxComp
          #
          # Which gives:
          #
          #   value - minValue       comp - minComp
          # -------------------  =  -----------------
          # maxValue - minValue     maxComp - minComp
          #
          # and then:
          #
          #                    /  value - minValue                         # comp =  minComp + |  ------------------- * (maxComp - minComp) |
          #                    \ maxValue - minValue                      /
          set newRGB {}
          foreach minComp $minRGB maxComp $maxRGB {
              if {$minComp == $maxComp} {
                  set comp $minComp
              } else {
                  set ratio [expr
      {double($value-$minValue)/($maxValue-$minValue)}]
                  set comp [expr {$minComp+($ratio*($maxComp-$minComp))}]
              }
              lappend newRBG $comp
          }

          return [MakeColor $newRBG]
      }
      # brightness::InterpolateColor

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

      # Balance adjustments
      proc brightness::TraceBalance { rScale gScale bScale wScale args } {
          variable Brightness
          # Compute the components of the composite color sample
          set max 0
          foreach component {r g b} {
              set from  [[set ${component}Scale] cget -from]
              set to    [[set ${component}Scale] cget -to]
              set value [[set ${component}Scale] get]

              set percent [expr {double($value-$from)/($to-$from)}]
              set $component [expr {$percent * 65535}]

              if {[set $component] > $max} {
                  set max [set $component]
              }
          }

          # Normalize the components (make max 65535)
          foreach component {r g b} {
              set $component [expr {[set $component]/$max * 65535}]
          }
          # Build a color from the normalized components
          set color [MakeColor [list $r $g $b]]

          # Set the maximum color of the composite bar's trough to the new
      color
          set Brightness($wScale,maxColor) $color

          # Update the composite scroll bar's trough color
          TraceScaleValue $wScale 
      }
      # brightness::TraceBalance

      brightness::main ""

  ObservedBehavior:
  On at least W95 and W98, in Tcl 8.0, 8.1, and 8.2b2 when the script is
      run on a 256 color display, moving one of the R, G, or B scales colors
      others.  The others retain the wrong color until the mouse pointer is
      dragged through them.  With 16 bit or Truecolor, there is no problem.
      It also seems to be OK on NT (this per a report to me by a co-worker, I
      haven't verified this for myself).

  DesiredBehavior:
  Dragging one of the R, G, or B scales should not affect the other two.


tkt_uuid: 1754051fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 8
foundin: None
resolution: None
title: Ignore multiple whitespace at end of word-wrapped line
comment:
  In '-wrap word' mode, ignore multiple whitespace at the right of display lines - do not wrap it round to the start of the next display line.

  At the moment the excess is ignored only if it will fit at the end of the display line.

  This feature could be implemented by bindings, but it would be more appropriate if it were part of the widget's internal word-wrap algorithm.


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


tkt_uuid: 220671ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: bug in tk_getOpenFile on WinNT 4.00.138 locks Tk app.
comment:
  OriginalBugID: 4113 Bug
  Version: 8.2.2
  SubmitDate: '2000-02-02'
  LastModified: '2000-02-05'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: Windows NT 4.00.1381
  Machine: PII-450 128M RAM
  FixedDate: '2000-02-05'
  FixedInVersion: 8.3


  Name:
  Richard Ellis

  ReproducibleScript:
  Using notepad, put these lines into a file named testcase.tcl:

  tk_getOpenFile
  button .b -text "Push Me"
  pack .b

  Then save the file and double click on it to run it as most users of Win would.  When the file selector opens, select a file or hit "cancel" (it does not matter).  The wish window will resize to be the single button marked "Push Me" but the app. is deaf to all mouse interaction.

  Running the same script by first loadnig wish, and at the console typing "source testcase.tcl" (assuming you have already "cd'ed" to the correct dir) will open a file selector that when closed does not cause the app. to be deaf to all mouse interaction.

  ObservedBehavior:
  I am writing a Tcl/Tk script under Linux, with the intent of having it execute on WinNT (4.00.1381) using Freewrap as the vehicle to execute it.  Under Linux, it works perfectly  When I wrapped up a test script to check operation under WinNT, the Tk lockup occued after interacting with the tk_getOpenFile dialog on WinNT.  I tested with freewrap (based on 8.2.2) as well as with Tcl/Tk 8.2.2 and 8.3b2 WinNT packages from the Scriptics download area.  All exhibited the identical behaviour.

  For now, the workaround has been to call tk_FDialog directly, avoiding usage of the native WinNT dialog.  The "feel" of the bug is that the win emulation layer is either causing the event loop to fail to begin, or is forgetting to remove a "grab" placed on the mouse for the dialog after the dialog is closed.  It is not caught in an endless loop, as task manager shows 0% cpu utilization for the app. while it is locked up.  Pressing the kill "X" in the title bar cleanly exits the app.

  DesiredBehavior:
  tk_getOpenFIle should not cause the app. to lockup.



  This was fixed for 8.3, where an EnableWindow(hWnd, 1) call was
  required after the call to the native dialog for each native
  dialog type in Windows Tk. 
  -- 02/05/2000 hobbs


tkt_uuid: 1789055fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 34. [tk_chooseColor]
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Invalid
title: tk_chooseColor returns None#(color)
comment:
  Using Aqua Tcl/Tk 8.4.15 I am seeing tk_chooseColor return "None#xxxxxx" (where #xxxxxx is a valid color) after pressing OK, or "None" after pressing Cancel. This may be related to PR 1782105. But I still see it in 8.4.16rc0, which was released after that PR was closed.

  The problem is that this does not show up in wish, but only when running my application. I have not been able to track down what starts it, but:
  - It always starts at the same point in my (complicated) code. So far efforts to track down the trigger (and thus simplify the code) have been in vain.
  - once it begins, it always happens

  I am happy to work harder at getting a small application and can easily supply an application that shows the bug (and contains source).


tkt_uuid: 1581955fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.6b1
resolution: None
title: text widget: window create ... -create ... doesn't work
comment:
  In Tk 8.5, the text widget command

      <path> window create <index> -create <script>

  doesn't behave as expected.  From the man page:

  "... this script will be evaluated when the annotation
  is about to be displayed on the screen. ... If the 
  annotation's window should ever be deleted, script will
  be evaluated again the next time the  annotation is 
  displayed."

  In earlier Tk versions, the window's creation was
  delayed indeed as specified in the man page, i.e.,
  until effectively displaying it on the screen.  This
  was a very useful feature, allowing the creation of a
  large number of embedded windows, of which only a few
  had to really exist.  For example, whenever vertical
  scrolling or anything else made it necessary to update
  the view, it was possible to destroy the windows
  embedded into the other lines.  A very effective way to
  save resources and avoid problems related to keyboard
  navigation with the Tab key (which becomes awfully slow
  in the presence of a large number of windows).

  In Tk 8.5, the "-create" option behaves basically like
  "-window".  The [window names] subcommand returns the
  names of *all* embedded windows, and it is quite easy
  to see that all of these really exist.  Any attempt to
  delete some of them fails, because they are immediately
  recreated, contrary to what is stated in the documentation.


tkt_uuid: 2918171fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Wish crash when destroying . with reflected channel
comment:
  When destroying ".", wish crashes with the following message (followed by lots of debug info):
  *** glibc detected *** /home/sbron/usr/bin/wish8.6: free(): invalid pointer: 0x00000000006297e0 ***

  This doesn't happen when just exiting the application. The script to reproduce this situation involves a reflected channel, so it may just as easily be a refchan problem. But since the issue only occurs in combination with wish, I opened the bug in the Tk tracker.


tkt_uuid: 742660ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 69. Events
priority: 7 High
foundin: None
resolution: Fixed
title: execute XCreateIC twice when "TK_XIM_SPOT" is enabled
comment:
  The over-the-spot mode of XIM (X Input Method) was
  applied on 05-Apr-2002, (tkEvent.c : CVS version 1.9,
  2002/04/05 08:41:07) by Jeff Hobbs. This is truly
  exciting improvement for people who needs character
  conversion when typing characters on the widgets, such
  as for Chinese, Japanese and Korean.

  But, in the middle of June 2002, just before releasing
  8.4b1, I found the over-the-spot mode of XIM did not
  work, but only the root-window mode of XIM worked.

  I've investigated the reason why the XIM is not working
  well. Indeed we, Japanese needs this feature.

  Recently, I've found the reason. Alas, this is very
  very small mistake caused by the modification on
  06-Jun-2002, (tkEvent.c : CVS version 1.13, 2002/06/15
  01:09:36).

  The reason why the over-the-spot mode of XIM is not
  enabled is:

  when TK_XIM_SPOT is enabled, the following two
  XCreateICs are executed in order, this is because of
  inappropriate #if and #endif directives in tkEvent.c.
  In fact, the later XCreateIC is for the root-window
  mode of XIM!

  winPtr->inputContext = XCreateIC(dispPtr->inputMethod,
  XNInputStyle, XIMPreeditPosition|XIMStatusNothing,
  XNClientWindow, winPtr->window,
  XNFocusWindow, winPtr->window,
  XNPreeditAttributes, preedit_attr,
  NULL);

  winPtr->inputContext = XCreateIC(dispPtr->inputMethod,
  XNInputStyle, XIMPreeditNothing|XIMStatusNothing,
  XNClientWindow, winPtr->window,
  XNFocusWindow, winPtr->window,
  NULL);

  The attached patch corrects these directives.

  If this patch is applied, all input contexts (ICs) are
  cleanly destroyed when exiting application. and no more
  aborting error can be seen when exiting.

  The improvement has been proved on Red Hat Linux 9,
  XFree86-4.3.0-2 and Tcl/Tk 8.4.3. Thanks.

  Keiichi


tkt_uuid: 3421183fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: None
title: Last filetype sometimes selected as default on Windows
comment:
  I'm using Tcl/Tk on Linux, Windows and Mac OS, and the file type that is selected by default changes depending on the platform. On Linux, the first file type is selected, while the last one is on the other platforms. I think the behavior on Linux is wrong, since examples of code I could find on the Web all use the last type for most generic filters. Anyway, the behavior should be consistent across platforms.

  I'm using Tk 8.5.9 on Fedora 15.

  Steps to reproduce:
  $ wish
  % tk_getOpenFile -filetypes "{First {*.a}} {Last {*.b}}" 


tkt_uuid: 220648ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: Double-clicking in text widget does not properly select a word if there are embedded windows/images
comment:
  OriginalBugID: 3989 Bug
  Version: 8.3b1
  SubmitDate: '2000-01-07'
  LastModified: '2000-01-19'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  FixedDate: '2000-01-19'
  FixedInVersion: 8.3


  Name:
  Peter Shawhan

  Comments:
  The explanation for this bug is that the procs tkTextNextPos and tkTextPrevPos (in text.tcl)
  use "$w get" to get a string from the text widget, then scan it for the nearest word break.  Since
  "get" omits embedded windows/images, the character indexing is offset from what it should be.

  One solution would be to provide an alternative form of "get" (e.g. an option) which replaces any
  embedded window/image by a space; tkTextNextPos and tkTextPrevPos could then call this form
  for purposes of scanning for word breaks.  The default form of "get" would still omit windows/images
  as is currently the case.

  Even if the alternative form of "get" is not implemented in the core text widget, the same behavior
  can be produced by a small piece of code which could be called by tkTextNextPos and tkTextPrevPos:

  proc alternative_get {w start end} {
      set string ""
      foreach {type val pos} [$w dump -text -window -image $start $end] {
  if {$type == "text"} {
      append string $val
  } else {
      append string " "
  }
      }
      return $string
  }

  ReproducibleScript:
  Execute the following script:

  #------------------- Beginning of script
  #-- Create a bitmap image
  set bmp [image create bitmap -foreground red -data "
  #define square_width 9
  #define square_height 15
  static unsigned char square_bits[] = {
     0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x7c, 0x00, 0x7c, 0x00,
     0x7c, 0x00, 0x7c, 0x00, 0x7c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
     0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
  "]

  #-- Create a text widget and pack it
  text .t -width 80 -height 10
  pack .t

  #-- Insert some text with embedded images/windows
  .t insert end " 11111"; .t image create end -image $bmp
  .t insert end " 22222"; .t image create end -image $bmp
  .t insert end " 33333"; .t image create end -image $bmp
  .t insert end " 44444\n\n";

  .t insert end "aaa 123"; .t image create end -image $bmp;
  .t insert end "456 bbb\n\n"

  .t insert end "ccc 789"
  button .t.help -text "Help" -command {puts "You pressed Help"}
  .t window create end -window .t.help
  .t insert end "000 ddd\n"
  #------------------- End of script

  Now double-click on the various groups of characters and observe what is selected.

  ObservedBehavior:
  Double-clicking does not properly select a word if there are embedded images/windows on a line.
  Specifically,
    1) The leftward extent of the selection is too large, by a number of characters equal to the 
      number of embedded images/windows on the line to the left of the selection.  For example,
      if you double-click on the group of 4's, the selection includes the final 3 from the group of
      3's, along with the image and space between the 3's and 4's.
    2) The rightward extent of the selection is sometimes too small, by a number of characters
      equal to the number of embedded images/windows in the current word to the right of where
      you double-clicked.  For example, if you double-click on the 123, the selection includes the
      following image and the 45, but not the 6.

  DesiredBehavior:
  Double-clicking should always select a word, even if there are embedded images/windows on
  the line.  (The issue of whether an image/window counts as part of a word is a subtlety that
  I do not care about, since in any case it is left out when the selection is pasted into another
  window.)



  This opened a bit of a sticky mess.  When you do a get for a range
  of text in the text widget over embedded windows/images, you don't
  get the embedded stuff returned, but you also don't get any
  compensation for the one index position that each takes.  Since at
  some point it was decided to move the word boundary checks to a Tcl
  routine, this info is totally lost and you get the behavior above
  (including many other related goofy behaviors for any binding that uses
  the tcl word break functions in the text widget).  I've added some
  hacks into 8.3.0 that get around almost all of this.

  I guess the reasoning for skipping the text widget search stuff,
  which would normally work, is the desire to have platform specific
  word boundary breaks.  Irk, this seems like a bad idea. 
  -- 01/19/2000 hobbs


tkt_uuid: 220709ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 50. [pack]
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: crash with "entry .e ; pack .e -side"
comment:
  OriginalBugID: 4422 Bug
  Version: 8.2
  SubmitDate: '2000-03-21'
  LastModified: '2000-03-23'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  FixedDate: '2000-03-23'


  ReproducibleScript:
  namespace eval ::huuhaa {
      set huuhaa huuhaa
  }
  proc ::huuhaa::UI {} {
      entry .e 
      pack .e -side
      # now examine the "Error in startup script"  and "malformed bucket 
      # chain in Tcl_DeleteHashEntry" dialogs followed by Dr. Watson saying: 
      # "wish82.exe Exception: harcoded breakpoint (0x80000003), 
      # Address 0x77f7629c"
  }
  ::huuhaa::UI
  tkwait variable _wait_for_a_while_
  #info patchlevel -> 8.2.0

  ObservedBehavior:
  Dr. Watson appears

  DesiredBehavior:
  wish exits without Dr. Watson

  Patch:
  N/A

  PatchFiles:
  N/A



  This is not a crash in 8.3, must have been fixed in the interim
  (likely before 8.2.3). 
  -- 03/23/2000 hobbs


tkt_uuid: 220284ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: Compiled Wish83.exe does not display console!
comment:
  OriginalBugID: 4260 Bug
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-02-28'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  Machine: Pentium PC, Win98 SE, NT 4.0 SP4
  ClosedDate: '2000-02-28'


  Name:
  Sage X

  CustomShell:
  None at all.

  ReproducibleScript:
  Download the stock Tcl/Tk 8.3.0 sources from scriptics and compile it.

  ObservedBehavior:
  The "console" and "consoleinterp" commands do not work at all.

  DesiredBehavior:
  The "console" command should work in the compiled wish. Since the "console" command works fine with the wish from the official scriptics binary distribution.



  The user needs to give more info.  This looks like user error
  now, because we just compile the binary from the sources like
  anyone else can... 
  -- 02/28/2000 hobbs


tkt_uuid: 220094ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Duplicate
title: scale widget callback is invoked when it shouldn't be
comment:
  OriginalBugID: 6339 Bug
  Version: 8.3.1
  SubmitDate: '2000-10-03'
  LastModified: '2000-10-18'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 3908
  OS: Linux-Red Hat
  OSVersion: 6.0
  Machine: Dell Precision 410
  FixedDate: '2000-10-18'


  Name:

  Jonas Beskow


  Comments:

  This bug is compiler-related (I'm using gcc version egcs-2.91.66) 

      Basically what happens is that a check for identity between two doubles

      (in TkScaleSetValue()) is not robust to compiler optimization.  The

      result is that the scale callback sometimes is invoked even when the

      value hasn't changed. Since TkScaleSetValue() is called from

      ConfigureScale(), the scale callback is invoked each time the widget is

      configured.


      This patch makes the double comparison robust by comparing the absolute

      value of the difference between the values with half the resolution.


  ReproducibleScript:

  proc scalecallback {args} {puts [info level 0]}

  pack [scale .s -resolution .1 -from 0 -to 1 -command scalecallback]

  .s set .5


  # move the mouse pointer into and out of the scale area of the widget (the "handle") - this

  # triggers a configure command that internally has the effect of setting the scale to the current value,

  # which in turn triggers the sacle callback (see comment below)


  ObservedBehavior:

  The scale callback is invoked whenever the pointer enters or leaves the scale area of the widget (the "handle")


  DesiredBehavior:

  The scale callback should only be invoked when the scale value has changed


  Patch:

  *** tkScale.c.old       Tue Oct  3 13:13:07 2000

  --- tkScale.c.new       Tue Oct  3 13:13:15 2000

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

  *** 1297,1303 ****

        }

        if (scalePtr->flags & NEVER_SET) {

          scalePtr->flags &= ~NEVER_SET;

  !     } else if (scalePtr->value == value) {

          return;

        }

        scalePtr->value = value;

  --- 1297,1303 ----

        }

        if (scalePtr->flags & NEVER_SET) {

          scalePtr->flags &= ~NEVER_SET;

  !     } else if (fabs(scalePtr->value - value) < 0.5*scalePtr->resolution) {

          return;

        }

        scalePtr->value = value;


  PatchFiles:

  tkScale.c




  This is indeed a compiler bug, as described in Ticket #3908.

  Thanks for submitting the patch; however, I don't think it's best to make this change to work around the buggy compiler.  This will ultimately penalize (a little bit anyway) every platform for the sake of working around one broken compiler.  Better to upgrade your compiler (egcs 2.95 or higher should do), or your Linux distro (newer versions of Redhat have a newer version of egcs).

  Thanks for sending in the bug report and patch nonetheless.

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

  -- 10/18/2000 ericm


tkt_uuid: 801001ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 50. [pack]
priority: 1 Zero
foundin: obsolete: 8.4.4
resolution: Out of Date
title: Portability issue -- writing over/under resize handle
comment:
  Shouldn't packer be aware that the lower right corner of 
  the window is reserved for the resize handle and avoid 
  putting non-empty frames in that corner of the window?


tkt_uuid: 220712ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Torn-off menus not given correct title
comment:
  OriginalBugID: 4506 Bug
  Version: 8.0p2
  SubmitDate: '2000-03-23'
  LastModified: '2000-03-30'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: Solaris 2.6
  Machine: SunOS 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-Enterprise
  FixedDate: '2000-03-30'
  FixedInVersion: 8.3.1


  Name:

  Mark A. Wege


  Extensions:

  TclX 8.0.2, Oratcl 2.5


  Comments:

  This patch will cause the titles of torn-off menus to be correct in most

      cases.


      If the torn-off menu is resized (i.e., stretched horizontally), however,

      the menu title of any menus which are torn off from the

      first torn-off menu may still be a variation of "tearoff".  Even though

      the menu is wider, the underlying code which created

      the menu only recognizes the original width of the menu option.  Once

      you move to the right of that width, the "active" index

      of the parent menu becomes "none", which causes the code that tries to

      determine a title to fail.


      NOTE: Although we are using Tcl 8.0p2 in our production environment,

      I've downloaded and built Tcl 8.3.0, and it continues

      to have this problem.  The problem has existed, at least to some extent,

      since Tcl 7.4-.


  ReproducibleScript:

  Create a menu with tearoffs enabled, and then tear off a menu.


  ObservedBehavior:

  After you have torn off a menu, the title of the torn-off menu is always set to the word "tearoff" followed by a number.


  DesiredBehavior:

  The title should be the same as the menu option from which the torn-off menu was created.


  Patch:

  *** menu.tcl.orig       Wed Mar 22 08:04:09 2000

  --- menu.tcl    Thu Mar 23 16:05:53 2000

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

  *** 648,655 ****

          set menu [$w entrycget active -menu]

          tkMenuFirstEntry $menu

        } elseif {[string equal [$w type active] "tearoff"]} {

  -       tkMenuUnpost $w

          tkTearOffMenu $w

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

          $w postcascade none

          $w activate none

  --- 648,655 ----

          set menu [$w entrycget active -menu]

          tkMenuFirstEntry $menu

        } elseif {[string equal [$w type active] "tearoff"]} {

          tkTearOffMenu $w

  +       tkMenuUnpost $w

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

          $w postcascade none

          $w activate none


  PatchFiles:

  lib/tk8.0/menu.tcl




  This does seem to correct the naming problem, and will be in 8.3.1. 
  -- 03/30/2000 hobbs


tkt_uuid: 1818082fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: None
title: saving Canvas area as PNG/BMP/GIF via the Tk_Photo format
comment:
  I would like to submit a patch that makes the Canvas object capable of exporting not only to Postscript but also to the Tk_Photo format. Using the Tk_Photo format a user will then be able to export canvas images directly to many other different formats and not just Postscript.

  Exporting to Postscript is pretty much only usefull on Unix systems. If you work under Windows it can be a bit troublesome to convert Postscript files to the native formats... especially if you want to do this in the background in runtime...

  I submitted this idea as a patch a few years ago, but it seams  to have gotten 'buried'. It seems the Canvas object still only exports to Postscript, so I think the patch still fills a 'hole'. Hobbs gladly greeted the suggestion back then so I (modestly) imagine that it will still be gladly accepted...

  ( I submitted the patch as a part of my original feature request: '[923890] saving canvas area as PNG/BMP/GIF')

  This patch modifies the file 'generic/tkCanvas.c' and adds a the test-example 'tests/canvGetImgPhoto.tcl'
  I tested this patch on Tcl8.5b1/Tk8.5b1. Compiles and works fine.


tkt_uuid: 220250ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Commands
priority: 1 Zero
foundin: None
resolution: Invalid
title: Changes needed for usage of Tk with games.
comment:
  OriginalBugID: 3383 RFE
  Version: 8.2
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-17'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: Mandrake 6
  ClosedDate: '1999-11-17'


  Name:
  George Peter Staplin

  Comments:
  I hope what I have written makes sense.  Thanks for making Tcl/Tk!

  DesiredBehavior:
  I would like a sprite extension to Tk for making games.  I would also
      like an easier way to have square hot spots on label images.  I must be
      able to bind the square area over the image to a command.  The square
      area must not be visible.  A general way to have a square invisible hot
      spot on any widget would also be very useful.
      
      For example something like this.
      
      mouseover .overimage -width 30 -height 35
      place .overimage -y 20 -x 40
      
      An easier way to pinpoint the exact position of a hot spot would be
      useful.  So a flag such as '-movablepinpoint true' creates a border
      around the hot spot and allows movement of the hot spot.  When the
      hotspot is moved a toplevel window could then report the current
      position of the hot spot.  This would save me a lot of time.



  The user found other Tk methods for this with a little more research. 
  -- 11/17/1999 hobbs


tkt_uuid: 783802ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 41. Photo Images
priority: 7 High
foundin: None
resolution: None
title: Tcl'2003: Split photo masters into Tcl package
comment:
  One idea that came up at Tcl2003 (in discussion with
  dgp and kbk IIRC) was that the photo master code
  could/should be split off into a separate package that
  can be loaded from Tcl without Tk.  That would prompt
  cleaning up of the grotty colour parsing mechanism, and
  would let images be trivially usable from applications
  like CGI scripts where display access is impractical
  and undesirable.


tkt_uuid: 481308ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 32. Key Symbols
priority: 8
foundin: None
resolution: None
title: Fix for Bug 229038 numerals pad solaris
comment:
  on Sun Solaris machines the numerals pad generates
  problems when there is a bind on the arrow-keys.
  In en entry-widget, the 4 and 6 numerals dont work, in
  a text-widget the 4,6,2 and 8 numerals.
  The problem is, that the "Numlock-Key" has the same
  effect as the "Mode-Key", but affects only the keys of
  the numerals pad. As a consequence, the third or fourth
  slot of the keymap-vector must be used, not the first
  and second. 
  When the first two vectors are used, XKeycodeToKeysym
  always produces the keysyms for the arrow key's and
  then the binding of the arrow-keys is taken and not the
  numeral istself.
  When there is no bind on the arrow-keys, the keys of
  the numerals pad work fine, because the function
  XmbLookupString takes the keycode and the state of the
  mode-switches.
  I tested my patch on a sun solaris machine with solaris
  2.7.
  I hope it works also with linux.
  I attach a patch for the following files
  generic/tkInt.hVersion 1.40
  unix/tkUnixKey.cVersion 1.5


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


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

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


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

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


tkt_uuid: 2805061fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: Wont Fix
title: TkMenuFont not used on MS Windows
comment:
  TIP 145 introduced named fonts including TkMenuFont.  However TkMenuFont use gets stomped
  on MS Windows because of some old cruft in tkWinMenu.c:SetDefaults() i.e. menuFontDString.

  Under WinXP and Tk 8.5.7:
  % menu .m
  % .m configure -font
  -font font Font TkMenuFont {Tahoma 10}


tkt_uuid: 1806585fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5b1
resolution: Invalid
title: Wish 8.5b1 fails to build on osx 10.4
comment:
  In tkMacOSXWm.c,
  kWindowUnifiedTitleAndToolbarAttribute and kWindowTexturedSquareCornersAttribute
  are not defined for build env prior 10.5.


tkt_uuid: 443848ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Fixed
title: 'elide' doesn't elide first newline
comment:
  The following script shows the bug:

  % text .t
  .t
  % pack .t
  % .t insert 1.0 "1111\n2222\n3333\n"
  % .t tag configure elidden -elide 1 -background red
  % .t tag add elidden 1.2 3.2

  The text widget now should contain one line with

  '1133'

  in it, but instead it contains two lines like this:

  11
  33

  and the region to the right of the '11' is actually 
  coloured red!  The bug seems to be that the newline in 
  the first line of an elided section is always 
  displayed.  (Note that the newline at the end of the 
  2222 line is correctly elided).


tkt_uuid: 220247ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: No response from Scriptics
comment:
  OriginalBugID: 3239 Bug
  Version: 8.0.4
  SubmitDate: '1999-10-28'
  LastModified: '1999-10-29'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  Machine: RS6000
  ClosedDate: '1999-10-29'


  Name:
  Anthony Johnson

  Comments:
  Please respond! Please respond! Please respond! Please respond! Please
      respond! Please respond! Please respond! Please respond! Please respond!
      Please respond! Please respond! Please respond! Please respond! Please
      respond! Please respond!

  ReproducibleScript:
  Scripts does not repond to bug report or any other inquiries.
      What does it take to get a bug fixed? Does Scriptics support this code
      or not?

  ObservedBehavior:
  I had supplied several bug reports over the last YEAR. I have received
      no email replies, and none of the reports have appeared on the
      comp.unix.aix newsgroup. I have sent several emails asking for updates
      with no replies. 
      
      The only response I ever received from Scriptics was a salesman trying
      to sell me support. I would be more than willing to purchase TclPro (if
      it were available for AIX) and support from Scriptics, but why should I
      now pay money to be completedly ignored?

  DesiredBehavior:
  ANY REPLY AT ALL!!!!!!!!!!!!!!!!!!!!!!!!!



  This person has received several responses before 10/28/99
  (the submission of this report).  Did we lose track of reports
  in some queue, or is this just an overeager submission? 
  -- 10/29/1999 hobbs


tkt_uuid: 814831ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Out of Date
title: No flat button relief, Mac Aqua
comment:
  Setting relief to "flat" makes no difference in Aqua Tk
  8.4.4.
  The button still appears raised.

  button .b -relief flat -text {hippo}
  pack .b

  The Python Mega-Widget package uses flat relief buttons
  for the
  tabs on tabbed panes (PMW Notebook).  The raised buttons
  make it not obvious these are tabs.

  This is related to tktoolkit bug 780528 which is a
  relief problem
  with radiobuttons with indicators off.


tkt_uuid: 544655ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Breaking MacOS 9 menus
comment:
  This bug report is to supercede #482139 as it doesn't
  need BWidget anymore to show the bug and is a short
  plaint tcl file.

  Current implementations (Tcl/Tk 8.3.4) of menu drawing
  routines have some show-stopper errors contained. The
  short example script attached shows how to reproduce a
  strange error:
  changing the labeltext when having menus open breaks
  the menus, that is, the menus are then shown relative
  to the menu window and not to the normal Mac
  Topmenubar.

  How to reproduce the error on Mac OS 9 (perhaps 8 too):

  1. start the attached script, make the window
  sufficiently large to show the label and place the
  window, say, amidst the screen.
  2. choose the first menu entry (labeled 'now') -> the
  label will change immediately and correctly
  3. now choose the second menu entry (labeled
  'after2000'). This will trigger the label change after
  2 seconds. BEFORE it has triggered, re-open the menu
  and let it stay open (that is, do not choose a menu
  entry).
  4. Wait for the after2000 to trigger

  5. You will now see two things:
    - that the normal menu (hopefully still opened, if
  not, restart at point 2) does not respond anymore.
    - parts of the menu are now drawn relative to the
  wish application window (that is, amidts the screen
  now), go with the mouse there and those menue will
  work. This does even include the Mac system menus!

  I'm a kind of perplexed.

  We've seen this kind of error also during other
  operations that involved gridding operations when
  having menus open, though I'll fill in a separate bug
  report once I extracted a small test case there too.

  Regards,
           Bastien


tkt_uuid: 220492ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: tk_chooseDirectory undocumnted
comment:
  OriginalBugID: 1786 Bug
  Version: 8.1b2
  SubmitDate: '1999-04-12'
  LastModified: '2000-01-26'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-01-26'
  FixedInVersion: 8.3


  Name:
  Christopher Nelson

  ReproducibleScript:
  info commands *ire*

  ObservedBehavior:
  There's no entry for tk_chooseDirectory in the .HLP file index nor can
      it be found by searching for directory

  DesiredBehavior:
  Document it like tk_getOpenFile and tk_saveFile; possibly on the same
      page (surely with a cross reference).



  Still missing in 8.2.1. 
  -- 10/22/1999 hobbs

  I added the documentation for tk_chooseDirectory as well as the implementation for Unix/Mac (adapted from the code in your errata).
  It will go out with 8.3.

  - eric

  -- 01/26/2000 ericm


tkt_uuid: 2821318fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 8
foundin: None
resolution: Fixed
title: tk::mac::iconBitmap crash
comment:
  The new tk::mac::iconBitmap command in Tk-Cocoa causes unpredictable crashes, especially when rendering a large number of images (such as in a file system/directory display). The crashes sometimes take the form of "alloc: invalid block: 0x11283a0c0" and sometimes a simple segfault. The sample script below, when tested with a large directory (163 + items), caused the invalid memory block crash: 

  toplevel .f

  set dir [tk_chooseDirectory]
  set filelist [glob -directory $dir *]


  foreach item $filelist {
       
      #  tk::mac::iconBitmap $item 16 16 -file $item
      if {[file isdir $item] || [file extension $item ] == "" } {
  tk::mac::iconBitmap $item 16 16 -file $item
      } else {

  tk::mac::iconBitmap $item 16 16 -fileType [lindex [split [file tail $item] . ] 1]
      }

      puts "creating iconbitmap for $item..."

      label .f.[lsearch $filelist $item] -bitmap $item -text [file tail $item] -compound left
      pack .f.[lsearch $filelist $item]

  }


tkt_uuid: 220610ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: tk configure and test failure
comment:
  OriginalBugID: 3348 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '1999-12-17'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: IRIX
  OSVersion: IRIX64 6.5.5
  FixedDate: '1999-12-17'
  FixedInVersion: 8.3b1


  Name:
  Nils H. Busch

  ReproducibleScript:
  enc CC=cc configure --enable-prefix=/home/ --enable-shared --enable
      threads
      make
      make test

  ObservedBehavior:
  compiler sgi cc v 7.3
      configure script tries to use gcc despite enc CC=cc and disabling gcc in
      configure
      modification to Makefile to eliminate unrecognized compiler options :
      n32 instead of -mabi=n32 and commenting out warning directives
      in configure:
      configure:1284: gcc -pipe -c -g -O2  conftest.c 1>&5
      gcc: -pipe is not supported.
      configure: failed program was:
      #line 1277 "configure"
      #include "confdefs.h"
      
      in make:
      
      c-1552 cc: WARNING File = ./../generic/tkFont.c, Line = 3031
        The variable "resultPtr" is set but never used.
      
            Tcl_Obj *resultPtr;
      
      c-1552 cc: WARNING File = ./tkUnixFont.c, Line = 342
        The variable "srcStart" is set but never used.
      
            CONST char *srcStart, *srcEnd;
      
      cc-1552 cc: WARNING File = ./tkUnixMenu.c, Line = 661
        The variable "margin" is set but never used.
      
            int margin;
                ^
      
      cc-1552 cc: WARNING File = ./tkUnixMenu.c, Line = 939
        The variable "currentRowWidth" is set but never used.
      
            int x, y, currentRowHeight, currentRowWidth, maxWidth;
                                        ^
      
      cc-1552 cc: WARNING File = ./tkUnixMenu.c, Line = 1138
        The variable "margin" is set but never used.
      
            int margin, segmentWidth, maxX;
      
      cc-1552 cc: WARNING File = ./../generic/tkEntry.c, Line = 584
        The variable "string" is set but never used.
      
                  char *string;
                        ^
      
      cc-1552 cc: WARNING File = ./../generic/tkEntry.c, Line = 1262
        The variable "string" is set but never used.
      
            char *string;
      
      cc-1552 cc: WARNING File = ./../generic/tkCanvText.c, Line = 629
        The variable "text" is set but never used.
      
              char *text;
      
      cc-1552 cc: WARNING File = ./../generic/tkImgPPM.c, Line = 356
        The variable "firstInLine" is set but never used.
      
            int i, numFields, firstInLine;
      int main() {
      
      ; return 0; }
      
      in make test
      entry.test
      
      ==== entry-3.81 EntryWidgetCmd procedure, "xview" widget command FAILED
      ==== Contents of test case:
      
          # UTF
          # If Tcl_NumUtfChars wasn't used, wrong answer would be:
          # {0.106383 0.319149} {0.117021 0.351064} {0.117021 0.351064}
      
          set x {}
          .e xview moveto .1
          lappend x [.e xview]
          .e xview moveto .11
          lappend x [.e xview]
          .e xview moveto .12
          lappend x [.e xview]
      
      ---- Result was:
      {0.0957447 0.255319} {0.106383 0.265957} {0.117021 0.329787}
      ---- Result should have been:
      {0.0957447 0.308511} {0.106383 0.319149} {0.117021 0.329787}
      ==== entry-3.81 FAILED
      
      unixFont.test
      
      ==== unixfont-1.2 TkpGetNativeFont procedure: native FAILED
      ==== Contents of test case:
      
          font measure fixed 0
      
      ---- Result was:
      12
      ---- Result should have been:
      6
      ==== unixfont-1.2 FAILED
      
      
      ==== unixfont-5.9 Tk_MeasureChars procedure: TK_PARTIAL_OK FAILED
      ==== Contents of test case:
      
          .b.c dchars $t 0 end
          .b.c insert $t 0 "0000"
          .b.c index $t @[expr int($ax*2.5)],1
      
      ---- Result was:
      4
      ---- Result should have been:
      2
      ==== unixfont-5.9 FAILED
      
      
      ==== unixfont-9.1 GetControlCharSubst procedure: 2 chars subst FAILED
      ==== Contents of test case:
      
          .b.c dchars $t 0 end
          .b.c insert $t 0 "0\a0"
          set x {}
          lappend x [.b.c index $t @[expr $ax*0],0]
          lappend x [.b.c index $t @[expr $ax*1],0]
          lappend x [.b.c index $t @[expr $ax*2],0]
          lappend x [.b.c index $t @[expr $ax*3],0]
      
      ---- Result was:
      0 1 3 3
      ---- Result should have been:
      0 1 1 2
      ==== unixfont-9.1 FAILED
      
      
      ==== unixfont-9.2 GetControlCharSubst procedure: 4 chars subst FAILED
      ==== Contents of test case:
      
          .b.c dchars $t 0 end
          .b.c insert $t 0 "0\0010"
          set x {}
          lappend x [.b.c index $t @[expr $ax*0],0]
          lappend x [.b.c index $t @[expr $ax*1],0]
          lappend x [.b.c index $t @[expr $ax*2],0]
          lappend x [.b.c index $t @[expr $ax*3],0]
          lappend x [.b.c index $t @[expr $ax*4],0]
          lappend x [.b.c index $t @[expr $ax*5],0]
      
      ---- Result was:
      0 1 1 3 3 3
      ---- Result should have been:
      0 1 1 1 1 2
      ==== unixfont-9.2 FAILED
      
      
      unixWm.test
      
      ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a toplevel,
      x-coords FAILED
      ==== Contents of test case:
      
          eval destroy [winfo children .]
          toplevel .t -width 300 -height 400 -bg green
          wm geom .t +40+0
          tkwait visibility .t
          toplevel .t2 -width 100 -height 80 -bg red
          wm geom .t2 +140+200
          tkwait visibility .t2
          raise .t2
          set x [winfo rootx .t]
          set y [winfo rooty .t]
          list [winfo containing [expr $x - 30] [expr $y + 250]]  [winfo
      containing [expr $x - 1] [expr $y + 250]]  [winfo containing $x [expr $y
      + 250]]  [winfo containing [expr $x + 99] [expr $y + 250]]  [winfo
      containing [expr $x + 100] [expr $y + 250]]  [winfo containing [expr $x
      + 199] [expr $y + 250]]  [winfo containing [expr $x + 200] [expr $y +
      250]]  [winfo containing [expr $x + 220] [expr $y + 250]]
      
      ---- Result was:
      {} {} .t {} {} {} {} .t
      ---- Result should have been:
      {} {} .t {} .t2 .t2 {} .t
      ==== unixWm-50.1 FAILED

  DesiredBehavior:
  successful test



  The noted compiler warnings have been fixed (good smart compiler).
  The test warnings are innocuous, and due to the fact that the test
  results are based on the tests running with a specific window
  manager (not 4dwm). 
  -- 12/17/1999 hobbs


tkt_uuid: 1235125fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Duplicate
title: MinGW: tkWinX.c reference error `SendInput'
comment:
  Compiling Tk8.5a3 on a W2K/SP4 with MSYS/MinGW
  (msys_mingw-0.6) I get the following error:

  /D/Tcl-Tk/Source tk8.5a3/win> ./configure --enable-gcc
  /D/Tcl-Tk/Source tk8.5a3/win> make
  ...
  [snip]
  ...
  Creating library file: libtk85.a
  tkWinX.o(.text+0x1b35):tkWinX.c: undefined reference to
  `SendInput'
  make: *** [tk85.dll] Error 1
  /D/Tcl-Tk/Source/tk8.5a3/win>


tkt_uuid: 3042724fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: TK dies with specific filename
comment:
  if I name a file 'menubutton.tcl' it errors on mouseover. Simplest file:
  pack [text .e]

  If I name it other things, it works fine. If I name it 'menubutton.tcl', every mouse over  generates the following message, twice:
  unknown option "-state"
      while executing
  "$w cget -state"
      (procedure "tk::MbEnter" line 8)
      invoked from within
  "tk::MbEnter ."
      (command bound to event)

  I'm running ActiveState 8.5.8


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


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

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

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

  selected.



  This patch fixes that problem.



  Ian Taylor

  ian@cygnus.com



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

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

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

  *** 200,205 ****

  --- 200,209 ----

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

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

          }

  + 

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

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

  + 

          incr i

        }



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

  To reiterate that behavior:

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

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


tkt_uuid: 220759ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: Add documentation for '-disabledforeground' to the label man page
comment:
  OriginalBugID: 6053 Bug
  Version: 8.4a1
  SubmitDate: '2000-07-25'
  LastModified: '2000-07-28'
  Severity: MED
  Status: Released
  Submitter: kuchler
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-07-28'
  FixedInVersion: 8.4a2


  The label has a disabled foreground flag for controlling the foreground
  color when it is disabled, but this is not documented.

  This should be added to the man page (and can probably be stolen from the
  button man page).



  I added -disabledforeground to the list of standard options supported by the widget.  Thanks for pointing this oversight out.

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

  -- 07/28/2000 ericm


tkt_uuid: 3602582fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 6
severity: Minor
foundin: current: 8.6.0
resolution: Invalid
title: text widget wrapping oddly
comment:
  I'm not totally sure if this is a bug or intended behaviour:

  pack [text .t -wrap word -width 80]
  .t insert end [string repeat "la " 28]
  puts [.t count 1.0 "1.0 display lineend";# 77

  The text widget wraps so that the second line contains "la la", despite the first line being only 77 characters long - long enough that the penultimate "la" would fit. This may well be deliberate - if the extra "la" was shown on the first line, it would mean that either the second line would start with a space (which never looks good), or that there would be no visual indication that the last word wasn't "lala" and it was wrapped per-char (which could be confusing). But a couple of people using an app have reported it as weird behaviour, so I thought I'd run it up the flagpole to you guys to double-check.


tkt_uuid: 2045553fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.6a1
resolution: None
title: tk_getSaveFile -defaultextension disagrees with its man page
comment:
  The man page for -defaultextension in tk_getSaveFile states that:

  -defaultextension extension
  Specifies a string that will be appended to the filename if the user enters a filename without an extension. The default value is the empty string, which means no extension will be appended to the filename in any case. This option is ignored on Mac OS X, which does not require extensions to filenames, and the UNIX implementation guesses reasonable values for this from the -filetypes option when this is not supplied.

  So, if I read this correctly, *on Windows* using -defaultextension "" or without this option should provide the same result: a file with no extension (when the user does not force the extension in the filename it enters).

  However, on Win XP with 8.6a0 I get (I only type myfile in the dialog using the keyboard, with no extension):

  tk_getSaveFile -defaultextension "" -filetypes {{"xyz type" "*.xyz"}}
    ---> myfile.xyz
  tk_getSaveFile -filetypes {{"xyz type" "*.xyz"}}
    ---> myfile

  The latter should spit myfile.txt and not only myfile. On Windows, this is therefore a bug.

  On Linux, I get myfile.xyz for both commands, which is consistent with the man page.

  Can't test on Mac, sorry.

  Francois


tkt_uuid: 936195ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 55. [focus]
priority: 6
foundin: None
resolution: None
title: Reset focus to embedded windows (bug fix)
comment:
  This patch provides a fix for handling bogus FocusOut
  events as can be observed by using an embedded
  application on certain X11 Window managers.

  This may be connected to the bugs #740565 and/or #480158.

  This patch is against Tk8.4.1 and confirmed to work on
  the following Unix systems:
  SLES 7 + 8 (ia32);
  RHEL 2.1 + 3.0 (ia32);
  SLES 8 (s390);
  SUN Solaris 5.7, 5.8, 5.9 (Sparc);
  AIX 4.3, 5.1, 5.2;
  HPUX 11+ (PA-Risc);
  Tru64 5.1;

  Not tested on other operating systems. This patch was
  originally developed by krischan (SF id).


tkt_uuid: 220371ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.0
resolution: Fixed
title: canvas tags bug
comment:
  OriginalBugID: 640 Bug
  Version: 8.0
  SubmitDate: '1998-05-25'
  LastModified: '1999-09-14'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-09-14'
  FixedInVersion: 8.2
  ClosedDate: '1999-09-13'


      I just found a very irritating bug in binding
  Tk canvas tags.  Asking for a binding for a non-existant
  canvas tag causes an error, but not an error message,
  making it very hard to track down a related bug.
  Strangely, Tk lets you create bindings to non-existant
  tags without complaint, which is very useful.

  netscape is very stupid and I have no middle mouse
  button so I have to type this in by hand, so forgive
  any errors

  plato% wish8.0
  % canvas .c
  % .c bind fred <Enter>
  % set errorInfo

      while executing
  ".c bind fred <Enter>"
  % .c bind fred <Enter> "puts hello"
  % .c bind fred <Enter>
  puts hello
  %

  -peter.
  pfl@fmsc.com.au

  Testing this in 8.2, I get:

  (tkcon) 54 % catch {.c bind bogus <Enter>}
  0

  which means that an error is not getting generated. 
  -- 09/13/1999 hobbs


tkt_uuid: 412727ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: XIM Patch
comment:
  Re-registration of Tcl Patch 402391 from bitwalk
  (Keiichi Takahashi).  It patches Tk, not Tcl.
  It belongs here.


tkt_uuid: 1212056fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 8
foundin: obsolete: 8.5a5
resolution: Fixed
title: panic on exit with safe tk window
comment:
  The following script (or entering the commands in the
  console) causes a panic in Tk 8.4.9 and Tk 8.4.10 on
  Windows when the process exits. This does NOT cause a
  panic on Tk 8.5a3

  package require Tk
  set slave [safe::interpCreate]
  safe::loadTk $slave
  after 1000 {set forever 1} ; tkwait variable ::forever
  exit

  On exit we get  a Fatal Error in Wish dialog with the
  message "TkpGetOtherWindow couldn't find window"
  followed by the Windows application crashed dialog.


tkt_uuid: 1206133fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Fixed
title: File filters broken on open and save dialogs
comment:
  System: WinXP, tcl/tk 8.5 from CVS, Mingw32 (gcc 3.4.2)

  While running the Tk 8.5 CVS widget demos, the file
  dialog demonstration does not create the full list of
  file filters, meaning, it actually only creates the
  list for the first filter.

  Looking at the sources, this seems to have been broken
  with a change made 5 months ago!

  In the file tk/generic/tkFileFilter.c function
  TkGetFileFilters, while iterating through the types
  list, there is a call to function AddClause:

  int
  TkGetFileFilters(interp, flistPtr, types, isWindows)
  ...
      for (i = 0; i<listObjc; i++) {
          ...
  if (count == 2) {
      return AddClause(interp, filterPtr, typeInfo[1], 
       NULL, isWindows);
  } else {
      return AddClause(interp, filterPtr, typeInfo[1], 
       typeInfo[2], isWindows);
  }
      }
     ...
  }

  Now... i don't think this is the intended behaviour,
  since it will terminate execution after adding the
  first clause.


tkt_uuid: 1012837fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 2
foundin: None
resolution: Fixed
title: more spelled docs
comment:
  Affected files are:
  font.n, keysyms.n, MaintGeom.3, options.n, 
  ParseArgv.3, photo.n, TkInitStubs.3

  in file photo.n string #186 is:

  only every xth pixel in the X direction and yth pixel in

  I think, it's better (for readability) to separate dimension 
  letter (x or y) and suffix 'th'
  I.e. x'th or y-th


tkt_uuid: 472250ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: tkConfig.sh not in MacOSXTk8.4a4.tar.gz
comment:
  In the Mac OS X build available on tcl.sourceforge.net 
  (MacOSXTk8.4a4.tar.gz), tkConfig.sh is missingin the TK 
  framework, although tclConfig.sh is available in TCL 
  framework.

  Please deliver this vital piece for anyone wishing (!) to use 
  Tk libs on Mac OS X.

  Thanks,
  Rupert


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

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

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

  -- Russell


tkt_uuid: 220381ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: display popup window in center of screen rather than left corner
comment:
  OriginalBugID: 687 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-02'
  LastModified: '1999-08-13'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-13'
  FixedInVersion: 8.1.1


  Hi,
          For what your information when running on Windows NT 4.0 Service
  Pack 3 I have found that the files dialog.tcl and msgbox.tcl need to
  have the following mods made for the popup window to be displayed in the
  center of the screen as intended rather than the upper left corder:

  bash-2.01$ diff dialog.tcl dialog.tcl.orig
  134,136d133
  <     if {$tcl_platform(platform) == "windows"} {
  <          update idletasks
  <     }

  bash-2.01$ diff msgbox.tcl msgbox.tcl.orig
  224,226d223
  <     if {$tcl_platform(platform) == "windows"} {
  <          update idletasks
  <     }

  I believe this same detail was in prior Versions of Tcl/Tk and has
  perhaps been reported by others but is is still there and is annoying.

  Thanks
  Kevin

  This was fixed in or before 8.1.1. 
  -- 08/13/1999 hobbs


tkt_uuid: 1088617fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Invalid
title: Control character appears in listbox
comment:
  The character "\x00" is appearing in basically any tk 
  object when the nul character ( ASCII x00) exists in the 
  string. The 8.0 version did not draw this. Other control 
  characters (0x80 and others) are also being printed. 
  Happens to entry, label, and text as well.

  Easy test using wish

  set str "\x00"
  pack [ listbox .test ]
  .text insert end $str


tkt_uuid: 1493144fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 39. Image Basics
priority: 5 Medium
foundin: None
resolution: None
title: terrible performance deleting canvas with many images
comment:
  The following script exposes a performance problem
  deleting canvases with many images:
  #---
  canvas .c
  set img [image create photo]
  for {set i 0} {$i < 40000} {incr i} { .c create image
  10 10 -image $img }
  destroy .c
  destroy .
  #---
  Almost all of the time (100 seconds on my system) is
  spend in the line "destroy .c", and C-level profiling
  with 'callgrind' shows that most of that time is in
  tkImage.c:Tk_FreeImage, traversing the linked list of
  images.

  Tested in 8.4.10 on linux but by inspection of the
  source I don't have any reason to believe the
  performance has been improved in 8.4.14 or 8.5.


tkt_uuid: 220788ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: None
title: request support for a window event "proxy"
comment:
  OriginalBugID: 1302 RFE
  Version: 8.1b1
  SubmitDate: '1999-02-25'
  LastModified: '2000-04-03'
  Severity: SER
  Status: Assigned
  Submitter: pat
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: 4
  Machine: X86


  Name:
  Bryan Oakley

  DesiredBehavior:
  I would like to be able to define an event "proxy" for a given window.
  For example,

      event proxy .foo.internal .foo

  would cause all events that happen within .foo.internal to be handled as
  if they actually occured over .foo. %W would report ".foo" in the
  binding scripts,
  and %x and %y would be relative to .foo instead of .foo.internal. 

  To support this, I also recommend adding a %P substitution in binding
  scripts, that returns the "proxied" window. In the above case, %W would
  refer to .foo and %P would be set to .foo.internal. This way binding
  scripts could know exactly which subwindow received the event, but %W
  would continue to work as expected.

  This would go a long way to being able to create megawidgets that behave
  like
  "real" widgets. Right now the workaround is a whole lot of event
  juggling and
  transmogrification -- imperfect at best -- which is a royal pain.







  Please seriously consider including this in the next beta of 8.1, so
  that we don't have to wait another year before this feature is
  available. I'd settle for this to be an unsupported feature for the
  purposes of experimentation.


  --

  this would really help with megawidgets.

  - eric
   
  -- 04/03/2000 ericm


tkt_uuid: 688188ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: Leave event not working correctly in OS X Aqua
comment:
  Compiled CVS version today of tk OS X Aqua.  When the
  user presses the mouse button and moves the mouse, both
  B1-Motion and B1-Leave are immediately generated (even
  when the mouse stays inside the window) and B1-Leave is
  not generated as the user leaves the window.


tkt_uuid: 1277227fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 4
foundin: None
resolution: Fixed
title: Notebook missing update event
comment:
  There seems to be a missing update event for nonmapped 
  pages when a notebook is resized, at least on Aqua. Win XP 
  seems ok. The script below reproduces the problem on my 
  MacOSX 10.2.8 box. Do: Click Tab2, increase the windows 
  size, click Tab1 => canvas not redrawn.

  This is just moved here from tile [ 1276374 ] Notebook 
  missing update event
  http://sourceforge.net/tracker/
  index.php?func=detail&aid=1276374&group_id=11464&atid=1
  11464
  since it only appears on Macs

  Mats

  package require tile
  ttk::notebook .nb
  .nb add [canvas .nb.c1 -width 100 -height 100] -text Tab1 -
  sticky news
  .nb add [canvas .nb.c2 -width 100 -height 100] -text Tab2 -
  sticky news
  .nb.c1 create oval 10 10 200 200 -fill blue
  pack .nb -fill both -expand 1
  bind .nb.c1 <Configure> {puts "Configure Tab1: [winfo width 
  %W]"}
  bind .nb.c1 <Map> {puts "Map Tab1: [winfo width %W]"}

  # Click Tab2, increase the windows size, click Tab1 => 
  canvas not redrawn


tkt_uuid: 220898ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: Excessive redrawing in Text widget
comment:
  OriginalBugID: 4343 Bug
  Version: 8.3
  SubmitDate: '2000-03-08'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Linux-Red Hat


  Name:
  D. Richard Hipp

  ReproducibleScript:
  When a text widget has focus but the flashing I-Beam insertion
  cursor is not visible on the page (because the insertion cursor 
  is located at a point in the document that is scrolled off the 
  visible part of the page) then the entire visible part of the 
  text widget is redrawn on every insertion cursor flash.

  I reported this same problem against Tk8.0.  It was fixed
  in Tk8.2.  But now it is broken again.

  ObservedBehavior:
  All text is drawn once per second, causing a noticable
  performance problem when Tk is connected to the X-server
  over a slow wire (ex: an analog modem).

  DesiredBehavior:
  You should not refresh the whole screen to flash the
  insertion cursor.  This is especially true if the
  insertion cursor isn't even visible.


tkt_uuid: 403047ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Allow multi-file select on Win9x as well
comment:
  The patch supplied is for tk/win/tkWinDialog.c

  With 8.4, the ability to select multiple files via
  the tk_getOpenFile was supposed to be allowed. I downloaded
  the latest sources and noticed that this was indeed
  done for WinNT but not for Win9x. As far as I can tell,
  the very EXACT changes also apply to the Win9x platform.

  So, I copied the logic from the WinNT side to the Win9x side
  and (made small changes to allow regular TCHAR strings).

  Since we are now allowing multiple files, I also increased
  the buffer size to be twice as big as MAX_PATH.

  I also noticed that in the Win9x side, we save and restore
  the current-working directory whereas on WinNT we do not.
  I do not know the reason for this (and I do not have
  access to a WinNT machine to see why). I did not modify this
  part since there may have been a good reason why the current
  working directory does not have to be saved and restored.

  I personally recommend doing the same thing for both platforms 
  so that the code for the two is as similar as possible.

  Regards,
  Haneef


tkt_uuid: 1173484fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Invalid
title: Memory leak
comment:
  Test code:

  while {1} {
  frame .f
  destroy .f
  }

  On large and long running projects memory usage
  increases significantly over time.

  If it is any help a valgrind log has been attached that
  shows what it thinks maybe memory issues.


tkt_uuid: 3431491fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 27. Objects
priority: 7 High
foundin: obsolete: 8.5.10
resolution: Fixed
title: canvas create line slow for pure lists of double coordinates
comment:
  In our application, we noticed that "canvas create line" takes a considerable amount of time when the list of coordinates is not pre-shimmered before it enters the canvas. It looks like the list itself does not gain a string representation, but every double inside does gain a string representation and a type conversion to "pixel". A list of doubles with string representations appears to go around 25x faster than a list of pure doubles, at least with our particular systems and usage of the canvas. After some examination of Tk, I believe the string conversion happens in the conversion to the pixel type. I only tested this on 8.5.9.


tkt_uuid: 220743ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: bgerror doesn't log to file
comment:
  OriginalBugID: 5781 Bug
  Version: 8.4a1
  SubmitDate: '2000-06-01'
  LastModified: '2000-06-02'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-06-02'
  FixedInVersion: 8.4a1


  Name:

  Don Porter



  CVS:

  $Id: bgerror.tcl,v 1.9 2000/05/31 23:28:46 ericm Exp $



  ReproducibleScript:

  $ wish

  % after 0 error foo

    <error dialog appears.

     click Details.

     dialog expands.

     click Save to Log

     file selection dialog appears.

     select foo.log

     click Save>

  % foo

      while executing

  "error foo"

      ("after" script)



  <foo.log is created, but is empty>



  DesiredBehavior:

  foo.log should contain the stack trace.

  No message should appear in interactive

  window.



  Patch:

  Index: library/bgerror.tcl

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

  RCS file: /cvsroot/tk/library/bgerror.tcl,v

  retrieving revision 1.9

  diff -c -r1.9 bgerror.tcl

  *** bgerror.tcl2000/05/31 23:28:461.9

  --- bgerror.tcl2000/06/01 15:03:35

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

  *** 62,68 ****

    return

        }

        set f [open $filename w]

  !     puts -nonewline $text

        close $f

    }

    

  --- 62,68 ----

    return

        }

        set f [open $filename w]

  !     puts -nonewline $f $text

        close $f

    }



  PatchFiles:

  library/bgerror.tcl





  whoops!  Thanks for catching that one.  I put the fix in for 8.4a1.

  - eric
   
  -- 06/02/2000 ericm


tkt_uuid: 220868ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.1
resolution: None
title: -command option doesn't seem to work for cascade menu items on unix
comment:
  OriginalBugID: 2816 Bug
  Version: 8.1
  SubmitDate: '1999-09-16'
  LastModified: '1999-10-29'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: based on debain 2.0, kernel is 2.0.34
  Machine: Other


  Name:
  Phil Endecott

  Extensions:
  None in the demo above.  My real application uses [incr tcl].  Some of my code uses tclx.

  CustomShell:
  None in the demo above.  My real application integrates my own code using SWIG.

  Comments:
  I've had a brief look at the source and can't see anything obviously
      wrong, but I've never delved into tk innards before.  I've tried to
      check for changes in more recent versions but searching for "cascade" on
      the scriptics web site doesn't find anything.  I have a very slow modem
      (14k4!) so I don't want to download a whole new package just in the hope
      that you've fixed it!!!

  ReproducibleScript:
  ernie:~/incr_draw$ wish8.1 
      % menu .m
      .m
      % menu .m.c
      .m.c
      % .m add cascade -menu .m.c -label "foo" -command {puts foo}
      % .m add command -label "blah"
      % bind . <ButtonPress-3> {tk_popup .m %X %Y}

      Press button-3 on the main window.  Menu pops up with a cascade entry.
      Nothing causes the puts foo command to get executed.

  ObservedBehavior:
  Nothing causes the puts foo command to get executed.

  DesiredBehavior:
  The man page says:

             If a -command option is specified for a cascade entry then |
             it is evaluated as a Tcl command  whenever  the  entry  is |
             invoked. This is not supported on Windows.

      I'm not running on windows.

      I'm not quite sure what "invoked" means here - I hope that it means that
      the command should get executed just before the submenu is posted.  But
      I can't cause it to be executed at any time at all.

      The workaround is to use the -postcommand on the submenu, but this isn't
      very suitable in my application because I have the same submenu bound to
      more than one cascade entry in the parent menu.  I need the behaviour of
      the command to be specific to the cascade entry, not to the submenu.


tkt_uuid: 219999ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Fixed
title: image -data option needs revisiting
comment:
  OriginalBugID: 2295 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-28'
  LastModified: '1999-08-05'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2431
  OS: Other
  OSVersion: NetBSD-1.4/i386
  Machine: NA
  ClosedDate: '1999-08-05'


  Name:
  Hume Smith

  ReproducibleScript:
  #!/usr/bin/env wish
      
      regsub -all .. [join {
      47494638376120002000c20000000000ffff0000ff008080000000ffff00
      000000000000002c00000000200020000003ac08badcfe908d01268d38cf
      cc4108de5775594078c479919089aa6c247ee01a3fab754b56afeb249f70
      22a80031c39e6020681a3748e393c96c3a7b1ae1d209b04e6d8e2675cbdd
      767d18abbaa8a876c547c896ba301b97714ca1b0702bac581c7b6d5e7d78
      50197b646c758788118a857d54817a7c7270790f7c970d448e607a61999a
      2c16a0a13898a85393178f8da414425fa5a749b8a56fb2b97f8ca3804a43
      a69f856b3b80bf3bcb1109003b} {}] {\\x&} x
      set x [subst $x]
      
      if {[catch {image create photo -format gif -data $x} n]} {
      puts {-data failed}
      } {
      label .1 -image $n
      pack .1
      }
      
      set fn /var/tmp/[pid]
      set f [open $fn w]
      fconfigure $f -translation binary
      puts -nonewline $f $x
      close $f
      
      if {[catch {image create photo -format gif -file $fn} n]} {
      puts {-file failed}
      } {
      label .2 -image $n
      pack .2
      }
      
      # eof

  ObservedBehavior:
  Creating the image using -data fails.

  DesiredBehavior:
  Now that we have binary string capability, I would expect two
      images to appear (sorry for the tactless choice, it was the
      smallest GIF i had. :-).



  This issue is addressed in the related report (Img patch).  It
  has been evaluated and is scheduled for 8.3. 
  -- 08/05/1999 hobbs


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

  tk_chooseDirectory

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

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

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


tkt_uuid: 404703ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 1 Zero
foundin: None
resolution: Works For Me
title: TK_NO_SECURITY doesn't work (for me?)
comment:
  When building tk/8.3.2 I used the following in the
  Makefile.in:

  # To turn off the security checks that disallow
  incoming sends when
  # the X server appears to be insecure, reverse the
  comments on the
  # following lines:
  #SECURITY_FLAGS      =
  SECURITY_FLAGS    = -DTK_NO_SECURITY

  I assume this is supposed to 'shut off' xauth security
  checks when
  running wish scripts on X servers.  However I have
  always gotten the following message no matter what
  version of wish I build and on what platform:

  "Error: X server insecure (must use xauth-style
  authorization); command ignored."

  Is there something else I have to do when using
  -DTK_NO_SECURITY?  Or has this never been
  implemented/tested?  Are there any special instructions
  to building
  or installing 'unix/libtk8.3.so'?

  Thanks
  -Nick Oleksinski


tkt_uuid: 1288128fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.4.11
resolution: Fixed
title: crash bug in '$text tag configure'
comment:
  In Tk 8.4.11, running the 'tag configure' subcommand on 
  a text widget for a tag which has not previously 
  been 'declared', with no arguments, crashes the 
  program. For example,

    text .t
    .t tag configure foobar

  will crash, but

    text .t
    .t tag configure foobar -underline 0
    .t tag configure foobar

  will not. 


tkt_uuid: 1144186fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: None
title: -use -container embedded windows menu problems
comment:
  # When a wish toplevel is embedded in a frame or
  toplevel of another wish app that has been identified
  as a container, there are problems with menus.

  # same whether the container is a frame or a toplevel

  # X11:
  # the menu bar is there, but the menus pop up in the
  wrong place (a bit too low on the screen)
  # Tested in Fedora Core 3
  # Same with 3 different window managers: KDE
  3.3.1-2.4.FC3, Gnome (metacity 2.8.6-2), or XFCE
  (xfwm4-4.0.6-1)
  # Same with both current versions of ActiveTcl:
  8.4.9.0, 8.5.0 beta3 (8.5a2)

  # Windows - a different problem
  # Windows XP Home (SP2): the menu bar does not appear
  at all.

  # test script is attached


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

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

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


tkt_uuid: 1162356fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Fixed
title: Bug in InvokeClientMessageHandlers
comment:
  There is a bug in InvokeClientMessageHandlers, that
  prevents TkDND from running with the Tk 8.5 series.
  (The bug does not allow any ClientMessage Handler to 
  be invoked.) The correct code of the function is:

  /*
   *------------------------------------------------------
   *
   * InvokeClientMessageHandlers --
   * 
   * Iterate the list of handlers and invoke the function
   * pointer for each.  
   * 
   * Results: 
   *     None.
   *
   * Side effects:
   *     Handlers may be deleted and events may be sent 
  to
   *     handlers.
   *------------------------------------------------------
   */
  static void
  InvokeClientMessageHandlers(tsdPtr, tkwin, eventPtr)
      ThreadSpecificData *tsdPtr;
      Tk_Window tkwin;
      XEvent *eventPtr;
  {
      GenericHandler *prevPtr;
      GenericHandler *curPtr = tsdPtr->cmList;
      GenericHandler *tmpPtr;

      for (prevPtr = NULL; curPtr != NULL; ) {
          if (curPtr->deleteFlag) {
          if (!tsdPtr->handlersActive) {
              /*
           * This handler needs to be deleted and there are
           * no calls pending through any handlers, so now
           * is a safe time to delete it.
           */
            
              tmpPtr = curPtr->nextPtr;
          if (prevPtr == NULL) {
              tsdPtr->cmList = tmpPtr;
          } else {
              prevPtr->nextPtr = tmpPtr;
          }
          if (tmpPtr == NULL) {
              tsdPtr->lastCmPtr = prevPtr;
          }
          (void) ckfree((char *) curPtr);
          curPtr = tmpPtr;
          continue;
          }
          } else {
              int done;
          
              tsdPtr->handlersActive++;
              done = (*(Tk_ClientMessageProc *)curPtr->proc)
                (tkwin, eventPtr);
              tsdPtr->handlersActive--;
              if (done) {
                  break;
              }
          }
      prevPtr = curPtr;
      curPtr = curPtr->nextPtr;
      }
  }


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


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


tkt_uuid: 1608046fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 7 High
foundin: obsolete: 8.4.11
resolution: Fixed
title: listbox itemconfigure slowness
comment:
  On comp.lang.perl.tk there was a report that
  Tk::Listbox::itemconfigure gets much slower if the number of listbox increases.

  It seems that this problem also affects Tcl/Tk.

  Please see http://groups.google.com/group/comp.lang.perl.tk/browse_frm/thread/599e8df5fcb12c2b/7c7418b3f6e4a7cc#7c7418b3f6e4a7cc
  for the discussion and a possible solution for the problem, which might also be applicable to Tcl/Tk.

  Regards,
      Slaven


tkt_uuid: 572978ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: Patch for TIP 47
comment:
  This patch includes the changes for TIP 47
  and the two little fixes needed to get
  everything working under Windows. This patch
  was integrated on 2002-06-14, this patch is
  just here so that someone can look at the
  patch in the future if needed.


tkt_uuid: 220846ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Request non-dithered photo image support
comment:
  OriginalBugID: 2167 RFE
  Version: 8.0.4
  SubmitDate: '1999-06-03'
  LastModified: '2000-01-29'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 5.5.1
  Machine: Other


  Name:

  Nancy Aten



  DesiredBehavior:

  My Tk app uses colors in a limited way - toolbars, graphic views with

      small set of colors and where exact color reproduction is not important.

      (I suspect this is a common situation for Tk apps). For applications

      like this, a) colors should not be dithered and b) the application

      should use already available colors and be neighborly about colormaps on

      unix (no flashing).

      

      "image create photo" does not meet these requirements. Instead, I must

      use the Img patch and "image create pixmap" of converted xpm files to

      get what I need. I also patched tkImgPhoto.c to make "image create

      photo" work how I wanted, but maintaining a core tcl/tk patch in a

      production environment is a pain, so I don't want to do it! So I'm using

      Img, but would prefer it if Tk's photo image provided what I need.

      

      Here's the patch I created. I am certainly no colormap expert; this was

      by trial and error. But it does make my toolbar buttons and other

      graphic glyphs look neat and clean and non-dithered and non-flashing in

      the presence of colormap hogs like netscape.



  Patch:

  361c365,366

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

  ---

  > static void           AllocateColors _ANSI_ARGS_((ColorTable *colorPtr,

  >                                                   Tk_Window tkwin));

  2459c2464,2465

  <       AllocateColors(colorPtr);

  ---

  >       AllocateColors(colorPtr,

  >                      Tk_MainWindow (instancePtr->masterPtr->interp));

  2517c2523

  < AllocateColors(colorPtr)

  ---

  > AllocateColors(colorPtr, tkwin)

  2519a2526

  >     Tk_Window tkwin;

  2524c2531

  <     XColor *colors;

  ---

  >     XColor *colors, *matchedColor;

  2644,2645c2651,2652

  <           if (!XAllocColor(colorPtr->id.display, colorPtr->id.colormap,

  <                   &colors[i])) {

  ---

  >           matchedColor = Tk_GetColorByValue(tkwin, &colors[i]);

  >           if (!matchedColor) {

  2659a2667,2668

  >           } else {

  >               colors[i] = *matchedColor;

  3623c3632

  <     int doDithering = 1;

  ---

  >     int doDithering = 0;



  PatchFiles:

  generic/tkImgPhoto.c


tkt_uuid: 758123ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: Xft: wrong fonts selected for display
comment:
  Georgios Petasis reports on comp.lang.tcl that on his
  system (RH9, with MS Unicode fonts installed), buttons
  and other Tk widgets are displayed in a serif font
  instead of a sans-serif one as expected:

  http://groups.google.com/groups?threadm=bbk4hl%24278g%241%40ulysses.noc.ntua.gr


tkt_uuid: 962589ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: Error when handling ^ in some cases
comment:
  This bug has been seenin both 8.4.6 and 8.5 on
  MacOSX (latest AquaBI distros) as well as win98
  (lastest Activestate distros). I assume it affects
  all platforms as it is in generic code.

  The following test code will demonstrate the problem

  gridtest work
  gridtest fail-x
  gridtest fail-omit

  the first time (case work) will not error and will show
  the layout & resize behavior I want *except* that item
  'i' is only there to avoid the bug, I really want empty space
  where 'i' is located - the relevant row  "work" uses:
      grid ^ ^ ^ .i
  to make an explicit empty space case "fail-x" uses:
      grid ^ ^ ^ x
  to make an implicit empty space case 'fail-omit" uses:
      grid ^ ^ ^

  both of the fail cases should give me what I am looking for
  but both complain with "can't use '^', cant find master"

  prod gridtest case {

    catch {eval destroy [winfo children .]}
    foreach w {a b c d e f g h i j k l m n o p q} {
        button .$w -text $w
    }
    grid .a .b .c .d -sticky news -padx 2 -pady 2
    grid .e  - .f .g -sticky news -padx 2 -pady 2
    grid  ^  ^  ^ .h -sticky news -padx 2 -pady 2
    switch $case {
       work {
         grid ^ ^ ^ .i -sticky news -padx 2 -pady 2
       }
       fail-x {
          grid ^ ^ ^ x -sticky news -padx 2 -pady 2
       }
       fail-omit {
           grid ^ ^ ^ -sticky news -padx 2 -pady 2
       }
    }
    grid ^ ^ ^ .j -sticky news -padx 2 -pady 2 
    grid ^ ^ ^ .k -sticky news -padx 2 -pady 2
    grid .l - - - -sticky news -padx 2 -pady 2
    grid .m .n .o .p -sticky news -padx 2 -pady 2
    grid columnconfigure . 1 -weight 1
    grid rowconfigure . 3 -weight 1

  }

  Bruce Hartweg


tkt_uuid: 1753609fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: menu separator background
comment:
  with
     set ::tk::mac::useCustomMDEF 1
  a menu separator uses a different background than the menu items.

  This is barely noticable and only cosmetic, but still a nuicance.

  kind regards,
  uwe


tkt_uuid: 1792191fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5b3
resolution: Fixed
title: Copy-paste error on manual page
comment:
  Text on "tag remove" is apparently copy-pasted from "tag add", because "If the last index2 is omitted then the single character at index1 is tagged." This information is also wrong because "ending just before index2 (the character at index2 isn't affected)." means "tag remove tagname index" is a no-op (index2 == index1).


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


  Tk 8.3.1 Bug

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

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

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

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

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

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


tkt_uuid: 220391ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: Compilation on DEC Alpha with MS VC++ 4.2-5.0 failed
comment:
  OriginalBugID: 763 Bug
  Version: 8.1a2
  SubmitDate: '1998-10-27'
  LastModified: '1998-12-10'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-12-10'
  FixedInVersion: 8.1b1


  Subject: Alpha-specific bug in Tk/winMain.c/WishPanic (MSVC++)
  From: petteri.kettunen@picker.fi

  Tk 8.1a2 Bug
  email:  petteri.kettunen@picker.fi
  Severity:  1
  Support:  None
  OperatingSystem:  Windows NT
  Extensions:  N/A
  CustomShell:  N/A
  Synopsis:  Alpha-specific bug in Tk/winMain.c/WishPanic (MSVC++)

  ReproducibleScript:
  Take source distribution and compile in DEC Alpha with MS VC++ 4.2-5.0.
  We have encountered this problem with 8.0p2/8.1a2.

  ObservedBehavior:
  Compilation fails (line 203)

  DesiredBehavior:
  Clean compilation.

  Patch:
  C:\tk\tmp>diff winMain.c.old winMain.c
  202c202
  < #ifdef _MSC_VER
  ---
  > #if defined(_MSC_VER) && defined(_X86_)


  12/10/1998 10:41 - stanton - The _asm statement has been replaced with the more portable DebugBreak() call.


tkt_uuid: 680660ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: Menu items accidentally selected
comment:
  The bindings for menubuttons/menus allow mouse
  selection by
  either press-drag-release or by click-move-click, and
  both
  normally work fine.  However, when the menu is posted
  so it
  overlaps the menubutton, the click-move-click scheme
  fails
  because some random menu item receives the
  ButtonRelease 
  from the initial click on the menubutton, and gets
  selected
  immediately.

  I have included a demo, if that is of any use.  Try
  clicking on
  the menu button with the window positioned mear the
  bottom
  of the computer screen.

  This behavior occurs on Linux installations of Tcl 8.0
  - 8.4.1
  (at least).  I suspect the problem does not occur on
  Windows.

  I think the bindings for menus should not accept a
  ButtonRelease 
  for some short period after the menu is posted.  The
  short period
  is probably specified by the window manager settings as
  the
  button-click time.  

  As a work-around, I have been using:

  bind Menubutton <Button-1> {+
     bind [winfo children %W] <ButtonRelease-1> {break}
     after 300 { bind [winfo children %W]
  <ButtonRelease-1> {}}
  }

  to disable the ButtonRelease event in menus for the
  first 300ms
  after the MenuButton is clicked on.


tkt_uuid: 528464ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Cut/Paste broken on Mac OSX
comment:
  When using the native OSX port of tk, I find that I cannot paste data 
  from other applications. I suspect this may have something to do 
  with encodings as what I get pasted is gibberish.


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

  Reproducible script below

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


  -- reproducible script --

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


  -- end of message --


tkt_uuid: 2784099fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 8
foundin: obsolete: 8.5.7
resolution: None
title: Aqua menus callbacks should not be idle tasks
comment:
  Aqua Tk 8.5.7 invokes menu entry callbacks as idle tasks.  Tk convention requires that user mouse/key event callbacks occurs when the window event is processed, and not later as idle tasks.  This is the behavior on X11 and Windows.  It is necessary so that "update idletasks" is able to redraw windows without invoking mouse/key callbacks in unsafe application code paths (e.g. user deletes data set via a menu entry while "update idletasks" is refreshing a status message for a computation on that data set).  This window updating without user event processing is the only purpose I know of for "update idletasks" and is a critical one for real-time applications.

  It took 10 hours to debug a hang in a Tk-based molecular viewer, UCSF Chimera, caused by unexpected menu entry callbacks within "update idletasks".


tkt_uuid: 220710ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: nonempty canvases accept all configs
comment:
  OriginalBugID: 4456 Bug
  Version: 8.3
  SubmitDate: '2000-03-22'
  LastModified: '2000-03-28'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-03-28'
  FixedInVersion: 8.3.1


  Name:
  hume smith

  Comments:
  In one program I happened to rely on a canvas pitching a fit given bad
      configures...  BTW it seems like every time I turn around it's harder
      and harder to find the bug report form.

  ReproducibleScript:
  canvas .c
  puts [catch {.c config -garkinkler foo}]
  .c create line 0 0 20 20
  puts [catch {.c config -garkinkler foo}]

  ObservedBehavior:
  prints
  1
  0

  DesiredBehavior:
  prints
  1
  1



  (posted to comp.lang.tcl)

  It looks like this got picked up with the Dash patch in 8.3.0.  I tracked
  the problem to this piece of code in tkCanvas.c:

        case CANV_CONFIGURE: {
          if (argc == 2) {
              result = Tk_ConfigureInfo(interp, canvasPtr->tkwin,
                          configSpecs, (char *) canvasPtr, (char *) NULL,
                          0);
          } else if (argc == 3) {
              result = Tk_ConfigureInfo(interp, canvasPtr->tkwin,
                          configSpecs, (char *) canvasPtr,
                          Tcl_GetString(argv[2]), 0);
          } else {
              result = ConfigureCanvas(interp, canvasPtr, argc-2, argv+2,
                      TK_CONFIG_ARGV_ONLY);
              for (itemPtr = canvasPtr->firstItemPtr;
                  itemPtr != NULL; itemPtr = itemPtr->nextPtr) {
                  if (itemPtr->state != TK_STATE_NULL) {
                      continue;
                  }
                  EventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);
                  result = (*itemPtr->typePtr->configProc)(interp,
                          (Tk_Canvas) canvasPtr, itemPtr, 0, 
                          (Tcl_Obj **) NULL, TK_CONFIG_ARGV_ONLY);
                  EventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);
                  canvasPtr->flags |= REPICK_NEEDED;
              }
          }
          break;
        }

  This is the bit of CanvasWidgetCmd that is responsible for handling the
  "configure" subcommand.  As you can see, when there are items on the
  canvas, it configures those items in addition to configuring the canvas
  itself.  In the process, it crushes the original return code from
  configuring the canvas.  The for loop in the code above came along with
  the Dash patch.  I don't think it should be there at all -- configuring
  the canvas should not configure the items on the canvas.  Perhaps Jan
  Nitjmans can shed some light on what the purpose of this code is?

  - eric

  -- 03/22/2000 ericm

  From Jan:

  The purpose of this code is to handle the "-state" option of the
  canvas itself. Any canvas widget which doesn't have "-state"
  set explicitely takes over the state of its parent. Therefore,
  all those items must eventually be reconfigured in order to be
  redrawn when the state changes.

  Another possibility is that configuring the canvas has the
  side-effect that another item could get the focus, which
  might also change the appearance and even the size of this
  item. This could happen, for example, when the new option
  "-activewidth" is used. That's what the REPICK_NEEDED is
  for. This part of the code works together with other parts
  in tkCanvas.c, making the configuration process as fast as
  possible. The configProc proc is called with no arguments,
  so it only has very little work to do. Actually this
  proc should never return an error, but this cannot
  be guaranteed because it might come from a user-written
  canvas widget.

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

  After some discussion with Jeff Hobbs and Scott Stanton, we decided that this it is in fact incorrect for the canvas configure command to perform a configure on each item on the canvas.  While Jan's comments that it might be used for items that don't, for example, have their own state value, no current canvas items do this.  Thus this loop is causing a performance hit to support the possibility that some items might do this.  A better solution would be to add the ability for canvas items to register interest in canvas configuration events; when the canvas is reconfigured, it could then look at this list (which would usually be far shorter than the list of all canvas items) and perform a configuration on each item in that list.

  The important thing here is that I have removed the offending code, so this bug is fixed.  This fix will go out with 8.3.1.

  - eric

  -- 03/28/2000 ericm


tkt_uuid: 858822ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: Duplicate
title: win-tk test suite hangs in 'send'
comment:
  Ever since the partial tip150 implementation was
  checked in, 'nmake -f makefile.vc TCLDIR=...... test'
  leads to the test suite hanging with an extra toplevel
  'tktest #N' hanging around. Examining my processes,
  there are two tktest.exe processes running and if I
  kill the extra one, the tests then run to completion.

  Older versions of Tk run the test suite fine.


tkt_uuid: 1591500fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: tk cvs head HANG during test suite
comment:
  tk 8.5 cvs head build on sparc solaris 9 using sun c
  compiler and test suite display via exceed 10.0.0.12 on
  win xp.

  Note that this test sits until the test process is killed.

  window.test

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

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

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


tkt_uuid: 833627ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a0
resolution: Fixed
title: TIP 155 text widget crashes and panics.
comment:
  I ran the new TIP 155 text widget with tkchat and it
  raised a Tk panic with the message
   "LayoutDLine couldn't place any characters on a line"

  This is due to the presence of elided text in the
  widget. I am hiding the entry messages and if I have
  these to be shown then it doesn't panic.

  While trying to produce a minimal example I get a crash
  from the following tcl code. (This is Win2k Tcl and Tk
  HEAD).

    pack [text .t]
    .t insert 0.0 HELLO
    .t tag configure HIDE -elide 1
    .t tag add HIDE 0.0 end


tkt_uuid: 940760ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 8
foundin: obsolete: 8.5a4
resolution: Out of Date
title: TkAqua: menu rebuild bug
comment:
  This simple test case illustrates a bug in TkAqua's
  menu handling:

  menu .menu
  menu .menu.one

  proc rebuild {} {
      destroy .menu.one.two
      menu .menu.one.two
      for {set i 0} {$i < 10} {incr i} {
          .menu.one.two add command -label "item $i" \
           -command "puts $i"
      }
      .menu.one.two add command -label "rebuild" \
          -command rebuild
  }

  rebuild

  .menu.one add cascade -menu .menu.one.two -label "sub"
  .menu.one add command -label dummy
  .menu add cascade -menu .menu.one -label "test"
  . configure -menu .menu

  Paste the above code into TkAqua's console, click on
  the main window to
  have the 'test' menu appear in the main OS menubar and
  then go down to the
  submenu and select 'rebuild'.  This command will
  destroy the menu, but
  then rebuild it as is so everything should be the same.
   However, if you
  return to the menubar and try to post the submenu
  again, you'll find it
  won't post.  Now click over to the Finder, or some
  other application and
  then back to Wish, and you'll find the menu now works!

  Somehow the menu->submenu connection is forgotten when
  the menu is rebuilt, and is only set correctly again
  when we switch context from/to TkAqua.


tkt_uuid: 931231ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Tcl_DoOneEvent blocks when there is modal dialog
comment:
  Tcl_DoOneEvent blocks when there is modal dialog 
  I am using C application with Tcl/Tk front end GUI. I use 
  tcl84.lib and tk84.lib for Windows 2000 platform. I 
  periodically use following to update display and get user 
  input.
  while (Tcl_DoOneEvent(TCL_ALL_EVENTS | 
  TCL_DONT_WAIT)); 

  But this call blocks and never returns when I have modal 
  dialog open in GUI. So when user opens modal dialog, I 
  cannot update GUI display from program. When I used 
  TCL_DONT_WAIT flag, I assumed that this will return 
  immediately, if there is no event pending. But it does not 
  work that way. Can anybody explain why this is not 
  working and how to make it work?
  Thanks,
  Niraj
   


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


  Name:

  Peter Shawhan


  Extensions:

  none


  CustomShell:

  none


  Comments:

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

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

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

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

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

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

      tkTextSelectTo to guarantee that the letter clicked on stays part

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

      are found to determine the actual selection.


  ReproducibleScript:

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

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

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

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

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

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

  pack .text


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

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

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

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

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

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

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


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

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

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

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

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

  selected as well.


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

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

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

  selected, but the third line becomes deselected.


  ObservedBehavior:

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

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

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

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

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

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

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

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

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


  DesiredBehavior:

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

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

  in text.tcl, as described below.


  Patch:

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

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

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

  *** 54,66 ****

        set tkPriv(selectMode) word

        tkTextSelectTo %W %x %y

        catch {%W mark set insert sel.last}

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

    }

    bind Text <Triple-1> {

        set tkPriv(selectMode) line

        tkTextSelectTo %W %x %y

        catch {%W mark set insert sel.last}

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

    }

    bind Text <Shift-1> {

        tkTextResetAnchor %W @%x,%y

  --- 54,64 ----

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

  *** 515,520 ****

  --- 513,527 ----

        set tkPriv(pressX) $x

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

        $w mark set anchor insert

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

  +     ;##- relative to the gap

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

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

  +       set side right

  +     } else {

  +       set side left

  +     }

  +     $w mark gravity anchor $side

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

    }


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

  *** 552,581 ****

              }

          }

          word {

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

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

  !               if { !$extend } {

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

  !               } else {

  !                   set last anchor

  !               }

              } else {

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

  !               if { !$extend } {

  !                   set first [tkTextPrevPos $w anchor tcl_wordBreakBefore]

  !               } else {

  !                   set first anchor

  !               }

              }

          }

          line {

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

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

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

  !           } else {

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

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

              }

          }

        }

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

  --- 559,594 ----

              }

          }

          word {

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

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

  !               set lindex "anchor"

  !               set rindex "anchor + 1c"

              } else {

  !               set lindex "anchor - 1c"

  !               set rindex "anchor"

              }

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

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

  +               set lindex $cur

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

  +               set rindex $cur

  +           }

  +           ;##- Now find word boundaries

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

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

          }

          line {

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

  !           set lindex "anchor linestart"

  !           set rindex "anchor - 1c lineend"

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

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

  !               set lindex "$cur linestart"

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

  !               set rindex "$cur -1c lineend"

              }

  +           set first [$w index $lindex]

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

          }

        }

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


  PatchFiles:

  lib/tk8.4/text.tcl


tkt_uuid: 434538ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Works For Me
title: tkUnixDraw.c", line 97: error 1563: Expr
comment:
  During the make I get:
  tkUnixDraw.c", line 97: error 1563: Expression in if 
  must be scalar

  Line 97 is a submitted by problem # 220747.

  HPUX 11.00 gcc v2.8.1

  Any help would be very nice.


tkt_uuid: 693603ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 86. Test Tools
priority: 5 Medium
foundin: None
resolution: None
title: Tk test suite should hardwire options
comment:
  To prevent make test from failing due to unusual X (or
  Windows, or  other) resources, the test suite should
  expect all settings for colors, fonts, font sizes,
  window sizes, etc. to be read via the options command.


tkt_uuid: 458879ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: Real TIP #26 patch
comment:
  This patch on Tk 8.4a2 implements TIP #26. It has been 
  tested on Linux and Windows, but still needs Mac 
  testing.


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


  Name:
  Lothar Linhard

  Extensions:
  We provide a Tcl/Tk extension

  CustomShell:
  No, our Tcl/Tk extenstion must run

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

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


tkt_uuid: 220892ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: None
title: focus changes forgotten during grab
comment:
  OriginalBugID: 4167 Bug
  Version: 8.3b1
  SubmitDate: '2000-02-14'
  LastModified: '2000-02-25'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Unix
  OSVersion: SGI Irix 6.5


  Comments:
  Same bug with Tcl/Tk 8.3.0 and 8.0.5

  ReproducibleScript:
  #!/bin/env wish8.3

  #
  # Tk bug report, focus changes forgotten during grab
  #
  # Here is the scenario I have encountered on unix machines.
  #
  # My application brings up a small window which reports progress on a
  # typically short 5 second calculation and presents a cancel button.
  # The window does a pointer grab because the user cannot do other
  # operations while the calculation is being performed, ie it is a modal
  # dialog.  The user moves the pointer and the main application window
  # is given the focus by the window manager.  The progress report window
  # disappears because the calculation finishes.  Now the user tries typing
  # input to the main window (like a menu accelerator) and the application
  # does not receive it.
  # 
  # If you use the Tk focus command with no arguments at this point, Tk returns
  # an empty string.  Tk believes the application does not have the focus, even
  # though the window manager highlights its window frame showing that it does
  # have the focus.  The problem happens because the focus change that occured
  # while the progress report window had a grab was thrown away by Tk.  The
  # problem is particularly common when your window manager changes focus
  # whenever the pointer is moved into a new window (the default on SGI Unix
  # machines where I see the problem).
  # 
  # There is no way for the application to deal with the fact that Tk "forgets"
  # that the application has the focus during a grab.  This should be changed
  # so that Tk correctly changes the keyboard focus during a grab.  This is
  # the behaviour implied by the Tk grab documentation:  "During local grabs,
  # keyboard events (key presses and key releases) are delivered as usual...".
  # 
  # It looks to me that the fix needs to be in source file generic/tkGrab.c
  # but I do not have a patch.
  # 
  # Here is a wish8.3 script that demonstrates the problem.
  # 

  label .label -justify left -text {
    Click in this window to create a grabbing window.
    The grabbing window will go away after 5 seconds.
    If you switch focus to the main window during the
    grab by clicking on the main window frame, Tk will
    not remember that focus change.  It will report that
    there is no focus window, ie it thinks some other
    application has the focus.
  }
  pack .label

  label .report
  pack .report

  bind . <ButtonPress> {
      toplevel .t
      wm transient .t .
      update
      focus .t
      grab set .t
      label .t.label -justify left -text {
  This window has a grab set.
  In 5 seconds it will go away.
      }
      pack .t.label
      after 5000 {
  destroy .t
  after 1000 {
      .report configure -text  "Tk reports the focus window to be '[focus]'"
  }
      }
  }


tkt_uuid: 1010083fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 9 Immediate
foundin: None
resolution: Fixed
title: spelled docs for widgets: menu and text
comment:
  spelled docs for widgets: 'menu' and 'text'
  see attached file 'text_menu_n.patch'

  additional comments:

  text.n

  pay attention to the submodifier sentence in the 
  INDICES chapter of the file
  even if the variant in the patch is not accepted
  the sentence in any way requires a revision (Bold-tag, 
  non-existent? and thus confusing submodifier 'nothing', 
  etc.)

  The 'which ...' clause appears 45 times in the file
  Could it be in some cases simplified?
  Splitted onto separate sentences or something else
  ____________________________

  menu.n

  "Note that in Tcl 8.0 on Macintosh and Windows, all 
  commands ?in a menu systems? are executed before any 
  are posted."
  does that mean 'in systems of a menu', or 'in menu 
  systems', or 'in a menu system'

  does 'labelled' (three times in file menu.n) is acceptable 
  instead of 'labeled'
  is this some type of 'accent'


tkt_uuid: 551969ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 31. Cursor Names
priority: 4
foundin: None
resolution: None
title: VFS and mouse cursor specification files
comment:
  Tcl version: 8.3.4
  OS Platform: Windows 2000

  Problem behaviour:
  The issue concerns the configuration of the mouse
  cursor through a separate mouse cursor specification
  file, e.g.

      . configure -cursor @linkcursor.cur

  When a script is run as a scripted document and the
  mouse cursor specification file is contained within the
  scripted document, the configuration command command
  fails, returning the error message:

  bad cursor spec
  "@F:/whateverpath/mousetest.sdk/bin/linkcursor.cur"

  (Both a script from which you can construct a scripted
  document that reproduces the error, and a scripted doc
  are packed in the attached zip file.)

  The faulty behaviour has been noticed when running
  under windows, however, I question whether it is
  platform specific.


  Expected nehaviour:
  The mouse cursor specification file should be read from
  the VFS and the shape of the mouse cursor should change
  accordingly.


  Jean Claude Wippler has tracked the problem down to:

  quote jcw start

  PS.  Oops, wait - I think I found the problem, it's 
  Windows-specific. The "win/tkWinCursor.c" has a call
  "LoadCursorFromFile", and I can't find
  LoadCursorFromFile anywhere else, so it looks like this
  call has not yet been made VFS aware. 

  quote jcw end


  Sincerely,

  Erik Leunissen
  ==============


tkt_uuid: 220036ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Duplicate
title:
  create a scale widget using -cursor attribute, core dump with panic "Tk_FreeCursor called before Tk_GetCursor"

comment:
  OriginalBugID: 3374 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-12'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2725
  OS: HP-UX
  OSVersion: HPUX 10.20
  ClosedDate: '1999-11-12'


  Name:
  Hormoz Rebati

  CVS:
  8/October/1999 10 am

  Extensions:
  BLT

  CustomShell:
  Have not modified anything

  Comments:
  Please resolve this as soon as possible.

  ReproducibleScript:
  toplevel .popup
      scale .popup.scale -label "No Of Repetitions" -from 0 -to 10000  -length 6c -width .3c  -resolution 1  -font {Helvetica -12 bold} -orient horizontal -tickinterval
      2000  -cursor crosshair

              pack .popup.scale -padx 1 -side top -fill x
      ...
              destroy .popup

      panics and aborts

  ObservedBehavior:
  Tk_FreeCursor called before Tk_GetCursor
      ABORT instruction

  DesiredBehavior:
  Expected to destroy the popup widget just like how it was with TK8.0.4


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


tkt_uuid: 652088ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Out of Date
title: paned window option problem
comment:
  There apears to be a problem in the panedwindow code.
  Although the documentation indicates that the height
  and width of a pane can be controled with the -height
  and -width options to the paneconfigure command, this
  doesn't appear to be the case. The following two
  command (for example) produce the same results (a pane
  that is 150 high).

  ${pwin} paneconfigure ${frame} -minsize 150
  ${pwin} paneconfigure ${frame} -minsize 150 -height 250

  A more telling example is the following which produces
  a pane that has 0 height.

  ${pwin} paneconfigure ${frame} -height 250

  I have also tried to use the sash place command to
  ajust the possition of the sash (and thus the size of
  the window) but this does not seem to work eather.


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


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

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



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

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

  To reproduce do the following 

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

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

  Expected result:  

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

  Actual result: 

  I can't copy the stack trace. 

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


tkt_uuid: 1006686fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Fixed
title: wm resizable command not working on Solaris/CDE
comment:
  The fix for bug #915350 "Tk sets min, max size in WM_HINTS
  when it shouldn't", which was recently backported to Tk
  8.4.7, breaks the wm resizable command for the CDE window
  manager on Solaris 8.  Setting wm resizable 0 0 is now not
  properly handled by the window manager, because the max
  size hint is not set.  The window cannot be made smaller
  than the current requested size, but it can be dragged
  larger by the user.

  Obviously this is in the realm of different interpretations
  and behaviours among different window managers (and
  probably different versions of the same window manager). 
  But the attached simple patch fixes the problem in
  Solaris/CDE, and hopefully won't undo the fix for bug
  #915350.

  The patch is for for UpdateSizeHints in the current head
  version 1.43 of tkUnixWm.c


tkt_uuid: 853003ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: obsolete: 8.5a0
resolution: Fixed
title: Performance problems in text widget
comment:
  Try the following:

  text .t
  for {set i 0} {$i < 10} { incr i } {
      .t delete 0.0 end
      puts [time {.t insert end [string repeat x [expr
  {$i*10000}]] ; update }]
  }


  With Tk 8.4, the time for each iteration is well under
  1 second, and scales approximately linearly.  With the
  current HEAD, the first iteration takes three orders of
  magnitude longer, and the time seems to go up
  quadratically.

  Oddly, if the text widget is [pack]ed first it's
  considerably faster, but still much slower than in 8.4.

  See also bug #231251 (re: bgerror dialog).


tkt_uuid: 814792ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Out of Date
title: Wrapped checkbutton text is clipped
comment:
  If checkbutton text wraps onto 2 lines in Aqua Tk 8.4.4
  then it
  is clipped on the top and bottom because not enough
  vertical
  space is allocated.  The following example,

  wm geometry . 400x100
  checkbutton .b -text {Some long text that wraps onto
  two lines to show the vertical clipping problem}
  pack .b

  wraps the checkbutton text onto 2 lines.  The tops of
  the characters
  in the first line are not visible and the bottom of the
  characters on
  the second line are not visible.


tkt_uuid: 1090371fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 3 Low
foundin: obsolete: 8.5a2
resolution: None
title: man.macros created in source-tree
comment:
  If I build  tk from a separate build-directory (starting 
  ../../tk/unix/configure ...  from say build/tk), then
  the file  doc/man.macros  is created in the source
  tree rather than in the build-tree.

  Not a big problem, sure.


tkt_uuid: 790435ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 02. Appearance
priority: 7 High
foundin: None
resolution: Invalid
title: label redraw issues with images...
comment:
  It seems that labels with images in them (via the -image 
  option) have trouble redrawing (at least on Windows 
  2000) when there are more than a few on the screen.

  I spoke with dkf and he said that this was already 
  a "known issue".


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


  Tk 8.3.1 Bug

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

  ReproducibleScript:
  Here is a script that expresses the problem.  

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

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

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

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

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

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

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

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

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

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

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

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

  Posted To comp.lang.tcl: Posted Successfully


tkt_uuid: 861840ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: Unicode support in windows and dialog titles and messages
comment:
  When using Japanese string in window title, dialog title or 
  dialog message (for save and open), the string gets 
  transformed to "????" or garbage.

  I have submitted patches to TkMacOSXDialog and 
  TkMacOSXWm that seem to fix these problems. They are 
  patches 861837 and 861839.


tkt_uuid: 830674ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: None
title: umask 027 causes bad wish installation
comment:
  tk 8.3.4
   When umask 027 is set during "make" stage (doesn't have
  to be set during "make install" stage), the wish8.3
  executable has permissions rwxr-x--- which renders it
  unusable for normal user.


tkt_uuid: 219977ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 06. Canvas Postscript
priority: 1 Zero
foundin: None
resolution: Duplicate
title: Would like to generate postscript for all unicode character sets in canvas
comment:
  OriginalBugID: 1956 RFE
  Version: 8.1b3
  SubmitDate: '1999-04-28'
  LastModified: '2000-04-14'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2596
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '2000-04-14'


  Jim Stokely is developing an educational program that would run on multiple platforms (windows and mac) and he is interested in the unicode support in Tcl/Tk 8.1. He would like to enter non ISO8859-1 characters in a canvas and generate postscript file from it. Currently, we support only ISO8859-1 character sets.



  I asked on comp.lang.postscript once for references to Unicode
  charsets, and the responses seemed to indicate that we would have
  to create our own because there aren't any free ones (at the
  moment) for postscript printing. 
  -- 02/28/2000 hobbs


tkt_uuid: 220038ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Duplicate
title: Scale widget property -cursor hand2 is fatal
comment:
  OriginalBugID: 3403 Bug
  Version: 8.2
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-12'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2725
  OS: Windows 95
  ClosedDate: '1999-11-12'


  Name:
  Jurge van Eijck

  ReproducibleScript:
  proc ScaleNoCurWindow {} {
      if [ winfo exists .demonocur ] {
      switch -exact -- [wm state .demonocur] {
      normal {
      wm iconify .demonocur
      wm deiconify .demonocur
       }
      iconic -
      withdrawn { wm deiconify .demonocur }
      }
      } else {
      toplevel .demonocur
      frame .demonocur.scale
      wm title .demonocur "Demo Scale WITHOUT -cursor hand2"

      scale .demonocur.scale.scale1 -from 1 -to 25 -length 200 -orient horizontal -label "Scale"
      pack .demonocur.scale.scale1 -side top -fill both -expand true 
      pack .demonocur.scale -side top -fill x 
      }
      }

      proc ScaleCurWindow {} {
      if [ winfo exists .democur ] {
      switch -exact -- [wm state .democur] {
      normal {
      wm iconify .democur
      wm deiconify .democur
       }
      iconic -
      withdrawn { wm deiconify .democur }
      }
      } else {
      toplevel .democur
      frame .democur.scale
      wm title .democur "Demo Scale WITH -cursor hand2"

      scale .democur.scale.scale1 -from 1 -to 25 -length 200 -orient horizontal -label "Scale" -cursor hand2

      pack .democur.scale.scale1 -side top -fill both -expand true 
      pack .democur.scale -side top -fill x 
      }
      }

      ## MAIN WINDOW
      # window title
      wm title . "Demonstrating Scale -cursor hand2 problem"

      # Top fram with Quit button
      frame .toprow -borderwidth 5 
      button .toprow.quit -text Quit  -borderwidth 2 -padx 1 -pady 1  -command
      exit
      pack .toprow.quit

      # buttons for calling the submenu's
      frame .submenus -borderwidth 5
      button .submenus.scale_cur -text "Scale Cursor" -width 20 -borderwidth 2
      -padx 1 -pady 1  -command ScaleCurWindow
      button .submenus.scale_nocur -text "Scale No Cursor" -width 20
      -borderwidth 2  -padx 1 -pady 1  -command ScaleNoCurWindow
      pack .submenus.scale_cur .submenus.scale_nocur -side top -pady 4

      # assemble the frame's
      pack .toprow 
      pack .submenus -side left

  ObservedBehavior:
  The script is giving a window with two buttons.
      Each button is opening a window with a scale widget on it.
      Only in one window the scale has the property cursor set to hand2.
      When closing this window a fatal error occurs and tcl/tk 8.2 crashes.
      This happens under Win95 and Solaris.

  DesiredBehavior:
  Window should be closed without any crash.


tkt_uuid: 1202951fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Invalid
title: Problem compiling tk 8.5a2
comment:
  # make
  gcc -pipe -c -O2 -s -O3 -march=i686 -Wall
  -Wno-implicit-int -fno-strict-aliasing -fPIC
  -I/tmp/tk8.5a2/unix -I/tmp/tk8.5a2/unix/../generic
  -I/tmp/tk8.5a2/unix/../bitmaps -I/tmp/tcl8.5a2/generic
  -I/tmp/tcl8.5a2/unix -I/usr/X11R6/include
  -DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\"
  -DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tk\ 8.5\"
  -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1
  -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
  -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
  -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
  -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
  -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1
  -DUSE_THREAD_STORAGE=1 -D_REENTRANT=1 -D_THREAD_SAFE=1
  -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1
  -DHAVE_PTHREAD_GETATTR_NP=1 -DGETATTRNP_NOT_DECLARED=1
  -DHAVE_READDIR_R=1 -DPEEK_XCLOSEIM=1
  -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1
  -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
  -DHAVE_STRUCT_STAT64=1 -DHAVE_TYPE_OFF64_T=1
  -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1
  -DHAVE_PW_GECOS=1 -DHAVE_XFT=1      -DTCL_NO_DEPRECATED
  -DUSE_TCL_STUBS  /tmp/tk8.5a2/unix/../generic/tk3d.c
  In file included from
  /tmp/tk8.5a2/unix/../generic/tkPort.h:32,
                   from
  /tmp/tk8.5a2/unix/../generic/tkInt.h:27,
                   from
  /tmp/tk8.5a2/unix/../generic/tk3d.h:18,
                   from
  /tmp/tk8.5a2/unix/../generic/tk3d.c:16:
  /tmp/tk8.5a2/unix/tkUnixPort.h:224:20: tclInt.h: No
  such file or directory
  make: *** [tk3d.o] Error 1


tkt_uuid: 1676677fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: new test failures
comment:
  On Solaris 9 /CDE, these
  test failures are new since
  8.5a5. Failures happen
  in both --enable- and --disable-xft
  configurations:

  ==== scrollbar-3.36 ScrollbarWidgetCmd procedure, "fraction" option FAILED
  ==== Contents of test case:

      .s fraction 4 179

  ---- Result was:
  0.760766
  ---- Result should have been (exact matching):
  1
  ==== scrollbar-3.36 FAILED



  ==== scrollbar-3.38 ScrollbarWidgetCmd procedure, "fraction" option FAILED
  ==== Contents of test case:

      .s fraction 4 178

  ---- Result was:
  0.755981
  ---- Result should have been (exact matching):
  0.993711
  ==== scrollbar-3.38 FAILED



  ==== scrollbar-3.52 ScrollbarWidgetCmd procedure, "identify" option FAILED
  ==== Contents of test case:

      .s set .3 .6
      .s identify 5 80

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



  ==== scrollbar-3.53 ScrollbarWidgetCmd procedure, "identify" option FAILED
  ==== Contents of test case:

      .s identify 5 145

  ---- Result was:
  slider
  ---- Result should have been (exact matching):
  trough2
  ==== scrollbar-3.53 FAILED


  ==== scrollbar-3.54 ScrollbarWidgetCmd procedure, "identify" option FAILED
  ==== Contents of test case:

      .s identify 5 195

  ---- Result was:
  trough2
  ---- Result should have been (exact matching):
  arrow2
  ==== scrollbar-3.54 FAILED



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

      .s identify 8 196

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

  ==== scrollbar-6.3 FAILED



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

      .s identify 8 52

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



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

      .s identify 8 84

  ---- Result was:
  slider
  ---- Result should have been (exact matching):
  trough2
  ==== scrollbar-6.24 FAILED


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

      .s identify 8 180

  ---- Result was:
  trough2
  ---- Result should have been (exact matching):
  arrow2
  ==== scrollbar-6.29 FAILED



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

      .s identify 8 195

  ---- Result was:
  trough2
  ---- Result should have been (exact matching):
  arrow2
  ==== scrollbar-6.30 FAILED



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

      .s identify 4 100

  ---- Result was:
  slider
  ---- Result should have been (exact matching):
  trough2
  ==== scrollbar-6.34 FAILED



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

      .s identify 18 100

  ---- Result was:
  slider
  ---- Result should have been (exact matching):
  trough2
  ==== scrollbar-6.35 FAILED


tkt_uuid: 220902ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: final: 8.2.3
resolution: None
title: Canvas widget loses track of mouse
comment:
  OriginalBugID: 4408 Bug
  Version: 8.2.3
  SubmitDate: '2000-03-20'
  LastModified: '2000-03-30'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat


  Name:

  Mark Smith


  ReproducibleScript:

  Have a look at the following code in CanvasBindProc() in generic/tkCanvas.c:


          } else {

              /*

               * Button release: first process the event, with the button

               * still considered to be down.  Then repick the current

               * item under the assumption that the button is no longer down.

               */


              canvasPtr->state = eventPtr->xbutton.state;

              CanvasDoEvent(canvasPtr, eventPtr);

              eventPtr->xbutton.state ^= mask;

              canvasPtr->state = eventPtr->xbutton.state;

              PickCurrentItem(canvasPtr, eventPtr);

              eventPtr->xbutton.state ^= mask;

          }


  The problem is that CanvasDoEvent might not return until the mouse has been moved

  by the user.  This can happen, for example, if the programmer creates a canvas item that

  simulates a button with a popup dialog to fire upon ButtonRelease.  When the popup dialog

  is done, the user has moved the mouse far from where the original ButtonRelease event says

  that it is.  This can cause undesirable effects, such as the display of a ToolTip on the wrong

  canvas item.


  DesiredBehavior:

  The position of the mouse should be checked again after the CanvasDoEvent() is done.

  You can't assume it's still valid.


tkt_uuid: 2947339fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: ttk::combobox : enhance dropdown list
comment:
  Subject : Make the width of the dropdown list of ttk::combobox configurable (and/or add the possibility to have a 2 columns dropdown list)

  When the user has to select an item in a popdown list of a combobox, it is sometime desirable to show beside each entry in the list a short text giving explanation about the choice to be selected. This is particularly usefull in database applications when the choices to be made are keys/abreviations not easy to remember for the user.
  In that case, it would be nice if the width of the popdown list could be configurable and not be depedant of the width of the text field of the combobox.

  Thanks a lot

  Jean-Marie


tkt_uuid: 220091ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Duplicate
title: TK 8.3.1 doesn't compile clean on AIX 4.3.2
comment:
  OriginalBugID: 5975 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-06'
  LastModified: '2000-09-05'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 6206
  OS: AIX
  FixedDate: '2000-09-05'


  Name:
  Joachim Zaers

  ReproducibleScript:
  using gcc-2.95-2, aix 4.3.2. BTW: Thanks for fixing AIX for tcl. There it worked fine.
  Looks like the changes in compile flags for gcc didn't make their way up from tcl to tk?

          rm -f libtk8.3.so
          /usr/local/LTA-DEV/src/tcl8.3.1/unix/ldAix /bin/ld -bhalt:4 -bM:SRE -bE:
  lib.exp -H512 -T512 -bnoentry -o libtk8.3.so tk3d.o tkArgv.o tkAtom.o tkBind.o t
  kBitmap.o tkClipboard.o tkCmds.o  tkColor.o tkConfig.o tkConsole.o tkCursor.o tk
  Error.o tkEvent.o  tkFocus.o tkFont.o tkGet.o tkGC.o tkGeometry.o tkGrab.o tkGri
  d.o  tkMain.o tkObj.o tkOldConfig.o tkOption.o tkPack.o tkPlace.o  tkSelect.o tk
  Util.o tkVisual.o tkWindow.o   tkUnix.o tkUnix3d.o tkUnixButton.o tkUnixColor.o
  tkUnixConfig.o  tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o  tkUnixF
  ocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o  tkUnixMenubu.o tkUnix
  Scale.o tkUnixScrlbr.o tkUnixSelect.o  tkUnixSend.o tkUnixWm.o tkUnixXId.o tkStu
  bInit.o tkStubLib.o tkButton.o tkEntry.o tkFrame.o tkListbox.o  tkMenu.o tkMenub
  utton.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  tk
  CanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o tkImgGIF.o t
  kImgPPM.o tkImgPhoto.o tkText.o tkTextBTree.o tkTextDisp.o tkTextImage.o tkTextI
  ndex.o  tkTextMark.o tkTextTag.o tkTextWind.o -L/usr/local/lib -L/usr/local/LTA-
  DEV/src/tcl8.3.1/unix  -lX11 -ldl -Wl,-bI:/usr/local/LTA-DEV/src/tcl8.3.1/unix/l
  ib.exp -L/usr/local/LTA-DEV/src/tcl8.3.1/unix -lm -lc
  noDotA="libtk8.3.so"
  ld: 0706-012 The -W flag is not recognized.
  ld: 0706-006 Cannot find or open library file: -l ,-bI:/usr/local/LTA-DEV/src/tc
  l8.3.1/unix/lib.exp
          ld:open(): A file or directory in the path name does not exist.
  make: 1254-004 The error code from the last command is 255.


tkt_uuid: 3019624fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 51. [place]
priority: 6
foundin: None
resolution: Fixed
title: Fix crash on calling place in a half-dead application
comment:
  The following code segfaults on last tk CVS head (8.5 seems ok):

  package require Tk
  bind . <Destroy> {puts [place slaves .]}
  destroy .

  Problem: Tk_PlaceObjCmd uses Tk_MainWindow(interp) to get a window needed for TkGetWindowFromObj. Main window of an interp is removed from main window list _before_ <Destroy> bindings are evaluated. Tk_MainWindow(interp) starts to return NULL, [place] doesn't check for it, and a bad thing happens.

  Solution: other geometry managers, [grid]/[pack] at least, install an interp main window pointer as a command's client data (see tkWindow.c). During the time this report is about, main window is half-dead and removed from main window list, but not deallocated, and [grid]/[pack] have no problem accessing it. Changing tkPlace.c along these lines is trivial, as the [place] clientData is unused by now.

  P.S. among other commands not taking main window as their ClientData, [wm] looks suspicious (it's formally a geometry manager, at least). I'll look deeper into it when I have more time.


tkt_uuid: 220183ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: I try to make a link on a menu
comment:
  OriginalBugID: 1942 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-27'
  LastModified: '1999-10-22'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-10-22'


  Name:
  JOYEUX Jean-François

  Extensions:
  none

  Comments:
  Perhaps my script is wrong..

  ReproducibleScript:
  menu .menubar
      . config -menu .menubar
      foreach m {Menu1 Menu2} {
         set .menubar.m$m [menu .menubar.m$m -tearoff 0 -background grey
      -foreground black]
         .menubar add cascade -label $m -menu .menubar.m$m
      }
      
      bind .menubar <ButtonPress> { puts stdout "Press" }

  ObservedBehavior:
  No behavior

  DesiredBehavior:
  I expect to see a bind on a menu



  Because the new menu system relies on native widgets, you are
  more restricted in you binding access to them.  The user
  probably wants to bind to the <<MenuSelect>> virtual event,
  created for this purpose. 
  -- 10/22/1999 hobbs


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


tkt_uuid: 220191ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 49. [grid]
priority: 1 Zero
foundin: None
resolution: Invalid
title: small gridder syntax enhancement
comment:
  OriginalBugID: 2049 RFE
  Version: 8.0p2
  SubmitDate: '1999-05-12'
  LastModified: '2000-01-05'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  OS: Other
  OSVersion: NetBSD-1.3.3/i386
  Machine: NA
  ClosedDate: '2000-01-05'


  Name:
  Hume Smith

  DesiredBehavior:
  it would be nice if columnconfigure and rowconfigure could each take
      several row/column indices...
      eg.  grid columnconfigure .buttongroup 0 1 2 3 -weight 1
      just as we can apply something to several slaves with
      grid configure .bg.open .bg.close .bg.delete -sticky ew
      then the gridder would be slightly more code-competitive with the packer
      - see
      http://www.glnx.com/~hclsmith/tcltk/pack-grid/ for examples.



  The grid command supports the use of a list of indices:

  grid columnconfigure .buttongroup {0 1 2 3} -weight 1

  This was true in 8.0p2 and is still true now in 8.3.

  - eric
  ericm@scriptics.com

   
  -- 01/05/2000 ericm


tkt_uuid: 661792ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: TkCreateFrame didn't get application name
comment:
  When a window is created (or tried to be "place"d) when wish  
  exists (activated by a <Destroy> binding), wish aborts,  
  instead of returning some kind of error... 
   
  There is a small script (WishAbort.tcl) that reproduces 
  the error...  


tkt_uuid: 835173ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: TkAqua: tk_getSaveFile disallows '.' filenames
comment:
  'tk_getSaveFile' keeps the save button dimmed if you
  try to enter any name, like '.cshrc' which starts with
  a '.'.


tkt_uuid: 2995325fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Out of Date
title: ttk::sizegrip does not take [wm resizable . h v]into account
comment:
  The ttk::sizegrip widget does not take the prior [wm resizable . h v]  calls into account for the toplevel it is intalled in.


tkt_uuid: 678281ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Works For Me
title: Double-Button-1 not detected
comment:
  I discovered a situation where Double-Button events are
  not detected.
  Basically, if the widget hierachy is sufficiently deep
  enough, physical events get lost before a Double,
  Triple, etc., events can be detected.

  Making the event ring larger solves the problem, but I
  think this just postpones the issue and might have the
  side effect of slowing down event processing on slower
  machines.

  The problem can be demonstrated with the attached code.
   Double clicking on the window should produce a
  Button-1, ButtonRelease-1, and Double-Button-1 message,
  which it does as long as the hierarchy depth is small
  (~12).

  Before you argue that this kind of widget depth is
  ludicrous, it's quite possible when using something
  like incrTk, building up megawidgets from other
  megawidgets.

  -Brian


tkt_uuid: 555396ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: None
resolution: Duplicate
title: 8 bit character support broken
comment:
  Some time in the recent weeks, something changed in the
  CVS code that has severely broken 8 but character
  display. The symptoms I see occur using the text widget
  and Hipp's HTML widget. These are the symptoms:

  - When typing in the text widget, deadkey suuport no
  longer works. So when I press ^e, I get "^e" instead of
  ê. This works in 8.3

  - An accented character at the end of the word makes
  the whole word invisible. So some thing like

  La vérité naît de la bouche des enfants

  is displayed like this

  La        naît de la bouche des enfants.

  - If the accented character is at the end of the line,
  the whole line isn't displayed

  - I see the same thing with the HTML widget. Similarly,
  using the widget with 8.3 doesn't show these symptoms
  so I surmise that the problem is with Tk.


tkt_uuid: 568253ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Accepted
title: Patch to cleanup wm transient use in Tk
comment:
  This patch copies the wm transient checks that
  appear in some of the Tk dialogs into the others.
  There is a small functional change, if the parent
  window is withdrawn, then no transient master
  is set. All the tk dialogs should behave the same
  way after this patch is applied.


tkt_uuid: 1005902fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 5 Medium
foundin: None
resolution: Invalid
title: grid: Cant set the focus anymore, cant type text
comment:
  I use the grid command to switch between frames:

  grid remove .currentframe
  grid .frametodisplay -column 1 -row 2

  Those are container frames containing toplevel windows
  (frames created with -container 1 containing windows
  created with toplevel -use)

  When I keep switching between tabs, I notice I can't
  set the focus anymore on any widget (or use keyboard
  bindings), or set the keyboard input focus on entry and
  text widgets. 

  (although I can still click on button style widgets or
  select text)

  Where is gone the focus ?

  There's a few ways to get it back depending on the
  Window Manager
  eg: clicking another window before, or clicking the
  title bar, display a popup menu - enter and leave it -
  release the mouse...

  maybe the bug is in my code (bugshit happends) ... or
  maybe i'm doing something i should'nt try with Tk ?..

  look at the attached code sample:

  tar -zxvf bug.tar.gz
  cd bug
  wish main.tcl


tkt_uuid: 1803839fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5b1
resolution: Invalid
title: original widget namespace??
comment:
  % namespace origin button
  ::button
  % namespace origin tk::button
  ::tk::button

  I would have expect one of these
  commands to be a [namespace import]
  of the other.  What am I missing?


tkt_uuid: 694271ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Accepted
title: TK_DLL_FILE for tkConfig.sh
comment:
  Just like tclConfig.sh.in defines a TCL_DLL_FILE
  environment variable, tkConfig.sh.in should define a
  TK_DLL_FILE environment variable, so install scripts of
  dependant programs know which files to copy to build a
  complete distribution.


tkt_uuid: 2553155fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 8
foundin: obsolete: 8.6b1
resolution: Wont Fix
title: Dead space in torn-off menus
comment:
  In MS-Windows, torn-off menu windows can be wider than the original menu, apparently due to an absolute minimum toplevel width.  When this happens, the extra space at the right of the menu does not respond to mouse movement or clicking.  Yet it lights up when the mouse is moved over the left-hand portion of the menu, giving very counter-intuitive look-and-feel.

  I noticed this while playing with spinbox menubutton (http://wiki.tcl.tk/9648).  Tear off either of the menus and try to use them.  I'm sure you'll see what I mean.


tkt_uuid: 1591501fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: Duplicate
title: Ttk test suite failure in tk cvs head
comment:
  tk 8.5 cvs head built solaris 9 sun c compiler and test
  suite display via exceed 10.0.0.12 on win xp.

  ttk.test

  ==== ttk-6.9 Bad font spec in styles FAILED
  ==== Contents of test case:

      pack [ttk::label .l -text Hi!]
      event generate .l <Expose>
      update
      destroy .l
      set ::bgerror

  ---- Result was:
  unknown color name "badColor"
  ---- Result should have been (exact matching):
  unknown font style "Bogus"
  ==== ttk-6.9 FAILED


tkt_uuid: 220386ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Null color means transparent for all objects except text.
comment:
  OriginalBugID: 738 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-15'
  LastModified: '1998-10-15'
  Severity: LOW
  Status: Released
  Submitter: welch
  ChangedBy: rjohnson
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-10-15'
  FixedInVersion: 8.0.4


  Jan Nijtmans says:

  The following bug has been submitted to me for inclusion
  in the dash-patch in May 1998. I fulfilled this request.
  In my opinion it is important enough to bring it to the
  attention of Scriptics again, hoping it will be put into
  Tk8.0.4. The attached "tkCanvText.txt" contains a
  newly generated diff in respect to Tk8.0.3.

  The effect of this bug can be seen by this code:
       canvas .c
       pack .c
       .c create text 100 100 -text abc
       .c itemconfig 1 -fill {}
  Although the canvas man-page doesn't specify what
  happens if the fill option is given an empty
  string, the most logical thing to do (compared with
  all other canvas widgets) is to make the text invisible.
  Currently the text will be black.

  In the functions ConfigureText(), DeleteText() and
  TextToPostscript(), explicit tests are done if
  the fill option (the variable "color") holds a NULL
  pointer. Currently that is impossible, because the
  lack of the TK_CONFIG_NULL_OK flag already forbids
  this. It looks as if this behavior is unintentional,
  otherwise there would be no need to perform such check.
  This was enough evidence for me to consider the
  current behavior a bug.

  Strictly speaking, this patch introduces a
  "Potention incompatibility". However, because the
  initial value of the "-color" option is "black"
  and setting it to "" has no effect now, it just
  makes no sense for any application to set this
  option to the empty string. I don't know any
  application that does this, except applications
  that expect the text to become invisible (as the
  referenced discussion in comp.lang.tcl suggests).
  After including it in the dash-patch, I never received
  any complaint about this "potential incompatability".
  Therefore I see no danger putting it into the core.


  This is a one-bit patch.



  diff -rc tk8.0p1.orig/doc/canvas.n tk8.0p1/doc/canvas.n

  *** tk8.0p1.orig/doc/canvas.n   Fri Oct 31 20:58:54 1997

  --- tk8.0p1/doc/canvas.n        Fri Nov 14 14:45:16 1997

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

  *** 1446,1451 ****

  --- 1446,1453 ----

    \fB\-fill \fIcolor\fR

    \fIColor\fR specifies a color to use for filling the text characters;

    it may have any of the forms accepted by \fBTk_GetColor\fR.

  + If \fIcolor\fR is an empty string then the text will be

  + transparent.

    If this option isn't specified then it defaults to \fBblack\fR.

    .TP

    \fB\-font \fIfontName\fR

  diff -rc tk8.0p1.orig/generic/tkCanvText.c tk8.0p1/generic/tkCanvText.c

  *** tk8.0p1.orig/generic/tkCanvText.c   Sat Oct 11 01:04:57 1997

  --- tk8.0p1/generic/tkCanvText.c        Thu Nov 13 13:47:55 1997

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

  *** 86,92 ****

          "center", Tk_Offset(TextItem, anchor),

          TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_COLOR, "-fill", (char *) NULL, (char *) NULL,

  !       "black", Tk_Offset(TextItem, color), 0},

        {TK_CONFIG_FONT, "-font", (char *) NULL, (char *) NULL,

          DEF_CANVTEXT_FONT, Tk_Offset(TextItem, tkfont), 0},

        {TK_CONFIG_JUSTIFY, "-justify", (char *) NULL, (char *) NULL,

  --- 86,92 ----

          "center", Tk_Offset(TextItem, anchor),

          TK_CONFIG_DONT_SET_DEFAULT},

        {TK_CONFIG_COLOR, "-fill", (char *) NULL, (char *) NULL,

  !       "black", Tk_Offset(TextItem, color), TK_CONFIG_NULL_OK},

        {TK_CONFIG_FONT, "-font", (char *) NULL, (char *) NULL,

          DEF_CANVTEXT_FONT, Tk_Offset(TextItem, tkfont), 0},

        {TK_CONFIG_JUSTIFY, "-justify", (char *) NULL, (char *) NULL,

  --


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


  Name:
  Thomas Wu

  CustomShell:
  None

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

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

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

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



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

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

  Thanks,
   
  -- 08/09/2000 angie

  Sounds like the user solved his own problem.

  - eric
   
  -- 08/09/2000 ericm


tkt_uuid: 1904322fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Fixed
title: multiple selection problem
comment:
  tk_getOpenFile -multiple 1 on Tk8.5.1 fails to select multiple files; it seems as if they were concatenated into one filename which doesn`t exist.


tkt_uuid: 220792ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.0.4
resolution: None
title: tk_popup does not work (Mac only?)
comment:
  OriginalBugID: 1443 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-04'
  LastModified: '2000-02-10'
  Severity: SER
  Status: Assigned
  Submitter: pat
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: 7.5.1
  Machine: Power PC


  Name: Lindsay Marshall

  ReproducibleScript:
  menu .foobar
  .foobar add command -label xxxxx
  tk_popup .foobar 10 10

  ObservedBehavior:
  Menu does not appear unless you do

  raise .foobar

  immediately after call to tk_popup.

  Also the menu does not popup in the correct place - there seems to be something wrong with the way that %X %Y are handled by bindings.

  DesiredBehavior:
  Menu pops up under the mouse.



  This works as expect on NT and Unix for 8.2.0.  This may be a
  Mac only problem, or was fixed in the interim. 
  -- 08/15/1999 hobbs


tkt_uuid: 1686012fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Fixed
title: expanded doc needed for -font
comment:
  currently, the docs for the various tk widgets say:
  > STANDARD OPTIONS
  >      -activebackground     -borderwidth         -foreground
  >      -activeborderwidth    -cursor              -relief
  >      -activeforeground     -disabledforeground  -takefocus
  >      -background           -font

  >      See the options manual entry for details on the standard options.

  When you go to the options manual entry, you get:

    Command-Line Name: -font
    Database Name: font
    Database Class: Font
    Specifies the font to use when drawing text inside the widget. The
  value may have any of the forms accepted by
    Tk_GetFont. 


  When you go to Tk_GetFont, the details are too oriented towards the internals of the source to be helpful to someone who just wants to use the -font argument on a widget.

  Somewhere in the man pages, there should be information for someone learning to use Tk, so they know what kinds of arguments one can provide to -font . 

  Hopefully, at some point, there will also be a section in a tutorial included with Tk that talks about the "database name/database class" concept and how a programmer would make use of that.


tkt_uuid: 2229999fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 7 High
foundin: obsolete: 8.6a4
resolution: Fixed
title: Tk doesn't compile on HP-UX any more
comment:
  When compiling Tk on HP-UX, it doesn't compile any more.

  The reason is that 3 files now contain the "inline"
  'keyword', which is not available in the HP-UX
  compiler. The offending files are:

  unix/tkUnixEmbed.c
  generic/tkBusy.c
  generic/tkCanvas.c

  removing the 'inline' keywords, or compiling with
  -Dinline= fixes this.

  Regards,
         Jan Nijtmans


tkt_uuid: 3164879fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: error dialog during test suite
comment:
  During a `make test` on the Tk HEAD,
  while "select.test" is running, an error reporting
  dialog box pops up.  Requesting the stack
  trace produces:

  wrong # args: should be "errIncrHandler type offset count"
  wrong # args: should be "errIncrHandler type offset count"
      while executing
  "errIncrHandler STRI>on 0 4000"
      (command handling selection)


tkt_uuid: 901880ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Invalid
title: "Motion" binding fails during startup
comment:
  This  code is called (within panedwindow.tcl) due to a
  binding of a panedwindow widget as my application is
  starting up (but prior to any user input):

  proc ::tk::panedwindow::Motion {w x y} {
  set id [$w identify $x $y]
  ....

  The trouble appears to be that while the application is
  starting up (widgets are being created), there is a
  race (within the various widgets, as I don't see how I
  can influence this...) between when this binding is
  assigned and when various resources are actually
  created (to the point that they support an "identify"
  call).

  I randomly get this error:
  Error: bad option "identify": should be one of...
  ....

  It happens 1 out of of 3 times I start up the
  application - the other 2 of 3 times everything works...

  It never occurs again after the application is running,
  presumably because now the resources is fully
  initialized and responds as expected to an "identify"
  request.

  The flow of my application is:

  1. create toplevel
  2. create panedwdiget
  3. create child(ren) of panedwidget within "childsite(s)"
  4. place, place, place
  5. enter event loop

  I have had no luck creating a smaller application to
  demonstrate this as it appears that the shear size of
  my application is what increases the likelyhood that
  this race will occur.  This root cause (failure to
  answer the "identify" request) might be a bigger
  problem, but it seems that this library code
  could/should trap this case as a matter of  cleanliness
  (other calls in this file do similar things that
  ideally would have similar traps).

  As an additionaly note, running with a slower link to
  the Xserver (i.e remote display over wireless ethernet)
  reduces the occurance of this error to near zero -
  further demonstrating that this is a race of some sort...

  System info:
  Using VTCL as an IDE, but hand editing code after
  inital widget creation/placement
  RH 7/8/9 (same result on all)
  Window managers (same result on all): 
  a. KDE
  b. remote display to NT + Xwin32 client
  c. gnome 

  Using Tcl/tk ("wish") with itcl/itk/BLT/iwidgets all
  latest stable versions as of ~2/12/2004

  The easy solution seems simple and harmless enough and
  perhaps should be applied to most of the bound
  functions in this file (panedwindow.tcl):
  --- panedwindow.tcl     Fri Feb 20 17:08:23 2004
  +++ panedwindow.tcl~    Mon Feb  9 13:14:48 2004
  @@ -108,12 +108,7 @@
   #
   proc ::tk::panedwindow::Motion {w x y} {
       variable ::tk::Priv
  -    # this resource may not yet be fully initialized,
  if so return without
  -    # doing anything...
  -    if {[catch {set id [$w identify $x $y]}]} {
  -       return
  -    }
  -
  +    set id [$w identify $x $y]
       if {([llength $id] == 2) && \
              (!$::tk_strictMotif || [string equal
  [lindex $id 1] "handle"])} {
          if { ![info exists Priv($w,panecursor)] } {


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

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


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

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

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


tkt_uuid: 220643ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: Cannot regenerate configure from configure.in
comment:
  OriginalBugID: 3938 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-27'
  LastModified: '2000-01-03'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: BSD
  OSVersion: NetBSD 1.4P
  FixedDate: '2000-01-03'
  FixedInVersion: 8.3b2


  Name:
  Andreas Gustafsson

  Comments:
  It looks like there is an aclocal.m4 file missing from tk8.2.3 distribution.
  Because of this, you can't generate a working configure script from
  the configure.in template by running autoconf.  This makes it kind of 
  hard to fix bugs in configure.in, and even harder to fix bugs in 
  the nonexistent aclocal.m4. :-(

  ReproducibleScript:
  cd tk8.2.3/unix
  autoconf
  ./configure

  ObservedBehavior:
  creating cache ./config.cache
  checking for ranlib... ranlib
  SC_ENABLE_GCC: not found
  [followed by other error messages]

  DesiredBehavior:
  Successful configuration



  This has been fixed for 8.3b2. 
  -- 01/03/2000 hobbs


tkt_uuid: 220733ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 59. [tk_focus*]
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: Bug in library file focus.tcl
comment:
  OriginalBugID: 5372 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-05'
  LastModified: '2000-05-09'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 6209
  OS: Linux-SuSE
  FixedDate: '2000-05-09'
  FixedInVersion: 8.4a1


  Name:
  Csaba Nemethi

  Comments:
  In Tk 8.3.1, line 139 of the library file focus.tcl was changed from
      
          set value [uplevel #0 $value $w]
      
      into
      
          set value [uplevel #0 [list $value $w]]
      
      This is BAD because it restricts the "value" passed to uplevel to be a
      single
      word.  In the above example, it caused the correct statement
      
          set value [uplevel #0 p 1 .e2]
      
      to be replaced with
      
          set value [uplevel #0 {{p 1} .e2}]
      
      which, obviously, cannot work.
      
      The change in the file focus.tcl was made in the intention to support
      widget
      names containing spaces and other special characters, as suggested in
      Bug
      Report #4208.  This bug report requested to change line 139 of the file
      into
      
          set value [uplevel #0 $value [list $w]]
      
      which is quite different from what is contained in version 8.3.1.  That
      is, the
      patch was applied incorrectly!
      
      Maybe the above example is somewhat artificial, but there are quite
      normal
      cases where the value of the -takefocus option has more than one word.
      For
      example, the keyboard traversal in my Mentry package doesn't work any
      longer
      under Tk 8.3.1.  Fortunately, I have found a workaround, which will be
      contained in the next version (which I am going to release in the next
      few
      days).  I am not sure, however, whether or not any other packages or
      applications are similarly affected by this improperly performed bug
      fix, which
      has produced another bug.

  ReproducibleScript:
  Consider the following simple script, which worked in all Tk releases prior to
  8.3.1:

      proc p {arg w} {
          return $arg
      }

      entry .e1
      entry .e2 -takefocus {p 1}
      pack .e1 .e2

  ObservedBehavior:
  When traversing to the second entry with Tab, the following error
  message is displayed:

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

  DesiredBehavior:
  The script should not raise any error.



  The list is still needed around the $w, but shouldn't have been
  placed around the $value.  Fixed for 8.4a1. 
  -- 05/09/2000 hobbs


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

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

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

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


tkt_uuid: 544197ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: None
resolution: Later
title: Add NeXT-style scrollbars to Unix
comment:
  This patch adds a "-nextstyle" boolean attribute to the
  Unix scrollbar implementation.  NeXT-style scrollbars
  collect both arrow buttons at one end of the scrollbar.
   Both vertical and horizontal scrollbars are supported.

  In the patch, NeXT style scrollbars are enabled by
  default, search for "FIXME" to find this line.


tkt_uuid: 1578519fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 8
foundin: obsolete: 8.5b2
resolution: Invalid
title: tk_getOpenFile -multiple 1 fails the first times
comment:
  tk_getOpenFile -multiple 1  fails the first times 
  (WinXP)

  The above instruction correctly opens the (native) 
  WinXP dialog, and allows the user to select more than 
  one file as expected.

  A problem happens however when the user, before 
  selecting his files, clicks on the "Desktop" shortcut 
  icon located in the left pane of the dialog. In such 
  a case, on clicking on the Open button from the 
  dialog, a popup window shows up saying that the file 
  cannot be found and that the user should check the 
  filename.

  Further observations:

  a. Navigating by hand to the same location as the 
  shortcut points to (usually C:\Documents and 
  Settings\<USER>\Desktop) does not produce the same 
  problem.

  b. It does not happen when the -multiple 1 option is 
  not set.

  This happens again and again until tk_getOpenFile 
  returns at least one filename. To repeat the bug, 
  you'll have to start a new wish session.

  Francois


tkt_uuid: 672169ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Invalid
title: tag option problem (-background)
comment:
  This is a problem with tk text widget.

  When a tag is used to override the widgets -background
  value it also overrides the widgets -selectbackground
  value which means selection highlighting no longer
  occurrs in the tagged text.


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

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


tkt_uuid: 220636ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: Bad man pages generate errors when building winhelp
comment:
  OriginalBugID: 3883 Bug
  Version: 8.3b1
  SubmitDate: '1999-12-14'
  LastModified: '2000-01-04'
  Severity: LOW
  Status: Released
  Submitter: wart
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-01-04'
  FixedInVersion: 8.3b1


  The Tcl/Tk winhelp is generated from the Unix Tcl/Tk man pages.  There are a couple of man pages that generate errors when used to create the winhelp.  These errors prevent the .hlp file from being generated.

  When I run "make winhelp" for Tk, I get the following:

  ...
  Pass 1 -- Z:/cvs/connect2.0/tk8.3/doc/SetGrid.3
  Pass 1 -- Z:/cvs/connect2.0/tk8.3/doc/SetOptions.3
  duplicate topic Tk_Offset in Tk
  Pass 1 -- Z:/cvs/connect2.0/tk8.3/doc/SetVisual.3
  Pass 1 -- Z:/cvs/connect2.0/tk8.3/doc/StrictMotif.3
  ...
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/GetCursor.3
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/GetDash.3
  Bad .AP macro: .AP CONST char *string in
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/GetFont.3
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/GetGC.3
  ...
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/button.n^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/canvas.n^M
  Unknown macro: .fo ^M
  Unknown macro: .fo ^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/checkbutton.n^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/chooseColor.n^M
  ...
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/label.n^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/listbox.n^M
  Unknown font: o^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/loadTk.n^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/lower.n^M



  These were all fixed before the 8.3b1 public release. 
  -- 01/04/2000 hobbs


tkt_uuid: 1497346fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: None
resolution: Out of Date
title: TK with XGL
comment:
  OS: Ubuntu Dapper

  The XGL window manager seems to cause problems with TK
  applications. Here is the message given by two
  different scripts:


  trains3 (http://wiki.tcl.tk/1359):
  $ wish train.tk.tcl
  Application initialization failed: this isn't a Tk
  applicationunknown color name "Black"
  Error in startup script: can't invoke "winfo" command:
   application has been destroyed
      while executing
  "winfo exists $w"
      (procedure "rr::init" line 5)
      invoked from within
  "rr::init .c"
      (file "train.tk.tcl" line 1281)


  analog clock (http://wiki.tcl.tk/1011):
  $ wish clock.tk.tcl
  Application initialization failed: this isn't a Tk
  applicationunknown color name "Black"
  Error in startup script: can't invoke "canvas" command:
   application has been destroyed
      while executing
  "canvas .c -width 200 -height 200"
      invoked from within
  "grid [canvas .c -width 200 -height 200]"
      (file "clock.tk.tcl" line 1)


tkt_uuid: 220795ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Invalid
title: [grab] doesn't prevent interaction with ungrabbed entries
comment:
  OriginalBugID: 1510 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-16'
  LastModified: '1999-10-22'
  Severity: MED
  Status: Assigned
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1268 1158
  OS: Windows 98
  Machine: X86


  Name:
  Toni M. Rath

  ReproducibleScript:
      set test "This entry can be activated and altered by pressing <TAB>"
      frame .f1
      frame .f2
      entry .f1.e -textvariable test
      button .f2.b -text "exit" -command "destroy .f1"
      pack .f1 -fill x
      pack .f2
      pack .f1.e -fill x
      pack .f2.b
      grab .f2
      tkwait window .f1
      puts $test
      exit
      
      Description: see below
      



  ObservedBehavior:
      There is a grab on the frame of the Exit-Button. It should not be
      possible to alter the entry. It is in fact not possible to activate the
      entry by clicking on it, but if you press TAB, the entry becomes
      activated.
      
      I have a script, that starts a procedure, when you press <RETURN> in an
      entry. This should not happen, since I am trying to finish another
      activity (I have
      a grab on the necessary widgets), that should not be influenced by the
      other
      procedure (started by pressing <RETURN>).
      



  DesiredBehavior:
      If there is a grab on a part of a window, it should not be possible to
      interact
      with other parts of the window!
      




  The error the user reported is a litle mis guided, however it does reval a problem with grab on Windows.  Running the provided script on Unix and Windows will show the diufference.  Related bu ID 1268.  03/25/1999 15:49 - surles -
  ----
  Related bug IDs 1268 1158


tkt_uuid: 219980ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Duplicate
title: tcl_pkgPath missing, tcl_libPath undocumented
comment:
  OriginalBugID: 2041 Bug
  Version: 8.1
  SubmitDate: '1999-05-10'
  LastModified: '1999-08-08'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2317 2394 2455
  OS: Other
  Machine: NA
  FixedInVersion: 8.2
  ClosedDate: '1999-08-08'


  Name:
  Christopher Nelson

  ObservedBehavior:
  The .HLP file which comes with Tcl 8.1 describes the variable
      tcl_pkgPath but on W98, [puts $tcl_pkgPath] fails in wish and tclsh
      because tcl_pkgPath does not exists.  However, [info vars *Path*] turns
      up tcl_libPath.  Is this a replacement for tcl_pkgPath?  Where's it
      documented?



  It says specifically in init.tcl that tcl_pkgPath is not used on
  Windows.  This is a bug in the documentation (which just mentions
  the variable without the caveats).  Doc fixed in 8.2b3.
   
  -- 08/08/1999 hobbs


tkt_uuid: 1185640fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: None
resolution: None
title: Strange word and line selection in the text widget
comment:
  George Petasis reports on c.l.tcl:

  | I have noticed a strange behaviour with the Tk text
  | widget. When the widget displays non-english text
  | (in my case greek), when I double-click (to select
  | a word) or tripple-click (to select a line) in
  | the widget, the appearence of the selected text is
  | bizzare: from the character the click was done the
  | text is displayed fine, but before this character
  | no text is shown. Also, strange things can happen,
  | like characters moving around, as if text was
  | inserted/deleted around the selection.
                                                        
                           
  Later:
                                                        
                           
  | Which happens only under unix (linux fedora core 3)
  | when I enable XFT support.  Without XFT, everything
  | is normal...


tkt_uuid: 404421ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 4
foundin: obsolete: 8.4a2
resolution: Fixed
title: allocing zero size images
comment:
  Following is a patch to eliminate zero size allocs
  for null images.  Without this patch, there is no-way
  to run BrowseX under the dmalloc memory checker
  as it craps out at these points.  I meant to submit
  these way back in 8.3.2 (same problem with bounds
  checking GCC), but never got around to it.

  Peter


  --- /a/tmp/tk8.4a2/generic/tkImgPhoto.c Mon Aug 21
  15:45:15 2000
  +++ ./tkImgPhoto.c      Sat Feb 17 21:50:07 2001
  @@ -2383,8 +2383,8 @@
          TkClipBox(masterPtr->validRegion, &validBox);
       }
   
  -    if ((width != masterPtr->width) || (height !=
  masterPtr->height)
  -           || (masterPtr->pix24 == NULL)) {
  +    if (((width != masterPtr->width) || (height !=
  masterPtr->height)
  +           || (masterPtr->pix24 == NULL)) &&
  (width*height)) {
   
          /*
           * Reallocate storage for the 24-bit image and
  copy
  @@ -2554,9 +2554,10 @@
          instancePtr->pixels = newPixmap;
       }
   
  -    if ((instancePtr->width != masterPtr->width)
  +    if (((instancePtr->width != masterPtr->width)
              || (instancePtr->height !=
  masterPtr->height)
  -           || (instancePtr->error == NULL)) {
  +           || (instancePtr->error == NULL))
  +           && (masterPtr->height * masterPtr->width))
  {
   
          newError = (schar *) ckalloc((unsigned)
                  (masterPtr->height * masterPtr->width *
  3 * sizeof(schar)));


