[interfacekit] BHandler::fToken
- From: "Adi Oanca" <e2joseph@xxxxxxxxxx>
- To: "OBOS IK Team" <interfacekit@xxxxxxxxxxxxx>
- Date: Thu, 6 Mar 2003 00:23:25 +0200
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:
