JsonViewer

Arnaud,

OK, sounds good. Just having it as a viewer is sufficient but I will make it visible and see what happens.

Appreciate,
John…

Dans ton cas, c’est judicieux de faire :
Oui, c’est vrai, je pourrais copier la valeur “action” dans une locale avant le au cas ou. Au demeurant cela m’arrive très souvent avec des commandes :
<code 4D>
au cas ou
:(événement formulaire=…)
:(événement formulaire=…)
</code 4D>
<code 4D>
$evt:=événement formulaire
au cas ou
:($evt=…)
:($evt=…)
</code 4D>
Après, comme le contexte est une réponse à une action d’utilisateur, ça ne se bouscule pas assez au portillon pour que je me sois soucié d’optimiser. Dans un traitement répétitif, je me pose plus de questions. Justement, dans ce viewer, c’est la fabrique du texte stylé qui était horriblement lente - ça concatène à tour de bras, là-dedans. Entre autres tentatives, j’ai remplacé tous les objet.machin par des locales : j’ai été mortifié, résultat quasiment nul. La bonne optimisation été d’oublier les habitudes, de lire la doc, de trouver join() et d’essayer : https://forums.4d.com/Post/FR/15873353/2/28881754#28881754la grosse claque>.
C’est un échange, je ne donne pas de leçon ou quoi que ce soit !!
Pas de souci, au contraire, un partage sans échange, ça manque de sel.

J’utilise depuis un moment ton excellent visualisateur et il m’a fait remarquer un défaut de 4D
Auparavant, j’écrivais Form.current.objectContent:=JSON Stringify(Form;)
et j’avais sur un gros objet un temps de réponse très long, jusqu’à 30 secondes.
Je mets en oeuvre le json viewer et pour le même objet, c’est quasi instantané ; bizarre.
En mettant un trace, je constate que Form.current.objectContent:=JSON Stringify(Form;
) est instantané mais que l’affichage de Form.current.objectContent est dramatiquement long.

Pourquoi l’affichage d’une variable texte de 9000 lignes est-il long, alors que la liste hiérarchique s’affiche quasi-instantanément ??

I think 4D needs to compute the kerning, spacing, style (especially italic and bold), word-wrap etc. for every line “off screen” to count the number of lines and manage the vertical scroll bar. None of that is necessary for a listbox, if “variable row height” is not used. Also the scroll is per-line for the listbox (since v13?), per-pixel for text input. Inserting or deleting text will have an effect on the remainder of the whole text, not just the line, so the entire text must be rendered all the time. For a fair competition, all 9000 lines should be displayed in a single listbox row.

Bonjour Bernard,
“historiquement” j’avais fait comme ça car je m’étais rendu compte que 4D peine à afficher une zone texte avec “trop” de texte. Voilà deux fils sur ce sujet, dans le second Miyako mentionne les parties de la doc où cette limite est documentée :
https://discuss.4d.com/t/variable-objet-invisible/10077
https://discuss.4d.com/t/character-display-limit-text-field-variable-missing-text-after-100k/14032

Dans ton cas, tant que Form.current.objectContent reste en mémoire, ça ira très vite. Mais dès que tu tenteras de le matérialiser dans le formulaire, tout ce qui demande à recalculer l’affichage de ce texte (modification de contenu ou de contenant) va te pourrir l’existence, y compris dans une zone invisible.

Je vois comme alternatives : write pro, liste hiérarchique, listbox.

  • write pro : jamais essayé
  • liste hiérarchique (LH) : j’avais très rapidement abandonné cette piste pour jsonViewer où je devais manipuler l’état “plié/déplié” des niveaux par du code, c’était effroyablement lent (je persiste à penser que ces vieilles commandes LH devraient être remplacées par un jeu de commandes plus moderne avec des objets en paramètres)
  • listbox : que du bonheur