# ticket

tkt_uuid: 740565ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 5 Medium
foundin: None
resolution: None
title: focus.test failures
comment:
  platform: sparc solaris 8 sunblade 100, sun c compiler,
  2003-05-19 cvs head snapshot from activestate ftp site
  tcl compiled with enable-shared enable-symbols
  enable-threads
  tk compiled with enable-shared enable-symbols

  focus.test

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

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

  ---- Result was:
  .t .t {}
  ---- Result should have been (exact matching):
  .t {} {}
  ==== focus-5.1 FAILED

  ==== focus-6.2 miscellaneous - embedded application in
  different process FAILED
  ==== Contents of test case:

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

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

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

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

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

      # Bring the focus back to the main application.

      focus .t.f2.e1
      after 300 {set timer 1}
      vwait timer
      set result [list $x [dobg {set x}]]
      cleanupbg
      set result

  ---- Result was:
  {.t.f2.e1 {} {focus out .t.f2.e1 NotifyNonlinear}
  {focus out .t.f2 NotifyNonline
  arVirtual} {focus in .t.f1 NotifyNonlinear} {focus out
  .t.f1 NotifyAncestor} {fo
  cus out .t NotifyVirtual} |} {{focus in .
  NotifyVirtual} {focus in .e1 NotifyAnc
  estor} {focus out .e1 NotifyAncestor} {focus out .
  NotifyVirtual} {focus in . No
  tifyVirtual} {focus in .e1 NotifyAncestor} | {focus out
  .e1 NotifyAncestor} {foc
  us out . NotifyVirtual}}
  ---- Result should have been (exact matching):
  {.t.f2.e1 {} {focus out .t.f2.e1 NotifyNonlinear}
  {focus out .t.f2 NotifyNonline
  arVirtual} {focus in .t.f1 NotifyNonlinear} | {focus
  out .t.f1 NotifyNonlinear} 
  {focus in .t.f2 NotifyNonlinearVirtual} {focus in
  .t.f2.e1 NotifyNonlinear}} {{f
  ocus in . NotifyVirtual} {focus in .e1 NotifyAncestor}
  | {focus out .e1 NotifyAn
  cestor} {focus out . NotifyVirtual}}
  ==== focus-6.2 FAILED


tkt_uuid: 2225507fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: obsolete: 8.4.19
resolution: None
title: Win32 menu keyboard traversal broken
comment:
  Greetings,

  the Win32 menu keyboard traversal is broken in the
  following way:
  When a menu (from a menubutton) is posted via the
  <Alt-Key> binding (_not_ via the mouse!), the <Escape>
  key closes the menu but leaves the menubutton armed.
  Unfortunately, another <Alt-Key> on the same menu
  then fails! One has to open a different menu before
  being able to open the first menu again.

  The proposed fix from
  http://groups.google.com/groups/search?as_q=Windows+Menu+Keyboard&as_epq=&as_oq=&as_eq=&num=10&scoring=&lr=&as_sitesearch=&as_ugroup=comp.lang.tcl&as_usubject=&as_uauthors=&safe=off

  which boils down to adding the line
  MenuUnpost {}
  to the proc
  ::tk::MenuFirstEntry
  fixes this problem for me.

  kind regards,
  Randolf
  -- 
  http://www.ayam3d.org/  NURBS modelling for the masses.


tkt_uuid: 413904ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Fixed
title: entry-20.* cause invalid memory use
comment:
  Running the test suite with Electric Fence, I see
  invalid memory usage in the routine
  EntryValidateChange() when running tests entry-20.*.

  EntryValidate() frees entryPtr, but later code
  in EntryValidateChange() keeps right on using it.

  I see Tcl_Preserve() sprinkled here and there, which
  might solve the problem, except that DestroyEntry
  calls ckfree() instead of Tcl_EventuallyFree().

  There's a comment indicating this is intentional,
  but it still needs fixing. 


tkt_uuid: 1550034fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Wont Fix
title: Choosing a non-existing directory on Linux
comment:
  Choosing a non-existing directory in the dialog 
  provided by [tk_chooseDirectory] returns a relative 
  file name on Linux. This behavior is unexpected and 
  inconsistent with the behavior on Windows, which works 
  as expected.

  To reproduce,
  - Run "tk_chooseDirectory" with no parameters.
  - In the dialog, browse to some directory; for the 
  purpose of this example, assume "/home/me".
  - In the "Selection" field, overwrite the current 
  selection with "foo", assuming that "foo" is neither a 
  file nor a sub-directory in the current directory.
  - Click "OK" once. Nothing happens!
  - Click "OK" a second time.
  tk_chooseDirectory now returns "foo".

  There are two bugs here:
  o The first click on "OK" that doesn't do anything.
  o Returning a relative file name, instead of the 
  expected absolute name "/home/me/foo".

  This works just fine on Windows: when you browse to 
  some directory, and enter a non-existing name, 
  tk_chooseDirectory returns an absolute file name with 
  the browsed-to directory as its directory name and the 
  desired tail.


tkt_uuid: 3505465fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Invalid
title: Error with "selection get"
comment:
  I'm using TkDND for dropping (X11 lib), and if I'm dropping files from Konqueror with "selection get -type text/plain..." I get the error message 'bad format for selection: wanted "32", got 8"'. I think that in case of 8 bit formats the function TkSelEventProc() should convert to a string in the system encoding, because throwing an error is inadequate, especially while "text/plain" is one of the most common drag types under X11. If the Tk library cannot handle "text/plain" (or other important string types), dropping files from other applications seems to be impossible.


tkt_uuid: 220505ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: Docs missing for Tk_GetNumMainWindows API
comment:
  OriginalBugID: 1865 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 a man entry for this API for 8.3.1.

  - eric
   
  -- 04/24/2000 ericm


tkt_uuid: 513690ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: button -padx options
comment:
  Specifying  low -padx options on buttons for aqua-tk
  causes the font to be clipped.

  This limitation is largely brought about due to the
  aqua look and feel. A possible solution is to have a
  minimum value (and ignore anything lower), although
  this minimum may be font dependent.


tkt_uuid: 689199ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: Memory Leak when GIF reading fails
comment:
  There is an execution path in FileReadGIF that can
  result in trashBuffer being allocated but not
  deallocated.


tkt_uuid: 220854ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.1
resolution: None
title: Trailing tab characters in entry widgets are not displayed.
comment:
  OriginalBugID: 2411 Bug
  Version: 8.1
  SubmitDate: '1999-07-19'
  LastModified: '1999-10-22'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: kernel 2.0.35, libc.so.5.4.13
  Machine: Other


  Name:
  Chris Laas

  Extensions:
  (none)

  CustomShell:
  (none)

  Comments:
  I'll note that the "bind" line in the example above is a somewhat ugly
      hack to be able to insert tabs into the text.  It would be nice to have
      a standardized way to do that.

  ReproducibleScript:
  % cat > test.tcl
      pack [entry .e]
      bind .e <Tab> { tkEntryInsert %W "\t" ; break }
      ^D
      % wish8.1 test.tcl
      
      Type [TAB] at the entry to insert tab characters.  For example, type
      "[TAB]a[TAB]b[TAB][TAB]" to see what I mean.

  ObservedBehavior:
  Most tabs show up fine, but any trailing tab does not "show up" -- by
      this, I don't mean that I expect it to display any text.  I mean that,
      for example, pressing [END] to bring the insertion cursor to the end
      does not acknowledge the width of the tab, although pressing [RIGHT] and
      [LEFT] make it clear that there is a (zero-width) character there.  This
      is something of a problem in some applications, and I can't find a
      simple workaround.

  DesiredBehavior:
  Tk 4.2 has the correct behavior for this case.
      I suspect this has something to do with the introduction of Tk_CharBbox,
      but I was unable to pinpoint the bug in the source.


tkt_uuid: 220913ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Fixed
title: wm resizable . 0 0 removes custom 'winico icon'
comment:
  OriginalBugID: 5324 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-02'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: Windows NT
  OSVersion: 4.0sp5


  Name:
  Vince Darley

  Extensions:
  Winico 0.3

  ReproducibleScript:
  # type this into a wish shell
  package require Winico
  # you need a .ico file
  set icon [winico create myIcon.ico]
  winico setwindow . $icon
  # Now the window has a nice icon
  wm resizable . 0 0
  # Not any more!

  ObservedBehavior:
  The standard Tk icon replaces 'myIcon'.

  Note that there are other related 'icon replacement' problems.  For example, the following script, when double-clicked on, fails to set the window's icon:

  package require Winico
  set icon [winico create myIcon.ico]
  winico setwindow . $icon

  Or for a similar effect, type this into a shell:

  toplevel .t ; winico setwindow .t $icon

  DesiredBehavior:
  I expect setting a toplevel's icon to be a permanent change, and not for Tk to reset the icon when it sees fit...

  I don't think these bug existed in, e.g., Tk 8.1 but I'm not sure.


tkt_uuid: 219937ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: Segmentation fault in wish when using Zircon
comment:
  OriginalBugID: 1410 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-11-02'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2454
  OS: Other
  OSVersion: NetBSD (unsure of version)
  Machine: NA
  ClosedDate: '1999-11-02'


  Name:
  Phil Reynolds

  CustomShell:
  No changes

  ReproducibleScript:
  (No script available. Activation with command "zircon", Lindsay Marshall's IRC client)

  ObservedBehavior:
  At times, for random/no reason, the application crashes with a segmentation fault. Common, but totally strange, causes include high load (excess of 0.9) on the machine being used as display (not processor), running of non blank-screen xlock (same problem).

  DesiredBehavior:
  No crash... application continues to run.


tkt_uuid: 2353712fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Duplicate
title: treeview's row height doesn't depend on font size
comment:
  This script demonstrates the problem:

  ----
  package require Tk

  font configure TkDefaultFont -size 24
  ttk::treeview .tree -columns {one two three} -show headings

  .tree insert {} end -values [list one two three]
  .tree insert {} end -values [list one two three]
  grid .tree

  ----

  BTW, I didn't find -rowheight style option 
  documented anywhere.


tkt_uuid: 220198ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Tk_Main() is no longer available in TK-8.1.1
comment:
  OriginalBugID: 2213 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-15'
  LastModified: '1999-07-16'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: redman
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  FixedInVersion: NA
  ClosedDate: '1999-07-16'


  Name:
  Jose Santiago



  Correct behavior, use Tk_MainEx() instead.
   
  -- 07/16/1999 redman


tkt_uuid: 587698ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Duplicate
title: wm attributes -topmost and System Menu
comment:
  Trying to use the new -topmost option of wm attributes, 
  a typical application would be to post a new "Always on 
  Top" menu option in the windows system menu (see 
  code below). However, when running this code and 
  selecting the "Always on Top" option, the menu choice 
  disappears! If I replace the wm -topmost command with 
  one from a custom dll that does the same thing, the 
  menu option stays as expected.

  There is some interaction with the topmost command 
  and system menu.
  #---Demo Code below ---------------------------------------
  proc pinOnSystemMenu {M W} {
     if {$M=={}} {
        set M $W.menubar
        menu $M -tearoff 0
        $W config -menu $M
     }
     $M add cascade -label System -font menu -menu 
  $M.system
     menu $M.system -tearoff 0
     set ::TA($W,pinned) 0
     $M.system add separator
     $M.system add checkbutton -label "Always on Top" \
        -variable ::TA($W,pinned) \
        -command "control $W \$::TA($W,pinned)"
  }

  proc control {win how} {
     wm attributes $win -topmost $how
  }
  proc state {win} {
     return [wm attributes $win -topmost]
  }

  wm withdraw .
  toplevel .test
  wm protocol .test WM_DELETE_WINDOW {exit}
  ;##
  ;# Play with system menu, the option will disappear 
  when selected.
  ;#
  pinOnSystemMenu {} .test


tkt_uuid: 788959ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 58. [send]
priority: 6
foundin: TIP Implementation
resolution: Accepted
title: TIP 150: Reference implementation of win32 send
comment:
  This is the implementation of the TIP 150 win32 send
  proposal. This code isn't complete -- it especially
  needs comments adding -- but it is functional.


tkt_uuid: 220906ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Stub Entries
priority: 5 Medium
foundin: None
resolution: Fixed
title: More of Tk's internal functions exported through Stub table
comment:
  OriginalBugID: 4642 RFE
  Version: 8.3
  SubmitDate: '2000-03-28'
  LastModified: '2000-06-02'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All


  Name:

  Jan Nijtmans


  Comments:

  The forward declarations in tkIntDecls.h are necessary, otherwise source

      files always have to

      include tkText.h before tkInt.h.

      The file tkStubInit.c must be adapted as well, and tkIntDecls.h has more

      adaptations. But that can

      be done by "make genstubs", so it is not included in this patch.


  DesiredBehavior:

  My attempts to compile tkTest.c, tkUnixTest.c  and the tkprint extension as stub-enabled

  extensions failed because of critical functions are lacking from the Stub table. Therefore

  I request that the following functions (see patch) will be exported in a nearby future

  version of Tk.


  Patch:

  *** generic/tkInt.decls.origThu Feb 10 09:52:34 2000

  --- generic/tkInt.declsSun Mar 26 21:16:46 2000

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

  *** 629,634 ****

  --- 629,679 ----

    }


  + declare 139 generic {

  +     int  TkTextGetIndex (Tcl_Interp *interp, struct TkText *textPtr, \

  +     char *string, struct TkTextIndex *indexPtr)

  + }

  + 

  + declare 140 generic {

  +     void  TkTextIndexBackBytes (CONST struct TkTextIndex *srcPtr, \

  +     int count, struct TkTextIndex *dstPtr)

  + }

  + 

  + declare 141 generic {

  +     void  TkTextIndexForwBytes (CONST struct TkTextIndex *srcPtr, \

  +     int count, struct TkTextIndex *dstPtr)

  + }

  + 

  + declare 142 generic {

  +     struct TkTextIndex * TkTextMakeByteIndex (struct TkTextBTree *tree, \

  +     int lineIndex, int byteIndex, struct TkTextIndex *indexPtr)

  + }

  + 

  + declare 143 generic {

  +     void  TkTextPrintIndex (CONST struct TkTextIndex *indexPtr, char *string)

  + }

  + 

  + declare 144 generic {

  +     struct TkTextSegment * TkTextSetMark (struct TkText *textPtr, char *name, \

  +     struct TkTextIndex *indexPtr)

  + }

  + declare 145 generic {

  +     int TkTextXviewCmd (struct TkText *textPtr, Tcl_Interp *interp, \

  +     int argc, char **argv)

  + }

  + declare 146 generic {

  +     void TkTextChanged (struct TkText *textPtr, struct TkTextIndex *index1Ptr, \

  +     struct TkTextIndex *index2Ptr)

  + }

  + declare 147 generic {

  +     int TkBTreeNumLines (struct TkTextBTree *tree)

  + }

  + declare 148 generic {

  +     void TkTextInsertDisplayProc (struct TkTextDispChunk *chunkPtr, \

  +     int x, int y, int height, int baseline, Display *display, \

  +     Drawable dst, int screenY)

  + }

  + 

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


    # Define the platform specific internal Tcl interface. These functions are

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

  *** 671,676 ****

  --- 716,727 ----

        void TkUnixSetMenubar (Tk_Window tkwin, Tk_Window menubar)

    }


  + declare 8 unix {

  +     int TkpTestembedCmd (ClientData clientdata, Tcl_Interp *interp, \

  +     int argc, char **argv)

  + }

  + 

  + 

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

    # Windows specific functions


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

  *** 814,819 ****

  --- 868,878 ----

        int TkWinGetPlatformId(void)

    }


  + declare 34 win {

  +     int TkpTestembedCmd (ClientData clietdata, Tcl_Interp *interp, \

  +     int argc, char **argv)

  + }

  + 

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

    # Mac specific functions


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

  *** 1044,1049 ****

  --- 1103,1112 ----

        void TkMacPreprocessMenu (void)

    }


  + declare 66 mac {

  +     int TkpTestembedCmd (ClientData clietdata, Tcl_Interp *interp, \

  +     int argc, char **argv)

  + }


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


  *** generic/tkIntDecls.h.origWed Feb  9 03:13:51 2000

  --- generic/tkIntDecls.hSun Mar 26 21:17:14 2000

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

  *** 22,27 ****

  --- 22,32 ----

    #define TCL_STORAGE_CLASS DLLEXPORT

    #endif


  + struct TkText;

  + struct TkTextIndex;

  + struct TkTextBTree;

  + struct TkTextDispChunk;

  + 

    /*

     * WARNING: This file is automatically generated by the tools/genStubs.tcl

     * script.  Any modifications to the function declarations below should be made


  PatchFiles:

  tkInt.decls tkIntDecls.h


tkt_uuid: 3154705fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Close button has no effect
comment:
  When displaying a tk_messageBox on a system that doesn't provide native message boxes(linux), the close button does not respond when pressed.

  This appears to be caused by the following line which sets the WM_DELETE_WINDOW protocol to nil:
  wm protocol $w WM_DELETE_WINDOW { }

  The proposed solution is to set the protocol to execute the same code that is execute when <Escape> is pressed:
  wm protocol $w WM_DELETE_WINDOW [list $w.$cancel invoke]


tkt_uuid: 2806562fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 36. [tk_chooseDirectory]
priority: 8
foundin: None
resolution: None
title: tk_chooseDirectory on Mac freezes when accessing Samba share
comment:
  Mac OS X only.

  Do:
  - On a Windows machine, share a folder to the network
  - On the Mac, open finder, press Command-K and connect to that shared folder
  - Open Wish, paste the following in the console:
  tk_chooseDirectory -initialdir ~ -mustexist 1 -title "hello" -parent .
  - In the dialog, click on the sharing computer in the left pane, then on the shared folder

  Happens:
  - The contents are not shown
  - The dialog is frozen

  Accessing the share through Finder or any other app (e.g. TextMate) that uses similar dialogs works fine.

  Tested on Mac OS X 10.5.6 and 10.5.7, with Tcl/Tk 8.5.4, 8.5.7 and 8.6b1.1 (built from CVS head).
  The Windows machine was using Windows Vista SP2.


tkt_uuid: 570321ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Duplicate
title: tktest finalize segfault (text)
comment:
  tktest segaults during finalization (FreeRegexp) after
  running
  the tests in text.test on Linux/Alpha:

  (gdb) run ./../tests/all.tcl -file text.test
  Starting program: /local/src/tk/unix/./tktest
  ./../tests/all.tcl -file text.test
  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/text.test
  Tests began at Mon Jun 17 23:19:28 EDT 2002
  text.test

  ==== text-12.16 ConfigureText procedure FAILED
  ==== Contents of test case:

      # This test is non-portable because the window size
  will vary depending
      # on the font size, which can vary.

      catch {destroy .t2}
      toplevel .t2
      text .t2.t -width 20 -height 10
      pack append .t2 .t2.t top
      wm geometry .t2 +0+0
      update
      wm geometry .t2

  ---- Result was:
  150x140+5+21
  ---- Result should have been:
  150x140+0+0
  ==== text-12.16 FAILED


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

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

  ---- Result was:
  20x10+5+21 150x140+5+21
  ---- Result should have been:
  20x10+0+0 150x140+0+0
  ==== text-15.2 FAILED


  Tests ended at Mon Jun 17 23:19:34 EDT 2002
  all.tcl:        Total   278     Passed  275     Skipped
  1       Failed  2
  Sourced 1 Test Files.
  Files with failing tests: text.test
  Number of tests skipped for each constraint:
          1       macOrPc

  Program received signal SIGSEGV, Segmentation fault.
  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1204b3870)
      at malloc.c:3121
  3121    malloc.c: No such file or directory.
  (gdb) bt
  #0  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1204b3870)
      at malloc.c:3121
  #1  0x200005c4574 in __libc_free (mem=0x20000770de0) at
  malloc.c:3023
  #2  0x12020a1a8 in TclpFree (cp=0x1204b3a90 "") at
  ./../generic/tclAlloc.c:702
  #3  0x120135f68 in Tcl_Free (ptr=0x1204b3a90 "")
      at ./../generic/tclCkalloc.c:1160
  #4  0x1201cb254 in FreeRegexp (regexpPtr=0x1204b2780)
      at ./../generic/tclRegexp.c:991
  #5  0x1201cb35c in FinalizeRegexp (clientData=0x0)
      at ./../generic/tclRegexp.c:1024
  #6  0x120172740 in Tcl_FinalizeThread () at
  ./../generic/tclEvent.c:906
  #7  0x120172520 in Tcl_Finalize () at
  ./../generic/tclEvent.c:804
  #8  0x120172108 in Tcl_Exit (status=0) at
  ./../generic/tclEvent.c:564
  #9  0x120137d88 in Tcl_ExitObjCmd (dummy=0x0,
  interp=0x120360480, objc=1,
      objv=0x120361c40) at ./../generic/tclCmdAH.c:667
  #10 0x12012dd90 in TclEvalObjvInternal
  (interp=0x120360480, objc=1,
      objv=0x120361c40, command=0x0, length=0, flags=0)
      at ./../generic/tclBasic.c:3012
  #11 0x120174ac8 in TclExecuteByteCode
  (interp=0x120360480, codePtr=0x12045d0a0)
      at ./../generic/tclExecute.c:1279
  #12 0x120173bf8 in TclCompEvalObj (interp=0x120360480,
  objPtr=0x1204630d0)
      at ./../generic/tclExecute.c:917
  #13 0x12012f6c8 in Tcl_EvalObjEx (interp=0x120360480,
  objPtr=0x1204630d0,
      flags=0) at ./../generic/tclBasic.c:3907
  #14 0x1201c8c64 in TclObjInterpProc
  (clientData=0x120473d40,
      interp=0x120360480, objc=2, objv=0x11fffeee0)
      at ./../generic/tclProc.c:1074
  #15 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
  #16 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
  #17 0x1201a6008 in Tcl_FSEvalFile (interp=0x120360480,
  pathPtr=0x1203ce740)
      at ./../generic/tclIOUtil.c:1355
  #18 0x1201a4c88 in Tcl_EvalFile (interp=0x120360480,
      fileName=0x11ffff248 "./../tests/all.tcl") at
  ./../generic/tclIOUtil.c:234
  #19 0x12004fe88 in Tk_MainEx (argc=3, argv=0x11ffff3b0,
      appInitProc=0x12002a500 <Tcl_AppInit>,
  interp=0x120360480)
      at /local/src/tk/unix/../generic/tkMain.c:234
  #20 0x12002a4d8 in main (argc=4, argv=0x11ffff3a8)
      at /local/src/tk/unix/tkAppInit.c:69


tkt_uuid: 514374ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: tk_getOpenFile -initialdir fails
comment:
  As the subject says, tk_getOpenFile -initialdir [pwd] 
  (for example) fails with a "bad directory" message.

  One possible problem with this is due to using / 
  as a directory separator in old-style mac calls.

  tkMacOSXUtil.c specifies DIR_SEP_CHAR as 
  colon, but the pathname passed in to 
  FSpLocationFromPath contains slashes (it's 
  whatever [pwd] returned). I assume that the macos 
  calls require : instead. (I did try replacing the /s 
  with :s, but it didn't cure it.)

   


tkt_uuid: 220954ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Works For Me
title: button-release events get lost when target window is destroy
comment:
  OriginalBugID: 6293 Bug
  Version: 8.3
  SubmitDate: '2000-09-21'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Linux-Red Hat
  OSVersion: redhat 6.0
  Machine: dell precision 410


  Name:
  Jonas Beskow

  Comments:
  This bug was introduced in tk 8.3 and is also present 8.4a1. There is a
      passage at the top of Tk_HandleEvent() that seems to be responsible
      (when it is commented out, the errant behavoiur goes away):

          /*
           * Hack for simulated X-events: Correct the state field
           * of the event record to match with the ButtonPress
           * and ButtonRelease events.
           */

          if (eventPtr->type==ButtonPress) {
            dispPtr = TkGetDisplay(eventPtr->xbutton.display);
      eventPtr->xbutton.state |= dispPtr->mouseButtonState;
      switch (eventPtr->xbutton.button) {
          case 1: dispPtr->mouseButtonState |= Button1Mask; break; 
          case 2: dispPtr->mouseButtonState |= Button2Mask; break; 
          case 3: dispPtr->mouseButtonState |= Button3Mask; break; 
      }
          } else if (eventPtr->type==ButtonRelease) {
      dispPtr = TkGetDisplay(eventPtr->xbutton.display);
      switch (eventPtr->xbutton.button) {
          case 1: dispPtr->mouseButtonState &= ~Button1Mask; break; 
          case 2: dispPtr->mouseButtonState &= ~Button2Mask; break; 
          case 3: dispPtr->mouseButtonState &= ~Button3Mask; break; 
      }
      eventPtr->xbutton.state |= dispPtr->mouseButtonState;
          } else if (eventPtr->type==MotionNotify) {

      dispPtr = TkGetDisplay(eventPtr->xmotion.display);
      eventPtr->xmotion.state |= dispPtr->mouseButtonState;
          }

  ReproducibleScript:
  toplevel .x
  pack [label .x.l -text "double-click me!"]

  bind .x.l <Double-Button-1> [list destroy .x]
  bind . <B1-Motion> {puts "B1-Motion event"}

  # run the above lines, double-click on the label
  # when the labe-window goes away, move pointer over main window with no button pressed

  ObservedBehavior:
  B1-motion events are fired when no button is pressed

  DesiredBehavior:
  B1-motion events should not fire when no button is pressed


tkt_uuid: 1867834fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: ttk Toolbutton has wrong default anchor
comment:
  Create two buttons like this:

  package require Tk
  ttk::button .a \
      -text "Hello" \
      -width 10 \
      -style Toolbutton
  ttk::button .b \
      -text "World" \
      -width 10 
  pack .a .b

  On my windows XP machine the text of .a is left-
  justified but the text of .b is centered.

  The bug seems to be that the default anchor of the 
  Toolbutton style is left when it should be center. 
  I can fix this in my code with:

  ttk::style configure Toolbutton -anchor center

  I think the default for the Toolbutton should be
  centered, shouldn't it?


tkt_uuid: 220473ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Add to Tk distributions reference files which may not be on user's system
comment:
  OriginalBugID: 1645 RFE
  Version: 8.1b2
  SubmitDate: '1999-03-26'
  LastModified: '2000-04-27'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-04-27'
  FixedInVersion: 8.4a1


  Name: Larry W. Virden

  DesiredBehavior:
  I would like to suggest that the Tk binary and source distributions add
  as provided documentation of the valid symbolic color, key event and cursor
  names that Tk recognizes , with platform differences in particular
  pointed out.
      





      This would provide programmers on MacOS and Windows the info
      that X programmers typically have.  With the platform
      differences pointed out, it provides the Tk programmers on
      X information also invaluable.

  --

  I added colors.n, keysyms.n, and cursors.n, with appropriate crosslinks in other manual entries.  These pages include the information requested.  They will go out with 8.4a1.

  - eric

  -- 04/27/2000 ericm


tkt_uuid: 669159ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Fixed
title: error msg on loading Tk in safe interpreter
comment:
  squish:44> /autons/ActiveTcl8.4.1/bin/wish
  % info patch
  8.4.1
  % interp create -safe i
  i
  % ::safe::loadTk i
  can't read "Si(access_path,n)": no such element in array
  %

  This happens on solaris2.6 and win2k.


tkt_uuid: 220907ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Support for filetypes in Motif style file browser
comment:
  OriginalBugID: 5032 RFE
  Version: 8.3
  SubmitDate: '2000-04-12'
  LastModified: '2000-04-12'
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Unix


  Name:

  James Bonfield


  DesiredBehavior:

  Support for filetypes in Motif style file browser. This is currently implemented using a list of

  radiobuttons, although other formats could be used instead. It is optional. Without -filetypes the

  browser looks normal.


  Request: how about adding a -defaulttype option? (Obviously this requires editing all the dialogues,

  not just this implementation).


  Patch:

  *** orig/xmfbox.tcl     Wed Apr 12 14:22:30 2000

  --- new/xmfbox.tcl      Wed Apr 12 18:03:48 2000

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

  *** 103,108 ****

  --- 103,109 ----


        wm transient $w $data(-parent)


  +     tkMotifFDialog_FileTypes $w

        tkMotifFDialog_Update $w


        # Withdraw the window, then update all the geometry information

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

  *** 113,118 ****

  --- 114,186 ----

        wm title $w $data(-title)


        return $w

  + }

  + 

  + # tkMotifFDialog_FileTypes --

  + #

  + #     Checks the -filetypes option. If present this adds a list of radio-

  + #     buttons to pick the file types from.

  + #

  + # Arguments:

  + #     w               Pathname of the tk_get*File dialogue.

  + #

  + # Results:

  + #     none

  + 

  + proc tkMotifFDialog_FileTypes {w} {

  +     upvar #0 [winfo name $w] data

  + 

  +     set f $w.top.f3.types

  +     catch {destroy $f}

  + 

  +     # No file types: use "*" as the filter and display no radio-buttons

  +     if {$data(-filetypes) == ""} {

  +       set data(filter) *

  +       return

  +     }

  + 

  +     # The filetypes radiobuttons

  +     # set data(fileType) $data(-defaulttype)

  +     set data(fileType) 0

  + 

  +     tkMotifFDialog_SetFilter $w [lindex $data(-filetypes) $data(fileType)]

  + 

  +     #don't produce radiobuttons for only one filetype

  +     if {[llength $data(-filetypes)] == 1} {

  +       return

  +     }

  + 

  +     frame $f

  +     set cnt 0

  +     if {$data(-filetypes) != {}} {

  +       foreach type $data(-filetypes) {

  +           set title  [lindex [lindex $type 0] 0]

  +           set filter [lindex $type 1]

  +           radiobutton $f.b$cnt \

  +               -text $title \

  +               -variable [winfo name $w](fileType) \

  +               -value $cnt \

  +               -command "[list tkMotifFDialog_SetFilter $w $type]"

  +           pack $f.b$cnt -side left

  +           incr cnt

  +       }

  +     }

  + 

  +     pack $f -side bottom -fill both

  + 

  +     return

  + }

  + 

  + # This proc gets called whenever data(filter) is set

  + #

  + proc tkMotifFDialog_SetFilter {w type} {

  +     upvar #0 [winfo name $w] data

  +     global tkpriv

  + 

  +     set data(filter) [lindex $type 1]

  +     set tkpriv(selectFileType) [lindex [lindex $type 0] 0]

  + 

  +     tkMotifFDialog_Update $w

    }


    # tkMotifFDialog_Config --


  PatchFiles:

  xmfbox.tcl


tkt_uuid: 220607ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 39. Image Basics
priority: 2
foundin: None
resolution: Fixed
title: need an 'is image in use' query
comment:
  OriginalBugID: 3327 RFE
  Version: 8.2
  SubmitDate: '1999-11-05'
  LastModified: '2000-05-15'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Other
  OSVersion: NetBSD-1.4.1/i386
  FixedDate: '2000-05-15'
  FixedInVersion: 8.4a1


  Name: hume smith

  DesiredBehavior:
  In a program like Quill, it's rather hard to keep track of whether or
  not an image is being used to know whether to erase it.  It would be
  nice to be able to simply ask the widget whether any widgets want it...
  I'm guessing this is known for the sake of Tk_ImageChanged, and requires
  little more than a script interface?


  I added an [image inuse] command with the semantics you describe:

  % image create photo foo -file foo.gif
  foo
  % image inuse foo
  0
  % button .b -image foo
  .b
  % image inuse foo
  1

  This will go out with 8.4a1.

  - eric
   
  -- 05/15/2000 ericm


tkt_uuid: 220534ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Implementation of XSetDashes for Windows
comment:
  OriginalBugID: 2168 RFE
  Version: 8.1.1
  SubmitDate: '1999-06-03'
  LastModified: '1999-12-13'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0 SP3
  Machine: X86
  FixedDate: '1999-12-13'
  FixedInVersion: 8.3b1


  Name:

  Jan Nijtmans


  Comments:

  This patch makes the XSetDashes function available for the mac

      as well, but there it only operates as a NOP.


  DesiredBehavior:

  This patch is extracted from the Dash-patch for 8.1.1,

      (to be released soon), but it is identical to version

      8.0.5 and 7.6p2. Slot 0 of the Xlib Stub-table is

      alread reserved for this function, the only thing

      missing is the implementation.


      This patch is created against 8.1.1, but it works

      unmodified for 8.0.x as well.


  Patch:

  *** generic/tkInt.decls.origWed May 26 07:11:33 1999

  --- generic/tkInt.declsSat May 29 00:02:25 1999

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

  *** 1051,1060 ****


    # X functions for Windows


  ! # This slot is reserved for use by the dash patch:

  ! #  declare 0 win {

  ! #XSetDashes

  ! #  }

    declare 1 win {

        XModifierKeymap* XGetModifierMapping (Display* d)

    }

  --- 1051,1061 ----


    # X functions for Windows


  ! declare 0 win {

  !     void XSetDashes (Display* display, GC gc, int dash_offset,

  !     _Xconst char* dash_list, int n)

  ! }

  ! 

    declare 1 win {

        XModifierKeymap* XGetModifierMapping (Display* d)

    }

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

  *** 1520,1529 ****


    # X functions for Mac


  ! # This slot is reserved for use by the dash patch:

  ! #  declare 0 win {

  ! #XSetDashes

  ! #  }


    declare 1 mac {

        XModifierKeymap* XGetModifierMapping (Display* d)

  --- 1521,1530 ----


    # X functions for Mac


  ! declare 0 mac {

  !     void XSetDashes (Display* display, GC gc, int dash_offset,

  !     _Xconst char* dash_list, int n)

  ! }


    declare 1 mac {

        XModifierKeymap* XGetModifierMapping (Display* d)

  *** win/tkWinDraw.c.origFri Apr 16 23:03:02 1999

  --- win/tkWinDraw.cSat May 29 00:02:34 1999

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

  *** 125,130 ****

  --- 125,131 ----

    static voidRenderObject _ANSI_ARGS_((HDC dc, GC gc,

        XPoint* points, int npoints, int mode, HPEN pen,

        WinDrawFunc func));

  + static HPENSetUpGraphicsPort _ANSI_ARGS_((GC gc));

    

    /*

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

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

  *** 888,929 ****


        dc = TkWinGetDrawableDC(display, d, &state);


  !     if (!tkpIsWin32s && (gc->line_width > 1)) {

  ! LOGBRUSH lb;

  ! DWORD style;

  ! 

  ! lb.lbStyle = BS_SOLID;

  ! lb.lbColor = gc->foreground;

  ! lb.lbHatch = 0;

  ! 

  ! style = PS_GEOMETRIC|PS_COSMETIC;

  ! switch (gc->cap_style) {

  !     case CapNotLast:

  !     case CapButt:

  ! style |= PS_ENDCAP_FLAT; 

  ! break;

  !     case CapRound:

  ! style |= PS_ENDCAP_ROUND; 

  ! break;

  !     default:

  ! style |= PS_ENDCAP_SQUARE; 

  ! break;

  ! }

  ! switch (gc->join_style) {

  !     case JoinMiter: 

  ! style |= PS_JOIN_MITER; 

  ! break;

  !     case JoinRound:

  ! style |= PS_JOIN_ROUND; 

  ! break;

  !     default:

  ! style |= PS_JOIN_BEVEL; 

  ! break;

  ! }

  ! pen = ExtCreatePen(style, gc->line_width, &lb, 0, NULL);

  !     } else {

  ! pen = CreatePen(PS_SOLID, gc->line_width, gc->foreground);

  !     }

        RenderObject(dc, gc, points, npoints, mode, pen, Polyline);

        DeleteObject(pen);


  --- 889,895 ----


        dc = TkWinGetDrawableDC(display, d, &state);


  !     pen = SetUpGraphicsPort(gc);

        RenderObject(dc, gc, points, npoints, mode, pen, Polyline);

        DeleteObject(pen);


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

  *** 1009,1015 ****


        dc = TkWinGetDrawableDC(display, d, &state);


  !     pen = CreatePen(PS_SOLID, gc->line_width, gc->foreground);

        oldPen = SelectObject(dc, pen);

        oldBrush = SelectObject(dc, GetStockObject(NULL_BRUSH));

        SetROP2(dc, tkpWinRopModes[gc->function]);

  --- 975,981 ----


        dc = TkWinGetDrawableDC(display, d, &state);


  !     pen = SetUpGraphicsPort(gc);

        oldPen = SelectObject(dc, pen);

        oldBrush = SelectObject(dc, GetStockObject(NULL_BRUSH));

        SetROP2(dc, tkpWinRopModes[gc->function]);

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

  *** 1171,1177 ****

         * difference in pixel definitions between X and Windows.

         */


  !     pen = CreatePen(PS_SOLID, gc->line_width, gc->foreground);

        oldPen = SelectObject(dc, pen);

        if (!fill) {

    /*

  --- 1137,1143 ----

         * difference in pixel definitions between X and Windows.

         */


  !     pen = SetUpGraphicsPort(gc);

        oldPen = SelectObject(dc, pen);

        if (!fill) {

    /*

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

  *** 1193,1198 ****

  --- 1159,1253 ----

        }

        DeleteObject(SelectObject(dc, oldPen));

        TkWinReleaseDrawableDC(d, dc, &state);

  + }

  + 

  + /*

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

  +  *

  +  * SetUpGraphicsPort --

  +  *

  +  *Set up the graphics port from the given GC.

  +  *

  +  * Results:

  +  *None.

  +  *

  +  * Side effects:

  +  *The current port is adjusted.

  +  *

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

  +  */

  + 

  + static HPEN

  + SetUpGraphicsPort(gc)

  +     GC gc;

  + {

  +     DWORD style;

  + 

  +     if (gc->line_style == LineOnOffDash) {

  + unsigned char *p = (unsigned char *) &(gc->dashes);

  + /* pointer to the dash-list */

  + 

  + /*

  +  * Below is a simple translation of serveral dash patterns

  +  * to valid windows pen types. Far from complete,

  +  * but I don't know how to do it better.

  +  * Any ideas: <mailto:Jan.Nijtmans@wxs.nl>

  +  */

  + 

  + if (p[1] && p[2]) {

  +     if (!p[3] || p[4]) {

  + style = PS_DASHDOTDOT;/*-..*/

  +     } else {

  + style = PS_DASHDOT;/*-.*/

  +     }

  + } else {

  +     if (p[0] > (4 * gc->line_width)) {

  + style = PS_DASH;/*-*/

  +     } else {

  + style = PS_DOT;/*.*/

  +     }

  + }

  +     } else {

  + style = PS_SOLID;

  +     }

  +     if (tkpIsWin32s || (gc->line_width < 2)) {

  + if (gc->line_width > 1) {

  +     style = PS_SOLID;

  + }

  + return CreatePen(style, gc->line_width, gc->foreground);

  +     } else {

  + LOGBRUSH lb;

  + 

  + lb.lbStyle = BS_SOLID;

  + lb.lbColor = gc->foreground;

  + lb.lbHatch = 0;

  + 

  + style |= PS_GEOMETRIC;

  + switch (gc->cap_style) {

  +     case CapNotLast:

  +     case CapButt:

  + style |= PS_ENDCAP_FLAT; 

  + break;

  +     case CapRound:

  + style |= PS_ENDCAP_ROUND; 

  + break;

  +     default:

  + style |= PS_ENDCAP_SQUARE; 

  + break;

  + }

  + switch (gc->join_style) {

  +     case JoinMiter: 

  + style |= PS_JOIN_MITER; 

  + break;

  +     case JoinRound:

  + style |= PS_JOIN_ROUND; 

  + break;

  +     default:

  + style |= PS_JOIN_BEVEL; 

  + break;

  + }

  + return ExtCreatePen(style, gc->line_width, &lb, 0, NULL);

  +     }

    }

    

    /*

  *** xlib/xgc.c.origFri Apr 16 23:03:05 1999

  --- xlib/xgc.cSat May 29 00:02:34 1999

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

  *** 46,52 ****

    {

        GC gp;


  !     gp = (XGCValues *)ckalloc(sizeof(XGCValues));

        if (!gp) {

    return None;

        }

  --- 46,60 ----

    {

        GC gp;


  ! /*

  !  * In order to have room for a dash list, MAX_DASH_LIST_SIZE extra chars are

  !  * defined, which is invisible from the outside. The list is assumed to end

  !  * with a 0-char, so this must be set explicitely during initialization.

  !  */

  ! 

  ! #define MAX_DASH_LIST_SIZE 10

  ! 

  !     gp = (XGCValues *)ckalloc(sizeof(XGCValues) + MAX_DASH_LIST_SIZE);

        if (!gp) {

    return None;

        }

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

  *** 73,78 ****

  --- 81,87 ----

        gp->clip_y_origin = (mask & GCClipYOrigin)?values->clip_y_origin:0;

        gp->dash_offset = (mask & GCDashOffset)?values->dash_offset:0;

        gp->dashes = (mask & GCDashList)?values->dashes:4;

  +     (&(gp->dashes))[1] = 0;


        if (mask & GCClipMask) {

    gp->clip_mask = (Pixmap)ckalloc(sizeof(TkpClipMask));

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

  *** 131,137 ****

        if (mask & GCClipYOrigin) { gc->clip_y_origin = values->clip_y_origin; }

        if (mask & GCClipMask) { XSetClipMask(d, gc, values->clip_mask); }

        if (mask & GCDashOffset) { gc->dash_offset = values->dash_offset; }

  !     if (mask & GCDashList) { gc->dashes = values->dashes; }

    }

    

    /*

  --- 140,146 ----

        if (mask & GCClipYOrigin) { gc->clip_y_origin = values->clip_y_origin; }

        if (mask & GCClipMask) { XSetClipMask(d, gc, values->clip_mask); }

        if (mask & GCDashOffset) { gc->dash_offset = values->dash_offset; }

  !     if (mask & GCDashList) { gc->dashes = values->dashes; (&(gc->dashes))[1] = 0;}

    }

    

    /*

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

  *** 198,203 ****

  --- 207,230 ----

    }


    void

  + XSetDashes(display, gc, dash_offset, dash_list, n)

  +     Display* display;

  +     GC gc;

  +     int dash_offset;

  +     _Xconst char* dash_list;

  +     int n;

  + {

  +     char *p = &(gc->dashes);

  + 

  +     gc->dash_offset = dash_offset;

  +     if (n > MAX_DASH_LIST_SIZE) n = MAX_DASH_LIST_SIZE;

  +     while (n-- > 0) {

  + *p++ = *dash_list++;

  +     }

  +     *p = 0;

  + }

  + 

  + void

    XSetFunction(display, gc, function)

        Display *display;

        GC gc;


  PatchFiles:

  tkInt.decls tkWinDraw.c xgc.c




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


tkt_uuid: 2128972fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 75. wish
priority: 7 High
foundin: obsolete: 8.5.4
resolution: None
title: wish 8.5.4 core dump
comment:
  platform: sparc solaris 9
  tcl/tk: 8.5.4

  A developer emailed me today, asking why their tcl application was core dumping.  I stopped by, and here is what I found.

  The application - assignee_edit - a purely tcl script - began:

  #! /vol/tclsrcsol/tcl85test/bin/wish8.5 -f

  :tk and tcl code

  The core file says:
  dbx /vol/tclsrcsol/tcl85test/bin/wish8.5 core 
  For information about new features see `help changes'
  To remove this message, put `dbxenv suppress_startup_message 7.0' in your .dbxrc 
  Reading wish8.5
  dbx: core object name "assignee_edit" doesn't match object name "wish8.5"
  core file ignored. 
  Use -f to force loading of corefile
  :
  :
  So, I typed:
  $ dbx -f /vol/tclsrcsol/tcl85test/bin/wish8.5 core 
  For information about new features see `help changes'
  To remove this message, put `dbxenv suppress_startup_message 7.0' in your .dbxrc 
  Reading wish8.5 core file 
  header read successfully 
  Reading ld.so.1 
  Reading libtk8.5.so 
  Reading libtcl8.5.so 
  Reading libX11.so.4 
  Reading libXext.so.0 
  Reading libdl.so.1 
  Reading libsocket.so.1 
  Reading libnsl.so.1 
  Reading libm.so.1 
  Reading libc.so.1 
  Reading libmp.so.2 
  Reading libc_psr.so.1 
  Reading libtclx8.4.so 
  Reading libOratcl4.4.so 
  Reading libclntsh.so.9.0 
  Reading libwtc9.so 
  Reading libgen.so.1 
  Reading libsched.so.1 
  Reading libaio.so.1 
  Reading librt.so.1 
  Reading libmd5.so.1 
  Reading libmd5_psr.so.1 
  program terminated by signal SEGV (no mapping at the fault address) 
  Current function is Tcl_NextHashEntry
    587           if (searchPtr->nextIndex >= tablePtr->numBuckets) {
  (dbx) where
  =>[1] Tcl_NextHashEntry(searchPtr = 0xffbfdc68), line 587 in "tclHash.c"
    [2] Tcl_FirstHashEntry(tablePtr = (nil), searchPtr = 0xffbfdc68), line 553 in "tclHash.c"
    [3] Oratcl_Clean(clientData = 0x6a478), line 217 in "oratcl.c"
    [4] Oratcl_Exit(clientData = 0x6a478), line 274 in "oratcl.c"
    [5] Tcl_Finalize(), line 949 in "tclEvent.c"
    [6] Tcl_Exit(status = 0), line 828 in "tclEvent.c"
    [7] Tk_MainEx(argc = -1, argv = 0xffbfe0f0, appInitProc = 0x114c8 = &Tcl_AppInit(Tcl_Interp *interp), interp = 0x2abc0), line 325 in "tkMain.c"
    [8] main(argc = 3, argv = 0xffbfe0e4), line 68 in "tkAppInit.c"

  Now, looking at the stack trace, one might think "hmm, probably an Oratcl error".

  Here's the kicker.

  For grins, I changed the script to read:

  #! /vol/tclsrcsol/tcl85test/bin/tclsh8.5

  package require Tk

  and now the program does not generate the core dump.

  Also, I have written the script:

  #! /vol/tclsrcsol/tcl85test/bin/wish8.5 -f
  pack [button .quit -text Quit -command exit}

  and it runs without a core dump, so it doesn't seem like the length of the magic line is the issue.


tkt_uuid: 220311ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 57. [option]
priority: 1 Zero
foundin: None
resolution: Invalid
title: option clear command apparently reads the ~/.Xdefaults file
comment:
  OriginalBugID: 5963 Bug
  Version: 8.3
  SubmitDate: '2000-06-29'
  LastModified: '2000-08-14'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows NT
  Machine: Dell OptiPlex GX1
  ClosedDate: '2000-08-14'


  Name:
  Allen Flick

  Comments:
  Although, in my example under Windows, TclTk is accessing the
      ~/.Xdefaults file, which is a Unix
      thing, I'd like to see it remain in future releases.  This would make Tk
      truly platform independent,
      and if Tk under Unix accesses this file a second time (since X does it
      in Unix) and that's deemed
      to be a problem for some reason, it wouldn't be too hard to check the
      platform type.  That's built
      right into TclTk anyway.

  ReproducibleScript:
  Within a *wish8.3*, at the console.

  % pack [button .b1 -text Button1]
  % pack [button .b2 -text Button2 -bg red]
  % pack [button .b3 -text Button3]
  % option add *Button.background blue
  % option add *Button.foreground yellow
  % pack [button .b4 -text Button4]
  % option clear
  % pack [button .b5 -text Button5]
  % option clear

  At this point I had to rename my ~/.Xdefaults file, so it wouldn't be reread.

  % pack [button .b6 -text Button6]
  % pack [button .b7 -text Button7]
  % option clear
  % pack [button .b8 -text Button8]
  %

  ObservedBehavior:
  After each *option clear* command, the default background was apparently taken from the
  ~/.Xdefaults file, as it was always reset to cyan except for the one time I renamed the
  ~/.Xdefaults file, temporarily.

  DesiredBehavior:
  I would expect to see the option database all cleared as manual states, and if
  the ~/.Xdefaults file is to be accessed as described in the manual (for Unix)
  then it do so as the manual states, the *next* time the database is accessed.



  The option database is implicitly accessed whenever a widget is created.  The behavior you are seeing is therefore consistent with the documentation:  [option clear] clears the database, and the next time the database is accessed (when the next widget is created), .Xdefaults is reread.

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

  -- 08/14/2000 ericm


tkt_uuid: 1845066fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 5 Medium
foundin: obsolete: 8.5b3
resolution: Invalid
title: grumpy "package require"
comment:
  Current version unnecessarily treats an *existing* different version of any package as error. I'll describe the thing using sqlite3 module as example:

  In Tcl8.4, when I requested sqlite3 package:

  tclsh8.4 [~]catch {package require sqlite3} errmsg

  attempt to provide package sqlite3 3.3 failed: package sqlite3 3.4.2 provided instead
  0
     
  ...and it was OK. Although it didn't find version 3.3 - a newer version has been found instead, so the result message "OK" (0) was quite proper.

  And now, while using 8.5b3:

  tclsh8.5 [~]catch {package require sqlite3} errmsg
  1
     
  No, it shouldn't be so, I suppose. When I'm not using "catch", it can find the package anyway:

  tclsh8.5 [~]package require sqlite3
  attempt to provide package sqlite3 3.3 failed: package sqlite3 3.4.2 provided instead
    while evaluating {package require sqlite3}

  (...of course, I realize, the package has been
  found while using "catch" too).

  What I have in mind, that it shouldn't be reported as error (1) - because I didn't specified an exact version; just wrote: "load any available sqlite3 package", what has been done. So, why error? The "difference in version" has been already reported by a warning message (and it's quite enough) - but as long, as sqlite3 module can be loaded, it shouldn't be treated as "package require error".

  Yes, I know: there's a need to make a little change pkgIndex.tcl - but why "package require" has been made so grumpy in 8.5, while its functionality in 8.4 was logical? "No (real) error - no `1' in output when catch-ing". Because version difference - noticed in pkgIndex - isn't, in fact, any real error (package has been found and loaded, anyway), and message "other version provided instead" is quite enough in such case.


tkt_uuid: 220537ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: tk_messageBox -icon incorrect behavior
comment:
  OriginalBugID: 2219 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-15'
  LastModified: '2000-06-26'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 2218 2690
  OS: All
  Machine: X86
  FixedDate: '2000-06-26'
  FixedInVersion: 8.4a2


  Name:
  Christopher Nelson

  ObservedBehavior:
  The help for tk_messageBox says that there isn't an icon if none is
      specified.  At least on Windoze 98, the default icon is info if none is
      specified.



  The documentation has been corrected to state that the default icon is info if none is specified.  This fix will be in 8.4a2.

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

  -- 06/26/2000 ericm


tkt_uuid: 2931538fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 7 High
foundin: obsolete: 8.5.8
resolution: Wont Fix
title: TkAqua MouseWheel wrong delta step size
comment:
  The delta value %D for MouseWheel events on in TkAqua is 1 or -1 or small integers.
  On Mac X11, Linux and Windows the delta value is 120 or -120 or small multiples of these.
  This means any MouseWheel tcl code has to be special-cased for TkAqua.  I believe the 120
  value is intended to allow future mouse wheel devices that provide finer granularity.

  The TkAqua MouseWheel events should produce 120 and -120 delta values to avoid special-case
  code in applications.  Maybe this change could be introduced into the new TkAqua 8.6 Cocoa
  implementation.

  Use the following Wish script to see the delta values produced by mouse wheel events:

  bind . <MouseWheel> { puts %D }


tkt_uuid: 1774593fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 9 Immediate
foundin: obsolete: 8.5.0
resolution: Fixed
title: Transparent items bindings undocumented (but very useful)
comment:
  Some canvas items can be invisible (using color "") and yet fire scripts bound to <Enter>, <Leave> etc. This is very useful but undocumented and therefore programmers have no guarantee that related features will stay as they are.

  For example, to create active rectangle area, several solutions come to mind and only experiments can determine  which one works and which does not:

  - rectangle item
  - very thick line
  - polygon

  (polygon and thick line work, while rectangle item reacts only by its outline)

  Fortunately, TIP46 withdrawal notice might serve as a precedens case, indicating that current invisible items behavior is intentional and will be kept as it is, however documenting it in the canvas man page would be much better.


tkt_uuid: 579885ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: Add _MOTIF_WM_HINTS support
comment:
  Tk should support setting the _MOTIF_WM_HINTS property
  as part of [wm attributes] on Unix/X; IIRC many window
  managers (aside from mwm and dtwm/CDE) support this
  nowadays as a way of getting client-specified styles
  going, and the structure is easy enough to figure out
  given a set of Motif header files.

  (submitted so the idea doesn't get lost.)


tkt_uuid: 220222ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Flash cursor uses excess CPU in text widget
comment:
  OriginalBugID: 2573 Bug
  Version: 8.1.1
  SubmitDate: '1999-08-18'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: 6.0 of client, 4.0 for server
  Machine: Other
  ClosedDate: '1999-08-20'


  Name:
  D. Richard Hipp

  Comments:
  Same problem seen on Tk8.0.4 and Tk8.1.1.  Didn't try any others.

  ReproducibleScript:
  text .t -yscrollcommand {.sb set} -height 50 -width 80
      scrollbar .sb -command {.t yview}
      pack .t -side left -fill both -expand 1
      pack .sb -side left -fill y
      .t insert end {This is sample text
      for a test script for a Scriptics
      bug report}
      for {set i 0} {$i<1000} {incr i} {
        .t insert end "This is line $i\n"
      }
      .t mark set insert {2.0 lineend}
      after idle {focus .t}
      
      
      Run the script above.  Scroll down so the insertion cursor is off the
      top
      of the page, and watch the CPU load jump.  Remove focus from the text
      widget (so that insert cursor stops flashing) and the CPU load goes
      away.  Scroll the text widget so the insertion cursor is visible again
      and the CPU load goes away.

  ObservedBehavior:
  When a text widget has focus and the insertion cursor is flashing,
      but the insertion cursor is not visible because it has been scrolled
      off the screen, then the cursor-flashing logic causes the X-server
      on a 200MHz PPro to use about 25% of its cycles to flash the (invisible)
      cursor.  Notes:  The Tcl script is running on a 500MHz PIII Xeon (RedHat
      6.0)
      but is being displayed on the 200MHz PPro (RedHat 4.0).  The CPU load is
      on the PPro.  The "wish" process is not using any measureable amount
      of CPU time.
      
      I also tried this on a VNC X-server (version 3.3) running on the 500MHz
      PIII.
      "top" reports a 11% CPU load by the VNC X-server when the cursor is 
      flashing off-screen.

  DesiredBehavior:
  When the insertion cursor is not visible, I would expect that no
      drawing traffic would be sent to the X-server at all.



  I cannot reproduce this at all for 8.2.0 on Solaris.  This might
  be an X server issue, but the above causes no CPU spiking whatsoever
  for NT or Solaris. 
  -- 08/20/1999 hobbs


tkt_uuid: 220527ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: font configure gives wrong error message when params are missing
comment:
  OriginalBugID: 2075 Bug
  Version: 8.1
  SubmitDate: '1999-05-14'
  LastModified: '1999-09-16'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux-Red Hat
  Machine: Other
  FixedDate: '1999-09-16'
  FixedInVersion: 8.2.1


  Name:
  Geoff Pike

  ReproducibleScript:
  Try this under unix (I'm using Redhat Linux 5.1):
      
      echo "font create f; font config f -size 12 -family" | wish8.0
      echo "font create f; font config f -size 12 -family" | wish8.1

  ObservedBehavior:
  Tk8.0 correctly complains that the family parameter is missing.  
      Tk8.1 complains that the size parameter is missing.


tkt_uuid: 438247ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Fixed
title: tk_getSaveFile causes [mc] error
comment:
  The following script:

     % set tk_strictMotif 1
     1
     % tk_getSaveFile

  Leads to the following error when an existing file is selected and OK clicked:

    not enough arguments for all format specifiers
    not enough arguments for all format specifiers
        while executing
    "format %s%s  [::msgcat::mc {File "%1$s" already exists.\n\n}  $selectFilePath ]"
        (procedure "tkMotifFDialog_ActivateSEnt" line 39)
        invoked from within
    "tkMotifFDialog_ActivateSEnt $w"
        (procedure "tkMotifFDialog_OkCmd" line 4)
        invoked from within
    "tkMotifFDialog_OkCmd .__tk_filedialog"
        invoked from within
    ".__tk_filedialog.bot.ok invoke"
        ("uplevel" body line 1)
        invoked from within
    "uplevel #0 [list $w invoke]"
        (procedure "tkButtonUp" line 25)
        invoked from within
    "tkButtonUp .__tk_filedialog.bot.ok
    "
        (command bound to event)


tkt_uuid: 220887ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.2.2
resolution: None
title: Popup-menus may fail if using threads
comment:
  OriginalBugID: 3921 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-22'
  LastModified: '2000-01-25'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT4.0 ServicePack6
  Machine: intel PC


  Name:

  Dr. Lukas Rosenthaler


  Extensions:

  img1.2, incr tcl


  CustomShell:

  with exception of patch above no other


  Comments:

  The cause of the problem is as follows:


  The window for the popup menu is initialized in TkpMenuInit. The window handle is stored in a

  thread specific data area (using Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData)); ).

  If the thread exits, the thread specific data is lost, and so the popup menu's window handle. However,

  starting a new thread doesn't invoke TkpMenuInit anymore. Then the WIN32-function 

  TrackPopupMenu (called from within TkpPostMenu) receives an invalid window handle and

  returns immediately (The new, patched version will check the return value of TrackPopupMenu

  and issue an error, if something's wrong).


  Solution to the Problem:


  The code to create the popup menu's window has been moved to TkpMenuThreadInit. Within

  TkpMenuThreadInit, an exit-handler using  "Tcl_CreateThreadExitHandler(MenuExitHandler,

  (ClientData) NULL);" has been added to destroy the menu-window if the thread exits.


  Tests (all compiled with "/DTCL_THREADS=1" !) have shown no side-effects of this patch.


  ReproducibleScript:

  Embedded Tcl/Tk in a threaded environment. The application (using it's own non-tcl windows based

  event loop) launches Tcl/Tk-threads which have their own toplevel windows and own event loops.


  ObservedBehavior:

  When using threads, the popup of menus doesn't work properly. The first time a thread is invoked,

  popup menus work fine, but if the first thread exits using Tcl_ThreadExit (0), and later a second thread

  is invoked, then the popup menus don't work anymore.


  DesiredBehavior:

  popup menu should work properly...


  Patch:

  *** tkWinMenu-orig.cWed Sep 22 08:53:24 1999

  --- tkWinMenu.cWed Dec 22 11:54:24 1999

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

  *** 778,785 ****

    }

        }


  !     TrackPopupMenu(winMenuHdl, flags, x, y, 0, 

  !     tsdPtr->menuHWND, &noGoawayRect);

        Tcl_SetServiceMode(oldServiceMode);


        GetCursorPos(&point);

  --- 778,794 ----

    }

        }


  !     if (TrackPopupMenu(winMenuHdl, flags, x, y, 0, 

  !        tsdPtr->menuHWND, &noGoawayRect) == 0) {

  !       LPVOID lpMsgBuf;

  !       char errstr[1024];

  !       FormatMessage (FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,

  !      NULL, GetLastError (), MAKELANGID (LANG_NEUTRAL, SUBLANG_DEFAULT),

  !      (LPTSTR) &lpMsgBuf, 0, NULL);

  !       sprintf (errstr, "[%s: #%04d] ERROR: TrackPopupMenu failed!\n%s",

  !        __FILE__, __LINE__, (char *) lpMsgBuf);

  !       MessageBox (NULL, errstr, "Tk Internal Error", MB_OK | MB_ICONERROR);

  !     }

        Tcl_SetServiceMode(oldServiceMode);


        GetCursorPos(&point);

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

  *** 2789,2814 ****

    void

    TkpMenuInit()

    {

  -     WNDCLASS wndClass;

  -     ThreadSpecificData *tsdPtr = (ThreadSpecificData *) 

  -             Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));


  -     wndClass.style = CS_OWNDC;

  -     wndClass.lpfnWndProc = TkWinMenuProc;

  -     wndClass.cbClsExtra = 0;

  -     wndClass.cbWndExtra = 0;

  -     wndClass.hInstance = Tk_GetHINSTANCE();

  -     wndClass.hIcon = NULL;

  -     wndClass.hCursor = NULL;

  -     wndClass.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);

  -     wndClass.lpszMenuName = NULL;

  -     wndClass.lpszClassName = MENU_CLASS_NAME;

  -     RegisterClass(&wndClass);

  - 

  -     tsdPtr->menuHWND = CreateWindow(MENU_CLASS_NAME, "MenuWindow", WS_POPUP,

  - 0, 0, 10, 10, NULL, NULL, Tk_GetHINSTANCE(), NULL);

  - 

  -     Tcl_CreateExitHandler(MenuExitHandler, (ClientData) NULL);

        SetDefaults(1);

    }

    

  --- 2798,2804 ----

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

  *** 2831,2838 ****

  --- 2821,2848 ----

    void

    TkpMenuThreadInit()

    {

  +     WNDCLASS wndClass;

        ThreadSpecificData *tsdPtr = (ThreadSpecificData *) 

                Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));

  + 

  + 

  +     wndClass.style = CS_OWNDC;

  +     wndClass.lpfnWndProc = TkWinMenuProc;

  +     wndClass.cbClsExtra = 0;

  +     wndClass.cbWndExtra = 0;

  +     wndClass.hInstance = Tk_GetHINSTANCE();

  +     wndClass.hIcon = NULL;

  +     wndClass.hCursor = NULL;

  +     wndClass.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);

  +     wndClass.lpszMenuName = NULL;

  +     wndClass.lpszClassName = MENU_CLASS_NAME;

  +     RegisterClass(&wndClass);

  + 

  +     tsdPtr->menuHWND = CreateWindow(MENU_CLASS_NAME, "MenuWindow", WS_POPUP,

  + 0, 0, 10, 10, NULL, NULL, Tk_GetHINSTANCE(), NULL);

  + 

  +     Tcl_CreateThreadExitHandler(MenuExitHandler, (ClientData) NULL);

  +     SetDefaults(0);


        Tcl_InitHashTable(&tsdPtr->winMenuTable, TCL_ONE_WORD_KEYS);

        Tcl_InitHashTable(&tsdPtr->commandTable, TCL_ONE_WORD_KEYS);


  PatchFiles:

  tkWinMenu.c


tkt_uuid: 479098ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Invalid
title: latest tk from cvs crashes w/tkchat
comment:
  Platform: SPARC Solaris 2.6 Sun compiler and tcl/tk
  8.4a4 from nov 5 snapshot tar file of andreas kupries.

  attempts to invoke tkchat (from the tcllib project)
  results in the error:
  Tk_FreeGC received unknown gc argument
  Abort(coredump)
  when hitting the update idletasks in errLog .  The
  stack for this is:

  $ dbx $(whence wish8.4) core
  Reading wish8.4
  core file header read successfully
  Reading ld.so.1
  Reading libtk8.4.so
  Reading libtcl8.4.so
  Reading libsocket.so.1
  Reading libnsl.so.1
  Reading libX11.so.4
  Reading libdl.so.1
  Reading libm.so.1
  Reading libc.so.1
  Reading libmp.so.2
  Reading libXext.so.0
  Reading libdga.so.1
  Reading libc_psr.so.1
  program terminated by signal ABRT (Abort)
  (dbx 1)
  where                                                  
  =>[1] _kill(0x0, 0x6, 0x0, 0xffffffff, 0xfef3c404,
  0xfeeb5690), at 0xfef1ba28
    [2] abort(0xfef3800c, 0xffbebc20, 0xff22f57c, 0x0,
  0x1, 0x8), at 0xfeeb5774
    [3] Tcl_Panic(0xff340a80, 0x20, 0x0, 0x20,
  0xffbebbcc, 0x39580), at 0xff1f4348
    [4] Tk_FreeGC(0x0, 0x20, 0xff3564c8, 0x120c20,
  0x1181b0, 0x1181b0), at 0xff2b5db8
    [5] TkMenuConfigureEntryDrawOptions(0x0, 0x0, 0x0,
  0x0, 0x0, 0x120ea0), at 0xff2f3cf4
    [6] MenuWorldChanged(0x1, 0x0, 0x117a90, 0x0, 0x0,
  0x0), at 0xff2efe6c
    [7] RecomputeWidgets(0x1181b0, 0xff3564c8, 0x2f928,
  0x4c6a8, 0x0, 0x0), at 0xff2b179c
    [8] RecomputeWidgets(0x1181b0, 0xff3564c8, 0x314,
  0xff374b68, 0x223d8, 0xff203e8c), at 0xff2b17b4
    [9] TclServiceIdle(0x0, 0x1, 0x2cf18, 0x13e9b0, 0x0,
  0x0), at 0xff203e84
    [10] Tcl_DoOneEvent(0x0, 0xff22f57c, 0x22c90, 0x0,
  0x22ca8, 0x1), at 0xff1f269c
    [11] MapFrame(0x4c6a8, 0x4c6a8, 0xff22f57c,
  0xff3903a4, 0xff3e2628, 0xff286fd1), at 0xff2ea724
    [12] TclServiceIdle(0x0, 0x0, 0x2cf18, 0x30550,
  0x13ec20, 0x0), at 0xff203e84
    [13] Tcl_DoOneEvent(0x0, 0x13fdb0, 0x22c90, 0x0,
  0x22ca8, 0x1), at 0xff1f269c
    [14] Tk_UpdateObjCmd(0x2f928, 0x20, 0x2, 0x23c48,
  0x22fe0, 0x22fe0), at 0xff2a97f8
    [15] TclExecuteByteCode(0x23c48, 0xff22f57c,
  0x142d0d, 0x2, 0xc, 0x23c38), at 0xff1ca0f8
    [16] Tcl_EvalObjEx(0xff235df4, 0x0, 0xffbec53c,
  0xff22f57c, 0x1912, 0x22fe0), at 0xff1a6f28
    [17] TclObjInterpProc(0xff21ecc8, 0x4, 0xf3938,
  0xffbec2bc, 0xff22f57c, 0x1), at 0xff1fda34
    [18] TclExecuteByteCode(0x23c40, 0xff22f57c,
  0x1427a1, 0x2, 0x4, 0x23c38), at 0xff1ca0f8
    [19] Tcl_EvalObjEx(0xff235df4, 0x0, 0xffbeca34,
  0xff22f57c, 0x190f, 0x22fe0), at 0xff1a6f28
    [20] TclObjInterpProc(0x1, 0x23b40, 0x10d978,
  0xffbec7b4, 0xff22f57c, 0x0), at 0xff1fda34
    [21] TclExecuteByteCode(0x23c3c, 0xff22f57c,
  0x115a8d, 0x1, 0x0, 0x23c38), at 0xff1ca0f8
    [22] Tcl_EvalObjEx(0xff235df4, 0x0, 0xffbecf2c,
  0xff22f57c, 0x176e, 0x22fe0), at 0xff1a6f28
    [23] TclObjInterpProc(0x6, 0x108e08, 0xdf3c8,
  0xffbeccac, 0xff22f57c, 0x0), at 0xff1fda34
    [24] TclExecuteByteCode(0x23c38, 0xff22f57c,
  0x113f3a, 0x1, 0x0, 0x23c38), at 0xff1ca0f8
    [25] Tcl_EvalObjEx(0x0, 0x0, 0x0, 0xff22f57c, 0x176d,
  0x22fe0), at 0xff1a6f28
    [26] Tcl_IfObjCmd(0x3, 0xff21c4d0, 0x4, 0xffbed3f0,
  0xff21c4c8, 0x0), at 0xff1aead4
    [27] EvalObjv(0x26110, 0x0, 0xb4358, 0x0, 0x0, 0x0),
  at 0xff1f5058
    [28] Tcl_EvalEx(0x22fe0, 0xffbed3f0, 0x1, 0x0,
  0xb4358, 0x34), at 0xff1f5804
    [29] Tcl_FSEvalFile(0x4ca70, 0x0, 0x4bdb8,
  0xff22f57c, 0x1, 0x4be48), at 0xff1e7bac
    [30] Tcl_EvalFile(0x22fe0, 0x4be48, 0x0, 0xff367a00,
  0x1, 0xff3679ec), at 0xff1e6f40
    [31] Tk_MainEx(0xff3679d4, 0x2b260, 0xffbed6f8,
  0x22fe0, 0xff3564c8, 0x10c04), at 0xff2bc7b0
    [32] main(0x2, 0xffbed884, 0x2, 0x20d90, 0x0, 0x0),
  at 0x10be4
  (dbx 2) 


tkt_uuid: 220154ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Invalid
title: "bind . <Configure>" behaves differently accross window managers:
comment:
  OriginalBugID: 1648 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-26'
  LastModified: '1999-04-06'
  Severity: MED
  Status: Closed
  Submitter: admin
  ChangedBy: surles
  OS: Solaris
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-06'


  I ran the following script on solaris, and I got the following
  differring results:

  On openWin:
     A(.) = 0
     A(.) = 3

  On CDE:
     A(.) = 0
     A(.) = 2

  # beginning of script
  bind . <Configure> {incr A(%W)}
  set A(.) 0
  foreach i {0 1 2} {
      frame .$i -width 100 -height 75
      set A(.$i) 0
  }
  puts "A(.) = $A(.)"
  grid .0 .1 .2
  update
  puts "A(.) = $A(.)"
  # end of script


  There is a test in grid.test that is mark with this bugid; ideally it should not be marked nonPortable...
  ---
  This is defined behavior.  The interface between different wm's will always very.  04/06/1999 14:41 - surles -


tkt_uuid: 614474ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: UMR in TextBlinkProc
comment:
  A run through purify spots that certain redraw events 
  (enter?) when the text cursor has been set off the edge of 
  the visible text widget area causes uninitialised accesses to 
  memory. The solution is simply to check the return code of 
  TkTextCharBbox.


tkt_uuid: 3537673fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.5.11
resolution: Wont Fix
title: erroneous png-image on MAC OSX
comment:
  Hello,

  if I create a button with an transparent png-File,
  the image is displayed erroneous in the button.

  MAC OSX (core); tcl/tk 8.5.11; tkimg 1.4

  On other platforms (windows/Linux) the image is shown correct.

  test_icon.png = the button-Image
  screenshot.png = Screenshot of the erroneous image

  Here the test-script:

  toplevel .a
  image create photo bild1 -file test_icon.png
  button .a.b -image bild1
  grid .a.b


  Am i doing something wrong or is there a bug in tkimg on MAC-Platform?

  Thanks for any help!
  Matthias


tkt_uuid: 483836ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Works For Me
title: focus.test focus-5.1 ChangeXFocus fails
comment:
  sparc/sun solaris 2.6/sun c compiler/cde window manager

  focus.test

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

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

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


tkt_uuid: 220432ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Crash on exit due to Tcl_Eval(consoleInterp, "tkConsoleExit");
comment:
  OriginalBugID: 1253 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-22'
  LastModified: '1999-04-05'
  Severity: CRIT
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '2019-06-01'
  FixedInVersion: 8.1b3


  Name:
  Petteri Kettunen

  CVS:
  Yes, February 19, 1999

  Extensions:
  N/A

  CustomShell:
  N/A

  ReproducibleScript:
  Open wish and do some graphics. I loaded some of my own extensions that
  operate on files and used simple routines to plot on canvas. 

  ObservedBehavior:
  When you finish the application by "exit 0" the program crashes. The
  same happens if you shut down the program by mouse.

  DesiredBehavior:
  Clean exit, no crash.

  Patch:
  See 11) below first. This is the patch for 8.1a2 sources, although the same applies to 8.1b1 (tkConsole.c revision 1.3).

  C:\oke\src\pntk>diff tkConsole.c c:\tmp\tkConsole.c
  542,544c542
  <       Tcl_DString dString;
  <
  <       consoleInterp = info->consoleInterp;
  ---
  >         consoleInterp = info->consoleInterp;
  557,561c555
  <
  <       Tcl_DStringInit(&dString);
  <       Tcl_DStringAppend(&dString, "tkConsoleExit", -1);
  <       Tcl_Eval(consoleInterp, Tcl_DStringValue(&dString));
  <       Tcl_DStringFree(&dString);
  ---
  >       Tcl_Eval(consoleInterp, "tkConsoleExit");

  PatchFiles:
  generic/tkConsole.c



  03/26/1999 18:42 - redman - Fixed, applied patch and fixed all other cases in tkConsole.c.  Couldn't find any instances outside of that file (not directly calling Tcl_Eval).

  I found the bug first from 8.1a2 (compiled with the Redmond compiler v.
  6.0). The program crashes in Tcl_ParseCommand (string[numBytes] = 0) and
  the string contains "tkConsoleExit". This comes when Tcl_Eval is called
  from tkConsole.c:

  Tcl_Eval(consoleInterp, "tkConsoleExit");

  Some compilers may store constant string to read-only memory. Hence it
  crashes. This is an old bug that I have seen before many times in my own
  extensions but it is still hidden in your 8.1b1 sources (tkConsole.c
  rev. 1.3).


tkt_uuid: 220940ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 4
foundin: obsolete: 8.4a1
resolution: Fixed
title: test suite corrections
comment:
  OriginalBugID: 6040 RFE
  Version: 8.4a1
  SubmitDate: '2000-07-24'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: All


  Name:

  Don Porter


  DesiredBehavior:

  This patch replaces all instances of


  [load {} tk]


  in Tk's test suite with


  [load {} Tk]


  This makes Tk robust against application

  of my submitted Tcl patch with the 

  synopsis:


  [info loaded] should return real package names.


  Patch:

  Index: tests/focus.test

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

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

  retrieving revision 1.6

  diff -c -r1.6 focus.test

  *** focus.test  2000/05/11 22:36:32     1.6

  --- focus.test  2000/07/22 01:22:33

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

  *** 572,578 ****

        bind all <FocusOut> {lappend x "focus out %W %d"}

        interp create child

        child eval "set argv {-use [winfo id .t.f1]}"

  !     load {} tk child

        child eval {

          entry .e1 -bg lightBlue

          pack .e1

  --- 572,578 ----

        bind all <FocusOut> {lappend x "focus out %W %d"}

        interp create child

        child eval "set argv {-use [winfo id .t.f1]}"

  !     load {} Tk child

        child eval {

          entry .e1 -bg lightBlue

          pack .e1

  Index: tests/macEmbed.test

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

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

  retrieving revision 1.4

  diff -c -r1.4 macEmbed.test

  *** macEmbed.test       1999/04/16 01:51:38     1.4

  --- macEmbed.test       2000/07/22 01:22:33

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

  *** 216,222 ****

        pack .f1 .f2

        interp create child

        child eval "set argv {-use [winfo id .f1]}"

  !     load {} tk child

        child eval {

          . configure -bd 2 -highlightthickness 2 -relief sunken

        }

  --- 216,222 ----

        pack .f1 .f2

        interp create child

        child eval "set argv {-use [winfo id .f1]}"

  !     load {} Tk child

        child eval {

          . configure -bd 2 -highlightthickness 2 -relief sunken

        }

  Index: tests/macMenu.test

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

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

  retrieving revision 1.3

  diff -c -r1.3 macMenu.test

  *** macMenu.test        1999/04/16 01:51:39     1.3

  --- macMenu.test        2000/07/22 01:22:34

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

  *** 852,858 ****

        catch {destroy .m1}

        catch {interp delete testinterp}

        interp create testinterp

  !     load {} tk testinterp

        menu .m1

        . configure -menu .m1

        raise .

  --- 852,858 ----

        catch {destroy .m1}

        catch {interp delete testinterp}

        interp create testinterp

  !     load {} Tk testinterp

        menu .m1

        . configure -menu .m1

        raise .

  Index: tests/menu.test

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

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

  retrieving revision 1.4

  diff -c -r1.4 menu.test

  *** menu.test   2000/05/11 22:37:05     1.4

  --- menu.test   2000/07/22 01:22:35

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

  *** 2300,2306 ****

    test menu-27.1 {GetMenuHashTable} {

        catch {interp destroy testinterp}

        interp create testinterp

  !     load {} tk testinterp

        list [catch {interp eval testinterp {menu .m1}} msg] $msg [interp delete testinterp]

    } {0 .m1 {}}


  --- 2300,2306 ----

    test menu-27.1 {GetMenuHashTable} {

        catch {interp destroy testinterp}

        interp create testinterp

  !     load {} Tk testinterp

        list [catch {interp eval testinterp {menu .m1}} msg] $msg [interp delete testinterp]

    } {0 .m1 {}}


  Index: tests/unixEmbed.test

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

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

  retrieving revision 1.7

  diff -c -r1.7 unixEmbed.test

  *** unixEmbed.test      1999/04/21 21:53:30     1.7

  --- unixEmbed.test      2000/07/22 01:22:35

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

  *** 550,556 ****

        pack .f1 .f2

        interp create child

        child eval "set argv {-use [winfo id .f1]}"

  !     load {} tk child

        child eval {

          . configure -bd 2 -highlightthickness 2 -relief sunken

        }

  --- 550,556 ----

        pack .f1 .f2

        interp create child

        child eval "set argv {-use [winfo id .f1]}"

  !     load {} Tk child

        child eval {

          . configure -bd 2 -highlightthickness 2 -relief sunken

        }

  Index: tests/unixWm.test

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

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

  retrieving revision 1.12

  diff -c -r1.12 unixWm.test

  *** unixWm.test 2000/03/29 00:09:07     1.12

  --- unixWm.test 2000/07/22 01:22:36

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

  *** 1832,1838 ****

        wm geometry .t +0+0

        tkwait visibility .t

        interp create slave

  !     load {} tk slave

        slave eval {wm geometry . 200x200+0+0; tkwait visibility .}

        set result [list [winfo containing 100 100] \

              [slave eval {winfo containing 100 100}]]

  --- 1832,1838 ----

        wm geometry .t +0+0

        tkwait visibility .t

        interp create slave

  !     load {} Tk slave

        slave eval {wm geometry . 200x200+0+0; tkwait visibility .}

        set result [list [winfo containing 100 100] \

              [slave eval {winfo containing 100 100}]]


  PatchFiles:

  tests/focus.test

      tests/macEmbed.test

      tests/macMenu.test

      tests/menu.test

      tests/unixEmbed.test

      tests/unixWm.test


tkt_uuid: 219974ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Duplicate
title: Compile error, and Alt key error on HP-UX
comment:
  OriginalBugID: 1920 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-22'
  LastModified: '1999-08-08'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2425
  OS: HP-UX
  OSVersion: 10
  Machine: Other
  FixedInVersion: 8.2b2
  ClosedDate: '1999-08-08'


  Name:

  Steve Mullerworth



  Extensions:

  None



  CustomShell:

  None



  ReproducibleScript:

  The errors are straightforward bugs



  ObservedBehavior:

  Compiling on HP-UX10:

      There are two compile failures in tk relating to (void) arguments:

      void TkEventInit(void)

      void TkSelGetInProgress(void)cc: 

      The errors are resolved by deleting the void:

      "../generic/tkEvent.c", line 424: error 1705: Function prototypes are an

      ANSI feature.

      

      When creating menus with -underlines, there is a failure when using

      the Alt-<key> to open the menu (line 933 of menu.tcl):

      can't read "i": no such variable

          while executing

      "$child cget $i -state"

          ("Menubutton" arm line 5)

          invoked from within

      "switch [winfo class $child] {

          Menubutton {

      set char2 [string index [$child cget -text]  [$child cget

      -underline]]

                    if {![string co..."

          (procedure "tkMenuFind" line 39)

          invoked from within

      "tkMenuFind $child $char"

          ("default" arm line 2)

          invoked from within

      "switch [winfo class $child] {

          Menubutton {

      set char2 [string index [$child cget -text]  [$child cget

      -underline]]

                    if {![string co..."

          (procedure "tkMenuFind" line 39)

          invoked from within

      "tkMenuFind $child $char"

          ("default" arm line 2)

          invoked from within

      "switch [winfo class $child] {

          Menubutton {

      set char2 [string index [$child cget -text]  [$child cget

      -underline]]

                    if {![string co..."

          (procedure "tkMenuFind" line 39)

          invoked from within

      "tkMenuFind [winfo toplevel $w] $char"

          (procedure "tkTraverseToMenu" line 16)

          invoked from within

      "tkTraverseToMenu . e"

          (command bound to event)





  Fixed in 8.2b2. 
  -- 08/08/1999 hobbs


tkt_uuid: 3410609fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Fixed
title: Keys with AltGr (ISO_Level3_Shift) on Swiss layout => ??
comment:
  Execute:
  setxkbmap ch # or any other method to switch your layout to Swiss
  wish
  % bind . <KeyPress> {puts %K}

  Hit AltGr (likely the key right next to your spacebar, not really sure) + ' = } (or {)

  Output:
  ISO_Level3_Shift
  ?? # should be braceright


tkt_uuid: 220918ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 62. Geometry Functions
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Request for additional public stub entry points
comment:
  OriginalBugID: 5757 RFE
  Version: 8.3.1
  SubmitDate: '2000-05-31'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: All


  Name:
  John Ellson

  DesiredBehavior:
  Request stubs for:
   TkBezierPoints
           TkBezierScreenPoints
           TkMakeBezierCurve
           TkMakeBezierPostscript

  These routines can be reused by alternative line smoothing methods.

  (i.e. Tkspline from http://www.graphviz.org/pub/ )


tkt_uuid: 220066ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Duplicate
title: Test suite failure report
comment:
  OriginalBugID: 4231 Bug
  Version: 8.3
  SubmitDate: '2000-02-23'
  LastModified: '2000-02-25'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2181
  OS: Solaris
  OSVersion: Solaris 2.6
  Machine: UltraSPARC 5
  ClosedDate: '2000-02-25'


  Name:
  Larry W. Virden

  CVS:
  Feb. 23, 2000

  Extensions:
  Tk

  CustomShell:
  I have tcl and tk built with the

  ReproducibleScript:
  configure --prefix=/usr/tcl83
  make all test

  ObservedBehavior:
  choosedir.test
  can't set "err(usage)": variable isn't array
  clipboard.test

  ==== clipboard-6.2 Tk_ClipboardAppend procedure FAILED
  ==== Contents of test case:

      setupbg
      clipboard clear
      clipboard append -f INTEGER -t TEST "16"
      set result [dobg {selection get -s CLIPBOARD TEST}]
      cleanupbg
      set result

  ---- Result was:
  CLIPBOARD selection doesn't exist or form "TEST" not defined
  ---- Result should have been:
  0x10
  ==== clipboard-6.2 FAILED

  clrpick.test
  cmds.test
  color.test
  config.test
  cursor.test
  entry.test
  event.test
  filebox.test
  focus.test

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

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

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

  DesiredBehavior:
  Test suite pass all tests


tkt_uuid: 1844143fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 9 Immediate
foundin: None
resolution: Accepted
title: Danish message catalog
comment:
  Tk does not have a danish message catalog
  in library/msgs. This patch supplies these (see attachted file 'da.msg').


tkt_uuid: 411669ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 6
foundin: obsolete: 8.3.2
resolution: Fixed
title: <hpBackTab> in tk.tcl is fatal on HP-UX
comment:
  This is a re-submit of Tcl bug 232383 from Ken Martch
  (khmartch).  It's a Tk bug, so it belongs here.

  The <hpBackTab> Keysym in tk.tcl in the command
     event add <<PrevWindow>> <hpBackTab>
  causes a stack dump when running wish on HP-UX B.10.20.
  Changing the line to 
     event add <<PrevWindow>> <BackTab>
  allows wish to start without error.  However I have not
  verified if the
  intended function of the Keysym is correct.


tkt_uuid: 607657ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Duplicate
title: Entry validation seg-fault after destroy
comment:
  The following script produces a segmentation fault under Windows 2000,
  when the "-textvariable FOO" is written *after destroying* the entry widget.

  It may be helpful to notice that there is no seg-fault,
  if the windows configuration in the validation procedure is made
  "after idle" (see commented line).

  ######################################
  proc validate {win event val} {
      set ok [expr {[string length $val] < 8}]
  #    after idle [list $win configure -bg [expr {$ok ? "white" : "yellow"}] ]
      $win configure -bg [expr {$ok ? "white" : "yellow"}]
      set ok
  }
  proc fooWin {} {
      toplevel .t
      entry .t.e1 -textvariable FOO -validate all -vcmd {validate %W %V %P}
      pack .t.e1
      focus .t.e1
  }

  set FOO "foo1"
  fooWin

  after 3000 {destroy .t}
  after 5000 {set FOO "hallo"}
  ######################################


tkt_uuid: 3028365fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: Default LIBDIR not on Tk's auto_path
comment:
  Having recently bought a new computer, I've had to recompile a number of packages. In doing so, I've noticed that TEA seems default to putting things in /usr/local/lib, which I suppose makes sense. The problem is however that this directory doesn't appear on Wish's auto_path:

  % info patchlevel
  8.6b1.2
  % set auto_path
  /Library/Frameworks/Tcl.framework/Versions/8.6/Resources/Scripts /Library/Frameworks/Tcl.framework/Versions/8.6/Resources /usr/local/bin/../../../Library/Frameworks/Tk.framework/Versions/8.6/Resources/Wish.app/Contents/lib ~/Library/Tcl /Library/Tcl /System/Library/Tcl ~/Library/Frameworks /Library/Frameworks /System/Library/Frameworks /Library/Frameworks/Tk.framework/Versions/8.6/Resources/Scripts /Library/Frameworks/Tk.framework/Versions/8.6/Resources/Scripts/ttk
  % info nameofexecutable
  /usr/local/bin/../../../Library/Frameworks/Tk.framework/Versions/8.6/Resources/Wish.app/Contents/MacOS/Wish

  I suppose the problem surfaces for wish but not for tclsh because the actual wish executable isn't locaed in /usr/local/bin, whereas tclsh gets its /usr/local item on auto_path from [info nameofexecutable]; for tclsh the corresponding results are:

  % info patchlevel
  8.6b1.2
  % set auto_path
  /Library/Frameworks/Tcl.framework/Versions/8.6/Resources/Scripts /Library/Frameworks/Tcl.framework/Versions/8.6/Resources /usr/local/lib ~/Library/Tcl /Library/Tcl /System/Library/Tcl ~/Library/Frameworks /Library/Frameworks /System/Library/Frameworks
  % info nameofexecutable
  /usr/local/bin/tclsh8.6

  I'm not sure how best to proceed. It would be nice if TEA could rather default to have at least platform-independent files in /Library/Tcl on MacOSX, but perhaps the more pragmatic approach is to ensure Wish is looking in /usr as well.


tkt_uuid: 1038905fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: text.n: unknown characters
comment:
  Tk: v8.5a2 HEAD at 01-10-04
  OS: WinXPsp2
  Built with makefile.vc using VC7

  The following two warnings occur while building the 
  helpfile:-

  Pass 2 -- D:/src_tk/win/../doc/text.n
  Unknown character: \s
  Unknown character: \{

  The attached patch fixes these typos.


tkt_uuid: 2883712fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: ttk::scale and ::progressbar display broken (OS X + x86_64)
comment:
  Running 64-bit, these two widgets don't update their controls: scale is pinned to the left and progressbar never progresses. This behavior happens on the default 10.6 Tk (8.5.7) and git://github.com/das/tcltk.git (de-carbon-8-5), which I gathered is nearly identical to the version included with 10.6.

  Issue looks like it's here at ttkMacOSXTheme.c:579:

      factor = ((double)(LONG_MAX>>1))/(to - from);

  and ttkMacOSXTheme.c:691:

      factor = ((double)(LONG_MAX>>1))/maximum;

  factor then is used to scale min/max/value parameters for HIThemeTrackDrawInfo fields that are typed SInt32. On 64-bit arch, the factor is much larger than SInt32 can represent for many "normal" min/max pairs, which on casting pins min, max, and value to INT_MIN. As a result the controls never update. 

  Suggested solutions: (1) hardcode a static 32-bit max constant in place of LONG_MAX or (2) add __LP64__ ifdef switch to use INT_MAX on 64-bit instead.

  Making such a change restores the ttk::scale and ::progressbar behavior.


tkt_uuid: 2491235fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: None
resolution: Rejected
title: Dictionary's man page [dict] needs better examples
comment:
  I noticed that the man page is very clear about how to insert elements into the dictionary, but it's not clear enough about how to access a whole entry, or how to delete it. In the example, it's also only mentioned how to to insert elements into a nested array, whereas it would be also nice to learn how to insert a single element into an array.


tkt_uuid: 583691ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: Incorrect focus ring under windows...
comment:
  Hi all,

  There seems that the focus ring in checkbuttons and radiobuttons is wrongly
  calculated, if these widgets are displaying an image and a label at the
  same time. Submitted a small script that displays the problem...

  George


tkt_uuid: 220880ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 4
foundin: obsolete: 8.2.2
resolution: Out of Date
title: test suite failures in focus & unixSelect on solaris 2.7
comment:
  OriginalBugID: 3550 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-11'
  LastModified: '1999-11-23'
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: jenn
  OS: Solaris
  OSVersion: SunOS 5.7


  Name:
  Don Porter

  Comments:
  window manager is olwm

  ObservedBehavior:
  $ make test
  ...
  ==== focus-5.1 ChangeXFocus procedure, don't take focus unless have it FAILED
  ---- Result was:
  .t .t {}
  ---- Result should have been:
  .t {} {}
  ==== focus-5.1 FAILED
  ...
  ==== unixSelect-1.5 TkSelGetSelection procedure: INCR i18n text, iso2022 FAILED
  ---- Result was:
  selection owner didn't respond {COMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000 3999 COMPOUND_TEXT 7998 4000 COMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000 3998}
  ---- Result should have been:
  1 8000 8002 {COMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000 3999 COMPOUND_TEXT 7998 4000 COMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000 3998 COMPOUND_TEXT 7997 4000}
  ==== unixSelect-1.5 FAILED

  DesiredBehavior:
  all tests pass


tkt_uuid: 220164ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_CreateTimerHandler API
comment:
  OriginalBugID: 1858 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-28'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: kenj
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-28'




  04/28/1999 14:00 - kenj - Former Tk function now incorporated in Tcl. Tcl API documented in the Tcl man pages. Tk usage deprecated.


tkt_uuid: 1883850fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: xptheme appearance on Vista
comment:
  USCode reports on c.l.t:

  I've been using Vista for a few months now and have noticed a few cosmetic differences.  I have a Vista machine on my left and an XP machine on my right so it's easy to compare.

  What I've noticed so far:

  - Combobox: When the box is 'readonly' (not enterable, user must select from defined list) the box assumes a different shape and color/texture altogether.

  - Indeterminate progress bar - the indeterminate indicator is wider and sort of fuzzed out on the ends.


tkt_uuid: 219975ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: Canvas image size limits
comment:
  OriginalBugID: 1926 Bug
  Version: 8.0.3
  SubmitDate: '1999-04-23'
  LastModified: '1999-10-22'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2964
  OS: Windows 98
  Machine: X86
  ClosedDate: '1999-10-22'


  Name:
  Christophe Odet

  ReproducibleScript:
  simply run this with wish80
      
          canvas .c -height 4000 -width 4000
          pack .c
          image create photo im -width 2047 -height 2040
          .c create image 0 0 -image im -anchor nw

  ObservedBehavior:
  When trying this little piece of tcl/tk 8.0.3, all is right:
      
          canvas .c -height 4000 -width 4000
          pack .c
          image create photo im -width 2047 -height 2039
          .c create image 0 0 -image im -anchor nw
      
      But when I change image size like in
      
          canvas .c -height 4000 -width 4000
          pack .c
          image create photo im -width 2047 -height 2040
          .c create image 0 0 -image im -anchor nw
      
      or in  (small changes !)
      
          canvas .c -height 4000 -width 4000
          pack .c
          image create photo im -width 2048 -height 2039
          .c create image 0 0 -image im -anchor nw
      
      IT CRASHES in tk80.dll on my PC Dell Dimension XPS R450 256 Mo Win98
      with tcl8.0.3.
      
      Stack trace:
      
      WISH80 a causé une défaillance de page dans
       le module TK80.DLL à 0177:0041f2d9.
      Registres :
      EAX=00000000 CS=0177 EIP=0041f2d9 EFLGS=00010202
      EBX=00600000 SS=017f ESP=0070f178 EBP=0070f17c
      ECX=00000000 DS=017f ESI=00d52ec0 FS=0e6f
      EDX=004e037c ES=017f EDI=004e6f60 GS=0000
      Octets à CS : EIP :
      89 51 08 8b e5 5d c3 55 8b ec 83 ec 34 8b 45 0c 
      État de la pile :
      00000000 0070f1c0 0045e25e 00000000 004e037c 004e6f60 00d52ec0 000007ff
      000007f8 0070f1e8 00000000 00000000 00000000 00000020 00000002 00000000

  DesiredBehavior:
  no crashes or limits known


tkt_uuid: 462338ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Works For Me
title: 20 grid-* tests fail
comment:
  $ cd tk/unix
  $ ./configure --disable-shared
  $ make tktest
  $ ./tktest ../tests/grid.test
  ...
  grid.test:Total140Passed118Skipped2Failed20
  Number of tests skipped for each constraint:
  2nonPortable

  See attached file for failed tests output.

  Perhaps the recent Obj-ification of [grid]
  caused this?


tkt_uuid: 2219588fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 7 High
foundin: obsolete: 8.6a4
resolution: None
title: ttk::spinbox needs aqua arrow elements
comment:
  I have committed a ttk::spinbox with support in all the core themes except for Aqua. Someone with a Mac needs to add the button elements for that theme and check it all looks ok.


tkt_uuid: 220925ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: -compund option for menu items (as exists in buttons, etc.)
comment:
  OriginalBugID: 5860 RFE
  Version: 8.4a1
  SubmitDate: '2000-06-08'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: All


  Name:
  Bruce Stephens

  DesiredBehavior:
  buttons (command, radio-, and check-) and labels now have the option 
  -compound, to allow both an image (or bitmap) and text to be displayed.  The
  analogous menu items don't.  

  I think menu items should also have this feature.


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


  Name: George A. Howlett


  Comments:

  This bug has been reported several times with previous releases.


  ReproducibleScript:

  scale .s -cursor trek

  destroy .s


  ObservedBehavior:

  wish segfaults in Tk_FreeOptions


  Patch:

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

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

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

  *** 164,170 ****

    static int            ConfigureScale _ANSI_ARGS_((Tcl_Interp *interp,

                              TkScale *scalePtr, int objc,

                              Tcl_Obj *CONST objv[]));

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

    static void           ScaleCmdDeletedProc _ANSI_ARGS_((

                              ClientData clientData));

    static void           ScaleEventProc _ANSI_ARGS_((ClientData clientData,

  --- 164,170 ----

    static int            ConfigureScale _ANSI_ARGS_((Tcl_Interp *interp,

                              TkScale *scalePtr, int objc,

                              Tcl_Obj *CONST objv[]));

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

    static void           ScaleCmdDeletedProc _ANSI_ARGS_((

                              ClientData clientData));

    static void           ScaleEventProc _ANSI_ARGS_((ClientData clientData,

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

  *** 523,532 ****

     */


    static void

  ! DestroyScale(memPtr)

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

    {

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


        /*

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

  --- 523,538 ----

     */


    static void

  ! DestroyScale(scalePtr)

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

    {

  ! 

  !     scalePtr->flags |= SCALE_DELETED;

  ! 

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

  !     if (scalePtr->flags & REDRAW_ALL) {

  !       Tcl_CancelIdleCall(TkpDisplayScale, (ClientData) scalePtr);

  !     }


        /*

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

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

  *** 550,556 ****

        }

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

              scalePtr->tkwin);

  !     TkpDestroyScale(scalePtr);

    }


    /*

  --- 556,562 ----

        }

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

              scalePtr->tkwin);

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

    }


    /*

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

  *** 1022,1035 ****

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

          TkEventuallyRedrawScale(scalePtr, REDRAW_ALL);

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

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

  !           scalePtr->tkwin = NULL;

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

  !       }

  !       if (scalePtr->flags & REDRAW_ALL) {

  !           Tcl_CancelIdleCall(TkpDisplayScale, (ClientData) scalePtr);

  !       }

  !       Tcl_EventuallyFree((ClientData) scalePtr, DestroyScale);

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

          ComputeScaleGeometry(scalePtr);

          TkEventuallyRedrawScale(scalePtr, REDRAW_ALL);

  --- 1028,1034 ----

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

          TkEventuallyRedrawScale(scalePtr, REDRAW_ALL);

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

  !       DestroyScale(scalePtr);

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

          ComputeScaleGeometry(scalePtr);

          TkEventuallyRedrawScale(scalePtr, REDRAW_ALL);

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

  *** 1082,1089 ****

         * destroys the widget.

         */


  !     if (tkwin != NULL) {

  !       scalePtr->tkwin = NULL;

          Tk_DestroyWindow(tkwin);

        }

    }

  --- 1081,1087 ----

         * destroys the widget.

         */


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

          Tk_DestroyWindow(tkwin);

        }

    }

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

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

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

  *** 191,204 ****

     *                            this widget.

     */


  ! #define REDRAW_SLIDER         1

  ! #define REDRAW_OTHER          2

  ! #define REDRAW_ALL            3

  ! #define ACTIVE                        4

  ! #define INVOKE_COMMAND                0x10

  ! #define SETTING_VAR           0x20

  ! #define NEVER_SET             0x40

  ! #define GOT_FOCUS             0x80


    /*

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

  --- 191,205 ----

     *                            this widget.

     */


  ! #define REDRAW_SLIDER         (1<<0)

  ! #define REDRAW_OTHER          (1<<1)

  ! #define REDRAW_ALL            (REDRAW_SLIDER | REDRAW_OTHER)

  ! #define ACTIVE                        (1<<2)

  ! #define INVOKE_COMMAND                (1<<3)

  ! #define SETTING_VAR           (1<<4)

  ! #define NEVER_SET             (1<<5)

  ! #define GOT_FOCUS             (1<<6)

  ! #define SCALE_DELETED         (1<<7)


    /*

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


  PatchFiles:

  generic/tkScale.c generic/tkScale.h




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


tkt_uuid: 1518677fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: Support for WM_UNICHAR window message (windows)
comment:
  This patch introduces support for the WM_UNICHAR window
  message, used under windows to send unicode characters
  to applications. This is particularly used by virtual
  keyboard applications, such as Tavultesoft Keyman
  (http://www.tavultesoft.com/keyman/).

  This patch is for Tk 8.5 current CVS head, but the
  needed changes are so few, that the patch can be also
  applied to 8.4. In fact, it would be good if the patch
  gets also applied to Tk 8.4, so as all current existing
  Tk applications can benefit from it and receive input
  from keyboard applications like KeyMan.

  George Petasis


tkt_uuid: 3466588fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: None
title: panedwindow resize problem with text -setgrid 1
comment:
  A panedwindow contains two frames, of which one is a text widget created with "-setgrid 1". When the top-level window is resized by more than about 20 pixel at a time, dragging the sash of the panedwindow also resizes the top-level window. Seen on Windows XP SP3 with Tcl/Tk 8.5.9 and 8.5.11. Omit the option "-setgrid 1" from the text widget command, and the problem is gone. That's ok for me. But I would like to have the problem documented, at least. The problem seems related to ID 1161543, where listboxes were used instead of a text.


tkt_uuid: 1754048fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: Extra options for tags
comment:
  As part of Tklib's ntext package, I have written bindings for Tk's text widget that indent wrapped display lines (other than the first of each logical line) using -lmargin2.  The purpose is to make all display lines observe the same leading whitespace as the first, giving a neater display of text.

  New options for text tags would greatly help the visual interpretation of text displayed in this way.  The options I would like are:

    -lmargin2color color
    specifies the background color to use (instead of "-background color") in regions that cannot contain characters because they are indented by -lmargin2

    -lmargin2stipple bitmap
    specifies a bitmap that is used as a stipple pattern for the background (instead of "-bgstipple bitmap") in regions that cannot contain characters because they are indented by -lmargin2

  Other users might want corresponding tag options for -lmargin1 and -rmargin; for my purposes, I only need these tag options for -lmargin2.

  The requested features are widely used in text editors (e.g. see the attached image of KDE's Kate), and I cannot find any way to implement them with the text widget's existing feature set.


tkt_uuid: 220693ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Shift-selection behavior in Text widget goofy
comment:
  OriginalBugID: 4253 RFE
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-04-17'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 4375
  OS: All
  FixedDate: '2000-04-17'
  FixedInVersion: 8.3.1
  ClosedDate: '2000-02-28'


  Name:
  George Petasis

  ReproducibleScript:
  There is a problem in extending a selection done with mouse:
  1) Select a word by double clicking on the text widget.
  2) Try to modify the selection with shift+arrows. Upon the first key press,
      the selection is modified in unpredictable manner. (the one end is the 
      character over which you wave done the double click. The other???)

  DesiredBehavior:
  The selection could be edited in a predictable way, preferably in the way
  that text editors implement it.



  The user needs to specify what is being unpredictable.  The selection
  code became more intelligent (complex) in 8.3 to handle embedded
  widgets and images correctly, but for raw text it works just the
  same as 8.2. 
  -- 02/28/2000 hobbs
  The complaint is just about shift-selection management, which is
  not very standard in Tk.  It should be made more like Windows.
  Moved to RFE. 
  -- 04/07/2000 hobbs

  I fixed the anchor/insert placement following double/triple clicks in the text widget.  I also tweaked the selection extension for shift-double-click, so that it now only extends selection on the side of the double-click (previously it would also select all the contiguous whitespace on the opposite side of the selection).

  This fix will go out with 8.3.1.

  - eric

  -- 04/17/2000 ericm


tkt_uuid: 220098ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: Balloon help windows appear in upper left corner of screen
comment:
  OriginalBugID: 544 Bug
  Version: 8.0p2
  SubmitDate: '1998-03-13'
  LastModified: '1999-08-15'
  Severity: MED
  Status: Closed
  Submitter: stanton
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-15'


  The following script incorrectly places the toplevel window at (0,0) on the root window:

  toplevel .t; wm override .t 1; wm withdraw .t; update idle; wm geometry .t -100-100; wm deiconify .t



  This is a user programming error.  This works as expected when you
  put the wm geom command before the update idle. 
  -- 08/15/1999 hobbs


tkt_uuid: 3471873fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: None
resolution: Fixed
title: mark next/prev with peer text widgets
comment:
  The attached patch fixes items 3288113 and 3288121:

  Missing marks when searching through mark next from peers:
    https://sourceforge.net/tracker/?func=detail&aid=3288113&group_id=12997&atid=112997

  Endless loop with mark prev from peer text widget:
    https://sourceforge.net/tracker/?func=detail&aid=3288121&group_id=12997&atid=112997

  The patch is against the latest Fossil sources.

  The existing textMark.test suite passes with no failure.
  Plus I have added one test item for each issue above that the patch is fixing.


tkt_uuid: 1225274fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: obsolete: 8.4.11
resolution: Duplicate
title: Aqua: panic in canvPs-3.1
comment:
  during test canvPs-3.1 on an
  -enable-aqua build on OSX Panther:

  canvPs.test
  XGetImage Failure: XGetImage: only ZPixmap types are
  implemented


tkt_uuid: 1173969fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 55. [focus]
priority: 5 Medium
foundin: None
resolution: None
title: Focus behaviour changes
comment:
  Possibility of modifing/extending the behaviour of focus?

  Background:  Tcl/Tk is running on an embedded computer
  running Linux with X without mouse, touch screen and
  only a minimilist keyboard.  The TclTk is the only
  application running under X and there is no Windows
  manager.

  There are serious problems with focus becoming lost or
  not ending up in the correct place for the following
  reasons:

  -To change the screen contents we must bring up a popup
  allowing selection of the new screen.  The popup
  restores focus to a widget that nolonger exists.

  -Focus between different toplevels appears not to be
  serialised.  For example if you focus on widget then
  toplevel/menu the final focus position is a bit random
  (especially if widget is in the process of mapping itself).

  -If there is a focus on a maping widget and then
  becomes unmapped the focus event gets held off until
  the next time the widget becomes shown.

  -If we focus on a mapping widget and then a popup
  appears before the focus event occurs then focus will
  be restored to the wrong location as  it stores what
  has focus rather than what was the last thing you asked
  for focus on.

  -Multiple focus events can come in the wrong order if
  you focus on a mapping widget and then focus on an
  already mapped widget.

  Suggestions for fixes:

  -Add a "-pending" option for focus to return always to
  the last asked for focus position.  Also make this work
  correctly with -lastfor.

  -Allow widget to pick up pending focus (by default?),
  perhaps a switch or a global option.

  -Providing ability to modify tkPriv with directly
  modifying the private variable.

  -A new focus request will cancel any pending focus request.

  -A focus request on a widget being removed from the
  screen becomes deleted (note focus -pending would need
  restoring in this case).

  Is presumed that normally [focus -pending] and [focus]
  will always return the same value unless we really have
  a pending request.


tkt_uuid: 1554672fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: unfree'd DString in tkMacOSXMenu.c
comment:
  The Tcl_DString:

   convertedTextDString

  in macosx/tkMacOSXMenu.c is not Tcl_DStringFree'd.
  Possibility of leaked memory.


tkt_uuid: 2118142fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: None
title: unexpected radiobutton selection behavior
comment:
  The following code operates differently between tk 8.4 and 8.5.

  Under 8.4, the 3 button frame appears with the first entry having a green background, but no button selected.

  Under 8.5, the first button having a green background, the first two buttons have a red dot but no black dot indicating selection, and the third button having the round button indicator, with no color inside the circle.

  Note that if I then move the mouse over the first button of the application, that circle changes from being red to being a round button with a black center, but still dim.

  I am unable to determine if this strange situation of having things change like this is intentional behavior by Tk or a bug.

  The code is simple:
  package require Tk

  wm title . [info tclversion]

     frame .frame
     pack .frame

     wm title . "Ex.1: [info tclversion]"

     frame .frame.typ
     pack .frame.typ

     set mcolor bisque
     set acolor green

     radiobutton .frame.typ.rad1 -relief raised -text "" -font 7x13bold \
          -width 12 -selectcolor red -anchor w -variable radio1 -value "radio1" -b
  ackground $mcolor -activebackground $acolor      -state active
     radiobutton .frame.typ.rad2 -relief raised -text "" -font 7x13bold \
          -width 12 -selectcolor red -anchor w -variable radio2 -value "radio2" -b
  ackground $mcolor -activebackground $acolor      -state normal
     radiobutton .frame.typ.rad3 -relief raised -text "" -font 7x13bold \
          -width 12 -selectcolor red -anchor w -variable radio3 -value "radio3" -b
  ackground $mcolor -activebackground $acolor      -state disabled

     pack .frame.typ.rad1 -side top
     pack .frame.typ.rad2 -side top
     pack .frame.typ.rad3 -side top


tkt_uuid: 565485ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 8
foundin: obsolete: 8.4a5
resolution: Fixed
title: Bad button sizing on Windows.
comment:
  I would expect that a button with -width and -height set
  has a size that is unaffected by its text. This is
  currently not true on Windows where an empty text gives
  a slightly smaller button.

  Also, I think a button with a one-line text should have
  the same size when -height is 0 and when it's 1.

  The attached patch fixes this and adds a test case
  in button.test since I think this behaviour should be
  platform independent. I have not tested on any other
  platform.

  Example: none of the buttons should change size:

  button .a -text Hej -font "Arial 12" -command exit
  button .b -text Hej -width 10 -height 1 -command exit
  wm geometry . 150x100
  place .a -x 10 -y 10
  place .b -x 10 -rely 0.5 

  proc apa {{odd 1}} {
      .a configure -height $odd
      .b configure -text [expr {$odd ? "" : "Hej"}]
      after 500 apa [expr !$odd]
  }
  apa


tkt_uuid: 3554081fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.12
resolution: Fixed
title: Test bind-22.10 fails
comment:
  In core-8-5-branch and core-8-4-branch as well:

  ==== bind-22.10 HandleEventGenerate FAILED
  ==== Contents of test case:

      setup
      bind .b.f <Key> {set x "%s %K"}
      set x {}
      event gen .b.f <Control-Key-1>
      set x

  ---- Result was:
  5 1
  ---- Result should have been (exact matching):
  4 1
  ==== bind-22.10 FAILED


  This was fixed a long time ago in trunk. See the bottommost comment in bug 2307387.
  Citing what was said there:
  "bind-22.10: it is due to the test case using a numeric character ("1") which has different layouts depending on keyboard locale. Using a more consensual key makes it universal."

  Consensual key chosen in the trunk version of this test is space, which seems to be a clever choice indeed.

  I will fix bind-22.10 accordingly in both core-8-5-branch and core-8-4-branch.


tkt_uuid: 1566196fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: Later
title: Implement alpha support
comment:
  The -alpha attribute in wm is not supported in Linux
  systems.

  Would be great if this attribute can be added, since
  the applications will have a more consistence look&feel
  in the different OS.

  Thanks.


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


  From: vince darley


  ReproducibleScript:

  text .t

  pack .t

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

  t insert 1.0 "aaaaa\u2022Xaaaaa\n"

  # same thing but without a multi-byte char

  t insert 2.0 "aaaaauXaaaaa"

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

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

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

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

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

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

  console show


  ObservedBehavior:

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


  Patch:

  Lines 1798-1801 of tkText.c:

          matchByte = i;

          matchLength = thisLength;

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

     } while (backwards);


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


  Comments:

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


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



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


tkt_uuid: 3020550fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: None
resolution: None
title: grid, pack, place on half-dead windows resurrects hash entry
comment:
  I've explored this issue in depth for "grid" manager only, but others seems to be affected, too. 

  Code in tkGrid.c uses hash table to find stored information for managed windows. It's a hash table with one-word keys, mapping from tkwin to "struct Gridder*"; when some grid operation on a tkwin is requested for the first time, this structure is allocated and added to hash table. It is deleted from the hash table on DestoyNotify event.

  A very bad thing happens when some <Destroy> binding executes a grid subcommand
  on a destroyed window (it may be [grid info] or even [grid forget]). Binding is executed when DestroyNotify handler has already removed a Gridder* from the hash table; hence a Gridder for dead window is [re]created and added to the hash table. _No one will remove it from there any more_. 

  But it's not just a tiny memory leak: tkwin is going to become invalid as soon as Tk_DestroyWindow finishes, and its memory block can be reused for any other data structure. For some allocators (tclThreadAlloc at least) this structure will be probably another tkwin, for a new window. Any grid operation on this unhappy window will find an "existing" Gridder* and use it. Tk_CreateEventHandler is not called when Gridder* already exists. We now have a window that looks alright from the scripts' point of view, but (1) it doesn't rearrange slaves when resized, and (2) it won't be removed from the hash table, even if no grid calls in <Destroy> bindings occur this time. Both actions, (1) and (2), depend on an event handler (StructureNotifyMask -> GridStructureProc) that is not installed.

  Destroyed tkwin addresses are reused surprisingly often. I was debugging the hv3 tabbed browser (where <Destroy> handler on notebook widget does [grid forget]), and after destroying a tab, the next new tab was disfunctional (the way described above) for about 10-30% of attempts. Thank God, such frequency enabled me to track down the problem.

  It seems to be an optimal solution to conceal the window's death for "informational" and "removing/forgetting" geometry manager subcommands, returning an empty value with no error, and to generate an error if a script tries to add or configure a slave of the dead window, or a dead window itself.

  Another variant, minimizing required effort and probably rather good semantically, is to add support for an _ultimate_ dead-window callback chain, called in Tk_DestroyWindow when no bindings or normal event handlers will be invoked any more. Removing tkwin from a hash table should happen in this callback. 

  A _pseudo-solution to be avoided_ is to reverse invocation order of [bind] handlers and Tk handlers for DestroyNotify event, ensuring that [bind] scripts are called first. Among other disadvantages, it is _unsafe_: adding a command trace for widget command deletion allows hooking into non-[bind] DestroyNotify handler chain.


tkt_uuid: 2956548fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: TkpButtonSetDefaults only initialises one button type
comment:
  In tkButton,c, I spot the following code:
      if (!tsdPtr->defaultsInitialized) {
  TkpButtonSetDefaults(optionSpecs[type]);
  tsdPtr->defaultsInitialized = 1;
      }

  There are 4 button types, TkpButtonSetDefaults()
  will only be called once, for the first constructed
  button. The other types will have the original
  defaults, defined by DEF_BUTTON_BORDER_WIDTH,
  in stead of the default determined by
  GetSystemMetrics(SM_CXEDGE).

  Luck enough, no-one will ever spot the
  difference: DEF_BUTTON_BORDER_WIDTH
  has the value 2, and GetSystemMetrics(SM_CXEDGE)
  normally returns 2 as well. But if GetSystemMetrics
  one day returns a different value, it will only be
  taken over by one button type, the other 3 will
  be left as-is.

  This is already fixed in HEAD, as
  part of the CONSTification of tkButton. But
  since 8.5 and 8.4 have the same problem
  (8.3 is OK!), I would like to backport the
  same solution to 8.5 and 8.4 as well.

  Proposed solution: Introduce a MODULE_SCOPE
  variable tkDefButtonBorderWidth, which is set
  directly by TkpButtonSetDefaults, and stores
  the default value for all button types. This way,
  the specPtr argument is not used any more and
  one call is sufficient to initialize all buttons.
  In 8.6, I removed the specPtr argument from
  TkpButtonSetDefaults(), but in 8.5 and 8.4
  I will keep the function signature the same.
  Patch upcoming.

  Any comments?


tkt_uuid: 219909ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 1 Zero
foundin: obsolete: 8.1a2
resolution: Duplicate
title: i18n bug in Tk menus
comment:
  OriginalBugID: 871 Bug
  Version: 8.1a2
  SubmitDate: '1998-11-25'
  LastModified: '1999-05-20'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hershey
  RelatedBugIDs: 819
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-05-20'


  Subject: i18n bug in Tk menus
  From: Ben Elliston <bje@cygnus.com>
  Date: 20 Oct 1998 17:46:04 +1000
  Posted-to: comp.lang.tcl

  The following message is a courtesy copy of an article
  that has been posted to comp.lang.tcl as well.

  I feel I have found a bug in the underline handling for menu buttons
  in Tcl/Tk 8.1a2--in relation to encoding support for i18n.

  Here is a tiny uuencoded file that contains two Kanji characters (ShiftJIS
  encoded) followed by the menu hotkey, as is typically shown in
  Japanised applications.  Suppose our two Kanji characters are `#' and
  `*' respectively.  The string in the file is:

  #*(V)

  (for a total of 5 characters).

  begin 644 shiftjis.str
  )E5R.IBA;5BD*
  `
  end

  First, we'll use wish to read this string into a variable:

  set f [open shiftjis.str r]
  fconfigure $f -encoding shiftjis
  set jstring [read $f]

  # Verify it. Tcl will translate Kanji chars to `?' for your
  # Western terminal.
  puts stdout $jstring

  Next, we'll create a menu button and label it with our string:

  menubutton .mb -text $jstring
  pack .mb

  Since we have five characters, you would expect that underlining index
  0 of the menu button label to underline `#' and index 3 to underline `V'.
  Underlining `V' is what I want to do.

  Interesting things happen if you manually underline each index in turn
  and observe:

  .mb configure -underline 0
  .mb configure -underline 1
  .mb configure -underline 2
  .mb configure -underline 3
  .mb configure -underline 4
  .mb configure -underline 5
  .mb configure -underline 6
  .mb configure -underline 7

  The underlining appears for index 0, but not 1 or 2, 3 but not 4 or
  5.  It appears for 6 and 7.  Underlining position 7 is what is
  required to underline `V'.

  Any ideas?

  Thanks, Ben

  ---
  Ben Elliston
  bje@cygnus.com


tkt_uuid: 1609616fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: reject xft cleanly
comment:
  Attached patch makes sure
  to clear the
  XFT_CFLAGS and XFT_XLIBS
  values when configure
  testing indicates xft
  support is broken in some way.

  This was needed to build
  Tk on my Solaris system.


tkt_uuid: 1027741fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: None
priority: 5 Medium
foundin: None
resolution: None
title: Selection doesn\'t change on Redo operation
comment:
  When Redo operation is invoked in text widget with
  selection,
  insertion cursor moves to the redone text, but if there
  is a selection which was created after last Undo, it
  persists.
  This can be misleading for users which thinks that text
  typed with active selection should replace selection.

  If selection changes would be saved in Undo stack, it
  would be more consistent with other (non-Tk ) applications.


tkt_uuid: 3551632fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: None
resolution: Accepted
title: Implement fullscreen on Tk-Cocoa
comment:
  Full-screen worked on Tk-Carbon but failed on Tk-Cocoa.  On inspection of the code, it appeared that the implementation from Carbon was just left in the code, but it does not work under Cocoa.  The attached patch removes this and substitutes appropriate Cocoa code so that wm attributes <win> -fullscreen 1/0 works.


tkt_uuid: 1519720fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Works For Me
title: Problem compiling tk8.5a4
comment:
  # make
  gcc -pipe -c -O2 -s -O3 -march=i686 -Wall
  -Wno-implicit-int -fPIC -I/tmp/tk8.5a4/unix/../unix
  -I/tmp/tk8.5a4/unix/../generic
  -I/tmp/tk8.5a4/unix/../bitmaps -I/tmp/tcl8.5a4/generic
  -I/tmp/tcl8.5a4/unix -I/usr/X11R6/include
  -DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\"
  -DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tk\ 8.5\"
  -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1
  -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
  -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
  -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
  -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
  -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1
  -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1
  -DHAVE_PTHREAD_GETATTR_NP=1 -DGETATTRNP_NOT_DECLARED=1
  -DTCL_THREADS=1 -DPEEK_XCLOSEIM=1
  -DTCL_SHLIB_EXT=\".so\" -DTCL_CFG_OPTIMIZED=1
  -DTCL_CFG_DEBUG=1 -D_LARGEFILE64_SOURCE=1
  -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1
  -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1 -DHAVE_TYPE_OFF64_T=1
  -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1
  -DHAVE_PW_GECOS=1 -DHAVE_XSS=1 -DHAVE_XFT=1     
  -DTCL_NO_DEPRECATED  -DUSE_TCL_STUBS 
  /tmp/tk8.5a4/unix/../generic/tkMain.c
  /tmp/tk8.5a4/unix/../generic/tkMain.c:23:20: tclInt.h:
  No such file or directory
  /tmp/tk8.5a4/unix/../generic/tkMain.c: In function
  `Tk_MainEx':
  /tmp/tk8.5a4/unix/../generic/tkMain.c:145: warning:
  implicit declaration of function `Tcl_GetStartupScript'
  /tmp/tk8.5a4/unix/../generic/tkMain.c:145: warning:
  comparison between pointer and integer
  /tmp/tk8.5a4/unix/../generic/tkMain.c:159: warning:
  implicit declaration of function `Tcl_SetStartupScript'
  /tmp/tk8.5a4/unix/../generic/tkMain.c:175: warning:
  assignment makes pointer from integer without a cast
  /tmp/tk8.5a4/unix/../generic/tkMain.c:256: warning:
  assignment makes pointer from integer without a cast
  make: *** [tkMain.o] Error 1


  I have just installed tcl8.5a4


tkt_uuid: 2262543fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 15. [scale]
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: None
title: Scale widget unexpectedly fires command callback
comment:
  The Tk scale widget (used through the Python/Tkinter interface) fires its command unexpectedly when it is initialized with a value.  This behavior is different then say, a checkbox, which can be initialized with a value without triggering the command callback.  I'm attaching a script which shows this behavior.

  scale1 is initialized with a value through the variable option.  The command callback for scale1 fires unexpectedly when the mainloop starts.  I say unexpectedly, because the value of the scale is never changed from its initial value (at least from the user/coders point of view).

  scale2 is initialized without a command callback.  The command callback is registered AFTER the value is changed, yet the callback still fires upon entering mainloop.

  Both of these behaviors strike me as unexpected, and contrary to how the command callback is typically used for other widgets.  Also in the test script are two checkbuttons that are initialized in similar fashion to the scale widgets above, and you can see that their command callbacks do not fire.

  This issue was discussed on the Tkinter mailing list: http://mail.python.org/pipermail/tkinter-discuss/2008-November/001714.html and there is additional info in Guilherme Polo's helpful replies.

  Guilherme also supplied this minimal tcl sample of the behavior as well, which I don't understand enough to explain:

  scale .s -command {puts}
  pack .s

  Thanks -

  Dave Giesen


tkt_uuid: 607009ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: patches to build 8.4.0 with CW 6.3
comment:
  After some tweaks, I managed to build Tk 8.4.0 (CVS as 
  of a few days ago) with CodeWarrior 6.3, as part of the 
  recent TclKit 8.4.0 build fest.

  Most changes affect CONST.  Some changes tell me the 
  code has not been built for a long time (perhaps code 
  moved around or added to mac without testing), given 
  that there were typo's among them.

  Some changes may be due to switching to MoreFiles 1.5.3 
  (was 1.5.2, I think).

  The Universal Interfaces version I used was 3.4.1, 
  applying all patches mentioned by Daniel Steffen in the 
  docs and rebuilding all libraries, as advised.  Latest 
  is now 3.4.2, but this was not tried.

  One or two casts will cast CONST away, but as far as I 
  can tell this is valid because in each of those cases 
  the pointers are known to be allocated.


tkt_uuid: 1967576fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Fixed
title: Resizing a ttk::label panics as width or height equal zero
comment:
  WinXP SP3/ VC++ 2008 / Tcl/Tk 8.5.2

  Running this script:
    package require Img

    image create photo img::download -format PNG -file download.png
    
    ttk::label .w -image img::download
    pack .w -side left

  and then resizing the toplevel to zero height causes wish to panic with:

  "Unable to alloc 4294967040 bytes"


  The cause is the clipping operation in ttklabel.c ImageDraw.

  On resizing, the widget window dimensions become smaller than the element area dimensions. When this happens the image dimension are clipped to int -1. The width/height are then cast to a (unsigned int) very large positive integer in tkimgphoto.c ImgPhotoDisplay. Wish panics in tkwinimage.c XGetImageZPixmap when memory is being allocated for the image.

  Here's the stack:
  wish85sg!Tcl_PanicVA+0xe9
  wish85sg!Tcl_Panic+0x1e
  wish85sg!Tcl_Alloc+0x34
  wish85sg!XGetImageZPixmap+0x6e9
  wish85sg!XGetImage+0x193
  wish85sg!ImgPhotoDisplay+0xa7
  wish85sg!Tk_RedrawImage+0xd9
  wish85sg!ImageDraw+0x7e
  wish85sg!LabelElementDraw+0x134
  wish85sg!Ttk_DrawElement+0x7b
  wish85sg!Ttk_DrawNodeList+0xd4
  wish85sg!Ttk_DrawNodeList+0x7b
  wish85sg!Ttk_DrawNodeList+0x7b
  wish85sg!Ttk_DrawLayout+0x1b
  wish85sg!TtkWidgetDisplay+0x28
  wish85sg!DrawWidget+0x7b
  wish85sg!TclServiceIdle+0xa5
  wish85sg!Tcl_ServiceAll+0x117
  wish85sg!WmProc+0x639

  This patch fixes the problem, but maybe it would be better to fix the root cause above...

  Index: ttkLabel.c
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/generic/ttk/ttkLabel.c,v
  retrieving revision 1.11
  diff -u -r1.11 ttkLabel.c
  --- ttkLabel.c13 Dec 2007 15:26:26 -00001.11
  +++ ttkLabel.c20 May 2008 00:25:12 -0000
  @@ -314,6 +314,13 @@
   height = Tk_Height(tkwin) - b.y;
       }
   
  +    if (width < 0) {
  +      width = 0;
  +    }
  +    if (height < 0) {
  +      height = 0;
  +    }
  +
       Tk_RedrawImage(image->tkimg, 0,0, width, height, d, b.x, b.y);
   
       /* If we're disabled there's no state-specific 'disabled' image, 


   


tkt_uuid: 1589226fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: TkAqua sends too many Expose events
comment:
  This patch fixes the handling of Carbon Update events in TkAqua: the 
  QuickDraw window update region was being ignored and all child 
  TkWindows were sent  an Expose XEvent even when they did not need to 
  be redrawn.


tkt_uuid: 3595620fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: Works For Me
title: tkMacOSXWindowEvent.c and tkMacOSXWm.c compilation
comment:
  tkMacOSXWindowEvent.c  has multiple compile warnings; tkMacOSXWm compile fails.  Trying to build on ppc G5 with osx 10.5.8.


tkt_uuid: 2927569fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: man page buglet for photo
comment:
  Greetings,

  the man page of photo documents the
  "-to" option of the "put" command as
  "Specifies the coordinates of the top-left corner (x1,y1) of the region of imageName into which data from filename are to be read."
  however, there is no reading from files
  and no filename option involved for
  this command?

  kind regards,
  Randolf


tkt_uuid: 583286ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Fixed
title: Strange focus handling
comment:
  Execute the following script:

    pack [text .t]
    .t window create 1.0 -window [button .t.b -text hi]
    .t insert end " some random text "
    focus .t.b

  Now, pressing the space bar operates the button (which
  is good) but the insertion cursor is flashing in the
  text widget while this is happening as if keypresses
  will be inserted there (which is bad.)  Surely the
  insertion cursor should only flash when the focus is
  directed to the text widget, and not to one of its
  children?


tkt_uuid: 220558ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Robustness of tk.tcl
comment:
  OriginalBugID: 2365 Bug
  Version: 8.1.1
  SubmitDate: '1999-07-16'
  LastModified: '1999-08-12'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 1138
  OS: Other
  Machine: NA
  FixedDate: '1999-08-12'
  FixedInVersion: 8.2


  Name:

  Jan Nijtmans



  CVS:

  july 10, 1999



  ReproducibleScript:

  If $tk_library is the empty string (which can happen in standalone

      executables), it is still appended to auto_path. Also other

      initialization files are attempted to be sourced from non-existing

      places. The patch below, which

      is needed for the upcoming "Wrap" extension, fixes this.



  Patch:

  *** library/tk.tcl.origSat Jul 10 12:32:09 1999

  --- library/tk.tclSat Jul 10 12:34:58 1999

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

  *** 20,29 ****

    # Add Tk's directory to the end of the auto-load search path, if it

    # isn't already on the path:

    

  ! if {[info exists auto_path]} {

  !     if {[lsearch -exact $auto_path $tk_library] < 0} {

  ! lappend auto_path $tk_library

  !     }

    }

    

    # Turn off strict Motif look and feel as a default.

  --- 20,28 ----

    # Add Tk's directory to the end of the auto-load search path, if it

    # isn't already on the path:

    

  ! if {[info exists auto_path] && [string compare $tk_library {}] &&

  ! [lsearch -exact $auto_path $tk_library] < 0} {

  !     lappend auto_path $tk_library

    }

    

    # Turn off strict Motif look and feel as a default.

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

  *** 181,187 ****

    # Read in files that define all of the class bindings.

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

    

  ! if {[string compare $tcl_platform(platform) "macintosh"]} {

        source [file join $tk_library button.tcl]

        source [file join $tk_library entry.tcl]

        source [file join $tk_library listbox.tcl]

  --- 180,187 ----

    # Read in files that define all of the class bindings.

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

    

  ! if {[string compare $tcl_platform(platform) "macintosh"] &&

  ! [string compare $tk_library {}]} {

        source [file join $tk_library button.tcl]

        source [file join $tk_library entry.tcl]

        source [file join $tk_library listbox.tcl]



  PatchFiles:

  tk.tcl





  Integrated into 8.2. 
  -- 08/12/1999 hobbs


tkt_uuid: 1717830fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Tk with Xft leaks using font commands
comment:
  Using CVS version of 2007/05/12
  I made a little script that increase memory by some MB...
  Usage :
  -Run it with wish : programe tells its PID
  -Do in a spearate console pmap <thepid>|grep total
  -Press enter in Tk console : wait until it says "Finished measure"
  -Redo pmap <thepid>|grep total : you will see that memory usage increased
  -Press enter again in Tk console : wait until it says "Finished metrics"
  -Redo pmap <thepid>|grep total : you will see that memory usage increased
  -Press enter again in Tk console to kill wish


tkt_uuid: 2408101fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: None
title: font sizes limited to integer values
comment:
  I believe this bug applies to fonts on all platforms with antialiased fonts and is present in all current versions of Tk. In tk8.*/generic/tkFont.h, TkFontAttributes.size is an integer.  So tkFont's converting between pixels and point sizes is inaccurate.  Also, with modern Linux font support, the user can type in non-integer point sizes for fonts in the standard font choosers.

  For example, on Fedora 7 with gnome:

  $ gconftool-2 --get /desktop/gnome/interface/font_name
  Nimbus Sans L Condensed 11.5
  $ wish
  % tk scaling
  1.47246376812

  So is that a 16 pixel or 17 pixel high font?  What if it were 11?

  The request is that TkFontAttributes.size be changed to be a float.


tkt_uuid: 946106ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: XP visual styles support for native Tk widgets...
comment:
  I simply post here an updated version of my patch that adds 
  drawing of native tk widgets (button, radiobutton, 
  checkbutton, spinbox, entry) using the XP style engine. 
  This patch adds a new option to all these widgets (-stylexp 
  boolean) which controls the drawing. 
   


tkt_uuid: 220134ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: "invalid OMF record, type 0x21"
comment:
  OriginalBugID: 1401 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-10-22'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  ClosedDate: '1999-10-22'


  Name:
  Bill Tovrea

  ReproducibleScript:
  Attempted to link a C++ program successfully linked under tk 8.0. After installing tk 8.0, received the following linker error : "C:/Program Files/Tcl/lib/tk80.lib contains invalid OMF record, type 0x21"

  ObservedBehavior:
  Unable to link program to tk lib

  DesiredBehavior:
  successful link



  C++ compilers are notorious for wanting all the modules
  compiled by the same compiler.  The problem here is likely
  that the tk80.lib must be rebuilt using their compiler.
  This does not seem to be a bug in Tcl or the install process,
  but rather in the integration with other C++ code. 
  -- 10/22/1999 hobbs


tkt_uuid: 220437ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: GPF occurs by bind %a
comment:
  OriginalBugID: 1321 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-02'
  LastModified: '1999-04-02'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: redman
  OS: Windows NT
  OSVersion: 4.0SP4
  Machine: X86
  FixedDate: '1999-04-02'
  FixedInVersion: 8.1b3


  Name:
  Satoshi Imai

  ReproducibleScript:
      GPF occurs by execution of the following commands. 
      
      button .b -text {Don't Push} -command exit
      pack .b
      
      bind .b <Enter> {
          set foo %a ;# GPF occurs by %a
      }
      




  Crashes on Windows.  03/25/1999 15:39 - surles -

  04/02/1999 18:53 - redman - %a is only valid during configure events, not during EnterLeave events.  But a check around the offending code. Fixed


tkt_uuid: 846884ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: textWind-10.6.1 fails
comment:
  Solaris 9 / CDE:

  ==== textWind-10.6.1 EmbWinLayoutProc procedure, error
  in creating window FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      catch {destroy .t2}
      .t window create 1.5 -create {
          toplevel .t2 -width 100 -height 150
          wm geom .t2 +0+0
          concat .t2
      }
      set msg {}
      update
      set msg

  ---- Result was:
  {{can't embed .t2 relative to .t}}
  ---- Result should have been (exact matching):
  {{can't embed .t2 relative to .t}} {{window name "t2"
  already exists in parent}}
  ==== textWind-10.6.1 FAILED


tkt_uuid: 220578ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 31. Cursor Names
priority: 2
foundin: obsolete: 8.2b2
resolution: Fixed
title: panic "GetCursorFromObj called with non-existent cursor!"
comment:
  OriginalBugID: 2562 Bug
  Version: 8.2b2
  SubmitDate: '1999-08-18'
  LastModified: '1999-08-20'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '1999-08-20'
  FixedInVersion: 8.2.1


  Name:

  Uwe Zimmermann



  Extensions:

  TclX 8.2, Tix 4.1.0.006



  CustomShell:

  No changes but this patch.



  ReproducibleScript:

  Cannot recreate but with our application, which runs fine with Tk 8.0.3

      Application changes cursor of all widget windows to "watch" cursor

      to indicate "busy" state.

      Have not been able to reproduce with simplified code.



  ObservedBehavior:

  Aborts with core with "GetCursorFromObj called with non-existent

      cursor!"



  DesiredBehavior:

  Works fine with Tk 8.0.3.

      Works fine with patch below.



  Patch:

  wazoom[352] diff -c tkCursor.c.orig tkCursor.c

  *** tkCursor.c.origTue Aug 17 11:28:17 1999

  --- tkCursor.cTue Aug 17 11:04:54 1999

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

  *** 716,722 ****

    

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

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

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

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

        cursorPtr->objRefCount++;

        return cursorPtr;

  --- 716,722 ----

    

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

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

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

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

        cursorPtr->objRefCount++;

        return cursorPtr;



  PatchFiles:

  generic/tkCursor.c





  This appears to have never been called before...  The fixed was
  applied for the 8.2.1/8.3b1 release. 
  -- 08/20/1999 hobbs


tkt_uuid: 403660ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Fixed
title: Canvas man page update for coordinate lists
comment:
  A recent (8.3) change to the Tk canvas allows several commands to accepts a [list] of coordinates instead of individual x1,y1,x2,y2... values.  While this is a really great feature, it is not described in the canvas.n man page.  This patch adds a sentence to the COORDINATES section and new function prototypes illustrating the new syntax.


tkt_uuid: 1803723fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: obsolete: 8.5a7
resolution: Fixed
title: Bidi wrong in Unicode label demo on WinXP
comment:
  The Unicode label demo in ActiveTcl 8.5.0b9 (= 8.5b1)
  has on Win XP the Arabic and Hebrew reversed.

  Fix: the two places where tk windowingsystem is checked should be modified to

  if {[tk windowingsystem] in {x11 win32}} {


tkt_uuid: 3071836fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 8
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Crash/Tcl_Panic on WinXP saving file to C:\
comment:
  Using tk_getSaveFile may cause a Tcl_Panic() if a particular sequence is used to browse to C:\ .

  Steps to reproduce:
  * Running on Win32 (confirmed on WinXP SP3 with latest patches)
  * Using Tcl 8.6b1.2 (from CVS 2010/08/31)
  * Built with OPTS=threads (debug build uses OPTS=threads,symbols STATS=memdbg)
  * In tclsh or wish execute the following script:
    package require Tk
    wm de .
    tk_getSaveFile -parent . -initialfile "SomeFile"
  * Using the "Look in" dropdown or the navigation bar on the left, select "Desktop".  Then (double-)click to select "My Computer", then "Local Disk (C:)"
  * Select "Save"
  * Interp will panic.

  Cause:
  * In GetFileNameW() (win\tkWinDialog.c) the call to ckfree(ofnData.dynFileBuffer) at the end of the proc detects a memory corruption and crashes / panics.
  * The corruption occurs in OFNHookProcW() (win\tkWinDialog.c) where "dirsize = SendMessageW(hdlg, CDM_GETFOLDERPATH, 0, 0)" may set dirsize to < 0 on failure.  Walking through the buffer manipulation logic one sees that the terminating NULL of the directory is replaced with a backslash, but with dirsize==-1 this corrupts the guard bytes on the buffer.
  * CDM_GETFOLDERPATH appears to return an error (< 0) when selecting an item in the "My Computer" context (since "My Computer" does not correspond to a folder in the filesystem).

  Solution:
  Apply the following patch to empty the buffer when dirsize < 0 :

  Index: tkWinDialog.c
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/win/tkWinDialog.c,v
  retrieving revision 1.77
  diff -r1.77 tkWinDialog.c
  1032c1032,1036
  <           if (selsize > 1) {
  ---
  >           /*
  >            * Just empty the buffer if dirsize indicates an error [Bug XXXXXX]
  >            *
  >            */
  >           if ((selsize > 1) && (dirsize > 0)) {


tkt_uuid: 220815ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: final: 8.0.5
resolution: None
title: Modal dialog behaves incorrectly in CDE
comment:
  OriginalBugID: 1930 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-23'
  LastModified: '1999-04-23'
  Severity: MED
  Status: Assigned
  Submitter: pat
  ChangedBy: pat
  OS: Solaris
  OSVersion: 2.5, 7
  Machine: NA
  FixedInVersion: NA


   > we have encountered another problem with (pro-)wish using CDE (Solaris
   > 2.5, HP-UX 10). If the window setting (in the style manager) "Allow
   > Primary Window On Top" is true, then the modal dialogs
   > (e.g. tk_getOpenFile) aren't modal any longer. The toplevel can get
   > the focus and therefore overlap the dialog window, while the dialog
   > window keeps the grab. So the user can't see any responses of the
   > application to his mouse clicks, what is irritating very much.
   > 
   > All works fine if this option of the CDE is disabled. Other
   > applications with modal dialogs (netscape, java applications) behave
   > correct with either setting.
   > 

  I did a test here using 8.0.5 and 8.1b3 on solaris 2.5 and solaris 7. The behavior is the same on all both versions of Tcl and Solaris. The only workaround is to turn off the option.


tkt_uuid: 842498ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: text widget xview confused when window just being created
comment:
  The following simple test shows the bug:

      set fixedFont {Courier -12}
      catch {destroy .t2}
      toplevel .t2
      wm geometry .t2 +0+0
      text .t2.t -width 20 -height 10 -font $fixedFont \
      -wrap none -xscrollcommand ".t2.s set"
      pack .t2.t -side top
      scrollbar .t2.s -orient horizontal -command ".t2.t
  xview"
      pack .t2.s -side bottom -fill x
      .t2.t insert end 1\n
      .t2.t insert end [string repeat "abc" 30]
      .t2.t xview scroll 5 unit
      update

  (make sure you evaluate it all in one go, NOT
  interactively, since we don't want events to trigger in
  between each command)

  The problem is the attempt to scroll by 5 units (i.e.
  characters) fails, and the window only scrolls by 1 unit.

  The reason?  Here's what I've debugged, but I'm not in
  need of advice:

  The problem is ultimately caused by this line in
  UpdateDisplayInfo (which is called by DisplayText):

      if (dInfoPtr->newByteOffset > maxOffset) {
  dInfoPtr->newByteOffset = maxOffset;
      }

  But the problem is that at this point 'maxOffset' is
  much too small, and so the newByteOffset (which was
  correct at 5 units) is thrown away and reduced to 1.

  So, why is maxOffset too small?  That's because while
  UpdateDisplayInfo iterates over the DLines in the
  widget, after laying out the first line (with maxOffset
  = 1 char), it finds that the current y position is
  greater than dInfoPtr->maxY -- i.e. greater than the
  vertical height of the widget.

  This is of course nonsense since the widget is set up
  to be some 10 characters high.  However, Tk's geometry
  calculations have not yet kicked in at this point, and
  so the text widget is still set at 1 pixel of height.

  When the geometry of the widget is eventually correctly
  set (which of course it is), it is too late for the '5
  unit' scroll, since that information has already been
  discarded as too big.

  Note that this bug has nothing to do with my Tk 8.5's
  text widget changes (both Tk 8.4 and 8.5 show the bug).

  So, is there a way that the text widget can realise
  that it hasn't yet been configured at all (but is going
  to be) and thereby DisplayText can take appropriate
  action (at the least not throw away the 5 units)?

  Could 'TK_NEED_CONFIG_NOTIFY' be used (I notice the
  TkWindow has that flag set)?  Or are there some other
  window attribute/flag that could be used?

  I notice that reqHeight is correct at the time
  UpdateDisplayInfo is called, but using instead of maxY
  is no good, since it is usually not same as the actual
  eventual height, and so we'd end up calculating too
  much or too little.


tkt_uuid: 759550ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: None
resolution: Invalid
title: tkFont.Font(name=existing) is an error
comment:
  The following demonstrates the error:

  >>> from Tkinter import *
  >>> root = Tk()
  >>> import tkFont
  >>> f = tkFont.Font()
  >>> str(f)
  'font2881056'
  >>> f2 = tkFont.Font(name=str(f))
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/tkFont.py", line 76, in __init__
      root.tk.call("font", "create", name, *font)
  _tkinter.TclError: named font "font2881056" already exists

  What I do is create a few named fonts (tkFont.Font objects) as I start a GUI application and use those to set the option database before creating any widgets. Then the user can modify the tkFont.Font objects to change the fonts used by all the widgets. Everything live-updates. A bit slowly perhaps, but it's very nice. So far so good.

  However, I would like some way to recreate the tkFont.Font object from a widget that uses it, so I don't have to keep the tkFont.Font objects around after I create them.

  Note that: f2 = tkFont.Font(font=wdg["font"]) does not work. f2 is created and has the right settings, but it has the wrong name, so modifying f2 does not modify wdg or any other widgets.

  One thing that does work is:
  f2 = tkFont.Font()
  f2.name = wdg["font"]
  but this creates a new Tk named font which is never used, so I'd be leery of using it.

  -- Russell

  P.S. as an aside, there is a similar issue with Tkinter variables. However, there is a reasonable workaround for variables: getvar and setvar. Unfortunately there are no equivalent functions for tkFont.Font objects.


tkt_uuid: 219992ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: final: 8.1.1
resolution: Duplicate
title: used tk_getOpenFile & pack; 2nd window freezes
comment:
  OriginalBugID: 2191 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-07'
  LastModified: '1999-08-20'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 1212
  OS: Windows 95
  Machine: X86
  ClosedDate: '1999-08-20'


  Name:
  Greg Samoluk

  CVS:
  reloaded latest version 6/7/99 @ 10:45 EST

  Extensions:
  no extensions used

  CustomShell:
  none

  Comments:
  Have I violated some coding conventions?

  ReproducibleScript:
  #===============================================================
      # BROWSE.TCL - browse a file
      #===============================================================
      set file_types {
           { "All Files" *.* }
      }
      set filename [tk_getOpenFile  -initialdir "c:"  -filetypes  $file_types  -title      "Browse File Open..."]
      if {$filename == ""} exit
      #===============================================================
      set input     [open "$filename" "r"]
      #===============================================================
      font create myfont -family Courier -size 10
      font create mybold -family Courier -size 10 -weight bold
      regsub -all {/} $filename {\\} wmfn
      wm      title    . "Browse $wmfn"
      wm      geometry . +100+150
      frame   .part1
      scrollbar .part1.xscroll -command {.part1.list xview}  -orient horizontal
      pack      .part1.xscroll -fill x
      listbox   .part1.list -yscrollcommand {.part1.yscroll set}  -xscrollcommand {.part1.xscroll set}  -height 10 -width 75 -font myfont
      while {[gets $input data] >= 0} {
          .part1.list insert end $data
      }
      close $input
      scrollbar .part1.yscroll -command {.part1.list yview}
      pack      .part1.list .part1.yscroll -fill y -side left
      pack      .part1

      label .blank -text " "
      pack  .blank

      button .quit -text "Quit" -font mybold -command exit
      pack   .quit

  ObservedBehavior:
  If I hard code the 'filename', the 2nd window allows me to browse a file
      with both vertical and horizontal scrolling (and the Quit button works).
       If tk_getOpenFile is used to make this code dynamic, the appropriate
      file is opened, some data is displayed but the scroll bars are frozen
      and the quit
      button does not respond.

  DesiredBehavior:
  see #7


tkt_uuid: 793825ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 22. Style Engine
priority: 2
foundin: obsolete: 8.5a0
resolution: Wont Fix
title: Style engine crashes
comment:
  Tk_GetStyledElement() can return invalid
  Tk_StyledElements; when calling Tk_DrawElement it
  crashes due to a NULL pointer in
  widgetSpecPtr->elementPtr->specPtr.

  Details sketchy at this point... it seems that this is
  triggered by creating two or more StyledElements with
  different names.


tkt_uuid: 1794328fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: None
resolution: Rejected
title: Silence 64 bit type conversion warnings
comment:
  The attached patch silences the 64 bit porting warnings I get when building Tk with msvc8 for the Windows 64bit AMD64 target. On this platform size_t != long so there is quite a lot of cast truncations to be done. Tcl in general seems to use int for the size of most things.


tkt_uuid: 1159367fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 9 Immediate
foundin: obsolete: 8.4.9
resolution: Fixed
title: Crash/Core dump with bad color resource in option db
comment:
  The following code produces a core dump or crash on
  unix variants and on Windows with at least 8.4.9 and 8.4.8



  % option add *background coredump
  %  menu .m
  unknown color name "coredump"
  %  menu .m
  unknown color name "coredump"
  %  menu .m
  Segmentation fault (core dumped)


  This problem seems centered around the menu widget to
  some degree and appears to be the direct result of
  failling to create a menu widget because of an invalid
  color in the tk option  database. Note that core dump
  usually occurs while creating certain widgets after the
  menu widget has failed to be created.


tkt_uuid: 220462ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Stub Entries
priority: 2
foundin: None
resolution: Fixed
title: XParseColor missing in stub table
comment:
  OriginalBugID: 1574 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-22'
  LastModified: '1999-03-29'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: Windows NT
  OSVersion: 4.0 SP4
  Machine: X86
  FixedDate: '1999-03-29'
  FixedInVersion: 8.1b3


  Name:

  Jan Nijtmans



  CVS:

  21/MAR/1998 11:00



  Extensions:

  Img 1.2b1



  ReproducibleScript:

      A prototype for XParseColor() is missing in tkIntXlibDecls.h,

      still this function is provided by the X11 emulation layer.

      







  Patch:

  *** generic/tkInt.decls.origSat Mar 20 14:20:48 1999

  --- generic/tkInt.declsSat Mar 20 14:25:06 1999

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

  *** 1419,1424 ****

  --- 1419,1429 ----

    #      int clip_y_origin, XRectangle rectangles[], int n, int ordering)

    #  }

    

  + declare 82 win {

  +     Status XParseColor (Display *display, Colormap map, \

  +     _Xconst char* spec, XColor *colorPtr)

  + }

  + 

    # X functions for Mac

    

    # This slot is reserved for use by the dash patch:

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

  *** 1685,1687 ****

  --- 1690,1696 ----

        unsigned int height)

    }

    

  + declare 58 mac {

  +     Status XParseColor (Display *display, Colormap map, \

  +     _Xconst char* spec, XColor *colorPtr)

  + }









  PatchFiles:

      tkInt.decls

      









      I noticed this when trying to create a binary distribution for Img 1.2b1
      on Windows. This bug is fatal for Img. There is another problem with
      Tk8.1b2 in combination with Img, but that will be handled in a separate
      bug report.
  ----
  Look and see if there is an external Tk API that should be used instead of the X routine.
  03/26/1999 11:04 - surles -

  This function should be exported.   03/29/1999 12:14 - stanton -


tkt_uuid: 1336228fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 62. Geometry Functions
priority: 5 Medium
foundin: None
resolution: None
title: place / winfo problem
comment:
  Hi guys,

  I'm playing with some frames inside frames to obtain a
  functionality similar to MDI windows.

  Doing that I've detected that the commands place and
  winfo gives the result with a diference of 2 pixels.

  If

  array set placeInfo [place info $_Tk]
  set _NormY $placeInfo(-y)
  set _NormY2 [winfo y $_Tk]

  Then

  _NormY = _NormY2 + 2

  If you need more info don't hesitate to contact me.


tkt_uuid: 1814488fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5b2
resolution: Out of Date
title: unixWm test suite failures
comment:
  I'm building the tcl/tk cvs head (snapshot from activestate) on sparc solaris 9, using sun's c compiler. 
  I used ./configure --prefix=/projects/sprs_lwv/tcl85 --enable-shared --enable-symbols --enable-stubs --enable-64bit --enable-threads
  to build tcl and tk.

  The results of the test, which occurs consistently, are:
  unixWm.test

  ==== unixWm-4.1 moving window while withdrawn FAILED
  ==== Contents of test case:

          wm withdraw .t
          sleep 200
          wm geom .t $geom
          update
          wm deiconify .t
          wm geom .t
      
  ---- Result was:
  100x150+57+80
  ---- Result should have been (exact matching):
  100x150+20+80
  ==== unixWm-4.1 FAILED
  ==== unixWm-4.3 moving window while withdrawn FAILED
  ==== Contents of test case:

          wm withdraw .t
          sleep 200
          wm geom .t $geom
          update
          wm deiconify .t
          wm geom .t
      
  ---- Result was:
  100x150+57+39
  ---- Result should have been (exact matching):
  100x150+0+0
  ==== unixWm-4.3 FAILED
  ==== unixWm-25.1 Tk_WmCmd procedure, "iconname" option FAILED
  ==== Contents of test case:

      list [catch {wm icon .t} msg] $msg

  ---- Result was:
  1 {ambiguous option "icon": must be aspect, attributes, client, colormapwindows,
   command, deiconify, focusmodel, forget, frame, geometry, grid, group, iconbitma
  p, iconify, iconmask, iconname, iconphoto, iconposition, iconwindow, manage, max
  size, minsize, overrideredirect, positionfrom, protocol, resizable, sizefrom, st
  ackorder, state, title, transient, or withdraw}
  ---- Result should have been (exact matching):
  1 {ambiguous option "icon": must be aspect, attributes, client, colormapwindows,
   command, deiconify, focusmodel, frame, geometry, grid, group, iconbitmap, iconi
  fy, iconmask, iconname, iconphoto, iconposition, iconwindow, maxsize, minsize, o
  verrideredirect, positionfrom, protocol, resizable, sizefrom, stackorder, state,
   title, transient, or withdraw}
  ==== unixWm-25.1 FAILED
  ==== unixWm-39.1 Tk_WmCmd procedure, miscellaneous FAILED
  ==== Contents of test case:

      list [catch {wm unknown .t} msg] $msg

  ---- Result was:
  1 {bad option "unknown": must be aspect, attributes, client, colormapwindows, co
  mmand, deiconify, focusmodel, forget, frame, geometry, grid, group, iconbitmap, 
  iconify, iconmask, iconname, iconphoto, iconposition, iconwindow, manage, maxsiz
  e, minsize, overrideredirect, positionfrom, protocol, resizable, sizefrom, stack
  order, state, title, transient, or withdraw}
  ---- Result should have been (exact matching):
  1 {bad option "unknown": must be aspect, attributes, client, colormapwindows, co
  mmand, deiconify, focusmodel, frame, geometry, grid, group, iconbitmap, iconify,
   iconmask, iconname, iconphoto, iconposition, iconwindow, maxsize, minsize, over
  rideredirect, positionfrom, protocol, resizable, sizefrom, stackorder, state, ti
  tle, transient, or withdraw}
  ==== unixWm-39.1 FAILED
  ==== unixWm-48.13 ParseGeometry procedure, resize causes window to move FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200
      wm geom .t +0+0
      update
      wm geom .t -0-0
      update
      set x [winfo x .t]
      set y [winfo y .t]
      wm geometry .t 150x300
      update
      list [expr [winfo x .t] - $x] [expr [winfo y .t] - $y]  [winfo width .t] [wi
  nfo height .t]

  ---- Result was:
  0 0 150 300
  ---- Result should have been (exact matching):
  50 -100 150 300
  ==== unixWm-48.13 FAILED
  ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a toplevel, x-coords FAILE
  D
  ==== Contents of test case:

      deleteWindows
      toplevel .t -width 300 -height 400 -bg green
      wm geom .t +40+0
      tkwait visibility .t
      toplevel .t2 -width 100 -height 80 -bg red
      wm geom .t2 +140+200
      tkwait visibility .t2
      raise .t2
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing [expr $x - 30] [expr $y + 250]]  [winfo containing [e
  xpr $x - 1] [expr $y + 250]]  [winfo containing $x [expr $y + 250]]  [winfo cont
  aining [expr $x + 99] [expr $y + 250]]  [winfo containing [expr $x + 100] [expr 
  $y + 250]]  [winfo containing [expr $x + 199] [expr $y + 250]]  [winfo containin
  g [expr $x + 200] [expr $y + 250]]  [winfo containing [expr $x + 220] [expr $y +
   250]]

  ---- Result was:
  {} {} .t .t .t .t .t .t
  ---- Result should have been (exact matching):
  {} {} .t {} .t2 .t2 {} .t
  ==== unixWm-50.1 FAILED

  ==== unixWm-50.8 Tk_CoordsToWindow procedure, more basics FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 400 -height 300 -bg green
      wm geom .t +0+0
      frame .t.f -width 200 -height 100 -bd 2 -relief raised
      place .t.f -x 100 -y 100
      frame .t.f.f -width 200 -height 100 -bd 2 -relief raised
      place .t.f.f -x 100 -y 0
      update
      set x [winfo rooty .t]
      set y [expr [winfo rooty .t] + 150]
      list [winfo containing [expr $x + 50] $y]  [winfo containing [expr $x + 150]
   $y]  [winfo containing [expr $x + 250] $y]  [winfo containing [expr $x + 350] $
  y]  [winfo containing [expr $x + 450] $y]

  ---- Result was:
  .t.f .t.f.f .t {} {}
  ---- Result should have been (exact matching):
  .t .t.f .t.f.f .t {}
  ==== unixWm-50.8 FAILED

  ==== unixWm-50.10 Tk_CoordsToWindow procedure, unmapped windows FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      frame .t.f -width 150 -height 150 -bd 2 -relief raised
      place .t.f -x 25 -y 25
      tkwait visibility .t.f
      set result [list [winfo containing 100 100]]
      place forget .t.f
      update
      lappend result [winfo containing 100 100]

  ---- Result was:
  .t .t
  ---- Result should have been (exact matching):
  .t.f .t
  ==== unixWm-50.10 FAILED


tkt_uuid: 2540465fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: Duplicate
title: Tk_MainWindow error message formatting nit
comment:
  If wish is called and DISPLAY is not set (or set incorrectly), Tk_MainWindow returns an error message that looks like this:

  Application initialization failed: this isn't a Tk applicationcouldn't connect to display "srv29:0.0"
  Error in startup script: this isn't a Tk applicationcouldn't connect to display "srv29:0.0"
      while executing
  "load /usr/tcl84/lib/tk8.4g/../libtk8.4g.so Tk"
      ("package ifneeded" script)
      invoked from within
  "package require Tk "
      (file "/ldatae/clearcase/upgrade7/MultiFig/n098/u10k/lib/MFigPGUI/main.tcl" line 2)
      invoked from within
  "source "$u10k/lib/MFigPGUI/main.tcl""
      (file "/cas/bin/sun4/mfigp" line 39)


  A colon at the end of "this isn't a Tk application" would make the error message slightly better.

  I wonder, as well, if the message shouldn't be "this application couldn't instantiate Tk:" ...


tkt_uuid: 3588158fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 9 Immediate
foundin: obsolete: 8.5.13
resolution: Fixed
title: tk: NSApplicationPresentationAutoHideDock undeclared
comment:
  tk fails to upgrade from version 8.5.12 to 8.5.13 and returns the following errors building object tkMacOSXWm.o:
  .../tk8.5.13/unix/../macosx/tkMacOSXWm.c:6332: error: ‘NSApplicationPresentationAutoHideDock’ undeclared (first use in this function)
  .../tk8.5.13/unix/../macosx/tkMacOSXWm.c:6332: error: (Each undeclared identifier is reported only once
  .../tk8.5.13/unix/../macosx/tkMacOSXWm.c:6332: error: for each function it appears in.)
  .../tk8.5.13/unix/../macosx/tkMacOSXWm.c:6332: error: ‘NSApplicationPresentationAutoHideMenuBar’ undeclared (first use in this function)

  Version Information:

  Mac OS Version:
  ProductName:Mac OS X
  ProductVersion:10.5.8
  BuildVersion:9L31a
  Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

  Xcode Version:
  Xcode 3.1.4
  Component versions: DevToolsCore-1204.0; DevToolsSupport-1186.0
  BuildVersion: 9M2809

  See MacPorts ticket #37016 https://trac.macports.org/ticket/37016 for additional information.


tkt_uuid: 2848897fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 6
foundin: None
resolution: Accepted
title: ODS_NOACCEL flag support
comment:
  One of user-configurable features of win2000 and above is "Hide keyboard navigation indicators until I press the Alt key", and Tk ignored it for a long time. Menu bars, as they are drawn by the system, behaved as configured, but owner-draw entries were underlined independently of this setting.

  This patch adds checking for ODS_NOACCEL flag in the menu window procedure, so the setting referred to above is obeyed by Tk.


tkt_uuid: 2054562fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: native sashcursors on MacOS X
comment:
  ttk doesn't use the native sashcursors on MacOS X (with Tk 8.5.3). Furthermore, "southeast" resizing uses the arrow cursor there. The fix is simply to adjust the Cursors array in ttk/cursors.tcl:

  <snip>
  "unix" -
  * {
  if {$::tcl_platform(os) == "Darwin"} {
  array set Cursors {
  hresize resizeleftright
  vresize resizeupdown
  seresizearrow
      }
  } else {
      array set Cursors {
  hresize sb_h_double_arrow
  vresize sb_v_double_arrow
  seresizebottom_right_corner
      }
      }
  }
  </snip>


  Cheers,
  Reinhold Straub
  demarchie@web.de


tkt_uuid: 1202223fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: TkAqua: text image embedding locks scrollbars
comment:
  After fixing two other scrolling bugs, 1202181 and
  1083728, I found one more.  When a text widget has
  embedded images, dragging a scrollbar to a point where
  the image is shown causes the scrollbar to lock so that
  it won't drag anymore until the mouse button is
  released and pressed again.

  The reason for this turns out to be because PtInRect()
  will only return true if the point and the rect are in
  the same graphics port, and TkMacOSXXGetPixel() and
  TkMacOSXXSetPixel() set the graphics port but neither
  they nor the loop in ThumbActionProc() restore it.  So
  once an image is drawn while scrolling, the code branch
  that handles delta calculations is never entered again
  until the port is restored.

  The attached patch versus core-8-4-branch fixes the
  bug.  With this patch, 1202181 and 1083728, scrollbars
  seem to behave properly in my cases, aside from the
  text-widget-specific line counting issues that I
  allegedly fixed in 8.5.


tkt_uuid: 438732ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Out of Date
title: CRITICAL core dump upon startup
comment:
  After downloading the July 4th snapshot of 8.4a3
  and compiling it on my SPARC Solaris 2.6 system (with
  Sun's v 5.1 C compiler, 
  I find that I get a BUS error core dump.  Here's
  the stack trace:
   $ dbx $(whence wish) core
  Reading wish
  core file header read successfully
  Reading ld.so.1
  Reading libtk8.4.so
  Reading libtcl8.4.so
  Reading libsocket.so.1
  Reading libnsl.so.1
  Reading libX11.so.4
  Reading libdl.so.1
  Reading libm.so.1
  Reading libc.so.1
  Reading libmp.so.2
  Reading libXext.so.0
  Reading libdga.so.1
  Reading libc_psr.so.1
  program terminated by signal BUS (invalid address
  alignment)
  (dbx 1)
  where                                                  
  =>[1] HashArrayKey(0x385a8, 0x9800005, 0x2e130,
  0x4e0c8, 0x0, 0x0), at 0xff1d6cb0
    [2] Tcl_FindHashEntry(0xff22feb8, 0x9800005, 0x385a8,
  0x9800005, 0x1, 0x1), at 0xff1d6218
    [3] CreateWrapper(0x4e070, 0xff354e64, 0x3e2a8,
  0x3e388, 0xffbed574, 0x385ac), at 0xff2e05f4
    [4] TkWmMapWindow(0x3e388, 0xff354e64, 0x3e2a8,
  0xff3e2628, 0x0, 0x0), at 0xff2da390
    [5] Tk_MapWindow(0x3e2a8, 0xff228c0c, 0x22c90, 0x0,
  0x22ca8, 0x1), at 0xff2c8ee0
    [6] MapFrame(0x4df08, 0x4df08, 0xff228c0c, 0x22ed4,
  0x22e54, 0xffbed660), at 0xff2e9114
    [7] TclServiceIdle(0x0, 0x0, 0x2d138, 0x2fe68,
  0xfffffffd, 0x0), at 0xff1fdf24
    [8] Tcl_DoOneEvent(0x0, 0xff228c0c, 0x22c90, 0x0,
  0x22ca8, 0x1), at 0xff1ec9f0
    [9] Tk_MainLoop(0x22fe0, 0xff228c0c, 0x4, 0x0,
  0x22fe0, 0xff228c0c), at 0xff2afaac
    [10] Tk_MainEx(0xff366258, 0x2bde0, 0x0, 0x22fe0,
  0xff354e64, 0x10c04), at 0xff2bc138
    [11] main(0x1, 0xffbed9d4, 0x1, 0x20d90, 0x0, 0x0),
  at 0x10be4
  (dbx 2) 


tkt_uuid: 776646ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: None
resolution: Fixed
title: cursor incompatabilities
comment:
  Originally submitted as a Tcl FR by rox - moved to Tk.

   the native pointer in X is "left_ptr" and in windows is
  "arrow". i suggest remapping the cursors so that arrow
  is the native pointer on all platforms

  the fleur/move cursor does not have the native
  appearance in windows

  there is no native hand (hyperlink) cursor spec in
  windows. it should be easy to add a mapping for hand2
  to IDC_HAND.

  the documentation says the "size" cursor is available
  in windows but i got an error when trying to use it in
  my 8.4.2 tclkit.

  all X cursors are available under windows as tk has
  them built in. however the windows cursors are not
  available on other platforms which can cause errors. i
  would suggest mapping the windows cursor names to their
  similar X names when running in X.


tkt_uuid: 220567ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: Abbreviated Tk commands don't work with iWidgets
comment:
  OriginalBugID: 2422 Bug
  Version: 8.0.5
  SubmitDate: '1999-07-20'
  LastModified: '1999-08-10'
  Severity: CRIT
  Status: Released
  Submitter: jenn
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  FixedDate: '1999-08-10'
  FixedInVersion: 8.2
  ClosedDate: '1999-08-05'


  Name:  Krzysztof Kozminski

  CVS:  RCS: @(#) $Id: tk.tcl,v 1.6 1999/01/04 19:25:27 rjohnson Exp $

  ReproducibleScript:
      There is no simple way to reproduce it.  But the fix is trivial.
      

  ObservedBehavior:
      In my application, Tk widget commands are hidden and replaced by Itcl
      classes with the same names; these are loosely based on Itk classes but,
      unlike Itk, they retain all Tk widget's attributes and methods (and have
      some additional ones).  For example, an Itcl class 'entry' has methods
      named bbox, cget, configure, delete, etc.  All that Itcl methods
      "inherited" from Tk widgets do, is pass the arguments to the Tk widgets
      associated with the Itcl object ($itk_hull in Itk).
      
      Unfortunately, while Tk widget methods can be abbreviated, Itcl object
      method do not seem to have this property.  So if I have, e,g. Tk entry
      .a-itk_hull and a corresponding Itcl object .a, I can do:
      
      .a-itk_hull icur end
      
      but the .a object requires full method name:
      
      .a icursor end.
      
      This breaks any code where the programmer was too lazy to type the full
      name of a Tk widget method.  The first example of this is in the
      aforementioned file (tk8.0/tk.tcl), in the procedure tkTabToWindow.
      

  DesiredBehavior:
      I expect the code in the tcl libraries to have Tk widgets methods
      spelled out in full.
      

  Patch:
  *** /tmp/tk.tcl Tue Jul 13 10:41:35 1999
  --- tk.tcl  Mon Jul 12 18:55:03 1999
  ***************
  *** 186,193 ****
    
    proc tkTabToWindow {w} {
        if {"[winfo class $w]" == "Entry"} {
  !   $w select range 0 end
  !   $w icur end
        }
        focus $w
    }
  --- 186,193 ----
    
    proc tkTabToWindow {w} {
        if {"[winfo class $w]" == "Entry"} {
  !   $w selection range 0 end
  !   $w icursor end
        }
        focus $w
    }


  Comments:
      In case you're wondering why this was done, I wanteded to be able to
      extend the behavior of Tk widgets, including those in various public
      extensions (e.g. file selection dialog), without editing the code of the
      public extension each time it is updated.
      


  This problem are fixed in 8.2b3. 
  -- 08/10/1999 hobbs


tkt_uuid: 220005ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 1 Zero
foundin: final: 8.1.1
resolution: Duplicate
title: Unicode support fails horribly on systems with Adobe G2 fonts
comment:
  OriginalBugID: 2405 Bug
  Version: 8.1.1
  SubmitDate: '1999-07-19'
  LastModified: '1999-08-04'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2406
  OS: Windows 95
  OSVersion: OSR3 + IE 5.0 (hence, it's effectively WIN98)
  Machine: X86
  ClosedDate: '1999-08-04'


  Name:

  Kevin Kenny



  CVS:

  * RCS: @(#) $Id: tkWinFont.c,v 1.5 1999/04/16 01:51:51 stanton Exp $



  Extensions:

  None relevant



  CustomShell:

  Patched as above.



  Comments:

  The problem lies in the fact that symbol fonts use the vendor-defined

      code range in Unicode, F000-FDFF.  This code range is used because these

      fonts

      define non-Unicode glyphs, and hence contain characters for which there

      is

      no correct Unicode encoding.

      

      The code in tkWinFont.c attempts to solve this problem by pretending

      that the

      code range F000-F0FF is equivalent to 0000-00FF, so that the Microsoft

      "Symbol"

      font can be displayed by using 8-bit characters.  Unfortunately, a

      symbol font

      containing higher-order characters will fail.

      

      In particular, the "Times New Roman Special G2" font contains the

      character

      ranges:  F020-F10E, F110-F112, F241-F25A, F260-F27B, and the end

      sentinel

      FFFF-FFFF.  The problem arises because the code in tkWinFont.c as it

      stands

      makes the first range into 0020-F10E; the result is that the font is

      thought

      to contain all printable Unicode characters, and a good many

      hypothetical

      ones to boot!  The patch changes the mapping so that all ranges between

      F000

      and FFFF and mapped down to 0000 through 0FFF.

      

      This approach is formally incorrect; a better approach would be to

      require

      users of the "Symbol" font to use the vendor-defined codes; hence, to

      get

      a label with a "Symbol" version of a "there-exists" sign, one would have

      to

      do

      

      grid [label .exists -text \uf024 -font {Symbol 24}]

      

      instead of

      

      grid [label .exists -text \$ -font {Symbol 24}]

      

      Unfortunately, this decision would break a good deal of existing code;

      hence, I wouldn't recommend it.



  ReproducibleScript:

  # On a Win95 system whose font configuration includes the Adobe G2

      fonts,

      # such as "Times New Roman Special G2", and has one of these fonts ahead

      of

      # a CJK font in the sequence returned from EnumFontFamilies, any attempt

      to

      # display CJK text will fail.  The test case is a simple program like

      

      grid [button .taiku -text "\u592a\u9177" -command exit]



  ObservedBehavior:

  The button contains two rectangles for characters not found.



  DesiredBehavior:

  Obvoiusly, the button should contain the Chinese phrase, "tai ku."



  Patch:

  *** Tcl8.1\src\tk8.1\win\tkWinFont.cThu Apr 29 15:38:42 1999

  --- Tcl8.1-from-source\src\tk8.1\win\tkWinFont.cSat Jul 17 16:26:26 1999

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

  *** 2295,2306 ****

  --- 2295,2315 ----

         */

    

        for (i = 0; i < segCount; i++) {

  + #ifdef AS_SHIPPED

    if ((startCount[i] & 0xff00) == 0xf000) {

        startCount[i] &= 0xff;

    }

    if ((endCount[i] & 0xff00) == 0xf000) {

        endCount[i] &= 0xff;

    }

  + #else

  + if ((startCount[i] >= 0xf000)) {

  +   startCount[i] -= 0xf000;

  + }

  + if ((endCount[i] >= 0xf000)) {

  +   endCount[i] -= 0xf000;

  + }

  + #endif

        }

    }

        }



  PatchFiles:

  tkWinFont.c


tkt_uuid: 1862692fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Duplicate
title: ttk::treeview does not scroll up via mousewheel on OS-X
comment:
  using ActiveTcl 8.5 on OS-X Leopard x86, I can not scroll upwards via the mouse wheel. To reproduce, please try:

  package re Tk
  ttk::treeview .tv
  ttk::scrollbar .sb -command ".tv yview" -orient vert
  ..tv configure -yscrollcommand ".sb set"
  pack .tv .sb -side left -fill y
  for {set i 0} {$i < 100} {incr i} {
      .tv insert "" $i -text "node $i"
  }

  Then click inside the treeview and move the mouse wheel... normally (on Windows, Linux) the treeview is scrolled up and down, but my experience is that only the scrolling down works. This is only for ttk::treeview (as far as I see... text works) and for both, ttk::scrollbar and tk::scrollbar. So I suspect the troublemaker is ttk::treeview.


tkt_uuid: 3001403fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: Wish crash on Windows XP when trying to free a color
comment:
  Hello,

  Using a tool emulating an msdos console (dosbox) in order to play old games. This tool change the colormap of the display.
  I launch amsn, after what i launch this tool. Then an error message is displayed saying "Tried to free a color that isn't allocated."

  I report the bug to the amsn team, which explain me it's linked to tcl/tk library -> http://www.amsn-project.net/forums/index.php/topic,7910.msg46589.html

  This bug appears already occur on version 8.4 -> http://sourceforge.net/tracker/?func=detail&aid=1708823&group_id=12997&atid=112997
  and on previous version too ? -> http://lists.jabber.ru/pipermail/tkabber/2003-February/000085.html

  Regards,
  Anael


tkt_uuid: 220052ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Duplicate
title: Patch still required for Tk 8.2.2 to avoid crashing when deleting top level windows using Tix
comment:
  OriginalBugID: 3872 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-13'
  LastModified: '1999-12-21'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 716
  OS: IRIX
  OSVersion: IRIX 6.5
  Machine: Origin 2000, Octanes
  ClosedDate: '1999-12-21'


  Name:

  Rob Ratcliff


  Extensions:

  Tix, Incr Tcl/Tk, sox


  CustomShell:

  Only the patch described above


  ReproducibleScript:

  The tixwish interpretter crashed sometimes when a toplevel window

  (popup) is deleted.


  I haven't been able to duplicate the problem in a small application

  to attach, but it does happen reliably, sometimes after deleting

  the problematic popup window 2-3 times.


  ObservedBehavior:

  Sometimes, when a toplevel window is deleted tixwish crashes

  with the error: 


  X Error of failed request:  BadWindow (invalid Window parameter)

    Major opcode of failed request:  40 (X_TranslateCoords)

    Resource id in failed request:  0x1c002b6

    Serial number of failed request:  34982

    Current serial number in output stream:  34982


  DesiredBehavior:

  Toplevel window is destroyed without crashing interpretter


  Patch:

  *** tkUnixWm.c.origThu Apr 15 18:51:47 1999

  --- tkUnixWm.cMon Dec 13 13:49:55 1999

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

  *** 3489,3494 ****

  --- 3489,3495 ----

        int x, y, childX, childY, tmpx, tmpy, bd;

        WmInfo *wmPtr;

        TkWindow *winPtr, *childPtr, *nextPtr;

  +     Tk_ErrorHandler handler;

        TkDisplay *dispPtr = ((TkWindow *) tkwin)->dispPtr;


        /*

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

  *** 3528,3539 ****

         *    the toplevel.

         */


        while (1) {

    if (XTranslateCoordinates(Tk_Display(tkwin), parent, window,

    x, y, &childX, &childY, &child) == False) {

  !     panic("Tk_CoordsToWindow got False return from XTranslateCoordinates");

    }

    if (child == None) {

        return NULL;

    }

    for (wmPtr = (WmInfo *) dispPtr->firstWmPtr; wmPtr != NULL; 

  --- 3529,3546 ----

         *    the toplevel.

         */


  +     handler = Tk_CreateErrorHandler(Tk_Display(tkwin), -1, -1, -1,

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

        while (1) {

    if (XTranslateCoordinates(Tk_Display(tkwin), parent, window,

    x, y, &childX, &childY, &child) == False) {

  !     fprintf (stderr, "Tk_CoordsToWindow got False return from XTranslateCoordinates\n");

  !     fflush (stderr);

  !     return NULL;

  !     /* panic("Tk_CoordsToWindow got False return from XTranslateCoordinates"); */

    }

    if (child == None) {

  +     Tk_DeleteErrorHandler(handler);

        return NULL;

    }

    for (wmPtr = (WmInfo *) dispPtr->firstWmPtr; wmPtr != NULL; 

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

  *** 3556,3561 ****

  --- 3563,3569 ----

        }


        gotToplevel:

  +     Tk_DeleteErrorHandler(handler);

        winPtr = wmPtr->winPtr;

        if (winPtr->mainPtr != ((TkWindow *) tkwin)->mainPtr) {

    return NULL;


  PatchFiles:

  unix/tkUnixWm.c


tkt_uuid: 2542828fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: None
resolution: Accepted
title: Windows native 'question_arrow' cursor
comment:
  On Windows, Tk uses an ugly built-in bitmap for the 'question_arrow' cursor. This while Windows actually has a native cursor for this: IDC_HELP.
  Attached is a small patch to support the IDC_HELP cursor.


tkt_uuid: 220332ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: author gets into bad state with exceptional project name
comment:
  OriginalBugID: 5181 Bug
  Version: 2.0b5
  SubmitDate: '2000-04-19'
  LastModified: '2000-05-12'
  Severity: CRIT
  Status: Released
  Submitter: key
  ChangedBy: angie
  OS: Solaris
  FixedDate: '2000-04-19'
  FixedInVersion: 2.0b7


  steps to reproduce:
  1)  create a new project named "foobar\"
  2)  create URL action
  3)  create XML generator attached to URL action

  expected result:
  nothing exceptional

  actual result:
  get error message:
  An error occurred in the XMLGenerator setValue method:
  no files match glob pattern "$pwd/foobar\/dtd"

  after dismissing the dialog there is a stacktrace.  at this point the author looks locked up.

  note:
  nt doesn't allow this kind of filename/projectname



  This bug is actually a bug in tk_getOpenFile when it is started with
  an '-initialdir' that has the backslash at the end of a directory
  like this one does. 
  -- 04/19/2000 kuchler
  This is fixed for the 8.3.1 release (putback before Connect 2.0b7).
  An extra glob was being done on -initialdir, although we had already
  done a file isdir check.  This was removed. 
  -- 04/19/2000 hobbs

  Integrated on Solaris/Linux/NT build 2015 
  -- 05/12/2000 angie


tkt_uuid: 413913ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 7 High
foundin: obsolete: 8.4a2
resolution: Fixed
title: SIGSEGV in listbox-27.1
comment:
  Stack trace isn't helpful:

  Program received signal SIGSEGV, Segmentation fault.
  0x20000170f28 in _XFlushInt () from
  /usr/X11R6/lib/libX11.so.6
  (gdb) bt
  #0  0x20000170f28 in _XFlushInt () from
  /usr/X11R6/lib/libX11.so.6
  #1  0x20000170eb8 in _XFlush () from
  /usr/X11R6/lib/libX11.so.6
  #2  0x20000170eb8 in _XFlush () from
  /usr/X11R6/lib/libX11.so.6
  Cannot access memory at address 0x1202edffc

  After placing the "obvious" Tcl_Preserve() and
  Tcl_Release() calls in DisplayListBox():

  Program received signal SIGSEGV, Segmentation fault.
  0x12003b380 in Tk_FreeCursor (display=0x2000076f118,
  cursor=0x34000e8)
      at
  /home/dgp/src/tk8.3/unix/../generic/tkCursor.c:526
  526         if (!dispPtr->cursorInit) {
  (gdb) bt
  #0  0x12003b380 in Tk_FreeCursor
  (display=0x2000076f118, cursor=0x34000e8)
      at
  /home/dgp/src/tk8.3/unix/../generic/tkCursor.c:526
  #1  0x120039cb4 in FreeResources
  (optionPtr=0x12040d9c0, objPtr=0x0, 
      internalPtr=0x1204308a0 "è", tkwin=0x1203f9740)
      at
  /home/dgp/src/tk8.3/unix/../generic/tkConfig.c:1608
  #2  0x1200399cc in Tk_FreeConfigOptions
  (recordPtr=0x120430790 "@\227? \001", 
      optionTable=0x12040d8e0, tkwin=0x1203f9740)
      at
  /home/dgp/src/tk8.3/unix/../generic/tkConfig.c:1511
  #3  0x12007d704 in DestroyListbox (memPtr=0x120430790
  "@\227? \001")
      at
  /home/dgp/src/tk8.3/unix/../generic/tkListbox.c:1451
  #4  0x12018f990 in Tcl_Release (clientData=0x120430790)
      at ./../generic/tclPreserve.c:241
  #5  0x12007dee8 in DisplayListbox
  (clientData=0x120430790)
      at
  /home/dgp/src/tk8.3/unix/../generic/tkListbox.c:1778
  #6  0x12019b6cc in TclServiceIdle () at
  ./../generic/tclTimer.c:692
  #7  0x1201817a8 in Tcl_DoOneEvent (flags=34) at
  ./../generic/tclNotify.c:923
  #8  0x1200f8a60 in Tk_UpdateObjCmd
  (clientData=0x120370030, 
      interp=0x120319310, objc=2, objv=0x11fffdb50)
      at /home/dgp/src/tk8.3/unix/../generic/tkCmds.c:889
  #9  0x120185810 in EvalObjv (interp=0x120319310,
  objc=2, objv=0x11fffdb50, 
      command=0x1203fb8af "    update idle\n    winfo
  exists .l\n", length=36, 
      flags=0) at ./../generic/tclParse.c:932
  #10 0x120186424 in Tcl_EvalEx (interp=0x120319310, 
      script=0x1203fb840 "\n    destroy .l\n    pack
  [listbox .l]\n    update\n   
   .l configure -cursor xterm -xscrollcommand { destroy
  .l }\n    update idle\n   
   winfo exists .l\n", numBytes=147, flags=262144)
      at ./../generic/tclParse.c:1393
  #11 0x120115f60 in Tcl_EvalObjEx (interp=0x120319310,
  objPtr=0x120417df0, 
      flags=262144) at ./../generic/tclBasic.c:2580
  #12 0x120190d04 in Tcl_UplevelObjCmd (dummy=0x0,
  interp=0x120319310, objc=1, 
      objv=0x12031aa98) at ./../generic/tclProc.c:604
  #13 0x12014b63c in TclExecuteByteCode
  (interp=0x120319310, codePtr=0x1203fc260)
      at ./../generic/tclExecute.c:873
  #14 0x120116324 in Tcl_EvalObjEx (interp=0x120319310,
  objPtr=0x120405500, 
      flags=0) at ./../generic/tclBasic.c:2733
  #15 0x1201917b4 in TclObjInterpProc
  (clientData=0x1203ff8a0, 
      interp=0x120319310, objc=5, objv=0x11fffe990)
      at ./../generic/tclProc.c:1001
  #16 0x12017d03c in InvokeImportedCmd
  (clientData=0x120419480, 
      interp=0x120319310, objc=5, objv=0x11fffe990)
      at ./../generic/tclNamesp.c:1468
  #17 0x120185810 in EvalObjv (interp=0x120319310,
  objc=5, objv=0x11fffe990, 
      command=0x1203f63f6 "\ntest listbox-27.1 {widget
  deletion while active} {\n 
     destroy .l\n    pack [listbox .l]\n    update\n   
  .l configure -cursor xterm
   -xscrollcommand { destroy .l }\n    update idle\n   
  winfo exists .l\n} "..., 
      length=277, flags=0) at ./../generic/tclParse.c:932
  #18 0x120186424 in Tcl_EvalEx (interp=0x120319310, 
      script=0x1203e69c0 "# This file is a Tcl script to
  test out the \"listbox\" 
  command\n# of Tk.  It is organized in the standard
  fashion for Tcl tests.\n#\n# 
  Copyright (c) 1993-1994 The Regents of the University
  of California.\n"..., 
      numBytes=64331, flags=0) at
  ./../generic/tclParse.c:1393
  #19 0x120175508 in Tcl_EvalFile (interp=0x120319310, 
      fileName=0x12037a5d0 "./../tests/listbox.test")
      at ./../generic/tclIOUtil.c:323
  #20 0x1201298b4 in Tcl_SourceObjCmd (dummy=0x0,
  interp=0x120319310, objc=2, 
      objv=0x12031aa80) at ./../generic/tclCmdMZ.c:858
  #21 0x12014b63c in TclExecuteByteCode
  (interp=0x120319310, codePtr=0x1203cf350)
      at ./../generic/tclExecute.c:873
  #22 0x120116324 in Tcl_EvalObjEx (interp=0x120319310,
  objPtr=0x1203859f0, 
      flags=131072) at ./../generic/tclBasic.c:2733
  #23 0x12015ee64 in Tcl_RecordAndEvalObj
  (interp=0x120319310, 
      cmdPtr=0x1203859f0, flags=131072) at
  ./../generic/tclHistory.c:142
  #24 0x12015ec18 in Tcl_RecordAndEval
  (interp=0x120319310, 
      cmd=0x120326358 "source ./../tests/listbox.test\n",
  flags=131072)
      at ./../generic/tclHistory.c:62
  #25 0x12004a310 in StdinProc (clientData=0x120380310,
  mask=2)
      at /home/dgp/src/tk8.3/unix/../generic/tkMain.c:356
  #26 0x12016cecc in Tcl_NotifyChannel
  (channel=0x120380310, mask=2)
      at ./../generic/tclIO.c:6139
  #27 0x1201b7adc in FileHandlerEventProc
  (evPtr=0x12038f020, flags=-3)
      at ./../unix/tclUnixNotfy.c:624
  #28 0x120181160 in Tcl_ServiceEvent (flags=-3) at
  ./../generic/tclNotify.c:607
  #29 0x120181770 in Tcl_DoOneEvent (flags=-3) at
  ./../generic/tclNotify.c:910
  #30 0x12003d5e4 in Tk_MainLoop ()
      at
  /home/dgp/src/tk8.3/unix/../generic/tkEvent.c:1257
  #31 0x12004a11c in Tk_MainEx (argc=1, argv=0x11ffff448, 
      appInitProc=0x120025920 <Tcl_AppInit>,
  interp=0x120319310)
      at /home/dgp/src/tk8.3/unix/../generic/tkMain.c:285
  #32 0x1200258f8 in main (argc=1, argv=0x11ffff448)
      at /home/dgp/src/tk8.3/unix/tkAppInit.c:77

  So what is the non-obvious, correct fix?


tkt_uuid: 220187ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: X-Resources not properly read by AddFromString
comment:
  OriginalBugID: 2001 Bug
  Version: 8.0.3
  SubmitDate: '1999-05-06'
  LastModified: '2000-01-03'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux-Red Hat
  Machine: Other
  ClosedDate: '2000-01-03'


  Name:
  Harald

  ObservedBehavior:
  The BWidget toolkit uses resource-class names patterned after 
      namespace names like `Tree::Node'. To set e.g. the fill color for a node
      from within e.g. .Xdefaults one has to enter something like:
      
        *Tree::Node.fill: blue
      
      However, Tk always understands the very first `:' as the separator, 
      independent of any backslashes. Therefore it is impossible to set the
      given resource.
      
      I don't know if it is really a fault of Tk or if it is rather a fault
      of BWidget to use said resource names.



  This is a BWidgets bug.  According to X11(7), the resource name
  may not contain a ':' character.  See that man page, the Resources
  section, for the exact allowed syntax. 
  -- 01/03/2000 hobbs


tkt_uuid: 1626415fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Text widget documentation bug
comment:
  The text widget documentation says:

  Command-Line Name: -inactiveselectionbackground 
  Database Name: inactiveSelectionBackground 
  Database Class: Foreground 
  Specifies the colour to use for the selection (the sel tag) when the window does not have the input focus. If empty, {}, then no selection is shown when the window does not have the focus. 


  Actually the -inactiveselectionbackground does not exist.

  Correct spelling is -inactiveselectbackground

  Don't know whether the database name is correct or not.

  Francois


tkt_uuid: 220502ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 57. [option]
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: Docs missing for Tk_AddOption API
comment:
  OriginalBugID: 1854 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 a man page for this function for 8.3.1.

  - eric
   
  -- 04/24/2000 ericm


tkt_uuid: 220304ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: canvas command "postscript" generates almost-empty files
comment:
  OriginalBugID: 5523 Bug
  Version: 8.3
  SubmitDate: '2000-05-16'
  LastModified: '2000-05-17'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: HP-UX hpp020 B.10.20 A 9000/712
  ClosedDate: '2000-05-17'


  Name:
  Paul Sievers

  Extensions:
  tix.4.1.0

  CustomShell:
  None

  ReproducibleScript:
  set w .w5
  wm withdraw .
      toplevel $w
      wm title $w "data5"

      wm geometry   $w =600x600

  canvas .w5.msc    -width 288 -height 51        -background white 

  .w5.msc create rectangle 0 3 436 17 -fill lightyellow -outline lightyellow
  .w5.msc create text 2  4 -anchor nw -text "CB121VF\CP_P_EXEC_SFF_TRANSITION         CSF513D" -font -misc-fixed-bold-r-normal--15-120-100-100-c-90-iso8859-1 -fill black
  .w5.msc create rectangle 138 18 142 32 -fill white -outline white
  .w5.msc create text 140  19 -anchor nw -text "" -font -misc-fixed-bold-r-normal--15-120-100-100-c-90-iso8859-1 -fill black
  .w5.msc create line 189 38 90 38  -width 3  -arrow last -arrowshape {9 9 4} -fill black
  pack $w.msc  -side top    -fill both
      $w.msc postscript    -file "/tmp/bad12" -pagex 0.i -pagey 10.i -pageanchor nw
  The command line was: wish tiny.tcl

  ObservedBehavior:
  The generated postscript file  "/tmp/bad12"  is "almost-empty"
  The text "CB121VF\CP_P_EXEC_SFF_ ..." does not appear in the file.
  The bounding box has only 2x3 pixels, as can be seen from the line:
  %%BoundingBox: 0 719 1 721
  in file  "/tmp/bad12".

  DesiredBehavior:
  When printing the postscript file, I'd like to see graphics that look like the canvas on the screen.




  After customer submitted this bug he sent another reply:

  Ok. It's not really a bug. Using options -width and -heigth
  solves the problem.

  Bye
  Paul Sievers
   
  -- 05/16/2000 angie

  A note for using the above is also recommended in the docs
  of the canvas postscript command, so that's probably what
  the user needs to use more liberally. 
  -- 05/17/2000 hobbs


tkt_uuid: 505159ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: TIP 27: tcl{FileName,Result,Var}.c callers
comment:
  Attached patch updates callers of Tcl interfaces
  changed by Tcl Patch 505072.  When that is committed,
  commit this too.


tkt_uuid: 3516768fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 8
foundin: obsolete: 8.5.10
resolution: Invalid
title: Latest Tk head fails to compile in debug mode
comment:
  Compiling in Win XP, MinGW, Latest Tcl and Tk head 8.5.11;
  The release compiles fine, but when using debug switch --enable-symbos it fails using the stdint.h.

  gcc -c -g -Wall  -I"./../generic" -I"." -I"./../xlib" -I"./../bitmaps" -I"/e/CM.git/tcltk85/dcompile/tcl/generic" -I"/e/
  CM.git/tcltk85/dcompile/tcl/win" -pipe -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRIN
  G=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_ST
  AT_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 -D
  HAVE_UNISTD_H=1 -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int -DHAVE_WINNT_IGNORE_VOID=1 -DHAVE_CAST_TO_UNION=1 -DHAVE_UXT
  HEME_H=1 -DTCL_CFG_DEBUG=1  -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPA
  CKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1 -DTCL_CFGVAL_ENCODING=\"cp1252\" -DHAVE_SYS_T
  YPES_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_NO_SEH=1 -DEXCEPTION_DISPOSITION=int -DHAVE_WINNT_IGNORE_VOID=1 -DHAVE_CAST
  _TO_UNION=1 -DHAVE_INTPTR_T=1 -Duintptr_t=unsigned\ int -DTCL_CFG_DEBUG=1  -DUSE_TCL_STUBS -DBUILD_tk -DBUILD_ttk "./../
  generic/tkMain.c" -o tkMain.o
  In file included from d:\programs\mingw\bin\../lib/gcc/mingw32/4.6.2/include/stdint.h:3:0,
                   from d:\programs\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include/process.h:18,
                   from e:/CM.git/tcltk85/dcompile/tcl/win/tclWinPort.h:61,
                   from e:/CM.git/tcltk85/dcompile/tcl/generic/tclPort.h:21,
                   from e:/CM.git/tcltk85/dcompile/tcl/generic/tclInt.h:36,
                   from ./../generic/tkMain.c:17:
  d:\programs\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include/stdint.h:75:24: error: duplicate 'unsigned'
  d:\programs\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include/stdint.h:75:24: error: two or more data types in decl
  aration specifiers
  make: *** [tkMain.o] Error 1


tkt_uuid: 220360ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: tk_getOpenFile -multiple
comment:
  OriginalBugID: 604 RFE
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '2000-06-23'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: ericm
  RelatedBugIDs: 5496
  OS: All
  FixedDate: '2000-06-23'
  FixedInVersion: 8.4a2


  This patch adds support for a -multiple option to tk_getOpenFile.  If

  tk_getOpenFile is used with the argument -multiple 1, then it permits

  multiple files to be selected, and returns a list of all selected

  files.


  This patch only adds support for Unix and Windows.  I don't know how

  to do this on the Mac.  The Unix support is only implemented when

  Tk_StrictMotif is false.  It should be straightforward to extend it to

  the Motif style file dialog.


  This patch is due to Stephen Peters and Khamis Abuelkomboz.


  Ian Taylor

  ian@cygnus.com


  *** /5g/ian/tk8.0p2/doc/getOpenFile.n   Mon Dec  9 19:37:06 1996

  --- doc/getOpenFile.n   Fri Apr 17 12:49:13 1998

  *************** end user to override the application def

  *** 68,73 ****

  --- 68,78 ----

    Specifies a filename to be displayed in the dialog when it pops

    up. This option is ignored by the \fBtk_getOpenFile\fR command.

    .TP

  + \fB\-multiple\fR \fIboolean\fR

  + Specifies whether multiple files can be selected in the dialog

  + box.  \fIBoolean\fR may have any proper boolean value, such as

  + \fB1\fR or \fBno\fR.  Defaults to 0.

  + .TP

    \fB\-parent\fR \fIwindow\fR

    Makes \fIwindow\fR the logical parent of the file dialog. The file

    dialog is displayed on top of its parent window.

  *************** option is not specified, then a default 

  *** 78,85 ****

    option is ignored on the Macintosh platform.

    .PP

    If the user selects a file, both \fBtk_getOpenFile\fR and

  ! \fBtk_getSaveFile\fR return the full pathname of this file. If the

  ! user cancels the operation, both commands return the empty string.

    .SH "SPECIFYING FILE PATTERNS"


    The \fIfilePatternList\fR value given by the \fB\-filetypes\fR option

  --- 83,91 ----

    option is ignored on the Macintosh platform.

    .PP

    If the user selects a file, both \fBtk_getOpenFile\fR and

  ! \fBtk_getSaveFile\fR return the full pathname of this file. If the 

  ! \fB-multiple\fR option is used, a list of full pathnames will be returned.

  ! If the user cancels the operation, both commands return the empty string.

    .SH "SPECIFYING FILE PATTERNS"


    The \fIfilePatternList\fR value given by the \fB\-filetypes\fR option

  *** /5g/ian/tk8.0p2/library/tkfbox.tcl  Thu Oct  9 13:39:42 1997

  --- library/tkfbox.tcl  Fri Apr 17 12:48:11 1998

  *************** proc tkIconList_Config {w argList} {

  *** 52,57 ****

  --- 52,58 ----

        set specs {

          {-browsecmd "" "" ""}

          {-command "" "" ""}

  +       {-multiple "" "" "0"}

        }


        # 2: parse the arguments

  *************** proc tkIconList_Create {w} {

  *** 95,100 ****

  --- 96,102 ----


        bind $data(canvas) <1>         "tkIconList_Btn1 $w %x %y"

        bind $data(canvas) <B1-Motion> "tkIconList_Motion1 $w %x %y"

  +     bind $data(canvas) <Shift-1>   "tkIconList_ShiftBtn1 $w %x %y"

        bind $data(canvas) <Double-1>  "tkIconList_Double1 $w %x %y"

        bind $data(canvas) <ButtonRelease-1> "tkCancelRepeat"

        bind $data(canvas) <B1-Leave>  "tkIconList_Leave1 $w %x %y"

  *************** proc tkIconList_SelectAtXY {w x y} {

  *** 373,378 ****

  --- 375,392 ----

          [$data(canvas) canvasx $x] [$data(canvas) canvasy $y]]

    }


  + proc tkIconList_AddSelectAtXY {w x y {no_delete 0}} {

  +     upvar #0 $w data

  + 

  +     if {$data(-multiple) && [info exists data(selected)]} {

  +       tkIconList_AddSelect $w [$data(canvas) find closest \

  +               [$data(canvas) canvasx $x] [$data(canvas) canvasy $y]] \

  +               1 $no_delete

  +       return

  +     }

  +     tkIconList_SelectAtXY $w $x $y

  + }

  + 

    proc tkIconList_Select {w rTag {callBrowse 1}} {

        upvar #0 $w data

        upvar #0 $w:itemList itemList

  *************** proc tkIconList_Select {w rTag {callBrow

  *** 385,390 ****

  --- 399,410 ----

        set text   [lindex $itemList($rTag) 2]

        set serial [lindex $itemList($rTag) 3]


  +     if {$data(-multiple) && [info exists data(rect)]} {

  +       foreach r $data(rect) {

  +           $data(canvas) delete $r

  +       }

  +       unset data(rect)

  +     }

        if ![info exists data(rect)] {

            set data(rect) [$data(canvas) create rect 0 0 0 0 \

              -fill #a0a0ff -outline #a0a0ff]

  *************** proc tkIconList_Select {w rTag {callBrow

  *** 394,404 ****

        eval $data(canvas) coords $data(rect) $bbox


        set data(curItem) $serial

  !     set data(selected) $text


        if {$callBrowse} {

          if [string compare $data(-browsecmd) ""] {

  !           eval $data(-browsecmd) [list $text]

          }

        }

    }

  --- 414,492 ----

        eval $data(canvas) coords $data(rect) $bbox


        set data(curItem) $serial

  !     

  !     if {$data(-multiple)} {

  !       set data(selected) [list $text]

  !     } else {

  !       set data(selected) $text

  !     }

  !     

  !     if {$callBrowse} {

  !       if [string compare $data(-browsecmd) ""] {

  !           eval $data(-browsecmd) [list $data(selected)]

  !       }

  !     }

  ! }

  ! 

  ! proc tkIconList_AddSelect {w rTag {callBrowse 1} {no_delete 0}} {

  !     upvar #0 $w data

  !     upvar #0 $w:itemList itemList

  ! 

  !     if ![info exists itemList($rTag)] {

  !       return

  !     }

  !     set iTag   [lindex $itemList($rTag) 0]

  !     set tTag   [lindex $itemList($rTag) 1]

  !     set text   [lindex $itemList($rTag) 2]

  !     set serial [lindex $itemList($rTag) 3]

  ! 

  !     if {[lsearch -exact $data(selected) $text] != -1} {

  !       if {$no_delete} {

  !           return

  !       }

  !        

  !       # we've clicked on an existing item, so we need to remove it

  !       set i [lsearch -exact $data(selected) $text]

  !       set data(selected) [lreplace $data(selected) $i $i]

  !       

  !       # find the appropriate coordinates and remove the

  !       # corresponding rectangle.

  !       set tmpbbox [$data(canvas) bbox $tTag]

  !       for {set i 0} {$i<[llength $data(rect)]} {incr i} {

  !           set rectTag [lindex $data(rect) $i]

  !           set testbbox [$data(canvas) coords $rectTag]

  !           # test first two coordinates; if they're the same the

  !           # entire box should match

  !           if {[lindex $testbbox 0]==[lindex $tmpbbox 0] && \

  !                   [lindex $testbbox 1]==[lindex $tmpbbox 1]} {

  !               $data(canvas) delete $rectTag

  !               set data(rect) [lreplace $data(rect) $i $i]

  !               break

  !           }

  !       }

  ! 

  !       if {$callBrowse} {

  !           if [string compare $data(-browsecmd) ""] {

  !               eval $data(-browsecmd) [list $data(selected)]

  !           }

  !       }

  !       return

  !     }

  ! 

  !     set tmprect [$data(canvas) create rect 0 0 0 0 \

  !           -fill #a0a0ff -outline #a0a0ff]

  !     lappend data(rect) $tmprect

  ! 

  !     $data(canvas) lower $tmprect

  !     set bbox [$data(canvas) bbox $tTag]

  !     eval $data(canvas) coords $tmprect $bbox

  ! 

  !     set data(curItem) $serial

  !     lappend data(selected) $text


        if {$callBrowse} {

          if [string compare $data(-browsecmd) ""] {

  !           eval $data(-browsecmd) [list $data(selected)]

          }

        }

    }

  *************** proc tkIconList_Unselect {w} {

  *** 407,413 ****

        upvar #0 $w data


        if [info exists data(rect)] {

  !       $data(canvas) delete $data(rect)

          unset data(rect)

        }

        if [info exists data(selected)] {

  --- 495,503 ----

        upvar #0 $w data


        if [info exists data(rect)] {

  !       foreach r $data(rect) {

  !           $data(canvas) delete $r

  !       }

          unset data(rect)

        }

        if [info exists data(selected)] {

  *************** proc tkIconList_Btn1 {w x y} {

  *** 436,441 ****

  --- 526,538 ----

        tkIconList_SelectAtXY $w $x $y

    }


  + proc tkIconList_ShiftBtn1 {w x y} {

  +     upvar #0 $w data

  + 

  +     focus $data(canvas)

  +     tkIconList_AddSelectAtXY $w $x $y

  + }

  + 

    # Gets called on button-1 motions

    #

    proc tkIconList_Motion1 {w x y} {

  *************** proc tkIconList_Motion1 {w x y} {

  *** 443,449 ****

        set tkPriv(x) $x

        set tkPriv(y) $y


  !     tkIconList_SelectAtXY $w $x $y

    }


    proc tkIconList_Double1 {w x y} {

  --- 540,546 ----

        set tkPriv(x) $x

        set tkPriv(y) $y


  !     tkIconList_AddSelectAtXY $w $x $y 1

    }


    proc tkIconList_Double1 {w x y} {

  *************** proc tkFDialog_Config {w type argList} {

  *** 746,751 ****

  --- 843,851 ----

          {-parent "" "" "."}

          {-title "" "" ""}

        }

  +     if {![string compare $type open]} {

  +       lappend specs {-multiple "" "" "0"}

  +     }


        # 2: default values depending on the type of the dialog

        #

  *************** proc tkFDialog_Config {w type argList} {

  *** 772,778 ****

        #

        if [string compare $data(-initialdir) ""] {

          if [file isdirectory $data(-initialdir)] {

  !           set data(selectPath) [glob $data(-initialdir)]

          } else {

              error "\"$data(-initialdir)\" is not a valid directory"

          }

  --- 872,879 ----

        #

        if [string compare $data(-initialdir) ""] {

          if [file isdirectory $data(-initialdir)] {

  !           # Use lindex in case the pathname has an embedded space.

  !           set data(selectPath) [lindex [glob $data(-initialdir)] 0]

          } else {

              error "\"$data(-initialdir)\" is not a valid directory"

          }

  *************** proc tkFDialog_Config {w type argList} {

  *** 786,791 ****

  --- 887,902 ----

        if ![winfo exists $data(-parent)] {

          error "bad window path name \"$data(-parent)\""

        }

  + 

  +     # Set -multiple to a one or zero value (not other boolean types

  +     # like "yes") so we can use it in tests more easily.

  +     if {![string compare $type save]} {

  +       set data(-multiple) 0

  +     } else {

  +       if {$data(-multiple)} { 

  +           set data(-multiple) 1 

  +       }

  +     }

    }


    proc tkFDialog_Create {w} {

  *************** static char updir_bits[] = {

  *** 826,837 ****

        #

        set data(icons) [tkIconList $w.icons \

          -browsecmd "tkFDialog_ListBrowse $w" \

  !       -command   "tkFDialog_ListInvoke $w"]


        # f2: the frame with the OK button and the "file name" field

        #

        set f2 [frame $w.f2 -bd 0]

        label $f2.lab -text "File name:" -anchor e -width 14 -under 5 -pady 0

        set data(ent) [entry $f2.ent]


        # The font to use for the icons. The default Canvas font on Unix

  --- 937,952 ----

        #

        set data(icons) [tkIconList $w.icons \

          -browsecmd "tkFDialog_ListBrowse $w" \

  !       -command   "tkFDialog_ListInvoke $w" \

  !       -multiple  "$data(-multiple)"]


        # f2: the frame with the OK button and the "file name" field

        #

        set f2 [frame $w.f2 -bd 0]

        label $f2.lab -text "File name:" -anchor e -width 14 -under 5 -pady 0

  +     if {$data(-multiple)} {

  +       $f2.lab config -text "File names:"

  +     }

        set data(ent) [entry $f2.ent]


        # The font to use for the icons. The default Canvas font on Unix

  *************** proc tkFDialog_EntFocusOut {w} {

  *** 1225,1237 ****

    }


  ! # Gets called when user presses Return in the "File name" entry.

    #

  ! proc tkFDialog_ActivateEnt {w} {

        upvar #0 [winfo name $w] data


  !     set text [string trim [$data(ent) get]]

  !     set list [tkFDialogResolveFile $data(selectPath) $text \

                    $data(-defaultextension)]

        set flag [lindex $list 0]

        set path [lindex $list 1]

  --- 1340,1351 ----

    }


  ! # Verification procedure.

    #

  ! proc tkFDialog_VerifyFileName { w fname } {

        upvar #0 [winfo name $w] data


  !     set list [tkFDialogResolveFile $data(selectPath) $fname \

                    $data(-defaultextension)]

        set flag [lindex $list 0]

        set path [lindex $list 1]

  *************** proc tkFDialog_ActivateEnt {w} {

  *** 1245,1251 ****

                  $data(ent) delete 0 end

              } else {

                  tkFDialog_SetPathSilently $w $path

  !               set data(selectFile) $file

                  tkFDialog_Done $w

              }

          }

  --- 1359,1369 ----

                  $data(ent) delete 0 end

              } else {

                  tkFDialog_SetPathSilently $w $path

  !               if {$data(-multiple)} {

  !                   lappend data(selectFile) $file

  !               } else {

  !                   set data(selectFile) $file

  !               }

                  tkFDialog_Done $w

              }

          }

  *************** proc tkFDialog_ActivateEnt {w} {

  *** 1262,1268 ****

                  $data(ent) icursor end

              } else {

                  tkFDialog_SetPathSilently $w $path

  !               set data(selectFile) $file

                  tkFDialog_Done $w

              }

          }

  --- 1380,1390 ----

                  $data(ent) icursor end

              } else {

                  tkFDialog_SetPathSilently $w $path

  !               if {$data(-multiple)} {

  !                   lappend data(selectFile) $file

  !               } else {

  !                   set data(selectFile) $file

  !               }

                  tkFDialog_Done $w

              }

          }

  *************** proc tkFDialog_ActivateEnt {w} {

  *** 1292,1297 ****

  --- 1414,1435 ----

        }

    }


  + # Gets called when user presses Return in the "File name" entry.

  + #

  + proc tkFDialog_ActivateEnt {w} {

  +     upvar #0 [winfo name $w] data

  + 

  +     set text [$data(ent) get]

  +     if {$data(-multiple)} {

  +       set data(selectFile) ""

  +       foreach fname $text {

  +           tkFDialog_VerifyFileName $w $fname

  +       }

  +     } else {

  +       tkFDialog_VerifyFileName $w $text

  +     }

  + }

  + 

    # Gets called when user presses the Alt-s or Alt-o keys.

    #

    proc tkFDialog_InvokeBtn {w key} {

  *************** proc tkFDialog_OkCmd {w} {

  *** 1332,1341 ****


        set text [tkIconList_Get $data(icons)]

        if [string compare $text ""] {

  !       set file [tkFDialog_JoinFile $data(selectPath) $text]

  !       if [file isdirectory $file] {

  !           tkFDialog_ListInvoke $w $text

  !           return

          }

        }


  --- 1470,1481 ----


        set text [tkIconList_Get $data(icons)]

        if [string compare $text ""] {

  !       if {!$data(-multiple)} {

  !           set file [tkFDialog_JoinFile $data(selectPath) $text]

  !           if [file isdirectory $file] {

  !               tkFDialog_ListInvoke $w $text

  !               return

  !           }

          }

        }


  *************** proc tkFDialog_ListInvoke {w text} {

  *** 1386,1392 ****

          return

        }


  !     set file [tkFDialog_JoinFile $data(selectPath) $text]


        if [file isdirectory $file] {

          set appPWD [pwd]

  --- 1526,1536 ----

          return

        }


  !     if {$data(-multiple)} {

  !       set file [tkFDialog_JoinFile $data(selectPath) [lindex $text 0]]

  !     } else {

  !       set file [tkFDialog_JoinFile $data(selectPath) $text]

  !     }


        if [file isdirectory $file] {

          set appPWD [pwd]

  *************** proc tkFDialog_ListInvoke {w text} {

  *** 1399,1405 ****

              set data(selectPath) $file

          }

        } else {

  !       set data(selectFile) $file

          tkFDialog_Done $w

        }

    }

  --- 1543,1553 ----

              set data(selectPath) $file

          }

        } else {

  !       if {$data(-multiple)} {

  !           set data(selectFile) [list $file]

  !       } else {

  !           set data(selectFile) $file

  !       }

          tkFDialog_Done $w

        }

    }

  *************** proc tkFDialog_Done {w {selectFilePath "

  *** 1417,1424 ****

        global tkPriv


        if ![string compare $selectFilePath ""] {

  !       set selectFilePath [tkFDialog_JoinFile $data(selectPath) \

  !               $data(selectFile)]

          set tkPriv(selectFile)     $data(selectFile)

          set tkPriv(selectPath)     $data(selectPath)


  --- 1565,1579 ----

        global tkPriv


        if ![string compare $selectFilePath ""] {

  !       if {$data(-multiple)} {

  !           set selectFilePath {}

  !           foreach f $data(selectFile) {

  !               lappend selectFilePath [file join $data(selectPath) $f]

  !           }

  !       } else {

  !           set selectFilePath [tkFDialog_JoinFile $data(selectPath) \

  !                   $data(selectFile)]

  !       }

          set tkPriv(selectFile)     $data(selectFile)

          set tkPriv(selectPath)     $data(selectPath)


  *** /5g/ian/tk8.0p2/tests/filebox.test  Fri Oct 10 20:04:51 1997

  --- tests/filebox.test  Fri Apr 17 12:49:13 1998

  *************** if {$tcl_platform(platform) == "unix"} {

  *** 92,99 ****

        set modes 1

    }


  - set unknownOptionsMsg {1 {unknown option "-foo", must be -defaultextension, -filetypes, -initialdir, -initialfile, -parent or -title}}

  - 

    foreach mode $modes {


        #

  --- 92,97 ----

  *************** foreach mode $modes {

  *** 110,115 ****

  --- 108,119 ----

        #


        foreach command "tk_getOpenFile tk_getSaveFile" {

  + 

  +       if {$command == "tk_getOpenFile" && $mode == 0} {

  +           set unknownOptionsMsg {1 {unknown option "-foo", must be -defaultextension, -filetypes, -initialdir, -initialfile, -multiple, -parent or -title}}

  +       } else {

  +           set unknownOptionsMsg {1 {unknown option "-foo", must be -defaultextension, -filetypes, -initialdir, -initialfile, -parent or -title}}

  +       }


          test filebox-1.1 "$command command" {

              list [catch {$command -foo} msg] $msg

  *** /5g/ian/tk8.0p2/win/tkWinDialog.c   Tue Oct 28 11:37:34 1997

  --- win/tkWinDialog.c   Fri Apr 17 12:51:21 1998

  *************** GetFileName(clientData, interp, argc, ar

  *** 483,502 ****

         * 3. Process the results.

         */

        if (winCode) {

  !       char *p;

  !       Tcl_ResetResult(interp);

  ! 

  !       for (p = custData->szFile; p && *p; p++) {

              /*

  !            * Change the pathname to the Tcl "normalized" pathname, where

  !            * back slashes are used instead of forward slashes

               */

  !           if (*p == '\\') {

  !               *p = '/';

              }

          }

  -       Tcl_AppendResult(interp, custData->szFile, NULL);

  -       tclCode = TCL_OK;

        } else {

          tclCode = ProcessCDError(interp, CommDlgExtendedError(),

                  ofnPtr->hwndOwner);

  --- 483,553 ----

         * 3. Process the results.

         */

        if (winCode) {

  !       if (ofnPtr->Flags & OFN_ALLOWMULTISELECT) {

              /*

  !            * The result in custData->szFile contains many items,

  !            * separated with null characters.  It is terminated with

  !            * two nulls in a row.  The first element is the directory

  !            * path.

               */

  !           char *dir;

  !           int dirlen;

  !           char *p;

  !           Tcl_DString fullname;

  !           Tcl_ResetResult(interp);

  ! 

  !           /* Get directory */

  !           dir = custData->szFile;

  !           for (p = custData->szFile; p && *p; p++) {

  !               /*

  !                * Change the pathname to the Tcl "normalized" pathname, where

  !                * back slashes are used instead of forward slashes

  !                */

  !               if (*p == '\\') {

  !                   *p = '/';

  !               }

  !           }

  ! 

  !           if (p[1] == '\0') {

  !               /*

  !                * Only one file was returned.

  !                */

  !               Tcl_AppendElement(interp, dir);

  !           } else {

  !               while (*(++p)) {

  !                   char *filname = p;

  !                   for (; p && *p; p++) {

  !                       if (*p == '\\') { *p = '/'; }

  !                   }

  !                   Tcl_DStringInit(&fullname);

  !                   Tcl_DStringAppend(&fullname, dir, -1);

  !                   Tcl_DStringAppend(&fullname, "/", -1);

  !                   Tcl_DStringAppend(&fullname, filname, -1);

  !                   Tcl_AppendElement(interp, Tcl_DStringValue(&fullname));

  !                   Tcl_DStringFree(&fullname);

  !               }

              }

  +           tclCode = TCL_OK;

  +       } else {

  +           /*

  +            * Not a multiple-selection box; just treat it as a single

  +            * element.

  +            */

  +           char *p;

  +           Tcl_ResetResult(interp);

  +           

  +           for (p = custData->szFile; p && *p; p++) {

  +               /*

  +                * Change the pathname to the Tcl "normalized" pathname, where

  +                * back slashes are used instead of forward slashes

  +                */

  +               if (*p == '\\') {

  +                   *p = '/';

  +               }

  +           }

  +           Tcl_AppendResult(interp, custData->szFile, NULL);

  +           tclCode = TCL_OK;

          }

        } else {

          tclCode = ProcessCDError(interp, CommDlgExtendedError(),

                  ofnPtr->hwndOwner);

  *************** ParseFileDlgArgs(interp, ofnPtr, argc, a

  *** 639,644 ****

  --- 690,706 ----

              if (v==argc) {goto arg_missing;}


              ofnPtr->lpstrTitle = argv[v];

  +       }

  +       else if (strncmp(argv[i], "-multiple", len)==0) {

  +           int tmp;

  +           if (v==argc) {goto arg_missing;}

  + 

  +           if (Tcl_GetBoolean(interp, argv[i+1], &tmp) != TCL_OK) {

  +               return TCL_ERROR;

  +           }

  +           if (tmp) {

  +               ofnPtr->Flags |= OFN_ALLOWMULTISELECT;

  +           }

          }

          else {

              Tcl_AppendResult(interp, "unknown option \"", 




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

  - eric

  -- 06/22/2000 ericm


tkt_uuid: 220316ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: Cannot load gif files with the "image create photo" command
comment:
  OriginalBugID: 6010 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-13'
  LastModified: '2000-07-17'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Digital Unix
  OSVersion: Tru64 Unix V4.0F
  Machine: Compaq Professional Workstation XP1000
  ClosedDate: '2000-07-17'


  Name:
  Mario Vincent

  CVS:
  RCS: @(#) $Id: tkImgGIF.c,v 1.14 2000/03/30 19:44:41 ericm Exp

  ReproducibleScript:
  I compiled tk on Tru64 Unix V4.0F. ( Digital Unix is now called Tru64 Unix)
  This bug is in the code of tkImgGIF.c.
  Look at lines 75 and 76
  #  define GIF87a         "\x47\x49\x46\x38\x37\x61" /* ASCII GIF87a */
  #  define GIF89a         "\x47\x49\x46\x38\x39\x61" /* ASCII GIF89a */
  Apparently the \xnn representation is not being converted into proper strings, so the strncmp (later)
  fails.

  I replaced by the octal representation, recompiled and it works.
  //#  define GIF87a         "\x47\x49\x46\x38\x37\x61" /* ASCII GIF87a */
  #  define GIF87a         "\107\111\106\070\067\141" /* ASCII GIF87a */
  //#  define GIF89a         "\x47\x49\x46\x38\x39\x61" /* ASCII GIF89a */
  #  define GIF89a         "\107\111\106\070\071\141" /* ASCII GIF89a */

  Maybe theres a hook u can pass to the compiler or something which will make this kind of string
  acceptible.. I dont know. 
  Thanks and regards,
  Mario



  We are aware of this problem, and the code has been fixed in 8.4; the defines were replaced with static character arrays:

  static CONST char GIF87a[] =
          { 0x47, 0x49, 0x46, 0x38, 0x37, 0x61, 0x00 }; /* ASCII GIF87a */
  static CONST char GIF89a[] =
          { 0x47, 0x49, 0x46, 0x38, 0x39, 0x61, 0x00 }; /* ASCII GIF89a */

  Thanks,

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

  -- 07/17/2000 ericm


tkt_uuid: 220111ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: winfo doesn't recognize widow paths with global scope (e.g., "::.w")
comment:
  OriginalBugID: 690 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-02'
  LastModified: '1999-08-06'
  Severity: MED
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-06'


          I have the latest version of tcl (8.0.3) and I have noticed that the
  winfo command does not recognize window pathnames that are explicitly
  given global scope such as "::.w". The error is:

  bad window path name "::.w"

  This name is returned by the $this variable in [incr Tk] (version 3.0).

  Thanks,

  -Lou Arata


  [incr Tk] is not returning a valid "window path name" in this
  case.  While .w and ::.w are valid command names, only the first
  is a valid window path name, which winfo requires. 
  -- 08/06/1999 hobbs


tkt_uuid: 1873627fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: Column separator in ttk::treeview
comment:
  Having tested the ttk::treeview I lack one
  visual thing.  A column separator line.
  A thin line in a different color between columns
  would help the eye a lot.
  Maybe have it configurable per column if a
  separator should be visible.


tkt_uuid: 627553ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 9 Immediate
foundin: final: 8.3.5
resolution: Fixed
title: unix/configure is broken
comment:
  The unix/configure file in the Tk 8.3.5 source distro
  is completely broken.  Several macros from
  unix/configure.in have not been expanded, including:

  SC_ENABLE_GCC
  SC_ENABLE_THREADS
  SC_PATH_TCLCONFIG
  SC_LOAD_TCLCONFIG
  SC_CONFIG_CFLAGS
  SC_ENABLE_SYMBOLS
  SC_PATH_X
  SC_BUGGY_STRTOD
  SC_ENABLE_SHARED

  It appears that "autoconf" was run without having
  the necessary tcl.m4 file around.

  A corrected distribution should be released.

  The release process should be examined to determine
  how this error could escape notice.


tkt_uuid: 846143ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: misleading comments in tkWinSend.c
comment:
  Line 331 of tkWinSend.c says:

      /* FIX ME: async and check for local interp */

  There's also:

      /*
       * FIX ME: we don't support displayPtr.
       */

  and code like this:

      /*ThreadSpecificData *tsdPtr =
  TCL_TSD_INIT(&dataKey);*/

  Which suggest that tip150 was applied to the cvs head
  rather prematurely and should not be tagged 'final'.


tkt_uuid: 465269ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Invalid
title: DoubleClickEvent at CanvasWindowItem
comment:
  The DoubleClick doesn't work correctly with the Canvas
  Window Item. It executes twice a SingleClick.
  The window Item includes a label-widget.


tkt_uuid: 3069480fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: [w64] The app was unable to start correctly (0xc000007b)
comment:
  I get this error launching wish (8.5.x, 8.6_HEAD)
  TITLE: wish85.exe/wish86.exe - Application Error
  TEXT:  The application was unable to start correctly (0xc000007b). Click OK to close the application.

  platform is windows x64, built with mingw64 for w64

  any hint on how to inspect what's failing there?


tkt_uuid: 220203ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: None
resolution: Invalid
title: Width=0 canvas lines are drawn width=1
comment:
  OriginalBugID: 2298 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-28'
  LastModified: '1999-10-21'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: 4.00.951
  Machine: X86
  ClosedDate: '1999-10-21'


  Name:
  John Nakulski

  ReproducibleScript:
  canvas .c
      pack .c
      .c create line 1 1 50 50 -width 0 ;# Draws a line of width 1

  ObservedBehavior:
  Canvas lines of width<=0 are drawn as if width=1

  DesiredBehavior:
  If I specify line width=0, I expect the line to be invisible (but to
      exist, so that I can later configure the width to be positive).
      
      If I specify width<0, I expect to get an error.



  This is actually a feature of X that you can say 0, but you always
  get at least a 1 pixel line.  The ability to make items invisible
  in general is being considered for a future release of Tk. 
  -- 10/21/1999 hobbs


tkt_uuid: 220679ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: wish fails to link
comment:
  OriginalBugID: 4176 Bug
  Version: 8.3
  SubmitDate: '2000-02-14'
  LastModified: '2000-02-25'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  OSVersion: 4.3.3
  Machine: IBM RS/6000 43P Model 150
  FixedDate: '2000-02-25'
  FixedInVersion: 8.3.1


  Name: Dave Marquardt

  Comments:
  AIX can't find libtk8.3.so.  The AIX linker "ld" doesn't understand how
      to find .so files, just .a files.  So
      libtk8.3.so file needs to be specified directly on the command line, or
      the command line needs to include

      -bI:/usr/local/src/tk8.3.0/unix/lib.exp

      which will also find the libtk8.3.so file.

  ReproducibleScript:
  wish fails to link.  I ran

  ./configure --enable-shared
  make

  ObservedBehavior:
  wish fails to link.  Here's the output from make:

          cc  tkAppInit.o  -L/usr/local/src/tk8.3.0/unix -ltk8.3  -L/usr/local/src/tcl8.3.0/unix   -lX11 -ldl -bI:/usr/local/src/tcl8.3.0/unix/lib.exp -lm -lc -L/usr/local/lib -o wish
  ld: 0706-006 Cannot find or open library file: -l tk8.3
          ld:open(): A file or directory in the path name does not exist.
  make: 1254-004 The error code from the last command is 255.

  Stop.

  DesiredBehavior:
  I expect wish to link correctly.



  The problem was that the TCL_NEEDS_EXP_FILE in aclocal.m4 got
  set to 0 when it should be 1 by default.  This is fixed for 8.3.1. 
  -- 02/25/2000 hobbs


tkt_uuid: 1921680fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 87. Logos
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk icon
comment:
  Code has been added to Tk8.5 that allows you to substitute the tk icon but for Tk < 8.5 and for people that don't have there own icon tk.ico should be updated to contain more resolutions and colour depths

  Bug #686329 provided tclkit.ico used in tclkit builds.

  Attached is tkicon.ico - its contains 16x16, 32x32, and 48x48 resolutions in both 24bit colour + 8bit alpha and 256 colours + 1bit alpha.

  The tk logo was vectorized and 3d shaded to produces these icons. No drop shadow was added. The SVG file is available to anyone that wants it.


tkt_uuid: 965186ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: Fixed
title: TkAqua Scrollbar problem
comment:
  The scrollbar in TKAqua does not behave as expected and is almost 
  unusable. --> See main window of widget demo.

  The scrollbar behaviour has gotten worse from release to release.

  In 8.4.5 the  mouse pointer movement was almost in sync with the 
  scrollbar. Only off by the size of the elevator.

  in other words: to scroll through the entire document the mouse 
  should move a distance equal to the length of the trough MINUS 
  the length of the elevator. apart from that 8.4.5 was fine.

  in 8.4.6 it seems that the scrolbar moves twice as quickly as the 
  mouse pointer.

  in 8.5a1 i cannot see the relationship.

  to fix the bug, 8.4.5 would probably be the best starting-point.

  kind regards,
  uwe

  uwe.kirschner@gmx.net


tkt_uuid: 3414089fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: None
title: Grab interaction problem on Windows-XP
comment:
  The attached script demonstrates a grab interaction
  problem on Windows-XP. It creates a pop-up
  transient dialog, and uses grab to make it modal,
  waiting until the user clicks OK before interaction
  with the rest of the application continues.  For
  demonstration the script is kept very simple.

  Whilst the pop-up dialog is visible, click right on
  some empty space in the Windows-XP taskbar and
  select "Show Desktop".  This minimises all open
  application windows.  It is then impossible for the
  user to restore the minimised Tk application
  window.  The application has to be killed using the
  task manager.

  This problem appears to be another unintended
  consequence of bug fix 1847002 (also see
  #2896605).  Using wish 8.5.6 works as expected,
  after the "Show Desktop" the user can click on the
  minimised application window in the task bar in
  order to restore it.


tkt_uuid: 1539962fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: can't correctly mark Hebrew text in tk entry/text widget
comment:
  I use tcl/tk 8.4.6 to develope a programm with GUI.
  When our programm  runs under windows XP Professional
  with SP2, und user tries to mark some Hebrew text in
  the entry/text widget, the marked texts shift
  themselves always. Under Linux (kernel 2.4.21) man can
  mark some Hebrew text, but the Hebrew text is not
  correctly displayed and the writing direction is wrong. 

  I think this has something to do with the writing
  direction from right to left of Hebrew. I have tested
  my program with Arabic, an it has the same problem. So
  it may be a bug in the implementation of entry/text
  widget. 
  It's would be great, if this Phenomenon can be located
  and fixed in a patch.   


tkt_uuid: 2353856fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Out of Date
title: compile of TkUnixEvent.c fails fix inside
comment:
  Line 294 of tkUnixEvent.c is a call to Tcl_Panic

      Tcl_Panic("Wild GenericEvent; panic! (extension=%d,evtype=%d)"
      xgePtr->extension, xgePtr->evtype);

  however this fails with a compile error because there is not comma "," after the first string arguement to Tcl_Panic. If the source is modified to include the comma then Tk compiles cleanly on Linux. 
  i.e. 

      Tcl_Panic("Wild GenericEvent; panic! (extension=%d,evtype=%d)",
      xgePtr->extension, xgePtr->evtype);


tkt_uuid: 220023ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Duplicate
title: Inserting to text widget core dumps
comment:
  OriginalBugID: 2716 Bug
  Version: 8.2
  SubmitDate: '1999-09-10'
  LastModified: '1999-09-10'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2316
  OS: AIX
  OSVersion: 4.3
  Machine: RS6000
  ClosedDate: '1999-09-10'


  Name:
  Adrian Wallaschek

  Extensions:
  None Just Tcl/Tk

  CustomShell:
  None

  Comments:
  AIX clsdev 3 4 000928804C00
      
      I am using xlC_r7 or cc, but it does not make a difference!
      So consider the compiler to be xlC 3.6 (IBM C & C++ Set)

  ReproducibleScript:
  text .t
      pack .t
      .t insert end "bldfl"

  ObservedBehavior:
  Segmentation fault in TkTextPixelIndex at 0x100f3cf8 ($t1)
      0x100f3cf8 (TkTextPixelIndex+0x140) 901c0008        stw   r0,0x8(r28)
      (dbx) where
      TkTextPixelIndex() at 0x100f3cf8
      TkTextPickCurrent() at 0x100f61f8
      DisplayText() at 0x100f0f74
      TclServiceIdle() at 0x100472fc
      Tcl_DoOneEvent() at 0x10047fdc
      Tk_MainLoop() at 0x1007afec
      Tk_MainEx() at 0x10079950
      main() at 0x10000344

  DesiredBehavior:
  When making use of the text widget (insert) under whatever condition the
      program crashes. Tried with constant, variables, etc. but the stacktrace
      seems to show there is a problem with a lower level routine (display)
      ?!?
      
      I had something like this already before but obviously it persists also
      in 8.2!
      
      I'd consider any suggestion, because like this Tk is not usable for me!



  This is a known problem with some configurations of AIX, and
  may have something to do with the ckalloc(0) problem on AIX.
   
  -- 09/10/1999 hobbs


tkt_uuid: 220278ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Invalid
title: Does not default to Top Level window focus
comment:
  OriginalBugID: 4151 RFE
  Version: 8.2.1
  SubmitDate: '2000-02-10'
  LastModified: '2000-03-27'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows 98
  Machine: Pentium II 266 / Enterprise 250 Ultrasparc Solaris 7
  ClosedDate: '2000-03-27'


  Name:
  Matthew Yacobucci

  DesiredBehavior:
  I'm just getting started with tcl/tk and some users are reporting that upon instantiation of a window it does not have a default focus.  For example if I open Notepad in Windows that window will be in focus and I can immediately start typing.  With tcl/tk though if I instantiate a window there needs to be another mouse click to establish focus to that new window.  I want the top-level window to have focus immediately - how do I do this, or can this behavior be added to upcoming releases?



  You can get the behavior you want by explicitly setting the focus to the toplevel you have created:

  toplevel .t
  focus -force .t

  Hope this helps,

  - eric

  -- 03/27/2000 ericm


tkt_uuid: 1677611fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: Fixed
title: tk_messageBox failing on OS X
comment:
  The attached file contains two calls of a tk message box which are fine on linux, windows, etc., but fail on OS X. The generated error message is empty.


tkt_uuid: 220801ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: obsolete: 8.1b2
resolution: None
title: canvas postscript problem
comment:
  OriginalBugID: 1689 Bug
  Version: 8.1b2
  SubmitDate: '1999-04-01'
  LastModified: '1999-04-06'
  Severity: LOW
  Status: Assigned
  Submitter: pat
  ChangedBy: surles
  OS: Solaris
  OSVersion: SunOS Release 5.5.1
  Machine: Other


  Name:
  Peter Weigand

  ReproducibleScript:
      The output of canvas postscript of text and other elements are not
      properly aligned.
      .canvas create text 0 0 -font "Times 24" -text "|||||||||||" -anchor nw
      .canvas create text 10 5 -font "Times 24" -text "|||||||||||" -anchor nw
      .canvas create line 0 0 0 20
      .canvas postscript -file /tmp/test.ps -colormode gray
      
      



  ObservedBehavior:
      The output is something like this:
      |||||||||||
           |||||||||||
      The texts are not positioned properly in postscript.
      As well the text is in postscript view smaller that other canvas objects
      compared with what you see in the window.
      



  DesiredBehavior:
      The output should be something like this:
      |||||||||||
         |||||||||||
      That's what you see in the window but not with postscript.
      


tkt_uuid: 2915709fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.6
resolution: None
title: notebook bug fix 2496162 should be backported to tk8.5
comment:
  I am getting very occasional crashes with tk8.5.6 on solaris 10.

  The stack trace is:

  t@1 (l@1) program terminated by signal SEGV (no mapping at the fault address)
  0xff235b58: Tk_GetOptionValue+0x010c:   ld       [%i3], %i1
  (dbx) where
  current thread: t@1
  =>[1] Tk_GetOptionValue(0x24198, 0x8822f8, 0x8821c0, 0x0, 0x987ef8, 0x916378), at 0xff235b58 
    [2] TtkGetOptionValue(0x24198, 0x8822f8, 0x394760, 0x916378, 0x8821c0, 0xff35bfbc), at 0xff301f5c 
    [3] NotebookTabCommand(0x24198, 0x4, 0xcc3670, 0x916308, 0x100b04, 0x63), at 0xff309700 
    [4] WidgetInstanceObjCmd(0x916308, 0xff36765c, 0x58, 0x100b04, 0x0, 0xff367674), at 0xff3199f4 
    [5] TclEvalObjvInternal(0x24198, 0x4, 0x100b04, 0x3, 0xffffffff, 0x1e0c10), at 0xff0ad2d4 
    [6] TclExecuteByteCode(0x18, 0x100b10, 0x100a88, 0xff1cf6c0, 0x394cf7, 0x24198), at 0xff10cc1c 
    [7] TclObjInterpProc(0x24198, 0x2, 0x4, 0x100a50, 0xff1d4270, 0xff1cf6c0), at 0xff16f790 
    [8] TclEvalObjvInternal(0x24198, 0x4, 0x100a38, 0x3, 0xffffffff, 0x1e0c05), at 0xff0ad2d4 
    [9] TclExecuteByteCode(0x18, 0x100a44, 0x100990, 0xff1cf6c0, 0xdc6ee3, 0x24198), at 0xff10cc1c 
    [10] TclCompEvalObj(0x22cb0, 0x1, 0x0, 0x0, 0x3, 0x24198), at 0xff10b014 
    [11] TclExecuteByteCode(0x20, 0x100a04, 0x100990, 0xff1cf6c0, 0x3f9b73, 0x3f9a98), at 0xff10ccf4 
    [12] TclObjInterpProc(0x24198, 0x2, 0x5, 0x100958, 0xff1d4270, 0xff1cf6c0), at 0xff16f790 
    [13] TclEvalObjvInternal(0x24198, 0x5, 0xffbfcb70, 0x3, 0x0, 0x1e0bf4), at 0xff0ad2d4 
    [14] Tcl_EvalObjv(0x24198, 0x5, 0xffbfcb70, 0x80000, 0x5, 0x0), at 0xff0ada2c 
    [15] AliasObjCmd(0x2, 0x24198, 0x1, 0x100944, 0x1006fc0, 0x1), at 0xff124234 
    [16] TclEvalObjvInternal(0x24198, 0x3, 0x100944, 0x3, 0xffffffff, 0x1e0bf3), at 0xff0ad2d4 
    [17] TclExecuteByteCode(0x18, 0x10094c, 0x1008a0, 0xff1cf6c0, 0xc25de8, 0x24198), at 0xff10cc1c 
    [18] TclObjInterpProc(0x24198, 0x2, 0x2, 0x100868, 0xf800, 0xff1cf6c0), at 0xff16f790 
    [19] TclEvalObjvInternal(0x24198, 0x2, 0xcc3880, 0x3, 0x0, 0x1dc7ff), at 0xff0ad2d4 
    [20] Tcl_EvalObjv(0x24198, 0x2, 0xcc3880, 0x20000, 0x3, 0x0), at 0xff0ada2c 
    [21] TclEvalObjEx(0x24198, 0x4, 0x20000, 0xe7e430, 0x100808, 0x9168e8), at 0xff0aef90 
    [22] TkInvokeMenu(0x0, 0xee2548, 0x0, 0xb977c0, 0xff368eec, 0x0), at 0xff2789f0 
    [23] MenuWidgetObjCmd(0xee2548, 0x0, 0xf149c0, 0x24198, 0x3, 0x28), at 0xff2783bc 
    [24] TclEvalObjvInternal(0x24198, 0x3, 0xf149c0, 0x4, 0x0, 0x1dc7fe), at 0xff0ad2d4 
    [25] Tcl_EvalObjv(0x24198, 0x3, 0xf149c0, 0x0, 0x2, 0x0), at 0xff0ada2c 
    [26] TclEvalObjEx(0x24198, 0x2, 0x0, 0x849d90, 0x1007d0, 0x1bc0d0), at 0xff0aef90 
    [27] Tcl_UplevelObjCmd(0x1007f8, 0x24198, 0x2, 0x7fee0, 0x100760, 0xff1cf6c0), at 0xff16e348 
    [28] TclEvalObjvInternal(0x24198, 0x3, 0x1007f8, 0x10, 0xffffffff, 0x1dc7fd), at 0xff0ad2d4 
    [29] TclExecuteByteCode(0x18, 0x100800, 0x100798, 0xff1cf6c0, 0xaff827, 0x24198), at 0xff10cc1c 
    [30] TclObjInterpProc(0x24198, 0x2, 0x3, 0x100760, 0x0, 0xff1cf6c0), at 0xff16f790 
    [31] TclEvalObjvInternal(0x24198, 0x3, 0x100658, 0x3, 0xffbfe574, 0x1dc7b4), at 0xff0ad2d4 
    [32] TclEvalEx(0x24198, 0x3, 0x3, 0x0, 0x10065c, 0xffbfe3b4), at 0xff0ae4f4 
    [33] Tk_BindEvent(0x5b, 0x38023, 0x51f58, 0xffbfe644, 0x391c8, 0x24198), at 0xff226d38 
    [34] TkBindEventProc(0x4, 0xbe0db8, 0xb38570, 0x102a4d8, 0xff35bfbc, 0x10), at 0xff22df7c 
    [35] Tk_HandleEvent(0xbe0db8, 0x0, 0x0, 0xff35bfbc, 0xff368eec, 0x24198), at 0xff2390bc 
    [36] WindowEventProc(0xbe0db0, 0xfffffffd, 0x8c, 0x1b800, 0xff35bfbc, 0x0), at 0xff239aec 
    [37] Tcl_ServiceEvent(0xfffffffd, 0x0, 0x3a380, 0xff1cf6c0, 0x10d7c, 0xbe0db0), at 0xff156dfc 
    [38] Tcl_DoOneEvent(0xfffffffd, 0x0, 0x0, 0x23e60, 0x10d7c, 0x10c00), at 0xff1570f8 
    [39] Tk_MainLoop(0x24198, 0xff368eec, 0xff15706c, 0xff1d496c, 0xff35bfbc, 0x8c), at 0xff23a014 
    [40] Tk_MainEx(0xff1d445c, 0xff14a564, 0xff368ef4, 0x24198, 0xff18efe0, 0xff1d496c), at 0xff24e954 
    [41] main(0x2, 0xffbfebec, 0xffbfebf8, 0x20e98, 0xfffeff1c, 0x10000), at 0x10d94 


  This suggests something wrong with the ttk::notebook tab option table.  I think it is very likely that this is the same as bug 2496162 which was fixed in generic/ttk/ttkNotebook.c revision 1.17 for tk 8.6.  The thought then was that changes to literals and the nre engine showed up the problem, but perhaps the same issue can arise in tk 8.5, just less frequently.

  I think that it would be a good idea to backport the #2496162 fix to the 8.5 branch, as follows:

  *** ttkNotebook.c.orig  Mon Jan 28 00:36:08 2008
  --- ttkNotebook.c       Wed Dec 16 17:36:14 2009
  ***************
  *** 1241,1248 ****
        Notebook *nb = recordPtr;
    
        Ttk_DeleteManager(nb->notebook.mgr);
  -     Tk_DeleteOptionTable(nb->notebook.tabOptionTable);
  -     Tk_DeleteOptionTable(nb->notebook.paneOptionTable);
    
        if (nb->notebook.tabLayout)
          Ttk_FreeLayout(nb->notebook.tabLayout);
  --- 1241,1246 ----


  I have done that on my installation, and will see if any more problems occur.


tkt_uuid: 1027743fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 5 Medium
foundin: None
resolution: Invalid
title: update idletasks doesn't always process visibility events
comment:
  When application does some long operation with periodic
  calls to update idletasks, not all widgets in
  application are redrawn
  if it is neccessary.

  In my case, when window was obscured by another app
  window, and then shown again, listbox widget is updated,
  but image buttons and lables was not. 


tkt_uuid: 1439517fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 6
foundin: obsolete: 8.5a4
resolution: Duplicate
title: Hang in window-2.9 on Linux/Gnome
comment:
  Running Linux-x86/Gnome, the test window-2.9 hangs
  during execution, hanging the whole test suite. Is some
  timeout missing? (This is only a high priority because
  of the hang.)

  Killing the right sub-process allows the remainder of
  the test suite to run to completion. If that is done,
  the following test message is printed for the problem test:

  ==== window-2.9 Tk_DestroyWindow, Destroy bindings
          evaluated after exit FAILED
  ==== Contents of test case:

      set code [loadTkCommand]
      append code {
          toplevel .t1
          toplevel .t2
          update
          bind .t2 <Destroy> {puts "Destroy .t2" ; exit 1}
          bind .t1 <Destroy> {puts "Destroy .t1" ; exit 0}
          destroy .t2
      }
      set script [makeFile $code script]
      if {[catch {exec [interpreter] $script -geometry
  10x10+0+0} msg]} {
          set error 1
      } else {
          set error 0
      }
      removeFile script
      list $error $msg

  ---- Result was:
  1 {Destroy .t2
  Destroy .t1
  child killed: software termination signal}
  ---- Result should have been (exact matching):
  0 {Destroy .t2
  Destroy .t1}
  ==== window-2.9 FAILED


tkt_uuid: 220849ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: final: 8.1.1
resolution: None
title: bug in font actual
comment:
  OriginalBugID: 2216 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-15'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: Other
  OSVersion: NetBSD-1.3.3/i386  XFree-?
  Machine: NA


  Name:
  Hume Smith

  ReproducibleScript:
  (copy of interactive session)
      aurora> wish
      % label .a -text Howdy -font {times -12}
      .a
      % label .b -text Howdy -font {times -13}
      .b
      % pack .a .b
      % font actual [.a cget -font]
      -family times -size 12 -weight normal -slant roman -underline 0
      -overstrike 0
      % font actual [.b cget -font]
      -family times -size 12 -weight normal -slant roman -underline 0
      -overstrike 0
      % info patchlevel
      8.1.1
      % winfo reqwidth .a
      40
      % winfo reqwidth .b
      46
      %

  ObservedBehavior:
  font actual reports the same sizes for the two fonts; but .b has a
      larger label than .a, as perhaps you can see from the requested widths.
      This is obviously quite sensitive to things like X server, the font
      implementation, dot pitch...

  DesiredBehavior:
  font atual should report different sizes


tkt_uuid: 748999ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: focus.test fails
comment:
  This test fails on Tru64UNix 5.1A - current cvs
  checkout linked against *tcl8.4.3*! And also in tk8.4.3
  linked with tcl8.4.3.

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

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

  ---- Result was:
  .t .t {}
  ---- Result should have been (exact matching):
  .t {} {}
  ==== focus-5.1 FAILED


tkt_uuid: 520520ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Works For Me
title: test suite failures
comment:
  platform: sparc solaris 2.6
  Compiler: Sun's C compiler
  cc: Sun WorkShop 6 2000/06/19 C 5.1 Patch 109491-02
  Tcl and Tk from the activestate cvs as of Feb 20, 00:05
  2002

  I did a make distclean then a 
  configure --prefix=/usr/tcl84 --enable-symbols
  in the Tcl directory, then a make, and a make test
  that passed all tests, then a make install.

  I then moved to the tk directory,
  did a make distclean then a 
  configure --prefix=/usr/tcl84 --enable-symbols
  and then a make and make test .  I got these errors

  filebox.test

  ==== filebox-3.2 tk_getSaveFile command FAILED
  ==== Contents of test case:

                  ToPressButton $parent ok
                  set choice [$command -title "Press Ok"
  -filetypes $filters($x) -
  parent $parent -initialfile $fileName -initialdir
  $fileDir]
              
  ---- Result was:
  /vol/tclsrcsol/tcl84/tk/unix/12x 455.txt
  ---- Result should have been:
  /vol/tclsrcsol/tcl84/tk/unix/12x 455
  ==== filebox-3.2 FAILED

  ==== filebox-3.3 tk_getSaveFile command FAILED
  ==== Contents of test case:

                  ToPressButton $parent ok
                  set choice [$command -title "Press Ok"
  -filetypes $filters($x) -
  parent $parent -initialfile $fileName -initialdir
  $fileDir]
              
  ---- Result was:
  /vol/tclsrcsol/tcl84/tk/unix/12x 455.txt
  ---- Result should have been:
  /vol/tclsrcsol/tcl84/tk/unix/12x 455
  ==== filebox-3.3 FAILED

  focus.test

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

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

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


  listbox.test

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

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

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


  unixWm.test

  ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a
  toplevel, x-coords FAILE
  D
  ==== Contents of test case:

      eval destroy [winfo children .]
      toplevel .t -width 300 -height 400 -bg green
      wm geom .t +40+0
      tkwait visibility .t
      toplevel .t2 -width 100 -height 80 -bg red
      wm geom .t2 +140+200
      tkwait visibility .t2
      raise .t2
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing [expr $x - 30] [expr $y +
  250]]  [winfo containing [e
  xpr $x - 1] [expr $y + 250]]  [winfo containing $x
  [expr $y + 250]]  [winfo cont
  aining [expr $x + 99] [expr $y + 250]]  [winfo
  containing [expr $x + 100] [expr 
  $y + 250]]  [winfo containing [expr $x + 199] [expr $y
  + 250]]  [winfo containin
  g [expr $x + 200] [expr $y + 250]]  [winfo containing
  [expr $x + 220] [expr $y +
   250]]

  ---- Result was:
  {} {} {} {} {} {} {} {}
  ---- Result should have been:
  {} {} .t {} .t2 .t2 {} .t
  ==== unixWm-50.1 FAILED

  ==== unixWm-50.2 Tk_CoordsToWindow procedure, finding a
  toplevel, y-coords and o
  verrideredirect FAILED
  ==== Contents of test case:

      eval destroy [winfo children .]
      toplevel .t -width 300 -height 400 -bg yellow
      wm geom .t +0+50
      tkwait visibility .t
      toplevel .t2 -width 100 -height 80 -bg blue
      wm overrideredirect .t2 1
      wm geom .t2 +100+200
      tkwait visibility .t2
      raise .t2
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      set y2 [winfo rooty .t2]
      list [winfo containing [expr $x +150] 10]  [winfo
  containing [expr $x +150] 
  [expr $y - 1]]  [winfo containing [expr $x +150] $y] 
  [winfo containing [expr $x
   +150] [expr $y2 - 1]]  [winfo containing [expr $x
  +150] $y2]  [winfo containing
   [expr $x +150] [expr $y2 + 79]]  [winfo containing
  [expr $x +150] [expr $y2 + 8
  0]]  [winfo containing [expr $x +150] [expr $y + 450]]

  ---- Result was:
  {} {} {} {} .t2 .t2 {} {}
  ---- Result should have been:
  {} {} .t .t .t2 .t2 .t {}
  ==== unixWm-50.2 FAILED

  ==== unixWm-50.3 Tk_CoordsToWindow procedure, finding a
  toplevel with embedding 
  FAILED
  ==== Contents of test case:

      eval destroy [winfo children .]
      toplevel .t -width 300 -height 400 -bg blue
      wm geom .t +0+50
      frame .t.f -container 1
      place .t.f -x 150 -y 50
      tkwait visibility .t.f
      setupbg
      dobg "
          wm withdraw .
          toplevel .x -width 100 -height 80 -use [winfo
  id .t.f] -bg yellow
          tkwait visibility .x"
      set result [dobg {
          set x [winfo rootx .x]
          set y [winfo rooty .x]
          list [winfo containing [expr $x - 1] [expr $y +
  50]]  [winfo containing 
  $x [expr $y +50]]
      }]
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      lappend result [winfo containing [expr $x + 200]
  [expr $y + 49]]  [winfo con
  taining [expr $x + 200] [expr $y +50]]

  ---- Result was:
  {} {} {} {}
  ---- Result should have been:
  {} .x .t .t.f
  ==== unixWm-50.3 FAILED

  ==== unixWm-50.4 Tk_CoordsToWindow procedure, window in
  other application FAILED
  ==== Contents of test case:

      catch {destroy .t}
      catch {interp delete slave}
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      tkwait visibility .t
      interp create slave
      load {} Tk slave
      slave eval {wm geometry . 200x200+0+0; tkwait
  visibility .}
      set result [list [winfo containing 100 100]  [slave
  eval {winfo containing 1
  00 100}]]
      interp delete slave
      set result

  ---- Result was:
  {} {}
  ---- Result should have been:
  {} .
  ==== unixWm-50.4 FAILED

  ==== unixWm-50.5 Tk_CoordsToWindow procedure, handling
  menubars FAILED
  ==== Contents of test case:

      eval destroy [winfo children .]
      toplevel .t -width 300 -height 400 -bd 2 -relief
  raised
      frame .t.f -width 150 -height 120 -bg green
      place .t.f -x 10 -y 150
      wm geom .t +0+50
      frame .t.menu -width 100 -height 30 -bd 2 -relief
  raised
      frame .t.menu.f -width 40 -height 20 -bg purple
      place .t.menu.f -x 30 -y 10
      testmenubar window .t .t.menu
      tkwait visibility .t.menu
      update
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing $x [expr $y - 31]]  [winfo
  containing $x [expr $y - 3
  0]]  [winfo containing [expr $x + 50] [expr $y - 19]] 
  [winfo containing [expr $
  x + 50] [expr $y - 18]]  [winfo containing [expr $x +
  50] $y]  [winfo containing
   [expr $x + 11] [expr $y + 152]]  [winfo containing
  [expr $x + 12] [expr $y + 15
  2]]

  ---- Result was:
  {} {} {} {} {} {} {}
  ---- Result should have been:
  {} .t.menu .t.menu .t.menu.f .t .t .t.f
  ==== unixWm-50.5 FAILED

  ==== unixWm-50.6 Tk_CoordsToWindow procedure, embedding
  within one app. FAILED
  ==== Contents of test case:

      eval destroy [winfo children .]
      toplevel .t -width 300 -height 400 -bg orange
      wm geom .t +0+50
      frame .t.f -container 1
      place .t.f -x 150 -y 50
      tkwait visibility .t.f
      toplevel .t2 -width 100 -height 80 -bg green -use
  [winfo id .t.f]
      tkwait visibility .t2
      update
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing [expr $x +149] [expr $y +
  80]]  [winfo containing [ex
  pr $x +150] [expr $y +80]]  [winfo containing [expr $x
  +249] [expr $y +80]]  [wi
  nfo containing [expr $x +250] [expr $y +80]]

  ---- Result was:
  {} {} {} {}
  ---- Result should have been:
  .t .t2 .t2 .t
  ==== unixWm-50.6 FAILED
  ==== unixWm-50.7 Tk_CoordsToWindow procedure, more
  basics FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 300 -height 400 -bg green
      wm geom .t +0+0
      frame .t.f -width 100 -height 200 -bd 2 -relief
  raised
      place .t.f -x 100 -y 100
      frame .t.f.f -width 100 -height 200 -bd 2 -relief
  raised
      place .t.f.f -x 0 -y 100
      tkwait visibility .t.f.f
      set x [expr [winfo rootx .t] + 150]
      set y [winfo rooty .t]
      list [winfo containing $x [expr $y + 50]]  [winfo
  containing $x [expr $y + 1
  50]]  [winfo containing $x [expr $y + 250]]  [winfo
  containing $x [expr $y + 350
  ]]  [winfo containing $x [expr $y + 450]]

  ---- Result was:
  {} {} {} {} {}
  ---- Result should have been:
  .t .t.f .t.f.f .t {}
  ==== unixWm-50.7 FAILED

  ==== unixWm-50.8 Tk_CoordsToWindow procedure, more
  basics FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 400 -height 300 -bg green
      wm geom .t +0+0
      frame .t.f -width 200 -height 100 -bd 2 -relief
  raised
      place .t.f -x 100 -y 100
      frame .t.f.f -width 200 -height 100 -bd 2 -relief
  raised
      place .t.f.f -x 100 -y 0
      update
      set x [winfo rooty .t]
      set y [expr [winfo rooty .t] + 150]
      list [winfo containing [expr $x + 50] $y]  [winfo
  containing [expr $x + 150]
   $y]  [winfo containing [expr $x + 250] $y]  [winfo
  containing [expr $x + 350] $
  y]  [winfo containing [expr $x + 450] $y]

  ---- Result was:
  {} {} {} {} {}
  ---- Result should have been:
  .t .t.f .t.f.f .t {}
  ==== unixWm-50.8 FAILED

  ==== unixWm-50.9 Tk_CoordsToWindow procedure, unmapped
  windows FAILED
  ==== Contents of test case:

      catch {destroy .t}
      catch {destroy .t2}
      sleep 500           ;# Give window manager time to
  catch up.
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      tkwait visibility .t
      toplevel .t2 -width 200 -height 200 -bg red
      wm geometry .t2 +0+0
      tkwait visibility .t2
      set result [list [winfo containing 100 100]]
      wm iconify .t2
      lappend result [winfo containing 100 100]

  ---- Result was:
  {} {}
  ---- Result should have been:
  .t2 .t
  ==== unixWm-50.9 FAILED

  ==== unixWm-50.10 Tk_CoordsToWindow procedure, unmapped
  windows FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      frame .t.f -width 150 -height 150 -bd 2 -relief
  raised
      place .t.f -x 25 -y 25
      tkwait visibility .t.f
      set result [list [winfo containing 100 100]]
      place forget .t.f
      update
      lappend result [winfo containing 100 100]
  ---- Result was:
  {} {}
  ---- Result should have been:
  .t.f .t
  ==== unixWm-50.10 FAILED

  ==== unixWm-51.6 TkWmRestackToplevel procedure, window
  to be stacked isn't mappe
  d FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      tkwait visibility .t
      catch {destroy .t2}
      toplevel .t2 -width 200 -height 200 -bg red
      wm geometry .t2 +0+0
      winfo containing 100 100

  ---- Result was:

  ---- Result should have been:
  .t
  ==== unixWm-51.6 FAILED

  ==== unixWm-51.7 TkWmRestackToplevel procedure, other
  window isn't mapped FAILED
  ==== Contents of test case:

      foreach w {.t .t2 .t3} {
          catch {destroy $w}
          toplevel $w -width 200 -height 200 -bg green
          wm geometry $w +0+0
      }
      raise .t .t2
      update
      set result [list [winfo containing 100 100]]
      lower .t3
      lappend result [winfo containing 100 100]

  ---- Result was:
  {} {}
  ---- Result should have been:
  .t3 .t
  ==== unixWm-51.7 FAILED

  util.test
  visual.test
  visual_bb.test
  winButton.test
  winClipboard.test
  winDialog.test
  winFont.test
  winMenu.test
  winSend.test
  skipping: Windows only tests...
  winWm.test
  window.test
  winfo.test

  ==== winfo-4.5 "winfo containing" command FAILED
  ==== Contents of test case:

      winfo containing [winfo rootx .t.f] [winfo rooty
  .t.f]

  ---- Result was:

  ---- Result should have been:
  .t.f
  ==== winfo-4.5 FAILED

  ==== winfo-13.4 [winfo containing] with embedded
  windows FAILED
  ==== Contents of test case:

      MakeEmbed
      button .b
      pack .b -expand yes -fill both
      update
      set z [string compare  [winfo containing [winfo
  rootx .emb.b] [winfo rooty .
  emb.b]] .emb.b]
      catch {destroy .con}
      catch {destroy .emb}
      set z

  ---- Result was:
  -1
  ---- Result should have been:
  0
  ==== winfo-13.4 FAILED

  wm.test

  ==== wm-stackorder-2.2  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t ; update
      raise .
      wm stackorder .

  ---- Result was:
  . .t
  ---- Result should have been:
  .t .
  ==== wm-stackorder-2.2 FAILED

  ==== wm-stackorder-2.3  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t ; update
      catch {destroy .t2}
      toplevel .t2 ; update
      raise .
      raise .t2
      wm stackorder .

  ---- Result was:
  . .t .t2
  ---- Result should have been:
  .t . .t2
  ==== wm-stackorder-2.3 FAILED

  ==== wm-stackorder-2.4  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t ; update
      catch {destroy .t2}
      toplevel .t2 ; update
      raise .
      lower .t2
      wm stackorder .

  ---- Result was:
  .t2 . .t
  ---- Result should have been:
  .t2 .t .
  ==== wm-stackorder-2.4 FAILED

  ==== wm-stackorder-2.5  FAILED
  ==== Contents of test case:

      catch {destroy .parent}
      toplevel .parent ; update
      catch {destroy .parent.child1}
      toplevel .parent.child1 ; update
      catch {destroy .parent.child2}
      toplevel .parent.child2 ; update
      catch {destroy .extra}
      toplevel .extra ; update
      raise .parent
      lower .parent.child2
      wm stackorder .parent

  ---- Result was:
  .parent.child2 .parent .parent.child1
  ---- Result should have been:
  .parent.child2 .parent.child1 .parent
  ==== wm-stackorder-2.5 FAILED

  ==== wm-stackorder-4.3 wm stackorder isabove|isbelow
  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t ; update
      raise .
      wm stackorder .t isa .

  ---- Result was:
  1
  ---- Result should have been:
  0
  ==== wm-stackorder-4.3 FAILED

  ==== wm-stackorder-4.4 wm stackorder isabove|isbelow
  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t ; update
      raise .
      wm stackorder .t isb .

  ---- Result was:
  0
  ---- Result should have been:
  1
  ==== wm-stackorder-4.4 FAILED

  ==== wm-stackorder-5.1 a menu is not a toplevel FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t
      menu .t.m -type menubar
      .t.m add cascade -label "File"
      .t configure -menu .t.m
      update
      raise .
     wm stackorder .

  ---- Result was:
  . .t
  ---- Result should have been:
  .t .
  ==== wm-stackorder-5.1 FAILED

  xmfbox.test


tkt_uuid: 219948ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Duplicate
title: Creating scale widgets from within a procedure changes expr precision
comment:
  OriginalBugID: 1606 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-23'
  LastModified: '1999-03-25'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: stanton
  RelatedBugIDs: 1516
  OS: SunOS
  OSVersion: 5.7
  Machine: Sparc
  ClosedDate: '1999-03-25'


  Name:
  Matthew Swift

  CVS:
  Checked out core-8-1-b2 of Tcl/Tk on March 22nd 1999 at 09:15+0000

  Extensions:
  None

  CustomShell:
  None

  ReproducibleScript:
      From within wish8.1:

      set tcl_patchLevel# Returns 8.1b2
      set tk_patchLevel# Returns 8.1b1 (should be 8.1b2)

      proc foo {name} {
      scale $name.s -from 0 -to 100 -orient horizontal  -variable ${name}(window) -showvalue 0

      pack $name.s -fill x -expand yes
      }

      expr 100# returns 100
      toplevel .x
      foo .x
      expr 100# returns 100.0, expected 100

      format "Hello %d" [expr 100 * 10] # ERROR: expected integer but got
      "1000.0"

  ObservedBehavior:
      1) tk_patchLevel variable is wrong (this isn't important though)
      2) The result of [expr 100] is 100 before I create the scale widget and
      100.0 afterwards. This lead to problems where subsequent calculations
      that are supposed to return integers produce errors when passed to the
      format command via the %d flag (as shown above).

  DesiredBehavior:
      The behaviour of expr should not be altered by the scale command.



      Interestingly, if I create the scale widget at the global level (i.e.
      not from within the procedure) the problem does not occur.
  ----
  Simplified script that causes bug:

    proc foo {} {
        scale .s -from 0 -to 100
    }
    puts "[expr 100]"
    foo
    puts "[expr 100]"

  03/25/1999 10:30 - surles -
      
      


tkt_uuid: 2026405fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: winfo id bug in cygwin build
comment:
  Please excuse my poor English.
  TkpPrintWindowId() in tk/win/tkWinWindow.c uses sprintf() with format specifier "0x%p"

  msvc generates ordinary hex string like "8048354" for "%p", so "0x%p" generates string like "0x8048354".

  On the other hand, gcc (which is used by cygwin) adds "0x" prefix for "%p", so "0x%p" results in "0x0x8048354".
  This is not what you want.

  It would be nice if TkpPrintWindowId() checks _MSC_VER or something, and considers compiler-specific situations.


tkt_uuid: 474151ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Works For Me
title: Clicking on menubar crashes wish
comment:
  I'm using tkcon with wish from CVS. When tkcon comes
  up, the menubar is all messed up. This doesn't occur
  with wish8.3. That's a first issue. But then, if I
  click on the menu bar, wish crashes with this error
  message:

  Tk_FreeGC received unknown gc argument
  Abort

  I'm attaching a snapshot of the window when tkcon first
  comes up.

  L


tkt_uuid: 1498415fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: None
title: Win98: A new menu related crash
comment:
  Hello out there,
  I managed to reduce the code to a manageable size which
  still exhibits this bug. Please see the instructions in
  the attached file.
  Best regards
  Helmut Giese


tkt_uuid: 694280ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 3 Low
foundin: obsolete: 8.4.1
resolution: Invalid
title: impossible to create an image named "info" on windows
comment:
  set tcl_platform(os) 
  Windows NT

  set tcl_platform(osVersion)
  5.1

  info patchlevel
  8.4.1

  image create photo info -file info.gif

  bad option "exists": must be blank, cget, configure, 
  copy, data, get, put, read, redither, transparency, or write

      while executing
  "consoleinterp eval "info exists tcl_prompt1""
      (procedure "ConsolePrompt" line 6)
      invoked from within
  "ConsolePrompt"
      (procedure "tk::ConsoleInvoke" line 23)
      invoked from within
  "tk::ConsoleInvoke"
      (command bound to event)


tkt_uuid: 219912ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Duplicate
title: window "raising" on windows nt doesn't often work
comment:
  OriginalBugID: 951 Bug
  Version: 8.0p2
  SubmitDate: '1998-12-14'
  LastModified: '1999-08-07'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1174
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  ClosedDate: '1999-08-07'


  Name:
  danny chen

  ReproducibleScript:
  try this short script in wish80:

  proc again {} {
      after 2000 again
      raise .
      wm deiconify .
  }
  again

  ObservedBehavior:

  on unix, no problem.  i can iconify or cover the wish window and it will pop up again in at most 2 seconds.  but on nt, the behavior is unpredictable.  sometimes the wish window will raise itself but other times it will not.
  (deiconify always works).

  interestingly, if i xhost a unix version, the raise always works (i.e. the x-server knows how to raise a window but tcl/tk does not seem to get it right all the time).



  03/01/1999 10:02 - redman - Same customer as Bug ID 1174?  In any case, it's the same problem.


tkt_uuid: 607390ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Duplicate
title: segfault in entry var trace
comment:
  Another segfault similar to 605121:

  set FOO init
  entry .e1 -textvariable FOO -validate all \
      -vcmd {%W configure -bg white; format 1}
  bind .e1 <Destroy> {set FOO hello}
  destroy .e1

  Again the problem is that EntryTextVarProc passes a NULL
  varName to Tcl_SetVar.



  Program received signal SIGSEGV, Segmentation fault.
  0x1201c8394 in TclLookupVar (interp=0x120346320,
  part1=0x0, part2=0x0,
      flags=1, msg=0x120216bef "read", createPart1=0,
  createPart2=1,
      arrayPtrPtr=0x11fffddb8) at
  ../unix/../generic/tclVar.c:236
  236         for (p = part1; *p ; p++) {
  (gdb) bt
  #0  0x1201c8394 in TclLookupVar (interp=0x120346320,
  part1=0x0, part2=0x0,
      flags=1, msg=0x120216bef "read", createPart1=0,
  createPart2=1,
      arrayPtrPtr=0x11fffddb8) at
  ../unix/../generic/tclVar.c:236
  #1  0x1201c99ac in Tcl_GetVar2Ex (interp=0x120346320,
  part1=0x0, part2=0x0,
      flags=1) at ../unix/../generic/tclVar.c:1075
  #2  0x1201c98cc in Tcl_GetVar2 (interp=0x120346320,
  part1=0x0, part2=0x0,
      flags=1) at ../unix/../generic/tclVar.c:1027
  #3  0x1201c9844 in Tcl_GetVar (interp=0x120346320,
  varName=0x0, flags=1)
      at ../unix/../generic/tclVar.c:987
  #4  0x12003931c in EntryTextVarProc
  (clientData=0x120436de0,
      interp=0x120346320, name1=0x120439f80 "FOO",
  name2=0x0, flags=32)
      at /local/src/tk/unix/../generic/tkEntry.c:3321
  #5  0x1201ceef8 in CallVarTraces (iPtr=0x120346320,
  arrayPtr=0x0,
      varPtr=0x120436120, part1=0x120439f80 "FOO",
  part2=0x0, flags=32,
      leaveErrMsg=512) at ../unix/../generic/tclVar.c:4188
  #6  0x1201ca874 in TclPtrSetVar (interp=0x120346320,
  varPtr=0x120436120,
      arrayPtr=0x0, part1=0x120439f80 "FOO", part2=0x0,
  newValuePtr=0x1203b3b00,
      flags=512) at ../unix/../generic/tclVar.c:1658
  #7  0x1201ca208 in Tcl_ObjSetVar2 (interp=0x120346320,
  part1Ptr=0x1203ddb20,
      part2Ptr=0x0, newValuePtr=0x1203b3b00, flags=512)
      at ../unix/../generic/tclVar.c:1492
  #8  0x1201c9df8 in Tcl_SetObjCmd (dummy=0x0,
  interp=0x120346320, objc=3,
      objv=0x11fffe450) at ../unix/../generic/tclVar.c:1263
  #9  0x12011cf3c in TclEvalObjvInternal
  (interp=0x120346320, objc=3,
      objv=0x11fffe450, command=0x11fffe668 "set FOO
  hello", length=13, flags=0)
      at ../unix/../generic/tclBasic.c:3048
  #10 0x12011e05c in Tcl_EvalEx (interp=0x120346320,
      script=0x11fffe668 "set FOO hello", numBytes=13,
  flags=0)
      at ../unix/../generic/tclBasic.c:3646
  #11 0x12011e5dc in Tcl_Eval (interp=0x120346320,
      string=0x11fffe668 "set FOO hello") at
  ../unix/../generic/tclBasic.c:3811
  #12 0x120120ec4 in Tcl_GlobalEval (interp=0x120346320,
      command=0x11fffe668 "set FOO hello") at
  ../unix/../generic/tclBasic.c:5261
  #13 0x1200c723c in Tk_BindEvent (bindingTable=0x1203a2400,
      eventPtr=0x11fffead8, tkwin=0x120436170, numObjects=0,
      objectPtr=0x11fffe910) at
  /local/src/tk/unix/../generic/tkBind.c:1805
  #14 0x1200d00a4 in TkBindEventProc (winPtr=0x120436170,
  eventPtr=0x11fffead8)
      at /local/src/tk/unix/../generic/tkCmds.c:287
  #15 0x1200dbc7c in Tk_HandleEvent (eventPtr=0x11fffead8)
      at /local/src/tk/unix/../generic/tkEvent.c:1017
  #16 0x12001d634 in Tk_DestroyWindow (tkwin=0x120436170)
      at /local/src/tk/unix/../generic/tkWindow.c:1356
  #17 0x1200d07cc in Tk_DestroyObjCmd
  (clientData=0x1203a11b0,
      interp=0x120346320, objc=2, objv=0x11fffef10)
      at /local/src/tk/unix/../generic/tkCmds.c:472
  #18 0x12011cf3c in TclEvalObjvInternal
  (interp=0x120346320, objc=2,
      objv=0x11fffef10, command=0x120436106 "destroy
  .e1\n", length=12, flags=0)
      at ../unix/../generic/tclBasic.c:3048
  #19 0x12011e05c in Tcl_EvalEx (interp=0x120346320,
      script=0x120436080 "set FOO init\nentry .e1
  -textvariable FOO -validate all
  \\\n\t-vcmd {%W configure -bg white; format 1}\nbind
  .e1 <Destroy> {set FOO hell
  o}\ndestroy .e1\n", numBytes=146, flags=0)
      at ../unix/../generic/tclBasic.c:3646
  #20 0x120191608 in Tcl_FSEvalFile (interp=0x120346320,
  pathPtr=0x1203b3b60)
      at ../unix/../generic/tclIOUtil.c:1371
  #21 0x120190288 in Tcl_EvalFile (interp=0x120346320,
      fileName=0x11ffff278 "seg3.tcl") at
  ../unix/../generic/tclIOUtil.c:234
  #22 0x12001b348 in Tk_MainEx (argc=1, argv=0x11ffff3e0,
      appInitProc=0x12001ae80 <Tcl_AppInit>,
  interp=0x120346320)
      at /local/src/tk/unix/../generic/tkMain.c:234
  #23 0x12001ae58 in main (argc=2, argv=0x11ffff3d8)
      at /local/src/tk/unix/tkAppInit.c:68


tkt_uuid: 1012325fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: compiler warning
comment:
  "/local/src/tk/unix/tkUnixWm.c", line 4324: warning:
  argument #7 is incompatible
   with prototype:
          prototype: pointer to const unsigned char :
  "/usr/openwin/include/X11/Xl
  ib.h", line 2283
          argument : pointer to const char
  "/local/src/tk/unix/tkUnixWm.c", line 4338: warning:
  argument #7 is incompatible
   with prototype:
          prototype: pointer to const unsigned char :
  "/usr/openwin/include/X11/Xl
  ib.h", line 2283
          argument : pointer to char


tkt_uuid: 219973ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 43. Photo Image|PPM
priority: 1 Zero
foundin: final: 8.0.5
resolution: Duplicate
title: error in writing out .ppm files on NT platform
comment:
  OriginalBugID: 1918 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-21'
  LastModified: '1999-11-16'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1963
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-11-16'


  Name:
  Parag

  ReproducibleScript:
  set loadedImage [image create photo -file something.gif]
      $loadedImage write temp.ppm -format ppm

  ObservedBehavior:
  1) the file is corrupted.
      2) Color channels are interchanged while writing out the file.
      
      this problem doesnot occur on Unix machines for the same version of
      tcl/tk...

  DesiredBehavior:
  the uncorrupted .ppm file


tkt_uuid: 1844034fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: None
resolution: None
title: Clipboard doesn't persist after quit
comment:
  On OS X (and apparently Windows as well), the Tk clipboard is 'lazy' - it doesn't appear to be copied to the main system clipboard until asked.  If the Tk app is quit before this happens, the copied text is lost forever.

  Obviously this has its uses (say, copying large chunks of video), but makes other workflows very frustrating.  I use gitk for browsing my git commits - typical workflow would be to fire up gitk from the terminal, find the commit I'm interested, copy the relevant SHA1 id, quit gitk, and paste that id to the terminal.  Tk's current pasteboard implementation prevents this.

  Are there any workarounds?


tkt_uuid: 220910ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Invalid
title: Canvas index @x,y uses wrong coordinates
comment:
  OriginalBugID: 5207 Bug
  Version: 8.3
  SubmitDate: '2000-04-20'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: All


  Name:

  Sebastian Wangnick


  ReproducibleScript:

  canvas .c

  pack .c

  .c configure -scrollregion {-200 -200 200 200}

  .c create text 100 100 -text FooBar -tag text

  puts [.c index text @100,100]

  puts [.c index text @300,300]


  ObservedBehavior:

  The script prints

  0

  2

  This indicates that the first invocation of index @x,y which uses the unmodified canvas coordinates @100,100 fails, whereas the second invocation at @300,300, where the topleft corner of the scrollregion was substracted from the text center position, delivers the correct result.


  DesiredBehavior:

  2

  6

  This being in line with the documentation, which specifies: 

  @x,y    Refers to the character or coordinate at the point given by x and

              y, where x and y are specified in the coordinate system of the

              canvas.


  Patch:

  *** tkCanvText.c.orig   Tue Dec 21 23:55:10 1999

  --- tkCanvText.c        Thu Apr 20 06:50:16 2000

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

  *** 1286,1293 ****

          }

          y = (int) ((tmp < 0) ? tmp - 0.5 : tmp + 0.5);

          *indexPtr = Tk_PointToChar(textPtr->textLayout,

  !               x + canvasPtr->scrollX1 - textPtr->leftEdge,

  !               y + canvasPtr->scrollY1 - textPtr->header.y1);

        } else if (Tcl_GetIntFromObj((Tcl_Interp *)NULL, obj, indexPtr) == TCL_OK) {

          if (*indexPtr < 0){

              *indexPtr = 0;

  --- 1286,1293 ----

          }

          y = (int) ((tmp < 0) ? tmp - 0.5 : tmp + 0.5);

          *indexPtr = Tk_PointToChar(textPtr->textLayout,

  !               x - textPtr->leftEdge,

  !               y - textPtr->header.y1);

        } else if (Tcl_GetIntFromObj((Tcl_Interp *)NULL, obj, indexPtr) == TCL_OK) {

          if (*indexPtr < 0){

              *indexPtr = 0;


  PatchFiles:

  tkCanvText.c


tkt_uuid: 1741072fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 25. Built-in Bitmaps
priority: 5 Medium
foundin: None
resolution: None
title: request for script level introspection for names of bitmaps
comment:
  It would be useful if Tk provided script level introspection to retrieve the names of the bitmaps that Tk knows at any particular time.  Right now, a developer has to locate the Tk_GetBitmap man page and add some code that hard codes a list, and has to keep track of updates to that man page for new bitmaps.

  It would be useful if Tk provided commands for retrieving any resource lists that it knows "intrinsically" (colors, bitmaps, etc.)


tkt_uuid: 1716613fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: font-7.4 fails
comment:
  ---- Result was:
  0 {named font "xyz" doesn't exist}
  ---- Result should have been (exact matching):
  1 {named font "xyz" doesn't exist}
  ==== font-7.4 FAILED

  The FONT_DELETE stanza in tkFont.c
  does not appear to have anything in
  place to transfer an error in
  TkDeleteNamedFont to the return
  code of [font delete].


tkt_uuid: 220696ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: tk_dialog behaviour changed - bgerror now broken
comment:
  OriginalBugID: 4266 Bug
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-04-17'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 4221 4997
  OS: All Windows
  OSVersion: Windows 98 OSR2
  Machine: Pentium III
  FixedDate: '2000-04-17'
  FixedInVersion: 8.3.1


  Name:
  Lawrence Chitty

  Comments:
  The handling of transient windows has been improved so that they are
      always withdrawn with their master. This has however broken the bgerror
      dialog as well as producing incompatabilities with other code (e.g. the
      tuba debugger uses tk_dialog boxes called .warn & .error . These no
      longer appear as the root window is withdrawn. This causes Tuba to
      effectively hang.

  ReproducibleScript:
  wm withdraw .
  after 100 {foo}

  ObservedBehavior:
  The bgerror dialog box does not appear.

  DesiredBehavior:
  bgerror dialog box always to appear



  We changed the behavior of bgerror for 8.3.1; if "." is withdrawn, the dialog box will still be displayed.  Similarly, we have corrected this for tk_messageBox and tk_dialog.

  This fix will go out with 8.3.1.

  - eric

  -- 04/17/2000 ericm


tkt_uuid: 220664ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: unix/aclocal.m4 is missing
comment:
  OriginalBugID: 4084 Bug
  Version: 8.2
  SubmitDate: '2000-01-25'
  LastModified: '2000-01-25'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-SuSE
  FixedDate: '2000-01-25'
  FixedInVersion: 8.3b2


  Name:
  Reinhard Max

  ObservedBehavior:
  unix/aclocal.m4 seems to be missing in all patchlevels of Tk8.2.
  When I run autoconf I get an unusable configure script.
  I need to edit configure.in to prepare Tck/Tk 8.2 for inclusion into SuSE Linux



  This was corrected in 8.3b2. 
  -- 01/25/2000 hobbs


tkt_uuid: 556526ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Fixed
title: Text item displaced with negative coords
comment:
  When placing a text item on a negative coordinate
  it is displaced one pixel. I.e a text at -1 is
  placed at the same place as one at 0.

  Example:

  pack [canvas .c -width 40 -height 40]
  foreach x {-2 -1 0 1 2} \
          col {white green black red blue} {
      .c create text $x $x -text 5 \
          -font "Courier 20" -fill $col
  }
  .c configure -scrollregion [.c bbox all]
  It can be seen that the white (at -2) is next
  to the black (at 0), and the green (at -1) is
  not seen at all (covered by the black).
  The bug is in tkCanvText.c row 638,
  function ComputeTextBbox:
      leftX = (int) (textPtr->x + 0.5);
      topY = (int) (textPtr->y + 0.5);

  That rounding does not work well with negative
  numbers which causes the effect.
  They should use proper rounding that works on both
  positive and negative numbers, e.g.:

      leftX = (int) floor(textPtr->x + 0.5);
      topY = (int) floor(textPtr->y + 0.5);


tkt_uuid: 220582ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: unix/configure needs -R<X11-path>
comment:
  OriginalBugID: 2586 Bug
  Version: 8.0p2
  SubmitDate: '1999-08-20'
  LastModified: '1999-08-20'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 5.6
  Machine: Other
  FixedDate: '1999-08-20'
  FixedInVersion: 8.2


  Name:
  Hallvard B Furuseth

  ReproducibleScript:
  # login on a host with /local/X11R6/lib/libX11.so but not libX11.a
      cd tk8.0/unix
      ./configure;
      make -s all install test

  ObservedBehavior:
  wish aborts while loading because it doesn't find libX11.so

  DesiredBehavior:
  workingn wish (without having to set LD_LIBRARY_PATH)

  Patch:
  I _think_ this should do it, though I have never hacked autoconf stuff.
  Afterwards configure must be rebuilt.

  --- unix/configure.in.bakMon Aug 16 06:54:23 1999
  +++ unix/configure.inWed Aug 18 18:00:34 1999
  @@ -179,3 +179,7 @@
       AC_MSG_RESULT($i)
  -    XLIBSW="-L$i -lX11"
  +    if test -r $i/libX11.so -o -r $i/libX11.sl; then
  +XLIBSW="-L$i -R$i -lX11"
  +    else
  +XLIBSW="-L$i -lX11"
  +    fi
       x_libraries="$i"
  @@ -188,3 +192,3 @@
       else
  -XLIBSW="-L$x_libraries -lX11"
  +XLIBSW="-L$x_libraries -R$x_libraries -lX11"
       fi

  PatchFiles:
  unix/configure.in
      unix/configure



  8.0p2 is an old version to be running on at this point, as there
  are more stable releases in the 8.0 and 8.2 lines where this
  bug has been fixed. 
  -- 08/20/1999 hobbs


tkt_uuid: 1013942fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Fixed
title: blocking of wheel-scrolling in demo:File sel.dialog
comment:
  Linux
  Widget Demonstration
  Demo: Common Dialogs -> File selection dialog
  option: Use Motif Style Dialog
  blocks wheel-scrolling in the whole demo application.
  Even when the example window is closed
  it sets the global variable 'tk_strictMotif'
  unblocking is possible by running again the example and
  unchecking the option

  for me worked this line (in the file 'filebox.tcl'):
  bind $w <Destroy> "+set tk_strictMotif 0"
  !but it is called 15 times per 'close'


tkt_uuid: 3547356fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: None
title: [tk busy] (8.6) bug with menu on toplevel
comment:
  The 8.6 [tk busy] command does not cause menu's attached to toplevels via configure -menu (menu widget name) to become "busy" when it makes the rest of the toplevel busy.

  I.e., run the following in an 8.6 interpreter:

  button .b -text "Button\n.b" -command [ puts stderr "Button .b" ]
  pack .b

  menu .mbar

  menu .mbar.file

  .mbar.file add command -label "Open" -command [ list puts stderr "Open" ]

  .mbar.file add command -label "Close" -command [ list puts stderr "Close" ]

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

  . configure -menu .mbar

  tk busy .

  Not that the button is "busy" and unavailable, but the menu attached to . via the -menu option is still available, and can be accessed.

  The busy.n man page makes no mention of what should be the expected behavior of performing [tk busy .toplevel] when .toplevel has a -menu attached.  I was expecting that the attached menu would also be made busy along with the rest of the toplevel window.

  I tested this with 8.6b2 under Linux and with an 8.6b1 starkit under windows.  Both Linux and Windows exhibited the bug.


tkt_uuid: 530531ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 81. Portability
priority: 2
foundin: None
resolution: Out of Date
title: Tk to be ported to BeOS and OpenBeOS ?
comment:
  Hi!
  I know that very few people here use BeOS even for 
  occasional fun, but BeOS and even more new OpenBeOS is 
  just reviving its renaisance.
  Developmen of OpenBeOS at http://open-
  beos.sourceforge.net/ is getting faster and faster.

  Tcl is ported and maintained but there was never a Tk 
  port and this makes a number of great cross-platform 
  applications unaccessible to BeOS users.

  Would anyone try porting Tk to BeOS?
  Who would be interested in doing so?
  Under which conditions?

  GCC is available from GeekGadgets website... 
  free BeOS is available through www.Bebits.com

  Best wishes ZB


tkt_uuid: 783798ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: None
title: Tcl'2003: lbind
comment:
  Placeholder to remind me about an efficient list and/or
  command-based version of [bind] that I discussed with
  kbk at Tcl2003.  The idea is that it is for a single
  command only and that it only substitutes whole
  arguments to the command.


tkt_uuid: 998125ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 08. [(label)frame] and [toplevel]
priority: 8
foundin: TIP Implementation
resolution: Fixed
title: Tip #125 Implementation
comment:
  Attached is a patch to implement Tip #125 [wm manage]
  and [wm forget] commands.  The patch includes Unix and
  Windows implementations as well as a partial
  implementation for MacOSX.  For Aqua, only the button
  and menubutton widgets may be placed in a [wm manage]'d
  frame.  To complete the implementation, the
  TK_URBAN_RENEWAL flag must be recognized and handled by
  all the intrinsic Tk widgets.  See the patch for details.

  You'll note that this patch implments an alternative
  approach to the original [wm topleve] proposal.  See
  the updated Tip for details of this change.


tkt_uuid: 220818ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: final: 8.1.1
resolution: None
title: Text kerning too tight on some I18N chars (worse than in 8.0)
comment:
  OriginalBugID: 2027 Bug
  Version: 8.1.1
  SubmitDate: '1999-05-10'
  LastModified: '2000-02-25'
  Severity: MED
  Status: Assigned
  Submitter: foster
  ChangedBy: hobbs
  RelatedBugIDs: 4075
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


  Trying the following on wish 8.0:
     set x \xef\xbf\xae           ;  # i-umlaut, upside-down ?, r-Registered
     label .l -text "abc$x"
     pack .l -padx 4 -pady 4

  gives nice even spacing for all six characters. 
  But in wish 8.1+ the c is followed too closely by the i-umlaut, making sort of an a-umlaut.



  Verified for the default (proportional) font of labels in 8.2. 
  -- 12/14/1999 hobbs


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


  Name:

  Jan Nijtmans


  Comments:

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


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

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

  automatically handles all situations well.


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

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

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

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


  ReproducibleScript:

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

  infoves the following additional fixes:

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

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

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

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

    efficiently. Img 1.2.3 is now prepared to do that.

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

  - portability problems when using Stubs. The documentation now has

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

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

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

    lets the compiler detect more possible problems.


  Patch:

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

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

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

  *** 270,276 ****

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

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


  ! STUB_LIB_OBJS = tkStubLib.o


    OBJS =  tk3d.o tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkClipboard.o tkCmds.o \

    tkColor.o tkConfig.o tkConsole.o tkCursor.o tkError.o tkEvent.o \

  --- 270,276 ----

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

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


  ! STUB_LIB_OBJS = tkStubLib.o tkStubImg.o


    OBJS =  tk3d.o tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkClipboard.o tkCmds.o \

    tkColor.o tkConfig.o tkConsole.o tkCursor.o tkError.o tkEvent.o \

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

  *** 806,811 ****

  --- 806,814 ----


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

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

  + 

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

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


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

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

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

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

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

  *** 331,337 ****

    tkWindow.$(OBJEXT)


    STUB_OBJS = \

  ! tkStubLib.$(OBJEXT)


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

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

  --- 331,338 ----

    tkWindow.$(OBJEXT)


    STUB_OBJS = \

  ! tkStubLib.$(OBJEXT) \

  ! tkStubImg.$(OBJEXT)


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

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

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

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

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

  *** 216,221 ****

  --- 216,222 ----

    $(TMPDIR)\tkWindow.obj


    TKSTUBOBJS = $(TMPDIR)\tkStubLib.obj \

  + $(TMPDIR)\tkStubImg.obj


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

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

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

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

  *** 1194,1216 ****

    Tk_PhotoImageBlock *blockPtr));

    #else

    typedef int (Tk_ImageFileMatchProc) _ANSI_ARGS_((Tcl_Channel chan,

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

    int *heightPtr, Tcl_Interp *interp));

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

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

    Tcl_Interp *interp));

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

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

    Tk_PhotoHandle imageHandle, int destX, int destY,

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

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

    Tcl_Obj *dataObj, Tcl_Obj *format, Tk_PhotoHandle imageHandle,

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

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

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

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

  ! Tcl_DString *dataPtr, Tcl_Obj *format,

  ! Tk_PhotoImageBlock *blockPtr));

    #endif


    /*

  --- 1194,1215 ----

    Tk_PhotoImageBlock *blockPtr));

    #else

    typedef int (Tk_ImageFileMatchProc) _ANSI_ARGS_((Tcl_Channel chan,

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

    int *heightPtr, Tcl_Interp *interp));

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

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

    Tcl_Interp *interp));

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

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

    Tk_PhotoHandle imageHandle, int destX, int destY,

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

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

    Tcl_Obj *dataObj, Tcl_Obj *format, Tk_PhotoHandle imageHandle,

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

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

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

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

  ! Tcl_Obj *format, Tk_PhotoImageBlock *blockPtr));

    #endif


    /*

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

  *** 1252,1258 ****

    EXTERN voidTk_CreateOldPhotoImageFormat _ANSI_ARGS_((

    Tk_PhotoImageFormat *formatPtr));


  ! #ifdef USE_OLD_IMAGE

    #define Tk_CreateImageType Tk_CreateOldImageType

    #define Tk_CreatePhotoImageFormat Tk_CreateOldPhotoImageFormat

    #endif

  --- 1251,1257 ----

    EXTERN voidTk_CreateOldPhotoImageFormat _ANSI_ARGS_((

    Tk_PhotoImageFormat *formatPtr));


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

    #define Tk_CreateImageType Tk_CreateOldImageType

    #define Tk_CreatePhotoImageFormat Tk_CreateOldPhotoImageFormat

    #endif

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

  *** 1313,1318 ****

  --- 1312,1325 ----


    #define Tk_InitStubs(interp, version, exact) \

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

  + 

  + #endif

  + 

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

  + 

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

  + 

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


    #endif


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

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

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

  *** 78,88 ****

     * The format record for the GIF file format:

     */


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

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

        Tcl_Interp *interp));

    static int      FileReadGIF  _ANSI_ARGS_((Tcl_Interp *interp,

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

        Tk_PhotoHandle imageHandle, int destX, int destY,

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

    static intStringMatchGIF _ANSI_ARGS_(( Tcl_Obj *dataObj,

  --- 78,88 ----

     * The format record for the GIF file format:

     */


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

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

        Tcl_Interp *interp));

    static int      FileReadGIF  _ANSI_ARGS_((Tcl_Interp *interp,

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

        Tk_PhotoHandle imageHandle, int destX, int destY,

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

    static intStringMatchGIF _ANSI_ARGS_(( Tcl_Obj *dataObj,

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

  *** 93,106 ****

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

        int srcX, int srcY));

    static int FileWriteGIF _ANSI_ARGS_((Tcl_Interp *interp,  

  !     char *filename, Tcl_Obj *format,

        Tk_PhotoImageBlock *blockPtr));

    static intCommonWriteGIF _ANSI_ARGS_((Tcl_Interp *interp,

        Tcl_Channel handle, Tcl_Obj *format,

        Tk_PhotoImageBlock *blockPtr));


    Tk_PhotoImageFormat tkImgFmtGIF = {

  ! "GIF",/* name */

    FileMatchGIF,   /* fileMatchProc */

    StringMatchGIF, /* stringMatchProc */

    FileReadGIF,    /* fileReadProc */

  --- 93,106 ----

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

        int srcX, int srcY));

    static int FileWriteGIF _ANSI_ARGS_((Tcl_Interp *interp,  

  !     CONST char *filename, Tcl_Obj *format,

        Tk_PhotoImageBlock *blockPtr));

    static intCommonWriteGIF _ANSI_ARGS_((Tcl_Interp *interp,

        Tcl_Channel handle, Tcl_Obj *format,

        Tk_PhotoImageBlock *blockPtr));


    Tk_PhotoImageFormat tkImgFmtGIF = {

  ! "gif",/* name */

    FileMatchGIF,   /* fileMatchProc */

    StringMatchGIF, /* stringMatchProc */

    FileReadGIF,    /* fileReadProc */

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

  *** 179,185 ****

    static int

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

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

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

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

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

     * returned here if the file is a valid

  --- 179,185 ----

    static int

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

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

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

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

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

     * returned here if the file is a valid

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

  *** 214,220 ****

    width, height, srcX, srcY)

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

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

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

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

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

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

  --- 214,220 ----

    width, height, srcX, srcY)

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

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

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

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

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

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

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

  *** 1266,1279 ****

    static int

    FileWriteGIF (interp, filename, format, blockPtr)

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

  !     char*filename;

        Tcl_Obj*format;

        Tk_PhotoImageBlock *blockPtr;

    {

        Tcl_Channel chan = NULL;

        int result;


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

        if (!chan) {

    return TCL_ERROR;

        }

  --- 1266,1279 ----

    static int

    FileWriteGIF (interp, filename, format, blockPtr)

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

  !     CONST char*filename;

        Tcl_Obj*format;

        Tk_PhotoImageBlock *blockPtr;

    {

        Tcl_Channel chan = NULL;

        int result;


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

        if (!chan) {

    return TCL_ERROR;

        }

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

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

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

  *** 371,377 ****

    static voidImgPhotoInstanceSetSize _ANSI_ARGS_((

        PhotoInstance *instancePtr));

    static intImgStringWrite _ANSI_ARGS_((Tcl_Interp *interp,

  !     Tcl_DString *dataPtr, Tcl_Obj *formatString,

        Tk_PhotoImageBlock *blockPtr));

    static char *ImgGetPhoto _ANSI_ARGS_((PhotoMaster *masterPtr,

        Tk_PhotoImageBlock *blockPtr,

  --- 371,377 ----

    static voidImgPhotoInstanceSetSize _ANSI_ARGS_((

        PhotoInstance *instancePtr));

    static intImgStringWrite _ANSI_ARGS_((Tcl_Interp *interp,

  !     Tcl_Obj *formatString,

        Tk_PhotoImageBlock *blockPtr));

    static char *ImgGetPhoto _ANSI_ARGS_((PhotoMaster *masterPtr,

        Tk_PhotoImageBlock *blockPtr,

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

  *** 462,469 ****

        *copyPtr = *formatPtr;

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

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

  !     copyPtr->nextPtr = tsdPtr->formatList;

  !     tsdPtr->formatList = copyPtr;

    }

    

    /*

  --- 462,474 ----

        *copyPtr = *formatPtr;

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

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

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

  ! copyPtr->nextPtr = tsdPtr->oldFormatList;

  ! tsdPtr->oldFormatList = copyPtr;

  !     } else {

  ! copyPtr->nextPtr = tsdPtr->formatList;

  ! tsdPtr->formatList = copyPtr;

  !     }

    }

    

    /*

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

  *** 796,804 ****

    break;

          }

          case PHOTO_DATA: {

  -         Tcl_DString buffer;

    char *data;

  - Tcl_Obj *formatObj;


    /*

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

  --- 801,807 ----

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

  *** 854,872 ****

    }

        }

        if (stringWriteProc == NULL) {

  - oldformat = 1;

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

  -      imageFormat = imageFormat->nextPtr) {

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

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

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

  -     stringWriteProc = imageFormat->stringWriteProc;

  -     break;

  - }

  -     }

  - }

  -     }

  -     if (stringWriteProc == NULL) {

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

    Tcl_GetString(options.format),

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

  --- 857,862 ----

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

  *** 882,906 ****

     */


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

  - Tcl_DStringInit(&buffer);


  ! formatObj = options.format;

  ! if (oldformat && formatObj) {

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

  ! }

  ! result =  stringWriteProc(interp, &buffer,

  ! formatObj, &block);

    if (options.background) {

        Tk_FreeColor(options.background);

    }

    if (data) {

        ckfree(data);

    }

  - if (result == TCL_OK) {

  -     Tcl_DStringResult(interp, &buffer);

  - } else {

  -     Tcl_DStringFree(&buffer);

  - }

    return result;

    break;

          }

  --- 872,887 ----

     */


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


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

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

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

    if (options.background) {

        Tk_FreeColor(options.background);

    }

    if (data) {

        ckfree(data);

    }

    return result;

    break;

          }

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

  *** 4882,4890 ****

     */


    static int

  ! ImgStringWrite(interp, dataPtr, formatString, blockPtr)

        Tcl_Interp *interp;

  -     Tcl_DString *dataPtr;

        Tcl_Obj *formatString;

        Tk_PhotoImageBlock *blockPtr;

    {

  --- 4863,4870 ----

     */


    static int

  ! ImgStringWrite(interp, formatString, blockPtr)

        Tcl_Interp *interp;

        Tcl_Obj *formatString;

        Tk_PhotoImageBlock *blockPtr;

    {

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

  *** 4892,4901 ****

  --- 4872,4883 ----

        char *line, *linePtr;

        unsigned char *pixelPtr;

        int greenOffset, blueOffset;

  +     Tcl_DString data;


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

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


  +     Tcl_DStringInit(&data);

        if ((blockPtr->width > 0) && (blockPtr->height > 0)) {

    line = (char *) ckalloc((unsigned int) ((8 * blockPtr->width) + 2));

    for (row=0; row<blockPtr->height; row++) {

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

  *** 4908,4917 ****

    pixelPtr += blockPtr->pixelSize;

    linePtr += 8;

        }

  !     Tcl_DStringAppendElement(dataPtr, line+1);

    }

    ckfree (line);

        }

        return TCL_OK;

    }

    

  --- 4890,4900 ----

    pixelPtr += blockPtr->pixelSize;

    linePtr += 8;

        }

  !     Tcl_DStringAppendElement(&data, line+1);

    }

    ckfree (line);

        }

  +     Tcl_DStringResult(interp, &data);

        return TCL_OK;

    }

    

  *** generic/tkStubImg.c.origSun Jan 23 10:23:33 2000

  --- generic/tkStubImg.cSun Jan 23 13:39:25 2000

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

  *** 0 ****

  --- 1,74 ----

  + /* 

  +  * tkStubImg.c --

  +  *

  +  *Stub object that will be statically linked into extensions that wish

  +  *to access Tk.

  +  *

  +  * Copyright (c) 1999 Jan Nijtmans.

  +  * Copyright (c) 1998-1999 by Scriptics Corporation.

  +  *

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

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

  +  *

  +  * RCS: @(#) $Id: tkStubImg.c,v 1.0 2000/01/03 01:31:06 nijtmans Exp $

  +  */

  + 

  + #include "tcl.h"

  + 

  + 

  + /*

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

  +  *

  +  * Tk_InitImageArgs --

  +  *

  +  *Performs the necessary conversion from Tcl_Obj's to strings

  +  *      in the createProc for Tcl_CreateImageType. If running under

  +  *      Tk 8.2 or earlier without the Img-patch, this function has

  +  *      no effect.

  +  *

  +  * Results:

  +  *argvPtr will point to an argument list which is guaranteed to

  +  *contain strings, no matter what Tk version is running.

  +  *

  +  * Side effects:

  +  *None

  +  *

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

  +  */

  + 

  + #ifdef Tk_InitImageArgs

  + #undef Tk_InitImageArgs

  + #endif

  + 

  + void

  + Tk_InitImageArgs(interp, argc, argvPtr)

  +     Tcl_Interp *interp;

  +     int argc;

  +     char ***argvPtr;

  + {

  +     static useNewImage = -1;

  +     static char **argv = NULL;

  + 

  +     if (argv) {

  + tclStubsPtr->tcl_Free((char *) argv);

  + argv = NULL;

  +     }

  + 

  +     if (useNewImage < 0) {

  + Tcl_CmdInfo cmdInfo;

  + if (!tclStubsPtr->tcl_GetCommandInfo(interp,"image", &cmdInfo)) {

  +     tclStubsPtr->tcl_Panic("cannot find the \"image\" command");

  + }

  + if (cmdInfo.isNativeObjectProc == 1) {

  +     useNewImage = 1; /* Tk uses the new image interface */

  + }

  +     }

  +     if (useNewImage && (argc > 0)) {

  + int i;

  + argv = (char **) tclStubsPtr->tcl_Alloc(argc * sizeof(char *));

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

  +     argv[i] = tclStubsPtr->tcl_GetString((Tcl_Obj *)(*argvPtr)[i]);

  + }

  + *argvPtr = (char **) argv;

  +     }

  + }

  *** generic/tkTest.c.origTue Dec 14 07:52:31 1999

  --- generic/tkTest.cSun Jan 23 10:23:44 2000

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

  *** 16,21 ****

  --- 16,25 ----

     * RCS: @(#) $Id: tkTest.c,v 1.9 1999/12/14 06:52:31 hobbs Exp $

     */


  + #ifdef MAC_TCL

  + #define USE_OLD_IMAGE

  + #endif

  + 

    #include "tkInt.h"

    #include "tkPort.h"

    #include "tkText.h"

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

  *** 61,70 ****

  --- 65,81 ----

     * The type record for test images:

     */


  + #ifdef USE_OLD_IMAGE

  + static intImageCreate _ANSI_ARGS_((Tcl_Interp *interp,

  +     char *name, int argc, char **argv,

  +     Tk_ImageType *typePtr, Tk_ImageMaster master,

  +     ClientData *clientDataPtr));

  + #else

    static intImageCreate _ANSI_ARGS_((Tcl_Interp *interp,

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

        Tk_ImageType *typePtr, Tk_ImageMaster master,

        ClientData *clientDataPtr));

  + #endif

    static ClientDataImageGet _ANSI_ARGS_((Tk_Window tkwin,

        ClientData clientData));

    static voidImageDisplay _ANSI_ARGS_((ClientData clientData,

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

  *** 78,84 ****


    static Tk_ImageType imageType = {

        "test",/* name */

  !     ImageCreate,/* createProc */

        ImageGet,/* getProc */

        ImageDisplay,/* displayProc */

        ImageFree,/* freeProc */

  --- 89,95 ----


    static Tk_ImageType imageType = {

        "test",/* name */

  !     (Tk_ImageCreateProc *) ImageCreate, /* createProc */

        ImageGet,/* getProc */

        ImageDisplay,/* displayProc */

        ImageFree,/* freeProc */

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

  *** 1557,1562 ****

  --- 1568,1608 ----

     */


    /* ARGSUSED */

  + #ifdef USE_OLD_IMAGE

  + static int

  + ImageCreate(interp, name, argc, argv, typePtr, master, clientDataPtr)

  +     Tcl_Interp *interp;/* Interpreter for application containing

  +  * image. */

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

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

  +     char **argv;/* Argument strings for options (doesn't

  +  * include image name or type). */

  +     Tk_ImageType *typePtr;/* Pointer to our type record (not used). */

  +     Tk_ImageMaster master;/* Token for image, to be used by us in

  +  * later callbacks. */

  +     ClientData *clientDataPtr;/* Store manager's token for image here;

  +  * it will be returned in later callbacks. */

  + {

  +     TImageMaster *timPtr;

  +     char *varName;

  +     int i;

  + 

  +     Tk_InitImageArgs(interp, argc, &argv);

  +     varName = "log";

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

  + if (strcmp(argv[i], "-variable") != 0) {

  +     Tcl_AppendResult(interp, "bad option name \"",

  +     argv[i], "\"", (char *) NULL);

  +     return TCL_ERROR;

  + }

  + if ((i+1) == argc) {

  +     Tcl_AppendResult(interp, "no value given for \"",

  +     argv[i], "\" option", (char *) NULL);

  +     return TCL_ERROR;

  + }

  + varName = argv[i+1];

  +     }

  + #else

    static int

    ImageCreate(interp, name, objc, objv, typePtr, master, clientDataPtr)

        Tcl_Interp *interp;/* Interpreter for application containing

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

  *** 1589,1594 ****

  --- 1635,1641 ----

    }

    varName = Tcl_GetString(objv[i+1]);

        }

  + #endif

        timPtr = (TImageMaster *) ckalloc(sizeof(TImageMaster));

        timPtr->master = master;

        timPtr->interp = interp;

  *** doc/CrtImgType.3.origSun Jan 23 12:42:29 2000

  --- doc/CrtImgType.3Sun Jan 23 13:20:15 2000

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

  *** 8,17 ****

    '\" RCS: @(#) $Id: CrtImgType.3,v 1.3 1999/10/29 03:57:40 hobbs Exp $

    '\" 

    .so man.macros

  ! .TH Tk_CreateImageType 3 8.0 Tk "Tk Library Procedures"

    .BS

    .SH NAME

  ! Tk_CreateImageType, Tk_GetImageMasterData \- define new kind of image

    .SH SYNOPSIS

    .nf

    \fB#include <tk.h>\fR

  --- 8,17 ----

    '\" RCS: @(#) $Id: CrtImgType.3,v 1.3 1999/10/29 03:57:40 hobbs Exp $

    '\" 

    .so man.macros

  ! .TH Tk_CreateImageType 3 8.3 Tk "Tk Library Procedures"

    .BS

    .SH NAME

  ! Tk_CreateImageType, Tk_GetImageMasterData, Tk_InitImageArgs \- define new kind of image

    .SH SYNOPSIS

    .nf

    \fB#include <tk.h>\fR

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

  *** 21,26 ****

  --- 21,28 ----

    .sp

    .VS

    \fBTk_GetImageMasterData\fR(\fIinterp, name, typePtrPtr\fR)

  + .sp

  + \fBTk_InitImageArgs\fR(\fIinterp, argc, argvPtr\fR)

    .SH ARGUMENTS

    .AS Tk_ImageType *typePtrPtr

    .AP Tk_ImageType *typePtr in

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

  *** 34,39 ****

  --- 36,45 ----

    .AP Tk_ImageType **typePtrPtr out

    Points to word in which to store a pointer to type information for

    the given image, if it exists.

  + .AP int argc

  + Number of arguments

  + .AP char ***argvPtr

  + Pointer to argument list

    .VE

    .BE


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

  *** 100,105 ****

  --- 106,121 ----

    If there already existed an image type by this name then

    the new image type replaces the old one.


  + .SH PORTABILITY

  + .PP

  + In Tk 8.2 and earlier, the createProc below had a different

  + signature. If you want to compile an image type using the

  + old interface which should still run on all Tcl/Tk versions,

  + compile it with the flag -DUSE_OLD_IMAGE. Further on, if

  + you are using Stubs, you need to call the function

  + Tk_InitImageArgs(interp, argc, &argv) first in your

  + createProc. See below for a description of this function.

  + 

    .SH CREATEPROC

    \fItypePtr->createProc\fR provides the address of a procedure for

    Tk to call whenever \fBimage create\fR is invoked to create

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

  *** 247,252 ****

  --- 263,280 ----

    pointer to the image master data structure).  If no such image exists

    then NULL is returned and NULL is stored at \fI*typePtrPtr\fR.

    .VE

  + 

  + .SH TK_INITIMAGEARGS

  + .VS

  + .PP

  + The function \fBTk_InitImageArgs\fR converts the arguments of the

  + \fBcreateProc\fR from objects to strings when necessary. When

  + not using stubs, not using the old interface, or running

  + under an older (pre-8.3) Tk version, this function has no

  + effect. This function makes porting older image handlers to

  + the new interface a lot easier: After running this function,

  + the arguments are guaranteed to be in string format, no

  + matter how Tk deliverd them.


    .SH "SEE ALSO"

    Tk_ImageChanged, Tk_GetImage, Tk_FreeImage, Tk_RedrawImage, Tk_SizeOfImage

  *** doc/CrtPhImgFmt.3.origSun Jan 23 12:42:49 2000

  --- doc/CrtPhImgFmt.3Sun Jan 23 13:01:17 2000

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

  *** 12,18 ****

    '\" RCS: @(#) $Id: CrtPhImgFmt.3,v 1.3 1999/10/29 03:57:40 hobbs Exp $

    '\"

    .so man.macros

  ! .TH Tk_CreatePhotoImageFormat 3 4.0 Tk "Tk Library Procedures"

    .BS

    .SH NAME

    Tk_CreatePhotoImageFormat \- define new file format for photo images

  --- 12,18 ----

    '\" RCS: @(#) $Id: CrtPhImgFmt.3,v 1.3 1999/10/29 03:57:40 hobbs Exp $

    '\"

    .so man.macros

  ! .TH Tk_CreatePhotoImageFormat 3 8.3 Tk "Tk Library Procedures"

    .BS

    .SH NAME

    Tk_CreatePhotoImageFormat \- define new file format for photo images

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

  *** 69,74 ****

  --- 69,82 ----

    procedure, and the \fIstringMatchProc\fR procedure if it provides the

    \fIstringReadProc\fR procedure.


  + .SH PORTABILITY

  + .PP

  + In Tk 8.2 and earlier, a different interface was used. Tk 8.3 will

  + still support the old format handlers if the format name is in upper

  + case. If you still want to compile old format handlers with Tk8.3,

  + use the flag -DUSE_OLD_IMAGE. This will restore all function prototypes

  + to match the pre-8.3 situation.

  + 

    .SH NAME

    .PP

    \fIformatPtr->name\fR provides a name for the image type.

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

  *** 76,82 ****

    in the \fB\-format\fR photo image configuration and subcommand option.

    The manual page for the photo image (photo(n)) describes how image

    file formats are chosen based on their names and the value given to

  ! the \fB\-format\fR option.


    .SH FILEMATCHPROC

    \fIformatPtr->fileMatchProc\fR provides the address of a procedure for

  --- 84,92 ----

    in the \fB\-format\fR photo image configuration and subcommand option.

    The manual page for the photo image (photo(n)) describes how image

    file formats are chosen based on their names and the value given to

  ! the \fB\-format\fR option. For new format handlers, the name should

  ! be in lower case. Pre-8.3 format handlers are assumed to be in

  ! upper case.


    .SH FILEMATCHPROC

    \fIformatPtr->fileMatchProc\fR provides the address of a procedure for

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

  *** 86,92 ****

    .CS

    typedef int Tk_ImageFileMatchProc(

    Tcl_Channel \fIchan\fR,

  ! char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    int *\fIwidthPtr\fR,

    int *\fIheightPtr\fR,

  --- 96,102 ----

    .CS

    typedef int Tk_ImageFileMatchProc(

    Tcl_Channel \fIchan\fR,

  ! CONST char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    int *\fIwidthPtr\fR,

    int *\fIheightPtr\fR,

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

  *** 108,120 ****

    \fIformatPtr->stringMatchProc\fR must match the following prototype:

    .CS

    typedef int Tk_ImageStringMatchProc(

  ! char *\fIstring\fR,

    Tcl_Obj *\fIformat\fR,

    int *\fIwidthPtr\fR,

    int *\fIheightPtr\fR,

    Tcl_Interp *\fIinterp\fR);

    .CE

  ! The \fIstring\fR argument points to the string containing the image

    data.  The \fIformat\fR argument contains the value given for

    the \fB\-format\fR option, or NULL if the option was not specified.

    If the data in the string appears to be in the format supported by

  --- 118,130 ----

    \fIformatPtr->stringMatchProc\fR must match the following prototype:

    .CS

    typedef int Tk_ImageStringMatchProc(

  ! Tcl_Obj *\fIdata\fR,

    Tcl_Obj *\fIformat\fR,

    int *\fIwidthPtr\fR,

    int *\fIheightPtr\fR,

    Tcl_Interp *\fIinterp\fR);

    .CE

  ! The \fIdata\fR argument points to the object containing the image

    data.  The \fIformat\fR argument contains the value given for

    the \fB\-format\fR option, or NULL if the option was not specified.

    If the data in the string appears to be in the format supported by

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

  *** 131,137 ****

    typedef int Tk_ImageFileReadProc(

    Tcl_Interp *\fIinterp\fR,

    Tcl_Channel \fIchan\fR,

  ! char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    PhotoHandle \fIimageHandle\fR,

    int \fIdestX\fR, int \fIdestY\fR,

  --- 141,147 ----

    typedef int Tk_ImageFileReadProc(

    Tcl_Interp *\fIinterp\fR,

    Tcl_Channel \fIchan\fR,

  ! CONST char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    PhotoHandle \fIimageHandle\fR,

    int \fIdestX\fR, int \fIdestY\fR,

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

  *** 159,165 ****

    .CS

    typedef int Tk_ImageStringReadProc(

    Tcl_Interp *\fIinterp\fR,

  ! char *\fIstring\fR,

    Tcl_Obj *\fIformat\fR,

    PhotoHandle \fIimageHandle\fR,

    int \fIdestX\fR, int \fIdestY\fR,

  --- 169,175 ----

    .CS

    typedef int Tk_ImageStringReadProc(

    Tcl_Interp *\fIinterp\fR,

  ! Tcl_Obj *\fIdata\fR,

    Tcl_Obj *\fIformat\fR,

    PhotoHandle \fIimageHandle\fR,

    int \fIdestX\fR, int \fIdestY\fR,

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

  *** 168,174 ****

    .CE

    The \fIinterp\fR argument is the interpreter in which the command was

    invoked to read the image; it should be used for reporting errors.

  ! The \fIstring\fR argument points to the image data in string form.

    The \fIformat\fR argument contains the

    value given for the \fB\-format\fR option, or NULL if the option was

    not specified.  The image data in the string, or a subimage of it, is to

  --- 178,184 ----

    .CE

    The \fIinterp\fR argument is the interpreter in which the command was

    invoked to read the image; it should be used for reporting errors.

  ! The \fIdata\fR argument points to the image data in object form.

    The \fIformat\fR argument contains the

    value given for the \fB\-format\fR option, or NULL if the option was

    not specified.  The image data in the string, or a subimage of it, is to

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

  *** 187,193 ****

    .CS

    typedef int Tk_ImageFileWriteProc(

    Tcl_Interp *\fIinterp\fR,

  ! char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    Tk_PhotoImageBlock *\fIblockPtr\fR);

    .CE

  --- 197,203 ----

    .CS

    typedef int Tk_ImageFileWriteProc(

    Tcl_Interp *\fIinterp\fR,

  ! CONST char *\fIfileName\fR,

    Tcl_Obj *\fIformat\fR,

    Tk_PhotoImageBlock *\fIblockPtr\fR);

    .CE

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

  *** 212,218 ****

    .CS

    typedef int Tk_ImageStringWriteProc(

    Tcl_Interp *\fIinterp\fR,

  - Tcl_DString *\fIdataPtr\fR,

    Tcl_Obj *\fIformat\fR,

    Tk_PhotoImageBlock *\fIblockPtr\fR);

    .CE

  --- 222,227 ----

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

  *** 221,227 ****

    The image data to be converted are in memory and are described by the

    Tk_PhotoImageBlock structure pointed to by \fIblockPtr\fR; see the

    manual page FindPhoto(3) for details.  The data for the string

  ! should be appended to the dynamic string given by \fIdataPtr\fR.

    The \fIformat\fR argument contains the

    value given for the \fB\-format\fR option, or NULL if the option was

    not specified.  The format string can contain extra characters

  --- 230,236 ----

    The image data to be converted are in memory and are described by the

    Tk_PhotoImageBlock structure pointed to by \fIblockPtr\fR; see the

    manual page FindPhoto(3) for details.  The data for the string

  ! should be put in the interpreter \fIinterp\fR result.

    The \fIformat\fR argument contains the

    value given for the \fB\-format\fR option, or NULL if the option was

    not specified.  T


  PatchFiles:

  Makefile.in (both UNIX and win) makefile.vc tk.h tkImgGIF.c tkImgPhoto.c

      tkTest.c CrtImgType.3 CrtPhImgFmt.3 tkStubImg.c (new file)




  patch applied for 8.3.0 release. 
  -- 02/08/2000 hobbs


tkt_uuid: 1087842fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Fixed
title: Man page typo
comment:
  I believe the description for "pathname sash dragto
  index x y" has a typo in it. It says that it moves the
  sash in reference to the last "sash coord command".
  However I believe this should say "sash mark command".

  Lio.


tkt_uuid: 220033ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Duplicate
title: Tk make test failure report
comment:
  OriginalBugID: 3340 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-23'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: jenn
  RelatedBugIDs: 2181
  OS: Solaris
  OSVersion: 2.6
  ClosedDate: '1999-11-23'


  Name: Larry W. Virden

  Comments:
  I have ran these tests several times and get the same error each time.
      
      This is the version of Tk from the tar file on Scriptic's ftp site.

  ReproducibleScript:
  make test

  ObservedBehavior:
  Two test suite entries report failures:
      clipboard.test
      
      ==== clipboard-6.2 Tk_ClipboardAppend procedure FAILED
      ==== Contents of test case:
      
          setupbg
          clipboard clear
          clipboard append -f INTEGER -t TEST "16"
          set result [dobg {selection get -s CLIPBOARD TEST}]
          cleanupbg
          set result
      
      ---- Result was:
      CLIPBOARD selection doesn't exist or form "TEST" not defined
      ---- Result should have been:
      0x10
      ==== clipboard-6.2 FAILED
      
      focus.test
      
      ==== focus-5.1 ChangeXFocus procedure, don't take focus unless have it
      FAILED
      ==== Contents of test case:
      
          focusSetup
          focus -force .t
          update
          set result [focus]
          send [dobg {tk appname}] {focus -force .; update}
          lappend result [focus]
          focus .t.b2
          update
          lappend result [focus]
      
      ---- Result was:
      .t .t {}
      ---- Result should have been:
      .t {} {}
      ==== focus-5.1 FAILED

  DesiredBehavior:
  all tests pass


tkt_uuid: 1535865fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Invalid
title: Different font sizes reported
comment:
  Hi guys,

  Playing with the fonts I've seen an small difference in
  the font sizes when I test it in different ways.

  (Bin) 21 % .c create text 100 50 -text "Test String"
  -font "arial 8"
  8
  (Bin) 22 % font measure "arial 8" "Test String"
  52
  (Bin) 23 % .c bbox 8
  73 43 127 57
  (Bin) 24 % 

  As you can see, the "font measure" sais it's 52, but
  the bbox sais it's 54. Looking in the bbox
  documentation I see it sais it returns an "approximate
  bounding box" and that "may overestimate", but it
  always returns the same difference. But then I do an
  screenshot, and when I measure the width I get 51.

  I known is a small difference, but working with a lot
  of texts in the screen and trying to make them fit
  together, the code becomes a bit messy :(

  Thanks again.


tkt_uuid: 220237ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: Tk arg parsing changed in an incompatible way from version 8.0
comment:
  OriginalBugID: 2872 Bug
  Version: 8.2
  SubmitDate: '1999-09-23'
  LastModified: '1999-09-28'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  Machine: Other
  ClosedDate: '1999-09-28'


  Name:

  Christopher Nelson


  Comments:

  This incompatible change it not noted in the ChangeLog!


  ReproducibleScript:

  wish -d foo


  ObservedBehavior:

  In version 8.0, this put "-d" and "foo" in the Tcl argv array for script

      access.  In 8.2, it attempts to connect to a display named "foo".  In

      our case, we have a Tk-based application that recognizes an argument -d

      and doesn't start up because of this change.


  DesiredBehavior:

  Tk arguments should not be abbreviated.


  Patch:

  *** tkWindow.c.orig     Wed Sep 22 14:20:28 1999

  --- tkWindow.c  Wed Sep 22 14:20:49 1999

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

  *** 2832,2838 ****

              return TCL_ERROR;

          }

          if (Tk_ParseArgv(interp, (Tk_Window) NULL, &argc, argv,

  !               argTable, TK_ARGV_DONT_SKIP_FIRST_ARG|TK_ARGV_NO_DEFAULTS)

                  != TCL_OK) {

              ckfree((char *) argv);

              goto argError;

  --- 2832,2838 ----

              return TCL_ERROR;

          }

          if (Tk_ParseArgv(interp, (Tk_Window) NULL, &argc, argv,

  !               argTable, TK_ARGV_NO_ABBREV|TK_ARGV_DONT_SKIP_FIRST_ARG|TK_ARGV_

  NO_DEFAULTS)

                  != TCL_OK) {

              ckfree((char *) argv);

              goto argError;


  PatchFiles:

  tk/generic/tkWindow.c




  This parsing has not changed since at least Tk4.0.  This was
  user error based on a (what must have been) locally patched
  version of wish. 
  -- 09/28/1999 hobbs


tkt_uuid: 2100430fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
severity: Minor
foundin: current: 8.5.14
resolution: Fixed
title: ttk::entry widget index must be integer
comment:
  Attempting to adjust the xview of a ttk::entry widget to show the insertion cursor with: 

     pathname xview insert

  results in an error message stating an integer is required.  Similar error with end index.  Easy local fixes with:

      pathname xview [pathname index insert]
  and
     pathname xview [pathname index end]

  but not as documented or as per original entry widget.


tkt_uuid: 220041ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Duplicate
title: menu: command item does not fire on top level menus on unix
comment:
  OriginalBugID: 3479 Bug
  Version: 8.2
  SubmitDate: '1999-11-05'
  LastModified: '2000-04-26'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 630
  OS: SunOS
  OSVersion: 2.6
  ClosedDate: '2000-04-26'


  Name: tom poindexter

  ReproducibleScript:
  catch {console show}
      menu .menu
      . configure -menu .menu
      .menu add cascade -label File -menu .menu.file
      
      menu .menu.file
      .menu.file add command -label "File stuff" -command {puts "File stuff"}
      .menu.file add command -label "Quit" -command {exit}
      
      .menu add cascade -label Edit -menu .menu.edit
      menu .menu.edit
      .menu.edit add command -label "Edit stuff" -command {puts "Edit stuff"}
      
      ####################################################
      #  next line works on windows, but not on unix
      
      .menu add command -label "Do it"  -command {puts "Do it"}
      
      label .l -text "demonstration of menu commands\nunder windows and unix"
      pack .l

  ObservedBehavior:
  a command item in a menu bar does not fire the command on unix.  it does
      
      work under windows.
      
      previously, menu were packed into frames, and ordinary 'button' could be
      packed in the frame, appearing as any other menu button.  i'm trying to
      update some of my code to a newer style of menu handling, using a single
      menu and using ' . configure -menu .menubar '.  unfortunately, a command
      menu item doesn't fire under unix;  when i revert to 'old -style' menus
      using a frame, the resulting menubar doesn't respond quite correctly
      under windows :(

  DesiredBehavior:
  command menu items are invoked on all platforms



  This is a duplicate of bug #630, which was fixed for 8.3.1.  Command entries on menubars now function on Unix.

  - eric

  -- 04/26/2000 ericm


tkt_uuid: 624116ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 8
foundin: obsolete: 8.4.0
resolution: Fixed
title: Scrollbars crash on windows XP
comment:
  The scrollbars crash on XP if they are fully expanded 
  and you try to drag them with the mouse.

  To reproduce, start the wish console, try to drag the 
  vertical scrollbar, and then move the graphics window 
  over the top of the scrollbar to detect the fact that it's not 
  repainting itself and has indeed crashed.

  Not sure if it occurs on any other windows variants.


tkt_uuid: 620498ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 6
foundin: obsolete: 8.4.0
resolution: Fixed
title: TkWinXCleanup free uniEn. exit heap erro
comment:
  When working with a custom shell and Tk 8.4.0 on NT 
  2000, I found that during Tk DLL detachment, there were 
  heap access errors coming from file TkWinXCleanup, file 
  tkWinX.c at the Tcl_FreeEncoding(unicodeEncoding) 
  call.  I am using the default build for Tk as far as 
  threading.  These problems were fixed by changing the 
  logic to be re-entrant safe for the cleanup.  The thinking 
  is that there is more than 1 thread going through the 
  cleanup logic but this is only a hypothesis.  It could be I 
  just moved some bad pointer reference around and thats 
  the real fix!

  void
  TkWinXCleanup(hInstance)
      HINSTANCE hInstance;
  {
      /*
       * Clean up our own class.
       */

      if (childClassInitialized) {
          childClassInitialized = 0;
          UnregisterClass(TK_WIN_CHILD_CLASS_NAME, 
  hInstance);
      }

      if (unicodeEncoding != NULL) {
          Tcl_Encoding ue;
          ue = unicodeEncoding;
          unicodeEncoding = NULL;
              Tcl_FreeEncoding(ue);
      }

      /*
       * And let the window manager clean up its own class
  (es).
       */

      TkWinWmCleanup(hInstance);
  }


tkt_uuid: 927239ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Wish shell crashes on amsn's delete contacts
comment:
  amsn is a msn messenger clone in tcl/tk. I am using it on macosx.
  If i delete about 4 or 5 contacts from the contact list, wish crashes 
  with the following:

  If i delete like 5 contacts or so from the contact list on macosx i 
  always get a crash.

  This is what macosx says about it:

  Date/Time: 2004-02-03 23:37:28 -0400
  OS Version: 10.3.2 (Build 7D24)
  Report Version: 2

  Command: Wish Shell
  Path: /usr/bin/../.././/Applications/Utilities/Wish Shell.app/
  Contents/MacOS/Wish Shell
  Version: 8.4.5 (8.4.5)
  PID: 391
  Thread: 0

  Exception: EXC_BAD_ACCESS (0x0001)
  Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000000d

  Thread 0 Crashed:
  0 com.apple.HIToolbox 0x927d25f8 
  SendEventToEventTargetInternal + 0x174
  1 com.apple.HIToolbox 0x927e4a88 SendEventToEventTarget 
  + 0x28
  2 com.apple.HIToolbox 0x9289b2c4 HIView::
  Click(OpaqueEventRef*) + 0x10c
  3 com.apple.HIToolbox 0x928e9744 HIViewClick + 0x38
  4 com.apple.HIToolbox 0x928b6ef0 HandleClickAsHIView + 
  0x9c
  5 com.apple.HIToolbox 0x928850ec HandleWindowClick + 
  0x204
  6 com.apple.HIToolbox 0x92866458 HandleMouseEvent + 
  0x1b8
  7 com.apple.HIToolbox 0x92828234 
  StandardWindowEventHandler + 0xa8
  8 com.apple.HIToolbox 0x927d2384 DispatchEventToHandlers 
  + 0x150
  9 com.apple.HIToolbox 0x927d25f8 
  SendEventToEventTargetInternal + 0x174
  10 com.apple.HIToolbox 0x927e4a88 SendEventToEventTarget 
  + 0x28
  11 com.apple.HIToolbox 0x927f3208 
  HandleMouseEventForWindow(OpaqueWindowPtr*, 
  OpaqueEventRef*, unsigned short) + 0x144
  12 com.apple.HIToolbox 0x927e8b24 
  HandleMouseEvent(OpaqueEventRef*) + 0x170
  13 com.apple.HIToolbox 0x927e3028 
  ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, 
  OpaqueEventRef*, void*) + 0x1e8
  14 com.apple.HIToolbox 0x927d2440 DispatchEventToHandlers 
  + 0x20c
  15 com.apple.HIToolbox 0x927d25f8 
  SendEventToEventTargetInternal + 0x174
  16 com.apple.HIToolbox 0x927e4a88 SendEventToEventTarget 
  + 0x28
  17 com.apple.HIToolbox 0x927e8980 ToolboxEventDispatcher 
  + 0x5c
  18 com.apple.HIToolbox 0x92805c6c HLTBEventDispatcher + 
  0x10
  19 com.apple.HIToolbox 0x92985ecc _RunAppModalLoop + 
  0x68
  20 com.apple.HIToolbox 0x92965d70 
  RunAppModalLoopForWindow + 0x70
  21 com.tcltk.tklibrary 0x0b07b700 Tk_MessageBoxObjCmd + 
  0x488
  22 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  23 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  24 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  25 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  26 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  27 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  28 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  29 com.tcltk.tcllibrary 0x0a00f2c4 Tcl_EvalObjEx + 0xc0
  30 com.tcltk.tklibrary 0x0b04c100 TkInvokeMenu + 0x1e0
  31 com.tcltk.tklibrary 0x0b084e68 EventuallyInvokeMenu + 0x38
  32 com.tcltk.tcllibrary 0x0a066e30 TclServiceIdle + 0x68
  33 com.tcltk.tcllibrary 0x0a056764 Tcl_DoOneEvent + 0x180
  34 com.tcltk.tklibrary 0x0b022df0 Tk_UpdateObjCmd + 0x9c
  35 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  36 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  37 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  38 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  39 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  40 com.tcltk.tcllibrary 0x0a00ee64 Tcl_EvalEx + 0x174
  41 com.tcltk.tcllibrary 0x0a067554 AfterProc + 0x8c
  42 com.tcltk.tcllibrary 0x0a066c5c TimerHandlerEventProc + 
  0x90
  43 com.tcltk.tcllibrary 0x0a056380 Tcl_ServiceEvent + 0xa4
  44 com.tcltk.tcllibrary 0x0a056750 Tcl_DoOneEvent + 0x16c
  45 com.tcltk.tklibrary 0x0b022df0 Tk_UpdateObjCmd + 0x9c
  46 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  47 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  48 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  49 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  50 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  51 com.tcltk.tcllibrary 0x0a00ee64 Tcl_EvalEx + 0x174
  52 com.tcltk.tcllibrary 0x0a067554 AfterProc + 0x8c
  53 com.tcltk.tcllibrary 0x0a066c5c TimerHandlerEventProc + 
  0x90
  54 com.tcltk.tcllibrary 0x0a056380 Tcl_ServiceEvent + 0xa4
  55 com.tcltk.tcllibrary 0x0a056750 Tcl_DoOneEvent + 0x16c
  56 com.tcltk.tklibrary 0x0b022df0 Tk_UpdateObjCmd + 0x9c
  57 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  58 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  59 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  60 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  61 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  62 com.tcltk.tcllibrary 0x0a00ee64 Tcl_EvalEx + 0x174
  63 com.tcltk.tcllibrary 0x0a067554 AfterProc + 0x8c
  64 com.tcltk.tcllibrary 0x0a066c5c TimerHandlerEventProc + 
  0x90
  65 com.tcltk.tcllibrary 0x0a056380 Tcl_ServiceEvent + 0xa4
  66 com.tcltk.tcllibrary 0x0a056750 Tcl_DoOneEvent + 0x16c
  67 com.tcltk.tklibrary 0x0b022df0 Tk_UpdateObjCmd + 0x9c
  68 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  69 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  70 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  71 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  72 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  73 com.tcltk.tcllibrary 0x0a00ee64 Tcl_EvalEx + 0x174
  74 com.tcltk.tcllibrary 0x0a067554 AfterProc + 0x8c
  75 com.tcltk.tcllibrary 0x0a066c5c TimerHandlerEventProc + 
  0x90
  76 com.tcltk.tcllibrary 0x0a056380 Tcl_ServiceEvent + 0xa4
  77 com.tcltk.tcllibrary 0x0a056750 Tcl_DoOneEvent + 0x16c
  78 com.tcltk.tklibrary 0x0b022df0 Tk_UpdateObjCmd + 0x9c
  79 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  80 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  81 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  82 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  83 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  84 com.tcltk.tcllibrary 0x0a00ee64 Tcl_EvalEx + 0x174
  85 com.tcltk.tcllibrary 0x0a067554 AfterProc + 0x8c
  86 com.tcltk.tcllibrary 0x0a066c5c TimerHandlerEventProc + 
  0x90
  87 com.tcltk.tcllibrary 0x0a056380 Tcl_ServiceEvent + 0xa4
  88 com.tcltk.tcllibrary 0x0a056750 Tcl_DoOneEvent + 0x16c
  89 com.tcltk.tklibrary 0x0b02d56c Tk_MainLoop + 0x14
  90 com.tcltk.tklibrary 0x0b04acf4 Tk_MainEx + 0x320
  91 com.tcltk.wish 0x00015db0 main + 0x11c
  92 com.tcltk.wish 0x000159c4 _start + 0x188 (crt.c:267)
  93 com.tcltk.wish 0x00015838 start + 0x30

  Thread 1:
  0 libSystem.B.dylib 0x9000b30c select + 0xc
  1 com.tcltk.tklibrary 0x0b08a8cc NotifierThreadProc + 0x1c0
  2 libSystem.B.dylib 0x900247e8 _pthread_body + 0x28

  PPC Thread State:
  srr0: 0x927d25f8 srr1: 0x0200f030 vrsave: 
  0x00000000
  cr: 0x24024222 xer: 0x00000004 lr: 0x927d25f8 ctr: 
  0x90001fa0
  r0: 0x927d25f8 r1: 0xbfffb2b0 r2: 0x00000000 r3: 
  0x00000000
  r4: 0x00000000 r5: 0x003ed4b0 r6: 0x00000001 r7: 
  0x00000001
  r8: 0x00000003 r9: 0x00000000 r10: 0xa27f8634 r11: 
  0x44024222
  r12: 0x90001fa0 r13: 0x00000001 r14: 0x00000001 r15: 
  0x00000000
  r16: 0x00000000 r17: 0x00000001 r18: 0x00000000 r19: 
  0x00000000
  r20: 0x00000002 r21: 0x00000000 r22: 0x08f4dfa0 r23: 
  0x08f48ba0
  r24: 0xbfffb7a0 r25: 0xffffd96e r26: 0x08f20fc0 r27: 
  0x00000001
  r28: 0x08f1a840 r29: 0x08f1a840 r30: 0x003d35b0 r31: 
  0x927d248c

  Binary Images Description:
  0x1000 - 0x16fff com.tcltk.wish 8.4.5 /usr/bin/../.././/
  Applications/Utilities/Wish Shell.app/Contents/MacOS/Wish Shell
  0x1722000 - 0x1728fff libtls1.50.dylib /Users/espectro/Library/
  Application Support/amsn/plugins/tls1.50/libtls1.50.dylib
  0xa000000 - 0xa089fff com.tcltk.tcllibrary 8.4.5 /Library/
  Frameworks/Tcl.framework/Versions/8.4/Tcl
  0xb000000 - 0xb0b2fff com.tcltk.tklibrary 8.4.5 /Library/
  Frameworks/Tk.framework/Versions/8.4/Tk
  0x78160000 - 0x7818dfff libssl.0.9.dylib /usr/lib/libssl.0.9.dylib
  0x880a0000 - 0x880a7fff libLW8Utils.dylib /System/Library/
  Printers/Libraries/libLW8Utils.dylib
  0x88170000 - 0x881affff libLW8Converter.dylib /System/Library/
  Printers/Libraries/libLW8Converter.dylib
  0x882a0000 - 0x882c6fff libConverter.dylib /System/Library/
  Printers/Libraries/libConverter.dylib
  0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld
  0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/
  libSystem.B.dylib
  0x90190000 - 0x9023dfff com.apple.CoreFoundation 6.3 (299)
  /System/Library/Frameworks/CoreFoundation.framework/
  Versions/A/CoreFoundation
  0x90280000 - 0x904f9fff com.apple.CoreServices.CarbonCore 
  10.3.2 /System/Library/Frameworks/CoreServices.framework/
  Versions/A/Frameworks/CarbonCore.framework/Versions/A/
  CarbonCore
  0x90570000 - 0x905ddfff com.apple.framework.IOKit 1.3 (???)
  /System/Library/Frameworks/IOKit.framework/Versions/A/
  IOKit
  0x90610000 - 0x90699fff com.apple.CoreServices.OSServices 3.0 
  (3.0.0) /System/Library/Frameworks/CoreServices.framework/
  Versions/A/Frameworks/OSServices.framework/Versions/A/
  OSServices
  0x90700000 - 0x90700fff com.apple.CoreServices 10.3 (???)
  /System/Library/Frameworks/CoreServices.framework/
  Versions/A/CoreServices
  0x90720000 - 0x90787fff com.apple.audio.CoreAudio 2.1.2
  /System/Library/Frameworks/CoreAudio.framework/Versions/
  A/CoreAudio
  0x907f0000 - 0x907f9fff com.apple.DiskArbitration 2.0
  /System/Library/PrivateFrameworks/
  DiskArbitration.framework/Versions/A/DiskArbitration
  0x90810000 - 0x90810fff com.apple.ApplicationServices 1.0 (???)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/ApplicationServices
  0x90910000 - 0x90983fff com.apple.DesktopServices 1.2
  /System/Library/PrivateFrameworks/
  DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
  0x90d00000 - 0x90d19fff com.apple.SystemConfiguration 1.4.1 
  (???) /System/Library/Frameworks/
  SystemConfiguration.framework/Versions/A/SystemConfiguration
  0x90d40000 - 0x90d40fff com.apple.Carbon 10.3 (???)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Carbon
  0x910b0000 - 0x910fffff com.apple.bom 1.2.3 (62.1)
  /System/Library/PrivateFrameworks/Bom.framework/Versions/
  A/Bom
  0x912a0000 - 0x912bdfff com.apple.audio.SoundManager 3.8
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/CarbonSound.framework/Versions/A/CarbonSound
  0x912e0000 - 0x912f7fff com.apple.LangAnalysis 1.5.4
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/LangAnalysis.framework/Versions/A/
  LangAnalysis
  0x91320000 - 0x913defff ColorSync /System/Library/Frameworks/
  ApplicationServices.framework/Versions/A/Frameworks/
  ColorSync.framework/Versions/A/ColorSync
  0x91460000 - 0x91473fff com.apple.speech.synthesis.framework 
  3.2 /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/
  SpeechSynthesis
  0x914a0000 - 0x91509fff com.apple.htmlrendering 1.1.2
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
  0x91560000 - 0x91619fff com.apple.QD 3.4.62 (???)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/QD.framework/Versions/A/QD
  0x91670000 - 0x916a8fff com.apple.AE 1.3.2 /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/AE.framework/Versions/A/AE
  0x916e0000 - 0x91773fff com.apple.print.framework.PrintCore 3.1
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
  0x917e0000 - 0x917f0fff com.apple.speech.recognition.framework 
  3.3 /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/SpeechRecognition.framework/Versions/A/
  SpeechRecognition
  0x91810000 - 0x9182afff com.apple.openscripting 1.2.1 (???)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/OpenScripting.framework/Versions/A/OpenScripting
  0x91850000 - 0x91860fff com.apple.ImageCapture 2.1.0
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/ImageCapture.framework/Versions/A/ImageCapture
  0x91890000 - 0x9189cfff com.apple.help 1.0.1 /System/Library/
  Frameworks/Carbon.framework/Versions/A/Frameworks/
  Help.framework/Versions/A/Help
  0x918c0000 - 0x918cdfff com.apple.CommonPanels 1.2.1 (1.0)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/CommonPanels.framework/Versions/A/CommonPanels
  0x918f0000 - 0x9193dfff com.apple.print.framework.Print 3.0 (3.1)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/Print.framework/Versions/A/Print
  0x91990000 - 0x9199bfff com.apple.securityhi 1.2 (90)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/SecurityHI.framework/Versions/A/SecurityHI
  0x919c0000 - 0x91a32fff com.apple.NavigationServices 3.3
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/NavigationServices.framework/Versions/A/
  NavigationServices
  0x91ab0000 - 0x91ac4fff libCGATS.A.dylib /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/CoreGraphics.framework/Versions/A/Resources/
  libCGATS.A.dylib
  0x91ae0000 - 0x91aebfff libCSync.A.dylib /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/CoreGraphics.framework/Versions/A/Resources/
  libCSync.A.dylib
  0x91b10000 - 0x91b2afff libPDFRIP.A.dylib /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/CoreGraphics.framework/Versions/A/Resources/
  libPDFRIP.A.dylib
  0x91b50000 - 0x91b5ffff libPSRIP.A.dylib /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/CoreGraphics.framework/Versions/A/Resources/
  libPSRIP.A.dylib
  0x91b80000 - 0x91b93fff libRIP.A.dylib /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/CoreGraphics.framework/Versions/A/Resources/
  libRIP.A.dylib
  0x91bb0000 - 0x91d44fff com.apple.QuickTime 6.5.0
  /System/Library/Frameworks/QuickTime.framework/QuickTime
  0x92070000 - 0x92096fff com.apple.FindByContent 1.4 (1.2)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/FindByContent.framework/Versions/A/
  FindByContent
  0x920c0000 - 0x922a6fff com.apple.security 2.1 (163.1)
  /System/Library/Frameworks/Security.framework/Versions/A/
  Security
  0x92430000 - 0x92468fff com.apple.LaunchServices 10.3 (84)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/LaunchServices.framework/Versions/A/
  LaunchServices
  0x92650000 - 0x926f3fff libcrypto.0.9.dylib /usr/lib/
  libcrypto.0.9.dylib
  0x92740000 - 0x92777fff com.apple.CFNetwork 1.2.1 (7)
  /System/Library/Frameworks/CoreServices.framework/
  Versions/A/Frameworks/CFNetwork.framework/Versions/A/
  CFNetwork
  0x927d0000 - 0x92b53fff com.apple.HIToolbox 1.3.1 (???)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/HIToolbox.framework/Versions/A/HIToolbox
  0x92d30000 - 0x92d80fff com.apple.HIServices 1.4.0 (0.0.1d1)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/HIServices.framework/Versions/A/
  HIServices
  0x935d0000 - 0x938a6fff com.apple.CoreGraphics 1.203.12 (???)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/CoreGraphics.framework/Versions/A/
  CoreGraphics
  0x939a0000 - 0x939b4fff libcups.2.dylib /usr/lib/libcups.2.dylib
  0x939d0000 - 0x939d4fff libmathCommon.A.dylib 
  /usr/lib/system/libmathCommon.A.dylib
  0x94060000 - 0x9407ffff com.apple.WebServices 1.1.0
  /System/Library/Frameworks/CoreServices.framework/
  Versions/A/Frameworks/WebServicesCore.framework/Versions/A/
  WebServicesCore
  0x945b0000 - 0x945b9fff libz.1.dylib /usr/lib/libz.1.dylib
  0x94610000 - 0x9462afff libresolv.9.dylib /usr/lib/
  libresolv.9.dylib
  0x94650000 - 0x946affff com.apple.SearchKit 1.0.2
  /System/Library/Frameworks/CoreServices.framework/
  Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
  0x94b20000 - 0x94babfff com.apple.ink.framework 1.1 (54.4)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/Ink.framework/Versions/A/Ink
  0x968d0000 - 0x969b2fff libicucore.A.dylib /usr/lib/
  libicucore.A.dylib
  0x96a20000 - 0x96ae2fff libcrypto.0.9.7.dylib /usr/lib/
  libcrypto.0.9.7.dylib
  0x96b40000 - 0x96b6efff libssl.0.9.7.dylib /usr/lib/
  libssl.0.9.7.dylib
  0x96bf0000 - 0x96c7ffff ATS /System/Library/Frameworks/
  ApplicationServices.framework/Versions/A/Frameworks/
  ATS.framework/Versions/A/ATS

  and this is what amsn/wish say about it:

  /usr/bin/wish: line 2: 391 Bus error "$(dirname )/../
  .././/Applications/Utilities/Wish Shell.app/Contents/MacOS/Wish 
  Shell" "$@"


tkt_uuid: 491427ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
severity: Minor
foundin: None
resolution: Fixed
title: Windows bindings - case sensitive
comment:
  Most of the keyboard bindings in Tk are lowercase 
  only, this means that when a user tries to activate a 
  keyboard binding with the capslock light on the 
  keypress is ignored.

  I've modified tk.tcl as follows at about line 315:

      "windows" {
   event add <<Cut>> <Control-Key-x> <Control-Key-X> 
  <Shift-Key-Delete>
   event add <<Copy>> <Control-Key-c> <Control-Key-C> 
  <Control-Key-Insert>
   event add <<Paste>> <Control-Key-v> <Control-Key-V> 
  <Shift-Key-Insert>
   event add <<PasteSelection>> <ButtonRelease-2>
      }

  As the keyboard bindings are case sensitive I've had 
  to add the capital X/C/V bindings also.

  I posted this on comp.lang.tcl, some notes were made 
  about distinguishing between control-key and control-
  shift-key but as discussed this shouldn't cause any 
  problems. When capslock is on the user isn't pressing 
  Shift.

  All other bindings should be reviewed also and 
  extended to include upper and lower case(?).


tkt_uuid: 3126428fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: ttk::button does not show image change
comment:
  A ttk::button displays an image.
  If the image changes in a) contents or b) size, this is not correctly displayed.
  A contents change is updated if the widget is redrawn.
  A size change is only updated if the image is configured again to the button.
  Within a non-themed button widget, an image change is directly displayed.

  Sample procedure on an interactive wish8.5.9 and Windows Vista 32 bit Aero Theme:
  % image create photo i -height 30 -width 30
  % i put red -to 0 0 29 29
  % pack [button .b1 -image i] [ttk::button .b2 -image i] [ttk::button .b3 -image i] -side left
  #-> 3 red buttons

  % i put black -to 0 0 29 29
  #-> Only button 1 changes color

  % .b2 configure -image i
  #-> Button 2 changes color

  # minimize and maximize window -> all button black

  % i configure -width 100 -height 100
  #-> only button 1 changes size

  % .b2 configure -image i
  #-> Button 2 changes size

  # minimize and maximize window -> no change 


tkt_uuid: 552509ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: None
title: Patch 541999 and multi-byte strings
comment:
  The recent patch 541999 has some side effects
  that do not allow multi-byte strings to be drawn
  correctly by Tk_DrawChars. A patch is attached
  that tries to correct things while keeping
  the new things from the 541999 patch.


tkt_uuid: 2725308fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: Option to exclude hidden unix files
comment:
  Add an -excludehidden option (or something equivalent) to the tk_getOpenFile and tk_getSaveFile dialogs, so that files whose names begin with "." are excluded from the displayed list of files.  If the option can be implemented in a more general way that works on all platforms (i.e., -exclude pattern), that's great.

  This would prevent the dialogs from displaying the myriad of hidden directories that tend to infest a user's home directory under Unix/Linux, unless of course they were desired.


tkt_uuid: 643800ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 4
foundin: obsolete: 8.4.1
resolution: Out of Date
title: buttonrelease-2 copy/paste on aqua Tk
comment:
  aqua Tk 8.4.1 on MacOS X 10.2: the buttonrelease-2 event seems to paste the selected text (at lest for entry and text widgets). I'd not be surprised to learn this is normal unix X behavior (though it seems oddly specialized; I could not find corresponding clicks to just copy or just paste data!), but it has some problems on the Mac, including:

  - The usual Mac behavior for button-2 is to pop up a contextual menu, if there is one. Thus the default binding for buttonrelease-2 will not only confuse users, but could easily corrupt the data the user has entered. (I found this out when I started putting contextual menus in my application; I also had to disable buttonrelease-2 to get sane behavior).

  - The copied data does not go onto the Mac clipboard, and thus cannot be moved to other normal Mac applications.

  My main suggestion would be to remove the binding for buttonrelease-2. If it will be kept, then please consider changing it to something less easy to stumble over (e.g. something that requires a modifier key) and putting the data on the normal clipboard.

  -- Russell


tkt_uuid: 220199ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Possible regexp bug in Tcl8.1.1-11.06 with text widget
comment:
  OriginalBugID: 2226 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-15'
  LastModified: '1999-08-05'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.5.1
  Machine: Other
  ClosedDate: '1999-08-05'


  Comments:
  It could be that I'm guilty for assuming that the Tcl8.1.1-11.06
      would work with Tk8.1.1, but in a checkout of the Tk stuff, the
      text widget hasn't had mods in that area anyway.

  ReproducibleScript:
  I compiled the Tcl8.1.1 11 June CVS tree (with Unicode string obj) and
      when I used it with Tk8.1.1 (stock), the text widget's regexp stuff
      no longer worked as expected.

  ObservedBehavior:
  In tkcon, the text widget regexps for proc/path/varname expansion that
      worked in Tcl/Tk8.1.1 (stock) and Tcl/Tk8.0 no longer function with the
      combination Tcl8.1.1-11.06 and Tk8.1.1.  (regexps can be found in
      tkConExpand).

  DesiredBehavior:
  The regexp to match as usual.



  Seems to have been taken care of somewhere along the way. 
  -- 08/05/1999 hobbs


tkt_uuid: 220596ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: CDE window manager Close operation causes dump
comment:
  OriginalBugID: 2802 Bug
  Version: 8.2
  SubmitDate: '1999-09-16'
  LastModified: '2000-01-17'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2483
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '2000-01-17'
  FixedInVersion: 8.2.1


  Name:
  Larry W. Virden

  CVS:
  August 23, 1999 15:42 EDT

  Extensions:
  Tcl / Tk 8.2, stooop 4.0.1, scwoop 2.6

  CustomShell:
  I have compiled the latest modules from the CVS.

  ReproducibleScript:
  I installed Tcl/Tk 8.2 with the latest patches cvs has returned.
      I installed stooop-4.0.1 and scwoop-2.6.
      I then ran scwoop-2.6/confdemo.tcl .  It brought up the demo fine.  To
      terminate the application, I used the Close option that CDE's window
      manager
      provides on the window title bar.

  ObservedBehavior:
  wish core dumped.
      
      Reading wish
      core file header read successfully
      Reading ld.so.1
      Reading libtk8.2.so
      Reading libtcl8.2.so
      Reading libsocket.so.1
      Reading libnsl.so.1
      Reading libX11.so.4
      Reading libdl.so.1
      Reading libm.so.1
      Reading libc.so.1
      Reading libmp.so.2
      Reading libXext.so.0
      Reading libc_psr.so.1
      program terminated by signal SEGV (no mapping at the fault address)
      (dbx 1) where                                                  
      =>[1] Tcl_DeleteHashEntry(0xef628228, 0x48, 0x132b10, 0x10d1a8,
      0x121490, 0xd8), at 0xef5d1d94
        [2] Tcl_DeleteCommandFromToken(0x8a798, 0x12e8c8, 0xe, 0xef322eb4,
      0x10d1a8, 0xd9), at 0xef5a7d50
        [3] DestroyEntry(0x12eaa8, 0xef73a7a0, 0xefffddc0, 0xefffddc0,
      0xef322eb4, 0xef2c672c), at 0xef6e20b0
        [4] Tk_HandleEvent(0x12e9c8, 0xef73a7a0, 0x8a798, 0x12e9c8, 0x20000,
      0x2f300), at 0xef6b04c0
        [5] Tk_DestroyWindow(0x12e9c8, 0x2d008, 0xef73a7a0, 0x0, 0x3d6a0,
      0x12e9c8), at 0xef6c8d40
        [6] Tk_DestroyWindow(0x12cf20, 0x12e9c8, 0xef73a7a0, 0x0, 0x3d6a0,
      0x12cf20), at 0xef6c8c7c
        [7] Tk_DestroyWindow(0x10ad78, 0x12cf20, 0xef73a7a0, 0x143688,
      0x3d6a0, 0x10ad78), at 0xef6c8c7c
        [8] Tk_DestroyWindow(0x97188, 0x10ad78, 0xef73a7a0, 0xde614, 0x3d6a0,
      0x97188), at 0xef6c8c7c
        [9] Tcl_DeleteCommandFromToken(0x8a798, 0xac6f0, 0x8a988, 0x13f900,
      0xef322eb4, 0xef5e3ed4), at 0xef5a7d9c
        [10] TclTeardownNamespace(0x8aa18, 0x0, 0x8a9e4, 0x13f900, 0x146450,
      0x8a798), at 0xef5e3f14
        [11] DeleteInterpProc(0x8a798, 0xef61946c, 0xef73a7a0, 0x91428,
      0x8a798, 0x896f0), at 0xef5a6b58
        [12] Tk_HandleEvent(0x896f0, 0xef73a7a0, 0x8a798, 0x896f0, 0x0,
      0x2f300), at 0xef6b0520
        [13] WindowEventProc(0x146148, 0xfffffffd, 0xef61946c, 0x1436a0,
      0xef322eb4, 0xef5e7434), at 0xef6b0a1c
        [14] Tcl_ServiceEvent(0xef6b09a0, 0x22c50, 0x146140, 0xfffffffd, 0x0,
      0x22e14), at 0xef5e734c
        [15] Tcl_DoOneEvent(0x0, 0xef61946c, 0x22c50, 0x0, 0x22c68, 0x1), at
      0xef5e766c
        [16] Tk_MainLoop(0x22fa0, 0xef61946c, 0x4, 0x0, 0xefffe438, 0x22fa0),
      at 0xef6b0ab8
        [17] Tk_MainEx(0x29ee8, 0xef74a6d4, 0xefffe438, 0x22fa0, 0xef73a7a0,
      0x10c60), at 0xef6bcf50
        [18] main(0x2, 0xefffe5c4, 0x20d78, 0x20c00, 0x0, 0x0), at 0x10c40
      (dbx 2)

  DesiredBehavior:
  no core dumps from wish



  This looks to be related to 2483, where long window pathnames used
  in megawidget like code could overflow a static buffer.  This was
  fixed in 8.2.1 (I can't reproduce this bug in 8.3). 
  -- 01/17/2000 hobbs


tkt_uuid: 1055023fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Fixed
title: Aqua button compound changes incomplete
comment:
  Under Aqua, configuring a button with -compound and a
  value other than none, then configuring it to none,
  only partially updates the geometry and leaves the
  text.  This can yield strange effects such as having
  the button text appear in the center of the button when
  it is supposed to not appear at all, or shift the image
  out of the center of the button.  e.g.

  pack [button .b -text Foo -image $img]
  .b configure -compound top
  .b configure -compound none

  The problem appears to be that the Aqua native control
  only has its text ("title") property changed when the
  text for the button changes.  It does not get re-set
  when the compound setting changes to none.

  The attached patch fixes the problem for me (note the
  version in the diffs is from my repository, not
  sourceforge's).


tkt_uuid: 220904ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Accepted
title: Meta in bind will not work with command key
comment:
  OriginalBugID: 4467 Bug
  Version: 8.3
  SubmitDate: '2000-03-22'
  LastModified: '2000-04-07'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: MacOS S-9.0 (Swedish)
  Machine: G3/350 (B/W), iMac 233


  Name:
  Johan Dahl

  ReproducibleScript:
  toplevel .w
  # This works
  bind .w <Command-a> {puts {Command-A was pressed}}
  # This will not work
  bind .w <Meta-b> {puts {Meta-B was pressed}}

  ObservedBehavior:
  Meta in menu accelerator will bind to using the Command key
  But not in bind.

  DesiredBehavior:
  Meta in bind should use the Command key, analoguous to how it works in menus


tkt_uuid: 1866774fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: Fixed
title: Remove X10 references from docs
comment:
  Hi *,

  X10 bitmaps are unsupported. At least if this error message is to be trusted:

  > wish8.5
  % image create bitmap -file logo_superh_mono.x10bm
  format error in bitmap data; looks like it's an obsolete X10 bitmap file
  % info patchlevel
  8.5.0

  The man pages GetBitmap and GetCursor are still mentioning it.

  BTW: the same error comes in 8.4.17 and 8.4.14 too. Using cvs annotate on generic/tkImgBmap.c, it seems it is unsupported since the early days of Tk 8.0...

  System: openSUSE 10.2 (X86-64)

  kind regards -- Matthias Kraft


tkt_uuid: 793252ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 8
foundin: obsolete: 8.4.4
resolution: Fixed
title: missing var in <ButtonRelease-2> binding
comment:
  Pack a [scale] widget:

  % pack [scale .a -orient horizontal \
                 -resolution .1 \
                 -from -180 -to 180]

  Then click and release mouse button 2
  within the scale.

  Up pops the error message:

  can't read "Priv(.a,relief)": no such element in array.


tkt_uuid: 220750ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: Tcl Help 8.4 crashes on Tk Built-In Commands - keysyms
comment:
  OriginalBugID: 5862 Bug
  Version: 8.4a1
  SubmitDate: '2000-06-08'
  LastModified: '2000-06-30'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows NT
  FixedDate: '2000-06-30'
  FixedInVersion: 8.4a2


  Name:
  Bob Halpin

  ReproducibleScript:
  Tcl Help 8.4 crashes on Tk Built-In Commands - keysyms.
  Error is: There is not enough memory available for this task. 
  (There is lots of memory).



  After some experimentation, it seems that the markup our help generator uses for code segments in the man pages cannot handle very large code segments.  A little testing indicates that the breaking point is somewhere around 600-700 lines; when I strip out the last few hundred keysyms from the man page, the help generated is fine.  We might be able to get around this just by breaking up the man page into chunks, ie:

  .CS
  ...
  .CE
  .CS
  ...
  .CE

  instead of
  .CS
  ...
  ...
  .CE

  - eric

  -- 06/25/2000 ericm

  I tried the above fix, and it works.  The fixed man pages have been committed to the CVS repository, and the fix will go out with Tcl/Tk 8.4a2.

  - eric

  -- 06/30/2000 ericm


tkt_uuid: 597009ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: None
resolution: Fixed
title: configuring tabs is counterintuitive
comment:
  Consider the following script:

  ----
  text .t1 -width 50 -height 3 -font courier -bd 2
  -relief sunken
  text .t2 -width 50 -height 3 -font courier -bd 2
  -relief sunken

  # configure t2 to have tabs set at every 8 characters
  set font [font actual [.t2 cget -font]]
  set emWidth [expr {([font measure $font M]/72.0)/[tk
  scaling]}]
  .t2 configure -tabs "[expr {$emWidth * 8}]i"

  set text "1234567890123456789012345678901234567890
  \tt1\tt2\tt3\tt4
  Hello, World!\ttab\ttab\ttab\ttab
  "
  .t1 insert end $text
  .t2 insert end $text

  pack .t1 .t2 -side top -fill both -expand y
  ----

  Notice that the bottom window has a different behavior
  than the top window, even though the tabstops in both
  windows are, in theory, identical. 

  The problem is, when the widget is configured via
  -tabs, the first occurance of a tab tries to place the
  text at the first tabstop rather than the next tabstop.
  This latter behavior -- moving the text to the next
  tabstop -- is what I consider to be the proper behavior
  since that's what probably every text editor known to
  man does.

  Fixing this could break old scripts, though I doubt
  very few scripts actually rely on this feature. If
  backwards compatibility is a concern, I'd humbly
  suggest another option be added to the text widget,
  such as "-tabmode" (eg: -tabmode traditional)


tkt_uuid: 965618ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 31. Cursor Names
priority: 8
foundin: obsolete: 8.4.6
resolution: Fixed
title: -cursor {} undocumented
comment:
  Bug 894550 mentions the following:

  "I believe the {} cursor name
  should restore the cursor to its default state, but I
  haven't found
  where this is stated in the docs (nothing in the
  Tk_GetCursor
  manpage seems to mention the {} cursor). However, several
  applications use this empty cursor name to restore the
  cursor (for
  instance TkChat relies on this behaviour)."

  and gives the following example:

  pack [canvas .c]
  .c create rect 50 50 100 100 -fill red -tags link
  .c bind link <Enter> [list .c configure -cursor hand1]
  .c bind link <Leave> [list .c configure -cursor {}]

  This behaviour, if valid, should be documented.


tkt_uuid: 220112ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: zombie processes left behind on Windows NT
comment:
  OriginalBugID: 755 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-22'
  LastModified: '2000-01-06'
  Severity: MED
  Status: Closed
  Submitter: admin
  ChangedBy: hobbs
  OS: Windows NT
  FixedInVersion: NA
  ClosedDate: '2000-01-06'


  The enclosed file leaves a zombie process on Win NT.  To recreate,
  make sure prowish80.exe is the default *.tcl exe, and then double
  click on the zombie.tcl file.

  bill wilborn wrote:

  I got a fix for this problem at the conference.   Iam now including
      "wm protocol . WM_DELETE_WINDOW {exit}"
  in each program so when the X is selected to close the window, the Tk
  exit routine is run.

    -Bill Wilborn

  brent wrote:

  The solution to the "zombie" problem is a nice work-around, but still,
  it's a hack.  I'd like too understand what's causing the problem, so
  we can fix it in the Tcl core.

    -brent
  ------
  # zombie.tcl

  global widget; 

  proc {main} {argc argv} {

  }

  proc {Window} {args} {
  global vTcl
      set cmd [lindex $args 0]
      set name [lindex $args 1]
      set newname [lindex $args 2]
      set rest [lrange $args 3 end]
      if {$name == "" || $cmd == ""} {return}
      if {$newname == ""} {
          set newname $name
      }
      set exists [winfo exists $newname]
      switch $cmd {
          show {
              if {$exists == "1" && $name != "."} {wm deiconify $name; return}
              if {[info procs vTclWindow(pre)$name] != ""} {
                  eval "vTclWindow(pre)$name $newname $rest"
              }
              if {[info procs vTclWindow$name] != ""} {
                  eval "vTclWindow$name $newname $rest"
              }
              if {[info procs vTclWindow(post)$name] != ""} {
                  eval "vTclWindow(post)$name $newname $rest"
              }
          }
          hide    { if $exists {wm withdraw $newname; return} }
          iconify { if $exists {wm iconify $newname; return} }
          destroy { if $exists {destroy $newname; return} }
      }
  }

  #################################
  # VTCL GENERATED GUI PROCEDURES
  #

  proc vTclWindow. {base} {
      if {$base == ""} {
          set base .
      }
      ###################
      # CREATING WIDGETS
      ###################
      wm focusmodel $base passive
      wm geometry $base 200x200+0+0
      wm maxsize $base 1156 849
      wm minsize $base 112 1
      wm overrideredirect $base 0
      wm resizable $base 1 1
      wm withdraw $base
      wm title $base "vt"
      ###################
      # SETTING GEOMETRY
      ###################
  }

  proc vTclWindow.top17 {base} {
      if {$base == ""} {
          set base .top17
      }
      if {[winfo exists $base]} {
          wm deiconify $base; return
      }
      ###################
      # CREATING WIDGETS
      ###################
      toplevel $base -class Toplevel
      wm focusmodel $base passive
      wm geometry $base 200x111+380+137
      wm maxsize $base 1156 849
      wm minsize $base 112 1
      wm overrideredirect $base 0
      wm resizable $base 1 1
      wm deiconify $base
      wm title $base "Hello World"
      entry $base.ent18  -textvariable txtout 
      button $base.but19  -text {Press Me} -command {set txtout {Hello World}}
      ###################
      # SETTING GEOMETRY
      ###################
      place $base.ent18  -x 5 -y 20 -width 191 -height 22 -anchor nw -bordermode ignore 
      place $base.but19  -x 65 -y 60 -anchor nw -bordermode ignore 
  }

  Window show .
  Window show .top17

  main $argc $argv



  Verified with 8.3b1 on NTsp4. 
  -- 01/06/2000 hobbs
  After further examination (This VTcl stuff is just screwy...), this
  is not a zombie process.  What is happening is that the user has
  caused the true '.' main window to be "withdrawn", which means it
  won't show up in the taskbar.  The window that you X out is .top17,
  and thus you leave the wish process running with . hidden. 
  -- 01/06/2000 hobbs


tkt_uuid: 220372ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Bug in tkWinWm.c
comment:
  OriginalBugID: 641 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1999-08-06'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  Found a bug in tkWinWm.c that causes system menubars to disappear
  from toplevel widgets if the toplevel style is changed,
  e.g. by using wm transient or wm overrideredirect.

  File: tkWinWm.c
  Line: 734
  Routine: UpdateWrapper
  Code:

      if (oldWrapper && (oldWrapper != wmPtr->wrapper) 
              && (oldWrapper != GetDesktopWindow())) {
          SetWindowLong(oldWrapper, GWL_USERDATA, (LONG) NULL);

  /* bug fix: Must remove any system menubar before deleting wrapper
   *          else the menubar gets deleted too !
   */
          SetMenu(oldWrapper,NULL);


          DestroyWindow(oldWrapper);
      }


  This fix exists in the 8.2b2 code. 
  -- 08/06/1999 hobbs


tkt_uuid: 220884ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 4
foundin: obsolete: 8.2.2
resolution: Out of Date
title: Mac Scroll bars don\'t work consistently
comment:
  OriginalBugID: 3734 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-01'
  LastModified: '2000-01-29'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: MacOS 8.1
  Machine: Power Mac 7300/200, 96MB RAM


  Name:
  Duane T Williams

  Comments:
  I have just started playing with tcl/tk, but I'm a professional computer programmer and have 20 years experience with Unix and 15 years experience with the Macintosh.

  ReproducibleScript:
  I ran the Widgets Demo program on my 200 MHz Power Mac 7300.  When I tried the scroll bar demo, I observed that click-hold in the arrows usually did not cause continuous scrolling as it should have done, although occasionally it would work.  Instead of continuous scrolling, I would see a one step scroll and then it would stop.

  I also observed strange behavior with the Radio Buttons demo.  Often I would click on a button and nothing would happen.  To make the buttons work reliably, I had ot click and hold until the button was highlighted.

  ObservedBehavior:
  Scroll bars in the Widgets Demo usually did not continuously scroll when they should.  Radio buttons and check boxes failed to register clicks unless the mouse was held down until after the button began to highlight.

  DesiredBehavior:
  I expected that mouse down events would not be lost and I expected that scroll bars would work reliably.


tkt_uuid: 1111213fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Fixed
title: Error in Spanish translation of "save" (file)
comment:
  In tk_getSaveFile the Spanish (locale es_es)
  translation of "save" as "salvar" is
  incorrect. It should be "guardar".


tkt_uuid: 2321708fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: None
title: radiobutton (and checkbutton) behavior question
comment:
  The documentation for radiobutton and checkbutton has, for quite some time, included a paragraph to this effect:

       Command-Line Name:-selectcolor
       Database Name:  selectColor
       Database Class: Background

            Specifies a background color to use when the button is
            selected.  If indicatorOn is true then the color applies to
            the indicator.  Under Windows, this color is used as the
            background for the indicator regardless of the select state.
            If indicatorOn is false, this color is used as the back-
            ground for the entire widget, in place of background or
            activeBackground, whenever the widget is selected.  If
            specified as an empty string then no special color is used
            for displaying when the widget is selected.

  That isn't exactly what Tk is doing, as of Tk 8.5 I think.

  What happens on Solaris is now the same thing as happens on Windows - the background is used regardless of the select state. 

  The original behavior - using the color only when the item is selected - is really the preferred behavior. 

  Of course, an enhancement to provide a -deselectcolor and a -tristatecolor setting would probably be even better.


tkt_uuid: 2441884fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Fixed
title: Incorrect indenting in [selection] man page
comment:
  The second paragraph describing [selection own] is not indented correctly.  The attached patch adds .RS and .RE macros to fix the indenting.  .RS and .RE must bracket all description paragraphs except for the one immediately following a .TP.


tkt_uuid: 1626419fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: Text widget documentation bug -inactiveselectionbackground
comment:
  The text widget documentation says:

  Command-Line Name: -inactiveselectionbackground 
  Database Name: inactiveSelectionBackground 
  Database Class: Foreground 
  Specifies the colour to use for the selection (the sel tag) when the window does not have the input focus. If empty, {}, then no selection is shown when the window does not have the focus. 


  Actually the -inactiveselectionbackground does not exist.

  Correct spelling is -inactiveselectbackground

  Don't know whether the database name is correct or not.

  Francois


tkt_uuid: 1038760fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 70. Event Loop
priority: 5 Medium
foundin: None
resolution: None
title: Tcl_DoOneEvent doesn't return when modal dialog is open.
comment:
       I have a problem with Tcl_DoOneEvent when used 
  with modal dialog box. 
  I am using C-Tcl/Tk interface on linux platform with C as 
  backend and Tcl/Tk as GUI front end. In C program I use 
  the call Tcl_DoOneEvent to service all Tcl events. If 
  TCL_DONT_WAIT flag is specified with this call, this call  
  should return when there are no events to handle. It 
  does return normally, but not when a modal dialog is 
  opened in Tcl/Tk. Thus, when a modal dialog box is 
  opened, my C program is effectively 'blocked' and I 
  cannot use C program to update display in GUI front 
  end. 
    I have attached a sample C and Tcl program to 
  simulate this problem. It can be compiled for linux with
  gcc -o tclmodal main.c -ltcl8.4 -tk8.4

    Following is the event loop shown here from attached 
  file main.c
  while (TclIsRunning) {
        while (Tcl_DoOneEvent(TCL_ALL_EVENTS | 
  TCL_DONT_WAIT));
  printf("Returned from Tcl_DoOneEvent ");
  usleep(10);   
  }
  When you run tclmodal, it will repeatedly print "Returned 
  from Tcl_DoOneEvent". But if you click File->Open, it will 
  open a dialog box and you will see that print messages 
  are stopped indicating that Tcl_DoOneEvent has not 
  returned. Closing the dialog box will resume printf 
  messages. 
     Can anybody explain this behavior of Tcl_DoOneEvent 
  and help me find a solution so that my C program is 
  not 'blocked' when modal dialog box is open ? I would 
  really appreciate the help. 

  The file attached is : main.c   
  I could attach only one file with the tracker, so I have 
  printed here contents of modaldlg.tcl. Just copy 
  following part to modaldlg.tcl file and run C application.  
  # modaldlg.tcl file for eventloop testing
  . configure -menu .mbar
  menu .mbar
  .mbar add cascade -label "File" -menu .mbar.file
  menu .mbar.file -tearoff 0
  .mbar.file add command -label "Open..." \
  -command {set openFile [tk_getOpenFile -
  title "Select File to Open"]}


tkt_uuid: 2930958fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Error when selecting a file in unix and directory is protect
comment:
  proc ::tk::dialog::file::ListInvoke in file tkfbox.tcl

  from:

              tk_messageBox -type ok -parent $w -message -icon warning \
                      [mc "Cannot change to the directory \"%1\$s\".\nPermission denied." $file]

  to

              tk_messageBox -type ok -parent $w -message -icon warning -message \
                      [mc "Cannot change to the directory \"%1\$s\".\nPermission denied." $file]


tkt_uuid: 220264ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: final: 8.2.3
resolution: Invalid
title: tk install: wrong include dir to tcl
comment:
  OriginalBugID: 3898 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-20'
  LastModified: '1999-12-20'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-SuSE
  ClosedDate: '1999-12-20'


  Name:
  endric

  CVS:
  99/12/17 11pm PST

  ReproducibleScript:
  to make tk compile, this variable in the makefile

  TCL_GENERIC_DIR =/home/endric/src/tcl8.2.2/generic

  should rather be .../src/tcl8.2.3/generic

  ObservedBehavior:
  source distrib wont compile/install

  DesiredBehavior:
  should compile/install ;-)



  If the user has multiple version of tcl around, then Tk might
  not find the right one, and it is up to the user to specify the
  correct version during the config step, like so:
     ./configure --with-tcl=...
  where '...' is the path to the unix subdirectory with tclConfig.sh. 
  -- 12/20/1999 hobbs


tkt_uuid: 3535362fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 8
foundin: obsolete: 8.5.11
resolution: Fixed
title: tk-8.5.8 does not compile with uclibc-nptl-0.9.33
comment:
  OS Platform : Linux (any version)
  Libc : uclibc-nptl-0.9.33

  Problem Behavior :
  ________________

  Building tk-8.5.8 package against uclibc-nptl-0.9.33 fails as follows :
  ---------------------------------------------------------------------------------------------------------------------------------------
  build/packages/tk-sh4_uclibc/BUILD/tk8.5.8/unix/../generic/ttk/ttkTreeview.c:482:17:
  error: conflicting types for 'unshare'
  /sh4_uclibc/target/usr/include/bits/sched.h:85:12:
  note: previous declaration of 'unshare' was here
  make: *** [ttkTreeview.o] Error 1
  ---------------------------------------------------------------------------------------------------------------------------------------
  Indeed uclibc commit w/ git id 19dd090a0f68765db87990ef8eda9bf77bb29581
  exported the unshare libc function to invoke the unshare kernel syscall.
  Unfortunately, tk8.5.8/generic/ttk/ttkTreeview.c got a static function called 'unshare' which
  clashes with libc one during compilation because definition of the latter gets loaded in.
  This issue is not appearing when compiling against glibc as in this case a different headers
  inclusion chain is generated vs uclibc so the libc unshare definition doesn't get loaded.

  Expected Behavior :
  ________________

  tk8.5.8/unix/../generic/ttk/ttkTreeview.c shall compile fine.

  Solution :
  ________

  Shall be to rename the unshare function inside ttkTreeview.c .


tkt_uuid: 231165ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Wont Fix
title: tk_chooseDirectory converts path to uppercase (Windows 98)
comment:
  #Run the following code (Windows 98, Wish 8.3.2)

  set f [tk_chooseDirectory -title "Choose a Directory with lowercase naming"]
  tk_messageBox -message "Directory chosen:$f"

  #the message box will show the uppercase conversion


tkt_uuid: 1115907fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Fixed
title: Man page missing value
comment:
  In the man page in the description for "pathName dump
  ?switches? index1 ?index2?" it lists the possible key
  values. I believe that it is missing the key value "image".

  Lio.


tkt_uuid: 667631ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: Drawing Text in XOR mode does not work on Windows
comment:
  Submitted by: jmartin _a_t_ notamusica D.O.T com

  When the current GC has been set to use XOR mode
  (XSetFunction(GCxor)), I would expect Tk_DrawChars() to
  draw the characters in xor mode, i.e. a second
  Tk_DrawChars() of the same text at the same location
  should remove the text. This is indeed how things work
  under Unix.

  Unfortunately, the windows implementation of
  Tk_DrawChars() always draws characters in copy mode. It
  uses the windows SetROP2() function to set the
  appropriate drawing mode, but SetROP2() applies only to
  windows drawing operations, not to windows text output,
  so it does not affect the way text is drawn.

  A solution might be to draw the text to a temporary
  bitmap and then XOR (or whatever the appropriate
  gc->function is) this temporary bitmap with the
  drawable/dc.


tkt_uuid: 1020001fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 6
foundin: obsolete: 8.5a2
resolution: Fixed
title: Ignorance of dead keys
comment:
  Hi, 

  As I post to news, I have problem with ignorance dead
  keys in input to entry, text vidget etc. There is
  sample code.

  #!/usr/bin/wish -f
  entry .oute
  label .nadpis -text "Label text : "
  grid .nadpis -row 0 -column 0
  grid .oute   -row 0 -column 1

  When entry alone (comment out "grid .nadpis -row 0
  -column 0"), thinks work normally. When add label to
  geometry, then i can type for example zcaron () as
  signe keyboard press, its ok. But when I type caron (as
  dead key) and then "z" i got only z and no z acaron.

  My locale settings:
  LANG=cs_CZ
  LC_ALL=cs_CZ
  LC_CTYPE=cs

  I test it with XFree86 Version 4.2.1.1 and XFree86
  Version 3.3.6a - no differneces.

  On same machine, all other nonTk apps working ok
  Previous Tk from CVS (i use from Sat, 19 Jun 2004)
  working ok
  Tk8.1-8.4 working ok

  Michal


tkt_uuid: 220430ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: The focus -force command does not work if the window has been iconized
comment:
  OriginalBugID: 1176 Bug
  Version: 8.0.5
  SubmitDate: '1999-02-10'
  LastModified: '1999-08-15'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-15'
  FixedInVersion: 8.2


  Test script:

  after 6000 reraise

  proc reraise {} {
      after 6000 reraise

      wm deiconify .
      raise .
      focus -force .
  }

  Run this test script and minimize the window. Notice that it will not pop up above all other ones as it should. When it does pop up, it does not have the focus.



  This works as expected in 8.2.0.  A change was made to deiconify
  for Windows in 8.2b3 that makes raise and focus superfuous. 
  -- 08/15/1999 hobbs


tkt_uuid: 220171ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 26. Conversions from String
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_NameOfJoinStyle API
comment:
  OriginalBugID: 1878 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:25 - kenj - Already documented in GetJoinStl.3


tkt_uuid: 220668ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: Shifted dead keys on Windows.
comment:
  OriginalBugID: 4105 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-31'
  LastModified: '2000-02-10'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3359
  OS: All Windows
  FixedDate: '2000-02-10'
  FixedInVersion: 8.3


  Name:
  Peter Spjuth

  ObservedBehavior:
  The main bug is that you can't use shifted dead keys on Windows.
  This patch also fixes some other bugs I stumbled upon, including that keyboard lock lamps did not work on Win98.

  Patches and more info can be downloaded from:
  http://www.dtek.chalmers.se/~d1peter/deadkey.zip

  My binaries with the patch applied can be found at:
  http://www.dtek.chalmers.se/~d1peter/tcl.zip



  Patch applied and tested for 8.3.0. 
  -- 02/10/2000 hobbs


tkt_uuid: 220084ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Duplicate
title: The main window is active,but located behind other open windows
comment:
  OriginalBugID: 5229 Bug
  Version: 2.0b6
  SubmitDate: '2000-04-22'
  LastModified: '2000-05-27'
  Severity: LOW
  Status: Closed
  Submitter: yakoubov
  ChangedBy: hobbs
  RelatedBugIDs: 5482 4016
  OS: All Windows
  ClosedDate: '2000-05-27'


  Steps to reproduce:
  1)Start Author
  2)Add URL's,create any actions
  3)Activate main window
  Expected results: If the main window is active,I'd expect it to be located on the top of the screen
  Actual results: The main window is active,but located behind other windows.



  Need more control of transient windows from Tk.
   
  -- 05/08/2000 redman


