ANNOUNCE: Tcl Windows API extension 1.0 Beta
pal...@yahoo.com
released. Project home page, including documentation,
examples and download links, is at:
http://twapi.sourceforge.net/
V1.0 Beta Changes
------------
Changes since V0.9 are primarily bug fixes and experimental COM client
support. See http://twapi.sf.net/versionhistory.html for a complete
list of changes.
IMPORTANT: There is one major backward-incompatible change.
The error class stored in errorCode when Windows encounters an error
has changed. In V0.9 and before, the error class was WINDOWS. To
prevent clashes with other extensions, the error class now used is
TWAPI_WIN32. Code that traps errors using pattern matching in try or
otherwise parses errorCode will need to be modified accordingly
TWAPI Summary
--------------
The Tcl Windows API (TWAPI) extension provides access to
over 350 functions in the Windows API from within the Tcl
scripting language. The extension targets the Windows NT
family (NT 4.0SP4+, Windows 2000, Windows XP and Windows 2003),
and is not supported on the Windows 95/98/ME platforms.
Currently functions in the following areas are implemented:
* System functions including OS and CPU information,
shutdown and message formatting
* User and group management
* Security and resource access control
* Window management - window attributes, position, size etc.
* User input: generation of key/mouse input and hotkey support
* Basic sound playback functions
* Configuration and control of Windows services
* Windows event log access
* Process and thread management
* Directory change monitoring
* Windows file and print network shares
* Drive information, file system types etc.
* Network configuration and statistics
* Network connection monitoring and control
* Clipboard access
* Console mode functions
* System performance data
* Window stations and desktops
* Internationalization
* Task scheduling
* Shell functions for shortcuts, themes, property dialogs
* COM client support
David Gravereaux
Hash: SHA1
pal...@yahoo.com wrote:
> IMPORTANT: There is one major backward-incompatible change.
> The error class stored in errorCode when Windows encounters an error
> has changed. In V0.9 and before, the error class was WINDOWS. To
> prevent clashes with other extensions, the error class now used is
> TWAPI_WIN32. Code that traps errors using pattern matching in try or
> otherwise parses errorCode will need to be modified accordingly
Ashok,
I was wondering if you could take the time to explain why your use of a
"WINDOWS" error class was creating problems with other extensions?
I just started using my own called, unfortunately, "WIN32" in a windows
only extension.
Let me guess, if large blocks of code are in a catch, one can't
determine the creator of the error should two extensions be using the
same error class?
FWIW, I made Tcl_Win32ErrId, Tcl_Win32ErrMsg, and
Tcl_Win32Error functions that are total mirrors of the core's
Tcl_ErrnoId, Tcl_ErrnoMsg, and Tcl_PosixError, respectively, and plan to
submit them to the patch tracker on SF.
http://iocpsock.cvs.sourceforge.net/*checkout*/iocpsock/iocpsock/tclWinError.c?revision=1.5
What's your opinion on having these available from the core as platform
export?
- --
David Gravereaux <davy...@pobox.com>
[species:human; planet:earth,milkyway(western spiral arm),alpha sector]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFFFMKylZadkQh/RmERAhUCAKCIIkHkktByj8U2idAYGW83rPVrpwCdEk8M
M66jYpDjM0lXe3+YpGq2FHU=
=BCiW
-----END PGP SIGNATURE-----
pal...@yahoo.com
> -----BEGIN PGP SIGNED MESSAGE-----
> I was wondering if you could take the time to explain why your use of a
> "WINDOWS" error class was creating problems with other extensions?
>
It wasn't actually creating any problems currently, but I was worried
about some other extension also using WINDOWS as the error class and
then having ambiguity about what the format of the rest of the
errorCode would be. Just trying to forestall any future issues...
> I just started using my own called, unfortunately, "WIN32" in a windows
> only extension.
>
> Let me guess, if large blocks of code are in a catch, one can't
> determine the creator of the error should two extensions be using the
> same error class?
>
Exactly. When TWAPI generates a Win32 error, the second element is a
numeric error code as opposed to a symbolic token like is done for the
POSIX case, the third element also has a specific format for COM
errors. Other extensions would most likely not follow the same format
so I thought it bese to separate it out into a TWAPI_WIN32 error code
"namespace".
> FWIW, I made Tcl_Win32ErrId, Tcl_Win32ErrMsg, and
> Tcl_Win32Error functions that are total mirrors of the core's
> Tcl_ErrnoId, Tcl_ErrnoMsg, and Tcl_PosixError, respectively, and plan to
> submit them to the patch tracker on SF.
>
Sound like a good idea. Ideally, in addition to the stock WIN32 errors,
these should also be able to handle/translate errors from COM,
netmsg.dll and pdh.dll and maybe some other "system" dlls
/Ashok
David Gravereaux
Hash: SHA1
TIP #281 now open.. The TIP itself could use more prose regarding the
explanation, but I'm spending my time working on the implementation,
which isn't done yet..
- --
David Gravereaux <davy...@pobox.com>
[species:human; planet:earth,milkyway(western spiral arm),alpha sector]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFFK/X2lZadkQh/RmERAhBUAKDiUuHzZICxS/2dq183l4qGK9e2yACg4oKJ
galoeHqwP34Vtoz8J7TjVlQ=
=huN4
-----END PGP SIGNATURE-----