|
| Inicio → WINDEV 2025 → Changement d'enregistrement involontaire à l'initialisation du projet |
| Changement d'enregistrement involontaire à l'initialisation du projet |
| Iniciado por Ferbak, 10,abr. 2020 09:43 - 16 respuestas |
| |
| | | |
|
| |
Miembro registrado
50 mensajes |
|
| Publicado el 10,abril 2020 - 09:43 |
Bonjour à tous,
Je viens de remarquer un comportement étrange à l'initialisation de mon projet.
Dans le code d'initialisation du projet, je lis un enregistrement du fichier User (celui utilisé lors du login).
A la toute fin de mon init projet, je trace toujours bien le bon user, mais à l'ouverture de la première fenêtre, je suis positionné sur un autre user dans le fichier (premier par ordre alphabétique).
En faisant "Pas à pas détaillé", le code qui vient juste après est l'init d'une fenêtre interne de la première fenêtre qui m'affiche déjà le positionnement sur le mauvais User.
Je ne comprends pas d'où ça vient et je ne sais pas ce qu'il peut se passer entre ces deux étapes.
Est-ce que quelqu'un saurait ce qu'il peut se passer ou une manière de tracer ce qui modifie un enregistrement?
Je me demandais aussi si il n'y avait pas moyen de voir tous les champs liés à une rubrique.
Dans l'absolu, je relis le bon User à l'ouverture de la première fenêtre donc rien de dramatique, mais j'aimerais savoir ce qu'il peut se passer malgré tout pour éviter que ça se reproduise.
Merci d'avance si vous avez des pistes.
Belle journée à tous! |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.362 mensajes |
|
| Publicado el 10,abril 2020 - 10:09 |
Bonjour,
Avec ton code ce serait peut être plus simple.
Toutefois, à vue de nez, ce serait peut être une histoire de contexte au niveau de la FI https://doc.pcsoft.fr/?1010029
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
50 mensajes |
|
| Publicado el 10,abril 2020 - 11:28 |
Bonjour et merci pour ton retour rapide!
J'ai pensé à ça également, mais cette case n'est cochée nulle part. Pour vérifier que ça ne venait pas de là, j'ai fait le test en lisant un enregistrement d'un autre fichier en même temps juste avant le changement de User. Le fichier contact ne bouge pas.
Pour simplifier, voici mon code
Toute fin de l'init du projet (pas d'autre code l'échelle du projet)
HLitRecherchePremier(User,ID_User,gnUseractifId)
HLitRecherchePremier(Contact,ID_Contact,15)
et voici le suivi des valeurs à ce moment là
Ensuite, en faisant "Pas à pas détaillé", j'arrive sur la déclaration globals d'une FI et avant même que q'une ligne s'éxécute,
Le user 70 est le premier par ordre alphabétique, il change donc si j'en ajoute un nommé "aaa".
Il y a effectivement des combos etc rempli par ordre alphabétique dans mon projet, mais impossible de déterminer ce qui fait changer la lecture entre ces deux étapes. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
356 mensajes |
|
| Publicado el 10,abril 2020 - 12:13 |
Bonjour,
Met un break conditionnel sur "Uers.ID_User" comme cela si c'est ton code qui est la cause du changement tu verras exactement ou.
Cela dit il est possible que ce soit directement Windev qui décide de faire ce changement du fait du chargement d'un champ, d'une combo, d'une table...
Peut-être aussi un timer ou un autre Thread qui effectue cette modification, mais dans ce cas tu le verra avec le break conditionnel.
Tiens nous au courant.
--
Francis MOREL
http://www.SoftProtect.fr |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.362 mensajes |
|
| Publicado el 10,abril 2020 - 12:34 |
Normalement cette FI doit se trouver dans la première fenêtre de ton projet.
Quel est l'ordre de son conteneur dans l'initialisation ?
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | |
| |
| Publicado el 10,abril 2020 - 12:35 |
Bonjour
A défaut, lors de l'initialisation sauve la ligne en cours dans un objet de type enregistrement (globale) ... et utilise ce record dans tes autres fenêtres
Bien cordialement |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
50 mensajes |
|
| Publicado el 10,abril 2020 - 14:31 |
Francis,
Qu'est ce que tu entends par "break conditionnel"? A ma connaissance on ne sait mettre qu'un point d'arrêt à un endroit du code, chose que j'ai fait juste avant que le problème se produise, et juste après. Mais tu vas peut-être m'apprendre quelque chose 
Sinon je n'ai pas de thread activé, et aucun qui ne lit ce fichier de toute façon, idem pour les timers.
Voroltinquo,
Cette fenêtre se trouve effectivement à deux endroits dans la fenêtre principale. Elle ne contient rien en rapport avec les users, et par acquis de conscience, j'ai mis des points d'arrêt sur le premier champ initialisé (un libellé) et il ne se déclenche pas avant mon souci.
Dans l'ordre, j'ai Init projet - Init des Cfi (switch de user déjà fait ici) - Init fenetre n°1 - Init premier champ des cfi
Gemini,
Tout à fait, c'est ce que j'ai fait. Mais je me dis que ce comportement "illogique" que je ne m'explique pas pourrait se reproduire si je n'en identifie pas la cause.
Merci à vous trois en tout cas! |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
356 mensajes |
|
| Publicado el 10,abril 2020 - 16:35 |
Pour faire simple : dans le volet du débogueur tu cliques sur le point vert devant la variable que tu veux tester, le point devient rouge, comme un breakpoint classique.
A chaque modification de la variable le débogueur stop sur la ligne qui va modifier cette variable.
Pour les autres options je te laisse voir l'aide.
--
Francis MOREL
http://www.SoftProtect.fr |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
50 mensajes |
|
| Publicado el 10,abril 2020 - 17:19 |
C'est une astuce qui va m'être plus qu'utile de manière générale. C'est peut-être connu, mais ce n'était pas mon cas, un grand merci!
Par contre, pas d'avancée dans mon souci, il s'arrête à la fin de l'init projet quand je lis le user 23, puis il s'arrête à nouveau quand je relis le user 23 à l'ouverture de ma première fenêtre (qui entre temps à changé donc ...). Il n'y a donc rien dans le code qui fait changer ça. Je penche sur un champ IHM, mais savoir où et pourquoi est une autre affaire... |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
170 mensajes |
|
| Publicado el 10,abril 2020 - 18:48 |
Bonjour,
Comment est chargée ta fenêtre interne ?
=> via ChangeFenetreSource() ?
=> via les sept onglets ?
Cette fenêtre interne contient-t-elle une autre fenêtre interne ? Comment est-elle chargée ?
est-ce que cette fenêtre interne manipule ton user ?
--
--
Jean-Jacques |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
356 mensajes |
|
| Publicado el 10,abril 2020 - 19:39 |
Re
Essaye de chercher "User.ID_User" dans le volet "Rechercher - Remplacer" tu pourras ainsi voir tous les endroits ou cette rubrique est liée à un champ.
A+
--
Francis MOREL
http://www.SoftProtect.fr |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
50 mensajes |
|
| Publicado el 17,abril 2020 - 12:59 |
Bonjour bonjour,
Les fenêtres internes sont "simplement" des champs fenêtre internes liées via les 7 onglets, oui.
Et non, pas de sous-fenêtre interne dans les fenêtre interne.
Oui, j'ai fais toutes les recherches possibles sur les Id_User, rien à signaler.
Je ne comprends pas ce qui peut se passer entre la fin de l'init projet et l'init de la première FI et qui ne soit pas pris en compte par le débogueur en pas à pas.
J'ai réglé ça en relisant le bon enregistrement dès l'ouverture de la fenêtre 1, mais ce comportement m'intrigue.
Merci d'essayer d'y voir plus clair en tout cas.
Belle aprem |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.362 mensajes |
|
| Publicado el 17,abril 2020 - 13:19 |
Tu n'as toujours pas répondu à la question concernant l'ordre du conteneur (la CFI) dans l'initialisation. Tu as parlé de l'ordre des procédure mais pas de l'ordre des champ.
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.362 mensajes |
|
| Publicado el 17,abril 2020 - 13:49 |
Par ailleurs à quoi sert ta FI ? Elle attend peut être un paramètre, ou alors, (cela arrive parfois) elle a conservé dans son code d'initialisation, ou dans le code de ses champ des paramètre de test.
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
170 mensajes |
|
| Publicado el 17,abril 2020 - 14:27 |
Bonjour,
Voici l'ordre d'initialisation des évènements de la fenêtre (FEN_Principale) et fenêtre interne (FI_Principale) dans le cas d'un chargement de la fenêtre interne, du moins en version 24 :
- via les sept onglets.
FI_Principale : Déclarations globales
FEN_Principale : Déclarations globales
FI_Principale : MAJ IHM
FI_Principale : FIN init
FEN_Principale : MAJ IHM
FEN_Principale : FIN init
- Via changeFenetreSource() dans les déclarations globales de FEN_Principale
FEN_Principale : Déclarations globales
FI_Principale : Déclarations globales
FI_Principale : FIN init
FI_Principale : MAJ IHM
FI_Principale : MAJ IHM
FEN_Principale : MAJ IHM
FEN_Principale : FIN init
- Via changeFenetreSource() dans la fin d'init de FEN_Principale
FEN_Principale : Déclarations globales
FEN_Principale : MAJ IHM
FEN_Principale : FIN init
FI_Principale : Déclarations globales
FI_Principale : FIN init
FI_Principale : MAJ IHM
- Via changeFenetreSource() dans la MAJ IHM de FEN_Principale
FEN_Principale : Déclarations globales
FEN_Principale : MAJ IHM
FI_Principale : Déclarations globales
FI_Principale : FIN init
FI_Principale : MAJ IHM
FEN_Principale : FIN init
Ceci pourrait avoir une influence sur les initialisations de tes <> champs.
hth,
--
--
Jean-Jacques |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
50 mensajes |
|
| Publicado el 27,abril 2020 - 10:16 |
Bonjour,
Je n'avais effectivement pas été très précis, mais j'avais déjà testé l’initialisation des premiers champs de ma première fenêtre interne.
Cette fenêtre se trouve effectivement à deux endroits dans la fenêtre principale. Elle ne contient rien en rapport avec les users, et par acquis de conscience, j'ai mis des points d'arrêt sur le premier champ initialisé (un libellé) et il ne se déclenche pas avant mon souci.
Dans l'ordre, j'ai Init projet - Init des Cfi (switch de user déjà fait ici) - Init fenetre n°1 - Init premier champ des cfi
C'est une Fi qui gère les filtres de recherche de projet. Aucun lien avec les users donc. Voici les premiers champs appelés, et un point d'arrêt dans l'init du premier libellé donnait déjà le problème.
Et rien comme code dans la FI au niveau init, ni dans le CFI. Pas de paramètre non plus donc.
Par contre, en retestant pour vous répondre, je vois que le problème ne se produit plus!
Depuis, j'ai retravaillé la création des listes créé dans des globales à l'init du projet, et dont certaines concernaient les users par ordre alphabétique.
Le fait que le user qui était lu ai été le premier non archivé par ordre alphabétique me laisse fortement penser qu'il y avait un lien avec ça.
Ça ne reste pas très logique, mais ça à résolu mon souci sans même devoir relire le bon user à l'ouverture de la fenêtre n°1.
Si ça devait se reproduire, j'essayerai de creuser plus sur la création des listes pour donner une solution plus concrète à mon souci.
Merci en tout cas pour toute votre aide!
Bonne semaine |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
170 mensajes |
|
| Publicado el 27,abril 2020 - 14:03 |
--
Hth,
Padbrain |
| |
| |
| | | |
|
| | | | |
| | |
|