Discussion :

[Jean-Marc JULES]

J'ai une question à poser sur ce forum.
Elle ne concerne pas le développement sur Mac OSX, mais celui avec 4D 2004.
Comme l'emploi de ce forum m'est très difficile à comprendre, je poste cette demande sans doute à l'endroit inadéquat, en espérant que quelqu'un pourra me guider.
Le problème est (4D 2004.5,MacOSX.4)
la variable OK est une variable système, donc par définition toujours définie.Dans un bouton défini sans action, comportant une méthode objet pour enrgitrer des donnée du formulaire sur lequel il est, l'execution de la méthode est bloquée lors du test de la variable OK (test: si(OK=1). Le déboqueur indique que les opérateurs ne sont pas compatibles car la variable OK est inféfinie.
Ce probléme s'était produit avec 4D 2003, avait disparu un temps sous 4D 2004, puis est réapparu.
S'agit-il d'un bug de 4D?

[ThibArg]

Bonjour,

Les variables "système" de 4D (OK, Error, etc.) ne sont définies avec certitude qu'en mode compilé. En interprété, tant qu'une action quelconque n'a pas défini et initialisé OK (par exemple : CHRCHER, TRIER, DIALOGUE, Ouvrir document, etc... bref, n'importe quelle commande qui modifie OK. Avec 4D 2003, on avait une liste de ces commandes, on ne l'a plus avec 4D 2004), cette variable peut rester indéfinie pour le process (puisqu'OK est une variable process, elle doit être déclarée pour chaque process qui l'utilise).

Mais c'est vrai qu'on aimerait bien que 4D le fasse pour nous au lancement de chaque process.

Thibaud

[Jean-Marc JULES]

Merci de votre réponse.
Le test de la variable OK suit un STOCKER ENREGISTREMENT placé dans un bouton (sans action) de format.
Il n'est effectivement pas spécifié dans la documentation que la variable OK est mise à 1 après cette commande.
C'est par contre spécifié pour la commande VALIDER qui a le même effet dans un bouton de format de formulaire de saisie (définie par FORMULAIRE ENTREE)
J'ai donc remplacé STOCKER ENREGISTREMENT par VALIDER, mais la variable OK reste indéfinie.
Cette anomalie avait disparu lorsque j'ai migré de 2004.1 en 2004.5, puis elle a réaaparu.
La compilation ne détecte aucune anomalie ni aucun warning.

[ThibArg]

Merci de votre réponse.
Le test de la variable OK suit un STOCKER ENREGISTREMENT placé dans un bouton (sans action) de format.
Il n'est effectivement pas spécifié dans la documentation que la variable OK est mise à 1 après cette commande.
C'est par contre spécifié pour la commande VALIDER qui a le même effet dans un bouton de format de formulaire de saisie (définie par FORMULAIRE ENTREE)
J'ai donc remplacé STOCKER ENREGISTREMENT par VALIDER, mais la variable OK reste indéfinie.
Cette anomalie avait disparu lorsque j'ai migré de 2004.1 en 2004.5, puis elle a réaaparu.
La compilation ne détecte aucune anomalie ni aucun warning.

C'est normal que la compilation ne détecte pas d'anomalie et n'affiche pas de warnings, le compilateur connait les variables système de 4D. Tu me diras que 4D aussi , mais il y a une différence (dans 4D) entre connaitre le type d'une variable et son existence réelle, en mémoire. Avec 4D, une variable peut être à la fois typée et indéfinie (en compilé, seuls les tableaux sont concernés).

Quand à VALIDER (ou NE PAS VALIDER), t'as pas de bol ;-), 4D met OK à 1 uniquement à la "sortie" du formulaire, pas immédiatement lors de l'appel à l'une de ces commandes :

` ici, OK indéfinie en interprété si jamais
` utilisée dans le process
AJOUTER ENREGISTREMENT(...)
` => bouton ou code qui fait VALIDER
` => tant que le formulaire n'est pas fermé, OK reste indéfinie
Si(OK=1) ` appel valide, 4D a mis OK à jour

Ce que tu peux faire, c'est explicitement déclarer OK au début de ton process, ou dans "Sur chargement" du formulaire :
Au cas ou
Evenement formulaire = sur chargement)
C_ENTIER LONG(OK)

FIn de cas

A+

Thibaud

[Jean-Marc JULES]

Merci à Thibaud pour ces explications.
Toutefois, je n'ai pas précisé que mon application comporte plusieurs tables, avec chacune son formulaire de saisie.
Le bouton de validation comporte les mêmes métodes génériques, frâce à des pointeurs, quelque soit la table et le formulaire.
La variable OK est définie (et affectée de 1) dans tous les cas sauf dans 1 formulaire, toujours le même...
La logique des faits n'est donc pas totalement claire.
JMJ

[ThibArg]

Une explication possible, c'est que le formulaire pour lequel ça arrive est exécuté dans un nouveau process, qui n'a jamais connu OK. Est-ce le cas ?

(et on est en interprété : si tu compiles, je penses que - sur ce plan là - ça marchera)

Thibaud

[Jean-Marc JULES]

Oui, c'est le cas, il s'agit d'un nouveau process.
En compilé, j'ai testé avec des alertes me donnant la valeur de OK, qui est à 0 apres STOCKER ENREGISTREMENT, sans doute car 4D ne l'a pas définie et qu'elle est donc à 0 par défaut???
Il semble donc impossible de tester OK dans le bouton de validation d'un formulaire saisie:
OK est indéfinie tant qu ele formulaire est chargé.
Tester OK apres la désactivation du formulaire qui se fait par NE PAS VALIDER, donne toujours 0 par définition.
Je n'ai pas trouvé d'autre moyen de fermer le formulaire avec un de ses propres boutons.
Je ne crois pas qu'il soit adapté de type une variable systeme avce C_ENTIER, car c'est justement la tâche du systéme...

[ThibArg]

En compilé, toutes les variables (hors tableaux, c'est autre chose) sont explicitement initialisées au lancement de chaque process : OK en fait partie et vaut donc 0 par défaut.

STOCKER ENREGISTREMENT n'est pas une commande qui modifie OK, c'est donc normal que OK reste inchangé après l'appel.

VALIDER ENREGISTREMENT ne met OK à 1 (et NE PAS VALIDER à 0) qu'une fois le formulaire fermé : c'est donc seulement l'appelant qui peut recevoir cette valeur.

D'ailleurs, si tu faios successivenemtn :
STOCKER ENREGISTREMENT
OK:=1
NE PAS VALIDER


On peut redéclarer des variables tant qu'on ne change pas leur type : écrire C_ENTIER LONG(OK) est tout à fait valide : en interprété, ça va te soulager de ton problème, en compilé, l'instruction n'aura complement aucun effet (enfin, 4D Compiler vérifiera que OK n'est pas retypé dans un autre type, mais c'est tout).

[ThibArg]

[arg zut, j'ai tapé la touche retour après une tabulation...]

Bref, donc : "si tu faios successivenemtn" voulait dire "Si tu fais successivement" :-)... Bon, je reprends.

En compilé, toutes les variables (hors tableaux, c'est autre chose) sont explicitement initialisées au lancement de chaque process : OK en fait partie et vaut donc 0 par défaut.

STOCKER ENREGISTREMENT n'est pas une commande qui modifie OK, c'est donc normal que OK reste inchangé après l'appel (que la variable vaille 0 ou 1, peu importe)

D'ailleurs, si tu fais successivement...
STOCKER ENREGISTREMENT
OK:=1
NE PAS VALIDER
... OK sera remis à 0 pas 4D pour l'appelant.


VALIDER ENREGISTREMENT modifie OK (de même que NE PAS VALIDER), mais seulement une fois le formulaire fermé : c'est donc seulement l'appelant qui peut recevoir cette valeur : la tester au sein du code du formulaire ne machera pas, à moins que tu ne l'initialises toi même :

STOCKER ENREGISTREMENT
OK:=1
VALIDER

=> Là, dans le code du formualire, tout baigne, tu peux tester OK. Idem si tu veux annuler :
OK:=0
NE PAS VALIDER

On peut redéclarer des variables tant qu'on ne change pas leur type : écrire C_ENTIER LONG(OK) est tout à fait valide : en interprété, ça va te soulager de ton problème, en compilé, l'instruction n'aura complement aucun effet (enfin, 4D Compiler vérifiera que OK n'est pas retypé dans un autre type, mais c'est tout). DOnc, si tu as un code générique de chargement de tes frmulaires tu peux sans aucun risque mettre C_ENTIER LONG(OK) dedans (avec un rappel : l'instrucion de typage ne modifie pas la variable : si OK valait 1 avant C_ENTIER LONG, il vaudra toujours 1 après)

Thibaud