Gambas France BETA


Pas de compte ? Incription

TrayIcon

Ce sujet est résolu.

1
AuteurMessages
valaquarus#1 Posté le 18/5/2021 à 07:36:20
-- Unus Ex Altera --Bonjour à tous,
comment fermer correctement une application qui utilise le trayicon?
Voici ce que j'obtiens systématiquement en fermant par le menu du trayicon :
1
2
3
4
5
gbx3 [2199]: warning: circular references detected:
gbx3: 1 DBusStatusIconMenu
gbx3: 1 DBusStatusIcon
gbx3: 1 TrayIcon
gbx3 [2199]: warning: 312 allocation(s) non freed.

Avant que de fermer je fais ceci :
1
2
3
4
Tray.Hide()
ME.Hide()
WAIT 0.5
Tray.Delete()

Philippe.
Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5
linuxos#2 Posté le 19/5/2021 à 03:40:12
Un peu de sel, de poivre et la crevette sera... Valaquarus,

De mon coté je mets ceci dans la Procedure Form_Close()

1
2
3
4
5
6
7
8
9
PUBLIC SUB Form_Close()

IF Desktop.HasSystemTray = TRUE THEN
TrayIcon1.Visible = FALSE
END IF

TrayIcon1.Delete

END


Ca fonctionne tres bien de mon coté.

Olivier
Lorsqu'on s'occupe d'informatique, il faut faire comme les canards... Paraître calme en surface et pédaler comme un forcené par en dessous.
valaquarus#3 Posté le 19/5/2021 à 07:26:02
-- Unus Ex Altera --Bonjour Linuxos,
J'ai essayé ton truc mais j'obtiens la même chose, ce qui me parait normal car :
1
2
3
4
Tray.Hide()
ME.Hide()
WAIT
Tray.Delete()
ou
1
2
3
4
5
IF Desktop.HasSystemTray = TRUE THEN
TrayIcon1.Visible = FALSE
END IF

TrayIcon1.Delete
pour moi c'est pareil.
Quand c'est le formulaire principal qui appelle le form_close cela fonctionne bien par contre, quand c'est le menu du trayIcon cela génère les erreurs citées plus haut.
Des références circulaires, pour moi c'est un objet qui s'appelle lui-même ce qui est bien le cas puisqu'un menuItem du menu lié au trayIcon appelle trayIcon.delete() mais je ne sais pas comment en sortir.
Philippe
Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5
linuxos#4 Posté le 19/5/2021 à 12:52:38
Un peu de sel, de poivre et la crevette sera... Bonjour Valaquarus,

Je pense comprendre ton soucis. J'avais pas noté que c'est quand tu clic sur le TrayIcon pour quitter que tu as l'erreur.
Il me semble que quand tu clic sur le TrayIcon alors tu montes un Événement 'TrayIcon1_Click()' qui doit etre executé, mais pendant que tu l’exécutes tu demandes a quitter l'application, ce qui fait que l’objet 'TrayIcon1', même avec l'instruction 'TrayIcon1.Delete()', n'a pas le temps d'être détruit, d’où la référence circulaire.

Peut être ajouté un délais dans le 'Form_Close()' pour laisser le temps a Gambas de détruire réellement le 'TrayIcon':

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
PUBLIC SUB Form_Close()

IF Desktop.HasSystemTray = TRUE THEN
TrayIcon1.Visible = FALSE

TrayIcon1.Delete()
TrayIcon1 = NULL

' While Object.IsValid(TrayIcon1)
' Try TrayIcon1.Delete()
' TrayIcon1 = Null
' Wait 1
' Wend

END IF

END


Essaye tout d’abord sans la boucle WHILE puis si ça fonctionne toujours pas, décommente la pour tester.
Ca devrait faire ton affaire je pense.

Olivier
Lorsqu'on s'occupe d'informatique, il faut faire comme les canards... Paraître calme en surface et pédaler comme un forcené par en dessous.
valaquarus#5 Posté le 19/5/2021 à 19:43:20
-- Unus Ex Altera --ReBonjour Linuxos,
d'abord merci de te pencher sur mon petit souci.
j'étais en train d'essayer tes propositions.
Voici d'abord ce que j'ai essayé :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
PUBLIC SUB Form_Close() 'fermeture de la fenêtre
ME.Visible = FALSE
' If Not IsNull(Tray) Then
' Tray.Hide()
' Wait 'wait à conserver sinon rien ne se passe
' Try Tray.Delete()
' Tray = Null
' Endif
IF Desktop.HasSystemTray = TRUE THEN
Tray.Visible = FALSE
Tray.Delete()
Tray = NULL
END IF
END

PUBLIC SUB mnuTrayQuit_Click() 'menu quitter
Form_Close()
END

dans cette configuration avec les lignes commentées tel que tu les vois l'arrêt se fait bien par le form_close(croix rouge du formulaire) mais pas par le menu mnuTrayQuit_click où là rien ne se passe.
Par contre si je décommente ces lignes et commente les suivantes alors le progr s'arrête par le mnuTrayQuit_Click avec les erreurs citées plus haut.
La proposition de laisser plus de temps par la boucle while ne fonctionne pas plus.
J'ai essayé de passer un Stop Event et même un Object.detach(Tray) mais c'est idem.
Au lieu de Form_close() j'ai tenté me.close() et là la liste des objets non fermés augmente.
Peut être que le problème vient simplement de l'IDE qui ne veut pas fermer correctement alors que le progr autonome ferme correctement.

1
2
3
4
5
6
7
8
9
10
11
12
13
PUBLIC SUB Form_Close() 'fermeture de la fenêtre
ME.Visible = FALSE
IF NOT IsNull(Tray) THEN
Tray.Hide()
WAIT 'wait à conserver sinon rien ne se passe
TRY Tray.Delete()
Tray = NULL
ENDIF
END

PUBLIC SUB mnuTrayQuit_Click() 'menu quitter
Form_Close()
END

Je vais compiler comme ça et voir ce qui reste en mémoire effectivement.
Philippe

Ps : si je rajoute un wait après Tray.Visible=False alors les deux propositions (commentées) sont équivalentes.
Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5
linuxos#6 Posté le 20/5/2021 à 02:29:57
Un peu de sel, de poivre et la crevette sera... Bonsoir Valaquarus,

Dans ce cas, il me semble que tu devrais ouvrir un bug sur le BugTracker du site de Gambas, cela y ressemble a mon avis.
Reprends les derniers tests que tu m'as cité pour décrire le BUG, je pense que c'est une bonne base.

Olivier
Lorsqu'on s'occupe d'informatique, il faut faire comme les canards... Paraître calme en surface et pédaler comme un forcené par en dessous.
valaquarus#7 Posté le 20/5/2021 à 12:19:01
-- Unus Ex Altera --Bonjour Linuxos,
je ne pense pas que ce soit un bug (sauf de ma part) mais plutôt mon formulaire principal qui doit être "trop complexe" (ce qui veut tout dire) pour une fermeture propre ; j'ai en effet créé un projet vide uniquement avec les éléments de la fermeture (avec un formulaire vide) et là, miracle cela fonctionne très bien et proprement. Je suis donc sur la piste du ou des coupables qui ne se ferment pas correctement et qui empêche le formulaire principal de se clore proprement.
Philippe.
Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5
linuxos#8 Posté le 20/5/2021 à 13:19:48
Un peu de sel, de poivre et la crevette sera... Bonjour Valaquarus,

Dans ce cas il faut traquer tous les objets, tableaux, etc... et les mettres a NULL avant de quitter pour que rien ne reste en mémoire.
Je sais c'est pas normal mais c'est la seule façon que j'ai trouvé pour faire le ménage dans mes projets.

Olivier
Lorsqu'on s'occupe d'informatique, il faut faire comme les canards... Paraître calme en surface et pédaler comme un forcené par en dessous.
valaquarus#9 Posté le 21/5/2021 à 05:58:40
-- Unus Ex Altera --Bonjour Linuxos,
quand même étrange ce problème de clôture propre, récurrent sur beaucoup de projet. pourquoi devoir faire la chasse à ce qui reste ouvert, et qui empêche la libération de la mémoire. Un de mes projets met exactement (montre en main ou avec le débogueur) trois minutes pour libérer la mémoire alors qu'un autre ne la libère pas tant que je n'interviens pas et impossible (pour mes yeux) de faire une différence qui expliquerait cela.
Philippe

PS : autre chose de particulier, quand je ferme par la croix rouge du formulaire cela se ferme correctement plus ou moins rapidement par contre par un menu quelconque en écrivant :
1
ME.close()
cela coince.
Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5
spheris#10 Posté le 22/5/2021 à 10:07:50
Peut être un brutal
1
QUIT
à la Foromus?
ça a au moins l'avantage de fermer sauvagement tout le programme.
:)
www.gambaslinux.fr
valaquarus#11 Posté le 22/5/2021 à 15:02:02
-- Unus Ex Altera --Bonjour à tous,
tout à fait Sphéris mais j'essaye d'être moins brutal (ceci dit ça fonctionne) mais je pense avoir trouvé d'où venait la référence circulaire.
Quand on ferme par me.close (normalement, quoi) il ne faut plus faire référence (ou appel) à quelque chose que l'on a déclaré dans le formulaire que l'on tente de fermer sinon on obtient des références circulaires.
Ici, j'avais un son déclaré dans le formulaire principal que j'appelais dans le splashForm après la fermeture du principal d'où l'erreur. J'ai simplement déplacé l'appel du son au moment de la clôture du formulaire principal et magie de la chose.

Philippe

PS : pour certains projets, trouver d'où viennent ces références circulaires s'avère vraiment coton et heureusement que le
1
QUIT
est là sinon la mémoire serait plutôt encombrée.
Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5
1