On Tue, 30 Aug 2005, Micha Nelissen wrote:
> On Tue, 30 Aug 2005 11:09:30 +0200 (Romance Daylight Time)
> Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 30 Aug 2005, Micha Nelissen wrote:
> >
> > > What do you mean with Idle handler? TApplication.OnIdle ? In any sane app,
> > > that is only called once when the user goes idle; after that, the app is
> > > blocked waiting for user input.
> >
> > Hm.
> >
> > So that is not usable.
> >
> > On Unix, it's easy:
> >
> > I once wrote a GTK version of a debug server.
> > You can tell GTK to watch for input on a file descriptor in it's main loop.
> > If there is input on your descriptor, a callback you specify is called.
>
> Yes, this is used in the gtk widgetset interface in the LCL too, now;
> that's what WakeMainThread does there (send a byte down that pipe).
>
> > In windows, it's slightly more difficult (surprise, surprise :-) )
> >
> > You can use MsgWaitForMultipleObjects to do this for a windows
> > handle, or use WaitForSingleObject on a simple file handle.
>
> You can't "wait" for file handles in windows.
>
> OTOH, the backend of the IPC server will use messages to copy things
> around ? So the message queue would be woken up that way.
Yes.
>
> > (Why they made this two separate functions is a mystery to me,
> > it makes things horribly complicated...)
>
> Some threads have no message queue, so MsgWait... is more expensive, would
> require a message queue to be created.
>
> > So in fact, what we'd need is a pair of calls in TApplication :
> >
> > TApplication.AddWatch(AHandle: THandle; Handler : TNotifyEvent);
> > TApplication.RemoveWatch(AHandle: THandle);
> >
> > Which would handle both things transparantly in the message loop.
> > (the standard IsWindow function of Windows could be used to determine what
> > kind of handle it is in a windows app)
> >
> > This would come in handy in many applications.
>
> Hmm, I'm not sure. Can you give examples? A THandle is a widget-specific
> thingy, it doesn't have the same semantics on various platforms, so it's not
> directly usable by users of LCL (if you want one source code base).
>
> Things you could use this function for: file change notifications,
> events, ... all have to be seperately implemented in the FCL/LCL to make
> them work "universally" and well.
Seems so, yes.
Sebastian Guenther once started such a thing (fpAsync) but never managed
to get the windows side of things working, exactly because of the
different types of handle.
Michael.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
