# ticket

tkt_uuid: 220072ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Duplicate
title: XIM support for Tk
comment:
  OriginalBugID: 4280 RFE
  Version: 8.3
  SubmitDate: '2000-03-01'
  LastModified: '2000-05-10'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4143 5425
  OS: All Unix
  ClosedDate: '2000-05-10'


  Name:

  Jan Nijtmans


  DesiredBehavior:

  Currently, XIM support doesn't work yet on UNIX. Here are the patches originally

  written by m-hirano <m-hirano@sra.co.jp> to make everything work.

  My adaptations are only related to some simplifications, moving part of

  the changes fro Tcl to Tk.

  This patch needs the following fix to Tcl, already contributed. See:

    http://www.deja.com/=dnc/getdoc.xp?AN=588973271


  Patch:

  *** unix/configure.in.origThu Feb 10 12:11:02 2000

  --- unix/configure.inSun Feb 27 09:43:40 2000

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

  *** 372,377 ****

  --- 372,484 ----

    TK_SHARED_BUILD=${SHARED_BUILD}


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

  + #Checking X lib for i18n related things.

  + #--------------------------------------------------------------------

  + 

  + X11_IMAKE_FLAGS=""

  + tk_oldCflags=$CFLAGS

  + tk_oldLibs=$LIBS

  + CFLAGS="$CFLAGS $XINCLUDES"

  + LIBS="$XLIBSW $LIBS"

  + 

  + AC_MSG_CHECKING([XRegisterIMInstantiateCallback])

  + AC_TRY_LINK([

  + #include <X11/Xlib.h>

  + ], [

  + XRegisterIMInstantiateCallback(0, 0, 0, 0, 0, 0);

  + ], [

  + AC_MSG_RESULT(yes)

  + X11_IMAKE_FLAGS="-DHAVE_XIMREGINSTCB"

  + ], [

  + AC_MSG_RESULT(no)

  + ])

  + 

  + AC_MSG_CHECKING([XIDProc])

  + AC_TRY_COMPILE([

  + #include <X11/Xlib.h>

  + ], [

  + XIDProc *a;

  + ], [

  + AC_MSG_RESULT(yes)

  + ], [

  + AC_MSG_RESULT(no)

  + X11_IMAKE_FLAGS="$X11_IMAKE_FLAGS -DNO_XIDPROC"

  + ])

  + 

  + HAVE_XMKMF=""

  + AC_PATH_PROG(HAVE_XMKMF, xmkmf, "", /usr/X11R6/bin /usr/X11R5/bin /usr/local/X11R6/bin /usr/local/X11R5/bin /usr/openwin/bin /usr/X11/bin /usr/X386/bin /usr/sww/bin /usr/unsupported/bin)

  + if test "X$HAVE_XMKMF" != "X"; then

  +     IMAKE_FLAGS=""

  +     if test -d ImakeCheck; then

  +         rm -rf ImakeCheck

  +     fi

  +     mkdir ImakeCheck

  +     cat << EOF > ImakeCheck/Imakefile

  + SRCS = dummy.c

  + OBJS = dummy.o

  + 

  + ComplexProgramTarget(dummy)

  + EOF

  +     cat << EOF > ImakeCheck/dummy.c

  + static int justAnInt = 0;

  + EOF

  +     (cd ./ImakeCheck; rm -f Makefile Makefile.*; eval $HAVE_XMKMF) > /dev/null 2>&1

  +     for i in `(cd ./ImakeCheck; make -n dummy.o)`

  +     do

  +         case $i in -D*) IMAKE_FLAGS="$IMAKE_FLAGS $i";; esac

  +     done

  +     if test "X$IMAKE_FLAGS" != "X"; then

  +         AC_MSG_RESULT(Add these flags for proper compile: $IMAKE_FLAGS)

  +         X11_IMAKE_FLAGS="$X11_IMAKE_FLAGS $IMAKE_FLAGS"

  +     fi

  +     rm -rf ImakeCheck

  + fi

  + 

  + # At last check FreeBSD and have -lxpg4.

  + AC_MSG_CHECKING([system version (for additional locale library)])

  + if test -f /usr/lib/NextStep/software_version; then

  +     system=NEXTSTEP-`awk '/3/,/3/' /usr/lib/NextStep/software_version`

  + else

  +     system=`uname -s`-`uname -r`

  +     if test "$?" -ne 0 ; then

  +         system=unknown

  +     else

  +         # Special check for weird MP-RAS system (uname returns weird

  +         # results, and the version is kept in special file).

  +     

  +         if test -r /etc/.relid -a "X`uname -n`" = "X`uname -s`" ; then

  +             system=MP-RAS-`awk '{print $3}' /etc/.relid'`

  +         fi

  +         if test "`uname -s`" = "AIX" ; then

  +             system=AIX-`uname -v`.`uname -r`

  +         fi

  +     fi

  + fi

  + 

  + case $system in

  +     FreeBSD-*)

  + LIBS="$XLIBSW -lxpg4 $tk_oldLibs"

  + CFLAGS="$CFLAGS $X11_IMAKE_FLAGS"

  + AC_TRY_COMPILE([

  + #include <locale.h>

  + ], [

  + (void)setlocale(LC_ALL, "");

  + ], [

  + AC_MSG_RESULT(use xpg4 library.)

  + XLIBSW="$XLIBSW -lxpg4"

  + ], [

  + AC_MSG_RESULT(no need other libraries.)

  + ])

  + ;;

  +     *)

  + AC_MSG_RESULT(No additional library is needed.)

  + ;;

  + esac

  + 

  + CFLAGS=$tk_oldCflags

  + LIBS=$tk_oldLibs

  + 

  + #--------------------------------------------------------------------

    # The statements below define various symbols relating to creating

    # the stub'd version of the Tk library

    #

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

  *** 453,457 ****

    AC_SUBST(XINCLUDES)

    AC_SUBST(XLIBSW)

    AC_SUBST(TK_SHARED_BUILD)

  ! 

    AC_OUTPUT(Makefile tkConfig.sh)

  --- 563,567 ----

    AC_SUBST(XINCLUDES)

    AC_SUBST(XLIBSW)

    AC_SUBST(TK_SHARED_BUILD)

  ! AC_SUBST(X11_IMAKE_FLAGS)

    AC_OUTPUT(Makefile tkConfig.sh)

  *** generic/tkEvent.c.origThu Dec 16 22:57:36 1999

  --- generic/tkEvent.cThu Feb 24 22:16:07 2000

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

  *** 663,668 ****

  --- 663,680 ----

        }


    #ifdef TK_USE_INPUT_METHODS

  + #ifdef I18N_IMPROVE

  +       /*

  +        * No need to create an input context for each and every window.

  +        *

  +        * Futhermore, XFilterEvent() should be called just after the

  +        * event is fetched, since some IM server have protocol bugs that

  +        * causes Tk freezing, so events EXCEPT THE INPUT METHODS THINGS

  +        * should only be queued into Tcl event queue.

  +        *

  +        *m-hirano

  +        */

  + #else

        /*

         * Pass the event to the input method(s), if there are any, and

         * discard the event if the input method(s) insist.  Create the

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

  *** 684,689 ****

  --- 696,702 ----

        goto done;

    }

        }

  + #endif /* I18N_IMPROVE */

    #endif /* TK_USE_INPUT_METHODS */


        /*

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

  *** 936,941 ****

  --- 949,965 ----

        break;

    }

        }

  + 

  + #if defined(TK_USE_INPUT_METHODS) && defined(I18N_IMPROVE)

  +     if (eventPtr->type == KeyPress && eventPtr->xkey.keycode == 0) {

  +         /*

  +          * No doubt this is a composed message from IM server.

  +          * Tk can handle KeyPress event with zero keycode value 

  +          * if state of the event is zero.

  +          */

  +         eventPtr->xkey.state = 0;

  +     }

  + #endif /* TK_USE_INPUT_METHODS && I18N_IMPROVE */


        if ((dispPtr->delayedMotionPtr != NULL) && (position == TCL_QUEUE_TAIL)) {

    if ((eventPtr->type == MotionNotify) && (eventPtr->xmotion.window

  *** generic/tkInt.h.origFri Jan 21 04:54:41 2000

  --- generic/tkInt.hThu Feb 24 22:14:07 2000

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

  *** 26,31 ****

  --- 26,34 ----

    #ifndef _TKPORT

    #include <tkPort.h>

    #endif

  + #ifdef I18N_IMPROVE

  + #include <X11/Xlocale.h>

  + #endif /* I18N_IMPROVE */


    /*

     * Opaque type declarations:

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

  *** 499,504 ****

  --- 502,522 ----

        int warpX;

        int warpY;

        int useInputMethods;/* Whether to use input methods */

  + #ifdef TK_USE_INPUT_METHODS

  + #ifdef I18N_IMPROVE

  +     Tcl_Encoding imEncoding;/* Tcl encoding when the first Tcl

  +  * interp was created.

  +  * For encoding conversion from

  +  * XmbLookupString() to UTF.

  +  */

  +     XIC lastFocusedIC;/* The last focused input context on

  +  * the display.

  +  */

  + #ifdef XNDestroyCallback

  +     XIMCallback destroyCallback;

  + #endif /* XNDestroyCallback */

  + #endif /* I18N_IMPROVE */

  + #endif /* TK_USE_INPUT_METHODS */

    } TkDisplay;


    /*

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

  *** 999,1007 ****

    EXTERN intTk_WmCmd _ANSI_ARGS_((ClientData clientData,

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


  - voidTkConsolePrint _ANSI_ARGS_((Tcl_Interp *interp,

  -     int devId, char *buffer, long size));

  - 

    EXTERN voidTkEventInit _ANSI_ARGS_((void));


    EXTERN intTkCreateMenuCmd _ANSI_ARGS_((Tcl_Interp *interp));

  --- 1017,1022 ----

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

  *** 1080,1085 ****

  --- 1095,1115 ----

     */

    EXTERN intTkUnsupported1Cmd _ANSI_ARGS_((ClientData clientData,

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

  + 

  + #if defined(TK_USE_INPUT_METHODS) && defined(I18N_IMPROVE)

  + EXTERN XICTkpCreateIC _ANSI_ARGS_((TkWindow *winPtr));

  + EXTERN voidTkpDestroyIC _ANSI_ARGS_((TkWindow *winPtr, int needDestroy));

  + EXTERN intTk_ImconfigureObjCmd _ANSI_ARGS_((ClientData clientData,

  +     Tcl_Interp *interp, int objc,

  +     Tcl_Obj *CONST objv[]));

  + #endif

  + 

  + # undef TCL_STORAGE_CLASS

  + # define TCL_STORAGE_CLASS

  + 

  + EXTERN intTkConsoleInit _ANSI_ARGS_((Tcl_Interp *interp));

  + EXTERN voidTkConsolePrint _ANSI_ARGS_((Tcl_Interp *interp,

  +     int devId, char *buffer, long size));


    # undef TCL_STORAGE_CLASS

    # define TCL_STORAGE_CLASS DLLIMPORT

  *** generic/tkWindow.c.origThu Dec 16 22:57:36 1999

  --- generic/tkWindow.cThu Feb 24 22:21:05 2000

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

  *** 155,160 ****

  --- 155,163 ----

    #ifdef MAC_TCL

        {"unsupported1",TkUnsupported1Cmd,NULL,1, 1},

    #endif

  + #if defined(TK_USE_INPUT_METHODS) && defined(I18N_IMPROVE)

  +     {"imconfigure",NULL,Tk_ImconfigureObjCmd,1, 1},

  + #endif /* TK_USE_INPUT_METHODS && I18N_IMPROVE */

        {(char *) NULL,(int (*) _ANSI_ARGS_((ClientData, Tcl_Interp *, int, char **))) NULL, NULL, 0}

    };


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

  *** 209,214 ****

  --- 212,226 ----

        char *name));

    static voidOpenIM _ANSI_ARGS_((TkDisplay *dispPtr));

    static voidUnlinkWindow _ANSI_ARGS_((TkWindow *winPtr));

  + #ifdef TK_USE_INPUT_METHODS

  + #ifdef I18N_IMPROVE

  + static intCanInitiateIm _ANSI_ARGS_((void));

  + static voidIMInstantiateCallback _ANSI_ARGS_ ((Display *display,

  + XPointer clientData, XPointer callData));

  + static voidIMDestroyCallback _ANSI_ARGS_ ((XIM im, XPointer clientData, 

  + XPointer callData));

  + #endif /* I18N_IMPROVE */

  + #endif /* TK_USE_INPUT_METHODS */

    

    /*

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

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

  *** 1275,1281 ****

        TkBindDeadWindow(winPtr);

    #ifdef TK_USE_INPUT_METHODS

        if (winPtr->inputContext != NULL) {

  ! XDestroyIC(winPtr->inputContext);

        }

    #endif /* TK_USE_INPUT_METHODS */

        if (winPtr->tagPtr != NULL) {

  --- 1287,1297 ----

        TkBindDeadWindow(winPtr);

    #ifdef TK_USE_INPUT_METHODS

        if (winPtr->inputContext != NULL) {

  ! #ifdef I18N_IMPROVE

  ! TkpDestroyIC(winPtr, 1);

  ! #else

  !   XDestroyIC(winPtr->inputContext);

  ! #endif /* I18N_IMPROVE */

        }

    #endif /* TK_USE_INPUT_METHODS */

        if (winPtr->tagPtr != NULL) {

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

  *** 2427,2432 ****

  --- 2443,2623 ----

    {

        return ((TkWindow *) tkwin)->mainPtr->strictMotif;

    }

  + #ifdef TK_USE_INPUT_METHODS

  + #ifdef I18N_IMPROVE

  + 

  + static int

  + CanInitiateIm()

  + {

  +     static int inited = 0;

  +     static int ret = 0;

  +     char *locale;

  + 

  +     /*

  +      * Determine the current encoding from the LC_* or LANG environment

  +      * variables.  We previously used setlocale() to determine the locale,

  +      * but this does not work on some systems (e.g. Linux/i386 RH 5.0).

  +      */

  + 

  +     locale = getenv("LC_ALL");

  + 

  +     if (locale == NULL || locale[0] == '\0') {

  + locale = getenv("LC_CTYPE");

  +     }

  +     if (locale == NULL || locale[0] == '\0') {

  + locale = getenv("LANG");

  +     }

  +     if (locale == NULL || locale[0] == '\0') {

  + return False;

  +     }

  + 

  +     if (inited == 0) {

  + char *curSpec = setlocale(LC_ALL, NULL);

  + 

  + inited = 1;

  + 

  + if (strcmp(locale, "C") == 0 ||

  +     strcmp(locale, "POSIX") == 0) {

  +     goto Checked;

  + }

  + 

  + /*

  +  * Ok I know, everyone of core Tcl/Tk developer hates this.

  +  * believe it or not, it must be needed to call

  +  * setlocale(3)/_Xsetlocale() VERY HERE. This is what the X

  +  * input method wants.

  +  * Note that X11's i18n implementation should be ONLY governed

  +  * by LC_CTYPE. This is clearly/explicitly specified in X11

  +  * documente Chapter 13. Thus, If there are some X11

  +  * implementation that need using LC_ALL to initialize i18n

  +  * subsystem, I won't care about such a X library.

  +  * But, we are still on edge of darkside. ctype(3) routines

  +  * are governed by LC_CTYPE.... Need to create "Locale

  +  * independent ctype libraries" for Tcl/Tk...

  +  *

  +  *m-hirano

  +  */

  + 

  + /*

  +  * OK, First of all, setting WHOLE locale to "C".

  +  */

  + (void)setlocale(LC_ALL, "C");

  + if (setlocale(LC_CTYPE, locale) == NULL) {

  +     /*

  +      * Reset to old locale.

  +      */

  +     if (setlocale(LC_ALL, curSpec) == NULL) {

  + (void)setlocale(LC_ALL, "C");

  +     }

  +     goto Checked;

  + } else {

  +     /*

  +      * For insurance, reset LC_NUMERIC to "C" for Tcl numeric parsing.

  +      */

  +     (void)setlocale(LC_NUMERIC, "C");

  + }

  + if (XSupportsLocale() != True) {

  +     goto Checked;

  + }

  + 

  + ret = True;

  + /*

  +  * At last, Setting the locale modifiers.

  +  */

  + (void)XSetLocaleModifiers("");

  +     }

  + 

  +     Checked:

  +     return ret;

  + }

  + 

  + /*

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

  +  *

  +  * IMInstantiateCallback

  +  *

  +  *Whenever IM server become available, this function will be called.

  +  *

  +  * Results:

  +  *OpenIM() is called.

  +  *

  +  * Side effects:

  +  *None.

  +  *

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

  +  */

  + 

  + void

  + IMInstantiateCallback(display, clientData, callData)

  +      Display *display;

  +      XPointer clientData;

  +      XPointer callData;

  + {

  +     TkDisplay *dispPtr = (TkDisplay *)clientData;

  + 

  +     if (display == dispPtr->display &&

  + dispPtr->inputMethod == NULL) {

  + OpenIM(dispPtr);

  +     }

  + }

  + 

  + /*

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

  +  *

  +  * IMDestroyCallback

  +  *

  +  *Whenever IM server stops the service, this function will be called.

  +  *

  +  * Results:

  +  *the XIM opened before is marked as unusable.

  +  *

  +  * Side effects:

  +  *XIC using this XIM will be useless.

  +  *

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

  +  */

  + void

  + IMDestroyCallback(im, clientData, callData)

  +      XIM im;

  +      XPointer clientData;

  +      XPointer callData;

  + {

  +     TkDisplay *dispPtr = (TkDisplay *)clientData;

  +     if (im == dispPtr->inputMethod) {

  + Tcl_HashTable winTable = dispPtr->winTable;

  + Tcl_HashEntry *entry = NULL;

  + Tcl_HashSearch search;

  + TkWindow *winPtr;

  + 

  + /*

  +  * We must not call XCloseIM() or XDestroyIC().

  +  * because the XIM and XIC are destroyed by Xlib 

  +  * automatically.

  +  */

  + for (entry = Tcl_FirstHashEntry(&winTable, &search); entry != NULL;

  +      entry = Tcl_NextHashEntry(&search)) {

  +     winPtr = (TkWindow *)Tcl_GetHashValue(entry);

  +     if (winPtr->dispPtr->display == dispPtr->display &&

  + winPtr->dispPtr->inputMethod == im &&

  + winPtr->inputContext != NULL) {

  + TkpDestroyIC(winPtr, 0);

  +     }

  + }

  + dispPtr->inputMethod = NULL;

  + dispPtr->lastFocusedIC = NULL;

  + #ifdef HAVE_XIMREGINSTCB

  + #ifdef NO_XIDPROC

  + XRegisterIMInstantiateCallback(dispPtr->display, NULL, NULL, NULL,

  +        (XIMProc)IMInstantiateCallback, (XPointer *)dispPtr);

  + #else

  + XRegisterIMInstantiateCallback(dispPtr->display, NULL, NULL, NULL,

  +        (XIDProc)IMInstantiateCallback, (XPointer)dispPtr);

  + #endif /* NO_XIDPROC */

  + #endif /* HAVE_XIMREGINSTCB */

  +     }

  + }

  + #endif /* I18N_IMPROVE */

  + #endif /* TK_USE_INPUT_METHODS */

    

    /* 

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

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

  *** 2457,2464 ****

  --- 2648,2681 ----

        unsigned short i;

        XIMStyles *stylePtr;


  + #ifdef I18N_IMPROVE

  +     int styleFound = 0;

  + 

  +     dispPtr->inputMethod = NULL;

  +     dispPtr->imEncoding = NULL;

  +     dispPtr->lastFocusedIC = NULL;

  + 

  +     if (CanInitiateIm() == False) {

  + return;

  +     }

  + #endif /* I18N_IMPROVE */

        dispPtr->inputMethod = XOpenIM(dispPtr->display, NULL, NULL, NULL);

        if (dispPtr->inputMethod == NULL) {

  + #ifdef I18N_IMPROVE

  + #ifdef HAVE_XIMREGINSTCB

  + /*

  +  * Maybe no IM server is available right now.

  +  * Try to register instantiate callback.

  +  */

  + #ifdef NO_XIDPROC

  + XRegisterIMInstantiateCallback(dispPtr->display, NULL, NULL, NULL,

  +        (XIMProc)IMInstantiateCallback, (XPointer *)dispPtr);

  + #else

  + XRegisterIMInstantiateCallback(dispPtr->display, NULL, NULL, NULL,

  +        (XIDProc)IMInstantiateCallback, (XPointer)dispPtr);

  + #endif /* NO_XIDPROC */

  + #endif /* HAVE_XIMREGINSTCB */

  + #endif /* I18N_IMPROVE */

    return;

        }


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

  *** 2469,2479 ****

        for (i = 0; i < stylePtr->count_styles; i++) {

    if (stylePtr->supported_styles[i]

    == (XIMPreeditNothing|XIMStatusNothing)) {

  !     XFree(stylePtr);

  !     return;

    }

        }

        XFree(stylePtr);


        error:


  --- 2686,2715 ----

        for (i = 0; i < stylePtr->count_styles; i++) {

    if (stylePtr->supported_styles[i]

    == (XIMPreeditNothing|XIMStatusNothing)) {

  ! #ifdef I18N_IMPROVE

  !     styleFound = 1;

  ! #else

  !       XFree(stylePtr);

  !       return;

  ! #endif /* I18N_IMPROVE */

    }

        }

        XFree(stylePtr);

  + #ifdef I18N_IMPROVE

  +     if (styleFound == 1) {

  + /*

  +  * Create a Tcl_Encoding for XmbLookupString() conversion.

  +  */

  + dispPtr->imEncoding = Tcl_GetEncoding(NULL, Tcl_GetEncodingName(NULL));

  + #ifdef XNDestroyCallback

  + dispPtr->destroyCallback.client_data = (XPointer)dispPtr;

  + dispPtr->destroyCallback.callback = (XIMProc)IMDestroyCallback;

  + (void)XSetIMValues(dispPtr->inputMethod,

  +    XNDestroyCallback, &(dispPtr->destroyCallback), NULL);

  + #endif /* XNDestroyCallback */

  + return;

  +     }

  + #endif /* I18N_IMPROVE */


        error:


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

  *** 2714,2719 ****

  --- 2950,2956 ----

        Tcl_DString class;

        ThreadSpecificData *tsdPtr;


  + 

        /*

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

         * really only an issue when Tk is loaded dynamically.

  *** unix/Makefile.in.origThu Feb 10 12:11:01 2000

  --- unix/Makefile.inThu Feb 24 22:25:33 2000

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

  *** 211,217 ****

    # modify any of this stuff by hand.

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


  ! AC_FLAGS =@EXTRA_CFLAGS@ @DEFS@

    RANLIB =@RANLIB@

    SRC_DIR =@srcdir@/..

    TOP_DIR =@srcdir@/..

  --- 211,218 ----

    # modify any of this stuff by hand.

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


  ! AC_FLAGS =@EXTRA_CFLAGS@ @DEFS@ @X11_IMAKE_FLAGS@ \

  ! -DI18N_IMPROVE @CPPFLAGS@

    RANLIB =@RANLIB@

    SRC_DIR =@srcdir@/..

    TOP_DIR =@srcdir@/..

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

  *** 268,274 ****

    tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o \

    tkUnixFocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o \

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

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


    STUB_LIB_OBJS = tkStubLib.o tkStubImg.o


  --- 269,276 ----

    tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o \

    tkUnixFocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o \

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

  ! tkUnixSend.o tkUnixWm.o tkUnixXId.o tkStubInit.o tkStubLib.o \

  ! tkUnixIm.o


    STUB_LIB_OBJS = tkStubLib.o tkStubImg.o


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

  *** 330,335 ****

  --- 332,338 ----

    $(UNIX_DIR)/tkUnixEmbed.c $(UNIX_DIR)/tkUnixEvent.c \

    $(UNIX_DIR)/tkUnixFocus.c \

    $(UNIX_DIR)/tkUnixFont.c $(UNIX_DIR)/tkUnixInit.c \

  + $(UNIX_DIR)/tkUnixIm.c \

    $(UNIX_DIR)/tkUnixKey.c \

    $(UNIX_DIR)/tkUnixMenu.c $(UNIX_DIR)/tkUnixMenubu.c \

    $(UNIX_DIR)/tkUnixScale.c $(UNIX_DIR)/tkUnixScrlbr.c \

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

  *** 843,848 ****

  --- 846,854 ----


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

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

  + 

  + tkUnixIm.o: $(UNIX_DIR)/tkUnixIm.c

  + $(CC) -c $(CC_SWITCHES) $(UNIX_DIR)/tkUnixIm.c


    tkUnixInit.o: $(UNIX_DIR)/tkUnixInit.c $(GENERIC_DIR)/tkInitScript.h tkConfig.sh

    $(CC) -c $(CC_SWITCHES) -DTK_LIBRARY=\"${TK_LIBRARY}\" \

  *** unix/tkConfig.sh.in.origThu Feb 10 12:11:02 2000

  --- unix/tkConfig.sh.inThu Feb 24 22:14:08 2000

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

  *** 20,26 ****

    TK_PATCH_LEVEL='@TK_PATCH_LEVEL@'


    # -D flags for use with the C compiler.

  ! TK_DEFS='@DEFS@'


    # Flag, 1: we built a shared lib, 0 we didn't

    TK_SHARED_BUILD=@TK_SHARED_BUILD@

  --- 20,26 ----

    TK_PATCH_LEVEL='@TK_PATCH_LEVEL@'


    # -D flags for use with the C compiler.

  ! TK_DEFS='@DEFS@ @X11_IMAKE_FLAGS@ -DI18N_IMPROVE'


    # Flag, 1: we built a shared lib, 0 we didn't

    TK_SHARED_BUILD=@TK_SHARED_BUILD@

  *** unix/tkUnixEvent.c.origFri Apr 16 03:51:46 1999

  --- unix/tkUnixEvent.cThu Feb 24 22:14:08 2000

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

  *** 161,167 ****

            (void) XSync(dispPtr->display, False);

            (void) XCloseDisplay(dispPtr->display);

        }

  !     

        ckfree((char *) dispPtr);

    }

    

  --- 161,172 ----

            (void) XSync(dispPtr->display, False);

            (void) XCloseDisplay(dispPtr->display);

        }

  ! #ifdef I18N_IMPROVE

  !     if (displayPtr->imEncoding != NULL) {

  ! Tcl_FreeEncoding(displayPtr->imEncoding);

  !     }

  ! #endif /* I18N_IMPROVE */    

  ! 

        ckfree((char *) dispPtr);

    }

    

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

  *** 246,251 ****

  --- 251,268 ----


        while (numFound > 0) {

    XNextEvent(display, &event);

  + #ifdef I18N_IMPROVE

  + /*

  +  * To avoid Tk freezing by IM server's protocol bugs,

  +  * Re-check queued event after an event is filterd.

  +  *

  +  *m-hirano

  +  */

  + if (XFilterEvent(&event, None) == True) {

  +     numFound = XEventsQueued(display, QueuedAlready);

  +     continue;

  + }

  + #endif /* I18N_IMPROVE */

    Tk_QueueWindowEvent(&event, TCL_QUEUE_TAIL);

    numFound--;

        }

  *** unix/tkUnixIm.c.origThu Feb 24 22:14:08 2000

  --- unix/tkUnixIm.cThu Feb 24 22:14:08 2000

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

  *** 0 ****

  --- 1,255 ----

  + /* 

  +  * tkUnixIm.c --

  +  *

  +  *      This file contains modules to implement the XIM protocol session.

  +  *This is the shrinked version of tkXIM.c, worte for tk8.0jp.

  +  *

  +  *Author:m-hirano@sra.co.jp

  +  *

  +  * Copyright 1999 Software Research Associates, Inc.

  +  *

  +  * Permission to use, copy, modify, and distribute this software and its

  +  * documentation for any purpose and without fee is hereby granted, provided

  +  * that the above copyright notice appear in all copies and that both that

  +  * copyright notice and this permission notice appear in supporting

  +  * documentation, and that the name of Software Research Associates not be

  +  * used in advertising or publicity pertaining to distribution of the

  +  * software without specific, written prior permission.  Software Research

  +  * Associates makes no representations about the suitability of this software

  +  * for any purpose.  It is provided "as is" without express or implied

  +  * warranty.

  +  */

  + 

  + #if 0

  + static char rcsid[] = "$Header: /home/m-hirano/cvsroot/tcltk/tk8.1/unix/tkUnixIm.c,v 1.1 1999/05/10 00:39:16 m-hirano Exp $";

  + #endif

  + 

  + #include "tkPort.h"

  + #include "tkInt.h"

  + 

  + #ifdef TK_USE_INPUT_METHODS

  + #ifdef I18N_IMPROVE

  + 

  + static voidTkpIMGenericHandler _ANSI_ARGS_((ClientData clientData, XEvent *eventPtr));

  + static TkWindow *GetToplevel _ANSI_ARGS_((TkWindow *winPtr));

  + static voidTkpCreateIMGenericHandler _ANSI_ARGS_((Tk_Window tkwin));

  + static voidTkpDeleteIMGenericHandler _ANSI_ARGS_((Tk_Window tkwin));

  + 

  + static TkWindow *

  + GetToplevel(winPtr)

  +      TkWindow *winPtr;

  + {

  +     while (!(winPtr->flags & TK_TOP_LEVEL)) {

  + winPtr = winPtr->parentPtr;

  + if (winPtr == NULL) {

  +     return NULL;

  + }

  +     }

  +     return winPtr;

  + }

  + 

  + 

  + static void

  + TkpIMGenericHandler(clientData, eventPtr)

  +      ClientData clientData;

  +      XEvent *eventPtr;

  + {

  +     Tk_Window tkwin = (Tk_Window)clientData;

  +     TkWindow *winPtr = (TkWindow *)clientData;

  +     

  +     if (eventPtr->xany.window != Tk_WindowId(tkwin) ||

  + winPtr->inputContext == NULL ||

  + !(winPtr->flags & TK_CHECKED_IC)) {

  + /*

  +  * Why ME ???

  +  */

  + return;

  +     }

  + 

  +     /*

  +      * Well, should I care about Enter/Leave ?

  +      */

  + 

  +     switch (eventPtr->type) {

  +         case KeyPress:

  +         case FocusIn: {

  +     Window root, child;

  +     int rootX, rootY;

  +     int wX, wY;

  +     unsigned int mask;

  + 

  +     /*

  +      * Care about case mouse pointer is not on winPtr->window.

  +      * In such a case, IM server can't fetch any events from Tk.

  +      */

  + 

  +     if (XQueryPointer(winPtr->display,

  +       RootWindow(winPtr->display, winPtr->screenNum),

  +       &root, &child, &rootX, &rootY, &wX, &wY, &mask) == True) {

  + TkWindow *pWin = (TkWindow *)Tk_CoordsToWindow(rootX, rootY,

  +        (Tk_Window)winPtr);

  + if (pWin != NULL && (pWin->window != winPtr->window)) {

  + #if 0

  +     /*

  +      * Code belows are what I REALLY want to do. But,

  +      * in XIMPreeditPosition mode, IM server use the

  +      * focus window as key event source window and as

  +      * PreeditArea window by X11 specification. I want

  +      * IM server to use this focus window ONLY as key

  +      * event source. Means:

  +      *

  +      * o PreeditArea and PreeditPosition take place

  +      *   within client window (winPtr->window).

  +      *o KeyPress event source is the window in which

  +      *  mouse pointer is (pWin->window).

  +      */

  + 

  +     if (XSetICValues(winPtr->inputContext, XNFocusWindow,

  +      pWin->window, NULL) != NULL) {

  + fprintf(stderr, "debugIC: can't set IC focus to pointer window 0x%08x\n",

  + pWin->window);

  +     } else {

  + fprintf(stderr, "debugIC: set IC focus to pointer window 0x%08x\n",

  + pWin->window);

  +     }

  + #endif

  +     /*

  +      * Check pWin and winPtr are in same toplevel.

  +      * If they are NOT, don't change focus. 

  +      */

  +     TkWindow *pTop = GetToplevel(pWin);

  +     TkWindow *wTop = GetToplevel(winPtr);

  +     if (pTop == wTop) {

  + TkpChangeFocus(winPtr, 1);

  +     }

  + }

  +     }

  +     /*

  +      * Get current focused window.

  +      */

  +     if (winPtr->dispPtr->lastFocusedIC != winPtr->inputContext) {

  + winPtr->dispPtr->lastFocusedIC = winPtr->inputContext;

  + XSetICFocus(winPtr->inputContext);

  +     }

  +     break;

  + }

  + 

  +         case FocusOut: {

  +     winPtr->dispPtr->lastFocusedIC = None;

  +     XUnsetICFocus(winPtr->inputContext);

  +     break;

  + }

  + 

  + case DestroyNotify: {

  +     winPtr->dispPtr->lastFocusedIC = NULL;

  +     XUnsetICFocus(winPtr->inputContext);

  +     TkpDeleteIMGenericHandler(tkwin);

  +     break;

  + }

  +     }

  + }

  + 

  + 

  + static void

  + TkpCreateIMGenericHandler(tkwin)

  +      Tk_Window tkwin;

  + {

  +     Tk_CreateEventHandler(tkwin, FocusChangeMask|StructureNotifyMask|KeyPressMask

  + #if 0

  +   EnterWindowMask|LeaveWindowMask,

  + #else

  +   ,

  + #endif

  +   (Tk_EventProc *)TkpIMGenericHandler,

  +   (ClientData)tkwin);

  + }

  + 

  + 

  + static void

  + TkpDeleteIMGenericHandler(tkwin)

  +      Tk_Window tkwin;

  + {

  +     Tk_DeleteEventHandler(tkwin, FocusChangeMask|StructureNotifyMask|KeyPressMask

  + #if 0

  +   EnterWindowMask|LeaveWindowMask,

  + #else

  +   ,

  + #endif

  +   (Tk_EventProc *)TkpIMGenericHandler,

  +   (ClientData)tkwin);

  + }

  + 

  + 

  + XIC

  + TkpCreateIC(winPtr)

  +      TkWindow *winPtr;

  + {

  +     if (winPtr->dispPtr->inputMethod != NULL &&

  + !(winPtr->flags & TK_CHECKED_IC)) {

  + winPtr->inputContext =

  + XCreateIC(winPtr->dispPtr->inputMethod,

  +   XNInputStyle, XIMPreeditNothing|XIMStatusNothing,

  +   XNClientWindow, winPtr->window,

  +   XNFocusWindow, winPtr->window,

  +   NULL);

  + if (winPtr->inputContext != NULL) {

  +     TkpCreateIMGenericHandler((Tk_Window)winPtr);

  + }

  +     }

  +     winPtr->flags |= TK_CHECKED_IC;

  +     return winPtr->inputContext;

  + }

  + 

  + 

  + void

  + TkpDestroyIC(winPtr, needDestroy)

  +      TkWindow *winPtr;

  +      int needDestroy;

  + {

  +     TkpDeleteIMGenericHandler((Tk_Window)winPtr);

  +     if (winPtr->inputContext == winPtr->dispPtr->lastFocusedIC) {

  + winPtr->dispPtr->lastFocusedIC = None;

  +     }

  +     if (needDestroy == 1 &&

  + winPtr->inputContext != NULL) {

  + XDestroyIC(winPtr->inputContext);

  +     }

  +     winPtr->flags &= ~(TK_CHECKED_IC);

  +     winPtr->inputContext = NULL;

  + }

  + 

  + 

  + int

  + Tk_ImconfigureObjCmd(clientData, interp, objc, objv)

  +      ClientData clientData;/* Main window associated with

  +  * interpreter. */

  +      Tcl_Interp *interp;/* Current interpreter. */

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

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

  + {

  +     Tk_Window tkwin = (Tk_Window)clientData;

  +     Tcl_Obj *resultPtr = Tcl_GetObjResult(interp);

  + 

  +     if (objc < 2) {

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

  + return TCL_ERROR;

  +     }

  + 

  +     tkwin = Tk_NameToWindow(interp, Tcl_GetStringFromObj(objv[1], NULL), tkwin);

  +     if (tkwin == NULL) {

  + return TCL_ERROR;

  +     }

  + 

  +     if (((TkWindow *)tkwin)->dispPtr->inputMethod == NULL) {

  + Tcl_AppendStringsToObj(resultPtr, "No IM server is available.", NULL);

  + return TCL_ERROR;

  +     }

  + 

  +     Tcl_AppendStringsToObj(resultPtr,

  +   (TkpCreateIC((TkWindow *)tkwin) != NULL) ? "1" : "0",

  +   NULL);

  +     return TCL_OK;

  + }

  + 

  + #endif /* I18N_IMPROVE */

  + #endif /* TK_USE_INPUT_METHODS */

  *** unix/tkUnixKey.c.origWed Feb  9 03:13:54 2000

  --- unix/tkUnixKey.cThu Feb 24 22:14:08 2000

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

  *** 89,95 ****

  --- 89,100 ----

    #endif /* TK_USE_INPUT_METHODS */

        Tcl_DStringSetLength(&buf, len);


  + #if defined(I18N_IMPROVE) && defined(TK_USE_INPUT_METHODS)

  +     Tcl_ExternalToUtfDString(winPtr->dispPtr->imEncoding,

  +      Tcl_DStringValue(&buf), len, dsPtr);

  + #else

        Tcl_ExternalToUtfDString(NULL, Tcl_DStringValue(&buf), len, dsPtr);

  + #endif /* I18N_IMPROVE && TK_USE_INPUT_METHODS */

        Tcl_DStringFree(&buf);


        return Tcl_DStringValue(dsPtr);

  *** library/entry.tcl.origThu Jan  6 03:22:24 2000

  --- library/entry.tclThu Feb 24 21:13:57 2000

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

  *** 214,219 ****

  --- 214,226 ----

        }

    }


  + # input method configuration binding (unix only)

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

  +     if {[string compare [info commands imconfigure] {}]} {

  + bind Entry <FocusIn> {catch {imconfigure %W}}

  +     }

  + }

  + 

    # Additional emacs-like bindings:


    bind Entry <Control-a> {

  *** library/text.tcl.origThu Feb 10 09:52:50 2000

  --- library/text.tclThu Feb 24 21:13:57 2000

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

  *** 378,383 ****

  --- 378,390 ----

        }

    }


  + # UNIX only bindings:

  + 

  + if {[string equal $tcl_platform(platform) "unix"] &&

  + [string compare [info commands imconfigure] {}]} {

  +     bind Text <FocusIn> {catch {imconfigure %W}}

  + }

  + 

    # Macintosh only bindings:


    # if text black & highlight black -> text white, other text the same


  PatchFiles:

  configure.in tkEvent.c tkInt.h tkWindow.c Makefile.in tkConfig.sh

      tkUnixEvent.c tkUnixIm.c (new file) tkUnixKey.c entry.tcl text.tcl


tkt_uuid: 220073ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Duplicate
title: Extending the current selection of a Text widget produces unexpected results
comment:
  OriginalBugID: 4375 RFE
  Version: 8.0p2
  SubmitDate: '2000-03-15'
  LastModified: '2000-04-16'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4253
  OS: Solaris
  OSVersion: Solaris 2.6
  Machine: SunOS 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-Enterprise
  ClosedDate: '2000-04-16'


  Name:
  Mark A. Wege

  ReproducibleScript:
  Execute the following code in an interactive session of wish, double-click in the middle of the word "selection", and then attempt
  to extend the selection by holding down the Shift key and pressing the Left arrow key.

  text .t
  pack .t
  .t insert end "Testing the selection of text"

  ObservedBehavior:
  When you double-click on the word "selection", the entire word is selected and the insert cursor moves to the beginning of the
  word.  When you extend the selection, however, all selected text in the word to the right of the initial insert point (where you
  double-clicked) is de-selected.

  A similar behavior occurs if you use the Right arrow key.

  DesiredBehavior:
  The text to the right of initial insert point should stay selected (as it does when you perform the same actions using an Entry
  widget).



  This has always been the behavior of the text widget selection
  routines.  I've changed this to an RFE, because the text widget
  should probably do more "intuitive" selection handling. 
  -- 03/23/2000 hobbs


tkt_uuid: 220074ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Duplicate
title: scale regression test fails
comment:
  OriginalBugID: 4397 Bug
  Version: 8.3
  SubmitDate: '2000-03-17'
  LastModified: '2000-03-23'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4433
  OS: HP-UX
  OSVersion: 11.00
  ClosedDate: '2000-03-23'


  Name:
  ed foltz

  ReproducibleScript:
  scale.test

  ==== scale-6.11 ComputeFormat procedure FAILED
  ==== Contents of test case:

      .s configure -from .0001 -to .001 -resolution .0001
      .s set .0006
      .s get

  ---- Result was:
  0.00060
  ---- Result should have been:
  0.0006
  ==== scale-6.11 FAILED


  ==== scale-6.12 ComputeFormat procedure FAILED
  ==== Contents of test case:

      .s configure -from .00001 -to .0001 -resolution .00001
      .s set .00006
      .s get

  ---- Result was:
  6e-05
  ---- Result should have been:
  0.00006
  ==== scale-6.12 FAILED


  ==== scale-6.14 ComputeFormat procedure FAILED
  ==== Contents of test case:

      .s configure -to .00001 -from .0001 -resolution .00001
      .s set .00006
      .s get

  ---- Result was:
  6e-05
  ---- Result should have been:
  0.00006
  ==== scale-6.14 FAILED

  DesiredBehavior:
  regression test should pass


tkt_uuid: 220075ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Duplicate
title: 1-dimension resizable toplevel shrinks in other dimension
comment:
  OriginalBugID: 4464 Bug
  Version: 8.3
  SubmitDate: '2000-03-22'
  LastModified: '2000-04-07'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4353
  OS: Macintosh
  OSVersion: MacOS S-9.0 (Swedish)
  Machine: G3/350 (B/W), iMac 233
  ClosedDate: '2000-04-07'


  Name:
  Johan Dahl

  ReproducibleScript:
  toplevel .w
  wm resizable .w 1 0

  ObservedBehavior:
  If I resize a toplevel window which is restricted in one dimension it shrinks one pixel in the other dimesion. This is related to the bug that causes a window to shrink one pixel in each dimension as soon as I click in the resize control

  DesiredBehavior:
  It should only resize in one dimension


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


  Name: Tommy B

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

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

  DesiredBehavior:
  A running Tk application ;)


tkt_uuid: 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


tkt_uuid: 220085ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Duplicate
title: Separator menu entries do not honor option database
comment:
  OriginalBugID: 5242 Bug
  Version: 8.3
  SubmitDate: '2000-04-24'
  LastModified: '2000-04-24'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 1166
  OS: All Windows
  ClosedDate: '2000-04-24'


  Name:
  Petasis Georgios

  ReproducibleScript:
  Just run the following script and open the "Test" menu:

  option add *Menu.Foreground       #000000
  option add *Menu.Background       #808080
  option add *Menu.activeForeground #BBBAED
  option add *Menu.activeBackground #666699
  option add *Menu.selectColor      #FFFF00

  menu .mb -type menubar
  .mb add cascade -label Test -menu .m
  . configure -menu .mb

  menu .m
  .m add command -label {This item is ok}
  .m add separator
  .m add command -label {Exit} -command {exit}
  wm geometry . 300x300

  ObservedBehavior:
  The separator does not have the same colors as the rest of the menu has.
  If you make the menu a window (by clicking the dashed menu item),
  the separator gets the corect color.



  This is a duplicate of Bug: 1166, which has already been fixed for 8.3.1.

  - eric 
  -- 04/24/2000 ericm


tkt_uuid: 220086ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Duplicate
title:
  various windows fonts (e.g., fixedsys, ms sans serif) don't display correctly in italic and bold forms

comment:
  OriginalBugID: 5305 Bug
  Version: 8.3
  SubmitDate: '2000-05-01'
  LastModified: '2000-05-10'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2583
  OS: Windows 95
  ClosedDate: '2000-05-10'


  Name:
  keith lea

  ReproducibleScript:
  set f [eval font create [font actual systemfixed] -weight bold -slant italic]
  pack [text .x -font $f -width 40 -height 7 -wrap word] -expand 1 -fill both

  .x insert end {Some random sample text.
  Here is more data
  some more data here: blaf blaasd asd asd asd asd asdasd asd.}

  set len [string length [.x get 1.0 end]]

  focus .x

  for {set i 0} {$i < $len} {incr i} {
      .x tag remove sel 1.0 end
      .x tag add sel "1.0 + $i char" "1.0 + [expr {$i + 5}] char"
      update
      after 100
  }

  ObservedBehavior:
  the textbox displays with large spaces on the borders of the selection


tkt_uuid: 220087ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Duplicate
title: Characters "ä", "ö", "ü" shown in wrong font
comment:
  OriginalBugID: 5469 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-12'
  LastModified: '2000-05-12'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2172
  OS: Windows NT
  OSVersion: MS Windows 98, NT 4.0 SP3
  Machine: Pentium II 400, Pentium II 333
  ClosedDate: '2000-05-12'


  Name:
  Stefan Koch

  Extensions:
  BWidget, Tk

  ReproducibleScript:
  Within the console window as well as in entry widgets the characters "ä", "ö", "ü" change the font type when using the font "Fixedsys 9"

  ObservedBehavior:
  Behaviour observed on NT and Windows 98



  The fix for this is listed in bug 2172, for which a different form
  will be incorporated into Tk8.4a1. 
  -- 05/12/2000 hobbs


tkt_uuid: 220088ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Duplicate
title: Main Window in Author doesn't raise when clicked
comment:
  OriginalBugID: 5482 RFE
  Version: 2.0b9
  SubmitDate: '2000-05-12'
  LastModified: '2000-05-27'
  Severity: MED
  Status: Closed
  Submitter: shawn
  ChangedBy: hobbs
  RelatedBugIDs: 4016
  OS: Windows NT
  ClosedDate: '2000-05-27'


  to reproduce - Hide the main author window partially with another connect window - 

  click on the window - and it doesn't raise - 

  I expect it to raise to the front of the other windows 



  Duplicate, this is a Tk problem. 
  -- 05/12/2000 redman
  This is just an incorrect assumption, if I understand the desc (which
  is just too short).  Connect makes toplevels transients of the main
  window, and transients always maintain stay-on-top behavior. 
  -- 05/12/2000 hobbs

  I guess that I don't agree that this is not a bug - if it's not a bug in tk (which I don't agree with either - really the stay on top behavior of transients should be optional), I still expect to raise the main window in Author to the front by clicking in the window - so that I can access the main controls in that window, even if it's obsured by another Author window.    
  -- 05/12/2000 shawn

  If I can expand on this a little - The behavior of a transient window is excellent in the case of a small error message serving a big window - in that case the transient behavior of popping up the error message serves us really well - it's easy to find the error window that way. Another model that works well is to use a toplevel without the transient behavior for the error message - then it can be found using the window manager in the OS - although the transient model is still much better. 

  This fails miserably however if you set a grab on the window - because if the window gets obscured by another application - suddenly - it is impossible to find the window and it can't be raised by clicking in the main application window - and the transient window can't be found using the window manager. It would be really nice if a single click in any of the application windows would raise the whole set of windows to the front - yet still require that the window with the grab get the attention.  

  The model I am thinking of is more like parents - where the three windows in the IDE toplevel share the same responsibility (they are like partners) for the children windows - and for each other.  Each one raises all the windows in the application - each one is fully functional, and can be raises itself  to the front - and we don't get the accumulation of icons that we would see in the .toplevel (without the transient behavior) model. Each of the three windows would behave the way a transient does now - without any window having to be "less" important by always having to stay behind. 

  This would be a good enhancement to the core, and would give the gui programmer more flexibility.  And it would make Ajuba easier to use.  

  -- 05/15/2000 shawn

  Finer grained control of toplevels is already specified by 4016.
  There should also be a Connect ticket opened linking to that. 
  -- 05/27/2000 hobbs


tkt_uuid: 220089ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Duplicate
title: Print facility for text widget
comment:
  OriginalBugID: 5616 RFE
  Version: 8.3
  SubmitDate: '2000-05-19'
  LastModified: '2000-05-22'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 1954
  OS: Linux-Red Hat
  OSVersion: 2.2.14
  Machine: AMDK6/2
  ClosedDate: '2000-05-22'


  Name:
  Simon Geard

  Extensions:
  BWidgets

  DesiredBehavior:
  It would be very nice to see a printing facility for the text widget by some means or other.  There is tkprint for windows but that's not really good enough - and doesn't cover Unix. A means of generating a Postscript file as you can do for the canvas widget would be wonderful.


tkt_uuid: 220090ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.4a1
resolution: Duplicate
title: Program coredumps with 8.1, 8.2, 8.3 and 8.4a1
comment:
  OriginalBugID: 5955 Bug
  Version: 8.4a1
  SubmitDate: '2000-06-27'
  LastModified: '2000-07-20'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 5960
  OS: Linux-Red Hat
  OSVersion: redhat 6.2
  Machine: i686
  FixedDate: '2000-07-20'


  Name:
  Lindsay Marshall

  Extensions:
  none

  ReproducibleScript:
  I am manipulating a canvas widget that is representing a tree on-screen. I have some window items that have an entry in them. When the user types the correct thing in the entry the entry is replaced with a text string, the window items
  are deleted and some subnodes are drawn. If you enter an incorrect value and then correct it, the failure does not happen. I am working on a cut down script, but the program though fairly small is realtively complex....

  ObservedBehavior:
  wish gives a segmentation fault.

  DesiredBehavior:
  No segmentation fault!


tkt_uuid: 220091ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Duplicate
title: TK 8.3.1 doesn't compile clean on AIX 4.3.2
comment:
  OriginalBugID: 5975 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-06'
  LastModified: '2000-09-05'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 6206
  OS: AIX
  FixedDate: '2000-09-05'


  Name:
  Joachim Zaers

  ReproducibleScript:
  using gcc-2.95-2, aix 4.3.2. BTW: Thanks for fixing AIX for tcl. There it worked fine.
  Looks like the changes in compile flags for gcc didn't make their way up from tcl to tk?

          rm -f libtk8.3.so
          /usr/local/LTA-DEV/src/tcl8.3.1/unix/ldAix /bin/ld -bhalt:4 -bM:SRE -bE:
  lib.exp -H512 -T512 -bnoentry -o libtk8.3.so tk3d.o tkArgv.o tkAtom.o tkBind.o t
  kBitmap.o tkClipboard.o tkCmds.o  tkColor.o tkConfig.o tkConsole.o tkCursor.o tk
  Error.o tkEvent.o  tkFocus.o tkFont.o tkGet.o tkGC.o tkGeometry.o tkGrab.o tkGri
  d.o  tkMain.o tkObj.o tkOldConfig.o tkOption.o tkPack.o tkPlace.o  tkSelect.o tk
  Util.o tkVisual.o tkWindow.o   tkUnix.o tkUnix3d.o tkUnixButton.o tkUnixColor.o
  tkUnixConfig.o  tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o  tkUnixF
  ocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o  tkUnixMenubu.o tkUnix
  Scale.o tkUnixScrlbr.o tkUnixSelect.o  tkUnixSend.o tkUnixWm.o tkUnixXId.o tkStu
  bInit.o tkStubLib.o tkButton.o tkEntry.o tkFrame.o tkListbox.o  tkMenu.o tkMenub
  utton.o tkMenuDraw.o tkMessage.o tkScale.o  tkScrollbar.o tkCanvas.o tkCanvArc.o
   tkCanvBmap.o tkCanvImg.o  tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o  tk
  CanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o tkImgGIF.o t
  kImgPPM.o tkImgPhoto.o tkText.o tkTextBTree.o tkTextDisp.o tkTextImage.o tkTextI
  ndex.o  tkTextMark.o tkTextTag.o tkTextWind.o -L/usr/local/lib -L/usr/local/LTA-
  DEV/src/tcl8.3.1/unix  -lX11 -ldl -Wl,-bI:/usr/local/LTA-DEV/src/tcl8.3.1/unix/l
  ib.exp -L/usr/local/LTA-DEV/src/tcl8.3.1/unix -lm -lc
  noDotA="libtk8.3.so"
  ld: 0706-012 The -W flag is not recognized.
  ld: 0706-006 Cannot find or open library file: -l ,-bI:/usr/local/LTA-DEV/src/tc
  l8.3.1/unix/lib.exp
          ld:open(): A file or directory in the path name does not exist.
  make: 1254-004 The error code from the last command is 255.


tkt_uuid: 220092ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.4a1
resolution: Duplicate
title: menu items with indicators and AVWXYZ drawn incorrectly
comment:
  OriginalBugID: 6177 Bug
  Version: 8.4a1
  SubmitDate: '2000-08-29'
  LastModified: '2000-08-29'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 6134
  OS: Windows NT
  OSVersion: 4.0sp6
  FixedDate: '2000-08-29'


  Name:
  Vincent Darley

  ReproducibleScript:
  wish
  % tk_optionMenu .b var A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
  .b.menu
  % pack .b

  ObservedBehavior:
  Now select any of A V W X Y Z to see the problem: the leftmost
  pixels of the character are not drawn properly, some pixels are missing.



  This is a duplicate of [Bug: 6134].  I have applied the patch from that bug report, which corrected the problem.  The fix will be included with Tk 8.4a2.  Thanks for your report,

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

  -- 08/29/2000 ericm


tkt_uuid: 220093ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.3.2
resolution: Duplicate
title: Disabled text widget selection inconsistency among Windows and Linux.
comment:
  OriginalBugID: 6249 Bug
  Version: 8.3.2
  SubmitDate: '2000-09-11'
  LastModified: '2000-09-11'
  Severity: LOW
  Status: Closed
  Submitter: sandeep
  ChangedBy: ericm
  RelatedBugIDs: 4329 5933
  OS: All
  FixedDate: '2000-09-11'


  Steps to Reproduce:
  1. Run the following script

  text .t
  .t insert end foo
  .t configure -state disabled
  pack .t

  2. Try to select "foo".

  Expected Result:
  Either both platforms should allow the selection, or both should not.

  Actual Result:
  In Linux (KDE & remotely via Exceed) you can select the text.  In Windows you can't.

  ACK! It's worse than that.  If you change the state of the widget to normal, do a selection, click somewhere to get rid of the selection, change the state back to disabled, it allows you to select from that point forward.  So -state disabled doesn't guarantee the disability to select.



  The behavior of the text widget on Windows is based on behaviors observed in Windows applications.  It is true that those behaviors are based on old applications, and should be updated to conform to the new standards.  However, it is an incorrect assumption that a text widget (or any widget) should have the same behavior on all platforms.  All platforms are not created equal.

  In any case, a complete solution to this problem, I believe, requires the introduction of a new state for text widgets: readonly, similar to the readonly state found in entry widgets in 8.4.  The whole problem now stems from the fact that the readonly and truly disabled states of a text widget are intermingled, and should not be.

  This is related to bugs 5933 and 4329.

  - eric

  -- 09/11/2000 ericm


tkt_uuid: 220094ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Duplicate
title: scale widget callback is invoked when it shouldn't be
comment:
  OriginalBugID: 6339 Bug
  Version: 8.3.1
  SubmitDate: '2000-10-03'
  LastModified: '2000-10-18'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 3908
  OS: Linux-Red Hat
  OSVersion: 6.0
  Machine: Dell Precision 410
  FixedDate: '2000-10-18'


  Name:

  Jonas Beskow


  Comments:

  This bug is compiler-related (I'm using gcc version egcs-2.91.66) 

      Basically what happens is that a check for identity between two doubles

      (in TkScaleSetValue()) is not robust to compiler optimization.  The

      result is that the scale callback sometimes is invoked even when the

      value hasn't changed. Since TkScaleSetValue() is called from

      ConfigureScale(), the scale callback is invoked each time the widget is

      configured.


      This patch makes the double comparison robust by comparing the absolute

      value of the difference between the values with half the resolution.


  ReproducibleScript:

  proc scalecallback {args} {puts [info level 0]}

  pack [scale .s -resolution .1 -from 0 -to 1 -command scalecallback]

  .s set .5


  # move the mouse pointer into and out of the scale area of the widget (the "handle") - this

  # triggers a configure command that internally has the effect of setting the scale to the current value,

  # which in turn triggers the sacle callback (see comment below)


  ObservedBehavior:

  The scale callback is invoked whenever the pointer enters or leaves the scale area of the widget (the "handle")


  DesiredBehavior:

  The scale callback should only be invoked when the scale value has changed


  Patch:

  *** tkScale.c.old       Tue Oct  3 13:13:07 2000

  --- tkScale.c.new       Tue Oct  3 13:13:15 2000

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

  *** 1297,1303 ****

        }

        if (scalePtr->flags & NEVER_SET) {

          scalePtr->flags &= ~NEVER_SET;

  !     } else if (scalePtr->value == value) {

          return;

        }

        scalePtr->value = value;

  --- 1297,1303 ----

        }

        if (scalePtr->flags & NEVER_SET) {

          scalePtr->flags &= ~NEVER_SET;

  !     } else if (fabs(scalePtr->value - value) < 0.5*scalePtr->resolution) {

          return;

        }

        scalePtr->value = value;


  PatchFiles:

  tkScale.c




  This is indeed a compiler bug, as described in Ticket #3908.

  Thanks for submitting the patch; however, I don't think it's best to make this change to work around the buggy compiler.  This will ultimately penalize (a little bit anyway) every platform for the sake of working around one broken compiler.  Better to upgrade your compiler (egcs 2.95 or higher should do), or your Linux distro (newer versions of Redhat have a newer version of egcs).

  Thanks for sending in the bug report and patch nonetheless.

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

  -- 10/18/2000 ericm


tkt_uuid: 220095ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: prowish80 window labeled prowish80.bin
comment:
  OriginalBugID: 423 Bug
  Version: 1.0b8
  SubmitDate: '1998-08-24'
  LastModified: '1999-12-14'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  RelatedBugIDs: 1013
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-12-14'


  when I run prowish80, I get a main window labeled "prowish80.bin".

  This is because it's derived from the appname, no other
  title was specified.  Was there another desired behavior? 
  -- 12/14/1999 hobbs


tkt_uuid: 220097ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 1 Zero
foundin: obsolete: 8.0
resolution: Invalid
title: Scrollbar display -- jitters
comment:
  OriginalBugID: 543 Bug
  Version: 8.0
  SubmitDate: '1998-03-12'
  LastModified: '1999-11-17'
  Severity: CRIT
  Status: Closed
  Submitter: rjohnson
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-11-17'


  The scrollbar appears to jitter under some window configuations.  Specifically when the scollbar is placed is a space that is small (like 15 or 16 pixels).



  Not reproducible with 8.2.1 build for PPC Mac. 
  -- 11/17/1999 hobbs


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: 220099ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Widgets
priority: 1 Zero
foundin: None
resolution: Invalid
title: balloon help widget
comment:
  OriginalBugID: 549 RFE
  Version: 8.1a2
  SubmitDate: '1998-03-18'
  LastModified: '1999-08-14'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  RelatedBugIDs: 2212
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-14'


  I was just thinking the other day that it would be nice if Tcl/Tk had a
  better API for balloon help since it is such an industry accepted paradigm.
  My thought was to make a -balloon method for all the objects in the Tk
  model.  In addition to the balloon method, we could set a Tk variable like
  tk_balloon to true for balloon help to be turned on, and false for off.
  The following demonstrates the concept:

  # Turn on balloon help for the application
  set tk_balloon 1

  # Create a button with balloon help
  button .b -Text "Exit" -balloon "Click to exit the application" -command
  exit

  Perhaps tcl8.1 can implement a standard look and feel for balloon help and
  make it part of the core using the above concept.  This would make all tcl
  apps have the same popup for ballon help and make it easier for app
  developers to implement balloon help on/off.

  Wes Bailey
  tkWorld Project Leader
  http://www.phys.ksu.edu/~bailey/tkWorld.html

  After some consideration, it was determined that balloon help is
  probably better done without requiring a -balloon option, so that
  widget extensions that don't support can tie into a more general
  Tcl based system.  Several good ones already exist.  We may consider
  including one as a contributed package. 
  -- 08/14/1999 hobbs


tkt_uuid: 220100ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1a2
resolution: Invalid
title: dde problem
comment:
  OriginalBugID: 557 Bug
  Version: 8.1a2
  SubmitDate: '1998-03-31'
  LastModified: '1999-03-31'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: redman
  OS: Windows 95
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-03-31'


  From: Gang Wang <wanggang@computermotion.com>
  Newsgroups: comp.lang.tcl
  Subject: dde problem
  Date: Wed, 25 Mar 1998 14:28:17 -0800
  Organization: Silicon Beach - Business Internet Services
  Lines: 11
  Message-ID: <35198501.2B33@computermotion.com>
  Reply-To: wanggang@computermotion.com
  NNTP-Posting-Host: host116.computermotion.com
  Mime-Version: 1.0
  Content-Type: text/plain; charset=us-ascii
  Content-Transfer-Encoding: 7bit
  X-Mailer: Mozilla 3.0Gold (Win95; I)
  Xref: nntp2.ba.best.com comp.lang.tcl:69969


  I tried the new dde command in Tk8.1 on window95. 
  It did not work as it was claimed. 
  I issued : 
  %dde execute -async Winword Documnet1 "Hello World"
  Then the word window blinks and dde command in wish console did not
  return. Unless I bring word window to the top ( activate it ), it keeps
  hanging on there. 


  Any idea to fix this ?


  Gang

  03/31/1999 15:48 - redman - No hang, but Winword blinks (correct behavior actually).


tkt_uuid: 220101ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1a2
resolution: Invalid
title: file cmd fails in threaded apps
comment:
  OriginalBugID: 562 Bug
  Version: 8.1a2
  SubmitDate: '1998-04-15'
  LastModified: '1999-04-05'
  Severity: MED
  Status: Closed
  Submitter: hershey
  ChangedBy: redman
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-05'


  Subject:      Tcl 8.1 Thread-safety issue:  "file" commands are
  broken.
  From:         ranga@cs.umd.edu (M.Ranganathan)
  Date:         1998/04/10
  Message-ID:   <6glmc1$6kv@zagnut.cs.umd.edu>
  Newsgroups:   comp.lang.tcl

  There is a small bug with the Makefile for the unix tcl 8.1.a2
  distribution.

  The Makefile for UNIX should include -D_REENTRANT -- otherwise
  various "file" commands do not work when a multi-threaded
  extension is built. The error is caused by the errno global
  variable
  which the TclMakeDir subroutine looks at. While using pthreads,
  errno
  is a macro. The macro does not kick in unless -D_REENTRANT is
  defined.
  I suspect other things like this would also break.

  The problem can be easily fixed by adding -D_REENTRANT to CFLAGS.

  Ranga.



  We need to get the OS version.
  Some platfroms have system headers that are altered by the REENTRANT flag.  We need to  determine if this is what is happening.  03/26/1999 11:09 - surles -
  03/27/1999 15:50 - redman - The configure script already checks for it and adds it when it should.  This appears to have been fixed already.


tkt_uuid: 220102ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 1 Zero
foundin: obsolete: 8.0
resolution: Invalid
title: off by one error in canvas item boundaries
comment:
  OriginalBugID: 567 Bug
  Version: 8.0
  SubmitDate: '1998-04-15'
  LastModified: '2000-04-03'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: ericm
  RelatedBugIDs: 3354 2251
  OS: All
  FixedInVersion: NA
  ClosedDate: '2000-04-03'


  From: "Munagala V. S. Ramanath" <ram@netcom.com>

  At line 1759 of tkCanvas.c (tk8.0) you have this loop:

        for (itemPtr = canvasPtr->firstItemPtr; itemPtr != NULL;
                itemPtr = itemPtr->nextPtr) {
            if ((itemPtr->x1 >= screenX2)
                    || (itemPtr->y1 >= screenY2)
                    || (itemPtr->x2 < screenX1)
                    || (itemPtr->y2 < screenY1)) {
                if (!itemPtr->typePtr->alwaysRedraw
                        || (itemPtr->x1 >= canvasPtr->redrawX2)
                        || (itemPtr->y1 >= canvasPtr->redrawY2)
                        || (itemPtr->x2 < canvasPtr->redrawX1)
                        || (itemPtr->y2 < canvasPtr->redrawY1)) {
                    continue;
                }
            }
            (*itemPtr->typePtr->displayProc)((Tk_Canvas) canvasPtr, itemPtr,
                    canvasPtr->display, pixmap, screenX1, screenY1, width,
                    height);
        }

  It appears that all 4 strict inequalities (<) above should instead
  be plain inequality (<=) since your invariant for bboxes is that
  x1/y1 are _included_ but x2/y2 are _excluded_. I was getting
  unnecessary calls to my canvas item displayProc when the item
  abutted but did not overlap the region to be refreshed and traced 
  it down to this code.

  The code shown appears correct with respect to the invarient for bbox:  the object is refreshed if

  screenX1 <= objectX < screenX2 &&
  screenY1 <= objectY < screenY2 &&
  redrawX1 <= objectX < redrawX1 &&
  redrawY1 <= objectY < redrawY2 &&
  !alwaysRedraw

  That is, if the object is in the bounding area defined by the coordinates, including the coordinates on the top and left (x1 and y1) and up to but not including the coordinates on the right and bottom (x2 and y2).

  - eric

  -- 04/03/2000 ericm


tkt_uuid: 220103ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: buttons are invoked by pressing return
comment:
  OriginalBugID: 585 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1999-08-09'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-09'


  On Windows, it's normal to invoke a button by pressing return.  The

  appended patch adds Tk bindings to make this happen by default.  This

  patch is due to Tom Tromey <tromey@cygnus.com>.



  Ian Taylor

  ian@cygnus.com



  *** /5g/ian/tk8.0p2/library/button.tcl  Mon Nov 25 11:42:30 1996

  --- button.tcl  Tue Apr 14 15:16:24 1998

  *************** if {$tcl_platform(platform) == "macintos

  *** 38,43 ****

  --- 38,52 ----

        }

    }

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

  +     bind Button <Return> {

  +       tkButtonInvoke %W

  +     }

  +     bind Checkbutton <Return> {

  +       tkCheckRadioInvoke %W

  +     }

  +     bind Radiobutton <Return> {

  +       tkCheckRadioInvoke %W

  +     }

        bind Checkbutton <equal> {

          tkCheckRadioInvoke %W select

        }





  This patch is incorrect.  The expected behavior on Windows is that <Return> should invoke the *default* button, not the button that currently has focus.  This is a subtle, but very important difference.  There is no default binding for this behavior because it depends on things like tab order and multiple button groupings.  The correct behavior is that within a given panel, exactly one button will have the "-default active" attribute.  This button is drawn in a different style and is the one that should be invoked if <Return> is pressed when focus is anywhere in the panel.  The binding typically has to be attached to the panel rather than the button to get the correct behavior.

  -- 08/09/1999 stanton


tkt_uuid: 220104ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: WM_SYSCOMMAND is not the same as WM_COMMAND
comment:
  OriginalBugID: 597 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-04'
  Severity: SER
  Status: Closed
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1998-08-04'


  The menu handling code in Tk8.0p2 on Windows handles the WM_SYSCOMMAND

  message as though it were the WM_COMMAND message.  That makes no

  sense.  Take a look at the documentation.



  In fact, I don't think the Tk menu handling needs to worry about

  WM_SYSCOMMAND at all.  WM_SYSCOMMAND is used for the system menu which

  appears on every window, and Tk is better off not dealing with that.



  In practice the code will normally just pass a WM_SYSCOMMAND message

  to DefWindowProc, because of how the Tk code happens to be written.

  However, the code is still wrong.



  Tk8.1a2 has the same problem.



  I've appended the trivial patch.



  Ian Taylor

  ian@cygnus.com



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

  --- tkWinMenu.c Wed Apr 15 14:41:13 1998

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

  *** 893,899 ****

              }

              break;

    

  -       case WM_SYSCOMMAND:

          case WM_COMMAND: {

              TkMenuInit();

              if (HIWORD(*pwParam) == 0) {

  --- 893,898 ----





  The Tk menu handling does need to handle WM_SYSCOMMAND because it is possible to append items to the system menu.  The wParam should contain the menu entry ID of the corresponding entry, if Tk has added anything to the system menu, otherwise it will simply invoke the default behavior.

  This is not a bug.


tkt_uuid: 220105ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: invoke/postcascade fails for UNIX menubar
comment:
  OriginalBugID: 617 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1999-09-13'
  Severity: MED
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  OS: All Unix
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-09-13'


  I'm running tk8.0 under Solaris2.5.  I recently switched to using
  the
  menubar for various commands, but now my keybindings which
  short-cut
  the menubar don't work anymore (UNIX only -- WIN32 is OK).  Here's
  the
  minimal code which fails:

  . configure -menu .m
  menu .m
  .m add cascade -label foo -menu .m.c
  menu .m.c
  .m.c add command -label bar -command {puts test} -under 0
  .m type 1 => cascade
  text .t
  pack .t
  bind .t <Alt-q> {.m postcascade 1}

  Under WIN32, I can now type Alt-q and the sub-menu posts, then I
  type
  'b' and 'test' is printed.

  Under UNIX, if I use <Meta-q> and type it, nothing happens.

  Workarounds, anyone?

  ht

  NB.  This appears to have been introduced in one of the patches,
  as my
  FreeBSD machine also handles this OK:  it's got menu.tcl 1.100 of
  97/08/26,
  while my Solaris machine is on 1.103 of 97/10/31.

  ht
  --
    Henry S. Thompson, HCRC Language Technology Group, University of
  Edinburgh
       2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131
  650-4440
              Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/


  This code does not seem to be valid for either Unix or Windows. 
  -- 09/13/1999 hobbs


tkt_uuid: 220106ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: bug in return value of "image cget"
comment:
  OriginalBugID: 626 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1999-08-13'
  Severity: MED
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-13'


  Hi! Is it possible, that there is a bug with [image cget]?
  It always returns zero, image configure bla  does also give a list of
  mostly empty data. Is this known? It appears with tk80p2. 


  This is likely confusion over the behavior of the image command.
  Once an image command is create (with image create ...), the
  command will return mostly empty data through config and cget.
  There are no defaults essentially, and it all depends on what
  the user sets for the values specifically.  This does work as
  expected. 
  -- 08/13/1999 hobbs


tkt_uuid: 220107ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: winfo children problem
comment:
  OriginalBugID: 629 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-06'


  I've been using Tcl/Tk 8.0p2 on Win95 and NT and have a question about
  the winfo children command in Tk. The help documentation says it returns
  a list of all the children of window and the list is in stacking order
  with the lowest window first. What it does return is the same list
  independent of stacking order. 
  Here's a brief example of what I mean.

  I make two windows 
          toplevel .a
          toplevel .b
  independent of stacking order, when I execute 
          winfo children .
  I get
  .a .b
  I tried it with frame with similar results. So the question is, am I
  misapplying this command, is it a bug or ?
  Does anyone know how I can find the path of the topmost window. Your
  help is greatly appreciated,

  Thanks,
  Bob Alkire <alkire@interval.com>

  This works as expected, with the difference that it works as you
  would have expected for frames, and toplevels ignore "stacking
  order" in this sense.  You can [raise] a toplevel, but it is
  really the children of toplevels, and their children, etc, that
  have a "stacking order" in this sense. 
  -- 08/06/1999 hobbs


tkt_uuid: 220108ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: bug in wm callbacks?
comment:
  OriginalBugID: 643 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1999-08-15'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-15'


  I noticed the following behavior in tcl8.0p2.
  When binding to Destroy  or using
  wm protocol WM_DELETE_WINDOW,
  in the callback, [winfo viewable $window] == 1,
  even though [winfo exists $win] == 0. This would
  be meaningful if one were saving the geometry of
  the window and wanted to test for its presence before
  saving.

  A workaround is to
  catch "wm geometry $win" var, but I didn't think it logical
  that the window could not exist, yet still be viewable.

  From: Robert Karen <robert@namsi.com>

  This is the desired behavior.  There was previously a bug where
  the winfo exists would actually return 1, which could really
  cause confusion and problems.  What is occuring is that the window
  is in the middle of being destroyed.  Since total destruction is
  imminent, exists is made to return 0.  However, the window is
  still (for the moment) physically viewable.

  If you throw some after calls in there, you will see that the
  window is still viewable, but interacting with it is not fully
  enabled because it is in the destruction process. 
  -- 08/15/1999 hobbs


tkt_uuid: 220109ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0
resolution: Invalid
title: loadable shared libraries
comment:
  OriginalBugID: 645 Bug
  Version: 8.0
  SubmitDate: '1998-05-25'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  OS: IRIX
  OSVersion: 6.2
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-06'


  Brent,

  I am trying to get the load random.so example on page 523 to 525
  of the second edition of your book to work. The make file
  makes a random.so file using code from example 41-1, 41-2,
  and 41-3.  The interaction with the machine looks like this,

  bangkok{lreder}349: make random
          CC -g -I/home/lreder/src/tcltk/tcl8.0/include -c random.c
          CC -g -I/home/lreder/src/tcltk/tcl8.0/include -c RandomCmd.c
          CC -g -I/home/lreder/src/tcltk/tcl8.0/include -c RandomObjCmd.c
          CC -o random.so -shared random.o RandomCmd.o RandomObjCmd.o
  -L/home/lreder/src/tcltk/tcl8.0/lib -ltcl8.0 -lm
  bangkok{lreder}350: wish8.0
  % pwd
  /home/lreder/src/animplayer/tktest
  % pkg_mkIndex /home/lreder/src/animplayer/tktest *.so
  error while loading or sourcing random.so: couldn't find procedure
  Random_Init

  I am running on Irix 6.2 and using tcl/tk 8.0.

  Also if I do,

  % load /home/lreder/src/animplayer/tktest/random.so
  couldn't find procedure Random_Init

  I know the Random_Init routine is in the random.so library.

  Can you tell me how to make this work?  I have a current
  application which is compiled into a wish shell.  What I
  want to do is make it a shared library so that I can just
  use the load command to include it into my tcl/tk scripts.
  This feature does not seem to work.

  A quick reply would be very much appreciated.

  Len

  P.S. Also in example 41-9 the variable object is not defined.
       Also in example 41-6 the Tcl_DecrRefCount call is not needed.
       The routine works without it but not with it. 


  This appears to be a random programming error (not extern'ed
  func or something). 
  -- 08/06/1999 hobbs


tkt_uuid: 220110ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: many tests fail on IRIX 6.5 in Tk 8.0p2
comment:
  OriginalBugID: 659 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '2000-04-03'
  Severity: MED
  Status: Closed
  Submitter: hershey
  ChangedBy: ericm
  RelatedBugIDs: 1770
  OS: IRIX
  OSVersion: 6.5
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '2000-04-03'


  When testing Tk8.0p2, some of the tests fail (see attached file).
  I am unable to figure out why.
  Are these known failures (to be fixed), something new
  nobody has seen before or have I done simply something
  wrong?
  For the record: IRIX 6.5, CFLAGS="-n32 -mips3", SGI Octane

  Zdenek Sekera          email: zs@cray.com
  ----
          LD_LIBRARY_PATH=`pwd`:/usr/people/zs/src/tcl8.0/unix:;  export LD_LIBRARY_PATH;  TCL_LIBRARY=/usr/people/zs/src/tcl8.0/library; export TCL_LIBRARY;  TK_LIBRARY=./../library; export TK_LIBRARY;  ( echo cd ./../tests\; source all\; exit )  | ./tktest -geometry +0+0
  bell.test
  (will skip non-portable tests)
  Bell should ring now ...
  bgerror.test
  bind.test
  button.test
  canvImg.test
  canvPs.test
  canvRect.test
  canvText.test

  ==== canvText-6.1 ComputeTextBbox procedure
  ==== Contents of test case:

      .c itemconfig test -font $font -text 0
      .c coords test 0 0
      set x {}
      lappend x [.c itemconfig test -anchor n; .c bbox test]
      lappend x [.c itemconfig test -anchor nw; .c bbox test]
      lappend x [.c itemconfig test -anchor w; .c bbox test]
      lappend x [.c itemconfig test -anchor sw; .c bbox test]
      lappend x [.c itemconfig test -anchor s; .c bbox test]
      lappend x [.c itemconfig test -anchor se; .c bbox test]
      lappend x [.c itemconfig test -anchor e; .c bbox test]
      lappend x [.c itemconfig test -anchor ne; .c bbox test]
      lappend x [.c itemconfig test -anchor center; .c bbox test]

  ==== Result was:
  {-8 0 8 31} {-1 0 15 31} {-1 -15 15 16} {-1 -31 15 0} {-8 -31 8 0} {-15 -31 1 0} {-15 -15 1 16} {-15 0 1 31} {-8 -15 8 16}
  ---- Result should have been:
  {-8 0 8 31} {-1 0 15 31} {-1 -16 15 15} {-1 -31 15 0} {-8 -31 8 0} {-15 -31 1 0} {-15 -16 1 15} {-15 0 1 31} {-8 -16 8 15}
  ---- canvText-6.1 FAILED
  canvWind.test
  canvas.test
  clipboard.test
  clrpick.test
  cmds.test
  color.test
  entry.test
  event.test
  filebox.test
  focus.test

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

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

  ==== Test generated error:
  X server insecure (must use xauth-style authorization); command ignored
  focusTcl.test
  font.test
  frame.test
  geometry.test
  grid.test
  id.test
  image.test
  imgBmap.test
  imgPPM.test
  imgPhoto.test
  listbox.test
  macEmbed.test
  macFont.test
  macMenu.test
  macWinMenu.test
  macscrollbar.test
  main.test
  menu.test
  menuDraw.test
  menubut.test
  msgbox.test
  oldpack.test
  option.test
  pack.test
  place.test
  raise.test
  safe.test
  scale.test

  ==== scale-7.1 ComputeScaleGeometry procedure
  ==== Contents of test case:

      catch {destroy .s}
      scale .s -from 0 -to 10 -label "Short" -orient vertical -length 5i
      pack .s
      update
      list [winfo reqwidth .s] [winfo reqheight .s]

  ==== Result was:
  88 472
  ---- Result should have been:
  88 458
  ---- scale-7.1 FAILED

  ==== scale-7.5 ComputeScaleGeometry procedure
  ==== Contents of test case:

      catch {destroy .s}
      scale .s -from 0 -to 10 -label "Short" -orient horizontal -length 5i
      pack .s
      update
      list [winfo reqwidth .s] [winfo reqheight .s]

  ==== Result was:
  472 61
  ---- Result should have been:
  458 61
  ---- scale-7.5 FAILED
  scrollbar.test
  select.test

  ==== select-10.4 ConvertSelection procedure
  ==== Contents of test case:

      setup
      setupbg
      set selValue $longValue
      set selInfo ""
      selection handle .f1 {errIncrHandler STRING}
      set result ""
      set pass 0
      lappend result [dobg {selection get}]
      cleanupbg
      lappend result $selInfo

  ==== Result was:
  {selection owner didn't respond} {STRING 0 4000 STRING 4000 4000 STRING 8000 4000 STRING 12000 4000 STRING 16000 4000 STRING 0 4000}
  ---- Result should have been:
  {selection owner didn't respond} {STRING 0 4000 STRING 4000 4000 STRING 8000 4000 STRING 12000 4000 STRING 16000 4000 STRING 0 4000 STRING 4000 4000}
  ---- select-10.4 FAILED
  send.test
  Your X server is insecure, so "send" can't be used; skipping "send" tests.
  text.test
  textBTree.test
  textDisp.test
  textImage.test
  textIndex.test

  ==== textIndex-5.1 TkTextGetIndex, "@"
  ==== Contents of test case:

      .t index @12,9

  ==== Result was:
  1.0
  ---- Result should have been:
  1.1
  ---- textIndex-5.1 FAILED
  textMark.test
  textTag.test
  textWind.test
  tk.test
  unixButton.test
  unixEmbed.test

  ==== unixEmbed-3.1 ContainerEventProc procedure, detect creation
  ==== Contents of test case:

      foreach w [winfo child .] {
          catch {destroy $w}
      }
      frame .f1 -container 1 -width 200 -height 50
      pack .f1
      dobg "set w1 [winfo id .f1]"
      set x [testembed]
      dobg {
          eval destroy [winfo child .]
          toplevel .t1 -use $w1
          wm withdraw .t1
      }
      list $x [testembed]

  ==== Result was:
  {{XXX .f1 {} {}}} {{XXX .f1 {} {}}}
  ---- Result should have been:
  {{XXX .f1 {} {}}} {{XXX .f1 XXX {}}}
  ---- unixEmbed-3.1 FAILED
  unixFont.test

  ==== unixfont-1.2 TkpGetNativeFont procedure: native
  ==== Contents of test case:

      font measure fixed 0

  ==== Result was:
  12
  ---- Result should have been:
  6
  ---- unixfont-1.2 FAILED

  ==== unixfont-5.9 Tk_MeasureChars procedure: TK_PARTIAL_OK
  ==== Contents of test case:

      .b.c dchars $t 0 end
      .b.c insert $t 0 "0000"
      .b.c index $t @[expr int($ax*2.5)],1

  ==== Result was:
  4
  ---- Result should have been:
  2
  ---- unixfont-5.9 FAILED

  ==== unixfont-8.3 AllocFont procedure: can't parse info from name
  ==== Contents of test case:

      if [catch {set a [font actual a12biluc]}]==0 {
          string compare $a "-family a12biluc -size 0 -weight normal -slant roman -underline 0 -overstrike 0"
      } else {
          set a 0
      }

  ==== Result was:
  1
  ---- Result should have been:
  0
  ---- unixfont-8.3 FAILED

  ==== unixfont-9.1 GetControlCharSubst procedure: 2 chars subst
  ==== Contents of test case:

      .b.c dchars $t 0 end
      .b.c insert $t 0 "0\a0"
      set x {}
      lappend x [.b.c index $t @[expr $ax*0],0]
      lappend x [.b.c index $t @[expr $ax*1],0]
      lappend x [.b.c index $t @[expr $ax*2],0]
      lappend x [.b.c index $t @[expr $ax*3],0]

  ==== Result was:
  0 1 3 3
  ---- Result should have been:
  0 1 1 2
  ---- unixfont-9.1 FAILED

  ==== unixfont-9.2 GetControlCharSubst procedure: 4 chars subst
  ==== Contents of test case:

      .b.c dchars $t 0 end
      .b.c insert $t 0 "0\1770"
      set x {}
      lappend x [.b.c index $t @[expr $ax*0],0]
      lappend x [.b.c index $t @[expr $ax*1],0]
      lappend x [.b.c index $t @[expr $ax*2],0]
      lappend x [.b.c index $t @[expr $ax*3],0]
      lappend x [.b.c index $t @[expr $ax*4],0]
      lappend x [.b.c index $t @[expr $ax*5],0]

  ==== Result was:
  0 1 1 3 3 3
  ---- Result should have been:
  0 1 1 1 1 2
  ---- unixfont-9.2 FAILED
  unixMenu.test
  unixWm.test

  ==== unixWm-41.2 ConfigureEvent procedure, menubars
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 300 -height 200 -bd 2 -relief raised
      wm geom .t +0+0
      update
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      frame .t.m -bd 2 -relief raised -height 20
      testmenubar window .t .t.m
      update
      set result {}
      bind .t <Configure> {
          if {"%W" == ".t"} {
              lappend result "%W: %wx%h"
          }
      }
      bind .t.m <Configure> {lappend result "%W: %wx%h"}
      wm geometry .t 200x300
      update
      lappend result [expr [winfo rootx .t.m] - $x]  [expr [winfo rooty .t.m] - $y]  [winfo width .t.m] [winfo height .t.m]  [expr [winfo rootx .t] - $x] [expr [winfo rooty .t] - $y]  [winfo width .t] [winfo height .t]

  ==== Result was:
  {.t.m: 200x20} {.t: 200x300} -8 -32 200 20 -8 -12 200 300
  ---- Result should have been:
  {.t.m: 200x20} {.t: 200x300} 0 0 200 20 0 20 200 300
  ---- unixWm-41.2 FAILED

  ==== unixWm-47.1 WaitRestrictProc procedure
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 300 -height 200
      frame .t.f -bd 2 -relief raised
      place .t.f -x 20 -y 30 -width 100 -height 20
      wm geometry .t +0+0
      tkwait visibility .t
      set result {}
      bind .t.f <Configure> {lappend result {configure on .t.f}}
      bind .t <Map> {lappend result {map on .t}}
      bind .t <Unmap> {lappend result {unmap on .t}; bind .t <Unmap> {}}
      bind .t <Button> {lappend result {button %b on .t}}
      event generate .t.f <Configure> -when tail
      event generate .t <Configure> -when tail
      event generate .t <Button> -button 3 -when tail
      event generate .t <Map> -when tail
      lappend result iconify
      wm iconify .t
      lappend result done
      update
      set result

  ==== Result was:
  iconify {unmap on .t} done {button 3 on .t} {map on .t}
  ---- Result should have been:
  iconify {unmap on .t} done {configure on .t.f} {button 3 on .t} {map on .t}
  ---- unixWm-47.1 FAILED

  ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a toplevel, x-coords
  ==== Contents of test case:

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

  ==== Result was:
  {} {} .t {} {} {} {} .t
  ---- Result should have been:
  {} {} .t {} .t2 .t2 {} .t
  ---- unixWm-50.1 FAILED
  util.test
  visual.test
  winButton.test
  winClipboard.test
  winFont.test
  winMenu.test
  winWm.test
  window.test
  winfo.test



  canvTest-6.1 is marked nonPortable in Tk8.1

  focus-5.1 gets skipped if X server is insecure in Tk8.1

  scale-* may be fixed in Tk8.1.  This may depend on the window manager.  It was reported that the previous (fixed in Tk8.1) behavior of some pack tests cause some window managers to later fail in scale tests.

  testIndex-5.1, unixEmbed-3.1, and unixWm-4* are marked nonPortable in Tk8.1

  select-10.4 and unixWm-50.1:  I can't reproduce these failure, and I'm reluctant to mark it nonPortable.  Let's see about this one in Tk8.1+ if it's still a problem.

  --

  These appear to perform much better in recent builds.  When this bug was submitted many of the tests that failed were not marked as non portable, even though they were (depending on such iffy bits as the number of pixels corresponding to one inch on the physical display).

  If you continue to see failures with the new version of Tcl/Tk, please send us an update.

  - eric

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


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

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

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

  DesiredBehavior:
  same as without swedish characters

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


tkt_uuid: 220114ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Window raise problem on NT
comment:
  OriginalBugID: 792 Bug
  Version: 8.0.4
  SubmitDate: '1998-11-04'
  LastModified: '1999-03-01'
  Severity: MED
  Status: Closed
  Submitter: welch
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-03-01'


  Seems I ran into a bug, err, an issue on Windows NT.

  To test this, run this code on NT:



  wm title . "NT Problem with raise"

  button .quit -command exit -text "Quit"

  pack .quit



  set state 0

  after 1000 toggle



  proc toggle {} {

      global state



      if { $state } {

  raise .

      } else {

  lower .

      }



      set state [ expr ! $state ]

      after 1000 toggle

  }



  Now move make sure the winodw is covered by some other window

  when it's lowered. Works beautifully, doesn't it? Now click

  on the titlebar of the raising/lowering window and the one

  that covers it. You should see that the window stops raising.

  (I tried NT with SP1 and with SP3.)



  Here is a patch that circumvents this behaviour by first

  making the window a topmost (like the taskmanager) and then

  cancelling that, which puts the window above all non-topmost

  windows.



  *** tkWinWindow.c.origThu Aug  6 03:20:06 1998

  --- tkWinWindow.cFri Oct 30 15:48:20 1998

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

  *** 767,777 ****

        siblingHwnd = temp;

    }

        } else {

  ! siblingHwnd = (pos == Above) ? HWND_TOP : HWND_BOTTOM;

        }

    

        SetWindowPos(hwnd, siblingHwnd, 0, 0, 0, 0,

        SWP_NOACTIVATE | SWP_NOMOVE | SWP_NOSIZE);

    }

    

    /*

  --- 767,782 ----

        siblingHwnd = temp;

    }

        } else {

  ! siblingHwnd = (pos == Above) ? HWND_TOPMOST : HWND_BOTTOM;

        }

    

        SetWindowPos(hwnd, siblingHwnd, 0, 0, 0, 0,

        SWP_NOACTIVATE | SWP_NOMOVE | SWP_NOSIZE);

  +     if (siblingHwnd == HWND_TOPMOST) {

  +       /* We do not really want a topmost. Move it down a little. */

  +       SetWindowPos(hwnd, HWND_NOTOPMOST, 0, 0, 0, 0,

  +  SWP_NOACTIVATE | SWP_NOMOVE | SWP_NOSIZE);

  +     }

    }

    

    /*



  03/01/1999 10:39 - stanton - This is the expected behavior.  Raise will raise windows within an application's window heirarchy.  If that application is active, then it will raise the window above all other windows.  If it is not active then Windows will not raise a window above the active application's windows.  The best way to achieve the user's desired behavior is to say:

  focus -force .
  raise .

  This ensures that . is both the active window and at the top of the stacking order.


tkt_uuid: 220115ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: need command for text & canvas tags that don't apply to any items
comment:
  OriginalBugID: 876 RFE
  Version: 8.0.3
  SubmitDate: '1998-11-25'
  LastModified: '2000-02-25'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: All
  ClosedDate: '2000-02-25'


  From: John Ousterhout <ouster@scriptics.com>
  Subject: RFE: need more introspection in Tcl and Tk

  This is another problem pointed out by Kevin Kenny in his Tcl/Tk
  Conference paper.

  Tcl and Tk are missing several pieces of introspection that are
  meeting to find memory leaks.  Right now there are no Tcl commands
  that can be invoked to find out about the following things:

  - text and canvas tags that don't apply to any items in the widget

  The "text tag names" returns all tags, and then "text tag ranges <name>"
  will return empty if no items have the tag.  On the canvas, this is
  moot because they are UIDs which can't be deallocated and have no other
  info associated with them (unlike text tags). 
  -- 02/25/2000 hobbs


tkt_uuid: 220116ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 1 Zero
foundin: obsolete: 8.1a2
resolution: Invalid
title: safeTk does not clean up the safe::tkInit array when the interpreter is deleted
comment:
  OriginalBugID: 938 Bug
  Version: 8.1a2
  SubmitDate: '1998-12-07'
  LastModified: '2000-04-03'
  Severity: SER
  Status: Closed
  Submitter: stanton
  ChangedBy: ericm
  RelatedBugIDs: 1523
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '2000-04-03'


  The safe::tkInit array may contain stale information because it is not cleared when an interpreter is deleted.  This may lead to the arguments for one safeTk instance being installed into another instance.



  This looks like it was fixed along with Bug 1523.

  - eric
   
  -- 04/03/2000 ericm


tkt_uuid: 220117ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 31. Cursor Names
priority: 1 Zero
foundin: None
resolution: Invalid
title: A window's -cursor command doesn't report valid options
comment:
  OriginalBugID: 945 Bug
  Version: 8.0.4
  SubmitDate: '1998-12-14'
  LastModified: '1999-09-15'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  ClosedDate: '1999-09-15'


  Name:
  Larry W. Virden

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  . configure -cursor something



  ObservedBehavior:
  bad cursor spec "something"



  DesiredBehavior:
  bad cursor spec "something": must be "arrow",
  "gumby", "right hand", ...

  where the list is the list appropriate
  for the platform.





  Anytime an argument or command requires a fixed value, and an incorrect value is provided, the list of correct values should be reported to the user.
  --
  The list of possible cursors is *very* long, plus there are the
  other variants of how to write a cursor.  One should read the docs
  to properly take care of this.  The error message is clear enough
  about where they are doing something wrong. 
  -- 09/15/1999 hobbs


tkt_uuid: 220118ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: Grid "-sticky" option seems to misbehave
comment:
  OriginalBugID: 946 Bug
  Version: 8.0p2
  SubmitDate: '1998-12-14'
  LastModified: '2000-01-18'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  OS: Linux
  Machine: Other
  ClosedDate: '2000-01-18'


  Name:
  David Skoll

  Extensions:
  Linux daw1 2.0.36 #1 Fri Nov 20 13:25:52 EST 1998 i586

  CustomShell:
  Stock Tcl/Tk -- no patches.

  ReproducibleScript:
  set n 0

  proc packit { how } {
      global n
      incr n
      set w .test$n
      toplevel $w
      wm title $w "Test: $how"

      frame $w.short -relief sunken -border 2
      frame $w.long -relief sunken -border 2
      grid $w.short -sticky ew
      grid $w.long -sticky ew

      label $w.longlab -text "This is a rather long label"
      grid $w.longlab -in $w.long -sticky ew

      label $w.how -text "short"
      if {$how == "grid"} {
  grid $w.how -in $w.short -sticky w
      } else {
  pack $w.how -in $w.short -expand 0 -fill none -anchor w
      }
  }

  wm withdraw .
  packit pack
  packit grid

  ObservedBehavior:
  When I run the script above, I expect the two top-level windows "pack" and "grid" to look identical.  Instead, the "grid" version centers the "short" label rather than left-justifying it.

  DesiredBehavior:
  I expect to see "short" left-justified in both windows.



  This is actually how the grid geometry manager is defined to behave.  The misunderstanding stems from confusing the parent widget with the slave cavity.

  When using grid, a cavity space is set up for each widget.  If no non-zero weights are specified for the columns and rows of the parent widget, the cavity will be "shrink-wrapped" around the slave widget.  The slave widget is actually sticky within its cavity, but because the cavity is exactly big enough to contain the widget, it doesn't look like it.  And the grid manager is defined to center layouts within the parent, if no weights are set.  So the widget appears centered in the parent, but really the cavity is centered, and the widget is sticky.

  If you alter the size of the cavity by setting its column width to a non-zero value (like 1), you will see the widget move to the spot you originally expected.

  - eric

  -- 01/18/2000 ericm


tkt_uuid: 220119ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: error handling is not turned on when invoking a proc from a menu (on windows95)
comment:
  OriginalBugID: 953 Bug
  Version: 8.0p2
  SubmitDate: '1998-12-14'
  LastModified: '2000-04-03'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  OS: Windows 95
  OSVersion: alpha
  Machine: X86
  ClosedDate: '2000-04-03'


  Name:
  michal holenderski

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  # here is short script which will show
  # my problem. i am using windows95 (on
  # unix this bug doesn't exist). when 
  # you envoke a procedure from a menu,
  # the error handling is not turned on.
  # i get no error messages. but if i 
  # envoke the same procedure using a # button, the exception handler is 
  # turned on. 
  # this script creates a simple form
  # with a menu and a button. to both
  # a not existing procedure (Quit) is
  # attached. when you press the button
  # an error message apears, when you
  # chose the menu, nothing happens.

  # create the menue
    set m  .menu 
    menu $m 

    set file $m.file
    menu $file -tearoff 0
    $m add cascade -label File -menu $file
    $file add command -label "Quit" -command "Quit"

    . configure -menu  .menu

    pack [button .quit -text "Quit" -command "Quit"]



  ObservedBehavior:
  # here is short script which will show
  # my problem. i am using windows95 (on
  # unix this bug doesn't exist). when 
  # you envoke a procedure from a menu,
  # the error handling is not turned on.
  # i get no error messages. but if i 
  # envoke the same procedure using a # button, the exception handler is 
  # turned on. 
  # this script creates a simple form
  # with a menu and a button. to both
  # a not existing procedure (Quit) is
  # attached. when you press the button
  # an error message apears, when you
  # chose the menu, nothing happens.




  DesiredBehavior:
  the menu schould behave like the button.




  This works on 8.3.0 with NT.

  - eric
   
  -- 04/03/2000 ericm


tkt_uuid: 220120ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Invalid
title: Menus do not work with double-byte characters
comment:
  OriginalBugID: 1009 Bug
  Version: 8.1b1
  SubmitDate: '1998-12-22'
  LastModified: '1999-03-25'
  Severity: SER
  Status: Closed
  Submitter: welch
  ChangedBy: surles
  RelatedBugIDs: 1060
  OS: Windows NT
  OSVersion: 4.0J
  Machine: X86
  ClosedDate: '1999-03-25'


  Name:

  Syd Polk


  CVS:

  12/19/1998 11:00 PST


  ReproducibleScript:

  On a Japanese Windows system, create a menu with Japanese text. Note that the normal convention is "XXXX(N)", where XXXX is Japanese, N is the N character, and N is underlined. The characters will be displayed incorrectly, and the N character will not work as a shortcut.


  ObservedBehavior:

  Bad display. Broken command keys.


  DesiredBehavior:

  Good display. Command keys working.


  Patch:

  Index: tkWinMenu.c

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

  RCS file: /cvsroot/tk/win/tkWinMenu.c,v

  retrieving revision 1.1.4.8

  diff -c -r1.1.4.8 tkWinMenu.c

  *** tkWinMenu.c1998/12/13 09:54:451.1.4.8

  --- tkWinMenu.c1998/12/18 20:12:58

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

  *** 462,467 ****

  --- 462,469 ----

    : Tcl_GetStringFromObj(mePtr->labelPtr, NULL);

    char *accel = (mePtr->accelPtr == NULL) ? "" 

    : Tcl_GetStringFromObj(mePtr->accelPtr, NULL);

  + int utfSize = Tcl_NumUtfChars(label, mePtr->labelLength);

  + int charSize;

    char *p, *next;

    Tcl_DString itemString;


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

  *** 474,499 ****


    Tcl_DStringInit(&itemString);


  ! for (p = label, i = 0; *p != '\0'; i++, p = next) {

        if (i == mePtr->underline) {

    Tcl_DStringAppend(&itemString, "&", 1);

        }

  !     if (*p == '&') {

    Tcl_DStringAppend(&itemString, "&", 1);

        }

  !     next = Tcl_UtfNext(p);

  !     Tcl_DStringAppend(&itemString, p, next - p);

    }

  !         if (mePtr->accelLength > 0) {

        Tcl_DStringAppend(&itemString, "\t", 1);

  !     for (p = accel, i = 0; *p != '\0'; i++, p = next) {

  ! if (*p == '&') {

        Tcl_DStringAppend(&itemString, "&", 1);

    }

  ! next = Tcl_UtfNext(p);

  ! Tcl_DStringAppend(&itemString, p, next - p);

        }

  ! }     


    itemText = ckalloc(Tcl_DStringLength(&itemString) + 1);

    strcpy(itemText, Tcl_DStringValue(&itemString));

  --- 476,509 ----


    Tcl_DStringInit(&itemString);


  ! 

  ! for (i = 0, p = label; i < utfSize; i++) {

        if (i == mePtr->underline) {

    Tcl_DStringAppend(&itemString, "&", 1);

        }

  !     next = Tcl_UtfNext(p);

  !     charSize = next - p;

  !     if ((charSize == 1) && (*p == '&')) {

    Tcl_DStringAppend(&itemString, "&", 1);

        }

  !     Tcl_DStringAppend(&itemString, p, charSize);

  !     p = next;

    }

  ! if (mePtr->accelLength > 0) {

        Tcl_DStringAppend(&itemString, "\t", 1);

  ! 

  !     utfSize = Tcl_NumUtfChars(accel, mePtr->accelLength);

  ! 

  !     for (i = 0, p = accel; i < utfSize; i++) {

  ! next = Tcl_UtfNext(p);

  ! charSize = next - p;

  ! if ((charSize == 1) && (*p == '&')) {

        Tcl_DStringAppend(&itemString, "&", 1);

    }

  ! Tcl_DStringAppend(&itemString, p, charSize);

  ! p = next;

        }

  ! }    


    itemText = ckalloc(Tcl_DStringLength(&itemString) + 1);

    strcpy(itemText, Tcl_DStringValue(&itemString));

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

  *** 995,1001 ****


    case WM_MENUCHAR: {

  !     unsigned char menuChar = (unsigned char) LOWORD(*pwParam);

        hashEntryPtr = Tcl_FindHashEntry(&tsdPtr->winMenuTable, 

                        (char *) *plParam);

        if (hashEntryPtr != NULL) {

  --- 1005,1011 ----


    case WM_MENUCHAR: {

  !     TCHAR menuChar = (TCHAR) LOWORD(*pwParam);

        hashEntryPtr = Tcl_FindHashEntry(&tsdPtr->winMenuTable, 

                        (char *) *plParam);

        if (hashEntryPtr != NULL) {

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

  *** 1005,1011 ****

    menuPtr = (TkMenu *) Tcl_GetHashValue(hashEntryPtr);

    for (i = 0; i < menuPtr->numEntries; i++) {

        int underline;

  !     char *label;


        underline = menuPtr->entries[i]->underline;

        if (menuPtr->entries[i]->labelPtr != NULL) {

  --- 1015,1023 ----

    menuPtr = (TkMenu *) Tcl_GetHashValue(hashEntryPtr);

    for (i = 0; i < menuPtr->numEntries; i++) {

        int underline;

  !     char *label, *underlineStr;

  !     Tcl_DString underlineDString;

  !     


        underline = menuPtr->entries[i]->underline;

        if (menuPtr->entries[i]->labelPtr != NULL) {

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

  *** 1013,1025 ****

    menuPtr->entries[i]->labelPtr, NULL);

        }

        if ((-1 != underline) 

  !     && (NULL != menuPtr->entries[i]->labelPtr)

  !     && (CharUpper((LPTSTR) menuChar) 

  !     == CharUpper((LPTSTR) (unsigned char) 

  !     label[underline]))) {

  ! *plResult = (2 << 16) | i;

  ! returnResult = 1;

  ! break;

        }

    }

        }

  --- 1025,1044 ----

    menuPtr->entries[i]->labelPtr, NULL);

        }

        if ((-1 != underline) 

  !     && (NULL != menuPtr->entries[i]->labelPtr)) {

  ! label = (unsigned char *) Tcl_UtfAtIndex(label, underline);

  ! Tcl_UtfToExternalDString(NULL, label, 1, &underlineDString);

  ! CharUpper((LPTSTR) &menuChar);

  ! underlineStr = Tcl_DStringValue(&underlineDString);

  ! CharUpper((LPTSTR) underlineStr);

  ! 

  ! if (menuChar == *underlineStr) {

  !     *plResult = (2 << 16) | i;

  !     returnResult = 1;

  !     Tcl_DStringFree(&underlineDString);

  !     break;

  ! }

  ! Tcl_DStringFree(&underlineDString);

        }

    }

        }


  PatchFiles:

  win/tkWinMenu.c




  Duplicate to bug ID 1060


tkt_uuid: 220121ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Invalid
title: Tk_UnderlineTextLayout breaks with double-byte chars.
comment:
  OriginalBugID: 1022 Bug
  Version: 8.1b1
  SubmitDate: '1998-12-30'
  LastModified: '1999-03-25'
  Severity: MED
  Status: Closed
  Submitter: welch
  ChangedBy: surles
  RelatedBugIDs: 1053
  OS: Windows NT
  OSVersion: 4.0J
  Machine: X86
  ClosedDate: '1999-03-25'


  Name:

  Syd Polk


  CVS:

  generic/tkFont.c 1.1.4.5


  ReproducibleScript:

  Actually, this one is hard to see. I did it with the tabbed-notebook widget from Tix running on Japanese NT 4.0.


  ObservedBehavior:

  Basically, if you have some string like XXXX(E), and set the underline to 5, and the XXXX characters are double-byte, the underline appears in the wrong place.


  DesiredBehavior:

  I expect the E to be underlined when displayed.


  Patch:

  Index: tkFont.c

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

  RCS file: /cvsroot/tk/generic/tkFont.c,v

  retrieving revision 1.1.4.5

  diff -c -r1.1.4.5 tkFont.c

  *** tkFont.c1998/11/25 23:06:421.1.4.5

  --- tkFont.c1998/12/31 01:38:19

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

  *** 2191,2203 ****

        int underline;/* Index of the single character to

     * underline, or -1 for no underline. */

    {

  !     TextLayout *layoutPtr;

        TkFont *fontPtr;

  !     int xx, yy, width, height;


  !     if ((Tk_CharBbox(layout, underline, &xx, &yy, &width, &height) != 0)

        && (width != 0)) {

  - layoutPtr = (TextLayout *) layout;

    fontPtr = (TkFont *) layoutPtr->tkfont;


    XFillRectangle(display, drawable, gc, x + xx, 

  --- 2191,2204 ----

        int underline;/* Index of the single character to

     * underline, or -1 for no underline. */

    {

  !     TextLayout *layoutPtr = (TextLayout *) layout;

        TkFont *fontPtr;

  !     int xx, yy, width, height, underlineByte;


  !     underlineByte = Tcl_UtfAtIndex(layoutPtr->string, underline) 

  !     - layoutPtr->string;

  !     if ((Tk_CharBbox(layout, underlineByte, &xx, &yy, &width, &height) != 0)

        && (width != 0)) {

    fontPtr = (TkFont *) layoutPtr->tkfont;


    XFillRectangle(display, drawable, gc, x + xx, 


  PatchFiles:

  generic/tkFont.c




  This looks like the last remaining call in Tk to Tk_CharBBox that things were not right with.
  ----
  This patch is bad and has been replaced by bug ID 1053


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


  Name:
  Ulrich Lauther

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


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


tkt_uuid: 220123ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Invalid
title: Tk file dialogue boxes crash with permission errors
comment:
  OriginalBugID: 1161 Bug
  Version: 8.0.4
  SubmitDate: '1999-02-02'
  LastModified: '1999-11-12'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux
  OSVersion: 2.034
  Machine: Other
  ClosedDate: '1999-11-12'


  Name: Lindsay Marshall

  ReproducibleScript:
  The internals of the file dialog code use a proc called 
  tkFDialogResolveFile. Use a file dialog inside a directory where you do not have access permission.

  ObservedBehavior:
  The internals of the file dialog code use a proc called 
  tkFDialogResolveFile. This proc calls pwd. If the pwd call fails then a tcl error results rather than the dialogue box code handling it cleanly.

  error getting working directory name: permission denied
      while executing
  "pwd"
      (procedure "tkFDialogResolveFile" line 41)
      invoked from within
  "tkFDialogResolveFile $data(selectPath) $text  $data(-defaultextension)"
      (procedure "tkFDialog_ActivateEnt" line 5)
      invoked from within
  "tkFDialog_ActivateEnt .__tk_filedialog"
      (command bound to event)

  DesiredBehavior:
  Clean error handling by the dialogue box code.



  Doing some tests, this seems to be valid behavior.  The dialog
  will pop up a message when you try and enter a non-readable
  directory, and this error is received when the -initialdir
  specified is non-readable.  Since the programmer has to specify
  this explicitly, they should check for [file readable] first. 
  -- 11/12/1999 hobbs


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


  Test script:

  after 6000 reraise

  proc reraise {} {
      after 6000 reraise

      wm deiconify .
      raise .
  }

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



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


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


  Danny has the following comments:

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

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

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


tkt_uuid: 220126ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: grab misbehaves on W98
comment:
  OriginalBugID: 1268 Bug
  Version: 8.1b1
  SubmitDate: '1999-02-23'
  LastModified: '2000-04-03'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  RelatedBugIDs: 1158 1510
  OS: Windows 98
  Machine: X86
  ClosedDate: '2000-04-03'


  Name:
  Christopher Nelson

  ReproducibleScript:
  button .b1 -text button1
  button .b2 -text button2
  pack .b1 .b2
  grab set -global .b1





  ObservedBehavior:
  Clicking on b2 causes b1 to be changed to sunken relief and never come
  back.




  DesiredBehavior:
  b1 should invoke normally or ignore the button click outside it's
  borders.






  Fails on all versions of Windows.  03/25/1999 15:37 - surles -
  Related bug IDs 1158 1510

  --

  This seems to have been fixed by 8.3.0.  I cannot reproduce it.

  - eric
   
  -- 04/03/2000 ericm


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


  Name:
  Bryan Oakley

  Extensions:
  (none)

  CustomShell:
  (none)

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

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

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





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




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






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


tkt_uuid: 220128ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 39. Image Basics
priority: 1 Zero
foundin: None
resolution: Wont Fix
title: image command may hose existing procedures
comment:
  OriginalBugID: 1338 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-09-13'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.5.1
  Machine: Other
  ClosedDate: '1999-09-13'


  Name:
  Michael Thomas

  Extensions:
  Itcl3.0.1, Home-made

  CustomShell:
  Jan Nijtman's dash patch was applied to

  ReproducibleScript:
      Run the following script with no arguments.
      
      #!/usr/local/bin/wish8.0
      
      proc image1 {} {
          puts "My image1 called"
      }
      
      image1
      
      image create photo
      
      image1
      
      



  ObservedBehavior:
      The first call to the image1 procedure invokes the user-defined "image1"
      proc.  The second call invokes the image1 command that was automatically
      created by the image command, as indicated by the error message.
      There was no warning or error when the user-defined image1 procedure was
      replaced.
      



  DesiredBehavior:
      When the Tk "image" command is used without supplying a command name, as
      it is above, it will automatically create a new command name.  It should
      check that the automatically created name does not already exist before
      using it, and choose a different name if it does.
      
      If the user specifies a name for the new image command, as in:
      
      image create photo myimageproc
      
      Then the current behaviour seems fine; it is up to the user in this
      case to make sure the command does not already exist.
      
      Similar results are obtained when using the Itcl "class" command.  I
      have
      not yet checked, but the same may also hold true for "open", and any
      other
      command that generates names for new commands. (I hope this was clear).
      
      




  This is a known 'feature' of images, as they are created like
  commands.  proc will also overwrite commands without warning. 
  -- 09/13/1999 hobbs


tkt_uuid: 220129ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: Listbox "-selectmode single" behavior
comment:
  OriginalBugID: 1358 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-08'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2086
  OS: HP-UX
  Machine: Other
  ClosedDate: '1999-08-07'


  Name:
  Bradley Mazurek

  Extensions:
  BLT, iTcl

  CustomShell:
  None

  ReproducibleScript:
  pack [listbox .lb -selectmode single]
  foreach item [list a b c d e f] {
    .lb insert end $item
  }
  .lb selection set 2 4

  ObservedBehavior:
  Even though the listbox selectmode is "single", more than one item is selected.

  DesiredBehavior:
  Because the selectmode is "single", precisely one item (don't really care which...first or last in given range), is selected.



  I could be completely off base, and this functionality/behavior may be
  intended....

  Yes, this is the intended behavior.  The listbox -selectmode is an
  option that the bindings use to interpret user interaction.  If
  the selection method is called by the programmer, then it can go
  against this behavior without problem. 
  -- 08/07/1999 hobbs


tkt_uuid: 220130ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: ld.so.1: ./wish8.0: fatal: libX11.so.6.1: open failed: No such file or directory
comment:
  OriginalBugID: 1371 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '1999-04-16'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: stanton
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  ClosedDate: '1999-04-16'


  Name:
  Ron Forrester

  ReproducibleScript:
  ./wish8.0

  ObservedBehavior:
  ld.so.1: ./wish8.0: fatal: libX11.so.6.1: open failed: No such file or directory

  DesiredBehavior:
  Expect to see the shell prompt for tk...



  Brand new install.
  installed packages tcl.8.0.3.sparc.solaris.2.6.pkg.tgz and tk.8.0.3.sparc.solaris.2.6.pkg.tgz with no problems.
  ./tclsh8.0 shell works fine.

  Could it be a PATH problem?

  Sounds like  a version problem. The solaris packages were built on Solaris 2.5 and possibly the new solaris has a different X11.  The user should check the LD_LIBRARY_PATH.  

  There is nothing to be done here, so I am closing the bug.
  04/16/1999 13:26 - stanton -


tkt_uuid: 220131ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: Timing problems displaying MS Windows scrollbars with correct configured width
comment:
  OriginalBugID: 1382 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '1999-10-22'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-10-22'


  From: "Phil Quackenbush" <QUACKENB@qwpage.com>

  Timing problems displaying MS Windows scrollbars with correct 
  configured width.

  7.  Instruction on how to reproduce the problem including a short test
      script.

  set testVariable {The rain in Spain falls mainly on the plain.}
  toplevel ._test
  entry ._test._entry
  scrollbar ._test._scrollbar
  ._test._entry configure -textvariable testVariable
  ._test._scrollbar configure -orient horizontal -width 3c
  pack ._test._entry -fill x
  pack ._test._scrollbar -fill x
  wm geometry ._test 433x95+0+0

  # believe it or not, sometimes the statement commented out below 
  # works, sometimes it doesn't!
  # with no delay or short delays the scrollbar remains skinny
  # if the delay is lengthened past 15-25, or whatever (? - timing not 
  # consistent), it usually works
  # at some point past this it always works

  #after 25 {wm geometry ._test 433x94+0+0}
  # or... (it doesn't matter, either one will do)
  #after idle {after 25 {wm geometry ._test 433x94+0+0}}

  8.  Described the undesired behavior you observed

  MS Windows scrollbar sits dead at some predefined default width, 
  until some delay has occurred, and then a whack to the geometry of 
  the toplevel sets the scrollbar to the correct height.

  Originally I had the script in 2 parts in 2 files and would source 
  them from the console (and hence the "human" delay in between).  Then 
  I caused the delay with the after command so I could play with it, 
  and submit a single script.

  9.  Described the behavior you expect to see

  I expect to see the scrollbar appear with the correct width in the 
  first place.

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


  This is a minor programming error.  The user requires an
  'update idletasks' or 'update' following the wm geometry call. 
  -- 10/22/1999 hobbs


tkt_uuid: 220132ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: upvar 2 (!) needed for traces on entry-textvariable
comment:
  OriginalBugID: 1383 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '2000-03-02'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  Machine: Other
  ClosedDate: '2000-03-02'


  Name:
  Alexandre FERRIEUX

  ReproducibleScript:
  proc handler {name index opt} {
  upvar 2 $name loc ;# <-- fails with upvar 1 !!!
  puts BEGIN
  puts "$name=$loc" ;# <-- errors here are caught !!!
  puts END
  }
  entry .e -textvariable x
  trace variable x w handler
  pack .e
  # type in the entry...

  ObservedBehavior:
  Bug 1: "upvar 2" is needed in this case (trace of a -textvariable), while "upvar 1" is required (and documented) in all other cases.

  Bug 2: errors raised within the handler are caught and ignored

  DesiredBehavior:
  obvious



  This is verified.  Since textvars are always required to be vars
  reached at the global scope, the work-around would be to use #0
  for the upvar level. 
  -- 08/07/1999 hobbs
  A little bit of interactive debugging solved this one (using
  tkcon's idebug).  The level is 2 for newer versions of Tcl
  because the handler is being called from tkEntryInsert (before
  the insert was done directly in the binding).  So one should
  always use #0, as for entry widgets they only work with global
  vars anyway. 
  -- 03/02/2000 hobbs


tkt_uuid: 220133ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: WinNT: buttons have too much padding
comment:
  OriginalBugID: 1394 Bug
  Version: 8.0p2
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-07'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-08-07'


  Name:
  John Wiersba

  ReproducibleScript:
  button .b -pady 0 -text high
  pack .b

  ObservedBehavior:
  on WinNT (version 8.0 according to $tcl_patchLevel), when I set -pady to 0, the button still has a lot of padding above/below the text.

  DesiredBehavior:
  no padding at all when -pady is set to 0



  The user needs to make use of -ipadx/-ipday as well. 
  -- 08/07/1999 hobbs


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: 220135ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: documentation of combobox.tcl
comment:
  OriginalBugID: 1408 RFE
  Version: 8.0p2
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: SunOS
  OSVersion: 4.1.3
  Machine: Sparc
  ClosedDate: '1999-08-06'


  Name:
  Grigaut Michel

  Extensions:
  7.4    8.0.2

  DesiredBehavior:
  Now I'm here, I'm almost sure I'm not at the right place. Please forgive me but I could not know before seeing thal all was (almost) for TclPro I'm not using.

  My request is :
  Is it possible to have two or three lines of example showing how to use the combobox.tcl package. If not, just forget it. Many thanks



  The combobox.tcl package is not a Scriptics related package.
  This could be the one from Donal Fellows or Bryan Oakley. 
  -- 08/06/1999 hobbs


tkt_uuid: 220136ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: problems compiling TK using Borland 4.52
comment:
  OriginalBugID: 1432 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-04'
  LastModified: '1999-11-16'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT4 service pack 3
  Machine: X86
  ClosedDate: '1999-11-16'


  Name: Mark Elfield

  ReproducibleScript:
  In win, copy makefile.bc to makefile, and run Borland make.

  ObservedBehavior:
  1.  Can't find zmouse.h (workaround, create a dummy zmouse.h and set WM_MOUSEWHEEL to something)

  2.  TCLDIR is set to 8.0.3, should be 8.0.4

  3.  Many warnings.  (haven't determined if the libraries work yet)

  Even more problems with 8.1

  DesiredBehavior:
  The make should run without errors or warnings.



  Direct support for the Borland compiler was dropped due to lack
  of user base maintaining the borland makefile.  We have instead
  moved to a cygwin build configuration for 8.2, with a working
  VC makefile as well.  Newer versions of Borland reportedly read
  the VC makefile.  (1) is due to an older Borland, (2) was eliminated
  along the way, and (3) we don't see in current builds. 
  -- 11/16/1999 hobbs


tkt_uuid: 220137ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: fatal error during make
comment:
  OriginalBugID: 1436 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-04'
  LastModified: '1999-09-16'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Other
  OSVersion: SCO Unixware 7.0
  Machine: NA
  ClosedDate: '1999-09-16'


  Name:
  Jack Wenger

  Extensions:
  ?

  CustomShell:
  none

  ReproducibleScript:
  make

  ObservedBehavior:
  # make
          cc -c -O    -I. -I./../generic  -I./../bitmaps -I/home/jack/download/tcl8.0.4/generic -I -lX11   -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1       ./tkUnixDraw.c
  UX:acomp: ERROR: "./tkUnixDraw.c", line 93: first operand must have scalar type: op "?:"
  *** Error code 1 (bu21)
  UX:make: ERROR: fatal error.

  DesiredBehavior:
  a finished compile



  I'm trying to install TK on an SCO Unixware 7.0 box. TCL compiled and installed fine. I've had to edit a number of .h files to even get to this point. The best part is I'm not a programmer, simply a Unix Admin.
  --
  These look to be compiler problems.  The areas that it is complaining
  about are valid C code. 
  -- 09/16/1999 hobbs


tkt_uuid: 220138ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: tk_textPaste
comment:
  OriginalBugID: 1445 Bug
  Version: 8.0p2
  SubmitDate: '1999-03-04'
  LastModified: '1999-09-18'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux-SuSE
  Machine: Other
  ClosedDate: '1999-09-18'


  Name:

  Joe Acosta


  ReproducibleScript:

  in the tk_textPaste function there is some code for unix that prevents pasting over a aselection.


  ObservedBehavior:

  If I create a text widget, and I I select some text and copy it using tk_textCopy, then I select some more text to paste over and then paste the original copied text using tk_textPaste under UNIX,  the pasted text does not overwrite the selected text.


  DesiredBehavior:

  there should not be a line in the tk_textPaste function of text.tcl that says

  if {"$tcl_platform(platform)" != "unix"} {




  That is there to better follow "Unix style", where the sense of a
  clipboard like on Windows is foreign.  In general on Unix, a widget
  owns the selection, and whatever is selected is what would be
  exported. 
  -- 09/18/1999 hobbs


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


  Name:
  Ed Hume

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

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

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



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


tkt_uuid: 220140ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: Control-v under Unix
comment:
  OriginalBugID: 1455 RFE
  Version: 8.0p2
  SubmitDate: '1999-03-04'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux-SuSE
  Machine: Other
  ClosedDate: '1999-08-06'


  Name:
  Joe Acosta

  DesiredBehavior:
  Some way of unbinding default bindings, using only the script and no C code.
  Currently there are default bindings, in particular "Control-v" whcih does a page down under unix. I am creating a cross platform editor and want to use Control-v as my Paste to please my Windows95/98/NT users. Is there/will there be a way to unbind this binding without me changing the text.tcl code? I think that possible makeing another value for tk_strictMotif may work, instead of it being a boolean of 0 or 1. Say a value of 2 would turn off all bindings? Then I could defing my own. Or maybe making the behavior such that the binding in the parent script override the default bindings of tcl/tk? I'd rather not use Meta keys either.



  All the bindings are controllable at the Tcl level through the
  'bind' command.  They can be overwritten, extended, removed, etc.
  You can refer to the text.tcl for just examples of what you might
  want to provide. 
  -- 08/06/1999 hobbs


tkt_uuid: 220141ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: Colour options in tk are not functioning correctly.
comment:
  OriginalBugID: 1489 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-11'
  LastModified: '1999-08-13'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux
  OSVersion: Caldera OpenLinux 1.3  (kernel 2.0.35)
  Machine: Other
  ClosedDate: '1999-08-13'


  Name:
  Donald Radke

  ObservedBehavior:
      I have a copy of Tcl-Blast which I have installed onto my RedHat Linux
      (2.0.36) and onto an Caldera OpenLinux (2.0.35).  Orginal design/coding
      and testing where performed on the RedHat drive with no problems.  I
      placed my code on the OpenLinux drive and the colour scheme was
      different.  My balloon popups do not have a background colour of yellow
      like the RedHat version.  Also, the default background seems to be white
      and will not change even if I try to modify it.
      
      Has anyone else had this problem?  Could it be that OpenLinux is using
      "libc" and RedHat is using the other one (glib)?
      




  These problems are likely X server related.  It is possible that
  the other machine sets X resources to change the fg/bg color,
  causing the balloon popup to change color (these are not a standard
  element of Tk).  Users have to be careful of global X resources, as
  they can effect Tk (this can occur on CDE/KDE as well in their
  default setups). 
  -- 08/13/1999 hobbs


tkt_uuid: 220142ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: grab bug
comment:
  OriginalBugID: 1496 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-12'
  LastModified: '2000-01-27'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.5.1
  Machine: Other
  ClosedDate: '2000-01-27'


  Name: steve

  Extensions: expect 8.0.4

  ReproducibleScript:
      running expectk - same under wish
      
      from menu command call proc to create child window
      from bind double-click listbox call same proc to create child window
      
      the grab gets set to child window everytime using menu option
      so that user can't touch parent window ever.
      
      the grab does not get set to child window everytime using double click
      from listbox.
      
      in other words if the user double clicks the grab does not get
      set everytime - seems to be hit and miss situation.

  ObservedBehavior:
      no errors at all ( no stack traces) - the behavior is not consistent
      when setting local grab using the same procedure
      via different call points/events

  DesiredBehavior:
      when i call this proc to produce a child window from either
      a menu command or a bind command the grab should work all the
      time.

   Actual code is necessary to really evaluate this one.  I suspect
  that the problem is the user may have set up the window to be
  grabbed when a mouse button could be down.  This is a special
  situation, so if the user needs to set the grab in a case like
  that, it has to be coded carefully. 
  -- 01/27/2000 hobbs


tkt_uuid: 220144ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Invalid
title: Code hangs after changing an ovals binding
comment:
  OriginalBugID: 1513 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-16'
  LastModified: '1999-03-25'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: surles
  OS: HP-UX
  OSVersion: B.10.20
  Machine: Other
  ClosedDate: '1999-03-25'


  Name:
  John Engebretsen

  ReproducibleScript:
      #!/bin/sh
      # the next line restarts using wish  exec wish "$0" "$@"
      
      button .b -command exit -bg black -fg white -text exit
      pack .b
      
      message .m -aspect 300 -bg blue -fg white -text "Is this a bug?
      Move the cursor over a corner of the square.
      A red dot should appear.
      When the cursor leaves the dot,
      the dot disappears
      
      Now click button 1"
      
      pack .m -fill x -expand true
      
      set w [canvas .draw -width 300 -height 300 -bg black]
      pack $w
      
      global nodeDT
      
      $w create line 100 100 100 200 200 200 200 100 100 100 -fill green -tags
      BOX
      
      set x 100
      set y 100
      set nodeDT(1) [$w create oval [expr $x-10] [expr $y-10] [expr $x+10] [expr
      $y+10] -outline "" -fill "" -tags NODE]
      set x 100
      set y 200
      set nodeDT(2) [$w create oval [expr $x-10] [expr $y-10] [expr $x+10] [expr
      $y+10] -outline "" -fill "" -tags NODE]
      set x 200
      set y 100
      set nodeDT(3) [$w create oval [expr $x-10] [expr $y-10] [expr $x+10] [expr
      $y+10] -outline "" -fill "" -tags NODE]
      set x 200
      set y 200
      set nodeDT(4) [$w create oval [expr $x-10] [expr $y-10] [expr $x+10] [expr
      $y+10] -outline "" -fill "" -tags NODE]
      
      $w bind NODE <Any-Enter> {
              set item [$w find withtag current]
              $w itemconfigure current -outline "" -fill red
      }
      
      $w bind NODE <Any-Leave> {
              $w itemconfigure current -outline "" -fill ""
      }
      
      bind $w <Button-3> {exit}
      
      bind $w <Button-1> {
              $w bind NODE <Any-Enter> {
                      set item [$w find withtag current]
                      $w itemconfigure current -outline red -fill ""
              }
              $w bind NODE <Any-Leave> {
                      $w itemconfigure current -outline "" -fill ""
              }
              .m configure -aspect 300 -text "
      Move the cursor over a corner of the square.
      Now the dots should be circles
      But the widget locks up (note: exit button), why?"
      }
      
      



  ObservedBehavior:
      Instructions are inculded in the example. When the bindings change for
      the ovals (tagged with NODE) the program hangs.
      



  DesiredBehavior:
      Small circles should surround corners of the square when
      the cursor passes over them. The corners of the square need
      to be visible for the real application.
      





      I'm not sure this should work, leaving an unfilled item may not have
      meaning.
      But it should not cause the code to hang.
      I have tried this on 8.03, 8.05, and 8.1b1, all beahve the same way.
  -----
  This is not a bug.  It is the way the Canvas handles filled items.  Take a look at the modified code
  sample below.  Notice the "update" command.  If you remove this, the "hanging" will appear, otherwise you will notice the output in the console.  The bindings on Enter and Leave are being fired infinately because the dots are being drawn then removed.
  03/25/1999 11:51 - surles -

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

  set w [canvas .draw -width 300 -height 300 -bg black]
  $w create oval 100 100 200 200 -fill "green" -tags BOX
  pack $w

  $w bind BOX <Any-Leave> [list badLeave $w]
  $w bind BOX <Any-Enter> [list badEnter $w]

  set badCounter 0
  proc badLeave {w} {
      puts "Leave$::badCounter"
      $w itemconfigure current -outline "" -fill ""
  }
  proc badEnter {w} {
      puts "Enter$::badCounter"
      incr ::badCounter

      set item [$w find withtag current]
      $w itemconfigure $item -outline red -fill ""
      update
  }


tkt_uuid: 220145ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: under Irix 6.2 I get segmentation violation in demos. 8.0.3 worked fine
comment:
  OriginalBugID: 1535 Bug
  Version: 8.0.5
  SubmitDate: '1999-03-18'
  LastModified: '1999-11-16'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: IRIX
  OSVersion: 6.2
  Machine: Other
  ClosedDate: '1999-11-16'


  Name:
  paul lansky

  CVS:
  March 16

  ReproducibleScript:
      /usr/local/lib/tk8.0/demos/widget
      
      gets segmentation violation, as do all the other demos there.
      
      I had no problems with 8.0.3 under Irix 6.2


  Was any change made in the compiler?  There are known problems
  with various versions of gcc on IRIX.  Also, some improved config
  stuff is in 8.2. 
  -- 09/20/1999 hobbs
  Verified that Tcl/Tk 8.0.5 builds and runs the demos fine on
  an IRIX 6.3 machine with the MIPS compiler. 
  -- 11/16/1999 hobbs


tkt_uuid: 220146ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Invalid
title: make runtest: missing dependency
comment:
  OriginalBugID: 1565 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-19'
  LastModified: '1999-03-25'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: surles
  OS: Other
  Machine: NA
  ClosedDate: '1999-03-25'


  Name:
  Don Porter

  ReproducibleScript:
      $ cd tk8.1b2/unix
      $ ./configure --enable-gcc --enable-shared
      $ make
      $ make runtest

  ObservedBehavior:
      ...
      ./tktest
      /bin/sh: ./tktest: not found
      make: *** [runtest] Error 1

  DesiredBehavior:
      make runtest should start the testing shell tktest
      with all the path variable nonsense taken care of.

      A dependency should make sure ./tktest exists.

  Patch:
  Index: sun/tk/unix/Makefile.in
  diff -c sun/tk/unix/Makefile.in:1.1.1.8 sun/tk/unix/Makefile.in:1.2
  *** sun/tk/unix/Makefile.in:1.1.1.8     Wed Mar 17 12:02:48 1999
  --- sun/tk/unix/Makefile.in     Fri Mar 19 19:17:03 1999
  ***************
  *** 406,412 ****
          ./tktest $(TOP_DIR)/tests/all.tcl -geometry +0+0

    # Useful target to launch a built tktest with the proper path,...
  ! runtest:
          LD_LIBRARY_PATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH};  export LD_LIBRARY_PATH;  SHLIB_PATH=`pwd`:${TCL_BIN_DIR}:${SHLIB_PATH};  --- 406,412 ----
          ./tktest $(TOP_DIR)/tests/all.tcl -geometry +0+0

    # Useful target to launch a built tktest with the proper path,...
  ! runtest: tktest
          LD_LIBRARY_PATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH};  export LD_LIBRARY_PATH;  SHLIB_PATH=`pwd`:${TCL_BIN_DIR}:${SHLIB_PATH};  

  PatchFiles:
      unix/Makefile.in



  Looking at the comment directly above the runtest target, it notes that this target is for
  ease of use.  It assumes that tcltest has been built and is up to date.  It's sole purpose
  is to set all of the env variables and launch tcltest the same way that the test target does.

  Since this is what runtest was designed to do, and the comments back this up, I'm closing 
  this bug.  03/25/1999 15:21 - surles -


tkt_uuid: 220148ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 64. Graphic Contexts
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Invalid
title: widget creation aborts Tk
comment:
  OriginalBugID: 1567 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-22'
  LastModified: '1999-04-20'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: redman
  OS: Other
  OSVersion: RedHat Linux 5.x on Alpha XL 300
  Machine: NA
  FixedInVersion: 8.1b3
  ClosedDate: '1999-04-20'


  Name:
  Don Porter

  ObservedBehavior:
      Invoking most of the widget creation commands of Tk is
      causing wish to abort.  Two examples follow; the first
      is most representative:
      
      $ wish8.1
      % text .t
      GC already registered in Tk_GetGC
      
      Program received signal SIGABRT, Aborted.
      0x15555eef4e8 in __kill () at __kill:2
      __kill:2: No such file or directory.
      (xxgdb) info stack
      #0  0x15555eef4e8 in __kill () at __kill:2
      #1  0x15555eef2f8 in raise (sig=6) at ../sysdeps/posix/raise.c:27
      #2  0x15555ef0940 in abort () at ../sysdeps/generic/abort.c:83
      #3  0x1555594b1e4 in Tcl_PanicVA (format=0x155557695d0 "GC already
      registered in Tk_GetGC", argList={__base = 0x11fffed90 "Ð\225vUU\001",
      __offset = 72}) at ./../generic/tclPanic.c:93
      #4  0x1555594b2a0 in Tcl_Panic (arg1=0x155557695d0 "GC already
      registered in Tk_GetGC") at ./../generic/tclPanic.c:121
      #5  0x155556bc098 in Tk_GetGC (tkwin=0x120167480, valueMask=65536,
      valuePtr=0x11fffeee8) at ./../generic/tkGC.c:262
      #6  0x155557536a4 in TkTextCreateDInfo (textPtr=0x120199040) at
      ./../generic/tkTextDisp.c:385
      #7  0x155557493d8 in Tk_TextCmd (clientData=0x12013b890,
      interp=0x1201016f0, argc=2, argv=0x11ffff030) at
      ./../generic/tkText.c:270
      #8  0x155558e0b94 in TclInvokeStringCommand (clientData=0x120142710,
      interp=0x1201016f0, objc=2, objv=0x120102ed0) at
      ./../generic/tclBasic.c:1773
      #9  0x155559147e0 in TclExecuteByteCode (interp=0x1201016f0,
      codePtr=0x120191900) at ./../generic/tclExecute.c:843
      #10 0x155558e203c in Tcl_EvalObjEx (interp=0x1201016f0,
      objPtr=0x1201118a0, flags=131072) at ./../generic/tclBasic.c:2719
      #11 0x15555927618 in Tcl_RecordAndEvalObj (interp=0x1201016f0,
      cmdPtr=0x1201118a0, flags=131072) at ./../generic/tclHistory.c:142
      #12 0x155559273d0 in Tcl_RecordAndEval (interp=0x1201016f0,
      cmd=0x12010d868 "text .t\n", flags=131072) at
      ./../generic/tclHistory.c:62
      #13 0x155556c6734 in StdinProc (clientData=0x12014ead0, mask=2) at
      ./../generic/tkMain.c:349
      #14 0x15555934a08 in Tcl_NotifyChannel (channel=0x12014ead0, mask=2) at
      ./../generic/tclIO.c:5597
      #15 0x15555979c5c in FileHandlerEventProc (evPtr=0x120149bc0, flags=-3)
      at ./../unix/tclUnixNotfy.c:572
      #16 0x1555594836c in Tcl_ServiceEvent (flags=-3) at
      ./../generic/tclNotify.c:573
      #17 0x15555948978 in Tcl_DoOneEvent (flags=-3) at
      ./../generic/tclNotify.c:875
      #18 0x155556b3038 in Tk_MainLoop () at ./../generic/tkEvent.c:1102
      #19 0x155556c6528 in Tk_MainEx (argc=1, argv=0x11ffff7e8,
      appInitProc=0x120000a88 <Tcl_AppInit>, interp=0x1201016f0) at
      ./../generic/tkMain.c:278
      #20 0x120000a5c in main (argc=1, argv=0x11ffff7e8) at ./tkAppInit.c:54
      
      $ wish8.1
      % entry .e
      
      Program received signal SIGSEGV, Segmentation fault.
      0x15555926d80 in ArrayCreate (tablePtr=0x120110718, key=0x6400006
      <Address 0x6400006 out of bounds>, newPtr=0x11fffedf8) at
      ./../generic/tclHash.c:734
      (xxgdb) info stack
      #0  0x15555926d80 in ArrayCreate (tablePtr=0x120110718, key=0x6400006
      <Address 0x6400006 out of bounds>, newPtr=0x11fffedf8) at
      ./../generic/tclHash.c:734
      #1  0x155556b0c5c in GetCursor (interp=0x1201016f0, tkwin=0x1201998c0,
      string=0x12014ce00 "xterm") at ./../generic/tkCursor.c:279
      #2  0x155556b09e8 in Tk_AllocCursorFromObj (interp=0x1201016f0,
      tkwin=0x1201998c0, objPtr=0x12014b810) at ./../generic/tkCursor.c:153
      #3  0x155556ae688 in DoObjConfig (interp=0x1201016f0,
      recordPtr=0x120199ab0 "À\230\031 \001", optionPtr=0x120199170,
      valuePtr=0x12014b810, tkwin=0x1201998c0, savedOptionPtr=0x0) at
      ./../generic/tkConfig.c:820
      #4  0x155556ade94 in Tk_InitOptions (interp=0x1201016f0,
      recordPtr=0x120199ab0 "À\230\031 \001", optionTable=0x120199090,
      tkwin=0x1201998c0) at ./../generic/tkConfig.c:538
      #5  0x155556ff324 in Tk_EntryObjCmd (clientData=0x0, interp=0x1201016f0,
      objc=2, objv=0x120102ed0) at ./../generic/tkEntry.c:518
      #6  0x155559147e0 in TclExecuteByteCode (interp=0x1201016f0,
      codePtr=0x120159fb0) at ./../generic/tclExecute.c:843
      #7  0x155558e203c in Tcl_EvalObjEx (interp=0x1201016f0,
      objPtr=0x1201118a0, flags=131072) at ./../generic/tclBasic.c:2719
      #8  0x15555927618 in Tcl_RecordAndEvalObj (interp=0x1201016f0,
      cmdPtr=0x1201118a0, flags=131072) at ./../generic/tclHistory.c:142
      #9  0x155559273d0 in Tcl_RecordAndEval (interp=0x1201016f0,
      cmd=0x12010d868 "entry .e\n", flags=131072) at
      ./../generic/tclHistory.c:62
      #10 0x155556c6734 in StdinProc (clientData=0x12014ead0, mask=2) at
      ./../generic/tkMain.c:349
      #11 0x15555934a08 in Tcl_NotifyChannel (channel=0x12014ead0, mask=2) at
      ./../generic/tclIO.c:5597
      #12 0x15555979c5c in FileHandlerEventProc (evPtr=0x12010e2a0, flags=-3)
      at ./../unix/tclUnixNotfy.c:572
      #13 0x1555594836c in Tcl_ServiceEvent (flags=-3) at
      ./../generic/tclNotify.c:573
      #14 0x15555948978 in Tcl_DoOneEvent (flags=-3) at
      ./../generic/tclNotify.c:875
      #15 0x155556b3038 in Tk_MainLoop () at ./../generic/tkEvent.c:1102
      #16 0x155556c6528 in Tk_MainEx (argc=1, argv=0x11ffff7e8,
      appInitProc=0x120000a88 <Tcl_AppInit>, interp=0x1201016f0) at
      ./../generic/tkMain.c:278
      #17 0x120000a5c in main (argc=1, argv=0x11ffff7e8) at ./tkAppInit.c:54
      
      





      I haven't yet been able to track down the bug and create a patch,
      but I didn't want to delay and miss the bug-fixing deadline for 8.1.
      This is definitely a show-stopper.

      Perhaps Tcl_CreateHashEntry(), stubs, and 64-bit platforms don't play
      well together?  Just guessing at this point.

  We need to make sure the 64-bit support in 8.1 has fixed this bug.
  04/16/1999 13:47 - stanton -
  04/20/1999 17:31 - redman - Fixed this problem in 8.1b3 when I added support for 64bit systems.


tkt_uuid: 220149ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b1
resolution: Invalid
title: threading problem in 8.1b1 provoked by tkcvs
comment:
  OriginalBugID: 1582 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-22'
  LastModified: '1999-03-22'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: pat
  OS: Solaris
  OSVersion: 2.6, fully patched
  Machine: Other
  ClosedDate: '1999-03-22'


  Name:
  Andreas Mueller

  Extensions:
  tcl 8.1b1, tk 8.1b1

  ReproducibleScript:
      I've installed tkcvs 6.0 and successfully run it with 8.0.
      Under 8.1b1 it works also some of the time, but stops working
      on a fast (Sun Ultra 60 type) machine when you move the mouse
      over the buttons at the bottom of the main window. Starting
      tkcvs under truss does not show this behaviour (machine seems
      to be more busy then, and thread locking seems not to be a problem).
      



  ObservedBehavior:
      As the problem does not show under truss, I'm quite out of
      luck to send you a trace.
      



  DesiredBehavior:
      tkcvs should not stop working
      




  03/22/1999 08:23 - pat - Problem resolved in 8.1b2
  From: Dr Andreas F Muller <afm@othello.ch>
  Date: Sun, 21 Mar 99 23:24:58 +0100
  To: support@scriptics.com
  Subject: Re: [Bug Tk 8.1b1] threading problem in 8.1b1 provoked by tkcvs
  Status: O

  Just checked with 8.1b2, problem did not show any longer.  Thanks
  for the fine software. Best regards

                                          Andreas Mueller


tkt_uuid: 220150ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: bug in ArrangeGrid procedure
comment:
  OriginalBugID: 1588 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-22'
  LastModified: '1999-10-21'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Other
  OSVersion: Linux 6.0 + glibc
  Machine: NA
  ClosedDate: '1999-10-21'


  Name:
  Andreas otto

  Extensions:
  adadtcl,

  CustomShell:
  See 6)

  ReproducibleScript:
          Lib:        libtk8.0
      
          Error:      Generate a CORE
                      Structure clientData was not initialised during
      idle-event-handling
      
          File:       generic/tkGrid.c
          Procedure:  ArrangeGrid
          Line:       ~ 1217
          Code:       Add ...
                          if(  masterPtr->column  > 1000  ||
                               masterPtr->row     > 1000  ||
                               masterPtr->numCols > 1000  ||
                               masterPtr->numRows > 1000      ) {
                          return;
                          }
                      ... to identify a not initialised clientData strukture
      
                      => this is a workaround
      
      



  ObservedBehavior:
      During an idle task the procedure ArrangeGrid was called with an invalid
      ClientData Pointer => CoreDump
      
      Workaround: test the pointer to be valid 
      all columns/rows must be less than 1000
      
      better add an extra field with Structur-Check Information
      => Identify if an pointe on a struc is valid
      



  DesiredBehavior:
      No CoreDump
      




  This appears to be the fault of whatever is passing in the
  bad clientData structure.  Is this adadtcl?  Since this is
  the only report of this type, we can only assume the custom
  shell is at fault. 
  -- 10/21/1999 hobbs


tkt_uuid: 220151ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Invalid
title: windows crash in "exit": TkFontPkgFree: all fonts should have been freed already
comment:
  OriginalBugID: 1593 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-22'
  LastModified: '1999-03-30'
  Severity: CRIT
  Status: Closed
  Submitter: hershey
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-03-30'


  At the end of the Tk test suite on Windows, during the "exit" call,
  you get the following crash error:

      TkFontPkgFree: all fonts should have been freed already

  To reporduce this crash, place the following code in the file
  "tk8.1/tests/tmp.tcl" and run the file on Windows in the "tktest.exe"
  interpreter:

  win/release/tktest.exe tests/tmp.tcl

  # beginning of crash script
  if {[lsearch ::test [namespace children]] == -1} {
      source [file join [pwd] [file dirname [info script]] defs.tcl]
  }
  set ::test::testSingleFile false

  set fileList {}
  foreach file [list entry.test event.test focusTcl.test font.test  frame.test geometry.test grid.test] {
      lappend fileList [file join $::test::testsDir $file]
  }

  # source each of the specified tests
  foreach file [lsort $fileList] {
      set tail [file tail $file]
      if {[string match l.*.test $tail]} {
  # This is an SCCS lockfile; ignore it
  continue
      }
      puts stdout $tail
      if {[catch {source $file} msg]} {
  puts stdout $msg
      }
  }
  exit
  # end of crash script



  a quick run through purify might expose the bug...

  This does not seem to be reproducible.
  03/30/1999 13:59 - stanton -


tkt_uuid: 220152ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Invalid
title: Request change in Tk installation
comment:
  OriginalBugID: 1641 RFE
  Version: 8.1b2
  SubmitDate: '1999-03-26'
  LastModified: '2000-02-25'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  ClosedDate: '2000-02-25'


  Name:
  Larry W. Virden

  Extensions:
  Tk

  DesiredBehavior:
      Libraries distributed relating to Tcl should be installed in
      either ${prefix}/lib/{extension_name.version} or in
      ${exec_prefix}/lib/{extension_name.version}, depending on
      whether the portion is script or binary.
      Current practice of installing binary extensions directly into
      ${exec_prefix}/lib/ results in pkgIndex.tcl problems.
      





      By updating the example extension, Tk, and Tcl distribution
      source, Scriptics sets a useful precendence for extension
      writers.
      ---

  I don't think I'm understanding the problem here correctly.  Tcl/Tk
  already separates itself based on $prefix and $exec-prefix.  What
  exactly is not being done correctly? 
  -- 02/25/2000 hobbs


tkt_uuid: 220153ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Invalid
title: Photos don't provide a way to get the size
comment:
  OriginalBugID: 1647 RFE
  Version: 8.1b2
  SubmitDate: '1999-03-26'
  LastModified: '1999-08-06'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Other
  OSVersion: FreeBSD 3.0
  Machine: NA
  ClosedDate: '1999-08-06'


  Name:
  Steven Grady

  CustomShell:
  I applied the Img8.1b2 patches to Tk

  ReproducibleScript:
      #!/usr/local/bin/wish8.1
      image create photo foo -file test.gif
      puts [foo cget -width] 
      
      (Provide a GIF file, test.gif, when running)
      



  ObservedBehavior:
      The width is "0"
      



  DesiredBehavior:
      I'd like to see the width of the image.  If I can't get it via "cget
      -width",
      then there should be a separate option to extract information about the
      current
      photo.
      
      (This is also important when changing the size via. subsampling.)
      




  This is the purpose of the [image width|height <name>] methods. 
  -- 08/06/1999 hobbs


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: 220155ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Works For Me
title: make test crashes with Tk and threading
comment:
  OriginalBugID: 1654 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-29'
  LastModified: '1999-08-31'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  ClosedDate: '1999-08-31'


  Name:
  Larry W. Virden

  Extensions:
  Tk 8.1b2

  CustomShell:
  none

  ReproducibleScript:
      I configured Tk using
      # /vol/tclsrcsol/tcl81/tk8.1b2/unix/configure  --prefix=/usr/tcl81
      --exec_prefix
      =/usr/tcl81/sun4 --enable-threads --enable-shared --with-x
      --enable-tcl-stub
      
      I then did a make test.
      



  ObservedBehavior:
      dbx tktest core
      Reading symbolic information for tktest
      core file header read successfully
      Reading symbolic information for rtld /usr/lib/ld.so.1
      dbx: program is not active
      Reading symbolic information for libtk8.1.so
      Reading symbolic information for libtcl8.1.so
      Reading symbolic information for libsocket.so.1
      Reading symbolic information for libnsl.so.1
      Reading symbolic information for libpthread.so.1
      Reading symbolic information for libX11.so.4
      Reading symbolic information for libdl.so.1
      Reading symbolic information for libm.so.1
      Reading symbolic information for libc.so.1
      Reading symbolic information for libmp.so.2
      Reading symbolic information for libXext.so.0
      Reading symbolic information for libc_psr.so.1
      Reading symbolic information for libthread.so.1
      detected a multithreaded program
      dbx: program is not active
      t@1 (l@1) terminated by signal SEGV (no mapping at the fault address)
      (dbx 1) where                                                  
      current thread: t@1
      =>[1] main(0x4, 0xefffd6f4, 0x31bf0, 0x33000, 0x0, 0x0), at 0x1d5fc
      



  DesiredBehavior:
      I expected to see Tk build and run properly.
      




  I cannot reproduce this behavior.  This appears to be a threading problem, and since threading has undergone so much change lately, I think this may be fixed, but let's wait and see...
  I've email Larry and asked him to let me know if this is still a bug.
  04/20/1999 20:35 - hershey -
  --
  Threading is known to have problems with Tk in 8.1.  It could possibly
  work with 8.2 on some platforms, but still needs work. 
  -- 08/31/1999 hobbs


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


  Name:
  Jeff Gosnell

  Extensions:
  none that apply

  CustomShell:
  none

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



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





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

      I guess the Windows 98 behavior is due to some changes in its code and
      is valid for all the applications. The problem you describe could be a
      bug in Tcl on Windows 98 (in that case you should submit it to
      Scriptics). In the meantime, your solution seems to be an acceptable
      workaround. Let me suggest you add OS detection so that you can activate
      columnbreak under Windows 95 but not Windows 98. To do so, you can use
      the variables tcl_platform(os) and tcl_platform(osVersion). If the
      former is "Windows 95" and the later is less than 4.10 then you are
      under Windows 95, else you are under 98 or later. I think you'll also
      have to test your code on NT 4 and 5 to see if you get the same
      difference.

      See you, Fred
      -- 
      Frédéric BONNET                        frederic.bonnet@ciril.fr
      ---------------------------------------------------------------
      "Theory may inform, but Practice convinces"
                                                          George Bain

  --

  Windows 98 added this ability to its menus.  We use native menus on Windows, so we are at the mercy of the OS when it comes to how the menus are drawn.  Menus in Windows 95 simply do not have this feature, so we cannot do anything about it.

  You might consider using a combobox widget (there are several available as megawidgets, and we will have one in Tcl/Tk 8.4), otherwise -columnbreak is your best bet.

  - eric

  -- 04/03/2000 ericm


tkt_uuid: 220157ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: The "." window does not respect bindings for the "Toplevel" tag.
comment:
  OriginalBugID: 1702 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-02'
  LastModified: '1999-08-07'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-08-07'


  Name:
  Tom Hahn

  Comments:
  Broken in both NT and SGI/Irix

  ReproducibleScript:
  The "." window does not respect bindings for the "Toplevel" tag.
      
      If you "bind Toplevel <1> {puts foo}"
      then clicking in newly created toplevels prints "foo", but not in "."



  This is as expected.  The . window will have slightly different
  bindtags than other toplevels as its default class isn't Toplevel,
  but rather the name of the app.  You can add Toplevel with bindtags
  if you wish. 
  -- 08/07/1999 hobbs


tkt_uuid: 220158ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: Win95/NT: Focusing Tcl/Tk doesn't make it the active window
comment:
  OriginalBugID: 1712 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-05'
  LastModified: '1999-08-07'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0 with SP4
  Machine: X86
  ClosedDate: '1999-08-07'


  Name:
  Dean Tan

  Extensions:
  Tk

  ReproducibleScript:
  I'm using the Tik (Tcl version of AOL IM client) on WindowsNT, and if
      Tik is not the active application, and if you receive an instant message
      (IM), the IM window doesn't raise above and make Tik the activate
      application.
      
      It's using the "raise" command.
      
      The Tik developer think that this is a bug in the Windows version of
      Tcl/Tk.

  ObservedBehavior:
  window doesn't raise to be activate application

  DesiredBehavior:
  window should raised to become the application application



  On Windows you should do:
     focus -force $toplevel
     raise $toplevel
   
  -- 08/07/1999 hobbs


tkt_uuid: 220159ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Invalid
title: wish (and tktest) core dumps
comment:
  OriginalBugID: 1731 Bug
  Version: 8.1b2
  SubmitDate: '1999-04-05'
  LastModified: 
  Severity: CRIT
  Status: Closed
  Submitter: pat
  RelatedBugIDs: 1748
  OS: Digital Unix
  Machine: Other
  ClosedDate: '1999-04-07'


  Name:
  James Hemmerle

  CustomShell:
  I have changed the core files listed above so that wish will work on my machine (by putting an & in front of the key values).  However, those changes might not work on operating systems with data sizes that return 1 for the calls to the Tcl_InitHashTable given above.

  ReproducibleScript:
  entry .e

  ObservedBehavior:
  wish core dumps (or exits with a panic) on a number of the test scripts.
      This occurs when widgtes are created and are getting configured.

      This seems to be related to the hash tables created in the three files 
      1. tkBitmap.c (in BitmapInit() -
      Tcl_InitHashTable(&dispPtr->bitmapIdTable, sizeof(Pixmap) 
                      /sizeof(int)))
      2. tkCursor.c (in CursorInit() -
      Tcl_InitHashTable(&dispPtr->cursorIdTable, sizeof(Display *) 
          /sizeof(int)))
      3. tkGC.c (in GCInit() -
      Tcl_InitHashTable(&dispPtr->gcIdTable, sizeof(GC)/sizeof(int));

      In all three cases, the second argument to the Tcl_InitHashTable has a
      value of 2.  When these tables are later used in the code, the key value
      given to functions are not integer arrays.
      For example, in the GetCursor function in TkCursor.c ther is a line
          cursorPtr->idHashPtr = Tcl_CreateHashEntry(&dispPtr->cursorIdTable, 
                  (char *) cursorPtr->cursor, &new);
      This function calls CreateArray which tries to read elements of an array
      pointed to by (char *)cursorPtr->cursor but that is not a legal memory
      location.

      4. I also get an exception in the tests in scale.test.  This has to do
         with the value of the variable "value" not being intialized in
         the function ConfigureScale() in tkScale.c.  The command in the test
         that causes the problem is ".s configure -variable x".  Since x
      doesn't
         exist the variable "value" is used but not initialized causing an
         exception in a call to floor().



  parts 1-3 are not reporducable--probable unique to the custom interp.
  part 4 is logged as a seperate bug:  1748
  -hershey


tkt_uuid: 220160ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: entry is not properly updated when textvariable is changed
comment:
  OriginalBugID: 1787 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-12'
  LastModified: '1999-08-13'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux
  OSVersion: latest slackware i586
  Machine: Other
  ClosedDate: '1999-08-13'


  Name:
  Luc Deschenaux

  Comments:
  one more :)

  ReproducibleScript:
  when I bind <Button-1> to a listbox so that I an reflect the current
      selection in the entry it doesnt works.. with <Double-1> it works..
         
         global newname
         $w.entry#1 configure -textvariable newname
         bind $w.listbox#1 <Button-1> {
          global newname
          set l .pname.listbox#1
          set csel [$l curselection]
          if {$csel!={}} {
            set newname [$l get [lindex $csel 0]]
            update idletasks
          }
        }

  ObservedBehavior:
  it works with <Double-1> but the entry is updated with a one-click delay
      when using <Button-1>

  DesiredBehavior:
  I'll use <Double-1> but it should work with <Button-1>



  This is a programming error.  The user should refer to the
  Tk Usage FAQ on listboxes for the various solutions:
      http://www.purl.org/net/hobbs/tcl/faqs/tk/ 
  -- 08/13/1999 hobbs


tkt_uuid: 220161ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: calling exit() early in program gives Access violation
comment:
  OriginalBugID: 1805 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-14'
  LastModified: '1999-04-20'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: rjohnson
  OS: Windows 95
  Machine: X86
  ClosedDate: '1999-04-20'


  Name:
  James Hemmerle

  CustomShell:
  None

  Comments:
  My real application checks the command line arguments and calls exit
      on invalid input.  If the user had valid input the program runs and
      exits properly.

  ReproducibleScript:
  Add an exit() call as first line of main() in winMain.c.
      Compile program and run.

  ObservedBehavior:
  As the program executes the exit() call, you get an report in the
      VC++ debugger of:
      First-chance exception in wishc81d.exe (Tk81d.dll): 0xC0000005: Access
      violation (I compiled with NODEBUG=0).
      
      It seems to occur when the .dll is being unloaded.  DllMain()
      (tkWin32Dll.c) calls TkWinXCleanup() which calls TkWinWmCleanup()
      which bombs on the line:
          ThreadSpecificData *tsdPtr = (ThreadSpecificData *) 
                  Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));

  DesiredBehavior:
  No access violation.



  Tcl was not designed to work that way.  Simply calling exit(0 will not clean up nicely on any version of Tcl.  04/20/1999 15:34 - rjohnson -


tkt_uuid: 220162ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: several tests failed
comment:
  OriginalBugID: 1848 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-16'
  LastModified: '1999-08-31'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Digital Unix
  OSVersion: 4.0E
  Machine: Other
  ClosedDate: '1999-08-31'


  Name:
  Manuel Op de Coul

  CustomShell:
  none

  Comments:
  I used cc for both Tcl and Tk. With gcc, many warnings are emitted about
      wrong function arguments.
      I am using a 64 bit machine.

  ReproducibleScript:
  make test >test.log

  ObservedBehavior:
  grid.test
      menubut.test
      scale.test
      textIndex.test
      unixFont.test
      unixWm.test

      failed. I wanted to attach the test.log file but can't do in this form.
      What's the email address?

  From: manuel.op.de.coul@ezh.nl
  To: support@scriptics.com
  Date: Fri, 16 Apr 1999 15:45:55 +0200
  Subject: Re: [Bug Tk 8.0.5] several tests failed
  Content-disposition: inline
  Status: O

  1.

  (See attached file: TEST.LOG)

  2.text/plain
  LD_LIBRARY_PATH=`pwd`:/usr/users/coul1358/tcl8.0.5/unix:/usr/local/lib/lib;  export LD_LIBRARY_PATH;  SHLIB_PATH=`pwd`:/usr/users/coul1358/tcl8.0.5/unix:;  export SHLIB_PATH;  TCL_LIBRARY=/usr/users/coul1358/tcl8.0.5/library; export TCL_LIBRARY;  TK_LIBRARY=./../library; export TK_LIBRARY;  ( echo cd ./../tests\; source all\; exit )  | ./tktest -geometry +0+0
  (will skip non-portable tests)
  bell.test
  Bell should ring now ...
  bgerror.test
  bind.test
  button.test
  canvImg.test
  canvPs.test
  canvRect.test
  canvText.test

  ==== canvText-6.1 ComputeTextBbox procedure
  ==== Contents of test case:

      .c itemconfig test -font $font -text 0
      .c coords test 0 0
      set x {}
      lappend x [.c itemconfig test -anchor n; .c bbox test]
      lappend x [.c itemconfig test -anchor nw; .c bbox test]
      lappend x [.c itemconfig test -anchor w; .c bbox test]
      lappend x [.c itemconfig test -anchor sw; .c bbox test]
      lappend x [.c itemconfig test -anchor s; .c bbox test]
      lappend x [.c itemconfig test -anchor se; .c bbox test]
      lappend x [.c itemconfig test -anchor e; .c bbox test]
      lappend x [.c itemconfig test -anchor ne; .c bbox test]
      lappend x [.c itemconfig test -anchor center; .c bbox test]

  ==== Result was:
  {-5 0 6 19} {-1 0 10 19} {-1 -9 10 10} {-1 -19 10 0} {-5 -19 6 0} {-10 -19 1 0} {-10 -9 1 10} {-10 0 1 19} {-5 -9 6 10}
  ---- Result should have been:
  {-6 0 5 19} {-1 0 10 19} {-1 -10 10 9} {-1 -19 10 0} {-6 -19 5 0} {-10 -19 1 0} {-10 -10 1 9} {-10 0 1 19} {-6 -10 5 9}
  ---- canvText-6.1 FAILED
  canvWind.test
  canvas.test
  clipboard.test
  clrpick.test
  Skipped tests clrpick2.1, clrpick2.2 and clrpick2.3 because
  you ran out of colors in your color palette, and this would
  have caused the tests to generate errors.
  cmds.test
  color.test
  entry.test
  event.test
  filebox.test
  focus.test

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

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

  ==== Test generated error:
  X server insecure (must use xauth-style authorization); command ignored
  focusTcl.test
  font.test
  frame.test
  geometry.test
  grid.test

  ==== grid-6.9 location: check updates pending
  ==== Contents of test case:

  set a ""
  foreach i {0 1 2} {
      frame .$i -width 120 -height 75 -bg red
      lappend a [grid location . 150 90]
      grid .$i -row $i -column $i
  }
  set a

  ==== Result was:
  {0 0} {0 1} {1 1}
  ---- Result should have been:
  {0 0} {1 1} {1 1}
  ---- grid-6.9 FAILED
  id.test
  image.test
  imgBmap.test
  imgPPM.test
  imgPhoto.test
  listbox.test
  macEmbed.test
  macFont.test
  macMenu.test
  macWinMenu.test
  macscrollbar.test
  main.test
  menu.test
  menuDraw.test
  menubut.test

  ==== menubutton-4.5 ConfigureMenuButton procedure
  ==== Contents of test case:

      catch {destroy .mb1}
      button .mb1 -text "Sample text" -width 10 -height 2
      pack .mb1
      set result "[winfo reqwidth .mb1] [winfo reqheight .mb1]"
      .mb1 configure -bitmap questhead
      lappend result [winfo reqwidth .mb1] [winfo reqheight .mb1]

  ==== Result was:
  104 46 20 12
  ---- Result should have been:
  102 46 20 12
  ---- menubutton-4.5 FAILED

  ==== menubutton-7.13 ComputeMenuButtonGeometry procedure
  ==== Contents of test case:

      catch {destroy .mb}
      menubutton .mb -text String -bd 2 -relief raised  -highlightthickness 1 -indicatoron 1
      pack .mb
      list [winfo reqwidth .mb] [winfo reqheight .mb]

  ==== Result was:
  81 28
  ---- Result should have been:
  78 28
  ---- menubutton-7.13 FAILED
  msgbox.test
  oldpack.test
  option.test
  pack.test
  place.test
  raise.test
  safe.test
  scale.test

  ==== scale-7.1 ComputeScaleGeometry procedure
  ==== Contents of test case:

      catch {destroy .s}
      scale .s -from 0 -to 10 -label "Short" -orient vertical -length 5i
      pack .s
      update
      list [winfo reqwidth .s] [winfo reqheight .s]

  ==== Result was:
  88 508
  ---- Result should have been:
  88 458
  ---- scale-7.1 FAILED

  ==== scale-7.5 ComputeScaleGeometry procedure
  ==== Contents of test case:

      catch {destroy .s}
      scale .s -from 0 -to 10 -label "Short" -orient horizontal -length 5i
      pack .s
      update
      list [winfo reqwidth .s] [winfo reqheight .s]

  ==== Result was:
  508 61
  ---- Result should have been:
  458 61
  ---- scale-7.5 FAILED
  scrollbar.test
  select.test
  send.test
  Your X server is insecure, so "send" can't be used; skipping "send" tests.
  text.test
  textBTree.test
  textDisp.test
  textImage.test
  textIndex.test

  ==== textIndex-5.1 TkTextGetIndex, "@"
  ==== Contents of test case:

      .t index @12,9

  ==== Result was:
  1.0
  ---- Result should have been:
  1.1
  ---- textIndex-5.1 FAILED
  textMark.test
  textTag.test

  ==== textTag-16.2 TkTextPickCurrent procedure
  ==== Contents of test case:

      event gen .t <ButtonRelease-1> -state 0x100 -x $x1 -y $y1
      event gen .t <Motion> -x $x2 -y $y2
      set x [.t index current]
      .t tag add big 3.0
      update
      lappend x [.t index current]

  ==== Result was:
  3.2 3.2
  ---- Result should have been:
  3.2 3.1
  ---- textTag-16.2 FAILED

  ==== textTag-16.6 TkTextPickCurrent procedure
  ==== Contents of test case:

      foreach i {a b c d} {
  .t tag remove $i 1.0 end
      }
      event gen .t <Motion> -x $x1 -y $y1
      .t tag bind a <Enter> {.t tag add big 3.0 3.2}
      .t tag add a 3.2
      event gen .t <Motion> -x $x2 -y $y2
      update
      .t index current

  ==== Result was:
  3.2
  ---- Result should have been:
  3.1
  ---- textTag-16.6 FAILED

  ==== textTag-16.7 TkTextPickCurrent procedure
  ==== Contents of test case:

      foreach i {a b c d} {
  .t tag remove $i 1.0 end
      }
      event gen .t <Motion> -x $x1 -y $y1
      .t tag bind a <Leave> {.t tag add big 3.0 3.2}
      .t tag add a 2.1
      event gen .t <Motion> -x $x2 -y $y2
      .t index current

  ==== Result was:
  3.2
  ---- Result should have been:
  3.1
  ---- textTag-16.7 FAILED
  textWind.test
  tk.test
  unixButton.test
  unixEmbed.test
  unixFont.test

  ==== unixfont-2.10 TkpGetFontFromAttributes: scalable font found
  ==== Contents of test case:

      lindex [font actual {-family courier -size 37}] 3

  ==== Result was:
  17
  ---- Result should have been:
  37
  ---- unixfont-2.10 FAILED

  ==== unixfont-8.3 AllocFont procedure: can't parse info from name
  ==== Contents of test case:

      if [catch {set a [font actual a12biluc]}]==0 {
  string compare $a "-family a12biluc -size 0 -weight normal -slant roman -underline 0 -overstrike 0"
      } else {
  set a 0
      }

  ==== Result was:
  1
  ---- Result should have been:
  0
  ---- unixfont-8.3 FAILED
  unixMenu.test
  unixWm.test

  ==== unixWm-41.2 ConfigureEvent procedure, menubars
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 300 -height 200 -bd 2 -relief raised
      wm geom .t +0+0
      update
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      frame .t.m -bd 2 -relief raised -height 20
      testmenubar window .t .t.m
      update
      set result {}
      bind .t <Configure> {
  if {"%W" == ".t"} {
      lappend result "%W: %wx%h"
  }
      }
      bind .t.m <Configure> {lappend result "%W: %wx%h"}
      wm geometry .t 200x300
      update
      lappend result [expr [winfo rootx .t.m] - $x]  [expr [winfo rooty .t.m] - $y]  [winfo width .t.m] [winfo height .t.m]  [expr [winfo rootx .t] - $x] [expr [winfo rooty .t] - $y]  [winfo width .t] [winfo height .t]

  ==== Result was:
  {.t.m: 200x20} {.t: 200x300} -11 -31 200 20 -11 -11 200 300
  ---- Result should have been:
  {.t.m: 200x20} {.t: 200x300} 0 0 200 20 0 20 200 300
  ---- unixWm-41.2 FAILED

  ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a toplevel, x-coords
  ==== Contents of test case:

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

  ==== Result was:
  {} {} .t {} {} {} {} .t
  ---- Result should have been:
  {} {} .t {} .t2 .t2 {} .t
  ---- unixWm-50.1 FAILED
  util.test
  visual.test
  winButton.test
  winClipboard.test
  winFont.test
  winMenu.test
  winWm.test
  window.test
  winfo.test
  This application hasn't been compiled with the testwrapper command,
  therefore I am skipping all of these tests.



  the following were marked nonportable in 8.1, so they will be skipped unless the user specifies to run them.
  canvText-6.1
  grid-6.9
  menubutton-*
  scale-7.*
  textIndex-5.1
  unixWm-41.2

  the following were not acted upon:
    unixFont-*, unixWm-50.1: either a bug in window manager or nonPortable
    focus-5.1:  gets skipped if server is insecure in 8.1
    textTag-16.7: couldn't reproduce this (likely nonPortable)
  04/20/1999 13:44 - hershey -


tkt_uuid: 220163ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_BackgroundError API
comment:
  OriginalBugID: 1856 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: 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: 220165ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_DeleteFileHandler API
comment:
  OriginalBugID: 1859 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: 220166ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_EventuallyFree API
comment:
  OriginalBugID: 1860 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: 220167ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 26. Conversions from String
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_GetMMFromObj API
comment:
  OriginalBugID: 1864 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '2000-04-25'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: ericm
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '2000-04-25'


  .

  This function is already documented (man Tk_GetMMFromObj).

  - eric
   
  -- 04/25/2000 ericm


tkt_uuid: 220168ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_GetVRootGeometry API
comment:
  OriginalBugID: 1867 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:32 - kenj - Already documented in GetVRoot.3.


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




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


tkt_uuid: 220170ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 26. Conversions from String
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_NameOfCapStyle API
comment:
  OriginalBugID: 1877 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:22 - kenj - Already documented in GetCapStyl.3. What were you smoking, Bryan?


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: 220172ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 24. Relief
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_NameOfRelief API
comment:
  OriginalBugID: 1879 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 GetRelief.3. It's in there.


tkt_uuid: 220173ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_Preserve API
comment:
  OriginalBugID: 1881 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: 220174ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_Release API
comment:
  OriginalBugID: 1883 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: 220175ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_Sleep API
comment:
  OriginalBugID: 1885 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: 220176ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_TimerToken API
comment:
  OriginalBugID: 1886 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: 220177ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 26. Conversions from String
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_NameOfJustify API
comment:
  OriginalBugID: 1891 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-28'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: kenj
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-28'




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


tkt_uuid: 220178ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_CancelIdleCall API
comment:
  OriginalBugID: 1892 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: 220179ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_CreateFileHandler API
comment:
  OriginalBugID: 1893 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-28'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: kenj
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-28'




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


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




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


tkt_uuid: 220181ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Exit Window
comment:
  OriginalBugID: 1921 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-22'
  LastModified: '1999-08-08'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-08'


  Name:  Chang LI
  email:  changl@neatware.com
  Support:  None
  Severity:  2
  OperatingSystem:  Windows 95
  Synopsis:  Exit Window

  ReproducibleScript:
      Click the exit button on the title bar of Tk Window cause system error.
      It just exit the entire process. Suppose we have a main process, and it
      open a Tk window, when this Tk window exit, we require it only destroy
      its own window. But current Tk implementation kill the main process
      either.
      And you have to keep a Tk window in active. You can not destroy it. 
      This is not the case of Tk8.0. 
      
      The thread code of Tk8.1b3 may cause this clearnup problem althought I
      did
      not enable the thread. 
      

  ObservedBehavior:
      When you run wish81 there is another Tk window. When you click the exit
      button
      on the title bar of the Tk window, you should not kill the wish81
      console
      window itself. 
      

  Patch:
  Maybe you can use the DeleteWindowsExitProc(NULL) replaces the ExitProcess.
  Posted To comp.lang.tcl: Posted Successfully



  The behavior observed is correct.  Kiiling the '.' (main) toplevel
  window is synonymous with exit in wish in the main interpreter.
  If the user wants to catch this, they need:
    wm protocol . WM_DELETE_WINDOW <SaveMeProc> 
  -- 08/08/1999 hobbs


tkt_uuid: 220182ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: Repeated button pressing crashes application.
comment:
  OriginalBugID: 1925 Bug
  Version: 8.0p2
  SubmitDate: '1999-04-23'
  LastModified: '2000-01-21'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: 4.0 (SP 3)
  Machine: X86
  ClosedDate: '2000-01-21'


  Name: Sven Delmas

  ReproducibleScript:
  catch {destroy .b}
  button .b -command call
  pack .b
  bind Button <Key-a> [bind Button <Key-space>]

  proc call {} {
      .b config -text [clock format [clock clicks]]
      update
  }

  ObservedBehavior:
  Run the script and press (and hold the a key... I use a because space
      will automatically select OK in the core dump dialog). The program will
      crash with a stack overflow within 1 or 2 minutes.

  DesiredBehavior:
  It should not crash.

  I can't reproduce this, and neither can Sven.  My guess is that it was an issue with the particular system (badness in NT, perhaps).

  - eric

  -- 01/21/2000 ericm


tkt_uuid: 220183ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: I try to make a link on a menu
comment:
  OriginalBugID: 1942 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-27'
  LastModified: '1999-10-22'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-10-22'


  Name:
  JOYEUX Jean-François

  Extensions:
  none

  Comments:
  Perhaps my script is wrong..

  ReproducibleScript:
  menu .menubar
      . config -menu .menubar
      foreach m {Menu1 Menu2} {
         set .menubar.m$m [menu .menubar.m$m -tearoff 0 -background grey
      -foreground black]
         .menubar add cascade -label $m -menu .menubar.m$m
      }
      
      bind .menubar <ButtonPress> { puts stdout "Press" }

  ObservedBehavior:
  No behavior

  DesiredBehavior:
  I expect to see a bind on a menu



  Because the new menu system relies on native widgets, you are
  more restricted in you binding access to them.  The user
  probably wants to bind to the <<MenuSelect>> virtual event,
  created for this purpose. 
  -- 10/22/1999 hobbs


tkt_uuid: 220184ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: tk_getOpenFile command
comment:
  OriginalBugID: 1943 Bug
  Version: 8.0p2
  SubmitDate: '1999-04-27'
  LastModified: '1999-08-20'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: SunOS
  Machine: Sparc
  ClosedDate: '1999-08-20'


  Name:
  Teresa

  ReproducibleScript:
  We keep getting the error:
      
      bgerror failed to handle background error.
          Original error: cannot auto-load command "tkFDialog"
          Error in bgerror: invalid command name "bgerror"
      when we use the tk_getOpenFile command



  This appears to be a Tk installation problem.  Please ensure that
  Tk was fully installed and that it is version correct against the
  libraries you are using. 
  -- 08/20/1999 hobbs


tkt_uuid: 220185ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: Tk8.1 strongly unstable with --enable-thread
comment:
  OriginalBugID: 1974 Bug
  Version: 8.1
  SubmitDate: '1999-05-04'
  LastModified: '1999-08-14'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: 2.2.1
  Machine: Other
  ClosedDate: '1999-08-14'


  Name:
  Eric Hassold

  Comments:
  We admit this description is not precise enough to be very helpful for
      Tcl/Tk developpers. It shoud be considered more as a "user feedback"
      than a "bug report" (we might investigate more deeply in the coming
      days/weeks). The question is "should thread-safety" still be considered
      as Beta ? has anyone else experiment such problem (maybe on others
      platforms) ? or are they any special rules to respect when linking with
      multi-threads enabled Tcl/Tk libraires, even if our app. is not (yet)
      multi-threaded ?

  ReproducibleScript:
  Not reproductible (random hang)

  ObservedBehavior:
  our Tcl/Tk/C application (about 100.000 lines of C, 20.000 of Tcl),
      compiled with thread-enabled Tcl/Tk 8.1 Final, hangs frequently, and
      randomly (that is, several runs gives errors not at the same moment).
      When it occurs, all windows frozen, so no stack trace available. Our
      application is *NOT* multi-threaded, and doesn't modify or redefine any
      of the core Tcl/Tk routines. It works fine with 8.0.X, and with 8.1
      Final compiled *without* --enable-thread



  Tk should not currently be considered "thread-safe".  Thread-safety
  work was concentrated on Tcl as that is used in server envs without
  Tk.  Tk thread-safety should be OK on Windows with 8.2.0, and we
  are working on it more for Unix in the future (there are a lot of
  underlying issues with X thread-safety). 
  -- 08/14/1999 hobbs


tkt_uuid: 220186ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: Simple c/s script hangs wish on W98
comment:
  OriginalBugID: 1979 Bug
  Version: 8.1
  SubmitDate: '1999-05-04'
  LastModified: '1999-10-22'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  ClosedDate: '1999-10-22'


  Name:
  Christopher Nelson

  ReproducibleScript:
  # A very simple client and server in the same script
      proc genData { channel count } {
          puts $channel "$count foo bar baz"
          flush $channel
          incr count -1
          if { $count == 0 } {
              close $channel
              return
          } else {
              after 500 genData $channel $count
          }
      }
      # [fcopy] callback
      proc cleanup { channel doneName args } {
          close $channel
          set ::$doneName 1
      }
      # [socket -server] callback
      proc newClient { clientDoneName channel address port } {
          fcopy $channel stdout  -command [list cleanup $channel $clientDoneName]
      }
      # The server socket (creates new read socket).  Let the system pick the
      port
      set serverSocket [socket -server [list newClient clientDone] 0]
      # Get the port from the socket
      set sockname [fconfigure $serverSocket -sockname]
      set port [lindex $sockname 2]
      # The client (write) end of the socket
      set clientSocket [socket localhost $port]
      # Write some stuff on the write socket
      genData $clientSocket 10
      # Let the events run
      vwait clientDone
      # Close the server socket
      close $serverSocket

  ObservedBehavior:
  When sourced into tclsh, the script runs to completion and writes data
      pumped through the socket to stdout.  In wish, only the first line is
      displayed then the Console hangs.

  DesiredBehavior:
  tclsh and wish should behave the same way for non-graphical scripts.



  There is no std 'stdout' in wish, as on Windows it is not a
  console based app (for good reason).  The user is attempting
  to fcopy into stdout, which is effectively /dev/null.  This
  would have to be rewritten for use on Windows in Tk.  This
  can be chalked up to platform inconsistency. 
  -- 10/22/1999 hobbs


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


  Name:
  Luca

  Comments:
  Up to 8.0.5 everything was right

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

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



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


tkt_uuid: 220189ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: Problem with Right-Mouse-Click in listbox.
comment:
  OriginalBugID: 2015 Bug
  Version: 8.0p2
  SubmitDate: '1999-05-07'
  LastModified: '1999-08-08'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  ClosedDate: '1999-08-08'


  Name:
  Owen Chang

  Extensions:
  tcl, tk

  Comments:
  Here is part of the code:

      # Domain listbox
         label .add.list.domain.lab  -relief         {raised}  -borderwidth    {0}  -text           {Domains}

         scrollbar .add.list.domain.scrol1  -command ".add.list.domain.list yview"  -relief {raised} -width {12}

         listbox .add.list.domain.list  -borderwidth    {1}  -relief         {raised}  -yscrollcommand "add.list.domain.scrol1 set"  -selectborderwidth      {1} -selectmode     single

         pack append .add.list.domain  .add.list.domain.lab {top frame nw}  .add.list.domain.list {left expand fill frame w}  .add.list.domain.scrol1 {left filly frame e}

         bind .add.list.domain.list <ButtonPress-3> {
    if {[llength [.add.list.domain.list curselection]] <= 1} { 
      .add.list.domain.list.menu entryconfigure 1 -state normal 
      .add.list.domain.list select set [.add.list.domain.list index %y]
    }
    if {[llength [.add.list.domain.list curselection]] > 1} { 
      .add.list.domain.list.menu entryconfigure 1 -state disabled 
    } else {
      .add.list.domain.list.menu post %X %Y
    }
  }

  ReproducibleScript:
  I have been upgrading some code from Tcl/Tk 7 to Tcl/Tk 8. Here is my
  problem. A listbox contains a large list (50+ items). When I select any
  of the FIRST three items from the list, and do a right-click, it
  automaticly
  select another items somewhere in the list randomly, even I had made the
  list
  as single select mode. This only occur when the list contain 30+ items.
  If I do the same thing after the forth items on the list, it seems to be
  working fine.



  This appears to be a coding mistake.  The original code was
  messed up by the bug db input routines, so I had to reformat
  to what I thought was intended.  I believe the user should want
  "nearest %y" instead of "index %y". 
  -- 08/08/1999 hobbs


tkt_uuid: 220190ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: during uncompress of tar.Z file, 'broken pipe error'
comment:
  OriginalBugID: 2043 Bug
  Version: 8.1
  SubmitDate: '1999-05-10'
  LastModified: '1999-06-29'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: redman
  OS: HP-UX
  Machine: Other
  FixedInVersion: NA
  ClosedDate: '1999-06-29'


  Name:
  YekSoon... Lok

  ReproducibleScript:
  uncompress < file.tar.Z | tar xvf -

  ObservedBehavior:
  uncompress halfway then meet with broken pipe error

  DesiredBehavior:
  uncompress fully with tk8.1 direcotry created successffully



  Bad download. 
  -- 06/29/1999 redman


tkt_uuid: 220191ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 49. [grid]
priority: 1 Zero
foundin: None
resolution: Invalid
title: small gridder syntax enhancement
comment:
  OriginalBugID: 2049 RFE
  Version: 8.0p2
  SubmitDate: '1999-05-12'
  LastModified: '2000-01-05'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  OS: Other
  OSVersion: NetBSD-1.3.3/i386
  Machine: NA
  ClosedDate: '2000-01-05'


  Name:
  Hume Smith

  DesiredBehavior:
  it would be nice if columnconfigure and rowconfigure could each take
      several row/column indices...
      eg.  grid columnconfigure .buttongroup 0 1 2 3 -weight 1
      just as we can apply something to several slaves with
      grid configure .bg.open .bg.close .bg.delete -sticky ew
      then the gridder would be slightly more code-competitive with the packer
      - see
      http://www.glnx.com/~hclsmith/tcltk/pack-grid/ for examples.



  The grid command supports the use of a list of indices:

  grid columnconfigure .buttongroup {0 1 2 3} -weight 1

  This was true in 8.0p2 and is still true now in 8.3.

  - eric
  ericm@scriptics.com

   
  -- 01/05/2000 ericm


tkt_uuid: 220192ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: listbox browse mode allows multiple selectins
comment:
  OriginalBugID: 2086 Bug
  Version: 8.1
  SubmitDate: '1999-05-17'
  LastModified: '1999-08-08'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1358
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-08-08'


  Name:
  Christopher Nelson

  Comments:
  This is present in Tk 8.0 on UNIX, too.

  ReproducibleScript:
  # The select mode defaults to "browse" which is a one-at-a-time
      # mode but using selection set, it is possible to select more than one.
      listbox .lb -exportselection 0
      pack .lb -padx 3m -pady 3m
      puts ".lb's mode is [.lb cget -selectmode]"
      
      for {set i 0} {$i < 5} {incr i} {
          .lb insert end "item $i"
          .lb selection set $i
      }

  ObservedBehavior:
  All the items in the lsitbox are selected

  DesiredBehavior:
  Only the last one should be selected



  This is the intended behavior.  The listbox -selectmode is an
  option that the bindings use to interpret user interaction.  If
  the selection method is called by the programmer, then it can go
  against this behavior without problem. 
  -- 08/08/1999 hobbs


tkt_uuid: 220193ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 48. Geometry Management
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: Tcl/Tk spins
comment:
  OriginalBugID: 2109 Bug
  Version: 8.1
  SubmitDate: '1999-05-20'
  LastModified: '1999-06-29'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: redman
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-06-29'


  Name:
  Ralf Scheidhauer

  ReproducibleScript:
  toplevel .0
      frame .0.1  
      frame .0.1.2  
      pack .0.1
      pack .0.1.2
      button .0.1.3  
      grid .0.1.3

  ObservedBehavior:
  If you feed the script under 6) into wish (do not feed it line by line
      but load it as a whole from a file) then wish will hang and eat up all
      CPU 
      time. This happens both under Windows and Linux both with 8.0.5 and 8.1



  Correct behavior, don't mix layout managers in a single frame. 
  -- 06/29/1999 redman


tkt_uuid: 220194ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: Menus pop down in Windows
comment:
  OriginalBugID: 2112 Bug
  Version: 8.0.5
  SubmitDate: '1999-05-20'
  LastModified: '2000-02-25'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  ClosedDate: '2000-02-25'


  Name:
  Greg Orchard

  ReproducibleScript:
  To recreate this problem, start the [incr Widgets] demo and open the
      HTML help example (hyperhelp). Then click on a menu item on the inactive
      window.

  ObservedBehavior:
  If one Tk window is the active window and you click on a menu item of an
      inactive window, the menu item pops up but pops back down when you
      release the mouse button. The original active window becomes the active
      window.

  DesiredBehavior:
  The behaviour you get when a non-Tk window is active and you click on a
      menu item of a Tk window is for the Tk window to become active and for
      the menu to stay popped up. This is the desirable behaviour between Tk
      windows.



  This behavior is not reproducable with 8.2 (perhaps fixed?), based
  on the description. 
  -- 02/25/2000 hobbs


tkt_uuid: 220195ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Invalid
title: tk_getOpenFile ... -parent locks up parent window
comment:
  OriginalBugID: 2143 Bug
  Version: 8.1
  SubmitDate: '1999-06-03'
  LastModified: '1999-11-12'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  ClosedDate: '1999-11-12'


  Name:
  Peter Costello

  ReproducibleScript:
  if {$operation == "open"} {
      # Tcl/Tk 8.05 and 8.1 hangs up buttons and entry area in parent window
      # set file [tk_getOpenFile -filetypes $types -parent $w]
      set file [tk_getOpenFile -filetypes $types ]
          } else {
      set file [tk_getSaveFile -filetypes $types -parent $w  -initialfile Untitled -defaultextension .txt]
          }

  ObservedBehavior:
  If you use -parent as option to tk_getOpenFile the parent window is
      locked out
      from button pushes or text entry. Ifd you remove the -parent it works
      fine
      and like version 8.0

  DesiredBehavior:
  I expect to see the same behavior as 8.0 and have the parent window
      buttons and
      text entry areas active after the tk_getOpenFile is executed.



  This was actually a conscious behavior change, that the dialog
  has a local grab over the parent. 
  -- 11/12/1999 hobbs


tkt_uuid: 220196ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: HPUX - drag slides right!
comment:
  OriginalBugID: 2160 Bug
  Version: 8.0.5
  SubmitDate: '1999-06-03'
  LastModified: '2000-01-29'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: HPUX 10.20
  Machine: Other
  ClosedDate: '2000-01-29'


  Name:
  Graham

  CustomShell:
  prefix=/usr/local/99

  Comments:
  In tkined, I also have problems creating a new node on the screen.
      It simply isn't there (workd OK on Solaris-7)
      
      I also had to create the link to libX11:
      cd /usr/lib/X11R5; ln -s libX11.1 libX11.sl

  ReproducibleScript:
  Demo/Canvas/ArrowHead

  ObservedBehavior:
  After moving a point it is in the correct place,
      during the manipulation, the object slides right
      You move up/down/left, it moves right
      This also happens in tkined



  This seems to relate more to a Tk application (tkined), not the core.
  Testing the Canvas->Arrowhead demo on HP works correctly for me.  If
  there is more to this, then we need to get more info. 
  -- 01/29/2000 hobbs


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


  Name:
  Udo Flögel

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

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



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


tkt_uuid: 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: 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: 220200ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Performance in Tk poor
comment:
  OriginalBugID: 2260 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-21'
  LastModified: '2000-01-03'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4
  Machine: X86
  ClosedDate: '2000-01-03'


  Name: Dr. David Alan Gilbert

  Comments:
  I'd say this as between minor and serious - it does make Tk look quite
      poor; peoples initial reactions are 'that is because it is interpreted'
      - but that obviously isn't the case because it happens after the
      creation of the buttons because the window size appears immediatly.

  ReproducibleScript:
  for { set y 0 } { $y < 20 } { incr y } {
        for { set x 0 } { $x < 20 } { incr x } {
          button .b_${x}_${y} -text "0"
          grid .b_${x}_${y} -column $x -row $y
        }
      }

  ObservedBehavior:
  The time taken to render the window described in the script is
      significantly
      higher than I expect - OK so there are a lot of buttons and there in a
      grid - but:
        1) The window appears almost instantaneously - so it must have got the
      size done and organised the grid OK.
        2) On the machine on my desk at work (a P166 with a reasonable amount
      of RAM with Windows NT (and Linux)) I see the redraw taking quite a few
      seconds - and in particular you can see that the redraw process is at
      least two stage - you see individual rectangles being drawn where each
      button is and then see the buttons drawn on top.  The fact that it
      doesn't appear to be just taken up with the time taken to actually
      render the rectangle makes me wonder if there is another effect in here
      somewhere - perhaps something causing the OS to generate another
      redraw????

  DesiredBehavior:
  I wouldn't expect to see multiple stages of redraw and generally it
      would be faster.



  The assumption that a second redraw is likely accurate, probably
  scheduled by the reconfiguring of the size of the toplevel.  If
  you set the toplevel size to 500x700 initially, you only get the
  one redraw.  For the number of widgets being drawn, this is not
  so unexpected a speed.  In situations like these, it is better to
  withdraw the toplevel first, grid all the buttons in, then
  deiconify it.  Better yet, use something like tkTable if a 2D
  data sheet effect is what is desired in the first place. 
  -- 01/03/2000 hobbs


tkt_uuid: 220201ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: bad prototypes in tkIntXlibDecls.h
comment:
  OriginalBugID: 2264 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-21'
  LastModified: '1999-06-30'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: redman
  RelatedBugIDs: 2308
  OS: Macintosh
  OSVersion: 8.5.1
  Machine: Power PC
  FixedInVersion: 8.2b1
  ClosedDate: '1999-06-30'


  Name:
  Jonathan Guyer

  ReproducibleScript:
  Compiling Tk 8.1.1 for the Mac with CodeWarrior Pro 4 generates errors
      in :tk8.1.1:generic:tkIntXlibDecls.h

  ObservedBehavior:
  Error   : identifier 'a' redeclared
      tkIntXlibDecls.h line 390   (Display* d, Window w, Atom a, Atom a, int
      i1, int i2, const unsigned char* c, int i3)
      
      Error   : identifier 'a' redeclared
      tkIntXlibDecls.h line 731   (Display* d, Window w, Atom a, Atom a, int
      i1, int i2, const unsigned char* c, int i3)

  DesiredBehavior:
  Should be "Atom a1, Atom a2" or please provide the necessary compiler
      switches if it's possible to remove this error.



  see 2308 
  -- 06/30/1999 redman


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


  Name:
  Gary Bliesener

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

  ReproducibleScript:
  wish

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

  DesiredBehavior:
  Smiling happy engineers merrily creating with version 8.1.



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


tkt_uuid: 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: 220204ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Stippled lines crash NMGC display driver
comment:
  OriginalBugID: 2299 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-28'
  LastModified: '1999-09-16'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: 4.00.951
  Machine: X86
  ClosedDate: '1999-09-16'


  Name:
  John Nakulski

  Comments:
  I will submit this same bug report to Neomagic corporation.

  ReproducibleScript:
  Run wish (under Windows 95), then source the following program:
      # Program to demonstrate Tk "stippled lines crash NMGC display driver"
      bug
      #
      # The bug appears when you use ALL of the following together:
      # * many stippled lines in one canvas (10 to 100);
      # * using "update idletasks" often, in between drawing the lines;
      # * setting the Display control panel to the following mode
      #   (so far, only tried on a HP Omnibook 3000 laptop with Win95):
      #   * either 16-bit (16M colors) or 8-bit (256 colors) display mode;
      #   * full (3/3) or partial (2/3) hardware acceleration (Neomagic
      MagicGraph-128XD display driver)
      #
      set w 800
      set h 500
      set stipples {gray12 gray25 gray50 gray75}
      set stipCount [llength $stipples]
      canvas .c -width $w -height $h -bg white
      pack .c
      for {set i 0} {$i < 100} {incr i} {
        set x1 [expr {int(rand() * $w)}]
        set x2 [expr {int(rand() * $w)}]
        set y1 [expr {int(rand() * $h)}]
        set y2 [expr {int(rand() * $h)}]
        set stip [lindex $stipples [expr {int(rand() * $stipCount)}]]
        puts ".c create line $x1 $y1 $x2 $y2 -stipple $stip"
        flush stdout
        .c create line $x1 $y1 $x2 $y2 -stipple $stip
        update idletasks
      }

  ObservedBehavior:
  After several (10-50) lines have been drawn correctly, strange
      "artefacts" begin to appear on the PC screen (initially just on the Tk
      window, then everywhere). These "artefacts" are small rectangles
      containing random pixels... as if some process was writing incorrectly
      to display memory.
      Within a few seconds, everything comes to a halt, and NMGC.DRV crashes
      fatally.
      NMGC.DRV is the Neomagic MagicGraph-128XD hardware-accelerated display
      driver used in the HP Omnibook 3000 and many other laptop PCs.
      (NMGC.DRV version 4.03.00.4607-Q package 6.07 Aug 15 1997)
      Usually, the crash brings down the whole PC, and I need to reboot.
      The bug could be in the display driver.
      My work-around is to set the hardware acceleration level to 1/3 or OFF
      (using the Win95 Display control panel).

  DesiredBehavior:
  Display driver should not crash



  This appears to be a bug in the other product (the display driver).
  When the driver settings can avert this, they are doing some (bad)
  level of optimization.  This error is otherwise unknown to us. 
  -- 09/16/1999 hobbs


tkt_uuid: 220205ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: Text centering problem
comment:
  OriginalBugID: 2304 Bug
  Version: 8.0.3
  SubmitDate: '1999-06-28'
  LastModified: '1999-08-05'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  Machine: Other
  ClosedDate: '1999-08-05'


  Name:
  Eric Yeh

  ReproducibleScript:
  I create a canvas and do a create text.  The text is not multi-lined and
      so it won't center.  According to the man page, it clearly states that
      only multi-lined text will have an affect on the justify option.  Why
      not just have it center for single-line too??

  DesiredBehavior:
  Just like the old versions.  You do a -justify center and it centers no
      matter how many lines of text exist.



  This is a misunderstanding of the options.  The user needs to look
  at the -anchor switch.  This will allow you to center about the
  point you chose for the text to be placed at. 
  -- 08/05/1999 hobbs


tkt_uuid: 220206ffffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 99. Other
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: Patch for word-wrapping problem with 8-bit strings (and other related problems)
comment:
  OriginalBugID: 2305 Bug
  Version: 8.0.5
  SubmitDate: '1999-06-28'
  LastModified: '1999-08-05'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  FixedInVersion: 8.1
  ClosedDate: '1999-08-05'


  Name:
  Frédéric BONNET

  Comments:
  This bug shouldn't affect Tcl8.1.1 as it now uses UTF-8 and Unicode
      is-routines.

  ReproducibleScript:
  # Try it on Windows. Other platforms may need different pixel values
      # for the bug to occur.

      # Notice the accented e in the third word
      label .l -font "Arial 16" -wraplength 130  -text "azertyuiop azertyuiop azértyuiop"

      # After packing, notice how the 3rd word is incorrectly cut
      pack .l -expand 1 -fill both

  ObservedBehavior:
  This bug report and patch follows one that I posted on 06/24/1999. It
      corrects the word-wrapping bug as well as several potential problems
      with is-routines (eg. isspace) in the Tcl and Tk source.

  Patch:
  http://www.multimania.com/fbonnet/pub/isxx.patch

  PatchFiles:
  tcl8.0.5/compat/strtol.c
      tcl8.0.5/compat/strtod.c
      tcl8.0.5/compat/strtoul.c
      tcl8.0.5/generic/tclDate.c
      tcl8.0.5/win/tclAppInit.c
      tcl8.0.5/win/tclWinPipe.c
      tcl8.0.5/win/winDumpExts.c
      tk8.0.5/win/winMain.c
      tk8.0.5/win/tkWinFont.c



  Fixed in Unicode versions of Tk (8.1+).  There is no plan to patch
  8.0 beyond 8.0.5. 
  -- 08/05/1999 hobbs


tkt_uuid: 220210ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: Events passed down to incorrect windows
comment:
  OriginalBugID: 2312 Bug
  Version: 8.0.3
  SubmitDate: '1999-07-01'
  LastModified: '1999-08-12'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 1339 2111
  OS: Windows 95
  OSVersion: original version (not OSR2)
  Machine: X86
  ClosedDate: '1999-08-05'


  Name:
  James Bonfield

  Extensions:
  Tix

  CustomShell:
  No patches.

  ReproducibleScript:
  # Highlights a problem in bug in tk on windows.
      #
      # 1. Bring up the main window and then press A.
      # 2. Make sure that the file dialogue covers the wish root window
      # 3. Double click on a file in the file dialogue
      #
      # Tk then reports (assuming interactive wish) "B1 event at x,y". Why
      does
      # this event get propagated down to this window?
      
      #tkinit
      
      wm geometry . 500x500
      label .l -textvariable .l.Var
      pack .l -side top
      bind . <1> {puts "B1 event at %x,%y"}
      bind . <KeyPress-a> {
          set .l.Var [tk_getOpenFile]
      }

  ObservedBehavior:
  By double clicking to select a file from a MS Windows file dialogue (it
      works fine on Unix), the tk_getOpenFile returns the filename as
      expected. However a button-1 event is passed down to whatever window was
      underneath the now-closed file dialogue.
      
      In some of our applications this can cause problems, although generally
      it's just an annoyance.

  DesiredBehavior:
  No B1 event in the root window of this demo.



  This was answered here:
     http://x23.deja.com/[ST_rn=ps]/getdoc.xp?AN=496001244

  This is more of a Windows native dialog problem, but requires
  that the Tk user be aware of the quirk with that dialog. 
  -- 08/05/1999 hobbs


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


  Name:
  Ed Knapen

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

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

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



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


tkt_uuid: 220212ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: Want to have a feature similar to tk_getopenfile
comment:
  OriginalBugID: 2351 RFE
  Version: 8.1
  SubmitDate: '1999-07-16'
  LastModified: '1999-11-16'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: I'm using tcl/tk built in with Modelsim 5.2
  Machine: X86
  ClosedDate: '1999-11-16'


  Name:
  Mujtaba Hamid

  DesiredBehavior:
  Is there a command which will allow me to select a directory, like
      tk_selectdirectory which i can then connect to a "browse and select
      directory" button? 
      Thanks!



  tk_chooseDirectory is availalbe on Windows. 
  -- 11/16/1999 hobbs


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


  Name:Q. Alex Zhao

  Extensions:Img 1.2

  CustomShell:the Img 1.2 patches

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



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


tkt_uuid: 220214ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: we occassionally get a tk internal error which freezes the script and users have to restart
comment:
  OriginalBugID: 2373 Bug
  Version: 8.0.3
  SubmitDate: '1999-07-16'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedInVersion: 8.2
  ClosedDate: '1999-08-20'


  Name:
  danny chen

  Extensions:
  none

  CustomShell:
  using prowish80

  ObservedBehavior:
  users occassionally get the following error message:
      
      Error: Can't read "tkprv(relief)": no such element in array
      
      after getting this message, our the script freezes and the users have to
      restart.  this is not one of our variables so it must be a tk internal
      variable.  i looked in the tk libraries and can't find any mention of
      it.
      can you tell us when/why this would happen?



  tkprv would have to come from some other code.  There is a tkPriv
  array that is used.  Some problems have been noted over time with
  various aspects of this, but all known ones have been fixed. 
  -- 08/20/1999 hobbs


tkt_uuid: 220215ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Stub Entries
priority: 1 Zero
foundin: None
resolution: Invalid
title: Please export 'TkGetDefaultScreenName' in Stub table
comment:
  OriginalBugID: 2387 RFE
  Version: 8.2b1
  SubmitDate: '1999-07-19'
  LastModified: '1999-08-01'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-01'


  Name:
  vince darley

  DesiredBehavior:
  The above function is required by the Plplot extension, and if it isn't
      in the stub table, that extension cannot be made stub-aware.
      
      (FYI: See http://www.santafe.edu/~vince/Pltk.html for info on Plplot
      extension)



  This function is already in the stubs... 
  -- 08/01/1999 hobbs


tkt_uuid: 220216ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: Tk_ItemType and OLD_CONFIG
comment:
  OriginalBugID: 2423 Bug
  Version: 8.1
  SubmitDate: '1999-07-20'
  LastModified: '2000-02-07'
  Severity: SER
  Status: Closed
  Submitter: jenn
  ChangedBy: hobbs
  OS: Linux
  OSVersion: Red Hat 5.0+ on Intel
  ClosedDate: '2000-02-07'


  Name:  Spiros Boucouris

  CustomShell:  No changes to core.  Locally compiled
  source release from Scriptics.


  ObservedBehavior:
      
      In tk.h, Tk_ItemType is conditionaly compiled under #ifndef
      __NO_OLD_CONFIG
      
      I cannot find anything that looks like a replacement.  The code that
      handles
      the configuration of Tk_Item(s) is marked as deprecated.  There are
      subtle
      differences to the behaviour of the custom item configuration that
      require changes on our code.  We cannot make these until the fate of
      custom Tk_Item(s)
      has been cleared.
      

  DesiredBehavior:
      
      It appears that 8.1 moved to the new Tk_Option for widgets and orphaned
      the
      canvas items.  We depend on custom canvas items, so we would like to see
      a consistent (old or new does not matter so much) API.  The present
      release looks like it was changed by someone who had no idea that canvas
      items existed
      (not very reassuring).
      

  Comments:
      
      Even the built-in canvas items now call the "deprecated, included only
      for backward compatibility" routines for handling configureSpec(s).
      Please ensure that side effects of changes are dealt with, especially in
      final releases.
      


  The user needs to elaborate more specifically on what they were
  attempting, what they wanted, and how it didn't work.  There are
  several extensions that create custom canvas item types in Tk 8.1+
  (BLT and Snack most notably), using a well-documented mechanism. 
  -- 02/07/2000 hobbs


tkt_uuid: 220217ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: obsolete: 8.0
resolution: Invalid
title: tk_DestroyWindow when called from a command results in crash
comment:
  OriginalBugID: 2464 Bug
  Version: 8.0
  SubmitDate: '1999-07-28'
  LastModified: '2000-01-07'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  ClosedDate: '2000-01-07'


  Name:
  Seema

  CustomShell:
  Yes

  ReproducibleScript:
  Environment: windows 95 and win NT
                            Tcl 7.6 Tk 4.2
      Application coded in VC 5.0
      From within the code I'm calling Tcl_CreateInterp to create interpreter.
      Also I'm creating some commands using "Tcl_CreateCommand".
      
      Problem : 
      I have written a command by name "exit"which finds the tk window and
      destroys it
      -----------code for
      command-------------------------------------------------------
      Tk_Window tkwin = Tk_MainWindow ( interp );
      if( tkwin ) Tk_DestroyWindow ( tkwin );   // CRASH POINT
      return TCL_OK;
      -------------------------------------------------------------------------
      ----------------------
      
      If I write a tcl script as :
      -------------------------------------------------------------------------
      ----------------------
      tk_messageBox -message "hello"
      exit
      -------------------------------------------------------------------------
      ----------------------
      
      My application crashes while executing exit command.The crash occurs 
      only for this combination of commands.
      The crash occurs while executing "Tk_DestroyWindow " command.
      Tk throws some exception while executing this command , I'm not able to 
      identify the cause of exception. My application crashes after this.
      If I execute a script with some other set of commands followed by "exit"
      
      command (that I implemented) , there is no problem and run goes smooth.
      It is only for consequent execution of tk_messageBox" and "exit" command
      that the crash occurs.After the exception occurs even interp->Result is
      empty 
      and I can't trace back any reason for the crash.

  DesiredBehavior:
  I would like to know the reason for this behaviour.
      Also if you could suggest some recovery mechanism.



  Note the version is 4.2.  That version is many years old, and
  we don't work on it anymore. 
  -- 01/07/2000 hobbs


tkt_uuid: 220218ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 1 Zero
foundin: obsolete: 8.2b1
resolution: Invalid
title: bind cannot distinguish between some keys
comment:
  OriginalBugID: 2487 Bug
  Version: 8.2b1
  SubmitDate: '1999-08-03'
  LastModified: '2000-04-14'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 870
  OS: Windows NT
  OSVersion: All Windows versions
  Machine: X86
  ClosedDate: '2000-04-14'


  Name:
  Ingemar Hansson

  ReproducibleScript:
  bind all <KeyPress> {puts "%K %N"}

  ObservedBehavior:
  Pressing both left and right Ctrl keys results in "Control_L 65507"
      Pressing both left and right Shift keys results in "Shift_L 65505"
      Pressing figure keys (0-9) on keys above letters or on the pad to the
      right results in same figure showed. (E.g. "1 49")
      Plus some more.

  DesiredBehavior:
  Pressing the right Ctrl key should of course result in Control_R and a
      different keysym number. There should also be different keysym numbers
      for the figure keys above the letter keys and the right keypad.



  The first of these (left vs. right keys) was fixed with #870.

  I am unable to reproduce the second problem on NT with 8.2 or 8.3.

  - eric
   
  -- 04/14/2000 ericm


tkt_uuid: 220219ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Try to compile expect-5.28 with tcl/tk8.1.1 on Sun SparcStation Solaris 2.2.x with failure.
comment:
  OriginalBugID: 2497 Bug
  Version: 8.1.1
  SubmitDate: '1999-08-04'
  LastModified: '1999-08-04'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: foster
  OS: Solaris
  Machine: Other
  ClosedDate: '1999-08-04'


  Name:
  Yi Luo



  (Per Scott R. reply to originator on 8/4/99)

  Expect 5.28 does not support Tcl/Tk 8.1.

  Instead, you need Expect 5.31 and Tcl/Tk 8.2b1+.  There were
  changes required to both Expect and Tcl/Tk in order to get
  the two to work properly.  You can download Tcl/Tk 8.2b1 from
  our website and get Expect from our CVS repository.

  http://www.scriptics.com
   
  -- 08/04/1999 foster


tkt_uuid: 220220ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: Menus are detached from their parents
comment:
  OriginalBugID: 2509 Bug
  Version: 8.0.3
  SubmitDate: '1999-08-05'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.5
  Machine: Other
  ClosedDate: '1999-08-20'


  Name:
  Steve Duncan

  CustomShell:
  No mods or redefined commands, as far as I am aware.

  Comments:
  The changes file suggests that this is a bug which has been fixed before
      in Tk.  I would guess that it has been reanimated by the menubar changes
      in 8.0.

  ReproducibleScript:
  Can't currently reproduce except in our application (which is large).

  ObservedBehavior:
  This is how it happens:
      
      1. I select a menu option in a launcher appliction that launches a new
      application with its own toplevel window.
      2. While waiting for the new app to initialise, I click on a menu item
      in the launcher toplevel window and hold the mouse button down.  The
      launcher window is inactive at this time so the menu is not posted.
      3. I release the mouse button once the new toplevel window has been
      mapped. The launcher window no longer has the focus, but releasing the
      mouse button causes the menu to pop up.
      4. This is the nasty part:  The menu is no longer bound to the menubar.
      It stays where it was first posted on the display

  DesiredBehavior:
  I don't expect the menu to pop up when the mouse button is released in
      the first place. I certainly don't expect the menu to come unstuck from
      the menu bar.



  This can be classified as 'quirk', and is not exclusive to Tk.
  I am fairly certain what is happening here is that the process
  is busy launching the new toplevel, but X has queued the event
  for you wanting to post a menu.  You will have moved off the
  launcher before Tk gets around to processing the message it
  received from X, but it will process it.

  You can get this menu to go away by rerequesting a menu popup.
  You may be able to avoid the problem entirely by rearchitecting
  to add a few update idles in the toplevel launching code, or
  exec it as a process in the background. 
  -- 08/20/1999 hobbs


tkt_uuid: 220221ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Menu bars and widgets will not activate when window is not active
comment:
  OriginalBugID: 2571 Bug
  Version: 8.1.1
  SubmitDate: '1999-08-18'
  LastModified: '1999-08-20'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  ClosedDate: '1999-08-20'


  Name:
  Kriston J. Rehberg

  Comments:
  I believe this happens with most other widgets on the canvas -- the user
  must first click into the window to make it active... the problem is
  that this click should also activate the widget or pull-down menu
  underneath the pointer, but it does not.
      
  This problem has been around since Tk 4.2 if I recall correctly.  I
  don't think X Windows users would see it since most window managers'
  default behavior is to activate a window under the mouse pointer, making
  this problem hard to duplicate except on MS Windows or in a Unix window
  manager with ClickToFocus turned on.

  ReproducibleScript:
  In the Widget Tour, choose Menus and Cascades.  Try to click one of the
  pull-down menus while the window is not in focus (on Windows, it usually
  isn't in focus).  Nothing will happen unless you click a second time to
  make the window active -- only then will the pull-down menus work.  This
  also happens with the "Dismiss" button and other widgets on the canvas.

  ObservedBehavior:
  The pull-down menu won't activate without clicking a second time.  This
  is unlike any other Windows applicationn which takes the click to
  activate the window as well as an event to click on a pull-down menu or
  widget.

  DesiredBehavior:
  One click should activate the pull-down menu or widget.



  I'm not sure that this is a valid bug.  If you compare the behavior
  of the Tk widget tour with that of Outlook (Outlook 2000 on NT),
  you get pretty much the same behavior.  If Outlook is not the active
  window, and you click into the menus of Outlook, you must click again
  to get the menus to activate.  However, if you aren't clicking into
  the menus but rather into a button (like "Inbox" in the left bar),
  then that will be processed without the need of a second click.

  Tk is the same, menus need the second click, buttons and actions
  for the rest of the interface do not. 
  -- 08/20/1999 hobbs


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: 220223ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Invalid
title: not enough event handling in tk widgets
comment:
  OriginalBugID: 2574 RFE
  Version: 8.1
  SubmitDate: '1999-08-18'
  LastModified: '1999-08-19'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: 6.0
  Machine: Other
  ClosedDate: '1999-08-19'


  Name:
  Jeff Chan

  Extensions:
  tk

  DesiredBehavior:
  I would like the ability to have more control over tk widgets for
      the purposes of the plugin in netscape especially (unix/win/mac).
      I need to validate data onfocus, onblur, onenter, onthis, onthat
      etc.  I also need to be able to enter nonmutable data into a 
      text field say (  )  -   for phone and also define maxlength.
      this is very important to our applications. How can we achieve this
      functionality and when do you plan on providing it?



  This functionality is already available in some way.  The full range
  of events (FocusIn, FocusOut, Enter, Leave, ...) is defined under
  the 'bind' man page.  The ability to validate data in an entry
  widget can be found in the Tk Usage FAQ:
      http://www.purl.org/net/hobbs/tcl/faqs/tk/

  We are also looking to make some of that support native, but the
  ability is already there. 
  -- 08/19/1999 hobbs


tkt_uuid: 220224ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: final: 8.1.1
resolution: Remind
title: Incorrect SHLIB_LD for SunOS4 & gcc
comment:
  OriginalBugID: 2576 Bug
  Version: 8.1.1
  SubmitDate: '1999-08-18'
  LastModified: '2000-04-14'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: SunOS
  Machine: Sparc
  ClosedDate: '2000-04-14'


  Name:
  David Wilson

  ReproducibleScript:
  When building on Tk 8.1.1. on SunOS 4 using gcc 2.7.2 (having specified
      --enable-gcc --enable-shared to configure) the tk shared library failed
      to
      build with unresolved symbols. This is probably because SHLIB_LD was set
      to
      'ld', while it should be gcc -shared when using gcc (and probably ld -G
      when
      using other compilers on a number of platforms).

  ObservedBehavior:
  Does not build

  DesiredBehavior:
  The Makefile created by configure should set the correct options.



  We need a specific patch that is known to work correctly for
  the SunOS env, as we have no access to one and don't want to
  potentially break a build. 
  -- 04/14/2000 hobbs


tkt_uuid: 220225ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: Charatcers bolded for RPS on Macintosh
comment:
  OriginalBugID: 2593 Bug
  Version: 8.2
  SubmitDate: '1999-08-20'
  LastModified: '1999-08-27'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: 8.6, PPC
  Machine: Power PC
  ClosedDate: '1999-08-27'


  Name:
  Thomas Stanley

  Extensions:
  none

  Comments:
  I can send you a picture of what is happening!

  ReproducibleScript:
  after entering the wish shell, I perform an ls (list) command, but the
      program 
      echo's lS.  When I change directories and perform an ls, all files that
      contain 
      r, p or s, have those letters bolded and uppercas

  ObservedBehavior:
  evertime a file has an r, p or s in its name it's bolded and uppercased
      in a 
      different font

  DesiredBehavior:
  The files should only have shown lower case characters and unbolded.  I
      don't 
      think I can trust 8.2 at this time



  This appears to be an unreproducable error for other Mac users on
  the newsgroup (other reports were all OK).  Perhaps the 'ls' command
  being issued is doing something crazy?? 
  -- 08/24/1999 hobbs
  Apparently this is confirmed by Jim Ingham, but not by others on
  the newsgroup.  This needs to be examined further. 
  -- 08/25/1999 hobbs
  From Jim Ingham:

  This was a bad font.  Thomas found the font (Stencil,
  if you care), and when he removes it, everything works as expected.
  He sent me a copy of the font, and I will poke around and see if I can
  figure out why it was fooling Tk into using it instead of the regular
  system font.
   
  -- 08/27/1999 hobbs


tkt_uuid: 220226ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: [entry]'s -disabledforeground doesn't work
comment:
  OriginalBugID: 2632 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-08-31'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  ClosedDate: '1999-08-31'


  Name:
  keith lea

  ObservedBehavior:
  entries' foreground color doesn't change when they are disabled and have
      a different -disabledforeground color

  DesiredBehavior:
  the foreground color of the entry should change



  entry widgets don't have a -disabledforeground option... 
  -- 08/31/1999 hobbs


tkt_uuid: 220227ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: Wish crashes no matter what I do
comment:
  OriginalBugID: 2633 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-08-31'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: Mac OS 8.6
  Machine: Power PC
  ClosedDate: '1999-08-31'


  Name:
  Bernhard Spinnler

  Extensions:
  8.2.0

  CustomShell:
  No

  ReproducibleScript:
  I downloaded Tcl/Tk 8.2.0 for Macintosh (URL:
      <http://www.scriptics.com/products/tcltk/download_file.tml?file=mac%2fMac
      Tk8%2e2%2eFinal%2ePPC%2esea%2ehqx&email=%40skip>. The downloaded file
      can be extracted but I do not get a REDME file as the description on the
      web page
      <http://www.scriptics.com/products/tcltk/downloadnow82.html?email=%40skip
      > says. 
      The only items are 'Simple Tcl (sh-ppc)', 'Simple Tk (sh-ppc)', and the
      'Tool Command Language' folder. When I copy the 'Tool Command Language'
      folder into my Extensions folder and try to use wish (Simple Tk
      (sh-ppc)), it crashes after two or three commands (no matter what
      commands).

  ObservedBehavior:
  Wish crashes with system error 2!



  Helpful note from Jim Ingham:
  START
  ...this was really a bug in

  file join /foo bar

  Or rather, it was really a bug in the regexp package.  It is solved
  temporarily by increasing the stack allocation for MacTk, which I will 
  do for the 8.2 release if we ever get an installer license from
  Stuffit.  Over the longer term, it will be solved

  a) By Henry Spencer reducing the HUMONGOUS stack requirements of the
  regexp code
  b) By tuning up the regexp's that file join uses to detect path type.
  END
   
  -- 08/31/1999 hobbs


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


  Name:
  James Garrison

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

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

  ObservedBehavior:
  the interperter crashes

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



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


tkt_uuid: 220229ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Invalid
title: WinNT Dr Watson when using WM_DELETE_WINDOW
comment:
  OriginalBugID: 2640 Bug
  Version: 1.3
  SubmitDate: '1999-08-31'
  LastModified: '1999-11-16'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT 4.0 SP4
  Machine: X86
  ClosedDate: '1999-11-16'


  Name:

  Raultk Segura Acevedo



  Comments:

  under my NT it does NOT crash if I pass "My_Exit"'s body as an argument

      to "wm protocol . WM_DELETE_WINDOW...", but it does under win95.

      it doesn't crash if I remove the line "if {$modificado..." nor with a

      shorter "set out [tk_messageBox..." command



  ReproducibleScript:

  run the following script and close it pressing Alt-F4 or clicking the

      button x

      

      set modificado 0

      wm protocol . WM_DELETE_WINDOW "My_Exit"

      

      proc My_Exit {} {

        global modificado

      

        if {$modificado == 0} {destroy .}

        set out [tk_messageBox -type yesnocancel -title "Confirmacion"

      -message \

          "El archivo no ha sido guardado.\nGuardar el archivo antes de

      salir?"]

        destroy .

      }



  ObservedBehavior:

  prowish82 crashes under windows, I get a Dr. Watson window and a memory

      dump on NT and a message error on Win95



  DesiredBehavior:

  a clean program termination





  Not verifiable on NT or 98 with 8.2.1, or NT with prowish82
  (Tcl 8.2.0). 
  -- 11/16/1999 hobbs


tkt_uuid: 220230ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: XIO: fatal IO error 0 on X server
comment:
  OriginalBugID: 2641 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-08-31'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: Linux 2.2.6 - slackware 4.0
  Machine: Other
  ClosedDate: '1999-08-31'


  Name:
  Aadt A.Jansen

  Extensions:
  tcl 8.2 tk 8.2

  ReproducibleScript:
  make test dies with
      XIO:  fatal IO error 0 (Success) on X server ":0.0"
            after 36 requests (34 known processed) with 1 events remaining
      
      No such behaviour with release 8.1.1



  This looks like a problem in connecting to the X server, not in
  Tk itself. 
  -- 08/31/1999 hobbs


tkt_uuid: 220231ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: TK Build failes on Solaris X86 5.7
comment:
  OriginalBugID: 2651 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '2000-02-07'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3905
  OS: Solaris
  OSVersion: X86 5.7
  Machine: Other
  ClosedDate: '2000-02-07'


  Name:
  Jay J. Rohr

  ReproducibleScript:
  ./configure --enable-gcc --enable-shared
      make

  ObservedBehavior:
  #./configure --enable-gcc --enable-shared
      creating cache ./config.cache
      checking for ranlib... ranlib
      checking for gcc... gcc
      checking whether the C compiler (gcc  ) works... yes
      checking whether the C compiler (gcc  ) is a cross-compiler... no
      checking whether we are using GNU C... yes
      checking whether gcc accepts -g... yes
      checking for gcc... (cached) gcc
      checking whether the C compiler (gcc -g -O2 ) works... yes
      checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no
      checking whether we are using GNU C... (cached) yes
      checking whether gcc accepts -g... (cached) yes
      checking how to run the C preprocessor... gcc -E
      checking for unistd.h... yes
      checking for limits.h... yes
      checking for building with threads... no (default)
      checking if the compiler understands -pipe... no
      checking for Tcl configuration... found
      /usr5/local/src/tcl8.2.0/unix/tclConfig.sh
      checking for existence of /usr5/local/src/tcl8.2.0/unix/tclConfig.sh...
      loading
      checking if 64bit support is enabled... no
      checking system version (for dynamic loading)... SunOS-5.7
      checking for dlopen in -ldl... yes
      checking for build with symbols... no
      checking for sin... no
      checking for main in -lieee... no
      checking stdlib.h... yes
      checking fd_set and sys/select... yes
      checking for ANSI C header files... yes
      checking for mode_t... yes
      checking for pid_t... yes
      checking for size_t... yes
      checking for uid_t in sys/types.h... yes
      checking for sys/time.h... yes
      checking whether time.h and sys/time.h may both be included... yes
      checking pw_gecos in struct pwd... yes
      checking for X... libraries /usr/openwin/lib, headers
      /usr/openwin/include
      checking for main in -lXbsd... no
      checking for connect... no
      checking for main in -lsocket... yes
      checking for gethostbyname... no
      checking for main in -lnsl... yes
      checking for sin... (cached) no
      checking for main in -lieee... (cached) no
      checking whether char is unsigned... no
      checking for strtod... yes
      checking for Solaris 2.4 strtod bug... ok
      checking how to build libraries... shared
      updating cache ./config.cache
      creating ./config.status
      creating Makefile
      creating tkConfig.sh
      
      #make
      ....
      
      /usr/ccs/bin/ld -G -z text -o libtk8.2.so tk3d.o tkArgv.o tkAtom.o
      tkBind.o tkBitmap.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o
      tkConsole.o tkCursor.o tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o
      tkGC.o tkGeometry.o tkGrab.o tkGrid.o tkMain.o tkObj.o tkOldConfig.o
      tkOption.o tkPack.o tkPlace.o tkSelect.o tkUtil.o tkVisual.o tkWindow.o
      tkUnix.o tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o
      tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o
      tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o tkUnixMenubu.o
      tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o
      tkUnixXId.o tkStubInit.o tkStubLib.o tkButton.o tkEntry.o tkFrame.o
      tkListbox.o tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o tkScale.o
      tkScrollbar.o tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o
      tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o tkCanvUtil.o
      tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o tkImgGIF.o
      tkImgPPM.o tkImgPhoto.o tkText.o tkTextBTree.o tk!
      TextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o
      tkTextWind.o -R /usr/local/lib:/usr/openwin/lib
      -L/usr5/local/src/tcl8.2.0/unix  -lsocket -lnsl -L/usr/openwin/lib -lX11
      -ldl -lm -lc
      Text relocation remains                         referenced
          against symbol                  offset      in file
      __ctype                             0x1cc       tkGet.o
      __ctype                             0x1e8       tkGet.o
      __ctype                             0x2a04      tkCanvPs.o
      ld: fatal: relocations remain against allocatable but non-writable
      sections

  DesiredBehavior:
  Correct build



  I believe this has to do with the extra '-z text' flag that
  is used.  This is correct for Solaris Sparc, but not Sol x86. 
  -- 10/21/1999 hobbs
  On a freshly setup Solaris5.7 x86 machine with gcc 2.95.2, both
  8.2.3 and 8.3b2 build and test OK.  This also has the -z text
  option specified.  Perhaps the newer gcc fixed this? 
  -- 02/07/2000 hobbs


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


  Name:
  Q. Alex Zhao

  Extensions:
  none

  CustomShell:
  none

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

  ObservedBehavior:
  Nothing happens.

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



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


tkt_uuid: 220233ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: None
resolution: Invalid
title: tktext widget insertion cursor looks bad when very wide
comment:
  OriginalBugID: 2712 Bug
  Version: 8.2
  SubmitDate: '1999-09-10'
  LastModified: '1999-09-10'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0sp5
  Machine: X86
  ClosedDate: '1999-09-10'


  Name:

  Vince Darley


  Comments:

  The above patch leaves the behaviour unmodified for narrow cursors (0-2

      pixels),

      and for larger widths makes the flashing insertion cursor extend to the

      right only.  It has no other effect.


  ReproducibleScript:

  text .t -font "Monaco 20" -insertwidth 20 -insertbackground red

      pack .t

      .t insert 1.0 "Here's some text to test out the large\

        cursor on.  It floats peculiarly half over two different\

        characters.  Most text editors, if you switch a 'block cursor'\

        on, will highlight the character just after the insertion point."


  ObservedBehavior:

  A wide insertion cursor (the same width as the current font, for

      instance), looks bad.


  DesiredBehavior:

  I think it would be better to make a wide flashing

      cursor extend to the right of the default position only, so that

      a wide insertion cursor will cover a single character, not half of 

      two different characters.


  Patch:

  diff -C 3 -X tktext-ignore -I *Copyright* tk8.2orig/generic/tkText.c tk8.2/generic/tkText.c

  *** tk8.2orig/generic/tkText.cSun Sep 05 15:11:10 1999

  --- tk8.2/generic/tkText.cSun Sep 05 15:21:13 1999

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

  *** 1515,1522 ****

        }

        TkTextMarkSegToIndex(textPtr, textPtr->insertMarkPtr, &index);

        TkTextCharBbox(textPtr, &index, &x, &y, &w, &h);

  !     TkTextRedrawRegion(textPtr, x - textPtr->insertWidth / 2, y,

  !     textPtr->insertWidth, h);

    }

    

    /*

  --- 1515,1527 ----

        }

        TkTextMarkSegToIndex(textPtr, textPtr->insertMarkPtr, &index);

        TkTextCharBbox(textPtr, &index, &x, &y, &w, &h);

  !     if (textPtr->insertWidth > 2) {

  ! TkTextRedrawRegion(textPtr, x - 1, y,

  ! textPtr->insertWidth, h);

  !     } else {

  ! TkTextRedrawRegion(textPtr, x - textPtr->insertWidth / 2, y,

  ! textPtr->insertWidth, h);

  !     }

    }

    

    /*

  diff -C 3 -X tktext-ignore -I *Copyright* tk8.2orig/generic/tkTextMark.c tk8.2/generic/tkTextMark.c

  *** tk8.2orig/generic/tkTextMark.cThu Apr 15 19:51:24 1999

  --- tk8.2/generic/tkTextMark.cSun Sep 05 15:28:39 1999

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

  *** 522,530 ****

     * corresponds to y. */

    {

        TkText *textPtr = (TkText *) chunkPtr->clientData;

  !     int halfWidth = textPtr->insertWidth/2;


  !     if ((x + halfWidth) < 0) {

    /*

     * The insertion cursor is off-screen.  Just return.

     */

  --- 522,530 ----

     * corresponds to y. */

    {

        TkText *textPtr = (TkText *) chunkPtr->clientData;

  !     int leftSideWidth = (textPtr->insertWidth > 2 ? 1 : textPtr->insertWidth/2);


  !     if ((x + textPtr->insertWidth - leftSideWidth) < 0) {

    /*

     * The insertion cursor is off-screen.  Just return.

     */

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

  *** 542,552 ****


        if (textPtr->flags & INSERT_ON) {

    Tk_Fill3DRectangle(textPtr->tkwin, dst, textPtr->insertBorder,

  ! x - textPtr->insertWidth/2, y, textPtr->insertWidth,

    height, textPtr->insertBorderWidth, TK_RELIEF_RAISED);

        } else if (textPtr->selBorder == textPtr->insertBorder) {

    Tk_Fill3DRectangle(textPtr->tkwin, dst, textPtr->border,

  ! x - textPtr->insertWidth/2, y, textPtr->insertWidth,

    height, 0, TK_RELIEF_FLAT);

        }

    }

  --- 542,552 ----


        if (textPtr->flags & INSERT_ON) {

    Tk_Fill3DRectangle(textPtr->tkwin, dst, textPtr->insertBorder,

  ! x - leftSideWidth, y, textPtr->insertWidth,

    height, textPtr->insertBorderWidth, TK_RELIEF_RAISED);

        } else if (textPtr->selBorder == textPtr->insertBorder) {

    Tk_Fill3DRectangle(textPtr->tkwin, dst, textPtr->border,

  ! x - leftSideWidth, y, textPtr->insertWidth,

    height, 0, TK_RELIEF_FLAT);

        }

    }


  PatchFiles:

  tkText.c

      tkTextMark.c




  The text widget cursor is only designed as an 'insertion' cursor,
  and not as a block cursor.  That would require a different style
  of drawing (instead of a filled rect, it would have to be unfilled
  over the boundary of a char). 
  -- 09/10/1999 hobbs


tkt_uuid: 220234ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: Subscript out of range in tkImg*.c
comment:
  OriginalBugID: 2724 Bug
  Version: 8.2
  SubmitDate: '1999-09-10'
  LastModified: '1999-09-10'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: IRIX
  OSVersion: IRIX 6.5
  Machine: Other
  ClosedDate: '1999-09-10'


  Name:
  Rob Ratcliff

  Extensions:
  Tix, Sox, incrTk

  ReproducibleScript:
  It appears that the dimension of the structure member "offset" isn't
      large enough
      in the file tk.h
      
      Excerpt from file tk.h
         941  /*
         942   * The following structure describes a block of pixels in
      memory:
         943   */
                 
         944  typedef struct Tk_PhotoImageBlock {
         945      unsigned char *pixelPtr;    /* Pointer to the first pixel.
      */
         946      int     width;      /* Width of block, in pixels. */
         947      int     height;     /* Height of block, in pixels. */
         948      int     pitch;      /* Address difference between
      corresponding
         949                   * pixels in successive lines. */
         950      int     pixelSize;  /* Address difference between successive
         951                   * pixels in the same line. */
         952      int     offset[3];  /* Address differences between the red,
      green
         953                   * and blue components of the pixel and the
         954                   * pixel as a whole. */
         955      int     reserved;   /* Reserved for extensions (dash patch)
      */
         956  } Tk_PhotoImageBlock;
      
      cc -c -O   -I. -I./../generic -I./../bitmaps
      -I/usr3/people/rrr6399/tk/tcl8.2.0/tcl8.2.0/generic  -n32  -DHAVE_UNIS
      TD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1
      -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1 -D__CHAR_UNS
      IGNED__=1      -DTCL_NO_DEPRECATED   ./../generic/tkImgGIF.c
      "./../generic/tkImgGIF.c", line 266: warning(1172): subscript out of
      range
            block.offset[3] = 0;
            ^
      
      cc -c -O   -I. -I./../generic -I./../bitmaps
      -I/usr3/people/rrr6399/tk/tcl8.2.0/tcl8.2.0/generic  -n32  -DHAVE_UNIS
      TD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1
      -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1 -D__CHAR_UNS
      IGNED__=1      -DTCL_NO_DEPRECATED   ./../generic/tkImgPPM.c
      "./../generic/tkImgPPM.c", line 186: warning(1172): subscript out of
      range
            block.offset[3] = 0;
            ^
      
      cc -c -O   -I. -I./../generic -I./../bitmaps
      -I/usr3/people/rrr6399/tk/tcl8.2.0/tcl8.2.0/generic  -n32  -DHAVE_UNIS
      TD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1
      -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1 -D__CHAR_UNS
      IGNED__=1      -DTCL_NO_DEPRECATED   ./../generic/tkImgPhoto.c
      "./../generic/tkImgPhoto.c", line 805: warning(1172): subscript out of
      range
              block.offset[3] = 0;
              ^
      
      "./../generic/tkImgPhoto.c", line 4177: warning(1172): subscript out of
      range
            blockPtr->offset[3] = 0;
            ^



  This is not really a bug.  As Jan Nijtmans pointed out, this will
  actually acccess the 'reserved' int, which is there for that
  purpose.  This was a pseudo-transitional for the Img patch, which
  is likely to be included in larger part in 8.3. 
  -- 09/10/1999 hobbs


tkt_uuid: 220235ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Tk bombs on canvImg.test
comment:
  OriginalBugID: 2727 Bug
  Version: 8.1.1
  SubmitDate: '1999-09-10'
  LastModified: '1999-09-20'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  ClosedDate: '1999-09-20'


  Name:
  Olivier Lefevre

  ReproducibleScript:
  I configured tcl and tk with './configure --enable-threads
      --enable-shared'  (plus
      --with-x for tk) and used gcc 2.95. Then 'make' and 'make test'

  ObservedBehavior:
  The test suite bombed with
      
      *** Error code 138



  Tcl is thread-safe, but Tk is not guaranteed to be so.  For 8.2.0,
  it is likely to work on Windows, and it is a pot-shot for Unix
  variants (depends on Xlib and X server used).  Further work is
  being done on this. 
  -- 09/20/1999 hobbs


tkt_uuid: 220236ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: let us manipulate scrollbars more
comment:
  OriginalBugID: 2835 RFE
  Version: 8.2
  SubmitDate: '1999-09-20'
  LastModified: '1999-09-20'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  ClosedDate: '1999-09-20'


  Name:
  keith lea

  DesiredBehavior:
  I'd like to be able to configure each element of the scrollbar to
      disabled, normal; a different color; whatever. it'd be nice to be able
      to configure the whole scrollbar disabled, too.
      
      i really like how StarOffice's scrollbars work: when you scroll to the
      top, the top arrow becomes disabled; when you scroll to the bottom, the
      bottom arrow becomes disabled; when you can't scroll, the scrollbar
      stays, but is disabled.
      
      I think a disabled scrollbar shouldn't have a slider, by the way (if you
      implement disabling the whole widget)



  The problem is that the scrollbar is one of the "native" widgets,
  where we use the native version on a platform.  In the case of
  Windows, this means we can't even change the background color, much
  less the individual arrows.  This seems to be what the majority of
  users wants.
   
  -- 09/20/1999 hobbs


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: 220238ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: won't compile
comment:
  OriginalBugID: 2873 Bug
  Version: 8.2
  SubmitDate: '1999-09-23'
  LastModified: '1999-09-28'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  Machine: Other
  ClosedDate: '1999-09-28'


  Name:
  Joe Beiter

  ReproducibleScript:
  ./tkUnixDraw.c: In function `TkScrollWindow':
      ./tkUnixDraw.c:72: warning: implicit declaration of function `XCopyArea'
      ./tkUnixDraw.c:95: void value not ignored as it ought to be
      ./tkUnixDraw.c:96: warning: control reaches end of non-void function
      make: *** [tkUnixDraw.o] Error 1
      
      Make fails on Linux



  This looks like a bad version of the X headers are on the
  machine.  On our RedHat machine, you can find it in
  /usr/include/X11/Xlib.h. 
  -- 09/28/1999 hobbs


tkt_uuid: 220239ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: Widget command names not handled correctly
comment:
  OriginalBugID: 2874 Bug
  Version: 8.2
  SubmitDate: '1999-09-23'
  LastModified: '1999-09-24'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: 2.0.33
  Machine: Other
  ClosedDate: '1999-09-24'


  Name:
  Ulrich Schöbel

  ReproducibleScript:
  % text .c1
      .c1
      % pack .c1
      % .c configure -relief raised
      %

  ObservedBehavior:
  The text widget .c1 is raised after the configure command.

  DesiredBehavior:
  Since a widget  .c does not exist, I expect an error to be raised.



  This was minor user error in interactive mode.  Running .c
  through unknown finds .c1. 
  -- 09/24/1999 hobbs


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


  Name:
  Diab Jerius

  Extensions:
  none

  CustomShell:
  none

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

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

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

  DesiredBehavior:
  character appearance should be instantaneous after pressing a key



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


tkt_uuid: 220241ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: Finding pthreads on SunOS4
comment:
  OriginalBugID: 2893 Bug
  Version: 8.2
  SubmitDate: '1999-09-24'
  LastModified: '1999-09-28'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: SunOS
  OSVersion: version 4.1.4
  Machine: Sparc
  ClosedDate: '1999-09-28'


  Name:
  Michael D. Johnson

  Extensions:
  NONE at this point.  Not rebuilt

  CustomShell:
  NO.

  ReproducibleScript:
  Building the 8.2 release on Sun-os-4.1.4 using gcc-2.95.1 with gnu Pth,
      it. fails to find the Pth thread library, installed in normal library
      directory; and having tried all 4 combinations, each builds, but only
      the default no option combination does not hang and actually runs the
      tcl tests, to about a 90% pass rate. TK builds under all combinations
      but core dumps on all attempts.



  Tk is not meant to be used in a threaded environment.  It is
  thread-safe, but not multi-threaded.  Tcl is both with pthreads,
  but it appears that the setup on the machine won't find them.
  The compiler has to be able to find them, as well as the config.
  I don't see what '4 combinations' are implied here. 
  -- 09/28/1999 hobbs


tkt_uuid: 220242ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: Portability using default files
comment:
  OriginalBugID: 2962 Bug
  Version: 8.1
  SubmitDate: '1999-09-28'
  LastModified: '1999-11-03'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  ClosedDate: '1999-11-03'


  Name: Hermann G. Striecks

  ReproducibleScript:
  #!/usr/local/bin/wish

      proc showScreen {} {
           eval destroy [winfo child .]
           wm title . "Do you want to have a look at the result
      file?(Y,\[N\])"
           wm iconname . "label"
           focus -force .
           bind . <F1>   aboutBox
           frame .info
           label .info.proto    -width 45 -text "   " -relief sunken -bd 1  -font -*-Helvetica-Medium-R-Normal--*-180-*-*-*-*-*-* -anchor
      w
           pack .info.proto -side left -padx 2 -expand yes -fill both
           pack .info -side top -fill x -pady 10
           .info.proto config -text "Please click \"Yes\" to agree or \"No\"
      to disagree\"!"

           frame  .but
           button .but.start -background Green     -text "Yes"  -command
      {endSel "Yes"}
           button .but.stop  -background PeachPuff -text "No"   -command
      {endSel "No"}
           pack   .but.start   -side left  
           pack   .but.stop    -side right 
           pack   .but         -side top   -fill x -pady 10 -padx 100
           frame .test
           label .test.proto    -width 45 -text "   " -relief sunken -bd 1  -font -*-Helvetica-Medium-R-Normal--*-180-*-*-*-*-*-* -anchor
      w
           pack .test.proto -side left -padx 2 -expand yes -fill both
           pack .test -side top -fill x -pady 10
           .test.proto config -text " "

      }

      proc endSel {arg } {
           global tk_version
           .test.proto config -text "$arg"
           if {$tk_version >= 8.0} {
               set answer [tk_messageBox -message "Really $arg?" -type yesno
      -icon question]
               case $answer {
                    yes {setMsg $arg; catch {destroy .}}
                    no  {tk_messageBox -message "Now you can re-select!" -type
      ok}
               }
           } else {
               setMsg $arg
               catch {destroy .}
           }
      }

      proc setMsg {arg} {
           if {$arg == "Yes"} {
              message "Y"
           } else {
              message "N"
           }
      }

      proc aboutBox {} {
           global tk_version
           if {$tk_version >= 8.0} {
               catch {
                 tk_messageBox -icon info -type ok  -title "About yesno.tk"  -message "\n\nCreated by 8.0."
               }
           } else {
               set w .hlpID0
               catch {destroy $w}
               toplevel $w
               wm title $w "About yesno.tk"
               wm iconname $w "helpID0"
               positionWindow $w
               set b0text "\n\nCreated by 8.0."
               label $w.label -justify left -text "$b0text" -relief raised
      -width 25
               pack  $w.label
           }
      }

      proc message {text} {
           if {"$text" == "" || "$text" == " "} { 
               #puts stdout "$text"
           } else {
                puts stdout "$text"
                flush stdout
              # exec tclsh "putstdout.tcl" "anton"
           }
      }

      proc response {} {
           global myresponse
           gets stdin   myresponse
      }

      # after making the next line to comment the program is running as
      expected
      #showScreen 

      puts stdout "myprompt:"
      gets stdin name
      puts stdout "sample $name"
      puts stdout "after sample"

  ObservedBehavior:
  Im using TclTk 8.0 under Windows NT and AIX. 
      But Ive problems under Windows NT using the commands 
       - gets stdin  name 
       - puts stdout $name 
       - puts stderr $name 
      in TK scripts (using wish). It seems that the commands do not work
      properly.

  DesiredBehavior:
  Under AIX the commands 
       - gets stdin  name 
       - puts stdout $name 
       - puts stderr $name 
      in TK scripts (using wish) work fine.  
      A TCL script (using tclsh) with that statements works fine under NT and
      AIX.



  Tk on Windows does not the std channels because it is not a
  console based app (by design - you don't want to be tied to
  the dos prompt in Tk apps).  You can get around this by piping
  to and from wish, as can be seen in the Tk test setup. 
  -- 11/03/1999 hobbs


tkt_uuid: 220243ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: window bug
comment:
  OriginalBugID: 3084 Bug
  Version: 8.1
  SubmitDate: '1999-10-11'
  LastModified: '1999-10-22'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-10-22'


  Name:
  Joe Acosta

  ReproducibleScript:
  I am using wish under windows.  IH ave written a script a basic text
      editor Tk NotePad. I have added a feature which works under Linux but
      not under windows. The problem is the menu font is not getting set under
      windows correctly. The sub menus get the fonts set correctly but the
      main menubar does not. The code snippet is shown below. 
      
      set menuFont -adobe-helvetica-bold-r-normal--12-*-75-75-*-*-*-*
      
      #create main menu
      menu .filemenu -tearoff 0 -font $menuFont
      
      #file menu
      menu .filemenu.files -tearoff 0 -font $menuFont
      .filemenu  add cascade -label "File" -underline 0 -menu .filemenu.files
      .filemenu.files add command -label "New" -underline 0 -command
      "filesetasnew"
      .filemenu.files add command -label "Open" -underline 0 -command
      "filetoopen" -accelerator Ctrl+o
      .filemenu.files add command -label "Save" -underline 0 -command
      "filetosave" -accelerator Ctrl+s
      .filemenu.files add command -label "Save As" -underline 5 -command
      "filesaveas"
      .filemenu.files add separator



  The user should use the new [list $family $size $style] font
  types for 8+ to get a more expected result on Windows. 
  -- 10/22/1999 hobbs


tkt_uuid: 220244ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: dde command is not supported
comment:
  OriginalBugID: 3170 Bug
  Version: 8.1.1
  SubmitDate: '1999-10-25'
  LastModified: '1999-10-29'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0 with Service patch 3
  Machine: X86
  ClosedDate: '1999-10-29'


  Name:
  Ramon Gallo

  Extensions:
  Tcl 8.1a2, Tk 8.1a2

  ReproducibleScript:
  My code was originally written under Tcl 8.1a2 and Tk 8.1a2 utlizing the
      "dde request" command line. When I attempted to run the same code under
      version 8.1.1, this command was not supported. According to the help
      file, the syntax had not changed from the version I had used.



  The dde command still exists, with the 'dde request' method
  still there.  The user is perhaps missing
      package require dde
  before using the dde command. 
  -- 10/29/1999 hobbs


tkt_uuid: 220245ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: bindings for buttons on text not working?
comment:
  OriginalBugID: 3232 Bug
  Version: 8.0.4
  SubmitDate: '1999-10-28'
  LastModified: '1999-10-30'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: Rh 6.0
  Machine: NA
  ClosedDate: '1999-10-30'


  Name:
  Joe Acosta

  Extensions:
  pure Tcl/Tk 8.0.4

  ReproducibleScript:
  It seems taht the Button-2 bindings are not working in the text widget.
      
      I try to use the folloing line 
      
      bind .textarea <Button-2> {mymethod}
      
      and mymethod does not get executed. However if I replace Button-2 with
      Button-1 then the method gets executed.  I searched thru the text.tcl
      code and there seems to be interactions for the Buton-2 but I am not
      sure what is happening..

  DesiredBehavior:
  Button-2 to have bindings to the text widget so that a popup menu can be
      created.



  The user is likely confusing Button-2 with Button-3.  Button-2
  is the middle mouse button on a 3 button mouse, Button-3 is the
  right mouse button.  Otherwise, I have no problem binding to
  Button-2 in 8.0. 
  -- 10/30/1999 hobbs


tkt_uuid: 220246ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: no gui update while reading from socket (fileevent readable)
comment:
  OriginalBugID: 3235 Bug
  Version: 8.0.5
  SubmitDate: '1999-10-28'
  LastModified: '1999-11-02'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  ClosedDate: '1999-11-02'


  Name:robert karen

  Extensions:tktable

  ReproducibleScript:
  proc blink {win} {
        if {![string compare [$win cget -fg] red]} {
          $win configure -fg blue
        } else {
          $win confgugre -fg red
        }
        update
        after 500 "blink $win"
      }
      filevent $sock readable readit....
      set s [socket $address $port]
      after 500 blink $label
      puts $s "get_file"
      vwait var

  ObservedBehavior:
  once script starts reading from socket (like a  file download
      where there are many reads), the update doesn't cause the 
      color to change. I believe that I have also had statements like
      '$win configure -cursor watch; update' have no effect
      if they were right before the socket started reading. Not sure
      though.



  In this case, the user wants 'update idle'.  The update will
  cause the fileevent to just trigger again, making it seem like
  the window isn't wanting to update. 
  -- 11/02/1999 hobbs


tkt_uuid: 220247ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: No response from Scriptics
comment:
  OriginalBugID: 3239 Bug
  Version: 8.0.4
  SubmitDate: '1999-10-28'
  LastModified: '1999-10-29'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  Machine: RS6000
  ClosedDate: '1999-10-29'


  Name:
  Anthony Johnson

  Comments:
  Please respond! Please respond! Please respond! Please respond! Please
      respond! Please respond! Please respond! Please respond! Please respond!
      Please respond! Please respond! Please respond! Please respond! Please
      respond! Please respond!

  ReproducibleScript:
  Scripts does not repond to bug report or any other inquiries.
      What does it take to get a bug fixed? Does Scriptics support this code
      or not?

  ObservedBehavior:
  I had supplied several bug reports over the last YEAR. I have received
      no email replies, and none of the reports have appeared on the
      comp.unix.aix newsgroup. I have sent several emails asking for updates
      with no replies. 
      
      The only response I ever received from Scriptics was a salesman trying
      to sell me support. I would be more than willing to purchase TclPro (if
      it were available for AIX) and support from Scriptics, but why should I
      now pay money to be completedly ignored?

  DesiredBehavior:
  ANY REPLY AT ALL!!!!!!!!!!!!!!!!!!!!!!!!!



  This person has received several responses before 10/28/99
  (the submission of this report).  Did we lose track of reports
  in some queue, or is this just an overeager submission? 
  -- 10/29/1999 hobbs


tkt_uuid: 220248ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: wish interp doesnt save window positions/size
comment:
  OriginalBugID: 3361 Bug
  Version: 8.2
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-12'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  ClosedDate: '1999-11-12'


  Name:
  John Russell

  ReproducibleScript:
  most windows 9x programs save the current windows positions
      and sizes for next run.  Wish82 doesnt do this for some
      reason.  on opening one must move the output window to
      work on the console --- would like to be able to size/posn
      and set for future use .... if not an automatic thing
      then could this be added to menu as a save window config
      or some such ...



  This can be done by modifying the ~/wishrc.tcl (Win) or
  ~/.wishrc (Unix) to set this up. 
  -- 11/12/1999 hobbs


tkt_uuid: 220249ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Invalid
title: Console window broken in Tcl/Tk 8.2.1 for Win32 when started from Cygnus bash prompt
comment:
  OriginalBugID: 3362 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-04-16'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  ClosedDate: '2000-04-16'


  Name:
  Terry Griffin

  ReproducibleScript:
  Scenario 1: Start just plain wish82 from Cygnus bash prompt with no Tcl
      script.
      Scenario 2: Run script containing "console show" command in wish82
      started from bash.

  ObservedBehavior:
  In scenario 1: No console window appears.
      In scenario 2: Console appears but output is directed toward the bash
      window (as if under Unix), but input is accepted only from the console
      window. An odd mix to be sure.

  DesiredBehavior:
  Fine old behavior that was in Tcl/Tk 8.0.5 (same as if wish82 is started
      from CMD.EXE prompt).



  This is more likely a bug/feature of the bash prompt on Windows.
  wish is not intended to tie itself to the DOS console, but will
  if you "| tee" or something similar.  It is likely that the bash
  prompt is doing something under the covers like that. 
  -- 01/27/2000 hobbs
  I can't repeat either of these problems with cygwin-b20.1 when
  used with the current 8.3.1 dev branch.  Likely this was a change
  in cygwin somewhere along the way, but may be related to a change
  in Tk. 
  -- 04/16/2000 hobbs


tkt_uuid: 220250ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Commands
priority: 1 Zero
foundin: None
resolution: Invalid
title: Changes needed for usage of Tk with games.
comment:
  OriginalBugID: 3383 RFE
  Version: 8.2
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-17'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: Mandrake 6
  ClosedDate: '1999-11-17'


  Name:
  George Peter Staplin

  Comments:
  I hope what I have written makes sense.  Thanks for making Tcl/Tk!

  DesiredBehavior:
  I would like a sprite extension to Tk for making games.  I would also
      like an easier way to have square hot spots on label images.  I must be
      able to bind the square area over the image to a command.  The square
      area must not be visible.  A general way to have a square invisible hot
      spot on any widget would also be very useful.
      
      For example something like this.
      
      mouseover .overimage -width 30 -height 35
      place .overimage -y 20 -x 40
      
      An easier way to pinpoint the exact position of a hot spot would be
      useful.  So a flag such as '-movablepinpoint true' creates a border
      around the hot spot and allows movement of the hot spot.  When the
      hotspot is moved a toplevel window could then report the current
      position of the hot spot.  This would save me a lot of time.



  The user found other Tk methods for this with a little more research. 
  -- 11/17/1999 hobbs


tkt_uuid: 220251ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Invalid
title: binding of <Control-i> does not replace inserting of a tab in text widget
comment:
  OriginalBugID: 3388 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-12'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  ClosedDate: '1999-11-12'


  Name:
  Holger Jakobs

  ReproducibleScript:
  set t [text .t -font $f]
      bind $t <Control-i> {}

  ObservedBehavior:
  Normally, pressing <Control-i> in a text widget inserts a tab character.
      When replacing this
      key binding with something else - or even nothing, for that matter - the
      new binding is accepted
      and will be executed. But subsequently, the inserting of a tab character
      is performed as well,
      although this is no longer wanted.

  DesiredBehavior:
  If replacing or changing a key binding, the standard bindings should not
      be active anymore,
      unless + is used before the bound script.



  As doc'ed in bindtags and bind, the user requires a 'break'
  in the binding. 
  -- 11/12/1999 hobbs


tkt_uuid: 220252ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Invalid
title: Jerky behavior, broken scrollbars, hangs
comment:
  OriginalBugID: 3405 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-17'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: 2.2.13
  ClosedDate: '1999-11-17'


  Name:
  David Ronis

  ReproducibleScript:
  I've tried building the latest CVS or Stan Shebs'  game xconq--it builds
      fine and runs, sort of. 
      when I go into survey-mode it hangs.  
      
      I've also noticed jerky or wrong behavior in some other tcl/tk apps
      (e.g., tkman or make xconfig for the linux kernel-2.2.13 [here the
      scrollbars don't behave properly].



  Was Tk possibly built with threads enabled, or running on a
  threads enabled Tcl?  These are symptoms of that, and Tk
  currently can't run with threads. 
  -- 11/16/1999 hobbs
  Built with threads was the case.  This is not a valid setup. 
  -- 11/17/1999 hobbs


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


  Name:
  Torbjörn Gannholm

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

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

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

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



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


tkt_uuid: 220254ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Invalid
title: tk_getOpenFile -initialdir option not working
comment:
  OriginalBugID: 3506 Bug
  Version: 8.2
  SubmitDate: '1999-11-08'
  LastModified: '1999-11-16'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: P-II pc clone.
  ClosedDate: '1999-11-16'


  Name: C. Allen Flick

  ReproducibleScript:
  source the following into a wish.

  cd /work ; # this is where my script resides
  for {set ctr 0} {$ctr < 10} {incr ctr} {
  set fname [ tk_getOpenFile -initialdir c:\WHATEVER -title "Getting It \#$ctr" ]
  }

  ObservedBehavior:
  With each iteration of the loop, the directory that is brought up with tk_getOpenFile is the one in
  which I was working, i.e. c:/work, regardless what is put into the -initialdir option.

  DesiredBehavior:
  I would expect the file selection dialog to come up in WHATEVER directory is specified within
  the -initialdir option.



  Could not verify this on Win98 or NT.  It is likely that the
  user is giving a non-existent directory (note that C:\Whatever
  is C:hatever after substitution), which doesn't complain, but
  instead uses pwd. 
  -- 11/16/1999 hobbs


tkt_uuid: 220255ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Invalid
title: Segmentation fault on wish start (no GUI-window)
comment:
  OriginalBugID: 3548 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-11'
  LastModified: '1999-11-15'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: sun-solaris2.5.1 / X11R6.4 (compiled with gcc2.95)
  Machine: Sparc20 / UltraSparc
  ClosedDate: '1999-11-15'


  Name:
  Ralf Oelschlaegel

  ReproducibleScript:
  ./configure --enable-gcc --enable-shared --enable-symbols
  (gcc version 2.95 19990728)
  same effect with gcc version 2.8.0 and cc: SC4.0 18 Oct 1995 C 4.0
  and also with Tcl/Tk 8.0.5

  ObservedBehavior:
  ldd ./wish 
  libtk8.2g.so => ./libtk8.2g.so
  libtcl8.2.so => /usr/local/lib/libtcl8.2.so
  libsocket.so.1 => /usr/lib/libsocket.so.1
  libX11.so.6.1 => /usr/local/X11/lib/libX11.so.6.1
  libdl.so.1 => /usr/lib/libdl.so.1
  libm.so.1 => /usr/lib/libm.so.1
  libc.so.1 => /usr/lib/libc.so.1
  libnsl.so.1 => /usr/lib/libnsl.so.1
  libintl.so.1 => /usr/lib/libintl.so.1
  libmp.so.1 => /usr/lib/libmp.so.1
  libw.so.1 => /usr/lib/libw.so.1

  (gdb) bt
  #0  0xef3e4870 in strncpy ()
  #1  0xef539480 in _XimMakeImName ()
  #2  0xef539590 in _XimOpenIM ()
  #3  0xef51080c in XOpenIM ()
  #4  0xef6dbfcc in OpenIM (dispPtr=0x319a8) at ./../generic/tkWindow.c:2455
  #5  0xef6d93c8 in GetScreen (interp=0x22b70, screenName=0x22780 ":0.0", 
      screenPtr=0xefffea1c) at ./../generic/tkWindow.c:456
  #6  0xef6d8fd0 in CreateTopLevelWindow (interp=0x22b70, parent=0x0, 
      name=0xefffed29 "wish", screenName=0xef76cee0 "") at ./../generic/tkWindow.c:285
  #7  0xef6d9bdc in TkCreateMainWindow (interp=0x22b70, screenName=0xef76cee0 "", 
      baseName=0xefffed29 "wish") at ./../generic/tkWindow.c:803
  #8  0xef703658 in TkCreateFrame (clientData=0x0, interp=0x22b70, argc=4, 
      argv=0xefffee18, toplevel=1, appName=0xefffed29 "wish")
      at ./../generic/tkFrame.c:333
  #9  0xef6dcb1c in Initialize (interp=0x22b70) at ./../generic/tkWindow.c:2912
  #10 0xef6dc2dc in Tk_Init (interp=0x22b70) at ./../generic/tkWindow.c:2618
  #11 0x1080c in Tcl_AppInit (interp=0x22b70) at ./tkAppInit.c:84
  #12 0xef6c8594 in Tk_MainEx (argc=1, argv=0xeffff23c, 
      appInitProc=0x107c8 <Tcl_AppInit>, interp=0x22b70) at ./../generic/tkMain.c:216
  #13 0x107b4 in main (argc=1, argv=0xeffff23c) at ./tkAppInit.c:54

  or
  0xef3cbe58 in _morecore ()
  #0  0xef3cbe58 in _morecore ()
  #1  0xef3cb738 in _malloc_unlocked ()
  #2  0xef3cb4a8 in malloc ()
  #3  0xef4f946c in _XimMakeImName ()

  DesiredBehavior:
  Opening of the generic wish window



  Please use a debugging version of Tcl with a debugging version
  of Tk (or nodebug with nodebug). 
  -- 11/11/1999 hobbs
  This turned out to be due to definition of the TK_USE_INPUT_METHODS,
  but that was not working on the users system.  This should be
  improved in 8.3. 
  -- 11/15/1999 hobbs


tkt_uuid: 220256ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Invalid
title: console is viewed as redirected input
comment:
  OriginalBugID: 3667 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-23'
  LastModified: '1999-11-29'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: Windows95
  Machine: Brandless clone Cyrix686
  ClosedDate: '1999-11-29'


  Name:
  Jean-Pierre Vial

  Extensions:
  Pure Tcl or Tk 8.2.2

  CustomShell:
  None

  Comments:
  A test under Linux (with a much older version of Tk) works fine,
  but obviously the process is quite different: with linux the console
  is an ordinary xterm window, with Windows95 Wish opens its own console,
  this is probably the origin of the problem.

  ReproducibleScript:
  I have applications (in C) which react differently
  in interactive mode and in shell scripts.
  They choose the appropriate mode via an <<isatty>> test.
  With tclsh, everything is OK
  with wish, the console is not considered as a tty but as a file. 
  Here is a C test file (tsttty.c)

  #include "stdio.h"
  #include "io.h"
  int main(void){
  if (isatty(fileno(stdin)))
  printf("stdin is the console: interactive mode\n");
  else printf("stdin is a file: automatic mode without prompt or messages\n");
  return 0;
  }

  ObservedBehavior:
  % tsttty
  stdin is a file: automatic mode without prompt or messages
  % 

  [this is done with Wish (= Tk 8.2.2), in interactive mode in the wish console]

  DesiredBehavior:
  % tsttty
  stdin is the console: interactive mode
  %

  (This is done with tclsh: no problem here)



  There is no problem here, this is a conscious design decision,
  that wish not be tied to the console.  See the comp.lang.tcl
  newsgroup for solutions on how to modify the makefile to put
  wish into console mode (which would pop up a DOS box with each
  invocation). 
  -- 11/29/1999 hobbs


tkt_uuid: 220257ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 48. Geometry Management
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Invalid
title: tcl/tk goes into infinite loop on both unix and windows platforms
comment:
  OriginalBugID: 3682 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-24'
  LastModified: '1999-11-29'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  OSVersion: windows NT4.0sp5 and HP-UX 10.20
  ClosedDate: '1999-11-29'


  Name:
  Bergur Ragnarsson

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  #! /opt/tcl/bin/wish
  # $Header: /home/CVS_ARCHIVE/tern/ats/integration/showmap.tcl,v 1.2 1999/11/18 18:53:36 bergur Exp $
  #

  #
  # $Header: /home/CVS_ARCHIVE/tern/ats/integration/stdinc.tcl,v 1.1 1999/11/05 16:19:48 bergur Exp $
  #
  #
  # Example 27-2
  # Scroll_Set manages optional scrollbars.
  #

  proc Scroll_Set {scrollbar geoCmd offset size} {
  if {$offset != 0.0 || $size != 1.0} {
  eval $geoCmd;# Make sure it is visible
  }
  $scrollbar set $offset $size
  }

  #
  # Example 27-3
  # Listbox with optional scrollbars.
  #

  proc Scrolled_Listbox { f args } {
  frame $f
  listbox $f.list  -xscrollcommand [list Scroll_Set $f.xscroll  [list grid $f.xscroll -row 1 -column 0 -sticky we]]  -yscrollcommand [list Scroll_Set $f.yscroll  [list grid $f.yscroll -row 0 -column 1 -sticky ns]]
  eval {$f.list configure} $args
  scrollbar $f.xscroll -orient horizontal  -command [list $f.list xview]
  scrollbar $f.yscroll -orient vertical  -command [list $f.list yview]
  grid $f.list -sticky news
  grid rowconfigure $f 0 -weight 1
  grid columnconfigure $f 0 -weight 1
  return $f.list
  }
  #####################################################################
  #
  # START
  #

  frame .f1 -width 3000 -height 300 -background blue

  text .f1.text -width 50 -height 10

  set aw [list G1 63.59.1 -22.36.5 64.39.5 -21.17.4 65.34.4 -19.29.2 65.45.4 -18.00.3 66.15.1 -15.15.4 END]
  set saw [lsort $aw]

  set aw_list [Scrolled_Listbox .f1.flst -width 30 -height 10] 
  #set aw_list [listbox .f1.flst -width 30 -height 10] 
  eval {$aw_list insert end} $saw
  #$aw_list insert end route1 route2 route3

  pack $aw_list
  grid .f1.flst

  grid .f1.text

  pack .f1

  # how to reproduce:
  # a) run the script
  # b) type a few characters in the text box, then try selecting a few 
  #    characters, i.e. hold down shift and press left arrow a few times
  # c) system hangs (infinite loop)

  ObservedBehavior:
  Infinite looping

  DesiredBehavior:
  no infinite loop !



  Followup:
  pack $aw_list
  seems to causes conflict between the geometry managers grid & pack;
  the list object was previously under grid's control. Granted this isn´t
  correct code but it's hardly acceptable to go into spin.

  Best regards,
  Bergur Ragnarsson
   
  -- 11/24/1999 foster

  It is a known problem that there is a manager contention between
  pack and grid, but they should never be used together.  This is
  a dup of simpler cases for pack v grid. 
  -- 11/29/1999 hobbs


tkt_uuid: 220258ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Invalid
title: Segmentation fault in strncpy on startup
comment:
  OriginalBugID: 3760 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-03'
  LastModified: '1999-12-16'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  Machine: SunOS  Generic sun4u sparc SUNW,Ultra-1
  ClosedDate: '1999-12-16'


  Name:
  simon blanchard

  CustomShell:
  elide from tkman

  ReproducibleScript:
  ./wish

  It crashes

  ObservedBehavior:
  (gdb) where
  #0  0xfeeb705c in strncpy ()
  #1  0xff00d3ec in _XimMakeImName ()
  #2  0xff00d540 in _XimOpenIM ()
  #3  0xff2c9f78 in OpenIM ()
  #4  0xff2c81c8 in GetScreen ()
  #5  0xff2c7e74 in CreateTopLevelWindow ()
  #6  0xff2c8750 in TkCreateMainWindow ()
  #7  0xff2e40fc in TkCreateFrame ()
  #8  0xff2ca658 in Initialize ()
  #9  0x11998 in Tcl_AppInit ()
  #10 0xff2bcf2c in Tk_MainEx ()
  #11 0x11948 in main ()
  (gdb)

  DesiredBehavior:
  The default wish window should come up



  This appears to be a bug in the X libraries of the users computer.
  The XOpenIM call is defined to accept NULL for string arguments,
  but it appears that the libraries this person is using are not
  taking that into account.  The work-around is to ensure that
  TK_USE_INPUT_METHODS does not get defined in tk.h (comment it out).
  It should have no effect on the users operation if they do not
  require input devices.

  The user should also note that 8.3b1 has elide in core. 
  -- 12/16/1999 hobbs


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


  Name:
  Lutz Newiger

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

  ObservedBehavior:
  Dear Ladies and Gentlemen,

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

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

  Best regards

  Lutz Newiger



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


tkt_uuid: 220260ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Under Enlightenment, calls to 'raise toplevel' are very slow
comment:
  OriginalBugID: 3777 Bug
  Version: 8.3b1
  SubmitDate: '1999-12-06'
  LastModified: '2000-04-12'
  Severity: SER
  Status: Closed
  Submitter: key
  ChangedBy: ericm
  RelatedBugIDs: 2581 2478
  OS: Linux-Red Hat
  ClosedDate: '2000-04-12'


  steps to reproduce:
  1) Start wish
  2) type "toplevel .t"
  3) type "raise .t"

  expected result:
  command returns quickly

  actual result:
  command returns after about 2 seconds


  Scott Stanton, Jeff and I tracked this down to a problem in TkWmRestackToplevel in tkUnixWm.c.  Basically here's the problem:  that function wants to find the user-level window (ie, the thing with the window border/decorations).  To do this on most wm's, you can walk to the top of the x window hierarchy, then go down one.  In enlightenment, there is an extra "pseudo-root" window in place, so we get the wrong window.  This ultimately leads to a timeout in WaitForEvent when it is waiting for a configure event to come through.  The timeout is the cause of the slowness.

  Graphically, here's the hierarchy we are expecting:

  root
  user window
  application (tk)

  here's what we have:

  root
  enlightenment
  user window
  application

  Unfortunately, Scott says we can't just go up one from the application window either, because there may be intervening windows there as well.  So it seems that we need a better algorithm for finding the user window, but I don't know what that is.  Donal Fellows may have sent Jeff a partial patch that is Enlightenment specific, but it has not been examined at all.

  - eric

  -- 12/07/1999 ericm

  At long last we have determined that this is in fact an Enlightenment bug.  The version of Enlightenment installed with Redhat 6.0 is version 0.15.5, and it exhibits this bug.  On upgrading to the latest release of Enlightenment, 0.16.4, the problem went away.

  - eric

  -- 04/12/2000 ericm


tkt_uuid: 220261ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Invalid
title: toplevels pop up in back of main window
comment:
  OriginalBugID: 3801 Bug
  Version: 8.2.1
  SubmitDate: '1999-12-07'
  LastModified: '1999-12-09'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  ClosedDate: '1999-12-09'


  Name:
  Peter Nye

  Comments:
  If there's a workaround, I'd like to know it!

  ReproducibleScript:
  # Create dialog if id doesn't exist already, otherwise pop it up.
  proc showDialog {} {
     if {![winfo exists .t]} {
        toplevel .t
        label .t.lab -text "Dialog"
        button .t.b -text ok -command "wm withdraw .t"
        pack .t.lab .t.b
        }
     wm deiconify .t
  }

  # Main menu
  menubutton .1 -text {File}
  pack .1 
  .1 config -menu .1.2
  menu .1.2 
  .1.2 add command -label {Show Dialog} -command {showDialog}

  ObservedBehavior:
  The first time you pop up the new toplevel, it comes up in front of the main window.  When you pop it up again (from the menu), it comes up behind the main window.  (Only on the Mac.)

  DesiredBehavior:
  It should come up on top every time.



  Add 'raise .t' after the deiconify.  It is likely that the other
  toplevel is moving higher in the Z order when the other gets
  withdrawn, and raise will correct that. 
  -- 12/09/1999 hobbs


tkt_uuid: 220262ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: strange values for abbrievated options from the configure widget command
comment:
  OriginalBugID: 3811 Bug
  Version: 8.0p2
  SubmitDate: '1999-12-08'
  LastModified: '1999-12-09'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  Machine: SunOS  5.6 Generic_105181-13 sun4m sparc SUNW,SPARCstation-10
  ClosedDate: '1999-12-09'


  Name: Drew Gutstein

  ReproducibleScript:
  This bug is very easy to reproduce and effects most tk widgets.  In this example I created a label and called that widgets configure command with no arguments.  The result is the usual big list of options and their values but abrievated options such as -bg, -fg, and -bd  have a different format.

  Here's the example:

  /u/drew> prowish80
  % label .l
  .l
  % .l configure
  {-anchor anchor Anchor center center} {-background background Background #d9d9d9 #AE00B200C300} {-bd borderWidth} {-bg background} {-bitmap bitmap Bitmap {} {}} {-borderwidth borderWidth BorderWidth 2 2} {-cursor cursor Cursor {} {}} {-fg foreground} {-font font Font {Helvetica -12 bold} {-dt-interface user-medium-r-normal-s*-*-*-*-*-*-*-*-*}} {-foreground foreground Foreground Black #000000000000} {-height height Height 0 0} {-highlightbackground highlightBackground HighlightBackground #d9d9d9 #d9d9d9} {-highlightcolor highlightColor HighlightColor Black Black} {-highlightthickness highlightThickness HighlightThickness 0 0} {-image image Image {} {}} {-justify justify Justify center center} {-padx padX Pad 1 1} {-pady padY Pad 1 1} {-relief relief Relief flat flat} {-takefocus takeFocus TakeFocus 0 0} {-text text Text {} {}} {-textvariable textVariable Variable {} {}} {-underline underline Underline -1 -1} {-width width Width 0 0} {-wraplength wrapLength WrapLength 0 0}
  %

  ObservedBehavior:
  Instead of the usual five element list you get a two element list which looks something like this: 
   {-bd borderWidth}.
  -bg, -fg, and -bd seem to be the only options which are synonyms for other options, so the problem is easy worked around.

  DesiredBehavior:
  the configure command shoud use the same format for abrievated options as is does when you call configure with just the single argument like this
  % .l configure -bd
  -borderwidth borderWidth BorderWidth 2 2
  %



  This is the designed and desired behavior, so you can introspect
  and see what are also valid synonyms (any options with llength==2).
  This is as documented. 
  -- 12/09/1999 hobbs


tkt_uuid: 220263ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: final: 8.2.3
resolution: Invalid
title: wish SEGVs
comment:
  OriginalBugID: 3894 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-17'
  LastModified: '2000-02-25'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: QNX 4.25
  Machine: i586
  ClosedDate: '2000-02-25'


  Name:
  Bruce Edge

  Comments:
  The call to XGetIMValues does not set stylePtr->supported_styles
  correctly.

  It may be a bug in the XFree86 libs, but I could fix it here.

  ReproducibleScript:
  run wish, it terminates with a segment violation immediately

  Patch:
  # //8/usr/local/src/tk8.2.3/generic> less tkWindow.diff
  *** tkWindow.c  Fri Dec 17 11:50:51 1999
  --- tkWindow.orig.c     Wed Apr 21 17:53:28 1999
  ***************
  *** 2461,2468 ****
              NULL) != NULL) || (stylePtr == NULL)) {
          goto error;
        }
  -
  - #ifndef __QNX__
        for (i = 0; i < stylePtr->count_styles; i++) {
          if (stylePtr->supported_styles[i]
                  == (XIMPreeditNothing|XIMStatusNothing)) {
  --- 2461,2466 ----
  ***************
  *** 2470,2476 ****
              return;
          }
        }
  - #endif
        XFree(stylePtr);
   
        error:
  --- 2468,2473 ----

  PatchFiles:
  tkwindow.c



  This is really like the XFree86 libs.  The better fix is to
  make sure that TK_USE_INPUT_METHODS is not defined (comment
  it out) before compiling.  This will skip that entire
  process, also avoiding the bug. 
  -- 12/17/1999 hobbs


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: 220265ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: final: 8.2.3
resolution: Invalid
title:
  A Tcl command invokes whenever  a mouse pointer enter the scale widget without changing the value of the variable.

comment:
  OriginalBugID: 3908 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-20'
  LastModified: '2000-01-14'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 6339
  OS: Linux-Red Hat
  OSVersion: RedHat 5.0
  ClosedDate: '2000-01-14'


  Name:
  Josephine Ng

  Extensions:
  Tcl/Tk

  Comments:
  The script is tested on both Tcl8.02p and Tcl8.2.3 on both windows 95 and Linux.
  While the script doesn't behave as expected in Linux, it behaves correctly in Windows 95.

  ReproducibleScript:
  set bandtest [scale .bt -orient horizontal  -from 410.8 -to 956.1  -resolution 0.1  -length 128 -width 5 -tickinterval [expr 956.1 - 410.8]  -digits 4 -showvalue 1 -troughcolor blue -command updateBandTest"]
  pack $bandtest

  proc updateBandTest { value } {
      puts "updateBandTest!! $value"

  }

  ObservedBehavior:
  The Tcl command will be invoked whenever the mouse pointer enter the scale widget without pressing
  any buttons of the mouse.

  DesiredBehavior:
  The Tcl command should only be invoked when the mouse button is pressed over the slider.



  This is verifed with 8.3b1 on Linux.  It does not occur on Windows
  or Solaris, so this seems to be Linux only at the moment (RH6). 
  -- 12/22/1999 hobbs

  Minimal case:

  --------------------------------
  proc foo {val} {puts "foo $val"}
  pack [scale .s -resolution 0.1 -command foo]
  .s set 0.3
  --------------------------------

  - eric

  -- 01/13/2000 ericm

  This seems to be a compiler bug.  On a sample RH 6.0 Linux install (which uses egcs-2.91.66), I found that adding diagnostic "printf" calls to the TkpSetScaleValue funciton in tkUnixScale.c made the problem go away.  Then I found that compiling the original code with neither optimization nor debugging enabled also made the problem go away.  These are classic signs of a C compiler bug.

  - eric

  -- 01/13/2000 ericm 
  -- 01/14/2000 ericm


tkt_uuid: 220266ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: final: 8.2.3
resolution: Invalid
title: make install fails to install wish in any system directory
comment:
  OriginalBugID: 3946 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-27'
  LastModified: '2000-01-03'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  Machine: ibm clone pentium 75 cpu
  ClosedDate: '2000-01-03'


  Name:
  kevin

  ReproducibleScript:
  ./configure ; make ; make install

  DesiredBehavior:
  i expect to find wish installed in a system directory after i rm-fr the compiling directory



  Was there no error message given?  In the default case, wish will
  be installed into /usr/local/bin - WITH THE VERSION NUMBER, so you
  can have multiple versions of wish at the same time.  Look for
  /usr/local/bin/wish8.2 and /usr/local/lib/{tcl8.2,tk8.2} 
  -- 01/03/2000 hobbs


tkt_uuid: 220267ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.3b1
resolution: Invalid
title: Elided text not mentioned in text man page
comment:
  OriginalBugID: 3968 Bug
  Version: 8.3b1
  SubmitDate: '2000-01-03'
  LastModified: '2000-01-03'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  OSVersion: 4.3.3
  Machine: RS/6000 43P Model 150
  ClosedDate: '2000-01-03'


  Name:
  Dave Marquardt

  ReproducibleScript:
  Build and install Tk 8.3b1.  Run "man text."  Notice that elided text isn't mentioned anywhere.

  ObservedBehavior:
  The elided text patch is supposed to be part of Tk 8.3b1, and apparently is, since TkMan works with wish8.3 without patching the Tk source code.  But this feature is not mentioned in the text man page.

  DesiredBehavior:
  Describe elided text in "text" man page.



  It is mentioned under TAGS as -state hidden, which is the option
  to attain it.  It may change in 8.3b2 to -elide TCL_BOOLEAN instead. 
  -- 01/03/2000 hobbs


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


  Name:
  luyingwei

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



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


tkt_uuid: 220269ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: Error: can't read "tkPriv(x)": no such element in array
comment:
  OriginalBugID: 3987 Bug
  Version: 8.3b1
  SubmitDate: '2000-01-07'
  LastModified: '2000-01-17'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  Machine: Micron P2-450, 256MB RAM
  ClosedDate: '2000-01-17'


  Name: Brian Schmidt


  ReproducibleScript:

  This error message pops up whenever the mouse passes over a toplevel window.  I normally get the error after first starting up wish (and not entering ANY commands) and passing the mouse over the console.  The below stack trace is from when I got the error on a toplevel window in my application after first starting it up.


  This error is intermittent and relatively rare.  However, the only remedy I can find is to reboot my system.  Otherwise the error keep reoccurring even though the Tcl/Tk application or wish is shut down and restarted.


  The stack trace code isn't in my application and must be in the core distribution.


  Errorbox message: Error: can't read "tkPriv(x)": no such element in array


  Thanks!


  ObservedBehavior:

  can't read "tkPriv(x)": no such element in array

      while executing

  "if {abs(122-$tkPriv(x)) > 2} {

      set tkPriv(mouseMoved) 1

  }"

      invoked from within

  "if {!$tk_strictMotif} {

  if {abs(122-$tkPriv(x)) > 2} {

      set tkPriv(mouseMoved) 1

  }

  .tCategories.fCategories.fAddDelete.eCategory scan dragto 12..."

      (command bound to event)




  The user noted that this really only happens over an entry.
  I wonder if the user is hitting the problem where they have
  given the script a name of one of the core widgets (like
  entry.tcl or button.tcl), which is known to cause an error
  because the class of the main toplevel will be set to that
  of one of the widgets. 
  -- 01/10/2000 hobbs
  Closed due to lack of reproducability (on our side, and on
  the users side). 
  -- 01/17/2000 hobbs


tkt_uuid: 220270ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: create 'wish' during installation
comment:
  OriginalBugID: 4045 RFE
  Version: 8.0.5
  SubmitDate: '2000-01-19'
  LastModified: '2000-01-26'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: WinLinux 2000 Final Beta
  Machine: i586 Pentium
  ClosedDate: '2000-01-26'


  Name:
  David M. Elton

  DesiredBehavior:
  After installing 8.0, wish8.0 is created in /usr/local/bin. However, several programs try to execute wish instead of wish8.0. Many people new to *nix operating systems may have trouble fixing this problem. What I did to fix it was simply type the command "ln -s wish8.0 wish" to create a link to wish8.0. Just suggesting that maybe that line is placed in the installation scripts.



  The decision not to do this was made when Tcl started versioning
  itself, because it can potentially cause compatibility problems
  when users do the traditional
    #!/bin/sh
    # exec wish ...

  Because you may be inserting a new version of wish into someones
  path.  If the user required special extensions for a particular
  version, this would then likely cause the script to no longer work
  until the 'exec wish' hard-coded the full path. 
  -- 01/26/2000 hobbs


tkt_uuid: 220271ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: Pop-up windows don't pop up for sub-widgets
comment:
  OriginalBugID: 4059 Bug
  Version: 8.2
  SubmitDate: '2000-01-24'
  LastModified: '2000-01-25'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  ClosedDate: '2000-01-25'


  Name: Les Hatton

  ReproducibleScript:
  Tried to implement a balloon help, (full example sent to Angie).  Works fine with TclPro1.2 shipped release for Linux.  Mostly works for Windows except that help window pops up in top left instead of relative to widget requesting help.  Works fine with TclPro1.3 (with shipped Tcl/Tk) for Linux but on Windows the help only pops up for the top-level widget (but still in top left) and doesn't pop up at all for sub-widgets.

  DesiredBehavior:
  Consistent behaviour between Linux and Windows as occurred with TclPro1.2.



  There are some known problems with geometry management for
  hidden toplevels that cause problems when attempting trivial
  tasks like balloon help.  Most problems were resolved by 8.2.1
  and all are fixed by 8.3b1.  For valid work-arounds for earlier
  version of tk, email hobbs @ scriptics. 
  -- 01/25/2000 hobbs


tkt_uuid: 220272ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Invalid
title: button widget error occur
comment:
  OriginalBugID: 4068 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-24'
  LastModified: '2000-01-25'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: WindowsNT4.0SP6a and Windows95
  Machine: PC
  ClosedDate: '2000-01-25'


  Name:
  Satoshi Imai

  Extensions:
  none

  ReproducibleScript:
  # Error occur by following script, if you focus in the button.
  # It's not joke.

  button .b -text Push
  pack .b

  ObservedBehavior:
  Error: unknown option "-state"



  Is this when the script is run interactively, or by double-clicking
  on it?  If the latter, what is the name of the script?

  This sounds like the error that pops up when someone has named a
  script after a class name for one of the widgets.  This is a known
  problem, because the class of the application becomes that for a
  widget, thus assuming the class bindings (like for <Enter>) as well.

  Need more info/verification from the user. 
  -- 01/25/2000 hobbs


tkt_uuid: 220273ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: Character widths wrong in Unicode text
comment:
  OriginalBugID: 4075 Bug
  Version: 8.2
  SubmitDate: '2000-01-24'
  LastModified: '2000-05-18'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2027
  OS: Linux
  ClosedDate: '2000-05-18'


  Name:
  Raphael Finkel

  ReproducibleScript:
  set width 40
  set blanks "                                        "; # 40 

  set convert(b) "\u5d1"

  text .here -height 2 -width [expr 2*$width] -font OEMFixed
  .here insert end $blanks
  focus .here; # so it gets a cursor
  pack .here 

  proc reduce {character numeric} {
          global convert
          if {$numeric > 0 && $numeric < 256} {
                  if {[info exists convert($character)]} {
                          return $convert($character)
                  } else {
                          return [format %c $numeric]
                  }
          } else {
                  return ""
          }
  }; # reduce

  set lineString {} ;# unicode representation

  bind Text <KeyPress> { ;# overriding the usual binding
          set reduced [reduce %K %N]
          set length [string length $reduced]
          if {$length > 0 && $length < 4} { ;# printable character
                  if {[string length $lineString] == 0} {
                          set rtlPlace [expr $width - 1]
                  }
                  append lineString $reduced
                  incr rtlPlace -1
                  .here delete 1.$rtlPlace
                  .here insert 1.$rtlPlace $reduced
          } 
  } ;# bind Text <KeyPress>

  vwait foo

  ObservedBehavior:
  type into the window a few "b" characters.  The Hebrew letter "beyt" will appear.  Each time you type "b", the program deletes a space on the left and inserts a "beyt" in its place.  Notice how the right hand margin creeps to the right.  It shouldn't.  After a few "b" characters, type "a" characters.  The
  "a"s will also be placed on the left, in the same way.  No more creepage.  It seems that Hebrew letters are misjudged as to screen width.  I have this problem
  both with font OEMFixed and font -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 .

  DesiredBehavior:
  The right-hand margin should not move as characters are typed, whether "b" or "a".



  The problem here appears to be just that the font really isn't
  of fixed width, so the spaces are smaller than the chars that
  are inserted.  This is backed up by the following:

  (tkcon) 64 % font metrics OEMFixed
  -ascent 15 -descent 3 -linespace 18 -fixed 0
   
  -- 05/18/2000 hobbs


tkt_uuid: 220274ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Invalid
title: mapping of 0 value coordinates is incorrect with create oval
comment:
  OriginalBugID: 4076 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-24'
  LastModified: '2000-03-27'
  Severity: LOW
  Status: Closed
  Submitter: shawn
  ChangedBy: hobbs
  OS: Windows NT
  ClosedDate: '2000-03-27'


  mapping of 0 value coordinates is incorrect with create oval - placement of an oval with the coordinates of 0 0 20 20 produces an oval which is truncated on the left and top -  of the canvas - avout the amount of the width of the border of the canvas- 

  Expected Results - 

  I expect to see a complete oval when I give these coordinates 

  Reproducible script: 

  canvas .c 
  pack .c 
  .c create oval  0 0 20 20 -fill red -stipple gray75 -outline red -outlinestipple gray75



  You'll find that the visible edge of the canvas is not 0,0.
  For that, do:
    .c xview moveto 0
    .c yview moveto 0 
  -- 03/27/2000 hobbs


tkt_uuid: 220275ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Invalid
title: "-data" option on "image create photo" only takes base64 character strings
comment:
  OriginalBugID: 4129 Bug
  Version: 8.3b2
  SubmitDate: '2000-02-04'
  LastModified: '2000-02-07'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 4125
  OS: Windows NT
  OSVersion: Windows NT V4.0 SP3
  Machine: Gateway Pentium 166Mhz
  ClosedDate: '2000-02-07'


  Name:
  David Burns

  ReproducibleScript:
  The online Help documentation doesn't mention that the 'string' that is supposed to be submitted to the "-data" option in a "image create photo" invocation is a base64 character string (Welch mentions this in his book though).  If you
  submit a binary character string you get "can't recognize data" message.

  I'm presuming that to maintain compatibility with previous incarnations of Tk,
  that another option is to be added (maybe "-binarydata"?) that will allow
  submitting true binary strings to this command.



  This is fixed in 8.3 final.  You can obtain the latest sources from our NetCVS repository, or just want for the release in a few days.  JPEG support is not yet integrated into the core.  The implementation in Img depends on libjpeg, and we don't want to make Tk dependent on external libraries like that (excluding the X libs, obviously, there's not really any way around that).

  We didn't actually have to introduce a new option for the binary data, because it is possible to differentiate between base64 data and binary data by examining the first few bytes of data.  So in 8.3 final, you can do:

  set f [open myfile.gif r]
  fconfigure $f -translation binary -encoding binary
  set data [read $f]
  image create photo -data $data

  This works as expected.

  - eric

  -- 02/07/2000 ericm


tkt_uuid: 220276ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.2.3
resolution: Invalid
title: TkTable Extension crashes in TableCellCoords.c
comment:
  OriginalBugID: 4135 Bug
  Version: 8.2.3
  SubmitDate: '2000-02-07'
  LastModified: '2000-04-18'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  ClosedDate: '2000-04-18'


  Name:

  Torsten Rottmann



  Comments:

  Should I define BOUNDS_CHECK to avoid this in the sequence below?

      

          /* real coords required, always should be passed acceptable values,

         * but this is a possible seg fault otherwise */

      #ifdef BOUNDS_CHECK

          row = MIN(tablePtr->rows-1, MAX(0, row));

          col = MIN(tablePtr->cols-1, MAX(0, col));

      #endif

          *w = tablePtr->colPixels[col];

          *h = tablePtr->rowPixels[row];



  ReproducibleScript:

  Somehow Tktable (2.5) craches with following stack:

  #0  0x4028dd6e in TableCellCoords (tablePtr=0x810fa00, row=177, col=0,

      x=0xbfffe004, y=0xbfffe000, w=0xbfffdffc, h=0xbfffdff8)

      at ./tkTableCell.c:100

  ---Type <return> to continue, or q <return> to quit---

  100         *h = tablePtr->rowPixels[row];

  (gdb) bt

  #0  0x4028dd6e in TableCellCoords (tablePtr=0x810fa00, row=177, col=0,

      x=0xbfffe004, y=0xbfffe000, w=0xbfffdffc, h=0xbfffdff8)

      at ./tkTableCell.c:100

  #1  0x4028dfe1 in TableCellVCoords (tablePtr=0x810fa00, row=177, col=0,

      rx=0xbfffe048, ry=0xbfffe044, rw=0xbfffe040, rh=0xbfffe03c, full=0)

      at ./tkTableCell.c:192

  #2  0x40286f83 in TableRefresh (tablePtr=0x810fa00, row=177, col=0, mode=4)

      at ./tkTable.c:1440

  #3  0x402893c2 in TableAdjustActive (tablePtr=0x810fa00) at ./tkTable.c:2650

  #4  0x40289f04 in TableAdjustParams (tablePtr=0x810fa00) at ./tkTable.c:3005

  #5  0x40286bda in TableConfigure (interp=0x8053000, tablePtr=0x810fa00,

      objc=2, objv=0x8056028, flags=1, forceUpdate=0) at ./tkTable.c:1219

  #6  0x40285d87 in TableWidgetObjCmd (clientData=0x810fa00, interp=0x8053000,

      objc=4, objv=0x8056020) at ./tkTable.c:705

  #7  0x400e4e23 in TclExecuteByteCode ()             

  ...

  (gdb) print *tablePtr

  $1 = {tkwin = 0x80fa100, display = 0x805f000, interp = 0x8053000,

    widgetCmd = 0x81106c0, autoClear = 1, selectMode = 0x80eb968 "browse",

    selectType = 1, selectTitles = 0, rows = 15, cols = 6, defRowHeight = 1,

    defColWidth = 10, maxReqCols = 0, maxReqRows = 15, maxReqWidth = 800,

    maxReqHeight = 600, arrayVar = 0x80eb960 "tup", rowSep = 0x0, colSep = 0x0,

    defaultTag = {bg = 0x8077180, fg = 0x8124a40, bd = 1, relief = 5,

      tkfont = 0x811c000, anchor = TK_ANCHOR_W, imageStr = 0x0, image = 0x0,

      state = STATE_UNKNOWN, justify = TK_JUSTIFY_LEFT, multiline = 1,

      wrap = 0, showtext = 0}, yScrollCmd = 0x811e0a0 ".tf.tupscroller set",

    xScrollCmd = 0x0, browseCmd = 0x811e040 "mdbb:browse %r %s %S",

    caching = 0, command = 0x0, useCmd = 1, selCmd = 0x0,

    valCmd = 0x811e020 "mdbb:validate %C %S", validate = 1,

    insertBg = 0x8124a00, cursor = 0x0, bdcursor = 0x3c0002e,

    exportSelection = 0, state = STATE_NORMAL, insertWidth = 2,

    insertBorderWidth = 0, insertOnTime = 600, insertOffTime = 300,

    invertSelected = 0, colStretch = 1, rowStretch = 1, colOffset = 1,

    rowOffset = -2, drawMode = 4, flashMode = 0, flashTime = 2, resize = 2,

    sparse = 0, rowTagCmd = 0x0, colTagCmd = 0x0, highlightWidth = 2,

    highlightBgColorPtr = 0x8077800, highlightColorPtr = 0x80777c0,

    takeFocus = 0x0, padX = 2, padY = 1, titleRows = 2, titleCols = 0,

    topRow = 2, leftCol = 0, anchorRow = 177, anchorCol = 0, activeRow = 14,

    activeCol = 0, oldTopRow = 168, oldLeftCol = 0, oldActRow = 177,

    oldActCol = 0, icursor = 4, flags = 55, dataSource = 4, maxWidth = 707, 



  ...



  ObservedBehavior:

  As you may see, the table has 15 rows, but  oldActRow = 177.

  The table was possibly resized serval times (don't know by insert/delete or

  a configure).



  DesiredBehavior:

  no crash!





  The BOUNDS_CHECK would likely prevent the problem, but it would
  be good to know what actually caused it.  I am not able to
  reproduce this bug in any way with v2.6alpha. 
  -- 04/18/2000 hobbs


tkt_uuid: 220277ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Invalid
title: tk_chooseDirectory returns upper case name on Win98
comment:
  OriginalBugID: 4145 Bug
  Version: 8.3b2
  SubmitDate: '2000-02-08'
  LastModified: '2000-02-10'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  ClosedDate: '2000-02-10'


  Name:
  Vince Darley

  ReproducibleScript:
  Any use of tk_chooseDirectory insists on returning an entirely uppercase version of what the user selects in the dialog, on Windows 98..  While the filesystem is case independent, it would be better to return (and display in the dialog) the actual case-dependent name...



  This looks to be an unforunate behavior of the chosen native
  dialog on Windows (Win32 API).  On NT, you get case preservation.
  The user may be able to get the properly cased name again by
  using file attributes. 
  -- 02/10/2000 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: 220279ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Invalid
title: tk_chooseDirectory Crashes
comment:
  OriginalBugID: 4177 Bug
  Version: 8.3
  SubmitDate: '2000-02-14'
  LastModified: '2000-04-12'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows 95
  OSVersion: Win 95 4.00.950 C
  Machine: 90 MHz Pentium, Intel motherboard (Gateway)
  ClosedDate: '2000-04-12'


  Name:
  John Blattner

  Extensions:
  none

  CustomShell:
  While I have made minor mods in the version which generates debug info (redefined the lib search path, removed the "info body" command, the same problem occurs with downloaded Scriptics executable.

  ReproducibleScript:
  tk_chooseDirectory works fine on one machine (Win98)

  On another machine (Win95 - 4.00.950 C), it crashes when I simply start wish, and enter "tk_chooseDirectory" in the console window.  I took the following precautions to make sure that other tcl versions / builds on the machine wouldn't interfere with the tcl/tk installation.

  1. Checked the registry to make sure that no HKEY_LOCAL_MACHINE/SOFTWARE/Scripts keys previously existed.

  2. Installed tcl/tk 8.3.0 from the Scriptics self-installing executable.  At this point, the registry now contained HKEY_LOCAL_MACHINE/SOFTWARE/Scripts values.

  3. Modified autoexec.bat.  The Wise installation script added the tcl/tk path to the end of my path.  I modified autoexec.bat to place the tcl/tk path at the beginning of the path (restarted machine, verified with "puts $env(PATH)").

  4. Started Wish.  Entered "tk_chooseDirectory".  Crash occured.

  ObservedBehavior:
  The following debug information was generated by compiling (a very slightly modified) version of tcl/tk 8.3.0 in debug mode using MSVC6.0, and then clicking on debug when the Access Violation message appeared at runtime.  If it would be helpful, I can back out our mods and recompile / rerun.

  CALL STACK =================

  ChooseDirectoryHookProc(HWND__ * 0x0000081c, unsigned int 273, unsigned int 16778377, long 2072) line 1172 + 6 bytes
  KERNEL32! bff7241d()
  ChooseDirectoryHookProc(HWND__ * 0x41180041, unsigned int 135797495, unsigned int 76087552, long 136053009) line 1096

  LOCAL VARIABLES ============

  - cdPtr0x000017a7
        interpCXX0017: Error: symbol "" not found
        lastCtrlCXX0030: Error: expression cannot be evaluated
        lastIdxCXX0030: Error: expression cannot be evaluated
  +    path0x000017b3 ""
              idCtrl1161

  FILE EDITOR  (tkWinDIalog.c, line 1172) =================

  if ((idCtrl != IDOK) || (notifyCode != BN_CLICKED)) {
      /*
       * OK Button wasn't clicked.  Do the default.
       */
      if ((idCtrl == lst2) || (idCtrl == edt10)) {
  cdPtr->lastCtrl = idCtrl; <============== PROBLEM LINE
      }
      return 0;
  }

  DesiredBehavior:
  On the Win98 machine, on starting wish and entering "tk_chooseDirectory", the directory selection widget appears, appropriately.



  (from the newsgroup)

  I played around with this in a previous version, and found that Win95 is changing the lCustData field, which is where cdPtr comes from:

  cdPtr = (ChooseDir *) ofnPtr->lCustData;

  I never reported it because tk_chooseDirectory wasn't supported at the time,
  and I upgraded to Win98 since then, and it works fine on 98 as you said.

  -- Tim Baker
  dbaker@direct.ca 
  -- 02/15/2000 ericm
  Verified on Win95 (only Win95 affected). 
  -- 04/07/2000 hobbs

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

  You can work around this by getting a new version of the common dialog files.  On our test machines, I was able to copy c:\windows\comdlg32.* from a Windows 98 machine to our Windows 95 machine, and this solved the problem.

  Of course, this may cause other problems, and you should check with Microsoft before making this sort of change to your system.  Or, you could upgrade to Windows 98/NT/2000.

  - eric

  -- 04/12/2000 ericm


tkt_uuid: 220280ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: wish -use doesn't work when use target is the root window
comment:
  OriginalBugID: 4205 Bug
  Version: 8.0.5
  SubmitDate: '2000-02-22'
  LastModified: '2000-03-06'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: redhat linux 6.1
  ClosedDate: '2000-03-06'


  Name:
  John Heidemann

  ReproducibleScript:
  #!/usr/bin/wish
  # Should create a red square in the corner of of the root when invoked
  # with "wish -use 0x26 script"  (assuming 0x26 is the root window,
  # as determined with xwininfo).
  # Instead, just makes a new toplevel.
  frame .g
  .g config -width 50  -height 50 -bg red
  pack .g

  ObservedBehavior:
  The script should allow one to write to the root window, but it just makes a new toplevel.

  DesiredBehavior:
  The script should allow one to write to the root window, but it just makes a new toplevel.



  This is the correct behavior, as the root window is a special case
  and the window manager will handle it in its own way. 
  -- 03/06/2000 hobbs


tkt_uuid: 220281ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.1a2
resolution: Fixed
title: invalid extern declarations within functions / inconsistancies
comment:
  OriginalBugID: 4209 Bug
  Version: 8.3
  SubmitDate: '2000-02-22'
  LastModified: '2000-02-25'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  ClosedDate: '2000-02-25'


  Name:

  Jan Nijtmans


  ReproducibleScript:

  Just compile Tk 8.3.0 with gcc-2.95.2 and see what happens.


  Further on, the 3 platforms include different test code, depending on the TCL_TEST symbol which is not used in Tk. Looks like some cleaning-up should be done. The patch shows how I think it should be, but I'm not 100% sure.


  ObservedBehavior:

  extern declarations shouldn't occur within function bodies. It's not ANSI-C, and gcc-2.95.2 rightfully complains about it.

  The fact that most other compilers accept it is no excuse.


  Patch:

  *** mac/tkMacAppInit.c.origThu Feb 10 09:53:06 2000

  --- mac/tkMacAppInit.cSat Feb 19 16:24:02 2000

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

  *** 26,42 ****

    #include "tclInt.h"

    #include "tclMac.h"


    #ifdef TK_TEST

    extern intTktest_Init _ANSI_ARGS_((Tcl_Interp *interp));

    #endif /* TK_TEST */


  - #ifdef TCL_TEST

  - extern intProcbodytest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  - extern intProcbodytest_SafeInit _ANSI_ARGS_((Tcl_Interp *interp));

  - extern intTclObjTest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  - extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  - #endif /* TCL_TEST */

  - 

    Tcl_Interp *gStdoutInterp = NULL;


    int TkMacConvertEvent _ANSI_ARGS_((EventRecord *eventPtr));

  --- 26,49 ----

    #include "tclInt.h"

    #include "tclMac.h"


  +     /*

  +      * The following #if block allows you to change the AppInit

  +      * function by using a #define of TCL_LOCAL_APPINIT instead

  +      * of rewriting this entire file.  The #if checks for that

  +      * #define and uses Tcl_AppInit if it doesn't exist.

  +      */

  + 

  + #ifndef TK_LOCAL_APPINIT

  + #define TK_LOCAL_APPINIT Tcl_AppInit    

  + #endif

  +     extern int TK_LOCAL_APPINIT _ANSI_ARGS_((Tcl_Interp *interp));

  + 

  + 

    #ifdef TK_TEST

  + extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));

    extern intTktest_Init _ANSI_ARGS_((Tcl_Interp *interp));

    #endif /* TK_TEST */


    Tcl_Interp *gStdoutInterp = NULL;


    int TkMacConvertEvent _ANSI_ARGS_((EventRecord *eventPtr));

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

  *** 105,111 ****

         */


        Tcl_FindExecutable(newArgv[0]);

  !     Tk_Main(argc, newArgv, Tcl_AppInit);

    }

    

    /*

  --- 112,118 ----

         */


        Tcl_FindExecutable(newArgv[0]);

  !     Tk_Main(argc, newArgv, TK_LOCAL_APPINIT);

    }

    

    /*

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

  *** 150,172 ****

         * where "Mod" is the name of the module.

         */


  ! #ifdef TCL_TEST

        if (Tcltest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

        Tcl_StaticPackage(interp, "Tcltest", Tcltest_Init,

                (Tcl_PackageInitProc *) NULL);

  -     if (TclObjTest_Init(interp) == TCL_ERROR) {

  - return TCL_ERROR;

  -     }

  -     if (Procbodytest_Init(interp) == TCL_ERROR) {

  - return TCL_ERROR;

  -     }

  -     Tcl_StaticPackage(interp, "procbodytest", Procbodytest_Init,

  -             Procbodytest_SafeInit);

  - #endif /* TCL_TEST */

  - 

  - #ifdef TK_TEST

        if (Tktest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

  --- 157,168 ----

         * where "Mod" is the name of the module.

         */


  ! #ifdef TK_TEST

        if (Tcltest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

        Tcl_StaticPackage(interp, "Tcltest", Tcltest_Init,

                (Tcl_PackageInitProc *) NULL);

        if (Tktest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

  *** unix/tkAppInit.c.origThu Dec  2 03:05:39 1999

  --- unix/tkAppInit.cSat Feb 19 16:30:50 2000

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

  *** 24,29 ****

  --- 24,51 ----

    extern int matherr();

    int *tclDummyMathPtr = (int *) matherr;


  +     /*

  +      * The following #if block allows you to change the AppInit

  +      * function by using a #define of TCL_LOCAL_APPINIT instead

  +      * of rewriting this entire file.  The #if checks for that

  +      * #define and uses Tcl_AppInit if it doesn't exist.

  +      */

  + 

  + #ifndef TK_LOCAL_APPINIT

  + #define TK_LOCAL_APPINIT Tcl_AppInit    

  + #endif

  +     extern int TK_LOCAL_APPINIT _ANSI_ARGS_((Tcl_Interp *interp));

  + 

  +     /*

  +      * The following #if block allows you to change how Tcl finds the startup

  +      * script, prime the library or encoding paths, fiddle with the argv,

  +      * etc., without needing to rewrite Tk_Main()

  +      */

  + 

  + #ifdef TK_LOCAL_MAIN_HOOK

  +     extern int TK_LOCAL_MAIN_HOOK _ANSI_ARGS_((int *argc, char ***argv));

  + #endif

  + 

    #ifdef TK_TEST

    extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));

    extern intTktest_Init _ANSI_ARGS_((Tcl_Interp *interp));

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

  *** 51,76 ****

        int argc;/* Number of command-line arguments. */

        char **argv;/* Values of command-line arguments. */

    {

  -     /*

  -      * The following #if block allows you to change the AppInit

  -      * function by using a #define of TCL_LOCAL_APPINIT instead

  -      * of rewriting this entire file.  The #if checks for that

  -      * #define and uses Tcl_AppInit if it doesn't exist.

  -      */

  -     

  - #ifndef TK_LOCAL_APPINIT

  - #define TK_LOCAL_APPINIT Tcl_AppInit    

  - #endif

  -     extern int TK_LOCAL_APPINIT _ANSI_ARGS_((Tcl_Interp *interp));

  -     

  -     /*

  -      * The following #if block allows you to change how Tcl finds the startup

  -      * script, prime the library or encoding paths, fiddle with the argv,

  -      * etc., without needing to rewrite Tk_Main()

  -      */


    #ifdef TK_LOCAL_MAIN_HOOK

  -     extern int TK_LOCAL_MAIN_HOOK _ANSI_ARGS_((int *argc, char ***argv));

        TK_LOCAL_MAIN_HOOK(&argc, &argv);

    #endif


  --- 73,80 ----

  *** win/winMain.c.origThu Dec  2 03:05:46 1999

  --- win/winMain.cSat Feb 19 16:27:58 2000

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

  *** 34,47 ****

    static voidsetargv _ANSI_ARGS_((int *argcPtr, char ***argvPtr));

    static voidWishPanic _ANSI_ARGS_(TCL_VARARGS(char *,format));


  ! #ifdef TK_TEST

  ! extern intTktest_Init(Tcl_Interp *interp);

  ! #endif /* TK_TEST */


  ! #ifdef TCL_TEST

  ! extern intTclObjTest_Init _ANSI_ARGS_((Tcl_Interp *interp));

    extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  ! #endif /* TCL_TEST */


    static BOOL consoleRequired = TRUE;


  --- 34,65 ----

    static voidsetargv _ANSI_ARGS_((int *argcPtr, char ***argvPtr));

    static voidWishPanic _ANSI_ARGS_(TCL_VARARGS(char *,format));


  !     /*

  !      * The following #if block allows you to change the AppInit

  !      * function by using a #define of TCL_LOCAL_APPINIT instead

  !      * of rewriting this entire file.  The #if checks for that

  !      * #define and uses Tcl_AppInit if it doesn't exist.

  !      */

  ! 

  ! #ifndef TK_LOCAL_APPINIT

  ! #define TK_LOCAL_APPINIT Tcl_AppInit    

  ! #endif

  !     extern int TK_LOCAL_APPINIT _ANSI_ARGS_((Tcl_Interp *interp));

  ! 

  !     /*

  !      * The following #if block allows you to change how Tcl finds the startup

  !      * script, prime the library or encoding paths, fiddle with the argv,

  !      * etc., without needing to rewrite Tk_Main()

  !      */

  ! 

  ! #ifdef TK_LOCAL_MAIN_HOOK

  !     extern int TK_LOCAL_MAIN_HOOK _ANSI_ARGS_((int *argc, char ***argv));

  ! #endif


  ! #ifdef TK_TEST

    extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  ! extern intTktest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  ! #endif /* TK_TEST */


    static BOOL consoleRequired = TRUE;


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

  *** 74,101 ****

        int argc;

        char buffer[MAX_PATH+1];

        char *p;

  -     

  -     /*

  -      * The following #if block allows you to change the AppInit

  -      * function by using a #define of TCL_LOCAL_APPINIT instead

  -      * of rewriting this entire file.  The #if checks for that

  -      * #define and uses Tcl_AppInit if it doesn't exist.

  -      */

  -     

  - #ifndef TK_LOCAL_APPINIT

  - #define TK_LOCAL_APPINIT Tcl_AppInit    

  - #endif

  -     extern int TK_LOCAL_APPINIT _ANSI_ARGS_((Tcl_Interp *interp));

  -     

  -     /*

  -      * The following #if block allows you to change how Tcl finds the startup

  -      * script, prime the library or encoding paths, fiddle with the argv,

  -      * etc., without needing to rewrite Tk_Main()

  -      */

  -     

  - #ifdef TK_LOCAL_MAIN_HOOK

  -     extern int TK_LOCAL_MAIN_HOOK _ANSI_ARGS_((int *argc, char ***argv));

  - #endif


        Tcl_SetPanicProc(WishPanic);


  --- 92,97 ----

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

  *** 189,206 ****

    }

        }


  ! #ifdef TCL_TEST

        if (Tcltest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

        Tcl_StaticPackage(interp, "Tcltest", Tcltest_Init,

                (Tcl_PackageInitProc *) NULL);

  -     if (TclObjTest_Init(interp) == TCL_ERROR) {

  - return TCL_ERROR;

  -     }

  - #endif /* TCL_TEST */

  - 

  - #ifdef TK_TEST

        if (Tktest_Init(interp) == TCL_ERROR) {

    goto error;

        }

  --- 185,196 ----

    }

        }


  ! #ifdef TK_TEST

        if (Tcltest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

        Tcl_StaticPackage(interp, "Tcltest", Tcltest_Init,

                (Tcl_PackageInitProc *) NULL);

        if (Tktest_Init(interp) == TCL_ERROR) {

    goto error;

        }


  PatchFiles:

  unix/tkAppInit.c win/winMain.c mac/tkMacAppInit.c (talking about naming

      consistancy........)




  We do compile with gcc 2.95.2 and it makes no complaints that are
  mentioned above....  In fact, the comments don't seem correct at all.
  Also, the user is changing Mac files, where gcc is definitely not
  used.  This looks like a bad set of patches. 
  -- 02/25/2000 hobbs


tkt_uuid: 220282ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: BWidget Dialog does not appear when . is withdrawn
comment:
  OriginalBugID: 4221 Bug
  Version: 8.3
  SubmitDate: '2000-02-22'
  LastModified: '2000-04-19'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4266 4997 3597
  OS: Windows NT
  ClosedDate: '2000-04-19'


  Name:
  Carsten Lund

  Extensions:
  BWidget-1.2.1

  CustomShell:
  Both Tk and BWidgets are clean.

  Comments:
  If you deiconify . afterward the dialog appears.
      
      Debuging the problem a little it dialog is waiting in a "tkwait
      visibility .p"
      
      Looking through the BugDB is seems that it may have something to do with
      TR#3597
      I had the same problem using Window98, but not under unix.

  ReproducibleScript:
  package require BWidget
  wm withdraw .
  PasswdDlg  .p

  ObservedBehavior:
  The password dialog never appears

  DesiredBehavior:
  The password dialog appears.



  8.3 corrected the behavior of transients in Tk to correctly
  follow the style for MS Windows transients - if the parent is
  not shown, the child should not be shown.  This requires more
  correct coding for the users (it is no longer acceptable to
  expect a transient of a withdrawn window to be visible).

  We've made some changes for some base dialogs in Tk to
  account for this as well. 
  -- 04/19/2000 hobbs


tkt_uuid: 220283ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: "winfo children ." returns incorrect stacking order
comment:
  OriginalBugID: 4241 Bug
  Version: 8.3
  SubmitDate: '2000-02-25'
  LastModified: '2000-02-25'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  ClosedDate: '2000-02-25'


  Name:
  Roger Lucas

  ReproducibleScript:
  Open a WISH console and type the following :
  % toplevel .one
  .one
  % toplevel .two
  .two
  % raise .one .two
  % winfo children .
  .one .two
  % raise .two .one 
  % winfo children .
  .one .two

  ObservedBehavior:
  According to the help manual, "winfo children ." will return a list of the toplevel windows in their stacking order.  It does not.  It returns them in their creation order.  

  This is confirmed behaviour on both Windows NT and Windows 98

  DesiredBehavior:
  Please make the "winfo children ." command match the documentation, and return the toplevel windows in their stacking order.



  The docs here are unclear, but the extra note about toplevels is
  meant to say that they are handled (and returned) differently than
  other Tk widget children.  This works correctly for child widgets,
  but toplevels are returned in creation order because their order
  is really maintained by the window manager. 
  -- 02/25/2000 hobbs


tkt_uuid: 220284ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: Compiled Wish83.exe does not display console!
comment:
  OriginalBugID: 4260 Bug
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-02-28'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  Machine: Pentium PC, Win98 SE, NT 4.0 SP4
  ClosedDate: '2000-02-28'


  Name:
  Sage X

  CustomShell:
  None at all.

  ReproducibleScript:
  Download the stock Tcl/Tk 8.3.0 sources from scriptics and compile it.

  ObservedBehavior:
  The "console" and "consoleinterp" commands do not work at all.

  DesiredBehavior:
  The "console" command should work in the compiled wish. Since the "console" command works fine with the wish from the official scriptics binary distribution.



  The user needs to give more info.  This looks like user error
  now, because we just compile the binary from the sources like
  anyone else can... 
  -- 02/28/2000 hobbs


tkt_uuid: 220285ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: Tab key does not trigger "bind all <Key>" scripts
comment:
  OriginalBugID: 4347 Bug
  Version: 8.3
  SubmitDate: '2000-03-08'
  LastModified: '2000-03-10'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Linux-Red Hat
  OSVersion: Red Hat 6.1
  Machine: AMD K6 233 MHz
  ClosedDate: '2000-03-10'


  Name:
  Jeremy Henty

  Extensions:
  N/A

  CustomShell:
  None

  ReproducibleScript:
  Run wish from the command line.  Type "bind all <Key> { bell; } at the prompt.
  Move the focus to the wish window and start pressing keys, including Tab.

  ObservedBehavior:
  All keys *except* Tab cause the Tk bell to ring when typed into the wish window.
  NB: using "bind ." instead of "bind all" does not suffer from this problem.

  DesiredBehavior:
  The Tab key should ring the bell, just as the other keys do.



  From the "bind" manual entry:

         If  more  than  one binding matches a particular event and
         they have the same tag, then the most specific binding  is
         chosen  and  its script is evaluated.  The following tests
         are applied, in  order,  to  determine  which  of  several
         matching  sequences is more specific: (a) an event pattern
         that specifies a specific button or key is  more  specific
         than  one that doesn't; (b) a longer sequence (in terms of
         number of events matched) is more specific than a  shorter
         sequence;  (c)  if  the modifiers specified in one pattern
         are a subset of the modifiers in another pattern, then the
         pattern  with more modifiers is more specific.  (d) a vir-
         tual event whose physical pattern matches the sequence  is
         less  specific  than the same physical pattern that is not
         associated with a virtual event.   (e)  given  a  sequence
         that  matches  two  or  more  virtual  events,  one of the
         virtual events will be chosen, but the order is undefined.

  By default, Tk has the following binding set up:

  bind all <Tab> {tkTabToWindow [tk_focusNext %W]}

  This makes tab work for keyboard focus traversals.  When combined with a
  binding like

  bind all <Key> {bell;}

  the combination of the two falls under case (a) above:  the more specific
  binding <Tab> is evaluated and the <Key> binding is ignored.

  - eric

   
  -- 03/10/2000 ericm


tkt_uuid: 220286ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: "after" prevents user from switching to other applications in MacOS
comment:
  OriginalBugID: 4358 Bug
  Version: 8.3
  SubmitDate: '2000-03-10'
  LastModified: '2000-04-07'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: MacOS 8.6
  Machine: PowerMac G3
  ClosedDate: '2000-04-07'


  Name: Q. Alex Zhao

  ReproducibleScript:
  set i 0
  while { $i < 100 } {
  incr i
  puts $i
  after 1000
  }

  ObservedBehavior:
  The numbers were not printed out one-by-one: they were printed out all at once at the end of the loop. During the 100 seconds of when the loop was running, the system appeared to be stuck -- I couldn't switch to the Finder or any other application running at the same time.

  If I put the code in a proc (say "testAfter") and do a
  after 5000 testAfter
  and switch to the Finder before the callback is called, "wish" doesn't interfere with other application that much (the numbers will still be printed out at the end of the loop, though).

  DesiredBehavior:
  When a Tcl/Tk program is the foreground process, waiting for "after" callbacks should not prevent the user from switching to another process.



  This is due to the lack or true multi-tasking on the part of
  the Mac.  The user has essentially created an app with a tight
  loop.  You can rewrite this to reschedule the proc instead of
  waiting in the proc. 
  -- 04/07/2000 hobbs


tkt_uuid: 220287ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: The Entry widget w/ char limit.
comment:
  OriginalBugID: 4406 RFE
  Version: 8.3
  SubmitDate: '2000-03-20'
  LastModified: '2000-03-23'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  OSVersion: not OS version/type specific
  ClosedDate: '2000-03-23'


  Name:

  Huver Hu


  Comments:

  The patch addes "-maxchars N" config option to the Entry widget.

      The the C code merely deals with proper char counts in Insert and

      SetValue.

      Please note I have NOT tested with non-English language (it is "chars",

      not

      "bytes").


  DesiredBehavior:

  Although it now has "validate" hooks, it is desireable to specify config

  option that limits the number of chars an entry is to take.  Doing this in

  C code doesn't take that much, but saves a lot of scripts (and potential

  timing problems).


  Patch:

  *** tkUnixDefault.h.orig        Tue Nov 16 20:40:55 1999

  --- tkUnixDefault.h     Mon Mar 20 00:11:20 2000

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

  *** 159,164 ****

  --- 159,165 ----

    #define DEF_ENTRY_TAKE_FOCUS          (char *) NULL

    #define DEF_ENTRY_TEXT_VARIABLE               ""

    #define DEF_ENTRY_WIDTH                       "20"

  + #define DEF_ENTRY_MAXCHARS            "0"


    /*

     * Defaults for frames:


  *** tkEntry.c.orig      Tue Mar 14 23:46:35 2000

  --- tkEntry.c   Mon Mar 20 00:27:49 2000

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

  *** 114,119 ****

  --- 114,122 ----

                                   * scripts.  Malloc'ed, but may be NULL. */

        int prefWidth;            /* Desired width of window, measured in

                                   * average characters. */

  +     int maxChars;             /* -maxchars: Max number of chars allowed,

  +                                * excluding terminating null.  Zero means

  +                                * no limit. */

        char *scrollCmd;          /* Command prefix for communicating with

                                   * scrollbar(s).  Malloc'ed.  NULL means

                                   * no command to issue. */

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

  *** 308,313 ****

  --- 311,318 ----

    #endif /* ENTRY_VALIDATE */

        {TK_OPTION_JUSTIFY, "-justify", "justify", "Justify",

          DEF_ENTRY_JUSTIFY, -1, Tk_Offset(Entry, justify), 0, 0, 0},

  +     {TK_OPTION_INT, "-maxchars", "maxchars", "MaxChars",

  +       DEF_ENTRY_MAXCHARS, -1, Tk_Offset(Entry, maxChars), 0, 0, 0},

        {TK_OPTION_RELIEF, "-relief", "relief", "Relief",

          DEF_ENTRY_RELIEF, -1, Tk_Offset(Entry, relief), 

            0, 0, 0},

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

  *** 1686,1705 ****

                                   * string). */

    {

        int byteIndex, byteCount, oldChars, charsAdded, newByteCount;

        char *new, *string;


  -     string = entryPtr->string;

  -     byteIndex = Tcl_UtfAtIndex(string, index) - string;

        byteCount = strlen(value);

        if (byteCount == 0) {

          return;

        }


        newByteCount = entryPtr->numBytes + byteCount + 1;

        new = (char *) ckalloc((unsigned) newByteCount);

  !     memcpy(new, string, (size_t) byteIndex);

        strcpy(new + byteIndex, value);

        strcpy(new + byteIndex + byteCount, string + byteIndex);


    #ifdef ENTRY_VALIDATE

        if ((entryPtr->validate == VALIDATE_KEY ||

  --- 1691,1728 ----

                                   * string). */

    {

        int byteIndex, byteCount, oldChars, charsAdded, newByteCount;

  +     int nChars;

        char *new, *string;

        byteCount = strlen(value);

        if (byteCount == 0) {

          return;

        }


  +     /* check maxchars limit */

  +     if (entryPtr->maxChars > 0) {

  +       /* ignore appending to after chars limit. */

  +       if (index >= entryPtr->maxChars) return;

  +     }

  +     string = entryPtr->string;

  +     byteIndex = Tcl_UtfAtIndex(string, index) - string;

  + 

        newByteCount = entryPtr->numBytes + byteCount + 1;

        new = (char *) ckalloc((unsigned) newByteCount);

  !     if (byteIndex > 0) {

  !       memcpy(new, string, (size_t) byteIndex);

  !     }

        strcpy(new + byteIndex, value);

        strcpy(new + byteIndex + byteCount, string + byteIndex);

  +     nChars = Tcl_NumUtfChars(new, -1);

  + 

  +     if (entryPtr->maxChars > 0  &&  nChars > entryPtr->maxChars) {

  +       value = new + byteIndex;

  +       byteIndex = Tcl_UtfAtIndex(new, entryPtr->maxChars) - new;

  +       new[byteIndex] = '\0';

  +       nChars = entryPtr->maxChars;

  +       byteCount = strlen(new);

  +     }


    #ifdef ENTRY_VALIDATE

        if ((entryPtr->validate == VALIDATE_KEY ||

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

  *** 1725,1733 ****

         */


        oldChars = entryPtr->numChars;

  !     entryPtr->numChars = Tcl_NumUtfChars(new, -1);

        charsAdded = entryPtr->numChars - oldChars;

  !     entryPtr->numBytes += byteCount;


        if (entryPtr->displayString == string) {

          entryPtr->displayString = new;

  --- 1748,1756 ----

         */


        oldChars = entryPtr->numChars;

  !     entryPtr->numChars = nChars /*Tcl_NumUtfChars(new, -1)*/;

        charsAdded = entryPtr->numChars - oldChars;

  !     entryPtr->numBytes /*+*/= byteCount;


        if (entryPtr->displayString == string) {

          entryPtr->displayString = new;

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

  *** 1962,1974 ****

        char *value;              /* New text to display in entry. */

    {

        char *oldSource;

  ! #ifdef ENTRY_VALIDATE

  !     int code;


        if (strcmp(value, entryPtr->string) == 0) {

          return;

        }


        if (entryPtr->flags & VALIDATE_VAR) {

          entryPtr->flags |= VALIDATE_ABORT;

        } else {

  --- 1985,2015 ----

        char *value;              /* New text to display in entry. */

    {

        char *oldSource;

  !     char *new = NULL;

  !     int  code, nChars, byteCount;


  +     byteCount = strlen(value);

  +     if (byteCount == 0) {

  +       return;

  +     }

        if (strcmp(value, entryPtr->string) == 0) {

          return;

        }


  +     /* check maxchars limit */

  +     nChars = Tcl_NumUtfChars(value, -1);

  +     if (entryPtr->maxChars > 0) {

  +       if (nChars > entryPtr->maxChars) {

  +         nChars = entryPtr->maxChars;

  +         byteCount = Tcl_UtfAtIndex(value, nChars) - value;

  +         new = (char *) ckalloc((unsigned) (byteCount + 1));

  +         memcpy (new, value, (size_t) byteCount);

  +         new[byteCount] = '\0';

  +         value = new;

  +       }

  +     }

  + 

  + #ifdef ENTRY_VALIDATE

        if (entryPtr->flags & VALIDATE_VAR) {

          entryPtr->flags |= VALIDATE_ABORT;

        } else {

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

  *** 1982,1987 ****

  --- 2023,2029 ----

           */

          if (entryPtr->flags & VALIDATE_ABORT) {

              entryPtr->flags &= ~VALIDATE_ABORT;

  +           if (new != NULL) ckfree(new);

              return;

          }

        }

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

  *** 1990,2000 ****

        oldSource = entryPtr->string;


        ckfree(entryPtr->string);

  !     entryPtr->numBytes = strlen(value);

  !     entryPtr->numChars = Tcl_NumUtfChars(value, entryPtr->numBytes);

        entryPtr->string =

              (char *) ckalloc((unsigned) (entryPtr->numBytes + 1));

        strcpy(entryPtr->string, value);


        if (entryPtr->displayString == oldSource) {

          entryPtr->displayString = entryPtr->string;

  --- 2032,2043 ----

        oldSource = entryPtr->string;


        ckfree(entryPtr->string);

  !     entryPtr->numBytes = byteCount /*strlen(value)*/;

  !     entryPtr->numChars = nChars /*Tcl_NumUtfChars(value, entryPtr->numBytes)*/;

        entryPtr->string =

              (char *) ckalloc((unsigned) (entryPtr->numBytes + 1));

        strcpy(entryPtr->string, value);

  +     if (new != NULL) free (new);


        if (entryPtr->displayString == oldSource) {

          entryPtr->displayString = entryPtr->string;


  PatchFiles:

  unix/tkUnixDefault.h

      generic/tkEntry.c




  We're passing on this because it's essentially equivalent to:

  entry .e -validate key -vcmd {expr {[string length %P] < $maxchars}}

  and doesn't otherwise disturb validation.  It also leaves a bit
  confusing the question of why not take as many chars as possible,
  and just cutting off some when a large paste is done.  Another
  reason why this is best left at the Tcl level. 
  -- 03/23/2000 hobbs


