Multipage: proprietà enable
0 views
Skip to first unread message
Janox - Uniteam s.r.l.
Jan 20, 2026, 3:55:44 AM (11 days ago) Jan 20
to jxsu...@googlegroups.com
Ciao Tommaso,
un multipage ha la proprietà enable true/false dinamica in funzione ad una variabile flag locale al programma.
La variabile flag è associata ad un checkbox con submit on change a true.
L'expression usata nella proprietà enable del multipage è semplicemente o2val(variabile flag).
Ti scrivo perchè ho dovuto spostare "l'enable" dal multipage ai singoli controlli nel suo interno (ricordo che ci fu un problema sull'eredità di enable nei multipage).
Screenshot con proprietà enable sul mutlipage:
Screenshot con proprietà enable spostata da multipage a singolo controllo:
Ho verificato che si verifica dalla runtime 20250929.
Grazie mille
Ciao e buona giornata
un multipage ha la proprietà enable true/false dinamica in funzione ad una variabile flag locale al programma.
La variabile flag è associata ad un checkbox con submit on change a true.
L'expression usata nella proprietà enable del multipage è semplicemente o2val(variabile flag).
Ti scrivo perchè ho dovuto spostare "l'enable" dal multipage ai singoli controlli nel suo interno (ricordo che ci fu un problema sull'eredità di enable nei multipage).
Screenshot con proprietà enable sul mutlipage:
Screenshot con proprietà enable spostata da multipage a singolo controllo:
Ho verificato che si verifica dalla runtime 20250929.
Grazie mille
Ciao e buona giornata
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://get.teamviewer.com/6nx6fgx
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://get.teamviewer.com/6nx6fgx
---------------------------------------------------------------------------
Tommaso Vannini
Jan 20, 2026, 11:12:47 AM (10 days ago) Jan 20
to jxsu...@googlegroups.com
Ciao Maurizio,
ti confesso che non capito esattamente quale sia il problema segnalato.
Vuoi dire che la proprietà enabled sul multipage non funziona?
Mi sembra strano: dovremmo avere miliardi di casi del genere...
Come sempre se mi indichi come vedere il caso specifico il problema sarà
più chiaro e la soluzione più rapida.
Saluti
--
. Tommaso Vannini
. <tvan...@janox.it>
. Software analysis & development
. Janox project manager (www.janox.it)
ti confesso che non capito esattamente quale sia il problema segnalato.
Vuoi dire che la proprietà enabled sul multipage non funziona?
Mi sembra strano: dovremmo avere miliardi di casi del genere...
Come sempre se mi indichi come vedere il caso specifico il problema sarà
più chiaro e la soluzione più rapida.
Saluti
--
. Tommaso Vannini
. <tvan...@janox.it>
. Software analysis & development
. Janox project manager (www.janox.it)
Janox - Uniteam s.r.l.
Jan 20, 2026, 11:25:26 AM (10 days ago) Jan 20
to jxsu...@googlegroups.com
Ciao Tommaso,
puoi verificare il problema entrando con:
puoi verificare il problema entrando con:
- App name: kfashion
- App alias: kfashion
- User: root
- Pwd: Lardinispa2026!
- Dev: maurizio
Vai sul menu "Tabelle base -> Stampe -> Clienti / Fornitori" e prova ad attivare il campo "Utilizza filtri su ana. commerciale (il solo flag già esclude le ana. prive di dati commerciali)":
Alla sua attivazione dovrebbe attivarsi il multipage che trovi sotto.
Il prg è stampa_anagrafiche e ce l'ho in check perchè ho spostato l'exp 19 dalla proprietà enable dei singoli controlli alla proprietà enable del multipage (per ripristinare la versione con la quale il cliente mi ha fatto la segnalazione).
Spero di essermi spiegato.
Grazie mille
Ciao e buona serata
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://get.teamviewer.com/6nx6fgx
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://get.teamviewer.com/6nx6fgx
---------------------------------------------------------------------------
Tommaso Vannini
Jan 20, 2026, 8:18:52 PM (10 days ago) Jan 20
to jxsu...@googlegroups.com
Ciao Maurizio,
non avevo capito che il problema fosse così generalizzabile.
In realtà questo problema è stato introdotto con la response selettiva
(solo controlli che hanno dipendenze variate), ormai più di 3 anni fa.
I container (come il multipage) non avevano dipendenze (cioè vengono
inviati sempre), ma i controlli contenuti nel container non avevano le
dipendenze del padre, quindi non venivano inviati, perché risultavano
"non variati".
Che sia un problema è innegabile, perché prima della response selettiva
funzionava, ma quello che mi sembra strano è che per tutto questo tempo
nessuno me lo abbia segnalato..!
Comunque credo di aver corretto la cosa ed ho applicato la patch in
ufficio: verifica anche tu, ma a me sembra che il caso specifico adesso
si comporti correttamente.
Ti lascio questa patch in prova per qualche giorno, giusto per scrupolo.
Io vedo di completare l'intervento estendendolo anche ai controlli
flowbox (un po' più complessi, perché hanno l'abilitazione per pagina)
e, se non emergono problemi (e se non hai particolari urgenze), vedo di
mettere tutto in rilascio per lunedì prossimo.
Come sempre grazie della segnalazione e fammi sapere.
non avevo capito che il problema fosse così generalizzabile.
In realtà questo problema è stato introdotto con la response selettiva
(solo controlli che hanno dipendenze variate), ormai più di 3 anni fa.
I container (come il multipage) non avevano dipendenze (cioè vengono
inviati sempre), ma i controlli contenuti nel container non avevano le
dipendenze del padre, quindi non venivano inviati, perché risultavano
"non variati".
Che sia un problema è innegabile, perché prima della response selettiva
funzionava, ma quello che mi sembra strano è che per tutto questo tempo
nessuno me lo abbia segnalato..!
Comunque credo di aver corretto la cosa ed ho applicato la patch in
ufficio: verifica anche tu, ma a me sembra che il caso specifico adesso
si comporti correttamente.
Ti lascio questa patch in prova per qualche giorno, giusto per scrupolo.
Io vedo di completare l'intervento estendendolo anche ai controlli
flowbox (un po' più complessi, perché hanno l'abilitazione per pagina)
e, se non emergono problemi (e se non hai particolari urgenze), vedo di
mettere tutto in rilascio per lunedì prossimo.
Come sempre grazie della segnalazione e fammi sapere.
Tommaso Vannini
Jan 20, 2026, 8:21:21 PM (10 days ago) Jan 20
to jxsu...@googlegroups.com
Ah,
scusa, nel caso ti servisse saperlo:
Il file patchato è "jxui.inc" della runtime.
scusa, nel caso ti servisse saperlo:
Il file patchato è "jxui.inc" della runtime.
Janox - Uniteam s.r.l.
Jan 21, 2026, 4:58:20 AM (10 days ago) Jan 21
to jxsu...@googlegroups.com
Ciao Tommaso,
confermo la correttezza della patch, installata sul server saas clienti.
Grazie mille
Ciao e buona giornata
confermo la correttezza della patch, installata sul server saas clienti.
Grazie mille
Ciao e buona giornata
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://get.teamviewer.com/6nx6fgx
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://get.teamviewer.com/6nx6fgx
---------------------------------------------------------------------------
Tommaso Vannini
Jan 25, 2026, 9:29:47 PM (5 days ago) Jan 25
to jxsu...@googlegroups.com
Ciao Maurizio,
in release odierna ho rilasciato questa correzione che, però, ha avuto
una portata molto più ampia di quanto avessi previsto inizialmente (in
patch).
La spiegazione breve è che ho dovuto estendere il modello delle
dipendenze a TUTTI i controlli.
Quindi questa release ha bisogno di essere testata in sviluppo.
Adesso la spiegazione lunga e vi darò del "voi", perché spero che tutti
i partecipanti a questo gruppo vogliano leggerla con attenzione.
Come vi ho detto ho dovuto estendere il concetto delle dipendenze a
tutti i controlli, questo è stato necessario per poter gestire i
container, come i multipage e i flowbox.
Vi faccio un esempio banale: se un multipage contiene un campo, diciamo
un edit, che ha visibilità condizionata da A, allora anche il multipage
deve avere un sistema di dipendenze ed A deve essere fra le sue
dipendenze, altrimenti al variare di A, i figli del multipage non
verrebbero aggiornati.
Questa stessa logica vale per qualunque tipo di controllo, perché, ad
esempio, il container potrebbe contenere semplicemente un separatore
(line) con visibilità condizionata ad un certo campo.
Quindi ho dovuto estendere la logica delle dipendenze a tutti i tipi di
controllo.
Questa nuova logica darà sicuramente risultati prestazionali
vantaggiosi: però non sono in grado di stimare questo vantaggio, perché
dipende da troppe variabili, nei singoli casi.
Fondamentalmente si basa sul rapporto fra codice inviato in response e
complessità dell'interfaccia da valutare, quindi confido che il
vantaggio sarà tanto maggiore quanto più complessa sarà l'interfaccia da
gestire.
Un'evidenza che emerge dal codice è che lo sforzo server-side (per
gestire le dipendenze) è ampiamente proporzionato al vantaggio in
response e ormai sappiamo bene che ogni vantaggio in response, per
quanto piccolo, vale bene uno sforzo server-side.
Comunque qui lo sforzo server-side non implica query o risorse esterne,
ma equivale solo ad un minimo aumento della sessione in RAM
dell'app-server ed è scalato sulla complessità del programma.
Ho messo in salvaguardia tre controlli: html-area, document e grid.
I primi due perché possono dipendere da risorse esterne alla logica
Janox, che (al momento) non possono essere gestite come dipendenze
interne.
Il terzo, la grid, perché storicamente ha un suo "ambiente" di gestione
delle dipendenze, a parte di quello generalizzato, perché preesistente e
molto complesso.
Anche per questi controlli, o almeno per la grid, sarebbe davvero
auspicabile poter ricondurre la loro gestione delle dipendenze a quella
generalizzata, ma questo intervento avrebbe avuto una portata, in
termini di destabilizzazione, che non mi sono sentito di affrontare e
non sono sicuro che sarà mai affrontabile.
Un'attenzione particolare la riserverei a due controlli: la progress-bar
e il navigator.
Sulla progress-bar credo di aver fatto tutte le possibili verifiche,
nelle varie situazioni (autonoma, in grid, da job, ecc...), o almeno
tutte quelle che mi permettevano i miei strumenti di test.
Sul navigator, invece, le mie situazioni di test non saranno mai
all'altezza delle vostre pratiche quotidiane.
Quindi direi: occhio al comportamento di tutto, ma in particolare al
comportamento dei navigator, specialmente se fuori da grid.
Concludo:
Queste classi, internamente, le definirei epocali, ma capisco che
dall'esterno sia difficile percepirlo: anzi, se non lo percepirete
affatto sarà un ottimo risultato, perché vorrà dire che non avrò "rotto"
nulla.
Quindi, però, queste classi avranno bisogno di una buona quarantena in
sviluppo.
Se si dimostreranno stabili e non emergeranno problemi direi di passare
da un consolidamento, perché il mio timore è che si faccia troppo ampio
il divario fra ciò che avete in sviluppo e ciò che, effettivamente,
usate in produzione.
Credo che alcuni di voi abbiano ancora in produzione la 2.9 e credo che
questo gap vada recuperato quanto prima.
in release odierna ho rilasciato questa correzione che, però, ha avuto
una portata molto più ampia di quanto avessi previsto inizialmente (in
patch).
La spiegazione breve è che ho dovuto estendere il modello delle
dipendenze a TUTTI i controlli.
Quindi questa release ha bisogno di essere testata in sviluppo.
Adesso la spiegazione lunga e vi darò del "voi", perché spero che tutti
i partecipanti a questo gruppo vogliano leggerla con attenzione.
Come vi ho detto ho dovuto estendere il concetto delle dipendenze a
tutti i controlli, questo è stato necessario per poter gestire i
container, come i multipage e i flowbox.
Vi faccio un esempio banale: se un multipage contiene un campo, diciamo
un edit, che ha visibilità condizionata da A, allora anche il multipage
deve avere un sistema di dipendenze ed A deve essere fra le sue
dipendenze, altrimenti al variare di A, i figli del multipage non
verrebbero aggiornati.
Questa stessa logica vale per qualunque tipo di controllo, perché, ad
esempio, il container potrebbe contenere semplicemente un separatore
(line) con visibilità condizionata ad un certo campo.
Quindi ho dovuto estendere la logica delle dipendenze a tutti i tipi di
controllo.
Questa nuova logica darà sicuramente risultati prestazionali
vantaggiosi: però non sono in grado di stimare questo vantaggio, perché
dipende da troppe variabili, nei singoli casi.
Fondamentalmente si basa sul rapporto fra codice inviato in response e
complessità dell'interfaccia da valutare, quindi confido che il
vantaggio sarà tanto maggiore quanto più complessa sarà l'interfaccia da
gestire.
Un'evidenza che emerge dal codice è che lo sforzo server-side (per
gestire le dipendenze) è ampiamente proporzionato al vantaggio in
response e ormai sappiamo bene che ogni vantaggio in response, per
quanto piccolo, vale bene uno sforzo server-side.
Comunque qui lo sforzo server-side non implica query o risorse esterne,
ma equivale solo ad un minimo aumento della sessione in RAM
dell'app-server ed è scalato sulla complessità del programma.
Ho messo in salvaguardia tre controlli: html-area, document e grid.
I primi due perché possono dipendere da risorse esterne alla logica
Janox, che (al momento) non possono essere gestite come dipendenze
interne.
Il terzo, la grid, perché storicamente ha un suo "ambiente" di gestione
delle dipendenze, a parte di quello generalizzato, perché preesistente e
molto complesso.
Anche per questi controlli, o almeno per la grid, sarebbe davvero
auspicabile poter ricondurre la loro gestione delle dipendenze a quella
generalizzata, ma questo intervento avrebbe avuto una portata, in
termini di destabilizzazione, che non mi sono sentito di affrontare e
non sono sicuro che sarà mai affrontabile.
Un'attenzione particolare la riserverei a due controlli: la progress-bar
e il navigator.
Sulla progress-bar credo di aver fatto tutte le possibili verifiche,
nelle varie situazioni (autonoma, in grid, da job, ecc...), o almeno
tutte quelle che mi permettevano i miei strumenti di test.
Sul navigator, invece, le mie situazioni di test non saranno mai
all'altezza delle vostre pratiche quotidiane.
Quindi direi: occhio al comportamento di tutto, ma in particolare al
comportamento dei navigator, specialmente se fuori da grid.
Concludo:
Queste classi, internamente, le definirei epocali, ma capisco che
dall'esterno sia difficile percepirlo: anzi, se non lo percepirete
affatto sarà un ottimo risultato, perché vorrà dire che non avrò "rotto"
nulla.
Quindi, però, queste classi avranno bisogno di una buona quarantena in
sviluppo.
Se si dimostreranno stabili e non emergeranno problemi direi di passare
da un consolidamento, perché il mio timore è che si faccia troppo ampio
il divario fra ciò che avete in sviluppo e ciò che, effettivamente,
usate in produzione.
Credo che alcuni di voi abbiano ancora in produzione la 2.9 e credo che
questo gap vada recuperato quanto prima.
Reply all
Reply to author
Forward
0 new messages