Ho provato a utilizzare diversi gestori di stato forniti da JMP, ma più li utilizzo più noto problemi con essi. Ci sono molte ragioni per cui vorrei usarli e forse anche più ragioni per evitarli. Il problema più grande è solitamente che sembrano attivarsi troppe volte e il valore restituito non è così utile.
Subscribe To Data Table List() è un buon esempio di come la maggior parte di questi dovrebbe funzionare. Puoi aggiungere diverse funzioni a diversi eventi (a volte però è una seccatura). Puoi immaginare come funzionerebbe Subscribe To Data Table List() se si attivasse ogni volta che succede qualcosa all'elenco delle tabelle dati (aggiungi, rimuovi, rinomina) e restituisse ad esempio solo il nome della tabella dati (o il numero di tabelle dati modificate ...) e niente più.
Di seguito sono riportati alcuni problemi e suggerimenti:
Etichetta al passaggio del mouse
Problema
Sembra che si attivi quando ti avvicini al punto su cui vuoi passare il mouse. Ciò provoca più trigger e rallenta JMP inutilmente e talvolta questo rallentamento è piuttosto notevole. Inoltre si attiva immediatamente quando passi con il mouse sul punto -> se muovi velocemente il mouse su più elementi si attiverà più volte. Si attiva anche più volte al passaggio del mouse (potrebbe essere correlato a tutte le cose menzionate in precedenza)
Suggerimenti
Rendilo più preciso quando si attiva l'etichetta al passaggio del mouse. Aggiunta la possibilità di "ritardare" l'attivazione dell'evento, ad esempio vorrei poter attivare l'etichetta al passaggio del mouse dopo che l'utente ha passato il mouse sullo stesso elemento per 0,2 secondi. Consenti anche la selezione della "zona sicura" per determinare quando l'etichetta al passaggio del mouse dovrebbe attivarsi.
Gestore dello stato della riga
Problema
Si attiva troppe volte e tutti gli eventi. Ha un bug in cui rimuovi la riga, il gestore dello stato della riga sembra essere rimosso.
Suggerimenti
Molto probabilmente sarebbe sufficiente se ci fosse un modo per acquisire solo modifiche specifiche dello stato della riga (e correggere il bug).
Gestore dello stato del filtro
Problema
Si attiva troppe volte. Un esempio è che se guardi anche il filtro, il gestore dello stato si attiverà.
Suggerimenti
Rimuovi i trigger non necessari dal gestore dello stato del filtro o dai la possibilità di scegliere quali stati dovrebbero attivare quale funzione.
Pianificatore
Problema
È possibile avere un solo programmatore alla volta e non è possibile nascondere la finestra del programmatore.
Suggerimenti
Consenti la creazione di pianificatori privati (al momento nascondo la finestra e spero che l'utente non la chiuda) e più pianificatori diversi contemporaneamente.
Temo che un ritardo per l'etichetta Hover la farà sembrare "lenta".
Ci sono ottimi esempi in rete di quanto possa essere emozionante un'etichetta hover "live":
https://wid.world/world/#lpfghg_p90p100_z/US;FR;DE;CN;ZA;GB;WO/2020/eu/k/p/yearly/l/false/3.516/100/curve/false/country
Forse:
non aggiornare il contenuto se è esattamente lo stesso di prima?
Appena:
posiziona l'etichetta Hover esistente nella nuova posizione .
@xxvvcczz , gli sviluppatori hanno studiato possibili modifiche a Crea il gestore RowState E Crea un gestore di modifica del filtro . Nessun aggiornamento da condividere ancora.
Ci sono aggiornamenti a riguardo? Sono passati un paio di mesi ormai.
Per favore, correggi il gestore dello stato della riga.
Voglio recuperare gli eventi di selezione al passaggio del mouse e inviare una richiesta http per ottenere dati per l'utente, ma in questo momento è incredibilmente lento e difficile. Sono arrivato al punto di riscrivere l'intero strumento di selezione come una trappola per topi per cercare di ottenere questa funzionalità, voglio solo che il gestore dello stato della riga si attivi una volta alla fine dell'evento di selezione.
https://community.jmp.com/t5/Discussions/Is-there-a-way-to-make-the-rowstate-handler-less-laggy/mp/550590
Grazie per aver inviato questo elenco e per aver fornito suggerimenti. Stiamo attualmente indagando.
@jthi D'accordo, lo scheduler è difficile da usare bene. In Feed di notizie Ho spostato l'oggetto scheduler fuori dalla finestra creata nella mia finestra, ma ciò non risolve il problema del singleton. (Utility.jsl righe 53-64. Utilizzato da httpServer.jsl riga 120.) Sospetto che non sia necessario che si trovi in una finestra una volta rimosso; probabilmente devi solo tenere la maniglia. In FileSnapper Ho utilizzato un approccio solo Windows con runprogram e alcuni comandi DOS. Avrei preferito utilizzare lo scheduler ad eccezione del problema del singleton. Non farlo perché {solo Windows, non a prova di futuro, ha ancora alcuni effetti collaterali}. In entrambi i casi, JSL viene eseguito solo quando JMP ha tempi di inattività, magari durante un wait().
