ANNOUNCE: Tcl Windows API extension V0.2
Ashok P. Nadkarni
Project home page, including documentation, examples and download
links, is at http://twapi.sourceforge.net. See
http://twapi.sourceforge.net/versionhistory.html for a list of changes
since V0.1.
The Tcl Windows API (TWAPI) extension provides access to functions in
the Windows API from within the Tcl scripting language. The extension
targets the Windows NT family (NT 4.0, 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:
- Operating system and processor information - version information,
performance data etc.
- User and group management
- Security functions - access control, authorization, impersonation
- Window management - retrieval and manipulation of window attributes,
position, size etc.
- Simulation of user input - generation of key and mouse input
- Sound playback - basic sound functions
- Windows services - configuration and control of Windows services
- Processes and threads - retrieving process and thread information,
termination of threads and processes, performance data
- Disk information - information related to disk usage, file system
types etc.
- Network shares - functions for managing Windows file and print
shares
Jean-Luc Fontaine
> Version 0.2 of the Tcl Windows API extension has been released.
> Project home page, including documentation, examples and download
> links, is at http://twapi.sourceforge.net. See
> http://twapi.sourceforge.net/versionhistory.html for a list of changes
> since V0.1.
Looks very promising, with very good documentation.
Thank you very much for making it available to all of us.
I was wondering: what is the difference between your implementation for
retrieving information (for example, getting system and processor
information) and a more generic approach using the PDH library?
Do you have any plan to implement an interface to PDH?
(if this sounds idiotic, please forgive me, as I am not a windows expert
in that area).
--
Jean-Luc Fontaine mailto:jfon...@free.fr http://jfontain.free.fr/
Roy Terry
How about the ability to define short-cut
keystrokes? That's currently in
"winutils" (David Gravereaux) but his implementation
requires itcl.
It's really nice to starting getting important
goodies in one package. Hmm, winico-type functionaliy would be
nice folded in also :-)
All the links to download/ expamples seem broken
at the moment. I will try later....
Cheers,
Roy
Ashok P. Nadkarni
> Looks very promising, with very good documentation.
> Thank you very much for making it available to all of us.
>
Thanks for the kudos on the documentation (although it still needs
significant work). Always the most painful part to work on so all
encouragement in that area much appreciated!
> I was wondering: what is the difference between your implementation for
> retrieving information (for example, getting system and processor
> information) and a more generic approach using the PDH library?
> Do you have any plan to implement an interface to PDH?
> (if this sounds idiotic, please forgive me, as I am not a windows expert
> in that area).
There is already an interface to PDH (see pdh.tcl) and the process /
processor /thread performance stuff is layered on top of that. The
reason it is not documented is that the PDH routines will likely be
significantly revised for the next release. If you want to play around
with it, (say for a WIndows version of MOODSS/MOOMPS :), you might
look through the pdh.tcl routines and how they are called from
osinfo.tcl and process.tcl. Alternately, you could directly call the
raw PDH Windows API routines. Do a "info commands twapi::Pdh* for a
list of what's implemented, and see the corresponding Windows SDK docs
for what each function does.
/Ashok
Ashok P. Nadkarni
Defining short-cut keys is however close to the top of the list. I'm
not sure about winico; doesn't Tcl 8.4 already have equivalent
built-in functionality?
/Ashok
Roy Terry <royt...@earthlink.net> wrote in message news:<3FF6D8D7...@earthlink.net>...
David Gravereaux
>Unfortunately, there are lots of API's still to be implemented!
>Defining short-cut keys is however close to the top of the list.
...
http://cvs.sourceforge.net/viewcvs.py/tomasoft/winutils/Hotkey.cpp?rev=1.10&view=markup
I don't know how you have your 'command protocol' arranged, nor what your
code looks like on the inside nor how you model async return of persistent
objects, but here's how I'm doing hotkeys (the non-Itcl way). One thread
per hotkey probably isn't a perfect model when it comes to resource usage,
but was the most simple. A single thread acting as the listener on all
WM_HOTKEY messages would be better. A better method for naming (and
picking) the virtual keys could use improvement.
I offer it, if it can help.
>Roy Terry <royt...@earthlink.net> wrote in message news:<3FF6D8D7...@earthlink.net>...
>> Thanks for adding sound playback!
>> How about the ability to define short-cut
>> keystrokes? That's currently in
>> "winutils" (David Gravereaux) but his implementation
>> requires itcl.
...
No sense re-inventing persistent objects in yet another custom way.
Jean-Luc Fontaine
> There is already an interface to PDH (see pdh.tcl) and the process /
> processor /thread performance stuff is layered on top of that. The
> reason it is not documented is that the PDH routines will likely be
> significantly revised for the next release. If you want to play around
> with it, (say for a WIndows version of MOODSS/MOOMPS :),
What makes you say that? ;-).
Seriously, I was just curious at this time, since I have so many thinks
to do yet on Linux (the platform with the most potential ;-), but maybe
in the future, as I could use it at work.
Thanks again,
Ashok P. Nadkarni
internals (how do you feed events into an interpreter from a different
thread that handles callbacks?) so I'll take a look at your code.
Internally, I'm using SWIG so I have to figure out how that handles
callbacks as well.
/Ashok
David Gravereaux <davy...@pobox.com> wrote in message news:<glbevvc7k1qqnsubv...@4ax.com>...
David Gravereaux
>Thanks for the pointer David. I understand very little of the Tcl 8.x
>internals (how do you feed events into an interpreter from a different
>thread that handles callbacks?) so I'll take a look at your code.
In HotKeyListener::ThreadHandlerProc it first saves the reference to the
script Tcl_Obj, which is owned by the HotKeyListener instance so we let it
morph to bytecode, into a private queue, then zaps Tcl with Tcl_AsyncMark.
When the Tcl_AsyncProc comes around (FlushHotkeys/QueueAllPendingHotkeys),
the private queue is emptied and each Tcl_Obj reference is queue'd into the
Tcl's event loop with Tcl_QueueEvent. When the Tcl_EventProc comes around
(EvalCallback/EvalOneHotkey), Tcl_EvalObj is called on it.
It seems like a long trip, but its about the shortest possible. If we
always know that Tcl was compiled for threads we could use
Tcl_ThreadQueueEvent, but the 3 part way will work in either.
A similar trick is used in some of the windows channel drivers, but they
call Tcl_ThreadAlert instead because coming out of the wait the event loop
does, each channel's Tcl_EventCheckProc is called.