Discussion :

[xavier.ninane]

Bonjour,

Ma question pourra paraître basique, mais je pédale : j'ai déjà cherché sur le forum et sur l'aide Windev.

Si vous avez des pistes... (ce doit être une erreur de syntaxe ou une impossibilité de l'EDI)

1/ Grâce à un arbre je choisis une société ;
2/ Pour cette société je décide de faire certaines opérations (en l’occurrence des paiements) grâce à une fenêtre interne ouverte dans un onglet dynamique ;
3/ Pour une autre société, je souhaite également effectuer des paiements. Je sélectionne cette société dans l'arbre => comportement attendu : changement des paramètres de la société dans la fenêtre interne du même onglet.

Cela se résume à passer des paramètres à une fenêtre interne d'un onglet précis, et à rafraîchir la fenêtre interne de cet onglet précis sur base des paramètres récupérés par l'arbre.
(Sans que nécessairement l'onglet en question soit l'onglet affiché)

Récupérer les paramètres de l'arbre ne pose aucun soucis, par contre, pour "piloter" la FI d'un onglet déterminé, ça pédale lourd !

Le but, bien entendu, étant de ne mettre à jour que certains onglets (sinon, ça ne serait pas fun ) - je passerai par un tableau pour lister les onglets à mettre à jour.

Merci de votre sagacité.

Exemple de code testé (entre autres)

Code :

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

ExécuteTraitement(FEN_Initiale.ONG_Principal[lsaOngletEnCours],trtInit,"Test")

Ce code utilise une variable qui récupère l'alias de l'onglet en cours (pour tester) et passe en paramètres une chaîne qui est tracée dans l'init de la fenêtre interne.
Sur ce code : pas d'erreur, mais pas de traces à l'init...
Je pense que ce code est erroné car il exécute un traitement à l'initialisation de l'onglet (et pas de la fenêtre interne) => comment accéder au traitement de la FI de cet onglet précis ?
Est-ce que je dois prévoir un code init (modif) dans les onglets ; voire créer un champ interne ?

Dernière précision : je ne sais pas, à priori, quels sont les onglets ouverts, et donc les FI qu'ils contiennent.
C'est pour cette raison que je veux un code "générique" qui me permettent un traitement onglet par onglet, en fonction du tableau que j'aurai rempli...

Merci d'avance (et dispo pour apporter tous les éclaircissements sur le dessein escompté)

X.

[dsr57]

Bonjour

Je créerai une procédure init dans la denetre interne. Et je l appelerai depuis le code de l arbre.

Bon dev

[xavier.ninane]

Merci pour la piste.

J'ai envisagé cette solution.

Mais je n'arrive pas à faire référence précisément à une procédure de la FI d'un onglet déterminé : c'est là que je pédale dans la syntaxe...

[Ry_Yo]

Bonjour,

Pour moi, il vous suffit de spécifier le nom de la fenêtre interne tout simplement :

Code :

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

ExécuteTraitement(FEN_Initiale.ONG_Principal[lsaOngletEnCours].NomFenetreInterne,trtInit,"Test")

Cordialement.

[dsr57]

Bonjour

As-tu essayé le code suivant :

Code :

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

FEN_Initiale.ONG_Principal[lsaOngletEnCours].NomChampFenInterne.NomProcFenInterne()

[Ry_Yo]

Le souci qu'il rencontre, c'est que sur un onglet dynamique, il n'y a pas de "champ fenêtre interne", on map, bind, lie directement l'onglet dynamique à une fenêtre interne.

C'est pour cela qu'il ne savait pas comment interroger la fenêtre interne. Pour une appli perso de gestion de connexion rdp. je me sers du même principe, à savoir une fenêtre interne qui contient un champ activeX pour les session rdp. Et cette fenêtre interne est appelé depuis les "onglets dynamiques" introduit avec la V20. Et j'arrive à piloter la fenêtre interne en lui passant le nom de la fenêtre. (comme expliqué plus haut).

[dsr57]

Bien vu Ry_Yo

[xavier.ninane]

De fait, le souci c'est que ces onglets sont... dynamiques. Impossible de connaitre à l'avance quelle FI se trouvera dans quel onglet.

La solution de Ry_Yo ne fonctionne malheureusement pas.

Dans ce code, FI_Initiale est la fenêtre interne en question.

Code :

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

ExécuteTraitement(FEN_Initiale.ONG_Initial[lsaOngletEnCours].FI_Initiale,trtInit,"Test")

Le message d'erreur (syntaxique) est : Erreur :L'élément 'FI_Initiale' n'existe pas dans l'élément 'ONG_Initial'.
Logique : FI_Initiale n'est pas "créé"

Est-ce que je devrais passer par une indirection ?

[jeanlouispy]

Bonjour,

La syntaxe ci-dessous fonctionne pour moi.

ExécuteTraitement(xAliasVolet+".NomDeLaProc",trtProcédure,param1,param2,paramN)

@++

[darkWD]

bon je ne connais pas les onglet dynamique mais je te conseille d'utiliser les indirections. c'est ce qu'on utilise pour les champs qui ne sont pas censé exister.
et puis pour le paramètre, je pense pas qu'on puisse le passer pour un champ (selon la syntaxe de la doc).
pour ça on peut utiliser une variable globale. mais le plus important pour le moment et que tu puisse réinitialiser la FI (avec un trace bidon).

[xavier.ninane]

Bonjour,

La syntaxe ci-dessous fonctionne pour moi.

ExécuteTraitement(xAliasVolet+".NomDeLaProc",trtProcédure,param1,param2,paramN)

@++

J'avais quelque peu laissé de côté cette partie du projet, qui n'était que de confort.

Et voilà que j'ai le temps de tester cette solution, que j'avais envisagée, mais pas aussi simplement.

Ce regard neuf m'a donc permis de résoudre ce problème !

Petite précision pour ceux qui souhaiteraient s'inspirer de cette discussion : j'ai placé le XAliasVolet du code précité dans une variable globale lors de l'ouverture de ce volet précis de telle sorte qu'à chaque sélection dans l'arbre, le code du clic sur sélection d'un élément pointe sur ce volet précis.

Grand merci à tous ceux qui ont pris le temps d'analyser le problème et tenté de le résoudre.

[Nico_tournai]

Bonjour

Dans le cadre d'un projet "important", on utilise le système d'onglet dynamique avec fenêtre interne.
On a différentes fenêtres qui s'affichent dans des nouveaux onglets, un double clic sur un enregistrement d'un client ouvre un nouvel onglet sur la fiche client par exemple.
C'est une interface comme les navigateurs web et ca plait assez pour le moment dans l'équipe.
On s'est rendu compte de quelques limitations, notamment les groupes qui ne fonctionnent pas dans les fenêtres internes, et l'instruction fichierversecran qui s exécute pour tous les onglets.
Mettre le contexte HFSQL indépendant n'y change rien. Mais on le coche quand même.On a fait une procédure qui pallie à ce problème.

Je voulais avoir votre retour sur l'utilisation en production, si ca fonctionne bien, si le fait d'avoir plein d'onglets n'est pas trop lourd (peut être limiter à n onglets..).

Nous sommes passés à la version 21 cette semaine, je me rends compte depuis qu'un onglet s'ouvre désormais après l'onglet en cours, et non en dernier comme à la version 20.
Je ne trouve pas d'infos à ce sujet sur les nouveautés, ca aurait pû être une option dans le champ onglet (ouverture à la fin, ou après celui en cours).
Je trouve ca dommage de ne pas en être averti (sauf ignorance de ma part) , même si c'est pas grave au fond..

[xavier.ninane]

Bizarre comme comportement : j'utilise justement les onglets dans le cas classique de consultation de fiche client et j'utilise les deux fonctions EcranVersFicher et FichierVersEcran.

Je viens de faire un rapide test, sur deux fiches qui pointent sur deux enregistrement du même fichier et sur deux fiches qui pointent sur deux enregistrements de deux fichiers distincts (gestion multi-société) : pas de soucis. Les modifications appliquées dans un onglet ne sont pas impactées par l'EcranVesrFichier du 2e onglet, et chaque fiche qui s'ouvre renseigne parfaitement les données liées par le FichierVersEcran. Je travaille avec une fenêtre interne mappée à l'onglet. Le contexte HFSQL est défini comme indépendant pour cette fenêtre interne.

Par contre, j'ai découvert un effet de bord : la manipulation graphique (le grisé d'un bouton, par exemple) se répercute sur tous les onglets mappés sur le fenêtre interne. Pour l'instant, je ne m'en suis pas soucié. Peut-être qu'une indirection pointant sur le bouton d'un onglet spécifique permettrait de solutionner cet effet...

[Nico_tournai]

Dans le cas de l'ecranversfichier, oui pas de soucis.

Par contre fichierversecran c est autre chose, et c est indiqué dans la doc il me semble cette limitation.
Exemple: j'ouvre une fiche client vers un nouvel onglet, je suis en modif et je commence à modifier un champ qui est lui même lié à une zone fichier de l'analyse.
J'ouvre un nouvel onglet sur une autre fiche client, le fichierversecran se déclenche pour ce nouvel onglet (qui contient une fenêtre interne), en allant sur l'onglet en modification, mon champ modifié (mais non validé pour la modification) a repris son information initiale...
C est un soucis que d'autres ont rencontré et ont suggéré aussi de faire leur propre fichierversecran (en parcourant tous les champs de la fenêtre et une indirection du champ avec liaisonfichier...)

Pour l'effet de bord graphique non j'ai pas de soucis, je rends grisé un bouton en fonction du mode de saisie, et ca fonctionne bien, il faut voir si l'instruction est lancée depuis la fenêtre mère ou propre à l'onglet.
Chez moi, j'ai une procédure locale à la fenêtre interne qui en fonction du mode de saisie, rends actif ou inactif certains champs.

[xavier.ninane]

Je viens de tester votre scénario (si je l'ai bien compris) : ouverture d'un client X, modification d'une des données (sans validation) de ce client, ouverture d'un client Y (l'onglet s'ouvre sur cette fiche), je me balade entre les onglets et les informations que j'avais commencé à modifier sur le client X sont en l'état où je les avais laissées.

Je précise : mon onglet initial comporte une fenêtre interne avec la liste des clients (table). L'ouverture des fiches détaillées s'appelle par un double clic dans une des lignes de table. Donc, tout tourne en "interne" du champ onglet.

Concernant l'effet de bord graphique, je relis mon code, et je m'aperçois que les boutons en question sont dans un groupe. Et vu que vous signalez un problème avec les groupes, j'ai testé sur un bouton seul. Effectivement, c'est le fait d'être dans un groupe qui créait l'effet de bord. Merci donc d'avoir incidemment résolu ce petit soucis.

[xavier.ninane]

Je pense que j'ai trouvé ce qui me permettait de maintenir la rémanence des données (non validées) d'un onglet à l'autre, même en ouvrant un onglet en cours de route : par sécurité, je fais un HchangeRep dans l'initialisation de ma fenêtre interne (pour rappel, je travaille en multi-sociétés). Cela me laisse penser que le contexte HyperFile indépendant + ce HchangeRep sont la combinaison qui permettent de créer une "isolation" complète du contexte de la fenêtre interne.
Mais ce n'est qu'une supposition...

[Nico_tournai]

oui c'est ce principe que j'utilise, un double clic d'une table ouvre un nouvel onglet.

Mes données sont issues d'une même table alors que vous non il semblerait, si vous faites un hChangeRep.
Si vous avez l'occasion de tester sur une même table...

Cordialement

[xavier.ninane]

Qu'entendez-vous par "mes données sont issues d'une même table" ? Je ne saisis pas.

Toujours est-il que j'ai rapidement testé en supprimant ce hChangeRep, et là, mon onglet n'affiche plus aucunes données ?!?

Le hLitRecherchePremier sur l'ID client passé en paramètre à la fenêtre interne renvoie faux.
Ma fenêtre interne qui contient la table est, elle en contexte dépendant. Si elle ne l'est pas, la table ne se remplit. Ce qui m'apparaît normal : la table est directement mappée au fichier de données, de telle sorte que quand je change de société, la liste des clients s'actualise via un TableAffiche.

Et, après quelque rapide tests, si je n'utilise pas ce hChangeRep en initialisation de ma fenêtre interne, cette fenêtre interne n'utilise, semble-t-il, aucune source de données, qu'elle soit en contexte dépendant, ou en contexte indépendant.

Je vous avoue ne pas saisir la subtilité.

Peut-être devriez-vous, de votre côté, tester ce hChangeRep pour voir si cela induit le comportement que vous attendez.

[Nico_tournai]

je saisis pas trop l'utilité de hChangeRep, mes données sont issues de HFSQL, une seule DB...
Demain si j'ai le temps , j'essaierai de pondre un code minimal en fichier local HF, voir si j'ai le même probleme,
peut être vous enverrais je le projet pour vous montrer, ce serait plus facile de comprendre certainement.

[xavier.ninane]

Dans mon projet ce hChangeRep est fondamental, car je suis en multi-sociétés et les données sont organisées en arborescence (version C/S) dans une seul BD :

SociétéA
Client.fic
SociétéB
Client.fic
SociétéC
Client.fic
Etc.

Ce que je ne saisis pas, c'est que sans ce hChangeRep, ma fenêtre interne ne pointe aucun fichier, et ça c'est bizarre.