PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV Mobile 2024 → Référence sur objet dans fenêtre interne
Référence sur objet dans fenêtre interne
Débuté par Nicolas CHARPENTIER, 21 juin 2018 12:37 - 4 réponses
Membre enregistré
24 messages
Popularité : +1 (1 vote)
Posté le 21 juin 2018 - 12:37
Bonjour,

Désolé par avance pour ce post un peu long (et mon premier sur ce forum :-) )
J'ai un problème de gestion des objets sur Windev Mobile, et aucune explication logique.

Sur WM23, j'ai une fenêtre fen_Test qui contient un BTN_1 et une ZR_1, peuplée avec la nouvelle fonctionnalité ZoneRépétéeAjouteFI.
Dans la FI, j'ai une seconde ZR, qui contient un bouton par répétition.







En fin d'init, ma fen_Test alloue statiquement un objet f_oCtl de type cCtl (j'ai essayé en dynamique, ce n'est pas le problème), et possède une procédure refresh, dans laquelle elle va interroger une propriété de oObjet (une variable Heure).
Le principe est simplement de gérer un contrôleur, qui va demander à la vue de se rafraîchir quand il aura modifié son état interne.

// Déclarations globales de fen_Test
Procedure MaFenêtre()
f_oCtl est un cCtl // dynamique ou pas : même topo


// Fin d'initialisation de fen_Test
f_oCtl.setClosure()


// Procédure ajoutée : refreshUI
Procedure refreshUI()
SAI_Now = HeureSys() // Affiche l'heure 'réelle'
SAI_NowCtl = f_oCtl.p_hNow // Affiche l'heure connue de l'objet
ZoneRépétéeSupprimeTout(ZR_1)
ZoneRépétéeAjouteFI(ZR_1,FI_Test,f_oCtl)


// Clic sur BTN_1 : on appelle la méthode utile de l'objet
f_oCtl.action()


Voici le code de mon objet cCtl
// Déclaration de la classe
PRIVÉ
hNow est une Heure
closure_ui est une Procedure=Null


// Constructeur
hNow = HeureSys()


// Propriété en lecture seule, donne l'heure mémorisée par l'objet
Procedure PUBLIQUE p_hNow() : Heure
RENVOYER hNow


// La récupération de la closure de fen_Test
Procedure setClosure()
closure_ui = fen_Test.refreshUI
SI closure_ui <> Null ALORS closure_ui()


// Action utile de l'objet : petite tempo, mise à jour de son heure, et refresh IHM
Procedure action()
Multitâche(150)
hNow = HeureSys()
SI closure_ui <> Null ALORS closure_ui()


=> Jusque là tout va bien : quand je clique sur le BTN_1, les deux champs de saisie de ma fenêtre SAI_Now et SAI_NowCtl ont la même valeur.

Maintenant, le code de ma fenêtre interne :
Procedure MaFenêtre(poCtl est un cCtl dynamique)
f_oCtl est un cCtl // dynamique ne change rien


// Fin d'initialisation de FI_Test
f_oCtl <- poCtl // Donc une REFERENCE sur l'objet !?


// Clic sur BTN_2 : le bouton de la ZR
f_oCtl.action()


=> Et là... c'est le drame. En mode simulateur (ou sur Windev), tout se passe bien : le BTN_2 de la fenêtre interne appelle la méthode "action" de l'objet, qui met à jour son heure, puis demande à la fen_Test de se rafraîchir. Celle-ci interroge alors la propriété p_hNow de l'objet, et les deux SAI affichent la même heure.

Par contre, sur un téléphone (un Samsung), la propriété p_hNow de l'objet renvoie l'heure qu'il avait AU MOMENT DE SA CREATION ! Comme si la FI avait fait une COPIE (et non une prise de référence de l'objet) : les méthodes de l'objet sont appelées correctement (il fait sa tempo, puis il lance le refresh de la fenêtre principale), par contre ses données ne sont pas à jour...
Sur ce constat, j'ai essayé plusieurs manips annexes (notamment en jouant sur les dynamique/pas-dynamique dans la déclaration des variables et les passages de paramètres) : soit ça provoque des erreurs de compil (donc tout va bien), soit ça compile sans problème, ça marche toujours sur le simulateur, et toujours pas sur un vrai téléphone.

J'ai ajouté une trace dans le constructeur de l'objet, pour m'assurer qui celui-ci n'était pas instancié une SECONDE FOIS lors de l'exécution, car c'est la seule explication logique que je trouve. Résultat : un seul passage dans toute l'exécution, donc l'objet n'existe bien, 'officiellement', qu'une seule fois. Or il y a manifestement deux objets en mémoire à l'exécution...

Si vous avez des pistes, je suis preneur, car ce modèle va être appliqué sur plusieurs fenêtres, et devait me garantir une compatibilité WD-WM... c'est pas gagné !

--
Nicolas
Posté le 23 juin 2018 - 09:07
je n'utilise jamais la poo mais je peut te dire que sur Android le dialogue entre fenêtres nécessite l'utilisation du nom complet du champ et l'utilisation des indirection. Ce qui n'est pas nécessaires en WD.
Posté le 24 juin 2018 - 17:18
sur Android il faut utilisé le nom complet du champ et utilisé les indirections
Membre enregistré
24 messages
Popularité : +1 (1 vote)
Posté le 24 juin 2018 - 22:31
Bonjour,

Merci pour ta réponse, malheureusement ça ne m'aide pas beaucoup (ou alors j'ai raté quelque chose) : avec ZoneRepeteeAjouteFI, il n'y a justement pas de champ FI.
Cela restera donc un mystère pour moi.
J'ai contourné le problème ainsi : la FI n'appelle plus directement le contrôleur (elle ne le connaît même plus, donc plus passage par référence). Quand le bouton BTN_2 est cliqué, la FI appelle une proc. de la fenêtre maître, et celle-ci appelle le contrôleur.
(Je rappelle pour ceux que ça intéresse que le code ci-dessus pose problème sur un VRAI téléphone, alors qu'il fonctionne 'normalement' sur le simulateur).

--
Nicolas
Membre enregistré
135 messages
Popularité : +8 (8 votes)
Posté le 02 novembre 2018 - 10:55
Bonjour Nicolas,

Je galère également avec ZoneRepeteeAjouteFI.

Je passe en paramètre également un objet à une fenêtre interne de zone répétée.. En mode 'Go' tout est toujours ok, les fenêtres internes manipulent bien l'objet correspondant. Sur Android ca 'bloque' totalement l'application (mais pas tout le temps !!). Pas de message, rien, juste un blocage et l'application qui stop au bout d'un moment.

Pour tester, j'ai mis des infos avant et après le zonerepeteeajoutefi et des infos dans le code de la fenêtre interne en question.
Info_Dbg("Affiche_Ticket 3A")
LOC_Indice = ZoneRépétéeAjouteFI(CZREP_Ticket,FENINT_ZR_Ticket_Suite,LOC_Lg) // LOC_Lg est un objet
Info_Dbg("Affiche_Ticket 3B")


Résultat, j'ai l'info avant le zonerepeteeajouteFI puis plus rien ! L'info qui est en première ligne du code d'init. de la fenêtre interne FENINT_ZR_Ticket_Suite ne s'affiche pas.. Le plantage arrive apparemment entre l'appel ZoneRepeteeAjouteFI et l'ouverture effective de cette fenêtre.

Pas simple de trouver le problème dans ces conditions et ce genre de problème me fait perdre un temps fou..

Rien donc pour te faire avancer :-) j'ajoute juste un retour d'exp. qui me semble aller dans le même sens que ton problème. Si quelqu'un à une liste des bonnes pratiques pour utiliser correctement ZoneRepeteeAjouteFI avec passage d'un objet en paramètre je suis preneur..

--
Dominique DAUSSY
http://www.serviceinfo76.com
Développeur de votre solution Windev, WebDev et Windev Mobile