Known Bugs in TclPro 1.1

• 1.0 Known Bugs List.
• 1.2 Known Bugs List.
• 1.3 Known Bugs List.

Known Bugs Index

1. TclPro 1.1

1.1. conflicting DLLs: error finding an entry point in tcl80.dll

Bug ID 433
Note that this applies to Windows only.
A potential conflict exists if both TclPro and Tcl/Tk 8.0p2 are installed on a machine. If you create a TclPro extension, or generate a wrapped executable, you may not be able to run the executable: the system will pop a dialog box stating that some "procedure entry point ... could not be located in the dynamic link library tcl80.dll". This is because the runtime linker has found, and loaded, the 8.0p2 DLL instead of the TclPro one.

In order to understand this behavior, you need to know about the search algorithm for DLLs used by the LoadLibrary function. When the system loads a DLL, it searches for it in the following locations in this order:

1. the directory from which the executable loaded
2. the current directory
3. the system directories
4. the Windows directory
5. the directories listed in the PATH environment variable

The first match terminates the search. The location of the system directories and Windows directory change depending on whether you are on NT or 95. The TclPro DLLs are in the TclPro bin directory. If your application resides in a directory other than the TclPro bin directory, then steps 1 through 4 will not find a DLL, but 5 will because the TclPro bin directory was placed in your PATH at installation time. The correct DLL will be found. But if Tcl 8.0p2 is installed, a tcl80.dll exists in the system directory, and the runtime linker will succeed at step 3, but with the wrong DLL. Note that, if your application is in the TclPro bin directory, step 1 succeeds and the correct DLL is loaded.

3 Work Arounds:

1. Uninstall Tcl 8.0p2. This is the cleanest workaround, unfortunately it means you won't be able to use Tcl 8.0p2. But TclPro is still an 8.0 release, so that your scripts should work as they are if you use protclsh and prowish instead of tclsh and wish.

2. Install your Tcl 8.0p2 executables in the TclPro bin directory. If you do that, the correct DLLs will be found, and you can still use 8.0p2. The disadvantage of this workaround is that you have to place your binaries in the directory hierarchy of a third-party product, where you don't have as much control; maintenance may be more complicated.

3. Move the following files from the system directory to the Tcl 8.0p2 bin directory: tcl80.dll tk80.dll. This lets you keep the 8.0p2 distribution, and lets you place your executables in directories of your choice. The drawback is that now you may start having problems while running Tcl 8.0p2 executables, because under some conditions the 8.0p2 executables may load the TclPro DLLs. Here's how this could happen:

Assume that your TclPro distribution is in c:\TclPro and Tcl 8.0p2 in c:\Tcl. If your PATH environment variable contains neither c:\Tcl\bin nor c:\TclPro\win32-ix86\bin, the DLLs won't be found. If PATH contains only c:\Tcl\bin, your TclPro apps will show the "missing entry point" behavior described above. If PATH contains only c:\TclPro\win32-ix86\bin, the TclPro apps will work, but 8.0p2 apps will fail at startup time with the message that _Tcl_Main cannot be located in tcl80.dll. This is because the incorrect DLL was loaded. If PATH contains both, one or the other will fail depending on the order of c:\Tcl\bin and c:\TclPro\win32-ix86\bin: if c:\Tcl\bin is before c:\TclPro\win32-ix86\bin, 8.0p2 apps will work and TclPro apps will fail with the "missing entry point" error. If the order is reversed, TclPro apps will work and 8.0p2 apps will fail because the _Tcl_Main entry point can't be found.

If you decide on this third workaround, you may have to wrap your executables with a batch file that sets up PATH so that the correct DLLs are loaded.

1.2. I index my [incr Tcl] and [incr Tk] files with auto_mkindex, and some of my classes are not indexed correctly.

Bug ID 467
There are conditions under which methods or classes that live in separate files are not found when the program runs. If you look at the tclIndex file generated from indexing those files, it will not contain entries for the commands in question.

The problem is that auto_mkindex is set up to look for the [incr Tcl] commands in the itcl namespace. If the script does a "namespace import", auto_mkindex will notice this and correctly index the script. However, if the script only does a "package require Itcl" and relies on the "namespace import" in the pkgIndex.tcl file, auto_mkindex will fail to index calls to "class" that don't have the itcl namespace qualifier. So classes defined with "itcl::class" will get indexed, but classes defined with "class" will not.

2 Work Arounds:

1. The simplest solution to the problem is to ensure that every file that contains class definitions or bodies that should be indexed also contains the following lines at the top:

    package require Itcl
    namespace import -force ::itcl::*

or

    package require Itk
    namespace import -force ::itcl::*

This work-around has the disadvantage that your scripts have to be modified.

2. If changing your code as described in 1) is not feasible or desirable, then you can add the following line to the end of lib/itcl3.0/itcl.tcl:

    auto_mkindex_parser::slavehook {
        _%@namespace import -force ::itcl::*
    }

This will cause auto_mkindex to automatically import the itcl namespace before indexing a file. With this workaround, you don't need to modify your sources. However, you have modified a system file which is likely to be overwritten by updates to the TclPro distribution; it is your responsibility to make sure that your change is merged into later releases if necessary.

Once you have made one of the modifications described above, start protclsh or prowish and re-index your [incr Itcl] and [incr Tk] files.

1.3. Invoking prodebug, procheck, procomp, prowrap or prolicense on Linux may generate a core file.

Bug 979
Note this applies to Linux only.
Prodebug, procheck, procomp, prowrap, and prolicense are shell scripts which set environment variables and invoke the binary for the corresponding tools. If the environment variables SHLIB_PATH and LD_LIBRARY_PATH are not set when executing these scripts, a core file may generated. This bug does not affect the functionality of TclPro tools. The resulting core file can be deleted.

Work Around:

Set both the LD_LIBRARY_PATH and SHLIB_PATH environment variables. The following is an example of how to do so in the "sh" shell:

	LD_LIBRARY_PATH="/opt/scriptics/TclPro1.2/lib"
	SHLIB_PATH="/opt/scriptics/TclPro1.2/lib"

2. TclPro Debugger 1.1

2.1. TclPro Debugger should exit gracefully instead of giving an error message: can't read "sock": no such variable when a user tries to bring it up on a Windows 95 machine that does not have networking installed.

Bug 827
TclPro Debugger uses socket to communicate with the application you are debugging. This error is raised if you do not have networking installed on your machine. You can set up networking even though you do not have a network card by installing the Microsoft Dialup adapter and add the Microsoft TCP/IP protocol to this adapter.

2.2. The errorInfo variable is sometimes littered with debugger code.

Bug ID 147, 390
TclPro Debugger corrupts the errorInfo variable because internal routines show up in the error stack. This is a side effect of instrumentation. Just ignore the DbgNub stack frames.

2.3. no way to see the return value of the target application.

RFE ID 95
There is no way to see the return value of the target application.

2.4. no way to see the return value of the result of subexpressions while single stepping

RFE ID 24
The debugger does not display the result of subexpressions while single stepping. It also does not show the result of a proc invocation, source command, or the program exit code.

2 Work Arounds:

1. Assign each subexpression to a temporary variable so the result can be checked.

2. Alternatively, if the subexpression has no side effects, it can be cut and pasted into the eval console.

2.5. debugger stops more than once on a breakpoint line.

Bug ID 75
Line-based breakpoints cause the debugger to stop before executing each command and subcommand on the specified line. To avoid this bug, you can break Tcl statements across multiple lines so each command begins on a different line.

2.6. TclPro Debugger appears to ignore line breakpoints set before a script runs.

Bug ID 98
In some cases, the path of a file used by TclPro Debugger does not match that used by the program that sources the file. The result is that breakpoints set in the file before the program starts will not be triggered.

2 Work Arounds:

1. Make sure to open the file using the same path as the program uses.

2. Set breakpoints after the first time the file is sourced.

2.7. Hyphens should not appear on blank or comment lines.

Bug ID 795
There are two instances when this can happen:

1. When the application has just finished running and it is no longer instrumented.
2. When a file is opened via the "File", "Open" menu option.

The fact that the hyphens appear on these lines allows the breakpoints to set where they would be ignored by TclPro Debugger. You can remove them by deleting them from the Breakpoint window.

2.8. Incr Tk fails with error messages like: cannot use "_initOptionInfo" without an object context

Bug ID 471
[incr Tcl] must be loaded before Itk or there will be bad function pointer references internally due to a bug in [incr Tcl].

Work Around:

Ensure that itcl30.dll is loaded before itk30.dll. The easiest way to do this is to put "package require Itcl" before a call to "package require Itk". Note that the Iwidgets init code already does this so the problem is only likely to occur when Itk is being used without Iwidgets, or the code explicitly requires Itk before requiring Iwidgets.

2.9. debugger crashes shortly after I dismiss a parsing error in [incr Tcl] code

Bug ID 456
The instrumenter fails to reset some of the special handlers used to instrument itcl 3.0 code. If there is an error during instrumentation, things can get confused, particularly if you run an [incr Tcl] 3.0 script followed by an [incr Tcl] 2.2 script.

Work Around:

Run TclPro Checker on the script to find the bug, fix it, then quit and restart TclPro Debugger before running the fixed script in TclPro Debugger.

2.10. TclPro Debugger does not kill my remote applications.

Bug ID 204
Kill button does not necessarily kill remote applications. It merely closes the socket. This will typically cause an error in the client, so in some cases this does in fact kill the application.

2 Work Arounds:

1. call "exit" in the eval console.

2. Kill the client from the remote machine.

2.11. Misaligned icons in margin to the left of code.

Bug ID 92
Small fonts cause misalignment between lines of code and icons to the left of code. This problem also occurs in the variable, watch, and breakpoint windows.

Work Around:

Choose a font with a height that is larger than the height of the icons. You can change your font via the Edit | Preferences menu.

3. TclPro Checker 1.1

3.1. reports false "numArgs" error when upvar or lsort is called with a substituted switch

Bug ID 193, 301, 307
The following are examples of Tcl code that will cause TclPro Checker to erroneously report a "numArgs" error:

    upvar $level $varName var
    lsort $opt $l

The $level and $opt are legal and the "numArgs" error should be ignored.

3.2. reports false "badSwitch" error when lsearch or return arguments begin with '-'

Bug ID 294, 300
Whenever a command is called that accepts switches and arguments, TclPro Checker reports an error if the argument begins with a '-'. TclPro Checker erroneously assumes that this word is a switch because of the leading '-' character. The following are examples of Tcl code that will cause TclPro Checker to erroneously report a "badSwitch" error:

    lsearch {-one -two} $a
    return "-type cannot be changed"

3.3. reports false "badEvent" error for events Key-Page_Up and Key-Page_Down

Bug ID 267
TclPro Checker reports the "badEvent" error for the following commands:

    bind $w <Key-Page_Down> $script
    bind $w <Key-Page_Up> $script  

These events are only legal events on Unix systems, so TclPro Checker should flag a "nonPortEvent" warning instead of a "badEvent" error.

Work Around:

Ignore the "badEvent" warnings by using the "-suppress badEvent" switch on the procheck command line.

3.4. incorrect checking of the "event generate" command

Bug ID 459
If the <event> argument is missing but optional switches are passed as arguments, TclPro Checker does not flag a warning. TclPro Checker should warn that the event is missing in the following line of Tcl code:

    event generate . -keysym a

The correct composition of the "event generate" command is the following:

    event generate . <event> -keysym a

3.5. error location indicator (^) points to wrong location

Bug ID 332
When checking poorly formed lists or the list command called with a bad number of args, the error location indicator (^) does not point to the correct location in the command. For example:

Z:/ws/pro/srcs/checker/foo.tcl:3 (numArgs) wrong # args
tk_getSaveFile -filetypes x
^

The caret should point to the argument "x" indicating that the argument to the "-filetypes" flag, "x", should be a list containing more than one argument/element.

4. TclPro Compiler 1.1

5. TclPro Wrapper 1.1

5.1. file paths on prowrap command line must match the file paths accessed in Tcl code

Bug ID 397
The archive created to hold all wrapped files contains a file entry list. Each entry in the list has the file name pattern that matches exactly as it appeared on the "prowrap" command line used to wrap the application (except any stripping of leading "-relativeto" directory specification). During runtime of the wrapped application, any file reference to a wrapped file must have the exact pattern specification as that in the file entry list--no filename resolution is performed for either the file reference or the wrapped file name.

2 Work Arounds:

1. Change your Tcl code so that file references match exactly those in the file entry list on the prowrap command line. If the command line was written as "prowrap ../foo/foo.tcl" then use the following Tcl code to access the file:

    set prefix ../ 
    source [file join $prefix foo foo.tcl]

A caveat to this workaround is that you will need to choose a consistent file reference semantic for each access of a given file.

2. If you want to avoid changing your Tcl code at all costs, you can use this workaround: change the prowrap command line to match the file references made in code. If the following legacy code was written:

    file exists ./../foo/bar.tcl
    open ./bar.tcl
    file exists .././fuzz.tcl

(where the same bar.tcl file is accessed by 2 different paths) then the prowrap command line should should resemble the following:

    prowrap ./../foo/bar.tcl ./bar.tcl .././fuzz.tcl

The drawback to this workaround is that files may need to be wrapped multiple times, thereby enlarging your wrapped application.

5.2. Tcl "glob" command doesn't find files wrapped in an application

Bug ID 348
TclPro Wrapper does not support the "glob" command for retrieving a list of wrapped file name paths. The result of a call to the "glob" command will not include any files from the list of wrapped files.

Work Around:

Applications that depend on the "glob" command to produce arbitrary lists of wrapped files will need to be rewritten to produce explicit lists of wrapped files.

5.3. On Windows, invoking prowrap with the -verbose option fails if the files to be wrapped are located in the current working directory.

Bug ID 831
Note that this applies to Windows only.
When wrapping an application that includes files in the current working directory, prowrap adds an interim directory path to the wrapped set of files. In doing so, it attempts to add "." (the current working directory) which is incorrectly interpreted on Windows. This causes prowrap to terminate if the -verbose option is used.

5.4. Executing "package require Iwidgets 3.0" in a wrapped application loads both Iwidgets 2.2 and Iwidgets 3.0 libraries.

Bug ID 974
TclPro Wrapper automatically appends the following directories to the auto_path:

	lib/iwidgets2.2.0 
	lib/iwidgets2.2.0/scripts
	lib/iwidgets3.0.0
	lib/iwidgets3.0.0/scripts

This is done so that the user does not have to explicitly import the megawidgets after executing the "package require" command. The side effect of this implementation is that when a wrapped application is executed, the tclindex files located in these directories automatically populate the auto_index with both iwidgets 2.2 and iwidgets 3.0 information.

When a megawidget is created, the first match in the auto_index entries determines the file to be sourced. In this case, the iwidgets 2.2 library scripts are found first.

Work Around:

Add the following code to the beginning of the startup script (do not do this with the -code option):

    set auto_path [list lib/tcl8.0 lib lib/tk8.0 \\
			lib/tcl8.0/http2.0 lib/iwidgets3.0.0]

    # append other directories required by your application
    eval lappend auto_path $otherDirList

    auto_reset

6. [incr Tcl] 3.0

6.1. The Man Page tab in the [incr Widgets] Catalog program does not work

Bug ID 500
Selecting the Man Page tab in the [incr Widgets] Catalog program results in a stack trace. Besides the Catalog program, you can find the man pages at the following URL:

	http://www.tcltk.com/iwidgets

6.2. Incorrect permission on "mkinstalldirs" and "install.sh" files in the source directory for [Iincr Tcl] 3.0.1.

Bug ID 838
Note that this applies to Unix only.
The execution permission is not set for the following files:

<TclPro>/src/config/mkinstalldirs
<TclPro>/src/config/instal.sh

Work Around:

Add the execute permission as follows:

	% chmod +x mkinstalldirs
	% chmod +x instal.sh

This is the main Tcl Developer Xchange site, www.tcl-lang.org .    About this Site | [email protected]
Home | About Tcl/Tk | Software | Core Development | Community | Documentation