[interfacekit] Re: BHandler::fToken
- From: Erik Jaesler <erik@xxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Fri, 07 Mar 2003 11:34:27 -0800
First, apologies to Adi for not getting back to him. He mailed me some
time ago asking about this very issue, and after promising an
explanation, my life got a bit out of control. =P
BHandler::fToken is local to the application, and is used to identify
handlers for messaging purposes; in particular, when sending messages
between applications -- where using a raw pointer is not necessarily the
safest thing to do. Looking at my "musing on fToken" in Handler.cpp, I
can see that I need to do an update to better reflect this
understanding. At the time I wrote it, it seemed the token could/would
get used everywhere; clearly, this is not the case.
e
Adi Oanca wrote:
> Hello!
>
> [ this is an email that was originally written for DarkWyrm, but I decided
> to make it public, to see others opinions
>
> I'm not a natural English speaker, so POTENTIAL MISTAKES ARE EXCUSED!]
>
> Tell me something...
> Do you know what people say when, after hours of searching and studying,
> they find an
>
> answer to their problems?
>
> They say: EVRIKA!
>
> ...and, now, I say: EVRIKAAA! (or BINGOOO! :)
>
> 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!
>
> 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!
> 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.
>
> 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).
>
> [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)
>
> 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.
>
>
> 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!
>
> Well. after all this, it seems that tokens are created by the client-side
> and then sent to app_server!
>
> Am I wrong? Where?
> What is your opinion?
>
> bye!
>
>
>
Other related posts:
