[haiku-development] Re: A BMessage w/o a BApplication?
- From: fano il primo <fanoilprimo@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 29 Jan 2012 18:55:49 +0100
Ahh I *DO love* this API!
Let's see if I've understood correctly, sirs:
This is the MessageReceived of my main application (that's the class that
extended beApplication, a special case of BLooper as it is not a thread but
it's the main() that continues as an unique thread of execution, correct?):
MessageReceived(BMessage* msg) {
switch(msg->what) {
case btn1:
NetHandler->PostMessage(new BMessage(DO_SOMETHING), NULL);
}
And this my MessageReceived() of my looper class that is another thread in
the same memory space of my beApp:
MessageReceived(BMessage* msg) {
switch(msg->what) {
case DO_SOMETHIN:
/* well.. DO send something in the Network, right?
}
So this is the right way to do a BeOS / Haiku application, right? If I've
to do something with slow resource I have to use a thread or better a
BLooper... I love this! It's so... automatic and simple... in Windows or
worst in Linux you're very tempted to be lazy and use select() in your
MAIN()... and your GUI blocks!
Here, simply, I've BLooper already done... simply I'd read the Docs (and
surprising they are... and are clear, too!) and I'm ready to go...
Maybe the code in which the Message mechanics was re-implemented was in
Kernel code?
I'd suppose Kernel cannot use BLooper code... or it could?
On Sun, Jan 29, 2012 at 5:39 PM, Adrien Destugues <
pulkomandy@xxxxxxxxxxxxxxxxx> wrote:
> Le 29/01/2012 17:09, fano il primo a écrit :
>
>> So a BLooper can be instantiated in a thread, too?
>> But it's because I'm part of Haiku GUI application (there's a be->app()
>> declared in main())?
>>
>> If I've a commandline application but I want to have all the BMessage
>> thing, I could declare a BLooper and I'm done?
>>
>> So why it's not done in Haiku sources?
>> Too much overhead to use a BLooper in a thread?
>> Or hhere's some other reasoning do NOT do this?
>>
>> It will not be useful to have a wrapper class (part of the support kit or
>> maybe kernel kit)) already done for this... a more "/hakuish/" thread let
>> me say?
>>
> BLooper IS a thread. It's started when you call it's run method. I suggest
> you carefully study the be book pages about this :
> http://www.haiku-os.org/**legacy-docs/bebook/**TheApplicationKit_Overview_
> **Introduction.html<http://www.haiku-os.org/legacy-docs/bebook/TheApplicationKit_Overview_Introduction.html>
> http://www.haiku-os.org/**legacy-docs/bebook/**
> TheApplicationKit_Messaging.**html<http://www.haiku-os.org/legacy-docs/bebook/TheApplicationKit_Messaging.html>
> http://www.haiku-os.org/**legacy-docs/bebook/BLooper_**Overview.html<http://www.haiku-os.org/legacy-docs/bebook/BLooper_Overview.html>
>
> Using a BApplication in a command line application is also possible, and
> sometimes simpler. BLooper is useful when you want two threads, one for the
> UI and another for network stuff, for example. In this case processing
> network data should not block the UI part of the application.
>
> A BLooper allows you to receive messages, if that's all you need; but
> receiving messages from other applications (drag and drop, ...) need the
> app_server connexion, in that case you need BApplication. But you do not
> need any BWindow.
>
> The symmetry is as follow :
>
> BApplication is a BLooper
> BWindow is a BLooper. It is a BHandler for messages coming from
> BApplication, and forwards some of them to views
> BView (and subclasses) is a BHandler. It gets messages from the BWindow.
>
> It is possible to take control at various levels. Replace BApplication
> with your own looper if you don't need the app_server link ; replace
> BWindow (or add more BHandlers next to it) if you don't want UI. And you
> may even register custom handlers in the BWindow thread if you want so.
>
> --
> Adrien.
>
> you may create more sub
>
>
Other related posts:
