[interfacekit] Re: BHandler::fToken
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: OBOS IK Team <interfacekit@xxxxxxxxxxxxx>
- Date: Thu, 6 Mar 2003 11:53:18 +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.
> Now, I will explain why. If u know, skip over the following section.
> -----------
> I knew that in a BApplication every BHandler has a unique ID(token),
> assigned by its constructor, I knew that every BWindow and BView have an
> associated app_server token, but I did not understood, what classes derived
> from BHandler should do with it!
I don't understand you problem. The handler token has nothing to do with
BView::server_token, nor with the app server at all.
> Then, after studying
> BMessenger::SendMessage(BMessage* message1, BHandler* relpyHandler,...)
> BMessage::SendReply(BMessage* message2,...)
>
> I finally got the answer!
>
> 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?
> When this function executes, it calls
> BMessenger replyMessenger( replyHandler );
> BMessenger::SendMessage(BMessage* message1, BMessenger*
> relpyMessenger,...),
>
> that does(not directly):
> message1->fReplyTo.target = replyHandler::fToken
> message1->fReplyTo.preferred = false;
> message1->fReplyTo.port = Looper()::fMsgPort;
> message1->fReplyTo.team = Looper()::Team();
>
> message1->replyRequired = true;
>
> 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).
> [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.
> when this message gets to BLooper::task_looper(), its
> message1->fReplyTo.preferred (witch is false)
> field will say that a Handler whose
> fToken field equals message2->fTarget
> will have to be found! Then, the replyHandler receives the message.
That's how it works.
> And that is a possible way a BMessage::SendReply(...) could function.
> ---------------------
>
> As I said we cannot change BHandler::fToken. That means, that, when a Window
> or a View is created, in the message that BWindow will send to app_server,
> there has to be attached an additional field (a int32) denoting the
> inherited BWindow::fToken/BView::fToken. We also have to change the specs we
> wrote!
Three things:
1) I have no idea, why we could want to change a handler's token.
2) The R5 app server doesn't use messaging. It communicates with the API
classes via ports.
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
> 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.
CU, Ingo
Other related posts:
