Hello!
I'm trying to program a little GUI interface with MUI, but I've never used it before.
So with MOS SDK autodocs and the calculators examples I've tryed to open a window,
add buttons etc. Ok. But now, I'm not able to understand how to catch events...
I understand the "easy" mode, switching in a while loop between return IDs specified with
the DoMethod function but, when I try the OOP version using Dispatcher, also looking
at the examples (SDK + calc3 and following), I have some very big understatement problems!
Can I use dispatcher without using a custom class? What the h... are the absolute
hex address used in the header of some MUI examples found in internet?
Please, excuse me for those lame questions, but I'm absolutely new in programming MUI and
I have also a little experience with C, but it's a fact that the autodocs included in the
SDK are not so easy to understand! ;-(
Can someone give me a little help?
Thanx a lot and aloha!
Mauro

A dispatcher can only be used with a costum class. Doesn't mean that the class is reall that costum, you just have to declare it based on the standard-class closest to your need and only catch events that you either have to change, or that are newly introduced in your costum class.

Everything else can just be sent to the Base-class.

Every MUI-app needs atleast 1 costum class.

If your GUI doesn't need any other elements than those offered by the standard classes, you might want to make this class a simple notify-class, only collecting all user-inputs to compute whatever your app shall compute.

Don't know what you mean with hex-addresses, or is it that you are talking about the IDs for the class' attributes/methods

You can setup notification:

DoMethod(button, MUIM_Notify, MUIA_Pressed, FALSE, MUIV_Notify_Self, 2, MUIM_CallHook, &ButtonEventHook);

Now when ever button is pressed MUI calls specified hook for you. In MorphOS this hook must be trapped too.

Hook would be something like this:

struct Hook ButtonEventHook = { NULL, NULL, &ButtonEventTrap, NULL, NULL };
struct EmulLibEntry ButtonEventTrap = { TRAP_LIB, 0, &ButtonEvent };

void ButtonEvent(void)
{
PutStr("Button was pressed!\n");
}

Unfortunately this is not covered in calculator examples

Thanx 4 the replies!
As you said in the 2nd caluclator examples there are 10 lines + of
comments explaining the simple switch construct to catch the messages
imposed with DoMethod(), but in the 3rd example and in the followings
,sadly, there isn't a single line of remark to explain the
dispatcher-beast ;-(
Could someone try to do this?
Thanx a lot for your time and ciao to Itix and all the others
mos-programming-gurus

Hmmm .... not sure what you mean, but the "switch-construct" IS the dispatcher.

The "DISPATCHER"-line is just there for some technical details, which shouldn't bother you.

I must admit that it is getting a bit hard to help you aslong we don't know what you want to do in detail.

Dear Kronos, you are right and I apologize for that but, sometimes, I must post at work from a win box.
Now I'm at home with my miggy in front of me and I'll try to be more precise altough my english, as you may see, is far from perfection

Here a piece of code cutted from calc2 :

...
DoMethod(BT_Clear, MUIM_Notify, MUIA_Pressed, TRUE, MUIV_Notify_Application, 2, MUIM_Application_ReturnID, CLEAR_ID);
...

while ((retval = DoMethod(app, MUIM_Application_NewInput, &signals)) != MUIV_Application_ReturnID_Quit)
{
switch (retval)
{
case CLEAR_ID : CalcClear(); break;
...
In this exemple, we parse the Method ID to catch a button pressed by the user but, as stated also in the remarks of the example, "ReturnIDs is not recommended way to do it but let's keep it simple, ok?".
Now we want to make it more complex (I'm masochist and make the parsing of the return id's more OO. So, let's take a look at calc3 source where the calculator itself is build as a custom class.
We have the usual DoMethod
...
DoMethod(BT_Clear, MUIM_Notify, MUIA_Pressed, TRUE, obj, 1, MUIM_Calculator_Clear);
...

then we have (AAARGHH) the dispatcher:

...
DISPATCHERPROTO(MCC_Dispatcher)
{
...

switch (msg->MethodID)
{
...
case MUIM_Calculator_Clear : return CalcClear (data);
...
}

return DoSuperMethodA(cl, obj, msg);
}
My answer is: if I don't want to build a custom class, how have I to use the Dispatcher?
And if I'm forced to build a new class, where could I find some basic hints to do that? Reading MUI autodocs in the SDK make me feel a little crazy... ;-(
Again thanx for your replies and excuse me for my not very clear posts.
Ciao!
Mauro.

Well the dispather is what makes a class costum, and therefore you
can't have one without the other.
(/me hums Al-Bundy-title-theme)

Lets make it simple:
Code:

This is the private data of the new class, which will be unique for
each object we create.

We also define a new Method.

Code:


This will create a class based MUIC_Area (you can use whatever
base-class you want). It will also make sure that every object has
enough space for our private Data.

Code:

Code:

This object can now handle all what MUIC_Area can handle plus the new
MUIM_Bla_Blupp-Method:

Code:

Many thanx Krons!
with your little turorial I've understood how to build my mui custom class!
Now I'll try to write a proggy with a (working with a simple GUI.
Again thanx 4 yout precious help!