Re: Winapi help (RE: [ANN] winapi 1.4)

[steve donovan <steve.j.donovan@...>]

On Tue, Jun 26, 2012 at 10:50 AM, Alexandre Rion <gaumerie@hotmail.com> wrote:
> It works perfectly. Good work!

Cool!  I like the idea of having a Window 'constructor' from HWND.
Windows handles are not pointers, so we should be ok with Lua.

Since the rest of the library is getting distressingly stable, there
is also winapi.thread which launches a new thread with a Lua
'daughter' state (that is, a coroutine. Hey, it was only 15 lines.)

https://github.com/stevedonovan/winapi/blob/master/examples/thread-test.lua

It appears safe to run straightforward Lua code in a separate thread,
and you can even set off a LuaSocket download in the background, but
no, it doesn't work with multiple HTTP requests unfortunately.
LuaSocket is just not thread-safe.

Reinventing Lanes does not seem to be a clever thing, so that's where
it will stay.

Anyway, the DLL is still under 50K so we've got room for anybody's
favourite Win API calls not used.[1] And there's scope for more
generality, eg. winapi.get_console() gets a File object for reading
and writing (which can be watched for the badly-named
wait_for_processes()) but only in line mode - a flag to set
single-character mode might be rather useful.

Another undocumented feature is winapi.open_serial(), which gets
passed a string like that accepted by the MODE command; with
read_async, that gives asynchronous serial I/O.

steve d.

[1] Except for actually putting up windows,  no matter how strong the
temptation when I'm writing little utilities for command-prompt-phobic
colleagues.