Problema apertura nodo treeview
0 views
Skip to first unread message
Janox - Uniteam s.r.l.
Jan 28, 2026, 3:55:44 AM (3 days ago) Jan 28
to jxsu...@googlegroups.com
Ciao Tommaso,
con l'ultima runtime ho un problema con il treeview in un programma: cliccando sull'icona di apertura/chiusura nodo si rompe qualcosa.
Se invece apro il nodo cliccando sul nome si apre correttamente:
Sul server di sviluppo trovi nella cartella "C:\Web\janox" anche la runtime 20251215.
Per testare il problema entra così:
con l'ultima runtime ho un problema con il treeview in un programma: cliccando sull'icona di apertura/chiusura nodo si rompe qualcosa.
Se invece apro il nodo cliccando sul nome si apre correttamente:
- Apertura da icona
- Apertura da nome
Sul server di sviluppo trovi nella cartella "C:\Web\janox" anche la runtime 20251215.
Per testare il problema entra così:
- App name: kfashion_exe (se usi kfashion ci sono troppi warning)
- App alias: kfashion
- User: rootscheda
- PWD: lascia vuota
- DEV: tommaso (usa il db rep "db_repository_lardini_cp_ufficiale.inc" che hai sotto il tuo dev)
Entrato nel programma vai nel menu:
Ti ritroverai nella maschera dei due screenshot iniziali.
Se provi ad aprire/chiudere tramite icona i
nodi qualcosa si rompe. Una volta rotto, se clicchi sul nome
funziona correttamente.
Funziona correttamente se clicchi subito su "AI27" e poi su
"LARDINI".
Spero di essermi spiegato, se non ti è chiaro scrivimi via mail o su whatsapp se l'orario è dopo le 18:00.
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
---------------------------------------------------------------------------
Janox - Uniteam s.r.l.
Jan 28, 2026, 4:04:25 AM (3 days ago) Jan 28
to jxsu...@googlegroups.com
Altra cosa legata all'ultima runtime.
Se apri il treeview "AI27 -> LARDINI -> FEELING" troverai una serie di item in un imagelist:
Clicca sul primo item, ti si apre una form con un altro treeview:
Questa form, solo in fase di avvio, visualizza una forma "nascosta" con un refresh timer expression pari a 0.001 con collegata l'action "tree_fold" che si occupa di aprire tutto il treeview e di nasconderla lasciando solo la form di lavoro.
Ho fatto questo perchè se eseguo il tree_fold nella action di avvio ricevo l'errore per "tree non trovato".
Questo escamotage non funziona più con l'ultima runtime, mentre con la 20251215 si.
Anche in questo treeview c'è il problema dell'apertura/chiusura nodo tramite icona.
Anche in questo caso scrivimi/chiamami quando vuoi.
Se apri il treeview "AI27 -> LARDINI -> FEELING" troverai una serie di item in un imagelist:
Clicca sul primo item, ti si apre una form con un altro treeview:
Questa form, solo in fase di avvio, visualizza una forma "nascosta" con un refresh timer expression pari a 0.001 con collegata l'action "tree_fold" che si occupa di aprire tutto il treeview e di nasconderla lasciando solo la form di lavoro.
Ho fatto questo perchè se eseguo il tree_fold nella action di avvio ricevo l'errore per "tree non trovato".
Questo escamotage non funziona più con l'ultima runtime, mentre con la 20251215 si.
Anche in questo treeview c'è il problema dell'apertura/chiusura nodo tramite icona.
Anche in questo caso scrivimi/chiamami quando vuoi.
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
---------------------------------------------------------------------------
--
--
Hai ricevuto questo messaggio in quanto sei iscritto al gruppo di supporto per gli sviluppatori Janox (www.janox.it).
---
Hai ricevuto questo messaggio perché sei iscritto al gruppo "jxsupport" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jxsupport+...@googlegroups.com.
Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jxsupport/46dd8cc2-fbf3-4d48-b647-62c9b5f8049d%40uniteambo.it.
Tommaso Vannini
Jan 29, 2026, 8:12:27 PM (2 days ago) Jan 29
to jxsu...@googlegroups.com
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)
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)
Reply all
Reply to author
Forward
0 new messages