# ticket

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: 220612ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: make install permission fix
comment:
  OriginalBugID: 3367 RFE
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-01-12'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3366 3389
  OS: IRIX
  OSVersion: 6.5
  FixedDate: '2000-01-12'
  FixedInVersion: 8.3b2


  Name:
  Albert Chin

  DesiredBehavior:
  While doing a 'make install', if the build was done on an NFS mounted
      partition and the 'make install' is being run as root, the execute bit
      on several files is changed (like install-sh). Rather than outright
      changing the permission, it would be wiser to test if this was needed
      first. The patch below fixes this.

  Patch:
  ftp://ftp.thewrittenword.com/incoming/pub/tk8.2.1.patch

  PatchFiles:
  unix/Makefile.in



  fixed in 8.3b2. 
  -- 01/12/2000 hobbs


tkt_uuid: 220613ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: resizing toplevel with menu generates fatal X Error
comment:
  OriginalBugID: 3377 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-01-07'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: RedHat Linux 6.0
  FixedDate: '2000-01-07'
  FixedInVersion: 8.3b2


  Name:

  Jonas Beskow


  ReproducibleScript:

  menu .m

      .m add cascade -label [info patchlevel]

      . config -menu .m


      # resize the toplevel window vertically until only the menubar is

      visible (i.e. window area below the 

      # menubar is exactly of zero height - the error is especially easy to

      produce on window managers with 

      # dynamic content window resizing, e.g. KDE)


  ObservedBehavior:

  wish exits with the following 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:  180

        Current serial number in output stream:  181


  DesiredBehavior:

  wish continues to run with no error


  Patch:

  *** tkUnixWm.c  Thu Oct 14 15:31:06 1999

  --- tkUnixWm.c.fix      Thu Oct 14 15:30:52 1999

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

  *** 2074,2079 ****

  --- 2074,2080 ----

        TkWindow *wrapperPtr = wmPtr->wrapperPtr;

        TkWindow *winPtr = wmPtr->winPtr;

        TkDisplay *dispPtr = wmPtr->winPtr->dispPtr;

  +     Tk_ErrorHandler handler;


        /* 

         * Update size information from the event.  There are a couple of

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

  *** 2203,2212 ****

         * Make sure that the toplevel and menubar are properly positioned within

         * the wrapper.

         */

  ! 

        XMoveResizeWindow(winPtr->display, winPtr->window, 0,

              wmPtr->menuHeight, (unsigned) wrapperPtr->changes.width,

              (unsigned) (wrapperPtr->changes.height - wmPtr->menuHeight));

        if ((wmPtr->menubar != NULL)

              && ((Tk_Width(wmPtr->menubar) != wrapperPtr->changes.width)

              || (Tk_Height(wmPtr->menubar) != wmPtr->menuHeight))) {

  --- 2204,2215 ----

         * Make sure that the toplevel and menubar are properly positioned within

         * the wrapper.

         */

  !     handler = Tk_CreateErrorHandler(winPtr->display, -1, -1, -1,

  !                                   (Tk_ErrorProc *) NULL, (ClientData) NULL);

        XMoveResizeWindow(winPtr->display, winPtr->window, 0,

              wmPtr->menuHeight, (unsigned) wrapperPtr->changes.width,

              (unsigned) (wrapperPtr->changes.height - wmPtr->menuHeight));

  +     Tk_DeleteErrorHandler(handler);

        if ((wmPtr->menubar != NULL)

              && ((Tk_Width(wmPtr->menubar) != wrapperPtr->changes.width)

              || (Tk_Height(wmPtr->menubar) != wmPtr->menuHeight))) {


  PatchFiles:

  tkUnixWm.c




  fixed in 8.3b2. 
  -- 01/07/2000 hobbs


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


  Name:
  Jan Nijtmans

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

  ObservedBehavior:
  tkConfig.sh contains the line:
          TK_SHARED_BUILD=

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

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

  PatchFiles:
  configure.in



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


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


  Name:
  Peter J Turner

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

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

      Information and comments please!

      Regards

      Peter Turner



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


tkt_uuid: 220616ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: Tk crashed with NULL pointer reference on exit
comment:
  OriginalBugID: 3402 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-02-09'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3236
  OS: Windows NT
  FixedDate: '2000-02-09'
  FixedInVersion: 8.3


  Name:

  Murugasamy


  CVS:

  RCS: @(#) $Id: tkMenu.c,v 1.5 1999/04/21 21:53:26 rjohnson Exp $


  CustomShell:

  Refer to section 9.


  Comments:

  The variables newObjv[0] and newObjv[1]in function DestroyMenuInstance

      are incremented without checking for NULL.


      In the first place these objects should not be NULL.


  ReproducibleScript:

  When menu entries which has sub-menus are deleted and added with the

      same name, TK chashes with NULL pointer memory read.


  ObservedBehavior:

  On exit the tk displays the following error:

      The instruction at "0x00445bda" referenced memory at "0x00000000". The

      memory could not be "read".


  DesiredBehavior:

  Fix the NULL pointer reference.


  Patch:

  File: generic\tkMenu.c

  Function: DestroyMenuInstance

  Old lines:

      for (; cascadePtr != NULL; cascadePtr = nextCascadePtr) {

      nextCascadePtr = cascadePtr->nextCascadePtr;


      if (menuPtr->masterMenuPtr != menuPtr)

      Tcl_Obj *menuNamePtr = Tcl_NewStringObj("-menu", -1);


  Fixed Lines:

      for (; cascadePtr != NULL; cascadePtr = nextCascadePtr) {

      nextCascadePtr = cascadePtr->nextCascadePtr;


      if (menuPtr->masterMenuPtr != menuPtr 

      && cascadePtr->menuPtr->masterMenuPtr->entries[cascadePtr->index]->namePtr != NULL) {

      Tcl_Obj *menuNamePtr = Tcl_NewStringObj("-menu", -1);


  PatchFiles:

  generic\tkMenu.c




  A real snippet of code to reproduce this would have been much more
  useful.  I cannot reproduce this.  I have placed checks in
  DestroyMenuInstance to see if the newObjv args aren't NULL before
  changing the ref count.  Bug 3236 shows a related problem, with
  the same bug fault, but also no script, and has a different patch
  (from the same submitter). 
  -- 02/09/2000 hobbs


tkt_uuid: 220617ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: <<ListboxSelect>> not documented
comment:
  OriginalBugID: 3500 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-08'
  LastModified: '1999-12-16'
  Severity: LOW
  Status: Released
  Submitter: hobbs
  ChangedBy: hobbs
  OS: All
  FixedDate: '1999-12-16'
  FixedInVersion: 8.3b1


  Should also make examples of using it.

  This is in 8.3b1. 
  -- 12/16/1999 hobbs


tkt_uuid: 220618ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: A typo that is easy to fix, and can cause BIG problems if not fixed.
comment:
  OriginalBugID: 3517 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-08'
  LastModified: '1999-11-18'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3518
  OS: Windows NT
  FixedDate: '1999-11-18'
  FixedInVersion: 8.2.3


  Name:

  Kory Hopkins


  ReproducibleScript:

  I have a long script that manages to create the bug.  I haven't bothered to make a simple one.  But if you look at the code changes you may be able to see how to create one.  I think it all depends on the names you give tk objects and/or the order you create them.  This determines the order that things are removed from the tcl hash table.  I had something being deleted twice and I found the fix.


  Look in file: tkentry.c, EntryCmdDeletedProc()


  The old line: if (! entryPtr->flags & ENTRY_DELETED) {

  the new line: if (! (entryPtr->flags & ENTRY_DELETED)) {


  those missing brackets have caused a weeks worth of bug hunting.  Please put them in the next version of tcl/tk....




  Fixed for 8.3b1. 
  -- 11/08/1999 hobbs


tkt_uuid: 220619ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: "static" keywork missing from function definitions
comment:
  OriginalBugID: 3520 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-08'
  LastModified: '1999-12-22'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  FixedDate: '1999-12-22'
  FixedInVersion: 8.3


  Name:
  D. Richard Hipp

  ReproducibleScript:
  In the file win/tkWinImage.c, the functions DestroyImage() and ImageGetPixel() should
  (I think) have only file scope.  In other words, their definition should begin with the
  keyword "static".  This is not the case.



  Fixed in 8.3b2. 
  -- 12/22/1999 hobbs


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


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

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



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


tkt_uuid: 220621ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: no encoding to/from mac-clipboard
comment:
  OriginalBugID: 3544 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-11'
  LastModified: '2000-01-03'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  FixedDate: '2000-01-03'
  FixedInVersion: 8.3b2


  Name:
  Henk-Jan Kooiman

  Comments:
  There are more problems with special characters on the Mac.
  (Double-clicking on a word selects normal or special characters, but not both)

  ReproducibleScript:
  just type é (char é) in an editor and copy it to a wish text window

  ObservedBehavior:
  You get a ?

  DesiredBehavior:
  é

  Patch:
  In tkMacClipboard.c

  proc TkSelGetSelection
  org:     result = (*proc)(clientData, interp, *handle);
  new:     Tcl_ExternalToUtfDString(NULL, *handle, length, &encodedText);
      result = (*proc)(clientData, interp, encodedText);
      Tcl_DStringFree(&encodedText);

  proc TkSuspendClipboard
  org:PutScrap(length, 'TEXT', buffer);
  new:Tcl_UtfToExternalDString(NULL, buffer, length, &encodedText);
  PutScrap(Tcl_DStringLength(&encodedText), 'TEXT', Tcl_DStringValue(&encodedText));
  Tcl_DStringFree(&encodedText);

  PatchFiles:
  tkMacClipboard.c



  changes made in 8.3b2. 
  -- 01/03/2000 hobbs


tkt_uuid: 220622ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 24. Relief
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: fix for 'thin frame garbage pixels bug'
comment:
  OriginalBugID: 3596 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-12'
  LastModified: '1999-12-20'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  RelatedBugIDs: 2519
  OS: Windows NT
  FixedDate: '1999-12-20'
  FixedInVersion: 8.3b1


  ReproducibleScript:

  frame .in

  label .in.1 -text "One"

  grid .in.1

  frame .in.blah -width 200 -height 11 -relief groove -bd 6

  grid .in.blah

  label .in.2 -text "Two"

  grid .in.2

  pack .in



  console show



  puts stdout "Move the console around over the other window"

  puts stdout "and notice the garbage pixels left behind"





  ObservedBehavior:

  Garbage pixels are left behind.



  Patch:

  The problem is in tk3d.c:



  Tk_Fill3dRectangle checks if:



      if ((width > doubleBorder) && (height > doubleBorder)) {



  and if that isn't true doesn't draw the middle of the frame.  However,

  Tk_Draw3DRectangle first does this:



      if (width < 2*borderWidth) {

  borderWidth = width/2;

      }

      if (height < 2*borderWidth) {

  borderWidth = height/2;

      }



  Hence, if the borderWidth is set to a silly value (as in my code snippet

  above, Tk_Fill will decide not to draw the middle, but then Tk_Draw will

  adjust the borderwidth to a value which leaves a small middle still exposed

  and undrawn).



  A fix is to replace:



      if (relief == TK_RELIEF_FLAT) {

  borderWidth = 0;

      }



  in Tk_Fill3DRectangle with



      if (relief == TK_RELIEF_FLAT) {

  borderWidth = 0;

      } else {

          if (width < 2*borderWidth) {

              borderWidth = width/2;

          }

          if (height < 2*borderWidth) {

      borderWidth = height/2;

          }

      }



  And then that method will correctly decide that it does need to 

  draw the narrow center of the frame.





  Posted To comp.lang.tcl: Posted Successfully







  fixed for 8.3b1. 
  -- 12/20/1999 hobbs


tkt_uuid: 220623ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: file dialog message boxes use wrong parent
comment:
  OriginalBugID: 3616 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-17'
  LastModified: '2000-01-21'
  Severity: LOW
  Status: Released
  Submitter: hobbs
  ChangedBy: ericm
  OS: All Unix
  FixedDate: '2000-01-21'
  FixedInVersion: 8.3


  When executing following code

  $> wish
  % tk_getSaveFile -parent .

  It works OK. When I select an already existing file,
  I get the request message box:
  "File already exists. Do you really want to overwrite it".
  That ok, too.

  But the parent of the message box is wrong.
  It should be the file selection
  dialog itself and not the parent of the file selection dialog.
  This is also wrong on any other message box in tkfbox.tcl.
  Currently, the message can be hidden by the file selection dialog.
  This can irritate the user if s?he uses "Focus follows mouse".




  The code clearly uses the parent of the file dialog.
  Whether this is appropriate needs to be checked.

  -----------

  I corrected the error.  All message boxes in the Unix tk_getSaveFile/tk_getOpenFile dialogs now use the file dialog as the parent instead of the parent of the file dialog.  This is fixed in 8.3.

  - eric

  -- 01/21/2000 ericm


tkt_uuid: 220624ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: Applescript and special characters
comment:
  OriginalBugID: 3644 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-23'
  LastModified: '1999-12-20'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: MacOS 8.6
  Machine: Performa 5300
  FixedDate: '1999-12-20'
  FixedInVersion: 8.3b1


  Name:
  Henk-Jan Kooiman

  Comments:
  The tclMacOSA fix is for the communication from Tcl/Tk to Applescript,
  the tkMacHLEvents-fix is for the communication from Applescript to Tcl/Tk.

  In fact: all text-communication between the OS and Tcl should be converted.

  ReproducibleScript:
  tell application "Wish"
  do script "cd één"
  end tell

  ObservedBehavior:
  Doesn't change to directory één

  DesiredBehavior:
  Do change to directory één

  Patch:
  tkMacHLEvents.c

  procedure ScriptHandler

  declare:
   Tcl_DString encodedText;

  Change:
  tclErr = Tcl_GlobalEval(interp, *theDesc.dataHandle);

  To:
  Tcl_ExternalToUtfDString(NULL, *theDesc.dataHandle, length, &encodedText);
  tclErr = Tcl_GlobalEval(interp, Tcl_DStringValue(&encodedText));
  Tcl_DStringFree(&encodedText);

  tclMacOSA.c

  Declare:
  Tcl_DString encodedText;

  Change:
  sysErr = AECreateDesc(typeChar, Tcl_DStringValue(scrptData), Tcl_DStringLength(scrptData), scrptDesc);

  To:
  Tcl_UtfToExternalDString(NULL, Tcl_DStringValue(scrptData), Tcl_DStringLength(scrptData), &encodedText);
  sysErr = AECreateDesc(typeChar, Tcl_DStringValue(&encodedText), Tcl_DStringLength(&encodedText), scrptDesc);
  Tcl_DStringFree(&encodedText);

  PatchFiles:
  tkMacHLEvents.c, tclMacOSA.c



  fixed in 8.3b1. 
  -- 12/20/1999 hobbs


tkt_uuid: 220625ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: iwidgets::combobox hiding of parent window
comment:
  OriginalBugID: 3645 Bug
  Version: 8.2
  SubmitDate: '1999-11-23'
  LastModified: '1999-12-01'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  Machine: win 98
  FixedDate: '1999-12-01'
  FixedInVersion: 8.2.1


  Name:
  Todd Shoemaker

  CustomShell:
  none

  ReproducibleScript:
  #! /usr/bin/sh
  # make sure wish80 is the current in interpreter and is in the $PATH
  #  exec wish "$0" "$@"
  package require Iwidgets 3.0
  set usds [list hello world]

  ################################################
  #procedure to position dialogs in center of screen
  ################################################
  proc DialogPosition {Dlg Dialogwidth DialogHeight} {
  set Width [winfo screenwidth .]
  set Height [winfo screenheight .]
  set Xoffset [expr (( $Width - $Dialogwidth )/2 )]
  set Yoffset [expr (( $Height - $DialogHeight )/2 )]
  wm geometry $Dlg ${Dialogwidth}x${DialogHeight}+$Xoffset+$Yoffset
  }

  ################################################
  #proc Add or remove notebook from proc GetUSDs
  ################################################
  proc AddRemoveUSD {Count Choice} {

  global  usds slots usdips allistboxes LocalCount
  if {$Count != 0} {
  set NoteBook [.usd.frm.nb add -label "USD [expr ($Count + 1)]"]
  } else {
  set NoteBook [.usd.frm.nb childsite]
  }
  iwidgets::Labeledframe $NoteBook.pr1 -labelpos nw -labeltext "Enter Host Name"
  set ChildSite1 [$NoteBook.pr1 childsite]
  iwidgets::Labeledframe $NoteBook.pr2 -labelpos nw -labeltext "Choose slots to Configure"
  set ChildSite2 [$NoteBook.pr2 childsite]
  iwidgets::combobox $ChildSite1.cb -labeltext "Host: " -labelpos w -textvariable text($Count) -editable 0  -selectioncommand {
  set ipaddress([.usd.frm.nb view]) "IP Address: [lindex $usdips [lsearch $usds $text([.usd.frm.nb view])]]"
  }
  iwidgets::labeledwidget $ChildSite1.addrs -labelvariable ipaddress($Count) 
  set allistboxes [lreplace $allistboxes $Count $Count $ChildSite1.cb]
  foreach val $usds {
  $ChildSite1.cb insert list end $val
  } 
  pack $ChildSite1.cb -padx 45 -pady 10 -fill x
  pack $ChildSite1.addrs -padx 15 -pady 5 -fill x 
  pack $NoteBook.pr1 -fill x -padx 20 -pady 5 
  pack $NoteBook.pr2 -fill x -padx 20 -pady 5 
  frame $ChildSite2.frm1
  frame $ChildSite2.frm2
  frame $ChildSite2.frm3
  set FirstColumn [list 1 5 9]
  set LastColumn [list 4 8 12]
  set PlaceHolder 0
  for {set k 1} {$k <= 3} {incr k} {
  for {set j [lindex $FirstColumn $PlaceHolder]} {$j <= [lindex $LastColumn $PlaceHolder]} {incr j} {
  checkbutton $ChildSite2.frm$k.slot$j -text "slot[format "%.2d" $j]" -variable slots($${Count}${j}) -onvalue $j -offvalue 0
  }
  incr PlaceHolder
  }
  set PlaceHolder 0
  for {set k 1} {$k <= 3} {incr k} {
  for {set j [lindex $FirstColumn $PlaceHolder]} {$j <= [lindex $LastColumn $PlaceHolder]} {incr j} {
  pack $ChildSite2.frm$k.slot$j  -side left -fill x
  }
  incr PlaceHolder
  }
  pack $ChildSite2.frm1 -pady 1 
  pack $ChildSite2.frm2 -pady 1
  pack $ChildSite2.frm3 -pady 1
  if {$Choice == "Disable"} {
  .usd.frm.options.add config -state disabled
  } elseif {$Choice == "Enable"} {
  .usd.frm.options.remove config -state normal
  }
  }

  ################################################
  #procFirst window to pop up when new configuratoin is chosen
  #Asks what USDs to configure
  ################################################
  proc GetUSDs {} {

  global UsdCount usds Yes hosts slots allistboxes tree Interface Type usdinterfacetypevalue statuscount 

  set Yes 1
  set hosts [list]
  set allistboxes [list null null null null null null]
  toplevel .usd
  frame .usd.frm -relief raised
  wm title .usd "UltraNet Storage Director Configuration"
  option add *Tabnotebook.backdrop grey
  option add *Scale.width 8
  iwidgets::tabnotebook .usd.frm.nb -tabpos n -width 320 -height 280 -bevelamount 2-raiseselect yes -tabbackground darkgrey -background grey
  pack .usd.frm.nb -fill both -expand yes
  .usd.frm.nb add -label "USD 1"
  .usd.frm.nb select 0
  AddRemoveUSD 0 null
  set UsdCount 1
  frame .usd.frm.options
  button .usd.frm.options.add -text "Add"  -command {
  }
  button .usd.frm.options.remove -text "Remove"  -command {
  }

  button .usd.frm.options.edit -text "Edit"  -command {
  }
  button .usd.frm.options.ok -text "Continue"  -command {
  }
  button .usd.frm.options.cancel -text "Cancel"  -command { 
  }

  pack .usd.frm.options.cancel .usd.frm.options.ok .usd.frm.options.edit .usd.frm.options.remove .usd.frm.options.add -side right -anchor e -ipadx 5 -padx 5 -pady 5
  pack .usd.frm.options -side bottom -fill x 
  pack .usd.frm -pady 5
  .usd.frm.options.remove config -state disabled
  DialogPosition .usd 350 335
  wm resizable .usd 0 0
  focus -force .usd
  #tkwait window .usd
  }

  wm title . "Gateway Test Suite"
  DialogPosition . 600 400
  update
  GetUSDs

  ObservedBehavior:
  When I click on the combobox in the toplevel window .usd, I only see the
  drop down box in .usd--the rest of .usd dissappears(when the . window is behind the .usd window initially),

  If I iconify the . window, and leave the .usd window on the screen,
  it works just fine.

  DesiredBehavior:
  I don't believe this behavior existed in 8.1



  This sounds like a bug in wm deiconify that was already
  fixed in 8.2.1.  Please verify if this is not the case. 
  -- 12/01/1999 hobbs


tkt_uuid: 220626ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: Better support for compilation as static library on Windows
comment:
  OriginalBugID: 3647 RFE
  Version: 8.3b1
  SubmitDate: '1999-11-23'
  LastModified: '2000-03-31'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-03-31'
  FixedInVersion: 8.3.1


  Name:

  Jan Nijtmans



  CVS:

  6 nov 1999



  Comments:

  This patch is supplied with Wrap 0.3, which requires those modifications.



  DesiredBehavior:

  - The function TkWinXInit() should be called when Tk is

    compiled as a static library.

  - The function TkWinGetPlatformId should be moved from

    TkWin32Dll.c to TkWinX.c. Otherwise when creating a

    static library we don't have the possibility to leave

    out DllMain, because TkWinGetPlatformId will be left

    out together with it.

  - It is not necessary to have both a DllMain and a

    DllEntryPoint function. With a proper macro both

    functions can be merged in a single one which works

    on VC++, Borland and (as extra bonus) with gcc as well.



  Patch:

  *** generic/tkWindow.c.origWed Apr 21 23:53:28 1999

  --- generic/tkWindow.cSat Sep 25 19:39:12 1999

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

  *** 21,26 ****

  --- 21,29 ----

    #if !defined(__WIN32__) && !defined(MAC_TCL)

    #include "tkUnixInt.h"

    #endif

  + #if defined(__WIN32__)

  + #include "tkWinInt.h"

  + #endif

    

    

    typedef struct ThreadSpecificData {

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

  *** 2709,2714 ****

  --- 2712,2727 ----

        Tcl_DString class;

        ThreadSpecificData *tsdPtr;

        

  + #if defined(__WIN32__) && defined(STATIC_BUILD) && !defined(NO_STATIC_INIT)

  +     /*

  +      * If we are in a statically linked executable, then we need to

  +      * explicitly initialize the Windows function tables here since

  +      * DllMain() will not be invoked.

  +      */

  + 

  +     TkWinXInit(GetModuleHandle(NULL));

  + #endif

  + 

        /*

         * Ensure that we are getting the matching version of Tcl.  This is

         * really only an issue when Tk is loaded dynamically.

  *** win/tkWin32Dll.c.origFri Apr 16 03:51:48 1999

  --- win/tkWin32Dll.cSat Sep 25 19:33:35 1999

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

  *** 13,26 ****

    

    #include "tkWinInt.h"

    

  ! static int tkPlatformId;

    

  - /*

  -  * The following declaration is for the VC++ DLL entry point.

  -  */

  - 

  - BOOL APIENTRYDllMain _ANSI_ARGS_((HINSTANCE hInst,

  -     DWORD reason, LPVOID reserved));

    

    /*

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

  --- 13,22 ----

    

    #include "tkWinInt.h"

    

  ! #if defined(_MSC_VER) || defined(__GNUC__)

  ! #define DllEntryPoint DllMain

  ! #endif

    

    

    /*

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

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

  *** 32,63 ****

     *routine.

     *

     * Results:

  !  *See DllMain.

  !  *

  !  * Side effects:

  !  *See DllMain.

  !  *

  !  *----------------------------------------------------------------------

  !  */

  ! 

  ! BOOL APIENTRY

  ! DllEntryPoint(hInst, reason, reserved)

  !     HINSTANCE hInst;/* Library instance handle. */

  !     DWORD reason;/* Reason this function is being called. */

  !     LPVOID reserved;/* Not used. */

  ! {

  !     return DllMain(hInst, reason, reserved);

  ! }

  ! 

  ! /*

  !  *----------------------------------------------------------------------

  !  *

  !  * DllMain --

  !  *

  !  *DLL entry point.

  !  *

  !  * Results:

  !  *TRUE on sucess, FALSE on failure.

     *

     * Side effects:

     *None.

  --- 28,34 ----

     *routine.

     *

     * Results:

  !  *TRUE on success, FALSE otherwise.

     *

     * Side effects:

     *None.

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

  *** 66,77 ****

     */

    

    BOOL APIENTRY

  ! DllMain(hInstance, reason, reserved)

  !     HINSTANCE hInstance;

  !     DWORD reason;

  !     LPVOID reserved;

    {

  -     OSVERSIONINFO os;

    

        /*

         * If we are attaching to the DLL from a new process, tell Tk about

  --- 37,47 ----

     */

    

    BOOL APIENTRY

  ! DllEntryPoint (

  !     HINSTANCE hInstance,/* Library instance handle. */

  !     DWORD reason,/* Reason this function is being called. */

  !     LPVOID reserved)/* Not used. */

    {

    

        /*

         * If we are attaching to the DLL from a new process, tell Tk about

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

  *** 80,119 ****

         */

        

        if (reason == DLL_PROCESS_ATTACH) {

  - os.dwOSVersionInfoSize = sizeof(os);

  - GetVersionEx(&os);

  - tkPlatformId = os.dwPlatformId;

  - 

            TkWinXInit(hInstance);

        } else if (reason == DLL_PROCESS_DETACH) {

            TkWinXCleanup(hInstance);

        }

        return(TRUE);

    }

  - 

  - /*

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

  -  *

  -  * TkWinGetPlatformId --

  -  *

  -  *Determines whether running under NT, 95, or Win32s, to allow 

  -  *runtime conditional code.

  -  *

  -  * Results:

  -  *The return value is one of:

  -  *    VER_PLATFORM_WIN32sWin32s on Windows 3.1. 

  -  *    VER_PLATFORM_WIN32_WINDOWSWin32 on Windows 95.

  -  *    VER_PLATFORM_WIN32_NTWin32 on Windows NT

  -  *

  -  * Side effects:

  -  *None.

  -  *

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

  -  */

  - 

  - int

  - TkWinGetPlatformId()

  - {

  -     return tkPlatformId;

  - }

  - 

  --- 50,58 ----

  *** win/tkWinX.c.origFri Jul  9 04:10:07 1999

  --- win/tkWinX.cSat Sep 25 19:33:35 1999

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

  *** 26,31 ****

  --- 26,32 ----

     */

    

    int tkpIsWin32s = -1;

  + static int tkPlatformId;

    

    /*

     * Declarations of static variables used in this file.

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

  *** 142,148 ****

    

        info.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);

        GetVersionEx(&info);

  !     tkpIsWin32s = (info.dwPlatformId == VER_PLATFORM_WIN32s);

    

        if (childClassInitialized != 0) {

    return;

  --- 143,150 ----

    

        info.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);

        GetVersionEx(&info);

  !     tkPlatformId = info.dwPlatformId;

  !     tkpIsWin32s = (tkPlatformId == VER_PLATFORM_WIN32s);

    

        if (childClassInitialized != 0) {

    return;

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

  *** 1132,1132 ****

  --- 1134,1161 ----

    }

  + 

  + /*

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

  +  *

  +  * TkWinGetPlatformId --

  +  *

  +  *Determines whether running under NT, 95, or Win32s, to allow 

  +  *runtime conditional code.

  +  *

  +  * Results:

  +  *The return value is one of:

  +  *    VER_PLATFORM_WIN32sWin32s on Windows 3.1. 

  +  *    VER_PLATFORM_WIN32_WINDOWSWin32 on Windows 95.

  +  *    VER_PLATFORM_WIN32_NTWin32 on Windows NT

  +  *

  +  * Side effects:

  +  *None.

  +  *

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

  +  */

  + 

  + int

  + TkWinGetPlatformId()

  + {

  +     return tkPlatformId;

  + }

  +



  PatchFiles:

  tkWindow.c tkWin32Dll.c tkWinX.c





  The TkWinXInit was added to tkWinInit.c:TkpInit where is can be
  safely called without the #def's.  The tkPlatformId was moved
  to tkWin32Dll.c, but I didn't change the DllEntryPoint (Tcl
  uses the same thing, and it works just fine). 
  -- 03/31/2000 hobbs


tkt_uuid: 220627ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: tk input widgets are crashing .
comment:
  OriginalBugID: 3685 Bug
  Version: 8.1.1
  SubmitDate: '1999-11-24'
  LastModified: '1999-11-29'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  FixedDate: '1999-11-29'
  FixedInVersion: 8.2


  Name:

  seema



  ReproducibleScript:

  =========script=================

  proc fact {x} {        

  set result 1           

  if {$x <=0} {           

  return $result

  }

  while {$x > 1} {             

  set result  [ expr $result * $x]    

  set x [expr $x-1]

  }

  return $result                               

  }

  entry .e -width 8 -relief sunken -textvariable entry

  #ssdfs

  label .l1 -text " The factorial is "   

  #fsddg

  label .result -textvariable result

  # dg

  pack .e  .l1 .result  -side left -padx 1m -pady 2m    

  #dfdfg

  bind .e <Return> {set result [fact $entry]}     

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

  as soon as user types input value the application crashes . 

  the crash lands in tcl81.dll



  ObservedBehavior:

  - do-



  DesiredBehavior:

  # This script will calculate the factorial of no not greater then 19

  # After running the script a window will popup and ask form the user to

  # give some input with  and press Enter key the  factorial crossponding  to

  # the entered value is displayed........

  the user should type in the number and get back the factorial of the number.



  Patch:

  TCL.H

  =====

  typedef struct Tcl_Parse {

      char *commentStart;/* Pointer to # that begins the first of

   * one or more comments preceding the

   * command. */

      int commentSize;/* Number of bytes in comments (up through

   * newline character that terminates the

   * last comment).  If there were no

   * comments, this field is 0. */

      char *commandStart;/* First character in first word of command. */

      int commandSize;/* Number of bytes in command, including

   * first character of first word, up

   * through the terminating newline,

   * close bracket, or semicolon. */

      int numWords;/* Total number of words in command.  May

   * be 0. */

      Tcl_Token *tokenPtr;/* Pointer to first token representing

   * the words of the command.  Initially

   * points to staticTokens, but may change

   * to point to malloc-ed space if command

   * exceeds space in staticTokens. */

      int numTokens;/* Total number of tokens in command. */

      int tokensAvailable;/* Total number of tokens available at

   * *tokenPtr. */

      int errorType;/* One of the parsing error types defined

   * above. */



      /*

       * The fields below are intended only for the private use of the

       * parser.They should not be used by procedures that invoke

       * Tcl_ParseCommand.

       */



      char *string;/* The original command string passed to

   * Tcl_ParseCommand. */

      char *end;/* Points to the character just after the

   * last one in the command string. */

      Tcl_Interp *interp;/* Interpreter to use for error reporting,

   * or NULL. */

      char *term;/* Points to character in string that

   * terminated most recent token.  Filled in

   * by ParseTokens.  If an error occurs,

   * points to beginning of region where the

   * error occurred (e.g. the open brace if

   * the close brace is missing). */

      int incomplete;/* This field is set to 1 by Tcl_ParseCommand

   * if the command appears to be incomplete.

   * This information is used by

   * Tcl_CommandComplete. */

      Tcl_Token staticTokens[NUM_STATIC_TOKENS];

  /* Initial space for tokens for command.

   * This space should be large enough to

   * accommodate most commands; dynamic

   * space is allocated for very large

   * commands that don't fit here. */



  //yes_debugger

  int errorLine; //smishi



  } Tcl_Parse;



  TCLINT.h

  ========

  typedef struct Proc {

      struct Interp *iPtr;  /* Interpreter for which this command

     * is defined. */

      int refCount;  /* Reference count: 1 if still present

     * in command table plus 1 for each call

     * to the procedure that is currently

     * active. This structure can be freed

     * when refCount becomes zero. */



  /* Addition Start */

  int linenumber;

  char filename[256];

  int numLevel;

  /* Additon End */



  PatchFiles:

  tcl.h

      tclint.h

      tclproc.c

      tclcompile.c

      tclparse.c

      tclexecute.c

      tclbasic.c





  This works as expected on NT and 98 with 8.2.2. 
  -- 11/29/1999 hobbs


tkt_uuid: 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: 220629ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: Body of tkEntrySeeInsert
comment:
  OriginalBugID: 3696 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-29'
  LastModified: '1999-11-29'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-SuSE
  FixedDate: '1999-11-29'
  FixedInVersion: 8.3b1


  Name:
  Csaba Nemethi

  ObservedBehavior:
  In Tk 8.2.2, the body of the tkEntrySeeInsert procedure in the file entry.tcl has been changed by eliminating a while loop.  The new version is, however, much more complicated than it should be.

  DesiredBehavior:
  Here is the improved code:

  proc tkEntrySeeInsert w {
      set c [$w index insert]
      if {($c < [$w index @0]) || ($c > [$w index @[winfo width $w]])} {
  $w xview $c
      }
  }



  updated in 8.3 
  -- 11/29/1999 hobbs


tkt_uuid: 220630ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: MacOS: Menu Cmds / Font Substitutions
comment:
  OriginalBugID: 3705 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-29'
  LastModified: '1999-12-14'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: 8.5.1
  Machine: iMac Rev.C
  FixedDate: '1999-12-14'
  FixedInVersion: 8.3b1


  Name:

  Peter Wilson


  Extensions:

  Dash-Patch for 8.2.2


  ReproducibleScript:

  1. Menu Cmds:  Disabled entry isn't completely greyed out and "..."->"......".


  . config -menu .mbar

  menu .mbar

  .mbar add cascade -menu .mbar.file -label File

  menu .mbar.file

  .mbar.file add command -label "Open..." -accel "Cmd-O" -state normal

  .mbar.file add command -label "New..." -accel "Cmd-N" -state disabled


  2. Font Substitution:  Some characters drawn as bitmaps


  font create tstFont -family Charcoal -size 40

  label .lbl -text "abcdefghijklmnopqrstuvwxyz\nABCDEFGHIJKLMNOPQRSTUVWXYZ"  -font tstFont

  pack .lbl


  3. Post Command: n/a


  ObservedBehavior:

  1. When a menu item with a shortcut is disabled, the text, but not the command

  string turns grey.  Bug is an unitialized variable.  Also, conversion of

  triple-dots to elipses results in 5 dots, not 3.  


  2. Some characters get displayed in a font other than the one requested. The

  "missing" characters would be drawn with bitmapped versions, instead. The

  particular characters lost differed between the 2 machines I tested.

  Bug is due to differing Font Records for bitmapped and outline fonts.


  3. Post commands do not get executed.


  (4. tkMacMenu.c contained nonASCII characters for special Mac symbols which were getting converted during local file handling... CVS and FTP transfers, etc.)


  DesiredBehavior:

  1.  Entire menu entry should be greyed and only one special elipsis character drawn in place of "..."


  2.  All characters should get drawn in same font.


  3.  Post commands executed prior to displaying the menu.


  (4. Special characters should be escaped.  I've converted them to \octal format.)


  Patch:

  diff -c ./tkMacFont.c /lheadev/pwilson/fv/tk8.2.2/mac/tkMacFont.c

  *** ./tkMacFont.cMon Nov 29 16:10:54 1999

  --- /lheadev/pwilson/fv/tk8.2.2/mac/tkMacFont.cFri Nov 26 14:38:36 1999

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

  *** 1721,1726 ****

  --- 1721,1730 ----

        unsigned char buf[16];

        int srcRead, dstWrote;

        Tcl_Encoding encoding;

  +     Handle fHandle;

  +     short theID;

  +     ResType theType;

  +     Str255 theName;


        subFontPtr->fontMap[row] = (char *) ckalloc(FONTMAP_BITSPERPAGE / 8);

        memset(subFontPtr->fontMap[row], 0, FONTMAP_BITSPERPAGE / 8);

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

  *** 1738,1775 ****

        fm.denom.v= 1;


    #if !defined(UNIVERSAL_INTERFACES_VERSION) || (UNIVERSAL_INTERFACES_VERSION < 0x0300)

  !     fontRecPtr = *((FontRec **) FMSwapFont(&fm)->fontResult);

    #else

  !     fontRecPtr = *((FontRec **) FMSwapFont(&fm)->fontHandle);

    #endif

  !     widths = (short *) ((long) &fontRecPtr->owTLoc 

  !         + ((long) (fontRecPtr->owTLoc - fontRecPtr->firstChar) 

  !         * sizeof(short)));

        isMultiByteFont = subFontPtr->familyPtr->isMultiByteFont;

  !         

  !     end = (row + 1) << FONTMAP_SHIFT;

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

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

  !         TCL_ENCODING_STOPONERROR, NULL, (char *) buf, sizeof(buf), 

  ! &srcRead, &dstWrote, NULL) == TCL_OK) {

  !             

  !             if (((isMultiByteFont != 0) && (buf[0] > 31))

  !                 || (widths[buf[0]] != -1)) {

  !             if ((buf[0] == 0x11) && (widths[0x12] == -1)) {

  !                 continue;

  !             }

  !             

  !                 /* 

  !                  * Mac's char existence metrics are only for one-byte

  !                  * characters.  If we have a double-byte char, just 

  !                  * assume that the font supports that char if the font's 

  !                  * encoding supports that char.

  !                  */

  !                 

                    bitOffset = i & (FONTMAP_BITSPERPAGE - 1);

  ! subFontPtr->fontMap[row][bitOffset >> 3] |= 1 << (bitOffset & 7);

  !     }

  ! }

        }

    }

    

  --- 1742,1801 ----

        fm.denom.v= 1;


    #if !defined(UNIVERSAL_INTERFACES_VERSION) || (UNIVERSAL_INTERFACES_VERSION < 0x0300)

  !     fHandle = FMSwapFont(&fm)->fontHandle;

    #else

  !     fHandle = FMSwapFont(&fm)->fontHandle;

    #endif

  !     GetResInfo(fHandle, &theID, &theType, theName);

        isMultiByteFont = subFontPtr->familyPtr->isMultiByteFont;

  !     if( theType=='sfnt' ) {

  !     

  !             /*  Found an outline font which has very complex font record.  */

  !             /*  Let's just assume *ALL* the characters are allowed.        */

  !         

  !         end = (row + 1) << FONTMAP_SHIFT;

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

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

  !                 TCL_ENCODING_STOPONERROR, NULL, (char *) buf, sizeof(buf),

  !                 &srcRead, &dstWrote, NULL) == TCL_OK) {

                    bitOffset = i & (FONTMAP_BITSPERPAGE - 1);

  !                subFontPtr->fontMap[row][bitOffset >> 3] |= 1 << (bitOffset & 7);

  !         }

  !     }

  !     } else {

  !     

  !             /*  Found an old bitmap font which has a well-defined record.     */

  !             /*  We can check the width table to see which characters exist.   */

  !         

  !         fontRecPtr = *((FontRec **) fHandle );

  !         widths = (short *) ((long) &fontRecPtr->owTLoc 

  !             + ((long) (fontRecPtr->owTLoc - fontRecPtr->firstChar) 

  !             * sizeof(short)));

  !             

  !         end = (row + 1) << FONTMAP_SHIFT;

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

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

  !             TCL_ENCODING_STOPONERROR, NULL, (char *) buf, sizeof(buf), 

  !     &srcRead, &dstWrote, NULL) == TCL_OK) {

  !                 

  !                 if (((isMultiByteFont != 0) && (buf[0] > 31))

  !                     || (widths[buf[0]] != -1)) {

  !                 if ((buf[0] == 0x11) && (widths[0x12] == -1)) {

  !                     continue;

  !                 }

  !                 

  !                     /* 

  !                      * Mac's char existence metrics are only for one-byte

  !                      * characters.  If we have a double-byte char, just 

  !                      * assume that the font supports that char if the font's 

  !                      * encoding supports that char.

  !                      */

  !                     

  !                     bitOffset = i & (FONTMAP_BITSPERPAGE - 1);

  !             subFontPtr->fontMap[row][bitOffset >> 3] |= 1 << (bitOffset & 7);

  !         }

  !         }

  !     }

        }

    }

    

  diff -c ./tkMacMenu.c /lheadev/pwilson/fv/tk8.2.2/mac/tkMacMenu.c

  *** ./tkMacMenu.cMon Nov 29 16:17:07 1999

  --- /lheadev/pwilson/fv/tk8.2.2/mac/tkMacMenu.cMon Nov 29 16:17:31 1999

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

  *** 724,735 ****

        char *dStringText;

        int i;


  ! for (i = 0; i < length; text++, i++) {

            if ((*text == '.')

                && (*(text + 1) != '\0') && (*(text + 1) == '.')

                && (*(text + 2) != '\0') && (*(text + 2) == '.')) {

            Tcl_DStringAppend(dStringPtr, elipsisString, -1);

            i += strlen(elipsisString) - 1;

           } else {

            Tcl_DStringSetLength(dStringPtr,

    Tcl_DStringLength(dStringPtr) + 1);

  --- 724,736 ----

        char *dStringText;

        int i;


  ! for (i = 0; *text; text++, i++) {

            if ((*text == '.')

                && (*(text + 1) != '\0') && (*(text + 1) == '.')

                && (*(text + 2) != '\0') && (*(text + 2) == '.')) {

            Tcl_DStringAppend(dStringPtr, elipsisString, -1);

            i += strlen(elipsisString) - 1;

  +                 text += 2;

           } else {

            Tcl_DStringSetLength(dStringPtr,

    Tcl_DStringLength(dStringPtr) + 1);

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

  *** 751,762 ****

     *

     * We try the following special mac characters. If none of them

     * are present, just use the check mark.

  !  * '' - Check mark character

  !  * '´' - Bullet character

  !  * '' - Filled diamond

  !  * '*' - Hollow diamond

  !  * '*' = Long dash ("em dash")

  !  * '-' = short dash (minus, "en dash");

     *

     * Results:

     *None.

  --- 752,763 ----

     *

     * We try the following special mac characters. If none of them

     * are present, just use the check mark.

  !  * '' - Check mark character     (\022)

  !  * '' - Bullet character         (\245)

  !  * '' - Filled diamond           (\023)

  !  * '*' - Hollow diamond           (\327)

  !  * '' = Long dash ("em dash")    (\321)

  !  * '-' = short dash (minus, "en dash")

     *

     * Results:

     *None.

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

  *** 778,798 ****

        tkfont = Tk_GetFontFromObj(mePtr->menuPtr->tkwin,

            (mePtr->fontPtr == NULL) ? mePtr->menuPtr->fontPtr

        : mePtr->fontPtr);

  !         

  !     if (!TkMacIsCharacterMissing(tkfont, '')) {

  !     markChar = '';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '´')) {

  !     markChar = '´';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '')) {

  !     markChar = '';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '*')) {

  !     markChar = '*';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '*')) {

  !     markChar = '*';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '-')) {

        markChar = '-';

        } else {

  !     markChar = '';

        }

        return markChar;

    }

  --- 779,799 ----

        tkfont = Tk_GetFontFromObj(mePtr->menuPtr->tkwin,

            (mePtr->fontPtr == NULL) ? mePtr->menuPtr->fontPtr

        : mePtr->fontPtr);

  ! 

  !     if (       !TkMacIsCharacterMissing(tkfont, '\022')) {  /*  Checkmark   */

  !     markChar = '\022';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '\245')) {  /*  Bullet      */

  !     markChar = '\245';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '\023')) {  /*  Filled Diamond  */

  !     markChar = '\023';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '\327')) {  /*  Hollow Diamond  */

  !     markChar = '\327';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '\321')) {  /*  Long Dash   */

  !     markChar = '\321';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '-'))    {  /*  Short Dash  */

        markChar = '-';

        } else {

  !     markChar = '\022';  /*  Everything missing... just throw up checkmark  */

        }

        return markChar;

    }

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

  *** 1178,1184 ****

                && (ENTRY_COMMAND_ACCEL 

                == (mePtr->entryFlags & ENTRY_ACCEL_MASK))) {

            char *accel = Tcl_GetStringFromObj(mePtr->accelPtr, NULL);

  !     SetItemCmd(macMenuHdl, index, accel[((EntryGeometry *)

        mePtr->platformEntryData)->accelTextStart]);

        }

        }

  --- 1179,1185 ----

                && (ENTRY_COMMAND_ACCEL 

                == (mePtr->entryFlags & ENTRY_ACCEL_MASK))) {

            char *accel = Tcl_GetStringFromObj(mePtr->accelPtr, NULL);

  !     SetItemCmd(macMenuHdl, base + index, accel[((EntryGeometry *)

        mePtr->platformEntryData)->accelTextStart]);

        }

        }

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

  *** 3574,3580 ****

        Tk_FontMetrics entryMetrics;

        int adjustedY = y + padY;

        int adjustedHeight = height - 2 * padY;

  -     int state;


        /*

         * Choose the gc for drawing the foreground part of the entry.

  --- 3575,3580 ----

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

  *** 3605,3611 ****

            }

        }


  ! if (((parentDisabled || (state == ENTRY_DISABLED)))

    && (menuPtr->disabledFgPtr != NULL)) {

        gc = mePtr->disabledGC;

        if (gc == NULL) {

  --- 3605,3611 ----

            }

        }


  ! if (((parentDisabled || (mePtr->state == ENTRY_DISABLED)))

    && (menuPtr->disabledFgPtr != NULL)) {

        gc = mePtr->disabledGC;

        if (gc == NULL) {

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

  *** 4398,4404 ****

        FixMDEF();


  !     Tcl_ExternalToUtf(NULL, NULL, "É", -1, 0, NULL, elipsisString,

        TCL_UTF_MAX + 1, NULL, NULL, NULL);

    }

    

  --- 4398,4404 ----

        FixMDEF();


  !     Tcl_ExternalToUtf(NULL, NULL, "\311", -1, 0, NULL, elipsisString,

        TCL_UTF_MAX + 1, NULL, NULL, NULL);

    }

    

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

  *** 4425,4428 ****

  --- 4425,4458 ----

        /*

         * Nothing to do.

         */

  + }

  + 

  + /*

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

  +  *

  +  * TkpPreprocessMacMenu --

  +  *

  +  *Handle preprocessing of menubar if it exists.

  +  *

  +  * Results:

  +  *None.

  +  *

  +  * Side effects:

  +  *All post commands for the current menubar get executed.

  +  *

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

  +  */

  + 

  + void TkpPreprocessMacMenu( void );

  + void TkpPreprocessMacMenu( void )

  + {

  +     TkMenuReferences *menuBarRefPtr;

  + 

  +     if( currentMenuBarName != NULL ) {

  +         menuBarRefPtr = TkFindMenuReferences(currentMenuBarInterp,

  +             currentMenuBarName);

  +         if( (menuBarRefPtr != NULL) && (menuBarRefPtr->menuPtr != NULL) ) {

  +             TkPreprocessMenu(menuBarRefPtr->menuPtr->masterMenuPtr);

  +         }

  +     }

    }

  diff -c ./tkMacWindowMgr.c /lheadev/pwilson/fv/tk8.2.2/mac/tkMacWindowMgr.c

  *** ./tkMacWindowMgr.cMon Nov 29 16:10:58 1999

  --- /lheadev/pwilson/fv/tk8.2.2/mac/tkMacWindowMgr.cFri Nov 26 14:38:38 1999

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

  *** 207,216 ****

  --- 207,219 ----

        {

    int oldMode;

    KeyMap theKeys;

  + void TkpPreprocessMacMenu(void);


    GetKeys(theKeys);

    oldMode = Tcl_SetServiceMode(TCL_SERVICE_ALL);

    TkMacClearMenubarActive();

  + /* POSTCOMMAND??? */

  + TkpPreprocessMacMenu();

    TkMacHandleMenuSelect(MenuSelect(eventPtr->where),

    theKeys[1] & 4);

    Tcl_SetServiceMode(oldMode);


  PatchFiles:

  tkMacFont.c

      tkMacMenu.c

      tkMacWindowMgr.c




  all applied for 8.3b1 
  -- 12/14/1999 hobbs


tkt_uuid: 220631ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: Missing global statement in "tkfbox.tcl"
comment:
  OriginalBugID: 3735 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-01'
  LastModified: '1999-12-16'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  FixedDate: '1999-12-16'
  FixedInVersion: 8.3b1


  Name: George Petasis



  ReproducibleScript:

  in "tkfbox.tcl" around line 833 (tk runtime library):



  if {![info exists tkPriv(updirImage)]} {

  set tkPriv(updirImage) [image create bitmap -data........



  but tkPriv is not declared as a global variable in that procedure



  ObservedBehavior:

  You cannot change the bitmap used in the file selection dialog

  to a user defined one, as can be done with the icons used for

  folders and files... (and make the file dialog has the look n feel of

  the rest of the applicatio under unix...)





  fixed for 8.3b1. 
  -- 12/16/1999 hobbs


tkt_uuid: 220632ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: Running 'make test' causes core dump
comment:
  OriginalBugID: 3740 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-01'
  LastModified: '1999-12-16'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2316
  OS: AIX
  OSVersion: 4.3
  Machine: RS/6000
  FixedDate: '1999-12-16'
  FixedInVersion: 8.3b1


  Hi,

  Further to my bug submission, here's the offending line
  that seems to be causing the core dump:

  tkTextDisp.c: line 4035
      indexPtr->byteIndex += (*chunkPtr->measureProc)(chunkPtr, x);

  Thanks,
  Paul

  Name:
  Paul A. Sue

  ReproducibleScript:
  make test

  I even tried running wish and then sourcing a test (e.g. buton.test)
  and I get same result (core dump)

  I'm running AIX 4.3

  ObservedBehavior:
  [using memory image in core]

  Segmentation fault in TkTextPixelIndex at 0xd30b316c
  0xd30b316c (TkTextPixelIndex+0x140) 901c0008        stw   r0,0x8(r28)
  (dbx) where
  TkTextPixelIndex() at 0xd30b316c
  TkTextPickCurrent() at 0xd30b5730
  DisplayText() at 0xd30b03e8
  TclServiceIdle() at 0xd2fd5498
  Tcl_DoOneEvent() at 0xd2fd63f4
  Tk_UpdateObjCmd() at 0xd303b47c
  TclExecuteByteCode() at 0xd2f9eaa4
  Tcl_EvalObjEx() at 0xd2fa7ca8
  TclObjInterpProc() at 0xd2fb1b78
  EvalObjv() at 0xd2fe16b8
  Tcl_EvalEx() at 0xd2fe31f8
  Tcl_EvalFile() at 0xd2fc9270
  Tcl_SourceObjCmd() at 0xd2ffb2bc
  TclExecuteByteCode() at 0xd2f9eaa4
  Tcl_EvalObjEx() at 0xd2fa7ca8
  Tcl_IfObjCmd() at 0xd2ff7f18
  EvalObjv() at 0xd2fe16b8
  Tcl_EvalEx() at 0xd2fe31f8
  Tcl_EvalFile() at 0xd2fc9270
  Tk_MainEx() at 0xd30bfb84
  main() at 0x10000344
  (dbx) quit

  DesiredBehavior:
  The tests to work!

  (make test on Tcl 8.2.2 ran fine)



  This turns out to be a bug in the IBM compiler (not noted for
  being the best).  The fix is to remove -O (optimization) from
  the CFLAGS.  This will be the default for 8.3, and we are
  also going to try and get the gcc options working properly. 
  -- 12/16/1999 hobbs


tkt_uuid: 220633ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: wish8.2 crashes when creating images on aix-4.1.5.
comment:
  OriginalBugID: 3799 Bug
  Version: 8.2
  SubmitDate: '1999-12-07'
  LastModified: '1999-12-09'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  OSVersion: aix 4.1.5
  Machine: rs6000
  FixedDate: '1999-12-09'
  FixedInVersion: 8.2.2


  Name:
  MArkus Pietrek

  Comments:
  a simple patch would be in Tcl_Alloc, to allocate at least 1 byte on AIX

  ReproducibleScript:
  set image {
  R0lGODlh9AFDAbMAAAAAAADW1gDW74z/////////////////////////////////////////
  /////////ywAAAAA9AFDAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//A
  oHBILBqPyKSyJVg6n9CodHpsUqwALHXL7Xq/4KxgTB5PtOG0es1uw9BXt3xOr9s18Lt+z+8H
  yVlxfoOEhYYsVolnh4yNjo+CihJ5kJWWl2uSWJSYnZ6fTmVanKClpqdEpKirrK0zqq6xsrMZ
  iaO0uLm6i4G9vrvAwaeavMLGx5fEk8jMzY1mv7DO09R30tXY2WrX2t3eU9zf4uMpAebn6Onq
  6+YC7O/w5+Tz9AABS/f1+t75Sf37AKn9OzIwoMFjBYskPMhQ18IhDxtKjBUxSMWJGE9d/LEx
  o8dD/pIodOwx8qPJPiEnlNyx8qTLNtB6bZLQMkfNlzi/KAt580bPnEDBVVCk5WcNo0GTLkFj
  q+gLeSiQKp1qhOkyX1Ir9EOalapXIDuv2otq7gLXr2h1zvRlxehWC2fTyp3jFkPZqHPztuF6
  VyveMzEXibIA6Jfewza6FozLVlCxYikRS+4gqrLlwiXejqX516pYsSEjTx7Ngu8/qCfyefY8
  FDLp16XxfZbZmrBr2LhTyzYcOc9aw7mDf+gKQ/WkJikp/Q4nvDnxp7ejYVjevLqH5y7+AaLu
  GDNz67mxt7j4HTh4nINbp78CDY342ByYlz9/8NZj4GudKrnMHzN9vawF/gjaZ++t0F9//yG2
  Wm0M/lagCgfyl+BhCzrWXTEPljPhfxXeN6BYUg0wwQAkrpDhhi51aF5jILIgogQv/oWidfZJ
  dwF3m50Q44gqnDjjR+t9CFlM+ulowY4m+PhjUOUVacKOJfa45I/y+YUCkgBgSYKSUyoV4WUh
  Hilll0t+aVmYWfKoIZlUmikKmllGuSabdHLA5ZZ15qnBnSPwqadefoYQ6J9yDTocoYhypoSh
  iVLFaAePNppUpBtQKmlOlmaQ6aUubWoWp3l6CheodYpqJalkmioSqmyqqhKrqe4G65KuKjrr
  j7XmeCuKuea6az29/jpjPMSu406xyPYl7K7z/i0rLCfNOvurctJW64FlHlqr7bXbdgtCtN5K
  KuFs4ZbLoLnoZpvusr+tuC6zDb5rrYDyVhskuPVyim++4vJb7r7+IgpwwH8OTHCeBh9MZ8IK
  N+zwwxBHLPHEFFds8cUYZ6zxxhx37PHHIIfs0zoid+lryRKdjDJDKq9sUMsuBwRzzOQQS/PN
  OAuT0Mw5V7Nzz9bZDDR4PA/dTdFGZ4N00j4zveHSTjfzTtRUV2110ulcHd6pWk/2c9defwq2
  ZF+PjdhAUJtNETpqt+322/UKDffZc5+ddt2o3I23KcrujZbefn/Sd+COEl5oPIYnrnjZfSo+
  D+MiAO44F3I3Prk4/thJfvkjdY26Od8qDS6obp5/LvirtloeOeKmn27rT523vopmukYuu9Ko
  1z466faIfjskqMWO5+u/C8Q77cUzEzvyyQNfFmPD56h582PmI/yWfU1PvYzM7749QrnD/j0y
  tIufGsnjN2J96qoP3336hWTNu/urwt9JsvjDE37u9vNR4PL8698eUGOiv7xPgHog4PwyQxPf
  IdB/DjzUA40RQTtNEBgKbB8IIqK9C1aqghuMXu066EG4gNB27UNbCevwPxGqcIV0yKCMvDdC
  GN5BhiIMYQBJaEOznLBSLuRaD29oPhSyj4dDFMkP94Q9/SVRDjjU4BMxEUUGTtETLbyi/jaQ
  qEV/dBF3X5wGO8JIQTIaz4zO4CIahaDGNVrEjTpjHRzn+C7I0bEVdrwj3+SoRzz28Y91HCMg
  cdHGQSbGkIREJC0KqcgYMLKR51MHJCdJSQTKr5KuCyAmK5HHTapPbJ7kJChDCTwhkpJzbDul
  KleJt9MskZUxrJ/uYOk/rj2SlrJM3S1xqUtT8tIOp/HlL2O5w2H2YX25NGYCXanMZjrzmdCM
  pjSnSc1qWvOa2MymNrfJzW56Eyid1JQmv6mDwa3kgOT0SQ11OMt0qvOFDQwmye6RSnceUlfl
  C50slbVLPeZznfCEpz1n8M8XBlSYAx1P/ZCJuoMmM6HQWRVD/hXl0HFCFD6vmuhmKsq+iypU
  K/9cp0g9mp1REhBtz0MoSVfK0q/0U5ovjWZMoTnTZ9bUmTdtZk6VuVNj9nSYP/1lUHk5VFwW
  lZZH3V4eW1JEQQmShqFUoUAlmEOqzjCqfpnqdZJUVSueUqq27Fsq6wlVq9rlpFAhqydDGkzi
  NZSrUrRlL9uJSbYWc5ZN3SD6ADpKUtr1iB3daP4GK0lI3SWcda2hKy9Zz7ya1YQMbSws6ZnV
  h4rNsVsVp2U16lfFJvNrmIUUEzcbWKyWbn9zDa0FNdvA1CK1r/EEafZeaVnD7pVtWwkebUma
  VFb2dpW/VWVwv9rSKQy3s8WNwnFNgZvcJyx3rc2FwnM3Od3ERtcJ1V3jJVWXXRhqlardLSFi
  R0vX6xpRU/zMqjzoWUXzrtYuqH1ray3qXtuedqNWYl54Lxi8/PoXsPVdk0H/O9IAi9ZzA17o
  XQ2cWQJTlMDfZTBr5yo9JbqVvhL2YQYViNvYRjjDIA6xiEdM4hKb2BgRAAA7
  }

  set img [image create photo -data $image]
  canvas .a
  pack .a
  .a create image 0 0 -image $img

  ObservedBehavior:
  malloc(0) returns NULL on AIX

  #0  0xd007b418 in raise ()
  #1  0xd001b36c in abort ()
  #2  0xd08592c4 in Tcl_PanicVA ()
  #3  0xd0859340 in Tcl_Panic ()
  #4  0xd0858cec in Tcl_Alloc ()
  #5  0xd09e4634 in ImgPhotoSetSize ()
  #6  0xd09e381c in ImgPhotoConfigureMaster ()
  #7  0xd09e1f54 in ImgPhotoCreate ()
  #8  0xd09dcf7c in Tk_ImageCmd ()
  #9  0xd0871350 in TclInvokeStringCommand ()

  DesiredBehavior:
  wish8.0, wish8.1 run correctly



  This has already been addressed in the 8.2.2+ builds, which
  are already available. 
  -- 12/09/1999 hobbs


tkt_uuid: 220634ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: fix for bug in TextSearchCmd with multi-byte chars
comment:
  OriginalBugID: 3839 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-09'
  LastModified: '1999-12-09'
  Severity: SER
  Status: Released
  Submitter: hobbs
  ChangedBy: hobbs
  RelatedBugIDs: 2582 2708
  OS: All
  FixedDate: '1999-12-09'
  FixedInVersion: 8.3b1


  From: vince darley


  ReproducibleScript:

  text .t

  pack .t

  # inserts 5 a's, a bullet, an X and 5 more a's (on Windows at least)

  t insert 1.0 "aaaaa\u2022Xaaaaa\n"

  # same thing but without a multi-byte char

  t insert 2.0 "aaaaauXaaaaa"

  set res [.t search -backwards -count count -regexp {.X} 2.0]

  set got [.t get $res "$res + ${count}c"]

  puts stdout "Found $count chars at $res, which were '$got'"

  set res [.t search -backwards -count count -regexp {.X} 3.0]

  set got [.t get $res "$res + ${count}c"]

  puts stdout "Found $count chars at $res, which were '$got'"

  console show


  ObservedBehavior:

  The above script claims to match the regexp {.X} to {Xu} which is obviously nonsense.  The problem lies in TextSearchCmd in tkText.c and is actually an old bug: without multibyte chars the only effect of the bug is to slow down backwards searches; with multibyte chars the search will return the wrong position (which in my own code can lead to infinite loops...)


  Patch:

  Lines 1798-1801 of tkText.c:

          matchByte = i;

          matchLength = thisLength;

          firstByte = i + Tcl_UtfToUniChar(startOfLine + matchByte, &ch);

     } while (backwards);


  The only change required is to the 'firstByte ...' line which was previously the incorrect 'firstByte += Tcl_Utf...'


  Comments:

  With this patch, Tk passes all 'text' tests and doesn't fail on my script above.


  I have previously reported this bug, so it should exist in Scriptics bug database.  However I didn't previously provide a fix, as I do here.



  integrated for 8.3b1. 
  -- 12/09/1999 hobbs


tkt_uuid: 220635ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: tk_getOpenFile man incorrectly states "-initialfile ignored by getOpenFile"
comment:
  OriginalBugID: 3882 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-14'
  LastModified: '1999-12-16'
  Severity: LOW
  Status: Released
  Submitter: ericm
  ChangedBy: hobbs
  OS: All
  FixedDate: '1999-12-16'
  FixedInVersion: 8.3b1


  The man page for tk_getOpenFile claims that the -initialfile parameter is ignored for the getOpenFile dialog, but it seems to work on Linux and Windows NT.

  - eric



  corrected, along with updated behavior on Unix. 
  -- 12/16/1999 hobbs


tkt_uuid: 220636ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: Bad man pages generate errors when building winhelp
comment:
  OriginalBugID: 3883 Bug
  Version: 8.3b1
  SubmitDate: '1999-12-14'
  LastModified: '2000-01-04'
  Severity: LOW
  Status: Released
  Submitter: wart
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-01-04'
  FixedInVersion: 8.3b1


  The Tcl/Tk winhelp is generated from the Unix Tcl/Tk man pages.  There are a couple of man pages that generate errors when used to create the winhelp.  These errors prevent the .hlp file from being generated.

  When I run "make winhelp" for Tk, I get the following:

  ...
  Pass 1 -- Z:/cvs/connect2.0/tk8.3/doc/SetGrid.3
  Pass 1 -- Z:/cvs/connect2.0/tk8.3/doc/SetOptions.3
  duplicate topic Tk_Offset in Tk
  Pass 1 -- Z:/cvs/connect2.0/tk8.3/doc/SetVisual.3
  Pass 1 -- Z:/cvs/connect2.0/tk8.3/doc/StrictMotif.3
  ...
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/GetCursor.3
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/GetDash.3
  Bad .AP macro: .AP CONST char *string in
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/GetFont.3
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/GetGC.3
  ...
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/button.n^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/canvas.n^M
  Unknown macro: .fo ^M
  Unknown macro: .fo ^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/checkbutton.n^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/chooseColor.n^M
  ...
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/label.n^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/listbox.n^M
  Unknown font: o^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/loadTk.n^M
  Pass 2 -- Z:/cvs/connect2.0/tk8.3/doc/lower.n^M



  These were all fixed before the 8.3b1 public release. 
  -- 01/04/2000 hobbs


tkt_uuid: 220637ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: inconsistent fonts on the Mac
comment:
  OriginalBugID: 3884 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-15'
  LastModified: '1999-12-16'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  FixedDate: '1999-12-16'
  FixedInVersion: 8.3b1


  Name:
  Peter Nye

  ReproducibleScript:
  button .b -text "The quick brown fox jumped over the lazy dog" -font lucida
  pack .b

  ObservedBehavior:
  The letters a ,e and q  appear to be coming from the wrong font in the above case, and also
  in the console window.  It's true for every font I tried, but is especially pronounced in lucida.
  This is flor the out-of-the-box 8.2.2 release.

  For 8.2.1, ther e is the same problem, but with different letters (q o n x p z y).



  This is already fixed in the upcoming 8.3b1 release for the Mac,
  with a community contributed patch.  If the user requires the
  fix, please respond (8.3b1 out before xmas). 
  -- 12/16/1999 hobbs


tkt_uuid: 220638ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: Doing a -nocase search on a text widget that contains a copyright symbol causes a seg fault
comment:
  OriginalBugID: 3886 Bug
  Version: 8.1
  SubmitDate: '1999-12-15'
  LastModified: '1999-12-16'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  FixedDate: '1999-12-16'
  FixedInVersion: 8.2


  Name: Mike Mahar

  Comments:
  This report is FYI only.  I'veworked around the problem but if you make a patch please email me.

  ReproducibleScript:
  # t is a text widget
  # fileid is an open file. The file contains a copyright symbol 0xA9
  $t insert end  [read $fileid]
  #now search for a string that is not  in the file to guarantee that we will see (c)
  $t search -nocase  -count numchars-- "nostring"  insert
  #At this point wish8.1 crashes with a seg fault.

  ObservedBehavior:
  Program received signal SIGSEGV, Segmentation fault.
  0x11f350 in Tcl_UniCharToUtf ()
  (gdb) where
  #0  0x11f350 in Tcl_UniCharToUtf ()
  #1  0x11fa84 in Tcl_UtfToLower ()
  #2  0x7eeb8 in TextSearchCmd (textPtr=0xa9c2a9c2, interp=0xa9c2a9c2, argc=-1446860350, argv=0xa9c2a9c2) at Isrc/../generic/tkText.c:1712
  #3  0x7ce30 in TextWidgetCmd (clientData=0xa9c2a9c2, interp=0xa9c2a9c2, argc=-1446860350, argv=0xa9c2a9c2) at Isrc/../generic/tkText.c:628
  #4  0xdf14c in TclInvokeStringCommand ()
  #5  0xf81c0 in TclExecuteByteCode ()
  #6  0xdfbe4 in Tcl_EvalObjEx ()
  Cannot access memory at address 0xa9c2a9fa.
  (gdb)



  This is not reproducible with the 8.2 version of Tk on Solaris7,
  so I'm assuming it was fixed before then. 
  -- 12/16/1999 hobbs


tkt_uuid: 220639ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: Listbox extended selection does fully initialize state
comment:
  OriginalBugID: 3892 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-17'
  LastModified: '1999-12-17'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0 SP6a
  Machine: 450MHz PII
  FixedDate: '1999-12-17'
  FixedInVersion: 8.3b1


  Name:

  Steve Fulmer


  ReproducibleScript:

  from an interactive Wish session:

  % .lb configure -selectmode extended

  % .lb insert end  "one"

  % .lb insert end "two"

  % grid .lb

  % focus .lb


  ObservedBehavior:

  Select the Wish window titlebar, but do not click on a list item.  Hold down the shift key and use the up/down arrows.  This should extend the current selection, but there is no current selection.  Hence the error.  I had to move up and down a few times to get the error, but I can consistently get it.


  Stack trace given below:


  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 .lb 1

  "

      (command bound to event)


  DesiredBehavior:

  If nothing is selected when extending the selection, select the old item (where you were before the event) and where you are going.




  8.3b1 will have the desired behavior. 
  -- 12/17/1999 hobbs


tkt_uuid: 220640ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: Tk make install fails
comment:
  OriginalBugID: 3896 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-17'
  LastModified: '1999-12-20'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: QNX 4.25
  Machine: i586
  FixedDate: '1999-12-20'
  FixedInVersion: 8.3b1


  Name:
  Bruce Edge

  ReproducibleScript:
  A test in the makefile does not execute as expected under QNX. This is similar to the bug report I submitted for tcl.

  ObservedBehavior:
  # //8/usr/local/src/tk8.2.3/unix> make install
  Installing libtk8.2g.a
  chmod +x //8/usr/local/src/tk8.2.3/unix/install-sh
  chmod +x //8/usr/local/src/tk8.2.3/unix/mkLinks
  Installing wish
  Installing tkConfig.sh
  make: *** [install-binaries] Error 1

  Patch:
  *** Makefile    Fri Dec 17 10:09:17 1999
  --- Makefile.new        Fri Dec 17 11:46:16 1999
  ***************
  *** 42,48 ****
    TK_LIBRARY =          $(prefix)/lib/tk$(VERSION)

    # Path name to use when installing library scripts:
  ! SCRIPT_INSTALL_DIR =  $(INSTALL_ROOT)/$(TK_LIBRARY)

    # Directory in which to install the .a or .so binary for the Tk library:
    LIB_INSTALL_DIR =     $(INSTALL_ROOT)$(exec_prefix)/lib
  --- 42,48 ----
    TK_LIBRARY =          $(prefix)/lib/tk$(VERSION)

    # Path name to use when installing library scripts:
  ! SCRIPT_INSTALL_DIR =  $(INSTALL_ROOT)$(TK_LIBRARY)

    # Directory in which to install the .a or .so binary for the Tk library:
    LIB_INSTALL_DIR =     $(INSTALL_ROOT)$(exec_prefix)/lib
  ***************
  *** 446,457 ****
          @$(INSTALL_PROGRAM) wish $(BIN_INSTALL_DIR)/wish$(VERSION)
          @echo "Installing tkConfig.sh"
          @$(INSTALL_DATA) tkConfig.sh $(LIB_INSTALL_DIR)/tkConfig.sh
  !       @if test "$(TK_BUILD_EXP_FILE)" != ""; then  !           echo "Installing $(TK_EXP_FILE)";  !           $(INSTALL_DATA) $(TK_BUILD_EXP_FILE)  !                       $(LIB_INSTALL_DIR)/$(TK_EXP_FILE);  !           fi
  !       @if test "$(TK_STUB_LIB_FILE)" != "" ; then  echo "Installing $(TK_STUB_LIB_FILE)";  $(INSTALL_DATA) $(STUB_LIB_FILE)  $(LIB_INSTALL_DIR)/$(TK_STUB_LIB_FILE);  --- 446,457 ----
          @$(INSTALL_PROGRAM) wish $(BIN_INSTALL_DIR)/wish$(VERSION)
          @echo "Installing tkConfig.sh"
          @$(INSTALL_DATA) tkConfig.sh $(LIB_INSTALL_DIR)/tkConfig.sh
  ! #     @if test "$(TK_BUILD_EXP_FILE)" != ""; then  ! #         echo "Installing $(TK_EXP_FILE)";  ! #         $(INSTALL_DATA) $(TK_BUILD_EXP_FILE)  ! #                     $(LIB_INSTALL_DIR)/$(TK_EXP_FILE);  ! #         fi
  !       if test "$(TK_STUB_LIB_FILE)" != "" ; then  echo "Installing $(TK_STUB_LIB_FILE)";  $(INSTALL_DATA) $(STUB_LIB_FILE)  $(LIB_INSTALL_DIR)/$(TK_STUB_LIB_FILE);  
  PatchFiles:
  Makefile



  The SCRIPT_INSTALL_DIR fix is correct and has been made for 8.3b1.
  The other fix looks like a problem with 'test' on the platform,
  because it should be able to check "" != "". 
  -- 12/20/1999 hobbs


tkt_uuid: 220641ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: Scale widget segfaults when destroyed.
comment:
  OriginalBugID: 3897 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-17'
  LastModified: '1999-12-20'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2725
  OS: All
  FixedDate: '1999-12-20'
  FixedInVersion: 8.3b1


  Name: George A. Howlett


  Comments:

  This bug has been reported several times with previous releases.


  ReproducibleScript:

  scale .s -cursor trek

  destroy .s


  ObservedBehavior:

  wish segfaults in Tk_FreeOptions


  Patch:

  *** tkScale.c-dist      Wed Apr 21 17:53:27 1999

  --- tkScale.c   Fri Dec 17 15:11:59 1999

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

  *** 164,170 ****

    static int            ConfigureScale _ANSI_ARGS_((Tcl_Interp *interp,

                              TkScale *scalePtr, int objc,

                              Tcl_Obj *CONST objv[]));

  ! static void           DestroyScale _ANSI_ARGS_((char *memPtr));

    static void           ScaleCmdDeletedProc _ANSI_ARGS_((

                              ClientData clientData));

    static void           ScaleEventProc _ANSI_ARGS_((ClientData clientData,

  --- 164,170 ----

    static int            ConfigureScale _ANSI_ARGS_((Tcl_Interp *interp,

                              TkScale *scalePtr, int objc,

                              Tcl_Obj *CONST objv[]));

  ! static void           DestroyScale _ANSI_ARGS_((TkScale *scalePtr));

    static void           ScaleCmdDeletedProc _ANSI_ARGS_((

                              ClientData clientData));

    static void           ScaleEventProc _ANSI_ARGS_((ClientData clientData,

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

  *** 523,532 ****

     */


    static void

  ! DestroyScale(memPtr)

  !     char *memPtr;     /* Info about scale widget. */

    {

  !     register TkScale *scalePtr = (TkScale *) memPtr;


        /*

         * Free up all the stuff that requires special handling, then

  --- 523,538 ----

     */


    static void

  ! DestroyScale(scalePtr)

  !     register TkScale *scalePtr; /* Info about scale widget. */

    {

  ! 

  !     scalePtr->flags |= SCALE_DELETED;

  ! 

  !     Tcl_DeleteCommandFromToken(scalePtr->interp, scalePtr->widgetCmd);

  !     if (scalePtr->flags & REDRAW_ALL) {

  !       Tcl_CancelIdleCall(TkpDisplayScale, (ClientData) scalePtr);

  !     }


        /*

         * Free up all the stuff that requires special handling, then

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

  *** 550,556 ****

        }

        Tk_FreeConfigOptions((char *) scalePtr, scalePtr->optionTable,

              scalePtr->tkwin);

  !     TkpDestroyScale(scalePtr);

    }


    /*

  --- 556,562 ----

        }

        Tk_FreeConfigOptions((char *) scalePtr, scalePtr->optionTable,

              scalePtr->tkwin);

  !     Tcl_EventuallyFree((ClientData) scalePtr, (Tcl_FreeProc *)TkpDestroyScale);

    }


    /*

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

  *** 1022,1035 ****

        if ((eventPtr->type == Expose) && (eventPtr->xexpose.count == 0)) {

          TkEventuallyRedrawScale(scalePtr, REDRAW_ALL);

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

  !       if (scalePtr->tkwin != NULL) {

  !           scalePtr->tkwin = NULL;

  !           Tcl_DeleteCommandFromToken(scalePtr->interp, scalePtr->widgetCmd);

  !       }

  !       if (scalePtr->flags & REDRAW_ALL) {

  !           Tcl_CancelIdleCall(TkpDisplayScale, (ClientData) scalePtr);

  !       }

  !       Tcl_EventuallyFree((ClientData) scalePtr, DestroyScale);

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

          ComputeScaleGeometry(scalePtr);

          TkEventuallyRedrawScale(scalePtr, REDRAW_ALL);

  --- 1028,1034 ----

        if ((eventPtr->type == Expose) && (eventPtr->xexpose.count == 0)) {

          TkEventuallyRedrawScale(scalePtr, REDRAW_ALL);

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

  !       DestroyScale(scalePtr);

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

          ComputeScaleGeometry(scalePtr);

          TkEventuallyRedrawScale(scalePtr, REDRAW_ALL);

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

  *** 1082,1089 ****

         * destroys the widget.

         */


  !     if (tkwin != NULL) {

  !       scalePtr->tkwin = NULL;

          Tk_DestroyWindow(tkwin);

        }

    }

  --- 1081,1087 ----

         * destroys the widget.

         */


  !     if (!(scalePtr->flags & SCALE_DELETED)) {

          Tk_DestroyWindow(tkwin);

        }

    }

  *** tkScale.h-dist      Thu Apr 15 21:51:21 1999

  --- tkScale.h   Fri Dec 17 13:10:22 1999

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

  *** 191,204 ****

     *                            this widget.

     */


  ! #define REDRAW_SLIDER         1

  ! #define REDRAW_OTHER          2

  ! #define REDRAW_ALL            3

  ! #define ACTIVE                        4

  ! #define INVOKE_COMMAND                0x10

  ! #define SETTING_VAR           0x20

  ! #define NEVER_SET             0x40

  ! #define GOT_FOCUS             0x80


    /*

     * Symbolic values for the active parts of a slider.  These are

  --- 191,205 ----

     *                            this widget.

     */


  ! #define REDRAW_SLIDER         (1<<0)

  ! #define REDRAW_OTHER          (1<<1)

  ! #define REDRAW_ALL            (REDRAW_SLIDER | REDRAW_OTHER)

  ! #define ACTIVE                        (1<<2)

  ! #define INVOKE_COMMAND                (1<<3)

  ! #define SETTING_VAR           (1<<4)

  ! #define NEVER_SET             (1<<5)

  ! #define GOT_FOCUS             (1<<6)

  ! #define SCALE_DELETED         (1<<7)


    /*

     * Symbolic values for the active parts of a slider.  These are


  PatchFiles:

  generic/tkScale.c generic/tkScale.h




  Fixed in 8.3b1 
  -- 12/20/1999 hobbs


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: 220643ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: Cannot regenerate configure from configure.in
comment:
  OriginalBugID: 3938 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-27'
  LastModified: '2000-01-03'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: BSD
  OSVersion: NetBSD 1.4P
  FixedDate: '2000-01-03'
  FixedInVersion: 8.3b2


  Name:
  Andreas Gustafsson

  Comments:
  It looks like there is an aclocal.m4 file missing from tk8.2.3 distribution.
  Because of this, you can't generate a working configure script from
  the configure.in template by running autoconf.  This makes it kind of 
  hard to fix bugs in configure.in, and even harder to fix bugs in 
  the nonexistent aclocal.m4. :-(

  ReproducibleScript:
  cd tk8.2.3/unix
  autoconf
  ./configure

  ObservedBehavior:
  creating cache ./config.cache
  checking for ranlib... ranlib
  SC_ENABLE_GCC: not found
  [followed by other error messages]

  DesiredBehavior:
  Successful configuration



  This has been fixed for 8.3b2. 
  -- 01/03/2000 hobbs


tkt_uuid: 220644ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: Improper use of after, eval, and uplevel
comment:
  OriginalBugID: 3943 Bug
  Version: 8.3b1
  SubmitDate: '1999-12-27'
  LastModified: '2000-01-03'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-SuSE
  FixedDate: '2000-01-03'
  FixedInVersion: 8.3b2


  Name:

  Dr. Csaba Nemethi


  Comments:

  Most people use only letters, digits, and underscore in the components

  of widget names, and a lot of Tcl/Tk code is potentionally broken

  because of the erronous assumption that widget names cannot have any 

  other characters (except the dot).  This is probably the reason for the

  above, very long-standing bug.


  ReproducibleScript:

  According to the Tcl man page, ".my entry" is a legal "word" and hence 

  a valid widget and command name.  For example, the following script is 

  both syntactically and semantically correct:


  pack [entry ".my entry"]

  ".my entry" insert 0 "any text"


  ObservedBehavior:

  When the mouse leaves this entry widget with button 1 down, the

  following error message is displayed:


      called "tkEntryAutoScan" with too many arguments

          while executing

      "tkEntryAutoScan .my entry"

          ("after" script)


  The reason is obvious:  In line 433 of the library file entry.tcl, the

  after-ID of the next auto-scan command to be executed for the given

  entry widget is set to [after 50 tkEntryAutoScan $w], where w has the

  value ".my entry". The after command concatenates its arguments,

  therefore tkEntryAutoScan are passed the arguments ".my" and "entry"

  instead of the single argument ".my entry".


  This is just one example of improper invocation of the after command in

  Tk library files, and there are similar problems with eval and uplevel.


  DesiredBehavior:

  The invocations of after, eval, and uplevel should make use of the list 

  command, in order to work for widget names containing spaces or other

  special characters.


  Patch:

  *** entry.tcl.OLD       Tue Nov 30 08:27:01 1999

  --- entry.tcl.NEW       Sun Dec 26 12:04:44 1999

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

  *** 430,436 ****

          $w xview scroll -2 units

          tkEntryMouseSelect $w $x

        }

  !     set tkPriv(afterId) [after 50 tkEntryAutoScan $w]

    }


    # tkEntryKeySelect --

  --- 430,436 ----

          $w xview scroll -2 units

          tkEntryMouseSelect $w $x

        }

  !     set tkPriv(afterId) [after 50 [list tkEntryAutoScan $w]]

    }


    # tkEntryKeySelect --

  *** listbox.tcl.OLD     Wed Dec 22 00:55:27 1999

  --- listbox.tcl.NEW     Sun Dec 26 12:05:53 1999

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

  *** 347,353 ****

          return

        }

        tkListboxMotion $w [$w index @$x,$y]

  !     set tkPriv(afterId) [after 50 tkListboxAutoScan $w]

    }


    # tkListboxUpDown --

  --- 347,353 ----

          return

        }

        tkListboxMotion $w [$w index @$x,$y]

  !     set tkPriv(afterId) [after 50 [list tkListboxAutoScan $w]]

    }


    # tkListboxUpDown --

  *** scale.tcl.OLD       Thu Sep  2 19:02:53 1999

  --- scale.tcl.NEW       Sun Dec 26 12:08:52 1999

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

  *** 211,222 ****


        if {[string equal $repeat "again"]} {

          set tkPriv(afterId) [after [$w cget -repeatinterval] \

  !               tkScaleIncrement $w $dir $big again]

        } elseif {[string equal $repeat "initial"]} {

          set delay [$w cget -repeatdelay]

          if {$delay > 0} {

              set tkPriv(afterId) [after $delay \

  !                   tkScaleIncrement $w $dir $big again]

          }

        }

    }

  --- 211,222 ----


        if {[string equal $repeat "again"]} {

          set tkPriv(afterId) [after [$w cget -repeatinterval] \

  !               [list tkScaleIncrement $w $dir $big again]]

        } elseif {[string equal $repeat "initial"]} {

          set delay [$w cget -repeatdelay]

          if {$delay > 0} {

              set tkPriv(afterId) [after $delay \

  !                   [list tkScaleIncrement $w $dir $big again]]

          }

        }

    }

  *** scrlbar.tcl.OLD     Wed Oct 20 03:02:24 1999

  --- scrlbar.tcl.NEW     Sun Dec 26 12:45:49 1999

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

  *** 198,208 ****

        }

        if {[string equal $repeat "again"]} {

          set tkPriv(afterId) [after [$w cget -repeatinterval] \

  !               tkScrollSelect $w $element again]

        } elseif {[string equal $repeat "initial"]} {

          set delay [$w cget -repeatdelay]

          if {$delay > 0} {

  !           set tkPriv(afterId) [after $delay tkScrollSelect $w $element again]

          }

        }

    }

  --- 198,209 ----

        }

        if {[string equal $repeat "again"]} {

          set tkPriv(afterId) [after [$w cget -repeatinterval] \

  !               [list tkScrollSelect $w $element again]]

        } elseif {[string equal $repeat "initial"]} {

          set delay [$w cget -repeatdelay]

          if {$delay > 0} {

  !           set tkPriv(afterId) [after $delay \

  !                   [list tkScrollSelect $w $element again]]

          }

        }

    }

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

  *** 258,266 ****

                      [expr {[lindex $tkPriv(initValues) 1] + $delta}]

          } else {

              set delta [expr {round($delta * [lindex $tkPriv(initValues) 0])}]

  !           eval $w set [lreplace $tkPriv(initValues) 2 3 \

                      [expr {[lindex $tkPriv(initValues) 2] + $delta}] \

  !                   [expr {[lindex $tkPriv(initValues) 3] + $delta}]]

          }

        } else {

          tkScrollToPos $w [expr {$tkPriv(initPos) + $delta}]

  --- 259,267 ----

                      [expr {[lindex $tkPriv(initValues) 1] + $delta}]

          } else {

              set delta [expr {round($delta * [lindex $tkPriv(initValues) 0])}]

  !           eval [list $w set [lreplace $tkPriv(initValues) 2 3 \

                      [expr {[lindex $tkPriv(initValues) 2] + $delta}] \

  !                   [expr {[lindex $tkPriv(initValues) 3] + $delta}]]]

          }

        } else {

          tkScrollToPos $w [expr {$tkPriv(initPos) + $delta}]

  *** tearoff.tcl.OLD     Thu Sep  2 19:02:53 1999

  --- tearoff.tcl.NEW     Sun Dec 26 20:02:51 1999

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

  *** 93,99 ****


        set cmd [$w cget -tearoffcommand]

        if {[string compare $cmd ""]} {

  !       uplevel #0 $cmd $w $menu

        }

        return $menu

    }

  --- 93,99 ----


        set cmd [$w cget -tearoffcommand]

        if {[string compare $cmd ""]} {

  !       uplevel #0 $cmd [list $w $menu]

        }

        return $menu

    }

  *** text.tcl.OLD        Thu Sep  2 19:02:53 1999

  --- text.tcl.NEW        Sun Dec 26 12:15:11 1999

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

  *** 634,640 ****

          return

        }

        tkTextSelectTo $w $tkPriv(x) $tkPriv(y)

  !     set tkPriv(afterId) [after 50 tkTextAutoScan $w]

    }


    # tkTextSetCursor

  --- 634,640 ----

          return

        }

        tkTextSelectTo $w $tkPriv(x) $tkPriv(y)

  !     set tkPriv(afterId) [after 50 [list tkTextAutoScan $w]]

    }


    # tkTextSetCursor

  *** tkfbox.tcl.OLD      Thu Dec 16 22:57:53 1999

  --- tkfbox.tcl.NEW      Sun Dec 26 12:22:25 1999

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

  *** 150,156 ****

        }


        tkIconList_Motion1 $w $x $y

  !     set tkPriv(afterId) [after 50 tkIconList_AutoScan $w]

    }


    # Deletes all the items inside the canvas subwidget and reset the IconList's

  --- 150,156 ----

        }


        tkIconList_Motion1 $w $x $y

  !     set tkPriv(afterId) [after 50 [list tkIconList_AutoScan $w]]

    }


    # Deletes all the items inside the canvas subwidget and reset the IconList's

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

  *** 555,561 ****

        catch {

          after cancel $tkPriv(ILAccel,$w,afterId)

        }

  !     set tkPriv(ILAccel,$w,afterId) [after 500 tkIconList_Reset $w]

    }


    proc tkIconList_Goto {w text} {

  --- 555,561 ----

        catch {

          after cancel $tkPriv(ILAccel,$w,afterId)

        }

  !     set tkPriv(ILAccel,$w,afterId) [after 500 [list tkIconList_Reset $w]]

    }


    proc tkIconList_Goto {w text} {

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

  *** 933,939 ****

        if {[info exists data(updateId)]} {

          return

        } else {

  !       set data(updateId) [after idle tkFDialog_Update $w]

        }

    }


  --- 933,939 ----

        if {[info exists data(updateId)]} {

          return

        } else {

  !       set data(updateId) [after idle [list tkFDialog_Update $w]]

        }

    }


  *** xmfbox.tcl.OLD      Wed Nov 24 21:59:06 1999

  --- xmfbox.tcl.NEW      Sun Dec 26 12:26:13 1999

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

  *** 786,792 ****

        catch {

          after cancel $tkPriv(lbAccel,$w,afterId)

        }

  !     set tkPriv(lbAccel,$w,afterId) [after 500 tkListBoxKeyAccel_Reset $w]

    }


    proc tkListBoxKeyAccel_Goto {w string} {

  --- 786,792 ----

        catch {

          after cancel $tkPriv(lbAccel,$w,afterId)

        }

  !     set tkPriv(lbAccel,$w,afterId) [after 500 [list tkListBoxKeyAccel_Reset $w]]

    }


    proc tkListBoxKeyAccel_Goto {w string} {


  PatchFiles:

  entry.tcl

      focus.tcl

      listbox.tcl

      scale.tcl

      scrlbar.tcl

      tearoff.tcl

      text.tcl

      tkfbox.tcl

      xmfbox.tcl




  fixed in 8.3b2 
  -- 01/03/2000 hobbs


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


  Name: Andreas Gustafsson

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

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

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

  ReproducibleScript:
  configure --enable-shared
  make

  ObservedBehavior:
  Normal configure and make output, then:

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

  DesiredBehavior:
  Successful linking.

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

  PatchFiles:
  aclocal.m4



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


tkt_uuid: 220646ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: Memory leak in advanced tag search feature
comment:
  OriginalBugID: 3977 Bug
  Version: 8.3b1
  SubmitDate: '2000-01-05'
  LastModified: '2000-01-07'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  FixedDate: '2000-01-07'
  FixedInVersion: 8.3b2


  Name:

  Jan Nijtmans


  Comments:

  Many thanks to Kirk Hilliard for reporting and tracking down this bug (he also provided the above example script), and to John Ellson for fixing it so quickly.

  And last but not least to David Engel for all his support.


  ReproducibleScript:

  proc poly {} {

      global id a b

      if {$id != 0} { .c delete $id }

      set id [.c create oval $a $a $b $b -fill #ff0000]

      incr a

      incr b -1

      if {$b == 10} {

          set a 10

          set b 90

      }

      after 10 poly

  }


  set id 0

  set a 10

  set b 90

  canvas .c -width 100 -height 100 -bg black

  pack append . .c expand

  poly


  ObservedBehavior:

  This script about 48 kByte each second.


  Patch:

  *** generic/tkCanvas.c.origWed Dec 22 04:13:44 1999

  --- generic/tkCanvas.cTue Jan  4 22:07:07 2000

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

  *** 311,318 ****

    static intRelinkItems _ANSI_ARGS_((TkCanvas *canvasPtr,

        Tcl_Obj *tag, Tk_Item *prevPtr,

        TagSearch **searchPtrPtr));

  ! static void TagSearchExprInit _ANSI_ARGS_ ((TagSearchExpr **exprPtrPtr,

  !     Tk_Uid uid));

    static voidTagSearchExprDestroy _ANSI_ARGS_((TagSearchExpr *expr));

    static voidTagSearchDestroy _ANSI_ARGS_((TagSearch *searchPtr));

    static intTagSearchScan _ANSI_ARGS_((TkCanvas *canvasPtr,

  --- 311,317 ----

    static intRelinkItems _ANSI_ARGS_((TkCanvas *canvasPtr,

        Tcl_Obj *tag, Tk_Item *prevPtr,

        TagSearch **searchPtrPtr));

  ! static void TagSearchExprInit _ANSI_ARGS_ ((TagSearchExpr **exprPtrPtr));

    static voidTagSearchExprDestroy _ANSI_ARGS_((TagSearchExpr *expr));

    static voidTagSearchDestroy _ANSI_ARGS_((TagSearch *searchPtr));

    static intTagSearchScan _ANSI_ARGS_((TkCanvas *canvasPtr,

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

  *** 3010,3018 ****

     */


    static void

  ! TagSearchExprInit(exprPtrPtr, uid)

    TagSearchExpr **exprPtrPtr;

  - Tk_Uid uid;

    {

        TagSearchExpr* expr = *exprPtrPtr;


  --- 3009,3016 ----

     */


    static void

  ! TagSearchExprInit(exprPtrPtr)

    TagSearchExpr **exprPtrPtr;

    {

        TagSearchExpr* expr = *exprPtrPtr;


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

  *** 3022,3028 ****

    expr->uids = NULL;

    expr->next = NULL;

        }

  !     expr->uid = uid;

        expr->index = 0;

        expr->length = 0;

        *exprPtrPtr = expr;

  --- 3020,3026 ----

    expr->uids = NULL;

    expr->next = NULL;

        }

  !     expr->uid = NULL;

        expr->index = 0;

        expr->length = 0;

        *exprPtrPtr = expr;

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

  *** 3068,3074 ****

     *      was successfully scanned (syntax).

     *      The information at *searchPtr is initialized

     *      such that a call to TagSearchFirst, followed by

  !  *      successive calls to NextItem will return items

     *      that match tag.

     *

     * Side effects:

  --- 3066,3072 ----

     *      was successfully scanned (syntax).

     *      The information at *searchPtr is initialized

     *      such that a call to TagSearchFirst, followed by

  !  *      successive calls to TagSearchNext will return items

     *      that match tag.

     *

     * Side effects:

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

  *** 3107,3123 ****

            searchPtr->rewritebuffer =

                ckalloc(searchPtr->rewritebufferAllocated);

        }

  !     TagSearchExprInit(&(searchPtr->expr),Tk_GetUid(tag));


  !     /* short circuit impossible searches for null tags */

  !     if ((searchPtr->stringLength = strlen(tag)) == 0) {

  !         return TCL_OK;

  ! }


        /* Make sure there is enough buffer to hold rewritten tags */

        if ((unsigned int)searchPtr->stringLength >=

        searchPtr->rewritebufferAllocated) {

  !         searchPtr->rewritebufferAllocated += 100;

            searchPtr->rewritebuffer =

                ckrealloc(searchPtr->rewritebuffer,

        searchPtr->rewritebufferAllocated);

  --- 3105,3119 ----

            searchPtr->rewritebuffer =

                ckalloc(searchPtr->rewritebufferAllocated);

        }

  !     TagSearchExprInit(&(searchPtr->expr));


  !     /* How long is the tagOrId ? */

  !     searchPtr->stringLength = strlen(tag);


        /* Make sure there is enough buffer to hold rewritten tags */

        if ((unsigned int)searchPtr->stringLength >=

        searchPtr->rewritebufferAllocated) {

  !         searchPtr->rewritebufferAllocated = searchPtr->stringLength + 100;

            searchPtr->rewritebuffer =

                ckrealloc(searchPtr->rewritebuffer,

        searchPtr->rewritebufferAllocated);

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

  *** 3135,3141 ****

         * hot item, in which case the search can be skipped.

         */


  !     if (isdigit(UCHAR(*tag))) {

            char *end;


            searchPtr->id = strtoul(tag, &end, 0);

  --- 3131,3137 ----

         * hot item, in which case the search can be skipped.

         */


  !     if (searchPtr->stringLength && isdigit(UCHAR(*tag))) {

            char *end;


            searchPtr->id = strtoul(tag, &end, 0);

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

  *** 3143,3148 ****

  --- 3139,3156 ----

                searchPtr->type = 1;

                return TCL_OK;

    }

  +     }

  + 

  +     /*

  +      * For all other tags and tag expressions convert to a UID.

  +      * This UID is kept forever, but this should be thought of

  +      * as a cache rather than as a memory leak.

  +      */

  +     searchPtr->expr->uid = Tk_GetUid(tag);

  + 

  +     /* short circuit impossible searches for null tags */

  +     if (searchPtr->stringLength == 0) {

  + return TCL_OK;

        }


        /*


  PatchFiles:

  tkCanvas.c




  fixed in 8.3b2 
  -- 01/07/2000 hobbs


tkt_uuid: 220647ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: "winfo containing" can crash wish
comment:
  OriginalBugID: 3983 Bug
  Version: 8.2.3
  SubmitDate: '2000-01-06'
  LastModified: '2000-01-07'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 716
  OS: Solaris
  OSVersion: Solaris 7
  Machine: Sparc
  FixedDate: '2000-01-07'
  FixedInVersion: 8.3b1


  Name:
  Colin McDonald

  ReproducibleScript:
  The following simplified script consistently fails under Solaris 7:

  toplevel .top1
  toplevel .top2
  update
  set x [winfo rootx .top2]
  set y [winfo rooty .top2]
  destroy .top2
  winfo containing $x $y

  ObservedBehavior:
  wish exits with the following Xlib error message:

  X Error of failed request:  BadWindow (invalid Window parameter)
    Major opcode of failed request:  40 (X_TranslateCoords)

  DesiredBehavior:
  The Tk routine Tk_CoordsToWindow has no protection against windows being
  deleted.  It should probably use Tk_CreateErrorHandler and/or ignore
  Tk windows in the process of being deleted.



  This was coincidentally fixed in 8.3b1 by bug 716 (for Tix) where
  the panic was changed to a stderr message with the error handler
  used. 
  -- 01/07/2000 hobbs


tkt_uuid: 220648ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: Double-clicking in text widget does not properly select a word if there are embedded windows/images
comment:
  OriginalBugID: 3989 Bug
  Version: 8.3b1
  SubmitDate: '2000-01-07'
  LastModified: '2000-01-19'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  FixedDate: '2000-01-19'
  FixedInVersion: 8.3


  Name:
  Peter Shawhan

  Comments:
  The explanation for this bug is that the procs tkTextNextPos and tkTextPrevPos (in text.tcl)
  use "$w get" to get a string from the text widget, then scan it for the nearest word break.  Since
  "get" omits embedded windows/images, the character indexing is offset from what it should be.

  One solution would be to provide an alternative form of "get" (e.g. an option) which replaces any
  embedded window/image by a space; tkTextNextPos and tkTextPrevPos could then call this form
  for purposes of scanning for word breaks.  The default form of "get" would still omit windows/images
  as is currently the case.

  Even if the alternative form of "get" is not implemented in the core text widget, the same behavior
  can be produced by a small piece of code which could be called by tkTextNextPos and tkTextPrevPos:

  proc alternative_get {w start end} {
      set string ""
      foreach {type val pos} [$w dump -text -window -image $start $end] {
  if {$type == "text"} {
      append string $val
  } else {
      append string " "
  }
      }
      return $string
  }

  ReproducibleScript:
  Execute the following script:

  #------------------- Beginning of script
  #-- Create a bitmap image
  set bmp [image create bitmap -foreground red -data "
  #define square_width 9
  #define square_height 15
  static unsigned char square_bits[] = {
     0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x7c, 0x00, 0x7c, 0x00,
     0x7c, 0x00, 0x7c, 0x00, 0x7c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
     0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
  "]

  #-- Create a text widget and pack it
  text .t -width 80 -height 10
  pack .t

  #-- Insert some text with embedded images/windows
  .t insert end " 11111"; .t image create end -image $bmp
  .t insert end " 22222"; .t image create end -image $bmp
  .t insert end " 33333"; .t image create end -image $bmp
  .t insert end " 44444\n\n";

  .t insert end "aaa 123"; .t image create end -image $bmp;
  .t insert end "456 bbb\n\n"

  .t insert end "ccc 789"
  button .t.help -text "Help" -command {puts "You pressed Help"}
  .t window create end -window .t.help
  .t insert end "000 ddd\n"
  #------------------- End of script

  Now double-click on the various groups of characters and observe what is selected.

  ObservedBehavior:
  Double-clicking does not properly select a word if there are embedded images/windows on a line.
  Specifically,
    1) The leftward extent of the selection is too large, by a number of characters equal to the 
      number of embedded images/windows on the line to the left of the selection.  For example,
      if you double-click on the group of 4's, the selection includes the final 3 from the group of
      3's, along with the image and space between the 3's and 4's.
    2) The rightward extent of the selection is sometimes too small, by a number of characters
      equal to the number of embedded images/windows in the current word to the right of where
      you double-clicked.  For example, if you double-click on the 123, the selection includes the
      following image and the 45, but not the 6.

  DesiredBehavior:
  Double-clicking should always select a word, even if there are embedded images/windows on
  the line.  (The issue of whether an image/window counts as part of a word is a subtlety that
  I do not care about, since in any case it is left out when the selection is pasted into another
  window.)



  This opened a bit of a sticky mess.  When you do a get for a range
  of text in the text widget over embedded windows/images, you don't
  get the embedded stuff returned, but you also don't get any
  compensation for the one index position that each takes.  Since at
  some point it was decided to move the word boundary checks to a Tcl
  routine, this info is totally lost and you get the behavior above
  (including many other related goofy behaviors for any binding that uses
  the tcl word break functions in the text widget).  I've added some
  hacks into 8.3.0 that get around almost all of this.

  I guess the reasoning for skipping the text widget search stuff,
  which would normally work, is the desire to have platform specific
  word boundary breaks.  Irk, this seems like a bad idea. 
  -- 01/19/2000 hobbs


tkt_uuid: 220649ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: event generate -warp 1 can cause a segv
comment:
  OriginalBugID: 4004 Bug
  Version: 8.3b1
  SubmitDate: '2000-01-11'
  LastModified: '2000-01-12'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT server 4 patchlevel 5
  Machine: Dual PII-400, 360 megs o' RAM
  FixedDate: '2000-01-12'
  FixedInVersion: 8.3b2


  Name: Bryan Oakley

  ReproducibleScript:
  button .b -text "Exit" -command exit
  pack .b

  after idle event generate .b <Motion> -x 1 -y 1 -warp 1

  ObservedBehavior:
  When I run the script, I get a segmentation violation

  DesiredBehavior:
  no segmentation violation 
  I also expect to see the pointer warp to the button.



  This is because the window has not yet been mapped, and thus the
  Windows HWND is still null.  This will be fixed, but the whole
  behavior is likely to change such that -warp requires that the
  window be mapped first, which means the user will have to put in
  an update, or put the -warp in a <Map> event. 
  -- 01/11/2000 hobbs
  The fixed was to add a check for Tk_IsMapped(tkwin), to make
  sure that the window has been mapped.  This also means that
  -warp, now by def'n, doesn't do anything if the window is not
  mapped (which makes sense).  The user would then get rid of
  the 'after idle' and add a:
      tkwait visibility .b
  to make the script correct (this will actually make 8.3b1 not
  core as well). 
  -- 01/12/2000 hobbs


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


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



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


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


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



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

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


tkt_uuid: 220652ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: Transient window madness
comment:
  OriginalBugID: 4026 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-17'
  LastModified: '2000-01-28'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-01-28'
  FixedInVersion: 8.3


  Name:
  Tim Baker

  Comments:
  When I remove the "wm resizable" line from the script, everything works as expected.

  ReproducibleScript:
  toplevel .topA
  wm resizable .topA no no

  toplevel .topB
  wm transient .topB .topA

  Put the above into a script and start wish83 (so that the console also appears), then source the script:
  % source script.tcl

  ObservedBehavior:
  Notice that topB is still withdrawn, it should be mapped. Type
  % wm deiconify .topB

  topB appears, but the contents are not being drawn!
  Now iconify topA by clicking the titlebar button, then deiconify topA by clicking the Windows Taskbar.
  If you drag topB, you'll discover that there are now two Win32 window frames for topB!



  This was introduced in 8.3b2 with reworking of the Windows wm.
  Must be corrected ASAP. 
  -- 01/17/2000 hobbs
  All the related problems have been solved.  This has always been
  an odd area, but now it should work more "as expected".  8.3 will
  also have clearer docs for 'wm', most directly pointing to the
  fact that there are some platform dependent aspects that must be
  considered when using the 'wm' command. 
  -- 01/28/2000 hobbs


tkt_uuid: 220653ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: string args bug from UTS4 C compiler
comment:
  OriginalBugID: 4027 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-17'
  LastModified: '2000-01-18'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: UTS4
  Machine: Amdahl ??
  FixedDate: '2000-01-18'
  FixedInVersion: 8.3


  Name: John Ellson

  ObservedBehavior:
  cc -c -O    -I. -I./../generic  -I./../bitmaps -I/opt2/exp/expmake/build/tcltksrc/tcl8.3/generic   -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1 -D__CHAR_UNSIGNED__=1       -DTCL_NO_DEPRECATED   ./../generic/tkListbox.c

  "./../generic/tkListbox.c", line 2517: Syntax error: stringRep
  2517        "number", (char *)NULL);
  ____________________________^
  "./../generic/tkListbox.c", line 2525: Syntax error: stringRep
  2525        "number", (char *)NULL);
  ____________________________^
            ./../generic/tkListbox.c ... 2 Errors.

  DesiredBehavior:
  no compile errors

  Patch:
  *** generic/tkListbox.c.origSun Jan 16 12:36:54 2000
  --- generic/tkListbox.cSun Jan 16 12:37:29 2000
  ***************
  *** 2513,2528 ****
    strtol(start, &end, 0);
    if ((start == end) || (*end != ',')) {
        Tcl_AppendResult(interp, "bad listbox index \"", stringRep,
  !     "\": must be active, anchor, end, @x,y, or a "
  !     "number", (char *)NULL);
        return TCL_ERROR;
    }
    start = end+1;
    y = strtol(start, &end, 0);
    if ((start == end) || (*end != '\0')) {
        Tcl_AppendResult(interp, "bad listbox index \"", stringRep,
  !     "\": must be active, anchor, end, @x,y, or a "
  !     "number", (char *)NULL);
        return TCL_ERROR;
    }
    *indexPtr = NearestListboxElement(listPtr, y);
  --- 2513,2528 ----
    strtol(start, &end, 0);
    if ((start == end) || (*end != ',')) {
        Tcl_AppendResult(interp, "bad listbox index \"", stringRep,
  !     "\": must be active, anchor, end, @x,y, or a number",
  !                     (char *)NULL);
        return TCL_ERROR;
    }
    start = end+1;
    y = strtol(start, &end, 0);
    if ((start == end) || (*end != '\0')) {
        Tcl_AppendResult(interp, "bad listbox index \"", stringRep,
  !     "\": must be active, anchor, end, @x,y, or a number",
  !                     (char *)NULL);
        return TCL_ERROR;
    }
    *indexPtr = NearestListboxElement(listPtr, y);

  PatchFiles:
  generic/tkListbox.c



  Although this is obviously a compiler bug (and serious, since this
  is a basic C tenant), the fix was made in the code. 
  -- 01/17/2000 hobbs
  Correction, this is not a compiler bug, it is ANSI C behavior,
  which we don't (yet) require.  For the UTS compiler, this is
  received by adding either -Xa or setting CC=$(ANSICC). 
  -- 01/18/2000 hobbs


tkt_uuid: 220654ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: seg fault on command "$canvas postscript"
comment:
  OriginalBugID: 4028 Bug
  Version: 8.2
  SubmitDate: '2000-01-17'
  LastModified: '2000-01-17'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  Machine: PC Celeron 333Mhz
  FixedDate: '2000-01-17'
  FixedInVersion: 8.3b2


  Name: Enrico Carniani

  ReproducibleScript:
  canvas .c
  ...
  update
  .c postscript -file a.ps

  ObservedBehavior:
  Sorry, no stack trace... The application crashes.
  In tk8.0, produced an empty postscript file.
  I haven't tried other previous versions.

  DesiredBehavior:
  I'd like the command to work...


  This does not core in Tk8.3b2 on Linux, so it was either fixed in
  the interim, or there is some other magic in the "..." that causes
  the crash. 
  -- 01/17/2000 hobbs


tkt_uuid: 220655ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: text widget bugs
comment:
  OriginalBugID: 4036 Bug
  Version: 8.2.3
  SubmitDate: '2000-01-18'
  LastModified: '2000-01-19'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0sp5
  FixedDate: '2000-01-19'
  FixedInVersion: 8.3


  Name:
  Vince Darley

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  I was looking through the contents of text.test, and some of the
  supposed 'correct' results seem to be wrong to me (some very minor,
  some more important):

  text-20.11, 20.12

  wrong # args: should be ".t search ?switches? pattern index ?stopIndex?

  Here we are missing a trailing "

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

  text-20.65 TextSearchCmd, unicode with non-text segments 
  (and some earlier tests seem to have similar problems)

  1.3 3

  Surely the result should be 1.3 2, since we are searching for a
  2 character string: 

  set result [list [.t search -count n \u30c9\u30ca 1.0] $n]

  Here, and in other tests, the search string is split in the window by
  an embedded widget.  But surely embedded widgets don't count as
  a 'count' of 1??!!

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

  Lastly:

  % text .i
  .i
  % .i dummy
  bad option "dummy": must be bbox, cget, compare, configure, debug, delete, dlineinfo, get, image, index, insert, mark, scan, search, see, tag, window, xview, or yview
  % .i dump
  Usage: .i dump ?-all -image -text -mark -tag -window? ?-command script? index ?index2?
  % 

  Why isn't "dump" in the list of options returned by an error?



  The first and last problems are fixed for 8.3.0, and the middle
  one (incorrect counting of bytes vs. chars for search) was fixed
  in 8.3b1 or b2 already. 
  -- 01/19/2000 hobbs


tkt_uuid: 220656ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: Wrong option spec for tkListbox
comment:
  OriginalBugID: 4039 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-19'
  LastModified: '2000-01-19'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  FixedDate: '2000-01-19'
  FixedInVersion: 8.3


  Name:

  Harald Kunze


  Extensions:

  iTcl


  Comments:

  When creating megawidgets with [incr Tk] which include a listbox and an entry it causes an error, as the resource class for selectBackground of an entry and a listbox differs.


  ReproducibleScript:

  option add *Background red


  listbox .l

  pack .l -fill both


  .l insert end this

  .l insert end is

  .l insert end a

  .l insert end test


  ObservedBehavior:

  The active item and the listbox itself have the same background color.


  DesiredBehavior:

  Only the background color of the listbox is set to red.


  Patch:

  234c234

  <     {TK_OPTION_BORDER, "-selectbackground", "selectBackground", "Background",

  ---

  >     {TK_OPTION_BORDER, "-selectbackground", "selectBackground", "Foreground",

  282c282

  <     {TK_OPTION_BORDER, "-selectbackground", "selectBackground", "Background",

  ---

  >     {TK_OPTION_BORDER, "-selectbackground", "selectBackground", "Foreground",


  PatchFiles:

  tkListbox.c




  Correct, this got incorrectly swapped in the objectification of
  the widget.  Also the items -select* class was changed. 
  -- 01/19/2000 hobbs


tkt_uuid: 220657ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: segfault on CANVAS COORDS
comment:
  OriginalBugID: 4042 Bug
  Version: 8.2
  SubmitDate: '2000-01-19'
  LastModified: '2000-02-10'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: 2.2.13
  Machine: Linux w/ Celeron 333, 32Mhz
  FixedDate: '2000-02-10'
  FixedInVersion: 8.3


  Name: Enrico Carniani

  Comments:
  Tk8.0 also gets a segmentation fault.

  ReproducibleScript:
  canvas .c
  .c coords [.c create line 0 0 10 10 -arrow last] 0 0

  ObservedBehavior:
  segmentation fault

  DesiredBehavior:
  It should report an error, such as "too few arguments" (as in Tk version 4.2).



  the LineCoords call was not checking for a minimum number of
  coordinates.  This is fixed in 8.3. 
  -- 01/19/2000 hobbs


tkt_uuid: 220658ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.1a2
resolution: Fixed
title: tkWinWm.c compile error
comment:
  OriginalBugID: 4047 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-19'
  LastModified: '2000-01-20'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT 4.0 Service Pack 4
  Machine: PC
  FixedDate: '2000-01-20'
  FixedInVersion: 8.3


  Name:
  K. Trenorden

  Extensions:
  N/A

  ReproducibleScript:
  With Visual C++ V 6.0 and Tk compiled with sysmbols on (ie. NODEBUG = 0) the compiler reports the following error in tkWinWm.c:

          "c:\PROGRA~1\MICROS~4\vc98\bin\cl.exe" -DDLL_BUILD -DBUILD_tk -Z7 -Od -WX -c -W3 -
  nologo -Fp.\Debug\ -YX -MDd -I"c:\PROGRA~1\MICROS~4\vc98\include"  -I..\win -I..\generic -
  I..\bitmaps -I..\xlib  -I..\..\tcl8.3.b2\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 bee
  n initialized
  ..\win\tkWinWm.c(2218) : error C2220: warning treated as error - no object file generated
  NMAKE : fatal error U1077: '"c:\PROGRA~1\MICROS~4\vc98\bin\cl.exe"' : return code '0x2'

  Looking in the code variable masterPtr is indeed not set - believe this reference should be to wm->masterPtr and
  not the local variable (which probably should be deleted ?)

  If symbols are turned off the compiler produces a warning and continues on.

  ObservedBehavior:
  tkWinWm.c doesn't compile with Smbols on and Visual C++ 6.0

  DesiredBehavior:
  No warning and compilation



  Already fixed in CVS for 8.3.0. 
  -- 01/20/2000 hobbs


tkt_uuid: 220659ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: Img patch 2: more fixes
comment:
  OriginalBugID: 4060 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-24'
  LastModified: '2000-02-08'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  FixedDate: '2000-02-08'
  FixedInVersion: 8.3


  Name:

  Jan Nijtmans


  Comments:

  The test suite of Img 1.2.3 handles all situations described here correctly.


  This patch is potentially incompatible with Tk8.3b2 but not with Tk8.2. It only

  has effects on extensions using the new API already. However, Img 1.2.3

  automatically handles all situations well.


  Because those fixes involve changes in the API it is important to

  handle it before 8.3 final: It is bad enough that API changes

  were necessary in the core; better to it one time correctly so that

  Tk9 doesn't need to make additional changes in the API.


  ReproducibleScript:

  This patch is a continuation of the Img patch already incorporated in Tk 8.3. It

  infoves the following additional fixes:

  - The writeStringProc function was not able to produce binary output. This problem

    was not addressed before because there didn't exist any format handler which

    produces binary output (Img only produces base-64 encoded output). However

    this is crucial if we want to transport pixel data from one package to the other

    efficiently. Img 1.2.3 is now prepared to do that.

  - Documentation did not currently reflect all changes in the new API yet.

  - portability problems when using Stubs. The documentation now has

    new sections how to compile 3th party image format handlers such

    that it will work transparently for all available Tk versions in all situations.

  - Addition of CONST keyword in new API. This has no effect, only

    lets the compiler detect more possible problems.


  Patch:

  *** unix/Makefile.in.origFri Jan 14 04:54:57 2000

  --- unix/Makefile.inSun Jan 23 10:23:44 2000

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

  *** 270,276 ****

    tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o \

    tkUnixSend.o tkUnixWm.o tkUnixXId.o tkStubInit.o tkStubLib.o


  ! STUB_LIB_OBJS = tkStubLib.o


    OBJS =  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 \

  --- 270,276 ----

    tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o \

    tkUnixSend.o tkUnixWm.o tkUnixXId.o tkStubInit.o tkStubLib.o


  ! STUB_LIB_OBJS = tkStubLib.o tkStubImg.o


    OBJS =  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 \

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

  *** 806,811 ****

  --- 806,814 ----


    tkStubLib.o: $(GENERIC_DIR)/tkStubLib.c

    $(CC) -c $(CC_SWITCHES) $(GENERIC_DIR)/tkStubLib.c

  + 

  + tkStubImg.o: $(GENERIC_DIR)/tkStubImg.c

  + $(CC) -c $(CC_SWITCHES) $(GENERIC_DIR)/tkStubImg.c


    tkUnix.o: $(UNIX_DIR)/tkUnix.c

    $(CC) -c $(CC_SWITCHES) $(UNIX_DIR)/tkUnix.c

  *** win/Makefile.in.origFri Jan 14 04:55:04 2000

  --- win/Makefile.inSun Jan 23 10:23:44 2000

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

  *** 331,337 ****

    tkWindow.$(OBJEXT)


    STUB_OBJS = \

  ! tkStubLib.$(OBJEXT)


    TCL_DOCS = "$(TCL_SRC_DIR_NATIVE)"/../doc/*.[13n]

    TK_DOCS = "$(ROOT_DIR_NATIVE)"/doc/*.[13n]

  --- 331,338 ----

    tkWindow.$(OBJEXT)


    STUB_OBJS = \

  ! tkStubLib.$(OBJEXT) \

  ! tkStubImg.$(OBJEXT)


    TCL_DOCS = "$(TCL_SRC_DIR_NATIVE)"/../doc/*.[13n]

    TK_DOCS = "$(ROOT_DIR_NATIVE)"/doc/*.[13n]

  *** win/makefile.vc.origThu Dec  9 15:46:41 1999

  --- win/makefile.vcSun Jan 23 10:23:44 2000

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

  *** 216,221 ****

  --- 216,222 ----

    $(TMPDIR)\tkWindow.obj


    TKSTUBOBJS = $(TMPDIR)\tkStubLib.obj \

  + $(TMPDIR)\tkStubImg.obj


    cc32= "$(TOOLS32)\bin\cl.exe"

  *** generic/tk.h.origSun Jan 16 20:35:23 2000

  --- generic/tk.hSun Jan 23 10:27:59 2000

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

  *** 1194,1216 ****

    Tk_PhotoImageBlock *blockPtr));

    #else

    typedef int (Tk_ImageFileMatchProc) _ANSI_ARGS_((Tcl_Channel chan,

  ! char *fileName, Tcl_Obj *format, int *widthPtr,

    int *heightPtr, Tcl_Interp *interp));

    typedef int (Tk_ImageStringMatchProc) _ANSI_ARGS_((Tcl_Obj *dataObj,

    Tcl_Obj *format, int *widthPtr, int *heightPtr,

    Tcl_Interp *interp));

    typedef int (Tk_ImageFileReadProc) _ANSI_ARGS_((Tcl_Interp *interp,

  ! Tcl_Channel chan, char *fileName, Tcl_Obj *format,

    Tk_PhotoHandle imageHandle, int destX, int destY,

    int width, int height, int srcX, int srcY));

    typedef int (Tk_ImageStringReadProc) _ANSI_ARGS_((Tcl_Interp *interp,

    Tcl_Obj *dataObj, Tcl_Obj *format, Tk_PhotoHandle imageHandle,

    int destX, int destY, int width, int height, int srcX, int srcY));

    typedef int (Tk_ImageFileWriteProc) _ANSI_ARGS_((Tcl_Interp *interp,

  ! char *fileName, Tcl_Obj *format, Tk_PhotoImageBlock *blockPtr));

    typedef int (Tk_ImageStringWriteProc) _ANSI_ARGS_((Tcl_Interp *interp,

  ! Tcl_DString *dataPtr, Tcl_Obj *format,

  ! Tk_PhotoImageBlock *blockPtr));

    #endif


    /*

  --- 1194,1215 ----

    Tk_PhotoImageBlock *blockPtr));

    #else

    typedef int (Tk_ImageFileMatchProc) _ANSI_ARGS_((Tcl_Channel chan,

  ! CONST char *fileName, Tcl_Obj *format, int *widthPtr,

    int *heightPtr, Tcl_Interp *interp));

    typedef int (Tk_ImageStringMatchProc) _ANSI_ARGS_((Tcl_Obj *dataObj,

    Tcl_Obj *format, int *widthPtr, int *heightPtr,

    Tcl_Interp *interp));

    typedef int (Tk_ImageFileReadProc) _ANSI_ARGS_((Tcl_Interp *interp,

  ! Tcl_Channel chan, CONST char *fileName, Tcl_Obj *format,

    Tk_PhotoHandle imageHandle, int destX, int destY,

    int width, int height, int srcX, int srcY));

    typedef int (Tk_ImageStringReadProc) _ANSI_ARGS_((Tcl_Interp *interp,

    Tcl_Obj *dataObj, Tcl_Obj *format, Tk_PhotoHandle imageHandle,

    int destX, int destY, int width, int height, int srcX, int srcY));

    typedef int (Tk_ImageFileWriteProc) _ANSI_ARGS_((Tcl_Interp *interp,

  ! CONST char *fileName, Tcl_Obj *format, Tk_PhotoImageBlock *blockPtr));

    typedef int (Tk_ImageStringWriteProc) _ANSI_ARGS_((Tcl_Interp *interp,

  ! Tcl_Obj *format, Tk_PhotoImageBlock *blockPtr));

    #endif


    /*

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

  *** 1252,1258 ****

    EXTERN voidTk_CreateOldPhotoImageFormat _ANSI_ARGS_((

    Tk_PhotoImageFormat *formatPtr));


  ! #ifdef USE_OLD_IMAGE

    #define Tk_CreateImageType Tk_CreateOldImageType

    #define Tk_CreatePhotoImageFormat Tk_CreateOldPhotoImageFormat

    #endif

  --- 1251,1257 ----

    EXTERN voidTk_CreateOldPhotoImageFormat _ANSI_ARGS_((

    Tk_PhotoImageFormat *formatPtr));


  ! #if !defined(USE_TK_STUBS) && defined(USE_OLD_IMAGE)

    #define Tk_CreateImageType Tk_CreateOldImageType

    #define Tk_CreatePhotoImageFormat Tk_CreateOldPhotoImageFormat

    #endif

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

  *** 1313,1318 ****

  --- 1312,1325 ----


    #define Tk_InitStubs(interp, version, exact) \

        Tcl_PkgRequire(interp, "Tk", version, exact)

  + 

  + #endif

  + 

  + void Tk_InitImageArgs _ANSI_ARGS_((Tcl_Interp *interp, int argc, char ***argv));

  + 

  + #if !defined(USE_TK_STUBS) || !defined(USE_OLD_IMAGE)

  + 

  + #define Tk_InitImageArgs(interp, argc, argv) /**/


    #endif


  *** generic/tkImgGIF.c.origSun Jan 23 12:31:43 2000

  --- generic/tkImgGIF.cSun Jan 23 12:37:24 2000

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

  *** 78,88 ****

     * The format record for the GIF file format:

     */


  ! static int      FileMatchGIF _ANSI_ARGS_((Tcl_Channel chan, char *fileName,

        Tcl_Obj *format, int *widthPtr, int *heightPtr,

        Tcl_Interp *interp));

    static int      FileReadGIF  _ANSI_ARGS_((Tcl_Interp *interp,

  !     Tcl_Channel chan, char *fileName, Tcl_Obj *format,

        Tk_PhotoHandle imageHandle, int destX, int destY,

        int width, int height, int srcX, int srcY));

    static intStringMatchGIF _ANSI_ARGS_(( Tcl_Obj *dataObj,

  --- 78,88 ----

     * The format record for the GIF file format:

     */


  ! static int      FileMatchGIF _ANSI_ARGS_((Tcl_Channel chan, CONST char *fileName,

        Tcl_Obj *format, int *widthPtr, int *heightPtr,

        Tcl_Interp *interp));

    static int      FileReadGIF  _ANSI_ARGS_((Tcl_Interp *interp,

  !     Tcl_Channel chan, CONST char *fileName, Tcl_Obj *format,

        Tk_PhotoHandle imageHandle, int destX, int destY,

        int width, int height, int srcX, int srcY));

    static intStringMatchGIF _ANSI_ARGS_(( Tcl_Obj *dataObj,

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

  *** 93,106 ****

        int destX, int destY, int width, int height,

        int srcX, int srcY));

    static int FileWriteGIF _ANSI_ARGS_((Tcl_Interp *interp,  

  !     char *filename, Tcl_Obj *format,

        Tk_PhotoImageBlock *blockPtr));

    static intCommonWriteGIF _ANSI_ARGS_((Tcl_Interp *interp,

        Tcl_Channel handle, Tcl_Obj *format,

        Tk_PhotoImageBlock *blockPtr));


    Tk_PhotoImageFormat tkImgFmtGIF = {

  ! "GIF",/* name */

    FileMatchGIF,   /* fileMatchProc */

    StringMatchGIF, /* stringMatchProc */

    FileReadGIF,    /* fileReadProc */

  --- 93,106 ----

        int destX, int destY, int width, int height,

        int srcX, int srcY));

    static int FileWriteGIF _ANSI_ARGS_((Tcl_Interp *interp,  

  !     CONST char *filename, Tcl_Obj *format,

        Tk_PhotoImageBlock *blockPtr));

    static intCommonWriteGIF _ANSI_ARGS_((Tcl_Interp *interp,

        Tcl_Channel handle, Tcl_Obj *format,

        Tk_PhotoImageBlock *blockPtr));


    Tk_PhotoImageFormat tkImgFmtGIF = {

  ! "gif",/* name */

    FileMatchGIF,   /* fileMatchProc */

    StringMatchGIF, /* stringMatchProc */

    FileReadGIF,    /* fileReadProc */

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

  *** 179,185 ****

    static int

    FileMatchGIF(chan, fileName, format, widthPtr, heightPtr, interp)

        Tcl_Channel chan;/* The image file, open for reading. */

  !     char *fileName;/* The name of the image file. */

        Tcl_Obj *format;/* User-specified format object, or NULL. */

        int *widthPtr, *heightPtr;/* The dimensions of the image are

     * returned here if the file is a valid

  --- 179,185 ----

    static int

    FileMatchGIF(chan, fileName, format, widthPtr, heightPtr, interp)

        Tcl_Channel chan;/* The image file, open for reading. */

  !     CONST char *fileName;/* The name of the image file. */

        Tcl_Obj *format;/* User-specified format object, or NULL. */

        int *widthPtr, *heightPtr;/* The dimensions of the image are

     * returned here if the file is a valid

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

  *** 214,220 ****

    width, height, srcX, srcY)

        Tcl_Interp *interp;/* Interpreter to use for reporting errors. */

        Tcl_Channel chan;/* The image file, open for reading. */

  !     char *fileName;/* The name of the image file. */

        Tcl_Obj *format;/* User-specified format object, or NULL. */

        Tk_PhotoHandle imageHandle;/* The photo image to write into. */

        int destX, destY;/* Coordinates of top-left pixel in

  --- 214,220 ----

    width, height, srcX, srcY)

        Tcl_Interp *interp;/* Interpreter to use for reporting errors. */

        Tcl_Channel chan;/* The image file, open for reading. */

  !     CONST char *fileName;/* The name of the image file. */

        Tcl_Obj *format;/* User-specified format object, or NULL. */

        Tk_PhotoHandle imageHandle;/* The photo image to write into. */

        int destX, destY;/* Coordinates of top-left pixel in

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

  *** 1266,1279 ****

    static int

    FileWriteGIF (interp, filename, format, blockPtr)

        Tcl_Interp *interp;/* Interpreter to use for reporting errors. */

  !     char*filename;

        Tcl_Obj*format;

        Tk_PhotoImageBlock *blockPtr;

    {

        Tcl_Channel chan = NULL;

        int result;


  !     chan = Tcl_OpenFileChannel(interp, filename, "w", 0644);

        if (!chan) {

    return TCL_ERROR;

        }

  --- 1266,1279 ----

    static int

    FileWriteGIF (interp, filename, format, blockPtr)

        Tcl_Interp *interp;/* Interpreter to use for reporting errors. */

  !     CONST char*filename;

        Tcl_Obj*format;

        Tk_PhotoImageBlock *blockPtr;

    {

        Tcl_Channel chan = NULL;

        int result;


  !     chan = Tcl_OpenFileChannel(interp, (char *) filename, "w", 0644);

        if (!chan) {

    return TCL_ERROR;

        }

  *** generic/tkImgPhoto.c.origSun Jan 23 12:14:47 2000

  --- generic/tkImgPhoto.cSun Jan 23 12:41:04 2000

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

  *** 371,377 ****

    static voidImgPhotoInstanceSetSize _ANSI_ARGS_((

        PhotoInstance *instancePtr));

    static intImgStringWrite _ANSI_ARGS_((Tcl_Interp *interp,

  !     Tcl_DString *dataPtr, Tcl_Obj *formatString,

        Tk_PhotoImageBlock *blockPtr));

    static char *ImgGetPhoto _ANSI_ARGS_((PhotoMaster *masterPtr,

        Tk_PhotoImageBlock *blockPtr,

  --- 371,377 ----

    static voidImgPhotoInstanceSetSize _ANSI_ARGS_((

        PhotoInstance *instancePtr));

    static intImgStringWrite _ANSI_ARGS_((Tcl_Interp *interp,

  !     Tcl_Obj *formatString,

        Tk_PhotoImageBlock *blockPtr));

    static char *ImgGetPhoto _ANSI_ARGS_((PhotoMaster *masterPtr,

        Tk_PhotoImageBlock *blockPtr,

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

  *** 462,469 ****

        *copyPtr = *formatPtr;

        copyPtr->name = (char *) ckalloc((unsigned) (strlen(formatPtr->name) + 1));

        strcpy(copyPtr->name, formatPtr->name);

  !     copyPtr->nextPtr = tsdPtr->formatList;

  !     tsdPtr->formatList = copyPtr;

    }

    

    /*

  --- 462,474 ----

        *copyPtr = *formatPtr;

        copyPtr->name = (char *) ckalloc((unsigned) (strlen(formatPtr->name) + 1));

        strcpy(copyPtr->name, formatPtr->name);

  !     if (isupper((unsigned char) *formatPtr->name)) {

  ! copyPtr->nextPtr = tsdPtr->oldFormatList;

  ! tsdPtr->oldFormatList = copyPtr;

  !     } else {

  ! copyPtr->nextPtr = tsdPtr->formatList;

  ! tsdPtr->formatList = copyPtr;

  !     }

    }

    

    /*

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

  *** 796,804 ****

    break;

          }

          case PHOTO_DATA: {

  -         Tcl_DString buffer;

    char *data;

  - Tcl_Obj *formatObj;


    /*

     * photo data command - first parse and check any options given.

  --- 801,807 ----

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

  *** 854,872 ****

    }

        }

        if (stringWriteProc == NULL) {

  - oldformat = 1;

  - for (imageFormat = tsdPtr->oldFormatList; imageFormat != NULL;

  -      imageFormat = imageFormat->nextPtr) {

  -     if ((strncasecmp(Tcl_GetString(options.format),

  -     imageFormat->name, strlen(imageFormat->name)) == 0)) {

  - if (imageFormat->stringWriteProc != NULL) {

  -     stringWriteProc = imageFormat->stringWriteProc;

  -     break;

  - }

  -     }

  - }

  -     }

  -     if (stringWriteProc == NULL) {

    Tcl_AppendResult(interp, "image string format \"",

    Tcl_GetString(options.format),

    "\" is not supported", (char *) NULL);

  --- 857,862 ----

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

  *** 882,906 ****

     */


    data = ImgGetPhoto(masterPtr, &block, &options);

  - Tcl_DStringInit(&buffer);


  ! formatObj = options.format;

  ! if (oldformat && formatObj) {

  !     formatObj = (Tcl_Obj *) Tcl_GetString(options.format);

  ! }

  ! result =  stringWriteProc(interp, &buffer,

  ! formatObj, &block);

    if (options.background) {

        Tk_FreeColor(options.background);

    }

    if (data) {

        ckfree(data);

    }

  - if (result == TCL_OK) {

  -     Tcl_DStringResult(interp, &buffer);

  - } else {

  -     Tcl_DStringFree(&buffer);

  - }

    return result;

    break;

          }

  --- 872,887 ----

     */


    data = ImgGetPhoto(masterPtr, &block, &options);


  ! result =  ((int(*) _ANSI_ARGS_((Tcl_Interp *interp, Tcl_Obj *formatString,

  ! Tk_PhotoImageBlock *blockPtr, VOID *dummy))) stringWriteProc)

  ! (interp, options.format, &block, (VOID *) NULL);

    if (options.background) {

        Tk_FreeColor(options.background);

    }

    if (data) {

        ckfree(data);

    }

    return result;

    break;

          }

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

  *** 4882,4890 ****

     */


    static int

  ! ImgStringWrite(interp, dataPtr, formatString, blockPtr)

        Tcl_Interp *interp;

  -     Tcl_DString *dataPtr;

        Tcl_Obj *formatString;

        Tk_PhotoImageBlock *blockPtr;

    {

  --- 4863,4870 ----

     */


    static int

  ! ImgStringWrite(interp, formatString, blockPtr)

        Tcl_Interp *interp;

        Tcl_Obj *formatString;

        Tk_PhotoImageBlock *blockPtr;

    {

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

  *** 4892,4901 ****

  --- 4872,4883 ----

        char *line, *linePtr;

        unsigned char *pixelPtr;

        int greenOffset, blueOffset;

  +     Tcl_DString data;


        greenOffset = blockPtr->offset[1] - blockPtr->offset[0];

        blueOffset = blockPtr->offset[2] - blockPtr->offset[0];


  +     Tcl_DStringInit(&data);

        if ((blockPtr->width > 0) && (blockPtr->height > 0)) {

    line = (char *) ckalloc((unsigned int) ((8 * blockPtr->width) + 2));

    for (row=0; row<blockPtr->height; row++) {

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

  *** 4908,4917 ****

    pixelPtr += blockPtr->pixelSize;

    linePtr += 8;

        }

  !     Tcl_DStringAppendElement(dataPtr, line+1);

    }

    ckfree (line);

        }

        return TCL_OK;

    }

    

  --- 4890,4900 ----

    pixelPtr += blockPtr->pixelSize;

    linePtr += 8;

        }

  !     Tcl_DStringAppendElement(&data, line+1);

    }

    ckfree (line);

        }

  +     Tcl_DStringResult(interp, &data);

        return TCL_OK;

    }

    

  *** generic/tkStubImg.c.origSun Jan 23 10:23:33 2000

  --- generic/tkStubImg.cSun Jan 23 13:39:25 2000

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

  *** 0 ****

  --- 1,74 ----

  + /* 

  +  * tkStubImg.c --

  +  *

  +  *Stub object that will be statically linked into extensions that wish

  +  *to access Tk.

  +  *

  +  * Copyright (c) 1999 Jan Nijtmans.

  +  * Copyright (c) 1998-1999 by Scriptics Corporation.

  +  *

  +  * See the file "license.terms" for information on usage and redistribution

  +  * of this file, and for a DISCLAIMER OF ALL WARRANTIES.

  +  *

  +  * RCS: @(#) $Id: tkStubImg.c,v 1.0 2000/01/03 01:31:06 nijtmans Exp $

  +  */

  + 

  + #include "tcl.h"

  + 

  + 

  + /*

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

  +  *

  +  * Tk_InitImageArgs --

  +  *

  +  *Performs the necessary conversion from Tcl_Obj's to strings

  +  *      in the createProc for Tcl_CreateImageType. If running under

  +  *      Tk 8.2 or earlier without the Img-patch, this function has

  +  *      no effect.

  +  *

  +  * Results:

  +  *argvPtr will point to an argument list which is guaranteed to

  +  *contain strings, no matter what Tk version is running.

  +  *

  +  * Side effects:

  +  *None

  +  *

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

  +  */

  + 

  + #ifdef Tk_InitImageArgs

  + #undef Tk_InitImageArgs

  + #endif

  + 

  + void

  + Tk_InitImageArgs(interp, argc, argvPtr)

  +     Tcl_Interp *interp;

  +     int argc;

  +     char ***argvPtr;

  + {

  +     static useNewImage = -1;

  +     static char **argv = NULL;

  + 

  +     if (argv) {

  + tclStubsPtr->tcl_Free((char *) argv);

  + argv = NULL;

  +     }

  + 

  +     if (useNewImage < 0) {

  + Tcl_CmdInfo cmdInfo;

  + if (!tclStubsPtr->tcl_GetCommandInfo(interp,"image", &cmdInfo)) {

  +     tclStubsPtr->tcl_Panic("cannot find the \"image\" command");

  + }

  + if (cmdInfo.isNativeObjectProc == 1) {

  +     useNewImage = 1; /* Tk uses the new image interface */

  + }

  +     }

  +     if (useNewImage && (argc > 0)) {

  + int i;

  + argv = (char **) tclStubsPtr->tcl_Alloc(argc * sizeof(char *));

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

  +     argv[i] = tclStubsPtr->tcl_GetString((Tcl_Obj *)(*argvPtr)[i]);

  + }

  + *argvPtr = (char **) argv;

  +     }

  + }

  *** generic/tkTest.c.origTue Dec 14 07:52:31 1999

  --- generic/tkTest.cSun Jan 23 10:23:44 2000

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

  *** 16,21 ****

  --- 16,25 ----

     * RCS: @(#) $Id: tkTest.c,v 1.9 1999/12/14 06:52:31 hobbs Exp $

     */


  + #ifdef MAC_TCL

  + #define USE_OLD_IMAGE

  + #endif

  + 

    #include "tkInt.h"

    #include "tkPort.h"

    #include "tkText.h"

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

  *** 61,70 ****

  --- 65,81 ----

     * The type record for test images:

     */


  + #ifdef USE_OLD_IMAGE

  + static intImageCreate _ANSI_ARGS_((Tcl_Interp *interp,

  +     char *name, int argc, char **argv,

  +     Tk_ImageType *typePtr, Tk_ImageMaster master,

  +     ClientData *clientDataPtr));

  + #else

    static intImageCreate _ANSI_ARGS_((Tcl_Interp *interp,

        char *name, int argc, Tcl_Obj *CONST objv[],

        Tk_ImageType *typePtr, Tk_ImageMaster master,

        ClientData *clientDataPtr));

  + #endif

    static ClientDataImageGet _ANSI_ARGS_((Tk_Window tkwin,

        ClientData clientData));

    static voidImageDisplay _ANSI_ARGS_((ClientData clientData,

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

  *** 78,84 ****


    static Tk_ImageType imageType = {

        "test",/* name */

  !     ImageCreate,/* createProc */

        ImageGet,/* getProc */

        ImageDisplay,/* displayProc */

        ImageFree,/* freeProc */

  --- 89,95 ----


    static Tk_ImageType imageType = {

        "test",/* name */

  !     (Tk_ImageCreateProc *) ImageCreate, /* createProc */

        ImageGet,/* getProc */

        ImageDisplay,/* displayProc */

        ImageFree,/* freeProc */

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

  *** 1557,1562 ****

  --- 1568,1608 ----

     */


    /* ARGSUSED */

  + #ifdef USE_OLD_IMAGE

  + static int

  + ImageCreate(interp, name, argc, argv, typePtr, master, clientDataPtr)

  +     Tcl_Interp *interp;/* Interpreter for application containing

  +  * image. */

  +     char *name;/* Name to use for image. */

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

  +     char **argv;/* Argument strings for options (doesn't

  +  * include image name or type). */

  +     Tk_ImageType *typePtr;/* Pointer to our type record (not used). */

  +     Tk_ImageMaster master;/* Token for image, to be used by us in

  +  * later callbacks. */

  +     ClientData *clientDataPtr;/* Store manager's token for image here;

  +  * it will be returned in later callbacks. */

  + {

  +     TImageMaster *timPtr;

  +     char *varName;

  +     int i;

  + 

  +     Tk_InitImageArgs(interp, argc, &argv);

  +     varName = "log";

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

  + if (strcmp(argv[i], "-variable") != 0) {

  +     Tcl_AppendResult(interp, "bad option name \"",

  +     argv[i], "\"", (char *) NULL);

  +     return TCL_ERROR;

  + }

  + if ((i+1) == argc) {

  +     Tcl_AppendResult(interp, "no value given for \"",

  +     argv[i], "\" option", (char *) NULL);

  +     return TCL_ERROR;

  + }

  + varName = argv[i+1];

  +     }

  + #else

    static int

    ImageCreate(interp, name, objc, objv, typePtr, master, clientDataPtr)

        Tcl_Interp *interp;/* Interpreter for application containing

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

  *** 1589,1594 ****

  --- 1635,1641 ----

    }

    varName = Tcl_GetString(objv[i+1]);

        }

  + #endif

        timPtr = (TImageMaster *) ckalloc(sizeof(TImageMaster));

        timPtr->master = master;

        timPtr->interp = interp;

  *** doc/CrtImgType.3.origSun Jan 23 12:42:29 2000

  --- doc/CrtImgType.3Sun Jan 23 13:20:15 2000

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

  *** 8,17 ****

    '\" RCS: @(#) $Id: CrtImgType.3,v 1.3 1999/10/29 03:57:40 hobbs Exp $

    '\" 

    .so man.macros

  ! .TH Tk_CreateImageType 3 8.0 Tk "Tk Library Procedures"

    .BS

    .SH NAME

  ! Tk_CreateImageType, Tk_GetImageMasterData \- define new kind of image

    .SH SYNOPSIS

    .nf

    \fB#include <tk.h>\fR

  --- 8,17 ----

    '\" RCS: @(#) $Id: CrtImgType.3,v 1.3 1999/10/29 03:57:40 hobbs Exp $

    '\" 

    .so man.macros

  ! .TH Tk_CreateImageType 3 8.3 Tk "Tk Library Procedures"

    .BS

    .SH NAME

  ! Tk_CreateImageType, Tk_GetImageMasterData, Tk_InitImageArgs \- define new kind of image

    .SH SYNOPSIS

    .nf

    \fB#include <tk.h>\fR

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

  *** 21,26 ****

  --- 21,28 ----

    .sp

    .VS

    \fBTk_GetImageMasterData\fR(\fIinterp, name, typePtrPtr\fR)

  + .sp

  + \fBTk_InitImageArgs\fR(\fIinterp, argc, argvPtr\fR)

    .SH ARGUMENTS

    .AS Tk_ImageType *typePtrPtr

    .AP Tk_ImageType *typePtr in

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

  *** 34,39 ****

  --- 36,45 ----

    .AP Tk_ImageType **typePtrPtr out

    Points to word in which to store a pointer to type information for

    the given image, if it exists.

  + .AP int argc

  + Number of arguments

  + .AP char ***argvPtr

  + Pointer to argument list

    .VE

    .BE


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

  *** 100,105 ****

  --- 106,121 ----

    If there already existed an image type by this name then

    the new image type replaces the old one.


  + .SH PORTABILITY

  + .PP

  + In Tk 8.2 and earlier, the createProc below had a different

  + signature. If you want to compile an image type using the

  + old interface which should still run on all Tcl/Tk versions,

  + compile it with the flag -DUSE_OLD_IMAGE. Further on, if

  + you are using Stubs, you need to call the function

  + Tk_InitImageArgs(interp, argc, &argv) first in your

  + createProc. See below for a description of this function.

  + 

    .SH CREATEPROC

    \fItypePtr->createProc\fR provides the address of a procedure for

    Tk to call whenever \fBimage create\fR is invoked to create

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

  *** 247,252 ****

  --- 263,280 ----

    pointer to the image master data structure).  If no such image exists

    then NULL is returned and NULL is stored at \fI*typePtrPtr\fR.

    .VE

  + 

  + .SH TK_INITIMAGEARGS

  + .VS

  + .PP

  + The function \fBTk_InitImageArgs\fR converts the arguments of the

  + \fBcreateProc\fR from objects to strings when necessary. When

  + not using stubs, not using the old interface, or running

  + under an older (pre-8.3) Tk version, this function has no

  + effect. This function makes porting older image handlers to

  + the new interface a lot easier: After running this function,

  + the arguments are guaranteed to be in string format, no

  + matter how Tk deliverd them.


    .SH "SEE ALSO"

    Tk_ImageChanged, Tk_GetImage, Tk_FreeImage, Tk_RedrawImage, Tk_SizeOfImage

  *** doc/CrtPhImgFmt.3.origSun Jan 23 12:42:49 2000

  --- doc/CrtPhImgFmt.3Sun Jan 23 13:01:17 2000

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

  *** 12,18 ****

    '\" RCS: @(#) $Id: CrtPhImgFmt.3,v 1.3 1999/10/29 03:57:40 hobbs Exp $

    '\"

    .so man.macros

  ! .TH Tk_CreatePhotoImageFormat 3 4.0 Tk "Tk Library Procedures"

    .BS

    .SH NAME

    Tk_CreatePhotoImageFormat \- define new file format for photo images

  --- 12,18 ----

    '\" RCS: @(#) $Id: CrtPhImgFmt.3,v 1.3 1999/10/29 03:57:40 hobbs Exp $

    '\"

    .so man.macros

  ! .TH Tk_CreatePhotoImageFormat 3 8.3 Tk "Tk Library Procedures"

    .BS

    .SH NAME

    Tk_CreatePhotoImageFormat \- define new file format for photo images

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

  *** 69,74 ****

  --- 69,82 ----

    procedure, and the \fIstringMatchProc\fR procedure if it provides the

    \fIstringReadProc\fR procedure.


  + .SH PORTABILITY

  + .PP

  + In Tk 8.2 and earlier, a different interface was used. Tk 8.3 will

  + still support the old format handlers if the format name is in upper

  + case. If you still want to compile old format handlers with Tk8.3,

  + use the flag -DUSE_OLD_IMAGE. This will restore all function prototypes

  + to match the pre-8.3 situation.

  + 

    .SH NAME

    .PP

    \fIformatPtr->name\fR provides a name for the image type.

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

  *** 76,82 ****

    in the \fB\-format\fR photo image configuration and subcommand option.

    The manual page for the photo image (photo(n)) describes how image

    file formats are chosen based on their names and the value given to

  ! the \fB\-format\fR option.


    .SH FILEMATCHPROC

    \fIformatPtr->fileMatchProc\fR provides the address of a procedure for

  --- 84,92 ----

    in the \fB\-format\fR photo image configuration and subcommand option.

    The manual page for the photo image (photo(n)) describes how image

    file formats are chosen based on their names and the value given to

  ! the \fB\-format\fR option. For new format handlers, the name should

  ! be in lower case. Pre-8.3 format handlers are assumed to be in

  ! upper case.


    .SH FILEMATCHPROC

    \fIformatPtr->fileMatchProc\fR provides the address of a procedure for

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

  *** 86,92 ****

    .CS

    typedef int Tk_ImageFileMatchProc(

    Tcl_Channel \fIchan\fR,

  ! char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    int *\fIwidthPtr\fR,

    int *\fIheightPtr\fR,

  --- 96,102 ----

    .CS

    typedef int Tk_ImageFileMatchProc(

    Tcl_Channel \fIchan\fR,

  ! CONST char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    int *\fIwidthPtr\fR,

    int *\fIheightPtr\fR,

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

  *** 108,120 ****

    \fIformatPtr->stringMatchProc\fR must match the following prototype:

    .CS

    typedef int Tk_ImageStringMatchProc(

  ! char *\fIstring\fR,

    Tcl_Obj *\fIformat\fR,

    int *\fIwidthPtr\fR,

    int *\fIheightPtr\fR,

    Tcl_Interp *\fIinterp\fR);

    .CE

  ! The \fIstring\fR argument points to the string containing the image

    data.  The \fIformat\fR argument contains the value given for

    the \fB\-format\fR option, or NULL if the option was not specified.

    If the data in the string appears to be in the format supported by

  --- 118,130 ----

    \fIformatPtr->stringMatchProc\fR must match the following prototype:

    .CS

    typedef int Tk_ImageStringMatchProc(

  ! Tcl_Obj *\fIdata\fR,

    Tcl_Obj *\fIformat\fR,

    int *\fIwidthPtr\fR,

    int *\fIheightPtr\fR,

    Tcl_Interp *\fIinterp\fR);

    .CE

  ! The \fIdata\fR argument points to the object containing the image

    data.  The \fIformat\fR argument contains the value given for

    the \fB\-format\fR option, or NULL if the option was not specified.

    If the data in the string appears to be in the format supported by

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

  *** 131,137 ****

    typedef int Tk_ImageFileReadProc(

    Tcl_Interp *\fIinterp\fR,

    Tcl_Channel \fIchan\fR,

  ! char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    PhotoHandle \fIimageHandle\fR,

    int \fIdestX\fR, int \fIdestY\fR,

  --- 141,147 ----

    typedef int Tk_ImageFileReadProc(

    Tcl_Interp *\fIinterp\fR,

    Tcl_Channel \fIchan\fR,

  ! CONST char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    PhotoHandle \fIimageHandle\fR,

    int \fIdestX\fR, int \fIdestY\fR,

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

  *** 159,165 ****

    .CS

    typedef int Tk_ImageStringReadProc(

    Tcl_Interp *\fIinterp\fR,

  ! char *\fIstring\fR,

    Tcl_Obj *\fIformat\fR,

    PhotoHandle \fIimageHandle\fR,

    int \fIdestX\fR, int \fIdestY\fR,

  --- 169,175 ----

    .CS

    typedef int Tk_ImageStringReadProc(

    Tcl_Interp *\fIinterp\fR,

  ! Tcl_Obj *\fIdata\fR,

    Tcl_Obj *\fIformat\fR,

    PhotoHandle \fIimageHandle\fR,

    int \fIdestX\fR, int \fIdestY\fR,

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

  *** 168,174 ****

    .CE

    The \fIinterp\fR argument is the interpreter in which the command was

    invoked to read the image; it should be used for reporting errors.

  ! The \fIstring\fR argument points to the image data in string form.

    The \fIformat\fR argument contains the

    value given for the \fB\-format\fR option, or NULL if the option was

    not specified.  The image data in the string, or a subimage of it, is to

  --- 178,184 ----

    .CE

    The \fIinterp\fR argument is the interpreter in which the command was

    invoked to read the image; it should be used for reporting errors.

  ! The \fIdata\fR argument points to the image data in object form.

    The \fIformat\fR argument contains the

    value given for the \fB\-format\fR option, or NULL if the option was

    not specified.  The image data in the string, or a subimage of it, is to

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

  *** 187,193 ****

    .CS

    typedef int Tk_ImageFileWriteProc(

    Tcl_Interp *\fIinterp\fR,

  ! char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    Tk_PhotoImageBlock *\fIblockPtr\fR);

    .CE

  --- 197,203 ----

    .CS

    typedef int Tk_ImageFileWriteProc(

    Tcl_Interp *\fIinterp\fR,

  ! CONST char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    Tk_PhotoImageBlock *\fIblockPtr\fR);

    .CE

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

  *** 212,218 ****

    .CS

    typedef int Tk_ImageStringWriteProc(

    Tcl_Interp *\fIinterp\fR,

  - Tcl_DString *\fIdataPtr\fR,

    Tcl_Obj *\fIformat\fR,

    Tk_PhotoImageBlock *\fIblockPtr\fR);

    .CE

  --- 222,227 ----

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

  *** 221,227 ****

    The image data to be converted are in memory and are described by the

    Tk_PhotoImageBlock structure pointed to by \fIblockPtr\fR; see the

    manual page FindPhoto(3) for details.  The data for the string

  ! should be appended to the dynamic string given by \fIdataPtr\fR.

    The \fIformat\fR argument contains the

    value given for the \fB\-format\fR option, or NULL if the option was

    not specified.  The format string can contain extra characters

  --- 230,236 ----

    The image data to be converted are in memory and are described by the

    Tk_PhotoImageBlock structure pointed to by \fIblockPtr\fR; see the

    manual page FindPhoto(3) for details.  The data for the string

  ! should be put in the interpreter \fIinterp\fR result.

    The \fIformat\fR argument contains the

    value given for the \fB\-format\fR option, or NULL if the option was

    not specified.  T


  PatchFiles:

  Makefile.in (both UNIX and win) makefile.vc tk.h tkImgGIF.c tkImgPhoto.c

      tkTest.c CrtImgType.3 CrtPhImgFmt.3 tkStubImg.c (new file)




  patch applied for 8.3.0 release. 
  -- 02/08/2000 hobbs


tkt_uuid: 220660ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 2
foundin: None
resolution: Fixed
title: Dash-patch functions missing from Stub table
comment:
  OriginalBugID: 4062 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-24'
  LastModified: '2000-02-08'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  FixedDate: '2000-02-08'
  FixedInVersion: 8.3


  Name:

  Jan Nijtmans


  Comments:

  "make genstubs" has to be run in order to make the necessary adations to tkDecls.h as well. Otherwise,

  this patch has no effect.


  ReproducibleScript:

  Up to now, there are no extensions using the functions added by the Dash-patch. Therefore it was

  not crucial to assign stub entries to them, and the declarations where just put in tk.h. However,

  the proper thing to do is move those declarions to tkDecls.h. This patch does exactly that.


  Patch:

  *** generic/tk.decls.origSun Jan 16 20:19:15 2000

  --- generic/tk.declsSun Jan 16 20:39:25 2000

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

  *** 1052,1057 ****

  --- 1052,1126 ----

    #    VOID *Tk_GetCanvasVisitor(Tcl_Interp *interp, CONST char *name)

    #}


  + declare 220 generic {

  +     intTk_GetDash(Tcl_Interp *interp, CONST char *value, Tk_Dash *dash)

  + }

  + declare 221 generic {

  +     void Tk_CreateOutline(Tk_Outline *outline)

  + }

  + declare 222 generic {

  +     void Tk_DeleteOutline(Display *display, Tk_Outline *outline)

  + }

  + declare 223 generic {

  +     int Tk_ConfigOutlineGC(XGCValues *gcValues, Tk_Canvas canvas,

  +     Tk_Item *item, Tk_Outline *outline)

  + }

  + declare 224 generic {

  +     int Tk_ChangeOutlineGC(Tk_Canvas canvas, Tk_Item *item,

  +     Tk_Outline *outline)

  + }

  + declare 225 generic {

  +     int Tk_ResetOutlineGC(Tk_Canvas canvas, Tk_Item *item,

  +     Tk_Outline *outline)

  + }

  + declare 226 generic {

  +     int Tk_CanvasPsOutline(Tk_Canvas canvas,

  +     Tk_Item *item, Tk_Outline *outline)

  + }

  + declare 227 generic {

  +     void Tk_SetTSOrigin(Tk_Window tkwin, GC gc, int x, int y)

  + }

  + declare 228 generic {

  +     int Tk_CanvasGetCoordFromObj(Tcl_Interp *interp, Tk_Canvas canvas,

  +     Tcl_Obj *obj, double *doublePtr)

  + }

  + declare 229 generic {

  +     void Tk_CanvasSetOffset(Tk_Canvas canvas, GC gc, Tk_TSOffset *offset)

  + }

  + declare 230 generic {

  +     void Tk_DitherPhoto(Tk_PhotoHandle handle, int x, int y, int width,

  +     int height)

  + }

  + declare 231 generic {

  +     int Tk_PostscriptBitmap(Tcl_Interp *interp, Tk_Window tkwin,

  +     Tk_PostscriptInfo psInfo, Pixmap bitmap, int startX,

  +     int startY, int width, int height)

  + }

  + declare 232 generic {

  +     int Tk_PostscriptColor(Tcl_Interp *interp, Tk_PostscriptInfo psInfo,

  +     XColor *colorPtr)

  + }

  + declare 233 generic {

  +     int Tk_PostscriptFont(Tcl_Interp *interp, Tk_PostscriptInfo psInfo,

  +     Tk_Font font)

  + }

  + declare 234 generic {

  +     int Tk_PostscriptImage(Tk_Image image, Tcl_Interp *interp,

  +     Tk_Window tkwin, Tk_PostscriptInfo psinfo, int x, int y,

  +     int width, int height, int prepass)

  + }

  + declare 235 generic {

  +     void Tk_PostscriptPath(Tcl_Interp *interp, Tk_PostscriptInfo psInfo,

  +     double *coordPtr, int numPoints)

  + }

  + declare 236 generic {

  +     int Tk_PostscriptStipple(Tcl_Interp *interp, Tk_Window tkwin,

  +     Tk_PostscriptInfo psInfo, Pixmap bitmap)

  + }

  + declare 237 generic {

  +     double Tk_PostscriptY(double y, Tk_PostscriptInfo psInfo)

  + }

  + 

    # Define the platform specific public Tk interface.  These functions are

    # only available on the designated platform.


  *** generic/tk.h.origSun Jan 16 20:19:28 2000

  --- generic/tk.hSun Jan 16 20:35:23 2000

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

  *** 1065,1091 ****

        Pixmap disabledStipple;/* Outline Stipple pattern if state is disabled. */

    } Tk_Outline;


  - /*

  -  * Some functions handy for Dashing and Outlines (in tkCanvUtil.c).

  -  */

  - 

  - EXTERN intTk_GetDash _ANSI_ARGS_((Tcl_Interp *interp,

  -     CONST char *value, Tk_Dash *dash));

  - EXTERN voidTk_CreateOutline _ANSI_ARGS_((Tk_Outline *outline));

  - EXTERN voidTk_DeleteOutline _ANSI_ARGS_((Display *display,

  -     Tk_Outline *outline));

  - EXTERN intTk_ConfigOutlineGC _ANSI_ARGS_((XGCValues *gcValues,

  -     Tk_Canvas canvas ,Tk_Item *item,

  -     Tk_Outline *outline));

  - EXTERN intTk_ChangeOutlineGC _ANSI_ARGS_((Tk_Canvas canvas,

  -     Tk_Item *item, Tk_Outline *outline));

  - EXTERN intTk_ResetOutlineGC _ANSI_ARGS_((Tk_Canvas canvas,

  -     Tk_Item *item, Tk_Outline *outline));

  - EXTERN intTk_CanvasPsOutline _ANSI_ARGS_((Tk_Canvas canvas,

  -     Tk_Item *item, Tk_Outline *outline));

  - EXTERN voidTk_SetTSOrigin _ANSI_ARGS_((Tk_Window tkwin, GC gc, int x,

  -     int y));

  - 

    

    /*

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

  --- 1065,1070 ----

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

  *** 1360,1403 ****

    typedef int (Tk_SelectionProc) _ANSI_ARGS_((ClientData clientData,

    int offset, char *buffer, int maxBytes));

    

  - /*

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

  -  *

  -  * Exported procedures introduced by dash-patch.

  -  *

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

  -  */

  - 

  - EXTERN intTk_CanvasGetCoordFromObj _ANSI_ARGS_((

  -     Tcl_Interp *interp, Tk_Canvas canvas, Tcl_Obj *obj,

  -     double *doublePtr));

  - EXTERN voidTk_CanvasSetOffset _ANSI_ARGS_((

  -     Tk_Canvas canvas, GC gc, Tk_TSOffset *offset));

  - EXTERN voidTk_CreatePhotoOption _ANSI_ARGS_((Tcl_Interp *interp,

  -     CONST char *name, Tcl_ObjCmdProc *proc));

  - EXTERN voidTk_DitherPhoto _ANSI_ARGS_((Tk_PhotoHandle handle,

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

  - EXTERN intTk_PostscriptBitmap _ANSI_ARGS_((Tcl_Interp *interp,

  -     Tk_Window tkwin, Tk_PostscriptInfo psInfo,

  -     Pixmap bitmap, int startX, int startY,

  -     int width, int height));

  - EXTERN intTk_PostscriptColor _ANSI_ARGS_((Tcl_Interp *interp,

  -     Tk_PostscriptInfo psInfo, XColor *colorPtr));

  - EXTERN intTk_PostscriptFont _ANSI_ARGS_((Tcl_Interp *interp,

  -     Tk_PostscriptInfo psInfo, Tk_Font font));

  - EXTERN intTk_PostscriptImage _ANSI_ARGS_((Tk_Image image,

  -     Tcl_Interp *interp, Tk_Window tkwin,

  -     Tk_PostscriptInfo psinfo, int x, int y,

  -     int width, int height, int prepass));

  - EXTERN voidTk_PostscriptPath _ANSI_ARGS_((Tcl_Interp *interp,

  -     Tk_PostscriptInfo psInfo, double *coordPtr,

  -     int numPoints));

  - EXTERN intTk_PostscriptStipple _ANSI_ARGS_((Tcl_Interp *interp,

  -     Tk_Window tkwin, Tk_PostscriptInfo psInfo,

  -     Pixmap bitmap));

  - EXTERN doubleTk_PostscriptY _ANSI_ARGS_((double y,

  -     Tk_PostscriptInfo psInfo));

  - 

    /*

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

     *

  --- 1339,1344 ----


  PatchFiles:

  tk.decls tk.h




  Patch applied for 8.3.0. 
  -- 02/08/2000 hobbs


tkt_uuid: 220661ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: XGetGeometry in tkWinPixmap.c should handle windows as well as bitmaps
comment:
  OriginalBugID: 4069 RFE
  Version: 8.3b2
  SubmitDate: '2000-01-24'
  LastModified: '2000-02-01'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-02-01'
  FixedInVersion: 8.3


  Name:

  Edward Lam


  CustomShell:

  Only added functionality was patched into the XGetGeometry function of the win\tkWinPixmap.c file. This should not affect existing behaviour.


  Comments:

  An added bonus with the way the Windows port is done is that simple X11 tcl/tk applications can be easily ported over to Windows as well with minimal hassle. This is exactly what caused me to patch my version tk. Perhaps an explicit export of the other functions in the Xlib library should be added to the X11 include files. This patch works for tk 8.2.3 and up. I haven't looked at this in the earlier versions.


  DesiredBehavior:

  This allows XGetGeometry to be used in Windows applications that get linked with the Tcl/Tk libraries (when ported from X11).


  Patch:

  *** tkWinPixmap.old.cMon Sep 14 14:24:00 1998

  --- tkWinPixmap.cMon Jan 24 07:52:00 2000

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

  *** 165,184 ****

        TkWinDrawable *twdPtr = (TkWinDrawable *)d;

        HDC dc;

        BITMAPINFO info;


  !     if ((twdPtr->type != TWD_BITMAP) || (twdPtr->bitmap.handle == NULL)) {

  ! panic("XGetGeometry: invalid pixmap");

  !     }

  !     dc = GetDC(NULL);

  !     info.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);

  !     info.bmiHeader.biBitCount = 0;

  !     if (!GetDIBits(dc, twdPtr->bitmap.handle, 0, 0, NULL, &info,

  !     DIB_RGB_COLORS)) {

  ! panic("XGetGeometry: unable to get bitmap size");

  !     }

  !     ReleaseDC(NULL, dc);


  !     *width_return = info.bmiHeader.biWidth;

  !     *height_return = info.bmiHeader.biHeight;

        return 1;

    }

  --- 165,196 ----

        TkWinDrawable *twdPtr = (TkWinDrawable *)d;

        HDC dc;

        BITMAPINFO info;

  +     RECT rect;


  !     if (twdPtr->type == TWD_BITMAP) {

  ! if (twdPtr->bitmap.handle == NULL) {

  !     panic("XGetGeometry: invalid pixmap");

  ! }

  ! dc = GetDC(NULL);

  ! info.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);

  ! info.bmiHeader.biBitCount = 0;

  ! if (!GetDIBits(dc, twdPtr->bitmap.handle, 0, 0, NULL, &info,

  ! DIB_RGB_COLORS)) {

  !     panic("XGetGeometry: unable to get bitmap size");

  ! }

  ! ReleaseDC(NULL, dc);


  ! *width_return = info.bmiHeader.biWidth;

  ! *height_return = info.bmiHeader.biHeight;

  !     } else if (twdPtr->type == TWD_WINDOW) {

  ! if (twdPtr->window.handle == NULL) {

  !     panic("XGetGeometry: invalid window");

  ! }

  ! GetClientRect(twdPtr->window.handle, &rect);

  ! *width_return = rect.right - rect.left;

  ! *height_return = rect.bottom - rect.top;

  !     } else {

  ! panic("XGetGeometry: invalid window");

  !     }

        return 1;

    }


  PatchFiles:

  win/tkWinPixmap.c




  patch applied for 8.3.0. 
  -- 02/01/2000 hobbs


tkt_uuid: 220662ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: Font in Wish and Console unreadable
comment:
  OriginalBugID: 4078 Bug
  Version: 8.2.1
  SubmitDate: '2000-01-24'
  LastModified: '2000-01-24'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: Mac OS 8.6
  Machine: Power Computing Power Center Pro 210
  FixedDate: '2000-01-24'
  FixedInVersion: 8.3b2


  Name:
  Paul Lujan

  CVS:
  1/24/00

  ReproducibleScript:
  The fonts on the Wish and Console windows are almost unreadable. The font in the Shell window is fine. I have tried to 
  change the system fonts, but this does not help.  I have also redownload TCL 8.2.1 to make sure its not corrupted.
  I am opperating using Mac OS 8.6. 

  I have read all the documentation on your web site that may relate to this with no luck 
  Please help.



  There was a problem with font choosing in Mac Tk for 8.2.1 that
  has been fixed in the 8.3b2 source code. 
  -- 01/24/2000 hobbs


tkt_uuid: 220663ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: crash on exit when creating windows in destroy
comment:
  OriginalBugID: 4079 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-24'
  LastModified: '2000-03-06'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-03-06'
  FixedInVersion: 8.3.1


  Name:
  Vince Darley

  ReproducibleScript:
  The problem is Tk_NameToWindow is called with a null tkwin argument.

  Script:
  # Double-click on this script under WindowsNT and
  # select 'quit' from the file menu to show the crash.
  menu .menubar
  menu .menubar.mfile
  menu .menubar.mrecent

  .menubar add cascade -menu .menubar.mfile -label "File"
  .menubar.mfile add cascade -menu .menubar.mrecent -label "Recent"
  .menubar.mfile add command -label "Quit" -command exit
  . configure -menu .menubar
  toplevel .t
  bind Toplevel <Destroy> {menu .menubar.mrecent}

  ObservedBehavior:
  Crash

  Complete call stack:

  Tk_NameToWindow(Tcl_Interp * 0x0015cab0, char * 0x00ced5a0, Tk_Window_ * 0x00000000) line 2113 + 7 bytes
  Tk_CreateWindowFromPath(Tcl_Interp * 0x0015cab0, Tk_Window_ * 0x00000000, char * 0x00d390c0, char * 0x0031e444) line 1045 + 17 bytes
  MenuCmd(int * 0x001ca880, Tcl_Interp * 0x0015cab0, int 2, Tcl_Obj * const * 0x0012f2c8) line 478 + 31 bytes
  EvalObjv(Tcl_Interp * 0x0015cab0, int 2, Tcl_Obj * const * 0x0012f2c8, char * 0x0012f4e0, int 21, int 0) line 932 + 25 bytes
  Tcl_EvalEx(Tcl_Interp * 0x0015cab0, char * 0x0012f4e0, int 21, int 0) line 1393 + 30 bytes
  Tcl_Eval(Tcl_Interp * 0x0015cab0, char * 0x0012f4e0) line 1512 + 17 bytes
  Tcl_GlobalEval(Tcl_Interp * 0x0015cab0, char * 0x0012f4e0) line 4139 + 13 bytes
  Tk_BindEvent(Tk_BindingTable_ * 0x00168ac0, _XEvent * 0x0012f6b0, Tk_Window_ * 0x00d19760, int 0, int * * 0x0012f5f8) line 1789 + 23 bytes
  TkBindEventProc(TkWindow * 0x00d19760, _XEvent * 0x0012f6b0) line 245 + 31 bytes
  Tk_HandleEvent(_XEvent * 0x0012f6b0) line 737 + 13 bytes
  Tk_DestroyWindow(Tk_Window_ * 0x00d19760) line 1237 + 9 bytes
  Tk_DestroyWindow(Tk_Window_ * 0x0016f7d0) line 1180 + 9 bytes
  DeleteWindowsExitProc(int * 0x00000000) line 2552 + 15 bytes
  Tcl_Finalize() line 764 + 12 bytes
  Tcl_Exit(int 0) line 561
  Tcl_ExitObjCmd(int * 0x00000000, Tcl_Interp * 0x0015cab0, int 1, Tcl_Obj * const * 0x00174ae0) line 672 + 9 bytes
  TclExecuteByteCode(Tcl_Interp * 0x0015cab0, ByteCode * 0x00234b20) line 846 + 25 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x0015cab0, Tcl_Obj * 0x00d0c7e8, int 131072) line 2723 + 13 bytes
  TkInvokeMenu(Tcl_Interp * 0x0015cab0, TkMenu * 0x00d19e60, int 2) line 1113 + 27 bytes
  TkWinHandleMenuEvent(HWND__ * * 0x0012fc4c, unsigned int * 0x0012fc50, unsigned int * 0x0012fc54, long * 0x0012fc58, long * 0x0012fc40) line 988 + 23 bytes
  WmProc(HWND__ * 0x00eb0890, unsigned int 273, unsigned int 35, long 0) line 4179 + 25 bytes
  USER32! 77e71268()



  Verified on Solaris7 and NT. 
  -- 01/25/2000 hobbs

  A simpler case:

  ------------------------------------
  bind Toplevel <Destroy> {menu .menu}
  toplevel .t
  exit
  ------------------------------------

  In general, this happens anytime the result from Tk_MainWindow is used without checking for NULL, which includes the creation of most widgets and the creation of photo images.

  I fixed the problem by putting protection against NULL tkwin in Tk_NameToWindow and in Tk_ConfigureWidget (which handles the photo case).  This fix will be in 8.3.1.

  - eric

  -- 03/06/2000 ericm


tkt_uuid: 220664ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: unix/aclocal.m4 is missing
comment:
  OriginalBugID: 4084 Bug
  Version: 8.2
  SubmitDate: '2000-01-25'
  LastModified: '2000-01-25'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-SuSE
  FixedDate: '2000-01-25'
  FixedInVersion: 8.3b2


  Name:
  Reinhard Max

  ObservedBehavior:
  unix/aclocal.m4 seems to be missing in all patchlevels of Tk8.2.
  When I run autoconf I get an unusable configure script.
  I need to edit configure.in to prepare Tck/Tk 8.2 for inclusion into SuSE Linux



  This was corrected in 8.3b2. 
  -- 01/25/2000 hobbs


tkt_uuid: 220665ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: bad scale RoundToResolution numerics
comment:
  OriginalBugID: 4099 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-27'
  LastModified: '2000-01-29'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3689
  OS: All
  FixedDate: '2000-01-29'


  Name:

  Don Porter



  Comments:

  In floating point arithmetic, it may not be true that

      

      (N + 1) * delta == N * delta + delta



  ReproducibleScript:

  # FILE demo.tcl

  pack [scale .s -length 441 -orient horizontal -resolution 0.5050838956 \

  -from 463.667016161 -to 563.67362749 -digits 18]

  .s set 513.7



  ObservedBehavior:

  $ wish demo.tcl



  Wave the mouse over the scale and watch the

  value and the slider "shake".



  DesiredBehavior:

  Scale should hold its value.



  Patch:

  Index: generic/tkScale.c

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

  RCS file: /cvsroot/tk/generic/tkScale.c,v

  retrieving revision 1.10

  diff -c -r1.10 tkScale.c

  *** tkScale.c   1999/12/22 20:01:07     1.10

  --- tkScale.c   2000/01/27 22:41:38

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

  *** 1147,1166 ****

        TkScale *scalePtr;                /* Information about scale widget. */

        double value;             /* Value to round. */

    {

  !     double rem, new;

    

        if (scalePtr->resolution <= 0) {

          return value;

        }

  !     new = scalePtr->resolution * floor(value/scalePtr->resolution);

        rem = value - new;

        if (rem < 0) {

          if (rem <= -scalePtr->resolution/2) {

  !           new -= scalePtr->resolution;

          }

        } else {

          if (rem >= scalePtr->resolution/2) {

  !           new += scalePtr->resolution;

          }

        }

        return new;

  --- 1147,1167 ----

        TkScale *scalePtr;                /* Information about scale widget. */

        double value;             /* Value to round. */

    {

  !     double rem, new, tick;

    

        if (scalePtr->resolution <= 0) {

          return value;

        }

  !     tick = floor(value/scalePtr->resolution);

  !     new = scalePtr->resolution * tick;

        rem = value - new;

        if (rem < 0) {

          if (rem <= -scalePtr->resolution/2) {

  !           new = (tick - 1.0) * scalePtr->resolution;

          }

        } else {

          if (rem >= scalePtr->resolution/2) {

  !           new = (tick + 1.0) * scalePtr->resolution;

          }

        }

        return new;



  PatchFiles:

  generic/tkScale.c





  Patch added to 8.3.0, also fixed resolution rounding bug in 3689. 
  -- 01/29/2000 hobbs


tkt_uuid: 220666ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: image format string should not be threated as binary data
comment:
  OriginalBugID: 4103 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-31'
  LastModified: '2000-01-31'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-01-31'
  FixedInVersion: 8.3


  Name:
  Jan Nijtmans

  CVS:
  29 jan 2000

  Comments:
  Further on: Great work, Eric!!!!

  ReproducibleScript:
  I tested the new 60% faster GIF encoder and the other excellent fixes by
  Eric Melski. Everything works fine. However, before the format string
  is passed to the format handler, it is converted to a ByteArray. The problem
  with that is usually this format string is treated as a list or string later, which
  leads to an unnecessary additional conversion. In all cases, this data should
  be threated as UTF-8, so it is simple wrong (even though it works).
  I guess this slipped in during the attempt to fix the handling of binary
  data for images.

  Patch:
  --- tkImgPhoto.cSat Jan 29 16:56:30 2000
  ***************
  *** 3556,3566 ****
        ThreadSpecificData *tsdPtr = (ThreadSpecificData *) 
                Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));
        char *formatString = NULL;
  -     int len;

        if (formatObj) {
  ! formatString = Tcl_GetByteArrayFromObj(formatObj, &len);
  !     /*Tcl_GetString(formatObj);*/
        }

        /*
  --- 3556,3564 ----
        ThreadSpecificData *tsdPtr = (ThreadSpecificData *) 
                Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));
        char *formatString = NULL;

        if (formatObj) {
  ! formatString = Tcl_GetString(formatObj);
        }

        /*

  PatchFiles:
  tkImgPhoto.c



  Yes, it certainly slipped in as you said when I was working on fixing the binary data handling.  I applied the patch.

  - eric

  -- 01/31/2000 ericm


tkt_uuid: 220667ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: new "-activedash" option doesn't work in all situations
comment:
  OriginalBugID: 4104 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-31'
  LastModified: '2000-02-01'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  FixedDate: '2000-02-01'
  FixedInVersion: 8.3


  Name:

  Jan Nijtmans


  Comments:

  This bug is discovered by Nick Ing-Simmons. Many thanks to him. It

      is caused by a number of tests using '>' which should have been '!='.

      The possibility of dash.number to be negative is added later to

      the dash-patch, and some places in the code have never been

      adapted accordingly.


  ReproducibleScript:

  In the following script, all canvas element are expected to

  turn dashed when the mouse moves over it.


  canvas .c

  .c create line 10 10 100 10 -width 3 -activedash .

  .c create poly 10 20 100 20 55 30 -width 3 -fill {} -outline black -activedash .

  .c create oval 10 40 30 60 -width 3 -fill {} -activedash .

  .c create rect 40 40 60 60 -width 3 -fill {} -activedash .

  .c create arc  50 40 90 80 -width 3 -fill {} -activedash .

  pack .c


  ObservedBehavior:

  Moving the mouse over the elemens has no effect


  DesiredBehavior:

  Elements should turn dashed when moving the mouse over it


  Patch:

  *** generic/tkCanvArc.c.origSun Jan 30 11:24:54 2000

  --- generic/tkCanvArc.cSun Jan 30 13:07:23 2000

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

  *** 482,488 ****

         */


        if (arcPtr->outline.activeWidth > arcPtr->outline.width ||

  !     arcPtr->outline.activeDash.number > 0 ||

        arcPtr->outline.activeColor != NULL ||

        arcPtr->outline.activeStipple != None ||

        arcPtr->activeFillColor != NULL ||

  --- 482,488 ----

         */


        if (arcPtr->outline.activeWidth > arcPtr->outline.width ||

  !     arcPtr->outline.activeDash.number != 0 ||

        arcPtr->outline.activeColor != NULL ||

        arcPtr->outline.activeStipple != None ||

        arcPtr->activeFillColor != NULL ||

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

  *** 842,848 ****

    if (arcPtr->outline.activeWidth>lineWidth) {

        lineWidth = arcPtr->outline.activeWidth;

    }

  ! if (arcPtr->outline.activeDash.number>0) {

        dashnumber = arcPtr->outline.activeDash.number;

    }

    if (arcPtr->activeFillStipple != None) {

  --- 842,848 ----

    if (arcPtr->outline.activeWidth>lineWidth) {

        lineWidth = arcPtr->outline.activeWidth;

    }

  ! if (arcPtr->outline.activeDash.number!=0) {

        dashnumber = arcPtr->outline.activeDash.number;

    }

    if (arcPtr->activeFillStipple != None) {

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

  *** 852,858 ****

    if (arcPtr->outline.disabledWidth>0) {

        lineWidth = arcPtr->outline.disabledWidth;

    }

  ! if (arcPtr->outline.disabledDash.number>0) {

        dashnumber = arcPtr->outline.disabledDash.number;

    }

    if (arcPtr->disabledFillStipple != None) {

  --- 852,858 ----

    if (arcPtr->outline.disabledWidth>0) {

        lineWidth = arcPtr->outline.disabledWidth;

    }

  ! if (arcPtr->outline.disabledDash.number!=0) {

        dashnumber = arcPtr->outline.disabledDash.number;

    }

    if (arcPtr->disabledFillStipple != None) {

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

  *** 931,937 ****

     * the outline is dashed, because then polygons don't work.

     */


  ! if (lineWidth < 1.5 || dashnumber > 0) {

        Tk_CanvasDrawableCoords(canvas, arcPtr->center1[0],

        arcPtr->center1[1], &x1, &y1);

        Tk_CanvasDrawableCoords(canvas, arcPtr->center2[0],

  --- 931,937 ----

     * the outline is dashed, because then polygons don't work.

     */


  ! if (lineWidth < 1.5 || dashnumber != 0) {

        Tk_CanvasDrawableCoords(canvas, arcPtr->center1[0],

        arcPtr->center1[1], &x1, &y1);

        Tk_CanvasDrawableCoords(canvas, arcPtr->center2[0],

  *** generic/tkCanvLine.c.origSun Jan 30 11:25:01 2000

  --- generic/tkCanvLine.cSun Jan 30 11:34:45 2000

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

  *** 514,520 ****

        }


        if (linePtr->outline.activeWidth > linePtr->outline.width ||

  !     linePtr->outline.activeDash.number > 0 ||

        linePtr->outline.activeColor != NULL ||

        linePtr->outline.activeStipple != None) {

    itemPtr->redraw_flags |= TK_ITEM_STATE_DEPENDANT;

  --- 514,520 ----

        }


        if (linePtr->outline.activeWidth > linePtr->outline.width ||

  !     linePtr->outline.activeDash.number != 0 ||

        linePtr->outline.activeColor != NULL ||

        linePtr->outline.activeStipple != None) {

    itemPtr->redraw_flags |= TK_ITEM_STATE_DEPENDANT;

  *** generic/tkCanvPoly.c.origSun Jan 30 11:25:16 2000

  --- generic/tkCanvPoly.cSun Jan 30 11:36:19 2000

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

  *** 464,470 ****

        state = itemPtr->state;


        if (polyPtr->outline.activeWidth > polyPtr->outline.width ||

  !     polyPtr->outline.activeDash.number > 0 ||

        polyPtr->outline.activeColor != NULL ||

        polyPtr->outline.activeStipple != None ||

        polyPtr->activeFillColor != NULL ||

  --- 464,470 ----

        state = itemPtr->state;


        if (polyPtr->outline.activeWidth > polyPtr->outline.width ||

  !     polyPtr->outline.activeDash.number != 0 ||

        polyPtr->outline.activeColor != NULL ||

        polyPtr->outline.activeStipple != None ||

        polyPtr->activeFillColor != NULL ||

  *** generic/tkRectOval.c.origSun Jan 30 11:26:01 2000

  --- generic/tkRectOval.cSun Jan 30 11:37:01 2000

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

  *** 439,445 ****

         */


        if (rectOvalPtr->outline.activeWidth > rectOvalPtr->outline.width ||

  !     rectOvalPtr->outline.activeDash.number > 0 ||

        rectOvalPtr->outline.activeColor != NULL ||

        rectOvalPtr->outline.activeStipple != None ||

        rectOvalPtr->activeFillColor != NULL ||

  --- 439,445 ----

         */


        if (rectOvalPtr->outline.activeWidth > rectOvalPtr->outline.width ||

  !     rectOvalPtr->outline.activeDash.number != 0 ||

        rectOvalPtr->outline.activeColor != NULL ||

        rectOvalPtr->outline.activeStipple != None ||

        rectOvalPtr->activeFillColor != NULL ||


  PatchFiles:

  tkCanvArc.c tkCanvLine.c tkCanvPoly.c tkRectOval.c




  applied to 8.3.0. 
  -- 02/01/2000 hobbs


tkt_uuid: 220668ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: Shifted dead keys on Windows.
comment:
  OriginalBugID: 4105 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-31'
  LastModified: '2000-02-10'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3359
  OS: All Windows
  FixedDate: '2000-02-10'
  FixedInVersion: 8.3


  Name:
  Peter Spjuth

  ObservedBehavior:
  The main bug is that you can't use shifted dead keys on Windows.
  This patch also fixes some other bugs I stumbled upon, including that keyboard lock lamps did not work on Win98.

  Patches and more info can be downloaded from:
  http://www.dtek.chalmers.se/~d1peter/deadkey.zip

  My binaries with the patch applied can be found at:
  http://www.dtek.chalmers.se/~d1peter/tcl.zip



  Patch applied and tested for 8.3.0. 
  -- 02/10/2000 hobbs


tkt_uuid: 220669ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: `winfo cont' crashes due to BadWindow in X_TranslateCoords
comment:
  OriginalBugID: 4106 Bug
  Version: 8.2.1
  SubmitDate: '2000-01-31'
  LastModified: '2000-01-31'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 716
  OS: BSD
  OSVersion: BSD/OS 2.1
  Machine: PII-350/64M/XFree86 vendor release number 3120
  FixedDate: '2000-01-31'
  FixedInVersion: 8.3b1


  Name:
  Jeff Epler

  Comments:
  The window hierarchy changes while Tk_CoordsToWindow is traversing it,
      because the window manager is tearing down the window ".t" and its
      decorations.

      The problem crops up at least on fvwm2 and icewm.  Since it depends on
      the actions of the wm the severity may depend on the one in use.

  ReproducibleScript:
  toplevel .t
  button .t.b -command {
          set px [winfo pointerx .]
          set py [winfo pointery .]
          destroy .t
          if { [winfo cont $px $py] != ".t.b" } {
                  puts "leave"
          }
  } -text {d}
  pack .t.b
  puts {Now invoke the "d" button}

  ObservedBehavior:
  % /tmp/tcl8/bin/wish8.2 ~/2tl.tcl 
  X Error of failed request:  BadWindow (invalid Window parameter)
    Major opcode of failed request:  40 (X_TranslateCoords)
    Resource id in failed request:  0x1c004f9
    Serial number of failed request:  202
    Current serial number in output stream:  202

  GDB produces the following stack trace when breaking on _XError:
  Starting program: /tmp/tcl8/bin/wish8.2 ~/2tl.tcl
  Now invoke the "d" button

  Breakpoint 1, 0xf7721 in _XError ()
  (gdb) where
  #0  0xf7721 in _XError ()
  #1  0xf612a in _XReply ()
  #2  0x101420 in XTranslateCoordinates ()
  #3  0x2996f in Tk_CoordsToWindow (rootX=519, rootY=543, tkwin=0x69c500)
      at ./tkUnixWm.c:3532
  #4  0x68e5 in Tk_WinfoObjCmd (clientData=0x69c500, interp=0x69d000, objc=4, 
      objv=0x6a1014) at ./../generic/tkCmds.c:1279
  #5  0xc03c3 in TclExecuteByteCode ()
  #6  0xa0b25 in Tcl_EvalObjEx ()
  #7  0x2d000 in TkInvokeButton (butPtr=0x749f00) at ./../generic/tkButton.c:1457
  #8  0x2c29a in ButtonWidgetObjCmd (clientData=0x749f00, interp=0x69d000, 
      objc=2, objv=0x6a100c) at ./../generic/tkButton.c:835

  DesiredBehavior:
  No X protocol error.  return value from `winfo' should probably not indicate .t or .t.b



  Already fixed in 8.3b1 with patch from bug 716. 
  -- 01/31/2000 hobbs


tkt_uuid: 220670ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Windows font bug in tk8.2
comment:
  OriginalBugID: 4108 Bug
  Version: 8.2
  SubmitDate: '2000-01-31'
  LastModified: '2000-02-01'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  FixedDate: '2000-02-01'
  FixedInVersion: 8.3


  Name:
  Jeremy Birch

  ReproducibleScript:
  The Windows version of Tk8.2 suffers an access violation when handling
  fonts with long names
  ie the name of the font is greater than 32 characters (my Python application
  that sits on top of Tk wanted
  to use "*lucidatypewriter-medium-*-*-*-*-140*", for instance). The LOGFONT
  datastructure only has a
  32 byte area for putting the font name into, and the GetScreenFont function
  in tkWinFont.c quite happily
  stomps over the back end of the structure, thus causing a failure later on.
  Obviously truncating the font name may
  risk getting the wrong font, but this is generally better than a SEGV!

  I have changed lines 1961-1965 to be as follows:
  count=31; /*max number of real chars allowed here*/
  while (*src != '\0') {
      *dst++ = *src++;
      if(--count==0) break;
  }

  Hope this is the best way.

  DesiredBehavior:
  ok


  Fixed to use a more general:

      /*
       * We can only store up to LF_FACESIZE characters
       */
      if (Tcl_DStringLength(&ds) >= LF_FACESIZE) {
          Tcl_DStringSetLength(&ds, LF_FACESIZE);
      }

  which goes before the platform check, to operate on Win9* as well. 
  -- 02/01/2000 hobbs


tkt_uuid: 220671ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: bug in tk_getOpenFile on WinNT 4.00.138 locks Tk app.
comment:
  OriginalBugID: 4113 Bug
  Version: 8.2.2
  SubmitDate: '2000-02-02'
  LastModified: '2000-02-05'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: Windows NT 4.00.1381
  Machine: PII-450 128M RAM
  FixedDate: '2000-02-05'
  FixedInVersion: 8.3


  Name:
  Richard Ellis

  ReproducibleScript:
  Using notepad, put these lines into a file named testcase.tcl:

  tk_getOpenFile
  button .b -text "Push Me"
  pack .b

  Then save the file and double click on it to run it as most users of Win would.  When the file selector opens, select a file or hit "cancel" (it does not matter).  The wish window will resize to be the single button marked "Push Me" but the app. is deaf to all mouse interaction.

  Running the same script by first loadnig wish, and at the console typing "source testcase.tcl" (assuming you have already "cd'ed" to the correct dir) will open a file selector that when closed does not cause the app. to be deaf to all mouse interaction.

  ObservedBehavior:
  I am writing a Tcl/Tk script under Linux, with the intent of having it execute on WinNT (4.00.1381) using Freewrap as the vehicle to execute it.  Under Linux, it works perfectly  When I wrapped up a test script to check operation under WinNT, the Tk lockup occued after interacting with the tk_getOpenFile dialog on WinNT.  I tested with freewrap (based on 8.2.2) as well as with Tcl/Tk 8.2.2 and 8.3b2 WinNT packages from the Scriptics download area.  All exhibited the identical behaviour.

  For now, the workaround has been to call tk_FDialog directly, avoiding usage of the native WinNT dialog.  The "feel" of the bug is that the win emulation layer is either causing the event loop to fail to begin, or is forgetting to remove a "grab" placed on the mouse for the dialog after the dialog is closed.  It is not caught in an endless loop, as task manager shows 0% cpu utilization for the app. while it is locked up.  Pressing the kill "X" in the title bar cleanly exits the app.

  DesiredBehavior:
  tk_getOpenFIle should not cause the app. to lockup.



  This was fixed for 8.3, where an EnableWindow(hWnd, 1) call was
  required after the call to the native dialog for each native
  dialog type in Windows Tk. 
  -- 02/05/2000 hobbs


tkt_uuid: 220672ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: tk_getOpenFile does not work with a default extension!
comment:
  OriginalBugID: 4117 Bug
  Version: 8.3b2
  SubmitDate: '2000-02-03'
  LastModified: '2000-02-10'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Unix
  FixedDate: '2000-02-10'
  FixedInVersion: 8.3


  Name:

  Mo DeJong



  CVS:

  Today



  Extensions:

  Tcl/Tk from the CVS



  CustomShell:

  NONE



  ReproducibleScript:

  Run this command



  tk_getOpenFile -defaultextension .exe



  In the dialog type "/tmp", this will print

  the following error message with an OK box.



  File "/tmp.exe" does not exist.



  This should have done a cd to the directory! It would have if there

  was no -defaultextension given!



  ObservedBehavior:

  Error is generated!



  DesiredBehavior:

  It should do a CD!



  Patch:

  This patch fixes the problem, it should be

  applied to tk/library/tkfbox.tcl



  Index: tkfbox.tcl

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

  RCS file: /cvsroot/tk/library/tkfbox.tcl,v

  retrieving revision 1.1.4.3

  diff -u -r1.1.4.3 tkfbox.tcl

  --- tkfbox.tcl  1998/11/25 21:16:34     1.1.4.3

  +++ tkfbox.tcl  2000/02/03 00:00:22

  @@ -1155,7 +1155,7 @@

   

       set path [tkFDialog_JoinFile $context $text]

   

  -    if {[file ext $path] == ""} {

  +    if {![file isdirectory $path] && [file ext $path] == ""} {

          set path "$path$defaultext"

       }



  PatchFiles:

  tk/library/tkfbox.tcl





  Good find, and thanks for the patch.  I applied this to the 8.3 final sources.  It's worth saying that on systems that allow multiple "." characters in a filename, the default extension will often not work because of the naievity of [file extension].  For example, if the default extension is .so and I specify "libtcl8.3" in the dialog box, I will get an error that libtcl8.3 does not exist, because [file extension] returns ".3" as the extension.  The test that determines if the extension should be added could be followed (if there already is an extension) by an attempt to find the file with the default extension attached.  I think the whole function would have to be tweaked to deal with this though.

  - eric

  -- 02/07/2000 ericm


tkt_uuid: 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: 220674ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: wm geometry $toplevel +x+y does not work on iconified window
comment:
  OriginalBugID: 4134 Bug
  Version: 8.2.3
  SubmitDate: '2000-02-07'
  LastModified: '2000-02-07'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  FixedDate: '2000-02-07'
  FixedInVersion: 8.3b2


  Name:
  Stefan Jäger

  ReproducibleScript:
  toplevel .t
  wm geometry .t +100+100
  wm iconify .t
  wm geometry .t +200+200
  wm deiconify .t
  wm geometry .t

  ObservedBehavior:
  .t is still at +100+100

  DesiredBehavior:
  .t at +200+200



  This is already fixed for 8.3b2. 
  -- 02/07/2000 hobbs


tkt_uuid: 220675ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: unpredictable segfaults in test suite
comment:
  OriginalBugID: 4153 Bug
  Version: 8.3b2
  SubmitDate: '2000-02-10'
  LastModified: '2000-02-22'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: 5.1
  Machine: Digital Alpha XL 300
  FixedDate: '2000-02-22'
  FixedInVersion: 8.3


  Name:
  Don Porter

  CVS:
  $Id: tkError.c,v 1.2 1998/09/14 18:23:09 stanton Exp $

  Comments:
  I'm using XFree86-3.3.5-1.5.x and fvwm2-2.0.46-12

  ReproducibleScript:
  source ./../tests/defs.tcl
  set tcltest::verbose bps
  set tcltest::testSingleFile false
  source ./../tests/winfo.test
  source ./../tests/winfo.test

  ObservedBehavior:
  When running the Tk test suite (tktest ./../tests/all.tcl),
  tktest sometimes segfaults.  It does not always do so, and it
  does not always do so in the same place.  I've observed
  segfaults in the following places:

  in unixWm-50.6
  in winfo-13.4
  in winfo.test after winfo-13.4
  in xmfbox.test before end of xmfbox-1.1

  I trapped the first of these in a debugger and
  got the following stack trace:

  Program received signal SIGSEGV, Segmentation fault.
  Tk_DeleteErrorHandler (handler=0x120413e00) at ./../generic/tkError.c:195
  (xxgdb) info stack
  #0  Tk_DeleteErrorHandler (handler=0x120413e00) at ./../generic/tkError.c:195
  #1  0x12006d7a0 in Tk_CoordsToWindow (rootX=254, rootY=153, tkwin=0x120356130) at ./tkUnixWm.c:3649
  #2  0x1200f9890 in Tk_WinfoObjCmd (clientData=0x120356130, interp=0x12031f560, objc=4, objv=0x11fffc8c8) at ./../generic/tkCmds.c:1312
  #3  0x120186b6c in EvalObjv (interp=0x12031f560, objc=4, objv=0x11fffc8c8, command=0x12055ffed "winfo containing [expr $x +249] [expr $y +80]]  [winfo containing [expr $x +250] [expr $y +80]]\n", length=45, flags=0) at ./../generic/tclParse.c:932
  #4  0x1201877ec in Tcl_EvalEx (interp=0x12031f560, script=0x12055ffed "winfo containing [expr $x +249] [expr $y +80]]  [winfo containing [expr $x +250] [expr $y +80]]\n", numBytes=45, flags=0) at ./../generic/tclParse.c:1393
  #5  0x12018712c in Tcl_EvalTokens (interp=0x12031f560, tokenPtr=0x11fffcba0, count=1) at ./../generic/tclParse.c:1192
  #6  0x120187748 in Tcl_EvalEx (interp=0x12031f560, script=0x12055fe20 "\n    eval destroy [winfo children .]\n    toplevel .t -width 300 -height 400 -bg orange\n    wm geom .t +0+50\n    frame .t.f -container 1\n    place .t.f -x 150 -y 50\n    tkwait visibility .t.f\n    tople"..., numBytes=557, flags=262144) at ./../generic/tclParse.c:1381
     ....

  DesiredBehavior:
  No crashes in the test suite.



  This was due to the change in Tk_CoordsToWindow with an odd goto
  that could be reached from above or below.  It was fixed for 8.3.0. 
  -- 02/22/2000 hobbs


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


  Name:

  Frank J. Leitner


  Comments:

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

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

      grabs are still to be discovered...


  ReproducibleScript:

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


  ObservedBehavior:

  Stack trace:


  grab failed: window not viewable

      while executing

  "grab -global $w"

      (procedure "tkMbPost" line 107)

      invoked from within

  "tkMbPost $tkPriv(inMenubutton) 785 594"

      invoked from within

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

  tkMbPost $tkPriv(inMenubutton) 785 594

      }

  "

      (command bound to event)


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


  grab failed: window not viewable

      while executing

  "grab -global $tkPriv(postedMb)"

      (procedure "tkMenuButtonDown" line 10)

      invoked from within

  "tkMenuButtonDown .__tk_filedialog.f1.menu.menu

  "

      (command bound to event)


  DesiredBehavior:

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


  Patch:

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

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

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

  *** 350,357 ****

        set tkPriv(tearoff) $tearoff

        if {$tearoff != 0} {

          focus $menu

  !       tkSaveGrabInfo $w

  !       grab -global $w

        }

    }


  --- 350,359 ----

        set tkPriv(tearoff) $tearoff

        if {$tearoff != 0} {

          focus $menu

  !       if {[winfo viewable $w]} {

  !           tkSaveGrabInfo $w

  !           grab -global $w

  !       }

        }

    }


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

  *** 561,567 ****

            return

        }

        $menu postcascade active

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

          grab -global $tkPriv(postedMb)

        } else {

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

  --- 563,569 ----

            return

        }

        $menu postcascade active

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

          grab -global $tkPriv(postedMb)

        } else {

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


  PatchFiles:

  library/menu.tcl




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

  - eric
   
  -- 03/10/2000 ericm


tkt_uuid: 220677ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Fixed
title: tk_chooseDirectory fails to close after browsing the directory tree.
comment:
  OriginalBugID: 4157 Bug
  Version: 8.3
  SubmitDate: '2000-02-11'
  LastModified: '2000-09-07'
  Severity: SER
  Status: Released
  Submitter: sven
  ChangedBy: sven
  OS: All Windows
  FixedDate: '2000-09-07'
  FixedInVersion: 8.4


  When I use tk_choosDirectory on Windows NT, the following steps cause a problem:

  1. Bring up the dialog.
  2. Change the drive and select a directory name.
  3. When I now press the OK button nothing happens.
  4. I have to click on the entry widget to make the OK button work.

  Expected behavior:
  - The dialog should close and return the selected path



  This happened when the user selected the initial directory without selecting anything else and then pressed ok. I changed the involved routine to always return the directory shown in the entry field. This seems to be the expected behavior for Windows NT.  
  -- 03/15/2000 sven


tkt_uuid: 220678ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: Letters "a","m","T" display in incorrect font
comment:
  OriginalBugID: 4168 Bug
  Version: 8.2.1
  SubmitDate: '2000-02-14'
  LastModified: '2000-02-22'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: Mac OS 9, Mac OS 8.5, Mac OS 8.6
  Machine: G4, G3 (blue&White)
  FixedDate: '2000-02-22'
  FixedInVersion: 8.3


  Name:
  David Caldwell

  ReproducibleScript:
  Every TK/TCL app I've run since release 8.1a has had this bug. "Widget Demos", for example, shows this error.

  ObservedBehavior:
  A Picture is worth a 1000 words...
  http://www.indigita.com/david/tk-font-bug.gif
  This shows "Widget Demos" running on my mac. G4, OS 9. I have the exact same problem on my G3 running os 8.5, 8.6, and 9.
  As you can see, many letters are displaying in the wrong font. Also, as shown in the picture, this affects the the menus to. Look at the last Q--Its in the wrong font. Weird...

  DesiredBehavior:
  I expect the letters to show up in the right font. Its almost impossible to read anything the way it is.



  This has already been fixed in the available 8.3.0 mac release. 
  -- 02/22/2000 hobbs


tkt_uuid: 220679ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: wish fails to link
comment:
  OriginalBugID: 4176 Bug
  Version: 8.3
  SubmitDate: '2000-02-14'
  LastModified: '2000-02-25'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  OSVersion: 4.3.3
  Machine: IBM RS/6000 43P Model 150
  FixedDate: '2000-02-25'
  FixedInVersion: 8.3.1


  Name: Dave Marquardt

  Comments:
  AIX can't find libtk8.3.so.  The AIX linker "ld" doesn't understand how
      to find .so files, just .a files.  So
      libtk8.3.so file needs to be specified directly on the command line, or
      the command line needs to include

      -bI:/usr/local/src/tk8.3.0/unix/lib.exp

      which will also find the libtk8.3.so file.

  ReproducibleScript:
  wish fails to link.  I ran

  ./configure --enable-shared
  make

  ObservedBehavior:
  wish fails to link.  Here's the output from make:

          cc  tkAppInit.o  -L/usr/local/src/tk8.3.0/unix -ltk8.3  -L/usr/local/src/tcl8.3.0/unix   -lX11 -ldl -bI:/usr/local/src/tcl8.3.0/unix/lib.exp -lm -lc -L/usr/local/lib -o wish
  ld: 0706-006 Cannot find or open library file: -l tk8.3
          ld:open(): A file or directory in the path name does not exist.
  make: 1254-004 The error code from the last command is 255.

  Stop.

  DesiredBehavior:
  I expect wish to link correctly.



  The problem was that the TCL_NEEDS_EXP_FILE in aclocal.m4 got
  set to 0 when it should be 1 by default.  This is fixed for 8.3.1. 
  -- 02/25/2000 hobbs


tkt_uuid: 220680ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Fixed
title: UNIX tk_chooseDirectory uses incorrect syntax for -mustexist
comment:
  OriginalBugID: 4182 Bug
  Version: 8.3
  SubmitDate: '2000-02-15'
  LastModified: '2000-02-15'
  Severity: MED
  Status: Released
  Submitter: ericm
  ChangedBy: ericm
  OS: All Unix
  FixedDate: '2000-02-15'


  On Windows, tk_chooseDirectory allows the specification of the -mustexist parameter, which requires that a boolean value be specified (ie, "-mustexist true" or "-mustexist false").  The documentation for the command confirms this behavior.

  On UNIX, -mustexist is treated as a flag, so its absence is equivalent to "-mustexist false" on Windows, and its presence is equivalent to "-mustexist true" on Windows.

  The UNIX implementation, therefore, is incompatible with the Windows implementation.  Because the Windows implementation is a native widget and cannot be changed, the UNIX implementation should be corrected to use the same syntax.

  A workaround is to wrap the call to tk_chooseDirectory with a platform dependancy check:

  if { $::tcl_platform(platform) == "windows" } {
  tk_chooseDirectory -mustexist true -intialdir ...
  } else {
  tk_chooseDirectory -mustexist -initialdir ...
  }

  Note that "-mustexist false" is assumed by both implementations if nothing is specified, so if the usage does not require -mustexist to be true, then it is adequate to simply omit the flag.  This will work across platforms.

  - eric



  This is fixed in the CVS repository.  The UNIX implementation was altered to handle -mustexist the same way it is handled on Windows.

  - eric


tkt_uuid: 220681ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: tk_getSaveFile causes wish app to become unresponsive under win98
comment:
  OriginalBugID: 4190 Bug
  Version: 8.2.3
  SubmitDate: '2000-02-16'
  LastModified: '2000-02-22'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  OSVersion: Windows 98 with update applied
  Machine: winbook xl
  FixedDate: '2000-02-22'
  FixedInVersion: 8.3


  Name: Devin Eyre

  Comments:
  If you encase tk_getSaveFile in a proc, the problem does not occur.

  ReproducibleScript:
  #!/usr/local/bin/wish
  if {[info exists argv0] && [file dir $argv0] != "."} {
     cd [file dir $argv0]
  }
  set pwd [pwd]
  frame .e
  if [file exists [file join $pwd data]] {
     set dir [file join $pwd data]
  } else {
     set dir $pwd
  }
  set file [tk_getSaveFile -initialdir $dir -defaultextension .dat -filetypes {{{Data files} {.dat}} {{Graph files} {.grf}}} -title "Choose a file to save"]
  if {[info exists file]} {
     set f [open $file w]
     foreach indx [array names pft] {
        puts $f "set pft($indx) $pft($indx)"
     }
     close $f
  }
  set now [clock seconds]
  set datetime [clock format $now -format "%m/%d/%Y 7:00%p"]
  entry .e.time -textvariable datetime -width 18
  entry .e.1 -textvariable attempt(1) -width 3
  entry .e.2 -textvariable attempt(2) -width 3
  entry .e.3 -textvariable attempt(3) -width 3 
  button .e.enter -text Enter -command {
  }
  pack .e -side top -fill both
  grid .e.time .e.1 .e.2 .e.3 .e.enter -sticky news
  focus .e.1
  #####end of script##########
  Run by double-clicking on file icon.  (note:  tcl8.2.3 is only version installed on this system)
  If wish is started first, and then the script is sourced, no problem occurs.
  Script runs fine under sparc solaris 2.6

  ObservedBehavior:
  After the tk_getSaveFile is run, widgets do not respond, no cursor is visible anywhere.
  It appears that focus grab isn't released.

  DesiredBehavior:
  The entry cursor should be in .e.1, button should respond to mouse event.



  This has already been fixed in 8.3.0. 
  -- 02/22/2000 hobbs


tkt_uuid: 220682ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Scale widget consumes CPU
comment:
  OriginalBugID: 4191 Bug
  Version: 8.3
  SubmitDate: '2000-02-16'
  LastModified: '2000-04-14'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  Machine: Compaq Deskpro, 200 MHz Pentium Pro
  FixedDate: '2000-04-14'
  FixedInVersion: 8.3.1


  Name:
  Ryan Telkamp

  ReproducibleScript:
  I'm running a CompaQ 200+ MHz Pentium Pro with 64 Mb memory and running Win NT 4.0 Patch 3.  I've tried the following code on TCL/TK rev 8.0.5 and now with 8.3 with the same results from Wish.

  % set x [scale .ra -from 0  -to 360  -length 200  -orient horizontal  -tickinterval 0.1  -showvalue false  -resolution 0.1  -variable scale_val   -command "puts stdout "]
  .ra
  % pack .ra

  ObservedBehavior:
  Whenever the cursor moves into the slider area CPU utilization jumps to 90-100 % utilization for 3-5 seconds, then slowly reduces back to 0 (when the cursor is still).  Responsiveness of the slider bar is very slow (2-3 seconds to acknoledge selection).

  Other TCL/TK apps that I've written, none of which used a scale directive, exhibit this.  Even when I have multiple levels of bindings.

  DesiredBehavior:
  Performance and CPU utilization similar to a scrollbar.



  The problem seems to be related to -tickinterval solely, and it
  can also screw up on Unix somewhat.  Also have to check into the
  problem that the scale command gets called too often on Motion. 
  -- 04/09/2000 hobbs
  This was due to an overagressive use of the configure method
  in the Motion event (calling tkScaleActivate).  This has been
  fixed for 8.3.1.  This only affected the scale widget. 
  -- 04/14/2000 hobbs


tkt_uuid: 220683ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 34. [tk_chooseColor]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: The tk_chooseColor fails with an invalid -initialcolor on NT
comment:
  OriginalBugID: 4198 RFE
  Version: 8.3
  SubmitDate: '2000-02-17'
  LastModified: '2000-03-31'
  Severity: LOW
  Status: Released
  Submitter: sven
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-03-31'
  FixedInVersion: 8.3.1


  On Unix an invalid -initialcolor (like "") is ignored, while on NT the procedure call returns an error.

  Expected behavior:
  I would expect that the invalid color is just ignored.



  Actually, the failure was that -initialcolor "" didn't complain
  on Unix (-initialcolor bogus does).  It's been fixed to complain
  correctly on Unix as well. 
  -- 03/31/2000 hobbs


tkt_uuid: 220684ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Segmentation fault in Tk_CanvasEventuallyRedraw
comment:
  OriginalBugID: 4202 Bug
  Version: 8.3
  SubmitDate: '2000-02-18'
  LastModified: '2000-04-13'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Linux-Red Hat
  OSVersion: Linux mitw.chipworks.com 2.2.5-15 #1 Mon Apr 19 23:00:46 EDT 199
  Machine: Intel PC clone
  FixedDate: '2000-04-13'
  FixedInVersion: 8.3.1


  Name:

  David F. Skoll


  Extensions:

  None


  CustomShell:

  Added new image type and canvas item type.


  ReproducibleScript:

  I am unable to show you how to reproduce the problem.  We have a 100 000-line proprietary C++ program with our own Image type, which worked fine with all versions of Tcl/Tk from 8.0 to 8.2.2.  However, we are sometimes getting crashes with 8.3.0.  It seems that when we destroy a canvas and an image in the canvas in the wrong order, Tk_CanvasEventuallyRedraw gets called with a null "tkwin" member in Canvas.  The enclosed patch fixes it.  I'm sorry that I'm unable to give your more data on what causes the problem -- it's very frustrating for you, I'm sure.


  Patch:

  *** tk8.3.0/generic/tkCanvas.c  Wed Jan 12 06:45:02 2000

  --- tk8.3.0-modified/generic/tkCanvas.c Fri Feb 18 12:03:29 2000

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

  *** 2566,2571 ****

  --- 2566,2574 ----

                                   * Pixels on edge are not redrawn. */

    {

        TkCanvas *canvasPtr = (TkCanvas *) canvas;

  +     if (!canvasPtr->tkwin) {

  +       return;

  +     }

        if ((x1 >= x2) || (y1 >= y2) ||

              (x2 < canvasPtr->xOrigin) || (y2 < canvasPtr->yOrigin) ||

              (x1 >= canvasPtr->xOrigin + Tk_Width(canvasPtr->tkwin)) ||


  PatchFiles:

  generic/tkCanvas.c




  Your patch looks OK, but I'd like to try to find out what the root cause of the problem is, ie, why is Tk_CanvasEventuallyRedraw getting called in the first place?

  Can you tell us what the "wrong order" is?  Do you have to destroy the canvas first, and then the image, or vice versa?  Does this only happen with your new image type?  If so, can you send the source for the image type?

  Thanks,

  - eric

  -- 04/10/2000 ericm

  I applied this patch; the fix will go out with 8.3.1.  However, I am still concerned that this is not the best fix for the problem.  What it comes down to is that this patch, though it fixes this particular problem, only addresses the "what" of the bug, not the "why".  It does not provide us with any understanding, really, of why this behavior is occuring.  Because of this, it doesn't really help us to avoid problems like this in the future. 

  There are practical reasons to search for other fixes as well.  What if what's really going on is that the image handler is mistakenly calling Tk_CanvasEventuallyRedraw?  This fix will prevent the core dump, but it will not stop the image handler from calling Tk_CanvasEventuallyRedraw, which may happen many many times.

  Also, checks like this one penalize the nominal case (tkwin != NULL) in order to handle the exceptional case (tkwin == NULL).  It would be better, in my opinion, to prevent the call to Tk_CanvasEventuallyRedraw in the first place.

  Because of the brevity of information provided here, we are unable to make a more complete diagnosis of the problem, unfortunately.

  - eric

  -- 04/13/2000 ericm


tkt_uuid: 220685ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Destroying listbox crashes wish
comment:
  OriginalBugID: 4207 Bug
  Version: 8.3
  SubmitDate: '2000-02-22'
  LastModified: '2000-03-02'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4218
  OS: All
  FixedDate: '2000-03-02'
  FixedInVersion: 8.3.1


  Name: Andreas Gustafsson

  ReproducibleScript:
  listbox .l
  .l configure -cursor crosshair
  destroy .

  ObservedBehavior:
  Segmentation fault (core dumped)

  Program received signal SIGSEGV, Segmentation fault.
  0x48087653 in FreeResources (optionPtr=0x80c3470, objPtr=0x0, internalPtr=0x8076cb0 "\b", tkwin=0x0)
      at ./../generic/tkConfig.c:1597
  (gdb) where
  #0  0x48087653 in FreeResources (optionPtr=0x80c3470, objPtr=0x0, internalPtr=0x8076cb0 "\b", tkwin=0x0)
      at ./../generic/tkConfig.c:1597
  #1  0x48087455 in Tk_FreeConfigOptions (recordPtr=0x8076c00 "", optionTable=0x80c3400, tkwin=0x0)
      at ./../generic/tkConfig.c:1500
  #2  0x480cc3f9 in DestroyListbox (memPtr=0x8076c00 "") at ./../generic/tkListbox.c:1449
  #3  0x481c441d in Tcl_EventuallyFree (clientData=0x8076c00, freeProc=0x480cc2f0 <DestroyListbox>)
      at ./../generic/tclPreserve.c:313
  #4  0x480cd8f4 in ListboxEventProc (clientData=0x8076c00, eventPtr=0xefbfd248) at ./../generic/tkListbox.c:2365
  #5  0x48089fe6 in Tk_HandleEvent (eventPtr=0xefbfd248) at ./../generic/tkEvent.c:722
  #6  0x480a6b99 in Tk_DestroyWindow (tkwin=0x8076100) at ./../generic/tkWindow.c:1237
  #7  0x480a6ac7 in Tk_DestroyWindow (tkwin=0x804d900) at ./../generic/tkWindow.c:1180
  #8  0x48082d19 in Tk_DestroyObjCmd (clientData=0x804d900, interp=0x804e000, objc=2, objv=0xefbfd3f0)
      at ./../generic/tkCmds.c:420
  #9  0x481bc3f1 in EvalObjv (interp=0x804e000, objc=2, objv=0xefbfd3f0, command=0x8052cea "destroy .\n\n\n",
      length=12, flags=0) at ./../generic/tclParse.c:932
  #10 0x481bcc7c in Tcl_EvalEx (interp=0x804e000,
      script=0x8052cc0 "listbox .l\n.l configure -cursor crosshair\ndestroy .\n\n\n", numBytes=54, flags=0)
      at ./../generic/tclParse.c:1393
  #11 0x481b1a5b in Tcl_EvalFile (interp=0x804e000, fileName=0xefbfd83c "/x/itcl/crash3.tcl")
      at ./../generic/tclIOUtil.c:323
  #12 0x48099127 in Tk_MainEx (argc=1, argv=0xefbfd99c, appInitProc=0x8048a04 <Tcl_AppInit>, interp=0x804e000)
      at ./../generic/tkMain.c:231
  #13 0x80489f2 in main (argc=2, argv=0xefbfd998) at ./tkAppInit.c:77
  #14 0x80487b5 in ___start ()

  DesiredBehavior:
  Successful destruction of the window.



  Was due to ill handling of tkwin being set to NULL.  This is fixed
  for 8.3.1.  The work-around is to unconfig the cursor before
  destroying the listbox. 
  -- 03/02/2000 hobbs


tkt_uuid: 220686ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 59. [tk_focus*]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Improper use of uplevel
comment:
  OriginalBugID: 4208 Bug
  Version: 8.3
  SubmitDate: '2000-02-22'
  LastModified: '2000-02-25'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-SuSE
  FixedDate: '2000-02-25'
  FixedInVersion: 8.3.1


  Name:

  Csaba Nemethi



  ReproducibleScript:

  In the patch contained in the bug report 3943 ("Improper use of after,

  eval, and uplevel") I unfortunately forgot to include a line from the

  Tk library file focus.tcl (although this file was present in the list

  of the affected files).  Consider the following script. in which the

  widget name ".e 2" intentionally contains a space (according to the

  Tcl man page, this is allowed):



      entry .e1

      entry ".e 2" -takefocus p

      proc p w {return ""}

      pack .e1 ".e 2"



  ObservedBehavior:

  When traversing to the second entry with Tab, the following error

  message is displayed:



      called "p" with too many arguments

          while executing

      "p .e 2"

          ("uplevel" body line 1)

          invoked from within

      "uplevel #0 $value $w"

          (procedure "tkFocusOK" line 9)

          invoked from within

      "tkFocusOK $cur"

          (procedure "tk_focusNext" line 36)

          invoked from within

      "tk_focusNext .e1"

          invoked from within

      "tkTabToWindow [tk_focusNext .e1]"

          (command bound to event)



  The error occurs because uplevel concatenates its arguments, therefore

  tkFocusOK are passed the arguments ".e" and "2" instead of the single

  argument ".e 2".



  DesiredBehavior:

  The invocation of uplevel should make use of the list command, in order

  to work for widget names containing spaces or other special characters.



  Patch:

  *** focus.tcl.OLD       Thu Sep  2 19:02:52 1999

  --- focus.tcl.NEW       Sun Dec 26 18:40:17 1999

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

  *** 136,142 ****

          } elseif {$value == 1} {

              return [winfo viewable $w]

          } else {

  !           set value [uplevel #0 $value $w]

              if {[string compare $value ""]} {

                  return $value

              }

  --- 136,142 ----

          } elseif {$value == 1} {

              return [winfo viewable $w]

          } else {

  !           set value [uplevel #0 $value [list $w]]

              if {[string compare $value ""]} {

                  return $value

              }



  PatchFiles:

  focus.tcl





  Fixed as noted for 8.3.1. 
  -- 02/25/2000 hobbs


tkt_uuid: 220687ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 5 Medium
foundin: obsolete: 8.1a2
resolution: Fixed
title: make process fails on tkImgGIF.c
comment:
  OriginalBugID: 4223 Bug
  Version: 8.3
  SubmitDate: '2000-02-22'
  LastModified: '2000-03-30'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: HP-UX
  FixedDate: '2000-03-30'
  FixedInVersion: 8.3.1


  Name:
  John McNeill

  CVS:
  2/21/00: tk8.3.0.tar(.gz)

  ReproducibleScript:
  Executed standard configure and attempted  a standard make.  Got errors shown in following panel.

  ObservedBehavior:
  cc -c -O  +z  -I. -I./../generic  -I./../bitmaps -I/opt/tcl8.3.0/generic   -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1       -DTCL_NO_DEPRECATED   ./../generic/tkImgGIF.c
  cc: "../generic/tkImgGIF.c", line 776: warning 5: "const" will become a keyword.
  cc: "../generic/tkImgGIF.c", line 776: error 1000: Unexpected symbol: "static".
  cc: "../generic/tkImgGIF.c", line 777: warning 5: "const" will become a keyword.
  cc: "../generic/tkImgGIF.c", line 777: error 1000: Unexpected symbol: "static".
  cc: "../generic/tkImgGIF.c", line 788: error 1588: "initialCodeSize" undefined.
  cc: "../generic/tkImgGIF.c", line 800: error 1588: "pixelPtr" undefined.
  cc: "../generic/tkImgGIF.c", line 800: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 809: error 1527: Incompatible types in cast: Must cast from scalar to scalar or to void type.
  cc: "../generic/tkImgGIF.c", line 811: error 1527: Incompatible types in cast: Must cast from scalar to scalar or to void type.
  cc: "../generic/tkImgGIF.c", line 818: error 1588: "i" undefined.
  cc: "../generic/tkImgGIF.c", line 818: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 818: error 1566: Test expression in for must be scalar.
  cc: "../generic/tkImgGIF.c", line 818: error 1560: Modifiable lvalue required with operator "++".
  cc: "../generic/tkImgGIF.c", line 818: error 1561: Increment and decrement operators take scalar operand.
  cc: "../generic/tkImgGIF.c", line 819: error 1528: Subscript expression must combine pointer and integer.
  cc: "../generic/tkImgGIF.c", line 819: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 826: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 826: error 1588: "ypos" undefined.
  cc: "../generic/tkImgGIF.c", line 826: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 826: error 1566: Test expression in for must be scalar.
  cc: "../generic/tkImgGIF.c", line 826: error 1560: Modifiable lvalue required with operator "++".
  cc: "../generic/tkImgGIF.c", line 826: error 1561: Increment and decrement operators take scalar operand.
  cc: "../generic/tkImgGIF.c", line 827: error 1588: "xpos" undefined.
  cc: "../generic/tkImgGIF.c", line 827: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 827: error 1566: Test expression in for must be scalar.
  cc: "../generic/tkImgGIF.c", line 922: error 1588: "v" undefined.
  cc: "../generic/tkImgGIF.c", line 922: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 923: error 1563: Expression in if must be scalar.
  cc: "../generic/tkImgGIF.c", line 932: error 1560: Modifiable lvalue required with operator "++".
  cc: "../generic/tkImgGIF.c", line 932: error 1561: Increment and decrement operators take scalar operand.
  cc: "../generic/tkImgGIF.c", line 932: error 1554: Indirection must be through a pointer.
  cc: "../generic/tkImgGIF.c", line 932: error 1528: Subscript expression must combine pointer and integer.
  cc: "../generic/tkImgGIF.c", line 932: error 1528: Subscript expression must combine pointer and integer.
  cc: "../generic/tkImgGIF.c", line 932: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 933: error 1560: Modifiable lvalue required with operator "++".
  cc: "../generic/tkImgGIF.c", line 933: error 1561: Increment and decrement operators take scalar operand.
  cc: "../generic/tkImgGIF.c", line 933: error 1554: Indirection must be through a pointer.
  cc: "../generic/tkImgGIF.c", line 933: error 1528: Subscript expression must combine pointer and integer.
  cc: "../generic/tkImgGIF.c", line 933: error 1528: Subscript expression must combine pointer and integer.
  cc: "../generic/tkImgGIF.c", line 933: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 934: error 1560: Modifiable lvalue required with operator "++".
  cc: "../generic/tkImgGIF.c", line 934: error 1561: Increment and decrement operators take scalar operand.
  cc: "../generic/tkImgGIF.c", line 934: error 1554: Indirection must be through a pointer.
  cc: "../generic/tkImgGIF.c", line 934: error 1528: Subscript expression must combine pointer and integer.
  cc: "../generic/tkImgGIF.c", line 934: error 1528: Subscript expression must combine pointer and integer.
  cc: "../generic/tkImgGIF.c", line 934: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 936: error 1560: Modifiable lvalue required with operator "++".
  cc: "../generic/tkImgGIF.c", line 936: error 1561: Increment and decrement operators take scalar operand.
  cc: "../generic/tkImgGIF.c", line 936: error 1554: Indirection must be through a pointer.
  cc: "../generic/tkImgGIF.c", line 936: error 1528: Subscript expression must combine pointer and integer.
  cc: "../generic/tkImgGIF.c", line 936: error 1528: Subscript expression must combine pointer and integer.
  cc: "../generic/tkImgGIF.c", line 936: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 938: error 1560: Modifiable lvalue required with operator "++".
  cc: "../generic/tkImgGIF.c", line 938: error 1561: Increment and decrement operators take scalar operand.
  cc: "../generic/tkImgGIF.c", line 944: error 1588: "interlaceStep" undefined.
  cc: "../generic/tkImgGIF.c", line 944: error 1588: "pass" undefined.
  cc: "../generic/tkImgGIF.c", line 944: error 1528: Subscript expression must combine pointer and integer.
  cc: "../generic/tkImgGIF.c", line 944: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 945: error 1564: Expression in while must be scalar.
  cc: "../generic/tkImgGIF.c", line 946: error 1560: Modifiable lvalue required with operator "++".
  cc: "../generic/tkImgGIF.c", line 946: error 1561: Increment and decrement operators take scalar operand.
  cc: "../generic/tkImgGIF.c", line 947: error 1563: Expression in if must be scalar.
  cc: "../generic/tkImgGIF.c", line 950: error 1528: Subscript expression must combine pointer and integer.
  cc: "../generic/tkImgGIF.c", line 950: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 953: error 1560: Modifiable lvalue required with operator "++".
  cc: "../generic/tkImgGIF.c", line 953: error 1561: Increment and decrement operators take scalar operand.
  cc: "../generic/tkImgGIF.c", line 955: error 1549: Modifiable lvalue required for assignment operator.
  cc: "../generic/tkImgGIF.c", line 1688: warning 5: "const" will become a keyword.
  cc: "../generic/tkImgGIF.c", line 1688: error 1000: Unexpected symbol: "char".
  cc: "../generic/tkImgGIF.c", line 1702: error 1701: Unsigned suffix is an  ANSI feature.
  *** Error exit code 1

  DesiredBehavior:
  no errors



  Looks like some ANSI specific stuff got into tkImgGIF.c.  I recommend
  never using HP's default (broken) cc anyway, but instead to use gcc.
  We're likely to require an ANSI compatible C compiler in the future
  (I believe -Aa and -Ae can be added for cc on HP10). 
  -- 02/22/2000 hobbs

  As Jeff suspected, there was a handle of ANSI specific bits spread throughout tkImgGIF.c (for example, using "const" instead of "CONST", which is defined during preprocessing to be either "" or "const" depending on the ANSI compatibility of your compiler).  I fixed these and no longer get the errors you show when I compile on HP-UX 10.20.  This fix will go out with 8.3.1, and is checked into our CVS repository now.

  - eric

  -- 03/30/2000 ericm


tkt_uuid: 220688ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Makefile build run fails if Tcl test was not compiled
comment:
  OriginalBugID: 4237 Bug
  Version: 8.3
  SubmitDate: '2000-02-23'
  LastModified: '2000-03-30'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Linux
  Machine: Black
  FixedDate: '2000-03-30'
  FixedInVersion: 8.3.1


  Name:
  mo

  ReproducibleScript:
  If you run the "make runtest" rule in the Tk build directory
  without running the "make runtest" rule in the Tcl directory,
  you will get an error because the Tcl test .o files can not
  be found.

  ObservedBehavior:
  The "make runtest" rule fails.

  DesiredBehavior:
  I would like it to not fail.

  Patch:
  Index: unix/Makefile.in
  ===================================================================
  RCS file: /cvsroot/tk/unix/Makefile.in,v
  retrieving revision 1.41
  diff -u -r1.41 Makefile.in
  --- Makefile.in 2000/02/14 22:43:32     1.41
  +++ Makefile.in 2000/02/23 21:44:40
  @@ -384,7 +384,13 @@
                  @TK_BUILD_LIB_SPEC@  $(WISH_LIBS) $(TK_CC_SEARCH_FLAGS) -o wish

  -tktest: $(TKTEST_OBJS) $(TK_LIB_FILE)
  +# This rule is executed if the user tried to run tktest without first
  +# building tcltest in the Tcl bin directory. Just do it for them.
  +${TCL_BIN_DIR}/tcltest:
  +       cd ${TCL_BIN_DIR} ;  +       make tcltest
  +
  +tktest: ${TCL_BIN_DIR}/tcltest $(TKTEST_OBJS) $(TK_LIB_FILE)
          ${CC} @LDFLAGS@ $(TKTEST_OBJS)  @TK_BUILD_LIB_SPEC@  $(WISH_LIBS) $(TK_CC_SEARCH_FLAGS) -o tktest
  @@ -409,7 +415,7 @@
          ./tktest $(TOP_DIR)/tests/all.tcl -geometry +0+0 $(TCLTESTARGS)

   # Useful target to launch a built tktest with the proper path,...
  -runtest:
  +runtest: tktest
          LD_LIBRARY_PATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH};  export LD_LIBRARY_PATH;  LIBPATH=`pwd`:${TCL_BIN_DIR}:${LIBPATH}; export LIBPATH;  Index: unix/configure.in
  ===================================================================
  RCS file: /cvsroot/tk/unix/configure.in,v
  retrieving revision 1.47
  diff -u -r1.47 configure.in
  --- configure.in        2000/02/10 08:53:16     1.47
  +++ configure.in        2000/02/23 21:44:40
  @@ -17,6 +17,8 @@
   if test "${exec_prefix}" = "NONE"; then
       exec_prefix=$prefix
   fi
  +# Make sure srcdir is fully qualified!
  +srcdir=`cd $srcdir ; pwd`
   TK_SRC_DIR=`cd $srcdir/..; pwd`

   AC_PROG_RANLIB

  PatchFiles:
  unix/Makefile.in
      unix/configure.in



  Thanks for the patch, Mo.  I applied it to the sources in CVS, and it will go out with 8.3.1.

  - eric

  -- 03/30/2000 ericm


tkt_uuid: 220689ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: entry widgets don't "grey out" when disabled
comment:
  OriginalBugID: 4239 RFE
  Version: 8.2
  SubmitDate: '2000-02-25'
  LastModified: '2000-05-14'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  FixedDate: '2000-05-14'
  FixedInVersion: 8.4a1


  Name:
  Chris Nelson

  ReproducibleScript:
  entry .e -state disabled

  ObservedBehavior:
  "Native" widgets on Win32 platforms change colors when disabled.  For example, an entry field's background changes to match the window background color, rather than the normal entry color.  The entry's foreground "greys out".  Tk entries don't do this.  It's a LOT of work to simulate correct behavior with a Tcl wrapper which reacts to changes of state by setting colors explicitly.

  DesiredBehavior:
  Tk widgets should look like native widgets.



  This is really an RFE.  entries should perhaps have three states:
  normal (you can edit and select), uneditable (you can only select),
  and disabled (you can't do anything). 
  -- 02/28/2000 hobbs

  I added a "readonly" state to the entry widget, which allows selection but not editing, and I changed the behavior of the disabled state such that the entry is drawn in a dimmed color when it is disabled.  In addition, selection in a disabled entry is no longer permitted.  This is a backwards incompatible change, as the behavior of a disabled entry is significantly different than it was in previous versions of Tk.  This change will go out with 8.4a1.

  - eric

  -- 05/14/2000 ericm


tkt_uuid: 220690ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Linking VTK with Tcl/Tk support
comment:
  OriginalBugID: 4240 Bug
  Version: 8.3
  SubmitDate: '2000-02-25'
  LastModified: '2000-03-27'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  FixedDate: '2000-03-27'
  FixedInVersion: 8.3.1


  Name:
  Bernhard Hombitzer

  Comments:
  Linking VTK (www.kitware.com) with tcl/tk failed with the error
      _TkWinChildProc in library not found.
      Changing the line 
      extern LRESULT CALLBACKTkWinChildProc _ANSI_ARGS_((HWND hwnd, UINT
      message,  WPARAM wParam, LPARAM lParam));
      to
      EXTERN LRESULT CALLBACKTkWinChildProc _ANSI_ARGS_((HWND hwnd, UINT
      message,  WPARAM wParam, LPARAM lParam));
      in file tk8.3.0/win/tkWinInt.h resolved that problem.



  The fix as noted is not correct.  It should go into the platform
  specific stubs table.  For some reason it wasn't done with the
  rest in 8.1... 
  -- 02/25/2000 hobbs
  This required a bit more than the above, but the fix is in 8.3.1. 
  -- 03/27/2000 hobbs


tkt_uuid: 220691ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Images appear stippled in menubuttons
comment:
  OriginalBugID: 4246 Bug
  Version: 8.2
  SubmitDate: '2000-02-25'
  LastModified: '2000-02-28'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  Machine: SunOS bksmx1 5.6 Generic_105181-16 sun4u sparc SUNW,UltraAX-MP
  FixedDate: '2000-02-28'
  FixedInVersion: 8.3b2


  Name:
  Tom Allard

  Extensions:
  None.

  CustomShell:
  None.  Uses prowish82 as distributed with TclPro 1.3.

  ReproducibleScript:
  # Assumes you have any xbm file called file.xbm in current directory
  prowish82
  catch "image create bitmap -file file.xbm" NewImage
  button .x -image $NewImage
  pack .x
  menubutton .y -image  $NewImage
  pack .y

  ObservedBehavior:
  When run with wish8.0, both images appear identical.  With prowish82, the second image appears stippled.  The second image should only be stippled if the menubutton state is disabled, which it is not in this example.

  DesiredBehavior:
  I do not expect to see the image in .y stippled (unless I change its state).



  Already fixed for 8.3 release. 
  -- 02/28/2000 hobbs


tkt_uuid: 220692ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Tk_CreateItemType doc out of date
comment:
  OriginalBugID: 4252 Bug
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-03-02'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  FixedDate: '2000-03-02'
  FixedInVersion: 8.3.1


  Name:
  Spiros J Boucouris

  ReproducibleScript:
  createProc, configProc and CoordPorc are listed as expecting
  char** argv
  instead of
  Tcl_Obj* CONST argv

  ObservedBehavior:
  Unexpected compiler errors.

  DesiredBehavior:
  Update the documentation



  adjusted for 8.3.1 
  -- 03/02/2000 hobbs


tkt_uuid: 220693ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Shift-selection behavior in Text widget goofy
comment:
  OriginalBugID: 4253 RFE
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-04-17'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 4375
  OS: All
  FixedDate: '2000-04-17'
  FixedInVersion: 8.3.1
  ClosedDate: '2000-02-28'


  Name:
  George Petasis

  ReproducibleScript:
  There is a problem in extending a selection done with mouse:
  1) Select a word by double clicking on the text widget.
  2) Try to modify the selection with shift+arrows. Upon the first key press,
      the selection is modified in unpredictable manner. (the one end is the 
      character over which you wave done the double click. The other???)

  DesiredBehavior:
  The selection could be edited in a predictable way, preferably in the way
  that text editors implement it.



  The user needs to specify what is being unpredictable.  The selection
  code became more intelligent (complex) in 8.3 to handle embedded
  widgets and images correctly, but for raw text it works just the
  same as 8.2. 
  -- 02/28/2000 hobbs
  The complaint is just about shift-selection management, which is
  not very standard in Tk.  It should be made more like Windows.
  Moved to RFE. 
  -- 04/07/2000 hobbs

  I fixed the anchor/insert placement following double/triple clicks in the text widget.  I also tweaked the selection extension for shift-double-click, so that it now only extends selection on the side of the double-click (previously it would also select all the contiguous whitespace on the opposite side of the selection).

  This fix will go out with 8.3.1.

  - eric

  -- 04/17/2000 ericm


tkt_uuid: 220694ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: entry validation should work better with textvar
comment:
  OriginalBugID: 4255 Bug
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-03-01'
  Severity: LOW
  Status: Released
  Submitter: hobbs
  ChangedBy: hobbs
  OS: All
  FixedDate: '2000-03-01'


  Anytime you set the textvar of an entry variable, entry-based
  validation will turn itself off.  It should only turn off when
  the value is set to something that is 'invalid' to the vcmd.

  pack [entry .e]
  .e config -textvar evar -validate key -vcmd {expr [string length %P] < 8}
  set evar 123

  .e config -validate


  Changed to what the new docs state:

       In general, the  textVariable  and  validateCommand  can  be  |
       dangerous  to  mix.  Any problems have been overcome so that  |
       using the validateCommand will not interfere with the tradi-  |
       tional behavior of the entry widget.  Using the textVariable  |
       for read-only  purposes  will  never  cause  problems.   The  |
       danger  comes when you try set the textVariable to something  |
       that the validateCommand  would  not  accept,  which  causes  |
       validate  to  become  none.   The same happens when an error  |
       occurs evaluating the validateCommand.                        |

       Primarily, an error will occur when the  validateCommand  or  |
       invalidCommand  encounters  an  error  in  its  script while  |
       evaluating or validateCommand does not return  a  valid  tcl  |
       boolean  value.  The validate option will also set itself to  |
       none when you edit the entry widget from within  either  the  |
       validateCommand  or  the invalidCommand.  Such editions will  |
       override the one that was being validated.  If you  wish  to  |
       edit  the  entry  widget  (for  example set it to {}) during  |
       validation and still  have  the  validate  option  set,  you  |
       should include the command                                    |
                 after idle {%W config -validate %v}                 |
       in the validateCommand or invalidCommand (whichever one  you  |
       were editing the entry widget from).  It is also recommended  |
       to not set an associated textVariable during validation,  as  |
       that  can  cause the entry widget to become out of sync with  |
       the textVariable.
   
  -- 03/01/2000 hobbs


tkt_uuid: 220695ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: extra / in SCRIPT_INSTALL_DIR path
comment:
  OriginalBugID: 4265 Bug
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-03-01'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: QNX
  Machine: PIII 500 MHz 128 MB
  FixedDate: '2000-03-01'
  FixedInVersion: 8.3.1


  Name: Bruce Edge

  ReproducibleScript:
  make; make install

  ObservedBehavior:
  Can't create dirs for installing libs as there are 2 "/" in start of path.

  DesiredBehavior:
  A single / so dir can be created.

  Patch:
  # //8/usr/local/src/tk8.3.0/unix> diff Makefile Makefile.orig
  45c45
  < SCRIPT_INSTALL_DIR =  $(INSTALL_ROOT)$(TK_LIBRARY)
  ---
  > SCRIPT_INSTALL_DIR =  $(INSTALL_ROOT)/$(TK_LIBRARY)

  PatchFiles:
  Whatever is used to gen Makefile, Makefile.in?



  Fixed in Makefile.in for 8.3.1. 
  -- 03/01/2000 hobbs


tkt_uuid: 220696ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: tk_dialog behaviour changed - bgerror now broken
comment:
  OriginalBugID: 4266 Bug
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-04-17'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 4221 4997
  OS: All Windows
  OSVersion: Windows 98 OSR2
  Machine: Pentium III
  FixedDate: '2000-04-17'
  FixedInVersion: 8.3.1


  Name:
  Lawrence Chitty

  Comments:
  The handling of transient windows has been improved so that they are
      always withdrawn with their master. This has however broken the bgerror
      dialog as well as producing incompatabilities with other code (e.g. the
      tuba debugger uses tk_dialog boxes called .warn & .error . These no
      longer appear as the root window is withdrawn. This causes Tuba to
      effectively hang.

  ReproducibleScript:
  wm withdraw .
  after 100 {foo}

  ObservedBehavior:
  The bgerror dialog box does not appear.

  DesiredBehavior:
  bgerror dialog box always to appear



  We changed the behavior of bgerror for 8.3.1; if "." is withdrawn, the dialog box will still be displayed.  Similarly, we have corrected this for tk_messageBox and tk_dialog.

  This fix will go out with 8.3.1.

  - eric

  -- 04/17/2000 ericm


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


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

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

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

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

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

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

  Bummer!

  - eric

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

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

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



  Need this fix for Connect 2.0 release

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

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

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

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

  I made this change in BWidgets.

  - eric

  -- 03/01/2000 ericm


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


  Name: Richard Duncan

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

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

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

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

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

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

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

  PatchFiles:
  tk8.3.0/generic/tkCmds.c



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


tkt_uuid: 220699ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: "winfo rgb" gives different results between Unix and Windows
comment:
  OriginalBugID: 4282 Bug
  Version: 8.3
  SubmitDate: '2000-03-01'
  LastModified: '2000-03-02'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-03-02'
  FixedInVersion: 8.3.1


  Name: Greg Couch



  Comments:

  We're actually using 8.0.5, but xlib/xcolors.c is the same in 8.3.0.



  ReproducibleScript:

  Give the tcl command "winfo rgb . red" in wish.



  ObservedBehavior:

  On Windows you get "65280 0 0".



  DesiredBehavior:

  On Unix, you get back "65535 0 0".



  Patch:

  *** xcolors.c   2000/03/02 00:50:17     1.1

  --- xcolors.c   2000/03/02 00:59:00

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

  *** 854,862 ****

        if (l > u) {

          return 0;

        }

  !     colorPtr->red = xColors[i].red << 8;

  !     colorPtr->green = xColors[i].green << 8;

  !     colorPtr->blue = xColors[i].blue << 8;

        return 1;

    }

    



  --- 854,862 ----

        if (l > u) {

          return 0;

        }

  !     colorPtr->red = (xColors[i].red << 8) | xColors[i].red; 

  !     colorPtr->green = (xColors[i].green << 8) | xColors[i].green;

  !     colorPtr->blue = (xColors[i].blue << 8) | xColors[i].blue;

        return 1;

    }



  PatchFiles:

  xcolors.c





  Applying this patch had no effect on the end result, although

  it seems straightforward.  Also a problem is XParseColor in the

  same file, that will cause the following bad result:

      winfo rgb . #ff0000

  =>  65280 0 0 

  -- 03/02/2000 hobbs

  Needed similar patch in XParseColor in xcolors.c and also:



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

  RCS file: RCS/tkWinColor.c,v

  retrieving revision 1.1

  diff -c -r1.1 tkWinColor.c

  *** tkWinColor.c2000/03/02 19:06:191.1

  --- tkWinColor.c2000/03/02 19:13:36

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

  *** 373,381 ****

    

    if ((index >= cmap->size) || (newPixel != closePixel)) {

        if (cmap->size == sizePalette) {

  ! color->red = closeEntry.peRed << 8;

  ! color->green = closeEntry.peGreen << 8;

  ! color->blue = closeEntry.peBlue << 8;

    entry = closeEntry;

    if (index >= cmap->size) {

        OutputDebugString("XAllocColor: Colormap is bigger than we thought");

  --- 373,381 ----

    

    if ((index >= cmap->size) || (newPixel != closePixel)) {

        if (cmap->size == sizePalette) {

  ! color->red = (closeEntry.peRed << 8) | closeEntry.peRed;

  ! color->green = (closeEntry.peGreen << 8) | closeEntry.peGreen;

  ! color->blue = (closeEntry.peBlue << 8) | closeEntry.peBlue;

    entry = closeEntry;

    if (index >= cmap->size) {

        OutputDebugString("XAllocColor: Colormap is bigger than we thought");

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

  *** 404,412 ****

    

    color->pixel = GetNearestColor(dc,

    RGB(entry.peRed, entry.peGreen, entry.peBlue));

  ! color->red = (GetRValue(color->pixel) << 8);

  ! color->green = (GetGValue(color->pixel) << 8);

  ! color->blue = (GetBValue(color->pixel) << 8);

        }

    

        ReleaseDC(NULL, dc);

  --- 404,412 ----

    

    color->pixel = GetNearestColor(dc,

    RGB(entry.peRed, entry.peGreen, entry.peBlue));

  ! color->red = (GetRValue(color->pixel) << 8) | GetRValue(color->pixel);

  ! color->green = (GetGValue(color->pixel) << 8) | GetGValue(color->pixel);

  ! color->blue = (GetBValue(color->pixel) << 8) | GetBValue(color->pixel);

        }

    

        ReleaseDC(NULL, dc);



  Patched for 8.3.1. 

  -- 03/02/2000 hobbs


tkt_uuid: 220700ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: entry goes nuts when textvariable and validation are on
comment:
  OriginalBugID: 4320 Bug
  Version: 8.3
  SubmitDate: '2000-03-06'
  LastModified: '2000-03-07'
  Severity: SER
  Status: Released
  Submitter: kuchler
  ChangedBy: hobbs
  OS: Linux
  OSVersion: rh linux 6.1 (x86)
  Machine: badajoz
  FixedDate: '2000-03-07'
  FixedInVersion: 8.3.1


  proc foo {w v V p} {
  puts "validate: $w $v $V $p"
  after 100
          if {![string is digit $p]} {
                  return 0
          }
          set ::e [string range 0$p end-1 end]
          after idle [list $w configure -validate $v]
          return 1
  }
  pack [entry .e -validate focus -textvar ::e -vcmd [list foo %W %v %V %P]]
  # if you don't see the entry go ape and print a bunch of garbage, set e
  # some more
  set e 0
  set e 0
  set e 0
  set e 0
  set e 0


  Needed to make copy of value in EntrySetValue as it could become
  invalid during validation (like in above case), sending us into
  a loop in some cases. 
  -- 03/07/2000 hobbs


tkt_uuid: 220701ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Fixed
title: tk_chooseDirectory fails to go to the rootdirectory with empty -initialdir.
comment:
  OriginalBugID: 4327 Bug
  Version: 8.3
  SubmitDate: '2000-03-06'
  LastModified: '2000-03-07'
  Severity: MED
  Status: Released
  Submitter: sven
  ChangedBy: ericm
  OS: All Unix
  FixedDate: '2000-03-07'
  FixedInVersion: 8.3.1


  Specify "" as the initial dir and try to get to the root directory /

  This is fixed -- specifying "" as an initialdir is now equivalent to specifying no initialdir which is equivalent to specifying an initialdir of [pwd].

  - eric

  -- 03/07/2000 ericm


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: 220703ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Tk's bgerror hangs - an innocent bug of Tk8.3.0
comment:
  OriginalBugID: 4370 Bug
  Version: 8.3
  SubmitDate: '2000-03-13'
  LastModified: '2000-04-10'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  OSVersion: All windows
  Machine: P133 Windows 95
  FixedDate: '2000-04-10'
  FixedInVersion: 8.3.1


  Name:
  Chengye Mao

  Comments:
  I found the same problem in Tk8.3.0. This problem was rooted from Tk's
      bgerror, but never happened due to an innocent "bug" of "wm transient"
      implementation. Tk8.3.0 of Windows seems to partially fix the bug, and
      the problem of bgerror starts to show.   

      Tk's bgerror handles the error during scripts evaluation. The "bgerror"
      procedure invokes a "tk_dialog" procedure to start posting the error
      information. The "tk_dialog" sets the dialog window to be transient with
      the Tk main window (using "wm transient"). According to the
      documentation of "wm transient", this dialog window should be
      synchronized with the Tk main window, i.e., it will not show if the Tk
      main window is either hiden or iconified. This was not true in all Tk's
      before 8.3.0. I refere this as an innocent "bug" since it had never
      caused any problem to me in previous Tk (8.2 or lower). However, it does
      cause a problem in Tk8.3.0, i.e., blocking the normal script evaluation
      when error occurs and the Tk's main window is either hidden or
      iconified.

  ReproducibleScript:
  If the Tk's main window is either hidden or iconified, "bgerror" will hang up.

  ObservedBehavior:
  Invoking of bgerror should not be blocked in any cases during script evaluation, but in Tk8.3.0, it does if the main window is either hidden or iconfied.

  DesiredBehavior:
  bgerror should display the error any time it is invoked.

  Patch:
  proc bgerror err {
      global errorInfo tcl_platform

      # reset the dialog window so that it would not be blocked 
      after idle wm transient .bgerrorDialog "{}"

      # save errorInfo which would be erased in the catch below otherwise.
      set info $errorInfo ;

      # For backward compatibility :
      # Let's try to execute "tkerror" (using catch {tkerror ...} 
      # instead of searching it with info procs so the application gets
      # a chance to auto load it using its favorite "unknown" mecanism.
      # (we do the default dialog only if we get a TCL_ERROR (=1) return
      #  code from the tkerror trial, other ret codes are passed back
      #  to our caller (tcl background error handler) so the called "tkerror"
      #  can still use  return -code break, to skip remaining messages
      #  in the error queue for instance)

      set ret [catch {tkerror $err} msg];
      if {$ret != 1} {return -code $ret $msg}

      # Ok the application's tkerror either failed or was not found
      # we use the default dialog then :
      if {$tcl_platform(platform) == "macintosh"} {
  set ok Ok
      } else {
  set ok OK
      }
      set button [tk_dialog .bgerrorDialog "Error in Tcl Script"  "Error: $err" error 0 $ok "Skip Messages" "Stack Trace"]
      if {$button == 0} {
  return
      } elseif {$button == 1} {
  return -code break
      }

      set w .bgerrorTrace
      catch {destroy $w}
      toplevel $w -class ErrorTrace
      wm minsize $w 1 1
      wm title $w "Stack Trace for Error"
      wm iconname $w "Stack Trace"
      button $w.ok -text OK -command "destroy $w" -default active
      if {![string compare $tcl_platform(platform) "macintosh"]} {
        text $w.text -relief flat -bd 2 -highlightthickness 0 -setgrid true  -yscrollcommand "$w.scroll set" -width 60 -height 20
      } else {
        text $w.text -relief sunken -bd 2 -yscrollcommand "$w.scroll set"  -setgrid true -width 60 -height 20
      }
      scrollbar $w.scroll -relief sunken -command "$w.text yview"
      pack $w.ok -side bottom -padx 3m -pady 2m
      pack $w.scroll -side right -fill y
      pack $w.text -side left -expand yes -fill both
      $w.text insert 0.0 $info
      $w.text mark set insert 0.0

      bind $w <Return> "destroy $w"
      bind $w.text <Return> "destroy $w; break"

      # Center the window on the screen.

      wm withdraw $w
      update idletasks
      set x [expr {[winfo screenwidth $w]/2 - [winfo reqwidth $w]/2  - [winfo vrootx [winfo parent $w]]}]
      set y [expr {[winfo screenheight $w]/2 - [winfo reqheight $w]/2  - [winfo vrooty [winfo parent $w]]}]
      wm geom $w +$x+$y
      wm deiconify $w

      # Be sure to release any grabs that might be present on the
      # screen, since they could make it impossible for the user
      # to interact with the stack trace.

      if {[string compare [grab current .] ""]} {
  grab release [grab current .]
      }
  }

  PatchFiles:
  bgerror.tcl



  Yes, this was definately an unintended side effect of fixing the behavior of transient windows on Windows.

  I applied your patch, with a slight modification:  rather than blindly undoing the transient bit of the .bgerrorDialog, I do the following:

      after idle {
  if { ![winfo viewable .bgerrorDialog] } {
      wm transient .bgerrorDialog {}
  }
      }

  This way, if "." _is_ viewable, we will retain the transient status of the dialog, which I think is beneficial.  If "." is not viewable, then the dialog will have the transient bit unset, so the dialog will be shown.

  This fix will go out with 8.3.1.

  - eric

  -- 04/10/2000 ericm


tkt_uuid: 220704ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: '-state disabled' items in menubars are not displayed as dimmed
comment:
  OriginalBugID: 4372 Bug
  Version: 8.3
  SubmitDate: '2000-03-13'
  LastModified: '2000-07-28'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: 4.0sp5
  FixedDate: '2000-07-28'
  FixedInVersion: 8.4a2


  Name:
  Vince Darley

  ReproducibleScript:
  menu .menubar
  menu .menubar.first
  menu .menubar.second
  .menubar.first add command -label "test-item"
  .menubar.second add command -label "test-item"
  .menubar add cascade -menu .menubar.first -label "Disabled" -state disabled
  .menubar add cascade -menu .menubar.second -label "Enabled"
  label .l -text "Both menus look the same, even though the first should be dimmed"
  pack .l -fill both -expand 1
  . configure -menu .menubar

  ObservedBehavior:
  The first menu will not post, since it is disabled (which is good), but since it isn't shown as disabled (it isn't dimmed or otherwise visually different to the second menu), it is rather confusing to the user...

  DesiredBehavior:
  Menus with '-state disabled' should be visually differentiated from those with '-state normal'.  Note that _submenus_ are displayed correctly and intuitively when dimmed.



  The menu entry did not have the MF_GRAYED bit set, which is separate from the MF_DISABLED bit (which apparently disables but does not gray the entry).  Thus entries that were drawn by the system (and not directly by Tk) did not get drawn grayed.  I added this bit, and this has fixed the problem.  This fix will be included with Tcl/Tk 8.4a2.  Thanks for the bug report!

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

  -- 07/28/2000 ericm


tkt_uuid: 220705ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Pressing Escape in a listbox results in a Tcl error dialog
comment:
  OriginalBugID: 4373 Bug
  Version: 8.0p2
  SubmitDate: '2000-03-15'
  LastModified: '2000-03-22'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-03-22'
  FixedInVersion: 8.3.1


  Name:
  Mark A. Wege

  Comments:
  Although we found this problem under Solaris 2.6 using Tcl 8.0p2, it
      also happens under Windows using Tcl 8.3.0 (which I
      downloaded from Scripts on 3/14/2000).

      Based on looking at the body of the tkListboxCancel procedure, it
      appears that the listboxPrev element of the tkPriv
      array is not being initialized properly.  For a workaround, I
      initialized it to the results of "$w index anchor".

      BTW, while looking at the procedure in Tcl 8.3, I saw the command:

           event generate $w <<ListboxSelect>>

      but could not find any definition of the virtual event
      <<ListboxSelect>>, even when issuing the command:

           bind Listbox <<ListboxSelect>>

      Is this for future use, or is some code missing from the build?

  ReproducibleScript:
  Execute the following code in an interactive session of wish, then move the mouse over the listbox and press the Escape key:

  listbox .l -selectmode extended
  pack .l
  focus .l

  ObservedBehavior:
  The following error is generated, but only when the listbox has a -selectmode of extended, and no rows have ever
  been selected by clicking on them (it does still happen if you select a row in your code using "selection set"):

  bad listbox index "": must be active, anchor, end, @x,y, or a number
      while executing
  "$w selection clear $first $last"
      (procedure "tkListboxCancel" line 13)
      invoked from within
  "tkListboxCancel .l"
      (command bound to event)

  DesiredBehavior:
  No error should be generated.



  listboxPrev is initialized, but to {}, which is an invalid index.  I added a check for this in tkListboxCancel.  The fix should go out with 8.3.1.

  ListboxSelect is a convenience event for developers.  If you bind to ListboxSelect on your listbox, you can get a callback everytime selection changes:

  bind [listbox .l] <<ListboxSelect>> {puts "selection event!"}

  This is described in the listbox manual entry:

         Any time the selection changes in the listbox, the virtual
         event  <<ListboxSelect>> will be generated.  It is easiest
         to bind to this event to be made aware of any  changes  to
         listbox selection.

  - eric

  -- 03/22/2000 ericm


tkt_uuid: 220706ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Crash: Null pointer read (tkwin is NULL) in tkListbox.c line 1450.
comment:
  OriginalBugID: 4385 Bug
  Version: 8.3
  SubmitDate: '2000-03-16'
  LastModified: '2000-03-23'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: Solaris 2.5.1
  Machine: Solaris
  FixedDate: '2000-03-23'
  FixedInVersion: 8.3.1


  Name:

  Douglas Selph


  Extensions:

  tcl 8.3.0, tk8.3.0, itcl3.1.0,  blt2.4m, iwidgets3.0.0


  Comments:

  Although I haven't worked out a reproducible example, looking at the

      code, I believe it is quite clear where the problem lies.  I am not

      exactly sure the right way to fix it though so I don't have a proposed

      patch.


      Analysis:


      The problem occurs on line 1598 of tkConfig.c:


              case TK_OPTION_CURSOR:

                  if (internalFormExists) {

                      if (*((Tk_Cursor *) internalPtr) != None) {

                          Tk_FreeCursor(Tk_Display(tkwin),

                                  *((Tk_Cursor *) internalPtr));

                          *((Tk_Cursor *) internalPtr) = None;

                      }


      The value of 'tkwin' is NULL, therefore the above code crashes.


      The stack trace above it is:


                  FreeResources  [tkConfig.c:1598]

                  Tk_FreeConfigOptions [tkConfig.c:1500]

                                     oldInternalPtr = NULL;

                                 }

                                 if (optionPtr->flags & OPTION_NEEDS_FREEING)

      {

                  =>                 FreeResources(optionPtr, oldPtr,

      oldInternalPtr, tkwin);

                                 }

                                 if (oldPtr != NULL) {

                                     Tcl_DecrRefCount(oldPtr);

                  DestroyListbox [tkListbox.c:1450]

                             Tk_FreeGC(listPtr->display, listPtr->selTextGC);

                         }

                         Tk_FreeConfigOptions((char *)listPtr,

      listPtr->optionTable,

                  =>             listPtr->tkwin);

                         ckfree((char *) listPtr);

                     }


                  ListboxEventProc [tkListbox.c:2365]

                             if (listPtr->flags & REDRAW_PENDING) {

                                 Tcl_CancelIdleCall(DisplayListbox,

      (ClientData) listPtr);

                             }

                  =>         Tcl_EventuallyFree((ClientData) listPtr,

      DestroyListbox);

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

                             int vertSpace;


      Now, tkwin is indeed NULL in the functions FreeResources,

      Tk_FreeConfigOptions, and DestroyListbox.  (I saw this in the

      debugger).


      And if you look in ListboxEventProc, just before the call to 


      Tcl_EventuallyFree((ClientData) listPtr, DestroyListbox);


      occurs, you will see the following lines:


              if (listPtr->tkwin != NULL) {

                  if (listPtr->setGrid) {

                      Tk_UnsetGrid(listPtr->tkwin);

                  }

                  listPtr->tkwin = NULL;

                  Tcl_DeleteCommandFromToken(listPtr->interp,

      listPtr->widgetCmd);

              }

              if (listPtr->flags & REDRAW_PENDING) {

                  Tcl_CancelIdleCall(DisplayListbox, (ClientData) listPtr);

              }

              Tcl_EventuallyFree((ClientData) listPtr, DestroyListbox);


      Notice in the above lines that 'tkwin' is explicitly getting set to

      NULL!

      And as I peruse the tkListbox.c code I see that tkwin is indeed allowed

      to be NULL in a number of places.

      However, in tkConfig.c it appears that tkwin is assumed NOT to be NULL.


      Why I couldn't find and apply a suitable patch:


      Where does one apply the fix?  Should you start detecting for a NULL

      tkwin in tkConfig.c?  If you do that, it seems to me you have to do it

      everywhere in that file.


      If you check for a NULL tkwin in tkListbox.c, ie. not calling 

      Tk_FreeConfigOptions((char *)listPtr, listPtr->optionTable,

                  listPtr->tkwin);

      on line 1450 when tkwin is NULL, then you loose all the other

      freeing benefits of the same call.  So what to do?


  ReproducibleScript:

  (I can only reproduce this within my wish under a complex set of circumstances.  I did not spend the time to try and find an indepedent working reproducible example.  However, even so, I believe I have found a convincing case that the code in tkConfig.c and tkListbox.c has some notable problems.  I describe this in detail below.  If this is still not good enough (please be good enough), I can try and come up with a reproducible senario.)


  ObservedBehavior:

  Program crashed.


  Stack Trace:


        NPR: Null pointer read

        This is occurring while in:

              FreeResources  [tkConfig.c:1598]

                             if (internalFormExists) {

                                 if (*((Tk_Cursor *) internalPtr) != None) {

                                     Tk_FreeCursor(Tk_Display(tkwin),

              =>                             *((Tk_Cursor *) internalPtr));

                                     *((Tk_Cursor *) internalPtr) = None;

                                 }

                             } else if (objPtr != NULL) {

              Tk_FreeConfigOptions [tkConfig.c:1500]

                                 oldInternalPtr = NULL;

                             }

                             if (optionPtr->flags & OPTION_NEEDS_FREEING) {

              =>                 FreeResources(optionPtr, oldPtr, oldInternalPtr,

  tkwin);

                             }

                             if (oldPtr != NULL) {

                                 Tcl_DecrRefCount(oldPtr);

              DestroyListbox [tkListbox.c:1450]

                         Tk_FreeGC(listPtr->display, listPtr->selTextGC);

                     }

                     Tk_FreeConfigOptions((char *)listPtr, listPtr->optionTable,

              =>             listPtr->tkwin);

                     ckfree((char *) listPtr);

                 }


              ListboxEventProc [tkListbox.c:2365]

                         if (listPtr->flags & REDRAW_PENDING) {

                             Tcl_CancelIdleCall(DisplayListbox, (ClientData)

  listPtr);

                         }

              =>         Tcl_EventuallyFree((ClientData) listPtr,

  DestroyListbox);

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

                         int vertSpace;


              Tk_HandleEvent [tkEvent.c:722]

              Tk_DestroyWindow [tkWindow.c:1237]

              Tk_DestroyWindow [tkWindow.c:1180]

              Tk_DestroyWindow [tkWindow.c:1180]

              Tk_DestroyWindow [tkWindow.c:1180]

              Tk_DestroyWindow [tkWindow.c:1180]

              Tk_DestroyWindow [tkWindow.c:1180]

              Tk_DestroyWindow [tkWindow.c:1180]

              Tk_DestroyWindow [tkWindow.c:1180]

              Tk_DestroyWindow [tkWindow.c:1180]

              Tk_DestroyWindow [tkWindow.c:1180]

              Tk_DestroyWindow [tkWindow.c:1180]

              Tk_DestroyWindow [tkWindow.c:1180]

              DeleteWindowsExitProc [tkWindow.c:2552]

              Tcl_Finalize   [tclLoadDl.c]

              Tcl_Exit       [tclLoadDl.c]

              StdinProc      [tkMain.c:325]

              Tcl_NotifyChannel [tclLoadDl.c]

              FileHandlerEventProc [tclUnixNotfy.c]

              Tcl_ServiceEvent [tclLoadDl.c]

              Tcl_DoOneEvent [tclLoadDl.c]

              Tk_MainLoop    [tkEvent.c:1130]

              Tk_MainEx      [tkMain.c:281]

              main           [tkAppInit.o]

              _start         [crt1.o]

        Reading 4 bytes from 0x0




  This sounds like the problem with setting the listbox cursor
  and then destroying the listbox (introduced for 8.3, fixed
  in 8.3.1 already). 
  -- 03/23/2000 hobbs


tkt_uuid: 220707ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: UMR: Uninitialized memory read
comment:
  OriginalBugID: 4387 Bug
  Version: 8.3
  SubmitDate: '2000-03-16'
  LastModified: '2000-04-07'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: Solaris 2.5.1
  Machine: Solaris
  FixedDate: '2000-04-07'
  FixedInVersion: 8.3.1


  Name:

  Douglas Selph


  Extensions:

  tcl8.3.0, tk8.3.0, itcl3.1.0, Blt2.4m, iwidgets3.0.0


  Comments:

  In procedure InitMasterData(masterPtr) the variable startX, and startY

      of struct GridMaster are not being initialized to anything.

      InitMasterData is defined between lines 1922 and 1945 of tkGrid.c.


      Therefore on line 403 of tkGrid.c the UMR is occuring because these

      values are being referenced.


      (The tcl command being exeuted was "grid bbox".)


  ReproducibleScript:

  (Although I didn't spend the time to work out a reproducible example, it's quite obvious from the code what the problem is.)


  ObservedBehavior:

  Uninitialized memory read in:


       UMR: Uninitialized memory read

        This is occurring while in:

              Tk_GridCmd     [tkGrid.c:403]

                         } 


                         sprintf(buf, "%d %d %d %d", x + gridPtr->startX, y +

  gridPtr->startY,

              =>                 width, height);

                         Tcl_SetResult(interp, buf, TCL_VOLATILE);

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

  length) == 0)) {

                         if (argv[2][0] != '.') {

              TclInvokeStringCommand [tclLoadDl.c]

              TclExecuteByteCode [tclLoadDl.c]

              Tcl_EvalObjEx  [tclLoadDl.c]

              Itcl_EvalMemberCode [libitcl31.so]

  ...




  These did indeed seem to be uninitialized (and other elements
  were doubly initialized...).  Fixed for 8.3.1. 
  -- 04/07/2000 hobbs


tkt_uuid: 220708ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: tkUnixWm memory leak
comment:
  OriginalBugID: 4405 Bug
  Version: 8.3
  SubmitDate: '2000-03-20'
  LastModified: '2000-03-27'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Unix
  FixedDate: '2000-03-27'
  FixedInVersion: 8.3.1


  Name:

  Huver Hu



  ReproducibleScript:

  keep on creating new children top-levels with the same group leader.



  ObservedBehavior:

  a few of the places where allocated memory are not freed.



  DesiredBehavior:

  see diff attached.



  Patch:

  *** tkUnixWm.c.orig     Thu Feb 10 02:53:19 2000

  --- tkUnixWm.c  Wed Feb 23 21:40:38 2000

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

  *** 1230,1235 ****

  --- 1230,1238 ----

              }

              wmPtr->hints.window_group = Tk_WindowId(wmPtr2->wrapperPtr);

              wmPtr->hints.flags |= WindowGroupHint;

  +           if (wmPtr->leaderName != NULL) {

  +               ckfree((char *) wmPtr->leaderName);

  +           }

              wmPtr->leaderName = ckalloc((unsigned) (strlen(argv[3])+1));

              strcpy(wmPtr->leaderName, argv[3]);

          }

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

  *** 1354,1359 ****

  --- 1357,1365 ----

                      TCL_STATIC);

              return TCL_OK;

          } else {

  +           if (wmPtr->iconName != NULL) {

  +               ckfree((char *) wmPtr->iconName);

  +           }

              wmPtr->iconName = ckalloc((unsigned) (strlen(argv[3]) + 1));

              strcpy(wmPtr->iconName, argv[3]);

              if (!(wmPtr->flags & WM_NEVER_MAPPED)) {

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

  *** 1847,1852 ****

  --- 1853,1861 ----

                      TCL_STATIC);

              return TCL_OK;

          } else {

  +           if (wmPtr->title != NULL) {

  +               ckfree((char *) wmPtr->title);

  +           }

              wmPtr->title = ckalloc((unsigned) (strlen(argv[3]) + 1));

              strcpy(wmPtr->title, argv[3]);

              if (!(wmPtr->flags & WM_NEVER_MAPPED)) {

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

  *** 1903,1908 ****

  --- 1912,1920 ----

                  CreateWrapper(wmPtr2);

              }

              wmPtr->master = Tk_WindowId(wmPtr2->wrapperPtr);

  +           if (wmPtr->masterWindowName != NULL) {

  +               ckfree((char *) wmPtr->masterWindowName);

  +           }

              wmPtr->masterWindowName = ckalloc((unsigned) (strlen(argv[3])+1));

              strcpy(wmPtr->masterWindowName, argv[3]);

          }



  PatchFiles:

  unix/tkUnixWm.c





  Good find, and thanks for the patch.  I applied it to the CVS repository.  The fix will go out with Tcl/Tk 8.3.1.

  - eric

  -- 03/27/2000 ericm


tkt_uuid: 220709ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 50. [pack]
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: crash with "entry .e ; pack .e -side"
comment:
  OriginalBugID: 4422 Bug
  Version: 8.2
  SubmitDate: '2000-03-21'
  LastModified: '2000-03-23'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  FixedDate: '2000-03-23'


  ReproducibleScript:
  namespace eval ::huuhaa {
      set huuhaa huuhaa
  }
  proc ::huuhaa::UI {} {
      entry .e 
      pack .e -side
      # now examine the "Error in startup script"  and "malformed bucket 
      # chain in Tcl_DeleteHashEntry" dialogs followed by Dr. Watson saying: 
      # "wish82.exe Exception: harcoded breakpoint (0x80000003), 
      # Address 0x77f7629c"
  }
  ::huuhaa::UI
  tkwait variable _wait_for_a_while_
  #info patchlevel -> 8.2.0

  ObservedBehavior:
  Dr. Watson appears

  DesiredBehavior:
  wish exits without Dr. Watson

  Patch:
  N/A

  PatchFiles:
  N/A



  This is not a crash in 8.3, must have been fixed in the interim
  (likely before 8.2.3). 
  -- 03/23/2000 hobbs


tkt_uuid: 220710ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: nonempty canvases accept all configs
comment:
  OriginalBugID: 4456 Bug
  Version: 8.3
  SubmitDate: '2000-03-22'
  LastModified: '2000-03-28'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-03-28'
  FixedInVersion: 8.3.1


  Name:
  hume smith

  Comments:
  In one program I happened to rely on a canvas pitching a fit given bad
      configures...  BTW it seems like every time I turn around it's harder
      and harder to find the bug report form.

  ReproducibleScript:
  canvas .c
  puts [catch {.c config -garkinkler foo}]
  .c create line 0 0 20 20
  puts [catch {.c config -garkinkler foo}]

  ObservedBehavior:
  prints
  1
  0

  DesiredBehavior:
  prints
  1
  1



  (posted to comp.lang.tcl)

  It looks like this got picked up with the Dash patch in 8.3.0.  I tracked
  the problem to this piece of code in tkCanvas.c:

        case CANV_CONFIGURE: {
          if (argc == 2) {
              result = Tk_ConfigureInfo(interp, canvasPtr->tkwin,
                          configSpecs, (char *) canvasPtr, (char *) NULL,
                          0);
          } else if (argc == 3) {
              result = Tk_ConfigureInfo(interp, canvasPtr->tkwin,
                          configSpecs, (char *) canvasPtr,
                          Tcl_GetString(argv[2]), 0);
          } else {
              result = ConfigureCanvas(interp, canvasPtr, argc-2, argv+2,
                      TK_CONFIG_ARGV_ONLY);
              for (itemPtr = canvasPtr->firstItemPtr;
                  itemPtr != NULL; itemPtr = itemPtr->nextPtr) {
                  if (itemPtr->state != TK_STATE_NULL) {
                      continue;
                  }
                  EventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);
                  result = (*itemPtr->typePtr->configProc)(interp,
                          (Tk_Canvas) canvasPtr, itemPtr, 0, 
                          (Tcl_Obj **) NULL, TK_CONFIG_ARGV_ONLY);
                  EventuallyRedrawItem((Tk_Canvas) canvasPtr, itemPtr);
                  canvasPtr->flags |= REPICK_NEEDED;
              }
          }
          break;
        }

  This is the bit of CanvasWidgetCmd that is responsible for handling the
  "configure" subcommand.  As you can see, when there are items on the
  canvas, it configures those items in addition to configuring the canvas
  itself.  In the process, it crushes the original return code from
  configuring the canvas.  The for loop in the code above came along with
  the Dash patch.  I don't think it should be there at all -- configuring
  the canvas should not configure the items on the canvas.  Perhaps Jan
  Nitjmans can shed some light on what the purpose of this code is?

  - eric

  -- 03/22/2000 ericm

  From Jan:

  The purpose of this code is to handle the "-state" option of the
  canvas itself. Any canvas widget which doesn't have "-state"
  set explicitely takes over the state of its parent. Therefore,
  all those items must eventually be reconfigured in order to be
  redrawn when the state changes.

  Another possibility is that configuring the canvas has the
  side-effect that another item could get the focus, which
  might also change the appearance and even the size of this
  item. This could happen, for example, when the new option
  "-activewidth" is used. That's what the REPICK_NEEDED is
  for. This part of the code works together with other parts
  in tkCanvas.c, making the configuration process as fast as
  possible. The configProc proc is called with no arguments,
  so it only has very little work to do. Actually this
  proc should never return an error, but this cannot
  be guaranteed because it might come from a user-written
  canvas widget.

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

  After some discussion with Jeff Hobbs and Scott Stanton, we decided that this it is in fact incorrect for the canvas configure command to perform a configure on each item on the canvas.  While Jan's comments that it might be used for items that don't, for example, have their own state value, no current canvas items do this.  Thus this loop is causing a performance hit to support the possibility that some items might do this.  A better solution would be to add the ability for canvas items to register interest in canvas configuration events; when the canvas is reconfigured, it could then look at this list (which would usually be far shorter than the list of all canvas items) and perform a configuration on each item in that list.

  The important thing here is that I have removed the offending code, so this bug is fixed.  This fix will go out with 8.3.1.

  - eric

  -- 03/28/2000 ericm


tkt_uuid: 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: 220712ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Torn-off menus not given correct title
comment:
  OriginalBugID: 4506 Bug
  Version: 8.0p2
  SubmitDate: '2000-03-23'
  LastModified: '2000-03-30'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: Solaris 2.6
  Machine: SunOS 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-Enterprise
  FixedDate: '2000-03-30'
  FixedInVersion: 8.3.1


  Name:

  Mark A. Wege


  Extensions:

  TclX 8.0.2, Oratcl 2.5


  Comments:

  This patch will cause the titles of torn-off menus to be correct in most

      cases.


      If the torn-off menu is resized (i.e., stretched horizontally), however,

      the menu title of any menus which are torn off from the

      first torn-off menu may still be a variation of "tearoff".  Even though

      the menu is wider, the underlying code which created

      the menu only recognizes the original width of the menu option.  Once

      you move to the right of that width, the "active" index

      of the parent menu becomes "none", which causes the code that tries to

      determine a title to fail.


      NOTE: Although we are using Tcl 8.0p2 in our production environment,

      I've downloaded and built Tcl 8.3.0, and it continues

      to have this problem.  The problem has existed, at least to some extent,

      since Tcl 7.4-.


  ReproducibleScript:

  Create a menu with tearoffs enabled, and then tear off a menu.


  ObservedBehavior:

  After you have torn off a menu, the title of the torn-off menu is always set to the word "tearoff" followed by a number.


  DesiredBehavior:

  The title should be the same as the menu option from which the torn-off menu was created.


  Patch:

  *** menu.tcl.orig       Wed Mar 22 08:04:09 2000

  --- menu.tcl    Thu Mar 23 16:05:53 2000

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

  *** 648,655 ****

          set menu [$w entrycget active -menu]

          tkMenuFirstEntry $menu

        } elseif {[string equal [$w type active] "tearoff"]} {

  -       tkMenuUnpost $w

          tkTearOffMenu $w

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

          $w postcascade none

          $w activate none

  --- 648,655 ----

          set menu [$w entrycget active -menu]

          tkMenuFirstEntry $menu

        } elseif {[string equal [$w type active] "tearoff"]} {

          tkTearOffMenu $w

  +       tkMenuUnpost $w

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

          $w postcascade none

          $w activate none


  PatchFiles:

  lib/tk8.0/menu.tcl




  This does seem to correct the naming problem, and will be in 8.3.1. 
  -- 03/30/2000 hobbs


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


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

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

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

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

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





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



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


tkt_uuid: 220714ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: event generate can't generate Alt-* events
comment:
  OriginalBugID: 4611 Bug
  Version: 8.3
  SubmitDate: '2000-03-27'
  LastModified: '2000-04-11'
  Severity: MED
  Status: Released
  Submitter: hobbs
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-04-11'
  FixedInVersion: 8.3.1


  As synopsis says, it effects all systems, but subtly different
  between Unix and Windows (Unix can generate them when using
  the Meta specifier).  Just do:

    pack [entry .e]
    bind .e <Alt-z> "puts alt-z'ed"
  # type alt-z to see that it works
    focus -force .e ; event generate .e <Alt-z>
  # this will just type a z into the widget

  Using Control works just fine.

  Verified; event generate is not creating the x event structure correctly for alt and meta keys.  I have a fix for this, almost done.

  - eric

  -- 04/10/2000 ericm

  Fixed is checked in and verified on Linux and NT.  As noted, the problem was basically this:

  to handle [event generate], we fake up an XEvent structure.  Part of that structure has a field that marks which modifier keys are set.  In Tk, we have two different views of modifier keys:  the Tk view, and the display specific view.  We were setting this modifier field to the values given by the Tk view, but then testing against the values for the display view.  I changed this to set the field to the values given by the display view.

  This only half fixed the problem.  The next issue was that the display view of the modifier bits was being determined lazily, only when Tk had to evaluate a key binding.  Of course, by the time it did that, we had already created our XEvent structure in [event generate].  The symptom of this was that [event generate $w <Alt-z>] would only work if it was the second key event handled by Tk for that display (ie, a "throw away" [event generate] would cause the initialization, as would a physical keypress of Alt-z).  I added code to cause this initialization (if necessary) in [event generate] as well, fixing this problem.

  This fix is in CVS now, and will go out with 8.3.1.  Good bug find to whomever actually noticed this one -- the bug has been around since [event generate] was introduced (in 8.0.?).

  - eric

  -- 04/11/2000 ericm


tkt_uuid: 220715ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Bug in transparency handling of X11 emulation for Windows
comment:
  OriginalBugID: 4617 Bug
  Version: 8.3
  SubmitDate: '2000-03-27'
  LastModified: '2000-03-30'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-03-30'
  FixedInVersion: 8.3.1


  Name:

  Jan Nijtmans


  ReproducibleScript:

  pack [canvas .c]

  .c create lin 10 10 100 100 -dash.


  ObservedBehavior:

  When drawing dashed lines on the canvas, the parts that are supposed to be transparent are in fact white. This is a long-standing

  bug in the dash-patch or - actually - a bug in the X11 emulation layer, affecting Windows only. This bug never affected Tk in

  earlier versions because there didn't exist partially transparant canvas items.

  Because of my lack of experience with the win32 api, I was not able to fix this earlier. However now I finally spent some

  time to investigate it. Here is the fix I came up with.


  Patch:

  *** win/tkWinInt.h.orig     Mon Mar 27 15:15:48 2000

  --- win/tkWinInt.h  Mon Mar 27 15:21:40 2000

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

  *** 48,53 ****

  --- 48,54 ----


    typedef struct TkWinDCState {

        HPALETTE palette;

  +     int bkmode;

    } TkWinDCState;


    /*

  *** win/tkWinDraw.c.orig    Mon Mar 27 15:07:56 2000

  --- win/tkWinDraw.c Mon Mar 27 15:42:06 2000

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

  *** 173,178 ****

  --- 173,179 ----

    cmap = twdPtr->bitmap.colormap;

        }

        state->palette = TkWinSelectPalette(dc, cmap);

  +     state->bkmode = GetBkMode(dc);

        return dc;

    }

    

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

  *** 199,204 ****

  --- 200,206 ----

        TkWinDCState *state;

    {

        TkWinDrawable *twdPtr = (TkWinDrawable *)d;

  +     SetBkMode(dc, state->bkmode);

        SelectPalette(dc, state->palette, TRUE);

        RealizePalette(dc);

        if (twdPtr->type == TWD_WINDOW) {

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

  *** 864,869 ****

  --- 866,872 ----

        dc = TkWinGetDrawableDC(display, d, &state);


        pen = SetUpGraphicsPort(gc);

  +     SetBkMode(dc, TRANSPARENT);

        RenderObject(dc, gc, points, npoints, mode, pen, Polyline);

        DeleteObject(pen);


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

  *** 950,955 ****

  --- 953,959 ----

        dc = TkWinGetDrawableDC(display, d, &state);


        pen = SetUpGraphicsPort(gc);

  +     SetBkMode(dc, TRANSPARENT);

        oldPen = SelectObject(dc, pen);

        oldBrush = SelectObject(dc, GetStockObject(NULL_BRUSH));

        SetROP2(dc, tkpWinRopModes[gc->function]);

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

  *** 1120,1125 ****

  --- 1124,1130 ----

     * it's only supported under Windows NT.

     */


  + SetBkMode(dc, TRANSPARENT);

    Arc(dc, x, y, x+width+1, y+height+1, xstart, ystart, xend, yend);

        } else {

    brush = CreateSolidBrush(gc->foreground);


  PatchFiles:

  tkWinInt.h tkWinDraw.c




  verified and patched as given for 8.3.1. 
  -- 03/30/2000 hobbs


tkt_uuid: 220716ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 52. [clipboard]
priority: 2
foundin: None
resolution: Fixed
title: add 'clipboard get'
comment:
  OriginalBugID: 4628 RFE
  Version: 8.3
  SubmitDate: '2000-03-27'
  LastModified: '2000-05-14'
  Severity: LOW
  Status: Released
  Submitter: hobbs
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-05-14'
  FixedInVersion: 8.4a1


  which is synonymous to 'selection get -selection CLIPBOARD'.

  I added "clipboard get"; this will go out in 8.4a1.

  - eric
   
  -- 05/14/2000 ericm


tkt_uuid: 220717ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title:
  Import Schema dialog doesn't automatically update the file name if you change the selection by using alpha characters instead of arrows

comment:
  OriginalBugID: 4710 Bug
  Version: 8.3
  SubmitDate: '2000-03-29'
  LastModified: '2000-03-29'
  Severity: MED
  Status: Released
  Submitter: jenn
  ChangedBy: hobbs
  OS: All Unix
  FixedDate: '2000-03-29'
  FixedInVersion: 8.3.1


  If you type in the Schema Selection dialog, the highlighted selection moves according to what you type.  However, the file name in the File entry doesn't change.  It does change if you use the arrow keys to change your selection.

  To reproduce:
  1) Open Author
  2) add an XMLGenerator action and edit it
     --> the schema import window should pop up
  3) In the schema import window, go to installdir/samples/RosettaNet
  4) In the schema import window, click in the box containing all the file names.  
  5) Type a "p"
     --> Note that the file entry doesn't change, but the highlighted selection does change

  I found this on linux.



  I think this might be a duplicate?  Sven, you're call 2.0 or 2.0b4.

  -- 03/29/2000 redman

  We are just using the standard Tk dialog. This is a problem in tk_getOpenFile, so I would assign this to Jeff. 
  -- 03/29/2000 sven

  This was specifically set as the behavior for the Unix dialog
  at some time, but I've flipped the bit so the browsecmd will
  get called (and the entry gets set). 
  -- 03/29/2000 hobbs


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


  Name:
  Ludwig Callewaert

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

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

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

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

  test

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

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



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


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


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

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

  - eric



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


tkt_uuid: 220720ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: tkWinColor.c scales color values incorrectly.
comment:
  OriginalBugID: 4919 Bug
  Version: 8.3
  SubmitDate: '2000-04-07'
  LastModified: '2000-04-16'
  Severity: MED
  Status: Released
  Submitter: angie
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-04-16'
  FixedInVersion: 8.3.1


  Name:  George A. Howlett



  ObservedBehavior:

  In tkWinColor.c the RGB components are scaled incorrectly.  It's a common

  error to simply shift the values.



      colorPtr->red = GetRValue(colorPtr->pixel) << 8;

      colorPtr->green = GetGValue(colorPtr->pixel) << 8;

      colorPtr->blue = GetBValue(colorPtr->pixel) << 8;



  This scales each 8-bit RGB color component into its corresponding

  16-bit component in an XColor structure. 



  For example, if the 8-bit value is 255, the 16-bit value should be 65535.



  but FF << 8 is FF00, not FFFF



  Instead of left shifting 8 (multiply by 256), the value needs to be

  multiplied by 257.



  255 * 257 = 65535



  Since it's rare to use an RGB component bigger than 8-bits, you usually

  don't notice the error. This causes problems when generating PostScript.





  Patch:

  *** tkWinColor.c.~1~Thu Apr 15 21:51:49 1999

  --- tkWinColor.cThu Apr 06 16:05:19 2000

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

  *** 156,164 ****

    

        *indexPtr = sysColors[i].index;

        colorPtr->pixel = GetSysColor(sysColors[i].index);

  !     colorPtr->red = GetRValue(colorPtr->pixel) << 8;

  !     colorPtr->green = GetGValue(colorPtr->pixel) << 8;

  !     colorPtr->blue = GetBValue(colorPtr->pixel) << 8;

        colorPtr->flags = DoRed|DoGreen|DoBlue;

        colorPtr->pad = 0;

        return 1;

  --- 156,164 ----

    

        *indexPtr = sysColors[i].index;

        colorPtr->pixel = GetSysColor(sysColors[i].index);

  !     colorPtr->red = GetRValue(colorPtr->pixel) * 257;

  !     colorPtr->green = GetGValue(colorPtr->pixel) * 257;

  !     colorPtr->blue = GetBValue(colorPtr->pixel) * 257;

        colorPtr->flags = DoRed|DoGreen|DoBlue;

        colorPtr->pad = 0;

        return 1;

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

  *** 373,381 ****

    

    if ((index >= cmap->size) || (newPixel != closePixel)) {

        if (cmap->size == sizePalette) {

  ! color->red = closeEntry.peRed << 8;

  ! color->green = closeEntry.peGreen << 8;

  ! color->blue = closeEntry.peBlue << 8;

    entry = closeEntry;

    if (index >= cmap->size) {

        OutputDebugString("XAllocColor: Colormap is bigger than we thought");

  --- 373,381 ----

    

    if ((index >= cmap->size) || (newPixel != closePixel)) {

        if (cmap->size == sizePalette) {

  ! color->red = closeEntry.peRed * 257;

  ! color->green = closeEntry.peGreen * 257;

  ! color->blue = closeEntry.peBlue * 257;

    entry = closeEntry;

    if (index >= cmap->size) {

        OutputDebugString("XAllocColor: Colormap is bigger than we thought");

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

  *** 404,412 ****

    

    color->pixel = GetNearestColor(dc,

    RGB(entry.peRed, entry.peGreen, entry.peBlue));

  ! color->red = (GetRValue(color->pixel) << 8);

  ! color->green = (GetGValue(color->pixel) << 8);

  ! color->blue = (GetBValue(color->pixel) << 8);

        }

    

        ReleaseDC(NULL, dc);

  --- 404,412 ----

    

    color->pixel = GetNearestColor(dc,

    RGB(entry.peRed, entry.peGreen, entry.peBlue));

  ! color->red = (GetRValue(color->pixel) * 257);

  ! color->green = (GetGValue(color->pixel) * 257);

  ! color->blue = (GetBValue(color->pixel) * 257);

        }

    

        ReleaseDC(NULL, dc);





  Comments:

      This bug exists is all versions of Tk 8.x.

      

      

  Posted To comp.lang.tcl: Posted Successfully



  Fixed for 8.3.1. 
  -- 04/16/2000 hobbs


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


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

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

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


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

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

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

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

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

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

  is below and will be in 8.3.1.



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

  retrieving revision 1.9

  diff -c -r1.9 tkWinFont.c

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

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

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

  *** 1947,1961 ****

    

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

    

  -     /*

  -      * We can only store up to LF_FACESIZE characters

  -      */

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

  -       Tcl_DStringSetLength(&ds, LF_FACESIZE);

  -     }

  - 

        if (TkWinGetPlatformId() == VER_PLATFORM_WIN32_NT) {

          Tcl_UniChar *src, *dst;

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

          dst = (Tcl_UniChar *) lf.lfFaceName;

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

  --- 1947,1961 ----

    

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

    

        if (TkWinGetPlatformId() == VER_PLATFORM_WIN32_NT) {

          Tcl_UniChar *src, *dst;

  + 

  +       /*

  +        * We can only store up to LF_FACESIZE wide characters

  +        */

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

  +           Tcl_DStringSetLength(&ds, LF_FACESIZE);

  +       }

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

          dst = (Tcl_UniChar *) lf.lfFaceName;

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

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

  *** 1964,1969 ****

  --- 1964,1975 ----

          *dst = '\0';

          hFont = CreateFontIndirectW(&lf);

        } else {

  +       /*

  +        * We can only store up to LF_FACESIZE wide characters

  +        */

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

  +           Tcl_DStringSetLength(&ds, LF_FACESIZE);

  +       }

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

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

        }


tkt_uuid: 220722ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Need to deiconify parents of transient windows
comment:
  OriginalBugID: 4997 Bug
  Version: 8.3
  SubmitDate: '2000-04-11'
  LastModified: '2000-04-17'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 4266 4221
  OS: All Unix
  OSVersion: 6.2
  Machine: SGI O2. Also witnessed on other platforms
  FixedDate: '2000-04-17'
  FixedInVersion: 8.3.1


  Name:

  James Bonfield


  Extensions:

  none


  ReproducibleScript:

  wm iconify . 

  update idletasks 

  tkMessageBox -parent . -message "test"


  ObservedBehavior:

  On _some_ window managers, the message box displayed is not displayed at all. This is because

  the window manager chooses to display the child transient window as iconified as the parent was

  already iconified. Not a good strategy when we go on to do a local grab of that window!


  An example window manager is SGI's 4dwm.


  ICCCM states that this is up to the window manager.


  DesiredBehavior:

  Ideally for the transient window to always be visible. It isn't just enough to require the programmer

  to deal with this case as the problem also arises for Tk error message windows, which may

  therefore have the effect of apparently freezing the application.


  My solution is simply to deiconify the parent window. Crude, but effective.


  Patch:

  *** orig/msgbox.tcl     Fri Dec  3 07:15:02 1999

  --- new/msgbox.tcl      Tue Apr  4 16:52:37 2000

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

  *** 249,254 ****

  --- 249,262 ----

          unsupported1 style $w dBoxProc

        }


  +     # Make sure parent window is deiconified. Good window managers will do

  +     # this anyway, but some (eg SGI's 4dwm) will simply create this child

  +     # window as iconified if the parent is also iconified, which is a very

  +     # bad idea for "grab"bed windows.

  +     if {[wm state [winfo toplevel [winfo parent $w]]] != "normal"} {

  +         wm deiconify [winfo toplevel [winfo parent $w]]

  +     }

  + 

        frame $w.bot

        pack $w.bot -side bottom -fill both

        frame $w.top

  *** orig/dialog.tcl     Wed Jan 12 11:45:14 2000

  --- new/dialog.tcl      Tue Apr  4 16:52:26 2000

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

  *** 63,68 ****

  --- 63,76 ----

          unsupported1 style $w dBoxProc

        }


  +     # Make sure parent window is deiconified. Good window managers will do

  +     # this anyway, but some (eg SGI's 4dwm) will simply create this child

  +     # window as iconified if the parent is also iconified, which is a very

  +     # bad idea for "grab"bed windows.

  +     if {[wm state [winfo toplevel [winfo parent $w]]] != "normal"} {

  +         wm deiconify [winfo toplevel [winfo parent $w]]

  +     }

  + 

        frame $w.bot

        frame $w.top

        if {[string equal $tcl_platform(platform) "unix"]} {


  PatchFiles:

  msgbox.tcl

      dialog.tcl




  I fixed this problem in CVS, and the fix will go out with 8.3.1.  I did not fix it in exactly the same way that you proposed in your patch.  Rather than deiconifying the parent window, I chose to make the dialog/message box not transient if the parent is not viewable.  This acheives the same goal, but is more backwards compatible -- consider the many users who don't use "." in their applications, and who don't set an appropriate parent for their dialogs -- all of a sudden they will get "." popping up in their app, for no good reason.  Thus, Jeff and I felt that the solution I chose is the better one.

  Thanks,

  - eric

  -- 04/17/2000 ericm


tkt_uuid: 220723ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: Speed up for motif file browser
comment:
  OriginalBugID: 4998 RFE
  Version: 8.3
  SubmitDate: '2000-04-11'
  LastModified: '2000-07-28'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Unix
  FixedDate: '2000-07-28'
  FixedInVersion: 8.4a2


  Name:

  James Bonfield



  Comments:

  tk8.3 has a substantially faster file browser than tk8.0, but it's still

      trivial to speed up further.

      My solution removes multiple file globs and stats, which can really kill

      performance on slow NFS networks. Also the sorting is performed on the

      split directory and file lists, rather than the combined list. Combined

      these give a 2x speed up.

      

      We use the Motif style browser instead of the standard one as the

      standard browser as the standard one is simply so slow that it can be

      unusable. Admittedly we have many files, but users were reporting pauses

      of minutes. A very rough estimation shows that the standard browser is

      about 20 times slower than the motif look-alike version.



  DesiredBehavior:

  The Motif style file browser is sped up.



  Patch:

  *** orig/xmfbox.tcl     Wed Apr  5 17:50:25 2000

  --- new/xmfbox.tcl      Thu Apr  6 12:08:23 2000

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

  *** 470,501 ****

          return

        }

    

  !     # Make the dir list

        #

  !     foreach f [lsort -dictionary [glob -nocomplain .* *]] {

  !       if {[file isdir ./$f]} {

  !           $data(dList) insert end $f

  !       }

  !     }

  !     # Make the file list

        #

  !     if {[string equal $data(filter) *]} {

  !       set files [lsort -dictionary [glob -nocomplain .* *]]

  !     } else {

  !       set files [lsort -dictionary \

  !           [glob -nocomplain $data(filter)]]

  !     }

  ! 

        set top 0

  !     foreach f $files {

  !       if {![file isdir ./$f]} {

  !           regsub {^[.]/} $f "" f

  !           $data(fList) insert end $f

  !           if {[string match .* $f]} {

  !               incr top

              }

          }

        }

    

        # The user probably doesn't want to see the . files. We adjust the view

        # so that the listbox displays all the non-dot files

  --- 470,500 ----

          return

        }

    

  !     # Make the dir and file lists

        #

  !     # For speed we only have one glob, which reduces the file system

  !     # calls (good for slow NFS networks).

        #

  !     # We also do two smaller sorts (files + dirs) instead of one large sort,

  !     # which gives a small speed increase.

  !     #

        set top 0

  !     set dlist ""

  !     set flist ""

  !     foreach f [glob -nocomplain .* *] {

  !       if {[file isdir ./$f]} {

  !           lappend dlist $f

  !       } else {

  !           if {[string match $data(filter) $f]} {

  !               if {[string match .* $f]} {

  !                   incr top

  !               }

  !               lappend flist $f

              }

          }

        }

  +     eval $data(dList) insert end [lsort -dictionary $dlist]

  +     eval $data(fList) insert end [lsort -dictionary $flist]

    

        # The user probably doesn't want to see the . files. We adjust the view

        # so that the listbox displays all the non-dot files



  PatchFiles:

  xmfbox.tcl





  Thanks for the patch; it has been applied to the CVS sources and the fix will be included in Tcl/Tk 8.4a2.

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

  -- 07/28/2000 ericm


tkt_uuid: 220724ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: File browser: selecting multiple files
comment:
  OriginalBugID: 4999 RFE
  Version: 8.3
  SubmitDate: '2000-04-11'
  LastModified: '2000-06-22'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 604
  OS: All Unix
  FixedDate: '2000-06-22'
  FixedInVersion: 8.4a2


  Name:

  James Bonfield


  CustomShell:

  Just the xmfbox speed-up patch sent in another mail. It is not required for the above change.


  Comments:

  We have extensions to allow -multiple to work for the built-in windows

      browser too, although at present these are diffs against tk8.0.3. We are

      working on upgrading these to the windows version of tk8.3 and we will

      submit this patch when ready.


      We do not have patches to the Mac version and neither do we have patches

      to the non-motif style file browser, but due to the severe slowness of

      that version we also have no plans to do so.


  DesiredBehavior:

  A "-multiple" option to allow selection of multiple files using tk_getOpenFile


  Patch:

  *** orig/xmfbox.tcl     Thu Jan  6 02:22:25 2000

  --- new/xmfbox.tcl      Wed Apr  5 17:50:25 2000

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

  *** 21,31 ****

    #     args            Options parsed by the procedure.

    #

    # Results:

  ! #     A list of two members. The first member is the absolute

  ! #     pathname of the selected file or "" if user hits cancel. The

  ! #     second member is the name of the selected file type, or ""

  ! #     which stands for "default file type"

  ! 

    proc tkMotifFDialog {type args} {

        global tkPriv

        set dataName __tk_filedialog

  --- 21,33 ----

    #     args            Options parsed by the procedure.

    #

    # Results:

  ! #     When -multiple is set to false, this returns the absolute pathname

  ! #     of the selected file. (NOTE: This is not the same as a single

  ! #     element list.)

  ! # 

  ! #     When -multiple is set to true, this returns a Tcl list of absolute

  ! #       pathnames.

  ! #

    proc tkMotifFDialog {type args} {

        global tkPriv

        set dataName __tk_filedialog

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

  *** 97,102 ****

  --- 99,105 ----

          set data(filterBtn) $w.bot.filter

          set data(cancelBtn) $w.bot.cancel

        }

  +     tkMotifFDialog_SetListMode $w


        wm transient $w $data(-parent)


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

  *** 138,143 ****

  --- 141,147 ----

          {-initialfile "" "" ""}

          {-parent "" "" "."}

          {-title "" "" ""}

  +       {-multiple "" "" ""}

        }


        # 2: default values depending on the type of the dialog

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

  *** 154,160 ****


        if {[string equal $data(-title) ""]} {

          if {[string equal $type "open"]} {

  !           set data(-title) "Open"

          } else {

              set data(-title) "Save As"

          }

  --- 158,168 ----


        if {[string equal $data(-title) ""]} {

          if {[string equal $type "open"]} {

  !           if {[string equal $data(-multiple) "true"]} {

  !               set data(-title) "Open Multiple Files"

  !           } else {

  !               set data(-title) "Open"

  !           }

          } else {

              set data(-title) "Save As"

          }

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

  *** 285,290 ****

  --- 293,310 ----

        wm protocol $w WM_DELETE_WINDOW [list tkMotifFDialog_CancelCmd $w]

    }


  + proc tkMotifFDialog_SetListMode {w} {

  +     upvar #0 [winfo name $w] data

  + 

  +     if {[string equal $data(-multiple) "true"]} {

  +       set selectmode extended

  +     } else {

  +       set selectmode browse

  +     }

  +     set f $w.top.f2.b

  +     $f.l configure -selectmode $selectmode

  + }

  + 

    # tkMotifFDialog_MakeSList --

    #

    #     Create a scrolled-listbox and set the keyboard accelerator

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

  *** 302,308 ****


    proc tkMotifFDialog_MakeSList {w f label under cmdPrefix} {

        label $f.lab -text $label -under $under -anchor w

  !     listbox $f.l -width 12 -height 5 -selectmode browse -exportselection 0\

          -xscrollcommand [list $f.h set] -yscrollcommand [list $f.v set]

        scrollbar $f.v -orient vertical   -takefocus 0 -command [list $f.l yview]

        scrollbar $f.h -orient horizontal -takefocus 0 -command [list $f.l xview]

  --- 322,328 ----


    proc tkMotifFDialog_MakeSList {w f label under cmdPrefix} {

        label $f.lab -text $label -under $under -anchor w

  !     listbox $f.l -width 12 -height 5 -exportselection 0 \

          -xscrollcommand [list $f.h set] -yscrollcommand [list $f.v set]

        scrollbar $f.v -orient vertical   -takefocus 0 -command [list $f.l yview]

        scrollbar $f.h -orient horizontal -takefocus 0 -command [list $f.l xview]

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

  *** 484,490 ****

        cd $appPWD

    }


  ! # tkMotifFDialog_BrowseFList --

    #

    #     This procedure is called when the directory list is browsed

    #     (clicked-over) by the user.

  --- 504,510 ----

        cd $appPWD

    }


  ! # tkMotifFDialog_BrowseDList --

    #

    #     This procedure is called when the directory list is browsed

    #     (clicked-over) by the user.

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

  *** 596,602 ****

        if {[string equal [$data(fList) curselection] ""]} {

          return

        }

  !     set data(selectFile) [$data(fList) get [$data(fList) curselection]]

        if {[string equal $data(selectFile) ""]} {

          return

        }

  --- 616,625 ----

        if {[string equal [$data(fList) curselection] ""]} {

          return

        }

  !     set data(selectFile) ""

  !     foreach item [$data(fList) curselection] {

  !       lappend data(selectFile) [$data(fList) get $item]

  !     }

        if {[string equal $data(selectFile) ""]} {

          return

        }

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

  *** 607,615 ****

        $data(fEnt) insert 0 [tkFDialog_JoinFile $data(selectPath) $data(filter)]

        $data(fEnt) xview end


        $data(sEnt) delete 0 end

  !     $data(sEnt) insert 0 [tkFDialog_JoinFile $data(selectPath) \

  !           $data(selectFile)]

        $data(sEnt) xview end

    }


  --- 630,644 ----

        $data(fEnt) insert 0 [tkFDialog_JoinFile $data(selectPath) $data(filter)]

        $data(fEnt) xview end


  +     # if it's a multiple selection box, just put in the filenames 

  +     # otherwise put in the full path as usual 

        $data(sEnt) delete 0 end

  !     if {[string equal $data(-multiple) "true"]} {

  !       $data(sEnt) insert 0 $data(selectFile)

  !     } else {

  !       $data(sEnt) insert 0 [tkFDialog_JoinFile $data(selectPath) \

  !                                 [lindex $data(selectFile) 0]]

  !     }

        $data(sEnt) xview end

    }


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

  *** 678,685 ****

        upvar #0 [winfo name $w] data


        set selectFilePath [string trim [$data(sEnt) get]]

  -     set selectFile     [file tail    $selectFilePath]

  -     set selectPath     [file dirname $selectFilePath]


        if {[string equal $selectFilePath ""]} {

          tkMotifFDialog_FilterCmd $w

  --- 707,712 ----

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

  *** 686,692 ****

          return

        }


  !     if {[file isdirectory $selectFilePath]} {

          set data(selectPath) [glob $selectFilePath]

          set data(selectFile) ""

          tkMotifFDialog_Update $w

  --- 713,723 ----

          return

        }


  !     if {[string compare $data(-multiple) "true"]} {

  !       set selectFilePath [list $selectFilePath]

  !     }

  ! 

  !     if {[file isdirectory [lindex $selectFilePath 0]]} {

          set data(selectPath) [glob $selectFilePath]

          set data(selectFile) ""

          tkMotifFDialog_Update $w

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

  *** 693,732 ****

          return

        }


  !     if {[string compare [file pathtype $selectFilePath] "absolute"]} {

  !       tk_messageBox -icon warning -type ok \

  !           -message "\"$selectFilePath\" must be an absolute pathname"

  !       return

  !     }

  ! 

  !     if {![file exists $selectPath]} {

  !       tk_messageBox -icon warning -type ok \

  !           -message "Directory \"$selectPath\" does not exist."

  !       return

  !     }

  ! 

  !     if {![file exists $selectFilePath]} {

  !       if {[string equal $data(type) open]} {

              tk_messageBox -icon warning -type ok \

  !               -message "File \"$selectFilePath\" does not exist."

              return

          }

  !     } else {

  !       if {[string equal $data(type) save]} {

  !           set message [format %s%s \

  !               "File \"$selectFilePath\" already exists.\n\n" \

  !               "Replace existing file?"]

  !           set answer [tk_messageBox -icon warning -type yesno \

  !               -message $message]

  !           if {[string equal $answer "no"]} {

                  return

              }

          }

        }


  !     set tkPriv(selectFilePath) $selectFilePath

  !     set tkPriv(selectFile)     $selectFile

  !     set tkPriv(selectPath)     $selectPath

    }


  --- 724,770 ----

          return

        }


  !     set newFileList ""

  !     foreach item $selectFilePath {

  !       if {[string compare [file pathtype $item] "absolute"]} {

  !           set item [file join $data(selectPath) $item]

  !       } elseif {![file exists [file dirname $item]]} {

              tk_messageBox -icon warning -type ok \

  !               -message "Directory \"[file dirname $item]\" does not exist."

              return

          }

  ! 

  !       if {![file exists $item]} {

  !           if {[string equal $data(type) open]} {

  !               tk_messageBox -icon warning -type ok \

  !                   -message "File \"$item\" does not exist."

                  return

              }

  +       } else {

  +           if {[string equal $data(type) save]} {

  +               set message [format %s%s \

  +                                "File \"$item\" already exists.\n\n" \

  +                                "Replace existing file?"]

  +               set answer [tk_messageBox -icon warning -type yesno \

  +                               -message $message]

  +               if {[string equal $answer "no"]} {

  +                   return

  +               }

  +           }

          }

  + 

  +       lappend newFileList $item

        }


  !     if {[string equal $data(-multiple) "true"]} {

  !       set tkPriv(selectFilePath) $newFileList

  !     } else {

  !       set tkPriv(selectFilePath) [lindex $newFileList 0]

  !     }

  ! 

  !     # Set selectFile and selectPath to first item in list

  !     set tkPriv(selectFile)     [file tail    [lindex $newFileList 0]]

  !     set tkPriv(selectPath)     [file dirname [lindex $newFileList 0]]

    }


  PatchFiles:

  xmfbox.tcl




  Thanks for the patch.  I have applied it to the sources in CVS, and it will go out with 8.4a2.

  - eric

  -- 06/22/2000 ericm


tkt_uuid: 220725ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Applying canvas move command to objects leaves trails; this behavior was not in 8.0.
comment:
  OriginalBugID: 5029 Bug
  Version: 8.3
  SubmitDate: '2000-04-12'
  LastModified: '2000-04-19'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Linux-Red Hat
  OSVersion: I'm not sure which version of Red Hat
  Machine: Dell Optiplex GX110; also occurred on DEC Alpha 3000 X
  FixedDate: '2000-04-19'
  FixedInVersion: 8.3.1


  Name:
  Tom Cormen

  Comments:
  I saw a comment in your bug database about trails from polygons.  This
      one, IMO, is a bit different because it occurs in 8.3 but not in 8.0.

  ReproducibleScript:
  Using wish, version 8.3, I run the following script:

  #!/usr/local/bin/wish
  #
  # CS 23 Winter 1998
  # Original version by David Kotz
  # Modified by Tom Cormen
  #
  # Tcl/Tk program to make a bouncing ball

  set xmax 500
  set ymax 200

  # make a canvas and make it appear
  canvas .c -width $xmax -height $ymax
  pack .c

  # diameter 
  set d 10

  # horizontal speed (pixels per time step)
  set vx 10

  # initial vertical speed (pixels per time step)
  set vy 0

  # vertical acceleration (positive is down)
  set a 3

  # size of timesteps (msec)
  set delay 50

  # how many timesteps
  set duration 200

  # create the oval, starting location in the upper-left corner
  # remember its item number in 'ball'
  set ball [.c create oval 0 0 $d $d -fill red -width 0]

  # position of center of ball
  set x [expr $d / 2]
  set y [expr $d / 2]

  for {set time 0} {$time < $duration} {incr time} {
      incr x $vx
      incr y $vy

      .c move $ball $vx $vy

      # bounce if we hit a wall, the ceiling, or the floor

      # are we hitting the left wall?
      if { $x < [expr $d / 2] } {
  .c move $ball [expr ($d/2) - $x] 0
  set x [expr $d/2]
  set vx [expr -$vx]
      }

      # are we hitting the right wall?
      if { [expr $x + ($d/2)] > $xmax } {
  .c move $ball [expr $xmax - ($d/2) - $x] 0
  set x [expr $xmax - ($d/2)]
  set vx [expr -$vx]
      }

      # are we hitting the ceiling?
      if { $y < [expr $d / 2] } {
  .c move $ball 0 [expr ($d/2) - $y]
  set y [expr $d/2]
  set vy [expr -$vy]
      }

      # are we hitting the floor?
      if { [expr $y + ($d/2)] > $ymax } {
  .c move $ball 0 [expr $ymax - ($d/2) - $y]
  set y [expr $ymax - ($d/2)]
  set vy [expr -$vy]
      }

      # increment y velocity by acceleration
      incr vy $a

      update idletasks
      after $delay
  }

  ObservedBehavior:
  I get trails from the bouncing ball.

  DesiredBehavior:
  No trails.  (Melissa Chawla knows this demo, as she used to TA this course!)



  This appears to have been added in during 8.3 (the dash patch)
  as this doesn't occur on 8.2 (verified on Windows). 
  -- 04/18/2000 hobbs

  In the sample code here, the ball is being created with an outline width of 0.  Prior to 8.3.0, outline widths of zero were not permitted on rectangles and ovals, and the width was auto-constrained to be >= 1.

  In 8.3.0, this restriction was removed, but there was a bug in the way rectangles/ovals with no outline were handled.  Specifically, the outline was always drawn, regardless of whether it had a zero width or not.  So it was as if the outline width was 1 for purposes of drawing.  But the actual stored width was 0, so when Tk computed the bounding box for the oval/rectangle, it did not include the outline width.  So when Tk refreshed the canvas display, it would underestimate the area that had to be redrawn by one pixel, and you would see these traces.

  I fixed this by correcting the handling of rectangles/ovals with no outline.
  Now when you specify a width of 0 for the outline width of an oval or rectangle, no outline will be drawn.  Consequently, the bounding box of the image drawn is now in sync with what the canvas believes it to be, and the canvas is refreshed properly, so there are no more trails.

  This fix will go out with 8.3.1.

  - eric

  -- 04/19/2000 ericm


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: 220727ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: Errant top level behaviour with Xmouse
comment:
  OriginalBugID: 5031 Bug
  Version: 8.2.3
  SubmitDate: '2000-04-12'
  LastModified: '2000-04-25'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2272
  OS: All Windows
  OSVersion: Windows 98 Second Edition
  Machine: Any intel PC
  FixedDate: '2000-04-25'
  FixedInVersion: 8.3.1


  Name: Haneef Mohammed

  Comments:
  We in our organization moved from a primarily Unix platform to
      a windoze platform and everybody is so used to this Xmouse behaviour.
      I am trying to move our development to Tcl/Tk but it has not been
      received very well by the end users because of this (in my opinion
      minor irritant).

  ReproducibleScript:
  1. Enable Xmouse on your Windows. You can do this using TweakUI
     (in Control Panel) in the Mouse Tab. You can install TweakUI from
     the Windows 98 PLUS CD. You can apparently also enable Xmouse on Win95
     and WinNT4.0 by setting the following registry entry...
         \My Computer\HKEY_CURRENT_USER\Control Panel\Mouse = 0x1
  2. When Xmouse is enabled, the top level windows get activted (and get
     focus) when the mouse moves over the window without raising that window.
  3. Invoke Wish. This will create two top level windows. Arrange these windows
     such that they overlap somewhat.
  4. Activate one of the Wish top levels and now move your mouse (without
     clicking) from one window to the other. You will notice that these windows
     are automatically raising themselves. This is not correct behaviour
  5. Now activate some other window. Notice that you can activate any non-tk
     window just by moving your mouse over it.
  6. Move the mouse back to any tk window. You will notice that the Tk windows
     never activate unless you actually click your mouse in it. This is also
     not correct behaviour.

  ObservedBehavior:
  1. Top level windows should not auto-raise just because they
     get activated.

  2. The WM_MOUSEACTIVATE event should be handled just like the
     Windows Default procedure does.

  3. I have tried the tk_focusFollowsMouse but that only seems to work
     within the Tk window hierarchy.

  DesiredBehavior:
  The problem is with the handling of WM_MOUSEACTIVATE, in win/tkWinWm.c
  If I let the DefWindowProc handle this event, everything works fine. But
  seems like Tk wanted to handle this event itself (I guess to emulate
  grabbing properly). I do not know enough about Tk to be able to fix this
  bug myself. I have already documented the expected behaviour in my instructions
  to duplicate the problem.



  Verified with 8.3.0 on NT with TweakUI 1.1. 
  -- 04/25/2000 hobbs
  Fixed for 8.3.1 (see related bug 2272). 
  -- 04/25/2000 hobbs


tkt_uuid: 220728ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Alt-octal sequence doesn't generate correct char on Windows
comment:
  OriginalBugID: 5088 Bug
  Version: 8.3
  SubmitDate: '2000-04-14'
  LastModified: '2000-04-18'
  Severity: SER
  Status: Released
  Submitter: hobbs
  ChangedBy: hobbs
  RelatedBugIDs: 5144
  OS: All Windows
  FixedDate: '2000-04-18'
  FixedInVersion: 8.3.1


  One thing I would like to mention:
  if pressing Alt <Numeric keypad> combinations the keys
  under Alt 199 are ok, but for example Alt 225 (which is a german ssharp ß)
  is not ok.
  You can simply compare it with notepad.


  I may have a partial fix for this:

  in tkWinPointer.c (TkWinGetModifierState()), change the VK_MENU test to or in ALT_MASK instead of Mod2Mask

  in tkBind.c (MatchPatterns()), add magic in the patPtr->needMods != 0 test that swaps the ALT_MASK bits in the "state" variable with the dispPtr->altModMask bits.

  - eric

  -- 04/14/2000 ericm

  It seems the above was all that was needed.  This fix will go out with 8.3.1.

  - eric

  -- 04/18/2000 ericm


tkt_uuid: 220729ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: 'ctrl-backspace' appears as 'ctrl-???' in bindings
comment:
  OriginalBugID: 5090 Bug
  Version: 8.3
  SubmitDate: '2000-04-14'
  LastModified: '2000-04-14'
  Severity: MED
  Status: Released
  Submitter: ericm
  ChangedBy: ericm
  OS: All Windows
  FixedDate: '2000-04-14'
  FixedInVersion: 8.3.1


  bind . <KeyPress> [list puts stdout "You pressed %K"]

  Go to the '.' window, hit 'backspace' a few times, then hit control-
  backspace a few times.  I get the following output with Tk 8.3.0 (_not_
  with 8.2.x)

  ObservedBehavior:
  You pressed BackSpace
  You pressed BackSpace
  You pressed BackSpace
  You pressed BackSpace
  You pressed Control_L
  You pressed ??
  You pressed ??
  You pressed ??
  %

  DesiredBehavior:
  Tk 8.2.3 gives:
  % bind . <KeyPress> [list puts stdout "You pressed %K"]
  You pressed BackSpace
  You pressed BackSpace
  You pressed BackSpace
  You pressed Control_L
  You pressed BackSpace
  You pressed BackSpace
  You pressed BackSpace
  You pressed BackSpace


  This was a side effect of the dead-key handling that was added in Tcl/Tk 8.3.0.  The Windows implementation was using a more correct Windows API call to get some information about the key that was pressed, and the code was not handling all the possible returns from that API call.

  I fixed this in CVS, and the fix will go out with 8.3.1.

  W.R.T. the delay in this bug showing up, it seems that this bug report slipped through the cracks -- we were having some server difficulties around the time that you submitted it, and it may just not have made it through.

  - eric


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


  Name:
  Rob Barris

  Extensions:
  Stock 8.3.0 download

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

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

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

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

  PowerPC unmapped memory exception at 3D57C444 GenerateKeyEvent+0014C

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

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



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


tkt_uuid: 220731ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: menu entry deletion
comment:
  OriginalBugID: 5275 Bug
  Version: 8.2.3
  SubmitDate: '2000-04-26'
  LastModified: '2000-07-27'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 1960
  OS: All
  FixedDate: '2000-07-27'
  FixedInVersion: 8.4a2


  Name:
  Tsutomu Hoshino

  Comments:
  The problem I found is at line #3400 in
      DeleteMenuCloneEntries() function in tk8.2.3/generic/tkMenu.c.
      
        for (i = last + 1; i < menuListPtr->numEntries; i++) {
            int j = ;
            menuListPtr->entries[i - numDeleted] = menuListPtr->entries[i];
            menuListPtr->entries[i - numDeleted]->index = i;  /* HERE */
        }
      
      It seems like the "i" here should be replaced with "i - numDeleted".
      Once I replaced it with "i - numDeleted", the bug seems to be fixed

  ReproducibleScript:
  I have found a bug that deleting an entry in a torn-off menu makes
  menu entries not behave correctly. This occurs on all platforms of
  IRIX, Linux, and Windows98.  I checked this with Tcl/tk-8.2.3 and
  TclPro 1.3.

  What you have to do is:
  1. Make a torn-off menu by selecting the tear-off entry.
  2. Click the "Add an entry" button 5 times or more.
  3. Make sure it prints a "#* pressed" message in response
     to a left mouse click.
  4. Delete the entry labeled "Entry #2" by clicking it with the
     right mouse button.
  5. Click "Entry #3" or "Entry #4". It doesn't print the "#* pressed"
     message anymore.

  Here is the script to test. 
  ----------------------------------------------------------------
  #!/bin/sh
  #  exec prowish82 "$0" "$@"

  option add *tearOffCommand tearOffCommand
  set menu .mb.m
  pack [menubutton .mb -relief raised -text {Menu Add/Remove} -menu $menu]
  menu $menu
  $menu add command -label Quit -command {destroy .}
  $menu add command -label {Add an entry} -command addMenu
  set num 0
  proc addMenu {} {
      global num
      global menu
      $menu add command -label "Entry #$num" -command "puts \"#$num pressed\""
      incr num
  }
  proc tearOffCommand {w w_tearOff} {
      $w configure -tearoff 0
      bind $w_tearOff <Destroy> "$w configure -tearoff 1"
      bind $w_tearOff <ButtonRelease-3> {
  set index [%W index active]
  if {$index<2} break  ;# to avoid deleting the first two entries.
  puts "last=[$menu index last] before removing $index"
  %W delete $index
  puts "last=[$menu index last] after removing $index"
  break
      }
  }

  ObservedBehavior:
  If you run the above script with wish8.2 or prowish82, entries
  below the entry deleted won't behave correctly anymore and sometimes
  wish program crashes.



  Nice job finding and fixing this bug.  I applied your fix to the sources in CVS, and it will go out with Tcl/Tk 8.4a2.  Thanks!

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

  -- 06/27/2000 ericm


tkt_uuid: 220732ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: menu 'separators' take up too much vertical space
comment:
  OriginalBugID: 5303 Bug
  Version: 8.3
  SubmitDate: '2000-05-01'
  LastModified: '2000-05-09'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  OSVersion: 4.0sp5
  FixedDate: '2000-05-09'
  FixedInVersion: 8.4a1


  Name:
  Vince Darley

  CVS:
  latest 8.3.1

  Comments:
  '8.3.1' is not a version you can select in the bug form...

  ReproducibleScript:
  Menu separators in Tk 8.3.1 now take up as much vertical space as a regular menu item.  This is different to Tk 8.2 or any common windows application, for which separators are 2-4 pixels smaller in height.  Visually this makes Tk's menus look not quite as nice.

  I assume this was introduced in:

  2000-04-13  Eric Melski  <ericm@scriptics.com>
  * win/tkWinMenu.c: Corrected code that created separator items on
  menus; originally, it requested that the system be responsible for
  drawing those items, so it would ignore configuration items like
  the widget background.  Now, we draw the separators ourselves (as
  we do with every other kind of menu item already). [Bug: 1166].

  DesiredBehavior:
  This is obviously only a cosmetic issue, but I'd like to see separators in Tk menus look the same as in other applications.



  Verified with 8.3.1.  The place to fix this is in GetMenuSeparatorGeometry in tkWinMenu.c.  Currently we use the menu font linespace as the height of the separator space.  Instead it should be

  linespace - (2 * descent)

  The menu drawing code could stand some more geometry tweaking as well, but I fixed the separator issue as best I could given the minor inaccuracies in the other code.  At least it looks correct with the default Windows system menu font.  This fix will go out with 8.4a1.

  - eric

  -- 05/09/2000 ericm


tkt_uuid: 220733ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 59. [tk_focus*]
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: Bug in library file focus.tcl
comment:
  OriginalBugID: 5372 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-05'
  LastModified: '2000-05-09'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 6209
  OS: Linux-SuSE
  FixedDate: '2000-05-09'
  FixedInVersion: 8.4a1


  Name:
  Csaba Nemethi

  Comments:
  In Tk 8.3.1, line 139 of the library file focus.tcl was changed from
      
          set value [uplevel #0 $value $w]
      
      into
      
          set value [uplevel #0 [list $value $w]]
      
      This is BAD because it restricts the "value" passed to uplevel to be a
      single
      word.  In the above example, it caused the correct statement
      
          set value [uplevel #0 p 1 .e2]
      
      to be replaced with
      
          set value [uplevel #0 {{p 1} .e2}]
      
      which, obviously, cannot work.
      
      The change in the file focus.tcl was made in the intention to support
      widget
      names containing spaces and other special characters, as suggested in
      Bug
      Report #4208.  This bug report requested to change line 139 of the file
      into
      
          set value [uplevel #0 $value [list $w]]
      
      which is quite different from what is contained in version 8.3.1.  That
      is, the
      patch was applied incorrectly!
      
      Maybe the above example is somewhat artificial, but there are quite
      normal
      cases where the value of the -takefocus option has more than one word.
      For
      example, the keyboard traversal in my Mentry package doesn't work any
      longer
      under Tk 8.3.1.  Fortunately, I have found a workaround, which will be
      contained in the next version (which I am going to release in the next
      few
      days).  I am not sure, however, whether or not any other packages or
      applications are similarly affected by this improperly performed bug
      fix, which
      has produced another bug.

  ReproducibleScript:
  Consider the following simple script, which worked in all Tk releases prior to
  8.3.1:

      proc p {arg w} {
          return $arg
      }

      entry .e1
      entry .e2 -takefocus {p 1}
      pack .e1 .e2

  ObservedBehavior:
  When traversing to the second entry with Tab, the following error
  message is displayed:

      invalid command name "p 1"
          while executing
      "{p 1} .e2"
          ("uplevel" body line 1)
          invoked from within
      "uplevel #0 [list $value $w"
          (procedure "tkFocusOK" line 9)
          invoked from within
      "tkFocusOK $cur"
          (procedure "tk_focusNext" line 36)
          invoked from within
      "tk_focusNext .e1"
          invoked from within
      "tkTabToWindow [tk_focusNext .e1]"
          (command bound to event)

  DesiredBehavior:
  The script should not raise any error.



  The list is still needed around the $w, but shouldn't have been
  placed around the $value.  Fixed for 8.4a1. 
  -- 05/09/2000 hobbs


tkt_uuid: 220734ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: Tcl/Tk 8.3 documentation errors
comment:
  OriginalBugID: 5396 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-09'
  LastModified: '2000-05-22'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  FixedDate: '2000-05-22'
  FixedInVersion: 8.4a1


  Name:
  Colin McDonald

  Comments:
  Although mostof these points are minor, the quality of the Tcl
      documentation has been one of its major strengths, and I would not like
      to see that diminished.  It is extremely important as regards the
      impression given to new users. In particular I found the updated photo
      command documentation confusing at first.

  ReproducibleScript:
  I have found the following documentation errors introduced in Tcl/Tk 8.3

  scan
  ====

  The scan synopsis should be:

  scan string format ?varName varName ...? 

  in order to indicate that no variable names are specified for inline mode.

  array unset
  ===========

  This command always returns an empty string, which is not the impression given by the documentation.  Could be reworded as follows:

  Unsets all of the elements in the array that match pattern (using the matching rules of string match).  If arrayName isn't the name of an array variable or there are no matching elements in the array, then the command completes without erroring.  If pattern is omitted and arrayName is an array variable, then the command unsets the entire array. The command result returns an empty string.

  listbox
  =======

  The new option name is -listvariable, not -listvar.

  Canvas DASH PATTERNS
  ====================

  "position" not "posibion"

  Last paragraph should be:

  On systems which support only a limited set of dash patterns, the dash pattern will be displayed as the closest dash pattern that is available. For example, on Windows only the first 4 of the above examples are available. The last 2 examples will be displayed identically to the first one. 

  Canvas COMMON ITEM OPTIONS
  ==========================

  -disableddash indicates the dash options apply only to arcs.  Should be:

  This option specifies dash patterns for an item's outine in its normal, active and disabled states.

  How is -dashoffset specified - Pixels? Index into the dash list?  And how does it affect the resulting dash pattern?

  -offset - "instead" not "in stead".

  -disabledwidth description contains "For arcs, wide outlines will be drawn centered on the edges of the arc's region".  What about the other item types?  I think that there used to be information about wide outline handling included in the individual item descriptions, which has now been lost.  Generally wide outlines are centered on the requested coordinates.

  Bind MODIFIERS
  ==============

  Support for <Quadruple> clicks has been added, but not documented in the bind modifier list.

  photo
  =====

  The data sub-command -format and -from options mention writing the image to a file - all references for this sub-command should be to returning the image data in a string.

  The put sub-command description and options repeatedly describe reading image data from a file, whereas this sub-command actually obtains the data from a string argument.

  Entry VALIDATION
  ================

  "possible" not "posible"

  label
  =====

  The -disabledforeground and -state options have been added to the label widget in Tk 8.3.1, but the manual page has not been updated.

  The "last change" version number has not been updated for some man pages.



  Docs updated for 8.4a1. 
  -- 05/22/2000 hobbs


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: 220736ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: proj.test causes wish to crash on windows
comment:
  OriginalBugID: 5438 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-10'
  LastModified: '2000-05-12'
  Severity: MED
  Status: Released
  Submitter: wart
  ChangedBy: hobbs
  OS: Windows NT
  FixedDate: '2000-05-12'
  FixedInVersion: 8.4a1
  ClosedDate: '2000-05-11'


  The tcldebugger test suite is run as part of nightly builds.  I consistenly see the proj.test cause wish to crash (the windows equivalent of a core dump).  This does not happen when run with a Debug build, only with a Release build.

  Steps to reproduce:

  Go to a nightly test area:
    % cd /home/build/WS/ws-happybox-20000507-2300/connect2.0/xmlserver/win32-ix86/Release
  Run the tcldebugger tests proj-14.5 and proj-14.6:
    % make tcldebugger-test TCLTESTARGS="-file proj.test -match proj-4.[56]"

  Result:

  A windows dialog pops up indication that wish has crashed.

  Expected result:

  Tests pass with no problems.

  It's interesting to note that the tests pass when run individually, but when both proj-4.5 and proj-4.6 are run together, wish crashes.



  Additional note:  This also happens when running the tcldebugger tests from a TclPro build.

  Mitch has also noticed a similar problem with his tclide post.test tests.

  --Mike
  --
  This turned out to be timing sensitive, and was caused by the
  tkWinWm.c:RaiseWinWhenIdle not accounting for the TK_DONT_DESTROY_WINDOW
  flag in addition to TK_ALREADY_DEAD.  This will go into 8.4a1, but it
  is also on the core-8-3-1-branch tag for Tk. 
  -- 05/12/2000 hobbs


tkt_uuid: 220737ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: Bad separators in windows system menu
comment:
  OriginalBugID: 5451 Bug
  Version: 8.4a1
  SubmitDate: '2000-05-11'
  LastModified: '2000-05-16'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 5303
  OS: All Windows
  FixedDate: '2000-05-16'
  FixedInVersion: 8.4a1


  Name:
  Peter Spjuth

  ReproducibleScript:
  menu .m
  .m add cascade -menu .m.system
  menu .m.system -tearoff 0
  .m.system add separator
  .m.system add command -label "Hej"
  .m.system add separator
  .m.system add command -label "Exit" -command exit
  . configure -menu .m

  ObservedBehavior:
  The separators in the system menu does not look like separators anymore.
  I guess this is related to the same change that caused Bug Id 5303.



  Verified in 8.4a1 CVS of 15 May. 
  -- 05/15/2000 hobbs

  What a tangled web these Windows menus are.  In fixing another separator bug [Bug 5303], I had removed the MF_SEPARATOR bit from all separator entries.  Since we were drawing them ourselves now, I didn't think it was needed.  Of course, we don't draw the system menu, and without that bit, the system wouldn't draw the separators properly.  I added the bit back in, and the problem is now fixed in CVS.

  - eric

  -- 05/16/2000 ericm


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


  Tk8.3.1 cores on the following script:


    toplevel .one

    menu .one.m

    toplevel .two -screen :1

    menu .two.m

    destroy .one


  The output of this script is:


    Tk_Get3DBorderFromObj called with non-existent border!

    Aborted (core dumped)


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

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

  running the script above I did this:


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


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

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

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

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

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

  *** 501,506 ****

  --- 501,507 ----

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

    {

        Tk_Free3DBorder(Tk_Get3DBorderFromObj(tkwin, objPtr));

  +     FreeBorderObjProc(objPtr);

    }

    

    /*

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

  *** 1263,1299 ****

    InitBorderObj(objPtr);

        }


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

  !     if (borderPtr != NULL) {

  ! if ((borderPtr->resourceRefCount > 0)

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

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

  !     /*

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

  !      * Just return it.

  !      */


  !     return (Tk_3DBorder) borderPtr;

  ! }

  ! hashPtr = borderPtr->hashPtr;

  ! FreeBorderObjProc(objPtr);

  !     } else {

  ! hashPtr = Tcl_FindHashEntry(&dispPtr->borderTable, 

  !                 Tcl_GetString(objPtr));

  ! if (hashPtr == NULL) {

  !     goto error;

  ! }

        }


        /*

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

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

         */

  ! 

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

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

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

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

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

        borderPtr->objRefCount++;

        return (Tk_3DBorder) borderPtr;

  --- 1264,1311 ----

    InitBorderObj(objPtr);

        }


  !     /*

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

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

  !      * structure we need will be cached in the internal

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

  !      */


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

  !     if ((borderPtr != NULL)

  !     && (borderPtr->resourceRefCount > 0)

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

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

  ! /*

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

  !  * Just return it.

  !  */

  ! return (Tk_3DBorder) borderPtr;

        }


  + 

  + 

  + 

        /*

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

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

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

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

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

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

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

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

  !      * the right TkBorder structure.

         */

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

  !     if (hashPtr == NULL) {

  ! goto error;

  !     }

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

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

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

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

  +      FreeBorderObjProc(objPtr);

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

        borderPtr->objRefCount++;

        return (Tk_3DBorder) borderPtr;

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

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

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

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

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

  *** 540,545 ****

  --- 540,546 ----

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

    {

        Tk_FreeColor(Tk_GetColorFromObj(tkwin, objPtr));

  +     FreeColorObjProc(objPtr);

    }

    

    /*

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

  *** 646,682 ****

    InitColorObj(objPtr);

        }


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

  !     if (tkColPtr != NULL) {

  ! if ((tkColPtr->resourceRefCount > 0)

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

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

  !     /*

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

  !      * Just return it.

  !      */


  !     return (XColor *) tkColPtr;

  ! }

  ! hashPtr = tkColPtr->hashPtr;

  ! FreeColorObjProc(objPtr);

  !     } else {

  ! hashPtr = Tcl_FindHashEntry(&dispPtr->colorNameTable, 

  !                 Tcl_GetString(objPtr));

  ! if (hashPtr == NULL) {

  !     goto error;

  ! }

        }


        /*

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

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

         */

  ! 

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

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

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

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

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

        tkColPtr->objRefCount++;

        return (XColor *) tkColPtr;

  --- 647,687 ----

    InitColorObj(objPtr);

        }


  +     /*

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

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

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

  +      */

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

  !     if ((tkColPtr != NULL)

  !     && (tkColPtr->resourceRefCount > 0)

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

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

  ! /*

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

  !  * Just return it.

  !  */


  ! return (XColor *) tkColPtr;

        }


        /*

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

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

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

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

  !      * list looking for the right TkColor structure.

         */

  !     hashPtr = Tcl_FindHashEntry(&dispPtr->colorNameTable, 

  !     Tcl_GetString(objPtr));

  !     if (hashPtr == NULL) {

  ! goto error;

  !     }

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

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

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

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

  +     FreeColorObjProc(objPtr);

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

        tkColPtr->objRefCount++;

        return (XColor *) tkColPtr;

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

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

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

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

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

  *** 561,566 ****

  --- 561,567 ----

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

    {

        FreeCursor(GetCursorFromObj(tkwin, objPtr));

  +     FreeCursorObjProc(objPtr);

    }

    

    /*

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

  *** 696,723 ****

    InitCursorObj(objPtr);

        }


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

  !     if (cursorPtr != NULL) {

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

  !     return cursorPtr;

  ! }

  ! hashPtr = cursorPtr->hashPtr;

  !     } else {

  ! hashPtr = Tcl_FindHashEntry(&dispPtr->cursorNameTable, 

  !                 Tcl_GetString(objPtr));

  ! if (hashPtr == NULL) {

  !     goto error;

  ! }

        }


        /*

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

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

         */

  ! 

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

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

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

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

        cursorPtr->objRefCount++;

        return cursorPtr;

  --- 697,726 ----

    InitCursorObj(objPtr);

        }


  +     /*

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

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

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

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

  +      */

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

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

  ! return cursorPtr;

        }


        /*

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

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

         */

  !     hashPtr = Tcl_FindHashEntry(&dispPtr->cursorNameTable,

  !     Tcl_GetString(objPtr));

  !     if (hashPtr == NULL) {

  ! goto error;

  !     }

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

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

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

  +     FreeCursorObjProc(objPtr);

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

        cursorPtr->objRefCount++;

        return cursorPtr;

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

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

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

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

  *** 2438,2457 ****


    # menu-34 MenuInit only called at boot time


    # cleanup

    deleteWindows

    ::tcltest::cleanupTests

    return

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  - 

  --- 2438,2458 ----


    # menu-34 MenuInit only called at boot time


  + # creating menus on two different screens then deleting the

  + # menu from the first screen crashes Tk8.3.1

  + #

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

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

  +     toplevel .one

  +     menu .one.m

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

  +     menu .two.m

  +     destroy .one

  +     destroy .two

  +   }

  + } {}

  + 

    # cleanup

    deleteWindows

    ::tcltest::cleanupTests

    return




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


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

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


  This was a request from Hilen Amin from Integral

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

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

  Doubt this can be done for 2.0.

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

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

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

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

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

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

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


