[interfacekit] Re: BHandler::fToken

On Wed, 12 Mar 2003, Marc Flerackers wrote:

> It is indeed the event port of BWindow that gets the event messages from the
> app_server, but they arrive as normal flattened BMessages.

I'm curious: Do you know any reason for using flattened BMessages? AFAIK
(unlike ours) the R5 app server is not linked against libbe and therefore
has to do similar hackery as the kernel to produce those. I would
understand this, if the messages were sent to the looper port directly.
Any reason for not doing this, BTW?

> I will try to explain how I think it happens in R5 :)
>
> To begin the story, a BView is created on the client side, since it is
> derived from BHandler, it gets a handler token, which is a unique identifier
> for the BView in the BApplication. At a certain moment, it gets attached to
> a BWindow (AddChild). By getting attached, it gets a counterpart on the
> app_server. The BWindow takes care of this, by sending the necessary command
> through the session port (view_builder), one of the parameters of this
> command is the handler token.

I wondered, how BView/BWindow could get the token of a BHandler, since
neither is a friend of it, but it seems I overlooked the inline friend
function `int32 _get_object_token_(const BHandler* )'. BTW, I'd propose to
drop all current friends and introduce a single friend class
BHandler::Private (similar to BRoster::Private), which bundles the
private member access.

> On the app_server side, the command and the parameters are read from the
> port, and a server view is created. This server view knows its counterpart
> on the client by it's handler token. When the server view is created, the
> server window writes the server_token to the port.
>
> The BWindow reads this server_token from the port and stores it in the
> BView.
>
> Now a user suddenly moves the mouse over the view. The input server notices
> the move, and notifies the app_server of this event. The app_server looks
> through its server windows, and finds the one the mouse is over. It then
> passes the message to this server window. The server window replaces the
> point, which is in screen coordinates, to one that is in window coordinates.
> It then searches the server view on which the mouse is over. It sets the
> target of the message to the handler token of the BView counterpart of the
> found window. Then it sends the message through the event port.
>
> The BWindow gets the message from the event port in task_looper, and puts it
> in the message queue. In BLooper the target of the message is determined, by
> looking up the handler token to get a BHandler*. From within BLooper
> BWindow::DispatchMessage is called with the message, and the handler (note
> that fLastMessage is set in BLooper before dispatching, and that the message
> is filtered if needed). The BWindow sees that it's a B_MOUSE_MOVED message,
> and calls do_mouse_moved(message, view), first dynamic casting the BHandler*
> to a BView*. Here the necessary data is extracted from the message to call
> BView::MouseMoved.
>
> I find this way of working very clean, and especially safe. As you can see,
> only once the view was searched through the tree, and the message went
> through the same processing pipeline as all other messages.

That clears things up quite a bit. The only thing I don't understand, is
why the message isn't sent to the looper port directly. Mmh, now I think
about it, is it maybe because the order of other commands sent to the
window and the messages must remain the same?

Moreover I still wonder, whether the server token for views is really
needed (i.e. internally in the app server). A server app local hash table
or a global one with a key including an app ID would be fine as well.

CU, Ingo

Other related posts: