ok thanks I finally did the event handling in the C part of the application
There is no official exposed framework, in part because, handling of window events is tricky and susceptible to user error and I don't want to land up supporting functionality that is hard for the user to get right. Having said that, you can see the implementation of register_hotkey as an example of how windows messages are handled. Note that is not intended for hooking arbitrary window but only messages received by a special internal use twapi window. If you are more specific about which windows...
Hi, Google AI engine returned an article describing how to use proc twapi::set_window_proc to process events but that procedure doesn't exist. I looked at all the twapi packages and I couldn't find anything equivalent. Is there a way to capture the events from a window with twapi? Thanks in advannce.
No good news. Im'm on Windows 11 pro. Locale ? I guess you mean the internationaizationl setting: currently set as Italy.
Aldo, anything further to report on this? I'm kind of stuck as to why this occurs on your system. Could you tell me what locale you are running under?
I'm using cmd.exe. Running c:\Tcl90\tclsh \tmp\x.tcl > output.txt or even c:\Tcl90\tclsh \tmp\x.tcl | more is OK, but this is not a full working solution ... I downloaded other tcl9.0 builds (from magicsplat), always with the same (bad) result. I will try to build Tcl9.0 by myself, but I suspect the problem is with the external MS dlls ... I'll keep you informed. Currently, working with Tcl9 on Windows is not a priority; since I'm developing various packages for Win/Mac/Linux and Tcl8/Tcl9, I need...
Very strange. There have been a few thousand downloads of 9.0 and no one else has reported this issue. As a first step to reproduce, what terminal/console are you using? cmd.exe, Windows Terminal or something else? Do other tcl 9.0 builds work (preferably if you can build tclsh yourself to check) ? What happens if you redirect stdout? For example, c:\Tcl90\tclsh \tmp\x.tcl > output.txt
Sorry, still the same error ... I have been working with TclTk 8.6.11 for many year (Magicsplat distro - installed under c:\Tcl) then I installed TclTk9.0.3 (Magicsplat distro) under c:\Tcl90 I can completeley unset the PATH and then run tvls86 or tclsh90 ... set PATH=Z:\dummy c:\Tcl\tclsh \tmp\x.tcl --> OK it works as expected c:\Tcl90\tclsh \tmp\x.tcl --> error writing "stdout": broken pipe .....
wish does not expect the stdout channel to be present, tclsh does. That's probably the difference. As to why stdout is not found or initialized, I am not sure. One possibility is that you have both tcl86 and tcl90 directories in your PATH environment variable. Could you check for that?
tclsh90.exe cannot start: broken pipe
Thank you! I tested briefly and no issues were found so far. On Fri, Sep 12, 2025 at 6:02 AM Ashok P. Nadkarni apnadkarni@users.sourceforge.net wrote: I have decided not to wait for tcllib releases. The 2.0.5 release should contain a repository snapshot that includes the fix. Please re-open if still not fixed. [tickets:#24] https://sourceforge.net/p/magicsplat/tickets/24/ untar still fails in 2.0.3 Status: open Milestone: 2.0.3 Created: Wed Jul 16, 2025 06:37 AM UTC by Michael Franz Last Updated:...
tclcompiler and tbcload mismatch in magicsplat 2.0.5
untar still fails in 2.0.3
I have decided not to wait for tcllib releases. The 2.0.5 release should contain a repository snapshot that includes the fix. Please re-open if still not fixed.
Default opening method of `.tclapp` files doesn't pass command line arguments
correct; that was the case, but I can no longer reliably reproduce the oproblem, thus just cllose this as "resolved". more info: I realized I also had MagicSplat Tcl+Tk 8.9..* installed (I saw it in my error/install logs while trying to get my exact window and Tcl+Tk versions.)
Just to confirm, you are using 8.6.15 and seeing the problem only if you write a .tclapp file and try to execute it, right?
It might also help mentioning, I do not have any problems if I execute "tclsh" or "wish" from the "cmd prompt", then "source" my files. It only gives me problems when I try to execute a *.tclapp or a *.tkapp from the command line (using the command line assoc's set up by MagicSplat. I checked them as well, and see nothing unusual or wrong with them, either.
from the command line: ver Microsoft Windows [Version 10.0.26120.1542] tclsh % info patchlevel 8.6.15
from the command line: ver Microsoft Windows [Version 10.0.26120.1542] tclsh % info patchlevel 8.6.15 9.
from the command line: ver Microsoft Windows [Version 10.0.26120.1542] tclsh % info patchlevel 8.6.15 9.
Please understand, I am disabled, and struck in a nursing home, so it is very difficult for me to find and provide the requested details. What I have done in the past is write a simple Tcl script to open potential (.tcl, .tclapp, .tk, and .tkapp) problem files, read them in binary mode to check the first 2, 3 or 4 bytes for a BOM: -- UTF-8 :: 0xEF 0xBB 0xBF -- UTF-16 LE :: 0xFF 0xFE -- UTF-16 BE :: 0xFE 0xFF -- UTF-32 LE :: 0xFF 0xFE 0x00 0x00 -- UTF-32 BE :: 0x00 0x00 0xFE 0xFF Unfortunately, I...
Also, it would be useful to know the Windows version (full, not just Win10 etc.) as shown by winver.
The magicsplat distribution does not in any form change the upstream releases in terms of the file encodings of scripts or other such aspects. Automating such changes is surprisingly tricky and would require comprehensive test coverage of every package which magicsplat does not do, relying on the upstream testing. Having said that, if you can provide some detail as to what exactly these "issues" are, tickets can be logged against the appropriate packages. Do you see these errors on some package require...
My suggestion is to ensure all the distro files are plain old 7-nit ASCII files, using "\uXXXX" style escapes where unicode chars are absolutely needed. (I personally cannot think of any cases where any kind of 8-bit character encoding is absolutely needed in the core distro.) I caught this issue because my text editor (Edit Pad Pro 7) is somewhat Unicode capacle and aware, and the error popup (on Windows) is something like: "invalid command name: \" ...\" while executing ...", which happens to...
Also, note that the BOM is NOT in any of the files I created/my source code: my editor has a toolbar that allows my to add/strip any BOM at will, and I have made certain that none of my source files have no BOM. It seem that at least one file in the MagicSplat distro is the problem, as I have a standard (plaijn ASCII) header in all my files, and the tracing I could do, show the problem occurs long before my file is even sourced in Tcl/Tk. As best as I can figure out, the MagicSplat Tcl/Tkinitialization...
I continue to have issues with getting MagicSplat Tcl/Tk running correctly on Windos. The problem appears to be how some files are not plain ASCII/7-bit, but encoded in some other format and have a BOM (Byte Order Marker) embeded in the first few bytes of the file. What happens is Tcl/Tk immediately dies with an error on these files because it is trying to interpret the BOM as a command instead of as it is intended: a BOM. My suggestion is to ensure all the distro files are plain old 7-nit ASCII...
I continue to have issues with getting MagicSplat Tcl/Tk running correctly on Windos. The problem appears to be how some files are not plain ASCII/7-bit, but encoded in some other format and have a BOM (Byte Order Marker) embeded in the first few bytes of the file. What happens is Tcl/Tk immediately dies with an error on these files because it is trying to interpret the BOM as a command instead of as it is intended: a BOM. My suggestion is to ensure all the distro files are plain old 7-nit ASCII...
Thanks. I understand. Maybe also tcllib has to be released a bit more often (not easy...)
This is unfortunately an issue with tcllib vs magicsplat release cycles. Having been burnt before, I am reluctant to pick up the tcllib "trunk" when I release magicsplat and rely on the "official" tcllib releases. That means fixes in the tcllib trunk do not get picked up until its next release. Perhaps I need to rethink this stand.
Sorry, meant 2.0.4
untar still fails in 2.0.3
Debugger in tcl 9 package still has a default path of 86
Closing as it appears the issue is fixed with 9.0.2 as I could step through the above Tk test file. Please reopen if it persists.
TclProDebug does not run if directory path has spaces
Fixed in the magicsplat 2.0.4 distribution.
critcl is not installed in 8.6.15 and possibly 9.0.0
Fixed for 8.6.16.
Please try the attached tar.tcl (replace the one in packages) and see if it fixes this issue. If it does I'll submit to tcllib as a fix. "It worked on my machine" :-)
Thanks for logging the bug. Hopefully whoever owns that module will take a look. Else I'll try to track it down.
Thank you, I will take a deeper look in Bawt3D. Tcl/Tk needs a way to have better and open source distributions. Scilab for example is stuck on 8.5 I think.
It's a hodgepodge of batch files and manual process to pull from repositories I'm afraid and not structured enough for public consumption. If you want to build a distribution, I strongly suggest you look at Paul's BAWT system - see https://www.tcl3d.org/bawt/index.html - which is very well documented and complete. Regarding reviving packages for Tcl 9 etc., that would be really great but you can always do that by forking those repositories yourself. There has been some talk of setting up an organization...
I would like to know. Even better, a github repo could be created so as to be able to contribute, e.g. add packages like nsf or revive old ones and make compatible with tcl 9+
I saw there's a new download, and although it took a while for the installer to "initialise", it has now completed and my tcl code is working.
Michael, could you please log this latest failure in the tcllib ticketing system at https://core.tcl-lang.org/tcllib/ticket so the appropriate folks can take a look? /Ashok
Unfortunately now I see errors like this: expected integer but got a list expected integer but got a list while executing "format %d 0[string trim [set $x] " \x00"]" (procedure "readHeader" line 8) invoked from within "readHeader [read $fh 512]" (procedure "::tar::untar" line 22) invoked from within "::tar::untar $tn -dir [file rootname $tn]" (procedure "extract_bugreports" line 24) invoked from within "extract_bugreports" (menu invoke) Tried to compare tcllib 2.0 and 1.2. The changes are quite large...
Look like ::tar::untar in tcllib included with 9.0 uses no longer supported binary value
Look like ::tar::untar in tcllib included with 9.0 uses no longer supported binary value
Should be fixed now in the 2.0.3 release
icu.tcl is not included in Tcl9 installer
I downloaded tcl-8.6.14-installer-1.14.0-x64.msi which includes tclsh, the tk shell, and interpreter. I try out commands using the shell, then started with some sample code and adapted it to try out topics from a couple of tutorials I found online (although some of the code examples are old) I could run my tcl files from the windows command prompt, as parameters to tclsh, and then downoaded tclkit-gui-8_6_3-twapi-4_0_61-x86-max.exe to try out the mechanism before copying the files onto another PC....
Please clarify which specific version of the installer and platform (x86 or x64). I also do not understand the issue you are reporting. What is the exact error message and content of $::errorInfo? You say sqlite3 commands like create tables and insert work with the tcl shell and then say "error trying to use sqlite3" but then also say "trying to use tclsh or tclkit-gui to run the tcl code, works". So I am confused about exactly which commands do not work and with which program?
I downloaded the tcl86 windows install, and have tried the tclkit runtime, and both have worked OK so far, with simple tcl and some tk widgets to create Windows 'apps', but when I wanted to try using sqlite3, although the tcl shell works with sqliite3 commands to creae/open, create tables, insert data and 'select' results, I get an error when trying to use sqlite3, or "package require swlite3"! There's a Tcl86\lib folder "sqlite3.45.2", which has a "packageindex.tcl" file, but tring to use tclsh...
Indeed. The updated tcllib will be included in the next magicsplat release. Thanks
Look like ::tar::untar in tcllib included with 9.0 uses no longer supported binary value
Also, see this - https://github.com/apnadkarni/tcl-cffi/issues/144 If you are using tcl-cffi 2.0, please try the configure similar to this Ubuntu CI line - ../configure --with-tcl=${{ env.TCLDIR }}/lib --enable-64bit --disable-staticffi Let me know if you still have issues though I'm afraid I am not a Unix/gcc guru.
Also please post questions / issues related to tcl-cffi in its repository (https://github.com/apnadkarni/tcl-cffi) as this SF location is only used for distribution. Thanks
What version of tcl-cffi were you using?
libffi 3.4.4, 3.4.6, 3.4.6-r2
Sorry for my poor English. I have tried to compile this package in Linux localhost 6.12.3-gentoo-dist #1 SMP PREEMPT_DYNAMIC Fri Dec 6 13:30:20 -00 2024 x86_64 AMD Ryzen 5 5600G with Radeon Graphics AuthenticAMD GNU/Linux and got /usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../lib64/libffi.a(prep_cif.o): warning: relocation against `ffi_type_sint32' in read-only section `.text' /usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld:...