Newbie switching from TCL

[Robin Becker]

In article <8o0scj01hch at news1.newsguy.com>, Alex Martelli
<alex at magenta.com> writes
....
etc etc etc etc; crappy === baroque === perl === win32 or is that too
pre-modernist.

>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
>
>
>

-- 
Robin Becker