Bascule lecture seulement/lecture écriture à partir d'un formulaire saisie

Bonjour,

je souhaiterais fixer à la volée le pouvoir de modifier ou pas certains enregistrements qu’un utilisateur va parcourir à partir d’un formulaire saisie dans une sélection d’enregistrements.

Pour cela, j’ai défini dans le formulaire une boîte à cocher “en modification” qui bascule la table soit en mode lecture écriture soir en mode lecture. Globalement ça fonctionne, sauf pour le premier enregistrement quand on essaie de le passer en mode écriture à partir d’un état lecture : les champs du formulaire restent non saisissables. Quand on passe à l’enregistrement suivant puis qu’on revient au précédent, ça fonctionne.

Je suppose que le problème vient du statut de la table qui doit être défini avant que l’enregistrement courant soit affiché et du fait qu’on soit dans une pile d’enregistrements. Néanmoins l’utilisation d’un “charger enregistrement” après le changement de statut de la table ne résout pas le problème.

Je peux contourner le problème en laissant la table en lecture écriture et en gérant le statut “saisissable” des champs un par un mais j’aurais préféré une solution plus générale. Il y a sans doute un truc trivial que je n’ai pas compris. Quelqu’un aurait une explication et une solution ?

Pour ton premier enregistrement, il te faut :

  • soit passer la table en lecture écriture dès le départ (mauvaise idée)
  • soit libérer oui charger à nouveau l’enregistrement sur la base de détection que cela est bien ton premier enregistrement

Patrick

Bonjour Gilles,
un formulaire de saisie ouvert par DIALOGUE résout tout cela. À lire ta description, ça n’a pas l’air d’être le cas.

Merci pour vos réponses

J’avais bien sûr essayé diverses combinaisons de Libérer enregistrement et de Charger enregistrement sans que cela résolve le problème.

Je dois préciser le contexte d’exécution : ma table est affichée dans un formulaire-liste (et pas via une list-box) et j’entre “classiquement” en mode saisie par une double-clic. Dans ce fonctionnement, l’appel à un Dialogue paraît non pertinent dans la mesure où le mécanisme de base de 4D appelle automatiquement le formulaire-saisi par défaut. J’avais, en fait, testé l’insertion de la commande Dialogue mais, dans ce contexte, ça vient en plus du double-clic et ça engendre un cycle surnuméraire (je dois cliquer deux fois sur les boutons de validation pour quitter).

En fait le problème advient uniquement quand j’ouvre une fiche, soit à partir du double-clic soit à partir des boutons suivant/précédent, le boîte “en modification” ayant été précédemment décochée (-> table en lecture seulement) : quand je recoche “en modificaiton” les champs du formulaire saisie restent insaisissables alors que les tests indiquent que l’enregistrement est bien déverrouillé. Si j’ouvre un enregistrement avec le bouton précédemment coché, la bascule fonctionne correctement, les champs passent en non saisissable/saisissable comme attendu.

J’ai l’impression qu’il est nécessaire de recharger un nouvel enregistrement pour lever l’état “en lecture seulement” dans ce contexte d’exécution (Charger enregistrement reste inopérant) et que ce que j’essaie de faire va à l’encontre du mécanisme de base de 4D.

Il est effectivement probable que cela fonctionne dans un contexte affichage sous list-box/modification par dialogue mais je n’avais pas prévu de modifier cette partie de l’interface dans l’immédiat.

Bonjour Gilles,

le contexte que tu décris doit évoluer absolument vers l’utilisation de la commande Dialogue pour quitter ce mode ‘classique’ si tu veux profiter des nouveautés de 4D.

: Gilles BAILLY

Je dois préciser le contexte d’exécution : ma table est affichée dans
un formulaire-liste (et pas via une list-box) et j’entre
“classiquement” en mode saisie par une double-clic.
OK, c’est ce que j’avais compris. La gestion du double clic en MODIFIER SELECTION fait partie d’un ensemble d’automatismes contre lesquels il est rapidement fatiguant de se battre ; tu aurais peut-être une possibilité pour contourner avec FILTRER EVENEMENT dans le Sur double clic, mais un (rapide) portage listbox + DIALOGUE sera infiniment plus sûr et pérenne.

Je suis en train de tester la solution préconisée.
Pour le remplacement du mode liste par une list-box dans un formulaire, c’est OK, ça c’est facile à implémenter.

En revanche, l’accès à l’enregistrement via Dialogue ne permet pas de continuer à parcourir la sélection en mode saisi comme souhaité, les boutons enregistrement suivant et précédent étant inopérants dans ce contexte, on revient à la fenêtre list-box après consultation de chaque enregistrement ce qui n’est pas le but.

En fait, dans une interface à partir de list-box, est-il possible de mimer le fonctionnement classique mode liste/parcours-modification des enregistrements en mode saisie/retour mode liste ? Ça semble assez compliqué de prime abord.

En y réfléchissant, j’ai l’impression qu’il faudra en passer par un process indépendant pour le mode saisie, lancé par un évènement double-clic sur le formulaire de la list-box, avec passage en paramètre du numéro d’enregistrement sélectionné. Le process indépendant affichant un dialogue avec boutons de navigation, modification et validation…

Quelque chose comme ça ?

: Gilles BAILLY

En fait, dans une interface à partir de list-box, est-il possible de
mimer le fonctionnement classique mode liste/parcours-modification
des enregistrements en mode saisie/retour mode liste ? Ça semble
assez compliqué de prime abord.
Suivant précédent doit être un des automatismes du visualiser/modifier sélection dont je parlais, bien possible qu’il soit inutilisable.

Dans le même process que la listbox, le fait de saisir avec DIALOGUE ne change rien à l’enregistrement courant et à la sélection courante. Tu vas juste devoir programmer des boutons dans l’écran de saisie, sans action automatique, avec des choses comme “si ce n’est pas le dernier enregistrement, faire enregistrement suivant, sinon faire tût tût pouêt”. Si tu optes pour la saisie dans un nouveau process, il faudra “envoyer” la sélection à ce dernier pour programmer suivant/précédent, gérer sur double clic si l’enregistrement est déjà ouvert, etc. Ce sera plus “codophage”, je pense.

Tant qu’à revisiter, tu peux peut-être proposer la saisie dans le même formulaire que la listbox (regarde le carnet d’adresse du mac, comme exemple) : un clic dans la listbox à gauche affiche l’enregistrement dans un sous formulaire à droite (fixer sous formulaire) ; dans ce dernier un bouton “modifier” permet de passer l’enregistrement en saisie (écriture). Ça évite de se faire suer avec suivant précédent…

Pour le caractère inopérant des boutons suivant/précédant en contexte de dialogue, je confirme.
Il faut remplacer les actions par défaut par des procédures manuelles ce qui n’est pas très compliqué.

J’avance petit à petit.
Je suppose que la commande MODIFIER ENREGISTREMENT est indispensable pour passer les champs en saisissable ? Son utilisation dans un dialogue est un peu compliquée à gérer dans la mesure où elle produit un cycle de rechargement du formulaire avec divers problèmes collatéraux d’ergonomie.

Par ailleurs, il semblerait que les commandes FIXER LIEN CHAMP, déclarées en début de process, soit inopérantes : les valeurs des champs des tables liées ne s’affichent pas dans le dialogue à moins de déclarer explicitement les CHARGER SUR LIEN nécessaires au niveau des boutons de navigation suivant/précédent, ce qui interdit de généraliser la procédure pour d’autres tables. Ou alors quelque chose m’a échappé ?

Je suppose que la commande MODIFIER ENREGISTREMENT est indispensable
Raté : tu as opté pour DIALOGUE : c’est l’une OU l’autre, fromage OU dessert, la crémière OU son *
DIALOGUE remplace aussi bien MODIFIER ENREGISTREMENT que AJOUTER ENREGISTREMENT.
Ce qui détermine que les champs sont saisissables est :

  • il y a un enregistrement “courant” :
    – en modification, il a été cherché et chargé en écriture
    – en ajout, il a été obtenu par CREER ENREGISTREMENT
  • la table doit être en écriture

il semblerait que les commandes FIXER LIEN CHAMP, déclarées en début
de process, soit inopérantes
Le chargement des “pères” ne se fait que si tu le demandes (gentiment), mais apparemment tu es sur la bonne voie :
1/ faire les FIXER LIEN CHAMP idoines pour le contexte (=le process), comme tu l’as fait
2/ faire http://doc.4d.com/4Dv17/4D/17/CHARGER-SUR-LIEN.301-3730101.fr.htmlCHARGER SUR LIEN>([laTable]) dans le Sur chargement du formulaire ; avec cette syntaxe, non seulement 4D charge (gentiment) tous les “pères” de l’enregistrement courant dont tu as fixé les liens aller à automatique, mais il le fait en une seule requête au serveur.
ce qui interdit de généraliser la procédure pour d’autres tables
Ceci devrait faire l’affaire :
CHARGER SUR LIEN(Table du formulaire courant->)

Le mot manquant était “minois”
honni soit qui mal y pense.

Merci pour cette disponibilité en ce 15 août.

Concernant le chargement des liens, ça fonctionne effectivement.
J’ai dû introduire le CHARGER SUR LIEN(Table) dans la procédure des boutons de navigation suivant/précédent ; ça ne fonctionne pas dans l’évènement Sur chargement du formulaire pour la raison, je pense, que c’est un dialogue et qu’il est chargé une seule fois et pas lors de la navigation entre enregistrements.

CHARGER SUR LIEN(Table du formulaire courant->) est une bonne idée mais, en l’occurrence, j’utilise (peut-être à tort) un formulaire projet donc pas de Table liée. Mais ça va aussi bien avec CHARGER SUR LIEN (pointeur sur Table->) avec pointeur déclaré en début de process et c’est généralisable (quoique moins joli certes). À voir par la suite s’il est intéressant de rester en formulaire projet ou de le redescendre en formulaire table…

Si j’ai abordé le MODIFIER ENREGISTREMENT, c’est que jusqu’à présent je n’arrive toujours pas à double-cliquer sur mes champs. J’y suis parvenu uniquement en introduisant un MODIFIER ENREGISTREMENT tout en me doutant que ça ne devait pas être bien licite…

La table est pourtant bien passée en lecture, les enregistrements déverrouillés et chargés par CHARGER ENREGISTREMENT, les champs tabulables dans le formulaire… Quand je trace la procédure, les champs du formulaire sont saisissable dans l’éditeur du mode Trace. Je me demande bien ce qui peut bloquer. Je m’attends à un truc trivial.

Je suis en 4Dv15 pour information.

Pour en avoir le cœur net, j’ai élaboré un dispositif ultra-simple :
– un formulaire hébergeant un seul champ modifiable de ma table
– appelé par DIALOGUE
– et muni d’un bouton Modifier exécutant :

LECTURE ECRITURE ([maTable])
ALLER A ENREGISTEMENT([maTable];numéro d’enregistrement)
si(Enregistrement verrouillé([maTable])=Faux)
CHARGER ENREGISTREMENT([maTable])
BEEP (pour me confirme l’exécution)
fin de si

Le champ est bien valorisé.
Néanmoins impossible de double-cliquer sur le champ pour le modifier.

Ya kekchose qui m’échappe définitivement.

La préférence de compatibilité “les champs sont saisissables dans les dialogues” est bien cochée ?

AAAARRGGHHH

non

:oops:

N’aurais jamais pensé à aller voir là.

Merci merci

Résolu

Plus qu’à se retrousser les manches pour la suite.

: Gilles BAILLY

N’aurais jamais pensé à aller voir là.
hi hi hi, il s’est fait eu :wink:
Bon, cela dit, telle qu’elle est interfacée, il n’est guère étonnant que cette page des compatibilités ne provoque pas l’enthousiasme. Seul un esprit retors peut avoir décidé qu’une case cochée peut signifier tantôt qu’on est à jour, tantôt qu’on ne l’est pas (*)…

Bon dialogues !

(*) y’a pas que moi que ça turlupine :
http://forums.4d.com/Post/FR/18563516/1/18563517#18563517
http://forums.4d.com/Post/EN/17596986#17596987
http://forums.4d.com/Post/FR/11705072/1/11705073#11705073