Newsgroup: it.comp.lang.delphi
Titolo: Come gestire enabled/disabled in TActionMainMenuBar

Salve a tutti,
poiche' sto cercando di rimodernare un po' una mia applicazione, mi
servirebbe un'aiuto su come gestire il seguente (tipico) scenario:
- Menu fatto con TMainMenuBar
- TActionManager che "pesca" le action da un TActionList
L'abilitazione (property Enabled) delle action inserite nel menu puo'
dipendere da piu' fattori, esempio:
- se non ci sono utenti loggati nell'applicazione, l'unica action
abilitata e' "User>Login",
- permessi che ha l'utente, 
- "oggetto/i" selezionato/i (ossia in base al contesto di lavoro).
- etc...
Con l'architettura che usavo in precedenza (TToolBar con TToolButton
associati a TPopupMenu) per simulare il caro vecchio TMainMenu
l'approccio era di occuparsi dell'abilitazione dei menuitem
nell'evento OnPopup dei TPopupMenu.
Questo approccio aveva i vantaggi di centralizzare il codice di
gestione dell'abilitazione e di eseguire tale codice solo quando era
effettivamente necessario, ossia all'apertura del menu.
Con le actionbands credo che si possa ottenere un risultato simile
creando una TAction da associare all'elemento base di TMainMenuBar, e
usare il suo evento Execute per abilitare le actions sottostanti (o
sbaglio?).
Pero' ho la sensazione che non sia la soluzione migliore.
Generalmente come si risolve un problema simile?
Grazie in anticipo
-- 
Roal Zanazzi

OnUpdate delle TAction?
-- 
Alberto Salvati
A NEAPOLITAN Delphi Developer who is studying c# and .net
"Dicette 'o pappece 'nfaccia 'a noce dammi 'o tiempo che pure te spertoso"

 
Grazie per la risposta.
Sembrerebbe la soluzione piu' adatta. Domande:
- conviene gestire l'OnUpdate delle singole action, oppure
"centralizzare" la gestione di stati comuni tra un gruppo di action
nell'OnUpdate di TActionList (o di una TAction che serve solo per
raggruppare poche action contenute in una actionlist)?
- In generale, come conviene frazionare le action? 
  Tante actionlist con poche action legate tra loro (es. solo le
action di un menu/toolbar);
  oppure una o poche actionlist con tutte/molte action?
- Nei casi precedenti, quanto puo' diventare oneroso per il sistema
aggiornare lo stato di alcune decine di taction?
Viceversa, quanto sono reattivi gli eventi OnUpdate se il sistema e'
sotto stress (es. durante la decodifica e visualizzazione di N stream
video)?
Grazie di nuovo.
-- 
Roal Zanazzi

 video)?
Domanda difficile. Se non ricordo male (non ho il tempo materiale di 
controllare), l'evento /OnUpdate/ viene generato quando l'applicazione 
entra nello stato "idle", cioè quando ha terminato di gestire tutti i 
messaggi presenti nella propria coda.
Se decodifichi e visualizzi uno stream video nel contesto del thread 
dell'applicazione, l'evento /OnUpdate/ verrà eseguito solo quando 
l'operazione è terminata; se invece utilizzi un thread secondario, è 
difficile secondo me determinare la "reattività" degli eventi /OnUpdate/ 
in assoluto poichè tutto dipende dalla priorità assegnata ai singoli 
thread e dalla condizione degli altri processi in esecuzione.
Ciao! :-)
-- 
MARCO «Alka» BREVEGLIERI
   (
http://www.marco.breveglieri.name
)
Leggi le FAQ di ICLD: 
http://icld.altervista.org

 
Nel mio caso gli stream video (e non solo) vengono decodificati e
visualizzati in thread secondari (questa parte non e' in Delphi).
Considerando un utilizzo "normale" della mia applicazione, direi che
in idle ci sta ben poco.
Se non erro OnUpdate viene anche forzato quando viene chiamato il
metodo Update(), se e' cosi' forse e' meglio se mi occupo di forzare
l'update almeno nei punti in cui viene cambiato uno stato che _deve_
riflettersi nelle action (es. logout utente => disabilito tutto).
Che ne pensi?
-- 
Roal Zanazzi

 thread e dalla condizione degli altri processi in esecuzione.
In un caso del genere, passarei all'istanza del thread un "qualcosa" che 
permetta al thread stesso di gestire una callback. Il "qualcosa" 
verrebbe verificato in vari punti del codice del thread, ad esempio, se 
esiste un loop inserirei un contatore che ogni n cicli andasse a 
processare la callback se assegnata.
Nella callback metterei poi il codice per aggiornare lo stato delle 
tactions. Dico "qualcosa" e non un semplice puntatore a funzione 
xchepotrebbe essere necessario utilizzare una critical section per 
evitare la chiamata della callback da + thread nello stesso momento.


 bisogno.
Anche io faccio così. ;-)


 Che ne pensi?
Credo che sia il modo giusto di procedere. Potresti inviare un messaggio 
all'applicazione quando lo stato nel thread cambia o quando desideri che 
l'applicazione venga a conoscenza di qualcosa che avviene nel thread stesso.
Quando l'applicazione gestisce il messaggio, può acquisire lo stato 
corrente del thread e aggiornare in modo sincrono con il thread 
principale dell'applicazione i componenti visuali preposti.
Conclusa la gestione del messaggio personalizzato, l'applicazione 
dovrebbe entrare nello stato "idle" e quindi aggiornare le azioni; in 
alternativa, potresti chiamare tu /Update/ nel codice che intercetta il 
messaggio personalizzato.
Si tratta di idee puramente teoriche che, in teoria appunto, dovrebbero 
funzionare, ma per saperlo occorre verificarle. ;-)
Fai qualche prova e facci sapere. Magari, analizzando il tuo modo di 
procedere e ottimizzando il codice che invii, potremmo realizzare una 
FAQ in grado di trattare a tutto campo la problematica di sincronizzare 
interfaccia e comandi di un'applicazione con lo stato di un thread 
secondario che si occupa di eseguire processi lunghi e/o onerosi (in 
termini di CPU).


 Ciao! :-)
