|
FORUMS PROFESSIONNELS WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Champ HTML dans une zone répétée |
| Débuté par Florian, 16 nov. 2025 13:21 - 4 réponses |
| |
| | | |
|
| |
| Posté le 16 novembre 2025 - 13:21 |
Bonjour,
J'essaye d'intégrer un champ affichage HTML dans une zone répétée dans le but de mettre en forme le contenu de la répétition, en fournissant directement le code HTML à afficher. Le contenu pouvant varier, la hauteur du champ HTML doit s'adapter, de fait j'utilise l'ancrage au contenu en hauteur.
L'objectif est de fournir à l'utilisateur un contenu formaté, facilement lisible (titres, listes à puces, etc) et sélectionnable/copiable.
Je rencontre cependant de sérieux problèmes de performances :
1. Dans le cas d'un champ affichage HTML directement dans la zone répétée, la hauteur du champ ne s'adapte pas à son contenu. 2. Dans le cas d'une fenêtre interne contenant un champ affichage HTML dans la zone répétée, parfois la hauteur du champ et de la fenêtre s'adaptent correctement au contenu, parfois il est nécessaire de cliquer/scroller sur le champ pour que ça fonctionne. Et des fois ça ne fonctionne juste pas. De plus, chaque modification du champ fait sauter l'affichage : curseur de chargement en cours, clignotement du champ, retour à la hauteur initiale puis adaptation de la hauteur au contenu.
Bref en l'état ce n'est pas exploitable.
Avez-vous déjà essayé d'obtenir ce genre de rendu? Voyez-vous des choses à modifier ou des alternatives ?
J'ai bien pensé à faire dans ma zone repétée une répétition avec un champ libellé par partie (titre, paragraphe etc), chacun avec son propre format, mais le contenu des libellés n'est pas sélectionnable et ce n'est donc pas envisageable. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 995 messages |
|
| Posté le 17 novembre 2025 - 09:48 |
Bonjour, Avez-vous essayé avec un Champ de Saisie en RTF ? Cdlt |
| |
| |
| | | |
|
| | |
| |
| Posté le 17 novembre 2025 - 11:41 |
Bonjour Cédric,
J'avais pensé au RTF mais je construis le contenu par programmation, la syntaxe HTML est beaucoup plus simple que la syntaxe RTF.
Je vais regarder si la conversion HTML -> RTF peut se faire sans usine à gaz, auquel cas je testerai cette option.
Merci ! |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 995 messages |
|
| Posté le 17 novembre 2025 - 13:15 |
Il y a une fonction HTMLVersRTF. Voir si elle convient mais le passage par HTML n'est peut être pas nécessaire dans ce cas.Message modifié, 17 novembre 2025 - 13:17 |
| |
| |
| | | |
|
| | |
| |
| Posté le 17 novembre 2025 - 15:32 |
Alors effectivement il y a une fonction HTMLVersRTF qui gère les principales balises. Elle manque de gestion des styles notamment, mais j'ai quand même testé sans en tenir compte pour éventuellement valider le concept, et j'ai toujours certains problèmes :
1. Le clignotement au scroll ou au survol de la ZR 2. Un blanc de facile 800 ajouté dans la zone de saisie de la ZR, en dessous du contenu 3. La sélection du contenu des champs RTF est impossible après le chargement des données de la ZR. Visiblement un redimensionnement de la ZR résout le problème (d'ailleurs ça élimine aussi le blanc en 2.)
J'ai également essayé avec une table contenant du RTF : l'affichage est à peu près ok, à part le fait qu'ajouter des marges à la colonne ou aux cellules rogne le contenu. De plus il semble être impossible de rendre le contenu sélectionnable sans mettre la table et la colonne en saisie.
En bref j'ai l'impression de tourner en rond ! Aucune solution ne cumule affichage fluide, mise en page sans défaut et sélection possible. Pourtant je ne me souviens pas avoir eu tant de problèmes avec les ZR dans le passé. J'imagine que je n'avais pas besoin d'interagir avec le contenu ou de l'actualiser régulièrement par programmation. |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|