Ciao Maurizio,
devo dire che ti sono grato per questa segnalazione, perché mi ha
costretto a capire alcune cose che, per il momento, avevo (diciamo)
messo sotto il tappeto :)
Ho fatto alcune modifiche sulle classi in ufficio: non è il caso che ti
indichi i moduli perché sono molti (3), le modifiche sono fatte un po'
alla rinfusa e non sono definitive.
Quindi questa "correzione" non la puoi applicare altrove, ma la puoi
provare.
Dovrei aver corretto il problema segnalato nella prima mail.
Il secondo problema, invece, non mi è chiaro, ma forse solo perché l'ho
guardato a valle della prima correzione e semplicemente non si verifica
più o magari non si verifica più nello stesso modo.
Quindi ti sarei grato se tu potessi, oltre a confermarmi la correzione
del primo problema, anche darmi un aggiornamento sullo stato del
secondo.
Segue una spiegazione tecnica: tranquilli, non è per voi, servirà a
memoria mia, per il futuro.
Il problema lo avevo già riscontrato, ma lo avevo attribuito al
controllo HTML-area.
Questo perché il controllo treeview (per ragioni storiche) può avere
sia una definizione programmatica (o2tree_def(), in HTML-area), sia
un utilizzo come controllo in form e io, nei miei test, non avevo
tenuto conto dei due diversi casi.
Il contesto delle dipendenze per il controllo era gestito correttamente,
ma Il controllo treeview può ricevere delle variazioni che non dipendono
dalle sue dipendenze dalle variabili di programma.
Ad esempio, tramite funzione (come avviene nel tuo caso) puoi
espandere o contrarre un singolo nodo, puoi spostare la select,
ecc.., senza cambiare la variabile che fornisce gli item al controllo
(che è la sua dipendenza).
Avrei potuto semplicemente mettere il controllo treeview fuori dalla
gestione delle dipendenze, reinviandolo sempre in response, ma:
1. è un controllo che, ormai, ha una certa diffusione e spesso in form
complesse;
2. quando viene reinviato, come codice, ha spesso un peso importante.
Quindi ho preferito mantenerlo nel contesto delle response selettive ed
utilizzare una strategia per forzarne il reinvio, a fronte di funzioni
che ne modifichino l'aspetto.
Se questa strategia risulterà risolutiva vorrei applicarla anche
all'img-list, che, anche se in grado minore, ha le stesse
caratteristiche.
Se non emergeranno problemi particolari nel prossimo rilascio (lunedì)
tenterò anche di ricondurre il controllo HTML-area sotto la gestione
delle dipendenze:
Credo che sarebbe importante, se possibile, perché spesso i controlli
HTML-area appesantiscono le response in maniera più che sensibile.
Quindi resteranno fuori solo due controlli:
- grid, che (come abbiamo detto) ha già un suo sistema a parte di
gestione delle dipendenze;
- document: talmente raro e talmente particolare da essere
trascurabile (anche se uniformare la toatalità dei controlli ad una
stessa logica di gestione delle dipendenze sarebbe sicuramente utile,
se non dal punto di vista strettamente prestazione, sicuramente da
quello della coerenza del codice interno).
Saluti
--
. Tommaso Vannini
. <
tvan...@janox.it>
. Software analysis & development
. Janox project manager (
www.janox.it)