Form. : décidément j'ai du mal avec cette commande

Soit un formulaire ouvert avec Dialogue et un objet passé en parametre.

dans mons formulaire j’ai un objet (variable) nommée “VarDate” dont la valeur est une expression :
Form.VarDate

jusqu’ici cela fonctionne.

Maintenant, si j’execute cette commande:

<code 4D>
C_POINTEUR($Ptr_Date)
$Ptr_Date:=OBJET Lire pointeur(Objet nommé;“VarDate”)

</code 4D>

J’obtiens un pointeur Nil :?: :!:

Est-ce normal ?

En attendant, je suis obligé de faire cela:

<code 4D>
C_ENTIER LONG($Event)
$Event:=Événement formulaire

Au cas ou
: ($Event=Sur chargement)
(OBJET Lire pointeur(Objet nommé;“VarDateModif”))->:=Form.VarDateModif
: ($Event=Sur libération)
Form.VarDateModif:=(OBJET Lire pointeur(Objet nommé;“VarDateModif”))->
Fin de cas

</code 4D>

mais, je trouve ça lourd et contraignant… :frowning:

Bonsoir Manuel,

je ne comprend pas ton problème.
Voici ce que je fais (en espérant ne pas m’attirer les foudres d’un super mega user)

<code 4D>
C_Object($MonObj)
$MonObj:=new object
$MonObj.propA:=""
$MonObj.propB:=1000
$MonObj.propA:=current date
// (et ainsi que suite)

// J’ouvre ensuite mon dialogue
$Win:=Open form window([MaTable];“Saisie”;)
DIALOG([MaTable];“Saisie”;$data;
)
</code 4D>

Ensuite, pendant toute la durée de vie du dialogue, je travaille uniquement avec les objets
Form.propA
Form.propB
Form.propC

SI j’ai besoin de la valeur dans mon formulaire, alors j’utilise directement l’appel ‘Form.propXX’.
Si tu dois sauvegarder les informations, alors il te faut le gérer dans ton bouton de validation

Patrick

J’ai dans mon formulaire un objet (une variable) à laquelle j’ai
affecté l’expression “Form.propA”
l’utilises tu de cette façon également ?

Si oui as-tu déjà essayé de lire un pointeur sur cet objet ?

Avec une objet standard (champ/variable normal) ou sans nom de
variable (variable dynamique) cela fonctionne bien.

Avec un objet ayant une expression “Form.xxx”, on ne peut plus lire de
pointeur sur l’objet et toutes méthodes génériques permettant de
mettre à jour l’objet ne peuvent plus fonctionner.

J’ai loupé un truc… :?:

: Patrick EMANUEL

Si tu dois sauvegarder les informations, alors il te faut le gérer
dans ton bouton de validation

Non, si tu l’affectes directement à un objet formulaire, si tu la modifie; ton objet (et sa propriété) est modifié également.

: Manuel PIQUET

J’ai dans mon formulaire un objet (une variable) à laquelle j’ai
affecté l’expression “Form.propA”

Je dirais aussi qu’il y a un problème de rhétorique:

On n’affecte pas une variable à l’expression “Form.propA” car la variable EST “Form.propA”.

Tu as raison j’aurais du mettre le terme “variable” entre cotes.
C’était pour expliqué le “type” d’objet tracé (zone texte, listbox, champ, variable) dans mon formulaire pas pour définir son vrai type.

Mais, cela ne répond pas à ma question… :razz:

L’utilisation de cette expression limite les possibilités, et cela est nouveau par rapport à avant, où même en utilisant les variables dynamiques, on n’avait pas de problème pour pointer sur un objet formulaire !

Comment on lit/fixe l’expression d’un objet formulaire par programmation ?

<code 4D>
C_POINTEUR($Ptr)
$Ptr:=OBJET Lire source données(*;“Variable”)

</code 4D>

me retourne toujours un pointeur Nil sur un objet ayant une expression “Form.param”

Bonjour Manuel,

dans un autre
http://forums.4d.com/Post/FR/25081539/1/25084523#25084523thread>,
Laurent Esnault à écrit :

: Laurent Esnault

The ‘Form’ expression is neither a field nor a variable

C’est pour cela que tu n’aura jamais autre chose que Nil.

J’entends cela, mais il y a de nombreuses limitations à utiliser cette commande.

Plus je l’utilise, et plus je suis confronté à ces limitations.

On ne peut pas pointer dessus.
On ne peut pas utiliser Self dans une méthode d’une objet ayant pour expression Form.xxx

Faire du générique avec ces limitations devient TRES compliqué.

Bonjour,

: Manuel PIQUET

On ne peut pas utiliser Self dans une méthode d’une objet ayant pour
expression Form.xxx

Moi je trouve cela super car cela m’évitera de trouver dans les bases que j’expertise des horreurs construites (je pense que le mot est très mal choisi) à base de SELF sous prétexte de faire du générique là ou c’est inutile.
De plus construire aujourd’hui une interface à base de SELF n’est pas vraiment la voie recommandée par la documentation :
<<Cette commande est conservée pour des raisons de compatibilité uniquement. A compter de la version 12 de 4D, il est conseillé d’utiliser la commande OBJET Lire pointeur>>

Cordialement,

Faut pas non plus simplifier tellement qu’on ne peut plus rien faire… :-?

Un exemple:

Soit une case à cocher sur laquelle j’affecte l’expression “Form.Appliquer1” je ne peux plus lire d’une façon générique la valeur de cette case à cocher !

Un simple code qui permet de cocher/décocher toutes mes cases (en maintenant une touche de modification) n’est plus possible… :roll:

Je suis obligé d’utiliser la même expression dans la méthode objet qui est affectée à l’objet, c’est un peu bête quand même…

Et Objet lire pointeur ne m’aide pas puisque cela ne fonctionne pas !

Je suis en train de reprendre une application (je la réécris) avec la v17.
J’utilise exclusivement des concepts ORDA, des formulaires avec des Form.xxxx, la commande Storage etc… et j’avoue que j’ai gagné un temps fou par rapport à ce que j’ai déjà réalisé en pure 4D. Je perds du temps car il me faut acquérir les concepts nécessaires mais globalement, je suis bien en deçà de ce que cela m’aurait pris en pur 4D. et je ne suis en aucun cas bloqué par la notion de pointeur (je n’en ai pas un seul pour le moment).
J’arrive même à faire des “génériques” en utilisant Form, des objets ou des collections, pour dire.

Par contre, je ne suis pas parti du principe que j’intégrai ces nouvelles commandes / fonctionnalités dans du code 4D, mais l’inverse, c’est-à-dire que lorsque je ne peux (ou arrive pas) à faire ce que je veux, alors je bascule sur du code 4D et pour le moment, cela doit représenter 10-15% de mon code actuel.
Il me semble que cela est plus facile dans ce sens que l’inverse car toutes ces dernières commandes sont tellement puissantes que l’on peut se demander pourquoi elles ne sont pas arrivées plus tôt :wink:

Patrick

Il ne faut pas mélanger ORDA et Form qui sont 2 choses distinctes. Personne ne remet en cause la formidable avancée qu’est ORDA.

L’utilisation de la commande Form apporte des limites qu’on ne connaissait pas avant (même avec l’introduction des variables dynamiques).

Pour moi, il manque la possibilité de “travailler” sur les objets possédant une expression Form.xxx.

Comment on lit cette expression ? comment on l’applique ? On ne peut pas pointer dessus, ni lire la valeur sans devoir utiliser l’expression en elle même. Le nom de l’objet ne sert plus à rien dans ce contexte ?!

: Manuel PIQUET

Comment on lit cette expression ? comment on l’applique ? On ne peut
pas pointer dessus, ni lire la valeur sans devoir utiliser
l’expression en elle même.
Quand j’ai besoin de travailler sur l’expression, je repasse par une variable locale.

: Manuel PIQUET

Le nom de l’objet ne sert plus à rien dans ce contexte ?!
Oui, je suis d’accord.

Maintenant, je peux me tromper, mais Form est pour moi, même si cela n’est pas de l’ORDA pur, est à mi-chemin entre le 4D classique et ORDA, langage ‘objet’.

Tu dis réussir à faire du code générique avec Form ?!
Comment tu fais ?
Une methode générique que l’on applique à un objet possédant l’expression Form.XXX dans sa propre méthode objet, on est OBLIGÉ de taper l’expression en entier pour désigner l’objet. Imagines avec 20 cases à cocher, pour CHAQUE méthode objet, on est obligé de faire varier le code avec autant de risque d’erreur; bref, ce n’est pas ce que j’appelle une amélioration…

Il nous faudrait à minima l’equivalent de Self (ou de Objet lire pointeur) non pas pour avoir le pointeur sur l’objet, mais pour au moins pouvoir passer la valeur de l’objet sans devoir réécrire l’expression dans son ensemble.

: Manuel PIQUET

Tu dis réussir à faire du code générique avec Form ?!
Comment tu fais ?

Comme je l’ai écrit, je redéveloppe une application depuis 0. J’ai donc, pour certaines propriétés communes, définit un standard de nommage aussi bien des champs que des variables. DU coup, cela me permet de faire du générique (ou standard). Quand j’ai besoin de spécificité, j’ai dans mon Form une propriété “exception” qui me permet de le gérer
Non seulement cela simplifie ma gestion, mais en plus, cela la rend beaucoup plus lisible.

Pour reprendre ton exemple des cases à cocher, as-tu essayé un truc du genre (non testé) :

<code 4D>
$nomDeCase:=“MaCase”
boucle($a;1;20)
$nomCaseForm:=$nomDeCase+string($a;“00”)
$objet:=Form[$nomCaseForm]
// FAIRE CE QU’IL FAUT ICI
fin de boucle
</code 4D>

Bonjour,

: Manuel PIQUET

Et Objet lire pointeur ne m’aide pas puisque cela ne fonctionne pas !

Lors de la post-classe du summit, j’avais un slide qui donnait les règles pour les développements en v17. La règle numéro 1 était :
Oubliez les numéros et les pointeurs, utilisez les noms : l’objet passe par des noms

Un pointeur sur une expression n’a pas de sens. Donc on oublie. Il faut bien penser que l’utilisation des nouvelles commandes demande une nouvelle approche (comme l’a bien expliqué Patrick E.). Persister avec des anciens principes de développement et vouloir utiliser en même temps des nouvelles commandes … amène dans le mur. Vous en faites l’expérience aujourd’hui.
Il est grand temps de mettre à la poubelle le “tout générique dogmatique” et commencer à réfléchir à la façon de coder les choses simplement.
Pour cocher toutes les cases de mon formulaire, j’affecterai directement les attributs de l’objet Form.

Cordialement,

Je veux bien faire table raze de tout ce que je connais pour faire
autre chose.
Maintenant La question : comment on fait ?

Cela était possible avant, cela n’est plus possible maintenant.

: Olivier DESCHANELS

Pour cocher toutes les cases de mon formulaire, j’affecterai
directement les attributs de l’objet Form.

Pour pouvoir faire cela, il faut pouvoir lire la valeur de l’objet formulaire que l’on coche.
Et NON, je ne veux pas me retrouver à avoir une méthode objet différente par case à cocher.
(càd. je ne veux pas me retrouver à devoir passer le nom de mon expression passée en paramètre d’une méthode)

Je fais comment ? (c’était possible avant avec du code (oh ! sacrilège :roll: générique) cela n’est plus possible maintenant… J’appelle cela une regression (ou pour le moins ce n’est PAS une simplification…).

Un code générique utilisé à bon escient n’est pas contre productif; au contraire, il permet d’éviter des erreurs dans la saisie c’est encore plus vrai maintenant avec les noms des paramètres d’objets.

Je veux un équivalent de This(Self , Objet lire pointeur, ou ce que vous voulez) utilisable dans les méthodes objet qui renvoit, non pas un pointeur, mais la valeur de l’objet(Formulaire) qui execute la dite méthode Objet.

Bonjour,

: Manuel PIQUET

Et NON, je ne veux pas me retrouver à avoir une méthode objet
différente par case à cocher.
Voici ce que j’appelais plus haut une position dogmatique. Avec de telles positions on ne peut avancer. Donc je ne peux aider une personne qui lutte contre l’esprit même de 4D.

Cordialement,