[OOP][C][MUI]Passaggio parametri.

[rebraist]

• 

Vediamo se ci ho capito qualcosa...
Una classe mui riconosce come sua area dati la struttura "data" (chiamiamola così genericamente) e riconosce come suoi metodi tutti quelli che o tramite il dispatcher o tramite la creazione di id personalizzati vengono legati ad essa.
Detto questo...
mettiamo che io abbia un mio bell'oggetto tavolozza (che altri non è che un derivato della classe area) all'interno dell'oggetto app(*)
Devo dichiarare la mia area dati e ci metto tutte le bravi variabiline, poi dichiaro le mie funzioncine e le lego alla classe.
Ora arriviamo al busillis:

SAVEDS ULONG mCleanup(struct IClass *cl,Object *obj,Msg msg,  APTR param_app)
{

   FreeMem(ievent,sizeof(struct InputEvent));
      FreeMem(buffer,bufsize);
    CloseDevice((struct IORequest *)&ioreq);
   MUI_DisposeObject(param_app);    
       MUI_DeleteCustomClass(mcc);
     

   return(DoSuperMethodA(cl,obj,msg));
}
ovviamente è lo speculare di setup etc etc.
Ho lavorato su class1.c dell'sdk di mui38 e tutto è contenuto in un unico file per cui tutto funziona.
Voglio salvare il mio oggetto in un file esterno .c .h.
Dalla guida di shinkuro (e da quelle di stuntz) leggo che un buon metodo mui esaurisce i suoi parametri esclusivamente in cl, obj e msg.
Ovviamente il metodo cleanup così come è scritto è errato: il metodo non può chiamare MUI_DisposeObject relativo all'oggetto applicazione che è di suo un oggetto esterno (fisicamente e logicamente).
Prima considerazione: il dispatcher è relativo all'oggetto custom o all'applicazione? Cioè il dispatcher dell'oggetto deve andare nei file .c del mio bravo oggetto?
Ha senso creare un metodo dispatcher per l'oggetto applicazione?
Premesso che cleanup e dispose dell'oggetto custom vengono chiamati in auto tramite il dispathcer alla chiusura di app, chi viene invocato per prima nel momento in cui chiudo app? Mui gestisce da solo questa catena, senza che mi si chiuda app senza chiudere l'oggetto (ad esempio cliccando sul pulsante di chiusura dell'applicazione)?
A questo punto altra domanda: la relazione che c'è tra app e oggetto contenuto nell'app è solo di ordine "grafico" o nel momento in cui vado a crearmi il mio bravo "script" mui si crea anche una relazione di ordine gerarchico per cui c'è effettivamente una relazione tra oggetto contenitore e oggetto contenuto, e quindi si preoccupa lui di chiudere tutto (chiaramente definendo il distruttore del mio oggetto custom)?

[ShInKurO]

• 

Prima considerazione: il dispatcher è relativo all'oggetto custom o all'applicazione? Cioè il dispatcher dell'oggetto deve andare nei file .c del mio bravo oggetto?

Non per forza, dipende dalla convenzione che segui, alla fine è sempre linguaggio C,dunque in teoria basta che lo dichiari solamente in un .h che includi e poi lo implementi da qualche altra parte. Il fatto che ogni classe BOOPSI abbia il suo dispatcher dentro lo stesso file degli altri metodi della classe è solo una convenzione d'ordine.

Ha senso creare un metodo dispatcher per l'oggetto applicazione?

Se l'oggetto applicazione deriva da una tua classe che è figlia di MUIC_Application allora si, poi dipende sempre da che genere di implementazione di classe stiamo parlando
Tra l'altro la mia memoria vacilla, quindi prendi le cose che ti scrivo con cautela, almeno fin quando non riprenderò un minimo di sviluppo su amiga

Premesso che cleanup e dispose dell'oggetto custom vengono chiamati in auto tramite il dispathcer alla chiusura di app, chi viene invocato per prima nel momento in cui chiudo app? Mui gestisce da solo questa catena, senza che mi si chiuda app senza chiudere l'oggetto (ad esempio cliccando sul pulsante di chiusura dell'applicazione)?

Se li dichiari correttamente nel dispatcher l'ordine d'esecuzione è quello che è dichiarato sulla mia guida e su quella ufficiale, dunque prima cleanup e poi dispose. Si, MUI gestisce in automatico l'esecuzione dei metodi se hai scritto correttamente il dispatcher.

A questo punto altra domanda: la relazione che c'è tra app e oggetto contenuto nell'app è solo di ordine "grafico" o nel momento in cui vado a crearmi il mio bravo "script" mui si crea anche una relazione di ordine gerarchico per cui c'è effettivamente una relazione tra oggetto contenitore e oggetto contenuto, e quindi si preoccupa lui di chiudere tutto (chiaramente definendo il distruttore del mio oggetto custom)?

c'è una relazione ovviamente tra un oggetto MUIC_Application più MUIC_Window e i relativi contenuti di ciascuna window. La chiusura se non sbaglio (esecuzione di cleanup e dispose) avviene a cascata gerarchica, quindi dal contenuto piùinterno a quello più esterno.
Dunque se hai un oggetto MUIC_Group al cui interno vi è una MUIC_Area, e MUIC_Group è contenuto dentro una MUIC_Window (ovvio),  tutti questi oggetti verranno disposti nell'ordine area->gruppo->finestra. Se i dispatcher e i dispose di ciascuna classe sono stati scritti correttamente avrai appunto il risultato descritto, ma questa non è una prerogativa di MUI/BOOPSI, bensì dell'OOP.

[rebraist]

• 

grazie dell'esauriente risposta.
stasera mi metto e vedo!

[rebraist]

• 

Andato avanti con le idee più chiare.
Ciò che non realizzo è:
nel momento in cui lego al mio oggetto mui la struttura PIPPO_DATA con tutte le mie brave variabili, per settarne o leggerne qualcuna, devo obbligatoriamente usare get e set? Non posso accedere direttamente ad esse? E se si, come?
Cioè mettiamo il caso pratico:
struct PIPPO_DATA
{
unsisgned short int mio;
}

struct PIPPO_DATA pippo;
Per fare un set che faccio?
set(pippo, mio, 5);
oppure cosa?

[ShInKurO]

• 

Vado a memoria.
Dunque, in una classe puoi avere attributi privati, cioè delle variabili membro di una struttura C a cui però in teoria non possono accedere altre classi. Inoltre puoi avere gli attributi pubblici.
Un attributo è pubblico nel momento in cui tu overrraidi ("dichiari") un metodo OM_SET e/o un metodo OM_GET e al loro interno nello switch dai un nome all'attributo, per esempio MUIA_MIACLASSE_NOMEATTRIBUTO nel caso di MUI, in questo modo puoi controllare il settaggio/gettaggio dell'attributo attraverso SetAttr() e GetAtt(). Cmq avevo scritto un paragrafo riassuntivo nella mia guida, spe che cerco... è il 4.10:


Riassumendo abbiamo visto come una classe MUI può essere dotata di:

- Attributi privati : sono le variabili dichiarate dentro l'area dati della
                      classe che non sono state associate ad alcun simbolo;

- Attributi pubblici    : sono variabili dichiarate (di solito) all'interno
                          dell'area dati della classe, le quali sono associate in
                          OM_NEW/OM_SET/OM_GET a dei simboli (per esempio MUIA_Classe1_Attr1);

- Attributi notificabili: sono attributi pubblici il cui cambiamento di
                          valore viene rilevato e/o modificato da MUI per mezzo
                          di metodi quali MUIM_Notify e MUIM_Set;



nel tuo caso se non sbaglio puoi cambiare il contenuto di un attributo privato in questo modo:

struct areaDati1 *data = INST_DATA(cl, obj);
data->attr1 = VALORE_DA_ASSEGNARE;

Spero di averti chiarito le idee  

[rebraist]

• 

Chiarissimo! Grazie!