clros ha scritto:
Si, vabbè, ma nn è questo il problema...
In realtà i tuoi problemi derivano proprio da questo, se il codice non è chiaro e facilmente leggibile dubito molto che tu possa venire a capo dei bug che potrebbero presentarsi...
...e nemmeno questo, anche se qui c'è un motivo di fondo; nn posso iniziare le chiamate cn le ReAction macro perchè...devo nel mio caso sempre riferirmi ai puntatori a libreria che appunto si trovano in libBase.
Chiudo le macro in quella maniera perchè è più semplice, ma è identico a mettere TAG_DONE);
Si ok, ma non è leggibile... Scusa mi spieghi perchè nel tuo caso devi riferirti ai puntatori di libreria? Io non ho mai visto alcun sorgente in cui vengono invocate le funzioni passando per i puntatori di libreria, mi piacerebbe sapere che caso è :)
Subclassare...cosa?
Tt il gadget è già sottoclasse di layout, ma servono dei pulsanti "di servizio" e li creo qui per poi aggiungerli al mio gadget subclassato.
E poi, sinceramente, per aggiungere solo 2 pulsanti e uno string... su un altro layout...bhe, penso che il casino aumenterebbe se subclassassi solo per la toolbar da aggiungere!
Esempio: Hai una finestra, una toolbar in alto, una lista a sinistra ed una serie di oggetti a destra.
1) Subclassi window;
2) Subclassi layout (credo sia la classe reaction adibita alla disposizione dei gadget);
3) subclassi layout;
4) subclassi layout;
5) subclassi layout;
-in 1) aggiungi le cose di corredo al tuo programma, chessò i menu ad esempio;
-nel OM_NEW di 3) istanzi le parti della tua toolbar se essa è piccola (altrimenti devi subclassare ulteriormente);
-nel OM_NEW di 4) istanzi la tua lista;
-nel OM_NEW di 5) istanzi la serie di oggetti a destra;
nel OM_NEW di 2) istanzi gli oggetti dalle sottoclassi 3), 4) e 5).
Ogni subclasse overloada almeno i metodi OM_SET, OM_GET ed aggiunge metodi pubblici per gestire alcune operazioni interne alla classe. set e get servono per interagire dall'esterno con i dati della classe, set in particolare NON deve mai fornire puntatori ad oggetti interni alla classe.
Le classi 3) 4) e 5) si parlano attraverso la classe 2) per mezzo dei metodi pubblici, la classe 1) non deve avere la possibilità di parlare in modo diretto con le classi 3) 4) e 5), ma solo tramite la classe 2) potrà interagire con esse.
Questo esempio utilizza l'incapsulamento, l'information hiding e le subclassi sono create attraverso composizione.
Stai programmando in BOOPSI (OOP), non in Intuition, i tuoi principali strumenti devono essere quelli forniti da BOOPSI. Nel caso in cui ci fossero cose non fornite da BOOPSI crei subclassi (immagino di gadget) che forniscano i servizi di cui senti la mancanza.
Se hai dubbi ti consiglio di guardare i sorgenti di ToolManager, per la maggior parte scritto in BOOPSI, con solo le preferenze MUI...
ToolManager è scritto utilizzando tutto questo o quasi... L'unico motivo per il quale non l'ho portato su AROS è che è davvero tosto come programma e non mi piace pensare di scervellarmi con le primitive classi BOOPSI, ma visto che a te piacciono allora il tuo punto di riferimento potrebbero essere proprio quei sorgenti (il programmatore li aveva difatti rilasciati proprio per fare capire agli altri come si programma in BOOPSI).
