[haiku-development] Re: Overview Messaging Application Kit
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 15 Jul 2007 15:19:32 +0200
On 2007-07-15 at 12:38:45 [+0200], Niels Reedijk <niels.reedijk@xxxxxxxxx>
wrote:
[...]
> I have a technical issue with the handling of handlers by BLooper
> (which might be a bug). In BLooper::AddHandler (line 320) a handler is
> chained to the last in the queue.
Actually there is no queue. There's the looper's list of handlers and there
are those NextHandler() chains, which usually form a tree.
> Say I have three handlers: A (the
> looper itself), B and C. Now I call A->SetNextHandler(C) (Handler.cpp
> line 296). This means A that if A doesn't handle the message, C will
> be next (as per Handler.cpp line 249). However, in line 1170 of
> Looper.cpp (in task_looper()), only one handler is called. If handler
> A is called, handler B will always be skipped. Is this the intended
> behaviour, or should BHander::SetNextHandler() or task_looper() make
> sure that always all handlers will be called?
>
> Same thing with setting a preferred handler by the way. If I set it to
> B, A will never be called.
A message always targets a single handler. The handler is either specified
directly or it is the preferred handler. In either case, this handler handles
the message. Only if it doesn't know what to do with it, the message is
passed on to NextHandler().
Generally the NextHandler() chain does not include all handlers belonging to
the looper. If you have a standard BLooper and add handlers without
explicitely invoking SetNextHandler() each of the handlers will only have the
looper itself as next handler. In case of a BWindow and BViews,
SetNextHandler() is used to mirror the BView hierarchy, i.e. the parent view
is the next handler. Thus messages not handled by a view are passed up the
view hierarchy.
CU, Ingo
Other related posts:
