Discussion :

[N2XF3]

Bonjour,

Je suis un peu perdu avec les différentes actions qui nous sont mises à disposition.
Par exemple dans le cas d'une modification nous avons:
AVANT_MOD, MODIF, INIMOD, VERIF_MOD...

Je souhaite calculer un champ spé sur les lignes de l'écran SIH4 (lignes factures) avant la transaction de modification ou de création de la facture pour ne pas avoir à réenregistrer la pièce une seconde fois.

Il y a quelques infos dans la documentation concernant INIMOD:
"Cette action est appelée lors de la transaction de modification, juste avant l'instruction Rewrite : les transferts de données vers la classe [F] à partir des champs des écrans ont été faits"


donc si je comprends bien c'est trop tard pour que les modifications apportées à l'écran soient prises en compte lors de l'enregistrement.

Pourriez-vous m'indiquer quel est la meilleure façon de procéder ?
Est-ce que je peux me placer dans AVANT_MOD ? Ou bien devrais-je mettre à jour la classe F directement plutôt que l'écran via une autre action ?

Merci beaucoup

[bimiman]

Bonjour,

Il faut le faire durant la création : l'action MODIF est pas mal pour ça (pensez à CREATION aussi).
Si vos champs sont dans SINVOICED, le mieux est sans doute d'utiliser des actions sur champ comme ça pas de question à se poser.

[Proscarion]

Bonjour N2XF3,

Je ne comprends pas tout a fait le besoin, mais voici quelques éléments.

Dans INIMOD, le transclasse a été fait ([F] = [M]), c'est à dire que si le champ spé ajouté sur l'écran a le même code que le champ spé sur la table, la modification faite sur l'écran a déjà été récupérée.
Donc si votre champ est calculé avant, l'enregistrement du champ spé se fera automatiquement, cela ne veux pas dire qu'il n'est pas possible de modifier à ce niveau [F], par contre il est inutile de modifier [M] (transclasse déjà fait).


Une approche "classique" pour moi serai de faire en sorte que votre champ spé s'alimente dans l'écran bien avant l'enregistrement, par exemple, si la valeur de votre champ spé dépend du prix brut et de la quantité, vous pouvez vous placer dans l'écran SIH4 et placer des actions Après modification sur les champs GROPRI et QTY (génèrera deux subprogs AM_GROPRI et AM_QTY dans votre SPESIH, dans lesquels vous pourrez faire votre calcul).
Pour derrière, laisser le transclasse faire son travail pour que la valeur du champ soit enregistrée

[Proscarion]

Dans tous les cas, quelques explications sur les différentes étiquettes de modification, pour que ce soit plus clair.

- AVANT_MOD : A ce niveau, vous venez de faire la première modification sur l'écran (ex : modifier la référence de la facture), cela correspond grossomodo au moment où le bouton enregistré devient cliquable => Aucun intérêt pour vous, votre champ spé ne sera pas le premier modifié de toute façon ;
- VERIF_MOD : Se déclenche au moment où vous cliquez sur enregistrer, est destiné à faire des contrôles sur les champs (le transclasse [F] = [M] n'est pas encore fait) => Pas propre de faire autre chose que du contrôle ici ;
- AVANT_MODFIC : Juste après VERIF_MOD si les contrôles sont ok. La transaction de modification est faite, le transclasse [F] = [M] n'est pas encore fait => N'est pas fait pour venir toucher aux écrans, plutôt pour des majs de tables annexes ou des choses plus techniques (verrous, déclaration de variables globales, ect.) ;
- INI_MOD : Après AVANT_MODFIC, ici le transclasse [F] = [M] est fait => donc il ne sert plus à rien de modifier l'écran ;
- MODIF : Après INI_MOD, ici les changements ont été fait, mais on n'a pas quitté la transaction de modification. Donc toute modif de [F] demandera un Rewrite pour être appliquée => Pas d'intérêt pour vous, plus pour faire des mises à jour sur des tables annexes
- APRES_MOD : La transaction est terminée (les modifications sont reportées dans la base de donnée) => Pas d'intérêt pour vous, peut être utilisé pour faire des mises à jour sur des tables annexes, déclencher des comportements après enregistrement, ect.
- FIN_MOD : C'est la toute dernière étiquette => Jamais trouvé d'utilité à celle ci
- AB_MODIF : S'il y a eu une erreur lors de l'enregistrement (MODIF) et qu'on revient en arrière => Pas d'intérêt pour vous

Voila tout pour les étiquette liés à la modification (dans le sens enregistrement), attention, vous trouverez les mêmes pour la création d'une facture, où vous voudrez certainement également calculer votre champ spé (VERIF_CRE, INICRE, CREATION, APRES_CRE, AB_CREATION, etc..).

Une possibilité pourrait être de passer par une étiquette du modèle objet dont le nom est beaucoup trop proche de APRES_MOD à mon goût (risque de confusion) : APRES_MODIF : Elle se déclenche sur toute modification de champ de l'objet. Lourdingue au possible (ca se déclenche vraiment sur tous les champs), donc il faut contrôler avec COUZON quel champ a déclenché APRES_MODIF. Bref, ne remplace pas une bonne action Après modif sur le champ qui vous intéresse dans l'écran. Est cependant utile dans certains contextes (rafraichissement de browser de picking par exemple)

[N2XF3]

Merci Proscarion pour toutes ces explications ! Je comprends mieux (et je vois également que c'est un peu le bazar dans certain de nos traitements...)

Bref, ne remplace pas une bonne action Après modif sur le champ qui vous intéresse dans l'écran. Est cependant utile dans certains contextes (rafraichissement de browser de picking par exemple)

J'ai effectivement déjà expérimenté avec les actions sur champ pour un cas similaire. Je passais via une action AVANT_ZONE. Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Subprog AV_ZCONTACT(VALEUR)
Variable Char    VALEUR()
	ZSERVICE(nolign-1) = "Test service"
End

Mon champ ZSERVICE prend bien la valeur "Test service" mais il est nécessaire de cliquer sur le champ pour que l'écran s'actualise et affiche la valeur.

Je pensais passer par un Affzo ZSERVICE(nolign-1) comme utilisé dans d'autres traitements mais visiblement X3 plante quand Affzo est utilisé dans une action sur champ.

Existe t'il une alternative à Affzo ?

Merci

[Proscarion]

Bonjour N2XF3,

Quelques remarques :
- J'estime (personnellement, c'est pas universel) qu'il est une assez mauvaise pratique de ne pas spécifier l'écran sur laquelle notre champ est, s'il n'y en a pas un besoin clair (ce qui veux dire qu'on s'appuie sur les File et Mask par défaut pour que le nom du champ soit reconnu). C'est du pinaillage mais ca m'a déjà évité des soucis. A l'inverse, il peux être intéressant de garder un appel sans spécifier l'écran pour des traitements étants appelés par plusieurs objets (devis, commande, par exemple) ;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Subprog AV_ZCONTACT(VALEUR)
	Variable Char    VALEUR()
	[M:SIH4]ZSERVICE(nolign-1) = "Test service"
End

- Essayez de modifier la variable VALEUR dans les actions champs, plutôt que directement le champ. Cela devrait s'afficher correctement. C'est aussi vrai sur d'autres actions sur champ, comme par exemple Après modif, où affecter la variable VALEUR modifiera bien le champ correctement (Il peux par contre y avoir un intérêt à affecter directement le champ, notamment lorsqu'on appelle des bouts de traitement utilisant le champ plutôt que VALEUR).

Est-ce qu'il existe une alternative à Affzo ? En tant qu'instruction, pas vraiment. Il y a bien Actzo qui est proche, mais il s'agit plutôt d'une instruction pour dégriser un champ.
Quelle est l'erreur que X3 vous donne quand vous utilisez Affzo ? Théoriquement cela devrait fonctionner.

Par contre, sur les actions champs avant zone, il est possible de contrôler l'affichage avec la variable mkstat (extrait de la doc ci-dessous)


Donc ce que je vous propose :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Subprog AV_ZCONTACT(VALEUR)
	Variable Char    VALEUR()
	[L]VALEUR = "Test service"
End

Pour moi, pas de raison que ca ne fonctionne pas (mkstat devrait être à 0 par défaut, mais vous pouvez le positionner si vous n'êtes pas sûr).

[N2XF3]

Bonjour Proscarion,

Effectivement en modifiant directement la variable VALEUR ça règle le problème !
pour répondre à votre question, voici l'erreur lorsque j'ajoute Affzo dans une action sur champ




En tout cas merci beaucoup pour votre aide et vos conseils
Je vais me renseigner sur d'éventuelles formations s'il en existe afin de combler mes lacunes en développement X3 et d'obtenir des bases saines.