PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV Mobile 2024 → Changement fde comportement depuis passage à windev mobile 24
Changement fde comportement depuis passage à windev mobile 24
Débuté par Christophe NICOLAS, 24 fév. 2019 16:19 - 3 réponses
Membre enregistré
3 messages
Posté le 24 février 2019 - 16:19
Bonjour à tous,

J'ai une appli windev mobile initialement développée en 22, puis en 23 et qui ne rencontrait pas de problème particuliers.

Depuis le passage à la 24, j'ai un étrange effet de bord que je ne m'explique pas.

J'ai une base HFSQL Client/serveur.

J'ai un fichier Cras d'une soixantaine d'enregistrement avec une clé ID dont la valeur va de 1 jusqu'à 60.

J'ai un écran qui me présente une liste de Cras avec la possibilité d'en sélectionner un pour ouvrir le détail.
Dans cette liste j'ai un Cras dont l'ID est 52 d'affiché. J'arrive à le sélectionner et ouvrir la fenêtre de détail dont le code d'initialisation est ci-après

Procedure MaFenêtre(gnCraID est un entier sur 8 octets)

gnDispEntete est un entier = 1
gnDispBouton est un entier = 2
gnDispFrais est un entier = 3
gnDispJours est un entier = 4

INT_Interrupteur1..Valeur = 0
INT_Interrupteur2..Valeur = 0
DISP_SansNom1[gnDispFrais]..Visible = Faux
DISP_SansNom1[gnDispJours]..Visible = Faux

SI gbTR ALORS
HExécuteRequête(REQ_CalculCraNbTR,hRequêteDéfaut,gnCraID)
HLitPremier(REQ_CalculCraNbTR)
SAI_JoursTR..Valeur = REQ_CalculCraNbTR.la_somme_Heures
SINON
SAI_JoursTR..Visible = Faux
FIN

HExécuteRequête(REQ_CalculCraNbRTT,hRequêteDéfaut,gnCraID)
HLitPremier(REQ_CalculCraNbRTT)
SAI_JoursRTT..Valeur = REQ_CalculCraNbRTT.la_somme_Heures

HExécuteRequête(REQ_CalculCraNbCP,hRequêteDéfaut,gnCraID)
HLitPremier(REQ_CalculCraNbCP)
SAI_JoursCP..Valeur = REQ_CalculCraNbCP.la_somme_Heures

HExécuteRequête(REQ_CalculCraNbTrav,hRequêteDéfaut,gnCraID)
HLitPremier(REQ_CalculCraNbTrav)
SAI_JoursTravailles..Valeur = REQ_CalculCraNbTrav.la_somme_Heures

HLitRecherchePremier(Cras, ID, gnCraID)
SI HTrouve(Cras) = Vrai ALORS

Info("Paramètre = " + gnCraID + " Fichier = " + Cras.ID)

FIN

FichierVersEcran()


La fonction HlitRecherchePremier(Cras, ID, gnCRaID) devrait bien me positionner sur l'enregistrement avec ID = gnCraID ( soit 52).
La fonction Htrouve () renvoi vrai.
Je m'attends donc naturellement à avoir les valeurs de mon enregistrement avec ID = 52 dans les champs de ma fenêtre lors du FichierVersEcran().

Or ce n'est pas le cas puisque les champs de ma fenêtre m'affichent les valeurs de l'enregistrement Cras avec un ID = 28 ! (La valeur change de manière aléatoire à chaque test)

La fonction Info que j'ai ajouté dans le Si…Fin me retourne : Paramètre = 52 Fichier = 28

Je n'y comprends plus rien !… Le code de cet écran n'a pas été modifié entre la 23 et la 24... Mais le comportement a changé !
Message modifié, 24 février 2019 - 16:34
Posté le 26 février 2019 - 04:35
Salut @christophe
essaie avec hlit seul.
Membre enregistré
16 messages
Posté le 05 mars 2019 - 14:27
Bonjour,
je constate exactement le même problème de mon côté sur une application Mobile qui tourne depuis V21 sans le moindre problème !
-J'ai une table d'interventions avec un GUID
-Zone répété qui liste les Interventions = GUID et infos Client, adresse, Site => OK
-Un clic sur cette ligne de ma ZR m'ouvre la fiche d'intervention en mode "MODIF" en lui passant en paramètre le GUID de l'inter
-c'est la variable "InterGuid" de la fiche Inter qui stocke donc le GUID
-La fiche d'inter fait alors un HLITRECHERCHE(MobInters,GUI_Inter,InterGuid)

=> de manière complètement aléatoire, une fois sur 5 c'est OK bon enregistrement et les 4 autres fois ce ne sont pas les infos de la bonne fiche ???

J'ai donc ajouté des Infos(InterGuid,MobInter.GUID_Inter) à différent étapes du code d'initialisation de la fenêtre Fiche_Inter

Le résultat => 4x sur 5 le MobInter.GUID_Inter est changé juste après la fonction FichierVersEcran() ou FichierVersEcran(Fiche_Inter,MobInters)

Ceci ne se produit jamais sur Emulateur Android ou émulateur PC-Soft, UNIQUEMENT sur périphérique Android !?

Si je remplace la fonction FichierVersEcran() par des affectations manuelle = Ok RAS (sauf que c'est très long à réaliser et surtout compliqué à maintenir)

Merci de nous tenir informé rapidement...
Jacky BARRET
Membre enregistré
16 messages
Posté le 05 mars 2019 - 16:14
Bonjour, complément du 05/03/2019 suite appel Support PC-SOFT, problème connu et corrigé avec nouvelle version publiée ce jour !

=> Je m'empresse de télécharger, installer et recompiler mon application
Résultat NOK problème toujours présent mais avec une nuance :
Avant mise à jour, le code ci-dessous renvoyée systématiquement 2 GUID différents avant la le "Fichierversécran" et après
(Je précise qu'il n'existe aucun Thread ou TâcheParallèle)

HLitRecherche(MobInters,GUID_Inter,InterGUID,hIdentique)
SI HTrouve(MobInters) ALORS
Info("GUID fiche avant fichierversEcran "+MobInters.GUID_Inter)
FichierVersEcran()
Info("GUID fiche après fichierversEcran "+MobInters.GUID_Inter)
FIN

Suite à la mise à jour, le code ci-dessus me retourne effectivement un GUID identique avant et après la fonction "Fichierversécran" et les champs sont effectivement bien affectés
=> Donc ont ce dis Super problème réglé...
Sauf que quand j'enlève les Info(xxxx) => A nouveau pas les bonne affectation de manière aléatoire !!!

En attendant pour contourner le problème, l'utilisation du code ci-dessous règle le problème mais bon c'est une rustine...

HFiltre(MobInters,GUID_Inter,InterGUID,InterGUID)
HLitPremier(MobInters)
//HLitRecherche(MobInters,GUID_Inter,InterGUID,hIdentique)
SI HTrouve(MobInters) ALORS
// Info("GUID fiche avant fichierversEcran "+MobInters.GUID_Inter)
FichierVersEcran()
// Info("GUID fiche après fichierversEcran "+MobInters.GUID_Inter)
FIN

**Ne pas oublier de désactiver le filtre à la fermeture de la fenêtre...