[interfacekit] Re: BHandler::fToken
- From: "Adi Oanca" <e2joseph@xxxxxxxxxx>
- To: <interfacekit@xxxxxxxxxxxxx>
- Date: Thu, 6 Mar 2003 15:38:16 +0200
> > 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.
> > When
> > BMessenger::SendMessage(BMessage* message1, BHandler*
> > relpyHandler,...)
> > sends a message, the reply is asynchronous! That means the looper that
will
> > receive this message will post a new one on our lopper's queue. That
means
> > that the reply message will be treated like all other messages. Well...
we
> > don't want that, because there is the replyHandler waiting for that
message.
>
> I don't get that. Why would would want to treat a reply message
> differently?
Sorry, my mistake! The reply messages is not treated differently!
Had to many on my mind then.
> > BMesseger::SendMessage(...) sends message1 to a (system-wide)
BLooper(not.
> > looper2), looper2 will send a reply, then dispatch the message (I don't
know
> > the order of those 2 operations).
>
> A message is dispatched, and if the no handler replies to that message,
> the looper sends a B_NO_REPLY (if necessary).
OK, thanks!, What I've wrote up here, was a quick thought.
>
> > [in looper2]
> > message1->SendReply( message2 );
> >
> > SendReply(...) will set the following fiends something like:
> >
> > message2->fTarget = message1->fReplyTo.target;
> > message2->fPreferred = message1->fReplyTo.preferred;
> > message2->fIsReply = true;
> >
> > message2->fReplyDone = true;
> > message2->fWasDelivered = true;
> > (I'm not sure about the last 2 lines)
>
> I think neither of the last two fields should be set to true. I think a
> `fReplyDone = true;' is done (on message1). fWasDelivered is currently not
> used in our implementation. I suspect, it must be set by BLooper, either
> before or after the message has been dispatched.
The 2 lines really meant nothing for this subject; I've just added them,
because they are linked somehow to a reply message! That is why a new line
is left blank between the first 3 and the last 2 lines.
>
> 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.
>
> 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" !!!
> 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...
> > 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 )?
Other related posts:
