Known Bugs in TclPro 1.2

• 1.1 Known Bugs List
• 1.3 Known Bugs List

Known Bugs Index

1. TclPro 1.2

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. Scriptics License Server 1.2

2.1. I am using the Shared Network License. Why does the License Server report that another TclPro Debugger session has been launched when I open the Help and About TclPro Debugger box in TclPro Debugger?

Bub ID 1238
When you open the Help and About TclPro Debugger box, TclPro Debugger needs to contact the License Server to get the registered name so that it can display the name in the About box. This causes a confusion and the License Server treats the request incorrectly. The extra TclPro Debugger session will time out in about 5 minutes. Please note that this does not reduce the number of available licenses.

3. TclPro Debugger 1.2

3.1. Public itcl variables override local method variables

When running scripts in the debugger, if a public variable is defined in an itcl class and the same name is used for a variable in a local method, the value of the variable in the method is ignored. Instead of using the value of the local variable, the value of the public variable is used. For example, in you have the following script:

 package require Itcl 3.0

 class foo {
     public variable port 7000
     method addPort {port} {
         puts "port =  $port"
     }
 }

 foo fooObj

 fooObj addPort ::myPort

When the script is run in a tcl shell without using the debugger, the result is:

    port = ::myPort

When the script is run using the same shell in the debugger, the result is:

    port = 7000

3.2. When you change a project from "local" to "remote" (or vice versa) in the project settings, TclPro Debugger doesn't immediately register the change.

Bug 1090
If you open a "local" project and switch it to "remote", TclPro Debugger fails to listen on the remote port.

If you open a "remote" project and switch it to "local", the local script does not get read in, none of the toolbar buttons are enabled, and TclPro Debugger is still listening on the previously specified remote port.

Work Around:

After changing a project from "local" to "remote" (or vice versa), close the project (saving its new contents) and then re-open the project. TclPro Debugger will then register the change properly.

3.3. Selecting Restart after editing the script being debugged does not update the script in the code window

Bug ID 1313
If you have edited your script and select Restart, TclPro Debugger does not update the copy of the script in the code window.

Work Around:

You can kill the application and select Run or Step In. This will update the code window to show the edited script. The difference between selecting Run and Step In is that Run will run the application until it reaches a breakpoint while Step In will cause TclPro Debugger to stop at the first line of the script.

3.4. 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.

3.5. 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.

3.6. 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.

3.7. 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.

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

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

1. When the project is open but the application is not running.
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 be set where they are ignored by TclPro Debugger. You can remove them by deleting them from the Breakpoint window.

3.9. 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.

3.10. 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.

3.11. 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.

3.12. 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.

4. TclPro Checker 1.2

4.1. 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

4.2. 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.

5. TclPro Compiler 1.2

5.1. The -prefix tag option does not extract the prefix from the input file.

Bug ID 1123
When using this option with procomp, the information in the input file is not prepended to the output file. The workaround is to edit the output file to add the desired information.

6. TclPro Wrapper 1.2

6.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.

6.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.

7. [incr Tcl] 3.0

7.1. Running [incr Widgets] Catalog demo results in a Tcl stack trace.

Bug ID 1040
When running the Incr Widgets Catalog program, I get an error while autoloading "iwidgets::panedwindow": invalid command name "class".

Work Around:

Add the following lines of code to the beginning of the file /lib/iwidgets3.0.0/demos/catalog

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

7.2. 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

7.3. 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