thanks nico,

well what im asking is similar to signals but not exactly that.
for example when a signal sent the signal handler is called without
any explicit call to it.(may be libc handles that)

what i want is a similar thing, rather than a signal(which is OS
specific) if i want some function to 'occur' rather than explicitly
calling it when some event happens.

found this article which seems to answer the question quite well
http://en.wikipedia.org/wiki/Callback_(computer_science)

btw, what i mentioned was C++ code, not VB


--- In [email protected], "Nico Heinze" <[EMAIL PROTECTED]> wrote:
>
> --- In [email protected], "Indika Bandara" <indikabandara19@>
> wrote:
> >
> > thanks nico,
> > just for curiosity .. can u tell me how are event handled in
> > Unix.. by signals ?
> > 
> > in some 3rd party libraries i have found things called
> > callbacks which come into action when an event occurs. for
> > example in a socket program there is a callback function
> > called onData() which gets triggered when data arrives.
> > how are these things actully implemented?
> <snip>
> 
> Brr, not that easy to answer...
> You have to distinguish (at least) two completely different kinds of
> events.
> First you have many GUIs (Graphical User Interfaces) which inform a
> user program about events, such as that a button has been clicked or
> so. This kind of events is usually brought to the attention of a user
> program by means of a so-called message queue (in Windows, X Windows,
> and [as far as I know] the MacOS Finder) or by directly invoking some
> callback functions (such as in Java and on many occasions under
> Windows [I don't know, but I think the same holds true for programs
> under X Windows]).
> 
> Second you have events such as signals. They are delivered to a
> program directly by the operating system. You have to write signal
> handlers to handle these events.
> 
> The name "onData()" suggests to me that this is a Visual Basic
> program. Visual Basic has its own mechanisms to hide the Windows
> message queue from a program, but it relies on this queue like
> (almost) every Windows program does.
> 
> That's all I can say about these things. I hope it helped a bit.
> 
> Regards,
> Nico
>


Reply via email to