Hi, I was just implementing BRoster::ActivateApp() and encountered two problems. Actually one oddity and one open question. The weird thing is that (with libbe) my test application class' AppActivated() isn't invoked. I create a standard window BWindow *window = new BWindow(BRect(100, 100, 200, 200), "roster-test", B_TITLED_WINDOW, B_QUIT_ON_WINDOW_CLOSE); window->Show(); and the B_APP_ACTIVATED messages appear in MessageReceived(), but AppActivated() isn't called. Here are the methods: virtual void MessageReceived(BMessage *message) { printf("TestApp::MessageReceived()\n"); BMessenger returnAddress(message->ReturnAddress()); printf("team: %ld\n", returnAddress.Team()); message->PrintToStream(); BApplication::MessageReceived(message); } virtual void AppActivated(bool active) { printf("TestApp::AppActivated()\n"); BMessage *message = CurrentMessage(); message->PrintToStream(); BMessenger returnAddress(message->ReturnAddress()); printf("team: %ld\n", returnAddress.Team()); } Do I miss anything, or is the R5 implementation buggy? If it is, do we mimic that behavior or e.g. call the hook method from BApplication::MessageReceived()? Now to the open question. The BeBook says in the AppActivated() description: `This function is called only if the app has an "activatable" windowi.e. a non-modal, non-floating window).' Let alone my problem described above, this does indeed happen -- i.e. I get the message only, if my app has an open window. The question is, how do we deal with that? This is obviously GUI related, but I can verify, that the B_ACTIVATE_APP messages are sent by the registrar. My first idea would be, that an application has to notify the registrar when the availability of the an "activatable" window changes -- this would be the push approach. But as the only BRoster method that seems to be related is UpdateActiveApp(team_id team), which has no further parameters that could tell the roster about anything, I think Be implemented pulling. That is, the roster either needs to ask the application itself -- but that does obviously make not much sense -- or the app server. In fact the application may not even have enough information. E.g. when the active window is closed/ minimized only the app server knows which window to activate next. I played around a bit and found out, 1) that the app receives its B_APP_ACTIVATED messages after the window has got its B_WINDOW_ACTIVATED and 2) that when overriding the window's DispatchMessage() and not passing B_WINDOW_ACTIVATED messages to the super class version, the application doesn't receive B_APP_ACTIVATED messages any more. That makes me believe, that BWindow::DispatchMessage() calls BRoster::UpdateActiveApp() which makes the roster have a look, whether this application has gained or lost "active" status and send a B_APP_ACTIVATED message to the application, if that's the case. Nevertheless the roster needs to get this information from somewhere... Any thoughts? CU, Ingo