Fonctionnalités sous V17 (notamment éditeur de recherche)

Product :4D - 4D Server
4D : v17
OS : Windows

Bonjour,
Avez-vous connaissance d’une fonctionnalité similaire en v17 (ORDA) à l’éditeur de recherche ?
Un plugin ou autre ?
Pour le moment j’ai fait une zone de recherche simple permettant à l’utilisateur de sélectionner le champ qu’il souhaite rechercher, une popup avec les mots clés, et le mot clé à rechercher.
Je pourrais l’améliorer en faisant un formulaire maison et dupliquer chacune de cette ligne de recherche, ce qui lui permettrait de faire une recherche multi critères mais si je peux gagner du temps ça m’arrangerait à ce jour.

Autre chose, j’aimerais ajouter des zones de saisie pour chacune des lignes d’une colonne mais je ne crois que cela existe ?
un bouton enregistrer permettrait de mettre à jour les entités de la listbox où le champ de saisie n’est pas vide.

[]27997463;“ex_formulaireAvecSaisie”[/]

Merci

Quelle(s) est(sont) la(les) raison(s) pour ne pas utiliser l’éditeur de recherche 4D ?

Une piste (payante…) pourrait être d’utiliser la fonctionnalité de 4D View Pro sur les listbox
[]27998734;“recherches spécifiques en utilisant une listbox avec 4D View Pro…”[/]

Pour éviter de devoir utiliser de la V16 et de la V17. L’application sur laquelle je travaille est presque en full v.17 (hors impression par ex)
Pour une question de maintenance et d’homogénéité (les utilisateurs doivent retrouver les mêmes fonctionnalités sur tous les formulaires) c’est plus cohérent que je reste le + possible sur de la v17.
Pour un formulaire spécifique qui comporte de nombreux champs il est important que j’offre aux utilisateurs un vrai formulaire de recherche.
Je ne peux pas utiliser de solutions payantes, mais merci pour vos réponses. Je crois que je vais finir par le coder moi-même, pas compliqué en soi mais je manque juste de temps :]
Bonne après-midi

J’ai pas tous compris :-? l’éditeur de recherche 4D étant resté le même entre la v16 et le v17.
C’est sûr que de devoir se retaper un formulaire de recherche spécifique par table, ben c’est long… :wink:

Dans certains formulaires je présente les informations de mes entités dans des listbox, pour cela je charge mes objets avec la commande Form.
Derrière je fais de nombreux traitements sur chacun de mes objets en v.17 (la v.17 bien que loiin d’un langage objet reste tout même beaucoup plus lisible, moins verbeux et donc plus facile à maintenir à mon sens que les anciennes versions).

Au sujet de l’objet pour lequel je souhaite un formulaire de recherche, j’ai donc un mixte entre de la v16 et v17.
v16 pour charger mes infos dans la listBox ex :
[Voiture]marque | [Voiture]modele]
ce qui me permet d’utiliser l’éditeur de recherche en appelant la commande QUERY(Current form table->)
mais cela m’oblige aussi, pour d’autres fonctionnalités, d’utiliser de la v.16.
Par contre quand j’affiche l’éditeur de saisie ou d’édition d’une voiture de ma listbox, tout le traitement est fait en v17.
C’est pourquoi j’aimerai faire du full v17,le code est plus lisible, et comme je disais plus haut le code doit rester homogène.

Difficile d’expliquer par le biais d’un forum :]

Je pense comprendre que vous utilisez le language objet (ou des objets) de la v17 et dans ce cas effectivement il n’y a pas (encore ?) d’éditeur de recherche adapté réellement pour ce style de recherche… :cry:

Oui désolé effectivement je parlais du langage objet 4D (c’est que j’essaie de ne faire que de l’objet travaillant depuis peu sur 4D pour moi les anciennes versions sont un casse tête)

Si tu n’as pas envie de refaire un éditeur de recherche, tu peux faire sale : utiliser celui de 4D puis convertir la sélection courante obtenue en entity selection avec https://doc.4d.com/4Dv17R2/4D/17-R2.1720/Creer-entity-selection.301-3857748.fr.htmlCreer entity selection>.

Cela dit, il faut aussi se poser la question de cet éditeur, il n’est pas vraiment fait pour le quotidien de l’utilisateur. Avec ta simple zone de recherche, tu pourrais déjà faire beaucoup pour lui. Exemples :

  • par défaut ça cherche dans toutes les colonnes visibles ; si l’utilisateur clique sur l’une d’elle, ça limite la recherche à celle-là
  • si la colonne est une date, un nombre, un texte et ainsi de suite on peut ajouter des tas d’astuces pour exprimer ce qu’on cherche (un montant : entre x et y, les dates : la semaine dernière…)
  • on peut ajouter des boutons radio pour chercher : “normal”, dans la sélection, ajouter à la sélection, soustraire de la sélection…
    Bref, avant qu’il ne trouve pas ce dont il a besoin, il y a de la marge…

Bonjour,
Du coup je suis partie sur cette solution de convertir la sélection courante, j’ai refait tout mon formulaire en objet c’est mieux ainsi, et pas si sale que ça :] (puis il avait déjà fallu que j’utilise cette méthode donc bon)
Effectivement j’étais pas forcément pour conserver l’éditeur de recherche, il est fonctionnel mais pas très lisible, puis l’utilisateur sélectionne les champs des tables, qui ne sont pas toujours parlant pour lui. Mais dans ce cas précis, il a besoin de rechercher dans plusieurs tables, sur plusieurs critères, ça va me dépanner le temps de faire un truc + jojo en “objet”.
Sur les autres formulaires par contre j’ai conservé celui que j’ai fait, simple mais suffisant pour l’utilisateur et il lui permet tout de même de faire des recherches sur quelques critères (les champs de la table, sur les dates…).
Merci et bonne journée