Newbie switching from TCL

[Alex Martelli]

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:6pe$9DAuq9o5EwJm at jessikat.demon.co.uk...
> In article <8o0e3c$7ls$1 at nnrp1.deja.com>, paulduffin at my-deja.com writes
> >In article <KqCqtKAJDVo5Ewvr at jessikat.fsnet.co.uk>,
> >  Robin Becker <robin at jessikat.fsnet.co.uk> wrote:
> >> In article <8nr6en0mh5 at news2.newsguy.com>, Alex Martelli
> >> <alex at magenta.com> writes
> >
> >> >(P.S.: Visual Basic does allow threading [reluctantly, and only
> >> >in recent releases], but event-handling is definitely at its core;
> >> >considering that it probably has more users than Tcl, Python, and
> >> >any one other scripting language you can name put together, it
> >> >might be considered "prominent"...).
>
> yes, but this is Win32 where visual basic only reluctantly allows
> threading and prefers to use events; it should be easy to do eventing

It is!  Easier than looping on a select, actually.


> why isn't it so for I/O. Seems like you can do select on sockets, but
> not anything else. Extremely selective and confusing design.

Yep, but 'select' is not the 'native' Win32 approach -- just an
emulation layer.  The native way is for example exposed via COM:
you RegisterBindStatusCallback on a IBindCtx ("bind-context"),
passing your own IBindStatusCallback instance, and you receive
callbacks on it, for methods such as OnProgress, OnDataAvailable,
etc, as the 'binding' of your monicker to the requested storage
object (or URL, or whatever) progresses.  No looping: you get
(COM) events fired right back at you.

At a lower level (kernel), you can for example CreateFile with
a FILE_FLAG_OVERLAPPED flag, then do your read and write with
an 'OVERLAPPED' structure which includes a handle-to-event --
the event object gets signaled with the I/O operation actually
terminates; you can also use ReadFileEx and specify the
'asynchronous completion routine' that will be called on
completion.  No looping: you get (kernel) events signaled
at you, and/or your designated routines called at event-time.

At a higher level, in Visual Basic, you typically use
AsyncRead on a UserControl or UserDocument object, and
receive AsyncReadProgress and AsyncReadComplete events
back from said object as the read progresses, then
completes.  No looping: you get (COM) events fired right
back at you.  Similarly, to work with sockets, event-wise,
you instantiate a Winsock Control COM object and then
sit back as it fires to you COM events such as DataArrival,
SendProgress, SendComplete, Connect, ConnectionRequest, ...

The design is indeed baroquely rich and complicated, as
is typical of Win32, particularly because there are so many
different conceptual levels at which you can approach it,
and they're not particularly well-delineated; post-modernists
that love Perl's TMTOWTDI should simply adore it:-P.

But it's simply, factually wrong to state that it isn't
easy to do eventing for I/O in Win32, and particularly
in Visual Basic.  'select' is not the only way to do
an 'eventing' approach to I/O.  Pity that win32com's
support for events (of the COM kind:-) is not quite
satisfactory (yet: there is still hope:-).


Alex