# ticket

tkt_uuid: 780478ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: Cascading Menu Problem (OSX - Help SubMenu)
comment:
  We have developed a set of application specific 
  tutorials. This list logically fits very nicely into 
  the Help submenu as a cascading menu.

  This works great under the UNIX and Windows Ports, 
  but the cascading menu does not appear on the OSX 
  port.

  The documentation mentions some restrictions, but not 
  specifically cascading menus. Are these restricted 
  within an "Apple Menu" (whatever that is, they look 
  the same to me)?


tkt_uuid: 492220ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: None
resolution: Fixed
title: Improve handling of default extensions
comment:
  We found tk_getSaveFile wasn't handling default extensions the way users 
  expected on UNIX, especially as compared to the same dialog on 'Windows.

  It was always true that if the option -defaultextension ext was supplied, 
  "ext" was used if the user entered a file name without an extension.  However,
  when specifying file types, some non-intuitive behavior could result.  With this 
  patch, if no option -defaultextension ext is supplied, the first extension for the 
  first data type is used.   For example, user selects postscript type which has 
  the filters "*.ps *.eps".  We'll append ".ps" to the file name, if an extension has 
  not been supplied in the file name.


tkt_uuid: 1522467fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: Overflow in setting readMask on AMD64
comment:
  Below a patch that fixes an overflow on amd64 when 
  there are more than 31 files open, before the display 
  is opened. The problem is that amd64 has 
  64bit 'long's (and fd_mask size) and 32 bit 'int's. 
  So the mask sould be a 'long' and the '1' that gets 
  shifted, should be a 'long' as well.
  Following the macro's for FD_SET,
  #define __FDMASK(d)     ((__fd_mask) 1 << ((d) % 
  __NFDBITS))
  the missing part is the '__fd_mask' cast on '1'.

  -- unix/tkUnixEvent.c.org      2006-07-14 
  12:06:33.000000000 +0200
  +++ unix/tkUnixEvent.c  2006-07-14 12:02:05.000000000 
  +0200
  @@ -489,7 +489,8 @@
       static fd_mask readMask[MASK_SIZE];
       struct timeval blockTime, *timeoutPtr;
       Tcl_Time now;
  -    int fd, index, bit, numFound, numFdBits = 0;
  +    int fd, index, numFound, numFdBits = 0;
  +    unsigned long bit;

       /*
        * Look for queued events first.
  @@ -539,7 +540,7 @@
          }
          fd = ConnectionNumber(dispPtr->display);
          index = fd/(NBBY*sizeof(fd_mask));
  -       bit = 1 << (fd%(NBBY*sizeof(fd_mask)));
  +       bit = 1L << (fd%(NBBY*sizeof(fd_mask)));
          readMask[index] |= bit;
          if (numFdBits <= fd) {
              numFdBits = fd+1;
  @@ -565,7 +566,7 @@
           dispPtr = dispPtr->nextPtr) {
          fd = ConnectionNumber(dispPtr->display);
          index = fd/(NBBY*sizeof(fd_mask));
  -       bit = 1 << (fd%(NBBY*sizeof(fd_mask)));
  +       bit = 1L << (fd%(NBBY*sizeof(fd_mask)));
          if ((readMask[index] & bit) || 
  (QLength(dispPtr->display) > 0)) {
              DisplayFileProc((ClientData)dispPtr, 
  TCL_READABLE);
          }


tkt_uuid: 1012852fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: Radio Button Checkboxes fail when accelerators are used
comment:
  TclTkAqua release 8.4.7

  When menu items include radiobuttons with accelerators, 
  the checkboxes indicating the currently selected item do 
  not update correctly.  In the following script, the menu 
  without accelerators works correctly.  In the one with 
  accelerators, the radio item is never unchecked.

  set lc "black"
  menu .menubar
  . config -menu .menubar
  set color [menu .menubar.color -tearoff 0]
  set color1 [menu .menubar.color1 -tearoff 0]
  .menubar add cascade -label "Colors with Accelerators" -
  menu
  .menubar.color
  .menubar add cascade -label "Colors without 
  Accelerators" -menu
  .menubar.color1
  $color add radio -label "Black" -variable lc -value "black" -
  accelerator
  "Command-B"
  $color add radio -label "Red" -variable lc -value "red" -
  accelerator
  "Command-R"
  $color add radio -label "Green" -variable lc -value "green" 
  -accelerator
  "Command-G"
  $color add radio -label "Blue" -variable lc -value "blue" -
  accelerator
  "Command-E"

  $color1 add radio -label "Black" -variable lc -value "black" 
  $color1 add radio -label "Red" -variable lc -value "red" 
  $color1 add radio -label "Green" -variable lc -value 
  "green" 
  $color1 add radio -label "Blue" -variable lc -value "blue" 

  canvas .pic -width 800 -height 600 -bg white
  pack .pic -side top -fill both -expand 1


tkt_uuid: 3607250fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: current: 8.6.0
resolution: Wont Fix
title: Duplicate events associated with Edit menu for Wish
comment:
  (1) The Wish binary has an "Edit" menu with entries for "Undo" and "Redo".  The "Redo" menu entry has a keyboard shortcut "Command-Y".  This should be replaced with the Apple standard shortcut adopted in Tk/Aqua 8.6, "Command-Shift-Z".

  (2) The menu entries for Undo, Redo appear to do something in addition to the bindings and events defined in tk.tcl.

  The keystroke "Lock-Command-Y" causes a <<Redo>> in a text widget, although it is not listed in [event info <<Redo>>], nor is it bound to a command in any of the widget's binding tags.

  The keystroke "Lock-Command-Z" causes a double <<Undo>>.

  If "Caps Lock" is not active, the widget behaves as expected.

  It appears that, when "Caps Lock" is active, the operations defined in the application menu are performed IN ADDITION TO any operations defined by Tk events and bindings.


tkt_uuid: 220197ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 82. X11 Emulation
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: Tk/Win32 scrolling effects and fixed-font width
comment:
  OriginalBugID: 2203 Bug
  Version: 8.0.5
  SubmitDate: '1999-06-11'
  LastModified: '2000-01-27'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  ClosedDate: '2000-01-27'


  Name:
  Udo Flögel

  ReproducibleScript:
  making in a canvas a grid with a lot rows (>50) and having in each row a
      Label with 
      its number and then fast vertical scrolling there are differences 
      in X11/Linux: the items follows the movements with readable numbers and 
      in W95: the numbers appear as unreadable rests until the scrolling 
      stops. 
      The user wishes to follow his own movements to find the right item. 
      How can I avoid this effect (so it is same as in Linux?). 
      
      fixed-font in W95: a 'X' seems to have a more little width as a space 
                         (in Linux it's o.k.)

  ObservedBehavior:
  #!/usr/local/bin/python
      import Tkinter
      from Tkconstants import *
      import string,array
      
      class Led:
      def __init__(self, parent, value,par1,par2):
      # eine einzelne LED
      self.par1=par1
      self.par2=par2
      if value == 1:
      self.text='X'
      else:
      self.text=' '
      self.b= Tkinter.Button(parent, text=self.text,
                                             font='fixed',
                                              relief=GROOVE,
      command=self.change, border=1)
      self.b.pack(side=LEFT, fill=BOTH, expand=1)
      return
      
      def change(self):
      if self.text == 'X':
      self.text=' '
      else:
      self.text='X'
      self.b.configure(text=self.text)
      return
      
      def get(self):
      if self.text == 'X':
      return( 1 )
      else:
      return( 0 )
      
      class LedZ:
      def __init__(self, fname, ledanz, parentfl, parentfr):
      # eine LED-Zeile
      self.ledanz=ledanz
      self.lb=Tkinter.Label(parentfl, text=fname, anchor=W)
      self.lb.pack(side=TOP, expand=1, anchor=W)
      self.flz=Tkinter.Frame(parentfr)
      self.led=[]
      for i in range(self.ledanz):
      self.led.append( 
        Led(self.flz, i % 2, self.lb, self.flz) )
      self.flz.pack(side=TOP, fill=BOTH, expand=1)
      
      class LEDs:
      def __init__(self, ledanz):
      self.ledanz=ledanz
      self.tk=Tkinter.Tk()
      self.f0=Tkinter.Frame(self.tk)
      self.f1=Tkinter.Frame(self.f0)
      
      self.fT=Tkinter.Frame(self.f1)
      self.fTl=Tkinter.Label(self.fT, text="Funktion", anchor=W,
                                              relief=GROOVE, border=2)
      self.fTr=Tkinter.Frame(self.fT, relief=GROOVE, border=2)
      for i in range(self.ledanz):
      a=Tkinter.Label(self.fTr, text='%2d' % 0,
                    font='fixed')
      a.pack(side=LEFT, fill=BOTH, expand=1)
      self.fTl.grid(row=0, column=0, sticky="nsew")
      self.fTr.grid(row=0, column=1, sticky="nsew")
      self.fT.rowconfigure(0, weight=1)
      self.fT.columnconfigure(0, weight=1)
      self.fT.columnconfigure(1, weight=1)
      self.fT.columnconfigure(0, minsize=195)
      self.fT.pack(side=TOP, anchor=W)
      
      self.canvas=Tkinter.Canvas( self.f1 )
      self.vscroll= Tkinter.Scrollbar(
                                  self.f0, orient=VERTICAL,
      command=self.canvas.yview)
      self.canvas.config( yscrollcommand=self.vscroll.set )
      self.f2=Tkinter.Frame(self.canvas)
      self.fl=Tkinter.Frame(self.f2, relief=GROOVE, border=2)
      self.fr=Tkinter.Frame(self.f2, relief=GROOVE, border=2)
      self.ledz=[]
      for i in range(50):
      self.ledz.append( LedZ('fff%d' % i, self.ledanz, self.fl, self.fr) )
      self.fl.grid(row=0, column=0, sticky="nsew")
      self.fr.grid(row=0, column=1, sticky="nsew")
      self.f2.rowconfigure(0, weight=1)
      self.f2.columnconfigure(0, weight=1)
      self.f2.columnconfigure(1, weight=1)
      self.f2.columnconfigure(0, minsize=195)
      self.f2.pack(fill=BOTH)
      self.canvas.create_window((0,0), window=self.f2, anchor=NW)
      self.canvas.pack(side=LEFT, fill=BOTH)
      self.vscroll.pack(side=RIGHT, fill=Y)
      self.f1.pack(side=BOTTOM, fill=BOTH)
      self.f1.update()
      self.canvas.config( height=self.f2.winfo_height() )
      self.canvas.config( width=self.f2.winfo_width() )
      self.canvas.config( scrollregion=(0,0,self.f2.winfo_width(),
            self.f2.winfo_height() )
        )
      self.f0.pack(fill=BOTH)
      self.f0.update()
      #print self.fl.winfo_width()
      self.fl.config( width=self.fTl.winfo_width() )
      self.canvas.config( width=self.f2.winfo_width() )
      self.canvas.config( scrollregion=(0,0,self.f2.winfo_width(),
            self.f2.winfo_height() )
        )
      self.fT.columnconfigure(1, minsize=self.fr.winfo_width())
      self.f0.update()
      print self.fl.winfo_width()
      print self.fTl.winfo_width()
      print self.fr.winfo_width()
      print self.fTr.winfo_width()
      return
      
      def cvcommand(self):
      self.canvas.yview
      
      def ls(self):
      self.canvas.config( height=self.f2.winfo_height() )
      self.canvas.config( width=self.f2.winfo_width() )
      self.canvas.config( scrollregion=(0,0,self.f2.winfo_width(),
            self.f2.winfo_height() )
        )
      
      L=LEDs(12)
      Tkinter.mainloop()



  This is really due to the slower Windows port (due to the use of
  X emulation).  This has improved since 8.0, but rapid movement is
  likely to still be slower on Windows.  The best work-around is to
  use a widget for handling large data sets (like tktable). 
  -- 01/27/2000 hobbs


tkt_uuid: 1325988fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: None
title: tk dyn build fails
comment:
  This line in tk/unix/configure(.in)
  TK_SHLIB_LD_EXTRAS="${TK_SHLIB_LD_EXTRAS}"'
  -install_name ${DYLIB_INSTALL_DIR}/${TK_LIB_FILE}
  -seg1addr 0xb000000 -unexported_symbols_list
  $$(f=$(TCL_STUB_LIB_FILE).E && nm -gjp
  $(TCL_BIN_DIR)/$(TCL_STUB_LIB_FILE) | tail +3

  makes tk dyn fail because of the output of nm -qjp wich
  includes blank lines and multiple modules paths.

  Rewriting it this way works better but there is still
  warning messages:
  TK_SHLIB_LD_EXTRAS="${TK_SHLIB_LD_EXTRAS}"'
  -install_name ${DYLIB_INSTALL_DIR}/${TK_LIB_FILE}
  -seg1addr 0xb000000 -unexported_symbols_list
  $$(f=$(TCL_STUB_LIB_FILE).E && nm -gjp
  $(TCL_BIN_DIR)/$(TCL_STUB_LIB_FILE) | tail +3 | awk
  "/^$$/ {exit} {print \$$0}" > $$f && echo $$f)'


  Errors with original line:
  ld: symbols names listed in -unexported_symbols_list:
  libtclstub8.5.a.E not in linked objects
  /Users/zazou/tclkit-builds/build/ZMac.local/tcl/libtclstub8.5.a(strtoll.o):
  /Users/zazou/tclkit-builds/build/ZMac.local/tcl/libtclstub8.5.a(strtoull.o):
  __CurrentRuneLocale
  ____runetype
  ___error
  _strtoll
  _strtoull
  /usr/bin/libtool: internal link edit command failed
  make: *** [libtk8.5.dylib] Error 1

  Warnings with the patched line:
  ld: warning multiple definitions of symbol _strtoll
  /Users/zazou/tclkit-builds/build/ZMac.local/tcl/libtcl8.5.a(strtoll.o)
  definition of _strtoll in section (__TEXT,__text)
  /usr/lib//libSystem.dylib(strtoll.So) definition of
  _strtoll


tkt_uuid: 220828ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: New canvas item 'buffer'
comment:
  OriginalBugID: 926 RFE
  Version: 8.0.4
  SubmitDate: '1998-12-04'
  LastModified: '1999-08-15'
  Severity: SER
  Status: UnAssn
  Submitter: welch
  ChangedBy: hobbs
  OS: Other
  Machine: NA


  Name:

  Sebastian Wangnick


  DesiredBehavior:

  I've implemented a new canvas item "buffer", which stores everything below it in the drawing list into a Pixmap, refreshing from this Pixmap when redrawing items above it in the display list. 

  The implementation required quite some changes to the canvas drawing algorithm and is therefore contained in tkCanvas.c. 

  To properly distribute dirtyness two new canvas API functions had to be added, namely Tk_CanvasEventuallyRedrawItem and Tk_CanvasEventuallyRedrawItemPartially; however, only tkCanvImg.c from the standard distribution had to be changed to make use of these new functions instead of Tk_CanvasEventuallyRedraw (which is obsolete, but retained for backwards-compatibility reasons). 


  This implementation gives a speed improvement for animations on top of complex backgrounds such as geographic maps of about 10x.


  Patch:

  diff -brc ../tk8.0.4.orig/generic/tk.h ./generic/tk.h

  *** ../tk8.0.4.orig/generic/tk.hFri Oct 16 17:22:59 1998

  --- ./generic/tk.hWed Dec  2 07:32:33 1998

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

  *** 653,658 ****

  --- 653,664 ----

     * items in this canvas.  Later items

     * in list are drawn on top of earlier

     * ones. */

  +     struct Tk_Item *prevBufferPtr; /* Points to the buffer prior in sequence

  +                      * that dirty rectangles are attributed to,

  +  * or NULL if below us is no buffer,

  +  * only the canvas background. 

  +  * Note that buffers point to their

  +  * predecessor as well. */

        Tk_Uid staticTagSpace[TK_TAG_SPACE];/* Built-in space for limited # of

     * tags. */

        Tk_Uid *tagPtr;/* Pointer to array of tags.  Usually

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

  *** 1074,1079 ****

  --- 1080,1090 ----

    EXTERN voidTk_CanvasEventuallyRedraw _ANSI_ARGS_((

        Tk_Canvas canvas, int x1, int y1, int x2,

        int y2));

  + EXTERN voidTk_CanvasEventuallyRedrawItem _ANSI_ARGS_((

  +     Tk_Canvas canvas, Tk_Item* itemPtr));

  + EXTERN voidTk_CanvasEventuallyRedrawItemPartially _ANSI_ARGS_((

  +     Tk_Canvas canvas, Tk_Item* itemPtr, int x1, int y1,

  +     int x2, int y2));

    EXTERN intTk_CanvasGetCoord _ANSI_ARGS_((Tcl_Interp *interp,

        Tk_Canvas canvas, char *string,

        double *doublePtr));

  diff -brc ../tk8.0.4.orig/generic/tkCanvImg.c ./generic/tkCanvImg.c

  *** ../tk8.0.4.orig/generic/tkCanvImg.cMon Sep 14 18:23:05 1998

  --- ./generic/tkCanvImg.cWed Dec  2 07:32:33 1998

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

  *** 667,677 ****

    x = y = 0;

    width = imgWidth;

    height = imgHeight;

  ! Tk_CanvasEventuallyRedraw(imgPtr->canvas, imgPtr->header.x1,

  ! imgPtr->header.y1, imgPtr->header.x2, imgPtr->header.y2);

        } 

        ComputeImageBbox(imgPtr->canvas, imgPtr);

  !     Tk_CanvasEventuallyRedraw(imgPtr->canvas, imgPtr->header.x1 + x,

  !     imgPtr->header.y1 + y, (int) (imgPtr->header.x1 + x + width),

        (int) (imgPtr->header.y1 + y + height));

    }

  --- 667,677 ----

    x = y = 0;

    width = imgWidth;

    height = imgHeight;

  ! Tk_CanvasEventuallyRedrawItem(imgPtr->canvas, &imgPtr->header);

        } 

        ComputeImageBbox(imgPtr->canvas, imgPtr);

  !     Tk_CanvasEventuallyRedrawItemPartially(imgPtr->canvas, &imgPtr->header,

  !     imgPtr->header.x1 + x, imgPtr->header.y1 + y,

  !     (int) (imgPtr->header.x1 + x + width),

        (int) (imgPtr->header.y1 + y + height));

    }

  diff -brc ../tk8.0.4.orig/generic/tkCanvas.c ./generic/tkCanvas.c

  *** ../tk8.0.4.orig/generic/tkCanvas.cTue Oct 13 18:13:06 1998

  --- ./generic/tkCanvas.cWed Dec  2 10:48:35 1998

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

  *** 151,156 ****

  --- 151,497 ----

    extern Tk_ItemType tkOvalType, tkPolygonType;

    extern Tk_ItemType tkRectangleType, tkTextType, tkWindowType;


  + 

  + /*

  +  * The structure below defines the record for each buffer item.

  +  */

  + 

  + static intCreateBuffer _ANSI_ARGS_((Tcl_Interp *interp,

  +     Tk_Canvas canvas, Tk_Item *itemPtr,

  +     int argc, char **argv));

  + static voidDeleteBuffer _ANSI_ARGS_((Tk_Canvas canvas,

  +     Tk_Item *itemPtr, Display *display));

  + static intConfigureBuffer _ANSI_ARGS_((Tcl_Interp *interp,

  +     Tk_Canvas canvas, Tk_Item *itemPtr, int argc,

  +     char **argv, int flags));

  + static voidDisplayBuffer _ANSI_ARGS_((Tk_Canvas canvas,

  +     Tk_Item *itemPtr, Display *display, Drawable dst,

  +     int x, int y, int width, int height));

  + static voidScaleBuffer _ANSI_ARGS_((Tk_Canvas canvas,

  +     Tk_Item *itemPtr, double originX, double originY,

  +     double scaleX, double scaleY));

  + static voidTranslateBuffer _ANSI_ARGS_((Tk_Canvas canvas,

  +     Tk_Item *itemPtr, double deltaX, double deltaY));

  + static intBufferToArea _ANSI_ARGS_((Tk_Canvas canvas,

  +     Tk_Item *itemPtr, double *rectPtr));

  + static doubleBufferToPoint _ANSI_ARGS_((Tk_Canvas canvas,

  +     Tk_Item *itemPtr, double *pointPtr));

  + 

  + static Tk_ConfigSpec bufferConfigSpecs[] = {

  +     {TK_CONFIG_END, (char *) NULL, (char *) NULL, (char *) NULL,

  + (char *) NULL, 0, 0}

  + };

  + 

  + typedef struct BufferItem  {

  +     Tk_Item header;/* Generic stuff that's the same for all

  +  * types.  MUST BE FIRST IN STRUCTURE. */

  + 

  +     /*

  +      * Fields that are set by widget commands other than "configure".

  +      */

  +      

  +     /*

  +      * Configuration settings that are updated by Tk_ConfigureWidget.

  +      */

  + 

  +     /*

  +      * Fields whose values are derived from the current values of the

  +      * configuration settings above.

  +      */

  + 

  +     Pixmap buffer;/* Buffer caching drawing from below, or None. */

  +     int width, height;/* Size of buffer in non-None. */

  +     int x1, y1, x2, y2;/* Accumulated dirty area that trickled down on

  +      * us, to be redrawn (at least, depending on dirty

  +      * stuff below us) to next buffer or window. */

  +     struct BufferItem *nextBufferPtr; /* Pointer to next buffer structure in sequence,

  +      * or NULL if our stuff (and the stuff on top) 

  +      * goes directly into window. */

  + } BufferItem;

  + 

  + Tk_ItemType tkBufferType = {

  +     "buffer",/* name */

  +     sizeof(BufferItem),/* itemSize */

  +     CreateBuffer,/* createProc */

  +     bufferConfigSpecs,/* configSpecs */

  +     ConfigureBuffer,/* configureProc */

  +     NULL,/* coordProc */

  +     DeleteBuffer,/* deleteProc */

  +     DisplayBuffer,/* displayProc */

  +     0,/* alwaysRedraw */

  +     BufferToPoint,/* pointProc */

  +     BufferToArea,/* areaProc */

  +     NULL,/* postscriptProc */

  +     ScaleBuffer,/* scaleProc */

  +     TranslateBuffer,/* translateProc */

  +     NULL,/* indexProc */

  +     NULL,/* icursorProc */

  +     NULL,/* selectionProc */

  +     NULL,/* insertProc */

  +     NULL,/* dTextProc */

  +     (Tk_ItemType *) NULL/* nextPtr */

  + };

  + 

  + static voidCanvasEventuallyRedrawBuffer _ANSI_ARGS_((

  +     TkCanvas *canvasPtr, Tk_Item* itemPtr));

  + static intCanvasIsBuffer _ANSI_ARGS_((Tk_Item* itemPtr));

  + static BufferItem*CanvasFindBuffer _ANSI_ARGS_((TkCanvas *canvasPtr,

  +     Tk_Item* itemPtr));

  + /*

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

  +  *

  +  * CanvasIsBuffer --

  +  *

  +  * Results:

  +  *  Checks whether an item is a buffer item.

  +  *

  +  * Side effects:

  +  *None.

  +  *

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

  +  */

  + 

  + static int

  + CanvasIsBuffer(itemPtr)

  +     Tk_Item *itemPtr;

  + {

  +     return itemPtr->typePtr==&tkBufferType;

  + }

  + 

  + /*

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

  +  *

  +  * CanvasFindBuffer --

  +  *

  +  *  Given an item, find the first buffer below it, i.e., the one

  +  *  that we attribute dirty rectangles induced by the item to.

  +  *  In case of the item NULL find the topmost buffer of the canvas,

  +  *  i.e., the one to refresh the window from without any item changes.

  +  *

  +  * Results:

  +  *The return value is a pointer to the buffer,

  +  *or NULL if there is no buffer below itemPtr.

  +  *

  +  * Side effects:

  +  *None.

  +  *

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

  +  */

  + 

  + static BufferItem *

  + CanvasFindBuffer(canvasPtr, itemPtr)

  +     TkCanvas *canvasPtr;/* Canvas widget to search. */

  +     Tk_Item *itemPtr;

  + {

  +     if (itemPtr) {

  +     itemPtr = itemPtr->prevBufferPtr;

  +     } else {

  +     itemPtr = canvasPtr->lastItemPtr;

  +     if (itemPtr && !CanvasIsBuffer(itemPtr)) {

  +         itemPtr = itemPtr->prevBufferPtr;

  +     }

  +     }

  +     return (BufferItem*) itemPtr;

  + }

  + 

  + /*--------------------------------------------------------------

  +  *

  +  * CreateBuffer --

  +  *

  +  *This procedure is invoked to create a new buffer item

  +  *in a canvas.

  +  *

  +  * Results:

  +  *A standard Tcl return value.  If an error occurred in

  +  *creating the item then an error message is left in

  +  *interp->result;  in this case itemPtr is left uninitialized

  +  *so it can be safely freed by the caller.

  +  *

  +  * Side effects:

  +  *A new buffer item is created.

  +  *

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

  +  */

  + 

  + static int

  + CreateBuffer(interp, canvas, itemPtr, argc, argv)

  +     Tcl_Interp *interp;/* Interpreter for error reporting. */

  +     Tk_Canvas canvas;/* Canvas to hold new item. */

  +     Tk_Item *itemPtr;/* Record to hold new item;  header

  +  * has been initialized by caller. */

  +     int argc;/* Number of arguments in argv. */

  +     char **argv;/* Arguments describing rectangle. */

  + {

  +     TkCanvas *canvasPtr = (TkCanvas *) canvas;

  +     BufferItem *bufferPtr = (BufferItem *) itemPtr;

  +     BufferItem *prevBufferPtr;

  + 

  +     if (argc != 0) {

  + Tcl_AppendResult(interp, "wrong # args: should be \"",

  + Tk_PathName(Tk_CanvasTkwin(canvas)), " create ",

  + itemPtr->typePtr->name, "\"", (char *) NULL);

  + return TCL_ERROR;

  +     }

  + 

  +     /*

  +      * Carry out initialization that is needed in order to clean

  +      * up after errors during the the remainder of this procedure.

  +      */

  + 

  +     bufferPtr->buffer= None;

  +     bufferPtr->x1= 0;

  +     bufferPtr->y1= 0;

  +     bufferPtr->x2= 0;

  +     bufferPtr->y2= 0;

  + 

  +     /* Append to list of buffers. */

  +     bufferPtr->nextBufferPtr = NULL;

  +     prevBufferPtr = CanvasFindBuffer((TkCanvas*)canvas,itemPtr);

  +     if (prevBufferPtr)

  +     prevBufferPtr->nextBufferPtr = bufferPtr;

  +     else

  +         canvasPtr->firstBufferPtr = bufferPtr;

  + 

  +     CanvasEventuallyRedrawBuffer(canvasPtr, itemPtr);

  + 

  +     return TCL_OK;

  + }

  + 

  + /*

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

  +  *

  +  * DeleteBuffer --

  +  *

  +  *This procedure is called to clean up the data structure

  +  *associated with a buffer item.

  +  *

  +  * Results:

  +  *None.

  +  *

  +  * Side effects:

  +  *Resources associated with itemPtr are released.

  +  *

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

  +  */

  + 

  + static void

  + DeleteBuffer(canvas, itemPtr, display)

  +     Tk_Canvas canvas;/* Info about overall canvas widget. */

  +     Tk_Item *itemPtr;/* Item that is being deleted. */

  +     Display *display;/* Display containing window for

  +  * canvas. */

  + {

  +     TkCanvas *canvasPtr = (TkCanvas *) canvas;

  +     BufferItem *bufferPtr = (BufferItem *) itemPtr;

  +     BufferItem *prevBufferPtr;

  + 

  +     if (bufferPtr->buffer != None) {

  + Tk_FreePixmap(display, bufferPtr->buffer);

  + 

  +     CanvasEventuallyRedrawBuffer(canvasPtr, itemPtr);

  + 

  +     /* Unlink from list of buffers. */

  +     prevBufferPtr = CanvasFindBuffer((TkCanvas*)canvas,itemPtr);

  +     if (prevBufferPtr)

  +     prevBufferPtr->nextBufferPtr = bufferPtr->nextBufferPtr;

  +     else

  +         canvasPtr->firstBufferPtr = bufferPtr->nextBufferPtr;

  +     }

  + }

  + 

  + /*

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

  +  *

  +  * Further Buffer routines --

  +  *

  +  *These are the buffer type manager required routines. 

  +  *      For buffers, they do nothing and/or return an error.

  +  *

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

  +  */

  + 

  + static void

  + CanvasEventuallyRedrawBuffer (canvasPtr, itemPtr)

  +     TkCanvas *canvasPtr;/* Canvas to invalidate. */

  +     Tk_Item *itemPtr;/* Buffer to be redrawn. */

  + {

  +     if (!canvasPtr->tkwin)

  +     return;

  +     Tk_CanvasEventuallyRedrawItemPartially((Tk_Canvas) canvasPtr, itemPtr,

  +             canvasPtr->xOrigin, canvasPtr->yOrigin,

  +             canvasPtr->xOrigin + Tk_Width(canvasPtr->tkwin),

  +             canvasPtr->yOrigin + Tk_Height(canvasPtr->tkwin));

  + }

  + 

  + static int

  + ConfigureBuffer (interp, canvas, itemPtr, argc, argv, flags)

  +     Tcl_Interp *interp;/* Interpreter for error reporting. */

  +     Tk_Canvas canvas;/* Canvas containing itemPtr. */

  +     Tk_Item *itemPtr;/* Buffer item to reconfigure. */

  +     int argc;/* Number of elements in argv.  */

  +     char **argv;/* Arguments describing things to configure. */

  +     int flags;/* Flags to pass to Tk_ConfigureWidget. */

  + {

  +     if (Tk_ConfigureWidget(interp, Tk_CanvasTkwin(canvas), bufferConfigSpecs, 

  +         argc, argv, (char *) itemPtr, flags) != TCL_OK) {

  + return TCL_ERROR;

  +     }

  +     return TCL_OK;

  + }

  + 

  + static void

  + DisplayBuffer (canvas, itemPtr, display, drawable, x, y, width, height)

  +     Tk_Canvas canvas;/* Canvas that contains item. */

  +     Tk_Item *itemPtr;/* Item to be displayed. */

  +     Display *display;/* Display on which to draw item. */

  +     Drawable drawable;/* Pixmap or window in which to draw

  +  * item. */

  +     int x, y, width, height;/* Describes region of canvas that

  +  * must be redisplayed (not used). */

  + {

  +     panic("tried to display buffer %d in canvas %s", itemPtr->id,

  +         Tk_PathName(Tk_CanvasTkwin(canvas)));

  + }

  + 

  + static void

  + ScaleBuffer (canvas, itemPtr, originX, originY, scaleX, scaleY)

  +     Tk_Canvas canvas;/* Canvas containing buffer. */

  +     Tk_Item *itemPtr;/* Buffer to be scaled. */

  +     double originX, originY;/* Origin about which to scale buffer. */

  +     double scaleX;/* Amount to scale in X direction. */

  +     double scaleY;/* Amount to scale in Y direction. */

  + {

  + }

  + 

  + static void

  + TranslateBuffer (canvas, itemPtr, deltaX, deltaY)

  +     Tk_Canvas canvas;/* Canvas containing buffer. */

  +     Tk_Item *itemPtr;/* Buffer that is being moved. */

  +     double deltaX, deltaY;/* Amount by which buffer is to be

  +  * moved. */

  + {

  + }

  + 

  + static int

  + BufferToArea(canvas, itemPtr, rectPtr)

  +     Tk_Canvas canvas;/* Canvas containing itemPtr. */

  +     Tk_Item *itemPtr;/* Item to check against rectangle. */

  +     double *rectPtr;/* Pointer to array of four coordinates

  +  * (x1, y1, x2, y2) describing rectangular

  +  * area.  */

  + {

  +     return -1;

  + }

  + 

  + static double

  + BufferToPoint(canvas, itemPtr, pointPtr)

  +     Tk_Canvas canvas;/* Canvas containing itemPtr. */

  +     Tk_Item *itemPtr;/* Item to check against point. */

  +     double *pointPtr;/* Pointer to x and y coordinates. */

  + {

  +     return 1.7E308;

  + }

  + 

    /*

     * Various Tk_Uid's used by this module (set up during initialization):

     */

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

  *** 166,171 ****

  --- 507,519 ----

    static int numSlowSearches;


    /*

  +  * Boolean variable indicating whether or not special debugging code

  +  * should be executed.

  +  */

  + 

  + int tkCanvasDebug = 0;

  + 

  + /*

     * Prototypes for procedures defined later in this file:

     */


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

  *** 178,183 ****

  --- 526,536 ----

        XEvent *eventPtr));

    static voidCanvasEventProc _ANSI_ARGS_((ClientData clientData,

        XEvent *eventPtr));

  + static void             CanvasEventuallyRedrawAll _ANSI_ARGS_((

  +                             TkCanvas *canvasPtr));

  + static void             CanvasEventuallyRedrawExpose _ANSI_ARGS_((

  +                 TkCanvas *canvasPtr,

  +                             int x1, int y1, int x2, int y2));

    static intCanvasFetchSelection _ANSI_ARGS_((

        ClientData clientData, int offset,

        char *buffer, int maxBytes));

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

  *** 295,300 ****

  --- 648,654 ----

        (ClientData) canvasPtr, CanvasCmdDeletedProc);

        canvasPtr->firstItemPtr = NULL;

        canvasPtr->lastItemPtr = NULL;

  +     canvasPtr->firstBufferPtr = NULL;

        canvasPtr->borderWidth = 0;

        canvasPtr->bgBorder = NULL;

        canvasPtr->relief = TK_RELIEF_FLAT;

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

  *** 650,665 ****

    itemPtr = StartTagSearch(canvasPtr, argv[2], &search);

    if (itemPtr != NULL) {

        if (argc != 3) {

  ! Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  ! itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

        }

        if (itemPtr->typePtr->coordProc != NULL) {

    result = (*itemPtr->typePtr->coordProc)(interp,

    (Tk_Canvas) canvasPtr, itemPtr, argc-3, argv+3);

        }

        if (argc != 3) {

  ! Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  ! itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

        }

    }

        } else if ((c == 'c') && (strncmp(argv[1], "create", length) == 0)

  --- 1004,1017 ----

    itemPtr = StartTagSearch(canvasPtr, argv[2], &search);

    if (itemPtr != NULL) {

        if (argc != 3) {

  ! Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

        }

        if (itemPtr->typePtr->coordProc != NULL) {

    result = (*itemPtr->typePtr->coordProc)(interp,

    (Tk_Canvas) canvasPtr, itemPtr, argc-3, argv+3);

        }

        if (argc != 3) {

  ! Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

        }

    }

        } else if ((c == 'c') && (strncmp(argv[1], "create", length) == 0)

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

  *** 701,706 ****

  --- 1053,1062 ----

    itemPtr->tagSpace = TK_TAG_SPACE;

    itemPtr->numTags = 0;

    itemPtr->typePtr = typePtr;

  + itemPtr->prevBufferPtr = canvasPtr->lastItemPtr;

  + if (itemPtr->prevBufferPtr && !CanvasIsBuffer(itemPtr->prevBufferPtr)) {

  +     itemPtr->prevBufferPtr = itemPtr->prevBufferPtr->prevBufferPtr;

  + }

    if ((*typePtr->createProc)(interp, (Tk_Canvas) canvasPtr,

    itemPtr, argc-3, argv+3) != TCL_OK) {

        ckfree((char *) itemPtr);

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

  *** 719,726 ****

        canvasPtr->lastItemPtr->nextPtr = itemPtr;

    }

    canvasPtr->lastItemPtr = itemPtr;

  ! Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  ! itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

    canvasPtr->flags |= REPICK_NEEDED;

    sprintf(interp->result, "%d", itemPtr->id);

        } else if ((c == 'd') && (strncmp(argv[1], "dchars", length) == 0)

  --- 1075,1081 ----

        canvasPtr->lastItemPtr->nextPtr = itemPtr;

    }

    canvasPtr->lastItemPtr = itemPtr;

  ! Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

    canvasPtr->flags |= REPICK_NEEDED;

    sprintf(interp->result, "%d", itemPtr->id);

        } else if ((c == 'd') && (strncmp(argv[1], "dchars", length) == 0)

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

  *** 759,770 ****

         * the old area.

         */


  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  !     itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

        (*itemPtr->typePtr->dCharsProc)((Tk_Canvas) canvasPtr,

        itemPtr, first, last);

  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  !     itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

    }

        } else if ((c == 'd') && (strncmp(argv[1], "delete", length) == 0)

        && (length >= 2)) {

  --- 1114,1137 ----

         * the old area.

         */


  !     Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

        (*itemPtr->typePtr->dCharsProc)((Tk_Canvas) canvasPtr,

        itemPtr, first, last);

  !     Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

  ! }

  !     } else if ((c == 'd') && (strncmp(argv[1], "debug", length) == 0)

  !     && (length >= 3)) {

  ! if (argc > 3) {

  !     Tcl_AppendResult(interp, "wrong # args: should be \"",

  !     argv[0], " debug ?boolean?\"", (char *) NULL);

  !     goto error;

  ! }

  ! if (argc == 2) {

  !     interp->result = (tkCanvasDebug) ? "1" : "0";

  ! } else {

  !     if (Tcl_GetBoolean(interp, argv[2], &tkCanvasDebug) != TCL_OK) {

  ! goto error;

  !     }

    }

        } else if ((c == 'd') && (strncmp(argv[1], "delete", length) == 0)

        && (length >= 2)) {

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

  *** 774,781 ****

    for (i = 2; i < argc; i++) {

        for (itemPtr = StartTagSearch(canvasPtr, argv[i], &search);

    itemPtr != NULL; itemPtr = NextItem(&search)) {

  ! Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  ! itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

    if (canvasPtr->bindingTable != NULL) {

        Tk_DeleteAllBindings(canvasPtr->bindingTable,

        (ClientData) itemPtr);

  --- 1141,1147 ----

    for (i = 2; i < argc; i++) {

        for (itemPtr = StartTagSearch(canvasPtr, argv[i], &search);

    itemPtr != NULL; itemPtr = NextItem(&search)) {

  ! Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

    if (canvasPtr->bindingTable != NULL) {

        Tk_DeleteAllBindings(canvasPtr->bindingTable,

        (ClientData) itemPtr);

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

  *** 875,882 ****

        goto done;

    }

    if ((itemPtr != NULL) && (canvasPtr->textInfo.gotFocus)) {

  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  !     itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

    }

    if (argv[2][0] == 0) {

        canvasPtr->textInfo.focusItemPtr = NULL;

  --- 1241,1247 ----

        goto done;

    }

    if ((itemPtr != NULL) && (canvasPtr->textInfo.gotFocus)) {

  !     Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

    }

    if (argv[2][0] == 0) {

        canvasPtr->textInfo.focusItemPtr = NULL;

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

  *** 893,900 ****

    }

    canvasPtr->textInfo.focusItemPtr = itemPtr;

    if (canvasPtr->textInfo.gotFocus) {

  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  !     itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

    }

        } else if ((c == 'g') && (strncmp(argv[1], "gettags", length) == 0)) {

    if (argc != 3) {

  --- 1258,1264 ----

    }

    canvasPtr->textInfo.focusItemPtr = itemPtr;

    if (canvasPtr->textInfo.gotFocus) {

  !     Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

    }

        } else if ((c == 'g') && (strncmp(argv[1], "gettags", length) == 0)) {

    if (argc != 3) {

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

  *** 933,940 ****

        index);

        if ((itemPtr == canvasPtr->textInfo.focusItemPtr)

        && (canvasPtr->textInfo.cursorOn)) {

  ! Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  ! itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

        }

    }

        } else if ((c == 'i') && (strncmp(argv[1], "index", length) == 0)

  --- 1297,1303 ----

        index);

        if ((itemPtr == canvasPtr->textInfo.focusItemPtr)

        && (canvasPtr->textInfo.cursorOn)) {

  ! Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

        }

    }

        } else if ((c == 'i') && (strncmp(argv[1], "index", length) == 0)

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

  *** 990,1001 ****

         * larger or smaller than the old area.

         */


  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  !     itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

        (*itemPtr->typePtr->insertProc)((Tk_Canvas) canvasPtr,

        itemPtr, beforeThis, argv[4]);

  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr, itemPtr->x1,

  !     itemPtr->y1, itemPtr->x2, itemPtr->y2);

    }

        } else if ((c == 'i') && (strncmp(argv[1], "itemcget", length) == 0)

        && (length >= 6)) {

  --- 1353,1362 ----

         * larger or smaller than the old area.

         */


  !     Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

        (*itemPtr->typePtr->insertProc)((Tk_Canvas) canvasPtr,

        itemPtr, beforeThis, argv[4]);

  !     Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

    }

        } else if ((c == 'i') && (strncmp(argv[1], "itemcget", length) == 0)

        && (length >= 6)) {

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

  *** 1030,1042 ****

    itemPtr->typePtr->configSpecs, (char *) itemPtr,

    argv[3], 0);

        } else {

  ! Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  ! itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

    result = (*itemPtr->typePtr->configProc)(interp,

    (Tk_Canvas) canvasPtr, itemPtr, argc-3, argv+3,

    TK_CONFIG_ARGV_ONLY);

  ! Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  ! itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

    canvasPtr->flags |= REPICK_NEEDED;

        }

        if ((result != TCL_OK) || (argc < 5)) {

  --- 1391,1401 ----

    itemPtr->typePtr->configSpecs, (char *) itemPtr,

    argv[3], 0);

        } else {

  ! Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

    result = (*itemPtr->typePtr->configProc)(interp,

    (Tk_Canvas) canvasPtr, itemPtr, argc-3, argv+3,

    TK_CONFIG_ARGV_ONLY);

  ! Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

    canvasPtr->flags |= REPICK_NEEDED;

        }

        if ((result != TCL_OK) || (argc < 5)) {

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

  *** 1086,1097 ****

    }

    for (itemPtr = StartTagSearch(canvasPtr, argv[2], &search);

    itemPtr != NULL; itemPtr = NextItem(&search)) {

  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  !     itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

        (void) (*itemPtr->typePtr->translateProc)((Tk_Canvas) canvasPtr,

        itemPtr,  xAmount, yAmount);

  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  !     itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

        canvasPtr->flags |= REPICK_NEEDED;

    }

        } else if ((c == 'p') && (strncmp(argv[1], "postscript", length) == 0)) {

  --- 1445,1454 ----

    }

    for (itemPtr = StartTagSearch(canvasPtr, argv[2], &search);

    itemPtr != NULL; itemPtr = NextItem(&search)) {

  !     Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

        (void) (*itemPtr->typePtr->translateProc)((Tk_Canvas) canvasPtr,

        itemPtr,  xAmount, yAmount);

  !     Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

        canvasPtr->flags |= REPICK_NEEDED;

    }

        } else if ((c == 'p') && (strncmp(argv[1], "postscript", length) == 0)) {

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

  *** 1150,1161 ****

    }

    for (itemPtr = StartTagSearch(canvasPtr, argv[2], &search);

    itemPtr != NULL; itemPtr = NextItem(&search)) {

  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  !     itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

        (void) (*itemPtr->typePtr->scaleProc)((Tk_Canvas) canvasPtr,

        itemPtr, xOrigin, yOrigin, xScale, yScale);

  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  !     itemPtr->x1, itemPtr->y1, itemPtr->x2, itemPtr->y2);

        canvasPtr->flags |= REPICK_NEEDED;

    }

        } else if ((c == 's') && (strncmp(argv[1], "scan", length) == 0)

  --- 1507,1516 ----

    }

    for (itemPtr = StartTagSearch(canvasPtr, argv[2], &search);

    itemPtr != NULL; itemPtr = NextItem(&search)) {

  !     Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

        (void) (*itemPtr->typePtr->scaleProc)((Tk_Canvas) canvasPtr,

        itemPtr, xOrigin, yOrigin, xScale, yScale);

  !     Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);

        canvasPtr->flags |= REPICK_NEEDED;

    }

        } else if ((c == 's') && (strncmp(argv[1], "scan", length) == 0)

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

  *** 1256,1266 ****

    goto error;

        }

        if (canvasPtr->textInfo.selItemPtr != NULL) {

  ! Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  ! canvasPtr->textInfo.selItemPtr->x1,

  ! canvasPtr->textInfo.selItemPtr->y1,

  ! canvasPtr->textInfo.selItemPtr->x2,

  ! canvasPtr->textInfo.selItemPtr->y2);

    canvasPtr->textInfo.selItemPtr = NULL;

        }

        goto done;

  --- 1611,1618 ----

    goto error;

        }

        if (canvasPtr->textInfo.selItemPtr != NULL) {

  ! Tk_CanvasEventuallyRedrawItem((Tk_Canvas) canvasPtr,

  ! canvasPtr->textInfo.selItemPtr);

    canvasPtr->textInfo.selItemPtr = NULL;

        }

        goto done;

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

  *** 1584,1593 ****


        CanvasSetOrigin(canvasPtr, canvasPtr->xOrigin, canvasPtr->yOrigin);

        canvasPtr->flags |= UPDATE_SCROLLBARS|REDRAW_BORDERS;

  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  !     canvasPtr->xOrigin, canvasPtr->yOrigin,

  !     canvasPtr->xOrigin + Tk_Width(canvasPtr->tkwin),

  !     canvasPtr->yOrigin + Tk_Height(canvasPtr->tkwin));

        return TCL_OK;

    }

    

  --- 1936,1942 ----


        CanvasSetOrigin(canvasPtr, canvasPtr->xOrigin, canvasPtr->yOrigin);

        canvasPtr->flags |= UPDATE_SCROLLBARS|REDRAW_BORDERS;

  !     CanvasEventuallyRedrawAll(canvasPtr);

        return TCL_OK;

    }

    

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

  *** 1622,1627 ****

  --- 1971,1977 ----

        canvasPtr = (TkCanvas *) instanceData;

        itemPtr = canvasPtr->firstItemPtr;

        for ( ; itemPtr != NULL; itemPtr = itemPtr->nextPtr) {

  +     if (itemPtr->typePtr->configProc) {

    result = (*itemPtr->typePtr->configProc)(canvasPtr->interp,

    (Tk_Canvas) canvasPtr, itemPtr, 0, NULL,

    TK_CONFIG_ARGV_ONLY);

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

  *** 1629,1639 ****

        Tcl_ResetResult(canvasPtr->interp);

    }

        }

        canvasPtr->flags |= REPICK_NEEDED;

  !     Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,

  !     canvasPtr->xOrigin, canvasPtr->yOrigin,

  !     canvasPtr->xOrigin + Tk_Width(canvasPtr->tkwin),

  !     canvasPtr->yOrigin + Tk_Height(canvasPtr->tkwin));

    }

    

    /*

  --- 1979,1987 ----

        Tcl_ResetResult(canvasPtr->interp);

        }

    }

  +     }

        canvasPtr->flags |= REPICK_NEEDED;

  !     CanvasEventuallyRedrawAll(canvasPtr);

    }

    

    /*

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

  *** 1661,1672 ****

        TkCanvas *canvasPtr = (TkCanvas *) clientData;

        Tk_Window tkwin = canvasPtr->tkwin;

        Tk_Item *itemPtr;

  !     Pixmap pixmap;

  !     int screenX1, screenX2, screenY1, screenY2, width, height;


        if (canvasPtr->tkwin == NULL) {

    return;

        }

        if (!Tk_IsMapped(tkwin)) {

    goto done;

        }

  --- 2009,2028 ----

        TkCanvas *canvasPtr = (TkCanvas *) clientData;

        Tk_Window tkwin = canvasPtr->tkwin;

        Tk_Item *itemPtr;

  !     Tk_Item *lastItemPtr;

  !     Pixmap tempForClipping = None;

  !     int sx1, sy1, sx2, sy2;

  ! 

  !     if (tkCanvasDebug) {

  ! Tcl_SetVar2(canvasPtr->interp, "tk_canvasRedraw", (char *) NULL,

  !     Tcl_GetCommandName(canvasPtr->interp, canvasPtr->widgetCmd),

  !                 TCL_GLOBAL_ONLY);

  !     }


        if (canvasPtr->tkwin == NULL) {

    return;

        }

  +     

        if (!Tk_IsMapped(tkwin)) {

    goto done;

        }

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

  *** 1688,1741 ****

        }


        /*

         * Compute the intersection between the area that needs redrawing

         * and the area that's visible on the screen.

         */


  !     if ((canvasPtr->redrawX1 < canvasPtr->redrawX2)

  !     && (canvasPtr->redrawY1 < canvasPtr->redrawY2)) {

  ! screenX1 = canvasPtr->xOrigin + canvasPtr->inset;

  ! screenY1 = canvasPtr->yOrigin + canvasPtr->inset;

  ! screenX2 = canvasPtr->xOrigin + Tk_Wid



  I've tried as much as possible to retain backwards-compatibility. However, one should be aware that an additional field had to be added to the Tk_Canvas structure.
  Severity is "Severe" because without the patch display of life air traffic (my application) is not possible.
  Documentation is outstanding. The only new command, however, is <.canvas> create buffer, there are no further configuration options.


tkt_uuid: 220253ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Invalid
title: cant clear selection in text
comment:
  OriginalBugID: 3429 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-17'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Digital Unix
  ClosedDate: '1999-11-17'


  Name:
  Torbjörn Gannholm

  ReproducibleScript:
  text .t -exportselection yes
  pack .t
  proc finn {} {
  global finnord finntyp funnen
    selection clear
    set funnen [.t search -$finntyp -count finnlen "$finnord" "$funnen +1 chars"]
    if { [string length $funnen] != 0 } {
      .t tag add sel $funnen "$funnen + $finnlen chars"
      .t mark set insert "$funnen + $finnlen chars"
      .t see insert
    } else {
      tk_messageBox -message "$finnord not found as $finntyp match" -type ok
      finn_dialog
    }
  }

  ObservedBehavior:
  calling finn gives error message
  text doesn't contain any characters tagged with "sel"

  DesiredBehavior:
  I expect selection to be cleared and if a word is found it is to be the new selection.

  when I remove the line
  selection clear
  it works fine but the selection remains in the old place as well as being set to the found word



  This works as expected.  If the user continues to have problems,
  they should instead use '$text tag remove sel 1.0 end', which
  is the correct way to do this anyway. 
  -- 11/17/1999 hobbs


tkt_uuid: 2902826fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Wont Fix
title: 'justify' attribute not set correctly by default on labels
comment:
  Try this :

  ttk::label .l
  pack .l -fill x
  puts [.l configure -justify]    => {} instead of "left" (text is clearly justified to the left).

  Labels should have their "justify" option set correctly by default.


tkt_uuid: 220874ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 7 High
foundin: obsolete: 8.2
resolution: None
title: Image zoom crash
comment:
  OriginalBugID: 3399 Bug
  Version: 8.2
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-12'
  Severity: CRIT
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  OSVersion: 4.10.1998


  Name:
  Bernard Tiddeman

  ReproducibleScript:
  canvas .c
      pack .c
      image create photo img
      image create photo tmp
      .c create image 0 0 -image img -anchor nw
      tmp read my_image.ppm  # My image is a large image e.g. 1240 by 1765
      img copy img zoom 2 2  # Crashes here!

  ObservedBehavior:
  WISH82 caused an invalid page fault in
      module TK82.DLL at 015f:004227b1.
      Registers:
      EAX=00000000 CS=015f EIP=004227b1 EFLGS=00010202
      EBX=0071f014 SS=0167 ESP=0071ed94 EBP=0071ed98
      ECX=00000000 DS=0167 ESI=0071f02c FS=19df
      EDX=00529adc ES=0167 EDI=036ebebc GS=0000
      Bytes at CS:EIP:
      89 51 08 8b e5 5d c3 55 8b ec 83 ec 34 8b 45 0c 
      Stack dump:
      00000000 0071eddc 00467fd4 00000000 00529adc 036ebebc 0071f02c 000009b0
      00000dca 0071ee20 00000000 00000000 00000000 0190beb0 0071f014 1000fa8c

  DesiredBehavior:
  A zoomed image to display


tkt_uuid: 220609ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: Window "." flashes under windows when tk starts
comment:
  OriginalBugID: 3338 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-01-06'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-01-06'
  FixedInVersion: 8.3b2


  Name:
  Georgios Petasis

  ObservedBehavior:
  When running an application under Windows 98 with directx 7.0 with tk
      8.2.1, the main window appears and disappears quickly, even if
      the first command in the script is "wm withdraw .". This problem has
      started with tk 8.2.1.

  DesiredBehavior:
  Applications starting normally, without getting this "flash" when just
      started.



  This has been fixed in 8.3b2.  The problem was that in 8.2.1,
  the Windows-style behavior to ensure that a deiconified window
  was raised to the top caused it to be mapped before waiting
  for geometry updates to occur (during idle time).  This has
  been changed to occur as an idle event. 
  -- 01/06/2000 hobbs


tkt_uuid: 630171ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: long, fat lines fail on Windows
comment:
  # Source this into wish. Test with

  #

  #   drawlines [makepts $count] $width

  #   

  # where $count is number of points, $width is width of
  lines

  # in pixels.

  #

  # Works well on unix.  Time required depends linearly
  on the

  # number of points, with thick lines (width>1) taking only

  # marginally longer than thin lines.

  #

  # On Windows, thin lines (width=1) work well, with time

  # required depending linearly on the number of points.

  # Thick lines are rendered slowly, with time required

  # increasing much worse than linear once the number of

  # points is more than say 100.  On my Win98 box, with

  # Tcl/Tk 8.4.1, 'drawlines [makepts 1638] 2' raises

  # an illegal operation fault.  More points than this

  # results in nothing being drawn.  On Win2k, system

  # response becomes very sluggish as the number of points

  # moves into the thousands.


tkt_uuid: 641216ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 7 High
foundin: None
resolution: Duplicate
title: Misleading messages on photo name "."
comment:
  A photo named "." can not be created, but still leads to 
  partial "brain-death" (Tk commands are refused):

  X:\tcl>tclsh
  % package require Tk
  8.4
  % image create photo .
  this isn't a Tk applicationNULL main window
  % image names
  can't invoke "image" command:  application 
  has been destroyed
  % pwd
  X:/tcl
  %

  A destroyed app that speaks? BTW, the NULL error 
  comes only if a tclsh was upgraded with [package 
  require Tk]. In a genuine wish it just exits, just like   
       proc . {} {} 
  - but also that is not what I call expectable behavior...

  [Richard Suchenwirth]


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

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

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


tkt_uuid: 220213ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Tk widgets not working
comment:
  OriginalBugID: 2352 Bug
  Version: 8.1.1
  SubmitDate: '1999-07-16'
  LastModified: '1999-11-16'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: SunOS
  OSVersion: 4.1.3_U1
  Machine: Sparc
  ClosedDate: '1999-11-16'


  Name:Q. Alex Zhao

  Extensions:Img 1.2

  CustomShell:the Img 1.2 patches

  ReproducibleScript:
  First of all, I couldn't build Tcl/Tk with gcc (egcs 1.1.2; parsing
      error),
      so I had to use the Sun compiler "acc: SC3.0.1 12/7/95 patch_101913-05"
      to
      build everything. The build was ok (there's a minor change in Tcl
      memcmp.c).
      But Tk doesn't work: for example if I type the following in wish8.1:
      button .b
      pack .b
      and I click on the button, it stays in the depressed mode and doesn't
      invoke
      the callback function (if there is one).



  There is not enough information to reproduce any problems,
  and this works on similarly built systems.  I don't know
  why gcc shouldn't have worked (error not specified), and
  it may not be finding the Tk runtime libraries correctly,
  which have the bindings that get most of the behaviors. 
  -- 11/16/1999 hobbs


tkt_uuid: 702230ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 9 Immediate
foundin: obsolete: 8.4.2
resolution: Fixed
title: Another panewindow/visual related problem
comment:
  I had the original visual related problem where if I 
  created a panewindow within a frame which had a 
  truecolor visual, but the root window had a visual of 
  psuedocolor, I would crash.

  This was fixed in 8.4.2 - Thanks - I can now create the 
  window.

  But.... If I use left mouse to adjust the size of the 
  panes, we are back to what appears to be a visual 
  related crash when trying to draw the "proxy" line.

  Using the middle mouse to adjust the panes on the fly 
  worked great. I attempted to locate the problem, and 
  followed it fairly deep, but a time crunch resulted in a 
  hack of just changing my binds to avoid use of the 
  proxy.

  I've attached a short example to demonstrate the 
  problem. You'll need to run on a Xserver with a default 
  root window which uses the psuedocolor visual (All of 
  our SGI and SUN systems do).

  The example should fail at start time for 8.4.1, but not 
  fail until the panes are adjusted with the left mouse 
  under 8.4.2.

  Thanks for your time.


tkt_uuid: 1155596fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 4
foundin: obsolete: 8.4.13
resolution: Accepted
title: TkAqua: display issues for buttons with image with alpha
comment:
  set img [image create photo -file image-with-alpha.png]
  pack [button .b -image $img]

  The button is not displayed, and "OpenCPicture failed"
  is printed to stderr.  Subsequently interacting with
  the GUI results in a crash.  This happens both with
  TkImg and with the PNG parser I'm implementing.  It
  does not crash with labels.

  0   com.apple.QD            0x9156d270 SetGWorld +
  0x401   com.tcltk.tklibrary     0x0b079e68 TkPutImage +
  0x300
  2   com.tcltk.tklibrary     0x0b040950 ImgPhotoDisplay
  + 0x1043   com.tcltk.tklibrary     0x0b039700
  Tk_RedrawImage + 0xb8
  4   com.tcltk.tklibrary     0x0b075924 SetupBevelButton
  + 0x1385   com.tcltk.tklibrary     0x0b075694
  TkMacOSXDrawControl + 0x29c
  6   com.tcltk.tklibrary     0x0b074638 TkpDisplayButton
  + 0x1287   com.tcltk.tcllibrary    0x0a0678f8
  TclServiceIdle + 0x68
  8   com.tcltk.tcllibrary    0x0a056dac Tcl_DoOneEvent +
  0x1809   com.tcltk.tklibrary     0x0b02bcf4 Tk_MainLoop
  + 0x18
  10  com.tcltk.tklibrary     0x0b04936c Tk_MainEx +
  0x33811  com.tcltk.wish          0x000163c4 0x1000 +
  0x153c4
  12  com.tcltk.wish          0x00015e80 0x1000 +
  0x14e8013  dyld                    0x8fe1a558
  _dyld_start + 0x64


tkt_uuid: 937783ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Invalid
title: Win TK menu binding does not register
comment:
  Tcl/Tk 8.4.6.0 for Windows (ActiveTcl Binary
  Distribution) seems to not register bindings to menu.
  However, linux version of Tcl/Tk seems to work fine.

  Code:

  frame .mbar -relief raised
  menubutton .mbar.m1_button -text "Test1" -menu
  .mbar.m1_button.m1
  menu .mbar.m1_button.m1
  pack .mbar -side top -fill x
  pack .mbar.m1_button -side left
  .mbar.m1_button.m1 add command -label "Test1 MenuItem A"
  .mbar.m1_button.m1 add command -label "Test1 MenuItem B"
  bind .mbar.m1_button.m1 <Enter> {exit}


  Problem:

  Running this code in Linux Tcl/Tk, when opening the
  menu and mousing over the menuitems, the program will
  exit, as expected. But running this code under Win
  Tcl/Tk, mousing over the menuitems, nothing happens!!


tkt_uuid: 220076ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Duplicate
title: unknown floating-point error, errno=84
comment:
  OriginalBugID: 4980 Bug
  Version: 8.3
  SubmitDate: '2000-04-10'
  LastModified: '2000-04-10'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4942
  OS: Linux-SuSE
  OSVersion: SuSE Linux 6.1, Kernel 2.2.14
  Machine: Celeron 466, 128MB RAM
  ClosedDate: '2000-04-10'


  Name: Tommy B

  ReproducibleScript:
  Don´t know if the error is recreatable;
  Every Tk application I start crashes immediately after startup with an "unknown floating-point error, errno=84"
  Perhaps it has to do with my recent upgrade to XFree86 4.0
  Tcl works just fine, I only have problems with Tk; even the same command that works under Tcl (tclsh) doesn´t work with Tk (wish), e.g. if [ $tcl_version < 7.6 ] ...

  ObservedBehavior:
  Fatal error immediately after start of a Tk script.

  DesiredBehavior:
  A running Tk application ;)


tkt_uuid: 683813ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Fixed
title: TabToWindow should treat spinbox same as entry
comment:
  A Spinbox is really just a fancy kind of Entry widget.
  And when the keyboard focus is moved to an Entry widget
  using the Tab key, the contents of the widget is
  automatically selected. The same thing should happen
  for the Spinbox.


tkt_uuid: 1592667fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: tkUnixRFont.c fails to compile on Solaris
comment:
  platform sparc solaris 9, sun c compiler, tk cvs head
  (downloaded from activestate ftp site). 
  configured with
  with options \"'--prefix=/volws/lwv27/ldatae'
  '--enable-shared' '--enable-symbols' '--enable-stubs'
  '--enable-langinfo' 'CC=cc'\"



  cc -c -g   -KPIC -I/vol/tclsrcsol/tcl85/tk/unix/../unix
  -I/vol/tclsrcsol/tcl85/tk/u
  nix/../generic
  -I/vol/tclsrcsol/tcl85/tk/unix/../bitmaps
  -I/vol/tclsrcsol/tcl85/tcl
  /generic -I/vol/tclsrcsol/tcl85/tcl/unix
  -I/usr/openwin/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_INT
  TYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
  -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -
  D_POSIX_PTHREAD_SEMANTICS=1 -D_THREAD_SAFE=1
  -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DT
  CL_THREADS=1 -D_REENTRANT=1
  -D_POSIX_PTHREAD_SEMANTICS=1 -DTCL_SHLIB_EXT=\".so\" -D
  TCL_CFG_DEBUG=1 -DTCL_WIDE_INT_TYPE=long\ long
  -DHAVE_STRUCT_DIRENT64=1 -DHAVE_STRU
  CT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
  -DHAVE_TYPE_OFF64_T=1 -DWORDS_BIGENDIA
  N=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1
  -Dstrtod=fixstrtod -DHAVE_PW_GECOS=1
   -DHAVE_XSS=1 -DHAVE_XFT=1      -DTCL_NO_DEPRECATED 
  -DUSE_TCL_STUBS  -I/usr/openwi
  n/include  
  /vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixRFont.c
  "/usr/openwin/include/X11/Xft/Xft.h", line 35: cannot
  find include file: <ft2build.
  h>
  "/usr/openwin/include/X11/Xft/Xft.h", line 36: bad file
  specification
  "/usr/openwin/include/X11/Xft/Xft.h", line 53: syntax
  error before or at: _XftFTlib
  rary
  "/usr/openwin/include/X11/Xft/Xft.h", line 53: warning:
  old-style declaration or in
  correct type for: _XftFTlibrary
  "/usr/openwin/include/X11/Xft/Xft.h", line 87: syntax
  error before or at: FT_UInt
  "/usr/openwin/include/X11/Xft/Xft.h", line 87: cannot
  recover from previous errors
  cc: acomp failed for
  /vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixRFont.c
  gmake: *** [tkUnixRFont.o] Error 2


tkt_uuid: 3574708fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 9 Immediate
foundin: obsolete: 8.5.12
resolution: Accepted
title: Fix for crash in Tk focus handling
comment:
  I have been seeing intermittent crashes in wish, Tcl/Tk
  8.5.12 running on Windows-XP.  The crashes mostly occur
  when I am running some test harness scripts to exercise
  the functionality of my application, which as a side
  affect can rapidly create & destroy some windows. 
  Stress testing Tk a bit, I suppose.

  The problem turns out to be with calls to TkSetFocusWin
  in generic/tkFocus.c.  Not all calls are checking for a
  TK_ALREADY_DEAD window.  So TkSetFocusWin can insert a
  reference to a dead window into the focus-tracking
  DisplayFocusInfo structure.  This results in a
  subsequent crash, usually on the *next* call to
  TkSetFocusWin when it tries to move focus away from that
  window, by which time its window structure has been
  overwritten i.e. a use-after-free error.

  The fix is simple - move the check for a TK_ALREADY_DEAD
  window to within TkSetFocusWin, so that it is performed
  for all calls. I've exercised my application with the
  fix applied, with no more crashes.


  --- ./tkFocus.c-8.5.12  Thu Oct  4 18:00:03 2012
  +++ ./tkFocus.c-8.5.12-fix      Thu Oct  4 18:09:09 2012
  @@ -160,9 +160,7 @@
              if (newPtr == NULL) {
                  return TCL_ERROR;
              }
  -           if (!(newPtr->flags & TK_ALREADY_DEAD)) {
  -               TkSetFocusWin(newPtr, 0);
  -           }
  +           TkSetFocusWin(newPtr, 0);
              return TCL_OK;
          }
       }
  @@ -552,6 +550,14 @@
       TkWindow *topLevelPtr;
       int allMapped, serial;

  +    /*
  +     * Don't set focus if window is already dead.
  +     */
  +
  +    if (winPtr->flags & TK_ALREADY_DEAD) {
  +       return;
  +    }
  +
       displayFocusPtr = FindDisplayFocusInfo(winPtr->mainPtr, winPtr->dispPtr);

       /*
  {


tkt_uuid: 1536735fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Accepted
title: Text widget modified flag (again)
comment:
  The text widget modified flag is normally not touched
  when an empty delete (or insert) is done. However, in
  the following case this fails:

  text .t
  .t delete insert
  .t edit modified   ;# prints "1"

  The reason is that we try to delete the final newline,
  which is a special case in the C code.

  Attached patch takes into account this special case for
  the modified flag.


tkt_uuid: 779174ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: seg-fault re-using text widget
comment:
  The attached script crashes Tk 8.5a0 when trying to
  re-use the widget name .t.

  NB. The script also crashes Tk 8.4, but that is an
  entirely different crash, in 'destroy .t', which has
  been fixed in 8.5a0.


tkt_uuid: 220789ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.0.4
resolution: None
title: Unmap,Deactivate,FocusOut,etc bindings don\'t work on NT for
comment:
  OriginalBugID: 1368 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '2000-04-03'
  Severity: LOW
  Status: Assigned
  Submitter: pat
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86


  Name:
  harry halladay

  ReproducibleScript:
  wm de .
  raise .
  set b [button .b -text menuhere -command exit]
  pack $b
  set menu [menu $b.m -tearoff 0]
  $menu add command -label "Line 0"
  $menu add separator
  $menu add command -label "Line 1" -command "puts line1"
  $menu add command -label "Line 2" -command "puts line2"
  $menu add command -label "Line 3" -command "puts line3"
  bind $b <ButtonRelease-3> "tk_popup $menu %X %Y 0"
  bind $menu <Unmap> "puts \"got unmap\""
  bind . <Deactivate> "puts \"got Deactivate\""

  ObservedBehavior:
  run the script
  pop up the menu with the right mouse button
  click on the NT desktop with the left button. the menu is unmapped, but the Unmap binding is not fired. This works properly on HPUX.

  DesiredBehavior:
  The menu should pop down and fire the Unmap binding



  This is verified on 8.3.0 and NT.  You might see if you can workaround this with a <<MenuSelect>> binding on the menu (which will tell you when an item in the menu has been selected).

  - eric

  -- 04/03/2000 ericm


tkt_uuid: 220268ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Invalid
title: it is the bug of BLT2.4 library.unicode support?
comment:
  OriginalBugID: 3980 Bug
  Version: 8.2.1
  SubmitDate: '2000-01-06'
  LastModified: '2000-01-07'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  ClosedDate: '2000-01-07'


  Name:
  luyingwei

  ReproducibleScript:
  First,it is the bug of BLT2.4 library.
  The title font y axis of graph and barchart components don't support unicode such as chinese fonts, but the title font of x axis do!I don't know why.



  This is likely a minor oversight in getting BLT up-to-date with
  i18n in 8.1+.  This is being closed against Tk, but the bug is
  being forwarded to the BLT author. 
  -- 01/07/2000 hobbs


tkt_uuid: 220037ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Duplicate
title: Resized window grows smaller
comment:
  OriginalBugID: 3375 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-04-07'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4464 4353
  OS: Macintosh
  OSVersion: Swedish MacOS 8.6
  ClosedDate: '2000-04-07'


  Name:
  Johan Dahl

  Extensions:
  Tclapplescript

  ReproducibleScript:
  make a new toplevel window. Restrict resizing in one dimension
      
      % toplevel .w
      % wm resizable .w 0 1

  ObservedBehavior:
  If I know resizes it the nonresizable dimension grows one pixel smaller
      each time.

  DesiredBehavior:
  The nonresizable dimension should stay the same


tkt_uuid: 461442ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Make Tk use the default Windows font
comment:
  Hello,

  Donal K. Fellows asked me to submit the following patch I posted to comp.lang.tcl. Its purpose is 
  to make Tk use the standard Windows dialog font by default. In the current version, the default 
  font for Tk buttons, labels, entries etc. is "MS Sans Serif" 8 pt regardless of what font the user 
  configured in Windows; this makes Tk programs look slightly (but noticably) different from native 
  Windows dialog applications. With my patch, Tk uses the Windows standard dialog font by default. 
  Here's the news article I wrote on September 13, 2001.

  --- 8< ---

  To make Tk use the standard Windows dialog font, the Tk
  source code has to be patched in two places. I did this
  for Tk 8.3.3. Perhaps someone has the time to put this
  on a Wiki page, include in a FAQ, or even integrate it
  in the official Tk for Windows source codes.

  First, a few lines have to be added to function TkpGetNativeFont
  in tk/win/tkWinFont.c. These lines add a new font name,
  "windefault", which can be used throughout Tk. The windefault
  font is always the Windows standard dialog font. Note that
  this font is different from all the other system fonts,
  like "system" or "ansi". It has to be implemented differently
  from the other system fonts since it can't be retrieved
  through GetStockObject. Here's the new version of TkpGetNativeFont:

  TkFont *
  TkpGetNativeFont(
      Tk_Window tkwin,/* For display where font will
   be used. */
      CONST char *name)/* Platform-specific font name. */
  {
      int object;
      WinFont *fontPtr;

  /* New code starts here */
  if (strcmp(name,"windefault")==0)
  {
  NONCLIENTMETRICS ncm;
  ncm.cbSize = sizeof(NONCLIENTMETRICS);
  SystemParametersInfo(SPI_GETNONCLIENTMETRICS,
   sizeof(NONCLIENTMETRICS),
  &ncm, 0);

  tkwin = (Tk_Window) ((TkWindow *) 
  tkwin)->mainPtr->winPtr;
  fontPtr = (WinFont *) ckalloc(sizeof(WinFont));
  InitFont(tkwin,
  CreateFontIndirect(&ncm.lfMessageFont),
  0, fontPtr);

  return (TkFont *) fontPtr;
  }
  /* New code ends here - rest of function unchanged */

      object = TkFindStateNum(NULL, NULL, systemMap, name);
      if (object < 0) {
  return NULL;
      }

      tkwin = (Tk_Window) ((TkWindow *) tkwin)->mainPtr->winPtr;
      fontPtr = (WinFont *) ckalloc(sizeof(WinFont));
      InitFont(tkwin, GetStockObject(object), 0, fontPtr);

      return (TkFont *) fontPtr;
  }

  With this modification it's possible to use the new font with any
  Tk widget, like this:

  button .b -text "Whatever" -font windefault

  The second modification sets the windefault font as the default for
  all Tk widgets. This is done by replacing the CTL_FONT define in
  tk/win/tkWinDefault.h with "windefault", like this:

  #define CTL_FONT"windefault"

  In the original version, CTL_FONT is hardcoded to 8 pt MS Sans Serif.

  After these changes, recompile the Tk library and rebuild wish or
  whatever application you're linking Tk into.
  --- 8< ---

  Sorry for not being able to submit CVS diffs, but I think the above should be obvious and not too 
  hard to integrate.

  If you have any questions about this, contact me at wr@grp.de.

  Thanks
  Wolfram Rösler


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




  04/28/1999 14:34 - kenj - Already documented in GetJustify.3.


tkt_uuid: 2913483fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: Images in disabled ttk::buttons don't display on Tk/Cocoa
comment:
  If a ttk::button is set to disabled on Tk-Cocoa, the image contained in the button disappears and is replaced by a white rectangle. cf: http://www.codebykevin.com/puretk.png

  The image in a disabled Tk button is correctly displayed, i.e. grayed out. 


tkt_uuid: 3487407fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: Weird indices
comment:
  text .t
  pack .t
  for {set i 1} {$i < 10} {incr i} {
    .t insert end "Line $i\n"
  }
  .t mark set insert 1.0
  .t configure -start 5 -end 5
  .t index insert

  This returns:
  *    -3.0 in Tk 8.5.9
  *    0.6 in core-8-5-branch
  *    "bad text index" error in bug-1630262 branch

  The question is what the correct output should be for this text widget showing ZERO lines (since -startline == -endline).

  Indices should be clamped to the -startline/-endline range of the text widget, so that no negative (or larger than the number of lines) index is ever returned. The two first answers are therefore both wrong.

  Also in core-8-5-branch is the fix for bug 1630271 (commit 61a3685ac2), which makes the "bad text index" error in branch bug-1630262: marks located outside the -startline/-endline range being not reachable from the considered peer, an error is thrown.

  I think "bad text index" is the right answer in this "corner" case.

  The problem then is consistency, since:

  .t mark names            ;# --> insert current
  .t index current         ;# --> 1.0


tkt_uuid: 1587363fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 3 Low
foundin: obsolete: 8.5a5
resolution: Out of Date
title: configure script doesn't find Tcl8.5 sources
comment:
  A plain ./configure fails to find the Tcl8.5 sources. 

  When fed with an extra:
   --with-tcl=/usr/local/src/tcl8.5a5/unix
  the build continues without problems.



  > pwd
  /usr/local/src/tk8.5a5/unix
  > ./configure
  checking for Tcl configuration... found
  /usr/local/src/tcl8.4.14/unix/tclConfig.sh
  checking for existence of
  /usr/local/src/tcl8.4.14/unix/tclConfig.sh... loading
  checking for tclsh... /usr/bin/tclshg
  checking for tclsh in Tcl build directory...
  /usr/local/src/tcl8.4.14/unix/tclsh
  configure: error:
  /usr/local/src/tcl8.4.14/unix/tclConfig.sh is for Tcl 8.4.
  Tk 8.5a5 needs Tcl 8.5.
  Use --with-tcl= option to indicate location of
  tclConfig.sh file for Tcl 8.5.
  > uname -a
  Linux somehost 2.4.21-303-athlon #1 Tue Dec 6 12:24:00
  UTC 2005 i686 athlon i386 GNU/Linux
  > 


tkt_uuid: 511956ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: "bool" is #defined to _Bool in ISO 99 C
comment:
  The ISO 99 C standard now requires that C 
  compilers define bool to be _Bool.  If you want to 
  use bool in your code, you have to undef it first.  
  This only shows up in one place in Tk, so rather 
  than fighting with the compiler, we should just 
  change it.  Here is the patch (just changing the int 
  bool variable to int boolval):

  Index: tkCmds.c
  =======================================
  ============================
  RCS file: /cvsroot/tktoolkit/tk/generic/tkCmds.c,v
  retrieving revision 1.20.2.2
  diff -c -w -r1.20.2.2 tkCmds.c
  *** tkCmds.c    2001/10/17 07:02:07     1.20.2.2
  --- tkCmds.c    2002/02/01 23:14:46
  ***************
  *** 709,721 ****
                   * That will indicate to the user that input 
  methods
                   * are just not available.
                   */
  !               int bool;
  !               if (Tcl_GetBooleanFromObj(interp, objv[2+
  skip], &bool)
                          != TCL_OK) {
                      return TCL_ERROR;
                  }
    #ifdef TK_USE_INPUT_METHODS
  !               dispPtr->useInputMethods = bool;
    #endif /* TK_USE_INPUT_METHODS */
              } else if ((objc - skip) != 2) {
                  Tcl_WrongNumArgs(interp, 2, objv,
  --- 709,721 ----
                   * That will indicate to the user that input 
  methods
                   * are just not available.
                   */
  !               int boolval;
  !               if (Tcl_GetBooleanFromObj(interp, objv[2+
  skip], &boolval)
                          != TCL_OK) {
                      return TCL_ERROR;
                  }
    #ifdef TK_USE_INPUT_METHODS
  !               dispPtr->useInputMethods = boolval;
    #endif /* TK_USE_INPUT_METHODS */
              } else if ((objc - skip) != 2) {
                  Tcl_WrongNumArgs(interp, 2, objv,


tkt_uuid: 487861ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.5.4
resolution: Accepted
title: cascade with -accelerator looks wrong
comment:
  If I create a cascade menu item and give it an 
  accelerator it looks wrong. The accelerator overwrites 
  the cascade items label from the left.

  Now I know it doesn't particularly make sense to have 
  an accelerator for a cascade, but the man page doesn't 
  say you can't, and suggests that if you do the 
  accelerator appears on the right.

  Here's how to reproduce:

  menu .m
  .m add cascade -label "Cascade" -accelerator "X"
  . configure -menu .m

  When I do the above on my box (win2k, tcl 8.2, 8.3 and 
  8.4) I see "Xascade"


tkt_uuid: 1167420fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: TIP Implementation
resolution: None
title: TIP#243: Find Dialog
comment:
  Implementation of a find dialog for use with a text
  widget. Submitted by Rüdiger Härtel <r_haertel@gmx.de>
  with updates for 8.5 by DKF


tkt_uuid: 886240ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 8
foundin: None
title: TIP 168: Cubic Bezier curves on the canvas
comment:
  This file contains changes that implement a "raw" 
  -smooth method (as described in TIP 168) for canvas
  items. It also does some cleanup of terminology in
  comments to specific functions.

  Affected files are tkTrig.c, tkCanvUtil.c,
  and tkInt.decls.


tkt_uuid: 436817ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Wont Fix
title: Courier 12 Underline font problem
comment:
  I am using the 8.3.3 release of tcl/tk, under windows, 
  and have noticed that Courier 12 Underlined doesn't 
  display correctly in the text widget.

  Consider the following

  toplevel .foo
  text .foo.bar -font {Courier 12 underline}

  pack .foo.bar

  As you type in the window, the font being displayed 
  does not have any underlined characters.

  If you then change the font as follows:-

  .foo.bar conf -font {Courier 10 underline}

  the display shows text that has been underlined.

  Trying several different fonts, it appears that 
  Courier (or Courier New) size 12 only displays this 
  behaviour.


tkt_uuid: 220554ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 2
foundin: None
resolution: Fixed
title: Maintainance improvement for Objectified commands
comment:
  OriginalBugID: 2348 RFE
  Version: 8.1.1
  SubmitDate: '1999-07-16'
  LastModified: '1999-12-13'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  Machine: NA
  FixedDate: '1999-12-13'
  FixedInVersion: 8.3b1


  Name:

  Jan Nijtmans


  CVS:

  juli 2, 1999


  DesiredBehavior:

  Currently, the 'objectification' of widgets not only requires the use of

      Tcl_Obj's in stead of strings, but also that the newer option database

      functions are used in stead of the older ones. This is a high burden in

      the process of converting all widgets to use Tcl_Objs. The following

      patch (tk.h, tkOldConfig.c) adds the flag TK_CONFIG_OBJS to the

      Tk_ConfigureWidget() function, which makes it usable with Tcl_Obj's

      as well.


      The remainder of the patch is a demonstration of this new feature:

      the objectification of the "frame" and "toplevel" commands while

      still using the old option functions (using the TK_CONFIG_OBJS flag).

      At the same time it is a thorough test, because the "frame" and

      "toplevel" commands are still expected to work exactly as before.

      Only they are speeded up because many string-object conversions are

      saved. Later, the switch can be made to the new option functions,

      thereby gaining an even greater speed-up.


      This feature is used by the dash-patch, in order to make it easier

      to track down changes in the Scriptics' source code. The value of

      TK_CONFIG_OBJS is carefully chosen not to conflict with any other

      flags. In time this code will disappear, but at least it will make

      life easier (and Tk run faster) until then.


      Finally, the submitted patch adapts the documentation as well

      (ConfigWidg.3).


  Patch:

  *** generic/tk.h.origWed Jul  7 19:46:46 1999

  --- generic/tk.hWed Jul  7 19:47:40 1999

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

  *** 347,352 ****

  --- 347,353 ----

     */


    #define TK_CONFIG_ARGV_ONLY1

  + #define TK_CONFIG_OBJS0x80


    /*

     * Possible flag values for Tk_ConfigSpec structures.  Any bits at

  *** generic/tkOldConfig.c.origWed Jul  7 19:46:51 1999

  --- generic/tkOldConfig.cWed Jul  7 19:47:40 1999

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

  *** 125,131 ****

         */


        for ( ; argc > 0; argc -= 2, argv += 2) {

  ! specPtr = FindConfigSpec(interp, specs, *argv, needFlags, hateFlags);

    if (specPtr == NULL) {

        return TCL_ERROR;

    }

  --- 125,138 ----

         */


        for ( ; argc > 0; argc -= 2, argv += 2) {

  ! char *arg;

  ! 

  ! if (flags & TK_CONFIG_OBJS) {

  !     arg = Tcl_GetString((Tcl_Obj *) *argv);

  ! } else {

  !     arg = *argv;

  ! }

  ! specPtr = FindConfigSpec(interp, specs, arg, needFlags, hateFlags);

    if (specPtr == NULL) {

        return TCL_ERROR;

    }

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

  *** 135,145 ****

     */


    if (argc < 2) {

  !     Tcl_AppendResult(interp, "value for \"", *argv,

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

        return TCL_ERROR;

    }

  ! if (DoConfig(interp, tkwin, specPtr, argv[1], 0, widgRec) != TCL_OK) {

        char msg[100];


        sprintf(msg, "\n    (processing \"%.40s\" option)",

  --- 142,157 ----

     */


    if (argc < 2) {

  !     Tcl_AppendResult(interp, "value for \"", arg,

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

        return TCL_ERROR;

    }

  ! if (flags & TK_CONFIG_OBJS) {

  !     arg = Tcl_GetString((Tcl_Obj *) argv[1]);

  ! } else {

  !     arg = argv[1];

  ! }

  ! if (DoConfig(interp, tkwin, specPtr, arg, 0, widgRec) != TCL_OK) {

        char msg[100];


        sprintf(msg, "\n    (processing \"%.40s\" option)",

  *** generic/tkFrame.c.origWed Jul  7 20:08:35 1999

  --- generic/tkFrame.cWed Jul  7 21:11:31 1999

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

  *** 167,173 ****

     */


    static intConfigureFrame _ANSI_ARGS_((Tcl_Interp *interp,

  !     Frame *framePtr, int argc, char **argv,

        int flags));

    static voidDestroyFrame _ANSI_ARGS_((char *memPtr));

    static voidDisplayFrame _ANSI_ARGS_((ClientData clientData));

  --- 167,173 ----

     */


    static intConfigureFrame _ANSI_ARGS_((Tcl_Interp *interp,

  !     Frame *framePtr, int objc, Tcl_Obj *CONST objv[],

        int flags));

    static voidDestroyFrame _ANSI_ARGS_((char *memPtr));

    static voidDisplayFrame _ANSI_ARGS_((ClientData clientData));

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

  *** 175,188 ****

        ClientData clientData));

    static voidFrameEventProc _ANSI_ARGS_((ClientData clientData,

        XEvent *eventPtr));

  ! static intFrameWidgetCmd _ANSI_ARGS_((ClientData clientData,

  !     Tcl_Interp *interp, int argc, char **argv));

    static voidMapFrame _ANSI_ARGS_((ClientData clientData));

    

    /*

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

     *

  !  * Tk_FrameCmd, Tk_ToplevelCmd --

     *

     *These procedures are invoked to process the "frame" and

     *"toplevel" Tcl commands.  See the user documentation for

  --- 175,188 ----

        ClientData clientData));

    static voidFrameEventProc _ANSI_ARGS_((ClientData clientData,

        XEvent *eventPtr));

  ! static intFrameWidgetObjCmd _ANSI_ARGS_((ClientData clientData,

  !     Tcl_Interp *interp, int objc, Tcl_Obj *CONST objv[]));

    static voidMapFrame _ANSI_ARGS_((ClientData clientData));

    

    /*

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

     *

  !  * Tk_FrameObjCmd, Tk_ToplevelObjCmd --

     *

     *These procedures are invoked to process the "frame" and

     *"toplevel" Tcl commands.  See the user documentation for

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

  *** 199,223 ****

     */


    int

  ! Tk_FrameCmd(clientData, interp, argc, argv)

        ClientData clientData;/* Main window associated with

     * interpreter. */

        Tcl_Interp *interp;/* Current interpreter. */

  !     int argc;/* Number of arguments. */

  !     char **argv;/* Argument strings. */

    {

  !     return TkCreateFrame(clientData, interp, argc, argv, 0, (char *) NULL);

    }


    int

  ! Tk_ToplevelCmd(clientData, interp, argc, argv)

        ClientData clientData;/* Main window associated with

     * interpreter. */

        Tcl_Interp *interp;/* Current interpreter. */

  !     int argc;/* Number of arguments. */

  !     char **argv;/* Argument strings. */

    {

  !     return TkCreateFrame(clientData, interp, argc, argv, 1, (char *) NULL);

    }

    

    /*

  --- 199,223 ----

     */


    int

  ! Tk_FrameObjCmd(clientData, interp, objc, objv)

        ClientData clientData;/* Main window associated with

     * interpreter. */

        Tcl_Interp *interp;/* Current interpreter. */

  !     int objc;/* Number of arguments. */

  !     Tcl_Obj *CONST objv[];/* Argument objects. */

    {

  !     return TkCreateFrame(clientData, interp, objc, objv, 0, (char *) NULL);

    }


    int

  ! Tk_ToplevelObjCmd(clientData, interp, objc, objv)

        ClientData clientData;/* Main window associated with

     * interpreter. */

        Tcl_Interp *interp;/* Current interpreter. */

  !     int objc;/* Number of arguments. */

  !     Tcl_Obj *CONST objv[];/* Argument objects. */

    {

  !     return TkCreateFrame(clientData, interp, objc, objv, 1, (char *) NULL);

    }

    

    /*

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

  *** 240,252 ****

     */


    int

  ! TkCreateFrame(clientData, interp, argc, argv, toplevel, appName)

        ClientData clientData;/* Main window associated with interpreter.

     * If we're called by Tk_Init to create a

     * new application, then this is NULL. */

        Tcl_Interp *interp;/* Current interpreter. */

  !     int argc;/* Number of arguments. */

  !     char **argv;/* Argument strings. */

        int toplevel;/* Non-zero means create a toplevel window,

     * zero means create a frame. */

        char *appName;/* Should only be non-NULL if clientData is

  --- 240,252 ----

     */


    int

  ! TkCreateFrame(clientData, interp, objc, objv, toplevel, appName)

        ClientData clientData;/* Main window associated with interpreter.

     * If we're called by Tk_Init to create a

     * new application, then this is NULL. */

        Tcl_Interp *interp;/* Current interpreter. */

  !     int objc;/* Number of arguments. */

  !     Tcl_Obj *CONST objv[];/* Argument objects. */

        int toplevel;/* Non-zero means create a toplevel window,

     * zero means create a frame. */

        char *appName;/* Should only be non-NULL if clientData is

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

  *** 262,270 ****

        Colormap colormap;

        Visual *visual;


  !     if (argc < 2) {

  ! Tcl_AppendResult(interp, "wrong # args: should be \"",

  ! argv[0], " pathName ?options?\"", (char *) NULL);

    return TCL_ERROR;

        }


  --- 262,269 ----

        Colormap colormap;

        Visual *visual;


  !     if (objc < 2) {

  ! Tcl_WrongNumArgs(interp, 1, objv, "pathName ?options?");

    return TCL_ERROR;

        }


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

  *** 277,304 ****


        className = colormapName = screenName = visualName = useOption = NULL;

        colormap = None;

  !     for (i = 2; i < argc; i += 2) {

  ! arg = argv[i];

  ! length = strlen(arg);

    if (length < 2) {

        continue;

    }

    c = arg[1];

  ! if ((c == 'c') && (strncmp(arg, "-class", strlen(arg)) == 0)

    && (length >= 3)) {

  !     className = argv[i+1];

    } else if ((c == 'c')

  ! && (strncmp(arg, "-colormap", strlen(arg)) == 0)) {

  !     colormapName = argv[i+1];

    } else if ((c == 's') && toplevel

  ! && (strncmp(arg, "-screen", strlen(arg)) == 0)) {

  !     screenName = argv[i+1];

    } else if ((c == 'u') && toplevel

  ! && (strncmp(arg, "-use", strlen(arg)) == 0)) {

  !     useOption = argv[i+1];

    } else if ((c == 'v')

  ! && (strncmp(arg, "-visual", strlen(arg)) == 0)) {

  !     visualName = argv[i+1];

    }

        }


  --- 276,302 ----


        className = colormapName = screenName = visualName = useOption = NULL;

        colormap = None;

  !     for (i = 2; i < objc; i += 2) {

  ! arg = Tcl_GetStringFromObj(objv[i], &length);

    if (length < 2) {

        continue;

    }

    c = arg[1];

  ! if ((c == 'c') && (strncmp(arg, "-class", length) == 0)

    && (length >= 3)) {

  !     className = Tcl_GetString(objv[i+1]);

    } else if ((c == 'c')

  ! && (strncmp(arg, "-colormap", length) == 0)) {

  !     colormapName = Tcl_GetString(objv[i+1]);

    } else if ((c == 's') && toplevel

  ! && (strncmp(arg, "-screen", length) == 0)) {

  !     screenName = Tcl_GetString(objv[i+1]);

    } else if ((c == 'u') && toplevel

  ! && (strncmp(arg, "-use", length) == 0)) {

  !     useOption = Tcl_GetString(objv[i+1]);

    } else if ((c == 'v')

  ! && (strncmp(arg, "-visual", length) == 0)) {

  !     visualName = Tcl_GetString(objv[i+1]);

    }

        }


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

  *** 321,327 ****

    screenName = (toplevel) ? "" : NULL;

        }

        if (tkwin != NULL) {

  ! new = Tk_CreateWindowFromPath(interp, tkwin, argv[1], screenName);

        } else {

    /*

     * We were called from Tk_Init;  create a new application.

  --- 319,325 ----

    screenName = (toplevel) ? "" : NULL;

        }

        if (tkwin != NULL) {

  ! new = Tk_CreateWindowFromPath(interp, tkwin, Tcl_GetString(objv[1]), screenName);

        } else {

    /*

     * We were called from Tk_Init;  create a new application.

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

  *** 392,399 ****

        framePtr->tkwin = new;

        framePtr->display = Tk_Display(new);

        framePtr->interp = interp;

  !     framePtr->widgetCmd = Tcl_CreateCommand(interp,

  !     Tk_PathName(new), FrameWidgetCmd,

        (ClientData) framePtr, FrameCmdDeletedProc);

        framePtr->className = NULL;

        framePtr->mask = (toplevel) ? TOPLEVEL : FRAME;

  --- 390,397 ----

        framePtr->tkwin = new;

        framePtr->display = Tk_Display(new);

        framePtr->interp = interp;

  !     framePtr->widgetCmd = Tcl_CreateObjCommand(interp,

  !     Tk_PathName(new), FrameWidgetObjCmd,

        (ClientData) framePtr, FrameCmdDeletedProc);

        framePtr->className = NULL;

        framePtr->mask = (toplevel) ? TOPLEVEL : FRAME;

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

  *** 426,432 ****

            mask |= ActivateMask;

        }

        Tk_CreateEventHandler(new, mask, FrameEventProc, (ClientData) framePtr);

  !     if (ConfigureFrame(interp, framePtr, argc-2, argv+2, 0) != TCL_OK) {

    goto error;

        }

        if ((framePtr->isContainer)) {

  --- 424,430 ----

            mask |= ActivateMask;

        }

        Tk_CreateEventHandler(new, mask, FrameEventProc, (ClientData) framePtr);

  !     if (ConfigureFrame(interp, framePtr, objc-2, objv+2, 0) != TCL_OK) {

    goto error;

        }

        if ((framePtr->isContainer)) {

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

  *** 454,460 ****

    /*

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

     *

  !  * FrameWidgetCmd --

     *

     *This procedure is invoked to process the Tcl command

     *that corresponds to a frame widget.  See the user

  --- 452,458 ----

    /*

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

     *

  !  * FrameWidgetObjCmd --

     *

     *This procedure is invoked to process the Tcl command

     *that corresponds to a frame widget.  See the user

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

  *** 470,552 ****

     */


    static int

  ! FrameWidgetCmd(clientData, interp, argc, argv)

        ClientData clientData;/* Information about frame widget. */

        Tcl_Interp *interp;/* Current interpreter. */

  !     int argc;/* Number of arguments. */

  !     char **argv;/* Argument strings. */

    {

        register Frame *framePtr = (Frame *) clientData;

  !     int result;

        size_t length;

        int c, i;


  !     if (argc < 2) {

  ! Tcl_AppendResult(interp, "wrong # args: should be \"",

  ! argv[0], " option ?arg arg ...?\"", (char *) NULL);

    return TCL_ERROR;

        }

        Tcl_Preserve((ClientData) framePtr);

  !     c = argv[1][0];

  !     length = strlen(argv[1]);

  !     if ((c == 'c') && (strncmp(argv[1], "cget", length) == 0)

  !     && (length >= 2)) {

  ! if (argc != 3) {

  !     Tcl_AppendResult(interp, "wrong # args: should be \"",

  !     argv[0], " cget option\"",

  !     (char *) NULL);

        result = TCL_ERROR;

        goto done;

    }

    result = Tk_ConfigureValue(interp, framePtr->tkwin, configSpecs,

  ! (char *) framePtr, argv[2], framePtr->mask);

  !     } else if ((c == 'c') && (strncmp(argv[1], "configure", length) == 0)

  !     && (length >= 2)) {

  ! if (argc == 2) {

        result = Tk_ConfigureInfo(interp, framePtr->tkwin, configSpecs,

        (char *) framePtr, (char *) NULL, framePtr->mask);

  ! } else if (argc == 3) {

        result = Tk_ConfigureInfo(interp, framePtr->tkwin, configSpecs,

  !     (char *) framePtr, argv[2], framePtr->mask);

    } else {

        /*

         * Don't allow the options -class, -colormap, -container,

         * -newcmap, -screen, -use, or -visual to be changed.

         */


  !     for (i = 2; i < argc; i++) {

  ! length = strlen(argv[i]);

    if (length < 2) {

        continue;

    }

  ! c = argv[i][1];

  ! if (((c == 'c') && (strncmp(argv[i], "-class", length) == 0)

    && (length >= 2))

    || ((c == 'c') && (framePtr->mask == TOPLEVEL)

  ! && (strncmp(argv[i], "-colormap", length) == 0)

    && (length >= 3))

    || ((c == 'c')

  ! && (strncmp(argv[i], "-container", length) == 0)

    && (length >= 3))

    || ((c == 's') && (framePtr->mask == TOPLEVEL)

  ! && (strncmp(argv[i], "-screen", length) == 0))

    || ((c == 'u') && (framePtr->mask == TOPLEVEL)

  ! && (strncmp(argv[i], "-use", length) == 0))

    || ((c == 'v') && (framePtr->mask == TOPLEVEL)

  ! && (strncmp(argv[i], "-visual", length) == 0))) {

  !     Tcl_AppendResult(interp, "can't modify ", argv[i],

        " option after widget is created", (char *) NULL);

        result = TCL_ERROR;

        goto done;

    }

        }

  !     result = ConfigureFrame(interp, framePtr, argc-2, argv+2,

        TK_CONFIG_ARGV_ONLY);

    }

  !     } else {

  ! Tcl_AppendResult(interp, "bad option \"", argv[1],

  ! "\": must be cget or configure", (char *) NULL);

  ! result = TCL_ERROR;

        }


        done:

  --- 468,554 ----

     */


    static int

  ! FrameWidgetObjCmd(clientData, interp, objc, objv)

        ClientData clientData;/* Information about frame widget. */

        Tcl_Interp *interp;/* Current interpreter. */

  !     int objc;/* Number of arguments. */

  !     Tcl_Obj *CONST objv[];/* Argument objects. */

    {

  +     static char *frameOptions[] = {

  + "cget", "configure", (char *) NULL

  +     };

  +     enum options {

  + FRAME_CGET, FRAME_CONFIGURE

  +     };

        register Frame *framePtr = (Frame *) clientData;

  !     int result = TCL_OK, index;

        size_t length;

        int c, i;


  !     if (objc < 2) {

  ! Tcl_WrongNumArgs(interp, 1, objv, "option ?arg arg ...?");

  ! return TCL_ERROR;

  !     }

  !     if (Tcl_GetIndexFromObj(interp, objv[1], frameOptions, "option", 0,

  !     &index) != TCL_OK) {

    return TCL_ERROR;

        }

        Tcl_Preserve((ClientData) framePtr);

  !     switch ((enum options) index) {

  !       case FRAME_CGET: {

  ! if (objc != 3) {

  !     Tcl_WrongNumArgs(interp, 2, objv, "option");

        result = TCL_ERROR;

        goto done;

    }

    result = Tk_ConfigureValue(interp, framePtr->tkwin, configSpecs,

  ! (char *) framePtr, Tcl_GetString(objv[2]), framePtr->mask);

  ! break;

  !       }

  !       case FRAME_CONFIGURE: {

  ! if (objc == 2) {

        result = Tk_ConfigureInfo(interp, framePtr->tkwin, configSpecs,

        (char *) framePtr, (char *) NULL, framePtr->mask);

  ! } else if (objc == 3) {

        result = Tk_ConfigureInfo(interp, framePtr->tkwin, configSpecs,

  !     (char *) framePtr, Tcl_GetString(objv[2]), framePtr->mask);

    } else {

        /*

         * Don't allow the options -class, -colormap, -container,

         * -newcmap, -screen, -use, or -visual to be changed.

         */


  !     for (i = 2; i < objc; i++) {

  ! char *arg = Tcl_GetStringFromObj(objv[i], &length);

    if (length < 2) {

        continue;

    }

  ! c = arg[1];

  ! if (((c == 'c') && (strncmp(arg, "-class", length) == 0)

    && (length >= 2))

    || ((c == 'c') && (framePtr->mask == TOPLEVEL)

  ! && (strncmp(arg, "-colormap", length) == 0)

    && (length >= 3))

    || ((c == 'c')

  ! && (strncmp(arg, "-container", length) == 0)

    && (length >= 3))

    || ((c == 's') && (framePtr->mask == TOPLEVEL)

  ! && (strncmp(arg, "-screen", length) == 0))

    || ((c == 'u') && (framePtr->mask == TOPLEVEL)

  ! && (strncmp(arg, "-use", length) == 0))

    || ((c == 'v') && (framePtr->mask == TOPLEVEL)

  ! && (strncmp(arg, "-visual", length) == 0))) {

  !     Tcl_AppendResult(interp, "can't modify ", arg,

        " option after widget is created", (char *) NULL);

        result = TCL_ERROR;

        goto done;

    }

        }

  !     result = ConfigureFrame(interp, framePtr, objc-2, objv+2,

        TK_CONFIG_ARGV_ONLY);

    }

  ! break;

  !       }

        }


        done:

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

  *** 591,597 ****

     *

     * ConfigureFrame --

     *

  !  *This procedure is called to process an argv/argc list, plus

     *the Tk option database, in order to configure (or

     *reconfigure) a frame widget.

     *

  --- 593,599 ----

     *

     * ConfigureFrame --

     *

  !  *This procedure is called to process an objv/objc list, plus

     *the Tk option database, in order to configure (or

     *reconfigure) a frame widget.

     *

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

  *** 608,619 ****

     */


    static int

  ! ConfigureFrame(interp, framePtr, argc, argv, flags)

        Tcl_Interp *interp;/* Used for error reporting. */

        register Frame *framePtr;/* Information about widget;  may or may

     * not already have values for some fields. */

  !     int argc;/* Number of valid entries in argv. */

  !     char **argv;/* Arguments. */

        int flags;/* Flags to pass to Tk_ConfigureWidget. */

    {

        char *oldMenuName;

  --- 610,621 ----

     */


    static int

  ! ConfigureFrame(interp, framePtr, objc, objv, flags)

        Tcl_Interp *interp;/* Used for error reporting. */

        register Frame *framePtr;/* Information about widget;  may or may

     * not already have values for some fields. */

  !     int objc;/* Number of valid entries in objv. */

  !     Tcl_Obj *CONST objv[];/* Arguments. */

        int flags;/* Flags to pass to Tk_ConfigureWidget. */

    {

        char *oldMenuName;

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

  *** 630,636 ****

        }


        if (Tk_ConfigureWidget(interp, framePtr->tkwin, configSpecs,

  !     argc, argv, (char *) framePtr, flags | framePtr->mask) != TCL_OK) {

    return TCL_ERROR;

        }


  --- 632,639 ----

        }


        if (Tk_ConfigureWidget(interp, framePtr->tkwin, configSpecs,

  !     objc, (char **) objv, (char *) framePtr,

  !     flags | framePtr->mask | TK_CONFIG_OBJS) != TCL_OK) {

    return TCL_ERROR;

        }


  *** generic/tkInt.decls.origWed Jul  7 20:41:28 1999

  --- generic/tkInt.declsWed Jul  7 20:42:49 1999

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

  *** 86,92 ****


    declare 13 generic {

        int TkCreateFrame (ClientData clientData, \

  !     Tcl_Interp *interp, int argc, char **argv, \

        int toplevel, char *appName)

    }


  --- 86,92 ----


    declare 13 generic {

        int TkCreateFrame (ClientData clientData, \

  !     Tcl_Interp *interp, int objc, Tcl_Obj *CONST argv[], \

        int toplevel, char *appName)

    }


  *** generic/tkInt.h.origWed Jul  7 20:43:15 1999

  --- generic/tkInt.hWed Jul  7 20:44:25 1999

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

  *** 909,916 ****

        Tcl_Obj *CONST objv[]));

    EXTERN intTk_FileeventCmd _ANSI_ARGS_((ClientData clientData,

        Tcl_Interp *interp, int argc, char **argv));

  ! EXTERN intTk_FrameCmd _ANSI_ARGS_((ClientData clientData,

  !     Tcl_Interp *interp, int argc, char **argv));

    EXTERN intTk_FocusObjCmd _ANSI_ARGS_((ClientData clientData,

        Tcl_Interp *interp, int objc, 

        Tcl_Obj *CONST objv[]));

  --- 909,917 ----

        Tcl_Obj *CONST objv[]));

    EXTERN intTk_FileeventCmd _ANSI_ARGS_((ClientData clientData,

        Tcl_Interp *interp, int argc, char **argv));

  ! EXTERN intTk_FrameObjCmd _ANSI_ARGS_((ClientData clientData,

  !     Tcl_Interp *interp, int objc,

  !     Tcl_Obj *CONST objv[]));

    EXTERN intTk_FocusObjCmd _ANSI_ARGS_((ClientData clientData,

        Tcl_Interp *interp, int objc, 

        Tcl_Obj *CONST objv[]));

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

  *** 974,981 ****

        Tcl_Obj *CONST objv[]));

    EXTERN intTk_TkwaitCmd _ANSI_ARGS_((ClientData clientData,

        Tcl_Interp *interp, int argc, char **argv));

  ! EXTERN intTk_ToplevelCmd _ANSI_ARGS_((ClientData clientData,

  !     Tcl_Interp *interp, int argc, char **argv));

    EXTERN intTk_UpdateObjCmd _ANSI_ARGS_((ClientData clientData,

        Tcl_Interp *interp, int objc, 

        Tcl_Obj *CONST objv[]));

  --- 975,983 ----

        Tcl_Obj *CONST objv[]));

    EXTERN intTk_TkwaitCmd _ANSI_ARGS_((ClientData clientData,

        Tcl_Interp *interp, int argc, char **argv));

  ! EXTERN intTk_ToplevelObjCmd _ANSI_ARGS_((ClientData clientData,

  !     Tcl_Interp *interp, int objc,

  !     Tcl_Obj *CONST objv[]));

    EXTERN intTk_UpdateObjCmd _ANSI_ARGS_((ClientData clientData,

        Tcl_Interp *interp, int objc, 

        Tcl_Obj *CONST objv[]));

  *** generic/tkIntDecls.h.origWed Jul  7 20:41:56 1999

  --- generic/tkIntDecls.hWed Jul  7 20:57:04 1999

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

  *** 82,89 ****

    XColor bg));

    /* 13 */

    EXTERN intTkCreateFrame _ANSI_ARGS_((ClientData clientData, 

  ! Tcl_Interp * interp, int argc, char ** argv, 

  ! int toplevel, char * appName));

    /* 14 */

    EXTERN Tk_WindowTkCreateMainWindow _ANSI_ARGS_((Tcl_Interp * interp, 

    char * screenName, char * baseName));

  --- 82,90 ----

    XColor bg));

    /* 13 */

    EXTERN intTkCreateFrame _ANSI_ARGS_((ClientData clientData, 

  ! Tcl_Interp * interp, int objc, 

  ! Tcl_Obj *CONST argv[], int toplevel, 

  ! char * appName));

    /* 14 */

    EXTERN Tk_WindowTkCreateMainWindow _ANSI_ARGS_((Tcl_Interp * interp, 

    char * screenName, char * baseName));

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

  *** 517,523 ****

        int (*tkCopyAndGlobalEval) _ANSI_ARGS_((Tcl_Interp * interp, char * script)); /* 10 */

        unsigned long (*tkCreateBindingProcedure) _ANSI_ARGS_((Tcl_Interp * interp, Tk_BindingTable bindingTable, ClientData object, char * eventString, TkBindEvalProc * evalProc, TkBindFreeProc * freeProc, ClientData clientData)); /* 11 */

        TkCursor * (*tkCreateCursorFromData) _ANSI_ARGS_((Tk_Window tkwin, char * source, char * mask, int width, int height, int xHot, int yHot, XColor fg, XColor bg)); /* 12 */

  !     int (*tkCreateFrame) _ANSI_ARGS_((ClientData clientData, Tcl_Interp * interp, int argc, char ** argv, int toplevel, char * appName)); /* 13 */

        Tk_Window (*tkCreateMainWindow) _ANSI_ARGS_((Tcl_Interp * interp, char * screenName, char * baseName)); /* 14 */

        Time (*tkCurrentTime) _ANSI_ARGS_((TkDisplay * dispPtr)); /* 15 */

        void (*tkDeleteAllImages) _ANSI_ARGS_((TkMainInfo * mainPtr)); /* 16 */

  --- 518,524 ----

        int (*tkCopyAndGlobalEval) _ANSI_ARGS_((Tcl_Interp * interp, char * script)); /* 10 */

        unsigned long (*tkCreateBindingProcedure) _ANSI_ARGS_((Tcl_Interp * interp, Tk_BindingTable bindingTable, ClientData object, char * eventString, TkBindEvalProc * evalProc, TkBindFreeProc * freeProc, ClientData clientData)); /* 11 */

        TkCursor * (*tkCreateCursorFromData) _ANSI_ARGS_((Tk_Window tkwin, char * source, char * mask, int width, int height, int xHot, int yHot, XColor fg, XColor bg)); /* 12 */

  !     int (*tkCreateFrame) _ANSI_ARGS_((ClientData clientData, Tcl_Interp * interp, int objc, Tcl_Obj *CONST argv[], int toplevel, char * appName)); /* 13 */

        Tk_Window (*tkCreateMainWindow) _ANSI_ARGS_((Tcl_Interp * interp, char * screenName, char * baseName)); /* 14 */

        Time (*tkCurrentTime) _ANSI_ARGS_((TkDisplay * dispPtr)); /* 15 */

        void (*tkDeleteAllImages) _ANSI_ARGS_((TkMainInfo * mainPtr)); /* 16 */

  *** generic/tkWindow.c.origWed Jul  7 20:45:36 1999

  --- generic/tkWindow.cWed Jul  7 21:05:50 1999

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

  *** 137,143 ****

        {"canvas",Tk_CanvasCmd,NULL,1, 1},

        {"checkbutton",NULL,Tk_CheckbuttonObjCmd,1, 0},

        {"entry",NULL,                   Tk_EntryObjCmd,1, 0},

  !     {"frame",Tk_FrameCmd,NULL,1, 1},

        {"label",NULL,Tk_LabelObjCmd,1, 0},

        {"listbox",Tk_ListboxCmd,NULL,1, 1},

        {"menubutton",NULL,                   Tk_MenubuttonObjCmd,1, 0},

  --- 137,143 ----

        {"canvas",Tk_CanvasCmd,NULL,1, 1},

        {"checkbutton",NULL,Tk_CheckbuttonObjCmd,1, 0},

        {"entry",NULL,                   Tk_EntryObjCmd,1, 0},

  !     {"frame",NULL,Tk_FrameObjCmd,1, 1},

        {"label",NULL,Tk_LabelObjCmd,1, 0},

        {"listbox",Tk_ListboxCmd,NULL,1, 1},

        {"menubutton",NULL,                   Tk_MenubuttonObjCmd,1, 0},

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

  *** 146,152 ****

        {"scale",NULL,                Tk_ScaleObjCmd,1, 0},

        {"scrollbar",Tk_ScrollbarCmd,NULL,1, 1},

        {"text",Tk_TextCmd,NULL,1, 1},

  !     {"toplevel",Tk_ToplevelCmd,NULL,0, 1},


        /*

         * Misc.

  --- 146,152 ----

        {"scale",NULL,                Tk_ScaleObjCmd,1, 0},

        {"scrollbar",Tk_ScrollbarCmd,NULL,1, 1},

        {"text",Tk_TextCmd,NULL,1, 1},

  !     {"toplevel",NULL,Tk_ToplevelObjCmd,0, 1},


        /*

         * Misc.

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

  *** 2705,2711 ****

    {

        char *p;

        int argc, code;

  !     char **argv, *args[20];

        Tcl_DString class;

        ThreadSpecificData *tsdPtr;


  --- 2705,2712 ----

    {

        char *p;

        int argc, code;

  !     char **argv;

  !     Tcl_Obj *args[20];

        Tcl_DString class;

        ThreadSpecificData *tsdPtr;


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

  *** 2870,2883 ****

         * using the information parsed from argv, if any.

         */


  !     args[0] = "toplevel";

  !     args[1] = ".";

  !     args[2] = "-class";

  !     args[3] = Tcl_DStringValue(&class);

        argc = 4;

        if (display != NULL) {

  ! args[argc] = "-screen";

  ! args[argc+1] = display;

    argc += 2;


    /*

  --- 2871,2884 ----

         * using the information parsed from argv, if any.

         */


  !     args[0] = Tcl_NewStringObj("toplevel", -1);

  !     args[1] = Tcl_NewStringObj(".", -1);

  !     args[2] = Tcl_NewStringObj("-class", -1);

  !     args[3] = Tcl_NewStringObj(Tcl_DStringValue(&class), -1);

        argc = 4;

        if (display != NULL) {

  ! args[argc] = Tcl_NewStringObj("-screen", -1);

  ! args[argc+1] = Tcl_NewStringObj(display, -1);

    argc += 2;


    /*

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

  *** 2891,2910 ****

    }

        }

        if (colormap != NULL) {

  ! args[argc] = "-colormap";

  ! args[argc+1] = colormap;

    argc += 2;

            colormap = NULL;

        }

        if (use != NULL) {

  ! args[argc] = "-use";

  ! args[argc+1] = use;

    argc += 2;

            use = NULL;

        }

        if (visual != NULL) {

  ! args[argc] = "-visual";

  ! args[argc+1] = visual;

    argc += 2;

            visual = NULL;

        }

  --- 2892,2911 ----

    }

        }

        if (colormap != NULL) {

  ! args[argc] = Tcl_NewStringObj("-colormap", -1);

  ! args[argc+1] = Tcl_NewStringObj(colormap, -1);

    argc += 2;

            colormap = NULL;

        }

        if (use != NULL) {

  ! args[argc] = Tcl_NewStringObj("-use", -1);

  ! args[argc+1] = Tcl_NewStringObj(use, -1);

    argc += 2;

            use = NULL;

        }

        if (visual != NULL) {

  ! args[argc] = Tcl_NewStringObj("-visual", -1);

  ! args[argc+1] = Tcl_NewStringObj(visual, -1);

    argc += 2;

            visual = NULL;

        }

  *** doc/ConfigWidg.3.origWed Jul  7 20:04:18 1999

  --- doc/ConfigWidg.3Wed Jul  7 20:06:57 1999

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

  *** 51,56 ****

  --- 51,58 ----

    TK_CONFIG_ARGV_ONLY causes the option database and defaults to be

    ignored, and flag bits TK_CONFIG_USER_BIT and higher are used to

    selectively disable entries in \fIspecs\fR.

  + TK_CONFIG_OBJS causes the argv argument to be threated

  + as Tcl_Obj's in stead of strings.

    .AP "type name" type in

    The name of the type of a widget record.

    .AP "field name" field in


  PatchFiles:

  tk.h tkOldConfig.c tkFrame.c tkInt.decls tkInt.h tkIntDecls.h tkWindow.c

      ConfigWidg.3




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


tkt_uuid: 1457279fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.12
resolution: None
title: w32: Creating Alt-Key binding on all breaks default handling
comment:
  If a binding for <Alt-Key> is created or added on the
  'all' tag, normal handling of special keystrokes (e.g.,
  Alt-F4) no longer works.

  How to reproduce:
  1. Invoke wish84.exe
  2. execute one of the following commands:
       bind all <Alt-Key> [bind all <Alt-Key>];
       bind all <Alt-Key> {+puts example};
       bind all <Alt-Key> {puts example};
  (any command that modifies the binding of <Alt-Key> on
  the 'all' tag, even ones that should leave any existing
  binding still in effect)
  3. Focus the main window and press Alt-F4.

  Expected behavior: The window closes
  Actual behavior: the window does not close.

  This problem exists in ActiveState ActiveTcl 8.4.12.0
  as well as a self-compiled version of tk 8.4.10. 
  Tested on a Windows XP SP2 machine.

  The problem apparently arises because bindings created
  by TkCreateBindingProcedure do not behave like normal
  bindings, acting instead like empty bindings when
  queried or modified by the [bind] command.


tkt_uuid: 636562ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: Rejected
title: OSX: No Drag&Drop in Wish Shell
comment:
  When no source file is loaded, the Wish shell accepts drag&drop 
  of tcl files. However, they don't get executed (which would be the 
  obvious behavior).

  Similarly, starting the Wish shell with an tcl file as argument 
  should immediately execute the program. Using a runtime binary, 
  the user  shouldn't be bothered with yet another file selector to 
  load a tcl source file. Instead, double-clicking on the tcl 
  application should start it right away (as in the Windows port). The 
  installer should create the right file association.


tkt_uuid: 220429ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Windows menu separators do not reflect the menu background color
comment:
  OriginalBugID: 1166 Bug
  Version: 8.0.4
  SubmitDate: '1999-02-04'
  LastModified: '2000-04-13'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: ericm
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-04-13'
  FixedInVersion: 8.3.1


  Sample script:

  menu .m -bg blue
  .m add separator
  .m add command -label foobar
  .m post 0 0

  Note that the tearoff and command label are in blue, but the separator is still in the system background color.



  Verified with 8.2 on NT for both old and new style menus. 
  -- 10/22/1999 hobbs

  The problem was that we were letting the system draw the separator entries on the menus, rather than drawing it ourselves (as we do for every other kind of menu item).  Thus the separator was being drawn with the system background color rather than with the widget background.  Oddly, the code to draw the separator ourselves was already there, but due to the way we were creating the menu item on windows, it was never being used.  I corrected this and the problem is now fixed.  This fix will go out with 8.3.1.

  - eric

  -- 04/13/2000 ericm


tkt_uuid: 220488ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: summary of test suite failures
comment:
  OriginalBugID: 1770 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-09'
  LastModified: '1999-04-21'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hershey
  RelatedBugIDs: 1769
  OS: Other
  OSVersion: Red Hat Linux 5.x on Alpha XL 300; fvwm2
  Machine: NA
  FixedDate: '1999-04-16'
  FixedInVersion: 8.1


  Name: Don Porter



  CustomShell: The patch to tkScale.c submitted earlier



  Comments: fvwm2 manages a desktop four times as big as the screen.

      I start the test suite in the NW screen of the desktop.

      As the test suite runs, the test windows move up and to

      the left beyond the corner of the screen (should they do

      that?).  When test pack-18.1 iconifies and de-iconifies

      the window .pack, it re-appears in the SE screen of

      the desktop, and the monitor is switched to view that

      screen.  Something about the shift in the screen being

      displayed on the monitor causes the errors in scale-15.5

      and scale-15.6 above.  The patch adjusts the position

      of .pack before test pack-18.1 to avoid the screen switch

      so all tests take place on one screen.  This makes the

      errors scale-15.5 and scale-15.6 go away and it makes

      the errors pack-18.1 and pack 18.2 go away in the 

      interactive testing.  No, I don't understand why the

      pack-* errors occur in interactive testing but not in

      'make test'.

      

      If I interactively select a different screen of the 

      desktop for display as the test suite runs, so that

      . and the other toplevel windows end up on different

      screens, some more errors occur, some apparently

      related to whether or not commands associated with

      widgets get evaluated:

      ==== entry-5.7 ConfigureEntry procedure FAILED

      ==== Test generated error:

      can't read "scrollInfo": no such variable

      ---- Result should have been:

      0 0.363636

      ==== entry-5.7 FAILED

      

      ==== entry-7.1 InsertChars procedure FAILED

      ==== Test generated error:

      can't read "scrollInfo": no such variable

      ---- Result should have been:

      abXXXcde abXXXcde {0 1}

      ==== entry-7.1 FAILED

      

      ==== entry-17.4 EntryUpdateScrollbar procedure FAILED

      ---- Result was:

      {This is line 1, out of 500

      This is line 2, out of 500

      ...

      This is line 500, out of 500

      } {bad entry index "1xyz"

          while executing

      ".e index 1xyz"}

      ---- Result should have been:

      {invalid command name "bogus"} {invalid command name "bogus"

          while executing

      "bogus 0 1"

          (horizontal scrolling command executed by entry)}

      ==== entry-17.4 FAILED

      

      ==== image-10.1 Tk_FreeImage procedure FAILED

      ---- Result was:

      foo {{foo free}}

      ---- Result should have been:

      foo {{foo free} {foo display 0 0 30 15 103 121}}

      ==== image-10.1 FAILED

      

      The remaining errors (menubutton-*, scale-7*,

      unixEmbed-3.1) I have no explanation for.

      

      The patch includes a fix for a rather obvious

      typo in tests/all.tcl .



  ObservedBehavior:

  $ cd tk8.1b3/unix

      $ ./configure --enable-gcc

      $ make all test

      ...

      ==== menubutton-4.5 ConfigureMenuButton procedure FAILED

      ---- Result was:

      98 44 20 12

      ---- Result should have been:

      102 46 20 12

      ==== menubutton-4.5 FAILED

      

      ==== menubutton-7.13 ComputeMenuButtonGeometry procedure FAILED

      ---- Result was:

      71 26

      ---- Result should have been:

      78 28

      ==== menubutton-7.13 FAILED

      ...

      ==== scale-7.1 ComputeScaleGeometry procedure FAILED

      ---- Result was:

      88 383

      ---- Result should have been:

      88 458

      ==== scale-7.1 FAILED

      

      ==== scale-7.5 ComputeScaleGeometry procedure FAILED

      ---- Result was:

      383 61

      ---- Result should have been:

      458 61

      ==== scale-7.5 FAILED

      

      ==== scale-15.5 ScaleVarProc procedure, variable deleted FAILED

      ---- Result was:

      0 6 6 6

      ---- Result should have been:

      0 6 6 untouched

      ==== scale-15.5 FAILED

      

      ==== scale-15.6 ScaleVarProc procedure, don't call -command FAILED

      ==== Contents of test case:

      ---- Result was:

      60 60

      ---- Result should have been:

      untouched 60

      ==== scale-15.6 FAILED

      ...

      ==== unixEmbed-3.1 ContainerEventProc procedure, detect creation FAILED

      ---- Result was:

      {{XXX .f1 {} {}}} {{XXX .f1 {} {}}}

      ---- Result should have been:

      {{XXX .f1 {} {}}} {{XXX .f1 XXX {}}}

      ==== unixEmbed-3.1 FAILED

      

      Also:

      $ make runtest

      % source ./../tests/pack.test

      

      ==== pack-18.1 unmap slaves when master unmapped FAILED

      ---- Result was:

      1 0 100 50 0 1

      ---- Result should have been:

      1 0 200 75 0 1

      ==== pack-18.1 FAILED

      

      ==== pack-18.2 unmap slaves when master unmapped FAILED

      ---- Result was:

      1 0 70 30 0 1

      ---- Result should have been:

      1 0 100 30 0 1

      ==== pack-18.2 FAILED



  DesiredBehavior:

  all tests pass



  Patch:

  Index: all.tcl

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

  RCS file: /cvsroot/tk/tests/Attic/all.tcl,v

  retrieving revision 1.1.2.6

  diff -c -r1.1.2.6 all.tcl

  *** all.tcl     1999/04/07 01:59:48     1.1.2.6

  --- all.tcl     1999/04/09 05:33:51

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

  *** 9,15 ****

    #

    # RCS: @(#) $Id: all.tcl,v 1.1.2.6 1999/04/07 01:59:48 hershey Exp $



  ! if {[lsearch ::tcltest [namespace children]] == -1} {

        source [file join [pwd] [file dirname [info script]] defs.tcl]

    }

    set ::tcltest::testSingleFile false

  --- 9,15 ----

    #

    # RCS: @(#) $Id: all.tcl,v 1.1.2.6 1999/04/07 01:59:48 hershey Exp $



  ! if {[lsearch [namespace children] ::tcltest] == -1} {

        source [file join [pwd] [file dirname [info script]] defs.tcl]

    }

    set ::tcltest::testSingleFile false

  Index: pack.test

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

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

  retrieving revision 1.1.4.4

  diff -c -r1.1.4.4 pack.test

  *** pack.test   1999/03/24 02:54:56     1.1.4.4

  --- pack.test   1999/04/09 05:33:52

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

  *** 923,928 ****

  --- 923,929 ----

          [catch {pack info .pack.a} msg] $msg

    } {place 20x40+40+10 1 {window ".pack.a" isn't packed}}



  + wm geometry .pack +100+100

    test pack-18.1 {unmap slaves when master unmapped} {tempNotPc} {

        # On the PC, when the width/height is configured while the window is

        # unmapped, the changes don't take effect until the window is remapped.



  PatchFiles:

  all.tcl

      pack.test





  I applied the patch.  I made the all.tcl change in Tcl8.1 as well as
  Tk8.1.  The pack.test change was added inside each pack-18.* test.

  I didn't do any work on the tests that failed as a result
  interactively selecting different screens.  It would be nice if such
  interactive changes will did not have ill consequense, but that's a
  rather high expectation.

  I marked the scale-7.*, menubutton, and unixEmbed tests nonPortable.
  I couldn't reproduce the scale-15.* failures. I suspect they are the fault
  of the window manager triggering too many events.
  -hershey


tkt_uuid: 3550691fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: None
title: Default font settings don't work well with high DPI
comment:
  Hi!

  As far as I can see the default font sizes on Unix are specified in pixels:

  % font configure TkDefaultFont
  -family sans-serif -size -12 -weight normal -slant roman -underline 0 -overstrike 0

  As a result, they look too small on a high resolution screen (tried on a laptop with 165DPI display).


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

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

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

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

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


tkt_uuid: 3598664fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: OS X: libtk8.6.dylib install_name invalid path in unix build
comment:
  When using the "unix" build (ie, X11, rather than Quartz) on OS X, at least when building with MacPorts, the configure script and Makefile supplied with 8.6.0 results in stamping an invalid search-path like path name for libtk8.6.dylib into the dynamic library as the "install_name" (ie, canonical pathname for the library), which then gets copied into the wish8.6 executable as the location from which to load the library.  Since the search-path style string is not a valid file pathname, the library can't be found and hence the wish8.6 executable cannot be loaded.  This behaviour seems to be new since 8.5.13, although the underlying cause may have been there for quite some time.

  Symptoms:

  When trying to run something that uses wish:

  dyld: Library not loaded: /opt/local/lib:/opt/local/lib/libtk8.6.dylib
    Referenced from: /opt/local/bin/wish
    Reason: image not found

  and inside the files:

  ewen@bethel:~$ otool -D /opt/local/lib/libtk8.6.dylib
  /opt/local/lib/libtk8.6.dylib:
  /opt/local/lib:/opt/local/lib/libtk8.6.dylib
  ewen@bethel:~$

  ewen@bethel:~$ otool -L /opt/local/bin/wish8.6 | grep libtk
          /opt/local/lib:/opt/local/lib/libtk8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
  ewen@bethel:~$

  Based on the MacPorts trouble ticket investigation:

  https://trac.macports.org/ticket/37395

  the fundamental problem is that DYLIB_INSTALL_DIR is used directly as part of the "install_name" for the OS X dylib, but the supplied Makefile.in copies that directly from LIB_RUNTIME_DIR which the configure script (now?) assembles into a library search path.  (It seems to me that LIB_RUNTIME_DIR is misnamed, if it is being treated as a RPATH-style search path.)  The most immediate trigger seems to be adding the X11 library location to the existing LIB_RUNTIME_DIR path (containing ${libdir}), but I'm not sure if that's new in the tk configure script or just being triggered now.

  The easiest work around, proven to work in MacPorts, is to set DYLIB_INSTALL_DIR from ${libdir} instead of from ${LIB_RUNTIME_DIR}:

  -DYLIB_INSTALL_DIR       = ${LIB_RUNTIME_DIR} 
  +DYLIB_INSTALL_DIR       = $(libdir) 

  (see patch being carried by Macports: https://trac.macports.org/browser/trunk/dports/x11/tk/files/patch-unix-Makefile.in.diff?rev=100816)

  Ewen

  PS: I'm not sure if this is "Mac OS X Build" or the "Unix Build", since it is the legacy unix/X11 handling on OS X which has the problem not the new Quartz handling.  But OS X is the only platform I'm aware of that uses this "install_name" canonical path stamping approach, so I went with that.  Feel free to change as appropriate.


tkt_uuid: 220864ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 49. [grid]
priority: 5 Medium
foundin: None
resolution: None
title: grid configure not consistent with other configure subcomman
comment:
  OriginalBugID: 2705 RFE
  Version: 8.2
  SubmitDate: '1999-09-10'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: Other
  Machine: NA


  Name:
  Clif Flynt

  Comments:
  One of the reasons I advocate Tcl over Perl is Tcl's internal
      consistency.   It irks me when I have
      to go back to the man pages because a sub-command has slightly different
      syntax for one command
      compared to another.

  DesiredBehavior:
  The "grid configure" command should use arguments consistent with the
      widget configure commands.
      "grid configure master" should  return a list of configuration options
      (be synonymous with the
      current "grid info", and "grid configure master -flag" should return the
      current value for that
      flag


tkt_uuid: 1489031fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Duplicate
title: tearoff submenus unresponsive
comment:
  On Windows (only), if you tearoff a menu that has one or more submenus, 
  using one of the submenus works normally the first time, but then after 
  that you can't raise the submenu again without first accessing some 
  _other_ item or submenu of the torn-off menu.

  The attached wish script demonstrates the problem:

  1) tear off the Edit menu
  2) access the Menu1 submenu, either by raising and dismissing it or by 
  raising it and choosing Command1
  3) you cannot reraise Menu1 without first accessing Menu2


tkt_uuid: 3039337fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Invalid
title: Test Suite isn't work correctly
comment:
  I try to porting tcl/tk on z/OS. And when I truy to run 'make test' for tk then I get next error message

  LD_LIBRARY_PATH="`pwd`:/u/pdmosk/local/lib:${LD_LIBRARY_PATH}"; export LD_LIBRARY_PATH; TCL_LIBRARY=/u/pdmosk/tcl8-5-8/library; export TCL_LIBRARY; TK_LIBRARY=/u/pdmosk/tk8-5-8/library; export TK_LIBRARY; ./tktest /u/pdmosk/tk8-5-8/unix/../tests/all.tcl -geometry +0+0
  Tests running in interp:  /u/pdmosk/tk8-5-8/unix/tktest
  Tests located in:  /u/pdmosk/tk8-5-8/tests
  Tests running in:  /u/pdmosk/tk8-5-8/unix
  Temporary files stored in /u/pdmosk/tk8-5-8/unix
  Test files sourced into current interpreter
  Running tests that match:  *
  Skipping test files that match:  l.*.test
  Only running test files that match:  *.test
  Tests began at Wed Aug 04 06:09:03 EDT 2010
  bell.test
  EZYXW10E X Error of failed request:  BadName (named color or font does
  not exist)
    Major opcode of failed request:  45 (X_OpenFont)
    Serial number of failed request:  65
    Current serial number in output stream:  67
  gmake: *** [test-classic] Error 1

  What is it may be? someone faced with this? 
  PS Sorry for my broken english ))


tkt_uuid: 2967911fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: [wm forget] fails when main window is iconified
comment:
  After the following commands, the .f widget hierarchy seems to be lost. It cannot be recovered.

  pack [frame .f]
  pack [text .f.t]
  wm manage .f
  wm iconify .
  update
  wm forget .f
  wm deiconify .
  pack .f

  This problem seems to have been introduced by fixing bug 2009788.


tkt_uuid: 1591491fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: textDisp test case failure on cvs head
comment:
  solaris 2.9 sun c compiler build of tk 8.5 cvs head;
  test suite displayed via exceed 10.0.0.12 on a win xp
  system.

  textDisp.test

  ==== textDisp-27.7 SizeOfTab procedure, center
  alignment, wrap -none (potential 
  numerical problems) FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      set cm [winfo fpixels .t 1c]
      .t configure -tabs {1c 2c center 3c 4c 5c 6c 7c 8c}
  -wrap none -width 40
      .t insert 1.0
  a\tb\tc\td\te\n012345678934567890a\tbb\tcc\tdd
      set width [expr {$fixedWidth * 19}]
      set tab $cm
      while {$tab < $width} {
          set tab [expr {$tab + $cm}]
      }
      # Now we've calculated to the end of the tab after
  'a', add one
      # more for 'bb\t' and we're there, with 4 for the
  border.  Since
      # Tk_GetPixelsFromObj uses the standard 'int(0.5 +
  float)' rounding,
      # so must we.
      set tab [expr {4 + int(0.5 + $tab + $cm)}]
      update
      set res [.t bbox 2.23]
      lset res 0 [expr {[lindex $res 0] - $tab}]
      set res

  ---- Result was:
  -36 18 7 13
  ---- Result should have been (exact matching):
  -28 18 7 13
  ==== textDisp-27.7 FAILED


tkt_uuid: 220156ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: menubutton inconsistency betw. win95 & win98
comment:
  OriginalBugID: 1661 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-29'
  LastModified: '2000-04-03'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  OS: Other
  OSVersion: Windows 95 & Windows 98 (see above)
  Machine: NA
  ClosedDate: '2000-04-03'


  Name:
  Jeff Gosnell

  Extensions:
  none that apply

  CustomShell:
  none

  ReproducibleScript:
      Under Windows 95 the following commands produces a very long menubutton
      list, which options disappear below the visible window.
      Under Windows 98 the following commands produces a very long menubutton
      list, the difference being there is an arrow at the top and bottom of
      the list for easy scrolling through the options (very nice I like)
      
         frame .route.stop
         label .route.stop.lbl -text "Choose a Stop" -font {-family "Times New
      Roman" -size 12}
         menubutton .route.stop.mb -textvariable stop -menu
      .route.stop.mb.menu -width 30 -relief raised -activebackground #00ffff
      -bg #00ccff
         set m [menu .route.stop.mb.menu -tearoff 0]
         foreach item [lsort $customer(list)] {
            if {$item == ""} {continue}
            $m add radio -label "$item" -variable stop -value "$item" 
         }
         pack .route.stop.lbl .route.stop.mb -side top
         pack .route.stop -expand 1
      
      



  ObservedBehavior:
      The work around for Windows 95 is the following (note the use of column
      break).  It's not as pretty as the Windows 98 arrows, but it works in 95
      (using columnbreak in Windows 98 does NOT work, it produces no options
      window)
      
         frame .route.stop
         label .route.stop.lbl -text "Choose a Stop" -font {-family "Times New
      Roman" -size 12}
         menubutton .route.stop.mb -textvariable stop -menu
      .route.stop.mb.menu -width 30 -relief raised -activebackground #00ffff
      -bg #00ccff
         set m [menu .route.stop.mb.menu -tearoff 0]
         set ctr 0
         foreach item [lsort $customer(list)] {
            if {$item == ""} {continue}
            $m add radio -label "$item" -variable stop -value "$item" 
            incr ctr
            if {$ctr == 30} {
               $m add command -columnbreak 1
               set ctr 0
            }
         }
         pack .route.stop.lbl .route.stop.mb -side top
         pack .route.stop -expand 1
      
      





      I posted this as a question on c.l.t.  I have recieved one answer and he
      suggested to post this as a bug on this site.  I have included his
      response just in case you might find it relevant.

      I guess the Windows 98 behavior is due to some changes in its code and
      is valid for all the applications. The problem you describe could be a
      bug in Tcl on Windows 98 (in that case you should submit it to
      Scriptics). In the meantime, your solution seems to be an acceptable
      workaround. Let me suggest you add OS detection so that you can activate
      columnbreak under Windows 95 but not Windows 98. To do so, you can use
      the variables tcl_platform(os) and tcl_platform(osVersion). If the
      former is "Windows 95" and the later is less than 4.10 then you are
      under Windows 95, else you are under 98 or later. I think you'll also
      have to test your code on NT 4 and 5 to see if you get the same
      difference.

      See you, Fred
      -- 
      Frédéric BONNET                        frederic.bonnet@ciril.fr
      ---------------------------------------------------------------
      "Theory may inform, but Practice convinces"
                                                          George Bain

  --

  Windows 98 added this ability to its menus.  We use native menus on Windows, so we are at the mercy of the OS when it comes to how the menus are drawn.  Menus in Windows 95 simply do not have this feature, so we cannot do anything about it.

  You might consider using a combobox widget (there are several available as megawidgets, and we will have one in Tcl/Tk 8.4), otherwise -columnbreak is your best bet.

  - eric

  -- 04/03/2000 ericm


tkt_uuid: 1753929fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Wont Fix
title: menu without entries
comment:
  with
  set ::tk::mac::useCustomMDEF 0
  it is possible to create menus without entries in the mac menu bar.

  this can be used to display some application state (or a digital clock...) in the menubar.

  with
  set ::tk::mac::useCustomMDEF 1
  this is no longer possible.

  please re-enable the original behaviour.

  kind regards,
  uwe


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

  I have found this bug in all versions of Tcl/Tk from at least 8.4.12 to the current 8.5.0.


tkt_uuid: 220735ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: Bug with Motif tk_getOpenFile and spaces in directory
comment:
  OriginalBugID: 5398 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-09'
  LastModified: '2000-06-26'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Unix
  FixedDate: '2000-06-26'
  FixedInVersion: 8.4a2


  Name:

  James Bonfield



  Comments:

  I have not checked for the same problem in tkfbox.tcl



  ReproducibleScript:

  set tk_strictMotif 1

  file mkdir "space dir"

  cd "space dir"

  puts [tk_getOpenFile -initialdir [pwd]]



  ObservedBehavior:

  The above script produces an error due to the space in the initialdir setting.



  Patch:

  *** orig/xmfbox.tcl     Tue May  9 11:44:43 2000

  --- ./xmfbox.tcl        Tue May  9 11:47:29 2000

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

  *** 170,176 ****

        #

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

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

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

          } else {

              set data(selectPath) [pwd]

          }

  --- 170,176 ----

        #

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

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

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

          } else {

              set data(selectPath) [pwd]

          }

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

  *** 692,698 ****

        }

    

        if {[file isdirectory $selectFilePath]} {

  !       set data(selectPath) [glob $selectFilePath]

          set data(selectFile) ""

          tkMotifFDialog_Update $w

          return

  --- 692,698 ----

        }

    

        if {[file isdirectory $selectFilePath]} {

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

          set data(selectFile) ""

          tkMotifFDialog_Update $w

          return



  PatchFiles:

  xmfbox.tcl





  This fix went in along with a larger patch from another user.  The fix will go out with Tcl/Tk 8.4a2.

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

  -- 06/26/2000 ericm


tkt_uuid: 857158ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 26. Conversions from String
priority: 5 Medium
foundin: obsolete: 8.4.5.1
resolution: Fixed
title: GetUid.3 glitch
comment:
  Eric Raymond reports a glitch
  in GetUid.3 at

  http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/1911201


tkt_uuid: 482139ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Out of Date
title: MacOS: menus broken in some cases
comment:
  The provided script shows an error case of menu display
  on Mac platforms.  The script needs BWidget (actually,
  the BWidget MainFrame).

  Observed on: Tcl/Tk 8.3.3, MacOS 9.1

  Observed behaviour : The menu entries do not get drawn
  correctly, they are misplaced. Additionally, the Mac
  *system* menu is also broken (misplaced). See the
  comments in the script for more detail.

  Bastien


tkt_uuid: 220825ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: None
title: add function to tkCanvas.c to export Tk_GetCanvasBackground
comment:
  OriginalBugID: 566 RFE
  Version: 8.1a2
  SubmitDate: '1998-04-15'
  LastModified: '1998-04-15'
  Severity: LOW
  Status: UnAssn
  Submitter: hershey
  ChangedBy: hershey
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


  >Date: Sun, 1 Feb 1998 11:42:41 -0800 (PST)
  >From: "Munagala V. S. Ramanath" <ram@netcom.com>
  >To: ouster@best.com
  >Subject: Tk8.1 request
  >X-Mozilla-Status: 8003
  >
  >Hi,
  >
  >Had a couple of requests for 8.1:
  >
  >1. Could you add the following function to tkCanvas.c and export the
  >   declaration in tk.h:
  >------------------------------------------------------------------------
  >XColor *Tk_GetCanvasBackground( Tk_Canvas canvas )
  >{
  >    return ((TkBorder *)(((TkCanvas *)canvas)->bgBorder))->bgColorPtr ;
  >}
  >------------------------------------------------------------------------
  >    I am implementing a new canvas item and need the RGB values of the
  >    canvas background to do anti-aliasing but saw no easy and portable
  >    way to get it using the currently exported interface. For example,
  >    I can get the actual background pixel with:
  >        Tk_Attributes(tkwin)->background_pixel
  >    but mapping this back to an XColor needs XQueryColor which is
  >    missing from the X emulation. Tk_ConfigureInfo is not usable since
  >    configSpecs[] is private to tkCanvas.c. Another way is to get the
  >    _name_ of the background color with a Tcl_Eval on something like
  >        "lindex [%s configure -bg] end"
  >    where the %s is replaced by the output of Tk_PathName( tkwin ) and
  >    then use Tk_GetColor to retrieve the XColor from the name which is
  >    very tortured and inefficient.
  >
  2. Is there any reason TkPutImage() cannot be exported ? I'd like to
  >   use this call to display images in a portable way.
  >
  >Thanks.
  >
  >Ram


tkt_uuid: 219918ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Duplicate
title: need support for Japanese text in the postscript template
comment:
  OriginalBugID: 1215 Bug
  Version: 8.1b2
  SubmitDate: '1999-02-16'
  LastModified: '2000-01-07'
  Severity: SER
  Status: Closed
  Submitter: admin
  ChangedBy: hobbs
  RelatedBugIDs: 2596
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '2000-01-07'


  I use Tcl/Tk8.1b1 on WindowsNT4.0.
  I have a question of canvas widget.

  If canvas which placed the Japanese text is output to PostScript, the
  Japanese character will transform itself.  Is there solution?.


  pack [canvas .can]
  .can create $x $y -text {Japanese Character} -font {Japanese Font}
  .can postscript -file foo.ps
  --
  Satoshi Imai
  2nd systems Department
  MicroComputer Division System LSI Operations Unit
  NEC Corporation
  E-mail: s-imai@lsi.nec.co.jp


tkt_uuid: 1019024fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: Tests can't find tk.tcl
comment:
  Tk: v8.5a2 HEAD at 30-08-04
  OS: WinXPsp1
  Built with makefile.vc using VC7

  When running the tests for Tk, from makefile.vc, 
  Wish85.exe fails to load due to it being unable to find 
  tk.tcl.

  This seems to be due to the changes to the search 
  paths in auto.tcl on 23-08-04.

  The attached patch adds the missing path to the tk 
  library into makefile.vc using the same format as was 
  used for the tcl library.

  Error displayed...
  error dialog
  title =Error in Wish
  text =Can't find a usable tk.tcl in the 
  following directories:
  D:/src_tcl/library/tk8.5
  D:/src_tcl/tk8.5
  D:/src_tk/win/lib/tk8.5
  D:/src_tk/lib/tk8.5
  D:/src_tk/win/library
  This problem means that tk wasn't 
  installed properly.

  Also included check for old 'MSVCDIR' as per tcl 
  makefile.vc.


tkt_uuid: 1525905fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Duplicate
title: binding Alt/Meta and mouse button does not work
comment:
  Binding Alt/Meta and mouse button does not work.
  How to reproduce:
  Start wish.
  Enter to the console:
  >bind . <Meta-ButtonPress-1> {puts here}
  Now go to the . window, press and hold the Meta key (on my
  system it is labelled Alt, as can be found out using a puts %K
  binding to <KeyPress>) and press/release mouse button 1.
  Nothing happens, but I expected the binding to fire.
  Bindings with Alt (Apple key) also do not work.
  Bindings with Shift and Control do work fine.

  best regards,
  Randolf,
  -- 
  http://www.ayam3d.org/    Ayam, two clicks surface of revolution.


tkt_uuid: 220842ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 6
foundin: obsolete: 8.3
resolution: Out of Date
title: Tk_InitStubs not usable with C++
comment:
  OriginalBugID: 2078 Bug
  Version: 8.1
  SubmitDate: '1999-05-17'
  LastModified: '2000-01-25'
  Severity: LOW
  Status: UnAssn
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1842
  OS: Windows NT
  OSVersion: 4.0 SP3
  Machine: X86


  Name:
  Jan Nijtmans

  ReproducibleScript:
  When compiling a Tk-extension using C++, inclusion of tk.h means
      that the name of the Tk_InitStubs() function is mangled. This
      makes tkstub81.lib unusable for C++ extensions, unless it is
      recompiled using a C++ compiler.

  DesiredBehavior:
  C++ extension using tk.h can link libtkstub8.1.a with
      their extension, without the need to recompile it
      using a C++ compiler.

      Much better would be to use the EXTERN macro
      in tk.h. Unfortunately this has the side-effect of
      using __decl on Windows, which can be switched off
      by undefining TCL_STORAGE_CLASS. This - in turn -
      has the undesired side-effect that all function
      declarations in tclDecls.h are affected, which
      can prevented by moving this code to the end
      of tk.h.

  Patch:
  *** generic/tk.h.origThu Apr 29 21:37:46 1999
  --- generic/tk.hSat May 15 08:44:18 1999
  ***************
  *** 1159,1173 ****
    #define Tk_Main(argc, argv, proc)  Tk_MainEx(argc, argv, proc, Tcl_CreateInterp())

  - char *Tk_InitStubs _ANSI_ARGS_((Tcl_Interp *interp, char *version, int exact));
  - 
  - #ifndef USE_TK_STUBS
  - 
  - #define Tk_InitStubs(interp, version, exact)  -     Tcl_PkgRequire(interp, "Tk", version, exact)
  - 
  - #endif
  - 
    
    /*
     *--------------------------------------------------------------
  --- 1159,1164 ----
  ***************
  *** 1200,1205 ****
  --- 1191,1214 ----
     */

    #include "tkDecls.h"
  + 
  + /*
  +  * Convenience declaration of Tk_InitStubs.
  +  * This function is not *implemented* by the tcl library, so the storage
  +  * class is neither DLLEXPORT nor DLLIMPORT
  +  */
  + 
  + #undef TCL_STORAGE_CLASS
  + #define TCL_STORAGE_CLASS
  + 
  + EXTERN char *Tk_InitStubs _ANSI_ARGS_((Tcl_Interp *interp, char *version, int exact));
  + 
  + #ifndef USE_TK_STUBS
  + 
  + #define Tk_InitStubs(interp, version, exact)  +     Tcl_PkgRequire(interp, "Tk", version, exact)
  + 
  + #endif

    /*
     * Tcl commands exported by Tk:

  PatchFiles:
  tk.h



  1842 has older version of same idea. 
  -- 01/25/2000 hobbs


tkt_uuid: 1982392fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Invalid
title: 8.5.2 compiles work, but wish fails
comment:
  I've done multiple 32-bit and 64-bit X11 compiles on our Mac hardware in the past without issue, but when I compile 8.5.2 the compile appears to work but wish crashes immediately when a button or label is created. I've tried it with and without the CoreFoundation stuff. I've tried with with the -O flag, and the -g flag. The 32-bit and 64-bit compiles fail with the same errors in the same location. It appears to have something to do with fonts, which might explain why button and label fail, but canvas and frame widgets don't. It fails remotely or at the system console.

  gdb reveals the following stack trace:

  % button .a -text a

  Program received signal EXC_BAD_ACCESS, Could not access memory.
  Reason: KERN_PROTECTION_FAILURE at address: 0x00000080
  0x0004420a in FcConfigAddCache ()
  (gdb) where
  #0  0x0004420a in FcConfigAddCache ()
  #1  0x000443b8 in FcConfigAddDirList ()
  #2  0x00044471 in FcConfigBuildFonts ()
  #3  0x0004fdc0 in FcInitLoadConfigAndFonts ()
  #4  0x0004fe0c in FcInit ()
  #5  0x0004450a in FcConfigGetCurrent ()
  #6  0x00046302 in FcConfigSubstituteWithPat ()
  #7  0x00046a07 in FcConfigSubstitute ()
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkUnixRFont.o" more recent than executable timestamp
  #8  0x0b0f7cbf in InitFont (tkwin=0x381730, pattern=0x381f70, fontPtr=0x382320) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../unix/tkUnixRFont.c:214
  #9  0x0b0f827d in TkpGetFontFromAttributes (tkFontPtr=0x0, tkwin=0x381730, faPtr=0x35f808) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../unix/tkUnixRFont.c:390
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkFont.o" more recent than executable timestamp
  #10 0x0b01d949 in Tk_AllocFontFromObj (interp=0x80a800, tkwin=0x381730, objPtr=0x835090) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkFont.c:1169
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkConfig.o" more recent than executable timestamp
  #11 0x0b015012 in DoObjConfig (interp=0x80a800, recordPtr=0x381b50 "0\0278", optionPtr=0x862b60, valuePtr=0x835090, tkwin=0x381730, savedOptionPtr=0x0) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkConfig.c:773
  #12 0x0b014a25 in Tk_InitOptions (interp=0x80a800, recordPtr=0x381b50 "0\0278", optionTable=0x862a00, tkwin=0x381730) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkConfig.c:553
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkButton.o" more recent than executable timestamp
  #13 0x0b041f85 in ButtonCreate (clientData=0x0, interp=0x80a800, objc=6, objv=0xe5048, type=1) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkButton.c:746
  #14 0x0b041a3a in Tk_ButtonObjCmd (clientData=0x0, interp=0x80a800, objc=6, objv=0xe5048) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkButton.c:572
  #15 0x0a015179 in TclEvalObjvInternal (interp=0x80a800, objc=6, objv=0xe5048, command=0xffffffff <Address 0xffffffff out of bounds>, length=-1, flags=0) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclBasic.c:3649
  #16 0x0a06fc67 in TclExecuteByteCode (interp=0x80a800, codePtr=0x381690) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclExecute.c:2314
  #17 0x0a06d745 in TclCompEvalObj (interp=0x80a800, objPtr=0x81e100, invoker=0x0, word=0) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclExecute.c:1460
  #18 0x0a016b2d in TclEvalObjEx (interp=0x80a800, objPtr=0x81e100, flags=131072, invoker=0x0, word=0) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclBasic.c:4763
  #19 0x0a01660f in Tcl_EvalObjEx (interp=0x80a800, objPtr=0x80, flags=131072) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclBasic.c:4555
  #20 0x0a087611 in Tcl_RecordAndEvalObj (interp=0x80a800, cmdPtr=0x81e100, flags=131072) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclHistory.c:161
  #21 0x0a08739b in Tcl_RecordAndEval (interp=0x80a800, cmd=0x311330 "button .a -text a -font \"Fixed 10\"\n", flags=131072) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclHistory.c:59
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkMain.o" more recent than executable timestamp
  #22 0x0b02d2d9 in StdinProc (clientData=0x329740, mask=2) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkMain.c:390
  #23 0x0a09668b in Tcl_NotifyChannel (channel=0x329740, mask=2) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclIO.c:7781
  #24 0x0a0f587b in FileHandlerEventProc (evPtr=0x37e030, flags=-3) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../unix/tclUnixNotfy.c:635
  #25 0x0a0b5990 in Tcl_ServiceEvent (flags=-3) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclNotify.c:675
  #26 0x0a0b5d9f in Tcl_DoOneEvent (flags=-3) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclNotify.c:978
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkEvent.o" more recent than executable timestamp
  #27 0x0b01afe0 in Tk_MainLoop () at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkEvent.c:2114
  #28 0x0b02d082 in Tk_MainEx (argc=-1, argv=0xbffff7ec, appInitProc=0x5603 <Tcl_AppInit>, interp=0x80a800) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkMain.c:321
  #29 0x000055fc in main (argc=1, argv=0xbffff7e8) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../unix/tkAppInit.c:68

  Any ideas or pointers as to what I should try next. I assume other are compiling X11 version of 8.5.2 on the Mac without error? I think I have modern hardware with the latest software (Leopard) and all updates installed.


tkt_uuid: 2546087fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Tk console drops chars after \0
comment:
  The Tk console drops characters after a \0 character. Example:

  (MJanssen) 3 % set a "abcd\0efgh"
  abcd
  (MJanssen) 4 % puts $a
  abcd
  (MJanssen) 5 % string length $a
  9
  (MJanssen) 6 % 

  inserting the same string in a text widget will show all the characters.

  Tk version 8.5.4


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

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

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

  crashes with:

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

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

  DefaultDepthOfScreen(Tk_Screen(tkwin))

  which should simply be replaced with

  Tk_Depth(tkwin)

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

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


tkt_uuid: 1168354fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Duplicate
title: tk numeric keypad bindings fail
comment:
  platform: sparc solaris 8
  most if not all Tk versions

  Sun does weird key map assignments that result in users
  having problems getting numeric keypad keys to work. 
  The following
  code seems to work around the problem.  

  package provide KeypadBindings 1.0

  # Replacement bindings for Sun keypad

  namespace eval kpBnd {}

  bind Entry <Left>   [list kpBnd::fixBindingForKeypad %W
  %A [bind Entry <Left>]]
  bind Entry <KP_Left> \
      [list kpBnd::fixBindingForKeypad %W %A [bind Entry
  <Left>]]
  bind Entry <Right>  [list kpBnd::fixBindingForKeypad %W
  %A [bind Entry <Right>]]
  bind Entry <KP_Right> \
      [list kpBnd::fixBindingForKeypad %W %A [bind Entry
  <Right>]]
  bind Entry <Delete> \
      [list kpBnd::fixBindingForKeypad %W %A [bind Entry
  <Delete>]]
  bind Entry <KP_Insert> \
      [list kpBnd::fixBindingForKeypad %W %A [bind Entry
  <Insert>]]
  bind Entry <F27>    [list kpBnd::fixBindingForKeypad %W
  %A [bind Entry <Home>]]
  bind Entry <F33>    [list kpBnd::fixBindingForKeypad %W
  %A [bind Entry <End>]]
  bind Entry <F29>    [list kpBnd::fixBindingForKeypad %W
  %A [bind Entry <Prior>]]
  bind Entry <F35>    [list kpBnd::fixBindingForKeypad %W
  %A [bind Entry <Next>]]

  bind Text <Up>      [list kpBnd::fixBindingForKeypad %W
  %A [bind Text <Up>]]
  bind Text <KP_Up>   \
      [list kpBnd::fixBindingForKeypad %W %A [bind Text
  <Up>]]
  bind Text <Down>    [list kpBnd::fixBindingForKeypad %W
  %A [bind Text <Down>]]
  bind Text <KP_Down> \
      [list kpBnd::fixBindingForKeypad %W %A [bind Text
  <Down>]]
  bind Text <Left>    [list kpBnd::fixBindingForKeypad %W
  %A [bind Text <Left>]]
  bind Text <KP_Left> \
      [list kpBnd::fixBindingForKeypad %W %A [bind Text
  <Left>]]
  bind Text <Right>   [list kpBnd::fixBindingForKeypad %W
  %A [bind Text <Right>]]
  bind Text <KP_Right> \
      [list kpBnd::fixBindingForKeypad %W %A [bind Text
  <Right>]]
  bind Text <Delete>  \
      [list kpBnd::fixBindingForKeypad %W %A [bind Text
  <Delete>]]
  bind Text <KP_Insert> \
      [list kpBnd::fixBindingForKeypad %W %A [bind Text
  <Insert>]]
  bind Text <F27>     [list kpBnd::fixBindingForKeypad %W
  %A [bind Text <Home>]]
  bind Text <F33>     [list kpBnd::fixBindingForKeypad %W
  %A [bind Text <End>]]
  bind Text <F29>     [list kpBnd::fixBindingForKeypad %W
  %A [bind Text <Prior>]]
  bind Text <F35>     [list kpBnd::fixBindingForKeypad %W
  %A [bind Text <Next>]]

  proc ::kpBnd::fixBindingForKeypad { win alpha
  originalBinding } {

      # remove non-printing characters like DEL (0177)
      regsub -all {[^[:graph:]]} $alpha {} alpha
      if { "$alpha" ne {} } {
          $win insert insert $alpha
      } else {
          # replace %W with actual window in original binding
          regsub -all "%W" $originalBinding "$win" binding
          eval $binding
      }
  }


  Perhaps these could go into the standard Tk distribution?


tkt_uuid: 220201ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: bad prototypes in tkIntXlibDecls.h
comment:
  OriginalBugID: 2264 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-21'
  LastModified: '1999-06-30'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: redman
  RelatedBugIDs: 2308
  OS: Macintosh
  OSVersion: 8.5.1
  Machine: Power PC
  FixedInVersion: 8.2b1
  ClosedDate: '1999-06-30'


  Name:
  Jonathan Guyer

  ReproducibleScript:
  Compiling Tk 8.1.1 for the Mac with CodeWarrior Pro 4 generates errors
      in :tk8.1.1:generic:tkIntXlibDecls.h

  ObservedBehavior:
  Error   : identifier 'a' redeclared
      tkIntXlibDecls.h line 390   (Display* d, Window w, Atom a, Atom a, int
      i1, int i2, const unsigned char* c, int i3)
      
      Error   : identifier 'a' redeclared
      tkIntXlibDecls.h line 731   (Display* d, Window w, Atom a, Atom a, int
      i1, int i2, const unsigned char* c, int i3)

  DesiredBehavior:
  Should be "Atom a1, Atom a2" or please provide the necessary compiler
      switches if it's possible to remove this error.



  see 2308 
  -- 06/30/1999 redman


tkt_uuid: 1499165fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: 8.5 text widget slow to update scrollbar
comment:
  When reading large files into a text widget,
  the widget sends scrollbar updates over many seconds
  as (i assume) it's calculating display lines. While 
  this is happening, the scrollbar will only represent 
  the part of the widget that the widget has processed.

  8.4 doesnt have this slow scrollbar update behavior.

  I'm assuming this was to improve scrollbar accuracy, 
  counting display lines instead of file lines.

  It would be nice to have an option to return to the 
  inaccurate but quick behavior of 8.4.
  I have one font and no line-wrapping, so a simply file 
  line count is correct.

  I'm running Solaris 5.8 on a 440MHz Sun.

  Thanx


tkt_uuid: 787402ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: No KP_Enter on Windows
comment:
  Original complaint on comp.lang.tcl:

  From: Wolf Grossi (Go2DevNull@magro-soft.com)
  Subject: KP_Enter on win98se
  Newsgroups: comp.lang.tcl
  Date: 2003-07-03 12:12:46 PST

  Hi all :-)

  can it be true that windoze does not distinguish between
  <Return> and <KP_Enter> ?

  Doing a   bind . <Key>  {puts %K}
  I get
  KP_Enter for enter and
  Return   for return
  on Linux.

  On win98se, the return key and the enter key both give
  <Return> as result.

  I browsed wiki but could not find anything related.

  Any way to solve the puzzle?

  Thanks 4 reading
  Wolf


tkt_uuid: 693063ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 62. Geometry Functions
priority: 8
foundin: None
resolution: Accepted
title: Rework pack, grid, and place geom managers
comment:
  After some discussion with Jeff, I created this patch
  to fixup
  a couple of problems in the geom managers. The first big
  problem was with place. When certain errors were raised
  by the place command, the winfo geometry command
  would return invalid results. Here is a quick example:

  place .foo -in .foo

  The above returns an error but also makes . the parent and
  sets place as the geom manager. Fixing this is actually
  quite
  tricky, what needs to be done is to have one block of code
  in the place command that gets executed when a new slave
  is added. Then, the Tk_ManageGeometry function can
  be called from that spot instead of from CreateSlave where
  it currently is called. To do that, one needs to check for
  simple cases like "place .foo -x 0 -y 1" followed by
  "place .foo -x 1 -y 1" to ensure that these do not change
  anything related to the slave window. The attached patch
  also adds this sort of check for the grid command so that
  it also works more like the pack impl.

  The other change this patch makes is to check for a
  NULL master and slave in each of the structure callbacks
  that can be invoked for child windows. The trick is that
  in error cases like "pack .foo -in .foo" the window .foo
  is entered into the pack slave table even though it is not
  linked into a master and slave. The PackStructureProc
  callback need to check for this sort of window before
  doing anything else so that no geom calculations are
  done for these sorts of error windows. The pack code
  did this, but it needed to be fixed in the grid code.

  I have run the test suite with these changes added and
  I am not seeing any failures. I would like to get this
  patch added as soon as possible since I am working on
  another patch to fix other geom manager problems
  and it needs to have this one applied first.


tkt_uuid: 220905ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3
resolution: None
title: Focus management for modal dialogs behaves non-standard on N
comment:
  OriginalBugID: 4609 RFE
  Version: 8.3
  SubmitDate: '2000-03-27'
  LastModified: '2000-03-27'
  Severity: MED
  Status: UnAssn
  Submitter: sven
  ChangedBy: sven
  RelatedBugIDs: 4561 5040
  OS: All Windows


  This is a cloned report. The issue is that when I grab, the clicking on a non interactive window should raise the application. This could be done by binding <Button-1> on the window that has the grab, in which case we will have to change BWidgets and other dialogs to support that behavior. If this could be done by Tk the implementation would be much easier.

  Original error:

  If you select New Project from the File menu, a New Project window appears.  If you do other things, you can get into a state where the window is hidden underneath other windows.  Clicking on the main window does not bring the New Project window back to the top level.  Thus, it looks like the application is stuck.  You can close/iconify all your windows and find the New Project window again, but it's an annoyance.  

  To reproduce:
  1) Start Author
  2) Select File->New Project
  3) Move another window over the New Project window
  4) Click on any visible Author windows
     --> The New Project window does not come into focus; the other ones don't  either.

  It would be nice if you could click on any of the other windows and have the New Project window pop up again from the background.


tkt_uuid: 220811ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.1b3
resolution: None
title: Docs missing for Tk_TranslateWinEvent API
comment:
  OriginalBugID: 1888 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: 791527ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: None
title: Menubar redisplay glitches on X
comment:
  Most Tk widgets handle <Expose> events by drawing into
  a background pixmap and blitting the results to the
  screen, for a quick refresh.

  The [menu] widget does not; instead it draws directly
  to the window.  This leads to a "blinking" effect when
  e.g., mousing over menu items or keyboard navigation. 
  This is most noticeable on slow displays.


tkt_uuid: 456299ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 7 High
foundin: obsolete: 8.4a2
resolution: Duplicate
title: Distorted images in Win2000 menus
comment:
  This bug occurs on Win2000 only.  WinNT, WinME, Win98,
  and Win95 (and of course Unix) all appear to work
  correctly.

  When a menu entry is an image instead of text, the
  first time the image is drawn it is distorted.  It
  appears as if the clip mask is offset up and to the
  left by 3 pixels.  The distortion appears only when
  the menu first pops up.  If you drag the mouse over
  the menu entry with the image, the image is repainted
  and is drawn correctly.

  The following script is sufficient to reproduce the
  problem:

    image create photo img4 -data {
     R0lGODlhEQAeAPEDAAEBAQAz/////wAAACH5
     BAUAAAMALAAAAAARAB4AAAJjnAepeqcCo2Am  
     yQsTArivD4ZiiDRlA5Sp6pzr2aLm+tJmFcN3
     yus3+/o5NMJd8XgLIE1KQ6CZfD4Hyun0UKVq
     qdWmd4vNbrtMJ9R6baC5SOlSWNtUiDhcr24H
     4lu2+8xFQ1QAADv/
    }
    menubutton .b -text {Press Me} -menu .b.m1
    pack .b
    menu .b.m1 -tearoff 0 -background white \ 
        -activebackground white
    .b.m1 add command -image img4 -command exit


tkt_uuid: 220726ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Poscript creation for photo images
comment:
  OriginalBugID: 5030 Bug
  Version: 8.3
  SubmitDate: '2000-04-12'
  LastModified: '2000-04-24'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4268 4186
  OS: All Windows
  Machine: Pentium // 300Mhz 32 MB RAM 24 bit color screen
  FixedDate: '2000-04-24'
  FixedInVersion: 8.3.1


  Name:
  Alberto Biancardi

  Comments:
  This new patch updates the one submitted as TR#4268.
      Thanks to Jan Nijtmans the new patches have a cleaner implementation.

  ReproducibleScript:
  cd $tk_library/images
  pack [canvas .c -width 600 -height 800]
  .c create image 300 400 -image [image create photo -file pwrdLogo75.gif]
  .c postscript -file test.ps

  ObservedBehavior:
  Wish crashes because XGetImage is not implemented

  DesiredBehavior:
  Being able to create a postscript dump of a canvas with images

  Patch:
  http://robot.unipv.it/~alberto/tcl/ps4photo.patch

  PatchFiles:
  tk.decls
      tkCanvPs.c
      tkDecls.
      tkImage.c
      tkImgPhoto.c
      tkStubInit.c.new



  Patched as noted for 8.3.1. 
  -- 04/24/2000 hobbs


tkt_uuid: 1939129fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: Fixed
title: ::ttk::combobox posts badly with wm attr -topmost
comment:
  package require Ttk
  wm attribute . -topmost 1
  ::ttk::combobox .cb -values {a b c d}
  label .a -text "filler\nfiller\nfiller"
  pack .cb .a -side top


  Clicking the combobox causes the dropdown window to get drawn BEHIND the toplevel window because it has wm attribute -topmost 1.


tkt_uuid: 490051ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: wish segfaults deleting a label
comment:
  'wish' appears to get a segfault if a label widget is deleted from an 'unset' trace on its textvariable.

  Test script:

  toplevel .t
  wm title .t "Countdown"
  grid [label .t.val -textvariable v -width 24]
  trace variable v u [list destroy .t]
  proc doit {} {
      global v
      if { $v == 0 } {
  unset v
      } else {
  incr v -1
  after 1000 doit
      }
  }
  set v 10
  after 1000 doit

  Resulting stack trace:

  Program received signal SIGSEGV, Segmentation fault.
  Tcl_GetString (objPtr=0x0) at ../unix/../generic/tclObj.c:792
  792         if (objPtr->bytes != NULL) {
  #0  Tcl_GetString (objPtr=0x0) at ../unix/../generic/tclObj.c:792
  #1  0x80900 in ButtonTextVarProc (clientData=0x2c24e8, interp=0x23f1b8,
      name1=0x29a150 "v", name2=0x0, flags=192)
      at /local/src/tk/unix/../generic/tkButton.c:1628
  #2  0x1c7d04 in CallTraces (iPtr=0x23f1b8, arrayPtr=0x0, varPtr=0xffbede00,
      part1=0x29a150 "v", part2=0x0, flags=192, resultTypePtr=0xffbedddc)
      at ../unix/../generic/tclVar.c:4606
  #3  0x1c3868 in Tcl_UnsetVar2 (interp=0x23f1b8, part1=0x29a150 "v", part2=0x0,
      flags=512) at ../unix/../generic/tclVar.c:2364
  #4  0x1c43dc in Tcl_UnsetObjCmd (dummy=0x0, interp=0x23f1b8, objc=2,
      objv=0x23fe10) at ../unix/../generic/tclVar.c:2883
  #5  0x127a40 in TclEvalObjvInternal (interp=0x23f1b8, objc=2, objv=0x23fe10,
      command=0x0, length=0, flags=0) at ../unix/../generic/tclBasic.c:2935
  #6  0x15e934 in TclExecuteByteCode (interp=0x23f1b8, codePtr=0x2cbc70)
      at ../unix/../generic/tclExecute.c:1258
  #7  0x15dbc0 in TclCompEvalObj (interp=0x23f1b8, objPtr=0x2a7d50, engineCall=0)
      at ../unix/../generic/tclExecute.c:844
  #8  0x128eac in Tcl_EvalObjEx (interp=0x23f1b8, objPtr=0x2a7d50, flags=0)
      at ../unix/../generic/tclBasic.c:3748
  #9  0x1ae8f8 in TclObjInterpProc (clientData=0x2c5058, interp=0x23f1b8,
      objc=1, objv=0xffbee6f8) at ../unix/../generic/tclProc.c:1074
  #10 0x127a40 in TclEvalObjvInternal (interp=0x23f1b8, objc=1, objv=0xffbee6f8,
      command=0x2c3200 "doit", length=4, flags=0)
      at ../unix/../generic/tclBasic.c:2935
  #11 0x128738 in Tcl_EvalEx (interp=0x23f1b8, script=0x2c3200 "doit",
      numBytes=4, flags=131072) at ../unix/../generic/tclBasic.c:3459
  #12 0x1b8b98 in AfterProc (clientData=0x2cb4b0) 


tkt_uuid: 220673ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: Uninitialized pointer causes compilation halt
comment:
  OriginalBugID: 4119 Bug
  Version: 8.3b2
  SubmitDate: '2000-02-03'
  LastModified: '2000-02-03'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  Machine: Compaq Deskpro 400MHz Pentium II, 128 MB RAM
  FixedDate: '2000-02-03'
  FixedInVersion: 8.3


  Name:
  Jay Schmidgall

  CustomShell:
  Straight up download from Scriptics of the gzipped source.

  ReproducibleScript:
  nmake -f makefile.vc

  ObservedBehavior:
  Attempting to build tk8.3b2 on Windows NT with MS Visual C++ 6.0.
  Whilst compiling tkWinWm.c, an uninitialized pointer is used, which causes the compilation to halt. 

          "c:\Progra~1\MI017E~1\vc98\bin\cl.exe" -DDLL_BUILD -DBUILD_tk -Z7 -Od -W
  X -c -W3 -nologo -Fp.\Debug\ -YX -MDd -I"c:\Progra~1\MI017E~1\vc98\include"  -I.
  .\win -I..\generic -I..\bitmaps -I..\xlib  -I..\..\tcl8.3\generic -D__WIN32__
  -DUSE_TCL_STUBS -Fo.\Debug\ ..\win\tkWinWm.c
  tkWinWm.c
  ..\win\tkWinWm.c(2218) : warning C4700: local variable 'masterPtr' used without
  having been initialized
  ..\win\tkWinWm.c(2218) : error C2220: warning treated as error - no object file
  generated
  NMAKE : fatal error U1077: '"c:\Progra~1\MI017E~1\vc98\bin\cl.exe"' : return cod
  e '0x2'
  Stop.

  DesiredBehavior:
  I would expect that either the pointer be initialized to NULL, if nothing else,
  or that the warning would not cause compilation to halt.



  This is already fixed in the current CVS (slipped through in 8.3b2).
  The pointer access is not valid at all as used. 
  -- 02/03/2000 hobbs


tkt_uuid: 1615592fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: Wish console misses first fronting click
comment:
  When the Wish application is started, the Tk toplevel window appears in front of the Console window.  It ought to be possible to click anywhere in the visible part of the Console window in order to raise the Console in front of the Tk toplevel.  In fact, the only part of the Console window where the click is effective is the title bar.

  After the Console has been brought to the front by clicking on the title bar, subsequent clicks on any visible part of either of the windows will serve to raise the window correctly.

  There was exactly the same problem with the Wish application on MacOS X corrected recently.  

  (This is reported using Windows XP SP2 and ActiveTcl 8.5.0.0.272633, but I believe it is a long-standing problem.)


tkt_uuid: 687522ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.4.1
resolution: Fixed
title: <<Modified>> triggers too often
comment:
  The <<Modified>> virtual event now triggers 
  everytime the modified flag is explicitely set with 
  the 'edit modified <boolean>' command. It should 
  only trigger when the value of the modified flag 
  actually changes.


tkt_uuid: 2908052fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Works For Me
title: TkAqua crashes on scrolling event
comment:
  The 8.6b1.1 version of TkAqua crashes when scrolling in a certain way. Holding the mouse button pressed on a scrolling arrow will cause wish to crash with the following message:

  wish8.6-aqua(1797,0xb0103000) malloc: free_garbage: garbage ptr = 0x1418c80, has non-zero refcount = 1
  2009-12-03 11:32:32.995 wish8.6-aqua[1797:10b] *** Assertion failure in +[NSEvent startPeriodicEventsAfterDelay:withPeriod:], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSEvent.m:1765
  2009-12-03 11:32:32.995 wish8.6-aqua[1797:10b] An uncaught exception was raised
  2009-12-03 11:32:32.997 wish8.6-aqua[1797:10b] Periodic events are already being generated
  2009-12-03 11:32:32.997 wish8.6-aqua[1797:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Periodic events are already being generated'
  2009-12-03 11:32:32.998 wish8.6-aqua[1797:10b] Stack: (
      2470170603,
      2514165307,
      2470170059,
      2478157508,
      2525052112,
      2526164841,
      2524622328,
      2523486967,
      2523276965,
      2195129,
      2196449,
      3235242,
      1389874,
      2705113,
      2707855,
      3011097,
      2707855,
      2737327,
      2738193,
      2198337,
      2523500175,
      2523499980,
      2524627019,
      2526164928,
      2524622328,
      2523486967,
      2523276965,
      2195129,
      2196449,
      3235242,
      1421705,
      1483183,
      25904,
      25689
  )
  Trace/BPT trap

  The same is true, when scrolling by holding the mouse pressed on the slider trough (tested on MacOS X 10.5 and 10.6).


tkt_uuid: 439503ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: None
title: exec command hangs
comment:
  Under Linux (RH7, MDK8) wish will hang when the exec
  command is used.  This does not happen under tclsh..

  Start wish then issue "exec ls".

  You will have to ctrl-c to kill wish.


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




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


tkt_uuid: 640337ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 4
foundin: obsolete: 8.4.1
resolution: Out of Date
title: Grid behaves oddly on aqua Tk 8.4.1
comment:
  I coded a command/entry widget that consisted of an existing scrolling log widget plus a command entry field underneath. It has a problem on MacOS X 10.2.1 with aqua Tk 8.4.1 (but apparently not under unix or Windows):

  When I bring up the window, the scrollbar shimmies and the CPU usage is high. Both of these can be stopped by resizing the toplevel window, and it does not happen if I specify an initial size for the toplevel window.

  I reduced my code to quite a bit and have attached it as gridbug.tcl. I run it by pasting it into the Wish Shell console.

  Several folks have reported that a Python/Tkinter version of this minimal code works fine on various flavors of unix and Windows, whereas I see the problem on MacOS X. Hence I suspect it is a Mac-specific bug, and possibly an aqua-Tk-specific bug.


tkt_uuid: 220588ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Tk fails to compile under HP-UX
comment:
  OriginalBugID: 2649 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-08-31'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: B.10.20
  Machine: Other
  FixedDate: '1999-08-31'
  FixedInVersion: 8.2.1


  Name:
  jso

  Comments:
  The problem arises from the use of explicit casts in a function
      declaration. By using the K&R style of typing the parameters after the
      (params) list, tk compiles cleanly. This only affects one function in
      one file: the TkpDrawHighlightBorder function in tkUnixDraw.c

  ObservedBehavior:
  Tk fails to compile while using HP's cc compiler on HP-UX B.10.20.



  Fixed header style for 8.2.1. 
  -- 08/31/1999 hobbs


tkt_uuid: 220535ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Handling of non true type fonts on Windows could be better.
comment:
  OriginalBugID: 2172 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-03'
  LastModified: '2000-05-12'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 5469
  OS: All Windows
  Machine: X86
  FixedDate: '2000-05-12'
  FixedInVersion: 8.4a1


  Name:

  Peter Spjuth



  Comments:

  When using non true type fonts, like the default font ms sans serif, and

      fonts

      like fixedsys and system, Tk only uses the characters up to 7F even

      though

      those fonts can display more.

      

      This patch let such fonts display characters A0-FF too, making things

      look

      a lot better when using Tk with a language like Swedish.

      

      I don't know if the assumption that fonts with ANSI_CHARSET always can

      display characters A0-FF is true, but as I see it, it is true enough.

      

      I have not done any deeper study of how fonts are handled, so I don't

      know if this solution is correct, or if it's the best solution, but

      it solves the problems I have had.



  ReproducibleScript:

  pack [label .l1 -text aöbéc]

      pack [label .l2 -text aöbéc -font system]

      pack [label .l3 -text aöbéc -font fixedsys]



  ObservedBehavior:

  The labels' texts don't look nice since the non US ascii characters 

      are displayed with a different font than the others.

      

      I hope the script survive the passage through e-mail, but otherwise

      you can enter any chars from the upper half of 8-bit ascii at the text

      option.



  Patch:

  *** tkWinFont.c.origSun May 30 18:34:06 1999

  --- tkWinFont.cWed Jun 02 21:02:38 1999

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

  *** 2202,2214 ****

        USHORT **endCountPtr,/* Filled with malloced pointer to 

     * character range information. */

        int *symbolPtr)

  !  {

  !     int n, i, swapped, offset, cbData, segCount;

        DWORD cmapKey;

        USHORT *startCount, *endCount;

        CMAPTABLE cmapTable;

        ENCODINGTABLE encTable;

        SUBTABLE subTable;

        char *s;

    

        segCount = 0;

  --- 2202,2215 ----

        USHORT **endCountPtr,/* Filled with malloced pointer to 

     * character range information. */

        int *symbolPtr)

  ! {

  !     int n, i, swapped, offset, cbData, segCount, charSet;

        DWORD cmapKey;

        USHORT *startCount, *endCount;

        CMAPTABLE cmapTable;

        ENCODINGTABLE encTable;

        SUBTABLE subTable;

  +     TEXTMETRIC tm;

        char *s;

    

        segCount = 0;

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

  *** 2305,2310 ****

  --- 2306,2323 ----

    }

        }

    }

  +     } else if (GetTextMetrics(hdc, &tm)) {

  +         charSet = tm.tmCharSet;

  +         if (charSet == ANSI_CHARSET) {

  +             segCount = 2;

  +             cbData = segCount * sizeof(USHORT);

  +             startCount = (USHORT *) ckalloc(cbData);

  +             endCount = (USHORT *) ckalloc(cbData);

  +             startCount[0] = 0x0020;

  +             endCount[0] = 0x007f;

  +             startCount[1] = 0x00a0;

  +             endCount[1] = 0x00ff;

  +         }

        }

        SelectObject(hdc, hFont);



  PatchFiles:

  tkWinFont.c





  I changed this patch to the simpler:



      } else if (GetTextCharset(hdc) == ANSI_CHARSET) {

  /*

   * Bitmap font.  We should also support ranges for the other

   * *_CHARSET values.

   */

  segCount = 1;

  cbData = segCount * sizeof(USHORT);

  startCount = (USHORT *) ckalloc(cbData);

  endCount = (USHORT *) ckalloc(cbData);

  startCount[0] = 0x0000;

  endCount[0] = 0x00ff;



  As upon further examination, ANSI_CHARSET == cp1252 for Windows,

  and that should really handle all of the first 256 chars.  After

  applying the patch, you can see the difference when using the

  right font and outputing:



  for {set i 0} {$i < 256} {incr i} {

      puts "$i\t[format %x $i]\t[subst \\[format %o $i]]"

  }



  This is in 8.4a1 for now, but may change because there are other

  bitmap charset identifiers which we might want to support correctly

  in that else case. 

  -- 05/12/2000 hobbs


tkt_uuid: 220417ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Cannot configure a font after assigning it to a widget
comment:
  OriginalBugID: 1055 Bug
  Version: 8.1b1
  SubmitDate: '1999-01-15'
  LastModified: '1999-04-19'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: surles
  OS: Solaris
  OSVersion: 5.6
  Machine: Other
  FixedDate: '1999-04-19'
  FixedInVersion: 8.1b3


  Name:
  Petasis George

  ObservedBehavior:
  You create a font with the "font create command"
  You assign this font in a widget (let's say a text widget)
  You configure the font with the "font configure"
  The changes are rejected. The font of the widget does not change, nor does change what you get from "font actual" command. You cannot even change the underline or overstrike option. This happened under Solaris 5.6 with more than
  1000 fonts installed and under windows NT 4.0 SP4.

  DesiredBehavior:
  The command "font configure" to change the properties of a font, previously created with the "font create" command.



  this may be fixed, but should be verified
  04/16/1999 14:54 - stanton -
  ---
  04/19/1999 19:02 - surles - The fix has been verified and works.


tkt_uuid: 220454ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: spawning wish or tktest with pipe on windows causes parent wish/tktest to hang on closing pipe
comment:
  OriginalBugID: 1495 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-12'
  LastModified: '1999-04-02'
  Severity: SER
  Status: Released
  Submitter: redman
  ChangedBy: redman
  RelatedBugIDs: 1594
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-04-02'
  FixedInVersion: 8.1b3


  This sample script, when run from wish81.exe or it's variants, or tktest.exe, causes it to hang on closing the pipe.  It appears to be a problem with either detecting that the pipe is closed (the child process's fault) or not killing off the child (the parent's fault) if it's supposed.  Verified to be in 8.1b1 and 8.1b2, should fix this before the final 8.1 release.

  Sample script:

  set tcltest [info nameofexecutable]
  puts $tcltest
  update
  puts "goodbye"
  flush stdout

  catch {
      file delete -force tmp
      set f [open tmp w]
      puts $f {
  exit
      }
      close $f
      set f [open "|[list $tcltest tmp]" r]
      close $f
  }
  catch {file delete -force tmp}



  Related bug ID 1594.

  04/02/1999 18:54 - redman - Should be fixed now, removed the send code.


tkt_uuid: 3202950fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Duplicate
title: ttk::menubutton dropdown arrow cut off on Windows 7
comment:
  toplevel .t
  ttk::menubutton .t.test -text "Foo"
  pack .t.test

  The right third of the drop-down arrow indicator is cut off.
  When moving the mouse over the item, highlighting shows a very narrow vertical slice being allocated for the dropdown half.
  Only happens with XP and Vista themes on Windows 7.  Does not occur under XP, have not tried Vista.
  Tried playing with layout and padding in both TCL and C (ttkWinXPTheme.c) without any effect.


tkt_uuid: 1357575fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Fixed
title: Unclear defn of result of text widget index with modifiers
comment:
  Index computation results in text widget depends on 
  the modifiers order.
  This simple script reproduces the problem:

  text .t
  pack .t
  .t insert 1.0 "this is a test text\n"
  .t insert 2.0 "this is the second line\n"
  .t insert 3.0 "this is the last line."
  puts [.t compare "1.0 - 1l + 1l" == "1.0"]
  puts [.t compare "1.0 + 1l - 1l" == "1.0"]
  puts [.t compare "1.0 - 1c + 1c" == "1.0"]
  puts [.t compare "1.0 + 1c - 1c" == "1.0"]
  puts [.t compare "3.0 + 2l - 2l" == "3.0"]
  puts [.t compare "3.0 - 2l + 2l" == "3.0"]
  puts [.t compare "4.0 + 1c - 1c" == "4.0"]
  puts [.t compare "4.0 - 1c + 1c" == "4.0"]

  All the comparison results should be 1 since 
  (mathematically) there is no preferred order in 
  adding/substracting one line or character.

  I believe Tcl analyzes the index string "base 
  modifier modifier..." by taking each modifier once at 
  a time, computes the new resulting index, and checks 
  for the text widget bounds at each iteration.
  It should check for bounds only at the end of the 
  index computation.

  The text widget man page tells that modifiers are 
  applied from left to right, that's OK, but it doesn't 
  tell that the boundaries are checked for each 
  intermediate result.

  The boundaries should be checked only when all the 
  modifiers have been applied. If this is not possible, 
  at the very least the man page should warn that the 
  widget checks bounds after applying each modifier.

  Occurs on Tcl/Tk 8.5 alpha and 8.4.11 as well.


tkt_uuid: 991849ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: None
title: removal/optimization of scrollbar events?
comment:
  While developing my application, I noticed that in some
  cases, I got scroll commands invocations with
  exceedingly small first and last range.
  For example:

  proc echo {args} {
    foreach argument $args {puts -nonewline "$argument "}
    puts {}
  }
  .canvas configure -xscrollcommand echo

  would, in some cases, give:
  0 0.00201613

  Since I use this type of code to automatically manage
  scrollbars (displayed only when needed), I end up with
  scrollbars displayed when they should not, as the event
  above implies that a scrollbar is needed (last - first
  < 1).

  At the time these events happen, and after looking at
  the 8.4.6 tkCanvas.c source code, [winfo width .canvas]
  = 1, which means that these events are not really
  valid, in the sense that the canvas is not really
  "displayed" yet (my interpretation).

  I traced the problem (if that is indeed one) using
  printf() calls, in ConfigureCanvas():

    ...
      printf("canvasPtr->xOrigin = %d,
  Tk_Width(canvasPtr->tkwin) = %d\n",  
  canvasPtr->xOrigin, Tk_Width(canvasPtr->tkwin));
      Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,
        canvasPtr->xOrigin, canvasPtr->yOrigin,
        canvasPtr->xOrigin + Tk_Width(canvasPtr->tkwin),
        canvasPtr->yOrigin + Tk_Height(canvasPtr->tkwin));
      return TCL_OK;
    }

  which gives:

    canvasPtr->xOrigin = 0, Tk_Width(canvasPtr->tkwin) = 1

  followed by, in Tk_CanvasEventuallyRedraw():

    ...
    if (!(canvasPtr->flags & REDRAW_PENDING)) {
      printf("canvasPtr->redrawX1 = %d,
  canvasPtr->redrawX2 = %d\n", canvasPtr->redrawX1,
  canvasPtr->redrawX2);
      Tcl_DoWhenIdle(DisplayCanvas, (ClientData) canvasPtr);
      canvasPtr->flags |= REDRAW_PENDING;
    }
  }

  which gives:

    canvasPtr->redrawX1 = 0, canvasPtr->redrawX2 = 1

  followed by the invocation of the X scroll command with
  first = 0, last = 0.00201613, as described before.

  Now there are quite many "invalid" events of this sort,
  which invoke commands at the Tcl level. Filtering these
  out at the C code level (when [winfo width/height] = 1,
  as I now do at the Tcl level in my automatic scrollbar
  code) would possibly improve Tk display performance and
  remove some display errors.

  What do you think? 

  Best regards,

  Jean-Luc


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


  Name:
  Boris Gontar

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

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

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



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


tkt_uuid: 220093ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.3.2
resolution: Duplicate
title: Disabled text widget selection inconsistency among Windows and Linux.
comment:
  OriginalBugID: 6249 Bug
  Version: 8.3.2
  SubmitDate: '2000-09-11'
  LastModified: '2000-09-11'
  Severity: LOW
  Status: Closed
  Submitter: sandeep
  ChangedBy: ericm
  RelatedBugIDs: 4329 5933
  OS: All
  FixedDate: '2000-09-11'


  Steps to Reproduce:
  1. Run the following script

  text .t
  .t insert end foo
  .t configure -state disabled
  pack .t

  2. Try to select "foo".

  Expected Result:
  Either both platforms should allow the selection, or both should not.

  Actual Result:
  In Linux (KDE & remotely via Exceed) you can select the text.  In Windows you can't.

  ACK! It's worse than that.  If you change the state of the widget to normal, do a selection, click somewhere to get rid of the selection, change the state back to disabled, it allows you to select from that point forward.  So -state disabled doesn't guarantee the disability to select.



  The behavior of the text widget on Windows is based on behaviors observed in Windows applications.  It is true that those behaviors are based on old applications, and should be updated to conform to the new standards.  However, it is an incorrect assumption that a text widget (or any widget) should have the same behavior on all platforms.  All platforms are not created equal.

  In any case, a complete solution to this problem, I believe, requires the introduction of a new state for text widgets: readonly, similar to the readonly state found in entry widgets in 8.4.  The whole problem now stems from the fact that the readonly and truly disabled states of a text widget are intermingled, and should not be.

  This is related to bugs 5933 and 4329.

  - eric

  -- 09/11/2000 ericm


tkt_uuid: 632514ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 7 High
foundin: obsolete: 8.4.1
resolution: Fixed
title: disabled listbox error
comment:
  Summary:
  Listbox new disabled state seems not tested inside lisbox.tcl.

  Test code:
    set ::listvar {a b c d e f g h i j}
    pack [listbox .lb -state disabled -listvar ::listvar -selectmode 
  extended]

  Result:
  Browsing the listbox give an error:
  expected boolean value but got ""
      while executing
  "if {[$w selection includes anchor]} {
      $w selection clear $i $el
      $w selection set anchor $el
        } else {
      $w selection clear $i $el
      $w selecti..."
      ("extended" arm line 7)
      invoked from within
  "switch [$w cget -selectmode] {
    browse {
        $w selection clear 0 end
        $w selection set $el
        set Priv(listboxPrev) $el
        event generate $w..."
      (procedure "tk::ListboxMotion" line 7)
      invoked from within
  "tk::ListboxMotion .lb [.lb index @39,79]

  Correction:
  Don't know.
  Should all events disabled when the listbox is disabled?

  ulis


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


  Name:
  Roy E. Terry

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

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

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


tkt_uuid: 1739506fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 81. Portability
priority: 9 Immediate
foundin: obsolete: 8.5a7
resolution: Fixed
title: package require Tk fails with makefile.vc
comment:
  The Tk makefile.vc uses $(TCL_PATCHLEVEL) but never defines it.  This results in a pkgIndex.tcl that fails to load Tk.

  The attached patch corrects the problem by introspecting the tcl.h file for the correct patch level using the new functionality provided by nmakehlp.c for this purpose.

  Please review, as I intend to commit this change soon.


tkt_uuid: 892880ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: Invalid
title: Accelerate WINDOWS wish startup
comment:
  Accelerate WINDOWS startup if 'consoleRequired' within 
  win/winMain.c is set to FALSE for argc > 1. Otherwise 
  the time consuming initialization of external packages is 
  done twice ! (UNIX ok)


tkt_uuid: 974600ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 7 High
foundin: obsolete: 8.5a2
resolution: None
title: Gaps in Line sections
comment:
  Platform: windows (note: bug also appears in v8.4.6)
  When I have created two or more lines on a canvas,  and 
  these lines are "growing" by means of successive insert 
  actions, gaps in line sections may occur under the 
  following conditions (here two lines are supposed):

  - Between any coordinate insert action of both lines the 
  Tk Mainloop must have been active.
  - Coordinates must be non-integer with non-zero 
  fractional part (at least one of the coordinates).
  - Only the LOWEST line (higher y-coordinate) is prone to 
  this behaviour.

  The lines will automatically refresh without gaps when 
  another window will be moved over the lines, regardless 
  whether it is a Tk window or not.

  Attached is a PNG of an example output with two 
  crossing lines. Interestingly: after the line crossing, all is 
  well (but I also have obeyed further gaps in the line 
  which is lowest).

  Here's the test code that results in the attached output:

  #console show
  # test file to show line drawing errors
  canvas .c -width 500 -height 200 -bg white 
  -highlightthickness 0
  #pack [button .b -text start -command {plotlines .c}]
  pack .c

  proc plotlines {w} {
      $w delete line
      set id1 [$w create line 0 0 0 0 -fill red -tags line]
      set id2 [$w create line 0 199 0 199 -fill blue -tags 
  line]
      set n 0
      for {set x 0} {$x < 450} {incr x 2} {
      $w insert $id1 end "$x [expr {$n/5.0}]"
      $w insert $id2 end "$x [expr {199 - ($n/5.0)}]"
      incr n 4
      update
      }
  }

  plotlines .c

  Note: the behaviour has been discovered in a datalogger 
  application where several channels are supplying data 
  via a com port. The data is retrieved event driven using 
  a fileevent setup. The code above lacks this event drive. 
  To achieve the erroneous result, an "update" command 
  is used. The window must be visible during the plotlines 
  call.


tkt_uuid: 1917674fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Select font in wish console
comment:
  Added some code to console.tcl to allow setting the font from a select list of font families in the edit menu.


tkt_uuid: 219991ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: final: 8.1.1
resolution: Duplicate
title: make install does not create intermediate directories
comment:
  OriginalBugID: 2183 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-07'
  LastModified: '1999-08-08'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 709
  OS: Digital Unix
  OSVersion: 4.0b
  Machine: Other
  ClosedDate: '1999-08-08'


  Extensions:
  none;

  CustomShell:
  none; no;

  ReproducibleScript:
  when building and installing tk in a nonstandard directory running
      make install
      will abort if the ${exec_prefix} directory does not exist; this is
      not the case with tcl which does the right thing;

  ObservedBehavior:
  Making directory /tools/tcl/source_tk/lib
      *** Exit 2

  DesiredBehavior:
  in the makefile and consquently in the file makefile.in the 
      install-binaries target should have 
      mkdir -p $$i;  rather than
      mkdir $$i;  


  Integrated sometime before 8.2b2. 
  -- 08/08/1999 hobbs


tkt_uuid: 219218ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 7 High
foundin: obsolete: 8.3.2
resolution: Fixed
title: error handling with bgerror in Tk
comment:
  OriginalBugID: 3998 Bug
  Version: 8.2.3
  SubmitDate: '2000-01-10'
  LastModified: '2000-01-23'
  Severity: MED
  Status: Assigned
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2577 2136 750
  OS: All
  FixedDate: '2000-10-25'
  ClosedDate: '2000-10-25'


  Name:
  Torsten Rottmann

  ReproducibleScript:
  wish
  % after 1 dfdf
  after#0
  % bgerror failed to handle background error.
      Original error: invalid command name "dfdf"
      Error in bgerror: invoked "break" outside of a loop

  ObservedBehavior:
  If you press "Skip Messages" ( the "return -code break" behaviour) former version of Tcl
  didn't complain about "break outside a loop"

  DesiredBehavior:
  Same as in Tcl8.0: nothing



  This behavior seems to have changed between 8.0.4 and 8.1. 
  -- 01/23/2000 hobbs


tkt_uuid: 220532ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Mac Simple Tk (PPC) causes type 1 error after exiting.
comment:
  OriginalBugID: 2161 Bug
  Version: 8.0.3
  SubmitDate: '1999-06-03'
  LastModified: '1999-11-16'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  Machine: Power PC
  FixedDate: '1999-11-16'
  FixedInVersion: 8.2


  Name:
  Arthur J. Milgram

  Extensions:
  none

  CustomShell:
  one function call in TclAppInit.c

  Comments:
  I've built an application which uses Boutell's GD library, and a CGI
      support lib from Apple, that runs under a Tcl/Tk interpreter. I've been
      working on this for over two years. The program reads GeneBank files and
      draws whole bacterial genomes in cartoon form, and manipulates genomic
      data on the size of several genomes in order to construct gene
      illustrations.
      
      It is very useful for me, and encapsulation is such that using the
      instructions in the FAQ to build and link with the Tcl/Tk interpreter
      required the insertion of only a single function call.
      
      I hope soonish to be able to release it as an Open Source app.
      
      This problem I describe occurs in the Simple Tk I am using for my
      program, but also in the Simple Tk app itself right out of the box (I
      mean the .gz tarball compiled with Code Warrior Pro 4, I purchased the
      Tcl Blast CD, but it doesn't have the libraries precompiled on it).
      
      I've also spent about 6 months time (since I upgraded from CW 11, to Pro
      4, which won't compile 7.6/4.0) trying to figure it out. Both in Simple
      Tk and in my app. I'm afraid this has lead to so real close the windows
      and lock the doors kind of moments for me.
      
      Is this a problem you've seen before, has anything like it been reported
      before? Is Tcl/Tk 8.1 available on Macs and would that fix my problems
      (Tcl/Tk 8.0.5 didn't appear to be)? I've looked at the Mac.Tcl mailing
      list on the consortium's site, but can't tell if the link is a subscribe
      to list "mailto" or the list itself. Are there any sources of
      information, or people who might know anything about this whom you might
      recomend?

  ReproducibleScript:
  Simple Tk (PPC) on a Mac 7600 Sys 8.5 Shell, and ToolKit work fine (all
      scripts, and tasks, no trouble), but after exiting, certain programs,
      (namely Netscape, and JPegView) will crash with a System Type 1 error if
      you pull down the file menu. 
      
      Is repeatable on my Powerbook G3 running Sys 8.0.

  ObservedBehavior:
  At first, this behavior also occured while Simple Tk (PPC) was running,
      but rebuilding the project Tk_MDEF.* fixed that.
      
      So, I'm suspecting this is a resources elated problem.

  DesiredBehavior:
  I'd like very much to run Simple Tk, quit and restart several times,
      without any OS troubles. *S*



  This behavior does not exist when testing on a PowerMac G4
  running OS 8.6.  Perhaps the fix went away with the new
  version.  It is possible that it was related to Tcl using
  too much stack before. 
  -- 11/16/1999 hobbs


tkt_uuid: 703697ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 82. X11 Emulation
priority: 3 Low
foundin: obsolete: 8.4.2
resolution: Fixed
title: Wrong init in XGetImage W32
comment:
  Hi I noticed folowing initializers in XGetimage




  infoPtr->bmiHeader.biCompression = BI_RGB;


  infoPtr->bmiHeader.biCompression = 0;




  This should actually be :




  infoPtr->bmiHeader.biCompression = BI_RGB;     
  infoPtr->bmiHeader.biSizeImage = 0;




  Luckily BI_RBG has the value 0, but you never know if 
  this behaveour changes through compiler versions.


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




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


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


  Name:

  George Petasis



  DesiredBehavior:

  Two things:



  1) winfo istoplevel win

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

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

  which is kind ackward...



  2) winfo toplevels

  An easy way to get all toplevels...





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

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


tkt_uuid: 220563ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: winfo interps returns empty string on Win95
comment:
  OriginalBugID: 2403 Bug
  Version: 8.0.5
  SubmitDate: '1999-07-19'
  LastModified: '1999-08-20'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  FixedDate: '1999-08-20'
  FixedInVersion: 8.2


  Name:
  Alain Wittmann

  ObservedBehavior:
  winfo returns an empty string on my PC running on Windows 95

  DesiredBehavior:
  I expect to see at least one interpreter in the list.



  winfo interps was stubbed out for 8.0 as send was not yet available.
  It was added temporarily in 8.1, but later replaced with the dde
  command which has become the standard for send on Windows.  See the
  docs on how to use it like send. 
  -- 08/20/1999 hobbs


tkt_uuid: 564897ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: application doesn't activate
comment:
  If yours is an embedded application, clicking a widget in 
  a Tk window may not activate your application.  It will fail 
  to activate it if your main window is a Windows window.  

  Following is some code from the WmProc function in 
  the tkWinWm.c file that I found solves the problem.  

  case WM_MOUSEACTIVATE: {
      ActivateEvent *eventPtr;
      winPtr = GetTopLevel((HWND) wParam);

      /*
       * If you have Tcl embedded in a C 
  application, 
       * your Windows windows may be above 
  your Tcl windows 
       * in the window hierarchy.  In this case, 
  the message 
       * goes to the main application window.  
  Since the application 
       * window is above all the Tk windows, and 
  isn't a Tk window itself, 
       * when we try to "get its toplevel" we get 
  a null pointer. 
       *      The result is that the applicate 
  doesn't activate 
       * if we click a widget in the application.  
  The !winPtr || portion 
       * ensures that the message is passed 
  through and 
       * the application activates. 
       */
      if (!winPtr || winPtr && (TkGrabState
  (winPtr) != TK_GRAB_EXCLUDED)) {
  /*
   * This allows us to pass the 
  message onto the
   * native menus [Bug: 2272]
   */
  result = DefWindowProc(hwnd, 
  message, wParam, lParam);
  goto done;
      }


  I hope that correct operation of Tk in an embedded 
  context is a priority for the Tcl community.  


                                           Regards, 

                                           Rick


tkt_uuid: 1677608fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Fixed
title: grid crash due to list shimmer
comment:
  Following script crashes:

  set i {0 mm}
  grid rowconfigure . $i -minsize $i

  When a "pixels" value is pulled
  from $i, the List intrep is shimmered
  away, which invaidates the lObjv
  array.  When we next try to access it...
  CRASH!


tkt_uuid: 1389270fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 4
foundin: None
resolution: Fixed
title: [event generate <FocusIn>] should work
comment:
  FocusIn and FocusOut events generated by [event
  generate] are now filtered out in TkFocusFilterEvent
  unless their send_event field is assigned some magic
  value. 

  Fortunately numeric send_event is allowed, but it would
  be great if the appropriate magic value were inserted
  as a default for send_event field by
  TkBind.c:HandleEventGenerate(). 

  I recognise that TkFocusFilterEvent does the important
  work of not letting the weird Xwindow notion of focus
  influence Tk's behavior. However, if an application
  writer wants to generate FocusIn or FocusOut (perhaps
  to make some widget think it has focus), he _should_ be
  allowed to do so without exploring TkFocus.c to find
  some GENERATED_EVENT_MAGIC there. It would save me a
  few hours today if it just worked.


tkt_uuid: 814788ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Out of Date
title: No multi-line Button text, Mac Aqua
comment:
  In Aqua Tk 8.4.4 only the first line of text is shown
  in a Button
  set to show two lines of text.  The following wish script

  button .b -text "some
  text"
  pack .b

  produces a button showing just the word "some".

  On Linux, Windows, SGI Irix and HP Alpha systems Tk
  8.4.4 shows both lines in the button.


tkt_uuid: 220711ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: can't read: tkPriv(listboxSelection/listboxPrev) if Shift-Arrow-Down is pressed
comment:
  OriginalBugID: 4496 Bug
  Version: 8.2.3
  SubmitDate: '2000-03-23'
  LastModified: '2000-03-23'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: SuSE-Linux
  FixedDate: '2000-03-23'
  FixedInVersion: 8.3


  Name:

  Stefan Jäger


  Comments:

  similar results with Linux


  ReproducibleScript:

  listbox .l -selectmode extended

  pack .l

  .l insert end 1 2 3 4 5

  .l activate 0

  focus .l


  ObservedBehavior:

  Now  try to select the first lines with pressing <shift arrow-key down> two times:

  You get:


  can't read "tkPriv(listboxSelection)": no such element in array

      while executing

  "lsearch $tkPriv(listboxSelection) $i"

      ("extended" arm line 15)

      invoked from within

  "switch [$w cget -selectmode] {

  browse {

      $w selection clear 0 end

      $w selection set $el

      set tkPriv(listboxPrev) $el

      event generate ..."

      (procedure "tkListboxMotion" line 7)

      invoked from within

  "tkListboxMotion $w [$w index active]"

      (procedure "tkListboxExtendUpDown" line 7)

      invoked from within

  "tkListboxExtendUpDown .l 1

  "

      (command bound to event)


  DesiredBehavior:

  see the elements selected.




  This has already been fixed in 8.3 (see changes in listbox.tcl). 
  -- 03/23/2000 hobbs


tkt_uuid: 220871ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 4
foundin: obsolete: 8.5a1
resolution: Out of Date
title: Errors generated by top-level Mac menus not caught
comment:
  OriginalBugID: 3231 Bug
  Version: 8.0.5
  SubmitDate: '1999-10-28'
  LastModified: '1999-11-03'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  Machine: Power PC


  Name:
  Peter Nye

  ReproducibleScript:
  . configure -menu .mainMenu
      menu .mainMenu 
      .mainMenu add cascade -label "File" -menu .mainMenu.file
      menu .mainMenu.file
      .mainMenu.file add command -label "Generate Error" -command {error foo}

  ObservedBehavior:
  If I construct a menu bar by hand, and put the File menu there, it
      generates an
      error when I select "Generate Error", but not in the case above.


tkt_uuid: 219938ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: None
resolution: Duplicate
title: MS Windows NT, can't get KeyPress events when a menu is posted
comment:
  OriginalBugID: 1415 RFE
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '2000-02-10'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 3222
  OS: Windows NT
  OSVersion: Version 4.0 (Build 1381)
  Machine: X86
  ClosedDate: '2000-02-10'


  Name:
  Quackenbush, Phil

  ReproducibleScript:
  Severe impact may be an exaggeration, but not being able to get help (e.g. F1) when a menu is up severely compromises usability.

  I bound <KeyPress-F1> to a menu, but couldn't get anything.

  Checked the MS Windows implementation of menus (tkWinMenu.c - WM_MENUCHAR case in the function TkWinHandleMenuEvent in particular) and it appears I can't get any KeyPress events?



  This is really an RFE.  We provide the <<MenuSelect>> to get the
  change in menu index, but since we use native menus on Win/Mac,
  we can't promise full control over the menus.  It may be possible
  to add handling for keys in Windows. 
  -- 02/10/2000 hobbs


tkt_uuid: 3101805fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Ugly buttons for tk_messageBox and tk_chooseColor
comment:
  I discovered this problem while working with the Tk Python binding. If you create a MessageBox or ColorChooser, it uses old-style Windows 98 buttons rather than sleek new Windows 7, VIsta or XP buttons. I've heard that the same problem exists on other desktops (Gnome specifically) as well. I initially reported the issue to the Python bug tracker, and after delving into the Python source I began to see that the problem was in the underlying Tk rather than Tkinter. See the original Python issue at http://bugs.python.org/issue10171.

  This problem can be reproduced in the most recent version of Tcl (I think, I know nothing of Tcl but I downloaded the Windows ActiveTcl 8.5 binary to test this) with the following 3 lines of code:

  package require Tk
  tk_chooseColor
  tk_messageBox

  I don't know what might be causing this problem, and I can't really fix it since I don't know Tcl. However, I'm pointing out this issue so that someone who can fix it can perhaps make a patch.

  Attached is a screenshot of the ugly button behavior.


tkt_uuid: 220022ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Duplicate
title: "wm transient" maps a toplevel
comment:
  OriginalBugID: 2710 Bug
  Version: 8.2
  SubmitDate: '1999-09-10'
  LastModified: '1999-10-22'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 572
  OS: Windows 98
  Machine: X86
  ClosedDate: '1999-10-22'


  Name:
  Tim Baker

  ReproducibleScript:
  % toplevel .topa
      % wm withdraw .topa
      % toplevel .topb
      % wm withdraw .topb
      % update
      % wm transient .topb .topa

  ObservedBehavior:
  The second toplevel .topb becomes mapped, even  though the master window
      .topa is unmapped.
      This is with Tk 8.2.0 on Windows 98.

  DesiredBehavior:
  The transient window should be mapped or unmapped like the master
      window, in this cased unmapped.


tkt_uuid: 2968379fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5.8
resolution: Fixed
title: Segfault when doing dump on text peer
comment:
  A segfault occurs reliably when doing a dump -all on a text peer.
  This happens on ArchLinux 32bit and 64bit as well as with ActiveTcl on Windows 7.
  Valgrind: http://paste.tclers.tk/2008
  GDB: http://paste.tclers.tk/2010

  Code to reproduce the issue:

  text .t1
  .t1 peer create .t2
  .t2 dump -all 1.0 end


tkt_uuid: 630533ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 8
foundin: obsolete: 8.4.1
resolution: Fixed
title: TkpCloseDisplay panic
comment:
  On Linux/Alpha,  with Tcl/Tk 8.4.1:

  #FILE panic.tcl
  proc Die { win } {
      if {![string equal . $win]} { return }
      exit
  }
  bind . <Destroy> {Die %W}
  #END FILE panic.tcl

  $ wish8.4 panic.tcl
  <Use the [x] of the wm to close the . window>
  input contexts not freed before XCloseIM
  Abort

  Now for the really weird part, compare with:

  #FILE nopanic.tcl
  proc Die { win } {
      if {. ne $win} { return }
      exit
  }
  bind . <Destroy> {Die %W}
  #END FILE nopanic.tcl

  $ wish8.4 panic.tcl
  <Same [x] wm close as before works fine>


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


  Name:
  Jostein Bo

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

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

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

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

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

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



  From Nemethi:

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

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


tkt_uuid: 2821962fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Copy & paste images in Unix
comment:
     Hello,

    I have been playing today with copy and paste images in TCL-TK and
  Unix. The origin of the image is Firefox, where I open the contextual
  menu over one image and select "copy image"

  The TCL code for pasting the image is:

  package require img::png
  set data [binary format c* [selection get -selection CLIPBOARD -type
  image/png]]
  set img [image create photo -data $data]

  This code does not work in a standard wish as there is a bug in file
  tkUnixSelect.c

  After a small modification in file "tkUnixSelect.c", it works
  correctly!!

  The modification is the following:

  in function TkSelEventProc

  ...
            if (format != 32 && format != 8) {
                  char buf[64 + TCL_INTEGER_SPACE];

                  sprintf(buf,
                          "bad format for selection: wanted \"32\" or \"8\", got \"%d\"",
                          format);
                  Tcl_SetResult(retrPtr->interp, buf, TCL_VOLATILE);
                  retrPtr->result = TCL_ERROR;
                  return;
              }
              Tcl_DStringInit(&ds);
              if (format == 32) {
                  SelCvtFromX((long *) propInfo, (int) numItems, type,
                              (Tk_Window) winPtr, &ds);
              } else {
                  SelCvtFromX8((char *) propInfo, (int) numItems, type,
                              (Tk_Window) winPtr, &ds);
              }
  ....

  in function SelRcvIncrProc (a similar change)

  new function "SelCvtFromX8":

  static void
  SelCvtFromX8(
      register char *propPtr,     /* Property value from X. */
      int numValues,              /* Number of 8-bit values in property. */
      Atom type,                  /* Type of property Should not be XA_STRING
                                   * (if so, don't bother calling this function
                                   * at all). */
      Tk_Window tkwin,            /* Window to use for atom conversion. */
      Tcl_DString *dsPtr)         /* Where to store the converted string. */
  {
      /*
       * Convert each long in the property to a string value, which is
  either
       * the name of an atom (if type is XA_ATOM) or a hexadecimal
  string. We
       * build the list in a Tcl_DString because this is easier than
  trying to
       * get the quoting correct ourselves; this is tricky because atoms
  can
       * contain spaces in their names (encountered when the atoms are
  really
       * MIME types). [Bug 1353414]
       */

      for ( ; numValues > 0; propPtr++, numValues--) {
          if (type == XA_ATOM) {
              Tcl_DStringAppendElement(dsPtr,
                      Tk_GetAtomName(tkwin, (Atom) *propPtr));
          } else {
              char buf[12];

              sprintf(buf, "0x%x", (unsigned char) *propPtr);
              Tcl_DStringAppendElement(dsPtr, buf);
          }
      } 


tkt_uuid: 1616245fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: segmentation fault after call to XOpenIM
comment:
  We were able to fix a segmentation fault by commenting
  out the call to OpenIM (tkUnixEvent.c),
  in OpenIM there's a call to the function XOpenIM from the
  X11 library (libX11.a) that caused the segmentation fault
  on a Fedora Core 3 (64 bit) machine with an amd processor.
  Unfortunately we don't own the machine and don't have
  root acces on it, so we can't tell if there's an 'X Input Method' server running on that machin\
  e.


tkt_uuid: 1461523fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 9 Immediate
foundin: obsolete: 8.5a4
resolution: Out of Date
title: CVS Release - Send File/Change Display Pic (Browse) Error
comment:
  Error when sending files to user, or Changing display
  pic (Using browse function)

  This error (Sending Files) brings up the dialog :

  unknown subcommand "config": must be configurelist
      while executing
  "$f1.menu config -takefocus 1 -highlightthickness 2"
      (procedure "::tk::dialog::file::Create" line 31)
      invoked from within
  "::tk::dialog::file::Create $w TkFDialog"
      (procedure "::tk::dialog::file::" line 17)
      invoked from within
  "::tk::dialog::file:: open -filetypes {{ "All Files"
  {*} }} -parent .msg_7 -initialdir /home/kev
  -initialfile {} -title {Send file}"
      ("eval" body line 1)
      invoked from within
  "eval ::tk::dialog::file:: open $args"
      (procedure "tk_getOpenFile" line 5)
      invoked from within
  "tk_getOpenFile -filetypes $types -parent $parent
  -initialdir $starting_dir -initialfile $initialfile
  -title $title"
      (procedure "chooseFileDialog" line 18)
      invoked from within
  "chooseFileDialog "" [trans sendfile] $win_name"
      (procedure "::amsn::FileTransferSend" line 6)
      invoked from within
  "::amsn::FileTransferSend .msg_7"
      (command bound to event)









  Changing Display Pic (Pressing Browse) error:

  attachment
  '.picbrowser.__tk_filedialog.f1.menu.menu.m.main.0.icon.tick'
  already exists
      while executing
  "error "$_type '$path' already exists""
      (procedure "::contentmanager::Snit_typemethodadd"
  line 9)
      invoked from within
  "contentmanager add attachment $main $entryid icon tick
  -widget $canvas -tag $radiotickid($entryid)"
      ("radio.*" arm line 10)
      invoked from within
  "switch -regexp $_type {
  com.* {
  # Create the canvas items
  set imageid($entryid) [$canvas create image $offx
  $offy -anchor nw -tags entry$en..."
      (procedure "::pixmapmenu::Snit_methodCreateEntry"
  line 36)
      invoked from within
  ".picbrowser.__tk_filedialog.f1.menu.menu.m CreateEntry
  end radiobutton -indicatoron 0 -label {} -variable
  ::tk::dialog::file::__tk_filedialog(selectPa..."
      ("eval" body line 1)
      invoked from within
  "eval $self CreateEntry end $_type $args"
      (procedure "::pixmapmenu::Snit_methodadd" line 37)
      invoked from within
  "$w.menu add radiobutton -indicatoron 0 -label $val
  -variable $var -value $val"
      (procedure "tk_optionMenu" line 6)
      invoked from within
  "tk_optionMenu $f1.menu [format %s(selectPath)
  ::tk::dialog::file::$dataName] """
      (procedure "::tk::dialog::file::Create" line 15)
      invoked from within
  "::tk::dialog::file::Create $w TkFDialog"
      (procedure "::tk::dialog::file::" line 17)
      invoked from within
  "::tk::dialog::file:: open -filetypes {{{Image Files}
  {*.gif *.GIF *.jpg *.JPG *.bmp *.BMP *.png *.PNG}}
  {{All Files} *}} -parent .picbrowser -initiald..."
      ("eval" body line 1)
      invoked from within
  "eval ::tk::dialog::file:: open $args"
      (procedure "tk_getOpenFile" line 5)
      invoked from within
  "tk_getOpenFile -filetypes $types -parent $parent
  -initialdir $starting_dir -initialfile $initialfile
  -title $title"
      (procedure "chooseFileDialog" line 18)
      invoked from within
  "chooseFileDialog "" "" "" "" open [list [list [trans
  imagefiles] [list *.gif *.GIF *.jpg *.JPG *.bmp *.BMP
  *.png *.PNG]] [list [trans allfiles] *]]"
      (procedure "pictureChooseFile" line 4)
      invoked from within
  "pictureChooseFile"
      invoked from within
  ".picbrowser.browse invoke"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list $w invoke]"
      (procedure "tk::ButtonUp" line 22)
      invoked from within
  "tk::ButtonUp .picbrowser.browse"
      (command bound to event)







  Also shows emtpy _tkfiledialog_

  This seems to be current on latest and previous
  snapshot and has been reproduced by at least one other
  user.

  Fedora 5 - No X window compiling - Tk/TCL 8.5 


tkt_uuid: 220476ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title:
  The search function of the text widget reports incorrect number of characters when finding double-byte code.

comment:
  OriginalBugID: 1666 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-30'
  LastModified: '1999-04-02'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  RelatedBugIDs: 1056  1148
  OS: Windows NT
  OSVersion: 4.0 Japanese
  Machine: X86
  FixedDate: '1999-04-02'
  FixedInVersion: 8.1b3


  Name:
  Syd Polk

  CVS:
  03/30/1999

  ReproducibleScript:
      Initialize a text widget with some japanese text. Call the text widget
      search function to look for two japanese characters. Make sure and add a
      "-count" paramter. The variable you give the -count parameter will
      contain the number 6, not the number 2.
      



  Patch:
  Index: tkText.c
  ===================================================================
  RCS file: /cvsroot/tk/generic/tkText.c,v
  retrieving revision 1.1.4.5
  diff -r1.1.4.5 tkText.c
  1837c1837,1838
  < sprintf(buffer, "%d", matchLength);
  ---
  > sprintf(buffer, "%d", Tcl_NumUtfChars(startOfLine + matchByte,
  >         matchLength));




  PatchFiles:
      tk/generic/tkText.c
      





      There are other problems in this function also, like adding and
      subtracting 1 from byte indices. While these probably don't affect much,
      doing a regexp search starting from in the middle of a multi-byte
      sequence is probably not a good idea.
      

  This patch is close, but not quite right.  I have applied the correct fix.

  04/02/1999 15:49 - stanton -


tkt_uuid: 219944ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: focus command not returning correct window
comment:
  OriginalBugID: 1506 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-15'
  LastModified: '2000-01-06'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1505 2307
  OS: AIX
  OSVersion: 4.1 and 4.3
  Machine: RS6000
  ClosedDate: '2000-01-06'


  Name:
  Anthony Johnson
  email:  caldiver@pacbell.net

  Extensions:
  8.0p2 and 8.0.4, TclX8.0.3, TkX8.0.3

  ReproducibleScript:
     focus <-- returns NULL
     toplevel .test
     raise .test
     focus .test
     focus <-- returns NULL
  ---------------------
     toplevel .test
     raise .test
     focus .test
     update
     focus <--- returns "."
  ------------------
     update
     toplevel .test
     raise .test
     focus .test
     focus <--- returns .test
  -------------------
     update
     toplevel .test
     raise .test
     focus .test
     focus <--- returns NULL
     destroy .test
     toplevel .test
     raise .test
     focus .test
     focus <--- returns NULL
  -------------------
     update
     toplevel .test
     raise .test
     focus .test
     focus <--- returns NULL
     destroy .test
     update
     toplevel .test
     raise .test
     focus .test
     focus <--- returns NULL

  ObservedBehavior:
  Using "update idletasks" instead of "update" has the same affect as omitting it entirely. I cannot use "update" becasue I do not want to start an event loop within my proc. Even when using "update", it doesnt appear to return the correct window I last focused on. Any time a window is destroyed, the focus command returns NULL until update is executed again.

  DesiredBehavior:
  Focus should return the name of the toplevel window which last had focus.

  Tk 8.0.4 Bug

  Name:  Anthony Johnson
  email:  caldiver@pacbell.net
  Support:  None
  CVS:  Correction: focus command not returning correct window
  Synopsis:  Correction to last portion of test case

  ReproducibleScript:
  Did not update my comments in the last portion of the test case:
  OLD:
     update
     toplevel .test
     raise .test
     focus .test
     focus <--- returns NULL
     destroy .test
     update
     toplevel .test
     raise .test
     focus .test
     focus <--- returns NULL
  NEW:
     update
     toplevel .test
     raise .test
     focus .test
     focus <--- returns .test
     destroy .test
     update
     toplevel .test
     raise .test
     focus .test
     focus <--- returns .test


tkt_uuid: 220702ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: add "link" relief for buttons
comment:
  OriginalBugID: 4348 RFE
  Version: 8.3
  SubmitDate: '2000-03-08'
  LastModified: '2000-05-09'
  Severity: LOW
  Status: Released
  Submitter: ericm
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-05-09'
  FixedInVersion: 8.4a1


  It would be nice if buttons supported "link" relief:  flat normally, then raised when the mouse is over the button (ala toolbar buttons in Netscape or Word or similar).

  This would require modification to tkConfig.c (add a check for link relief for TK_OPTION_RELIEF, and a check for NULL ClientData, so that link relief can only be used on some widgets), tk.h (add #define TK_RELIEF_LINK), and tk3d.c (add "link" to reliefStrings and to the NameOfRelief/GetRelief functions) to add support for the link relief, and then some amount of work in the button drawing procedures to do the special magic for that relief.

  - eric



  I have working code for this in my work space.

  - eric
   
  -- 05/09/2000 ericm


tkt_uuid: 899010ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 9 Immediate
foundin: obsolete: 8.4.6
resolution: Fixed
title: imgPhoto-16.1 test error
comment:
  On Solaris 9, CDE 1.5:

  ==== imgPhoto-16.1 copying to self doesn't access freed
  memory FAILED
  ==== Contents of test case:

      # Bug 877950 makes this crash when trying to copy
  out of a deallocated area
      set photo [image create photo]
      $i put red -to 0 0 1000 1000
      $i copy $i -from 0 0 1000 1000 -to 500 0
      image delete $i

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: can't read "i": no such variable
      while executing
  "$i put red -to 0 0 1000 1000"
      ("uplevel" body line 4)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-16.1 FAILED

  Really should fix before 8.4.6 is released.


tkt_uuid: 220642ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: test scale-11.1 dumps core
comment:
  OriginalBugID: 3922 Bug
  Version: 8.3b1
  SubmitDate: '1999-12-22'
  LastModified: '1999-12-22'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: 5.x
  Machine: Compaq/Digital Alpha XL 300
  FixedDate: '1999-12-22'
  FixedInVersion: 8.3b1


  Name:
  Don Porter

  CVS:
  $Id: tkScale.c,v 1.9 1999/12/21 23:55:11 hobbs Exp $

  Comments:
  Revision 1.9 of tk/generic/tkScale.c introduced the bug.

  ReproducibleScript:
  # FILE: demo.tcl
      proc killScale value {
             destroy .s1
      }
      scale .s1 -from 0 -to 100 -command killScale
      pack .s1
      .s1 set 40

  ObservedBehavior:
  $ wish8.3
  % source demo.tcl
  Program received signal SIGSEGV, Segmentation fault.
  0x155556b9b04 in _XFlushInt ()
  (xxgdb) info stack
  #0  0x155556b9b04 in _XFlushInt ()
  #1  0x155556b9a38 in _XFlush ()
  #2  0x15555691fa4 in XCreatePixmap ()
  #3  0x12002c6d4 in Tk_GetPixmap (display=0x15555c536b8, d=0, width=50, height=106, depth=16) at ./tkUnixXId.c:468
  #4  0x1200fdda8 in TkpDisplayScale (clientData=0x1203b07c0) at ./tkUnixScale.c:543
  #5  0x12018a324 in TclServiceIdle () at ./../generic/tclTimer.c:692
  #6  0x1201704a0 in Tcl_DoOneEvent (flags=-3) at ./../generic/tclNotify.c:923
  #7  0x1200cafe8 in Tk_MainLoop () at ./../generic/tkEvent.c:1130
  #8  0x120018690 in Tk_MainEx (argc=1, argv=0x11ffff4b0, appInitProc=0x120017ff8 <Tcl_AppInit>, interp=0x1203169c0) at ./../generic/tkMain.c:281
  #9  0x120017fcc in main (argc=1, argv=0x11ffff4b0) at ./tkAppInit.c:77

  DesiredBehavior:
  No crash



  Fixed before release of 8.3b1 final. 
  -- 12/22/1999 hobbs


tkt_uuid: 220062ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Duplicate
title: XIM is not working on Tcl/Tk8.3b2
comment:
  OriginalBugID: 4143 Bug
  Version: 8.3b2
  SubmitDate: '2000-02-08'
  LastModified: '2000-04-16'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4280
  OS: Linux-Red Hat
  OSVersion: RedHat Linux 6.1 Japanese Edition
  Machine: Pentium II
  ClosedDate: '2000-04-16'


  Name:
  Keiichi Takahashi

  Comments:
  Jan Nijtmans Plus Patches for 8.1.1, 8.2.X supported XIM.

  DesiredBehavior:
  With the command,

  tk useinputmethods 1

  It is expected to use XIM on text input widgets such as text or entry, but it isn't working.
  Lack of this feature affects on people who use multi-byte character, Chinese, Korean, Japanese and so on.


tkt_uuid: 1591484fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 55. [focus]
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: test suite focus test 5.1 failure
comment:
  I'm building the latest cvs head, building on sparc
  solaris 2.9, using sun c compiler. I display back
  through exceed 10.0.0.12 on a windows xp machine.

  focus.test

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

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

  ---- Result was:
  .t .t {}
  ---- Result should have been (exact matching):
  .t {} {}
  ==== focus-5.1 FAILED


tkt_uuid: 570748ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 29. Colormaps and Visuals
priority: 8
foundin: obsolete: 8.4a5
resolution: Works For Me
title: Tried to free a color that isn't alloc..
comment:
  Tcl 8.4a5 && Tk 8.4a5
  Windows XP

  Wierd things occur when using the remote desktop.

  If a TK application is started on the PC, then a remote
  desktop connection is made to that PC, the TK 
  application appears with only the frame padding visible.  
  All buttons, labels, menu's entry's, text.. etc. are 
  transparent.  I am able to see the background image 
  behind.  Moving, iconifiying, and use of the application 
  do not restore its appearance to normal.  The 
  application continues to work, menu items can be seen 
  and buttons (if you can guess where they are) still 
  function.  Occasionally while closeing the application by 
  clicking on the [x] button, top right corner, I get a Tk 
  crash.  A dailog appears with "Tried to free a color that 
  isn't allocated" and then a dialog with a memory 
  address failure appears.

  a simple sample script is all that is necessary to 
  reproduce.

  button .b
  pack .b -side top


tkt_uuid: 3077986fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: Win configure: tclsh path with spaces
comment:
  tclsh85.exe is in "c:\program files\tcl8.5\bin" which is in the path variable.
  msys: sh tk8.5.9/win/configure outputs: No tclsh found on PATH

  Supposed reason:
  tk8.5.9/win/configure row 4173 replaces the path separator ":" with space.
  If there are spaces in a path component, it is also separated there by the following for loop

  Workaround: use the 8 char "PROGRA~1" version of the path.


tkt_uuid: 220545ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Boo boo in wm help page
comment:
  OriginalBugID: 2284 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-25'
  LastModified: '1999-08-08'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  FixedDate: '1999-08-08'
  FixedInVersion: 8.2


  Name:
  Christopher Nelson

  ObservedBehavior:
  The help for [wm positionfrom] says:
      
        If who is specified, it must be either program or user, ... Otherwise
      it 
        returns user or window
      
      I'm confused between "program" and "window".  Is "window" a typo?  It
      would seem to be.



  Fixed in 8.2b3 docs.  The 'window' should be 'program'. 
  -- 08/08/1999 hobbs


tkt_uuid: 3538401fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Fixed
title: Documentation: winfo/wm geometry
comment:
  winfo geometry and wm geometry return different values, yet the differences are not documented.

  I see, it is in the FAQ, but not the main documentation.

  5.7. What is the difference between wm and winfo?
  wm (short for window manager) is used for managing or finding information about toplevels, while winfo (short for widget info) is for querying info about all types of widgets.

  For example, wm geometry . will give you the size of the main toplevel, including window manager decoration, as perceived by the window manager. However, winfo geometry . returns only the size of . as perceived by Tk.


tkt_uuid: 601954ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 6
foundin: None
resolution: None
title: destroying menubuttons leaves them unpostable
comment:
  I had the following behavior reported to me, which I have 
  verified on my machine.

  Code to reproduce bug:

  #################
  proc create {} {
  menubutton .mb -text Sample -relief raised -
  menu .mb.menu
  pack .mb
  set m [menu .mb.menu -tearoff 0]
  $m add radio -label One -command {}
  $m add radio -label Two -command {}
  }

  create
  after 10000 {destroy .mb; create}
  #################

  As reported by the other user:

  "The problem occurs if the menu is still posted when the 
  menubutton is destroyed (i.e. no selection was made, or 
  the user did not click outside the window).  Under these 
  circumstance, if the menubutton is then recreated, the 
  menu is no longer dislayed properly (sometimes it won't 
  display at all).  I have tried "unpost"ing the menu before 
  destroying the menubutton but this doesn't seem to 
  have any effect.

  The version of tcl/tk I'm using is 8.4 and the platform is 
  Solaris. Try clicking on the menu button when it comes 
  up and waiting until the program destroys it -- then try to 
  open the menu again.  After some time and multiple 
  clicks the menu usually reappears -- but this behavior is 
  inconsistant and I would like it to be dismissed properly."

  I observed the same behavior on a Linux system 
  (specifically Linux 2.4.8-26mdk) with the KDE window 
  manager (other window managers not tried). I duplicated 
  the behavior using Tcl/Tk 8.3.4 and 8.4b2.

  The same code was able to crash wish (both 8.3.2 and 
  8.4b2) on Windows 2000. If the menu is posted but no 
  items are active (the mouse isn't over the menu), there's 
  no problem; it's as if nothing happened, and the 
  menubutton and menu still work fine. However, if there is 
  an active item (the mouse is over an item), the 
  destroy/create seems to occur, but then as soon as I 
  move my mouse, wish crashes.

  (I'll admit that what the user was doing isn't great 
  programming practice. But wish shouldn't crash as a 
  result.)


tkt_uuid: 691908ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: Compiling static Tcl and dynamic Tk fails on mingw Windows
comment:
  When trying to build static Tcl 8.4.1 with dynamic Tk,
  building failed as Tk tried to link against
  libtclstub84.a, while libtclsutb84s.a was available.

  This can probably be the same with non-mingw builds on
  Windows (do not have the software to check it)


tkt_uuid: 219932ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Duplicate
title: port of Tcl/Tk to Windows CE?
comment:
  OriginalBugID: 1375 RFE
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '2000-02-07'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 3509
  OS: Linux-Red Hat
  Machine: Other
  ClosedDate: '2000-02-07'


  Name:
  Jeff Richards

  DesiredBehavior:
  Probably doesn't fit.  Just curious if anyone considered porting Tcl/Tk to Windows CE.


tkt_uuid: 1109657fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 3 Low
foundin: obsolete: 8.4.9
resolution: None
title: canvas clipping of window items
comment:
  This script demonstrates what may or may not be a bug:
  window items are clipped to their parent, not to the
  canvas.  If not a bug, it could stand clarification in
  the canvas manpage.

   frame .f -bg blue
   canvas .c2 -bg red -width 100
   grid rowconfigure .f 0 -weight 1 -minsize 0
   grid rowconfigure .f 1 -weight 0 -minsize 0
   grid columnconfig .f 0 -weight 1 -minsize 0
   grid columnconfig .f 1 -weight 0 -minsize 0

   grid [canvas .f.c -bg yellow -width 100 \
      -xscrollcommand ".f.x set" -yscrollcommand ".f.y
  set"] \
          -row 0 -column 0 -sticky news
   grid [scrollbar .f.y -orient vertical -command ".f.c
  yview"] \
          -row 0 -column 1 -sticky news
   grid [scrollbar .f.x -orient horizontal -command ".f.c
  xview"] \
          -row 1 -column 0 -sticky news

   grid columnconfig . 0 -weight 1 -minsize 0
   grid columnconfig . 1 -weight 1 -minsize 0
   grid rowconfigure . 0 -weight 1 -minsize 0
   grid .f -row 0 -column 0 -sticky news
   grid .c2 -row 0 -column 1 -sticky news

   checkbutton .cb -text "012345678901234567890123456789"
  -bg green
   checkbutton .f.cb -text
  "012345678901234567890123456789" -bg green
   checkbutton .f.c.cb -text
  "012345678901234567890123456789" -bg green
   .f.c create window 0 0 -anchor nw -window .cb
   .f.c create window 0 30 -anchor nw -window .f.cb
   .f.c create window 0 60 -anchor nw -window .f.c.cb


tkt_uuid: 791151ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Improved 3D borders on Unix
comment:
  This patch improves the look of 3D borders by drawing
  them in a more rounded fashion, like Windows.  

  This only affects raised, and sunken borders. 

  For sunken borders it draws the top/left border as
  "darkColor blackColor" and the bottom/right border as
  "bgColor lightColor".

  For raised borders it draws the top/left border as
  "lightColor bgColor" and the bottom/right border as
  "darkColor blackColor".

  To apply:

  cd TK_SRC_DIR
  patch -p1 < tk-unix-3d-borders.patch


tkt_uuid: 1019085fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: bind-22.163 failure
comment:
  Tk: v8.5a2 HEAD at 30-08-04
  OS: WinXPsp1
  Built with makefile.vc using VC7

  just one test overlooked in TIP#165, attached patch 
  adds extra '-data' option to expected result.

  ==== bind-22.163 HandleEventGenerate: options 
  <Key> -xyz 1 FAILED
  ==== Contents of test case:

  setup
  bind .b.f $event "lappend x $substitution"
  set x {}
  if [catch {eval event gen .b.f $event 
  $generator} msg] {
      set x [list 1 $msg]
  }
  set x
      
  ---- Result was:
  1 {bad option "-xyz": must be -when, -above, -
  borderwidth, -button, -count, -data, -delta, -detail, -
  focus, -height, -keycode, -keysym, -mode, -override, -
  place, -root, -rootx, -rooty, -sendevent, -serial, -
  state, -subwindow, -time, -warp, -width, -window, -x, 
  or -y}
  ---- Result should have been (exact matching):
  1 {bad option "-xyz": must be -when, -above, -
  borderwidth, -button, -count, -delta, -detail, -focus, -
  height, -keycode, -keysym, -mode, -override, -place, -
  root, -rootx, -rooty, -sendevent, -serial, -state, -
  subwindow, -time, -warp, -width, -window, -x, or -y}
  ==== bind-22.163 FAILED


tkt_uuid: 220001ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: Crazy focus behavior of toplevel window
comment:
  OriginalBugID: 2310 Bug
  Version: 8.0.4
  SubmitDate: '1999-07-01'
  LastModified: '1999-08-07'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 1505
  OS: AIX
  OSVersion: 4.1, 4.3
  Machine: RS6000
  ClosedDate: '1999-08-07'


  Name:
  Anthony Johnson

  Extensions:
  8.0p2 and 8.0.4, TclX8.0.3, TkX8.0.3

  ReproducibleScript:
  Problem occurs when creating/destroying toplevel windows within the
      application.
      Problems are very inconsistent but frequent enough to make the
      application
      very annoying to use.

  ObservedBehavior:
  1. When destroying a top-level window, {destroy $curwin; raise $parent;
      focus
      $parent} has no affect. The focus is still given to the prior toplevel
      in the
      stack.
      2. When toplevel is destroyed, prior window in the stack gets raised but
      is not
      refreshed until the pointer is moved into the window (it seem this is
      only the
      behaviour with Mwm and not Cde window manager)
      3. When a toplevel is created (withdrawn, deiconified, raised), the main
      (.)
      toplevel is [sometimes] immediately raised above it for no obvious
      reason.
      4. Miscellandous windows, even those that are not part of the
      application (or
      even Tk), get raised when the cursor moves into them. This (mostly)
      occurs after
      a toplevel has been destroyed. The window focus policy is explicit, and
      this
      behaviour never occurs unless running the Tk application.

  DesiredBehavior:
  When a toplevel is destroyed, I expect the prior window in the stack to
      be
      raised, refreshed, and focused. But, even explicit raise/focus command
      do nto
      appear to work as expected.


tkt_uuid: 445469ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: tk without tcl
comment:
  * separate the tcl and tk stuff so we have:

  * tk - an widget set library
  * tcl - tcl script interpreter
  * wish - tcl/tk runtime system based
  on tcl and tk

  *  tk should build completely without tcl


tkt_uuid: 2908379fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: ttk:* widgets - selection text illegible on Mac OS X
comment:
  peterc reports in #2908368:

  Selected text on Mac needs have the font as a light colour (white?) rather
  than black, otherwise it's unreadable: eg,

  http://pc.autons.net/stuff/ttk_treeview_unreadable_macosx.png

  and reports on the chat that ttk::entry widgets also have the same problem.

  I can't tell which (if any) of the kThemeTextColor* constants in Appearance.h is the right one to use.  das?


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

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


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


  Name:
  Warren Dodge

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

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

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

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



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


tkt_uuid: 917195ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 4
foundin: None
resolution: None
title: TkMacOSXXPutPixel() / tkdvi
comment:
  Submitted by Matthieu Quignard (quignard@loria.fr) as 
  requested by Daniel A. Steffen (das)

  Context : building tkdvi (0.4) by Anselm Lingnau, on MacOS 
  X (10.2.8) with Tcl/Tk Aqua (8.4.6).

  Configure :
  set tcldir=/Library/Frameworks/Tcl.framework/Versions/
  Current
  set tclincdir=$tcldir/Headers
  set tkdir=/Library/Frameworks/Tk.framework/Versions/
  Current
  set tkincdir=$tkdir/Headers
  set kpathdir=/sw/lib
  set kpathincdir=/sw/include/kpathsea
  (kpathsea got from fink tetex-dev)

  ./configure --with-tcl=$tcldir
  --with-tclinclude=$tclincdir --
  with-tk=$tkdir --with-tkinclude=$tkincdir --with-
  kpathsea=$kpathdir 
  --with-kpathseainclude=$kpathincdir --enable-debug --
  disable-threads

  Fix the Makefile in ./dvi :
  * Add -DHAVE_PROTOTYPES=1 to compile with gcc 3.3 and 
  remove -DUSE_STUBS_TK=1 -DUSE_STUBS_TCL=1
  * link with -L/Library/Frameworks/Tk.framework/Versions/
  8.4 -L/Library/Frameworks/Tcl.framework/Versions/8.4 -
  framework Tcl -framework Tk -lpthread -framework 
  CoreFoundation

  Compiling and linking are succesfull.

  Testing (tkdvi testdvi/mini) leads to Segmentation fault.

  Here is the crash report :
  Date/Time:  2004-03-16 10:12:24 +0100
  OS Version: 10.2.8 (Build 6R73)
  Host:       vercors.loria.fr

  Command:    Wish Shell
  PID:        2138

  Exception:  EXC_BAD_ACCESS (0x0001)
  Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xffff0000

  Thread 0 Crashed:
   #0   0x91ad9754 in SetCPixel
   #1   0x0b094518 in TkMacOSXXPutPixel
   #2   0x01338fc0 in GlyphToImageShrink
   #3   0x013391c4 in RenderGlyph
   #4   0x013326fc in Dvi_DoInterpret
   #5   0x01339a58 in DviImgDisplay
   #6   0x0b03b044 in Tk_RedrawImage
   #7   0x0b013bac in DisplayImage
   #8   0x0b00ef5c in DisplayCanvas
   #9   0x0a066f74 in TclServiceIdle
   #10  0x0a056910 in Tcl_DoOneEvent
   #11  0x0b033628 in MapFrame
   #12  0x0a066f74 in TclServiceIdle
   #13  0x0a056910 in Tcl_DoOneEvent
   #14  0x0b02d2f8 in Tk_MainLoop
   #15  0x0b04ab50 in Tk_MainEx
   #16  0x00010180 in 0x10180
   #17  0x0000ffa8 in 0xffa8
   #18  0x0000fe28 in 0xfe28

  Thread 1:
   #0   0x9002568c in select
   #1   0x0b08a658 in NotifierThreadProc
   #2   0x90020c28 in _pthread_body

  PPC Thread State:
    srr0: 0x91ad9754 srr1: 0x0200f030                vrsave: 
  0x00000000
     xer: 0x20000000   lr: 0x91ad9740  ctr: 0x902216d0   mq: 
  0x00000000
      r0: 0x91ad9740   r1: 0xbfffef80   r2: 0x01436788   r3: 
  0x00000000
      r4: 0x00000000   r5: 0xbffff048   r6: 0x69012501   r7: 
  0x0133c9d8
      r8: 0x0128623c   r9: 0xffff0000  r10: 0x0133c8d8  r11: 
  0xa1a50cd0
     r12: 0x902216d0  r13: 0x00000000  r14: 0x00000000  
  r15: 0x00000000
     r16: 0xbffff184  r17: 0xbffff180  r18: 0x0140ce08  r19: 
  0x00000005
     r20: 0x00000000  r21: 0x01286234  r22: 0x00000000  
  r23: 0x00000008
     r24: 0x00000039  r25: 0xbffff048  r26: 0x00000000  r27: 
  0x00000000
     r28: 0x69012501  r29: 0x00000000  r30: 0x0129be08  
  r31: 0x01338d3c


tkt_uuid: 634864ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 9 Immediate
foundin: obsolete: 8.5a0
resolution: Fixed
title: invalid images in [images names]
comment:
  This started out as an RFE 633300
  /tracker/?func=detail&aid=633300&group_id=12997&atid=362997
  but I think the problem may be somewhat different. I'll
  rephrase the problem and have attached a Tcl script
  that shows it.

  The problem is that if you [image delete] an image 
  that is being used by a Tk widget, the reference to the
  widget
  stays in [image names] even though a config in the image
  results in a "invalid command name" error.

  The bug is:
  1) deleting an image when a widget is using it
  results in an incomplete deletion, and/or
  2) [images names] is returning a list with images
  that results in an error when queried by configure.

  I believe this is platform and version independent.
  Tested under 8.3.3 under Windows and 8.3.5 under Linux.


tkt_uuid: 837300ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a0
resolution: Fixed
title: Infinite sequences of events in tkTextDisp.c
comment:
  The test file textDisp.test hangs in a state where it
  is still handling events while executing textDisp-9.2
  on Linux/*x86 with display sent to an SGI O2 running
  IRIX6.5 over SSH.  This is *bad* since it impacts upon
  the whole test suite's running to completion!


tkt_uuid: 220196ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: HPUX - drag slides right!
comment:
  OriginalBugID: 2160 Bug
  Version: 8.0.5
  SubmitDate: '1999-06-03'
  LastModified: '2000-01-29'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: HPUX 10.20
  Machine: Other
  ClosedDate: '2000-01-29'


  Name:
  Graham

  CustomShell:
  prefix=/usr/local/99

  Comments:
  In tkined, I also have problems creating a new node on the screen.
      It simply isn't there (workd OK on Solaris-7)
      
      I also had to create the link to libX11:
      cd /usr/lib/X11R5; ln -s libX11.1 libX11.sl

  ReproducibleScript:
  Demo/Canvas/ArrowHead

  ObservedBehavior:
  After moving a point it is in the correct place,
      during the manipulation, the object slides right
      You move up/down/left, it moves right
      This also happens in tkined



  This seems to relate more to a Tk application (tkined), not the core.
  Testing the Canvas->Arrowhead demo on HP works correctly for me.  If
  there is more to this, then we need to get more info. 
  -- 01/29/2000 hobbs


tkt_uuid: 516751ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 25. Built-in Bitmaps
priority: 5 Medium
foundin: None
resolution: None
title: ASCII to XBM conversion script
comment:
  Attached is the Tcl source to convert ASCII art
  diagrams like:
  <pre>
  @@@@@
  .@@@.
  ..@..
  </pre>

  into XBM format suitable for passing into [image create
  bitmap -data ...].  This script is prompted by TIP 71
  and is submitted as an
  alternative to the suggestion of simply adding more
  hardcoded
  bitmaps into Tk.

  Eric Melski


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

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

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



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

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

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



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

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

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



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

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

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



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

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

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



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

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

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


tkt_uuid: 220463ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: "window" format from Img 1.2b1 doesn't work with Tk8.1b2
comment:
  OriginalBugID: 1575 RFE
  Version: 8.1b2
  SubmitDate: '1999-03-22'
  LastModified: '2000-02-08'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 4060
  OS: Other
  Machine: NA
  FixedDate: '2000-02-08'
  FixedInVersion: 8.3


  Name:

  Jan Nijtmans


  CVS:

  21 Mar 1998


  ReproducibleScript:

      The reason why this doesn't work is because there is no way in the

      fileMatchProc and stringMatchProc functions to retreive the

      interpreter where the request came from. The patch I am

      submitting solves this problem, by adding an additional

      "interp" argument to the above two callback functions.


      The "window" format handler is the only handler using this,

      for other handlers it has no effect. It is binary compatible

      with Tk8.0.x, but not necessary source compatible. However,

      this potential source incompatibly is very easy to solve

      (which is already done in Img).


  Patch:

  *** generic/tk.h.origSat Mar 20 14:40:10 1999

  --- generic/tk.hSat Mar 20 14:42:53 1999

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

  *** 1060,1068 ****


    typedef struct Tk_PhotoImageFormat Tk_PhotoImageFormat;

    typedef int (Tk_ImageFileMatchProc) _ANSI_ARGS_((Tcl_Channel chan,

  ! char *fileName, char *formatString, int *widthPtr, int *heightPtr));

    typedef int (Tk_ImageStringMatchProc) _ANSI_ARGS_((char *string,

  ! char *formatString, int *widthPtr, int *heightPtr));

    typedef int (Tk_ImageFileReadProc) _ANSI_ARGS_((Tcl_Interp *interp,

    Tcl_Channel chan, char *fileName, char *formatString,

    Tk_PhotoHandle imageHandle, int destX, int destY,

  --- 1060,1068 ----


    typedef struct Tk_PhotoImageFormat Tk_PhotoImageFormat;

    typedef int (Tk_ImageFileMatchProc) _ANSI_ARGS_((Tcl_Channel chan,

  ! char *fileName, char *formatString, int *widthPtr, int *heightPtr, Tcl_Interp *interp));

    typedef int (Tk_ImageStringMatchProc) _ANSI_ARGS_((char *string,

  ! char *formatString, int *widthPtr, int *heightPtr, Tcl_Interp *interp));

    typedef int (Tk_ImageFileReadProc) _ANSI_ARGS_((Tcl_Interp *interp,

    Tcl_Channel chan, char *fileName, char *formatString,

    Tk_PhotoHandle imageHandle, int destX, int destY,

  *** generic/tkImgGIF.c.origSat Mar 20 14:48:06 1999

  --- generic/tkImgGIF.cSat Mar 20 14:53:01 1999

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

  *** 76,88 ****

     */


    static int      FileMatchGIF _ANSI_ARGS_((Tcl_Channel chan, char *fileName,

  !     char *formatString, int *widthPtr, int *heightPtr));

    static int      FileReadGIF  _ANSI_ARGS_((Tcl_Interp *interp,

        Tcl_Channel chan, char *fileName, char *formatString,

        Tk_PhotoHandle imageHandle, int destX, int destY,

        int width, int height, int srcX, int srcY));

    static intStringMatchGIF _ANSI_ARGS_(( char *string,

  !     char *formatString, int *widthPtr, int *heightPtr));

    static intStringReadGIF _ANSI_ARGS_((Tcl_Interp *interp, char *string,

        char *formatString, Tk_PhotoHandle imageHandle,

        int destX, int destY, int width, int height,

  --- 76,88 ----

     */


    static int      FileMatchGIF _ANSI_ARGS_((Tcl_Channel chan, char *fileName,

  !     char *formatString, int *widthPtr, int *heightPtr, Tcl_Interp *interp));

    static int      FileReadGIF  _ANSI_ARGS_((Tcl_Interp *interp,

        Tcl_Channel chan, char *fileName, char *formatString,

        Tk_PhotoHandle imageHandle, int destX, int destY,

        int width, int height, int srcX, int srcY));

    static intStringMatchGIF _ANSI_ARGS_(( char *string,

  !     char *formatString, int *widthPtr, int *heightPtr, Tcl_Interp *interp));

    static intStringReadGIF _ANSI_ARGS_((Tcl_Interp *interp, char *string,

        char *formatString, Tk_PhotoHandle imageHandle,

        int destX, int destY, int width, int height,

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

  *** 165,177 ****

     */


    static int

  ! FileMatchGIF(chan, fileName, formatString, widthPtr, heightPtr)

        Tcl_Channel chan;/* The image file, open for reading. */

        char *fileName;/* The name of the image file. */

        char *formatString;/* User-specified format string, or NULL. */

        int *widthPtr, *heightPtr;/* The dimensions of the image are

     * returned here if the file is a valid

     * raw GIF file. */

    {

    return ReadGIFHeader(chan, widthPtr, heightPtr);

    }

  --- 165,178 ----

     */


    static int

  ! FileMatchGIF(chan, fileName, formatString, widthPtr, heightPtr, interp)

        Tcl_Channel chan;/* The image file, open for reading. */

        char *fileName;/* The name of the image file. */

        char *formatString;/* User-specified format string, or NULL. */

        int *widthPtr, *heightPtr;/* The dimensions of the image are

     * returned here if the file is a valid

     * raw GIF file. */

  +     Tcl_Interp *interp;/* not used */

    {

    return ReadGIFHeader(chan, widthPtr, heightPtr);

    }

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

  *** 393,403 ****

     */


    static int

  ! StringMatchGIF(string, formatString, widthPtr, heightPtr)

        char *string;/* the string containing the image data */

        char *formatString;/* the image format string */

        int *widthPtr;/* where to put the string width */

        int *heightPtr;/* where to put the string height */

    {

        unsigned char header[10];

        int got;

  --- 394,405 ----

     */


    static int

  ! StringMatchGIF(string, formatString, widthPtr, heightPtr, interp)

        char *string;/* the string containing the image data */

        char *formatString;/* the image format string */

        int *widthPtr;/* where to put the string width */

        int *heightPtr;/* where to put the string height */

  +     Tcl_Interp *interp;/* not used */

    {

        unsigned char header[10];

        int got;

  *** generic/tkImgPPM.c.origSat Mar 20 14:47:59 1999

  --- generic/tkImgPPM.cSat Mar 20 14:54:11 1999

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

  *** 39,45 ****


    static intFileMatchPPM _ANSI_ARGS_((Tcl_Channel chan,

        char *fileName, char *formatString,

  !     int *widthPtr, int *heightPtr));

    static intFileReadPPM  _ANSI_ARGS_((Tcl_Interp *interp,

        Tcl_Channel chan, char *fileName,

        char *formatString, Tk_PhotoHandle imageHandle,

  --- 39,45 ----


    static intFileMatchPPM _ANSI_ARGS_((Tcl_Channel chan,

        char *fileName, char *formatString,

  !     int *widthPtr, int *heightPtr, Tcl_Interp *interp));

    static intFileReadPPM  _ANSI_ARGS_((Tcl_Interp *interp,

        Tcl_Channel chan, char *fileName,

        char *formatString, Tk_PhotoHandle imageHandle,

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

  *** 86,98 ****

     */


    static int

  ! FileMatchPPM(chan, fileName, formatString, widthPtr, heightPtr)

        Tcl_Channel chan;/* The image file, open for reading. */

        char *fileName;/* The name of the image file. */

        char *formatString;/* User-specified format string, or NULL. */

        int *widthPtr, *heightPtr;/* The dimensions of the image are

     * returned here if the file is a valid

     * raw PPM file. */

    {

        int dummy;


  --- 86,99 ----

     */


    static int

  ! FileMatchPPM(chan, fileName, formatString, widthPtr, heightPtr, interp)

        Tcl_Channel chan;/* The image file, open for reading. */

        char *fileName;/* The name of the image file. */

        char *formatString;/* User-specified format string, or NULL. */

        int *widthPtr, *heightPtr;/* The dimensions of the image are

     * returned here if the file is a valid

     * raw PPM file. */

  +     Tcl_Interp *interp;/* not used */

    {

        int dummy;


  *** generic/tkImgPhoto.c.origSat Mar 20 14:43:24 1999

  --- generic/tkImgPhoto.cSat Mar 20 14:45:06 1999

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

  *** 3058,3064 ****

        (void) Tcl_Seek(chan, 0L, SEEK_SET);


        if ((*formatPtr->fileMatchProc)(chan, fileName, formatString,

  !     widthPtr, heightPtr)) {

    if (*widthPtr < 1) {

        *widthPtr = 1;

    }

  --- 3058,3064 ----

        (void) Tcl_Seek(chan, 0L, SEEK_SET);


        if ((*formatPtr->fileMatchProc)(chan, fileName, formatString,

  !     widthPtr, heightPtr, interp)) {

    if (*widthPtr < 1) {

        *widthPtr = 1;

    }

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

  *** 3148,3154 ****

    }

    if ((formatPtr->stringMatchProc != NULL)

    && (*formatPtr->stringMatchProc)(string, formatString,

  ! widthPtr, heightPtr)) {

        break;

    }

        }

  --- 3148,3154 ----

    }

    if ((formatPtr->stringMatchProc != NULL)

    && (*formatPtr->stringMatchProc)(string, formatString,

  ! widthPtr, heightPtr, interp)) {

        break;

    }

        }


  PatchFiles:

      tk.h tkImgPhoto.c tkImgPPM.c tkImgGIF.c




  This is handled by the patch applied from 4060 for 8.3.0. 
  -- 02/08/2000 hobbs


tkt_uuid: 1611359fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 05. Canvas Items
priority: 8
foundin: TIP Implementation
resolution: Accepted
title: TIP#119: Rotated text for canvas
comment:
  This patch is a partial implementation of TIP#119, being for UNIX/X11 only. Needs Windows and OSX/Aqua implementations.

  Thanks to Simon Geard for recovering the patch (which had been lost) and upgrading it to work with 8.5. :-)

  Includes copy of xvertext 5.0; I think the license is Tcl/Tk-compatible.


tkt_uuid: 3102739fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Fixed
title: de.msg misses %OK used by tk_messageBox
comment:
  Under Linux (or any platform using the Tcl-Implementation of tk_messageBox) :
  % package require Tk
  % proc ::msgcat::mcunknown args {
  puts "mcunknown $args"
  return [lrange $args 1 end]
  }
  % tk_messageBox
  mcunknown de_de %OK
  ok

  Thus the line 
  ::msgcat::mcset de "&OK"
  is missing in
  lib/tk8.5/msgs/de.msg


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

  The software should allow a 1 pixel wide selection.

  Ryan P. Casey


tkt_uuid: 1591493fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: textImage test case failure on cvs head
comment:
  tk 8.5 cvs head built on solaris 2.9 with sun c
  compiler, test suite display back via exceed 10.0.0.12
  on win xp.

  textImage.test

  ==== textImage-3.2 delayed image management FAILED
  ==== Contents of test case:

          catch {
              image create photo small -width 5 -height 5
              small put red -to 0 0 4 4
          }
          catch {destroy .t}
          text .t -font test_font -bd 0
  -highlightthickness 0 -padx 0 -pady 0
          pack .t
          .t image create end -name test
          update
          set result ""
          lappend result [.t bbox test]
          .t image configure test -image small -align top
          update
          lappend result [.t bbox test]

  ---- Result was:
  {0 8 0 0} {0 0 5 5}
  ---- Result should have been (exact matching):
  {} {0 0 5 5}
  ==== textImage-3.2 FAILED


tkt_uuid: 1327471fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 9 Immediate
foundin: obsolete: 8.4.19
resolution: Wont Fix
title: Stickyness of Unix menus is feature change
comment:
  In 8.4.10, a change was introduced in menu.tcl, which
  made Unix popup menus stay open when the mouse button
  was released over a non-active item or the menu border.

  This is a feature change that breaks the previous Unix
  popup menu behaviour. Refer to menu.n which states:
  "When a button is released over a menu, the active
  entry (if any) is invoked.
  The menu also unposts unless it is a torn-off menu."

  Rather, the previous behaviour should be retained.


tkt_uuid: 220014ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Duplicate
title: Tk crashes if you keep resizing menu bars with mouse
comment:
  OriginalBugID: 2622 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '2000-01-07'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3377
  OS: Solaris
  Machine: Other
  ClosedDate: '2000-01-07'


  Name:
  Giorgos Petasis

  ReproducibleScript:
  Just start the Tk demo, and select the menu demo. Try to minimise the
      menu bar. If you keep for a while, enlarging and minimasing the 
      menu bar, at the end will get the following X error:
      X Error of failed request:  BadValue (integer parameter out of range for
      operation)
        Major opcode of failed request:  12 (X_ConfigureWindow)
        Value in failed request:  0x0
        Serial number of failed request:  14043
        Current serial number in output stream:  14044 
      
      This happen under Solaris 2.6 and Redhat Linux 6.0, although it is far
      easier to get this error under linux than solaris...


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


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

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





  unknown color name ""

      while executing

  "winfo rgb . [lindex $value 3]"

      (procedure "tkRecolorTree" line 10)

      invoked from within

  "tkRecolorTree $child c"

      (procedure "tkRecolorTree" line 22)

      invoked from within

  "tkRecolorTree $child c"

      (procedure "tkRecolorTree" line 22)

      invoked from within

  "tkRecolorTree . new"

      (procedure "tk_setPalette" line 64)

      invoked from within

  "tk_setPalette gray80"





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





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

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

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





    Bill





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

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

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

  proc tk_setPalette {args} {

       global tkPalette

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

  +   return

  +    }

  +

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

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



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


tkt_uuid: 1236847fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 7 High
foundin: obsolete: 8.4.9
resolution: Fixed
title: tk_getOpenFile -initialdir {} fails on Aqua
comment:
  tk_getOpenFile -initialdir {} 
  uses a sensible default directory on unix, but fails with unknown 
  directory "" on Aqua Tcl/Tk

  This is with 8.4.9. I haven't yet tried it with 8.4.11 (8.4.10 was 
  unusable on Aqua due to a label bug and the 8.4.11 Mac binaries 
  haven't come out yet).


tkt_uuid: 220766ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: tk_getOpen/SaveFile silently fail with odd input
comment:
  OriginalBugID: 6369 Bug
  Version: 8.4a1
  SubmitDate: '2000-10-17'
  LastModified: '2000-10-18'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  OSVersion: win 2000 pro sp1
  FixedDate: '2000-10-18'
  FixedInVersion: 8.4a2


  Name:
  Vince Darley

  CVS:
  latest

  CustomShell:
  My trace patch is applied

  ReproducibleScript:
  tk_getSaveFile -initialfile "C:/x:x"
  tk_getOpenFile -initialfile "C:/x:x"

  ObservedBehavior:
  Both of the above calls simply return "" without ever showing a dialog to the user at all.

  DesiredBehavior:
  I would expect them either to (i) throw an error (illegal 'initialfile' specification) or (ii) ignore the initial file and show a dialog anyway.



  The code that invokes the native dialogs on Windows was not checking for error return values from those dialogs.  In this case, the open file/save file dialog was returning an "invalid filename" error, but it was being ignored.  I added error checking for these and for the other common dialogs (choose color, choose directory) to catch the error cases, display an error message in the interp and return TCL_ERROR instead of TCL_OK.

  Thanks for reporting the bug.  The fix will be in 8.4a2.

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

  -- 10/18/2000 ericm


tkt_uuid: 220564ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Further info: unicode crash with Adobe G2 fonts
comment:
  OriginalBugID: 2406 Bug
  Version: 8.1.1
  SubmitDate: '1999-07-19'
  LastModified: '2000-02-08'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2405
  OS: Windows 95
  OSVersion: OSR3+IE5.0
  Machine: X86
  FixedDate: '2000-02-08'
  FixedInVersion: 8.3


  Name:
  Kevin Kenny

  CVS:
  * RCS: @(#) $Id: tkWinFont.c,v 1.5 1999/04/16 01:51:51 stanton Exp $

  CustomShell:
  Patched as above

  ReproducibleScript:
  #  The bug report that I submitted earlier today contains a questionable
      patch.
      # Pleas apply the attached one instead.

  ObservedBehavior:
  # The bad patch causes the G2 fonts to match various Unicode characters
      # in the range 0x0100-0x0fff, incorrectly

  DesiredBehavior:
  # The symbol fonts should use the symbol encoding only for 8-bit
      characters

  Patch:
  *** Tcl8.1/src/tk8.1/win/tkWinFont.cThu Apr 29 15:38:42 1999
  --- Tcl8.1-from-source/src/tk8.1/win/tkWinFont.cSat Jul 17 17:25:20 1999
  ***************
  *** 2295,2304 ****
         */
    
        for (i = 0; i < segCount; i++) {
  ! if ((startCount[i] & 0xff00) == 0xf000) {
        startCount[i] &= 0xff;
  - }
  - if ((endCount[i] & 0xff00) == 0xf000) {
        endCount[i] &= 0xff;
    }
        }
  --- 2295,2303 ----
         */
    
        for (i = 0; i < segCount; i++) {
  ! if ( ( startCount[i] & 0xff00 ) == 0xf000
  !      && ( endCount[i] & 0xff00 ) == 0xf000 ) {
        startCount[i] &= 0xff;
        endCount[i] &= 0xff;
    }
        }

  PatchFiles:
  tkWinFont.c



  Patch applied, although I don't have a G2 font to test the change.
  The fix is applied for 8.3.0. 
  -- 02/08/2000 hobbs


tkt_uuid: 3600260fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Fixed
title: Errors in new virtual event definitions
comment:
  library/tk.tcl (trunk and core-8-6-0)

  The virtual event <<SelectPrevPara>> is defined twice for each windowing system.
  In each case, the second definition should be for <<SelectNextPara>>.


tkt_uuid: 3205260fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: [wm manage] crash
comment:
  Under windows, using [wm manage] on a frame containing a Tkhtml3 widget crashes.
  In fact, RemapWindows() in win/tkWinWm.c checks that the class of window is not "Menu".
  Since Tkhtml3 creates a child window without setting the class, this check crashes.
  Checking that the class is not NULL before calling strcmp will fix it.
  The unix and macosx implementations of RemapWindows() don't check the class (tk8.5.9).


tkt_uuid: 610641ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Fixed
title: incorrect %A docs in bind(n)
comment:
  bind(n) says:

       %A   Substitutes the ASCII character 
  corresponding  to  the
            event,  or  the  empty  string  if  the 
  event  doesn't
            correspond to an ASCII character (e.g.  the 
  shift  key
            was  pressed).   XLookupString  does  all 
  the  work of
            translating from  the  event  to  an  ASCII 
  character.
            Valid only for KeyPress and KeyRelease events.

  With Unicode encodings and XIM the truth is more complex
  than that; you can get non-ASCII characters from a %A.

  Also, the subtitution is described incorrectly.  The
  substitution
  is done with Tcl_ConvertElement() which *never* substitutes
  "the empty string".  If the empty string would be
  called for,
  it gets brace-quoted, and the true substitution is
  "{}".  Since
  all string values of %-substitutions in [bind] are
  inserted with
  Tcl_ConvertElement(), there are probably other errors in
  bind(n) also, misleading users into thinking that
  %-subsitutions
  in [bind] are like those in [format], when they are not.


tkt_uuid: 627453ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 76. Widget Tour
priority: 6
foundin: None
resolution: Accepted
title: Unicode demo
comment:
  It is proposed to add the script below, or a variation of it 
  to the Tk demo to illustrate the Unicode abilities. 
  (Richard Suchenwirth)

   pack [text .t -font {Helvetica 16}]
   .t insert end "
   Arabic \uFE94\uFEF4\uFE91
  \uFEAE\uFECC\uFEDF\uFE8D\uFE94\uFEE4\uFEE0
  \uFEDC\uFEDF\uFE8D
   Trad. Chinese      \u4E2D\u570B\u7684\u6F22\u5B57
   Simplified Chinese \u6C49\u8BED
   Greek   \u0395\u03BB\u03BB\u03B7\u03BD\u03B9
  \u03BA\u03AC\
   \u03B3\u03BB\u03CE\u03C3\u03C3\u03B1
   Hebrew  \u05DD\u05D9\u05DC\u05E9\u05D5\u05E8
  \u05D9\
   \u05DC\u05D9\u05D0\u05E8\u05E9\u05D9
   Japanese \u65E5\u672C\u8A9E\u306E\u3072\u3089
  \u304C\u306A,\
   \u6F22\u5B57\u3068\u30AB\u30BF\u30AB\u30CA
   Korean          \uB300\uD55C\uBBFC\uAD6D\uC758 
  \u3CA2\u3498
   Russian         \u0420\u0443\u0441\u0441\u043A\u0438
  \u0439\
   \u044F\u0437\u044B\u043A"


tkt_uuid: 220200ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Performance in Tk poor
comment:
  OriginalBugID: 2260 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-21'
  LastModified: '2000-01-03'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4
  Machine: X86
  ClosedDate: '2000-01-03'


  Name: Dr. David Alan Gilbert

  Comments:
  I'd say this as between minor and serious - it does make Tk look quite
      poor; peoples initial reactions are 'that is because it is interpreted'
      - but that obviously isn't the case because it happens after the
      creation of the buttons because the window size appears immediatly.

  ReproducibleScript:
  for { set y 0 } { $y < 20 } { incr y } {
        for { set x 0 } { $x < 20 } { incr x } {
          button .b_${x}_${y} -text "0"
          grid .b_${x}_${y} -column $x -row $y
        }
      }

  ObservedBehavior:
  The time taken to render the window described in the script is
      significantly
      higher than I expect - OK so there are a lot of buttons and there in a
      grid - but:
        1) The window appears almost instantaneously - so it must have got the
      size done and organised the grid OK.
        2) On the machine on my desk at work (a P166 with a reasonable amount
      of RAM with Windows NT (and Linux)) I see the redraw taking quite a few
      seconds - and in particular you can see that the redraw process is at
      least two stage - you see individual rectangles being drawn where each
      button is and then see the buttons drawn on top.  The fact that it
      doesn't appear to be just taken up with the time taken to actually
      render the rectangle makes me wonder if there is another effect in here
      somewhere - perhaps something causing the OS to generate another
      redraw????

  DesiredBehavior:
  I wouldn't expect to see multiple stages of redraw and generally it
      would be faster.



  The assumption that a second redraw is likely accurate, probably
  scheduled by the reconfiguring of the size of the toplevel.  If
  you set the toplevel size to 500x700 initially, you only get the
  one redraw.  For the number of widgets being drawn, this is not
  so unexpected a speed.  In situations like these, it is better to
  withdraw the toplevel first, grid all the buttons in, then
  deiconify it.  Better yet, use something like tkTable if a 2D
  data sheet effect is what is desired in the first place. 
  -- 01/03/2000 hobbs


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


tkt_uuid: 220104ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: WM_SYSCOMMAND is not the same as WM_COMMAND
comment:
  OriginalBugID: 597 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-04'
  Severity: SER
  Status: Closed
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1998-08-04'


  The menu handling code in Tk8.0p2 on Windows handles the WM_SYSCOMMAND

  message as though it were the WM_COMMAND message.  That makes no

  sense.  Take a look at the documentation.



  In fact, I don't think the Tk menu handling needs to worry about

  WM_SYSCOMMAND at all.  WM_SYSCOMMAND is used for the system menu which

  appears on every window, and Tk is better off not dealing with that.



  In practice the code will normally just pass a WM_SYSCOMMAND message

  to DefWindowProc, because of how the Tk code happens to be written.

  However, the code is still wrong.



  Tk8.1a2 has the same problem.



  I've appended the trivial patch.



  Ian Taylor

  ian@cygnus.com



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

  --- tkWinMenu.c Wed Apr 15 14:41:13 1998

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

  *** 893,899 ****

              }

              break;

    

  -       case WM_SYSCOMMAND:

          case WM_COMMAND: {

              TkMenuInit();

              if (HIWORD(*pwParam) == 0) {

  --- 893,898 ----





  The Tk menu handling does need to handle WM_SYSCOMMAND because it is possible to append items to the system menu.  The wParam should contain the menu entry ID of the corresponding entry, if Tk has added anything to the system menu, otherwise it will simply invoke the default behavior.

  This is not a bug.


tkt_uuid: 220486ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: Chinese letter support in text widget
comment:
  OriginalBugID: 1761 RFE
  Version: 8.0.5
  SubmitDate: '1999-04-08'
  LastModified: '1999-09-01'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  FixedDate: '1999-09-01'
  FixedInVersion: 8.2


  Name:
  Di Yu

  DesiredBehavior:
  I want to use Tcl/Tk for Windows to write a program, I want it to
      support 
      Chinese also. Under Chinese platforms such as Richwin for Windows,
      Tcl/Tk8.0.5 
      can display Chinese letters(while 8.1b2 can't), but (1)sometimes Chinese
      letters 
      in a text widget will be cut in half when the widget try to wrap the
      line 
      (2)when I click on a disabled text widget with Chinese letters in it,
      sometimes 
      the letters will change into a mess.



  Please upgrade to the newest Tcl/Tk: 8.2, as this will solve most
  of the Unicode problems.  8.0 was not really a Unicode ready version. 
  -- 09/01/1999 hobbs


tkt_uuid: 577906ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4b1
resolution: Fixed
title: %P substitution not documented
comment:
  TIP 47 allegedly added a %P substitution to [bind] scripts,
  but it is not mentioned in doc/bind.n


tkt_uuid: 756840ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 9 Immediate
foundin: obsolete: 8.5a2
resolution: Fixed
title: thread finalize crash with console
comment:
  When Tcl_FinalizeThread is called for a thread that has a 
  console, it eventually calls TclFinalizeIOSubsystem, 
  which calls Tcl_Close for the console channel(s).  At 
  some point TkConsolePrint is called by the Tcl IO 
  subsystem.  In the included stack trace, TkConsolePrint 
  is trying to do various things with the interpreter, which 
  seems to have been already deleted.

  Tcl_GetCurrentNamespace(Tcl_Interp * 0x027b0b10) line 
  207 + 6 bytes
  Tcl_FindCommand(Tcl_Interp * 0x027b0b10, const char 
  * 0x0267d344, Tcl_Namespace * 0x00000000, int 0) line 
  1987 + 9 bytes
  Tcl_GetCommandInfo(Tcl_Interp * 0x027b0b10, const 
  char * 0x0267d344, Tcl_CmdInfo * 0x0306fd78) line 
  2207 + 17 bytes
  TkConsolePrint(Tcl_Interp * 0x027b0b10, int 8, const 
  char * 0x03507b00, long 0) line 798 + 25 bytes
  ConsoleOutput(void * 0x00000008, const char * 
  0x03507b00, int 0, int * 0x0306fde0) line 420 + 23 bytes
  FlushChannel(Tcl_Interp * 0x00000000, Channel * 
  0x027db000, int 0) line 2066 + 38 bytes
  CheckFlush(Channel * 0x027db000, ChannelBuffer * 
  0x03507ae0, int 0) line 3413 + 13 bytes
  WriteChars(Channel * 0x027db000, const char * 
  0x024ad744, int 0) line 3206 + 17 bytes
  Tcl_Close(Tcl_Interp * 0x00000000, Tcl_Channel_ * 
  0x027db000) line 2540 + 16 bytes
  TclFinalizeIOSubsystem() line 243 + 11 bytes
  Tcl_FinalizeThread() line 933


tkt_uuid: 220754ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: regexp escapes \M and \W fail in -nocase text search
comment:
  OriginalBugID: 5988 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-06'
  LastModified: '2000-07-24'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows NT
  FixedDate: '2000-07-24'
  FixedInVersion: 8.4a2


  Name:
  Roy E. Terry

  ReproducibleScript:
  package require Tk
  text .e
  .e insert 1.0 "word1 word2"
  pack .e
  after 500

  # first will succeed
  puts "plain search: [.e search -count cnt -regexp word. 1.0 end]"

  # \m works
  puts "\\m search: [.e search -count cnt -regexp {\mword.} 1.0 end]"

  # \M fails
  puts "\\M search: [.e search -count cnt -nocase -regexp {word.\M} 1.0 end]"

  # literal space match works
  puts "space search: [.e search -regexp -count cnt -nocase {word. } 1.0 end]"

  # \W white space match fails
  puts "\\W search: [.e search -regexp -count cnt -nocase {word.\W} 1.0 end]"

  ObservedBehavior:
  The search command of the text widget fails to match using constraint 
  escape \M or \W when the
  command includes the -count cnt and -nocase options.

  DesiredBehavior:
  \M should work regardless of options given to search command.



  It seems that the -nocase flag causes the problem.  The presence or absence of the -count flag does not seem to affect the outcome.

  The following comment (and the code that immediately follows it) is the problem:

      /*
       * Convert the pattern to lower-case if we're supposed to ignore case.
       */

  So the regexp pattern {word.\M} is being converted to {word.\m}, because of the -nocase flag.  The new regexp engine interface has APIs that support flags to specify nocase matching, so I updated the text search code to use those, instead of lowercasing the pattern as it used to.  This corrected the problem.  The fix will go out with Tcl/Tk 8.4a2.  Thanks for finding this bug.

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

  -- 07/24/2000 ericm


tkt_uuid: 485803ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: suspect code in tkImage.c
comment:
  A compiler warning about unreachable code in
  generic/tkImage.c brought my attention to 
  lines 371-377:

  371 if (masterPtr->typePtr != NULL) {
  372   for (imagePtr = masterPtr->instancePtr; imagePtr
  != NULL;
  373     imagePtr = imagePtr->nextPtr) {
  374        count = 1;
  375        break;
  376   }
  377 }

  The unconditional break inside the for loop
  does look suspect.  Is it meant to be a
  break in the case statement?  Worth a look
  by the maintainer anyway.


tkt_uuid: 1574843fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 51. [place]
priority: 7 High
foundin: obsolete: 8.4.14
resolution: Out of Date
title: tk8.4.14-RC1 test errors
comment:
  Attaching the test results - 34 errors. I have never
  seen 0 anyway, but some look unfamiliar: especially
  image, place (this could be a fluke), scale, spinbox.

  Platform is linux/xorg/icewm (hacked not to have
  titlebars - should not make a difference, right?).

  Tested both with --disable-shared, with and without
  --enable-symbols=all. The pace.test error only appeared
  in the symbols build.


tkt_uuid: 220611ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: Can't use the dead keys with accents that require the shift key
comment:
  OriginalBugID: 3359 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-02-10'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3695 4105
  OS: Windows 95
  FixedDate: '2000-02-10'
  FixedInVersion: 8.3


  Name:
  Joao Andre Simioni

  Comments:
  I'm using windows 95, standard U.S. keyboard with accentuation.
      There isn't the same problem when I use tcl/tk in Linux

  ObservedBehavior:
  Whenever I create an entry or text widget, I cannot write characters
      such as:
      ã - ê - ü
      because tk always write:
      à - e - ú.
      It appears that tk is ignoring the dead keys with the shift key pressed.

  DesiredBehavior:
  I'd like to be able to write all accentuated characters



  Fixed via patch from Spjuth in 8.3.0. 
  -- 02/10/2000 hobbs


tkt_uuid: 220106ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: bug in return value of "image cget"
comment:
  OriginalBugID: 626 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1999-08-13'
  Severity: MED
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-13'


  Hi! Is it possible, that there is a bug with [image cget]?
  It always returns zero, image configure bla  does also give a list of
  mostly empty data. Is this known? It appears with tk80p2. 


  This is likely confusion over the behavior of the image command.
  Once an image command is create (with image create ...), the
  command will return mostly empty data through config and cget.
  There are no defaults essentially, and it all depends on what
  the user sets for the values specifically.  This does work as
  expected. 
  -- 08/13/1999 hobbs


tkt_uuid: 220103ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: buttons are invoked by pressing return
comment:
  OriginalBugID: 585 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1999-08-09'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-09'


  On Windows, it's normal to invoke a button by pressing return.  The

  appended patch adds Tk bindings to make this happen by default.  This

  patch is due to Tom Tromey <tromey@cygnus.com>.



  Ian Taylor

  ian@cygnus.com



  *** /5g/ian/tk8.0p2/library/button.tcl  Mon Nov 25 11:42:30 1996

  --- button.tcl  Tue Apr 14 15:16:24 1998

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

  *** 38,43 ****

  --- 38,52 ----

        }

    }

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

  +     bind Button <Return> {

  +       tkButtonInvoke %W

  +     }

  +     bind Checkbutton <Return> {

  +       tkCheckRadioInvoke %W

  +     }

  +     bind Radiobutton <Return> {

  +       tkCheckRadioInvoke %W

  +     }

        bind Checkbutton <equal> {

          tkCheckRadioInvoke %W select

        }





  This patch is incorrect.  The expected behavior on Windows is that <Return> should invoke the *default* button, not the button that currently has focus.  This is a subtle, but very important difference.  There is no default binding for this behavior because it depends on things like tab order and multiple button groupings.  The correct behavior is that within a given panel, exactly one button will have the "-default active" attribute.  This button is drawn in a different style and is the one that should be invoked if <Return> is pressed when focus is anywhere in the panel.  The binding typically has to be attached to the panel rather than the button to get the correct behavior.

  -- 08/09/1999 stanton


tkt_uuid: 554763ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 4
foundin: TIP Implementation
resolution: Fixed
title: TIP #104 Reimplement undo stack + minor fixes
comment:
  This is a Tk 8.4a4 patch.

  The purpose is a reimplemtation of the undo stack.
  An item on the undo stack is now a list of items
  containing two scripts (Tc_Obj's): the apply action
  (for redo) and the revert action (for undo).
  This opens the path to undoing more than only text
  inserts and deletions, such as applying or removing
  tags (this is not part of the patch however).

  The undo stack implementation has been separated from
  the text widget, and is in fact usable by other
  widgets as well now.

  Some typos in the text.n doc are corrected as well,
  and a problem with the tk::TextPaste function (pasting
  twice) was also corrected.

  This patch has only been verfied on Red Hat Linux 7.2

  The Windows Makelfile.in was adapted to accomodate the
  new tkUndo.c and tkUndo.h files.

  The Mac section was NOT adapted yet for these two new
  files.


tkt_uuid: 2926819fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Fixed
title: event generate -warp 1 doesn't work on Mac OSX Aqua
comment:
  In the Aqua build of Tk, warping the pointer doesn't work in either 8.5.8 or 8.6b1. SImple script to reproduce:

  package require Tk
  bind . <1> { puts "Yes"; event generate . <Motion> -warp 1 -x 5 -y 5 }

  in X11/MacOS, this warps the pointer as expected when clicking anywhere in the main window. This functionality is needed e.g. for a 3D game, where the pointer is hidden and only the motion is tracked.


tkt_uuid: 3610628fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: Notebook in Paned Window crashes app when closed
comment:
  Scid vs PC uses embeded toplevels inside notebook and panedwidnows.
  All wish-8.5 series code is fine, but 8.6.0 and todays (April 6) trunk
  crash when closing a panedwindow and/or notebook.Via keyboard bindings.

    svn co https://scidvspc.svn.sourceforge.net/svnroot/scidvspc
    cd scidvspc
  ./configure TCL_VERSION=8.6
   make install
   /usr/local/bin/scid
   press f2 twice

   X Error of failed request:  BadWindow (invalid Window parameter)
    Major opcode of failed request:  10 (X_UnmapWindow)
    Resource id in failed request:  0x3e00995
    Serial number of failed request:  34177
    Current serial number in output stream:  34182

  Sorry for the shitty bug report. I'm trying to find a testcase , but so far am unable.


tkt_uuid: 220599ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Bug in FocusGroup Handling under CDE
comment:
  OriginalBugID: 2960 Bug
  Version: 8.2
  SubmitDate: '1999-09-28'
  LastModified: '2000-04-07'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.7
  Machine: Other
  FixedDate: '2000-04-07'
  FixedInVersion: 8.3.1


  Name:

  Donal Fellows



  Comments:

  This fixes a long-standing bug in Tk (it was certainly there

      in 8.0.4) which made keyboard navigation of the standard

      open/save file dialogs nearly impossible.  Since keyboard

      navigation is important for Power Users, this fix is a good

      idea.  It doesn't impact much on beginners though, who

      tend to prefer the point-and-grunt style of interaction...



  ReproducibleScript:

  First, run the following code in wish running under CDE (it might

      exist under other window managers/environments, but I have not

      checked):

          set tk_strictMotif 0

          tk_getOpenFile -initialfile foobar

      Now, try to use the left arrow key (not the mouse) to move

      backward within the entry field to between the "o" and the "b". 

      You will find that it is impossible to move more than one

      character back.  This is a problem!



  ObservedBehavior:

  The problem is that the focus handling for focus groups is too

      agressive (given the context of CDE at least, which traps

      some keystrokes for its own nefarious purposes.)  FocusIn

      events are only meaningful when they have a detail field (%d)

      of NotifyNonlinear or NotifyNonlinearVirtual.



  DesiredBehavior:

  I expect to be able to use the keyboard to navigate about the entry

      widget!



  Patch:

  *** comdlg.tcl.old      Tue Sep 28 10:50:29 1999

  --- comdlg.tcl.new      Tue Sep 28 10:51:30 1999

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

  *** 217,222 ****

  --- 217,228 ----

    proc tkFocusGroup_In {t w detail} {

        global tkPriv tkFocusIn

    

  +     if {[string compare $detail NotifyNonlinear] &&

  +       [string compare $detail NotifyNonlinearVirtual]} {

  +       # This is caused by mouse moving out&in of the window *or*

  +       # ordinary keypresses some window managers!

  +       return

  +     }

        if {![info exists tkFocusIn($t,$w)]} {

          set tkFocusIn($t,$w) ""

          return



  PatchFiles:

  comdlg.tcl





  Confirmed in CDE and fixed for 8.3.1. 
  -- 04/07/2000 hobbs


tkt_uuid: 734625ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: Output the contents of a text widget to a (PostScript) file
comment:
  Just like the canvas widget the text widget should be
  able to output its contents to an external text file,
  such as a PostScript file or maybe an HTML file. 


tkt_uuid: 1248241fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 74. Application Embedding
priority: 3 Low
foundin: obsolete: 8.4.11
resolution: None
title: DllMain calls TkFinalize (arbitrary side effects)
comment:
  DllMain cannot call most of the Win32 API, see:

  http://msdn.microsoft.com/library/en-us/dllproc/base/dllmain.asp?frame=true

  This means that calling exit handlers that potentially
  have arbitrary side effects could result in a variety
  of nasty surprises.


tkt_uuid: 3520202fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: None
title: Cocoa Tk 8.5 generates invalid mouse_wheel invents
comment:
  See details and test case at Python issue http://bugs.python.org/issue10731

  It appears that, for Tcl_CreateCommand at least, mouse_wheel events are being returned with a bogus argument count value of 20, possibly the length of the valid first argument string.  This causes problems in Python 3.x when _tkinter.c attempts to translate the garbage arguments strings, expecting them to be valid Unicode UTF-8 strings.  


tkt_uuid: 1258604fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 57. [option]
priority: 9 Immediate
foundin: obsolete: 8.5a4
resolution: Fixed
title: Tk widget option configuration failed to handle defaults
comment:
  One example of scrollbar

  % scrollbar .sh -orient horizontal
  .sh
  % scrollbar .sv 
  .sv
  % .sv config -orient
  -orient orient Orient vertical horizontal
  % 

  This bug is in recently changed 
  Tk_ConfigureWidget/TkOldConfig.c and has been fixed.


tkt_uuid: 540013ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 5 Medium
foundin: None
resolution: Accepted
title: wm stackorder error message
comment:
  wm stackorder reports isabove|isbelow as optional
  but this is not true, the keyword has to be present.


  % toplevel .t
  .t
  % wm stackorder . isabove .t
  0
  % wm stackorder . isbelow .t
  1
  % wm stackorder . .t
  wrong # arguments: must be "wm stackorder
  window ?isabove|isbelow? ?window?"
  %


tkt_uuid: 3239768fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: tk8.4.19 (and later) WIN32 menu font support
comment:
  Enclosed is a patch which allows tk8.4.19 when built with newer Microsoft
  compilers (MSVC 2008)  to correctly get the menu font information.  The
  problem is that the size of ncMetrics is larger when using the newer compilers
  causing the SystemParametersInfo call to fail on win2k/win2k3/winxp.  This
  results in the menu font being ill defined (e.g. Arial 396 which is huge).

  Changes:

    1) In SetDefaults adjust the size of ncMetrics when running on older
       operating systems as describe in the remarks section of:

         http://msdn.microsoft.com/en-us/library/ff729175(v=VS.85).aspx

  Notes:

    1) It appears from looking at the tk8.5.9 and tk8.6b1 source code that
       the problem is also present in those releases.

    2) This may require work to support older compilers which are missing
       iPaddedBorderWidth.


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

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

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

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

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


tkt_uuid: 1611821fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 6
foundin: obsolete: 8.4.14
resolution: Accepted
title: tk_getSaveFile -initialfile odd behavior
comment:
  If you do:

  set someRealFile /Library/Tcl/Tclapplescript/pkgIndex.tcl
  tk_getSaveFile -initialfile $someRealFile

  the dialog converts the / to -.  The workaround is to separate file and dir segments for -initialdir and -initialfile, but that is not the way Tk docs it, so it really is a Tk/Aqua bug.


tkt_uuid: 219964ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Duplicate
title: Disabled menubuttons have same foreground & background color
comment:
  OriginalBugID: 1703 Bug
  Version: 8.1b2
  SubmitDate: '1999-04-02'
  LastModified: '1999-04-06'
  Severity: LOW
  Status: Closed
  Submitter: lfb
  ChangedBy: lfb
  RelatedBugIDs: 1735
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-04-05'
  FixedInVersion: 8.1b3


  menubutton .mb -text "File" -state disabled
  pack .mb -padx 4 -pady 4

  The above script produces a menubutton that uses the same fg and bg color, which renders the text impossible to read.



  Duplicate bug id #1735


tkt_uuid: 2917663fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Treat SI:localuser, SI:localgroup as secure
comment:
  Since at least X11R6.8.0 there is a ServerInterpreted family of X host access.  On Ubuntu 9.10, [send] does not work because by default there are SI:localuser authorizations in the authorized hosts list.  The same is apparently true of Fedora 8 and newer.

  SI:localuser and SI:localgroup authorizations can be as secure as Xauth-only authorizations.

  This patch makes [send] continue to work even if SI:localuser and SI:localgroup authorizations appear in the authorization list.

  'xhost +' and 'xhost + localhost' still make [send] stop with an error about the X server being insecure.

  Before applying this patch, revert tkUnixSend.c r1.25 on TRUNK and r1.20.2.1 on the tk8.5 branch; that change was wrong.  It only allows a single SI: authorization.  Ubuntu 9.10 has 3 by default (this user, gdm, root).


tkt_uuid: 220243ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: window bug
comment:
  OriginalBugID: 3084 Bug
  Version: 8.1
  SubmitDate: '1999-10-11'
  LastModified: '1999-10-22'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-10-22'


  Name:
  Joe Acosta

  ReproducibleScript:
  I am using wish under windows.  IH ave written a script a basic text
      editor Tk NotePad. I have added a feature which works under Linux but
      not under windows. The problem is the menu font is not getting set under
      windows correctly. The sub menus get the fonts set correctly but the
      main menubar does not. The code snippet is shown below. 
      
      set menuFont -adobe-helvetica-bold-r-normal--12-*-75-75-*-*-*-*
      
      #create main menu
      menu .filemenu -tearoff 0 -font $menuFont
      
      #file menu
      menu .filemenu.files -tearoff 0 -font $menuFont
      .filemenu  add cascade -label "File" -underline 0 -menu .filemenu.files
      .filemenu.files add command -label "New" -underline 0 -command
      "filesetasnew"
      .filemenu.files add command -label "Open" -underline 0 -command
      "filetoopen" -accelerator Ctrl+o
      .filemenu.files add command -label "Save" -underline 0 -command
      "filetosave" -accelerator Ctrl+s
      .filemenu.files add command -label "Save As" -underline 5 -command
      "filesaveas"
      .filemenu.files add separator



  The user should use the new [list $family $size $style] font
  types for 8+ to get a more expected result on Windows. 
  -- 10/22/1999 hobbs


tkt_uuid: 625472ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: None
resolution: Fixed
title: Cygwin fixes for Tk 8.4.1 cvs
comment:
  The following back port and minor change are required to 
  compile Tk 8.4.1 cvs on Cygwin:
  2001-07-24  Mo DeJong  <mdejong@redhat.com>
   * win/configure: Regen.
   * win/tcl.m4 (SC_CONFIG_CFLAGS): Check for bug in
   Cygwin version of windres and work around that
   case by passing a POSIX path instead of a Windows
   native path. One can't always pass a POSIX path
   because the mingw native toolchain accepts only
   Windows native paths.

  And win/tkWinPort.h was altered to make sure 
  OPEN_MAX is only defined if not already defined by 
  system (ie Cygwin)


tkt_uuid: 1480105fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: TkAqua: unmap not propagating in 8.4.13
comment:
  The attached unmap.tcl wish script works in the wish8.4
  that comes with Mac OS X 10.4.6 (8.4.7) and fails with
  a fresh build of Tcl/Tk 8.4.13.  The correct behavior
  occurs when the button is pressed and the frame
  containing the interior label is unmapped and the
  interior label does not get the unmap event.  This is a
  show stopper for the Togl widget,
  http://togl.sourceforge.net, because togl needs to
  disable OpenGL drawing when the widget isn't mapped.


tkt_uuid: 220820ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.1
resolution: Duplicate
title: Container Frame in Tk on Windows NT
comment:
  OriginalBugID: 2208 Bug
  Version: 8.1
  SubmitDate: '1999-06-15'
  LastModified: '2000-01-07'
  Severity: SER
  Status: Assigned
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT 4.0 service pack 4
  Machine: X86


  Name:
  Christian Knoepfel-Eva

  Extensions:
  Tk

  ReproducibleScript:
  % pack [frame .f -container 1]
      % winfo id .f
      % 0x10a051a
      
      start a second wish: 
      c:> wish81 -use 0x10a051a
      % pack [button .b -text "I like linux"]
      % exit

  ObservedBehavior:
  Unfortunately the second wish crashes at the exit statement and the exit
      statement and the container window does not work anymore with another
      application (3rd wish).

  DesiredBehavior:
  same as linux - no problems at all



  verified in 8.3b1. 
  -- 01/07/2000 hobbs


tkt_uuid: 852014ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Factor instance/master code
comment:
  It seems that all image managers (photo, bitmap, user
  defined types) really ought to have some sort of
  instance management code, but this isn't provided by
  Tk.  It seems like it would make sense to have this be
  part of the common Tk infrastructure instead of
  cut'n'pasted between implementations.


tkt_uuid: 220566ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2b1
resolution: Fixed
title: NetCVS distributed deprecated files
comment:
  OriginalBugID: 2418 Bug
  Version: 8.2b1
  SubmitDate: '1999-07-19'
  LastModified: '1999-07-20'
  Severity: MED
  Status: Released
  Submitter: jenn
  ChangedBy: stanton
  OS: All
  Machine: NA
  FixedDate: '1999-07-20'


  Name:  Don Porter

  ObservedBehavior:
      The following files are distributed as part of Tk by NetCVS, even though
      they are no longer part of the official Tk releases:
      
      doc/InitStubs.3
      generic/tkIntPlatStubs.c
      generic/tkIntStubs.c
      generic/tkIntXlibStubs.c
      generic/tkPlatStubs.c
      generic/tkStubs.c
      mac/tkMacProlog.c
      tests/all
      tests/defs
      tests/visual
      win/makefile.bc
      
      

  DesiredBehavior:
      'cvs rm' files from NetCVS as they become obsolete.


  07/20/1999 14:05 - stanton - fixed rdist script to removed deleted files


tkt_uuid: 581795ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 7 High
foundin: obsolete: 8.4b2
resolution: Accepted
title: '$menu post' halts tcl script
comment:
  unixWm.test numbers 54.1 and 54.2 both hang 
  under windows 2000.  The user is required to click 
  somewhere (once for each test) and then the test 
  proceeds fine.  The problem appears to be that 
  when the menu is posted, the script halts and it is 
  only when the user clicks somewhere that 'update' 
  is actually reached...

  test unixWm-54.1 {TkpMakeMenuWindow 
  procedure, setting save_under} {
      catch {destroy .t}
      catch {destroy .m}
      toplevel .t -width 300 -height 200 -bd 2 -relief 
  raised
      bind .t <Expose> {set x exposed}
      wm geom .t +0+0
      update
      menu .m
      .m add command -label First
      .m add command -label Second
      .m add command -label Third
      .m post 30 30
      update
      set x {no event}
      destroy .m
      set x
  } {no event}
  test unixWm-54.2 {TkpMakeMenuWindow 
  procedure, setting override_redirect} {
      catch {destroy .m}
      menu .m
      .m add command -label First
      .m add command -label Second
      .m add command -label Third
      .m post 30 30
      update
      set result [wm overrideredirect .m]
      destroy .m
      set result
  } {1}


tkt_uuid: 939389ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Win Tk can lose clipboard data on exit (bug fix)
comment:
  When wish84.exe runs the following script saved as 
  "a.tcl", the clipboard on Windows system doesn't 
  have the text "foo":

  # run as "wish84.exe a.tcl"
  clipboard append foo
  exit

  TkpCloseDisplay() function (win/tkWinX.c) tries to 
  render the clipboard data before exiting wish84.exe 
  if dispPtr->clipWindow is not NULL. But, 
  TkCloseDisplay() function (generic/tkWindow.c) 
  calls TkClipCleanup() function before calling 
  TkpCloseDisplay() function so that dispPtr->clipWindow 
  in TkpCloseDisplay() is always NULL.
  TkWinClipboardRender() function (win/tkWinClipboard.c) 
  is only called when WM_RENDERFORMAT message is sent.


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


  Name:
  Charles Shartsis

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

  CustomShell:
  None

  ReproducibleScript:
  Test Script:

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

  #set height 30
  set height 200

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

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

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

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



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

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

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

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

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

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

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

  -- 09/24/2000 ericm


tkt_uuid: 220803ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 8
foundin: obsolete: 8.1b3
resolution: Fixed
title: Docs missing for Tk_AttachHWND API
comment:
  OriginalBugID: 1855 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: 527921ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Invalid
title: spinbox not readonly
comment:
  Setting the spinbox readonly option does not disable
  buttons or keyboard up/down
  (8.4a4 Linux Mandrake 8.1 and Windows 2000 ActiveTcl
  8.4.0.1 b2)


tkt_uuid: 220844ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: final: 8.0.5
resolution: Out of Date
title: Strange Windows message processing behaivor
comment:
  OriginalBugID: 2125 Bug
  Version: 8.0.5
  SubmitDate: '1999-05-24'
  LastModified: '2000-01-25'
  Severity: CRIT
  Status: UnAssn
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86


  Name: Justin Frodsham

  ReproducibleScript:
  No script needed.

  ObservedBehavior:
  Tk ignores Window Manager messages such as WM_KEYDOWN.  This seems odd.
  There are notes in the code about the possibly of stray messages not
  belonging to the window, but that is not possible.

  DesiredBehavior:
  If I send a keystroke DIRECTLY to a windows message queue (specifically
  my Tk app), it should NEVER be abritrarily thrown away.  This is the
  only way we could work around TCL not being multi-thread safe, and do
  event driven coding.  Any ideas?


tkt_uuid: 219970ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title:
  Get an coredump while inserting text in a 'text'-widget. Also the 'widget'-demo doesn't work in the demos-directorywork

comment:
  OriginalBugID: 1795 Bug
  Version: 8.0.4
  SubmitDate: '1999-04-13'
  LastModified: '1999-08-20'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2316
  OS: AIX
  OSVersion: AIX 4.3.2
  Machine: RS6000
  ClosedDate: '1999-08-20'


  Name:
  Siegfried Weigl

  Extensions:
  Tix 4.1.0

  ReproducibleScript:
  text .t
      pack .t
      .t insert end "Hello world\n"


tkt_uuid: 220226ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: [entry]'s -disabledforeground doesn't work
comment:
  OriginalBugID: 2632 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-08-31'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  ClosedDate: '1999-08-31'


  Name:
  keith lea

  ObservedBehavior:
  entries' foreground color doesn't change when they are disabled and have
      a different -disabledforeground color

  DesiredBehavior:
  the foreground color of the entry should change



  entry widgets don't have a -disabledforeground option... 
  -- 08/31/1999 hobbs


tkt_uuid: 3612022fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: wm_resizable is all or nothing
comment:
  With the Tk (and Python) that ship with Mountain Lion, preventing window resizing only works for both directions, if either with or height are true that call has no effect.


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


  Name:
  keith lea

  DesiredBehavior:
  this would be nice:

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

  just for convenience



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


tkt_uuid: 3077303fffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: Set background and opacity of Tk-Cocoa textured windows
comment:
  The attached patch allows you to set the background and opacity of textured ("metal") windows with Tk-Cocoa using the tk::unsupported::MacWindowStyle command. The current configuration of metal/textured windows does not integrate well with Tk widgets because the non-opacity of the window's background color causes the color to flicker through or "flash" during redraws of Tk widgets; it also does not allow Tk widgets to blend in seamlessly with the background because it is a gradient. This patch allows one to set the textured background to opaque, to set it to a standard NSColor, and then set the Tk widget to a corresponding hex color. 

  Here is an example:

  toplevel .f
  tk::unsupported::MacWindowStyle style .f document {metal light opaque closeBox collapseBox resizable standardDocument }

  pack [label .f.f -bg  #ababab -text "This is a textured window\nwith opacity and a gray background\nsimilar to other Mac applications"] -fill both -expand yes

  The patch updates both tkOSXWm.c and the README file, with documentation. 


tkt_uuid: 572909ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4a5
resolution: Works For Me
title: Wm crash on Win98
comment:
  The current 8.4b1 crashes in the test suite on Win98.

  The crash happens in wm-state-2.4, the update row.
  The crash is in tkWinWm.c line 3817 in
  UpdateGeometryInfo(). wmPtr is bad (= 0xdddddddd)

  Can't dig for more details right now...


tkt_uuid: 528893ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Out of Date
title: OSX tk crashes
comment:
  This is just to log the fact that OSX tk crashes when running my 
  mercator program. As yet I have not tracked down the cause so cannot 
  give more details, however, I did find an OSX console message about 
  an attempt to free already free storage so that may be the cause. I 
  will investigate further and see if I can get more details.


tkt_uuid: 219934ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: canvas oval stipple & no cursors
comment:
  OriginalBugID: 1379 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-14'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1274
  OS: Windows NT
  OSVersion: 4.0 with service pack 3
  Machine: X86
  ClosedDate: '1999-08-14'


  Name:
  Keith Powell

  Extensions:
  itcl, iwidgets that comes with TclPro1.1

  CustomShell:
  none

  ReproducibleScript:
  The canvas 'create oval' command seems to ignore the stipple.

  #-----------------------------
  canvas .c
  pack .c
  .c create oval 10 10 100 100 -fill blue -stipple gray12
  #-----------------------------

  Also, I have created a custom shell to use with prowrap.  When I try configure a widget to use any cursor other than arrow, it fails saying 'bad cursor spec "blahblah"'.  Have I missed something that makes the cursors available?


tkt_uuid: 1016389fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Wont Fix
title: [rename image] breaks Tk_InitImageArgs
comment:
  Tk_InitImageArgs() does a
  Tcl_GetCommandInfo(..."image" ...)
  to get data it needs to operate.

  After a [rename] of [image]. this
  may fail.


tkt_uuid: 819290ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: None
resolution: None
title: tk_messageBox -timeout option
comment:
  Hi,

   I need the "tk_messageBox" with an additional flag

    >>> -timeout <<< with default value "0"

   why? 
   My application creates a couples of messageboxes and every
   MessageBox uses the same code to create. 
   => if you look into the file "msgbox.tcl" every
  MessageBox is 
      waiting for 
    >>> tkwait variable tkPriv(button) <<<
   to get the button pressed.
   this is a problem because if the application runs
  overnight the
   eval-loop is filled up with "unpressed" MessageBoxes.
   to solve this problem the flag "-timeout" was
  introduced and
   the behaviour is to press the default-button after
  "-timeout" ms

  code:

  tcl 8.3.4
  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  152d151
  <         {-timeout "" "" "0"}
  400,402d398
  <     if {$data(-timeout)} {
  <       after $data(-timeout) set tkPriv(button)
  $data(-default)
  <     }
  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


  mfg

    aotto


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


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

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

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

  else.



  The appended patch will fix this problem.



  Ian



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

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

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

  *** 206,213 ****

          bind Entry <Command-KeyPress> {# nothing}

    }

    

  ! bind Entry <Insert> {

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

    }

    

    # Additional emacs-like bindings:

  --- 206,217 ----

          bind Entry <Command-KeyPress> {# nothing}

    }

    

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

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

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

  !     bind Entry <Insert> {

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

  !     }

    }

    

    # Additional emacs-like bindings:



  applied patch 8/5/98 (SS)


tkt_uuid: 3607200fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Cocoa/Carbon/OSX: variant keyboard events
comment:
  It is helpful when building an application for distribution if Tk behavior is the same for all variants of the same platform.  Any reduction of differences is beneficial.

  I am comparing Tk/Aqua/Cocoa 8.6 trunk and core-8-5-branch, with the Tk/Aqua/Carbon 8.5.9 shipped with Mountain Lion, and also with Tk/Aqua/Carbon 8.5.11 built on Tiger and running on either Mountain Lion or Tiger.

  Items (1), (2), (3) are differences between keyboard events in Tk/Aqua/Cocoa and those in Tk/Aqua/Carbon.

  Item (4) is a dependence on the runtime version of OS X.

  Item (5) is a dependence on the build version of OS X.

  Cf. documentation for Aqua/Carbon keyboard modifiers at http://wiki.tcl.tk/28331

  Every platform has small differences, so it is a matter of opinion whether items (2) and (3) below are "bugs" or "features".  I believe they should be considered bugs, because this Tk/Aqua/Cocoa behavior differs from that of Tk/Aqua/Carbon.

  ====

  Differences between keyboard events in Tk/Aqua/Cocoa and those in Tk/Aqua/Carbon.

  (1) BAD REPORTED KEYSYM FOR MODIFIER KEYS
  The value of %K for modifier keys (other than Caps_Lock) is reported as "??", rather than the values "Shift_L" etc used in non-Aqua platforms.  This bug is also found in recent combinations of Tk/Aqua/Carbon and OS X build platform (but not in older combinations, e.g. 8.5.11 built on Tiger and running on Mountain Lion).

  (2) NO REPORTED MODIFIER FOR ALT KEY
  The Option modifier generated by the "alt" key is intercepted by the operating system, which modifies the character (and hence the values of %K and %A).  The event is a <KeyPress>, whereas in Tk/Aqua/Carbon it is an <Option-KeyPress>.

  The "Option" modifier is correctly reported if an event also uses the Command or Control modifier. 

  (3) NO REPORTED MODIFIERS FOR SHIFT AND SHIFT-LOCK
  Holding down the shift key and pressing "s" produces the event <KeyPress> with %K equal to "S".  On other platforms it produces the event <Shift-KeyPress> with %K equal to "S".

  Pressing the "Shift Lock" key and then pressing "s" produces the event <KeyPress> with %K equal to "S".  On other platforms it produces the event <Lock-KeyPress> with %K equal to "S".

  Pressing the "Shift Lock" key, then holding down the shift key and pressing "s" produces the event <KeyPress> with %K equal to "S".  On other platforms it produces the event <Shift-Lock-KeyPress> with %K equal to "s".

  However, the "Shift" and "Lock" modifiers are correctly reported (as they are on other Tk platforms) if an event also uses the Command or Control (but not the Option) modifier. 

  Notes on (3):
  - (a) Conventionally, "Shift Lock" is not reversible by Shift on the Mac.
  - (b) It might be considered a "feature", not a "bug", of Tk on the Mac that the operating system and Tk fully interpret the Shift and Lock keys, and pass the script the appropriate symbol as %K and %A without conveying information about the Shift and Lock modifiers.
  - (c) The opposing arguments, that this is a "bug", not a "feature" are:
  --    (i) non-Mac platforms also do this interpretation of the Shift and Lock modifier keys (though in a different way from the Mac, see (a)) AND ALSO tell the application whether the modifiers Shift and Lock have been applied;
  --    (ii) Tk/Aqua/Carbon does the same as Tk on non-Mac platforms: therefore the change made in Tk/Aqua/Cocoa, even if it is considered desirable, is a change of behavior made at a patch level revision of Tk/Aqua.

  ====

  Dependence on the runtime version of OS X.

  (4) GRATUITOUS MODIFIER FOR NON-PRINTING, NON-NUMERIC-KEYPAD KEYS
  This applies to a Cocoa binary built and executed on Mountain Lion, and to a Carbon binary built on either Tiger or Mountain Lion and executed on Mountain Lion.

  The keys {Next Prior Home End Delete Help Clear}, and F1 to F16 (except when intercepted by the operating system), are reported as <M4-KeyPress>, not as <KeyPress> (which is the behavior for a Carbon binary built and executed on Tiger).

  The keys {Up Down Left Right} are reported as <M4-KeyPress>, not as <M3-KeyPress> (which is the behavior for a Carbon binary built and executed on Tiger).

  (For comparison: all versions of Mac OS X and Tk/Aqua report the modifier M3 for keys in the numeric keypad, except the Clear key).

  ====

  Dependence on the build version of OS X.

  (5) REPORTED UNICODE CHARACTER %A FOR NON-PRINTING KEYS
  The keys {Next Prior Home End Delete Help Up Down Left Right Clear}, and F1 to F16 (except when intercepted by the operating system) generate a non-empty value for %A.  This value is a Unicode character in the private use area U+E000 to U+F8FF.

  This occurs for both Tk/Aqua/Carbon and Tk/Aqua/Cocoa binaries built and executed on Mountain Lion.

  On other platforms, and for Tk/Aqua/Carbon binaries built on Tiger and executed on Tiger or Mountain Lion, the behavior is different: %A is the empty string, or ASCII 127 for the Delete key.


tkt_uuid: 3567778fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 8
foundin: obsolete: 8.6b3
resolution: Fixed
title: unixfont-5.11 hang
comment:
  In an --enable-aqua build of Tk8.6b3, the test suite
  hangs up in test unixfont-5.11 when building and
  testing on Snow Leopard. Spinning rainbow ball.

  At least once when I left it hang long enough, I got
  printed to the console terminal a series messages
  like this:

  tktest(30053,0x7fff70636cc0) malloc: *** auto malloc[30053]: agc error: Can not allocate new region


tkt_uuid: 2821084fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: WM_DELETE_WINDOW error
comment:
  Under Tk-Cocoa, cancelling the WM_DELETE_WINDOW protocol causes the main window to withdraw, and not to return. 

  The sample code below is a test case. Under Tk 8.4.7, it causes Wish to exit if "yes" is chosen and the command to be cancelled if "no" is chosen, leaving the toplevel mapped. Under Tk-Cocoa, Wish exists if "yes" is chosen, and the toplevel is unmapped if "no" is chosen. The toplevel should remain mapped. 


  wm protocol . WM_DELETE_WINDOW shutDown


  proc shutDown {} {

      global datadir

      set fetchanswer [tk_messageBox -title "Quit" -icon info  -message "Do you really want to quit?" -type yesno -parent . ]
      switch $fetchanswer {
  yes {
      exit
  }
  no {
      destroy $fetchanswer
  }
      }
  }


tkt_uuid: 220255ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Invalid
title: Segmentation fault on wish start (no GUI-window)
comment:
  OriginalBugID: 3548 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-11'
  LastModified: '1999-11-15'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: sun-solaris2.5.1 / X11R6.4 (compiled with gcc2.95)
  Machine: Sparc20 / UltraSparc
  ClosedDate: '1999-11-15'


  Name:
  Ralf Oelschlaegel

  ReproducibleScript:
  ./configure --enable-gcc --enable-shared --enable-symbols
  (gcc version 2.95 19990728)
  same effect with gcc version 2.8.0 and cc: SC4.0 18 Oct 1995 C 4.0
  and also with Tcl/Tk 8.0.5

  ObservedBehavior:
  ldd ./wish 
  libtk8.2g.so => ./libtk8.2g.so
  libtcl8.2.so => /usr/local/lib/libtcl8.2.so
  libsocket.so.1 => /usr/lib/libsocket.so.1
  libX11.so.6.1 => /usr/local/X11/lib/libX11.so.6.1
  libdl.so.1 => /usr/lib/libdl.so.1
  libm.so.1 => /usr/lib/libm.so.1
  libc.so.1 => /usr/lib/libc.so.1
  libnsl.so.1 => /usr/lib/libnsl.so.1
  libintl.so.1 => /usr/lib/libintl.so.1
  libmp.so.1 => /usr/lib/libmp.so.1
  libw.so.1 => /usr/lib/libw.so.1

  (gdb) bt
  #0  0xef3e4870 in strncpy ()
  #1  0xef539480 in _XimMakeImName ()
  #2  0xef539590 in _XimOpenIM ()
  #3  0xef51080c in XOpenIM ()
  #4  0xef6dbfcc in OpenIM (dispPtr=0x319a8) at ./../generic/tkWindow.c:2455
  #5  0xef6d93c8 in GetScreen (interp=0x22b70, screenName=0x22780 ":0.0", 
      screenPtr=0xefffea1c) at ./../generic/tkWindow.c:456
  #6  0xef6d8fd0 in CreateTopLevelWindow (interp=0x22b70, parent=0x0, 
      name=0xefffed29 "wish", screenName=0xef76cee0 "") at ./../generic/tkWindow.c:285
  #7  0xef6d9bdc in TkCreateMainWindow (interp=0x22b70, screenName=0xef76cee0 "", 
      baseName=0xefffed29 "wish") at ./../generic/tkWindow.c:803
  #8  0xef703658 in TkCreateFrame (clientData=0x0, interp=0x22b70, argc=4, 
      argv=0xefffee18, toplevel=1, appName=0xefffed29 "wish")
      at ./../generic/tkFrame.c:333
  #9  0xef6dcb1c in Initialize (interp=0x22b70) at ./../generic/tkWindow.c:2912
  #10 0xef6dc2dc in Tk_Init (interp=0x22b70) at ./../generic/tkWindow.c:2618
  #11 0x1080c in Tcl_AppInit (interp=0x22b70) at ./tkAppInit.c:84
  #12 0xef6c8594 in Tk_MainEx (argc=1, argv=0xeffff23c, 
      appInitProc=0x107c8 <Tcl_AppInit>, interp=0x22b70) at ./../generic/tkMain.c:216
  #13 0x107b4 in main (argc=1, argv=0xeffff23c) at ./tkAppInit.c:54

  or
  0xef3cbe58 in _morecore ()
  #0  0xef3cbe58 in _morecore ()
  #1  0xef3cb738 in _malloc_unlocked ()
  #2  0xef3cb4a8 in malloc ()
  #3  0xef4f946c in _XimMakeImName ()

  DesiredBehavior:
  Opening of the generic wish window



  Please use a debugging version of Tcl with a debugging version
  of Tk (or nodebug with nodebug). 
  -- 11/11/1999 hobbs
  This turned out to be due to definition of the TK_USE_INPUT_METHODS,
  but that was not working on the users system.  This should be
  improved in 8.3. 
  -- 11/15/1999 hobbs


tkt_uuid: 1463233fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 9 Immediate
foundin: obsolete: 8.5a3
resolution: Fixed
title: text [.t tag configure -wrap {}] errors out
comment:
  The text widget in 8.5 errors on 

    [.t configure X -wrap {}] 

  even though {} is the default value.  Thus it not
  possible to save/restore values for tags, without
  kicking an error.

  This appears to be a bug in 8.5 text widget due to the
  conversion to Tk_OptionSpec, and in particular the use
  of the "" string in -wrap's TK_OPTION_STRING_TABLE.

  The problem occurs from DoObjConfig() where a lookup of
  {} via Tcl_GetIndexFromObjStruct() generates an error
  for zero length strings at around line 205 of
  tclIndexObj.c:

      if (key[0] == '\0') {
          goto error;
      }


tkt_uuid: 220276ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.2.3
resolution: Invalid
title: TkTable Extension crashes in TableCellCoords.c
comment:
  OriginalBugID: 4135 Bug
  Version: 8.2.3
  SubmitDate: '2000-02-07'
  LastModified: '2000-04-18'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  ClosedDate: '2000-04-18'


  Name:

  Torsten Rottmann



  Comments:

  Should I define BOUNDS_CHECK to avoid this in the sequence below?

      

          /* real coords required, always should be passed acceptable values,

         * but this is a possible seg fault otherwise */

      #ifdef BOUNDS_CHECK

          row = MIN(tablePtr->rows-1, MAX(0, row));

          col = MIN(tablePtr->cols-1, MAX(0, col));

      #endif

          *w = tablePtr->colPixels[col];

          *h = tablePtr->rowPixels[row];



  ReproducibleScript:

  Somehow Tktable (2.5) craches with following stack:

  #0  0x4028dd6e in TableCellCoords (tablePtr=0x810fa00, row=177, col=0,

      x=0xbfffe004, y=0xbfffe000, w=0xbfffdffc, h=0xbfffdff8)

      at ./tkTableCell.c:100

  ---Type <return> to continue, or q <return> to quit---

  100         *h = tablePtr->rowPixels[row];

  (gdb) bt

  #0  0x4028dd6e in TableCellCoords (tablePtr=0x810fa00, row=177, col=0,

      x=0xbfffe004, y=0xbfffe000, w=0xbfffdffc, h=0xbfffdff8)

      at ./tkTableCell.c:100

  #1  0x4028dfe1 in TableCellVCoords (tablePtr=0x810fa00, row=177, col=0,

      rx=0xbfffe048, ry=0xbfffe044, rw=0xbfffe040, rh=0xbfffe03c, full=0)

      at ./tkTableCell.c:192

  #2  0x40286f83 in TableRefresh (tablePtr=0x810fa00, row=177, col=0, mode=4)

      at ./tkTable.c:1440

  #3  0x402893c2 in TableAdjustActive (tablePtr=0x810fa00) at ./tkTable.c:2650

  #4  0x40289f04 in TableAdjustParams (tablePtr=0x810fa00) at ./tkTable.c:3005

  #5  0x40286bda in TableConfigure (interp=0x8053000, tablePtr=0x810fa00,

      objc=2, objv=0x8056028, flags=1, forceUpdate=0) at ./tkTable.c:1219

  #6  0x40285d87 in TableWidgetObjCmd (clientData=0x810fa00, interp=0x8053000,

      objc=4, objv=0x8056020) at ./tkTable.c:705

  #7  0x400e4e23 in TclExecuteByteCode ()             

  ...

  (gdb) print *tablePtr

  $1 = {tkwin = 0x80fa100, display = 0x805f000, interp = 0x8053000,

    widgetCmd = 0x81106c0, autoClear = 1, selectMode = 0x80eb968 "browse",

    selectType = 1, selectTitles = 0, rows = 15, cols = 6, defRowHeight = 1,

    defColWidth = 10, maxReqCols = 0, maxReqRows = 15, maxReqWidth = 800,

    maxReqHeight = 600, arrayVar = 0x80eb960 "tup", rowSep = 0x0, colSep = 0x0,

    defaultTag = {bg = 0x8077180, fg = 0x8124a40, bd = 1, relief = 5,

      tkfont = 0x811c000, anchor = TK_ANCHOR_W, imageStr = 0x0, image = 0x0,

      state = STATE_UNKNOWN, justify = TK_JUSTIFY_LEFT, multiline = 1,

      wrap = 0, showtext = 0}, yScrollCmd = 0x811e0a0 ".tf.tupscroller set",

    xScrollCmd = 0x0, browseCmd = 0x811e040 "mdbb:browse %r %s %S",

    caching = 0, command = 0x0, useCmd = 1, selCmd = 0x0,

    valCmd = 0x811e020 "mdbb:validate %C %S", validate = 1,

    insertBg = 0x8124a00, cursor = 0x0, bdcursor = 0x3c0002e,

    exportSelection = 0, state = STATE_NORMAL, insertWidth = 2,

    insertBorderWidth = 0, insertOnTime = 600, insertOffTime = 300,

    invertSelected = 0, colStretch = 1, rowStretch = 1, colOffset = 1,

    rowOffset = -2, drawMode = 4, flashMode = 0, flashTime = 2, resize = 2,

    sparse = 0, rowTagCmd = 0x0, colTagCmd = 0x0, highlightWidth = 2,

    highlightBgColorPtr = 0x8077800, highlightColorPtr = 0x80777c0,

    takeFocus = 0x0, padX = 2, padY = 1, titleRows = 2, titleCols = 0,

    topRow = 2, leftCol = 0, anchorRow = 177, anchorCol = 0, activeRow = 14,

    activeCol = 0, oldTopRow = 168, oldLeftCol = 0, oldActRow = 177,

    oldActCol = 0, icursor = 4, flags = 55, dataSource = 4, maxWidth = 707, 



  ...



  ObservedBehavior:

  As you may see, the table has 15 rows, but  oldActRow = 177.

  The table was possibly resized serval times (don't know by insert/delete or

  a configure).



  DesiredBehavior:

  no crash!





  The BOUNDS_CHECK would likely prevent the problem, but it would
  be good to know what actually caused it.  I am not able to
  reproduce this bug in any way with v2.6alpha. 
  -- 04/18/2000 hobbs


tkt_uuid: 3002484fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: None
title: Hard crash in wish on OSX when no windowserver
comment:
  When I start wish on OSX from a session that does not have access to the window server (for instance using an SSH connection as a user that is not logged on on the console) I get a hard crash due to an uncaught ObjC exception:

  Sun May 16 11:30:39 Rivendell.local Wish[37073] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
  _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
  % 2010-05-16 11:30:39.691 Wish[37073:903] setCanCycle: is deprecated.  Please use setCollectionBehavior instead
  2010-05-16 11:30:39.704 Wish[37073:903] An uncaught exception was raised
  2010-05-16 11:30:39.704 Wish[37073:903] Error (1002) creating CGSWindow
  2010-05-16 11:30:39.705 Wish[37073:903] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating CGSWindow'
  *** Call stack at first throw:
  (
  0   CoreFoundation                      0x00007fff85e31d24 __exceptionPreprocess + 180
  1   libobjc.A.dylib                     0x00007fff860000f3 objc_exception_throw + 45
  2   CoreFoundation                      0x00007fff85e31b47 +[NSException raise:format:arguments:] + 103
  3   CoreFoundation                      0x00007fff85e31ad4 +[NSException raise:format:] + 148
  4   AppKit                              0x00007fff84614aba _NSCreateWindowWithOpaqueShape2 + 473
  5   AppKit                              0x00007fff845a9055 -[NSWindow _commonAwake] + 1214
  6   AppKit                              0x00007fff845c6d3d -[NSWindow _makeKeyRegardlessOfVisibility] + 96
  7   AppKit                              0x00007fff845c6cb2 -[NSWindow makeKeyAndOrderFront:] + 24
  8   Tk                                  0x00000001000c435a XMapWindow + 139
  9   Tk                                  0x0000000100032d3c Tk_MapWindow + 84
  10  Tk                                  0x000000010003db5f TkCreateFrame + 1869
  11  Tcl                                 0x00000001001eec9c TclServiceIdle + 76
  12  Tcl                                 0x00000001001d531d Tcl_DoOneEvent + 340
  13  Tk                                  0x000000010001af93 Tk_MainLoop + 29
  14  Tk                                  0x0000000100027257 Tk_MainEx + 1589
  15  Wish                                0x00000001000044fe 0x0 + 4294984958
  16  Wish                                0x00000001000044ac 0x0 + 4294984876
  )
  terminate called after throwing an instance of 'NSException'
  Abort trap


  I'd expect to get a Tcl error instead of a hard abort.

  This also affects embedders of Tcl/Tk, the reason I post this issue is the following issue in the Python tracker: <http://bugs.python.org/issue8716>. I'm looking for a workaround for that issue (because we'll have to work with system versions of Tk) but it would be nice if this were fixed upstreams as well.


tkt_uuid: 837870ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Bezier canvas support
comment:
  This provides support for bezier curves as a canvas type.  
  The support was added for the BRL-CAD package and has 
  existed and been distributed for several years; the original 
  author is John Anderson of the U.S. Army Research 
  Laboratory.

  There may be some "polish" still required to make the 
  canvas type behave like all of the rest, but the functionality 
  is there and useable as is.  We've found it useful, I imagine 
  others will too.

  The patch is rather simple.  There is a new file, 
  tkCanvBezier.c that goes in generic/. as well as the 
  necessary entries in unix/Makefile.in provided as a diff -u 
  patch.

  Cheers!
  Sean


tkt_uuid: 2830991fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 8
foundin: obsolete: 8.5.7
resolution: Invalid
title: Scrolling problem in Tk-Cocoa
comment:
  Rapid scrolling of a tablelist widget in Tk-Cocoa causes this crash error: 

  2009-08-01 22:10:01.909 Wish[395:10b] *** Assertion failure in +[NSEvent startPeriodicEventsAfterDelay:withPeriod:], /SourceCache/AppKit/AppKit-949.46/AppKit.subproj/NSEvent.m:1765
  2009-08-01 22:10:01.994 Wish[395:10b] An uncaught exception was raised
  2009-08-01 22:10:01.995 Wish[395:10b] Periodic events are already being generated
  2009-08-01 22:10:01.996 Wish[395:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Periodic events are already being generated'
  2009-08-01 22:10:01.997 Wish[395:10b] Stack: (
      140735390297052,
      140735374665935,
      140735390296645,
      140735348771047,
      140735363627265,
      140735364719298,
      140735363200221,
      140735362063667,
      140735361856246,
      4295758353,
      4295759600,
      4296889279,
      4295051574,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296483162,
      4296764007,
      4296481868,
      4296485160,
      4295760884,
      140735362077430,
      140735362077231,
      140735363205617,
      140735364719396,
      140735363200221,
      140735362063667,
      140735361856246,
      4295758353,
      4295759600,
      4296889279,
      4295051574,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296483162,
      4296764007,
      4296481868,
      4296485160,
      4295760884,
      140735362077430,
      140735362077231,
      140735363205617,
      140735363205344,
      140735363200179,
      140735362063667,
      140735361856246,
      4295758353,
      4295759600,
      4296889279,
      4295051574,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296709912,
      4296946738,
      4296481868,
      4296483162,
      4296764007,
      4296481868,
      4296485160,
      4295760884,
      140735362077430,
      140735362077231,
      140735363205617,
      140735363204707,
      140735363200179,
      140735362063667,
      140735361856246,
      4295758353,
      4295759600,
      4296889279,
      4295077955,
      4295127767,
      4294985022,
      4294984940
  )
  terminate called after throwing an instance of 'NSException'

  I believe the issue is with Tk-Cocoa because the same script has normal scrolling with Tk-Carbon (both 8.5.3 and 8.4.7).  


  Below is the script that causes the error:

  package require tablelist


  image create photo folder -data {R0lGODlhEAAMAKEAAAD//wAAAPD/gAAAACH5\
              BAEAAAAALAAAAAAQAAwAAAIghINhyycvVFsB\
              QtmS3rjaH1Hg141WaT5ouprt2HHcUgAAOw==}

  image create photo filename -data {R0lGODlhDAAMAKEAALLA3AAAAP//
  8wAAACH5\
              BAEAAAAALAAAAAAMAAwAAAIgRI4Ha+IfWHsO\
              rSASvJTGhnhcV3EJlo3kh53ltF5nAhQAOw==}


  frame .listframe
  pack .listframe -fill both -expand yes



      tablelist::tablelist .listframe.listbox -columns {20 "File" 20 "Path"} -yscrollcommand [list .listframe.vsb set] -width 100 -height 10 -stretch all -showseparators no  -labelcommand tablelist::sortByColumn

  scrollbar .listframe.vsb -orient vertical -command [list .listframe.listbox yview]

  pack .listframe.listbox -side left -fill both -expand yes
  pack .listframe.vsb -side right -fill y -expand no


  for {set i 1} {$i < 6000} {incr i 1} {
       lappend numberlist [list file_$i path_$i]
  }

  foreach item $numberlist {
      .listframe.listbox insert end $item
   .listframe.listbox cellconfigure end,0 -image filename
   .listframe.listbox cellconfigure end,1 -image folder
  }


tkt_uuid: 788706ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: Fix bind to Alt and Meta modifiers on MacOSX
comment:
  Currently the Command and Option keys can only be bound
  by using their aliases Mod1 and Mod2.

  This patch corrects that by replacing code that tries to
  compute support for these in an X11 fashion (and fails)
  with code that just sets the necessary flags
  unconditionally.  On MacOS all those variations just
  don't exist, so there is no need for the computations.


tkt_uuid: 1747794fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: None
title: Menu posts outside screen
comment:
  with

  set ::tk::mac::useCustomMDEF 1

  a menubutton posts its menu outside the right screen border if the menubutton is very close to the right screen border.

  with

  set ::tk::mac::useCustomMDEF 0

  the menu will always be inside the screen border.


  kind regards,
  uwe


tkt_uuid: 219986ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Duplicate
title: Solaris 2.5.1: Failed focus and unixEmbed tests on solaris 2.5.1
comment:
  OriginalBugID: 2116 Bug
  Version: 8.1
  SubmitDate: '1999-05-21'
  LastModified: '1999-11-23'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: jenn
  RelatedBugIDs: 2181
  OS: Solaris
  OSVersion: 2.5.1
  Machine: Other
  ClosedDate: '1999-11-23'


  Name:
  Hans Werner Strube

  ReproducibleScript:
  (In subdirectory unix/ :) make test

  ObservedBehavior:
  tk8.1 in Solaris 2.5.1 on UltraSPARC 1,
      compiler: Sun cc, version SC4.0 18 Oct 1995 C 4.0,
      configure --enable-threads
      
      Running "make test" yields the following failed tests:
      focus, unixEmbed; detailed output:
      
      focus.test
      
      ==== focus-5.1 ChangeXFocus procedure, don't take focus unless have it
      FAILED
      ==== Contents of test case:
      
          focusSetup
          focus -force .t
          update
          set result [focus]
          send [dobg {tk appname}] {focus -force .; update}
          lappend result [focus]
          focus .t.b2
          update
          lappend result [focus]
      
      ---- Result was:
      .t .t {}
      ---- Result should have been:
      .t {} {}
      ==== focus-5.1 FAILED
      
      unixEmbed.test
      
      ==== unixEmbed-5.1 EmbedFocusProc procedure, FocusIn events 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
      bind .t1 <FocusIn> {lappend x "focus in %W"}
      bind .t1 <FocusOut> {lappend x "focus out %W"}
      set x {}
          }
          focus -force .f1
          update
          dobg {set x}
      
      ---- Result was:
      
      ---- Result should have been:
      {focus in .t1}
      ==== unixEmbed-5.1 FAILED

  DesiredBehavior:
  No "FAILED" messages.


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


  Name:
  Vince Darley

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

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

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

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

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

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



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

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


  - eric
   
  -- 03/21/2000 ericm


tkt_uuid: 492259ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 7 High
foundin: obsolete: 8.4a4
resolution: Fixed
title: wm-stackorder-5.1 fails
comment:
  Using the current HEAD Tcl and Tk on Solaris 8,
  CDE window manager:

  ==== wm-stackorder-5.1 overrideredirect does not change
  stackorder FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t
      wm overrideredirect .t 1
      update
      raise .
      wm stackorder . isabove .t

  ---- Result was:
  0
  ---- Result should have been:
  1
  ==== wm-stackorder-5.1 FAILED


tkt_uuid: 220628ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: Bug of "wm deiconify"
comment:
  OriginalBugID: 3687 Bug
  Version: 8.0.5
  SubmitDate: '1999-11-24'
  LastModified: '1999-12-14'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: Windows 95/98/NT
  Machine: Windows95/P133
  FixedDate: '1999-12-14'
  FixedInVersion: 8.3b1


  Name: Chengye Mao



  Comments:

  I tested the modification for Tk8.0 and it worked fine.

  The same bug can also be found in Tk 8.1.x, 8.2.x and

  the fix should be the same.



  ReproducibleScript:

  #Script 1:

  tk_dialog .d Test Test warning 1 Ok Quit





  #Script 2:

  toplevel .t

  wm withdraw .t; wm geom .t +300+20; wm deiconify .t



  ObservedBehavior:

  In Scripts 1 and 2, both the dialog window .d and 

  the toplevel window .t were positioned at wrong places.



  DesiredBehavior:

  The dialog window .d should be at the screen center and

  the toplevel .t should be at (x=300,y=20)



  Patch:

  /* 

      the following are the modified code segment of "wm deiconify" 

      in source file "tkWinWm.c", starting from line# 1310.

  */



      } else if ((c == 'd') && (strncmp(argv[1], "deiconify", length) == 0)) {

  if (argc != 3) {

      Tcl_AppendResult(interp, "wrong # arguments: must be \"",

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

      return TCL_ERROR;

  }

  if (wmPtr->iconFor != NULL) {

      Tcl_AppendResult(interp, "can't deiconify ", argv[2],

      ": it is an icon for ", winPtr->pathName, (char *) NULL);

      return TCL_ERROR;

  }

          if (winPtr->flags & TK_EMBEDDED) {

              Tcl_AppendResult(interp, "can't deiconify ", winPtr->pathName,

                      ": it is an embedded window", (char *) NULL);

              return TCL_ERROR;

          }



          /*

          11/14/99 Chengye Mao. The following if statement takes care

          the problem.



          If WM_UPDATE_PENDING is true, a pending UpdateGeometryInfo may

          need to be called first to update a withdrew toplevel's geometry

          before it is deiconified by TkpWmSetState.



          UpdateGeometryInfo has no effect on an iconified toplevel.

          */



          if (wmPtr->flags & WM_UPDATE_PENDING) {

              Tcl_CancelIdleCall(UpdateGeometryInfo, (ClientData) winPtr);

              UpdateGeometryInfo((ClientData) winPtr);

          }



  TkpWmSetState(winPtr, NormalState);



  PatchFiles:

  Affected file: tkWinWm.c





  Added to 8.3b1. 
  -- 12/14/1999 hobbs


tkt_uuid: 220102ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 1 Zero
foundin: obsolete: 8.0
resolution: Invalid
title: off by one error in canvas item boundaries
comment:
  OriginalBugID: 567 Bug
  Version: 8.0
  SubmitDate: '1998-04-15'
  LastModified: '2000-04-03'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: ericm
  RelatedBugIDs: 3354 2251
  OS: All
  FixedInVersion: NA
  ClosedDate: '2000-04-03'


  From: "Munagala V. S. Ramanath" <ram@netcom.com>

  At line 1759 of tkCanvas.c (tk8.0) you have this loop:

        for (itemPtr = canvasPtr->firstItemPtr; itemPtr != NULL;
                itemPtr = itemPtr->nextPtr) {
            if ((itemPtr->x1 >= screenX2)
                    || (itemPtr->y1 >= screenY2)
                    || (itemPtr->x2 < screenX1)
                    || (itemPtr->y2 < screenY1)) {
                if (!itemPtr->typePtr->alwaysRedraw
                        || (itemPtr->x1 >= canvasPtr->redrawX2)
                        || (itemPtr->y1 >= canvasPtr->redrawY2)
                        || (itemPtr->x2 < canvasPtr->redrawX1)
                        || (itemPtr->y2 < canvasPtr->redrawY1)) {
                    continue;
                }
            }
            (*itemPtr->typePtr->displayProc)((Tk_Canvas) canvasPtr, itemPtr,
                    canvasPtr->display, pixmap, screenX1, screenY1, width,
                    height);
        }

  It appears that all 4 strict inequalities (<) above should instead
  be plain inequality (<=) since your invariant for bboxes is that
  x1/y1 are _included_ but x2/y2 are _excluded_. I was getting
  unnecessary calls to my canvas item displayProc when the item
  abutted but did not overlap the region to be refreshed and traced 
  it down to this code.

  The code shown appears correct with respect to the invarient for bbox:  the object is refreshed if

  screenX1 <= objectX < screenX2 &&
  screenY1 <= objectY < screenY2 &&
  redrawX1 <= objectX < redrawX1 &&
  redrawY1 <= objectY < redrawY2 &&
  !alwaysRedraw

  That is, if the object is in the bounding area defined by the coordinates, including the coordinates on the top and left (x1 and y1) and up to but not including the coordinates on the right and bottom (x2 and y2).

  - eric

  -- 04/03/2000 ericm


tkt_uuid: 700305ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: OS X Aqua: Entry controls get drawn in incorrect places
comment:
  This bug appears to occur only in the MacOS X Aqua Wish
  Shell.app.

  In the below example code, the entry widget gets drawn
  in the upper-left corner of the toplevel dialog,
  overlapping the label that it should be beside.

  If you click on where the entry widget is drawn,
  nothing happens.  If you click on where the entry
  widget is SUPPOSED to be, it takes focus as expected.

  Below is the shortest code I could get to reproduce the
  bug.  If you uncomment the 'update idletasks', the bug
  goes away.  It seems to only happen in a separately
  created (non-.) toplevel.  If I remove the selection
  command, the bug goes away.  The bug does not seem to
  happen with pack.

  Here's the code:

      toplevel .tl
      label .tl.l -text Label
      entry .tl.e
      grid .tl.l .tl.e
      # update idletasks
      .tl.e selection range 0 end


tkt_uuid: 1708823fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 29. Colormaps and Visuals
priority: 5 Medium
foundin: obsolete: 8.4.12
resolution: None
title: Wish crash on Windows XP when trying to free a color
comment:
  On Windows XP, Wish sometimes crashes after showing a dialog box stating "Tried to free a color that isn't allocated.".

  For me, this happens whilst running a Tk application when another application (e.g., a game) takes over the full screen and changes screen resolution (and probably screen color mode).

  Other users have seen this as well seemingly from time to time. Refer, e.g., to http://www.amsn-project.net/forums/viewtopic.php?t=584.

  This might well be a reoccurrence of bug #570748 (http://sourceforge.net/tracker/index.php?func=detail&aid=570748&group_id=12997&atid=112997).

  Regards,
  Sebastian


tkt_uuid: 1372483fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: None
title: Change mouse cursor appearance in menus
comment:
  In top level menus and menubuttons, the cursor changes
  from a left pointing arrow to a right pointing arrow as
  soon as a selection is made, and remains this way while
  the menu is open. This is inconsistent with other Linux
  applications and desktops which do not change the
  cursor direction. Request the cursor direction remains
  unchanged in menus.


tkt_uuid: 1068293fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 6
foundin: obsolete: 8.5.6
resolution: Accepted
title: TkAqua: CompleteIdlers() is never called for menubar menus
comment:
  It appears that a menu's -postcommand on Aqua is not
  called until after the menu is posted, or else if it
  makes changes to the menu they are not reflected until
  the next time the menu is posted.  A short example:

  menu .m
  .m add cascade -label Foo -menu .m.f
  menu .m.f -postcommand Foo
  .m.f add command -label "(Empty)"

  set i 1

  proc Foo {} {
          .m.f delete 0 end
          .m.f add command -label "$::i - Foo1"
          .m.f add command -label "$::i - Foo2"
          .m.f add command -label "$::i - Foo3"
          .m.f add command -label "$::i - Foo4"
          incr ::i
  }

  . config -menu .m

  Each time the menu is posted, its contents will change
  to some so the number indicates how many times it's
  been posted.  It's expected that the -first- time it's
  posted it will show "1 - Foo1" etc.  Instead it shows
  "(Empty)".  It's expected that the second time it's
  posted it will show "2 - Foo1" etc.  Instead it shows
  "1 - Foo1" etc.


tkt_uuid: 220162ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: several tests failed
comment:
  OriginalBugID: 1848 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-16'
  LastModified: '1999-08-31'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Digital Unix
  OSVersion: 4.0E
  Machine: Other
  ClosedDate: '1999-08-31'


  Name:
  Manuel Op de Coul

  CustomShell:
  none

  Comments:
  I used cc for both Tcl and Tk. With gcc, many warnings are emitted about
      wrong function arguments.
      I am using a 64 bit machine.

  ReproducibleScript:
  make test >test.log

  ObservedBehavior:
  grid.test
      menubut.test
      scale.test
      textIndex.test
      unixFont.test
      unixWm.test

      failed. I wanted to attach the test.log file but can't do in this form.
      What's the email address?

  From: manuel.op.de.coul@ezh.nl
  To: support@scriptics.com
  Date: Fri, 16 Apr 1999 15:45:55 +0200
  Subject: Re: [Bug Tk 8.0.5] several tests failed
  Content-disposition: inline
  Status: O

  1.

  (See attached file: TEST.LOG)

  2.text/plain
  LD_LIBRARY_PATH=`pwd`:/usr/users/coul1358/tcl8.0.5/unix:/usr/local/lib/lib;  export LD_LIBRARY_PATH;  SHLIB_PATH=`pwd`:/usr/users/coul1358/tcl8.0.5/unix:;  export SHLIB_PATH;  TCL_LIBRARY=/usr/users/coul1358/tcl8.0.5/library; export TCL_LIBRARY;  TK_LIBRARY=./../library; export TK_LIBRARY;  ( echo cd ./../tests\; source all\; exit )  | ./tktest -geometry +0+0
  (will skip non-portable tests)
  bell.test
  Bell should ring now ...
  bgerror.test
  bind.test
  button.test
  canvImg.test
  canvPs.test
  canvRect.test
  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:
  {-5 0 6 19} {-1 0 10 19} {-1 -9 10 10} {-1 -19 10 0} {-5 -19 6 0} {-10 -19 1 0} {-10 -9 1 10} {-10 0 1 19} {-5 -9 6 10}
  ---- Result should have been:
  {-6 0 5 19} {-1 0 10 19} {-1 -10 10 9} {-1 -19 10 0} {-6 -19 5 0} {-10 -19 1 0} {-10 -10 1 9} {-10 0 1 19} {-6 -10 5 9}
  ---- canvText-6.1 FAILED
  canvWind.test
  canvas.test
  clipboard.test
  clrpick.test
  Skipped tests clrpick2.1, clrpick2.2 and clrpick2.3 because
  you ran out of colors in your color palette, and this would
  have caused the tests to generate errors.
  cmds.test
  color.test
  entry.test
  event.test
  filebox.test
  focus.test

  ==== focus-5.1 ChangeXFocus procedure, don't take focus unless have it
  ==== 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]

  ==== Test generated error:
  X server insecure (must use xauth-style authorization); command ignored
  focusTcl.test
  font.test
  frame.test
  geometry.test
  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
  id.test
  image.test
  imgBmap.test
  imgPPM.test
  imgPhoto.test
  listbox.test
  macEmbed.test
  macFont.test
  macMenu.test
  macWinMenu.test
  macscrollbar.test
  main.test
  menu.test
  menuDraw.test
  menubut.test

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

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

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

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

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

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

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

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

  ==== Result was:
  88 508
  ---- Result should have been:
  88 458
  ---- scale-7.1 FAILED

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

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

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

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

      .t index @12,9

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

  ==== textTag-16.2 TkTextPickCurrent procedure
  ==== Contents of test case:

      event gen .t <ButtonRelease-1> -state 0x100 -x $x1 -y $y1
      event gen .t <Motion> -x $x2 -y $y2
      set x [.t index current]
      .t tag add big 3.0
      update
      lappend x [.t index current]

  ==== Result was:
  3.2 3.2
  ---- Result should have been:
  3.2 3.1
  ---- textTag-16.2 FAILED

  ==== textTag-16.6 TkTextPickCurrent procedure
  ==== Contents of test case:

      foreach i {a b c d} {
  .t tag remove $i 1.0 end
      }
      event gen .t <Motion> -x $x1 -y $y1
      .t tag bind a <Enter> {.t tag add big 3.0 3.2}
      .t tag add a 3.2
      event gen .t <Motion> -x $x2 -y $y2
      update
      .t index current

  ==== Result was:
  3.2
  ---- Result should have been:
  3.1
  ---- textTag-16.6 FAILED

  ==== textTag-16.7 TkTextPickCurrent procedure
  ==== Contents of test case:

      foreach i {a b c d} {
  .t tag remove $i 1.0 end
      }
      event gen .t <Motion> -x $x1 -y $y1
      .t tag bind a <Leave> {.t tag add big 3.0 3.2}
      .t tag add a 2.1
      event gen .t <Motion> -x $x2 -y $y2
      .t index current

  ==== Result was:
  3.2
  ---- Result should have been:
  3.1
  ---- textTag-16.7 FAILED
  textWind.test
  tk.test
  unixButton.test
  unixEmbed.test
  unixFont.test

  ==== unixfont-2.10 TkpGetFontFromAttributes: scalable font found
  ==== Contents of test case:

      lindex [font actual {-family courier -size 37}] 3

  ==== Result was:
  17
  ---- Result should have been:
  37
  ---- unixfont-2.10 FAILED

  ==== unixfont-8.3 AllocFont procedure: can't parse info from name
  ==== Contents of test case:

      if [catch {set a [font actual a12biluc]}]==0 {
  string compare $a "-family a12biluc -size 0 -weight normal -slant roman -underline 0 -overstrike 0"
      } else {
  set a 0
      }

  ==== Result was:
  1
  ---- Result should have been:
  0
  ---- unixfont-8.3 FAILED
  unixMenu.test
  unixWm.test

  ==== unixWm-41.2 ConfigureEvent procedure, menubars
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 300 -height 200 -bd 2 -relief raised
      wm geom .t +0+0
      update
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      frame .t.m -bd 2 -relief raised -height 20
      testmenubar window .t .t.m
      update
      set result {}
      bind .t <Configure> {
  if {"%W" == ".t"} {
      lappend result "%W: %wx%h"
  }
      }
      bind .t.m <Configure> {lappend result "%W: %wx%h"}
      wm geometry .t 200x300
      update
      lappend result [expr [winfo rootx .t.m] - $x]  [expr [winfo rooty .t.m] - $y]  [winfo width .t.m] [winfo height .t.m]  [expr [winfo rootx .t] - $x] [expr [winfo rooty .t] - $y]  [winfo width .t] [winfo height .t]

  ==== Result was:
  {.t.m: 200x20} {.t: 200x300} -11 -31 200 20 -11 -11 200 300
  ---- Result should have been:
  {.t.m: 200x20} {.t: 200x300} 0 0 200 20 0 20 200 300
  ---- unixWm-41.2 FAILED

  ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a toplevel, x-coords
  ==== 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
  util.test
  visual.test
  winButton.test
  winClipboard.test
  winFont.test
  winMenu.test
  winWm.test
  window.test
  winfo.test
  This application hasn't been compiled with the testwrapper command,
  therefore I am skipping all of these tests.



  the following were marked nonportable in 8.1, so they will be skipped unless the user specifies to run them.
  canvText-6.1
  grid-6.9
  menubutton-*
  scale-7.*
  textIndex-5.1
  unixWm-41.2

  the following were not acted upon:
    unixFont-*, unixWm-50.1: either a bug in window manager or nonPortable
    focus-5.1:  gets skipped if server is insecure in 8.1
    textTag-16.7: couldn't reproduce this (likely nonPortable)
  04/20/1999 13:44 - hershey -


tkt_uuid: 2116837fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: obsolete: 8.4.14
resolution: Fixed
title: EZ Fix for <<Copy>> <<Paste>> <<Cut>> to work w/CAP-LOCK
comment:
  Under Tcl/Tk 8.4.14 and earlier the default sequences for the <<Copy>> <<Paste>> and <<Cut>> virtual events do not operate with the CAPS-LOCK key on. Solution: include sequences for <Control-Key-C> <Control-Key-V> and <Control-Key-X> (upper case key letters) to the respective virtual bindings to allow bindings on these events to operate independent of CAPS-LOCK position. Tested on Windows (XP) version 8.4.14.


tkt_uuid: 925653ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: None
title: Win9X, i18n: codepage of error messages
comment:
  I used binaries - ActiveTcl8.4.4, 8.4.5

  This applies to non-English Win9X, for languages where
  codepages/encoding for DOS and Windows differ.

  "Console applications" in Win9X return "error text" in
  DOS codepage. Whereas "wish" always displays Error text
  in Windows codepage. This leads to unreadable Error
  messages returned to "wish" by console apps.

  (Sometimes in Activetcl it's possible to save the trace
  to journal (into logfile). In this case user/programmer
  can read saved file (in DOS-codepage) )

  This is no problem for English users (as English
  codepage is the same).
  This can be of less importance for end-user if we
  assume that there are no error messages happening in
  the "final" program.

  For example (for me particulary):
  Russian DOS codepage is cp866
  Russian WIN codepage is cp1251

  Example script:
  place these two files in the same directory and run the
  tcl-script
  this will display error, returned by VBScript
  the problem is visible on localized versions of Windows 9X

  file1: testerr.tcl
  #--------------------------------------------
  # CScript - console version of Win9X interpreter for
  VBScript, JScript et al
  exec -- cscript [file join [file dirname [info script]]
  "test.vbs"]
  #--------------------------------------------

  file2: test.vbs
  '-This is VBScript-------------------------
  Msgbox
  '---------------------------------------------


tkt_uuid: 2971663fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Up and down arrow keys in entry fields, Mac Cocoa
comment:
  Pressing the up or down arrow keys in an entry field in Tk Cocoa 8.6 from Jan 8, 2010 source code causes unicode arrow key codes to be placed in the text variable associated for up or down arrows.  Those inserted are invisible in the displayed entry field and lead to errors parsing the entry text by client code which the user cannot understand because they do not see the invisible characters.  In general Tk ignores invisible characters (e.g. ctrl-Y, up arrow, ...) that are typed into entry fields unless they have special bindings (like left/right arrow for moving the insert cursor).  Aqua Tk (Carbon) 8.5.8 does not put invisible arrow keys in entry fields, nor does Tk Mac X11 8.5.8.  I believe the correct behavior is to not put the up / down arrow key unicode into the entry field text variable when the user presses those keys.

  Here's a Wish script demonstrating the problem.

  variable tv "test"
  entry .e -textvariable tv
  pack .e

  Click into the entry field, press the down arrow key, then display the string

  puts $tv
  -> tei\234\201st

  This problem may be related to the fact that the %A substitution used to show unicode for KeyPress events is non-empty for Tk Cocoa 8.6 while it is empty for Tk Carbon 8.5.8.


tkt_uuid: 1876493fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Fixed
title: Standard option -state not documented
comment:
  The -state option is not documented on the standard options page (http://www.tcl.tk/man/tcl8.5/TkCmd/options.htm), although for example [ttk::checkbutton]'s man page (http://www.tcl.tk/man/tcl8.5/TkCmd/ttk_checkbutton.htm) links to it.


tkt_uuid: 220544ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: text man page incorrect
comment:
  OriginalBugID: 2277 Bug
  Version: 8.1
  SubmitDate: '1999-06-22'
  LastModified: '2000-01-18'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  Machine: Other
  FixedDate: '2000-01-18'
  FixedInVersion: 8.3


  Name:
  Greg McFarlane

  ReproducibleScript:
  In the description of mark gravity in the text widget man page,
      the following line:
          "position will appear to the right of the mark.  The gravity"
      should be:
          "position will appear to the *left* of the mark.  The gravity"



  Well, that's a spot of the code that definitely needs reading
  twice to understand it.  I've changed it to:

    If a mark has left gravity, then the mark is treated as if it
    were attached to the character on its left, so the mark will
    remain to the left of any text inserted at the mark position.
    If the mark has right gravity, new text inserted at the mark
    position will appear to the left of the mark (so that the mark
    remains rightmost).  The gravity for a mark defaults to \fBright\fR.
   
  -- 01/18/2000 hobbs


tkt_uuid: 2891877fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: 32k pixel limit when viewing a scrolled frame on a canvas
comment:
  I was told at Tcl 2009 that Tk windows on X11 should no longer have a 32k pixel limit, and any such limitations should be reported as bugs.

  A canvas item that is a frame can be much larger than 32k pixels, but the region that can be viewed by scrolling is never much more than 32k.

  The attached file is a test that demonstrates the problem.

  Tested on ActiveTcl 8.5.7.1 and 8.6.0.0b2, Linux x86 with X-server Xorg-1.5.3


tkt_uuid: 1117435fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 8
foundin: obsolete: 8.5a3
resolution: Fixed
title: typeListPtr mutex undeclared
comment:
  generic/tkCanvas.c line 956 and later in latest (as of 1830 GMT 
  6Feb05) anonymous cvs head contains three references to a 
  mutex "typeListPtr" which is undeclared. A quick grep of the source 
  tree shows that these are the only refs to the mutex anywhere and 
  it is not declared anywhere. This breaks the build on at least Mac 
  OS X, but I would assume everywhere else too.


tkt_uuid: 1281243fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Wont Fix
title: panedwindow sash coord documentation bug
comment:
  Documentation for .panedwindow sash coord says:

  Return the current x and y coordinate pair for the sash 
  given by index. Index must be an integer between 0 and 
  1 less than the number of panes in the panedwindow. 
  The coordinates given are those of the top left corner of 
  the region containing the sash.

  1.
  "between 0 and 1" is clearly wrong and should be 
  suppressed.

  2.
  In what coordinate system are these x and y returned?


  Francois


tkt_uuid: 749011ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 51. [place]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: None
title: place.test fails
comment:
   This test fails on Tru64Unix 5.1A with tcl8.4.3/tk-cvs
   but NOT tcl8.4.3/tk8.4.3(maybe it's expected when
   messing up versions):

  ==== place-4.2 ConfigureSlave procedure, bad -in option
  FAILED
  ==== Contents of test case:

      place forget .t.f2
      list [winfo manager .t.f2]  [catch {place .t.f2 -in
  .t.f2} err] $err  [winfo manager .t.f2]

  ---- Result was:
  {} 1 {can't place .t.f2 relative to itself} place
  ---- Result should have been (exact matching):
  {} 1 {can't place .t.f2 relative to itself} {}
  ==== place-4.2 FAILED


tkt_uuid: 220000ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: focus command not returning corect window
comment:
  OriginalBugID: 2307 Bug
  Version: 8.0.4
  SubmitDate: '1999-07-01'
  LastModified: '1999-08-07'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 1506
  OS: AIX
  OSVersion: 4.1, 4.3
  Machine: RS6000
  ClosedDate: '1999-08-07'


  Name:
  Anthony Johnson

  Extensions:
  8.0p2 and 8.0.4, TclX8.0.3, TkX8.0.3

  ReproducibleScript:
  focus <-- returns NULL
         toplevel .test
         raise .test
         focus .test
         focus <-- returns NULL
      ---------------------
         toplevel .test
         raise .test
         focus .test
         update
         focus <--- returns "."
      ------------------
         update
         toplevel .test
         raise .test
         focus .test
         focus <--- returns .test
      -------------------
         update
         toplevel .test
         raise .test
         focus .test
         focus <--- returns NULL
         destroy .test
         toplevel .test
         raise .test
         focus .test
         focus <--- returns NULL
      -------------------
          update
         toplevel .test
         raise .test
         focus .test
         focus <--- returns .test
         destroy .test
         update
         toplevel .test
         raise .test
         focus .test
         focus <--- returns .test

  ObservedBehavior:
  Using "update idletasks" instead of "update" has the same affect as
      omitting it
      entirely. I cannot use "update" becasue I do not want to start an event
      loop
      within my proc. Even when using "update", it doesnt appear to return the
      correct
      window I last focused on. Any time a window is destroyed, the focus
      command
      returns NULL until update is executed again.

  DesiredBehavior:
  Focus should return the name of the toplevel window which last had
      focus.


tkt_uuid: 1080290fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 42. Photo Image|GIF
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Thread-safety for GIF code
comment:
  The attached patch gives thread-safety for the GIF
  reading and writing code. The GIF reading code gets
  thread-safety using thread-local variables, and the GIF
  writing code has a mutex wrapped about it to protect
  its extensive static variables.


tkt_uuid: 1518577fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Build error on Cygwin - tkWinDefault.h missing
comment:
  I tried building tk8.5a4 on Cygwin and it failed in
  first instance because of tkWinDefault.h.

  I changed the include statement in default.h to:

  #include "../win/tkWinDefault.h"

  and then it all worked okay. 

  (I do not know whether this is a proper solution to the
  problem - it just solved my immediate problem)


tkt_uuid: 526209ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: semi-random event-* test failures
comment:
  The event-* tests seem to fail for semi-random
  reasons.  I've figured out at least some of
  a few of the reasons.  Leaving it to Mo to find
  solutions.

  Occasionally, one gets the error:

  can't read "y1": no such variable

  This happens when [$text bbox $ind] returns an empty
  list, and according to the [text] docs, that happens
  when the index $ind of $text is not visible.  I
  believe that if by chance windows overlap during the
  test in such a way that the $ind of $text is obscured,
  you get this error.

  I also see the tests event-click-drag-1.2 and
  event-double-click-drag-1.2 fail on occasion.
  When they fail, only the first character of
  the test string has been "typed in" to the entry.
  This is because that entry widget has lost the
  focus.  This happens when the window manager
  is configured to have "focus follows mouse" and
  it just happens that the mouse cursor was in the text
  widget of the prior test, but is currently not
  in the entry widget of the current test (because
  the entry is smaller than the text).  Because the
  mouse cursor has "moved out" of the window (even
  though it is still), the focus is shifted to whatever
  window currently lies below the mouse, and the
  "typing" events are lost.

  This can happen even with the mouse stationary.
  It is easy to induce even more errors if one moves
  the mouse around during the event-* tests in a
  window manager configured for "focus follows mouse".


