Risposta breve: non lo so e non me lo ricordo.

Risposta estesa:
MUI dovrebbe gestire le notifiche gerarchicamente secondo la filosofia top down, quindi dalla finestra ai figli, andando sempre più all'interno.
Devi anche aggiungere il fatto che l'esecuzione effettiva di una notifica dipende dalla lunghezza della catena di notifiche che deve attraversare. Più lunga la catena, più tempo impiegherà ad arrivare la notifica.
MUI garantisce solo che la notifica arriverà, non quando. Quindi non puoi sapere se una notifica verrà eseguita prima di un'altra.

Questo è "aggirabile" con un metodo bellissimo che io amo, si chiama MUIM_Application_PushMethod. Ovviamente PushMethod funziona diversamente in ciascuna versione di MUI, quindi ti consiglio di fare un grep sui sorgenti di NoWinED per vedere come lo uso io, o aspettare che io abbia tempo per farlo e incollare il significato intrinseco delle minchiate che avrò scritto

Cmq se hai dubbi io ti consiglio di leggere due fonti ottime per MUI (le trovi su aminet):

MUIUndoc18;
mui_htmlhelp;

E vedrai che si aprirà un nuovo mondo

A proposito, ma chi è Mark K (donut123)?
E' un grande, sta confrontando AROS68k con AmigaOS e fa dei report dettagliatissimi sulle incompatibilità di AROS con tutte le funzioni AmigaOS, principalmente AmigaDOS, ma non solo...
Dovrebbero fargli una statua... sono proprio curioso di vedere quando questi report verranno fixati  

Non proprio... solo i programmi che usano Forbid() / Permit() potrebbero avere problemi. Si tratta di una tecnica arcaica di programmazione che blocca gli interrupt di sistema per manipolare le strutture dell'OS manualmente.
Se un programma sfrutta solo le API moderne, dovrebbe uscire illeso dal processo di introduzione dell'SMP.

Non è così raro usare il blocco Forbid()/Permit(), leggi il  paragrafo 5.3.4 della mia guida...

Risolto, nelle prossime settimane cercherò di capire se ci sono problemi con il nuovo AROS :-P

Intanto, non e' che potresti dare un'occhiatina a nowined? ultimamente ho notato che facendo clic sul pulsante per salvare i file (salva sul file stesso, per capirci), il programma va spesso in crash.

Ci provo questo weekend...

...scaricati i sorgenti di nowined, messo su ambiente qemu, aros installato ecc... amidevcpp risalente all'anno scorso, provo a compilare nowined ed ho problemi con SDI, buongiorno mondo

39 C:UsersShInKurODesktopNoWinEDtrunksourcesabout.c invalid conversion from 'IPTR (*)(Hook*, void*, void*)' to 'IPTR (*)()'

ovviamente una loro macro.

Io ho incluso tutto quello che dovevo includere in C:CrossCompilerAmiDevCppusrlocalamigai386-aros, però nulla, vedremo nei prossimi giorni... sicuramente ci sarà qualcosa che non ricordo minimamente della compilazione per AROS su AmiDevCPP.
Se sono stati fatti degli aggiornamenti sugli include di AROS fammelo sapere, devo reinstallare AmiDevCPP con una versione più nuova ?

A proposito di bounty, nessuno ha commentato quello aperto per rendere opensource DOpus Magellan2.
Trovo davvero uno spreco di denaro fare un bounty per DOpus Magellan2 per sistemi come OS4 e AROS quando opensource è possibile trovare Ambient.
Purtroppo come nella maggior parte dei casi gli amighisti non si rendono conto che un sw che usavano 15 anni fa e con cui si trovavano bene potrebbe non essere all'altezza delle altre alternative che durante gli anni sono uscite.
DOpus non supporta nemmeno le icone di OS3.5, genera i propri gadget con GadTools senza probabilmente passare nemmeno per BOOPSI.
In pratica su OS4 avrebbe un aspetto osceno, inoltre non utilizza API nuove (le richieste minime erano OS3.0 o meno?), e questo vuol dire anche che avrà grosse difficoltà a gestire robe come il compositing.

Davvero mi chiedo come la gente abbia potuto raccogliere la bellezza di 900$+ per una roba così datata.  Aveva senso quando uscì OS4.0, ma non accadde. Sembra che gli amighisti non si rendano conto che il tempo passa, anche per il loro OS.

Con 1000$+ sicuramente gente come ka1sle sicuramente si sarebbe trovata. Il codice di Ambient è una delle risorse da cui attingere quando si parla di programmazione Amiga moderna, è sempre uno spettacolo leggere certe soluzioni. Di certo non si può dire lo stesso di DOpusMagellan che nasce quando ancora nemmeno il gcc era il compilatore di default su Amiga e ci sono svariate parti scritte in assembly 68k.

Un'altra occasione per Ambient andata persa. Ambient potrebbe diventare ciò che sono Gnome e KDE per i sistemi UNIX, e invece solo MorphOS ha il privilegio di utilizzarlo.

Te l'ho detto che dovresti leggere proprio qualcosa relativo all'oop, perchè non hai chiare alcune cose fondamentali  

Cioè che rende un attributo publico BOOPSI una variabile privata di un'area dati della tua classe sono proprio gli overriding dei metodi principali dell'oop.

Pensaci bene: mica il C è Skynet, non potrà mai sapere che pluto è pubblica e pippo è privata, glielo devi dire tu. Come? facendo override dei metodi oop.

Se overridi new e ti parsi la taglist alla ricerca di un eventuale valore settato che si riferisce al tuo attributo  allora in questo caso BOOPSI chiama il tuo attributo I, cioè settabile solo all'istanziazione.
Se overridi get e parsi la tag list allora il tuo attributo sarà solo G, cioè gettable.
Se overridi set e parsi la tag list allora il tuo attributo sarà solo S, cioè settable.

Se overridi tutti e tre e parsi la tag list in tutti e tre e controlli il tuo attributo in tutti e tre allora il tuo attributo sarà ISG, è questa la nomenclatura che trovi nella documentazione degli attributi delle classi BOOPSI/MUI.

Dunque è ovvio che ti devi parsare la taglist nel set/get e/o new, perchè altrimenti BOOPSI non viene informato degli attributi pubblici.

Ricordati che il C non è OOP, è BOOPSI che dà al linguaggio C delle proprietà OOP. Quindi è come se tu implementassi con il C il C++ o altri linguaggi ad oggetti attraverso una libreria.

Dovresti vedere gli attributi BOOPSI/MUI come le proprietà del C#, magari se lo hai studiato ti viene più semplice un accostamento simile.

In pratica

SetAttr() non fa altro che andare a chiamare il tuo override a set se la invochi su un oggetto della tua classe, poi se ben ricordi alla fine del metodo si mette un return DoSuperMethodA() che andrà a chiamare il set della superclasse della tua classe e cosivvia fino alla classe root.

è C puro che implementa l'OOP, non pensare che i linguaggi ad oggetti siano implementati in modo differente, solo che in quel caso tu non vedi questi meccanismi e non li implementi, mentre su librerie OOP per il C tu hai pieno potere sulla filosofia stessa dell'OOP.

Secondo me è affascinante  :geek:

Domanda: questo chiaramente non è fattibile in C o sbaglio?

C'è un altro moodo di programmare sugli AmigaOS che non sia il C?
Tutte le API AmigaOS prevedono interfacciamento con C (ed eventualmente assembly, ma non lo considero), quindi qualsiasi cosa che scrivo vale per il linguaggio C. Hai mai provato a scrivere programmi C++ su AmigaOS3.x? E' una cosa quasi impossibile, tra l'altro consumano il triplo di memoria e molte tecniche di programmazione del C++ sono mal supportate dai compilatori di OS3.x. Qualche programma scritto in C++ esiste, tipo HTMLView, ma è buggatissimo.

Altra domanda ancor più scema di quella di prima: dichiarare un attributo pubblico (che non ho capito se si parla di una costante simbolica del c oppure di un effettivo attributo pubblico di una classe c++),

Un attributo pubblico è una variabile dell'area dati della tua classe visibile da altre classi perchè è associata a un simbolo ed è gestita attraverso l'override di almeno uno dei metodi OOP new, get, set.

per la serie:

#define MUIA_MiaClasse_MioAttributo  18328439692438424

IPTR SetClasse1(struct IClass *cl,Object *obj,struct opSet *msg)
{
  struct areaDati1  *data = INST_DATA(cl,obj);

  {/*blocco per la lettura della tag list*/
    struct TagItem *tags, *tag;
    tags=((struct opSet *)msg)->ops_AttrList;

    while (tag=NextTagItem((TAGITEM)&tags))
    {
      switch (tag->ti_Tag)
      {
        case MUIA_MiaClasse_MioAttributo:
         if (data->attr1==tag->ti_Data) tag->ti_Tag = TAG_IGNORE;
        else  
        {                                                                      
          data->attr1 = (STRPTR) tag->ti_Data;
          //E' CAMBIATO IL MIO ATTRIBUTO, FACCIO QUALCOSA
        }
        break;

        ...
      }
    }
  }

  return DoSuperMethodA(cl,obj,(Msg)msg);
}

 
E dall'esterno lo potrai dunque settare:

SetAttrs(objIstanziatoDallaMiaClasse, MUIA_MiaClasse_MioAttributo, "Cambio DI Valore", TAG_DONE);


considerando che gli unici punti in cui i miei due oggetti si incontrano è nei metodi predefiniti (per quanto in override) non comporta necessariamente un aumento della lista parametri rispetto ai 3 canonici (cl, obj e msg)?

Come puoi vedere NO