[interfacekit] Re: BHandler::fToken
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Fri, 7 Mar 2003 02:11:33 +0100 (MET)
On Thu, 6 Mar 2003, Adi Oanca wrote:
> > > I had a problem with BHandler::fToken.
> > > I needed to use that, but I didn't know if I was allowed to do whatever
> I
> > > want with it.
> > >
> > > After a loooong look over BHandler, BLooper, BApplication, BMessage I
> > > finally got the answer!
> > >
> > > NO! I cannot modify BHandler::fToken!
> >
> > Actually, I have not the faintest idea, why you would want to do that,
> > anyway.
>
> Ufff... long talk. Basically, because every BWindow and every BView have a
> counterpart in app_server, and there has to be a way for the pairs to know
> about each other.
> For example: when the user presses the mouse button in a window, the
> BWindow's counterpart(ServerWindow) receives a message, and then searches a
> Layer object(BView's counterpart) that contains the location where the mouse
> has been pressed. It then takes the ID(token) of this Layer object and sends
> it to BWindow's thread, as an attachment to a message(in this case
> B_MOUSE_DOWN). When BWindow will see that B_MOUSE_DOWN message has been
> received, it will search a view(of type BView) witch has the same
> ID(BHandler::fToken) as the one attached to message. It then calls the
> corresponding BView hook function.
For the window to identify the concerned view you could probably use the
pointer of the BView itself. It could be sent to the sent to the app
server on addition of the view to the hierarchy and passed back to the
window with each message for which it makes sense. This would be the
quickest way.
That could in principle be safe. If the need arises to have a means to
check whether the pointer is still valid, BTokenSpace could be extended to
provide a reverse mapping. Then one can be sure, that the pointer at least
refers to a valid BHandler, dynamic_cast it to a BView*, and an
invocation of Window() will reveal whether it's indeed a BView belonging
to the window.
[...]
> > Three things:
> >
> > 1) I have no idea, why we could want to change a handler's token.
>
> I needed and ID as I said, and I was wondering if BHandler::fToken is
> available.
It could, of course, be made available. It's probably not suitable for the
purpose the server token server, since, I suspect, the server token is
used to uniquely identify a view in the server, while the handler tokens
are unique only in the application.
> > 2) The R5 app server doesn't use messaging. It communicates with the API
> > classes via ports.
>
> Ingo... I AM WORKING on BWindow, do you think I didn't know that???
> I said "message", NOT "BMessage" or something about "messaging" !!!
Well, that wasn't that obvious to me. When using `message' in connection
with BHandler I usually think of a BMessage.
> > 3) Even if our app server would use messages -- which was possible, since
> > it links against libopenbeos, though I doubt DarkWyrm plans to do so -- I
> > still don't see the problem. I would simply use BMessengers
>
> In this matter I'm supporting DarkWyrm, for the simple reason that, there is
> no need to send additional data(BMessage's members) over the port. We will
> lose performance if we do that!
> Remember the number of data member that BMessage has! ... many many bytes...
That may be right. I wonder nevertheless, how e.g. a B_MOUSE_DOWN message
is sent, and by whom.
> > > Well. after all this, it seems that tokens are created by the
> client-side
> > > and then sent to app_server!
> >
> > The handler tokens are, no doubt, since they have nothing to do with the
> > app server. For the server tokens I don't know -- that's DWs department --
> > but at least the name `server token' suggests, that they are created
> > server side.
>
> Yes, True!, But, what if, and THIS I AM PROPOSING FOR DarkWyrm, when a
> BWindow, or a BView is created, in the constructor, after obtaining a token,
> in the creation message (something like AS_XXXX_CREATE) that will be sent to
> app_server, we will attach a int32 value = BHandler::fToken( this.fToken )?
That can be done instead of passing the pointer to the BView (as
proposed above). BTokenSpace would be used on client side to translate it
to a BHandler*, which can be casted to a BView*. That would work as well.
I wouldn't worry about the access to BHandler::fToken -- we can e.g.
introduce an adapter class for the private members of BHandler, as done
for BRoster with BRoster::Private.
CU, Ingo
Other related posts:
