# ticket

tkt_uuid: 2831084fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 1 Zero
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: "configure" lists takefocus twice on some ttk::*buttons
comment:
  Invoking configure on a ttk::button,  ttk::checkbutton or ttk::radiobutton lists the takefocus option twice with different values.

  WIDGET_TAKES_FOCUS is redundant with WIDGET_INHERIT_OPTIONS(BaseOptionSpecs)   in ttkButton.c

  Possible fixes :  
     * WIDGET_INHERIT_OPTIONS(BaseOptionSpecs)  checks for duplicates and does not override existing value.
     * -takefocus should not be in ttkCoreOptionSpecs


tkt_uuid: 1941740fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 34. [tk_chooseColor]
priority: 5 Medium
foundin: None
resolution: Fixed
title: tk_chooseColor -title doesn't work on Win XP
comment:
  The -title option for tk_chooseColor doesn't seem to have any effect on Windows XP SP2 (using the native Windows dialog), it always comes up with the title "Color" regardless. Not sure if it's a bug, or just not possible to change on Windows and the documentation needs updating to reflect that..


tkt_uuid: 836483ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 8
foundin: obsolete: 8.4.4
resolution: Fixed
title: listbox itemconfigure causes a memory leak
comment:
  The following tcl program causes a memory leak. The 
  leak is because of the ".lst itemconfigure" lines:


  proc start {} {
      listbox .lst -background White -yscrollcommand 
  {.scrly set} -xscrollcommand {.scrlx set}
      scrollbar .scrly -command {.lst yview}
      scrollbar .scrlx -command {.lst xview} -orient 
  horizontal
      grid columnconf . 0 -weight 1
      grid rowconf . 0 -weight 1
      grid .lst -in . -column 0 -row 0 -sticky swne
      grid .scrly -in . -column 1 -row 0 -sticky ns
      grid .scrlx -in . -column 0 -row 1 -sticky ew
      bind .lst <<ListboxSelect>> {.lst selection clear 0 
  end}

      for {set x 0} {$x<10000000} {incr x} {
          for {set y 0} {$y<100} {incr y} {
              .lst insert end  "$x: iteration $y"
              .lst itemconfigure $y -foreground #888888
              .lst itemconfigure $y -selectbackground #4444ff
              update
          }
          .lst delete 0 end
      }
  }

  start


tkt_uuid: 1509288fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 07. [entry]
priority: 7 High
foundin: None
resolution: Fixed
title: entry widget <<Clear>> virtual event
comment:
  The entry widget has the following binding for the
  <<Clear>> virtual event (file library/entry.tcl):

  bind Entry <<Clear>> {
      %W delete sel.first sel.last
  }

  This gives an error when the selection is not in the
  entry widget. I believe this should be catched (it is
  done this way for the text widget too):

  bind Entry <<Clear>> {
      catch {%W delete sel.first sel.last}
  }


tkt_uuid: 220410ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: Copying and pasting from Tk Windows to other applications mangles double-byte text
comment:
  OriginalBugID: 935 Bug
  Version: 8.1a2
  SubmitDate: '1998-12-04'
  LastModified: '1998-12-08'
  Severity: SER
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Windows NT
  OSVersion: 4.0 Japanese
  Machine: X86
  FixedDate: '1998-12-08'
  FixedInVersion: 8.1b1


  Name:

  Syd Polk


  CVS:

  win/tkWinClipboard.c 1.1.4.2


  ReproducibleScript:

  On Windows NT4.0J, copy some text with Japanese in it from Notepad and paste it into a text widget.


  ObservedBehavior:

  The characters are mangled. Same thing the other direction.


  DesiredBehavior:

  The same text in both Notepad and the text widget.


  Patch:

  *** tkWinClipboard.cFri Dec  4 16:06:36 1998

  --- tkWinClipboard.c.newFri Dec  4 16:06:15 1998

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

  *** 50,55 ****

  --- 50,56 ----

        ClientData clientData;/* Arbitrary value to pass to proc. */

    {

        char *data, *buffer, *destPtr;

  +     Tcl_DString selDString;

        HGLOBAL handle;

        int result, length;


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

  *** 72,79 ****

    *destPtr = '\0';

    GlobalUnlock(handle);

    CloseClipboard();

  ! result = (*proc)(clientData, interp, buffer);

    ckfree(buffer);

    return result;

        }

        CloseClipboard();

  --- 73,83 ----

    *destPtr = '\0';

    GlobalUnlock(handle);

    CloseClipboard();

  ! Tcl_ExternalToUtfDString(NULL, buffer, -1, &selDString);

    ckfree(buffer);

  + result = (*proc)(clientData, interp, 

  + Tcl_DStringValue(&selDString));

  + Tcl_DStringFree(&selDString);

    return result;

        }

        CloseClipboard();

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

  *** 162,169 ****

        TkClipboardTarget *targetPtr;

        TkClipboardBuffer *cbPtr;

        HGLOBAL handle;

  !     char *buffer, *p, *endPtr;

        int length;


        for (targetPtr = dispPtr->clipTargetPtr; targetPtr != NULL;

        targetPtr = targetPtr->nextPtr) {

  --- 166,174 ----

        TkClipboardTarget *targetPtr;

        TkClipboardBuffer *cbPtr;

        HGLOBAL handle;

  !     char *buffer, *p, *rawText, *endPtr;

        int length;

  +     Tcl_DString selDString;


        for (targetPtr = dispPtr->clipTargetPtr; targetPtr != NULL;

        targetPtr = targetPtr->nextPtr) {

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

  *** 183,193 ****

        }

    }

        }

  !     handle = GlobalAlloc(GMEM_MOVEABLE|GMEM_DDESHARE, length+1);

  !     if (!handle) {

  ! return;

  !     }

  !     buffer = GlobalLock(handle);

        if (targetPtr != NULL) {

    for (cbPtr = targetPtr->firstBufferPtr; cbPtr != NULL;

    cbPtr = cbPtr->nextPtr) {

  --- 188,194 ----

        }

    }

        }

  !     buffer = rawText = ckalloc(length + 1);

        if (targetPtr != NULL) {

    for (cbPtr = targetPtr->firstBufferPtr; cbPtr != NULL;

    cbPtr = cbPtr->nextPtr) {

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

  *** 201,207 ****

  --- 202,219 ----

    }

        }

        *buffer = '\0';

  +     Tcl_UtfToExternalDString(NULL, rawText, -1, &selDString);

  +     ckfree(rawText);

  +     handle = GlobalAlloc(GMEM_MOVEABLE|GMEM_DDESHARE, 

  +     Tcl_DStringLength(&selDString)+1);

  +     if (!handle) {

  + return;

  +     }

  +     buffer = GlobalLock(handle);

  +     memcpy(buffer, Tcl_DStringValue(&selDString), 

  +     Tcl_DStringLength(&selDString) + 1);

        GlobalUnlock(handle);

  +     Tcl_DStringFree(&selDString);

        SetClipboardData(CF_TEXT, handle);

        return;

    }


  PatchFiles:

  win/tkWinClipboard.c


tkt_uuid: 409172ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Fixed
title: transient toplevel windows crash 8.3.2
comment:
  Initial Comment:
  The following short script crashes tcl/tk 8.3.2 under windows 98

  --- BEGIN SCRIPT ---
  update idletasks
  toplevel .foo
  # update idletasks ;#  <--  THIS WORKS AROUND
  # set z 0
  # button .foo.x -command {global z; set z 1;}
  # pack .foo.x
  wm transient .foo .
  tkwait variable z
  # exit
  --- END SCRIPT ---


  Setup:
  I have verified this crash under Windows 98 with tcl 8.3.2 and 8.4a2.  It does not crash 8.2.1.
  I have received reports that it also crashes under Windows 2000 and Windows ME using 8.3.2.

  Reproduction:

  Save the script to a file named "something.tcl" and double click on that file from explorer
  OR
  Create a shortcut that runs "c:\path\to\wish83.exe something.tcl" and click on that shortcut

  The crash only occurrs when this script is run directly via a shortcut or double-clicking a tcl file 
  directly;  starting the wish interpreter first and source-ing or pasting the script will NOT cause the 
  crash.  


  Expected result:
  As is, 2 windows should appear, one of which is transient.

  The commented out lines are necessary for the script to be sane, but not for the crash.

  Actual result:
  Windows popup saying  "This program has performed an illegal operation and will be shut down"

  Additional information:
  The indicated line will prevent the crash when uncommented.

  The indicated line prevents the crash from occurring.


tkt_uuid: 572134ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 86. Test Tools
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: remove unnecessary tcltest dependence
comment:
  The building of the tktest executable depends on the
  existence of a tcltest executable and several of the
  object files that make up the Tcltest module.

  However, the tktest executable does not actually use
  any of the features provided by Tcltest.  This
  dependence is apparently due to the
  Tcltest_Init() call inside tkAppInit.c, that can be removed
  with no change in the behavior of tktest.

  I have mods implementing this fix, and I'll attach them
  here as soon as SF CVS come back to life and I
  can generate the patch.


tkt_uuid: 2128087fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: None
title: menubutton menu-traversal shortkeys doesn't work
comment:
  Please run by wish the following script under win32. The menu-traversal shortkey
  doesn't work, but it works fine under linux :)

  Thank you all.

  lz_ufo@tin.it


  #################################################################################
  #!/usr/bin/wish

  frame .f
  pack .f -fill x

  frame .f2
  pack .f2


  # the "-underline 0" switch should create a menu-traversal shortkey.
  # Then using alt-f we aspect to open the menu.
  # It works in linux, but not in win32 :(
  #
  menubutton .f.mb -text "File" -underline 0 -menu .f.mb.m

  menu .f.mb.m -tearoff 0


  .f.mb.m add command -label "dummy" -underline 0 -command {
  }

  .f.mb.m add command -label "exit" -underline 0 -command {
          exit
  }

   
  pack .f.mb -side left

  label .f2.l -text "sample"
  pack .f2.l -side bottom


  focus -force .f
  update
  ##########################################################


tkt_uuid: 1424513fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.4.12
resolution: Fixed
title: listbox crash caused by listvariable in a namespace
comment:
  Consider the following simple script:

  namespace eval test {
      variable foo {bar0 bar1}
  }

  listbox .lb -listvariable ::test::foo
  pack .lb

  namespace delete test
  .lb insert end bar2 bar3

  On my PC running SUSE LINUX 9.3, this script generates
  the following error message:

  Error in startup script: 
      while executing
  ".lb insert end bar2 bar3"
      (file "Bug.tcl" line 10)
  Segmentation fault

  If I set an own trace on the variable ::test::foo then
  the behavior becomes even worse:

  namespace eval test {
      variable foo {bar0 bar1}
  }
  proc tracer {args} {
      puts "tracer called"
  }

  listbox .lb -listvariable ::test::foo
  pack .lb

  trace add variable ::test::foo unset tracer
  namespace delete test
  .lb insert end bar2 bar3

  This version of the script generates the following output:

  Error in startup script: 
      while executing
  ".lb insert end bar2 bar3"
      (file "Bug.tcl" line 14)
  *** glibc detected *** free(): invalid pointer:
  0x080af108 ***

  One could argue that it is not expected to delete a
  namespace containing a listvariable.  On the other
  hand, IMHO, doing so must not cause a crash.


tkt_uuid: 1200934fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: None
resolution: None
title: Entry selection with -textvariable
comment:
  There is a bad side effect of -textvariable's entry when 
  text is selected. While the text change when setting the 
  variable, the selection does not change:

  package require Tk
  pack [entry .e -textvariable v]
  set v "test"
  .e selection range 0 end
  set v "test_test"

  A solution could be to check the selection in 
  EntryTextVarProc(), and:
     * if the selection includes all current text, reselect all 
  the text after changing to new text.
     * otherwise, clear the selection.


tkt_uuid: 922336ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Tk apps have no maximize window button under KDE-3.2.1
comment:
  After upgrading to KDE-3.2(.1), Tk applications do not  
  have "maximize window" button anymore (only 
  "minimize" and "terminate" buttons). Application 
  window can still be resized by hand, though. Other 
  toolkits, such as Gtk, don't suffer from a similar problem, 
  so I suspect some incompatibility between new kwm and 
  Tk's WM code. 
   


tkt_uuid: 3572016fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: Fixed
title: Aqua menus do not get re-enabled
comment:
  Try the following using Tk 8.6b3 (Tk-Cocoa) on OS X (happens in OS X 10.7 and 10.8 at least). This works with any of the wish menus apart from the "Wish" menu itself:

  1. Launch wish
  2. Select one of the wish menus and see that the items are enabled
  3. type into the console: "tk_chooseColor"
  3. while the dialog is open: select one of the wish menus and see that the items are disabled
  4. dismiss the color dialog
  5. select one of the wish menus and see that the items are still disabled

  At step 5, the menus should be enabled again, but they are not. If you do the same sequence but skip step 3, then everything is OK. So it seems that choosing a menu while a modal dialog is open will correctly show disabled menu items but the menu will never be re-enabled afterwards.

  This happens not only in plain wish but also with custom menus from [. configure -menu]


tkt_uuid: 2904114fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Duplicate
title: Aqua menubutton checkbutton indicator not showing properly
comment:
  Using Tcl 8.5.8, the following code works properly, i.e. the indicators for the checkbutttons are shown where the corresponding variable is 1 and the indicator is not shown, where the corresponding variable is 0:

  menubutton .m -text test -menu .m.f
  pack .m -padx 20 -pady 20
  menu .m.f
  .m.f add checkbutton -label entryOn -variable v1 -command {puts $v1}
  set v1 1
  .m.f add checkbutton -label entryOff -variable v2 -command {puts $v2}
  set v2 0

  In the current Tcl 8.6b1.1 (directly from cvs), none of the indicators are shown and can not be switched on by selecting the entry in the menubutton. It works OK in the X11 build for Mac, but not in the Aqua build (embedded build, if that matters). So the problem seems to be in the Aqua code.


tkt_uuid: 1408279fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: None
title: (sub)menus do not automatically open when mouse over
comment:
  With TK 8.5a4, (sub)menus do not autmatically open 
  when the mouse is over them.  
  This was the the behaviour of TK 8.4, and it's really   
  better than having to click each (sub)menu entry to 
  open it.   
    
  Is this a feature or a bug?  
    


tkt_uuid: 220327ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 1 Zero
foundin: obsolete: 8.3.2
resolution: Invalid
title: -cursor "c:/my temp/mycursor.cur" fails due to space in path
comment:
  OriginalBugID: 6343 Bug
  Version: 8.3.2
  SubmitDate: '2000-10-06'
  LastModified: '2000-10-11'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  ClosedDate: '2000-10-11'


  Name:
  Christian Heide Damm

  ReproducibleScript:
  Run wish and type
      . configure -cursor "@c:/my temp/mycursor.cur"

  (assuming, of course, that there are directories and files called "my temp" and 
  "mycursor.cur")

  ObservedBehavior:
  bad cursor spec "@c:/my temp/mycursor.cur"
     (processing "-cursor" option)
     invoked from within
  ". configure -cursor "@c:/my temp/mycursor.cur""
     (file "myfile.tcl" line X)



  As discussed on comp.lang.tcl, this is not a bug, but a sensitive configuration issue.  -cursor is expecting a list, and 
  "@c:/my temp/mycursor.cur" is a two element list.  According to Tk_GetCursor, that means it will try to interpret it as "@sourcename fgColor".  On the other hand, "@c:/my\ temp/mycursor.cur" is a one element list.  Unfortunately the [list] command doesn't do the right thing in this case, because it just wants to add {}s in places that Tk_GetCursor doesn't understand.  So you can either do the -shortname, or specific '\ ' on spaces.

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

  -- 10/11/2000 ericm


tkt_uuid: 220125ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: Would like an option to raise the window to the top of the global stack
comment:
  OriginalBugID: 1175 RFE
  Version: 8.0.5
  SubmitDate: '1999-02-10'
  LastModified: '1999-08-13'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-13'


  Danny has the following comments:

  the other thing i would contend with is the "semantics" of raise.  if on
  windows, the raise means something different than on unix, then you will
  force all tcl programmers to include platform dependent code if they have to
  do a "focus -force" on windows (its something i wouldn't want to do on unix
  if i can help it).  what i'd like to see is perhaps a new option on "raise",
  perhaps something like "-global" that will raise a window above all others
  regardless of the "active application".  this way, i can code this for unix
  in exactly the same way as for windows.

  once again, i point to the behavior of xhosted tcl apps on windows (the
  raise works "correctly").  also since tcl is used very much by
  administrators for "popup" messages, the need to raise above all windows is
  critical.

  'raise' has the same semantics on Unix as it does on Windows.
  On Unix it does not make it the active application, so to do
  so on Windows would be altering the semantics for one platform.
  For 8.2b3, a change was made so that 'wm deiconify' on Windows
  actually raises and focuses the window, which is more in line
  with the Windows style. 
  -- 08/13/1999 hobbs


tkt_uuid: 462320ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: tk/unix/README refers to missing script?
comment:
  the tk/unix/README says:

  There are also a number of visual tests for things such
  as screen layout,
  Postscript generation, etc.  These tests all have to be
  run manually and
  the results have to be verified visually.  To run the
  tests, cd to the
  "tests" directory and run the script "visual".  It will
  present a main
  window with a bunch of menus, which you can use to
  select various tests.

  However, the tests directory contains:

  $ ls
  CVS                clrpick.test      
  macMenu.test       textIndex.test
  README             cmap.tcl          
  macWinMenu.test    textMark.test
  all.tcl            cmds.test         
  macscrollbar.test  textTag.test
  arc.tcl            color.test        
  main.test          textWind.test
  bell.test          config.test       
  menu.test          tk.test
  bevel.tcl          cursor.test       
  menuDraw.test      unixButton.test
  bgerror.test       defs.tcl          
  menubut.test       unixEmbed.test
  bind.test          dialog.test       
  message.test       unixFont.test
  bitmap.test        entry.test        
  msgbox.test        unixMenu.test
  border.test        event.test        
  obj.test           unixSelect.test
  bugs.tcl           filebox.test      
  oldpack.test       unixSend.test
  butGeom.tcl        focus.test        
  option.file1       unixWm.test
  butGeom2.tcl       focusTcl.test     
  option.file2       util.test
  button.test        font.test         
  option.test        visual.test
  canvImg.test       frame.test        
  pack.test          visual_bb.test
  canvPs.test        geometry.test     
  place.test         winButton.test
  canvPsArc.tcl      get.test          
  raise.test         winClipboard.test
  canvPsBmap.tcl     grab.test         
  safe.test          winDialog.test
  canvPsGrph.tcl     grid.test         
  scale.test         winFont.test
  canvPsImg.tcl      id.test           
  scrollbar.test     winMenu.test
  canvPsText.tcl     image.test        
  select.test        winSend.test
  canvRect.test      imgBmap.test      
  send.test          winWm.test
  canvText.test      imgPPM.test       
  spinbox.test       window.test
  canvWind.test      imgPhoto.test     
  text.test          winfo.test
  canvas.test        listbox.test      
  textBTree.test     xmfbox.test
  choosedir.test     macEmbed.test      textDisp.test
  clipboard.test     macFont.test       textImage.test


  Is the "visual" mentioned in the README supposed to be
  "visual.test" or is there a missing script called
  visual?


tkt_uuid: 220122ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Invalid
title: XLookupString missing in X-emulation under Windows
comment:
  OriginalBugID: 1150 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-02'
  LastModified: '2000-01-03'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  Machine: X86
  ClosedDate: '2000-01-03'


  Name:
  Ulrich Lauther

  In tk8.0.x there used to be a XLookupString in the X11 emulation part tk.
  This vanished in 8.1b1 and I cannot see any hint in the man-pages, how to 
  access strings associated with a keyboard event


  Look for exported Tk bug instead of using the X routine.  We need to make sure there is an equivelant API.  03/26/1999 11:13 - surles -
  --
  It is now called TkpGetString (p means private), and was essentially
  changed to handle UTF (still in tkWinKey.c).  Since we don't want
  to create a generic X emulation layer, we used a routine that works
  better for Tk internally.  The user can refer to that code if they
  need it. 
  -- 01/03/2000 hobbs


tkt_uuid: 2750849fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: bind-8.2 fails
comment:
  ==== bind-8.2 TkCreateBindingProcedure: new binding FAILED
  ==== Contents of test case:

      catch {destroy .b.f}
      frame .b.f
      testcbind .b.f <1> "lappend x 1" "lappend x bye.1"
      set x {}
      event gen .b.f <1>
      destroy .b.f
      set x

  ---- Result was:
  1 bye.1
  ---- Result should have been (exact matching):
  bye.1
  ==== bind-8.2 FAILED


  This is a regression since Tk 8.5.6, and likely
  more recent than that.


tkt_uuid: 1792432fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 9 Immediate
foundin: obsolete: 8.5a7
resolution: Invalid
title: --disable-shared Tcl / --enable-shared Tk
comment:
  This combination produces a working
  wish using the Tcl/Tk 8.5a6 releases.

  It produces a wish that crashes on 
  the HEAD:

  $ ./wish
  ./wish: symbol lookup error: ./wish: undefined symbol: Tcl_InitStubs

  Perhaps a consequence of the changes
  addressing 1716117 ?


tkt_uuid: 1843410fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: None
resolution: None
title: Additional option (f.e. "-description")
comment:
  It is quite common today to have additional, short description of chosen buttons/menu entries etc. either on kind of statusbar, or in the "tooltip"-form. Currently such description has to be added using some additional structures, while it can be avoided by having additional option: let's here call it "-description" - which can be then easily called using "cget". That "description" (which itself is a simple text, and nothing more) could even be set in form similar to "-command": using {} dynamically, using "" statically - which will make the ways of assignment even broader.

  A short example, how could it look like:

  $w.menu add cascade -label "File" -description "File operations menu"

  bind Menu <<MenuSelect>> {
    global menustatus
    if {[catch {%W entrycget active -description} label]} {
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         set label "    "
    }
    set menustatus $label
    update idletasks
  }

  Such option could be added to all the "interactive" widgets - those which can be used to run commands, or choose options - of course, it won't be necessarily for "separators" (or can be ignored in such case).

  Such way adding/changing "tooltips" (or statusbar texts) contents would be much more easier during both creation and maintenance.


tkt_uuid: 220485ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title:
  when binding "destroy $w" to alt-w and ctrl-w, you got an error pressing alt-w and it works pressing ctrl-c...

comment:
  OriginalBugID: 1759 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-08'
  LastModified: '1999-09-16'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux
  OSVersion: latest slackware i586 pc
  Machine: Other
  FixedDate: '1999-09-16'
  FixedInVersion: 8.2


  Name:

  Luc Deschenaux



  Extensions:

  Tk..



  CustomShell:

  nothing but applied this patch right now



  Comments:

  Thanks for Tcl/Tk !



  ReproducibleScript:

  two destructive hotkeys that's too hot for a TK 8.0.5...

      

      I try to be user friendly and look what happends... 

      I use ctrl and alt for my shortcuts, eg:

      (paste this in wish and press alt-w)

      

      proc about {} { 

        catch { 

          set w .about 

          toplevel $w 

      #    about_ui $w 

          bind $w <Alt-w> "destroy $w" 

          bind $w <Control-w> "destroy $w" 

          wm title .about "About this application" 

          wm resizable .about 0 0 

        } 

      } 

      about

      

      



  ObservedBehavior:

  the window is destroyed normally using Control-w but I got an error when

      I press Alt-w...  the error occurs in tkTraverseToMenu (lib/tk/menu.tcl)

      and there's no menu in this window :) 

      

      the stack trace is: 

      

      bad window path name ".about" 

          while executing 

      "winfo class $w" 

          (procedure "tkTraverseToMenu" line 6) 

          invoked from within 

      "tkTraverseToMenu .about w" 

          (command bound to event) 

        

      

      once it crashed my program and I got this message in the terminal

      window: 

      

      bgerror failed to handle background error. 

          Original error: bad window path name ".about" 

          Error in bgerror: can't invoke "toplevel" command:  application has

      been destroyed



  DesiredBehavior:

  guess..

      

      ok wait, I make the patch myself..



  Patch:

  *** menu.tcl.orig       Thu Apr  8 07:51:01 1999

  --- menu.tcl    Thu Apr  8 07:56:00 1999

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

  *** 956,962 ****



    proc tkTraverseToMenu {w char} {

        global tkPriv

  !     if {$char == ""} {

          return

        }

        while {[winfo class $w] == "Menu"} {

  --- 956,962 ----



    proc tkTraverseToMenu {w char} {

        global tkPriv

  !     if {[catch {winfo class $w}] || $char == ""} {

          return

        }

        while {[winfo class $w] == "Menu"} {



  PatchFiles:

  lib/tk8.0/menu.tcl





  The "winfo class" should probably be a "winfo exists", since that avoids the need for a catch. 
  04/16/1999 14:49 - stanton -
  This works as expected for 8.2. 
  -- 09/16/1999 hobbs


tkt_uuid: 220240ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: delayed appearance of characters in text entry widgets
comment:
  OriginalBugID: 2876 Bug
  Version: 8.2
  SubmitDate: '1999-09-23'
  LastModified: '1999-10-29'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  ClosedDate: '1999-10-29'


  Name:
  Diab Jerius

  Extensions:
  none

  CustomShell:
  none

  Comments:
  I'm using the following compiler:
      cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2
      
      tcl was configured as
      ./configure  --enable-threads --enable-shared
      
      tk was configured as
      ./configure  --enable-shared

  ReproducibleScript:
  type in any entry widget, e.g. using the widget demo

  ObservedBehavior:
  when entering text, the widget appears to buffer characters before
      displaying them.  there is a noticeable delay between the keystroke and
      the appearance of the character.  one can get bursts of several
      characters appearing at once.   I haven't seen this before on my
      platform with Tk8.0.

  DesiredBehavior:
  character appearance should be instantaneous after pressing a key



  This should be retried on a Tcl that isn't threads enabled.
  While Tcl runs find with threads, Tk does not (as yet), and
  that can in fact cause problems. 
  -- 09/24/1999 hobbs
  This is, in fact, a threading problems.  You can't mix
  Tcl w/ thread and Tk.  We have other bug reports for getting
  Tk fixed with threads, so this one is being closed out. 
  -- 10/29/1999 hobbs


tkt_uuid: 608690ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: wm geometry slow on Linux
comment:
  On comp.lang.tcl, Ian Gay reports that:

  1. A script was ok on Windows and showed slow response
  on Linux.
  2. Inspection showed I was frequently doing the
  equivalent of
     [wm geometry . [wm geometry .]]
  3. When I stopped doing this the script worked ok on
  Linux. Tentative       
  conclusion: Linux spends a lot of time in wm geometry.
  4. Joe English reported, and I confirm, that
     time  {wm geometry . [wm geometry .]} 1000 shows
  that wm geometry does not 
  take a long time, it executes in microseconds, so that
  can't be the answer.
  5. If I source the whole script and run it a bit, and
  then time the routine in 
  which wm geometry occurs, I also find that routine to
  be fast.
  6. If I disable my binding on <Configure> then the
  response is good, even when 
  doing the unnecessary [wm geometry . [wm geometry .]]
  calls.
  7. Aha! Obviously [wm geometry . [wm geometry .]]
  generates a <Configure> 
  event and I have gone into some kind of loop or race.
  8. No. When I instrument my <Configure> callback to
  show when it is run, I 
  find that [wm geometry . [wm geometry .]] does not
  generate a <Configure>.

  Slaven Rezic provided the missing clue:

  > Add "update" or "update idletasks" [after wm
  geometry].

  The problem occurs under icewm, fvwm2 and twm.


tkt_uuid: 220127ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Invalid
title: .button "configure" returns wrong information
comment:
  OriginalBugID: 1272 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-23'
  LastModified: '1999-03-26'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: surles
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  ClosedDate: '1999-03-26'


  Name:
  Bryan Oakley

  Extensions:
  (none)

  CustomShell:
  (none)

  ReproducibleScript:
  Run the following script both in 8.0.4 and 8.1b1 wish shells. You will
  notice that the output is different between the two shells.

      puts "patchlevel: [info patchlevel]"
      catch {destroy .button .frame}
      button .button
      frame .frame
      puts "button synonyms:"
      foreach item [.button configure] {
          if {[llength $item] == 2} {
      puts "    $item"
          }
      }

      puts "frame synonyms:"
      foreach item [.frame configure] {
          if {[llength $item] == 2} {
      puts "    $item"
          }
      }





  ObservedBehavior:
  In 8.1b1, buttons report incorrect information for the option synonyms.
  Other widgets report synonyms as the option name and option class name
  (eg: -bd borderWidth). But for buttons the second element of the list is
  the name of an option instead of the classname.




  DesiredBehavior:
  I expect the output from the script to be the same between 8.0.4 and
  8.1b1.






  This bug is what is preventing the quite impressive "bwidgets" from
  running under 8.1b1.
  ---
  Not reproducable on WinN or Unix.  03/25/1999 16:05 - surles -


tkt_uuid: 904371ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 8
foundin: None
resolution: Fixed
title: Unicode support inconsistency between menu titles and items
comment:
  The following script:

  ---------------------------------------
  menu .mb
  . configure -menu .mb

  menu .mb.m1
  set s1 "\u3072\u3089\u304C\u306A"
  .mb add cascade -label $s1 -menu .mb.m1
  .mb.m1 add command -label $s1

  menu .mb.m2
  set s3 "G\u00E9n\u00E9ration"
  .mb add cascade -label $s3 -menu .mb.m2
  .mb.m2 add command -label $s3

  wm title . "$s1 - $s3"
  ---------------------------------------

  does not work as expected on a french version of
  Windows 2k:
  - the accented characters in the second menu show up
  correctly in menu titles and items
  - if a japanese font is not installed, the characters
  in the first menu show up as '?' in titles and as
  squares in items
  - if a japanese font is installed, the characters are
  correctly displayed in items, but still show up as '?'
  in the first menu title

  This has been tested with tcl/tk 8.3.4 and 8.4.1


tkt_uuid: 220416ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: My patch of 12/30 to fix drawing of underlines was bogus.
comment:
  OriginalBugID: 1053 Bug
  Version: 8.1b1
  SubmitDate: '1999-01-15'
  LastModified: '1999-03-29'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: Windows NT
  OSVersion: 4.0J
  Machine: X86
  FixedDate: '1999-03-29'
  FixedInVersion: 8.1b3


  Name:
  Syd Polk

  CVS:
  generic/tkFont.c 1.1.4.5

  ReproducibleScript:
  Tk_UnderlineTextLayout was screwing up with double-byte text. This patch fixes this, as well as the problem with my original patch of underlining the first character even when there was not supposed to be any underlining at all.

  Patch:
  Index: tkFont.c
  ===================================================================
  RCS file: /cvsroot/tk/generic/tkFont.c,v
  retrieving revision 1.1.4.5
  diff -c -r1.1.4.5 tkFont.c
  *** tkFont.c1998/11/25 23:06:421.1.4.5
  --- tkFont.c1999/01/01 00:28:02
  ***************
  *** 2191,2208 ****
        int underline;/* Index of the single character to
     * underline, or -1 for no underline. */
    {
  !     TextLayout *layoutPtr;
        TkFont *fontPtr;
  !     int xx, yy, width, height;

  !     if ((Tk_CharBbox(layout, underline, &xx, &yy, &width, &height) != 0)
  !     && (width != 0)) {
  ! layoutPtr = (TextLayout *) layout;
  ! fontPtr = (TkFont *) layoutPtr->tkfont;

  ! XFillRectangle(display, drawable, gc, x + xx, 
  ! y + yy + fontPtr->fm.ascent + fontPtr->underlinePos,
  ! (unsigned int) width, (unsigned int) fontPtr->underlineHeight);
        }
    }
    
  --- 2191,2211 ----
        int underline;/* Index of the single character to
     * underline, or -1 for no underline. */
    {
  !     TextLayout *layoutPtr = (TextLayout *) layout;
        TkFont *fontPtr;
  !     int xx, yy, width, height, underlineByte;

  !     if (underline > -1) {
  ! underlineByte = Tcl_UtfAtIndex(layoutPtr->string, underline) 
  ! - layoutPtr->string;
  ! if ((Tk_CharBbox(layout, underlineByte, &xx, &yy, &width, &height) != 0)
  ! && (width != 0)) {
  !     fontPtr = (TkFont *) layoutPtr->tkfont;

  !     XFillRectangle(display, drawable, gc, x + xx, 
  !     y + yy + fontPtr->fm.ascent + fontPtr->underlinePos,
  !     (unsigned int) width, (unsigned int) fontPtr->underlineHeight);
  ! }
        }
    }
    

  PatchFiles:
  generic/tkFont.c



  The patch is incorrect, but the problem was present.  The Layout apis are character oriented, but the lower level font apis are byte oriented.  This has been clarified and their usage standardized.
  03/29/1999 20:00 - stanton -


tkt_uuid: 3073331fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 73. Argv Parsing
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: Out of Date
title: Namespace error on "::1:1.0" for XVNC DISPLAY variable
comment:
  I ran into an old namespace bug, which, according to the following email thread: https://sourceforge.net/mailarchive/message.php?msg_name=268895540912061058l60228248u483940a5c2737cca@mail.gmail.com and https://sourceforge.net/tracker/?func=detail&aid=2912473&group_id=12997&atid=112997, should be solved from 8.4. Was the patch taken out again? It works fine when I work from the local ":0.0" display.

  I run TCL/TK 8.5.5 from the Suse SLES 11 SP1 enterprise distro, so I can't upgrade to the latest TCL version unpunished... 

  Please let me know if you need extra information. Did I choose the right category?


tkt_uuid: 430116ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 57. [option]
priority: 7 High
foundin: obsolete: 8.4a3
resolution: Invalid
title: [option get] behavior change
comment:
  The following script works in Tcl/Tk 8.0 and Tcl/Tk 8.2 but fails in Tcl/Tk 8.4:

   proc jnl_entryState { e state } {
       switch -- $state {
           normal {
               $e configure \
                      -foreground [option get $e *Entry.Foreground Foreground] \
                      -background [option get $e *Entry.Background Background]
           }
           disabled {
               $e configure \
               -foreground \
               [option get $e *Entry.DisabledForeground DisabledForeground] \
               -background \
               [option get $e *Entry.DisabledBackground DisabledBackground]
           }
       }
       # switch
   }
   # jnl_entryState


   wm withdraw .
   toplevel .foo -class Foo


   set class [winfo class [winfo toplevel .foo]]

   option add  *${class}*Entry.Foreground grey widgetDefault
   option add  *${class}*Entry.DisabledForeground green widgetDefault

   option add  *${class}*Entry.Background white widgetDefault
   option add  *${class}*Entry.DisabledBackground blue widgetDefault

   entry .foo.e
   pack .foo.e

   button .foo.exit -text Done -command exit
   pack .foo.exit

   jnl_entryState .foo.e disabled

  In Tcl/Tk 8.4 it produces:

   Error in startup script: unknown color name ""
       (processing "-foreground" option)
       invoked from within
   "$e configure  -foreground  [option get $e *Entry.DisabledForeground DisabledForeground]   
  -background  [option get $e *Entry.DisabledBackground Disable..."
       ("disabled" arm line 2)
       invoked from within
   "switch -- $state {
            normal {
                $e configure  -foreground [option get $e *Entry.Foreground Foreground]  -background  
  [option get $e *..."
       (procedure "jnl_entryState" line 2)
       invoked from within
   "jnl_entryState .foo.e disabled
   "
       (file "testOption.tcl" line 39)


tkt_uuid: 3575664fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 9 Immediate
foundin: obsolete: 8.5.12
resolution: Works For Me
title: Cocoa Tk 8.5: Python IDLE crashes opening Preferences
comment:
  With a current Tcl/Tk built from the tk-cocoa-8-5-backport branch on OS  and a Python that dynamically links with it, attempting to open Python IDLE's Preferences menu causes Tk to crash.  By bisecting changes, it appear that this critical regression was introduced by fossil checkin 5393f608dd on 2012-08-06 ("Fixes for menu and wm fullscreen bugs").  http://core.tcl.tk/tk/info/5393f608dd

  This problem was first noticed with the release of ActiveTcl 8.5.12.1, the current OS X ActiveTcl version; previous versions 8.5.12.0 and 8.5.11.1 do not exhibit this problem with IDLE.

  To reproduce, install either the current OS X ActivePython 2.7.2 (http://www.activestate.com/activepython/downloads) or an OS X 64-bit/32-bit python.org python (http://www.python.org/download/), install Tcl and Cocoa Tk 8.5 in /Library/Frameworks, launch IDLE (for example, type /usr/local/bin/idle2.7 in a shell), then either select Python -> Preferences from the menu bar or press command-, (comma), the keyboard accelerator for the Preferences menu item.
  Using a debug build of Cocoa Tk at current tip (77b3f433c7), the crash occurs at tkMacOSXMenu.c:681.  See the attached crash dump.

  http://bugs.python.org/issue15853


tkt_uuid: 1491656fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 15. [scale]
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: adding a new widget command
comment:
  from: kitchen@pelletron.com

  I've run into an issue with the scale widget and likely
  others in the toolset.  I've seen this in other widget
  toolsets such as Motif also.

  In this case I am creating a control panel for
  something. The control panel is actually a client and
  sends commands to a server which performs the work.

  There may be several copies of the client running at
  the same time.

  Generally the way this is done is to operate everything
  in full duplex mode.  This means that a client
  originates a command which is sent to the server and
  the server replies to all clients with the new value
  of the parameter.

  At that time all clients are expected to update their
  widgets to show the new value.

  As an example let's look at a push button.

  In this case the user pushes the button which calls the
  callback which in turn sends a command to the server
  requesting a state change for the parameter.

  If the server agrees to change the state a message is
  sent back to all clients which ultimately causes the
  button label to change, for example from "off" to "on".

  This particular example is not a problem for the widget
  set.

  Another example is the slider widget.  In this case
  one client may change the value and the rest of the
  clients need to be updated to reflect the new slider
  position.

  This is a problem because issuing a command to the
  widget to change the value causes the callback to
  be called which sends a message back to the server
  potentially creating an infinite loop.

  In this case I modified the scale widget to add a new
  command "set_lcl" which updates the widget but doesn't
  call the callback.

  I suspect there are other widgets which should be
  similarly modified however I haven't taken the time
  to do anything about it.


tkt_uuid: 1036963fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 7 High
foundin: obsolete: 8.4.7
resolution: Fixed
title: panedwindow proxy sash should have save_under attribute set
comment:
  The panedwindow proxy sash should have the X windows
  save_under attribute set, the same as pop-up menus.

  The save_under attribute is used in X windows to
  indicate that a window is a temporary pop-up, and the
  contents of windows beneath it should be preserved if
  possible.  If save_under is not set then the
  panedwindow pane windows get Expose events as the
  proxy sash is dragged across them.  This is
  demonstrated using the attached test script.  The
  consequence of the Expose events is that the
  pane windows must redraw the damaged areas as
  the proxy sash is moved, causing extra processing (and
  network traffic for remote displays).  I am using an
  OpenGL extension to create the pane windows, which can
  involve a lot of processing to redraw in response to
  an Expose event.

  The attached simple patch adds the save_under flag to
  the proxy sash window.  The diff is generated from the
  latest HEAD version 1.20.  It could also be applied to
  the 8.4 branch. The change only affects X windows
  systems, and is ignored by the Xlib emulation on
  Windows.


  #!/bin/env wish
  #
  # Example script to demonstrate expose events being
  # generated as the panedwindow proxy sash is dragged
  # across the panes

  panedwindow .p

  frame .p.pane1
  .p add .p.pane1 -sticky nsew -width 200 -height 200

  bind .p.pane1 <Expose> { puts "Expose on pane1" }

  frame .p.pane2
  .p add .p.pane2 -sticky nsew -width 200 -height 200

  bind .p.pane2 <Expose> { puts "Expose on pane2" }

  pack .p -fill both -expand 1


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: 220499ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: canvas find below x - segmentation error
comment:
  OriginalBugID: 1840 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-15'
  LastModified: '1999-04-16'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: rjohnson
  OS: Solaris
  OSVersion: 2.5.1
  Machine: Other
  FixedDate: '1999-04-16'
  FixedInVersion: 8.1


  Name:

  Peter Weigand



  ReproducibleScript:

  canvas .c

      pack .c

      .c find below Selected



  DesiredBehavior:

  no segmentation error



  Patch:

  *** tkCanvas.cWed Feb 17 03:18:30 1999

  --- tkCanvas.c.newThu Apr 15 21:43:15 1999

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

  *** 2539,2546 ****

        return TCL_ERROR;

    }

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

  ! if (itemPtr->prevPtr != NULL) {

  !     DoItem(interp, itemPtr->prevPtr, uid);

    }

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

    double closestDist;

  --- 2539,2548 ----

        return TCL_ERROR;

    }

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

  ! if (itemPtr != NULL) {/* needed otherwise segment error */

  !     if (itemPtr->prevPtr != NULL) {

  ! DoItem(interp, itemPtr->prevPtr, uid);

  !     }

    }

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

    double closestDist;



  PatchFiles:

  tkCanvas.c





  That sure was a bug - must have been in for a long time!  04/16/1999 18:37 - rjohnson -


tkt_uuid: 432104ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: None
resolution: Fixed
title: Blue colors documented as RGB 0 0 0
comment:
  In the colors documentation man pages at 
  http://tcl.activestate.com/man/tcl8.3.2/TkCmd/colors.htm and
  http://tcl.activestate.com/man/tcl8.4/TkCmd/colors.htm

  all these colors are documented as having RGB values 0 0 0:

  blue, blue1, blue2, blue4, dark blue, DarkBlue, medium blue, MediumBlue, 
  navy, navy blue, NavyBlue

  When I query my X server, I get these values:


    0   0 255             blue
    0   0 255             blue1
    0   0 238             blue2
    0   0 205             blue3
    0   0 139             blue4
   50  50 204             medium blue
   50  50 204             mediumblue
   35  35 117             navy blue
   35  35 117             navyblue

  but I don't get a value for darkblue.  Is that really a color?  I don't see it
  in my /usr/lib/X11/rgb.txt.


tkt_uuid: 726861ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Duplicate
title: tk_getOpenFile ignores extension/fork choice
comment:
  tk_getOpenFile dialogue lists all files regardless of filename 
  extension and/or resource fork data specified for the 
  selected filetype 
   
  This can be seen with the example code in the doc page for 
  Tk_getOpenFile 
   
  I'm using TclTkAqua BI 8.4.2 


tkt_uuid: 521466ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Duplicate
title: panedwindow-frame-text sizing trouble
comment:
  When I run the vertical panedwindow demo (which I've
  checked into CVS and intend to have distributed with
  the rest of Tk) the widgets inside the pane do not show
  up until after the window as a whole is resized.  No
  problem is present in the horizontal panedwindow demo.


tkt_uuid: 3176239fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 7 High
foundin: obsolete: 8.6b2
resolution: Fixed
title: control-MouseWheel causes segv
comment:
  On X11, on Ubuntu 10.10 with Tcl/Tk 8.6b1.1 (2011-1-18 version, can't get latest CVS version due to sourceforge breakin), the attached ctrlwheelbug.tcl script will cause a Tcl/Tk crash in XLookupSymbol if the user presses control-MouseWheel.  MouseWheel events without the control key do not have problems.  The same script works with Tcl/Tk 8.4.19 and 8.5.8.  Looking through the other bug reports, this might be the same bug as #3117468.


tkt_uuid: 1761327fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Duplicate
title: Aqua: cascade menus in menubuttons don't post
comment:
  using OS X Aqua 8.4.15:


  cascade menus on menus attached to menubuttons don't post

  for example:

  toplevel .t
  grid [menubutton .t.m -menu .t.m.menu -width 15] -row 0 -column 0
  menu .t.m.menu
  .t.m.menu add radiobutton -label 1
  .t.m.menu add cascade -label 2 -menu .t.m.menu.m1
  menu .t.m.menu.m1
  .t.m.menu.m1 add radiobutton -label a
  .t.m.menu.m1 add radiobutton -label b



  the cascade menu under 2 doesn't post.

  this appears to be new since 8.4.13, haven't tested 8.4.14


tkt_uuid: 220340ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: compiling 64 Bit binaries causes problems in the Tcl_HashEntry function
comment:
  OriginalBugID: 553 Bug
  Version: 8.1a2
  SubmitDate: '1998-03-31'
  LastModified: '1999-03-26'
  Severity: SER
  Status: Released
  Submitter: hershey
  ChangedBy: redman
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-03-26'
  FixedInVersion: NA


  From: Fuad Abdallah <abdallah@nazgul.mpiz-koeln.mpg.de>
  Newsgroups: comp.lang.tcl
  Subject: Tcl8.1a2 error on irix6.2 64 bit ?
  Date: 26 Mar 1998 20:30:29 GMT
  Organization: GWDG, Goettingen
  Lines: 19
  Message-ID: <6fedt5$sbh$1@gwdu19.gwdg.de>
  NNTP-Posting-Host: nazgul.mpiz-koeln.mpg.de
  User-Agent: tin/pre-1.4-980202 (UNIX) (IRIX64/6.2 (IP28))
  Xref: nntp2.ba.best.com comp.lang.tcl:70051


  Hi,


  i have just compiled tcl8.1a2 under irix 6.2. It seems that
  compiling 64 Bit binaries causes problems in the function
  static Tcl_HashEntry *OneWordCreate
  resulting in coredumps.
  I used the irix cc 7.2 and gcc 2.8.1, both giving the same
  result.



  Regards,
  Fuad

  03/26/1999 18:43 - redman - Should be fixed now.  The hash code for XIDs was forced to use the single word hashing on 64bit systems.


tkt_uuid: 895638ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Duplicate
title: Bold fonts displayed incorrectly in text widget
comment:
  On Windows/NT OS's , the following re-creates the 
  problem

  #####
  pack [text .a -font {{MS sans serif} 8 bold}]
  .a insert 0.0 {Move the cursor through this text to see 
  the problem}
  #####

  Whilst moving cursor through the text, the text 
  spacing 'jiggles' about. 

  Problem varies between font family used. Some families 
  do not exhibit this problem.


tkt_uuid: 220002ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 1 Zero
foundin: final: 8.1.1
resolution: Duplicate
title: Many fixes to photo images
comment:
  OriginalBugID: 2325 RFE
  Version: 8.1.1
  SubmitDate: '1999-07-06'
  LastModified: '1999-08-01'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2431
  OS: Other
  Machine: NA
  ClosedDate: '1999-08-01'


  Name:

  Jan Nijtmans


  CVS:

  July 2, 1999


  Comments:

  Especiall the C-API changes are important to be implemented now, because

      otherwise they have to wait for Tk 8.3. The "window" format handler of

      Img 1.2 depends on it.


      Due to the size of this patch I don't post it to comp.lang.tcl.


  DesiredBehavior:

  This patch adds many enhancements to the "image" command, mainly

      the photo widget. This patch is supplied by Img for a long time,

      and is from time to time enhanced with more features. This

      version is functionally equivalent to the Img 1.2 patch, only

      it is regenerated and cleaned up for use with Tk 8.2 from

      the latest CVS sources.

      - 100% objectified (much faster than before). This part is

        originally written by Steve Ball. It makes the image command

        much faster and in addition allows the "-data" option to accept

        binary data.

      - Transparency handled correctly. In order to do this, it was

        necessary to change the internal representation from 3 to 4

        bytes per pixel. The current implementation works for GIF only,

        but this patch moves this code to the Tcl_PhotoPutBlock() function.

        This makes it usable for all image formats, not only GIF.

      - new "imageName data" subcommand. This command allows the content

        of an image to be read into a base-64 encoded string. Currently

        the only way to do that is through a temporary file and an external

        base-64 decoder.

      - new options "-grayscale" and "-background" to the "imageName data"

        and "imageName write" commands. Those options allow colored images

        to be written in grayscale and partially transparent images to be

        written fully opaque. They work for all image formats.

      - GIF format handler has a new "-index" option, which allows to

        extract single images from an animated GIF.

      - C-API changed in order to accomodate the above modifications.

      The documentation "photo.n" is adapted according to the above

      enhancements at the Tcl level. The C-API modifications are not

      yet documented, but this is rather trivial (I'm willing to do

      that, if it helps)


  Patch:

  *** generic/tk.h.origSat Jul  3 20:06:24 1999

  --- generic/tk.hSat Jul  3 21:38:15 1999

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

  *** 979,985 ****


    typedef struct Tk_ImageType Tk_ImageType;

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

  ! char *name, int argc, char **argv, Tk_ImageType *typePtr,

    Tk_ImageMaster master, ClientData *masterDataPtr));

    typedef ClientData (Tk_ImageGetProc) _ANSI_ARGS_((Tk_Window tkwin,

    ClientData masterData));

  --- 979,985 ----


    typedef struct Tk_ImageType Tk_ImageType;

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

  ! char *name, int objc, Tcl_Obj *CONST objv[], Tk_ImageType *typePtr,

    Tk_ImageMaster master, ClientData *masterDataPtr));

    typedef ClientData (Tk_ImageGetProc) _ANSI_ARGS_((Tk_Window tkwin,

    ClientData masterData));

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

  *** 1055,1064 ****

     * pixels in successive lines. */

        intpixelSize;/* Address difference between successive

     * pixels in the same line. */

  !     intoffset[3];/* Address differences between the red, green

  !  * and blue components of the pixel and the

  !  * pixel as a whole. */

  !     intreserved;/* Reserved for extensions (dash patch) */

    } Tk_PhotoImageBlock;


    /*

  --- 1055,1063 ----

     * pixels in successive lines. */

        intpixelSize;/* Address difference between successive

     * pixels in the same line. */

  !     intoffset[4];/* Address differences between the red, green,

  !  * blue and alpha components of the pixel and

  !  * the pixel as a whole. */

    } Tk_PhotoImageBlock;


    /*

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

  *** 1068,1087 ****


    typedef struct Tk_PhotoImageFormat Tk_PhotoImageFormat;

    typedef int (Tk_ImageFileMatchProc) _ANSI_ARGS_((Tcl_Channel chan,

  ! char *fileName, char *formatString, int *widthPtr, int *heightPtr));

  ! typedef int (Tk_ImageStringMatchProc) _ANSI_ARGS_((char *string,

  ! char *formatString, int *widthPtr, int *heightPtr));

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

  ! Tcl_Channel chan, char *fileName, char *formatString,

    Tk_PhotoHandle imageHandle, int destX, int destY,

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

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

  ! char *string, char *formatString, 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, char *formatString, Tk_PhotoImageBlock *blockPtr));

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

  ! Tcl_DString *dataPtr, char *formatString,

    Tk_PhotoImageBlock *blockPtr));


    /*

  --- 1067,1088 ----


    typedef struct Tk_PhotoImageFormat Tk_PhotoImageFormat;

    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));


    /*

  *** generic/tkImage.c.origSat Jul  3 20:06:29 1999

  --- generic/tkImage.cSun Jul  4 22:27:56 1999

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

  *** 119,125 ****

    /*

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

     *

  !  * Tk_ImageCmd --

     *

     *This procedure is invoked to process the "image" Tcl command.

     *See the user documentation for details on what it does.

  --- 119,125 ----

    /*

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

     *

  !  * Tk_ImageObjCmd --

     *

     *This procedure is invoked to process the "image" Tcl command.

     *See the user documentation for details on what it does.

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

  *** 134,148 ****

     */


    int

  ! Tk_ImageCmd(clientData, interp, argc, argv)

        ClientData clientData;/* Main window associated with interpreter. */

        Tcl_Interp *interp;/* Current interpreter. */

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

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

    {

        TkWindow *winPtr = (TkWindow *) clientData;

  !     int c, i, new, firstOption;

  !     size_t length;

        Tk_ImageType *typePtr;

        ImageMaster *masterPtr;

        Image *imagePtr;

  --- 134,155 ----

     */


    int

  ! Tk_ImageObjCmd(clientData, interp, objc, objv)

        ClientData clientData;/* Main window associated with interpreter. */

        Tcl_Interp *interp;/* Current interpreter. */

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

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

    {

  +     static char *imageOptions[] = {

  + "create", "delete", "height", "names", "type", "types", "width",

  + (char *) NULL

  +     };

  +     enum options {

  + IMAGE_CREATE, IMAGE_DELETE, IMAGE_HEIGHT, IMAGE_NAMES,

  + IMAGE_TYPE, IMAGE_TYPES, IMAGE_WIDTH

  +     };

        TkWindow *winPtr = (TkWindow *) clientData;

  !     int i, new, firstOption,  index;

        Tk_ImageType *typePtr;

        ImageMaster *masterPtr;

        Image *imagePtr;

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

  *** 153,186 ****

        ThreadSpecificData *tsdPtr = (ThreadSpecificData *) 

                Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));


  !     if (argc < 2) {

  ! Tcl_AppendResult(interp, "wrong # args: should be \"", argv[0],

  ! " option ?args?\"", (char *) NULL);

    return TCL_ERROR;

        }

  !     c = argv[1][0];

  !     length = strlen(argv[1]);

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

  ! if (argc < 3) {

  !     Tcl_AppendResult(interp, "wrong # args: should be \"", argv[0],

  !     " create type ?name? ?options?\"", (char *) NULL);

        return TCL_ERROR;

    }

  - c = argv[2][0];


    /*

     * Look up the image type.

     */


    for (typePtr = tsdPtr->imageTypeList; typePtr != NULL;

    typePtr = typePtr->nextPtr) {

  !     if ((c == typePtr->name[0])

  !     && (strcmp(argv[2], typePtr->name) == 0)) {

    break;

        }

    }

    if (typePtr == NULL) {

  !     Tcl_AppendResult(interp, "image type \"", argv[2],

        "\" doesn't exist", (char *) NULL);

        return TCL_ERROR;

    }

  --- 160,196 ----

        ThreadSpecificData *tsdPtr = (ThreadSpecificData *) 

                Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));


  !     if (objc < 2) {

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

    return TCL_ERROR;

        }

  ! 

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

  !     &index) != TCL_OK) {

  ! return TCL_ERROR;

  !     }

  !     switch ((enum options) index) {

  !       case IMAGE_CREATE: {

  ! char *arg;

  ! if (objc < 3) {

  !     Tcl_WrongNumArgs(interp, 2, objv, "type ?name? ?options?");

        return TCL_ERROR;

    }


    /*

     * Look up the image type.

     */


  + arg = Tcl_GetString(objv[2]);

    for (typePtr = tsdPtr->imageTypeList; typePtr != NULL;

    typePtr = typePtr->nextPtr) {

  !     if ((*arg == typePtr->name[0])

  !     && (strcmp(arg, typePtr->name) == 0)) {

    break;

        }

    }

    if (typePtr == NULL) {

  !     Tcl_AppendResult(interp, "image type \"", arg,

        "\" doesn't exist", (char *) NULL);

        return TCL_ERROR;

    }

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

  *** 189,201 ****

     * Figure out a name to use for the new image.

     */


  ! if ((argc == 3) || (argv[3][0] == '-')) {

        dispPtr->imageId++;

        sprintf(idString, "image%d", dispPtr->imageId);

        name = idString;

        firstOption = 3;

    } else {

  !     name = argv[3];

        firstOption = 4;

    }


  --- 199,212 ----

     * Figure out a name to use for the new image.

     */


  ! arg = Tcl_GetString(objv[3]);

  ! if ((objc == 3) || (arg[0] == '-')) {

        dispPtr->imageId++;

        sprintf(idString, "image%d", dispPtr->imageId);

        name = idString;

        firstOption = 3;

    } else {

  !     name = arg;

        firstOption = 4;

    }


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

  *** 240,247 ****

     * the image.

     */


  ! if ((*typePtr->createProc)(interp, name, argc-firstOption,

  ! argv+firstOption, typePtr, (Tk_ImageMaster) masterPtr,

    &masterPtr->masterData) != TCL_OK) {

        DeleteImage(masterPtr);

        return TCL_ERROR;

  --- 251,258 ----

     * the image.

     */


  ! if ((*typePtr->createProc)(interp, name, objc-firstOption,

  ! objv+firstOption, typePtr, (Tk_ImageMaster) masterPtr,

    &masterPtr->masterData) != TCL_OK) {

        DeleteImage(masterPtr);

        return TCL_ERROR;

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

  *** 255,292 ****

    Tcl_SetResult(interp,

    Tcl_GetHashKey(&winPtr->mainPtr->imageTable, hPtr),

    TCL_STATIC);

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

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

  !     hPtr = Tcl_FindHashEntry(&winPtr->mainPtr->imageTable, argv[i]);

        if (hPtr == NULL) {

  !     Tcl_AppendResult(interp, "image \"", argv[i],

        "\" doesn't exist", (char *) NULL);

    return TCL_ERROR;

        }

        masterPtr = (ImageMaster *) Tcl_GetHashValue(hPtr);

        DeleteImage(masterPtr);

    }

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

  ! char buf[TCL_INTEGER_SPACE];

  ! 

  ! if (argc != 3) {

  !     Tcl_AppendResult(interp, "wrong # args: should be \"", argv[0],

  !     " height name\"", (char *) NULL);

        return TCL_ERROR;

    }

  ! hPtr = Tcl_FindHashEntry(&winPtr->mainPtr->imageTable, argv[2]);

    if (hPtr == NULL) {

  !     Tcl_AppendResult(interp, "image \"", argv[2],

        "\" doesn't exist", (char *) NULL);

        return TCL_ERROR;

    }

    masterPtr = (ImageMaster *) Tcl_GetHashValue(hPtr);

  ! sprintf(buf, "%d", masterPtr->height);

  ! Tcl_SetResult(interp, buf, TCL_VOLATILE);

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

  ! if (argc != 2) {

  !     Tcl_AppendResult(interp, "wrong # args: should be \"", argv[0],

  !     " names\"", (char *) NULL);

        return TCL_ERROR;

    }

    for (hPtr = Tcl_FirstHashEntry(&winPtr->mainPtr->imageTable, &search);

  --- 266,307 ----

    Tcl_SetResult(interp,

    Tcl_GetHashKey(&winPtr->mainPtr->imageTable, hPtr),

    TCL_STATIC);

  ! break;

  !       }

  !       case IMAGE_DELETE: {

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

  !     char *arg = Tcl_GetString(objv[i]);

  !     hPtr = Tcl_FindHashEntry(&winPtr->mainPtr->imageTable, arg);

        if (hPtr == NULL) {

  !     Tcl_AppendResult(interp, "image \"", arg,

        "\" doesn't exist", (char *) NULL);

    return TCL_ERROR;

        }

        masterPtr = (ImageMaster *) Tcl_GetHashValue(hPtr);

        DeleteImage(masterPtr);

    }

  ! break;

  !       }

  !       case IMAGE_HEIGHT: {

  ! char *arg;

  ! if (objc != 3) {

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

        return TCL_ERROR;

    }

  ! arg = Tcl_GetString(objv[2]);

  ! hPtr = Tcl_FindHashEntry(&winPtr->mainPtr->imageTable, arg);

    if (hPtr == NULL) {

  !     Tcl_AppendResult(interp, "image \"", arg,

        "\" doesn't exist", (char *) NULL);

        return TCL_ERROR;

    }

    masterPtr = (ImageMaster *) Tcl_GetHashValue(hPtr);

  ! Tcl_SetIntObj(Tcl_GetObjResult(interp), masterPtr->height);

  ! break;

  !       }

  !       case IMAGE_NAMES: {

  ! if (objc != 2) {

  !     Tcl_WrongNumArgs(interp, 2, objv, NULL);

        return TCL_ERROR;

    }

    for (hPtr = Tcl_FirstHashEntry(&winPtr->mainPtr->imageTable, &search);

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

  *** 294,308 ****

        Tcl_AppendElement(interp, Tcl_GetHashKey(

        &winPtr->mainPtr->imageTable, hPtr));

    }

  !     } else if ((c == 't') && (strcmp(argv[1], "type") == 0)) {

  ! if (argc != 3) {

  !     Tcl_AppendResult(interp, "wrong # args: should be \"", argv[0],

  !     " type name\"", (char *) NULL);

        return TCL_ERROR;

    }

  ! hPtr = Tcl_FindHashEntry(&winPtr->mainPtr->imageTable, argv[2]);

    if (hPtr == NULL) {

  !     Tcl_AppendResult(interp, "image \"", argv[2],

        "\" doesn't exist", (char *) NULL);

        return TCL_ERROR;

    }

  --- 309,326 ----

        Tcl_AppendElement(interp, Tcl_GetHashKey(

        &winPtr->mainPtr->imageTable, hPtr));

    }

  ! break;

  !       }

  !       case IMAGE_TYPE: {

  ! char *arg;

  ! if (objc != 3) {

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

        return TCL_ERROR;

    }

  ! arg = Tcl_GetString(objv[2]);

  ! hPtr = Tcl_FindHashEntry(&winPtr->mainPtr->imageTable, arg);

    if (hPtr == NULL) {

  !     Tcl_AppendResult(interp, "image \"", arg,

        "\" doesn't exist", (char *) NULL);

        return TCL_ERROR;

    }

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

  *** 310,347 ****

    if (masterPtr->typePtr != NULL) {

        Tcl_SetResult(interp, masterPtr->typePtr->name, TCL_STATIC);

    }

  !     } else if ((c == 't') && (strcmp(argv[1], "types") == 0)) {

  ! if (argc != 2) {

  !     Tcl_AppendResult(interp, "wrong # args: should be \"", argv[0],

  !     " types\"", (char *) NULL);

        return TCL_ERROR;

    }

    for (typePtr = tsdPtr->imageTypeList; typePtr != NULL;

    typePtr = typePtr->nextPtr) {

        Tcl_AppendElement(interp, typePtr->name);

    }

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

  ! char buf[TCL_INTEGER_SPACE];

  ! 

  ! if (argc != 3) {

  !     Tcl_AppendResult(interp, "wrong # args: should be \"", argv[0],

  !     " width name\"", (char *) NULL);

        return TCL_ERROR;

    }

  ! hPtr = Tcl_FindHashEntry(&winPtr->mainPtr->imageTable, argv[2]);

    if (hPtr == NULL) {

  !     Tcl_AppendResult(interp, "image \"", argv[2],

        "\" doesn't exist", (char *) NULL);

        return TCL_ERROR;

    }

    masterPtr = (ImageMaster *) Tcl_GetHashValue(hPtr);

  ! sprintf(buf, "%d", masterPtr->width);

  ! Tcl_SetResult(interp, buf, TCL_VOLATILE);

  !     } else {

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

  ! "\": must be create, delete, height, names, type, types,",

  ! " or width", (char *) NULL);

  ! return TCL_ERROR;

        }

        return TCL_OK;

    }

  --- 328,363 ----

    if (masterPtr->typePtr != NULL) {

        Tcl_SetResult(interp, masterPtr->typePtr->name, TCL_STATIC);

    }

  ! break;

  !       }

  !       case IMAGE_TYPES: {

  ! if (objc != 2) {

  !     Tcl_WrongNumArgs(interp, 2, objv, NULL);

        return TCL_ERROR;

    }

    for (typePtr = tsdPtr->imageTypeList; typePtr != NULL;

    typePtr = typePtr->nextPtr) {

        Tcl_AppendElement(interp, typePtr->name);

    }

  ! break;

  !       }

  !       case IMAGE_WIDTH: {

  ! char *arg;

  ! if (objc != 3) {

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

        return TCL_ERROR;

    }

  ! arg = Tcl_GetString(objv[2]);

  ! hPtr = Tcl_FindHashEntry(&winPtr->mainPtr->imageTable, arg);

    if (hPtr == NULL) {

  !     Tcl_AppendResult(interp, "image \"", arg,

        "\" doesn't exist", (char *) NULL);

        return TCL_ERROR;

    }

    masterPtr = (ImageMaster *) Tcl_GetHashValue(hPtr);

  ! Tcl_SetIntObj(Tcl_GetObjResult(interp), masterPtr->width);

  ! break;

  !       }

        }

        return TCL_OK;

    }

  *** generic/tkImgBmap.c.origSat Jul  3 20:06:31 1999

  --- generic/tkImgBmap.cSun Jul  4 22:33:53 1999

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

  *** 80,86 ****


    static intGetByte _ANSI_ARGS_((Tcl_Channel chan));

    static intImgBmapCreate _ANSI_ARGS_((Tcl_Interp *interp,

  !     char *name, int argc, char **argv,

        Tk_ImageType *typePtr, Tk_ImageMaster master,

        ClientData *clientDataPtr));

    static ClientDataImgBmapGet _ANSI_ARGS_((Tk_Window tkwin,

  --- 80,86 ----


    static intGetByte _ANSI_ARGS_((Tcl_Channel chan));

    static intImgBmapCreate _ANSI_ARGS_((Tcl_Interp *interp,

  !     char *name, int argc, Tcl_Obj *CONST objv[],

        Tk_ImageType *typePtr, Tk_ImageMaster master,

        ClientData *clientDataPtr));

    static ClientDataImgBmapGet _ANSI_ARGS_((Tk_Window tkwin,

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

  *** 150,162 ****

     */


    static intImgBmapCmd _ANSI_ARGS_((ClientData clientData,

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

    static voidImgBmapCmdDeletedProc _ANSI_ARGS_((

        ClientData clientData));

    static voidImgBmapConfigureInstance _ANSI_ARGS_((

        BitmapInstance *instancePtr));

    static intImgBmapConfigureMaster _ANSI_ARGS_((

  !     BitmapMaster *masterPtr, int argc, char **argv,

        int flags));

    static intNextBitmapWord _ANSI_ARGS_((ParseInfo *parseInfoPtr));

    

  --- 150,162 ----

     */


    static intImgBmapCmd _ANSI_ARGS_((ClientData clientData,

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

    static voidImgBmapCmdDeletedProc _ANSI_ARGS_((

        ClientData clientData));

    static voidImgBmapConfigureInstance _ANSI_ARGS_((

        BitmapInstance *instancePtr));

    static intImgBmapConfigureMaster _ANSI_ARGS_((

  !     BitmapMaster *masterPtr, int argc, Tcl_Obj *CONST objv[],

        int flags));

    static intNextBitmapWord _ANSI_ARGS_((ParseInfo *parseInfoPtr));

    

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

  *** 184,190 ****

     * 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

  --- 184,190 ----

     * image. */

        char *name;/* Name to use for image. */

        int argc;/* Number of arguments. */

  !     Tcl_Obj *CONST argv[];/* Argument objects 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

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

  *** 197,203 ****

        masterPtr = (BitmapMaster *) ckalloc(sizeof(BitmapMaster));

        masterPtr->tkMaster = master;

        masterPtr->interp = interp;

  !     masterPtr->imageCmd = Tcl_CreateCommand(interp, name, ImgBmapCmd,

        (ClientData) masterPtr, ImgBmapCmdDeletedProc);

        masterPtr->width = masterPtr->height = 0;

        masterPtr->data = NULL;

  --- 197,203 ----

        masterPtr = (BitmapMaster *) ckalloc(sizeof(BitmapMaster));

        masterPtr->tkMaster = master;

        masterPtr->interp = interp;

  !     masterPtr->imageCmd = Tcl_CreateObjCommand(interp, name, ImgBmapCmd,

        (ClientData) masterPtr, ImgBmapCmdDeletedProc);

        masterPtr->width = masterPtr->height = 0;

        masterPtr->data = NULL;

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

  *** 238,259 ****

     */


    static int

  ! ImgBmapConfigureMaster(masterPtr, argc, argv, flags)

        BitmapMaster *masterPtr;/* Pointer to data structure describing

     * overall bitmap image to (reconfigure). */

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

  !     char **argv;/* Pairs of configuration options for image. */

        int flags;/* Flags to pass to Tk_ConfigureWidget,

     * such as TK_CONFIG_ARGV_ONLY. */

    {

        BitmapInstance *instancePtr;

        int maskWidth, maskHeight, dummy1, dummy2;


        if (Tk_ConfigureWidget(masterPtr->interp, Tk_MainWindow(masterPtr->interp),

  !     configSpecs, argc, argv, (char *) masterPtr, flags)

        != TCL_OK) {

    return TCL_ERROR;

        }


        /*

         * Parse the bitmap and/or mask to create binary data.  Make sure that

  --- 238,267 ----

     */


    static int

  ! ImgBmapConfigureMaster(masterPtr, objc, objv, flags)

        BitmapMaster *masterPtr;/* Pointer to data structure describing

     * overall bitmap image to (reconfigure). */

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

  !     Tcl_Obj *CONST objv[];/* Pairs of configuration options for image. */

        int flags;/* Flags to pass to Tk_ConfigureWidget,

     * such as TK_CONFIG_ARGV_ONLY. */

    {

        BitmapInstance *instancePtr;

        int maskWidth, maskHeight, dummy1, dummy2;


  +     char **argv = (char **) ckalloc((objc+1) * sizeof(char *));

  +     for (dummy1 = 0; dummy1 < objc; dummy1++) {

  + argv[dummy1]=Tcl_GetString(objv[dummy1]);

  +     }

  +     argv[objc] = NULL;

  + 

        if (Tk_ConfigureWidget(masterPtr->interp, Tk_MainWindow(masterPtr->interp),

  !     configSpecs, objc, argv, (char *) masterPtr, flags)

        != TCL_OK) {

  + ckfree((char *) argv);

    return TCL_ERROR;

        }

  +     ckfree((char *) argv);


        /*

         * Parse the bitmap and/or mask to create binary data.  Make sure that

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

  *** 742,792 ****

     */


    static int

  ! ImgBmapCmd(clientData, interp, argc, argv)

        ClientData clientData;/* Information about the image master. */

        Tcl_Interp *interp;/* Current interpreter. */

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

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

    {

        BitmapMaster *masterPtr = (BitmapMaster *) clientData;

  !     int c, code;

  !     size_t length;


  !     if (argc < 2) {

  ! Tcl_AppendResult(interp, "wrong # args: should be \"", argv[0],

  ! " option ?arg arg ...?\"", (char *) NULL);

    return TCL_ERROR;

        }

  !     c = argv[1][0];

  !     length = strlen(argv[1]);

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

  !     && (length >= 2)) {

  ! if (argc != 3) {

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

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

  !     (char *) NULL);

        return TCL_ERROR;

    }

    return Tk_ConfigureValue(interp, Tk_MainWindow(interp), configSpecs,

  ! (char *) masterPtr, argv[2], 0);

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

  !     && (length >= 2)) {

  ! if (argc == 2) {

        code = Tk_ConfigureInfo(interp, Tk_MainWindow(interp),

        configSpecs, (char *) masterPtr, (char *) NULL, 0);

  ! } else if (argc == 3) {

        code = Tk_ConfigureInfo(interp, Tk_MainWindow(interp),

  !     configSpecs, (char *) masterPtr, argv[2], 0);

    } else {

  !     code = ImgBmapConfigureMaster(masterPtr, argc-2, argv+2,

        TK_CONFIG_ARGV_ONLY);

    }

    return code;

  !     } else {

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

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

  ! return TCL_ERROR;

        }

    }

    

    /*

  --- 750,801 ----

     */


    static int

  ! ImgBmapCmd(clientData, interp, objc, objv)

        ClientData clientData;/* Information about the image master. */

        Tcl_Interp *interp;/* Current interpreter. */

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

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

    {

  +     static char *bmapOptions[] = {"cget", "configure", (char *) NULL};

        BitmapMaster *masterPtr = (BitmapMaster *) clientData;

  !     int code, index;


  !     if (objc < 2) {

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

  ! return TCL_ERROR;

  !     }

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

  !     &index) != TCL_OK) {

    return TCL_ERROR;

        }

  !     switch (index) {

  !       case 0: {

  ! if (objc != 3) {

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

        return TCL_ERROR;

    }

    return Tk_ConfigureValue(interp, Tk_MainWindow(interp), configSpecs,

  ! (char *) masterPtr, Tcl_GetString(objv[2]), 0);

  !       }

  !       case 1: {

  ! if (objc == 2) {

        code = Tk_ConfigureInfo(interp, Tk_MainWindow(interp),

        configSpecs, (char *) masterPtr, (char *) NULL, 0);

  ! } else if (objc == 3) {

        code = Tk_ConfigureInfo(interp, Tk_MainWindow(interp),

  !     configSpecs, (char *) masterPtr,

  !     Tcl_GetString(objv[2]), 0);

    } else {

  !     code = ImgBmapConfigureMaster(masterPtr, objc-2, objv+2,

        TK_CONFIG_ARGV_ONLY);

    }

    return code;

  !       }

  !       default: {

  ! panic("bad const entries to bmapOptions in ImgBmapCmd");

  !       }

        }

  +     return TCL_OK;

    }

    

    /*

  *** generic/tkImgGIF.c.origSat Jul  3 20:06:31 1999

  --- generic/tkImgGIF.cSat Jul  3 21:38:19 1999

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

  *** 3,15 ****

     *

     *A photo image file handler for GIF files. Reads 87a and 89a GIF

     *files. At present there is no write function.  GIF images may be

  !  *read using the -data option of the photo image by representing

     *the data as BASE64 encoded ascii.  Derived from the giftoppm code

     *found in the pbmplus package and tkImgFmtPPM.c in the tk4.0b2

     *distribution.

     *

     * Copyright (c) Reed Wade (wade@cs.utk.edu), University of Tennessee

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

     *

     * See the file "license.terms" for information on usage and redistribution

     * of this file, and for a DISCLAIMER OF ALL WARRANTIES.

  --- 3,17 ----

     *

     *A photo image file handler for GIF files. Reads 87a and 89a GIF

     *files. At present there is no write function.  GIF images may be

  !  *read using the -data option of the photo image.  The data may be

  !  *given as a binary string in a Tcl_Obj or by representing

     *the data as BASE64 encoded ascii.  Derived from the giftoppm code

     *found in the pbmplus package and tkImgFmtPPM.c in the tk4.0b2

     *distribution.

     *

     * Copyright (c) Reed Wade (wade@cs.utk.edu), University of Tennessee

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

  +  * Copyright (c) 1997 Australian National University

     *

     * See the file "license.terms" for information on usage and redistribution

     * of this file, and for a DISCLAIMER OF ALL WARRANTIES.

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

  *** 63,69 ****

    /*

     *  HACK ALERT!!  HACK ALERT!!  HACK ALERT!!

     * This code is hard-wired for reading from files.  In order to read

  !  * from a data stream, we'll trick fread so we can reuse the same code

     */


    typedef struct ThreadSpecificData {

  --- 65,72 ----

    /*

     *  HACK ALERT!!  HACK ALERT!!  HACK ALERT!!

     * This code is hard-wired for reading from files.  In order to read

  !  * from a data stream, we'll trick fread so we can reuse the same code.

  !  * 0==from file; 1==from base64 encoded data; 2==from binary data

     */


    typedef struct ThreadSpecificData {

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

  *** 76,90 ****

     */


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

  !     char *formatString, int *widthPtr, int *heightPtr));

    static int      FileReadGIF  _ANSI_ARGS_((Tcl_Interp *interp,

  !     Tcl_Channel chan, char *fileName, char *formatString,

        Tk_PhotoHandle imageHandle, int destX, int destY,

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

  ! static intStringMatchGIF _ANSI_ARGS_(( char *string,

  !     char *formatString, int *widthPtr, int *heightPtr));

  ! static intStringReadGIF _ANSI_ARGS_((Tcl_Interp *interp, char *string,

  !     char *formatString, Tk_PhotoHandle imageHandle,

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

        int srcX, int srcY));


  --- 79,95 ----

     */


    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,

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

  !     Tcl_Interp *interp));

  ! static intStringReadGIF _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));


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

  *** 165,177 ****

     */


    static int

  ! FileMatchGIF(chan, fileName, formatString, widthPtr, heightPtr)

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

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

  !     char *formatString;/* User-specified format string, or NULL. */

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

     * returned here if the file is a valid

     * raw GIF file. */

    {

    return ReadGIFHeader(chan, widthPtr, heightPtr);

    }

  --- 170,183 ----

     */


    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

     * raw GIF file. */

  +     Tcl_Interp *interp;/* not used */

    {

    return ReadGIFHeader(chan, widthPtr, heightPtr);

    }

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

  *** 197,208 ****

     */


    static int

  ! FileReadGIF(interp, chan, fileName, formatString, imageHandle, destX, destY,

    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. */

  !     char *formatString;/* User-specified format string, or NULL. */

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

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

     * photo image to be written to. */

  --- 203,214 ----

     */


    static int

  ! FileReadGIF(interp, chan, fileName, format, imageHandle, destX, destY,

    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

     * photo image to be written to. */

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

  ***


tkt_uuid: 220586ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: entryfield "-show" option doesn't stop cut-n-paste
comment:
  OriginalBugID: 2614 Bug
  Version: 8.0.5
  SubmitDate: '1999-08-31'
  LastModified: '1999-08-31'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT4 SP4
  Machine: X86
  FixedDate: '1999-08-31'
  FixedInVersion: 8.1.1


  Name:
  Shaun Lowry

  Comments:
  This is considered a security risk in what is arguably a security
      feature

  ReproducibleScript:
  entryfield .f -show "*"
      
      or 
      
      entryfield .f -show "*" -exportselection false

  ObservedBehavior:
  When cutting and pasting from an entryfield which is showing *'s, the
      cut text on the clipboard is what was actually typed in

  DesiredBehavior:
  I would expect the clipboard text to be all *'s or cut-n-paste should be
      disabled



  This was fixed on 1999-04-05. 
  -- 08/31/1999 hobbs


tkt_uuid: 220228ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: load bad image - Tcl/Tk crashes
comment:
  OriginalBugID: 2635 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-12-14'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0 sp3
  Machine: X86
  ClosedDate: '1999-12-14'


  Name:
  James Garrison

  Comments:
  I downloaded the TKWeather application, and noticed this problem...This
      application was not save the GIF image correctly, thus this problem
      occured...I have since fixed the application by incorporating the
      fconfigure to set the file i/o to binary:

  ReproducibleScript:
  load an image, in my case a bad (corrupted) GIF image, causes the Tcl
      interperter to crash...
      
      I'm running on a WinNT 4.0 workstation

  ObservedBehavior:
  the interperter crashes

  DesiredBehavior:
  the image loader should validate the image and if fails then returns
      gracefully, instead of crashing...



  We need the actual bad image to test this bug.  8.3 will have
  an objectified image command, although the underlying internals
  aren't too much different, so it might still be susceptible. 
  -- 12/14/1999 hobbs


tkt_uuid: 583303ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Works For Me
title: Test file text.test: one failure
comment:
  Compiled with SUN's cc
  Running on SunOS 5.6 using Reflection-X as X-emulator
  Test report:
  text.test

  ==== text-1.9 text options FAILED
  ==== Contents of test case:

          set result {}
          lappend result [catch {.t2 configure [lindex
  $test 0] [lindex $test 3]}]
          .t2 configure [lindex $test 0] [lindex $test 1]
          lappend result [.t2 cget [lindex $test 0]]

  ---- Result was:
  0 fixed
  ---- Result should have been:
  1 fixed
  ==== text-1.9 FAILED


tkt_uuid: 1686151fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: Aqua: canvas H scroll of windows misdraws
comment:
  Horizontal scrolling of a canvas containing 'window' items with text is drawn incorrectly while moving, on OS X Aqua only.  Scrolling of 'window' items containing buttons, or straight 'text' items works.  The script below demonstrates these various cases.

  eval destroy [winfo children .]
  canvas .canv -height 34 -width 250 -xscrollcommand {.scrol set}
  scrollbar .scrol -orient horizontal -command {.canv xview}
  pack .canv -in . -side top
  pack .scrol -in . -side bottom -fill x
  .canv delete all
  .canv configure -scrollregion "0 0 [expr 72 * 20] 34"
  for { set i 1 } { $i <= 20 } { incr i } {
  #    button .canv.t$i -text "Foobar $i"
      text .canv.t$i
      .canv.t$i insert end "Foobar $i"
      .canv create window [expr ($i - 1) * 72] 3 -anchor nw -window .canv.t$i
  #    .canv create text [expr ($i - 1) * 72] 3 -anchor nw -text "Foobar $i"
  }


tkt_uuid: 220747ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: tkUnixDraw.c", line 97: first operand must have sca
comment:
  OriginalBugID: 5819 Bug
  Version: 8.3.1
  SubmitDate: '2000-06-06'
  LastModified: '2000-07-20'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Solaris
  OSVersion: Solaris 2.8
  Machine: Sun Ultra-2
  FixedDate: '2000-07-20'
  FixedInVersion: 8.4a2


  Name:
  Richard Paynter

  Extensions:
  n/a

  CustomShell:
  None

  ReproducibleScript:
  ./configure --prefix=/usr/local --enable-64bit
  make
  Compiler: Forte c/c++ 6 from Sun

  ObservedBehavior:
  Error:

  "/usr/share/src/tk8.3.1/unix/tkUnixDraw.c", line 97: first operand must have scalar type: op "?:"
  cc: acomp failed for /usr/share/src/tk8.3.1/unix/tkUnixDraw.c
  make: *** [tkUnixDraw.o] Error 2

  Code:

      return XEmptyRegion((Region) damageRgn) ? 0 : 1;

  If the code is changed to:

      if (XEmptyRegion((Region) damageRgn));
          return 1;
      else
          return 0;

  I get these errors:

  "/usr/share/src/tk8.3.1/unix/tkUnixDraw.c", line 97: operand cannot have void type: op "CBRANCH"
  "/usr/share/src/tk8.3.1/unix/tkUnixDraw.c", line 97: controlling expressions must have scalar type
  "/usr/share/src/tk8.3.1/unix/tkUnixDraw.c", line 99: syntax error before or at: else
  "/usr/share/src/tk8.3.1/unix/tkUnixDraw.c", line 101: invalid directive
  "/usr/share/src/tk8.3.1/unix/tkUnixDraw.c", line 102: cannot recover from previous errors
  cc: acomp failed for /usr/share/src/tk8.3.1/unix/tkUnixDraw.c
  make: *** [tkUnixDraw.o] Error 2

  DesiredBehavior:
  I expect a clean compile.



  I think you got your bug report a little confused, but I think you are saying that there is a problem with your platform/compiler and the use of the trinary ( ? : ) operator indicated above.  I replaced it with an if/else as you suggested, which will hopefully fix the problem for you.  This fix is in the CVS repository now, and will go out with 8.4a2.  Thanks for finding the bug and suggesting the fix!

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

  -- 07/20/2000 ericm


tkt_uuid: 1303103fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: None
title: -namespace option for "bind" and widgets
comment:
  pass namespace name for script execution.
  Sample : 
  button .b -namespace [ namespace current ] -command {
   set flag "clicked"
  }
  bind .b <FocusIn> -namespace ::other {
   set focusOwner %W
  }

  This solution maid tk script simple and more readable,
  prevent global`ization.  Also gain help for tk extensions.


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: 1211080fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 9 Immediate
foundin: obsolete: 8.5a3
resolution: Fixed
title: tk in HEAD fails to compile clean
comment:
  ..\win\tkWinEmbed.c(734) : warning C4013:
  'TkpWmGetState' undefined; assuming extern returning int
  ..\win\tkWinWm.c(2227) : warning C4013:
  'Tk_GetMenuHWND' undefined; assuming extern returning int
  ..\win\tkWinWm.c(7645) : warning C4013:
  'Tk_GetEmbeddedMenuHWND' undefined; assuming extern
  returning int
  ..\win\tkWinWm.c(7645) : warning C4047: 'initializing'
  : 'struct HWND__ *' differs in levels of indirection
  from 'int '
  ..\win\tkWinX.c(345) : warning C4013:
  'TkWinCleanupContainerList' undefined; assuming extern
  returning int
  ..\win\tkWinX.c(1930) : warning C4047: '=' : 'unsigned
  long ' differs in levels of indirection from 'void *'


tkt_uuid: 1096323fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: None
resolution: None
title: Support hexadecimal (and other integer) formats
comment:
  Tcler's Chat Log:

  [09:19]sbDoes somebody here know what needs to be
  done to make a spinbox display its value in hexadecimal?
  [09:19]arjenFrom Bwidget?
  [09:19]sbNo, the builtin Tk one.
  [09:19]arjenOh, have you checked the man pages?
  [09:20]sbYes. The format parameter sounds promising,
  but it should be a format specifier that accepts floats.
  [09:20]arjenYes, I see that too
  [09:21]arjenUse -values?
  [09:21]arjen-values {0 1 2 3 4 5 6 7 8 9 a B C D E F} ?
  [09:21]sbI want the spinbox to go from 0000 to FFFF.
  [09:21]arjenUse a long list 
  [09:22]sbI hope there is a better way.
  [09:22]sbI have tried using the command parameter,
  but then after 000A it goes back to 0000.
  [09:24]Ladies and Gentlemen, <NewGuy`> has left the
  building!
  [09:24]dkfHmm, sounds like time for a feature request... 


tkt_uuid: 220869ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 4
foundin: obsolete: 8.2b3
resolution: Invalid
title: iconwindow disables button events
comment:
  OriginalBugID: 2821 Bug
  Version: 8.2b3
  SubmitDate: '1999-09-17'
  LastModified: '1999-10-22'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: SunOS
  Machine: Sparc


  Name:
  Glenn Burkhardt

  ReproducibleScript:
  Using 'iconwindow' to create and manage an icon results (by design,
      according to the code) in the
      button events being disabled.  Therefore, when a user clicks on the icon
      to map the application, the
      button event is handled by the window manager, as if the icon isn't
      there.
      
      This results in un-uniform behavior for the icon.  Every other icon on
      the desktop will map when
      clicked, except for the tk application using 'iconwindow'.  In fact, if
      the 'twm' window manager is used,
      the application cannot be mapped without the use of 'twm's iconmanager.
      
      In the file tkUnixWm.c, there's this comment:
      
      * Remove the icon window relationship.  In principle we
      * should also re-enable button events for the window, but
      * this doesn't work in general because the window manager
      * is probably selecting on them (we'll get an error if
      * we try to re-enable the events).  So, just leave the
      * icon window event-challenged;  the user will have to
      * recreate it if they want button events.

  DesiredBehavior:
  All icons should handle button events in the same way, regardless of
      whether the iconwindow function
      is used or not.  Uniform behavior of the desktop should be the design
      requirement.


tkt_uuid: 219922ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Duplicate
title: Transparent frames don't quite work on W98
comment:
  OriginalBugID: 1267 RFE
  Version: 8.1b1
  SubmitDate: '1999-02-23'
  LastModified: '1999-12-14'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2339
  OS: Windows 98
  Machine: X86
  ClosedDate: '1999-12-14'


  Name:
  Christopher Nelson

  ReproducibleScript:
  frame .f -background red
  pack .f
  frame .f.f -background {}
  pack .f.f
  button .f.f.b1 -text foo
  pack .f.f.b1
  button .f.f.b2 -text "foo bar baz"
  pack .f.f.b2





  ObservedBehavior:
  The slack space around .f.f.b1 should be red.  Its color is
  unpredicable.  Continuing the script with 

  .f.f configure -background blue
  .f.f configure -background {}

  shows more interesting results.




  DesiredBehavior:
  I expect the slack space around .f.f.b1 to show .f's background color.





  This was an undocumented side effect that apparently no longer works.
  03/26/1999 11:14 - surles -


tkt_uuid: 3588364fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
severity: Minor
foundin: current: 8.5.14
resolution: Fixed
title: Crash on Tk dll
comment:
  I'm try to build Python with mingw. It mostly all done except 64bit build where I got error on _tkinter module. I use mingw-w64 with gcc-4.7.2. I try various version of tcl/tk 8.5.11, 8.5.12, 8.5.13 but without success. On 32bit builds all fine It crash only on 64bit. I attach gdb backtrace. I find that python crash on module unload. Can you told me is it tcl/tk error or python error?


tkt_uuid: 1230576fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Out of Date
title: double source of tk.tcl fails
comment:
  $ wish
  % info patch
  8.5a4
  % source [file join $tk_library tk.tcl]
  can't import command "mc": already exists
  % set errorInfo
  can't import command "mc": already exists
      while executing
  "namespace import ::msgcat::mc"
      (in namespace eval "::tk::msgcat" script line 21)
      invoked from within
  "namespace eval msgcat {
          namespace export mc mcmax        
          if {[interp issafe] || [catch {package require
  msgcat}]} {
              # The msgcat..."
      (in namespace eval "::tk" script line 3)
      invoked from within
  "namespace eval ::tk {
      # Set up the msgcat commands
      namespace eval msgcat {
          namespace export mc mcmax        
          if {[interp issafe] || [..."
      (file "/home/fs3c/dgp/lib/tk8.5/tk.tcl" line 20)
      invoked from within
  "source [file join $tk_library tk.tcl]"

  This failure interacts badly with
  Tcl's auto-loader after an [auto_reset].


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: 2896501fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Windows: Filenames limit with tk_getFileName -multiple 1
comment:
  Platform: Windows-XP:

  The -multiple option for the tk_getFileName command returns 0 if the total length of the filenames a certain threshold:

  Assuming I create 480 files using this oneliner:

  $ perl -e 'for $x (1..480) { open OUT, ">file-longname$x.txt" ; print OUT "Hi\n" ; close OUT ; }'

  If I select all those files:
  llength "[tk_getOpenFile -multiple true -initialdir c:/temp/test_TclTk2/]"

  would return 0

  If I reduce the number of files to 440 the same command would return 440.

  If I use shorter filenames I can select more files.

  For 700 files:
  $ rm *.txt
  $ perl -e 'for $x (1..700) { open OUT, ">file$x.txt" ; print OUT "Hi\n" ; close OUT ; }'

  % llength "[tk_getOpenFile -multiple true -initialdir c:/temp/test_TclTk2/]"
  700

  This behaviour is quite annyoing as the number of files which can be selected depends on the filenname length off the files.

  As tested with a Csharp-Program the native Windows-Dialog allows selection of more files regardless of the filenames length.
  regards,
  dgroth


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


  Name:
  Rigoberto Corujo

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

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

  This did not happen under Tcl/Tk 7.6.

  #!/usr/bin/wish

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

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

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


tkt_uuid: 582383ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 7 High
foundin: obsolete: 8.4b2
resolution: None
title: winWm.test failure
comment:
  There is one test failure in winWm.test on Windows.

  winWm.test

  ==== winWm-5.1 UpdateGeometryInfo: menu 
  resizing FAILED
  ==== Contents of test case:

      set result {}
      toplevel .t
      frame .t.f -width 150 -height 50 -bg red
      pack .t.f
      update
      set result [winfo height .t]
      menu .t.m
      .t.m add command -label foo
      .t conf -menu .t.m
      update
      lappend result [winfo height .t]
      .t.m add command -label "thisisreallylong"
      .t.m add command -label "thisisreallylong"
      update
      lappend result [winfo height .t]
      destroy .t
      set result

  ---- Result was:
  50 50 32
  ---- Result should have been (exact matching):
  50 50 50
  ==== winWm-5.1 FAILED


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: 897516ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Out of Date
title: Static build needs more 2 ole libs for tkWinSend
comment:
  nmake -f makefile.vc OPTS=static with 8.5a0 produced 
  link errors. I goggled for the symbols and added
  ole32.lib and oleaut32.lib to the assignment of
  baselibs in makefile.vc

  <baselibs  = kernel32.lib user32.lib
  >baselibs  = kernel32.lib user32.lib ole32.lib oleaut32.lib

  The static build now completes w/o error.

  I'm on Win2000 but I am using a very old copy of MSVC
  which could be a factor:
  Microsoft (R) 32-bit C/C++ Standard Compiler Version 
  12.00.8168 for 80x86
  Copyright (C) Microsoft Corp 1984-1998. All rights 
  reserved.


  Cheers,
  Roy

  ======= ERROR OUTPUT BELOW ======
  (corrected by adding libs as described above)

  ....
  stubs.c
  lib -nologo -out:".\Release\tk85s.lib" 
  @c:\tmp\nme10728.

  link -nologo -machine:IX86 -release -opt:ref -
  opt:icf,3 -subsystem:windows -
  out:".\Release\wish85s.exe" kernel32.lib user32.lib 
  gdi32.lib "..\..\tcl\win\Release\tcl85s.lib" .\Release\tk_Sta
  tic\winMain.obj .\Release\tk_Static\wish.res ".\Release\tk
  85s.lib"
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__CoGetMalloc@8
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__CreateBindCtx@8
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__GetRunningObjectTable@8
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__CreateFileMoniker@8
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__VariantClear@4
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__SysFreeString@4
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__VariantChangeType@16
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__SysAllocString@4
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__VariantInit@4
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__SetErrorInfo@8
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__CreateErrorInfo@4
  .\Release\wish85s.exe : fatal error LNK1120: 11 
  unresolved externals


tkt_uuid: 1660811fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 02. Appearance
priority: 3 Low
foundin: obsolete: 8.5a5
resolution: None
title: Wrong rendering in transparent areas
comment:
  When using the option -background "", frames are transparent, but transparent area is never redrawn at all.
  It seems Tk ignore these areas by applying no treatment at all....
  Everything placed on a transparent frame (even dragging an other application window from the desktop throw this kind of area) can't be graphically removed after even if it was effectively removed according to the placement manager.
  Here's the code wich reproduces this:

  #######################################################
  procrefreshPrLayer {framePath} {
  update
  set FrameWidth [winfo width $framePath]
  set FrameHeight [winfo height $framePath]
  $framePath configure -width 0
  update
  $framePath configure -width $FrameWidth -height $FrameHeight
  }


  canvas .c -width 100 -height 100 -bg "#800000" -borderwidth 0 -highlightthickness 0
  frame .c.f1 -width 200 -height 50 -background ""
  frame .c.f2 -width 200 -height 50 -background ""
  frame .c.f1.f1 -background "#0000FF" -width 50 -height 50 -borderwidth 0 -highlightthickness 0
  frame .c.f2.f1 -background "#FFFFFF" -width 50 -height 50 -borderwidth 0 -highlightthickness 0
  frame .c.f2.f2 -background "#00FFFF" -width 50 -height 50 -borderwidth 0 -highlightthickness 0
  pack .c -fill both -expand 1
  pack .c.f1 .c.f2 -side top -anchor w
  pack .c.f1.f1 -side left -padx 10 -pady 10 -fill both -expand 1
  pack .c.f2.f1 .c.f2.f2 -side left -padx 10 -pady 10 -fill both -expand 1


  after 2000 {
  destroy .c.f2.f1
  # Uncomment the next line to see a trick wich can refresh the transparent area (destroyed frame will disappear as it should without the trick) or just drag a window from your desktop throw the tcl one to see the problem
  #refreshPrLayer .c.f2
  }
  #####################################################


tkt_uuid: 220358ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Report errors from menu invocations on Windows
comment:
  OriginalBugID: 596 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-04'
  Severity: SER
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1998-08-04'


  In Tk8.0p2, the Windows menu code does not report errors from

  TkPreprocessMenu or TkInvokeMenu.  Since both of those commands can

  run user written code, they need to report errors using

  Tcl_BackgroundError.



  Here is a patch which fixes this.  It also preserves the interpreter

  while invoking the user code.



  In Tk8.1a2, errors are correctly reported from TkInvokeMenu, but the

  interpreter is not preserved.  Errors are still not reported from

  TkPreprocessMenu.  I don't know if preserving the interpreter is

  important here; I did it because that is what other similar code does

  elsewhere.



  Ian Taylor

  ian@cygnus.com



  *** /5g/ian/tk8.0p2/win/tkWinMenu.c     Wed Oct 29 16:09:10 1997

  --- tkWinMenu.c Wed Apr 15 14:22:47 1998

  *************** TkWinHandleMenuEvent(phwnd, pMessage, pw

  *** 883,889 ****

                      ReconfigureWindowsMenu((ClientData) menuPtr);

                  }

                  if (!inPostMenu) {

  !                   TkPreprocessMenu(menuPtr);

                  }

                  TkActivateMenuEntry(menuPtr, -1);

                  *plResult = 0;

  --- 883,900 ----

                      ReconfigureWindowsMenu((ClientData) menuPtr);

                  }

                  if (!inPostMenu) {

  !                   Tcl_Interp *interp;

  !                   int code;

  ! 

  !                   interp = menuPtr->interp;

  !                   Tcl_Preserve((ClientData)interp);

  !                   code = TkPreprocessMenu(menuPtr);

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

  !                               && code != TCL_BREAK) {

  !                       Tcl_AddErrorInfo(interp, "\n    (menu preprocess)");

  !                       Tcl_BackgroundError(interp);

  !                   }

  !                   Tcl_Release((ClientData)interp);

                  }

                  TkActivateMenuEntry(menuPtr, -1);

                  *plResult = 0;

  *************** TkWinHandleMenuEvent(phwnd, pMessage, pw

  *** 904,909 ****

  --- 915,922 ----

                      if (mePtr != NULL) {

                          TkMenuReferences *menuRefPtr;

                          TkMenuEntry *parentEntryPtr;

  +                       Tcl_Interp *interp;

  +                       int code;

    

                          /*

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

  *************** TkWinHandleMenuEvent(phwnd, pMessage, pw

  *** 934,941 ****

                              }

                          }

    

  !                       TkInvokeMenu(mePtr->menuPtr->interp,

  !                               menuPtr, mePtr->index);

                      }

                      *plResult = 0;

                      returnResult = 1;

  --- 947,961 ----

                              }

                          }

    

  !                       interp = mePtr->menuPtr->interp;

  !                       Tcl_Preserve((ClientData)interp);

  !                       code = TkInvokeMenu(interp, menuPtr, mePtr->index);

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

  !                               && code != TCL_BREAK) {

  !                           Tcl_AddErrorInfo(interp, "\n    (menu invoke)");

  !                           Tcl_BackgroundError(interp);

  !                       }

  !                       Tcl_Release((ClientData)interp);

                      }

                      *plResult = 0;

                      returnResult = 1;





  Added patch 8/4/98 (SS)


tkt_uuid: 1000613fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Invalid
title: keyboard traversal with menubuttons under windows
comment:
  The keyboard traversal default bindings for menubuttons
  seems to work only under unix/linux.

  I've tried to bind manually for keyboard traversal but
  i've encountered a major problem: under windows is
  impossible to bind a simple keypress to a menu.

  An example:

  toplevel .tl
  menu .tl.menu -tearoff 0
  menu .tl.menu.file -tearoff 0
  .tl.menu add cascade -label File -menu .tl.menu.file
  .tl.menu.file add command -label New
  .tl.menu.file add command -label Open
  .tl configure -menu .tl.menu
  bind .tl.menu.fichero <h> {puts "Hello"}
  ----

  This works on linux but not on windows.


tkt_uuid: 220035ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Duplicate
title: application error depends on scripts file name
comment:
  OriginalBugID: 3372 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '1999-12-22'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2691
  OS: Windows 95
  ClosedDate: '1999-12-22'


  Name:
  Jianmang Li

  Comments:
  8.2.1 compiles fine on Linux (with gcc, thread, share lib option), but
      it hang after a while. (I start widget demo, about a couple of seconds
      it hangs)

  ReproducibleScript:
  #!/bin/sh
      #exec wish "$0" "$@"
      eval destroy [winfo child .]
      wm title . "Demo"
      menu .menuBar -tearoff 0
      .menuBar add cascade -label "File" -menu .menuBar.file -underline 0
      menu .menuBar.file -tearoff 0
      .menuBar.file add command -label "Quit" -command "exit" -underline 0
      . configure -menu .menuBar

  ObservedBehavior:
  Name the above script to menu.tcl (other name won't product the error).
      start the program and place your place pointer at the bottom boundary
      then you will see a dialog with Error unkown option "-type"

  DesiredBehavior:
  This is on Windows 95 platform.  I can never imagine that an error is
      depends on the program's name.



  The problem occurs when confusion arises over class names.
  A script takes the root filename of the script as the class
  name for the primary toplevel.  Tk will then tie that in
  to known classes when creating the toplevel, so a toplevel
  will try to be configured with class Menu...

  As for the threaded Tk, this is known to cause problems, and
  8.2.3 has added a warning about this. 
  -- 12/22/1999 hobbs


tkt_uuid: 495100ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: None
resolution: None
title: Add invoke none subcommand
comment:
  It is sometimes desirable to invoke the code associated with a spinbox's 
  -command option directly such as in a validation routine.  % substitutions
  prevent this from being done with something like:

     eval [$sb cget -command]

  This patch adds "none" as a value identifier to the spinbox's invoke subcommand.
  Code like:

     $sb invoke none

  will perform % substitutions and invoke the command but will not change the value
  of the spinbox.  I've used this in code like:

     proc spinboxCmd { w } {
         # Do something here to make the application react to the value.
         puts " new value:[$w get]"
     }

     proc spinboxVal { w v } {
         if { ! [string is integer $v]} {
     return 0
         } elseif {[string length $v]} {
     set values [$w cget -values]

     if {[llength $values]} {
         if {[lsearch $values $v] == -1} {
     return 0
         }
     } else {
         if {$v < [$w cget -from]
         || $v > [$w cget -to]} {
     return 0
         }
         # WUZ - worry about increment?
     }
         }

         # OK, the new value is OK, invoke the command
         after idle $w invoke none

         # It's valid.
         return 1
     }

     spinbox .sb -width 5 \
     -from 0 -to 10 -increment 1 \
     -command [list spinboxCmd %W] \
     -vcmd [list spinboxVal %W %P] \
     -validate key


tkt_uuid: 220512ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 56. [grab]
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: Docs missing for Tk_Ungrab API
comment:
  OriginalBugID: 1889 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '2000-04-24'
  Severity: MED
  Status: Released
  Submitter: surles
  ChangedBy: ericm
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-04-24'
  FixedInVersion: 8.3.1


  .

  I added the man page entry for this API for 8.3.1.

  - eric
   
  -- 04/24/2000 ericm


tkt_uuid: 220232ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: multiple outstanding "vwait"s don't work
comment:
  OriginalBugID: 2681 Bug
  Version: 8.2
  SubmitDate: '1999-09-01'
  LastModified: '1999-09-01'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  Machine: Other
  ClosedDate: '1999-09-01'


  Name:
  Q. Alex Zhao

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  In a fresh wish8.2 shell:
      proc waitvar1 {} {
          vwait var1
          puts "var1 is set"
      }
      proc waitvar2 {} {
          vwait var2
          puts "var2 is set"
      }
      after 10 waitvar1
      after 20 waitvar2
      after 30 "set var1 var1"

  ObservedBehavior:
  Nothing happens.

  DesiredBehavior:
  When the variable that the first "vwait" is waiting on changes, the
      first "vwait" should be woke up. This is not the same situation as
      described in the "vwait" manual page -- the event handler that sets var1
      DOES complete immediately, and "vwait var1" has no reason to wait any
      longer.
      
      In addition, if I add
      after 40 "set var2 var2"
      wish outputs:
      var2 is set
      var1 is set
      So it seems that the second "vwait" somehow blocks the first "vwait".



  This is the expected behavior because multiple vwaits will
  nest, not queue up, so the second must get triggered before
  the first can return. 
  -- 09/01/1999 hobbs


tkt_uuid: 835997ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: generate event ignored if wdg never displayed (OSX)
comment:
  If a widget has never been displayed then it cannot 
  generate an event; any attempt is silently ignored.

  To see the bug:
  - Run the sample script below
  - Push the button "Send Foo". This tells the label .l to 
  generate a <<Foo>> event
  - "got foo" is NOT printed, indicating that the <<Foo>> 
  event was not generated
  - Toggle the checkbutton "Show Label" one or more 
  times, to display the label and possibly hide it again
  - Push the button. The event is generated.

  Summary: pushing the button "Send Foo" has no effect 
  (i.e. the <<Foo>> event is not generated) until the label "I 
  Send Foo" has been displayed at least once. After that the 
  event is generated reliably. I first discovered this problem 
  with a far more complex widget than a label.

  I observed this bug in Tcl/Tk 8.4.4 on MacOS X.

  --------- sample script follows ----------

  label .l -text "I generate Foo"
  grid .l -row 2 -column 0
  grid remove .l
  variable x

  checkbutton .c -text "Show Label" -variable x -command {
  if {$x} {
  grid .l
  } else {
  grid remove .l
  }
  }
  grid .c -row 1 -column 0

  button .b -text "Send Foo" -command {
  event generate .l "<<Foo>>"
  }
  grid .b -row 0 -column 0

  bind . "<<Foo>>" {
  puts "got foo"
  }


tkt_uuid: 219917ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: Making an unmapped window transient maps it again
comment:
  OriginalBugID: 1165 Bug
  Version: 8.0.4
  SubmitDate: '1999-02-03'
  LastModified: '1999-09-16'
  Severity: MED
  Status: Closed
  Submitter: stanton
  ChangedBy: hobbs
  RelatedBugIDs: 572
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-09-16'


  I think I have found a bug in the "wm transient" command. Try the
  following: 

  toplevel .t
  wm withdraw .t
  wm transient .t .

  The "wm transient" command causes the toplevel to be mapped !


  02/03/1999 18:27 - stanton - This happens because the wm code tries to ensure the transient is in the same state as its master.  Unfortunately this is inappropriate if the master is currently mapped and the transient window isn't.  This logic needs to be beefed up.


tkt_uuid: 570324ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Duplicate
title: tktest finalize segfault (select)
comment:
  tktest segfaults during finalization after running the
  tests
  in select.test with the "-file sel\*.test" option:

  (gdb) run ./../tests/all.tcl -file sel\*.test
  Starting program: /local/src/tk/unix/./tktest
  ./../tests/all.tcl -file sel\*.tes
  t
  Tk 8.4a5 tests running in interp: 
  /local/src/tk/unix/./tktest
  Tests running in working dir:  /local/src/tk/unix
  Sourcing files that match:  /local/src/tk/tests/sel*.test
  Tests began at Mon Jun 17 23:49:03 EDT 2002
  select.test

  Tests ended at Mon Jun 17 23:50:05 EDT 2002
  all.tcl:        Total   108     Passed  93      Skipped
  15      Failed  0
  Sourced 1 Test Files.
  Number of tests skipped for each constraint:
          8       altDisplay
          6       macOrPc
          1       nonPortable

  Program received signal SIGSEGV, Segmentation fault.
  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1203c2a00)
      at malloc.c:3121
  3121    malloc.c: No such file or directory.
  (gdb) bt
  #0  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1203c2a00)
      at malloc.c:3121
  #1  0x200005c4574 in __libc_free (mem=0x20000770de0) at
  malloc.c:3023
  #2  0x12020a1a8 in TclpFree (cp=0x1203c3360 " =\005 \001")
      at ./../generic/tclAlloc.c:702
  #3  0x120135f68 in Tcl_Free (ptr=0x1203c3360 " =\005 \001")
      at ./../generic/tclCkalloc.c:1160
  #4  0x120172754 in Tcl_FinalizeThread () at
  ./../generic/tclEvent.c:907
  #5  0x120172520 in Tcl_Finalize () at
  ./../generic/tclEvent.c:804
  #6  0x120172108 in Tcl_Exit (status=0) at
  ./../generic/tclEvent.c:564
  #7  0x120137d88 in Tcl_ExitObjCmd (dummy=0x0,
  interp=0x120360480, objc=1,
      objv=0x120361c40) at ./../generic/tclCmdAH.c:667
  #8  0x12012dd90 in TclEvalObjvInternal
  (interp=0x120360480, objc=1,
      objv=0x120361c40, command=0x0, length=0, flags=0)
      at ./../generic/tclBasic.c:3012
  #9  0x120174ac8 in TclExecuteByteCode
  (interp=0x120360480, codePtr=0x1204b7ec0)
      at ./../generic/tclExecute.c:1279
  #10 0x120173bf8 in TclCompEvalObj (interp=0x120360480,
  objPtr=0x1204630d0)
      at ./../generic/tclExecute.c:917
  #11 0x12012f6c8 in Tcl_EvalObjEx (interp=0x120360480,
  objPtr=0x1204630d0,
      flags=0) at ./../generic/tclBasic.c:3907
  #12 0x1201c8c64 in TclObjInterpProc
  (clientData=0x12046cb70,
      interp=0x120360480, objc=2, objv=0x11fffeee0)
      at ./../generic/tclProc.c:1074
  #13 0x12012dd90 in TclEvalObjvInternal
  (interp=0x120360480, objc=2,
      objv=0x11fffeee0,
      command=0x12044988a "::tcltest::cleanupTests
  1\nreturn\n", length=26,
      flags=0) at ./../generic/tclBasic.c:3012
  #14 0x12012ee5c in Tcl_EvalEx (interp=0x120360480,
      script=0x120448ff0 "# all.tcl --\n#\n# This file
  contains a top-level script
   to run all of the Tk\n# tests.  Execute it by invoking
  \"source all.tcl\" when
  running tktest\n# in this directory.\n#\n# Copyright
  (c) 1998-1999 by Sc"...,
      numBytes=2235, flags=0) at ./../generic/tclBasic.c:3607
  #15 0x1201a6008 in Tcl_FSEvalFile (interp=0x120360480,
  pathPtr=0x1203ce740)
      at ./../generic/tclIOUtil.c:1355
  #16 0x1201a4c88 in Tcl_EvalFile (interp=0x120360480,
      fileName=0x11ffff248 "./../tests/all.tcl") at
  ./../generic/tclIOUtil.c:234
  #17 0x12004fe88 in Tk_MainEx (argc=3, argv=0x11ffff3b0,
      appInitProc=0x12002a500 <Tcl_AppInit>,
  interp=0x120360480)
      at /local/src/tk/unix/../generic/tkMain.c:234
  #18 0x12002a4d8 in main (argc=4, argv=0x11ffff3a8)
      at /local/src/tk/unix/tkAppInit.c:69


tkt_uuid: 3601782fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 9 Immediate
foundin: current: 8.6.0
resolution: Fixed
title: checkin dc77a27c54 fails badly
comment:
  Starting with Tk trunk checkin

    http://core.tcl.tk/tk/info/dc77a27c54

  Tk 8.6.* rejects pre-8.6.0 Tcl.  The wisdom
  of this is questionable, since it at least complicates
  if not impedes bisecting Tcl across the pre-stable
  to stable boundary searching for Tcl changes that
  break Tk -- the task I'm currently on.

  Still, I recognize the value in nudging people to
  throw out their alphas and betas, so assuming
  we keep this in place, it ought to at least fail
  better.  I see just a crash.  A panic with an useful
  error message is the better way to go.

  The stack trace I see (no I don't understand it yet)
  is:

  Program received signal SIGABRT, Aborted.
  0x00000033dd630285 in raise () from /lib64/libc.so.6
  (gdb) bt
  #0  0x00000033dd630285 in raise () from /lib64/libc.so.6
  #1  0x00000033dd631d30 in abort () from /lib64/libc.so.6
  #2  0x0000000000418886 in Tk_MainEx (argc=1, argv=0x7fffffffdd08,
      appInitProc=0x418755 <Tcl_AppInit>, interp=0x965d70)
      at /home/dgp/fossil/tk/unix/../generic/tkMain.c:192
  #3  0x000000000041874e in main (argc=1, argv=0x7fffffffdd08)
      at /home/dgp/fossil/tk/unix/../unix/tkAppInit.c:74


tkt_uuid: 220749ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: Patch to add ming build support for Tk!
comment:
  OriginalBugID: 5844 RFE
  Version: 8.4a1
  SubmitDate: '2000-06-07'
  LastModified: '2000-06-13'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  FixedDate: '2000-06-13'
  FixedInVersion: 8.4a2


  Name:
  Mo

  CVS:
  Wed Jun  7

  Comments:
  I don't think this will break the VC++ build but it is possible.
      I did not test with vc++ under windows and gnu make.

  DesiredBehavior:
  The following patch will add the ability to build
  Tk using the mingw toolchain (gcc on Windows).
  Tcl already builds with mingw, but Tk did not
  build up until now.

  Patch:
  Index: win/Makefile.in
  ===================================================================
  RCS file: /cvsroot/tcl/win/Makefile.in,v
  retrieving revision 1.36
  diff -u -r1.36 Makefile.in
  --- Makefile.in2000/05/19 18:57:591.36
  +++ Makefile.in2000/06/07 12:28:57
  @@ -47,7 +47,7 @@
   # Directory in which to install the program tclsh:
   BIN_INSTALL_DIR= $(INSTALL_ROOT)$(bindir)

  -# Directory in which to install libtcl.so or libtcl.a:
  +# Directory in which to install the .a or .so binary for the Tcl library:
   LIB_INSTALL_DIR= $(INSTALL_ROOT)$(libdir)

   # Path name to use when installing library scripts.
  @@ -130,7 +130,7 @@
   DDE_LIB_FILE= tcldde$(VER)${LIBSUFFIX}
   REG_DLL_FILE= tclreg$(VER)${DLLSUFFIX}
   REG_LIB_FILE= tclreg$(VER)${LIBSUFFIX}
  -PIPE_DLL_FILE= tclpip$(VER).dll
  +PIPE_DLL_FILE= tclpip$(VER)${DLLSUFFIX}

   SHARED_LIBRARIES = $(TCL_DLL_FILE) $(TCL_STUB_LIB_FILE)  $(DDE_DLL_FILE) $(REG_DLL_FILE) $(PIPE_DLL_FILE)
  @@ -169,7 +169,7 @@
   OBJEXT= @OBJEXT@
   STLIB_LD= @STLIB_LD@
   SHLIB_LD= @SHLIB_LD@
  -SHLIB_LD_LIBS= @SHLIB_LD_LIBS@
  +SHLIB_LD_LIBS= @SHLIB_LD_LIBS@ $(LIBS)
   SHLIB_CFLAGS= @SHLIB_CFLAGS@
   SHLIB_SUFFIX= @SHLIB_SUFFIX@
   VER= @TCL_MAJOR_VERSION@@TCL_MINOR_VERSION@
  @@ -178,6 +178,7 @@

   RMDIR= rm -rf
   MKDIR= mkdir -p
  +SHELL= @SHELL@
   RM= rm -f
   COPY= cp

  @@ -301,7 +302,7 @@

   tcltest: $(TCLTEST)

  -binaries: @LIBRARIES@ $(STATIC_LIBRARIES) $(TCLSH)
  +binaries: @LIBRARIES@ $(TCLSH)

   libraries:

  @@ -323,11 +324,11 @@
   $(CC) $(CFLAGS) $(TCLTEST_OBJS) $(TCL_LIB_FILE) $(LIBS)  tclsh.$(RES) $(CC_EXENAME) 

  -cat32.${OBJEXT}: cat.c
  +cat32.$(OBJEXT): cat.c
   $(CC) -c $(CC_SWITCHES) $(DEPARG) $(CC_OBJNAME)

  -$(CAT32): cat32.${OBJEXT}
  -$(CC) $(CFLAGS) cat32.${OBJEXT} $(CC_EXENAME) $(LDFLAGS_CONSOLE)
  +$(CAT32): cat32.$(OBJEXT)
  +$(CC) $(CFLAGS) cat32.$(OBJEXT) $(CC_EXENAME) $(LDFLAGS_CONSOLE)

   # The following targets are configured by autoconf to generate either
   # a shared library or static library
  @@ -339,7 +340,7 @@

   ${TCL_DLL_FILE}: ${TCL_OBJS} tcl.$(RES)
   @$(RM) ${TCL_DLL_FILE}
  -@MAKE_DLL@ ${TCL_OBJS} tcl.$(RES)
  +@MAKE_DLL@ ${TCL_OBJS} tcl.$(RES) $(SHLIB_LD_LIBS)

   ${TCL_LIB_FILE}: ${TCL_OBJS}
   @$(RM) ${TCL_LIB_FILE}
  @@ -348,11 +349,11 @@

   ${DDE_DLL_FILE}: ${DDE_OBJS} ${TCL_STUB_LIB_FILE}
   @$(RM) ${DDE_DLL_FILE}
  -@MAKE_DLL@ ${DDE_OBJS} ${TCL_STUB_LIB_FILE}
  +@MAKE_DLL@ ${DDE_OBJS} $(TCL_STUB_LIB_FILE) $(SHLIB_LD_LIBS)

   ${REG_DLL_FILE}: ${REG_OBJS} ${TCL_STUB_LIB_FILE}
   @$(RM) ${REG_DLL_FILE}
  -@MAKE_DLL@ ${REG_OBJS} ${TCL_STUB_LIB_FILE}
  +@MAKE_DLL@ ${REG_OBJS} $(TCL_STUB_LIB_FILE) $(SHLIB_LD_LIBS)

   # PIPE_DLL_FILE is actually an executable, don't build it
   # like a DLL.
  @@ -513,14 +514,14 @@

   depend:

  -Makefile: Makefile.in
  +Makefile: $(SRC_DIR)/Makefile.in
   ./config.status

   cleanhelp:
   $(RM) *.hlp *.cnt *.GID *.rtf man2tcl.exe

   clean: cleanhelp
  -$(RM) *.lib *.exp *.dll *.$(RES) *.${OBJEXT} *~ \#* TAGS a.out
  +$(RM) *.lib *.a *.exp *.dll *.$(RES) *.${OBJEXT} *~ \#* TAGS a.out
   $(RM) $(TCLSH) $(TCLTEST) $(CAT32)
   $(RM) *.pch *.ilk *.pdb

  Index: win/configure.in
  ===================================================================
  RCS file: /cvsroot/tcl/win/configure.in,v
  retrieving revision 1.22
  diff -u -r1.22 configure.in
  --- configure.in2000/05/18 22:19:171.22
  +++ configure.in2000/06/07 12:28:57
  @@ -79,6 +79,12 @@
   AC_CHECK_HEADER(errno.h, , MAN2TCLFLAGS="-DNO_ERRNO_H")
   AC_SUBST(MAN2TCLFLAGS)

  +#------------------------------------------------------------------------
  +# tclConfig.sh refers to this by a different name
  +#------------------------------------------------------------------------
  +
  +TCL_SHARED_BUILD=${SHARED_BUILD}
  +
   #--------------------------------------------------------------------
   # Perform final evaluations of variables with possible substitutions.
   #--------------------------------------------------------------------
  @@ -91,6 +97,7 @@
   eval "TCL_STUB_LIB_FILE=${LIBPREFIX}tclstub$VER${LIBSUFFIX}"
   eval "TCL_DLL_FILE=tcl$VER${DLLSUFFIX}"
   eval "TCL_LIB_FILE=${LIBPREFIX}tcl$VER${LIBSUFFIX}"
  +
   eval "DLLSUFFIX=${DLLSUFFIX}"
   eval "LIBPREFIX=${LIBPREFIX}"
   eval "LIBSUFFIX=${LIBSUFFIX}"
  @@ -113,6 +120,7 @@
   AC_SUBST(CFG_TCL_SHARED_LIB_SUFFIX)
   AC_SUBST(CFG_TCL_UNSHARED_LIB_SUFFIX)
   AC_SUBST(CFG_TCL_EXPORT_FILE_SUFFIX)
  +AC_SUBST(TCL_SHARED_BUILD)

   AC_SUBST(PATHTYPE)
   AC_SUBST(CYGPATH)
  @@ -140,6 +148,8 @@
   AC_SUBST(RC_TYPE)
   AC_SUBST(RC_INCLUDE)
   AC_SUBST(RES)
  +AC_SUBST(LIBS)
  +AC_SUBST(LIBS_GUI)
   AC_SUBST(DLLSUFFIX)
   AC_SUBST(LIBPREFIX)
   AC_SUBST(LIBSUFFIX)
  Index: win/tcl.m4
  ===================================================================
  RCS file: /cvsroot/tcl/win/tcl.m4,v
  retrieving revision 1.12
  diff -u -r1.12 tcl.m4
  --- tcl.m42000/05/19 18:57:591.12
  +++ tcl.m42000/06/07 12:28:57
  @@ -165,6 +165,10 @@
   #
   #Sets the following vars:
   #CCCommand to use for the compiler
  +#ARComman for the archive tool
  +#RANLIBCommand for the archive indexing tool
  +#RCCommand for the resource compiler
  +#
   #------------------------------------------------------------------------

   AC_DEFUN(SC_ENABLE_GCC, [
  @@ -335,7 +339,7 @@
   #
   # Results:
   #
  -#Defines the following vars for all compilers:
  +#Can the following vars:
   #EXTRA_CFLAGS
   #CFLAGS_DEBUG
   #CFLAGS_OPTIMIZE
  @@ -349,12 +353,13 @@
   #PATHTYPE
   #VPSEP
   #CYGPATH
  -#
  -#Defines the following vars for non-gcc compilers
   #SHLIB_LD
   #SHLIB_LD_LIBS
   #LIBS
   #AR
  +#RC
  +#RES
  +#
   #MAKE_LIB
   #MAKE_EXE
   #MAKE_DLL
  @@ -507,7 +512,8 @@
       # dynamic
               AC_MSG_RESULT([using shared flags])
       runtime=-MD
  -    MAKE_DLL="\${SHLIB_LD} \${SHLIB_LD_LIBS} \$(LDFLAGS) -out:\[$]@"
  +    # Add SHLIB_LD_LIBS to the Make rule, not here.
  +    MAKE_DLL="\${SHLIB_LD} \$(LDFLAGS) -out:\[$]@"
       LIBSUFFIX="\${DBGX}.lib"
       DLLSUFFIX="\${DBGX}.dll"
       EXESUFFIX="\${DBGX}.exe"
  @@ -570,3 +576,50 @@
       AC_SUBST(TCL_BIN_DIR)
   ])

  +# FIXME : SC_PROG_TCLSH should really look for the installed tclsh and
  +# not the build version. If we want to use the build version in the
  +# tk script, it is better to hardcode that!
  +
  +#------------------------------------------------------------------------
  +# SC_PROG_TCLSH
  +#Locate a tclsh shell in the following directories:
  +#${exec_prefix}/bin
  +#${prefix}/bin
  +#${TCL_BIN_DIR}
  +#${TCL_BIN_DIR}/../bin
  +#${PATH}
  +#
  +# Arguments
  +#none
  +#
  +# Results
  +#Subst's the following values:
  +#TCLSH_PROG
  +#------------------------------------------------------------------------
  +
  +AC_DEFUN(SC_PROG_TCLSH, [
  +    AC_MSG_CHECKING([for tclsh])
  +
  +    AC_CACHE_VAL(ac_cv_path_tclsh, [
  +search_path=`echo ${exec_prefix}/bin:${prefix}/bin:${TCL_BIN_DIR}:${TCL_BIN_DIR}/../bin:${PATH} | sed -e 's/:/ /g'`
  +for dir in $search_path ; do
  +    for j in `ls -r $dir/tclsh[[8-9]]*.exe 2> /dev/null`  +    `ls -r $dir/tclsh* 2> /dev/null` ; do
  +if test x"$ac_cv_path_tclsh" = x ; then
  +    if test -f "$j" ; then
  +ac_cv_path_tclsh=$j
  +break
  +    fi
  +fi
  +    done
  +done
  +    ])
  +
  +    if test -f "$ac_cv_path_tclsh" ; then
  +TCLSH_PROG=$ac_cv_path_tclsh
  +AC_MSG_RESULT($TCLSH_PROG)
  +    else
  +AC_MSG_ERROR(No tclsh found in PATH:  $search_path)
  +    fi
  +    AC_SUBST(TCLSH_PROG)
  +])

  Index: win/Makefile.in
  ===================================================================
  RCS file: /cvsroot/tk/win/Makefile.in,v
  retrieving revision 1.25
  diff -u -r1.25 Makefile.in
  --- Makefile.in2000/05/23 02:44:181.25
  +++ Makefile.in2000/06/07 12:33:05
  @@ -87,11 +87,14 @@

   # This is a switch passed to a Cygwin script that generates file
   # names based on the platform.
  -PATHTYPE= @PATHTYPE@
  +PATHTYPE= @PATHTYPE@

  +# This program converts between Windows native and Cygwin POSIX pathnames.
  +CYGPATH= @CYGPATH@
  +
   # The name of the Tcl library.
  -TCL_LIB_FILE  = "$(shell cygpath $(PATHTYPE) '@TCL_BIN_DIR@/@TCL_LIB_FILE@')"
  -TCL_STUB_LIB_FILE = "$(shell cygpath $(PATHTYPE) '@TCL_BIN_DIR@/@TCL_STUB_LIB_FILE@')"
  +TCL_LIB_FILE  = "$(shell $(CYGPATH) $(PATHTYPE) '@TCL_BIN_DIR@/@TCL_LIB_FILE@')"
  +TCL_STUB_LIB_FILE = "$(shell $(CYGPATH) $(PATHTYPE) '@TCL_BIN_DIR@/@TCL_STUB_LIB_FILE@')"

   SRC_DIR= @srcdir@
   ROOT_DIR= $(SRC_DIR)/..
  @@ -102,14 +105,15 @@
   XLIB_DIR= $(ROOT_DIR)/xlib
   RC_DIR= $(WIN_DIR)/rc

  -ROOT_DIR_NATIVE   = $(shell cygpath $(PATHTYPE) '$(ROOT_DIR)')
  -WIN_DIR_NATIVE   = $(shell cygpath $(PATHTYPE) '$(WIN_DIR)')
  -GENERIC_DIR_NATIVE = $(shell cygpath $(PATHTYPE) '$(GENERIC_DIR)')
  -BITMAP_DIR_NATIVE= $(shell cygpath $(PATHTYPE) '$(ROOT_DIR)/bitmaps')
  -XLIB_DIR_NATIVE= $(shell cygpath $(PATHTYPE) '$(ROOT_DIR)/xlib')
  -TCL_GENERIC_NATIVE= $(shell cygpath $(PATHTYPE) '$(TCL_GENERIC_DIR)')
  -TCL_SRC_DIR_NATIVE      = $(shell cygpath $(PATHTYPE) '$(TCL_SRC_DIR)')
  -TCL_BIN_DIR_NATIVE      = $(shell cygpath $(PATHTYPE) '$(TCL_BIN_DIR)')
  +ROOT_DIR_NATIVE   = $(shell $(CYGPATH) $(PATHTYPE) '$(ROOT_DIR)')
  +WIN_DIR_NATIVE   = $(shell $(CYGPATH) $(PATHTYPE) '$(WIN_DIR)')
  +GENERIC_DIR_NATIVE = $(shell $(CYGPATH) $(PATHTYPE) '$(GENERIC_DIR)')
  +BITMAP_DIR_NATIVE= $(shell $(CYGPATH) $(PATHTYPE) '$(ROOT_DIR)/bitmaps')
  +XLIB_DIR_NATIVE= $(shell $(CYGPATH) $(PATHTYPE) '$(ROOT_DIR)/xlib')
  +TCL_GENERIC_NATIVE= $(shell $(CYGPATH) $(PATHTYPE) '$(TCL_GENERIC_DIR)')
  +TCL_SRC_DIR_NATIVE      = $(shell $(CYGPATH) $(PATHTYPE) '$(TCL_SRC_DIR)')
  +TCL_BIN_DIR_NATIVE      = $(shell $(CYGPATH) $(PATHTYPE) '$(TCL_BIN_DIR)')
  +RC_DIR_NATIVE      = $(shell $(CYGPATH) $(PATHTYPE) '$(RC_DIR)')

   DLLSUFFIX= @DLLSUFFIX@
   LIBSUFFIX= @LIBSUFFIX@
  @@ -132,14 +136,14 @@
   # Macro that expands to the first dependency argument with the appropriate
   # path type already resolved.

  -DEPARG = "$(shell cygpath $(PATHTYPE) $<)"
  +DEPARG = "$(shell $(CYGPATH) $(PATHTYPE) $<)"

   # Setting the VPATH variable to a list of paths will cause the 
   # makefile to look into these paths when resolving .c to .obj
   # dependencies. Note the ':' to avoid autoconf's habit of deleting
   # all VPATH lines without an explicit ':' in it.

  -VPATH = $(GENERIC_DIR);$(WIN_DIR);$(UNIX_DIR);$(XLIB_DIR);$(RC_DIR) # : 
  +VPATH = $(GENERIC_DIR)@VPSEP@$(WIN_DIR)@VPSEP@$(UNIX_DIR)@VPSEP@$(XLIB_DIR)@VPSEP@$(RC_DIR) # : 

   # warning flags
   CFLAGS_WARNING= @CFLAGS_WARNING@
  @@ -163,8 +167,10 @@
   MAN2TCLFLAGS= @MAN2TCLFLAGS@

   AR= @AR@
  +RANLIB= @RANLIB@
   CC= @CC@
   RC= @RC@
  +RES= @RES@
   AC_FLAGS= @EXTRA_CFLAGS@ @DEFS@
   CPPFLAGS= @CPPFLAGS@
   LDFLAGS= @LDFLAGS@
  @@ -172,20 +178,19 @@
   LDFLAGS_WINDOW= @LDFLAGS_WINDOW@
   EXEEXT= @EXEEXT@
   OBJEXT= @OBJEXT@
  +STLIB_LD= @STLIB_LD@
   SHLIB_LD= @SHLIB_LD@
  -SHLIB_LD_LIBS= @SHLIB_LD_LIBS@ $(TCL_STUB_LIB_FILE) gdi32.lib comdlg32.lib
  +SHLIB_LD_LIBS= @SHLIB_LD_LIBS@ $(TCL_STUB_LIB_FILE) $(LIBS)
   SHLIB_CFLAGS= @SHLIB_CFLAGS@
   SHLIB_SUFFIX= @SHLIB_SUFFIX@
   VER= @TK_MAJOR_VERSION@@TK_MINOR_VERSION@
   DOTVER= @TK_MAJOR_VERSION@.@TK_MINOR_VERSION@
  -LIBS= @LIBS@ gdi32.lib comdlg32.lib
  +LIBS= @LIBS_GUI@
   RMDIR= rm -rf
   MKDIR= mkdir -p
   SHELL= @SHELL@
   RM= rm -f
   COPY= cp
  -CC_OBJNAME= @CC_OBJNAME@
  -CC_EXENAME= @CC_EXENAME@

   TCLSH_PROG= @TCLSH_PROG@

  @@ -194,6 +199,9 @@
   -I"${XLIB_DIR_NATIVE}" -I"${BITMAP_DIR_NATIVE}"  -I"${TCL_GENERIC_NATIVE}" ${AC_FLAGS}

  +CC_OBJNAME = @CC_OBJNAME@
  +CC_EXENAME = @CC_EXENAME@
  +
   STUB_CC_SWITCHES= ${CC_SWITCHES} -DUSE_TCL_STUBS
   CON_CC_SWITCHES= ${CC_SWITCHES} -DCONSOLE

  @@ -487,22 +495,22 @@
   install-doc:

  -$(WISH): $(TK_LIB_FILE) $(WISH_OBJS) wish.res
  +$(WISH): $(TK_LIB_FILE) $(WISH_OBJS) wish.$(RES)
   $(CC) $(CFLAGS) $(WISH_OBJS) $(TCL_LIB_FILE) $(TK_LIB_FILE) $(LIBS)  -wish.res $(CC_EXENAME) -link $(LDFLAGS_WINDOW)
  +wish.$(RES) $(CC_EXENAME) $(LDFLAGS_WINDOW)

   tktest : $(TKTEST)

  -$(TKTEST): $(TK_LIB_FILE) $(TKTEST_OBJS) wish.res $(CAT32)
  +$(TKTEST): $(TK_LIB_FILE) $(TKTEST_OBJS) wish.$(RES) $(CAT32)
   $(CC) $(CFLAGS) $(TKTEST_OBJS_NATIVE) $(TCL_LIB_FILE)  $(TK_LIB_FILE) $(LIBS)  -wish.res $(CC_EXENAME) -link $(LDFLAGS_WINDOW)
  +wish.$(RES) $(CC_EXENAME) $(LDFLAGS_WINDOW)

   cat32.${OBJEXT}: $(TCL_SRC_DIR)/cat.c
   $(CC) -c $(CC_SWITCHES) $(DEPARG) $(CC_OBJNAME)

   $(CAT32): cat32.${OBJEXT}
  -$(CC) $(CFLAGS) cat32.$(OBJEXT) $(CC_EXENAME) -link $(LDFLAGS_CONSOLE)
  +$(CC) $(CFLAGS) cat32.$(OBJEXT) $(CC_EXENAME) $(LDFLAGS_CONSOLE)

   # The following targets are configured by autoconf to generate either
   # a shared library or static library
  @@ -510,14 +518,16 @@
   ${TK_STUB_LIB_FILE}: ${STUB_OBJS}
   @$(RM) ${TK_STUB_LIB_FILE}
   @MAKE_LIB@ ${STUB_OBJS}
  +@POST_MAKE_LIB@

  -${TK_DLL_FILE}: ${TK_OBJS} tk.res
  +${TK_DLL_FILE}: ${TK_OBJS} tk.$(RES)
   @$(RM) ${TK_DLL_FILE}
  -@MAKE_DLL@ ${TK_OBJS} tk.res
  +@MAKE_DLL@ ${TK_OBJS} tk.$(RES) $(SHLIB_LD_LIBS)

   ${TK_LIB_FILE}: ${TK_OBJS}
   @$(RM) ${TK_LIB_FILE}
   @MAKE_LIB@ ${TK_OBJS}
  +@POST_MAKE_LIB@

   # Special case object file targets

  @@ -542,29 +552,29 @@
   # automatically added.

   .SUFFIXES: .${OBJEXT}
  -.SUFFIXES: .res
  +.SUFFIXES: .$(RES)
   .SUFFIXES: .rc

   # Implicit rule for all object files that will end up in the Tcl library

  -.c.${OBJEXT}:
  +.c.$(OBJEXT):
   $(CC) -c $(STUB_CC_SWITCHES) -DBUILD_tk ${DEPARG} $(CC_OBJNAME)

  -.rc.res:
  -$(RC) -fo $@ -r -i "$(GENERIC_DIR_NATIVE)" -i "$(TCL_GENERIC_NATIVE)" $(DEPARG)
  +.rc.$(RES):
  +$(RC) @RC_OUT@ $@ @RC_TYPE@ @RC_INCLUDE@ "$(GENERIC_DIR_NATIVE)" @RC_INCLUDE@ "$(TCL_GENERIC_NATIVE)" @RC_INCLUDE@ "$(RC_DIR_NATIVE)" $(DEPARG)

   depend:

   cleanhelp:
  -$(RM) *.hlp *.cnt *.hpj *.GID *.rtf man2tcl.exe
  +$(RM) *.hlp *.cnt *.hpj *.GID *.rtf man2tcl${EXEEXT}

   clean: cleanhelp
  -$(RM) *.lib *.exp *.dll *.res *.${OBJEXT} *~ \#* TAGS a.out
  +$(RM) *.lib *.a *.exp *.dll *.res *.${OBJEXT} *~ \#* TAGS a.out
   $(RM) $(WISH) $(TKTEST) $(CAT32)
   $(RM) *.pch *.ilk *.pdb

   distclean: clean
   $(RM) Makefile config.status config.cache config.log tkConfig.sh

  -Makefile: Makefile.in
  +Makefile: $(SRC_DIR)/Makefile.in
   ./config.status
  Index: win/aclocal.m4
  ===================================================================
  RCS file: /cvsroot/tk/win/aclocal.m4,v
  retrieving revision 1.9
  diff -u -r1.9 aclocal.m4
  --- aclocal.m42000/05/03 00:18:371.9
  +++ aclocal.m42000/06/07 12:33:05
  @@ -1,488 +1 @@
  -#------------------------------------------------------------------------
  -# SC_PATH_TCLCONFIG --
  -#
  -#Locate the tclConfig.sh file and perform a sanity check on
  -#the Tcl compile flags
  -#Currently a no-op for Windows
  -#
  -# Arguments:
  -#PATCH_LEVELThe patch level for Tcl if any.
  -#
  -# Results:
  -#
  -#Adds the following arguments to configure:
  -#--with-tcl=...
  -#
  -#Sets the following vars:
  -#TCL_BIN_DIRFull path to the tclConfig.sh file
  -#------------------------------------------------------------------------
  -
  -AC_DEFUN(SC_PATH_TCLCONFIG, [
  -    AC_MSG_CHECKING([the location of tclConfig.sh])
  -
  -    if test -d ../../tcl8.4$1/win;  then
  -TCL_BIN_DIR_DEFAULT=../../tcl8.4$1/win
  -    else
  -TCL_BIN_DIR_DEFAULT=../../tcl8.4/win
  -    fi
  -    
  -    AC_ARG_WITH(tcl, [  --with-tcl=DIR          use Tcl 8.4 binaries from DIR],
  -    TCL_BIN_DIR=$withval, TCL_BIN_DIR=`cd $TCL_BIN_DIR_DEFAULT; pwd`)
  -    if test ! -d $TCL_BIN_DIR; then
  -AC_MSG_ERROR(Tcl directory $TCL_BIN_DIR does not exist)
  -    fi
  -    if test ! -f $TCL_BIN_DIR/tclConfig.sh; then
  -AC_MSG_ERROR(There is no tclConfig.sh in $TCL_BIN_DIR:  perhaps you did not specify the Tcl *build* directory (not the toplevel Tcl directory) or you forgot to configure Tcl?)
  -    fi
  -    AC_MSG_RESULT($TCL_BIN_DIR/tclConfig.sh)
  -])
  -
  -#------------------------------------------------------------------------
  -# SC_PATH_TKCONFIG --
  -#
  -#Locate the tkConfig.sh file
  -#Currently a no-op for Windows
  -#
  -# Arguments:
  -#none
  -#
  -# Results:
  -#
  -#Adds the following arguments to configure:
  -#--with-tk=...
  -#
  -#Sets the following vars:
  -#TK_BIN_DIRFull path to the tkConfig.sh file
  -#------------------------------------------------------------------------
  -
  -AC_DEFUN(SC_PATH_TKCONFIG, [
  -    AC_MSG_CHECKING([the location of tkConfig.sh])
  -
  -    if test -d ../../tk8.4$1/win;  then
  -TK_BIN_DIR_DEFAULT=../../tk8.4$1/win
  -    else
  -TK_BIN_DIR_DEFAULT=../../tk8.4/win
  -    fi
  -    
  -    AC_ARG_WITH(tk, [  --with-tk=DIR          use Tk 8.4 binaries from DIR],
  -    TK_BIN_DIR=$withval, TK_BIN_DIR=`cd $TK_BIN_DIR_DEFAULT; pwd`)
  -    if test ! -d $TK_BIN_DIR; then
  -AC_MSG_ERROR(Tk directory $TK_BIN_DIR does not exist)
  -    fi
  -    if test ! -f $TK_BIN_DIR/tkConfig.sh; then
  -AC_MSG_ERROR(There is no tkConfig.sh in $TK_BIN_DIR:  perhaps you did not specify the Tk *build* directory (not the toplevel Tk directory) or you forgot to configure Tk?)
  -    fi
  -
  -    AC_MSG_RESULT($TK_BIN_DIR/tkConfig.sh)
  -])
  -
  -#------------------------------------------------------------------------
  -# SC_LOAD_TCLCONFIG --
  -#
  -#Load the tclConfig.sh file
  -#Currently a no-op for Windows
  -#
  -# Arguments:
  -#
  -#Requires the following vars to be set:
  -#TCL_BIN_DIR
  -#
  -# Results:
  -#
  -#Subst the following vars:
  -#TCL_BIN_DIR
  -#TCL_SRC_DIR
  -#TCL_LIB_FILE
  -#
  -#------------------------------------------------------------------------
  -
  -AC_DEFUN(SC_LOAD_TCLCONFIG, [
  -    AC_MSG_CHECKING([for existence of $TCL_BIN_DIR/tclConfig.sh])
  -
  -    if test -f "$TCL_BIN_DIR/tclConfig.sh" ; then
  -        AC_MSG_RESULT([loading])
  -. $TCL_BIN_DIR/tclConfig.sh
  -    else
  -        AC_MSG_RESULT([file not found])
  -    fi
  -
  -    # The eval is required to do the TCL_DBGX substitution in the
  -    # TCL_LIB_FILE variable.
  -
  -    eval TCL_LIB_FILE=${TCL_LIB_FILE}
  -    eval TCL_LIB_FLAG=${TCL_LIB_FLAG}
  -
  -    AC_SUBST(TCL_BIN_DIR)
  -    AC_SUBST(TCL_SRC_DIR)
  -    AC_SUBST(TCL_LIB_FILE)
  -])
  -
  -#------------------------------------------------------------------------
  -# SC_LOAD_TKCONFIG --
  -#
  -#Load the tkConfig.sh file
  -#Currently a no-op for Windows
  -#
  -# Arguments:
  -#
  -#Requires the following vars to be set:
  -#TK_BIN_DIR
  -#
  -# Results:
  -#
  -#Sets the following vars that should be in tkConfig.sh:
  -#TK_BIN_DIR
  -#------------------------------------------------------------------------
  -
  -AC_DEFUN(SC_LOAD_TKCONFIG, [
  -    AC_MSG_CHECKING([for existence of $TCLCONFIG])
  -
  -    if test -f "$TK_BIN_DIR/tkConfig.sh" ; then
  -        AC_MSG_CHECKING([loading $TK_BIN_DIR/tkConfig.sh])
  -. $TK_BIN_DIR/tkConfig.sh
  -    else
  -        AC_MSG_RESULT([could not find $TK_BIN_DIR/tkConfig.sh])
  -    fi
  -
  -
  -    AC_SUBST(TK_BIN_DIR)
  -    AC_SUBST(TK_SRC_DIR)
  -    AC_SUBST(TK_LIB_FILE)
  -])
  -
  -#------------------------------------------------------------------------
  -# SC_ENABLE_GCC --
  -#
  -#Allows the use of GCC if available
  -#
  -# Arguments:
  -#none
  -#
  -# Results:
  -#
  -#Adds the following arguments to configure:
  -#--enable-gcc
  -#
  -#Sets the following vars:
  -#CCCommand to use for the compiler
  -#------------------------------------------------------------------------
  -
  -AC_DEFUN(SC_ENABLE_GCC, [
  -    AC_ARG_ENABLE(gcc, [  --enable-gcc            allow use of gcc if available [--disable-gcc]],
  -[ok=$enableval], [ok=no])
  -    if test "$ok" = "yes"; then
  -CC=gcc
  -AC_PROG_CC
  -    else
  -CC=cl
  -    fi
  -])
  -
  -#------------------------------------------------------------------------
  -# SC_ENABLE_SHARED --
  -#
  -#Allows the building of shared libraries
  -#
  -# Arguments:
  -#none
  -#
  -# Results:
  -#
  -#Adds the following arguments to configure:
  -#--enable-shared=yes|no
  -#
  -#Defines the following vars:
  -#STATIC_BUILDUsed for building import/export libraries
  -#on Windows.
  -#
  -#Sets the following vars:
  -#SHARED_BUILDValue of 1 or 0
  -#------------------------------------------------------------------------
  -
  -AC_DEFUN(SC_ENABLE_SHARED, [
  -    AC_MSG_CHECKING([how to build libraries])
  -    AC_ARG_ENABLE(shared,
  -[  --enable-shared         build and link with shared libraries [--enable-shared]],
  -    [tcl_ok=$enableval], [tcl_ok=yes])
  -
  -    if test "${enable_shared+set}" = set; then
  -enableval="$enable_shared"
  -tcl_ok=$enableval
  -    else
  -tcl_ok=yes
  -    fi
  -
  -    if test "$tcl_ok" = "yes" ; then
  -AC_MSG_RESULT([shared])
  -SHARED_BUILD=1
  -    else
  -AC_MSG_RESULT([static])
  -SHARED_BUILD=0
  -AC_DEFINE(STATIC_BUILD)
  -    fi
  -])
  -
  -#------------------------------------------------------------------------
  -# SC_ENABLE_THREADS --
  -#
  -#Specify if thread support should be enabled
  -#
  -# Arguments:
  -#none
  -#
  -# Results:
  -#
  -#Adds the following arguments to configure:
  -#--enable-threads=yes|no
  -#
  -#Defines the following vars:
  -#TCL_THREADS
  -#------------------------------------------------------------------------
  -
  -AC_DEFUN(SC_ENABLE_THREADS, [
  -    AC_MSG_CHECKING(for building with threads)
  -    AC_ARG_ENABLE(threads, [  --enable-threads        build with threads],
  -[tcl_ok=$enableval], [tcl_ok=no])
  -
  -    if test "$tcl_ok" = "yes"; then
  -AC_MSG_RESULT(yes)
  -TCL_THREADS=1
  -AC_DEFINE(TCL_THREADS)
  -    else
  -TCL_THREADS=0
  -AC_MSG_RESULT(no (default))
  -    fi
  -])
  -
  -#------------------------------------------------------------------------
  -# SC_ENABLE_SYMBOLS --
  -#
  -#Specify if debugging symbols should be used
  -#
  -# Arguments:
  -#none
  -#
  -#Requires the following vars to be set:
  -#CFLAGS_DEBUG
  -#CFLAGS_OPTIMIZE
  -#
  -# Results:
  -#
  -#Adds the following arguments to configure:
  -#--enable-symbols
  -#
  -#Defines the following vars:
  -#CFLAGS_DEFAULTSets to CFLAGS_DEBUG if true
  -#Sets to CFLAGS_OPTIMIZE if false
  -#LDFLAGS_DEFAULTSets to LDFLAGS_DEBUG if true
  -#Sets to LDFLAGS_OPTIMIZE if false
  -#DBGXDebug library extension
  -#
  -#------------------------------------------------------------------------
  -
  -AC_DEFUN(SC_ENABLE_SYMBOLS, [
  -    AC_MSG_CHECKING([for build with symbols])
  -    AC_ARG_ENABLE(symbols, [  --enable-symbols        build with debugging symbols [--disable-symbols]],    [tcl_ok=$enableval], [tcl_ok=no])
  -
  -    if test "$tcl_ok" = "yes"; then
  -CFLAGS_DEFAULT="${CFLAGS_DEBUG}"
  -LDFLAGS_DEFAULT="${LDFLAGS_DEBUG}"
  -DBGX=d
  -AC_MSG_RESULT([yes])
  -    else
  -CFLAGS_DEFAULT="${CFLAGS_OPTIMIZE}"
  -LDFLAGS_DEFAULT="${LDFLAGS_OPTIMIZE}"
  -DBGX=""
  -AC_MSG_RESULT([no])
  -    fi
  -])
  -
  -
  -#--------------------------------------------------------------------
  -# SC_CONFIG_CFLAGS
  -#
  -#Try to determine the proper flags to pass to the compiler
  -#for building shared libraries and other such nonsense.
  -#
  -#NOTE: The backslashes in quotes below are substituted twice
  -#due to the fact that they are in a macro and then inlined
  -#in the final configure script.
  -#
  -# Arguments:
  -#none
  -#
  -# Results:
  -#
  -#Defines the following vars for all compilers:
  -#    EXTRA_CFLAGS
  -#    CFLAGS_DEBUG
  -#    CFLAGS_OPTIMIZE
  -#    CFLAGS_WARNING
  -#    LDFLAGS_DEBUG
  -#    LDFLAGS_OPTIMIZE
  -#    PATHTYPE
  -#    CC_OBJNAME
  -#    CC_EXENAME
  -#
  -#Defines the following vars for non-gcc compilers
  -#    SHLIB_LD
  -#    SHLIB_LD_LIBS
  -#    LIBS
  -#    AR
  -#    MAKE_LIB
  -#    MAKE_EXE
  -#    MAKE_DLL
  -#
  -#    LIBSUFFIX
  -#    LIBRARIES
  -#    EXESUFFIX
  -#    DLLSUFFIX
  -#
  -#--------------------------------------------------------------------
  -
  -AC_DEFUN(SC_CONFIG_CFLAGS, [
  -    AC_MSG_CHECKING([compiler flags])
  -    EXTRA_CFLAGS=""
  -    # set various compiler flags depending on whether we are using gcc or cl
  -    
  -    if test "${GCC}" = "yes" ; then
  -CFLAGS_DEBUG=-g
  -CFLAGS_OPTIMIZE=-O
  -CFLAGS_WARNING="-Wall -Wconversion"
  -LDFLAGS_DEBUG=-g
  -LDFLAGS_OPTIMIZE=-O
  -PATHTYPE=-u
  -
  -# Specify the CC output file names based on the target name
  -CC_OBJNAME="-o \[$]@"
  -CC_EXENAME="-o \[$]@"
  -    else
  -SHLIB_LD="link -dll -nologo"
  -SHLIB_LD_LIBS="user32.lib advapi32.lib"
  -LIBS="user32.lib advapi32.lib"
  -AR="lib -nologo"
  -RC="rc"
  -MAKE_LIB="\${AR} -out:\[$]@"
  -MAKE_EXE="\${CC} -Fe\[$]@"
  -
  -if test "${SHARED_BUILD}" = "0" ; then
  -    # static
  -            AC_MSG_RESULT([using static flags])
  -    runtime=-MT
  -    MAKE_DLL="echo "
  -    LIBSUFFIX="s\${DBGX}.lib"
  -    LIBRARIES="\${STATIC_LIBRARIES}"
  -    EXESUFFIX="s\${DBGX}.exe"
  -    DLLSUFFIX=""
  -else
  -    # dynamic
  -            AC_MSG_RESULT([using shared flags])
  -    runtime=-MD
  -    MAKE_DLL="\${SHLIB_LD} \${SHLIB_LD_LIBS} \$(LDFLAGS) -out:\[$]@"
  -    LIBSUFFIX="\${DBGX}.lib"
  -    DLLSUFFIX="\${DBGX}.dll"
  -    EXESUFFIX="\${DBGX}.exe"
  -    LIBRARIES="\${SHARED_LIBRARIES}"
  -fi
  -
  -EXTRA_CFLAGS="-YX"
  -CFLAGS_DEBUG="-nologo -Z7 -Od -WX ${runtime}d"
  -#CFLAGS_OPTIMIZE="-nologo -O2 -Gs -GD ${runtime}"
  -CFLAGS_OPTIMIZE="-nologo -Oti -Gs -GD ${runtime}"
  -CFLAGS_WARNING="-W3"
  -LDFLAGS_DEBUG="-debug:full -debugtype:cv"
  -LDFLAGS_OPTIMIZE="-release"
  -PATHTYPE=-w
  -
  -# Specify the CC output file names based on the target name
  -CC_OBJNAME="-Fo\[$]@"
  -CC_EXENAME="-Fe\"\$(shell cygpath \$(PATHTYPE) '\[$]@')\""
  -
  -# Specify linker flags depending on the type of app being 
  -# built -- Console vs. Window.
  -LDFLAGS_CONSOLE="-subsystem:console"
  -LDFLAGS_WINDOW="-subsystem:windows"
  -    fi
  -])
  -
  -#------------------------------------------------------------------------
  -# SC_WITH_TCL --
  -#
  -#Location of the Tcl build directory.
  -#
  -# Arguments:
  -#none
  -#
  -# Results:
  -#
  -#Adds the following arguments to configure:
  -#--with-tcl=...
  -#
  -#Defines the following vars:
  -#TCL_BIN_DIRFull path to the tcl build dir.
  -#------------------------------------------------------------------------
  -
  -AC_DEFUN(SC_WITH_TCL, [
  -    if test -d ../../tcl8.4$1/win;  then
  -TCL_BIN_DEFAULT=../../tcl8.4$1/win
  -    else
  -TCL_BIN_DEFAULT=../../tcl8.4/win
  -    fi
  -    
  -    AC_ARG_WITH(tcl, [  --with-tcl=DIR          use Tcl 8.4 binaries from DIR],
  -    TCL_BIN_DIR=$withval, TCL_BIN_DIR=`cd $TCL_BIN_DEFAULT; pwd`)
  -    if test ! -d $TCL_BIN_DIR; then
  -AC_MSG_ERROR(Tcl directory $TCL_BIN_DIR does not exist)
  -    fi
  -    if test ! -f $TCL_BIN_DIR/Makefile; then
  -AC_MSG_ERROR(There is no Makefile in $TCL_BIN_DIR:  perhaps you did not specify the Tcl *build* directory (not the toplevel Tcl directory) or you forgot to configure Tcl?)
  -    else
  -echo "building against Tcl binaries in: $TCL_BIN_DIR"
  -    fi
  -    AC_SUBST(TCL_BIN_DIR)
  -])
  -
  -#------------------------------------------------------------------------
  -# SC_PROG_TCLSH
  -#Locate a tclsh shell in the following directories:
  -#${exec_prefix}/bin
  -#${prefix}/bin
  -#${TCL_BIN_DIR}
  -#${TCL_BIN_DIR}/../bin
  -#${PATH}
  -#
  -# Arguments
  -#none
  -#
  -# Results
  -#Subst's the following values:
  -#TCLSH_PROG
  -#------------------------------------------------------------------------
  -
  -AC_DEFUN(SC_PROG_TCLSH, [
  -    AC_MSG_CHECKING([for tclsh])
  -
  -    AC_CACHE_VAL(ac_cv_path_tclsh, [
  -search_path=`echo ${exec_prefix}/bin:${prefix}/bin:${TCL_BIN_DIR}:${TCL_BIN_DIR}/../bin:${PATH} | sed -e 's/:/ /g'`
  -for dir in $search_path ; do
  -    for j in `ls -r $dir/tclsh[[8-9]]*.exe 2> /dev/null`  -    `ls -r $dir/tclsh* 2> /dev/null` ; do
  -if test x"$ac_cv_path_tclsh" = x ; then
  -    if test -f "$j" ; then
  -ac_cv_path_tclsh=$j
  -break
  -    fi
  -fi
  -    done
  -done
  -    ])
  -
  -    if test -f "$ac_cv_path_tclsh" ; then
  -TCLSH_PROG=$ac_cv_path_tclsh
  -AC_MSG_RESULT($TCLSH_PROG)
  -    else
  -AC_MSG_ERROR(No tclsh found in PATH:  $search_path)
  -    fi
  -    AC_SUBST(TCLSH_PROG)
  -])
  -
  +builtin(include,tcl.m4)
  Index: win/configure.in
  ===================================================================
  RCS file: /cvsroot/tk/win/configure.in,v
  retrieving revision 1.17
  diff -u -r1.17 configure.in
  --- configure.in2000/05/03 00:18:371.17
  +++ configure.in2000/06/07 12:33:05
  @@ -75,9 +75,9 @@

   SC_ENABLE_SYMBOLS

  -TK_DBGX=${DBGX}
   CFLAGS=${CFLAGS_DEFAULT}
   LDFLAGS=${LDFLAGS_DEFAULT}
  +TK_DBGX=${DBGX}

   #--------------------------------------------------------------------
   # Locate and source the tclConfig.sh file.
  @@ -92,15 +92,28 @@
   # Perform final evaluations of variables with possible substitutions.
   #--------------------------------------------------------------------

  +TK_SHARED_LIB_SUFFIX="\${NODOT_VERSION}${DLLSUFFIX}"
  +TK_UNSHARED_LIB_SUFFIX="\${NODOT_VERSION}${LIBSUFFIX}"
  +TK_EXPORT_FILE_SUFFIX="\${NODOT_VERSION}${LIBSUFFIX}"
  +
   eval "TK_SRC_DIR=`cd $srcdir; pwd`"
  +eval "TK_STUB_LIB_FILE=${LIBPREFIX}tkstub$VER${LIBSUFFIX}"
   eval "TK_DLL_FILE=tk$VER${DLLSUFFIX}"
  -eval "TK_LIB_FILE=tk$VER${LIBSUFFIX}"
  -eval "TK_STUB_LIB_FILE=tkstub$VER${LIBSUFFIX}"
  +eval "TK_LIB_FILE=${LIBPREFIX}tk$VER${LIBSUFFIX}"
  +
  +eval "TCL_STUB_LIB_FILE=${LIBPREFIX}tclstub$VER${LIBSUFFIX}"
   eval "TCL_DLL_FILE=tcl$VER${DLLSUFFIX}"
  -eval "TCL_LIB_FILE=tcl$VER${LIBSUFFIX}"
  -eval "TCL_STUB_LIB_FILE=tclstub$VER${LIBSUFFIX}"
  +eval "TCL_LIB_FILE=${LIBPREFIX}tcl$VER${LIBSUFFIX}"
  +
  +eval "DLLSUFFIX=${DLLSUFFIX}"
  +eval "LIBPREFIX=${LIBPREFIX}"
  +eval "LIBSUFFIX=${LIBSUFFIX}"
   eval "EXESUFFIX=${EXESUFFIX}"

  +CFG_TK_SHARED_LIB_SUFFIX=${TK_SHARED_LIB_SUFFIX}
  +CFG_TK_UNSHARED_LIB_SUFFIX=${TK_UNSHARED_LIB_SUFFIX}
  +CFG_TK_EXPORT_FILE_SUFFIX=${TK_EXPORT_FILE_SUFFIX}
  +
   AC_SUBST(TK_VERSION)
   AC_SUBST(TK_MAJOR_VERSION)
   AC_SUBST(TK_MINOR_VERSION)
  @@ -122,13 +135,19 @@
   AC_SUBST(TCL_SRC_DIR)
   AC_SUBST(TCL_BIN_DIR)
   AC_SUBST(TCL_DBGX)
  -
  +AC_SUBST(CFG_TK_SHARED_LIB_SUFFIX)
  +AC_SUBST(CFG_TK_UNSHARED_LIB_SUFFIX)
  +AC_SUBST(CFG_TK_EXPORT_FILE_SUFFIX)
  +dnl AC_SUBST(TCL_SHARED_BUILD)

   AC_SUBST(PATHTYPE)
  +AC_SUBST(CYGPATH)
  +AC_SUBST(VPSEP)
   AC_SUBST(CFLAGS_DEBUG)
   AC_SUBST(CFLAGS_OPTIMIZE)
   AC_SUBST(CFLAGS_WARNING)
   AC_SUBST(EXTRA_CFLAGS)
  +AC_SUBST(STLIB_LD)
   AC_SUBST(SHLIB_LD)
   AC_SUBST(SHLIB_LD_LIBS)
   AC_SUBST(SHLIB_CFLAGS)
  @@ -141,13 +160,23 @@
   AC_SUBST(LDFLAGS_CONSOLE)
   AC_SUBST(LDFLAGS_WINDOW)
   AC_SUBST(AR)
  +AC_SUBST(RANLIB)
   AC_SUBST(RC)
  +AC_SUBST(RC_OUT)
  +AC_SUBST(RC_TYPE)
  +AC_SUBST(RC_INCLUDE)
  +AC_SUBST(RES)
  +AC_SUBST(LIBS)
  +AC_SUBST(LIBS_GUI)
   AC_SUBST(DLLSUFFIX)
  +AC_SUBST(LIBPREFIX)
   AC_SUBST(LIBSUFFIX)
   AC_SUBST(EXESUFFIX)
   AC_SUBST(LIBRARIES)
   AC_SUBST(MAKE_LIB)
  +AC_SUBST(POST_MAKE_LIB)
   AC_SUBST(MAKE_DLL)
  +AC_SUBST(MAKE_EXE)
   AC_SUBST(TK_XINCLUDES)
   AC_SUBST(XINCLUDES)

  PatchFiles:
  Tcl:

      win/Makefile.in
      win/configure.in
      win/tcl.m4

      Tk:

      win/Makefile.in
      win/aclocal.m4
      win/configure.in

      You will also need to copy the new
      tcl/win/tcl.m4 to tk/win/tcl.m4
      before running autoconf.



  I applied this patch to the sources in CVS; it will go out with 8.4a2.  Thanks for the patch,

  - eric

  -- 06/13/2000 ericm


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

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

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

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

  The failure causes Tk to go into on infinite loop.

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

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

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


tkt_uuid: 691973ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: None
title: OS X Aqua: accelerators not drawn for menu entries under men
comment:
  Compiled from recent CVS checkout, OS 10.1.5, 
  Devel tools April 2002.  The -accelerator flag has
  no effect when the menu is attached to a menubutton.
  -accelerator works for menubutton menus on other OS's.
  I poked around in the source code, but wasn't able to
  track down where this is happening... perhaps in the 
  calls to MacOS?  At any rate, DrawMenuEntryAccelerator
  is not called when the menu attached to a menubutton 
  is posted

  test code:

  menubutton .mb -menu .mb.m -text Test
  menu .mb.m
  .mb.m add command -command {puts hello} -label hello
  .mb.m entryconfigure 1 -accelerator h
  pack .mb


tkt_uuid: 220380ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: UNIX cascade menus auto-posted
comment:
  OriginalBugID: 676 Bug
  Version: 8.0.3
  SubmitDate: '1998-09-09'
  LastModified: '2000-03-06'
  Severity: LOW
  Status: Released
  Submitter: lfb
  ChangedBy: ericm
  RelatedBugIDs: 691 1320
  OS: All Unix
  FixedDate: '2000-03-06'
  FixedInVersion: 8.3.1


  When a menu containing a cascade is entered under UNIX, the cascade menu is automatically posted, and the focus redirected to that cascade menu.  With nested cascades, entering a top level menu can instantly summon a distant child. (lfb)

  e.g.: Run this script, and enter the File menu with the mouse or keyboard

  menu .menu
  .menu add cascade -label "File" -menu .menu.f -underline 0

  menu .menu.f
  .menu.f add cascade -label "New" -menu .menu.f.new -underline 0

  menu .menu.f.new
  .menu.f.new add cascade -label "File" -underline 0

  . configure -menu .menu



  This is verified "quirk".  The problem is that if you take away
  the piece that auto-posts cascades like the above, then when
  you move left/right in the menubar, you will not autopost those
  menus either (instead having to arrow down into it, as you
  expect one to arrow right in the above case).  To look for a
  better solution, edit tkMenuNextEntry in menu.tcl. 
  -- 08/13/1999 hobbs

  This is fixed in 8.3.1.  I changed tkMenuFirstEntry to only post a first entry that is a cascade if the current menu is a menubar, thus avoiding the cascading cascades effect.

  - eric

  -- 03/06/2000 ericm


tkt_uuid: 220310ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: App gives "Tk_FreeCursor called before Tk_GetCursor" and core dumps on exit.
comment:
  OriginalBugID: 5962 Bug
  Version: 8.3
  SubmitDate: '2000-06-28'
  LastModified: '2000-06-30'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: HP-UX
  OSVersion: HP-UX 10.20
  ClosedDate: '2000-06-30'


  Name:
  John McNeill

  Extensions:
  DMH

  Comments:
  The application was developed using Visual Tcl on Windows NT and ftp'ed
      to the HP-UX.  Another application developed and transferred the same
      way does not display this error.

  ReproducibleScript:
  We invoke wish8.3 to run an application. (wish8.3 <app name> from the command line)

  ObservedBehavior:
  On exit, the application displays "Tk_FreeCursor called before Tk_GetCursor" and core dumps.

  DesiredBehavior:
  No message; no core dump



  There was a particular bug in 8.3.0 relating to configuring the cursor of a listbox, and then destroying the listbox, which caused a core dump and may cause a message like the one you see.  The workaround was to unconfigure the cursor, ie:

  listbox .l
  .l configure -cursor crosshair
  .l configure -cursor {}
  exit

  will not cause the coredump.  The bug was fixed in 8.3.1; I recommend you upgrade to that version, or wait for 8.3.2, which should be released in 2-3 weeks.

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

  -- 06/30/2000 ericm


tkt_uuid: 1292219fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 21. [panedwindow]
priority: 7 High
foundin: None
resolution: None
title: panedwindow don't propagate Map/Unmap state to children
comment:
  Unlike the other geometry manager (e.g. pack, see
  tkPack.c, 1400), panedwindow do not handle MapNotify
  and UnmapNotify events to propagate to its children.

  So, we can have:

  panedwindow .pw
  .pw add [button .pw.b]
  pack .pw
  update
  puts [winfo ismapped .pw.b] ;# => 1
  pack forget .pw
  update
  puts [winfo ismapped .pw.b] ;# => 1
  puts [winfo ismapped .pw] ;# => 0

  This is the same for ttk::notebook.


tkt_uuid: 592638ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: remove tcltest dependence
comment:
  Tk's Makefile on Windows enforces
  a dependence of the tktest executable
  on the tcltest executable from Tcl, and
  its components, even though nothing
  in those components is actually used.

  This patch removes this dependence,
  which appears to be vestigial.

  Assigning to kennykb in hopes he
  has time to test this on an appropriate
  platform.  If not, pass along to someone
  who can.


tkt_uuid: 788825ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 7 High
foundin: obsolete: 8.4.2
resolution: None
title: Tk does not handle non-us primary xkb map properly
comment:
  I had:

  in /etc/X11/XF86Config:
  Section "InputDevice"
    Option       "XkbLayout" "cz_qwerty,us"

  than I run Python's IDLE, that did (using Python-Tk):
  text.event_add("<<calltip-show>>", "(")

  but nothing happend (Czech keyboard has "(" on
  different position) (even if I switched to the
  secondary keymap meanwhile).

  I discovered that it's a problem of a primary xkb map.
  When I change XF86Config to:
  Section "InputDevice"
    Option       "XkbLayout" "us,cz_qwerty"

  it works now.

  I checked other Tk programs and it's broken the same
  way. I guess Tk doesn't use the X events in a proper way...

  Is it understandable? What do you think?

  My e-mail address is: vinil@zagamma.cz. Please, CC me.


tkt_uuid: 1779265fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 8
foundin: obsolete: 8.4.15
resolution: None
title: GUI freezes in some laptops running Windows
comment:
  There is a strange problem that only occurs in some notebooks running Windows. 
  I have a Tcl/Tk application that executes another one using 'open |<command> r+', the pipe returned by open is used to communicate to the standard input/output of the new process. 
  The second process works fine until any key is pressed when any of its windows owns the focus, then the GUI freezes. But if something is written in its 'stdin' it wakes up, then the key event is received, and everything works again. After that no more key presses causes a freeze.

  This pair of Tcl files recreates the error: 
  ########################################## 
  ## File run-hello.tcl 
  proc read-pipe {pipe} {
      if {![eof $pipe]} {
          puts [gets $pipe]
      } else {
          close $pipe
      }
  }

  set pipe [open "| tclsh.exe hello.tcl" r+]
  fconfigure $pipe -buffering line
  fileevent $pipe readable [list read-pipe $pipe]

  package require Tk
  button .b -text {Send -wake up-} -command [list puts $pipe {wake up}]
  pack .b
  ########################################## 

  ########################################## 
  ## File hello.tcl 
  proc read-pipe {pipe} {
      if {![eof $pipe]} {
          puts [gets $pipe]
      } else {
          close $pipe
      }
  }
  fileevent stdin readable {read-pipe stdin}

  package require Tk
  button .b -text Hello -command {puts Hello!}
  pack .b
  ########################################## 

  This code seems to be correct and it works fine in Unix and most Windows machines, it only hangs in some laptops running Windows. 

  The laptop were I detected the bug, is a Compaq nc6400. But I know it happened also in an IBM Thinkpad.
  I have tested it with some versions of tcl, and the problem has always appeared:
  ActiveTcl 8.4.7
  ActiveTcl 8.4.15
  dqkit     8.4.13
  tclkit    8.5.a6

  OS version: Windows XP Professional SP2
  Other info:
  env(PROCESSOR_ARCHITECTURE) = x86
  env(PROCESSOR_IDENTIFIER)   = x86 Family 6 Model 14 Stepping 8, GenuineIntel
  env(PROCESSOR_LEVEL)        = 6
  env(PROCESSOR_REVISION)     = 0e08
  tcl_platform(byteOrder) = littleEndian
  tcl_platform(machine)   = intel
  tcl_platform(os)        = Windows NT
  tcl_platform(osVersion) = 5.1
  tcl_platform(platform)  = windows
  tcl_platform(wordSize)  = 4


tkt_uuid: 1377481fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 25. Built-in Bitmaps
priority: 5 Medium
foundin: None
resolution: None
title: Patch to panic if Tk button resources not found
comment:
  I recently built a static executable that linked
  to a static Tk library (not a dll). Things seemed
  to work except for checkbuttons and related widgets.
  The problem was that my executable needed to also
  link in resources that were part of Tk build are
  not included in the static library. The Tk code
  was not a lot of help since it just silently did
  the wrong thing. I think this patch will fix it
  by calliung panic() if someone runs into this case
  in the future. This should not change anything
  about wish.exe or tk.dll, it should only matter
  when someone links to a static version of Tk.

  Mo DeJong


tkt_uuid: 607649ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Duplicate
title: XP Menu Sizing and Image Problems
comment:
  The screenshots here demonstrate the bugs: 
  http://www.xmission.com/~georgeps/bugs/

  As you can see the menu items get cut off on the right.  
  This shows up with images mostly, and it seems that 
  images don't animate properly in TkChat with the 
  current menu code (redraw issue?).  These problems 
  don't occur with Tcl/Tk 8.3.2 in XP.  Jeff Hobbs thought 
  that it might be a bug introduced by the compound 
  menu code.


tkt_uuid: 2024753fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.6a1
resolution: Fixed
title: listbox-28.2 duplication
comment:
  In listbox.test:

  test listbox-28.2 {listbox -activestyle} {!win} {
      destroy .l
      listbox .l
      .l cget -activestyle
  } dotbox
  test listbox-28.2 {listbox -activestyle} {win} {
      destroy .l
      listbox .l
      .l cget -activestyle
  } underline

  Each test name should be used only
  once.  A simple change to deal with
  this is to add .win to one of the test
  names.

  The !win constraint is using tcltest's
  constraint expressions "feature" which
  is really better off not used.  Create
  a named constraint with the meaning you
  need instead.

  I'll also suggest that the "win" constraint
  may not be the best to use.  The "win"
  constraint asserts the tests are running
  on some Windows system.  The graphical
  things getting tested here might be better
  served by a constraint directly connected
  to the [tk windowingsystem].

  Assigning to patthoyts since the bug
  originates with his commit, but feel
  free to pass on to aniap if you like.


tkt_uuid: 219968ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Duplicate
title: scale fails with uninitialized -variable on HP and 64-bit Solaris (with openWin display)
comment:
  OriginalBugID: 1748 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-07'
  LastModified: '1999-04-19'
  Severity: CRIT
  Status: Closed
  Submitter: hershey
  ChangedBy: hershey
  RelatedBugIDs: 1686 1731
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-19'


      ==== scale-5.3 ConfigureScale procedure FAILED
      ==== Contents of test case:
      
          catch {destroy .s}
          catch {unset x}
          scale .s -from 0 -to 100 -variable x
          set result $x
          lappend result [.s get]
          set x 92
          lappend result [.s get]
          .s set 3
          lappend result $x
          unset x
          lappend result [catch {set x} msg] $msg
      
      ---- Result was:
      100 100 92 3 0 3
      ---- Result should have been:
      0 0 92 3 0 3
      ==== scale-5.3 FAILED


  this bug was already reported on digital unix.
  -hershey


tkt_uuid: 780536ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: <Control-Alt-Key-Anything> on MacOSX
comment:
  I can not seem to get my Control-Alt sequences 
  working on my Mac OSX port. I "hide" special options 
  on Control-Alt sequences. They work great on our 
  other ports, but I can't make them "fire" on the Mac.

  Alt key seems to generate a Meta KEYSYM and the Apple 
  key seems to generate an Alt KEYSYM. I can work
  with either, but can't get anything to trigger my 
  bindings.

  Ex.

     bind all <Control-Alt-Key-b> "bell"

  Holding Control, Pressing and Holding Alt, and
  pressing the b key should beep once for each time
  the b key is pressed until the Control and/or Alt
  are released. Right?


     


tkt_uuid: 220113ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 1 Zero
foundin: obsolete: 8.1a2
resolution: Invalid
title: canvas find withtag do not work with swedish characters
comment:
  OriginalBugID: 761 Bug
  Version: 8.1a2
  SubmitDate: '1998-10-27'
  LastModified: '1999-05-20'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hershey
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1998-12-08'


  Subject: canvas find withtag do not work with swedish characters "åäöÅÄÖ"
  From: mats.gauffin@lm.se

  Tk 8.1a2 Bug
  email:  mats.gauffin@lm.se
  Severity:  2
  Support:  None
  OperatingSystem:  Sun Solaris
  OperatingSystemVersion:  2.6
  Synopsis:  canvas find withtag do not work with swedish characters "åäöÅÄÖ"

  ReproducibleScript:
  create a canvas add items with tags including swedish characters "ÅÄÖåäö"
  .c create polygon -241 ... -tags {"xxÅxx"}
  set se_key "xxÅxx"
    [$c find withtag $se_key]
  do not return any object

  DesiredBehavior:
  same as without swedish characters

  The sample script has two quoting bugs.  This problem does not seem to be reproducible.


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: 220188ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: wish8.1 doesn't start under SCO5.0.4
comment:
  OriginalBugID: 2010 Bug
  Version: 8.1
  SubmitDate: '1999-05-07'
  LastModified: '1999-09-16'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Other
  OSVersion: SCO5.0.4
  Machine: NA
  ClosedDate: '1999-09-16'


  Name:
  Luca

  Comments:
  Up to 8.0.5 everything was right

  ReproducibleScript:
  compile and install Tcl8.1 (with --enable-shared)
      compile and install Tk8.1  (with --enable-shared)

  ObservedBehavior:
  Trying to run wish8.1 will give you:
      Application initialization failed: syntax error in expression "[catch
      {uplevel #0 [list source $tclfile]} msg] != 1"



  There appears to have been an error during installation, because
  this error is otherwise unknown.  The given expression looks to
  be OK though. 
  -- 09/16/1999 hobbs


tkt_uuid: 624732ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.3.4
resolution: Fixed
title: text -wrap none crash with binary data
comment:
  Adding a whole load of nulls to a text widget with -wrap 
  none causes it to crash on Digital Unix 4.0E.

  For example:

  pack [text .t -wrap none] 
  .t insert end [string repeat "\0" 500] 

  gdb gives some info, but unfortunately this was built 
  without debugging.

  Program received signal SIGSEGV, Segmentation fault.
  0x300008a1c00 in Tcl_UtfToUniChar ()
     from 
  /home5/pubseq/share/distrib/unix-2002.0/lib/alpha-binaries/libtcl8.4.so
  (gdb) where
  #0  0x300008a1c00 in Tcl_UtfToUniChar ()
     from 
  /home5/pubseq/share/distrib/unix-2002.0/lib/alpha-binaries/libtcl8.4.so
  #1  0x3000005cc08 in TkpFontPkgInit ()
     from 
  /home5/pubseq/share/distrib/unix-2002.0/lib/alpha-binaries/libtk8.4.so
  #2  0x30000859178 in Tcl_UtfToExternalDString ()
     from 
  /home5/pubseq/share/distrib/unix-2002.0/lib/alpha-binaries/libtcl8.4.so
  warning: Hit heuristic-fence-post without finding
  warning: enclosing function for address 0x1400834c8


tkt_uuid: 219903ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: bug in tk_getOpenFile when called before adding widgets to the "." window
comment:
  OriginalBugID: 715 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-13'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: admin
  ChangedBy: hobbs
  RelatedBugIDs: 1212
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-20'


  # BUG:
  # This code demonstrates an apparent bug in the grab handling of
  # tk_getOpenFile, if run at the start of a program.  If tk_getOpenFile
  # is run before adding any widgets to the "." window, the widgets in
  # the "." window will fail to respond to any events other than 
  # WM_DESTROY and resizing.  Note that this behavior is only exhibited
  # on Windows, not on Unix or MacOS.
  #
  # AFFECTED PLATFORMS:
  # - Tcl 8.0p2 & 8.0.3 on Win NT4 (SP3), Win 98, Win 95 (OSR2.5)
  #
  # UNAFFECTED PLATFORMS:
  # - Tcl 8.0p2 on Solaris 2.5
  # - Tcl 8.0.3 on Linux (Redhat 5.0)
  # - Tcl 8.0.3 on MacOS
  #
  # WORKAROUND:
  # This can be worked around by doing the tk_getOpenFile after windows
  # have been mapped, using an "after idle" as shown in the lower section
  # of this program.

  set demonstrate_bug 1

  if {$demonstrate_bug} {
      set inputFile [tk_getOpenFile -title "Choose a URL-Mapping Text File"  -filetypes {{{Text Files} {.txt}}} -initialdir [pwd]]
      label .l1 -text "Selected:" -justify left -anchor w
      label .l2 -textvariable inputFile -justify left -anchor w
      button .b -text Ok -command exit
      pack .l1 .l2 .b -side top -fill x
  } else {
      label .l1 -text "Selected:" -justify left -anchor w
      label .l2 -textvariable inputFile -justify left -anchor w
      button .b -text Ok -command exit
      pack .l1 .l2 .b -side top -fill x
      after idle {
          set inputFile [tk_getOpenFile -title "Choose a URL-Mapping Text File"  -filetypes {{{Text Files} {.txt}}} -initialdir [pwd]]
      }
  }


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: 666243ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: None
resolution: None
title: labels not moving in Mac OSX
comment:
  Problem detected only at Mac OSX when using the multi-column listbox, tablelist package, from www.nemethi.de. It works under Sun Solaris 8.0 and Window 2000.

  After creating a tablelist with multiple columns, and attaching it with vertical and horizontal bar. Shrink the width of the multi-col listbox, so you can slide the horizontal bar.

  In Sun and Window 2000, the lable and data columns move left and right accordingly.

  In Mac OSX, I am using 8.4.1 tcl/tk, the label will not move, only the data column move.

  Enclosed are the sample program you can use.
  You can start my example use:

  % source NavigateDir.tk
  % fmgr::NavigateDir:display {} -dir /usr


tkt_uuid: 220387ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: wish crashes in scrollbar code if locale is not
comment:
  OriginalBugID: 744 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-19'
  LastModified: '1999-10-22'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-10-22'
  FixedInVersion: 8.2


  I would like to report a bug, which affects the wish program, if
  the character-type locale is set to something other than C.

  Reproduce-by:

  setenv LC_CTYPE de_DE

  and execute following script:

  === snip ===
  #!/usr/bin/wish -f

  frame .main
  listbox .list -yscrollcommand ".sb set" 
  scrollbar .sb
  pack .list -side left -in .main
  pack .sb -side left -fill y -in .main

  pack .main 
  === snip ===

  The program reports:

  Error: unknown floating-point error, errno = 84

  and the stack trace is

  unknown floating-point error, errno = 84
      while executing
  ".sb set 0 1"
      (vertical scrolling command executed by listbox)


  Environment:

  Linux 2.1.125
  glibc 2.0.7
  Tcl/Tk 8.0.3

  Errno 84 is
  #define EILSEQ          84      /* Illegal byte sequence */

  which is probably a bit confusing - I suspect something
  like reading errno when no error was returned from the
  syscall or something like this.

  Regards
  --
  Stanislav Meduna



  Tcl is not designed to run in anything but "C" locale, so this isn't a critical problem.  That said, it still shouldn't crash.
  ---
  This is no longer pertinent in 8.2, as code exists to maintain
  "acceptable" locales for use with X and i18n. 
  -- 10/22/1999 hobbs


tkt_uuid: 565760ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Out of Date
title: tk compilation on macosx
comment:
  Hi all,

  I downloaded Tcl/Tk 8.3.4 source code and tried to
  compile on MacOSX.
  The Tcl compilation was ok but not for Tk.

  configure command:
  ./configure --prefix=/Users/raphael/software
  --x-includes=/usr/X11R6/include
  --x-libraries=/usr/X11R6/lib

  during make, Tk compilation failed at the Tk shared lib
  generation (libtk8.3.dylib).

  The commands produced by the Makefile was:

  cc -dynamiclib -prebind  -o libtk8.3.dylib tk3d.o
  tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkClipboard.o
  tkCmds.o tkColor.o tkConfig.o tkConsole.o tkCursor.o
  tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o
  tkGeometry.o tkGrab.o tkGrid.o tkMain.o tkObj.o
  tkOldConfig.o tkOption.o tkPack.o tkPlace.o tkSelect.o
  tkUtil.o tkVisual.o tkWindow.o tkUnix.o tkUnix3d.o
  tkUnixButton.o tkUnixColor.o tkUnixConfig.o
  tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o
  tkUnixFocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o
  tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o
  tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o
  tkUnixXId.o tkStubInit.o tkStubLib.o tkButton.o
  tkEntry.o tkFrame.o tkListbox.o tkMenu.o tkMenubutton.o
  tkMenuDraw.o tkMessage.o tkScale.o tkScrollbar.o
  tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o
  tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o
  tkCanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o
  tkImage.o tkImgBmap.o tkImgGIF.o tkImgPPM.o
  tkImgPhoto.o tkText.o tkTextBTree.o tkTextDisp.o
  tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o
  tkTextWind.o  -L/Users/raphael/tcl8.3.4/unix

  I found several problems and solved them as follow:

  1) Missing paths for linking.
  with error message:

  ld: Undefined symbols:
  _Tcl_DeleteHashEntry
  _Tcl_Free
  ..

  That was easily solved by adding at the end of the cc
  command:
  -L/Users/raphael/tcl8.3.4/unix -ltcl8.3
  -L/usr/X11R6/lib -L/sw/lib -lX11 -ldl -lm -lc

  I guess that during the configure script generation or
  execution, the -L and linked libs need to be added in
  the Makefile (usually on other platforms, something
  like -L../../tclx.y/unix is added for tcl shared lib).

  2) With the corrected cc command, I got another error:

  ld: warning multiple definitions of symbol _dataKey
  tkMain.o definition of _dataKey in section
  (__DATA,__common)
  /Users/raphael/tcl8.3.4/unix/libtcl8.3.dylib(tclMain.o)
  definition of _dataKey

  It seems that this is related to the declaration of:

  Tcl_ThreadDataKey dataKey;

  in generic/tkMain.c
  By changing the declaration to:

  static Tcl_ThreadDataKey dataKey;

  the compilation goes ok.
  After that, I restarted make and managed to compile all.

  Thanks for this release since it solves the dynamic
  loading problem of the Tk shared lib through a tclsh
  script (command 'package require Tk') that was failing
  in earlier versions on MacOSX.

  Cheers,

  Raphael


tkt_uuid: 1036245fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Invalid
title: grid places new cell over old (removed one)
comment:
  The following example shows the issue:

    
  label .l1 -text 1
  label .l2  -text 2
  grid .l1    
  grid remove .l1
  grid .l2
  grid .l1

  if we remove last grid cells their place is overtaken
  by creating next cells
  even the first cells are not forgotten (like in grid
  forget), the placement is
  wrong

  puts  [ grid info .l1 ]
  -in . -column 0 -row 0 -columnspan 1 -rowspan 1 -ipadx
  0 -ipady 0 -padx 0 
  -pady 0 -sticky {}

  puts  [ grid info .l2 ]
  -in . -column 0 -row 0 -columnspan 1 -rowspan 1 -ipadx
  0 -ipady 0 -padx 0 
  -pady 0 -sticky {}

  It shows that both cells have the same place now!!!!!!!!

  Workaround: firstly create all cells, afterwards
  remove/re-add necessary ones. 8.3 did not have this bug


tkt_uuid: 220100ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1a2
resolution: Invalid
title: dde problem
comment:
  OriginalBugID: 557 Bug
  Version: 8.1a2
  SubmitDate: '1998-03-31'
  LastModified: '1999-03-31'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: redman
  OS: Windows 95
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-03-31'


  From: Gang Wang <wanggang@computermotion.com>
  Newsgroups: comp.lang.tcl
  Subject: dde problem
  Date: Wed, 25 Mar 1998 14:28:17 -0800
  Organization: Silicon Beach - Business Internet Services
  Lines: 11
  Message-ID: <35198501.2B33@computermotion.com>
  Reply-To: wanggang@computermotion.com
  NNTP-Posting-Host: host116.computermotion.com
  Mime-Version: 1.0
  Content-Type: text/plain; charset=us-ascii
  Content-Transfer-Encoding: 7bit
  X-Mailer: Mozilla 3.0Gold (Win95; I)
  Xref: nntp2.ba.best.com comp.lang.tcl:69969


  I tried the new dde command in Tk8.1 on window95. 
  It did not work as it was claimed. 
  I issued : 
  %dde execute -async Winword Documnet1 "Hello World"
  Then the word window blinks and dde command in wish console did not
  return. Unless I bring word window to the top ( activate it ), it keeps
  hanging on there. 


  Any idea to fix this ?


  Gang

  03/31/1999 15:48 - redman - No hang, but Winword blinks (correct behavior actually).


tkt_uuid: 1028888fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 51. [place]
priority: 8
foundin: obsolete: 8.4.7
resolution: Fixed
title: memory leak in [place forget]
comment:
  This script causes memory use
  to grow without bound:

  . configure -width 500 -height 50 -bg white
  frame .f -height 50 -width 5 -bg red
  place .f -x 250 -y 0 -anchor nw
  set place 0
  while 1 {
      place forget .f
      place .f -x [expr {[incr place] %500}]
  }


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




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


tkt_uuid: 1844430fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: None
title: cygwin make fails in 8.4.14-8.5b3
comment:
  When building tk in the cygwin environment, the Makefile dependencies should use the cygwin file names not the Windows native ones.  Currently, the following error message is given:

  Makefile:419: *** target pattern contains no `%'.  Stop.

  And if that one is fixed, there's an other one on line 425 (the line numbers are from tk 8.5b3).

  Attached is a patch that changes the two dependencies on
  TCL_SRC_DIR_NATIVE to TCL_SRC_DIR in tk-src/win/Makefile.in.


tkt_uuid: 846141ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 58. [send]
priority: 5 Medium
foundin: None
resolution: None
title: winSend.test failures and tkWinSend.c bug
comment:
  The listed tests fail on WinXP, Tk 8.5a0.  Also I note
  that code like this:

  Tcl_SetStringObj(Tcl_GetObjResult(interp),
      "option not implemented: \"displayof\" is not
  available "
      "for this platform.", -1);

  Is no good if the result object is shared -- it will
  trigger a panic.

  Vince.

  ----

  winSend.test

  ==== winSend-2.1 Tk_SendObjCmd - # of args FAILED
  ==== Contents of test case:

      list [catch {send tktest} msg] $msg

  ---- Result was:
  1 {bad option "tktest": must be -async, -displayof, or
  --wrong # args: should be
   "send ?-async? ?-displayof? ?--? interpName arg ?arg
  ...?"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "send ?options? interpName
  arg ?arg ...?"}
  ==== winSend-2.1 FAILED


  ==== winSend-2.1 Tk_SendObjCmd: arguments FAILED
  ==== Contents of test case:

      list [catch {send -bogus tktest} msg] $msg

  ---- Result was:
  1 {no application named "-bogus"}
  ---- Result should have been (exact matching):
  1 {bad option "-bogus": must be -async, -displayof, or --}
  ==== winSend-2.1 FAILED


  ==== winSend-2.1 Tk_SendObjCmd: arguments FAILED
  ==== Contents of test case:

      list [catch {send -async bogus foo} msg] $msg

  ---- Result was:
  1 {no application named "bogus"}
  ---- Result should have been (exact matching):
  1 {no registered server named "bogus"}
  ==== winSend-2.1 FAILED


  ==== winSend-2.1 Tk_SendObjCmd: arguments FAILED
  ==== Contents of test case:

      list [catch {send -displayof . bogus foo} msg] $msg

  ---- Result was:
  1 {option not implemented: "displayof" is not available
  for this platform.}
  ---- Result should have been (exact matching):
  1 {no registered server named "bogus"}
  ==== winSend-2.1 FAILED


  ==== winSend-2.1 Tk_SendObjCmd: arguments FAILED
  ==== Contents of test case:

      list [catch {send -- -bogus foo} msg] $msg

  ---- Result was:
  1 {no application named "-bogus"}
  ---- Result should have been (exact matching):
  1 {no registered server named "-bogus"}
  ==== winSend-2.1 FAILED


  ==== winSend-2.4 Tk_SendObjCmd - sending to ourselves
  in a different interp with
   errors FAILED
  ==== Contents of test case:

      newApp testApp
      list [catch {send testApp {expr 2 / 0}} msg] $msg
  $errorCode $errorInfo [int
  erp delete testApp]

  ---- Result was:
  1 {divide by zero} ARITH {divide by zeroDIVZERO
      invoked from within
  "send testApp {expr 2 / 0}"} {}
  ---- Result should have been (exact matching):
  1 {divide by zero} {ARITH DIVZERO {divide by zero}}
  {divide by zero
      while executing
  "expr 2 / 0"
      invoked from within
  "send testApp {expr 2 / 0}"} {}
  ==== winSend-2.4 FAILED


  ==== winSend-2.7 Tk_SendObjCmd - sending to another app
  - error FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {send $interp {expr 2 / 0}} msg] $msg
  $errorCode $errorInfo

  ---- Result was:
  1 {divide by zero} ARITH {divide by zeroDIVZERO
      invoked from within
  "send $interp {expr 2 / 0}"}
  ---- Result should have been (exact matching):
  1 {divide by zero} {ARITH DIVZERO {divide by zero}}
  {divide by zero
      while executing
  "expr 2 / 0"
      invoked from within
  "send $interp {expr 2 / 0}"}
  ==== winSend-2.7 FAILED


  ==== winSend-3.1 TkGetInterpNames FAILED
  ==== Contents of test case:

      set origLength [llength $currentInterps]
      set newLength [llength [winfo interps]]
      expr {($newLength - 2) == $origLength}

  ---- Result was:
  0
  ---- Result should have been (exact matching):
  1
  ==== winSend-3.1 FAILED


  ==== winSend-6.1 SendDDEServer - XTYP_CONNECT FAILED
  ==== Contents of test case:

      set foo "Hello, World"
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde request Tk [tk appname] foo"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {Hello, World}
  ==== winSend-6.1 FAILED


  ==== winSend-6.2 SendDDEServer - XTYP_CONNECT_CONFIRM
  FAILED
  ==== Contents of test case:

      set foo "Hello, World"
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde request Tk [tk appname] foo"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {Hello, World}
  ==== winSend-6.2 FAILED


  ==== winSend-6.3 SendDDEServer - XTYP_DISCONNECT FAILED
  ==== Contents of test case:

      set foo "Hello, World"
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde request Tk [tk appname] foo"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {Hello, World}
  ==== winSend-6.3 FAILED


  ==== winSend-6.4 SendDDEServer - XTYP_REQUEST variable
  FAILED
  ==== Contents of test case:

      set foo "Hello, World"
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde request Tk [tk appname] foo"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {Hello, World}
  ==== winSend-6.4 FAILED


  ==== winSend-6.5 SendDDEServer - XTYP_REQUEST array FAILED
  ==== Contents of test case:

      catch {unset foo}
      set foo(test) "Hello, World"
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde request Tk [tk appname] foo(test)"
      list [catch "send \{$interp\} \{$command\}" msg]
  $msg [catch {unset foo}]

  ---- Result was:
  1 {invalid command name "dde"} 0
  ---- Result should have been (exact matching):
  0 {Hello, World} 0
  ==== winSend-6.5 FAILED


  ==== winSend-6.6 SendDDEServer - XTYP_REQUEST return
  results FAILED
  ==== Contents of test case:

      set foo 3
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "send [tk appname] {expr $foo + 1}"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {no application named "tktest"}
  ---- Result should have been (exact matching):
  0 4
  ==== winSend-6.6 FAILED


  ==== winSend-6.7 SendDDEServer - XTYP_EXECUTE FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "send [tk appname] {expr 4 / 2}"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {no application named "tktest"}
  ---- Result should have been (exact matching):
  0 2
  ==== winSend-6.7 FAILED


  ==== winSend-6.8 SendDDEServer - XTYP_WILDCONNECT FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde services Tk {}"
      list [catch "send \{$interp\} \{$command\}"]

  ---- Result was:
  1
  ---- Result should have been (exact matching):
  0
  ==== winSend-6.8 FAILED


  ==== winSend-9.1 SetDDEError FAILED
  ==== Contents of test case:

      list [catch {dde execute Tk foo {set foo hello}}
  msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {dde command failed}
  ==== winSend-9.1 FAILED


  ==== winSend-10.1 Tk_DDEObjCmd - wrong num args FAILED
  ==== Contents of test case:

      list [catch {dde} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde ?-async? serviceName
  topicName value"}
  ==== winSend-10.1 FAILED


  ==== winSend-10.2 Tk_DDEObjCmd - unknown subcommand FAILED
  ==== Contents of test case:

      list [catch {dde foo} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {bad command "foo": must be execute, request, or
  services}
  ==== winSend-10.2 FAILED


  ==== winSend-10.3 Tk_DDEObjCmd - execute - wrong num
  args FAILED
  ==== Contents of test case:

      list [catch {dde execute} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde execute ?-async?
  serviceName topicName value"}
  ==== winSend-10.3 FAILED


  ==== winSend-10.4 Tk_DDEObjCmd - execute - wrong num
  args FAILED
  ==== Contents of test case:

      list [catch {dde execute 3 4 5 6 7} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde execute ?-async?
  serviceName topicName value"}
  ==== winSend-10.4 FAILED


  ==== winSend-10.5 Tk_DDEObjCmd - execute async - wrong
  num args FAILED
  ==== Contents of test case:

      list [catch {dde execute -async} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde execute ?-async?
  serviceName topicName value"}
  ==== winSend-10.5 FAILED


  ==== winSend-10.6 Tk_DDEObjCmd - request - wrong num
  args FAILED
  ==== Contents of test case:

      list [catch {dde request} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde request serviceName
  topicName value"}
  ==== winSend-10.6 FAILED


  ==== winSend-10.7 Tk_DDEObjCmd - services wrong num
  args FAILED
  ==== Contents of test case:

      list [catch {dde services} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde services serviceName
  topicName"}
  ==== winSend-10.7 FAILED


  ==== winSend-10.8 Tk_DDEObjCmd - null service name FAILED
  ==== Contents of test case:

      list [catch {dde services {} {tktest #2}}]

  ---- Result was:
  1
  ---- Result should have been (exact matching):
  0
  ==== winSend-10.8 FAILED


  ==== winSend-10.9 Tk_DDEObjCmd - null topic name FAILED
  ==== Contents of test case:

      list [catch {dde services {Tk} {}}]

  ---- Result was:
  1
  ---- Result should have been (exact matching):
  0
  ==== winSend-10.9 FAILED


  ==== winSend-10.10 Tk_DDEObjCmd - execute - nothing to
  execute FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {dde execute Tk $interp {}} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {cannot execute null data}
  ==== winSend-10.10 FAILED


  ==== winSend-10.11 Tk_DDEObjCmd - execute - no such
  conversation FAILED
  ==== Contents of test case:

      list [catch {dde execute Tk foo {set foo hello}}
  msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {dde command failed}
  ==== winSend-10.11 FAILED


  ==== winSend-10.12 Tk_DDEObjCmd - execute - async FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {dde execute -async Tk $interp {set foo
  hello}} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {}
  ==== winSend-10.12 FAILED


  ==== winSend-10.13 Tk_DDEObjCmd - execute FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {dde execute Tk $interp {set foo
  goodbye}} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {}
  ==== winSend-10.13 FAILED


  ==== winSend-10.14 Tk_DDEObjCmd - request - nothing to
  request FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {dde request Tk $interp {}} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {cannot request value of null data}
  ==== winSend-10.14 FAILED


  ==== winSend-10.15 Tk_DDEObjCmd - request - invalid
  interp FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {dde request Tk foo foo} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {dde command failed}
  ==== winSend-10.15 FAILED


  ==== winSend-10.16 Tk_DDEObjCmd - invalid variable FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      send $interp {unset foo}
      list [catch {dde request Tk $interp foo} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {remote server cannot handle this command}
  ==== winSend-10.16 FAILED


  ==== winSend-10.17 Tk_DDEObjCmd - valid variable FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      send $interp {set foo winSend-10.17}
      list [catch {dde request Tk $interp foo} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 winSend-10.17
  ==== winSend-10.17 FAILED


  ==== winSend-10.18 Tk_DDEObjCmd - services FAILED
  ==== Contents of test case:

      set currentService [list Tk [tk appname]]
      list [catch {dde services Tk {}} msg] [expr
  [lsearch $msg $currentService] >
  = 0]

  ---- Result was:
  1 0
  ---- Result should have been (exact matching):
  0 1
  ==== winSend-10.18 FAILED


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: 619440ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Invalid
title: Problem compiling tk 8.4
comment:
  Hi,

  I try to compile tk8.4.0 on my GNU/Linux system with
  gcc-3.2
  There was no problem with the configure but for the
  make i got this :

  # gmake
  gcc -pipe -rdynamic  tkAppInit.o \
  -L/tmp/tk8.4.0/unix -ltk8.4 \
  -framework Tcl  -lpthread -L/usr/X11R6/lib -lX11 -ldl
  -lieee -lm -Wl,-rpath,/usr/local/lib:/usr/X11R6/lib -o wish
  gcc: Tcl: No such file or directory
  gmake: *** [wish] Error 1


  I compiled tcl8.4.0 with --enable-framework




  It would be great if you could help me with this !

  Best regards,

  Pierre.


tkt_uuid: 220018ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Duplicate
title: Numeric Key Pad bindings do not work as expected
comment:
  OriginalBugID: 2680 Bug
  Version: 8.0p2
  SubmitDate: '1999-09-01'
  LastModified: '2000-04-03'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 1810
  OS: Solaris
  OSVersion: 2.5.1 (SunOS 5.5.1 Generic_103640-24)
  Machine: Other
  ClosedDate: '2000-04-03'


  Name:
  Raymond Steele

  Comments:
  Please review all funtions related to the numeric Key Pad and its
      interface.  If this turns out to be an
      OS bug please let me know.  I've asked for the auto post for the news
      group.  If anyone else has an
      answer to this please email me directly since I will probably not visit
      the news group posting often
      enough to catch a posting.  Thanks in advance.

  ReproducibleScript:
  #!/usr/local/bin/wish
      #########################################################################
      ##
      ##
      ##      This is a utility that displays keysyms to stdout.
      ##      The KeyRelease is needed because of a bug.
      ##      The bug also does not allow keysyms for KP_4, Left, KP_6,
      ##      and Right to be displayed. Furthermore, NumLock doesn't 
      ##      work as expected.  
      ##
      ##      This code was submitted as a bug report at the end of Aug `99
      ##
      ##      Raymond Steele 
      ##      rsteele@ieee.org
      ##
      #########################################################################
      ##

      set help_msg {
      This is a keysym generation test.
      }
      #########################################################################
      ##
      ## Display window
      #########################################################################
      ##
      frame    .msg         -bg lightblue -borderwidth 5 -relief ridge  
      message  .msg.helpmsg -justify left -text $help_msg -bg lightblue  -font {fixed 12 bold } -aspect 1000
      pack     .msg         -fill both -side top 
      pack     .msg.helpmsg

      frame    .control     -bg lightblue -borderwidth 10 
      pack     .control     -side bottom -fill both  -expand true

      button   .control.exit   -text exit -command Quit  -font {fixed 12 bold}  -bg lightblue -activebackground lightblue

      entry    .control.entry1 -textvariable typed -background white  -borderwidth 2 -relief sunken  -width 40  -font "fixed 12"
      bind     .control.entry1 <Left> {%W insert insert 4} 
      bind     .control.entry1 <KeyRelease> {%W icursor end} 
      bind     .control.entry1 <Key> {
  puts stdout {keycode: %k}; 
  puts stdout {printing character: %A}; puts stdout {keysym: %K};
  puts stdout {}
      } 
      bind     .control.entry1 <Right> {%W insert insert 6} 
      pack     .control.entry1 -expand true 
      pack     .control.exit   -expand false 

      focus .control.entry1
      #########################################################################
      ##
      ## Window Mangager Directives 
      #########################################################################
      ##
      wm protocol . WM_DELETE_WINDOW Quit
      wm title . "Keysym Utility"
      wm geometry . +500+400

      proc Quit {} {
          global typed

          puts stdout "You typed the following line:"
          puts stdout $typed
          exit
      }

      Run this script.  Type every button on the numeric key pad.  Observe
      entry and stdout.  If you remove
      the key bindings for Left, Right and . , you cannot enter 4, 6 or . in
      the entry using the numeric key pad.
      even if NumLock in on.

  ObservedBehavior:
  Although it is possible to edit the entry with the numeric key pad,
      there are unexpected results.  No
      keysym is generated for what should be Left, KP_4, Right, KP_6.  Keysyms
      generated for all key pad
      keys remain the same regardless of the NumLock key.  The most annoying
      thing is the Left key.  It 
      insists on moving the cursor back one character after a 4 is typed.
      This is the reason for the
      <KeyRelease> binding in the sample script.  When running the script,
      notice that the cursor jumps
      back and forth when a 4 is typed on the numeric key pad.  This works
      well enough, but I believe that
      future applications I write will have conflicts because of this strange
      behavior and lack of keysym 
      generation.

  DesiredBehavior:
  I should get KP_4 as a keysym when NumLock is on and the 4 of the
      numeric keypad is pressed.
      Furthermore, the cursor should not move back one character under these
      conditions.

      Also, note that besides no KP_6 keysym.  a Delete keysym should change
      to a . when NumLocks
      is on.  This same behavior is a problem for other keys as well but this
      bug report is primarily for 
      KP_4 and KP_6.

      The sample script includes a work around.  If the Left , Right and
      Delete key bindings are removed
      You cannot type a 4, 6 or . on the keypad and see a 4, 6 or a .  being
      entered in the entry.


tkt_uuid: 3076671fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: CVS HEAD Tk build fails on win32 with msys/mingw
comment:
  Trying to build CVS HEAD Tk fails - probably after changes to support Unicode:

  [23:02:58] 2  >> gcc -c -O2 -fomit-frame-pointer -DUNICODE -D_UNICODE -Wall -Wdeclaration-after-statement  -I"../../../sources/tk-8.6b1.2/win/../generic" -I"../../../sources/tk-8.6b1.2/win" -I"../../../sources/tk-8.6b1.2/win/../xlib" -I"../../../sources/tk-8.6b1.2/win/../bitmaps" -I"/y/cookit/sources/tcl-8.6b1.2//generic" -pipe -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DSTATIC_BUILD=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UXTHEME_H=1 -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1  -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int -DHAVE_WINNT_IGNORE_VOID=1 -DHAVE_ALLOCA_GCC_INLINE=1 -DHAVE_CAST_TO_UNION=1 -DTCL_CFGVAL_ENCODING=\"cp1252\" -DSTATIC_BUILD=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ZLIB=1 -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1   -DBUILD_tk -DBUILD_ttk "../../../sources/tk-8.6b1.2/win/tkWinSend.c" -o tkWinSend.o
  [23:03:00] 2  >> In file included from ../../../sources/tk-8.6b1.2/win/tkWinSend.c:15:
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/tchar.h:41: error: syntax error before "TCHAR"
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/tchar.h:42: error: syntax error before "_TCHAR"
  [23:03:00] 2  >> In file included from y:/cookit/sources/tcl-8.6b1.2/generic/tcl.h:2391,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/../generic/tkIntXlibDecls.h:25,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/../xlib/X11/Xlib.h:1196,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinPort.h:64,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/../generic/tkPort.h:20,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/../generic/tkInt.h:21,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSend.c:16:
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:53: error: syntax error before '*' token
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:54: warning: type defaults to `int' in declaration of `Tcl_WinUtfToTChar'
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:54: warning: data definition has no type or storage class
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:56: warning: type defaults to `int' in declaration of `TCHAR'
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:56: error: syntax error before '*' token
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:77: error: syntax error before "TCHAR"
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:77: warning: no semicolon at end of struct or union
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:78: warning: type defaults to `int' in declaration of `TCHAR'
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:78: error: syntax error before '*' token
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:84: warning: type defaults to `int' in declaration of `TclPlatStubs'
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:84: warning: data definition has no type or storage class
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:89: error: syntax error before '*' token
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:89: warning: type defaults to `int' in declaration of `tclPlatStubsPtr'
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:89: warning: data definition has no type or storage class
  [23:03:00] 2  >> In file included from Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windef.h:246,
  [23:03:00] 2  >>                  from Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h:48,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWin.h:38,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinInt.h:28,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSendCom.h:19,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSend.c:17:
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winnt.h:96: error: syntax error before "TBYTE"
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winnt.h:97: error: syntax error before '*' token
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winnt.h:98: error: syntax error before '*' token
  [23:03:00] 2  >> In file included from Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h:50,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWin.h:38,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinInt.h:28,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSendCom.h:19,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSend.c:17:
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winbase.h:1026: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winbase.h:1027: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winbase.h:1028: error: syntax error before "LPTSTR"
  [23:03:00] 2  >> In file included from ../../../sources/tk-8.6b1.2/win/tkWinSendCom.h:19,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSend.c:17:
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:190: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:191: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:193: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:194: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:195: warning: parameter names (without types) in function declaration
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:196: error: syntax error before "LPTSTR"
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c: In function `Win32ErrorObj':
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:836: error: syntax error before "lpBuffer"
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:842: error: `lpBuffer' undeclared (first use in this function)
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:842: error: (Each undeclared identifier is reported only once
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:842: error: for each function it appears in.)
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:845: error: `sBuffer' undeclared (first use in this function)
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:849: error: `p' undeclared (first use in this function)
  [23:03:01] 2  >> make: *** [tkWinSend.o] Error 1
  [23:03:01] 2 waitForExtCommand: Error: Command exited with code 2

  Removing the following line from tkWinSend.c:15 resolves the issue, but I am not sure if it also works for non-MinGW builds on win32:
    * RCS: @(#) $Id: tkWinSend.c,v 1.24 2010/04/08 14:06:20 nijtmans Exp $
    */
  -#include <tchar.h>
   #include "tkInt.h"
   #include "tkWinSendCom.h"


tkt_uuid: 220280ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: wish -use doesn't work when use target is the root window
comment:
  OriginalBugID: 4205 Bug
  Version: 8.0.5
  SubmitDate: '2000-02-22'
  LastModified: '2000-03-06'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: redhat linux 6.1
  ClosedDate: '2000-03-06'


  Name:
  John Heidemann

  ReproducibleScript:
  #!/usr/bin/wish
  # Should create a red square in the corner of of the root when invoked
  # with "wish -use 0x26 script"  (assuming 0x26 is the root window,
  # as determined with xwininfo).
  # Instead, just makes a new toplevel.
  frame .g
  .g config -width 50  -height 50 -bg red
  pack .g

  ObservedBehavior:
  The script should allow one to write to the root window, but it just makes a new toplevel.

  DesiredBehavior:
  The script should allow one to write to the root window, but it just makes a new toplevel.



  This is the correct behavior, as the root window is a special case
  and the window manager will handle it in its own way. 
  -- 03/06/2000 hobbs


tkt_uuid: 219949ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 1 Zero
foundin: final: 8.0.5
resolution: Duplicate
title: wm deiconify $win doesn't raise at the same time
comment:
  OriginalBugID: 1610 Bug
  Version: 8.0.5
  SubmitDate: '1999-03-23'
  LastModified: '1999-03-23'
  Severity: MED
  Status: Closed
  Submitter: welch
  ChangedBy: stanton
  RelatedBugIDs: 1609
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  ClosedDate: '1999-03-23'


  Name:

  Marco R. Gazzetta



  CVS:

  RCS: @(#) $Id: tkWinWm.c,v 1.7 1999/03/10 19:29:24 redman Exp $



  ReproducibleScript:

      wish80d.exe

      wm withdraw .

      [ now click on any window that was behind . ]

      wm deiconify .

      







  ObservedBehavior:

      the main window never appears

      







  DesiredBehavior:

      the main window shows up

      







  Patch:

  Index: tkWinWm.c

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

  RCS file: /cvsroot/tk/win/tkWinWm.c,v

  retrieving revision 1.7

  diff -c -r1.7 tkWinWm.c

  *** tkWinWm.c   1999/03/10 19:29:24     1.7

  --- tkWinWm.c   1999/03/23 18:17:15

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

  *** 1348,1353 ****

  --- 1348,1358 ----

                        ": it is an embedded window", (char *) NULL);

                return TCL_ERROR;

            }

  +         /* Annoying bug on windows: whenever a window is iconified, it

  +          * is put at the end of the Z-order. If we don't restack here,

  +          * deiconified windows stay always in the background (marcog)

  +          */

  +         Tk_RestackWindow(tkwin,Above,NULL);

          TkpWmSetState(winPtr, NormalState);

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

              && (length >= 2)) {







  PatchFiles:

      tkWinWm.c

      









      the standard behavior on UNIX is that wm deiconify not only RAISES the
      window, it additionally focuses it. I left that out in the patch to have
      minimal impact, but it might be considered. As soon as this patch is in
      and if the UNIX behavior  is considered a model, the focus change could
      be added as well.
      
      This second consideration seemed less important to me. The problem was
      that the window, since not showing up, was never percieved as existing,
      which meant quite a debugging effort.
      


tkt_uuid: 220353ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Tk on Windows handles destroying menus poorly
comment:
  OriginalBugID: 591 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-03'
  Severity: SER
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: 8.0.3
  ClosedDate: '1998-08-03'


  In Tk8.0p2 on Windows, destroying a menu does not free some

  information, causing a memory leak.  It can also leave modalMenuPtr

  set to a bad value.



  Here is a simple patch to fix these problems.



  Ian Taylor

  ian@cygnus.com



  *** /5g/ian/tk8.0p2/win/tkWinMenu.c     Wed Oct 29 16:09:10 1997

  --- tkWinMenu.c Wed Apr 15 13:52:59 1998

  *************** TkpDestroyMenu(menuPtr)

  *** 343,351 ****

  --- 343,363 ----

                  }

              }

          } else {

  +           Tcl_HashEntry *hashEntryPtr;

  + 

  +           /* Remove the menu entry from the hash table.  */

  +           hashEntryPtr = Tcl_FindHashEntry(&winMenuTable,

  +                               (char *) winMenuHdl);

  +           if (hashEntryPtr != NULL) {

  +               Tcl_DeleteHashEntry(hashEntryPtr);

  +           }

              DestroyMenu(winMenuHdl);

          }

          menuPtr->platformData = NULL;

  +     }

  + 

  +     if (menuPtr == modalMenuPtr) {

  +       modalMenuPtr = NULL;

        }

    }

    





  Applied patch 8/3/98 (SS).


tkt_uuid: 1723362fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 8
foundin: obsolete: 8.4.14
resolution: Accepted
title: tkWinDraw transparent bitmap problem and fix
comment:
  XCopyPlane in tk/win/tkWinDraw.c is used to draw
  bitmap images.  For some image types SetBkColor and
  SetTextColor are set.  For bitmap images with a
  transparent background (case 2 in the code), the
  SetBkColor and SetTextColor are not set.  But those
  settings can affect the output of transparent images,
  in ways that are not clearly documented in MSDN.

  The problem is not always seen.  It does not seem to
  affect tcl/tk core widgets which almost always draw
  via an off-screen pixmap.  But the tktable extension
  legitimately draws directly to the on-screen window
  for performance, and can get often get corrupted
  transparent bitmaps - it also seems to depends on the
  type of wish build, what has been drawn previously,
  the state of ms-windows, day of the week etc.

  The attached tktable-bitmap1.tcl script demonstrates
  the problem using tktable.  The second bitmap is
  supposed to be a red square with rounded corners, but
  on my system is displayed reversed.

  The fix is simply to reset BkColor and TextColor for
  transparent bitmaps, as shown in the following patch. 
  Note that the background/foreground settings are
  counter-intuitive.


  --- tkWinDraw.c Tue May 22 11:37:46 2007
  +++ tkWinDraw-update.c    Tue May 22 11:38:07 2007
  @@ -415,11 +415,14 @@
              /*
               * Case 2: transparent bitmaps are handled by setting the
               * destination to the foreground color whenever the source
  -            * pixel is set.
  +            * pixel is set.  We need to reset the BkColor and TextColor,
  +            * because they affect bitmap colour mapping.
               */
   
              fgBrush = CreateSolidBrush(gc->foreground);
              oldBrush = SelectObject(destDC, fgBrush);
  +           SetBkColor(destDC, RGB(255,255,255));
  +           SetTextColor(destDC, RGB(0,0,0));
              BitBlt(destDC, dest_x, dest_y, width, height, srcDC, src_x, src_y,
                      MASKPAT);
              SelectObject(destDC, oldBrush);



  I'll attach updated source files for the current CVS
  HEAD and core-8-4-15 branches.  I have been using the
  fix with tk8.14 for several weeks with no problems.


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: 2817382fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: rendering problem with ttk::notebook
comment:
  NOTE:
  This is bug item #2816331. I replicated this artifact because
  comments have been closed for  #2816331.

  IMPORTANT NOTE:
  Please try the following example with X11 windowing system.

  IMPORTANT NOTE:
  This rendering problem occurs as well without paned windows, e..g. if the
  frame containing a notebook is too small.

  IMPORTANT NOTE:
  Please be patient, it may take a while until you can see the error.
  I can see the error if the label is showing a value about 250.

  ==============================
  Bug item #2816331
  ==============================

  Please try the following code:
  ---------------------------------------------------------------------------
  --------------
  bind Panedwindow <B1-Motion> {+ .pw.f configure -text %y }
  set pw [panedwindow .pw -orient vertical -opaqueresize true -background
  darkgray]
  set fr [ttk::label $pw.f]
  set nb [ttk::notebook $pw.nb]
  $pw add $fr -sticky nsew -stretch never
  $pw add $nb -sticky nsew -stretch always
  $nb add [ttk::frame $nb.f -height 400 -width 400] -sticky nsew -text Test
  $nb add [ttk::frame $nb.g -height 400 -width 400] -sticky nsew -text Test
  pack $pw -fill both -expand yes
  ---------------------------------------------------------------------------
  --------------

  Now watch careful the notebook labels while moving the sash of the paned
  window.
  Sometimes the labels will be rendered normal, sometimes the relief is too
  small.

  I have a weak suspicion that the paned window has an error while
  calculating the
  geometry of the subwindows or while calculating its own geometry. There is
  a lack
  of two pixels somewhere.

  I have tested this on Linux (that means with x11 windowing system).

  NOTE: with ttk::panedwindow you will get the same result.


tkt_uuid: 220489ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: Chinese letters in a text widget become a mess when clicked
comment:
  OriginalBugID: 1774 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-09'
  LastModified: '1999-08-13'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  FixedDate: '1999-08-13'
  FixedInVersion: 8.1


  Name:
  Di Yu

  ReproducibleScript:
  "text .t1 -font ... 
      pack .t1"
      then input Chinese letters into the text under Windows 95 and a Chinese
      platform like Richwin for Internet. Then, click the mouse on the middle
      point of a Chinese letter.

  ObservedBehavior:
  Under Windows 95 and a Chinese platform, the text widget can display
      Chinese words, but when I click the mouse over the widget or move the
      insertion mark by direction keys in the widget, then the text becomes a
      mess. Entry widget doesn't have this problem, so I guess there is
      something wrong with the text widget.

  DesiredBehavior:
  The letters inside text widget should not be influenced by the moving of
      the insertion mark whether by keyboard or by mouse-clicking, no matter
      the letters are English or Chinese. As entry widget can do this, I think
      text widget should also be able to do this.



  This was fixed with internationalization work done in 8.1. 
  -- 08/13/1999 hobbs


tkt_uuid: 437282ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Invalid
title: Windows button -highlight* broken
comment:
  OK, if it's not actually broken, the behavior inconsistent, and the fix is not readily apparent from the documenation, and the fix might cause portability problems (different behavior on different platforms.


  Run the following code snippit in wish 8.3.3 on Linux.

      toplevel .t
      button .t.b -text "Foo" -command {puts stdout "Foo!"} -highlightthickness 2 -highlightcolor red -highlightbackground red -borderwidth 0
      pack .t.b

  And you should see a flat button with a 2bit red box around it.


  However, under Windows, the same code snippet results in no visible border (although the widget >is< sized correctly to accomodate the border).  However, if you then type

      .t.b configure -default active

  The missing border is displayed correctly (correct == in the manner displayed under Unix, which is what is described in the documentation, and is what I expect it to be doing).

  The culprit code appears to be in tk/win/winButton.c, around line 399.  At this point, highlightthickness is overridden and forced to zero if the "-default" option is not "active".  A brief perusal of tk/unix/unixButton.c does not turn up a similar value stomp; however, I didn't do a detailed walkthru so it may have eluded me.


  Something that just occurred to me is that the default setting for "-default" may be different between the two platforms.  I haven't checked that.

  I haven't checked Mac behavior, either.


tkt_uuid: 3574945fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: None
resolution: None
title: Scrolling up with elided text doesn't play nice
comment:
  Create a basic text widget with some elided text, for example:

  pack [text .t -yscroll ".s set"] [scrollbar .s -command ".t yview"] -side left -fill y
  .t tag config hide -elide 1
  foreach x [list 0 1 2 3 4 5 6 7 8 9 0] {
    .t insert end "foo\nfoo\nfoo\nfoo\nfoo\nfoo\n"
    .t insert end "bar\nbar\nbar\nbar\nbar\nbar\n" hide
  }


  Then scroll the text a line at a time, either by clicking in the text widget and using the up/down arrow keys, or with

  .t yview scroll 1 unit
  .t yview scroll -1 unit

  The text scrolls down without any problem, but when scrolling up again, it pauses whenever it gets to an ellided line, causing the scroll action to have no visible effect. (tested on 8.5.9 and 8.6b1 on Windows XP and Win 7)


tkt_uuid: 220039ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Duplicate
title: Increasing times for function call 'update'
comment:
  OriginalBugID: 3410 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-01-25'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3220
  OS: Linux-SuSE
  ClosedDate: '2000-01-25'


  Name:
  Monika Holzammer

  CVS:
  27-Oct-1999

  ReproducibleScript:
  The following script can show you the increasing update times - you
      should call it from a terminal window to see the time measurement
      lines:

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

      #
      -----------------------------------------------------------------------
      proc showWin {} {
          wm title . UPDATE-TEST

          set ftop [frame .ftop]
          pack $ftop -side top -expand yes
            set b_refresh [button $ftop.refresh -text "Refresh"  -command [list doRefresh .fbott]]
            set b_dlg [button $ftop.bdlg -text "Dialog" -command Show_Dialog]
            pack $b_refresh $b_dlg -padx 20 -pady 10

          set fbott [frame .fbott -width 300 -height 200]
          pack $fbott -side top -expand yes

          addFrames $fbott
      }

      #
      -----------------------------------------------------------------------
      proc addFrames {f} {
      global counter color

        # Add some element frames
        for {set i 0} {$i < 5} {incr i} {
          set fg [frame $f.fg$i -relief solid -bd 2]

          for {set j 0} {$j < 3} {incr j} {
            set fp [frame $fg.fp$j]
              set lab  [label $fp.lab -text "Name:" -anchor w]
              set ent  [entry $fp.ent -width 20]
              set butt [button $fp.butt -relief raised -bd 2 -text "?"]
              pack $lab $ent $butt -side left
            pack $fp -side top -padx 2 -pady 2
          }
          pack $fg -side top -padx 5 -pady 3
        }
      }

      #
      -----------------------------------------------------------------------
      proc doRefresh {f} {

        # Destroy all element frames
        foreach groupFrame [winfo children $f] {
          foreach paraFrame [winfo children $groupFrame] {
            foreach elem [winfo children $paraFrame] {
              destroy $elem
            }
            destroy $paraFrame
          }
          destroy $groupFrame
        }

        # Add the frames again
        addFrames $f
      }

      #
      -----------------------------------------------------------------------
      proc Show_Dialog {} {
      global dialogClosed

        set oldfocus [focus]

        set w .myDialog 
        toplevel $w
        wm title    $w Test-Dialog
        wm transient $w $oldfocus

        # Label
        set lab [label $w.lab -text "Hallo"]
        pack $lab -side top -padx 30 -pady 20

        # Button Area
        set buttArea [frame $w.barea]
        pack $buttArea -side bottom -fill x -padx 5 -pady 15
        set b_close [button $buttArea.close -text Close  -command [list set dialogClosed 1] ]
        pack $b_close -side left -expand yes -padx 10

        # Check update time
        set t0 [clock clicks]
        update idletasks
        puts "Dlg: [expr [clock clicks] - $t0]"

        # Wait on closing dialog
        set dialogClosed 0
        bind $w <Destroy> [list set dialogClosed 1]
        tkwait variable dialogClosed

        catch {destroy $w}
      }

      ##########################
      ####### MAIN #############
      ##########################
      showWin

  ObservedBehavior:
  Handle the little test application in the following way:
      - Click button 'Dialog' to call a little dialog widget - the time used
      for 'update idletasks' call will be outputted - close it
      - Now click on button `Refresh' - all elements in the lower part of the
      widget will be destroyed and then created again.
      - Click button 'Dialog' again - close it
      - Click button 'Refresh'
      - and so on ...

      You will see that the time needed for 'update idletasks' is growing

      In our real application many little widgets (labels, entry fields and
      buttons) are dynamically build up and destroyed again. The upper
      described behaviour results in our application became slower and slower.
      Finally only restart the application can be done.

  DesiredBehavior:
  We expect that dynamically creating and destroying widgets is possible
      without getting a slow application.


tkt_uuid: 1305708fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Spelling mistake in el.msg
comment:
  There is a spelling mistake in the greek translation of
  "Skip messages" in tktoolkit/tk/library/msgs/el.msg

  The entry should read:

      ::msgcat::mcset el "Skip Messages"     
  "\u0391\u03c0\u03bf\u03c6\u03c5\u03b3\u03ae
  \u03bc\u03b7\u03bd\u03c5\u03bc\u03ac\u03c4\u03c9\u03bd"

  A corrected el.msg is attached.


tkt_uuid: 220367ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: positionning tk_ dialog boxes
comment:
  OriginalBugID: 631 Bug
  Version: 8.0
  SubmitDate: '1998-05-25'
  LastModified: '1999-11-12'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-11-12'
  FixedInVersion: 8.3b1


  The option -parent associated with the standard dialogs
  (tk_messageBox, tk_getOpenFile ...) doesn't influence
  the positionning on Unix (solaris).
  The dialog box is always displayed in the middle
  of the virtual X window (a large one) in which our application 
  is running and not in the middle of the parent window (the application)
  while the option parent is specified as follows : "-parent ."

  thanks in advance for a solution

  Jean-Marie Condom

  |---------------------------------------------- 
  | Equipe Informatique Appliquee  
  | Universite de Pau et des Pays de l'Adour         
  | Avenue de l'universite        
  | 64000 Pau             
  | FRANCE
  | Email : condom@univ-pau.fr

  All fixed for 8.3b1. 
  -- 11/12/1999 hobbs


tkt_uuid: 1026485fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: search return index is less than the start
comment:
  Parts of this are taken from tklib bug 984407 by Niel
  Madden:

  This bug doesn't occur with 8.4.6 in unix, but does
  occur with 8.5 and the HEAD as of Sep 11, 2004.  It can
  result in an endless loop with applications that expect
  the result to be >= the start index.

  Using the ctext.tcl (a text megawidget) in the HEAD of
  tklib:

  source ctext.tcl
  pack [ctext .t]
  ctext::addHighlightClassForRegexp .t comment navy
  {#[^\n]*\n}

  Then if I add the following to the text widget:

  This is a test
  # This is a test
  foo

  Then position the cursor somewhere in the comment, and
  press
  backspace - endless loop occurs in ctext::highlight -
  the third while
  1 loop. Problem seems to be that the [$win search..]
  stuff is
  passed indices like 4.0 3.15 (i.e. start is after end),
  and it return
  3.0 bizarrely (this may be a bug in the text widget, or
  possibly in
  the Mac OS X implementation - I haven't followed up
  yet). The fix
  was to add these lines after the {"" == $res} check:

  # If result given is less than the start index (can
  happen), then
  # break out
  foreach {l1 c1} [split $res .] {l2 c2} [split $si .] {
  break }
  if {$l1 < $l2 || ($l1 == $l2 && $c1 < $c2)} { break }


tkt_uuid: 571937ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: TIP #94: listbox -activestyle patch
comment:
  This is the implementation of -activestyle (TIP #94) for 
  the listbox.  This includes extra comments that may be 
  stripped out, but are left in for posterity here.


tkt_uuid: 1824521fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 9 Immediate
foundin: obsolete: 8.5b2
resolution: Fixed
title: Using -bitmap crashes TkpDisplayMenuButton
comment:
  Exception:  EXC_BAD_ACCESS (0x0001)
  Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000050

  Thread 0 Crashed:
  0   libtk8.5.dylib      0x0b0b5a20 XCopyPlane + 96
  1   libtk8.5.dylib      0x0b0c25ac TkpDisplayMenuButton + 2466
  2   libtcl8.5.dylib     0x0a08f4a7 TclServiceIdle + 65
  3   libtcl8.5.dylib     0x0a0751f8 Tcl_DoOneEvent + 380
  4   libtk8.5.dylib      0x0b0c7ab8 TkMacOSXProcessWindowEvent + 746
  5   libtk8.5.dylib      0x0b0b84b6 TkMacOSXProcessEvent + 107
  6   libtk8.5.dylib      0x0b0cf9aa CarbonEventHandlerProc + 95
  7   com.apple.HIToolbox 0x92dec537 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093
  8   com.apple.HIToolbox 0x92debbdc SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304
  9   com.apple.HIToolbox 0x92debaa1 SendEventToEventTargetWithOptions + 55
  10  com.apple.HIToolbox 0x92df3123 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 357
  11  com.apple.HIToolbox 0x92dec8ee DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 2044
  12  com.apple.HIToolbox 0x92debbdc SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304
  13  com.apple.HIToolbox 0x92df2fbc SendEventToEventTarget + 56
  14  libtk8.5.dylib      0x0b0cfea7 TkMacOSXReceiveAndDispatchEvent + 136
  15  libtk8.5.dylib      0x0b0c3ea4 CarbonEventsCheckProc + 49
  16  libtcl8.5.dylib     0x0a0751da Tcl_DoOneEvent + 350
  17  libtk8.5.dylib      0x0b011fdb Tk_MainLoop + 36
  18  libtk8.5.dylib      0x0b01f184 Tk_MainEx + 1995
  19  wish                0x00002e97 main + 41
  20  wish                0x00002e52 _start + 216
  21  wish                0x00002d79 start + 41


tkt_uuid: 827535ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 9 Immediate
foundin: obsolete: 8.4.4
resolution: Fixed
title: tk_dialog can prevent user interaction
comment:
  On Windows XP, the following simple script:

  tk_dialog .dial0 "test" [string repeat "hello there\n"
  500] {} ok cancel

  makes the dialog appear offscreen (at '901 -4946'). 
  Given that none of the dialog is visible to the user at
  all, the effect is a total application hang!

  The problem appears to be caused here (in dialog.tcl):

      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

  For whatever reason 'winfo reqheight $w' is returning a
  vast number like 11092 (which may well be correct
  here).  This number is then used to position the
  dialog, but then the actual height of the dialog when
  it appears is different (much smaller) and so when the
  dialog appears it is totally offscreen (and then the
  grab completes the lock-up). 

  The root of the bug appears to be elsewhere.  I suggest
  that at least for Tk 8.4.5 a test is put in dialog.tcl
  so that huge dialogs don't go offscreen.  Perhaps
  something as simple as

  if {$y < 0 && [winfo reqheight $w] > [winfo
  screenheight $w]} { set y 0 }


tkt_uuid: 220805ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 8
foundin: obsolete: 8.1b3
resolution: Out of Date
title: Docs missing for Tk_MacSetEmbedHandler API
comment:
  OriginalBugID: 1873 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-22'
  Severity: MED
  Status: Assigned
  Submitter: surles
  ChangedBy: hershey
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


tkt_uuid: 493145ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Fixed
title: Scale binding on Windows
comment:
  The scale bindings work well with three button mice, 
  allowing the middle button to jump to specific 
  locations on the scale. However on windows, must users 
  have two button mice with the "second" button being 
  called button 3. The patch below to the scale widget 
  binds the normal button 2 bindings to button 3. Note, 
  this could also be done with virtual events so the 
  below code is more of an example. Also, on the Mac, 
  only one button is used which makes things even more 
  difficult.

  Tom Wilkason

  cvs -z3 diff -w scale.tcl (in directory 
  D:\CVS\sourceforge\tk\library\)
  Index: scale.tcl
  =======================================================
  ============
  RCS file: /cvsroot/tktoolkit/tk/library/scale.tcl,v
  retrieving revision 1.8
  diff -w -r1.8 scale.tcl
  51a52,68
  > switch -- $tcl_platform(platform) {
  >    "windows" {
  >       bind Scale <3> {
  >           tk::ScaleButton2Down %W %x %y
  >       }
  >       bind Scale <B3-Motion> {
  >           tk::ScaleDrag %W %x %y
  >       }
  >       bind Scale <B3-Leave> { }
  >       bind Scale <B3-Enter> { }
  >       bind Scale <ButtonRelease-3> {
  >           tk::CancelRepeat
  >           tk::ScaleEndDrag %W
  >           tk::ScaleActivate %W %x %y
  >       }
  >    }
  >    default {
  64a82,83
  >    }
  > }

  *****CVS exited normally with code 1*****


tkt_uuid: 1623257fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 7 High
foundin: obsolete: 8.4.14
resolution: Duplicate
title: selecting file from file dialog shuts down application
comment:
  In windows XP, selecting a file on the Desktop using a tk file dialog will shut down the application. I found this bug using Python and the tkinter module but can reproduce this using wish.exe.

  to repeat:
  1) start DOS console and cd to C:\Tcl\demos\Tk8.4
  2) at prompt enter: wish widget.tcl  - the Widget Demonstration Window opens
  3) scroll to Common Dialogs and select 2. File selection dialog
  4) click Browse button in file selection dialog
  5) click Desktop button on left hand side of dialog
  6) double click any .txt file - the file path is entered in entry field
  7) step 4 and 5 is repeated so, click browse button again
  8) click Desktop button again
  9) just move cursor over a .txt file 

  The dialog and whole application shuts down.  Note: I could not reproduce this on Win 2000.


tkt_uuid: 1375436fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Fixed
title: compilation error in dec 5 cvs head snapshot
comment:
  I downloaded the tk-20051205.tar.gz file from the
  activestate snapshot tar file repository. I
  configured it on a SPARC Solaris 8 system (Sun's C
  compiler) with the flags:

  --prefix=/volws/lwv27/ldatae --enable-threads
  --enable-shared --enable-symbols -enable-langinfo

  The compilation step failed at this point:

  cc -c -g   -KPIC -I/vol/tclsrcsol/tcl85/tk/unix/../unix
  -I/vol/tclsrcsol/tcl85/t
  k/unix/../generic
  -I/vol/tclsrcsol/tcl85/tk/unix/../bitmaps
  -I/vol/tclsrcsol/tcl
  85/tcl/generic -I/vol/tclsrcsol/tcl85/tcl/unix
  -I/usr/openwin/include -DPACKAGE_
  NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\"
  -DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=
  \"tk\ 8.5\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1
  -DHAVE_SYS_TYPES_H=1 -DHAV
  E_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
  -DHAVE_MEMORY_H=1 -DHAVE_STRI
  NGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1
  -DHAVE_LIMITS_H=1 -DTCL_THREADS=1 
  -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1
  -D_POSIX_PTHREAD_SEMANTICS=1 -D_THREAD_SAFE=
  1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -D_REENTRANT=1
  -D_POSIX_PTHREAD_SEMANTICS=1
   -DTCL_SHLIB_EXT=\".so\" -DTCL_CFG_DEBUG=1
  -DTCL_WIDE_INT_TYPE=long\ long -DHAVE
  _STRUCT_DIRENT64=1 -DHAVE_STRUCT_STAT64=1
  -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1 -DHAV
  E_TYPE_OFF64_T=1 -DWORDS_BIGENDIAN=1
  -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 
  -Dstrtod=fixstrtod -DHAVE_PW_GECOS=1 -DHAVE_XSS=1     
  -DTCL_NO_DEPRECATED  -DUS
  E_TCL_STUBS 
  /vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixEvent.c
  "/vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixEvent.c",
  line 653: invalid type combination
  cc: acomp failed for
  /vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixEvent.c
  gmake: *** [tkUnixEvent.o] Error 2

  This line reads:

  const char const *scim = "@im=SCIM";

  If I place this line into a file by itself, with no
  include files, etc. and attempt to compile it, I get:
  $ cc /tmp/a.c -o /tmp/a.out
  "/tmp/a.c", line 4: invalid type combination
  cc: acomp failed for /tmp/a.c
  srv06 (534) $ cat /tmp/a.c

  int main(int argv, char **argc)
  {
          const char const *scim = "@im=SCIM";
  }


  Perhaps this is a GNU C construct?


tkt_uuid: 1096580fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: None
title: soft-hyphen in text widget
comment:
  Soft-hyphens '\u00AD' are not properly handled in text
  widgets.
  They are always shown as '-' (hyphen) but a soft-hyphen
  should only appear if it is the last character in a line.

  I.E
  "abc\u00AD123"  should be displayed as

  abc123

  or

  abc-
  123

  but is always displayed as
  abc-123

  Tested on win/linux
  8.4.6 / 8.4.7 / 8.5a2


tkt_uuid: 220330ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: Stack trace in Job Action gui - from spinbox
comment:
  OriginalBugID: 4900 Bug
  Version: 2.0b4
  SubmitDate: '2000-04-06'
  LastModified: '2000-04-13'
  Severity: LOW
  Status: Released
  Submitter: shawn
  ChangedBy: shawn
  OS: Windows NT
  FixedDate: '2000-04-06'
  FixedInVersion: 2.0b5


  To reproduce - 

  Open a new project and schedule a job in the project enable action - and the error could appear.  I must have been pushing the start hour button.   

  can't read "tkPriv(relief)": no such element in array
      while executing
  "$w configure -$tkPriv(element)relief $tkPriv(relief)"
      (procedure "::tk::spinbox::ButtonUp" line 9)
      invoked from within
  "::tk::spinbox::ButtonUp .mdi1.leftRight.f1.frame.frame.apptFrm.f.timeFrm.starthour 22 13
  "
      (command bound to event)

  I have tried to reproduce this and haven't been able to - this is a new install and was run locally - by a new user - and the error appeared the first time the job action was opened, but wouldn't reappear after that.  

  I tried to reproduce it on a completely clean environment and wasn't able to .  

  Shawn



  Could this be a problem with the our build?

  I don't think this should happen normally.

  Jeff, any ideas on why this fails? 
  -- 04/06/2000 kuchler
  Fixed in CVS 6 Apr 2000.  The problem was the same as applied
  to the button previously - the Windows native dialogs go away
  on the buttonpress, leaving a stray buttonrelease to be interp'd
  by Tk. 
  -- 04/06/2000 hobbs

  Integrated in Qa build 2011 2.0 b5 
   
  -- 04/13/2000 shawn


tkt_uuid: 3609608fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: None
title: Windows Text hi-lights disappear when text loses focus
comment:
  On Windows the text widget hi-lights will disappear when text widget loses focus.  Linux and Mac OS X Tk behaves appropriately.  This bug is generated from a number of bugs for IDLE (Python's IDE) here http://bugs.python.org/issue14146.  On Windows the IDLE debugger no longer hi-lights the current line in the editor.  On Windows the find/replace functions are not functioning properly because found text is not hi-lighted.  The issue was tested using Tk 8.5.13 and Tk 8.6 both exhibit the same problem.  We created a small test program to reproduce this bug with Python 3.x and tkinter:

  from tkinter import *

  main = Tk()
  text = Text(main, width=40, height=10, wrap="char")
  text.pack()
  text.insert(INSERT, "".join(map(str, range(100))))
  text.tag_add(SEL, "1.0", "end")
  text.focus_set()

  def jump():
      text.after(500, btn.focus_set)
      text.after(1000, text.focus_set)

  btn = Button(main, text="Click me", command=jump)
  btn.pack()
  main.mainloop()

  Thanks for your help!


tkt_uuid: 517935ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: Setting scrollbar width fails
comment:
  Usng the native aqua-tk look.

  scrollbar .s -orient horiz
  button .b -text button
  pack .s .b -fill both -expand 1

  So the scrollbar has been given the same screen 
  area as the button.

  Now try resizing. The scrollbar refuses to change 
  width, which is perhaps a correct part of the Aqua-
  Tk interface.

  However it doesn't clear the screen space it 
  occupies either.

  Given that it's probably impossible to change the 
  scrollbar dimensions, I'd suggest that instead the 
  scrollbar is simply positioned as it is now, but the 
  additional screen space allocated to it is cleared.


tkt_uuid: 3556238fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: None
title: Documentation of tk_getOpenFile wrong
comment:
  The doucmentation for tk_getOpenFile states:
      -initialfile filename
          Specifies a filename to be displayed in the dialog when it pops up. This option is ignored on the Macintosh platform.

  Tk bug #829003 clearly states this option is not ignored, in fact the tk_getOpenFile call fails if the file does not exists.


tkt_uuid: 1667206fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: tkTextBtree fails to compile
comment:
  I grabbed the tk-20070222.tar.gz file from the activestate tcl ftp area.
  I configured it with options \"'--prefix=/projects/sprs_lwv/tcl85' '--enable-shared' '--enable-symbols' '--enable-stubs' '--enable-64bit' 'CC=cc'\"



  and when I ran the compile, I get this error:
  cc -c -g  -xarch=v9   -KPIC -I/vol/tclsrcsol/tcl85/tk/unix/../unix -I/vol/tclsrc
  sol/tcl85/tk/unix/../generic -I/vol/tclsrcsol/tcl85/tk/unix/../bitmaps -I/vol/tc
  lsrcsol/tcl85/tcl/generic -I/vol/tclsrcsol/tcl85/tcl/unix -I/usr/openwin/include
   -DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\" -DPACKAGE_VERSION=\"8.5\" -DPACK
  AGE_STRING=\"tk\ 8.5\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPE
  S_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
  -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DUSE
  _THREAD_ALLOC=1 -D_REENTRANT=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_THREAD_SAFE=1 -DH
  AVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DTCL_THREADS=1 -D_REENTRANT=1 -D_POSIX_PTHREAD_
  SEMANTICS=1 -DTCL_CFG_DO64BIT=1 -DTCL_SHLIB_EXT=\".so\" -DTCL_CFG_DEBUG=1 -DTCL_
  WIDE_INT_IS_LONG=1 -DWORDS_BIGENDIAN=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=
  1 -DHAVE_PW_GECOS=1 -DHAVE_XSS=1      -DTCL_NO_DEPRECATED  -DUSE_TCL_STUBS  /vol
  /tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c
  "/vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c", line 1816: syntax error
   before or at: register
  "/vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c", line 1816: warning: und
  efined or missing type for: register
  "/vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c", line 1818: warning: par
  ameter mismatch: 2 declared, 0 defined
  "/vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c", line 1823: undefined sy
  mbol: linePtr
  "/vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c", line 1823: warning: imp
  roper pointer/integer combination: op "=="
  "/vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c", line 1831: non-unique m
  ember requires struct/union pointer: parentPtr
  "/vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c", line 1831: left operand
   of "->" must be pointer to struct/union
  "/vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c", line 1832: warning: imp
  roper pointer/integer combination: op "!="
  "/vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c", line 1833: warning: imp
  roper pointer/integer combination: op "=="
  "/vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c", line 1848: non-unique m
  ember requires struct/union pointer: parentPtr
  "/vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c", line 1848: left operand
   of "->" must be pointer to struct/union
  cc: acomp failed for /vol/tclsrcsol/tcl85/tk/unix/../generic/tkTextBTree.c
  gmake: *** [tkTextBTree.o] Error 2


tkt_uuid: 498684ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Fixes jumpy multi-widget scrolling
comment:
  A Listbox, Textbox, and Entry packed in the same frame 
  and bound to the same horizontal scrollbar will scroll 
  differently (even when they include the same text) due 
  to a rounding error.

  See bug 225025 for details (and a demonstration 
  script).


tkt_uuid: 219842ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: can't fill canvas object with a stipple
comment:
  OriginalBugID: 555 Bug
  Version: 8.0p2
  SubmitDate: '1998-03-31'
  LastModified: '1999-08-14'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  RelatedBugIDs: 1274 1379
  OS: Macintosh
  OSVersion: 8.1
  Machine: NA
  FixedDate: '2000-10-30'
  FixedInVersion: NA
  ClosedDate: '1999-08-14'


  From: "David A. Smith" <dasmith@perseus.tufts.edu>
  Newsgroups: comp.lang.tcl
  Subject: BUG: Stipple on the Mac
  Date: Thu, 26 Mar 1998 12:36:06 -0500

  I seem to remember that it's a known bug that the Mac can't fill canvas
  objects with a stipple. Any idea if and when this will be fixed. Using
  Tk8.0p2 on MacOS 8.1, the following will reproduce the bug:

  canvas .c
  pack .c
  set id [.c create rectangle 100 100 200 200 -fill red]
  .c itemconfigure $id -stipple gray 50

  The rectangle remains a solid red.

  Stippling is known to not work on Mac/Windows. 
  -- 08/06/1999 hobbs


tkt_uuid: 219993ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Widgets
priority: 1 Zero
foundin: None
resolution: Duplicate
title: No "hint"-option available for Tk-buttons
comment:
  OriginalBugID: 2212 RFE
  Version: 8.1
  SubmitDate: '1999-06-15'
  LastModified: '1999-08-06'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 549
  OS: Windows 98
  Machine: X86
  ClosedDate: '1999-08-06'


  Name:
  Toni Rath

  DesiredBehavior:
  I need those "hints" just like in Windows or KDE (those little windows
      that
      pop up, when you stay over a button for a second or more). If you only
      have
      little drawings in the button, the user might not understand the
      function of
      this button and with the hints one could get a little help text.


tkt_uuid: 557083ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Adding Tk_PhotoBlendBlock()
comment:
  Tk_PhotoPutBlock() blends the source block with the
  image, which prevent extension writer to set alpha
  value in the image.

  So it would be good to add Tk_PhotoBlendBlock() (and
  Tk_PhotoBlendZoomedBlock()) and make Tk_PhotoPutBlock()
  doing a solid copy of the source block.
  Also, [$image copy] and [$image put] can take an
  additionnal
  option, -blend /boolean/, to switch on
  Tk_PhotoPutBlock() or
  Tk_PhotoBlendBlock().


tkt_uuid: 220433ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Tcl unloads library (package) before all events have been handled.
comment:
  OriginalBugID: 1273 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-23'
  LastModified: '1999-03-30'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  RelatedBugIDs: 989  1573  1593
  OS: Windows NT
  Machine: X86
  FixedDate: '1999-03-30'
  FixedInVersion: 8.1b3


  Name:
  George A. Howlett

  Extensions:
  BLT

  ReproducibleScript:
  Under Windows, dynamically load a package that calls
  Tk_CreateEventHandler 
  using a callback routine within its package.  Then exit Tcl.  Tcl will
  first
  unload the library and then handle pending Tk events.  This causes a
  fault
  Tcl attempts to execute a handlerPtr->proc that no longer is loaded.




  ObservedBehavior:
  Coredump. In Tk_HandleEvent where invoking winPtr->handlerPtr->proc.

  Note that this routine is successfully called many times earlier (before
  the library has been unloaded).





  DesiredBehavior:
  No fault.






  Any dynamically loaded package calling Tk_CreateEventHandler will fail in this way.
  ---
  Related to 989, 1573, 1593

  Unloading of libraries is deferred until all exit handlers have been invoked.
  03/30/1999 14:26 - stanton -


tkt_uuid: 2891541fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: Fixed
title: Grab on . prevents minimizing app on Windows.
comment:
  For bug #1847002 we added some restrictions for system commands when a grab is present. One of the changes was to prevent grabbed toplevels from being minimized as this can confuse users if the only active window in a Tk app disappears.
  Unfortunately it seems that some applications manage to leave a grab on the main window. This now prevents the application from being minimized although everything else is normal.
  Therefore the previous modification -- deny minimize when a grab is present -- must be changed to deny minimize when a grab is present except when the grab is on the mainwindow (.) and . is the window to be minimized. (This comes out shorter in code).
  The application presenting this problem is 'git gui' and their bug is http://code.google.com/p/msysgit/issues/detail?id=301


tkt_uuid: 219939ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: Toplevels not resizing when widgets destroyed
comment:
  OriginalBugID: 1450 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-04'
  LastModified: '1999-08-07'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2308
  OS: AIX
  OSVersion: 4.3
  Machine: RS6000
  ClosedDate: '1999-08-07'


  Name:
  Anthony Johnson
  email:  caldiver@pacbell.net

  ReproducibleScript:
  toplevel .test
  button .test.but1 -text "show button" -command "button .test.but2  -text {destroy me} -command {destroy .test.but2; pack .test.but2}"

  -> Try pressing the "destroy" button after resizing the toplevel.
  -> Try adding "wm resizable .test 0 0"

  ObservedBehavior:
  Catch-22: I want to destroy a widget from a toplevel window and have the toplevel shrink accordingly:
    - If the user changes the window size using the resize bars from the
      window manager, the toplevel will no longer shrink when widgets destroyed.
    - If I use "wm resizable .win 0 0" so the user can't resize the window, the
      toplevel will also not shrink when widgets destroyed.
  Essencially, to have this function, I must allow the user to resize the window, but if they do so, the program no longer works as expected.

  DesiredBehavior:
  I need to EITHER:
    1. disable the resizing of the window by the user and still have the
       window adjust its size to fit new/destroyed widgets. OR
    2. allow the user to resize the window and STILL automatically re-adjust the
       window to fit new/destroyed widgets.


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: 220204ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Stippled lines crash NMGC display driver
comment:
  OriginalBugID: 2299 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-28'
  LastModified: '1999-09-16'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: 4.00.951
  Machine: X86
  ClosedDate: '1999-09-16'


  Name:
  John Nakulski

  Comments:
  I will submit this same bug report to Neomagic corporation.

  ReproducibleScript:
  Run wish (under Windows 95), then source the following program:
      # Program to demonstrate Tk "stippled lines crash NMGC display driver"
      bug
      #
      # The bug appears when you use ALL of the following together:
      # * many stippled lines in one canvas (10 to 100);
      # * using "update idletasks" often, in between drawing the lines;
      # * setting the Display control panel to the following mode
      #   (so far, only tried on a HP Omnibook 3000 laptop with Win95):
      #   * either 16-bit (16M colors) or 8-bit (256 colors) display mode;
      #   * full (3/3) or partial (2/3) hardware acceleration (Neomagic
      MagicGraph-128XD display driver)
      #
      set w 800
      set h 500
      set stipples {gray12 gray25 gray50 gray75}
      set stipCount [llength $stipples]
      canvas .c -width $w -height $h -bg white
      pack .c
      for {set i 0} {$i < 100} {incr i} {
        set x1 [expr {int(rand() * $w)}]
        set x2 [expr {int(rand() * $w)}]
        set y1 [expr {int(rand() * $h)}]
        set y2 [expr {int(rand() * $h)}]
        set stip [lindex $stipples [expr {int(rand() * $stipCount)}]]
        puts ".c create line $x1 $y1 $x2 $y2 -stipple $stip"
        flush stdout
        .c create line $x1 $y1 $x2 $y2 -stipple $stip
        update idletasks
      }

  ObservedBehavior:
  After several (10-50) lines have been drawn correctly, strange
      "artefacts" begin to appear on the PC screen (initially just on the Tk
      window, then everywhere). These "artefacts" are small rectangles
      containing random pixels... as if some process was writing incorrectly
      to display memory.
      Within a few seconds, everything comes to a halt, and NMGC.DRV crashes
      fatally.
      NMGC.DRV is the Neomagic MagicGraph-128XD hardware-accelerated display
      driver used in the HP Omnibook 3000 and many other laptop PCs.
      (NMGC.DRV version 4.03.00.4607-Q package 6.07 Aug 15 1997)
      Usually, the crash brings down the whole PC, and I need to reboot.
      The bug could be in the display driver.
      My work-around is to set the hardware acceleration level to 1/3 or OFF
      (using the Win95 Display control panel).

  DesiredBehavior:
  Display driver should not crash



  This appears to be a bug in the other product (the display driver).
  When the driver settings can avert this, they are doing some (bad)
  level of optimization.  This error is otherwise unknown to us. 
  -- 09/16/1999 hobbs


tkt_uuid: 1799963fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5a7
resolution: Invalid
title: Document keynav package
comment:
  Context: http://groups.google.com/group/comp.lang.tcl/msg/d8be991b44b2f1c0

  Joe says that the keynav package is undocumented but supported. That situation means that documentation should be written. :-)


tkt_uuid: 1098625fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 7 High
foundin: obsolete: 8.5a2
resolution: Fixed
title: wrong toplevel geometry when created with a menu
comment:
  Run the following script:

  menu .m
  menu .m.file
  .m add cascade -label File -menu .m.file
  .m.file add command -label Print -comm "puts print"
  toplevel .s -menu .m -width 230 -height 200

  the result is a toplevel window with a height of 1 and a 
  width of 118


tkt_uuid: 597404ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 9 Immediate
foundin: obsolete: 8.4b2
resolution: Works For Me
title: misnamed distribution directory
comment:
  The source distribution tarball unpacks
  into a directory named "tk".  Following
  tradition, the directory should be named
  "tk8.4b2".

  We should note what went wrong and
  avoid a repeat of the problem for the
  Tk 8.4.0 release.

  I would think a `make dist` would do
  the right thing?


tkt_uuid: 862787ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: tcl script that writes to stdout and is called from wish thr
comment:
  A tcl script that writes to stdout and is called from wish 
  through exec does not return but just sits there and 
  consumes CPU cycles. This occurs when wish is started 
  by double clicking in the finder. The problem does not 
  occur when wish is started from the terminal like this:

  $ /Applications/Utilities/Wish 
  Shell.app/Contents/MacOS/Wish Shell

  To illustrate the problem, look at the following two little 
  scripts a.tcl and b.tcl:

  a.tcl:
  ---------------------------------
  #!/bin/sh
  # the next line restarts using tclsh \
  exec tclsh "$0" ${1+$@}

  if [catch {exec [file join [file dirname [info script]] 
  b.tcl]} error] {
   puts stderr $error
  }

  puts "end of a.tcl"
  ---------------------------------

  b.tcl:
  ---------------------------------
  #!/bin/sh
  # the next line restarts using tclsh \
  exec tclsh "$0" ${1+$@}

  puts "end of b.tcl"
  ---------------------------------

  When "a.tcl" is called from the command line the output 
  is

  end of a.tcl

  as expected. But when "a.tcl" is sourced from Wish 
  (either by source a.tcl or by using wish's menu item) 
  b.tcl gets called but never returns. It seems to be 
  related to the called script writing to stdout/stderr; 
  when the puts in "b.tcl" is removed everything works as 
  expected.

  Calling tclsh directly by putting "#!/usr/bin/tclsh" in the 
  first line instead of calling indirectly through sh does not 
  solve the problem.

  I am using Daniel Steffen's BI distribution of Tcl/Tk 8.4.4 
  on Mac OS X 10.3.1!


tkt_uuid: 1100518fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: None
title: Button should stay in -overrelief state after event
comment:
  Given the following Tcl/Tk 8.4.9 example:

  console hide
  wm state . zoomed
  raise .
  frame .tb -bd 1 -relief raised 
  button .tb.bt1 -text "Button1" -relief flat -overrelief
  raised
  pack .tb -fill x -side top 
  pack .tb.bt1 -side left

  When the mouse hovers over Button1 it's -overrelief
  option is raised.  However, after the button is pressed
  the relief is returning back to the -relief option,
  even though the mouse is still hovering over the button.

  Button1 should still be in it's -overrelief state
  always as long as the mouse is over it, even if the
  button was pressed.

  Thanks!
  USCode


tkt_uuid: 219935ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: Scrollbars not scrolling canvas correctly
comment:
  OriginalBugID: 1385 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-07'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2309
  OS: AIX
  OSVersion: 4.1 - 4.3
  Machine: RS6000
  ClosedDate: '1999-08-07'


  Name:
  Anthony Johnson
  email:  caldiver@pacbell.net

  Extensions:
  TclX

  ReproducibleScript:
  I create a canvas and a window and attach a scrollbar. The canvas contains a gridded list, each line containing a button with a 16x16 bitmap image and a label of approximately 20 characters.

  The scroll increment is set to the height of a single cell. I use the Scroll_Set and Scrolled_Listbox procedures as defined in Welch's book.

  ObservedBehavior:
  If the list exceeds 1380 lines, the scrollbar will no longer scroll to the bottom of the list. It is not possible to view or select any entries from the list below that point. Also, if you clock the scrollbar area between the bar and the arrow button (for scrolling a page), it jumps several pages at once.

  DesiredBehavior:
  The same behavior with a long list as a short list.


tkt_uuid: 3410536fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: None
title: -install_name badly set because of LIB_RUNTIME_DIR badly set
comment:
  As this bug is really similar to bug ID: 2965133, I copy most of it here.

  I try to build Tk 8.6 X11 version on Mac OSX 10.5.8
  I build it with the current Tk HEAD (just cd tk/unix; configure --prefix=/usr/local/TclTk8.6 ; make ; make install, and it compiles without complaining. But launching wish8.6 gives : 

  dyld: Library not loaded: /usr/local/TclTk8.6/lib:/usr/X11/lib

  As far as I can tell, the problem is that LIB_RUNTIME_DIR is being set up as a colon-separated list of directories, which is then copied to DYLIB_INSTALL_DIR, which in turn is treated as just one directory. Makefile.in sets it up thus:

  DYLIB_INSTALL_DIR = ${LIB_RUNTIME_DIR}

  and this variable is only used in configure.in, thus:

  TK_SHLIB_LD_EXTRAS="${TK_SHLIB_LD_EXTRAS}"' -install_name "${DYLIB_INSTALL_DIR}"/${TK_LIB_FILE}'

  FWIW, manually editing the build/tk/*/Makefile to remove the second components from the definition of LIB_RUNTIME_DIR made wish running again.


tkt_uuid: 669759ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 7 High
foundin: obsolete: 8.4.1
resolution: Fixed
title: image destruction on <Destroy> crashes
comment:
  This script crashes WinTk (debug or non-dbug build) on
  Windows 2000.


  # script
  image create photo splash -file [file join $tk_library
  images logo100.gif]

  canvas .c -width 100 -height 100
  .c create image 0 0 -image splash -anchor nw

  bind . <Destroy> {catch {image delete splash}}
  update

  destroy .
  # end script

  The crash occurs here:

  static void
  DeleteImage(masterPtr)
      ImageMaster *masterPtr;/* Pointer to main data
  structure for image. */
  {
      Image *imagePtr;
      Tk_ImageType *typePtr;

      typePtr = masterPtr->typePtr;
      masterPtr->typePtr = NULL;
      if (typePtr != NULL) {
  for (imagePtr = masterPtr->instancePtr; imagePtr != NULL;
  imagePtr = imagePtr->nextPtr) {
     (*typePtr->freeProc)(imagePtr->instanceData,
     imagePtr->display);

  with 'typePtr' being garbage.

  Vince.


tkt_uuid: 797404ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: TIP Implementation
resolution: Accepted
title: Implementation of TIP#158
comment:
  To provide distinction between Return and KP_Enter on
  windows, the following patch does the job:

  Module: tkWinX.c
  Function: GetState

  Immediately following after

  switch(wParam) {
      case VK_SHIFT:
  ...
  }

  1133a1134,1138
  >     if ( HIWORD( lParam ) & KF_EXTENDED ) {
  >        mask |= Mod4Mask;   
  >        prevState = ((state & mask) ^ prevState) ? 0 : 1;
  >     }
  >

  KP_Enter is recognized as Mod4-Return if bound.
  Otherwise, KP_Enter is recognized as Return.


   


tkt_uuid: 3553311fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.12
resolution: Fixed
title: Test spinbox-3.70 fails (core-8-5-branch)
comment:
  In core-8-5-branch, on Windows Vista:

  ==== spinbox-3.70 SpinboxWidgetCmd procedure, "xview" widget command FAILED
  ==== Contents of test case:

      .e xview moveto 0.5
      format {%.6f %.6f} {*}[.e xview]

  ---- Result was:
  0.505376 0.720430
  ---- Result should have been (exact matching):
  0.505376 0.72043
  ==== spinbox-3.70 FAILED


  My understanding is that the expected results are wrong, and that the output really should be 
  0.505376 0.720430
  exactly as it is.

  This test passes in core-8-4-branch because there is no format %.6f in this test in that branch.

  This test passes in trunk because the expected test result matches the output (i.e. 0.505376 0.720430) that I think is correct.

  I will fix the test in core-8-5-branch.


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


  Name:
  Scott Thibault

  Extensions:
  None

  CustomShell:
  No

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

  ObservedBehavior:
  Crashes due to a NULL pointer access.


tkt_uuid: 1815246fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: text broken but canvas ok
comment:
  While using arabic characters I found a strange behaviour of tcl/tk. The canvas widget and the text widget should give the same display when both are given the same text, but the following two snippets show
  a difference.
  The canvas widget works as expected and displays the character \uFEA0 with a diacritic sign \u0651 above it:

     font create titusFont -family "TITUS Cyberbit Basic" -size 48
     canvas .c -width 500 -height 500
     pack .c
     .c create text 300 300 -font titusFont -text "\u0651\uFEA0"


  Trying the same with a text widget distorts the display. The base sign  \uFEA0 renders fine but the diacritic \u0651 is reduced to only one pixel width:

     font create titusFont -family "TITUS Cyberbit Basic" -size 48
     text .t -font titusFont -width 20 -height 3
     pack .t
     .t insert end  "\u0651\uFEA0"

  Is this an error of TK or am I doing something wrong? I get this strange behaviour with tcl/tk version 8.4.11, 8.4.14, and 8.5a3under linux with X11R6 version 6.8.2.


tkt_uuid: 3012605fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: Menubar entries not normalized after viewing disabled
comment:
  Enter these commands:
  . config -menu [menu .m1]
  .m1 add cascade -menu [menu .m2] -label Foo
  .m2 add command -label Bar

  You can now select Foo from the top menu and select the Bar entry from it

  .m1 entryconfig Foo -state disabled

  Foo can still be selected but the entry Bar is greyed out and cannot be selected

  .m1 entryconfig Foo -state normal

  Bar is still greyed out and still cannot be selected.
  Note that if you do not select Foo between disabling and normalizing it, Bar can still be selected after normalizing it. Also if you enter 

  .m2 entryconfig Bar -state normal

  ...then Bar will be selectable again.


tkt_uuid: 219900ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Duplicate
title: bug in checkbutton inside cascade menu: can't traverse cascade past the checkbutton menu
comment:
  OriginalBugID: 691 Bug
  Version: 8.0p2
  SubmitDate: '1998-10-02'
  LastModified: '1999-08-13'
  Severity: MED
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  RelatedBugIDs: 676
  OS: All Unix
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-10-31'
  FixedInVersion: NA
  ClosedDate: '1999-08-13'


  The menus do not seem to work properly under Unix.  I am running
  Tcl/Tk 8.0.2 on Redhat Linux 5.1.

  To reproduce the problems, do the following:

  Try running the widget demo and then clicking on "Menus and cascades".
  Bring up the "Cascades" menu.  Using the down arrow, move to "Check
  buttons".  As soon as you get to that menu option, the cascade menu
  pops up and you are no longer traversing the "Cascades" menu, but are
  now in the "Check buttons" menu.  You have to click the left arrow key
  to get back to the "Cascades" menu.

  This effect is really bad if the first item at the top of a menu is a
  cascade menu.  Then, just clicking the mouse to popup the overall menu
  will cause the cascade menu to popup.  Even though it was never
  selected.  There are no menus in the demos which have this, so it is
  trickier to demonstrate this, although it happens in some of my code.

  Thanks,
  Sim Harbert

  This is the defined behavior, and not really a bug.  On Windows,
  you get the behavior you expected using native menus.  Unix does
  not seem to have a standard for this (Netscape is totally messed
  up - the Linux one anyway). 
  -- 08/13/1999 hobbs


tkt_uuid: 220481ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: selected text not highlighted in edit
comment:
  OriginalBugID: 1688 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-01'
  LastModified: '1999-08-07'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  FixedDate: '1999-08-07'
  FixedInVersion: 8.1.1


  Name:
  Brian Toby

  ReproducibleScript:
      text .txt -width 50 -wrap none -state disabled  -yscrollcommand ".yscroll set" -xscrollcommand ".xscroll set" 
      scrollbar .yscroll -command ".txt yview"
      scrollbar .xscroll -command ".txt xview" -orient horizontal
      grid .xscroll -column 0 -row 2 -sticky ew -columnspan 4
      grid .txt -column 0 -row 1 -sticky nsew -columnspan 4
      grid .yscroll -column 4 -row 1 -sticky ns 
      grid columnconfigure . 3 -weight 1
      grid rowconfigure . 1 -weight 1
      grid [button .b1 -text enable -command ".txt config -state normal"]  -column 0 -row 0
      grid [button .b2 -text disable -command ".txt config -state disabled"]
       -column 1 -row 0
      grid [button .b3 -text "show selection"  -command {tk_dialog .show Select [selection get] "" 0 OK} ]  -column 2 -row 0
      for {set i 0} {$i < 50} {incr i} {.txt insert end "this is line $i\n"}

  ObservedBehavior:
      In the above script, text in the text box can be selected by dragging
      the mouse. In UNIX selected text is highlighted, in Windows it is not,
      even though the selection is indeed set . Interestingly, the text is
      highlighted if the state for .txt is set to normal. Once text has been
      selected and highlighted once, the text box can then be set "disabled"
      and text highlighting occurs correctly.

  DesiredBehavior:
      Selected text should always be highlighted.



      I would really love a work around -- is there any command that would
      allow me to select part of rhe buffer.
  --
  This was a minor bug in the bindings that disabled select on Windows
  for state disabled texts and has since been fixed.  A work-around
  in 8.0.5 would be to remove the check for state. 
  -- 08/07/1999 hobbs


tkt_uuid: 2175411fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: Fixed
title: test ttk-6.3 lacks important control
comment:
  test ttk-6.3 "Test package cleanup" -body {
      interp create foo
      foo eval { if {[catch {package require Tk}]} { load {} Tk } }
      foo eval { destroy . }
      interp delete foo
  }

  The [package require Tk] is influenced
  by so many factors, there's no telling
  what this test will actually be testing.
  The versions and variants of Tk that
  happen to be installed as well as the
  value of environment variables like
  TCLLIBPATH fill this test with uncertainties.

  If the aim is to test the same Tk library
  that the test suite is already testing,
  it's simpler and more predictable to
  replace the line

      foo eval { if {[catch {package require Tk}]} { load {} Tk } }

  with

      load {} Tk foo

  The particular failure I encountered
  that led me to file this report, is
  that I was testing in a --enable-symbols=mem
  --enable-threads Tcl interpreter, and the
  uncontrolled [package require Tk] in this
  test brought in a libtk that was not a
  --enable-symbols=mem build, and that
  combination leads to panics.


tkt_uuid: 1160025fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Fixed
title: MacOS X : mouse co-ordinates reported offset from pointer
comment:
  This bug is rather more troublesome than it would
  appear at first sight, given the utterly contrived
  nature of the example presented here.  

  We find that mouse events (click, drag, etc.) are
  frequently reported as having occurred at a position
  offset from the pointer.  This affects
  application-specific bindings, such as those we create
  for a user to draw on a canvas, and also internal Tk
  bindings, such as those needed to trigger a button
  press.  This latter artefact can give the interface the
  appearance of being hung or frozen.

  The workaround is to move the window (even very
  slightly) by dragging the title bar.

  As I say, it occurs quite frequently in practice, but
  it hasn't been all that easy to find a simple sequence
  of steps that reliably reproduces the problem.  Now
  here goes...

     1. Create a Tcl/Tk script "offset.tcl" in your 
        working directory (attached)
     2. Start "wish" from the Terminal command prompt 
        in your working directory
     3. Enter the following three commands at the % 
        prompt, and WITHOUT touching the "Wish Shell" 
        window:
               source offset.tcl
               toplevel .t
               destroy .t
     4. Click on the title bar of "Wish Shell" to 
        bring it to the front
     5. Click in the canvas (i.e. anywhere in the 
        Wish Shell window)

  A circle will be drawn on the canvas, but it will be
  displaced from the click by a margin of very roughly
  50-100 pixels below and to the right. Repeat for as
  long as you like :-)  Move the window, and click again.
  Circles will now be drawn at the mouse pointer
  location.  You can return focus to the Terminal window
  and repeat the creation and destruction of the dummy
  top-level in order to re-create the problem.  You must
  give focus to the Wish Shell window by clicking on its
  title bar.  If you click anywhere else in the window,
  the problem does not arise.

  The contents of offset.tcl define the canvas and its
  binding :

  ---Start of offset.tcl---
  proc drawCircle {c x y} {
    set x1 [expr $x-2]
    set y1 [expr $y-2]
    set x2 [expr $x+2]
    set y2 [expr $y+2]
    $c create oval $x1 $y1 $x2 $y2
  }

  canvas .c -height 400 -width 400
  pack .c
  bind .c <Button-1> "drawCircle .c %x %y"
  --- End of offset.tcl ---


tkt_uuid: 219404ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
resolution: Works For Me
title: Wish crashes under Win2K
comment:
  OriginalBugID: 6314 Bug
  Version: 8.0.3
  SubmitDate: '2000-09-26'
  LastModified: '2000-10-25'
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: Windows 2000
  OSVersion: Windows 2000
  Machine: Pentium III 500, 256MB RAM, 10GB HDD
  FixedDate: '2000-10-25'
  ClosedDate: '2000-10-25'


  Name:
  Connie van Zyl

  Extensions:
  TCL

  CustomShell:
  None.

  ReproducibleScript:
  When running wish.exe under Windows 2000, it creates a Dr. Watson error.  The software I'm using actually uses Tcl 7.5 source code.  I'm not doing any programming with Tcl myself, but I nned to get this wish problem sorted out as soon as possible.


tkt_uuid: 1826019fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 34. [tk_chooseColor]
priority: 5 Medium
foundin: None
resolution: None
title: Update for the default colour picker
comment:
  With the coming release of Tk 8.5 Donal Fellows asked if 
  anybody was interested in updating the colour picker
  (::tk::dialog::color::) that is used for platforms that
  do not offer a native facility. I volunteered.

  The attached source uses Tile widgets instead of Tk 
  widgets, where possible. Further improvements: a better alignment for the label, entry and colour bars.

  There is one smallish issue: the Alt-letter bindings
  have no effect anymore. This is due to the Tile 
  widgets - if you change ::ttk::label into ::tk::label
  they work again.

  Furthermore: I needed extra padding for the selFrame 
  widget (line 303) otherwise the border of the surrounding
  widget was incomplete (especially with the clam theme
  under Windows)


tkt_uuid: 1506006fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Rejected
title: Add a blink option on some widgets
comment:
  A blink option should be add for the text associated
  with some widgets:


  for example with a button widget:

  .b -text myButton -blink 500 , 'myButton' blinks every
  500 ms.

  With a label widget:

  .l -text myLabel -blink 1000, 'myLabel' blinks every 1s.

  etc...for other concerned widgets

  FD
  fadel[at]laposte.net


tkt_uuid: 220029ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Duplicate
title:
  Tk8.2.0/unix  ldAix-script does not exist for RS6000. After configure tk8.2, then run make will produce the error no idAix file found

comment:
  OriginalBugID: 2916 Bug
  Version: 8.2
  SubmitDate: '1999-09-27'
  LastModified: '1999-09-28'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2917
  OS: Other
  Machine: NA
  ClosedDate: '1999-09-28'


  Name:
  Sang-Lung CHAN

  CustomShell:
  Aix 4.2.1


tkt_uuid: 2058868fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: None
resolution: None
title: Spinbox Options
comment:
  The current behaviour of a spinbox differs from that of other widgets such as radiobuttions, checkbuttons and labels in that the initial value is the first item in a values list unlike radio/check buttons & labels which adopt any stored value of -variable or -textvariable as the initial value

  This limits the functionality and is confusing (at least to me)

  To preserve current functionality but extend the capability I would propose an additional option of
  -initialvalue

  The behaviour should be to confirm this is a valid item in the -values list and if it is than this value should be displayed in the widget, if it is not a valid item then the first item in the values list should be
  displayed

  Spinbox is different to the other widgets in that there are multiple potential -values hence the need for an additional option to nominate the initial value where it is relevant. 

  A good string value example is selection of a username from a preset list of usernames & storage of the selection between sessions. 

  A good numeric example would be a scale of -10 to +10 with an initial value of 0

  please refer to ActiveTcl Bug 71910: and 

  http://sourceforge.net/tracker/index.php?func=detail&aid=1778168&group_id=12997&atid=362997

  for other comments



  bugs@crossroadz.com.au


tkt_uuid: 3426824fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: None
title: fonts ignore tk scaling
comment:
  Fonts appear to ignore the value of tk scaling:

  Code:

  puts "tk_patchLevel = $tk_patchLevel"
  tk scaling 1
  font create f -family helvetica -size 12
  label .l -text "Hello World" -font f
  update idletasks
  puts "tk scaling = [tk scaling]"
  puts "linespace (1) = [font metrics f -linespace]"
  puts "winfo reqheight .l = [winfo reqheight .l]"
  tk scaling 2
  update idletasks
  puts "tk scaling = [tk scaling]"
  puts "linespace (2) = [font metrics f -linespace]"
  puts "winfo reqheight .l = [winfo reqheight .l]"
  font configure f -size 12
  update idletasks
  puts "linespace (3) = [font metrics f -linespace]"
  puts "winfo reqheight .l = [winfo reqheight .l]"
  exit 0

  Output with 8.5.10/8.6b2:

  tk_patchLevel = 8.6b2
  tk scaling = 1.00028129395218
  linespace (1) = 18
  winfo reqheight .l = 22
  tk scaling = 2.00056258790436
  linespace (2) = 18
  winfo reqheight .l = 22
  linespace (3) = 18
  winfo reqheight .l = 22

  Output with 8.4.19:


  tk_patchLevel = 8.4.19
  tk scaling = 1.00028129395
  linespace (1) = 12
  winfo reqheight .l = 18
  tk scaling = 2.0005625879
  linespace (2) = 12
  winfo reqheight .l = 18
  linespace (3) = 27
  winfo reqheight .l = 33

  Tested on Linux (Ubuntu 11.10)  with 8.5.10 and 8.6b2. Works as expected with 8.4.19 on Linux and with 8.6b2 on Windows XP. Not tested on Mac.

  See also: http://wiki.tcl.tk/8488


tkt_uuid: 2028703fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.5.3
resolution: Fixed
title: Crash packing children into unmapped toplevel
comment:
  Bug 2009788 had Tk crashing when calling RemapWindows on an unmapped toplevel. Fixing that and adding further tests shows that packing a child widget into the unmapped/unmanaged toplevel will crash. This time its in TopLevelRequestProc called from Tk_GeometryRequest in the idle loop. The following test crashes on Windows with Tk HEAD and in 8.5.3.

  test wm-forget-1.4 "pack into unmapped toplevel causes crash" -body {
      toplevel .parent
      toplevel .parent.child
      wm forget .parent.child
      pack [button .parent.child.button -text Hello]
      after 250 {destroy .parent}
      tkwait window .parent
  } -cleanup {
      deleteWindows
  } -result {}


tkt_uuid: 518057ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Invalid
title: tk-8.3.4 wont compile@ freebsd4.5-stable
comment:
  aleph# ./configure
  loading cache ./config.cache
  checking for ranlib... (cached) ranlib
  checking for gcc... (cached) cc
  checking whether the C compiler (cc  ) works... yes
  checking whether the C compiler (cc  ) is a cross-
  compiler... no
  checking whether we are using GNU C... (cached) yes
  checking whether cc accepts -g... (cached) yes
  checking how to run the C preprocessor... (cached) 
  cc -E
  checking for unistd.h... (cached) yes
  checking for limits.h... (cached) yes
  checking for building with threads... no (default)
  checking if the compiler understands -pipe... yes
  checking for Tcl configuration... (cached) 
  found /usr/local/src/tcl8.3.4/unix/tclConfig.sh
  checking for existence 
  of /usr/local/src/tcl8.3.4/unix/tclConfig.sh... 
  loading
  checking if 64bit support is requested... no
  checking if 64bit Sparc VIS support is requested... no
  checking system version (for dynamic loading)... 
  FreeBSD-4.5-STABLE
  checking for dlopen in -ldl... (cached) no
  checking for ar... (cached) ar
  checking for build with symbols... no
  checking for sin... (cached) no
  checking for main in -lieee... (cached) no
  checking stdlib.h... yes
  checking fd_set and sys/select... yes
  checking for ANSI C header files... (cached) yes
  checking for mode_t... (cached) yes
  checking for pid_t... (cached) yes
  checking for size_t... (cached) yes
  checking for uid_t in sys/types.h... (cached) yes
  checking for sys/time.h... (cached) yes
  checking whether time.h and sys/time.h may both be 
  included... (cached) yes
  checking pw_gecos in struct pwd... yes
  checking for X... (cached) no
  checking for X11 header files... couldn't find any!
  checking for X11 libraries... checking for 
  XCreateWindow in -lXwindow... (cached) no
  couldn't find any!  Using -lX11.
  checking for main in -lXbsd... (cached) no
  checking for connect... (cached) yes
  checking for gethostbyname... (cached) yes
  checking for sin... (cached) no
  checking for main in -lieee... (cached) no
  checking whether char is unsigned... (cached) no
  checking for strtod... (cached) yes
  checking for Solaris2.4/Tru64 strtod bugs... ok
  checking how to build libraries... shared
  updating cache ./config.cache
  creating ./config.status
  creating Makefile
  creating tkConfig.sh
  aleph# make
  cc -pipe -c -O -Wall -Wconversion -Wno-implicit-int -
  fPIC  -I/usr/local/src/tk8.3.4/unix -
  I/usr/local/src/tk8.3.4/unix/../generic  -
  I/usr/local/src/tk8.3.4/unix/../bitmaps -
  I/usr/local/src/tcl8.3.4/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  /usr/local/src/tk8.3.4/unix/../gen
  eric/tk3d.c
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:21
  ,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:83: 
  X11/Xlib.h: No such file or directory
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tkPort.h:3
  2,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:27
  ,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:77: X11/Xlib.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:78: X11/cursorfont.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:79: X11/keysym.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:80: X11/Xatom.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:81: X11/Xproto.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:82: X11/Xresource.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:83: X11/Xutil.h: No such file or directory
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:21
  ,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:581: 
  syntax error before `Bool'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:591: 
  syntax error before `Bool'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:597: 
  syntax error before `Bool'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:657: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:660: 
  syntax error before `Visual'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:662: 
  syntax error before `Window'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:671: 
  syntax error before `XWindowChanges'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:673: 
  syntax error before `XSetWindowAttributes'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:787: 
  syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:887: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:889: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:985: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1049: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1061: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1091: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1094: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1337: 
  syntax error before `XErrorEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1339: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1341: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1343: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1348: 
  syntax error before `XEvent'
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tk.h:1361,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:21
  ,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:37: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:37: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:39: 
  syntax error before `Tk_3DBorderGC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:40: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:43: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:48: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:57: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:76: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:80: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:90: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:95: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:115: 
  syntax error before `XSetWindowAttributes'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:122: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:125: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:146: 
  syntax error before `XWindowChanges'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:164: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:185: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:229: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:239: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:244: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:248: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:254: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:256: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:262: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:267: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:274: 
  syntax error before `Tk_FontId'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:274: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:278: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:281: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:283: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:286: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:291: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:296: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:299: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:305: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:307: 
  syntax error before `Tk_GCForColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:307: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:308: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:324: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:330: 
  syntax error before `Tk_GetBitmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:331: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:333: 
  syntax error before `Tk_GetBitmapFromData'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:335: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:340: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:341: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:343: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:344: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:344: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:346: 
  syntax error before `Tk_GetColormap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:347: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:367: 
  syntax error before `Tk_GetGC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:369: 
  syntax error before `XGCValues'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:369: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:396: 
  syntax error before `Tk_GetPixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:396: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:397: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:414: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:419: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:421: 
  syntax error before `Colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:421: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:430: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:432: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:441: 
  syntax error before `Tk_InternAtom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:442: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:478: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:483: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:485: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:503: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:540: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:543: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:548: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:583: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:592: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:595: 
  syntax error before `Colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:598: 
  syntax error before `Visual'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:601: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:618: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:624: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:640: 
  syntax error before `Tk_AllocBitmapFromObj'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:642: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:648: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:650: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:693: 
  syntax error before `Tk_GetBitmapFromObj'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:694: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:696: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:697: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:763: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:766: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:779: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:787: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:794: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:798: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:814: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:842: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:844: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:845: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:847: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:852: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:853: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:856: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:858: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:863: 
  syntax error before `XSetWindowAttributes'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:865: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:866: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:871: 
  syntax error before `XWindowChanges'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:876: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:882: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:894: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:898: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:899: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:900: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:901: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:902: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:903: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:904: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:906: 
  syntax error before `Font'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:908: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:909: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:910: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:911: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:913: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:915: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:916: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:918: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:924: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:926: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:929: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:937: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:946: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:951: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:953: 
  syntax error before `Visual'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:956: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:957: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:960: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:973: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:975: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:976: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:983: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:994: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:995: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:996: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1007:
   syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1010:
   syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1011:
   syntax error before `Colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1012:
   syntax error before `Visual'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1013:
   syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1019:
   syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1020:
   syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1026:
   syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1028:
   syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1042:
   syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1063:
   syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1064:
   syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1068:
   syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1070:
   syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1072:
   syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1073:
   syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1077:
   syntax error before `Pixmap'
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:46: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:50: 
  syntax error before `Window'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:50: 
  `Window' declared as function returning a function
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:50: 
  warning: parameter names (without types) in function 
  declaration
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:53: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:62: 
  syntax error before `TkClassCreateProc'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:84: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:118: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:122: 
  syntax error before `Time'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:162: 
  syntax error before `KeyCode'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:221: 
  syntax error before `Font'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:388: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:421: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:435: 
  syntax error before `XID'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:498: 
  field `warpWindow' declared as a function
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:645: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:650: 
  syntax error before `Visual'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:653: 
  field `window' declared as a function
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:703: 
  syntax error before `XWindowChanges'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:707: 
  syntax error before `XSetWindowAttributes'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:814: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:871: 
  syntax error before `*'
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:87
  8,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:46
  : syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:51
  : syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:57
  : syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:81
  : syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:91
  : syntax error before `TkCurrentTime'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:91
  : warning: data definition has no type or storage 
  class
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:98
  : syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:10
  5: syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:11
  9: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:12
  2: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:14
  7: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:17
  5: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:18
  2: syntax error before `keysym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:19
  2: syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:23
  9: `TkpMakeWindow' declared as function returning a 
  function
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:24
  6: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:25
  9: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:27
  1: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:27
  3: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:28
  0: syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:28
  7: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:29
  1: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:30
  1: syntax error before `TkStringToKeysym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:30
  1: warning: data definition has no type or storage 
  class
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:31
  9: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:36
  4: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:46
  9: syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:47
  6: syntax error before `KeySym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:47
  8: syntax error before `TkpGetKeySym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:47
  9: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:47
  9: warning: data definition has no type or storage 
  class
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:48
  9: syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:49
  1: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:49
  4: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:49
  9: syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:50
  2: syntax error before `Time'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:50
  5: syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:50
  7: syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:51
  1: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:51
  2: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:52
  1: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:53
  1: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:53
  3: syntax error before `keysym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:53
  6: syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:55
  3: `tkpMakeWindow' declared as function returning a 
  function
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:55
  6: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:56
  0: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:56
  4: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:56
  5: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:56
  6: syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:56
  8: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:57
  0: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:57
  3: syntax error before `KeySym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:58
  0: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:59
  6: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:70
  2: syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:70
  4: syntax error before `KeySym'
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:1063: 
  syntax error before `XImage'
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:33: 
  syntax error before `Screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:38: 
  syntax error before `Colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:52: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:34: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:37: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Alloc3DBorderFromObj':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:108: 
  warning: implicit declaration of function 
  `ScreenOfDisplay'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:108: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:108: 
  structure has no member named `screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:109: 
  structure has no member named `atts'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:109: 
  structure has no member named `colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:138: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:138: 
  structure has no member named `screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:139: 
  structure has no member named `atts'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:139: 
  structure has no member named `colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Get3DBorder':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:194: 
  syntax error before `gcValues'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:195: 
  `XColor' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:195: 
  (Each undeclared identifier is reported only once
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:195: 
  for each function it appears in.)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:195: 
  `bgColorPtr' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:195: 
  warning: statement with no effect
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:196: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:198: 
  `dispPtr' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:209: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:209: 
  structure has no member named `screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:210: 
  structure has no member named `atts'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:210: 
  structure has no member named `colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:232: 
  structure has no member named `screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:232: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:233: 
  structure has no member named `visual'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:233: 
  structure has no member named `visual'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:235: 
  structure has no member named `colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:235: 
  structure has no member named `atts'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:238: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:239: 
  structure has no member named `darkColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:240: 
  structure has no member named `lightColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:241: 
  structure has no member named `shadow'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:241: 
  `None' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:242: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:243: 
  structure has no member named `darkGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:244: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:255: 
  `gcValues' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:255: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:256: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:256: 
  `GCForeground' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:191: 
  warning: `hashPtr' might be used uninitialized in 
  this function
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Draw3DRectangle':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:283: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: At top 
  level:
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:351: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:353: 
  warning: return-type defaults to `int'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_3DBorderColor':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:355: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:356: 
  warning: control reaches end of non-void function
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: At top 
  level:
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:375: 
  syntax error before `Tk_3DBorderGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:376: 
  warning: return-type defaults to `int'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_3DBorderGC':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:384: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:384: 
  `None' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:388: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:390: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:392: 
  structure has no member named `darkGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:401: 
  `GC' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:401: 
  syntax error before `None'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:402: 
  warning: control reaches end of non-void function
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Free3DBorder':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:428: 
  `Display' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:428: 
  `display' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:428: 
  warning: implicit declaration of function 
  `DisplayOfScreen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:428: 
  structure has no member named `screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:429: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:436: 
  `prevPtr' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:438: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:439: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:441: 
  structure has no member named `darkColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:442: 
  structure has no member named `darkColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:444: 
  structure has no member named `lightColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:445: 
  structure has no member named `lightColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:447: 
  structure has no member named `shadow'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:447: 
  `None' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:448: 
  structure has no member named `shadow'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:450: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:451: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:453: 
  structure has no member named `darkGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:454: 
  structure has no member named `darkGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:456: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:457: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_SetBackgroundFromBorder':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:600: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Draw3DPolygon':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:752: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:754: 
  syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:766: 
  syntax error before `poly'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:768: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:770: 
  syntax error before `gc'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:772: 
  `Display' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:772: 
  `display' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:772: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:774: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:774: 
  `None' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:800: 
  `p1Ptr' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:800: 
  subscripted value is neither array nor pointer
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:801: 
  `p2Ptr' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:801: 
  subscripted value is neither array nor pointer
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:847: 
  subscripted value is neither array nor pointer
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:847: 
  warning: left-hand operand of comma expression has no 
  effect
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:847: 
  warning: value computed is not used
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:848: 
  warning: left-hand operand of comma expression has no 
  effect
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:859: 
  `newB1' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:860: 
  `newB2' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:862: 
  `poly' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:865: 
  `b1' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:865: 
  `b2' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:897: 
  `perp' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:900: 
  `c' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:901: 
  `shift1' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:902: 
  `shift2' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:916: 
  `gc' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:916: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:918: 
  structure has no member named `darkGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:920: 
  warning: implicit declaration of function 
  `XFillPolygon'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:920: 
  `Convex' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:921: 
  `CoordModeOrigin' undeclared (first use in this 
  function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:848: 
  warning: value computed is not used
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Fill3DRectangle':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:960: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:994: 
  warning: implicit declaration of function 
  `XFillRectangle'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:994: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:994: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Fill3DPolygon':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1025: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1027: 
  syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1041: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1041: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1042: 
  `Complex' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1042: 
  `CoordModeOrigin' undeclared (first use in this 
  function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: At top 
  level:
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1093: 
  syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1094: 
  `p2Ptr' used prior to declaration
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1094: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1099: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1099: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1101: 
  syntax error before `{'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:35: 
  warning: `Intersect' declared `static' but never 
  defined
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:36: 
  warning: `InitBorderObj' used but never defined
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:38: 
  warning: `ShiftLine' declared `static' but never 
  defined
  *** Error code 1

  Stop in /usr/local/src/tk8.3.4/unix.
  aleph# 


tkt_uuid: 220152ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Invalid
title: Request change in Tk installation
comment:
  OriginalBugID: 1641 RFE
  Version: 8.1b2
  SubmitDate: '1999-03-26'
  LastModified: '2000-02-25'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  ClosedDate: '2000-02-25'


  Name:
  Larry W. Virden

  Extensions:
  Tk

  DesiredBehavior:
      Libraries distributed relating to Tcl should be installed in
      either ${prefix}/lib/{extension_name.version} or in
      ${exec_prefix}/lib/{extension_name.version}, depending on
      whether the portion is script or binary.
      Current practice of installing binary extensions directly into
      ${exec_prefix}/lib/ results in pkgIndex.tcl problems.
      





      By updating the example extension, Tk, and Tcl distribution
      source, Scriptics sets a useful precendence for extension
      writers.
      ---

  I don't think I'm understanding the problem here correctly.  Tcl/Tk
  already separates itself based on $prefix and $exec-prefix.  What
  exactly is not being done correctly? 
  -- 02/25/2000 hobbs


tkt_uuid: 1724841fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Fixed
title: README typos with fix
comment:
  I'm attaching a patch to this bug report. The tk8.4.15/unix/README file has a few typos, and I've fixed them.


tkt_uuid: 1957792fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: None
title: Window not redrawn
comment:
  If I create a label widget with an image and this image is changed somehow, the widget does not get redrawn until I do something with it, like clicking at it etc. Reproduce this by having two images of the same size and do:

  set f1 [tk_getOpenFile]
  set f2 [tk_getOpenFile]
  set name1 [image create photo -file $f1]
  set name2 [image create photo -file $f2]
  pack [ttk::label .l -image $name1 -compound image -padding 100]

  # wait here and see the result then do

  $name1 copy $name2

  I'm runng 8.5.2 on an 10.5.2 Mac.
  Likely this happened when the extra double buffering was removed.


tkt_uuid: 415757ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 4
foundin: obsolete: 8.3.3
resolution: Fixed
title: Incorrect [bgerror] documentation
comment:
  bgerror(n) distributed with Tk 8.3.3 describes
  a user-configurable button (via the option database)
  in Tk's [bgerror] implementation.

  This feature is not available in Tk 8.3.  It first
  appears in Tk 8.4.


tkt_uuid: 220577ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: raising a popup window crashes
comment:
  OriginalBugID: 2530 Bug
  Version: 8.1.1
  SubmitDate: '1999-08-12'
  LastModified: '2000-02-09'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 8.1.1
  Machine: X86
  FixedDate: '2000-02-09'
  FixedInVersion: 8.3


  Name:
  David Beccue

  CustomShell:
  none until this patch

  Comments:
  Please let me know if this patch is good, or if instanceData shouldn't
      ever be NULL so there really must be something wrong somewhere else in
      my code.

      Thanks!

  ReproducibleScript:
  I'm a newbie at TCL/TK porting a project from Unix to NT.  I didn't take
      the time to produce a small example, BUT I did trace the problem in the
      TK source and patch it effectively.

  ObservedBehavior:
  crash in TkFrame.c::TkInstallFrameMenu::TkpMenuNotifyToplevelCreate when
      framePtr == NULL

  DesiredBehavior:
  no crash

  Patch:
  I just added:

  if (framePtr)

  in front of the call to TkpMenuNotifyToplevelCreate(...) in function TkInstallFrameMenu in TkFrame.c in generic subdirectory

  PatchFiles:
  TkInstallFrameMenu in TkFrame.c in generic subdirectory



  It should never happen that the framePtr is NULL, please check the
  C code.  A 'panic' was added in 8.3 to help others pinpoint future
  problems of the same sort. 
  -- 02/09/2000 hobbs


tkt_uuid: 220186ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: Simple c/s script hangs wish on W98
comment:
  OriginalBugID: 1979 Bug
  Version: 8.1
  SubmitDate: '1999-05-04'
  LastModified: '1999-10-22'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  ClosedDate: '1999-10-22'


  Name:
  Christopher Nelson

  ReproducibleScript:
  # A very simple client and server in the same script
      proc genData { channel count } {
          puts $channel "$count foo bar baz"
          flush $channel
          incr count -1
          if { $count == 0 } {
              close $channel
              return
          } else {
              after 500 genData $channel $count
          }
      }
      # [fcopy] callback
      proc cleanup { channel doneName args } {
          close $channel
          set ::$doneName 1
      }
      # [socket -server] callback
      proc newClient { clientDoneName channel address port } {
          fcopy $channel stdout  -command [list cleanup $channel $clientDoneName]
      }
      # The server socket (creates new read socket).  Let the system pick the
      port
      set serverSocket [socket -server [list newClient clientDone] 0]
      # Get the port from the socket
      set sockname [fconfigure $serverSocket -sockname]
      set port [lindex $sockname 2]
      # The client (write) end of the socket
      set clientSocket [socket localhost $port]
      # Write some stuff on the write socket
      genData $clientSocket 10
      # Let the events run
      vwait clientDone
      # Close the server socket
      close $serverSocket

  ObservedBehavior:
  When sourced into tclsh, the script runs to completion and writes data
      pumped through the socket to stdout.  In wish, only the first line is
      displayed then the Console hangs.

  DesiredBehavior:
  tclsh and wish should behave the same way for non-graphical scripts.



  There is no std 'stdout' in wish, as on Windows it is not a
  console based app (for good reason).  The user is attempting
  to fcopy into stdout, which is effectively /dev/null.  This
  would have to be rewritten for use on Windows in Tk.  This
  can be chalked up to platform inconsistency. 
  -- 10/22/1999 hobbs


tkt_uuid: 2534237fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: None
title: Tk not linking correctly on netbsd
comment:
  NetBSD elf linker don't use /etc/ld.so.conf to find the shared libraries at runtime. As a consequence, the linker option -rpath must be used to hardcode the library search path into the binaries on this platform.
  The following patch address these issues.

  The reversed order of arguments for the X11_LIB_SWITCHES variables in Makefile.in is to allow the library path of the xft library appears in the rpath before the x11 one, as on this platform the xft library can be installed separatedly. If the x11 library path appears first, the xft delivered with the X system will be picked up instead of the choosed one (usually on /usr/pkg/lib).


tkt_uuid: 220398ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: tkOpenDocument is not internationalized
comment:
  OriginalBugID: 869 Bug
  Version: 8.1a2
  SubmitDate: '1998-11-25'
  LastModified: '1999-05-20'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: hershey
  OS: Macintosh
  OSVersion: 8.1
  Machine: NA
  FixedDate: '1998-11-25'
  FixedInVersion: 8.1b1


  I am using MacTk 8.1a2 on Japanese MacOS8.1.

  I have tried to create an application by using "Drag & Drop Tclets",
  but the target application is not correctly created.

  Therefore I have examined "Drag & Drop Tclets", and found that
  "tkOpenDocument" passes the argument which contains invalid characters
  if the path name of the file dropped from finder contains international
  characters (i.e. shiftjis).


  see the patch at /patches/tk8.1a2/tkMacHLEvents.c.txt


tkt_uuid: 1876768fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: None
resolution: None
title: fix for bug 220826 - reentrancy and tk_messageBox
comment:
  The bug 220826 is currently marked as close, but shouldn't have been closed IMHO.

  This patch makes the common variable used by the dialog box unique per dialog box window.  This prevents the global close of all currently active dialog boxes exhibited by the bug report.

  It does not change the current behavior that causes a subsequent dialog to close the currently active dialog that has the same parent window name.

  The change is simple enough to replicate on the 8.4 branch.

  The attached tar file contains diffs of files msgbox.tcl dialog.tcl and dialog.test.


tkt_uuid: 1616446fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.11
resolution: Invalid
title: ns2 installation
comment:
  i try to install ns2-allinone-2.29 but i got the error tk8.4.11 make failed...



  narayananbest@gmail.com


tkt_uuid: 1601982fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 6
foundin: obsolete: 8.4.15
resolution: Duplicate
title: Tk console shows up in embedded use
comment:
  The code in tkMacOSXInit.c:TkpInit for controlling whether the console shows (and we are tcl_interactive) says:

  /*
   * If we don't have a TTY and stdin is a special character file of
   * length 0, (e.g. /dev/null, which is what Finder sets when double
   * clicking Wish) then use the Tk based console interpreter.
   */

  But this appears to be too aggressive for the use case of embedding Tk in apps.  For Windows, the console creation is only done in winMain.c (for wish).  I guess OS X does it in TkpInit because it shares code with the unix branch.  However, this then does leak into Tk usage as a library.

  I'm a bit stumped as to where the best place to move it would be, without propagating some magic information around.


tkt_uuid: 795725ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Fixed
title: canvas font & foreground
comment:
  Canvas widgets do not support the -font and -foreground
  options. When creating text items, there are given a
  default -fill color of black, which is not very useful
  if the canvas is black. Also text items are given a
  default system-dependent font.

  Of course, if you set resources values such as:

  % option add *Canvas.background black
  % option add *foreground white
  % option add *font "Courier 20"

  this doesn't work. I would like to see the canvas
  widget support these options.

  See also Tk bug report 795717


tkt_uuid: 220225ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: Charatcers bolded for RPS on Macintosh
comment:
  OriginalBugID: 2593 Bug
  Version: 8.2
  SubmitDate: '1999-08-20'
  LastModified: '1999-08-27'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: 8.6, PPC
  Machine: Power PC
  ClosedDate: '1999-08-27'


  Name:
  Thomas Stanley

  Extensions:
  none

  Comments:
  I can send you a picture of what is happening!

  ReproducibleScript:
  after entering the wish shell, I perform an ls (list) command, but the
      program 
      echo's lS.  When I change directories and perform an ls, all files that
      contain 
      r, p or s, have those letters bolded and uppercas

  ObservedBehavior:
  evertime a file has an r, p or s in its name it's bolded and uppercased
      in a 
      different font

  DesiredBehavior:
  The files should only have shown lower case characters and unbolded.  I
      don't 
      think I can trust 8.2 at this time



  This appears to be an unreproducable error for other Mac users on
  the newsgroup (other reports were all OK).  Perhaps the 'ls' command
  being issued is doing something crazy?? 
  -- 08/24/1999 hobbs
  Apparently this is confirmed by Jim Ingham, but not by others on
  the newsgroup.  This needs to be examined further. 
  -- 08/25/1999 hobbs
  From Jim Ingham:

  This was a bad font.  Thomas found the font (Stencil,
  if you care), and when he removes it, everything works as expected.
  He sent me a copy of the font, and I will poke around and see if I can
  figure out why it was fooling Tk into using it instead of the regular
  system font.
   
  -- 08/27/1999 hobbs


tkt_uuid: 220585ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Windows 8.2.0 installation has tk_patchLevel 8.2b3
comment:
  OriginalBugID: 2599 Bug
  Version: 8.2
  SubmitDate: '1999-08-20'
  LastModified: '1999-08-20'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '1999-08-20'
  FixedInVersion: 8.2.1


  Name:
  Mike Bevington

  ReproducibleScript:
  run tcl82.exe to install tcl8.2 on Windows NT 4.0
      run wish82.exe - click Help, About
      
      reports:
      
      Tcl 8.2.0
      Tk 8.2b3
      
      When I build tk8.2\win from the scriptics repository source
      after nmake clean, I get a tk82.dll with the correct version.

  ObservedBehavior:
  No operational problems observed.

  DesiredBehavior:
  Tcl 8.2.0
      Tk 8.2.0



  This particular oversight has since been fixed.  Hopefully we
  bump it appropriately for the next cut... 
  -- 08/20/1999 hobbs


tkt_uuid: 1711994fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: ttkLabel strict-aliasing
comment:
  compiler warning:

  /home/dgp/src/tk8.5a6/unix/../generic/ttk/ttkLabel.c: In function ‘LabelSetup’:
  /home/dgp/src/tk8.5a6/unix/../generic/ttk/ttkLabel.c:510: warning: dereferencing type-punned pointer will break strict-aliasing rules


  Also, unless the ttk files are
  going to be bug-free, we need
  to add maintainer categories for
  them, both here in the Tracker
  and in TIP 23.


tkt_uuid: 2858503fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: "end" flag for ttk::combobox current
comment:
  the ttk::combobox widget has a "current" method which allow to choose which item of the list given to the combobox to be displayed. Unfortunatly, this method doesn't accept the "end" mark, specifying the end of the list.
  It would be great to have to "end" indice available in order to avoid computation of the length of the list before invoking <pathname> current method.


tkt_uuid: 903427ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Wont Fix
title: test failures with Tk from cvs on german w2k
comment:
  Attached is the log from running the test suite, i
  experience a hang in winDialog.test

  Looks like the test suit does not work well with a
  localized windows.


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: 814846ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 3 Low
foundin: obsolete: 8.5.8
resolution: Out of Date
title: No menu entry background color, Mac Cocoa
comment:
  Setting background colors for menu entries in Aqua Tk
  8.4.4 has
  no effect.  Here's an example.

  menubutton .b -text Tools
  menu .b.m
  .b.m add command -label stuff -background red
  .b configure -menu .b.m
  pack .b

  The resulting menu has a white background on the Mac.
  On Linux, Windows, SGI and HP Alpha the menu entry
  background comes out red as requested.


tkt_uuid: 3553180fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: ttk::treeview can't be disabled
comment:
  ... or, rather, disabling it doesn't do anything, at least as of Tk 8.5.9. It still responds to all events, allowing the selection to be changed, columns to be resized, etc. In my app I do:

    foreach x [bind Treeview] {
       bind Treeview $x [format {if { ![%%W instate disabled] } { %s }} [bind Treeview $x]]
    }

  to make a disabled treeview totally disabled, but I think something like this should be the default.


tkt_uuid: 456632ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 6
foundin: obsolete: 8.4a4
resolution: Fixed
title: Tk_OptionTable handling flawed
comment:
  This is a verbatim copy of an email I sent to others:

  In the move from Tk 8.0 to 8.1 (or thereabouts), a new 
  and clever
  way of storing the optionTable data for the widget (to 
  work with
  the objectification of optionTables) was created.  I'm 
  now finding
  a serious flaw in those changes (Scott was noted in 
  the CVS fixes,
  but I don't know where the idea originated) - you 
  can't do this
  and for commands that are namespace imported.

  To jog memories, the change was something to the 
  effect of using
  the clientData field of the created command object to 
  store the
  initialized optionTable info in (before this was used 
  to cache
  the Tk_MainWindow result).  This looks like (from 
  tkButton.c,
  r1.1 -> r1.3):

  ***************
  *** 311,333 ****
     */
    
    static int
  ! ButtonCreate(clientData, interp, argc, argv, type)
  !     ClientData clientData;    /* Main window 
  associated with
  !                                * interpreter. */
        Tcl_Interp *interp;               /* Current 
  interpreter. */
  !     int argc;                 /* Number of 
  arguments. */
  !     char **argv;              /* Argument strings. */
        int type;                 /* Type of button to 
  create: TYPE_LABEL,
                                   * TYPE_BUTTON, 
  TYPE_CHECK_BUTTON, or
                                   * TYPE_RADIO_BUTTON. 
  */
    {
  !     register TkButton *butPtr;
  !     Tk_Window tkwin = (Tk_Window) clientData;
  !     Tk_Window new;
  ! 
  !     if (argc < 2) {
  !       Tcl_AppendResult(interp, "wrong # args: should 
  be \"",
  !               argv[0], " pathName ?options?\"", 
  (char *) NULL);
          return TCL_ERROR;
        }
    
  --- 556,597 ----
     */
    
    static int
  ! ButtonCreate(clientData, interp, objc, objv, type)
  !     ClientData clientData;    /* Option table for 
  this widget class, or
  !                                * NULL if not created 
  yet. */
        Tcl_Interp *interp;               /* Current 
  interpreter. */
  !     int objc;                 /* Number of 
  arguments. */
  !     Tcl_Obj *CONST objv[];    /* Argument values. */
        int type;                 /* Type of button to 
  create: TYPE_LABEL,
                                   * TYPE_BUTTON, 
  TYPE_CHECK_BUTTON, or
                                   * TYPE_RADIO_BUTTON. 
  */
    {
  !     TkButton *butPtr;
  !     Tk_OptionTable optionTable;
  !     Tk_Window tkwin;
  ! 
  !     optionTable = (Tk_OptionTable) clientData;
  !     if (optionTable == NULL) {
  !       Tcl_CmdInfo info;
  !       char *name;
  ! 
  !       /*
  !        * We haven't created the option table for 
  this widget class
  !        * yet.  Do it now and save the table as the 
  clientData for
  !        * the command, so we'll have access to it in 
  future
  !        * invocations of the command.
  !        */
  ! 
  !       TkpButtonSetDefaults(optionSpecs[type]);
  !       optionTable = Tk_CreateOptionTable(interp, 
  optionSpecs[type]);
  !       name = Tcl_GetString(objv[0]);
  !       Tcl_GetCommandInfo(interp, name, &info);
  !       info.objClientData = (ClientData) optionTable;
  !       Tcl_SetCommandInfo(interp, name, &info);
  !     }
  ! 
  !     if (objc < 2) {
  !       Tcl_WrongNumArgs(interp, 1, objv, "pathName ?
  options?");
          return TCL_ERROR;
        }

  So what's the problem?  If you were to create the 
  command in a
  namespace, say ::vu::dial, export dial and then import 
  dial into
  :: (or any other namespace), the command that gets 
  called is
  actually a special obj command whose objClientData 
  field is
  already used for the ImportCommand - you can't reset 
  it.  This
  manifests itself in the core simply:

  lorax [~/build/8333/tk8.3] 27 > wish8.3
  % namespace export -clear *
  % namespace eval ::foo { namespace import ::button }
  % namespace eval ::foo { ::foo::button .b }
  .b
  % namespace eval ::foo { ::foo::button .c }
  Segmentation fault

  The first call changes objClientData, causing the 
  second call
  to seg fault.  While this is an odd case for the core, 
  this would
  be common for extension authors who create their 
  widgets in
  namespaces that people import as a matter of course.  
  This only
  affects them when they use this model for the new obj-
  ified
  optionTable setup.

  My thinking was to rework this to use 
  ThreadSpecificData fields.
  Does anyone see a problem with that?  Is there perhaps 
  a better
  way that I'm missing?


tkt_uuid: 219924ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Duplicate
title: undesirable automatic post of cascade menu
comment:
  OriginalBugID: 1320 RFE
  Version: 8.1b1
  SubmitDate: '1999-03-02'
  LastModified: '1999-11-02'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 676
  OS: Solaris
  OSVersion: SUN-OS 5.5
  Machine: Other
  ClosedDate: '1999-11-02'


  Name:
  Aldo MAZZILLI

  ReproducibleScript:
      menubutton .test -text "TEST" -menu .test.menu
      pack .test -side left
      set n [menu .test.menu ]
      $n add cascade -label "Subtest" -menu $n.test
      set n0 [menu $n.test]
      $n0 add command -label "exit" -command "exit"
      
      



  ObservedBehavior:
      The command menu line "exit" is automatically posted when you click on
      the "TEST" menubutton which is an undesirable behaviour for the
      customer.
      Under SunOS : this occurs with TCL/TK8.0.4 and TCL/TK8.1b1 but it was
      not exist with TCL/TK7.6.
      Under Win32 : everything is correct
      



  DesiredBehavior:
      I don't want the cascade menu (which is the command menu line "exit") to
      be posted automatically but only when the customer click on the
      cascade-line "Subtest" like it was under TCL/TK7.6
      


tkt_uuid: 3597410fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: None
title: new virtual events <<NewLine>> and <<NewPage>>
comment:
  TkCon and console.tcl need those virtual events to make sure that
  <Return> and <KP_Enter> have the same binding without duplicating
  it. And the entry, spinbox and text widgets can be simplyfied with
  it as well.

  <<NewLine>> joins <Return> with <KP_Enter>, while <<NewPage>>
  does the same but then with the <Control> key.


tkt_uuid: 2049429fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.3
resolution: None
title: Some options aren't picked up from the options database
comment:
  The text widget ignore the value in the option database for certain options. Examples are -spacing[123]. This fact is not documented in the text manual page.

  After a bit of source diving, there's an option in the 'flags' field of the Tk_OptionSpec struct in tkText.c named TK_OPTION_DONT_SET_DEFAULT which prevents the value to be read form the option database (line 490 of tkConfig.c). This value is not documented in the Tk_SetOptions manual page, which states " At present only a single flag is supported: TK_OPTION_NULL_OK". There is also TK_CONFIG_NULL_OK in tkText.c, also not documented.


tkt_uuid: 220336ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title:
  I have problem using the 4 and 6 number keys on the keypad when the Num Lock is on. They behave as Left and Right arrow keys.

comment:
  OriginalBugID: 6029 Bug
  Version: 8.2.2
  SubmitDate: '2000-07-20'
  LastModified: '2000-07-21'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: shawn
  RelatedBugIDs: 6028
  OS: SunOS
  Machine: SUN m/c
  FixedDate: '2000-07-20'
  ClosedDate: '2000-07-21'


  Name:
  Meetu Sharma

  Extensions:
  Using Tcl 7.6 and Tk 4.2

  ReproducibleScript:
  I am coding in TK4.2 on Sun Solaris 2.6. The problem i am facing is that when i bring up the view on a SUN m/c and put the NUM LOCK key on, the 4 and 6 keys on the keypad behave as left and right arrow keys. On setting the NUM LOCK to off they behave properly (as arrow keys). However, all other number keys behave perfectly fine. 
  Instead if i make a telnet session to the same SUN m/c from a WIN-NT  machine, the keypad keys work perfectly fine. There is no problem in that case.

  I tried the same thing with TK-8.2 on Sun Solaris and it behaves the same as with TK-4.2 on Sun.

  Could you pl. help me out on this.

  ObservedBehavior:
  The 4 and 6 keys on the keypad on the right of the keyboard behave as left and right arrow keys even if the NUM LOCK is ON.

  DesiredBehavior:
  The 4 and 6 key when pressed with NUM Lock set to ON, in a Tk Widger should show the numbers 4 and 6 instead of moving the cursor to the left and right.



  Exact Duplicate of 6028 
  -- 07/21/2000 shawn


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: 739965ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: numerous text test failures (TIP 113?)
comment:
  starting with today's HEAD (after TIP 113 commit)
  many (~40) tests begin to fail, all with the same
  "bad switch" error, for example:

  ==== text-20.2 TextSearchCmd procedure, -backwards
  option FAILED
  ==== Contents of test case:

      .t search -backwards xyz 1.4

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad switch "": must be --, -all,
  -backward, -count, -elide, -exact, -forward, -nocase,
  -nolinestop, or -regexp
      while executing
  ".t search -backwards xyz 1.4"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== text-20.2 FAILED

  looks like a bug in option parsing for [$text search] ?


tkt_uuid: 1900872fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: None
title: makefile.vc needs ws2_32.lib added to baselibs
comment:
  When compiling with Visual C++ 2008 the definition of baselibs in makefile.vc must be changed to the following in order to link the WISH program properly.

  baselibs   = kernel32.lib user32.lib ws2_32.lib


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

  wm deiconify .
  wm resizable . 0 0

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

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


tkt_uuid: 1844749fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk build fails with MinGW on Windows
comment:
  When building a shared lib, Tk HEAD on windows using mingw, the link step fails, because the ole32.lib and oleaut32.lib have been removed from tcl.m4 ( r 1.47 ) why were these libraries removed?

  after:
  ./configure --enable-threads --prefix=/usr
  make


  The link error is:

  Creating library file: libtk85.a
  tkWinSend.o:tkWinSend.c:(.text+0x160): undefined reference to `GetRunningObjectTable@8'
  tkWinSend.o:tkWinSend.c:(.text+0x187): undefined reference to `CreateBindCtx@8'
  tkWinSend.o:tkWinSend.c:(.text+0x1b4): undefined reference to `CreateFileMoniker@8'
  tkWinSend.o:tkWinSend.c:(.text+0x212): undefined reference to `CreateFileMoniker@8'
  tkWinSend.o:tkWinSend.c:(.text+0x389): undefined reference to `VariantInit@4'
  tkWinSend.o:tkWinSend.c:(.text+0x39b): undefined reference to `VariantInit@4'
  tkWinSend.o:tkWinSend.c:(.text+0x3e6): undefined reference to `SysAllocString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x47a): undefined reference to `VariantChangeType@16'
  tkWinSend.o:tkWinSend.c:(.text+0x4d8): undefined reference to `SysFreeString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x4ea): undefined reference to `SysFreeString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x4fc): undefined reference to `SysFreeString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x50e): undefined reference to `VariantClear@4'
  tkWinSend.o:tkWinSend.c:(.text+0x830): undefined reference to `SysAllocString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x84c): undefined reference to `SysAllocString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x865): undefined reference to `CreateErrorInfo@4'
  tkWinSend.o:tkWinSend.c:(.text+0x8eb): undefined reference to `SetErrorInfo@8'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x10): undefined reference to `CoTaskMemAlloc@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x167): undefined reference to `CoTaskMemFree@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x31e): undefined reference to `VariantInit@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x342): undefined reference to `VariantChangeType@16'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x362): undefined reference to `VariantClear@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x3af): undefined reference to `VariantInit@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x3cf): undefined reference to `VariantChangeType@16'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x3f7): undefined reference to `SysStringLen@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x433): undefined reference to `SysStringLen@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x47a): undefined reference to `VariantInit@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x4a9): undefined reference to `SysAllocString@4'
  collect2: ld returned 1 exit status
  make: *** [tk85.dll] Error 1 


tkt_uuid: 2794032fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 9 Immediate
foundin: None
resolution: Accepted
title: enable [load] of Tk 8.5 into Tcl 8.6+
comment:
  Attached patch, when applied to core-8-5-branch
  of Tk will produce a Tk library that no longer refuses
  to [load] into Tcl 8.6 and later.

  Since Tcl 8.6 has not introduced any interface
  incompatibilities that break Tk 8.5, this permits:

  $ tclsh8.6
  % info patch
  8.6b1.1
  % package require Tk 8.5.0-8.6
  8.5.7

  and according to the Tk test suite
  all is "well" (that is, as "well" as the
  test suite runs for matching Tcl/Tk)


tkt_uuid: 220598ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Tk8.2.0/unix ldAix-script does not exist for RS6000.
comment:
  OriginalBugID: 2917 Bug
  Version: 8.2
  SubmitDate: '1999-09-27'
  LastModified: '1999-09-28'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  OSVersion: AIX 4.2.1
  Machine: RS6000
  FixedDate: '1999-09-28'
  FixedInVersion: 8.2.1


  Name:
  Sang-Lung CHAN

  After configure tk8.2, then run make will produce the error no idAix file found

  This was a bug in the config script, fixed in 8.2.1. 
  -- 09/28/1999 hobbs


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


  Name:
  Allen Flick

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

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

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

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


tkt_uuid: 2039720fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 9 Immediate
foundin: obsolete: 8.6a1
resolution: Fixed
title: Tk doesn't need to manage XIDs
comment:
  After some discussion with Joe English, and subsequent discussions with the X.org developers, it has become apparent that Tk doesn't need to manage XIDs by replacing the core XID allocator.  This is all managed by the XC-MISC extension now that is very common.  I have also confirmed this by studying libX11 sources, which use XC-MISC.

  I have attached a patch to this bug report.  The patch makes Tk_FreeXId a no-op.  This patch also eliminates some unnecessary internal functions and function calls.

  keithp is Keith Packard of X.org in this discussion:

  <imaginator> Hi. I'm trying to get a definitive answer on whether or not XAllocID() can run out of ids these days. Does it make any attempt to reuse XIDs over a period of time?
  <keithp> imaginator: xlib manages reuse automatically
  <ajax> imaginator: if you have the XC-MISC extension on your server (and you do) then they get reused internally, yes.
  <ajax> you can still run out, but that requires actually consuming all of the XID space
  <imaginator> ok, so an application that runs a long time will no longer need to reuse XIDs or replace the core dpy->resource_alloc?
  <keithp> imaginator: right
  <imaginator> ok, good to know. So it seems we can put this code to rest in Tk: http://tktoolkit.cvs.sourceforge.net/tktoolkit/tk/unix/tkUnixXId.c?revision=1.11&view=markup
  <ajax> oh my.
  <imaginator> ajax?
  <ajax> yes, please do
  <keithp> imaginator: uh, yeah, since like 1993
  <ajax> i just didn't know tk did that
  <imaginator> How does the XC-MISC extension do this, and how common is the XC-MISC extension?
  <ajax> it asks the server for a list of unused IDs
  <keithp> imaginator: it's been around in every X server for 15 years
  <imaginator> thank you :)
  <imaginator> Now I think I have suitable justification to nuke this code.
    


tkt_uuid: 679960ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 4
foundin: obsolete: 8.4.1
resolution: Out of Date
title: Option menu shows \'...\', Aqua
comment:
  Option menu entries sometimes are shown in the menu button 
  abbreviated with "..." even though the button is allowed to resize 
  to accomodate the text.

  This happens on Aqua Tk 8.4.1.  Testing shows that the option 
  menus can only use the default font.  This is probably an 
  implementation limitation that should be documented.  If the font 
  is changed using the Tk option database then the option menu 
  continues to use the default font but sizes the button to 
  accomodate text using the requested font.

  Here is a wish script that demonstrates the problem.

  option add *font {system 8}
  wm geometry . 400x100
  tk_optionMenu .m v {The menu button is not} {made big enough} 
  {to accomodate the text.}
  pack .m

  The option menu button will show part of the text of the selected 
  entry followed by "...".  If the first line of the script is commented 
  out then the full text is shown in the option menu button.

  This bug makes panels of preferences containing many option 
  menus difficult to use.


