|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| EnumèreChamp : comment interprétez-vous la doc ? |
| Débuté par Pascal BOULESTEIX, 04 mai 2025 07:49 - 2 réponses |
| |
| | | |
|
| |
Membre enregistré
1 166 messages |
|
| Posté le 04 mai 2025 - 07:49 |
Bonjour
J'utilise la fonction EnumèreChamp pour changer la couleur des boutons dans ma page home, boutons répartis dans plusieurs plans.
Dans le première paragraphe de la doc, comment interprétez-vous la deuxième phase du texte explicatif ("Cet élément doit être affiché.").
https://doc.pcsoft.fr/fr-FR/?3025005&productversion=xxA302032
En mode GO, tous les champs de tous les plans de la fenêtre sont énumérés, qu'ils soient "visible" vrai ou faux et qu'ils soient "visibles" au sens "au premier plan" dans le plan courant.
Si je pose la question, c'est qu'il arrive que quand je reviens sur mon application ayant été mise en arrière plan dans le téléphone ou bien que, mon application étant au premier plan mais que mon téléphone sorte de mise en veille, j'ai un plantage sur l'affectation d'un setTextColor (dans le texte) sur un objet undefined.
Attempt to read from field 'eg.a sg.c.Y' on a null object reference in method 'void af.h0.setTextColor(eg.a)'
--
Pascal Boulesteix
Applications Visiolittoral et WNat |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 705 messages |
|
| Posté le 04 mai 2025 - 14:31 |
Salut,
Pour moi, c'est le fait de mettre ton application en arrière plan qui pose problème.
Tu as des fonctions comme EnModeArrièrePlan
Tu devrais verrouillé ton application pendant la mise en arrière plan
Pour éviter qu'elle agisse avec l'ihm
Peut être que la LST n°87 : Android Verrouillage pourra t'aider
Je suis d'ailleurs étonné que le support ne propose pas un autre exemple sur le sujet |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
1 166 messages |
|
| Posté le 05 mai 2025 - 10:20 |
Salut popoy
J'utilise déjà EnModeArrièrePlan.
Pour cela, j'ai surchargé les principes fonctions susceptibles d'interférer avec l'IU (info, ouinon, toastaffiche...)
Si par hasard une de ces fonctions est utilisées en arrière-plan, j'envoie une notification quand c'est possible.
Il est vrai que dans le rapport, le message parle d'un ouvreFille que je n'ai pas surchargé, mais je ne vois pas dans quel cas j'aurais besoin d'ouvrir une autre fenêtre quand l'application revient au premier plan !
Il faut noter que ce bug n'arrive que quand la connexion Internet est instable.
Le processus de détection du changement de statut de connexion est en place depuis des années.
Dans l'init du projet :
gbIsInternet = InternetConnecté()
InternetConnecté(gPROC_INTERNET_REFRESH)
Procedure gPROC_INTERNET_REFRESH(Etat)
sUuid est une chaîne = DonneGUID(guidFormaté)
sMsg est une chaîne =""
SI Etat=RéseauDéconnecte ALORS
gbIsInternet = Faux
gbIsInternet=gPROC_INTERNET_TEST_REPONSE_URL()
IF gbIsInternet=Faux ALORS
gnQuidInternet=3
SINON
gnQuidInternet=99
FIN
SI gbIsInternet=Vrai ALORS
gnQuidInternet = 99
FIN
SINON
gbIsInternet = Vrai
gnQuidInternet=Etat
FIN
SELON gnQuidInternet
CAS RéseauDéconnecte
sMsg="Vous n'êtes pas connecté à Internet"
CAS réseauMobile
sMsg="Connexion Internet par GSM"
CAS réseauWifi
sMsg="Connexion Internet par WIFI"
CAS 99
sMsg="Connexion Internet active"
FIN
SI PAS EnModeArrièrePlan() ALORS
ToastAffiche(sMsg,toastCourt,cvBas,chCentre)
FIN
Trace("myTRACE : CALLBACK gPROC_INTERNET_REFRESH "+sMsg)
Le mode verrouillage évoqué dans lst87 n'est pas adapté dans mon application et je ne vois pas ce que ça changerait au sortir de l'arrière-plan.
--
Pascal Boulesteix
Applications Visiolittoral et WNat |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|