TRAYICON - VOTRE ICONE DANS LA BARRE DES TACHES
blueperfect
Messages postés
234
Date d'inscription
mardi 13 novembre 2007
Statut
Membre
Dernière intervention
21 novembre 2013
-
20 mars 2009 à 04:51
blueperfect Messages postés 234 Date d'inscription mardi 13 novembre 2007 Statut Membre Dernière intervention 21 novembre 2013 - 23 mars 2009 à 23:00
blueperfect Messages postés 234 Date d'inscription mardi 13 novembre 2007 Statut Membre Dernière intervention 21 novembre 2013 - 23 mars 2009 à 23:00
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/49558-trayicon-votre-icone-dans-la-barre-des-taches
https://codes-sources.commentcamarche.net/source/49558-trayicon-votre-icone-dans-la-barre-des-taches
23 mars 2009 à 23:00
23 mars 2009 à 20:10
Cordialement, Bacterius !
23 mars 2009 à 18:56
Qu'est ce que je disais ah oui, le ballon d'information peut servir d'alerte et donc bien sûr peut déboucher sur tout un tas d'action..
il y aussi le message qui monte et qui descend derrière la barre de taches..etc.
23 mars 2009 à 18:47
Moi je fais ça (avec la version la plus récente du composant, c'est-à-dire celle qui est en ligne) :
// Ajout d'un composant TrayIcon, avec Active := True, IconType := itDefault, Hint := 'My TrayIcon';
// Ajout d'un bouton :
procedure TForm1.Button1Click(Sender: TObject);
begin
TrayIcon1.BalloonHint('Salut !', 'Hahaha', 10, biInfo);
end;
Et mon ballon s'affiche sans problème.
Evidemment si il n'y a pas d'icône, aucun ballon ne s'affichera (j'ai même mis un contrôle d'erreur dans la procédure BalloonHint).
Cordialement, Bacterius !
23 mars 2009 à 18:41
Sinon, oui quand il y a trop de choses ça devient pénible (regarde CoolTrayIcon, je ne l'utilise plus à cause de ça ... trop d'options inutiles !).
Sinon ... envoyer des e-mails n'est pas le rôle d'une icône :} enfin je pense - celui qui veut faire ça n'a qu'à envoyer la procédure SendEmail (par exemple) pour envoyer son e-mail quand il en a besoin.
Je vérifie le ballon ...
Cordialement, Bacterius !
22 mars 2009 à 22:16
C'était le charme du compo..
rien ajouter, ouf.. on peut toujours tu pourrais mettre des alertes styles MSN envoyer des emails etc..
mais dès que ça devient l'usine à gaz..
essaie de remettre les ballons et stabilise le.
22 mars 2009 à 18:25
Sinon, je pense qu'on peut difficilement ajouter quelque chose de plus à ce composant ...
Cordialement, Bacterius !
22 mars 2009 à 18:13
21 mars 2009 à 16:51
Cordialement, Bacterius !
21 mars 2009 à 13:02
7/10 (lol)...
21 mars 2009 à 12:14
Maintenant, l'icône se remet automatiquement dans la barre des tâches si explorer.exe a un problème et doit fermer.
Néanmoins, j'ai un problème : "Erreur système. Code : 1400. Handle de fenêtre non valide" dans toutes les fenêtres Delphi. Mais ça ne doit pas venir de mon composant.
Cordialement, Bacterius !
21 mars 2009 à 11:56
Cordialement, Bacterius !
20 mars 2009 à 21:26
Cordialement, Bacterius !
20 mars 2009 à 21:20
Mais restons en là sur ce sujet, je souhaitais publier un composant, et il ne voit pas le jour...
20 mars 2009 à 21:18
si c'est l'utilisateur qui le kill c'est l'OS qui le redémarre donc contrôle total
quand à ta série de messages elle ne sert à rien dans ce cas précis ... ça n'a rien à voir avec la gestion de l'alimentation.
20 mars 2009 à 20:52
Anormal, et là tu n'as pas de moyen réel de controler...alors j'oublie !
>>en général c'est l'OS qui le fait
Normal, et là il y a une série de messages et de confirmations, voire ci-dessus...là je traite...
>>pfff....calme toi
exaspération : 7 synonymes.
Synonymes agacement, aggravation, crispation, énervement, exacerbation, irritation, rage.
je ne te retourne pas l'onomatopée...
20 mars 2009 à 20:45
il n'y a rien d'irrespectueux là dedans.
c'est toi qui prend tout de haut sinon on en serait pas là en ce moment .....
outre le fait que l'utilisateur peut terminer le processus Explorer.exe en général c'est l'OS qui le fait.
je te retourne donc ce conseil ... calme toi
20 mars 2009 à 20:33
procedure TD3User.AfterConstruction;
begin
inherited AfterConstruction;
if not(csDesigning in self.ComponentState)
then self._handle := Classes.AllocateHWnd(self.DoWindowProcedure);
end;
procedure TD3User.DoWindowProcedure(var _message:TMessage);
const
// APM messages
PBT_APMQUERYSUSPEND = $0000;
PBT_APMQUERYSTANDBY = $0001;
PBT_APMQUERYSUSPENDFAILED = $0002;
PBT_APMQUERYSTANDBYFAILED = $0003;
PBT_APMSUSPEND = $0004;
PBT_APMSTANDBY = $0005;
PBT_APMRESUMECRITICAL = $0006;
PBT_APMRESUMESUSPEND = $0007;
PBT_APMRESUMESTANDBY = $0008;
PBT_APMBATTERYLOW = $0009;
PBT_APMPOWERSTATUSCHANGE = $000A;
var _allow:Boolean;
begin
inherited; // default message handler
if _message.Msg = WM_POWERBROADCAST
then case _message.WParam of
PBT_APMQUERYSUSPEND : begin
_allow := self.DoQuerySuspend;
if _allow
then _message.Result := Integer(True)
else _message.Result := BROADCAST_QUERY_DENY;
end;
PBT_APMQUERYSTANDBY : begin
_allow := self.DoQueryStandby;
if _allow
then _message.Result := Integer(True)
else _message.Result := BROADCAST_QUERY_DENY;
end;
PBT_APMBATTERYLOW : self.DoBatteryLow;
PBT_APMPOWERSTATUSCHANGE : self.DoPowerStatusChange;
PBT_APMRESUMECRITICAL : self.DoResumeCritical;
PBT_APMRESUMESUSPEND : self.DoResumeSuspend;
PBT_APMRESUMESTANDBY : self.DoResumeStandby;
PBT_APMSUSPEND : self.DoSuspend;
PBT_APMQUERYSUSPENDFAILED : self.DoSuspendFailed;
PBT_APMSTANDBY : self.DoStandby;
PBT_APMQUERYSTANDBYFAILED : self.DoStandbyFailed;
end
else if _message.Msg = WM_QUERYENDSESSION
then _message.Result := Integer(self.DoQueryEndSession);
end;
C'est une mini-gestion de l'arrêt/mise en veille/restart...
Tu alloue un handle de fenêtre virtuel (sans visuel), et il intercepte les messages de l'alimentation... bon courage
DH
20 mars 2009 à 20:24
Je ne vois pas trop comment faire autrement que de surcharger Application.OnMessage, vu que le système, quand explorer redémarre, envoie le message juste aux fenêtres parentes, soit Application.
Je n'ai jamais aimé travailler avec Application.OnMessage. Plusieurs dizaines de milliers de messages passent par cet événement toutes les secondes, il ne faut pas se louper ...
Cordialement, Bacterius !
20 mars 2009 à 20:19
"C'est ça qui n'est pas normal, de deoir re-démarrer l'explorer..."
Je ne suis pas d'accord non plus. Parfois, WindowsXP, à la suite de certaines opérations, doit redémarrer l'explorer. Ca peut arriver. Il faut savoir être souple, si l'utilisateur aime bien cliquer sur "Terminer le processus" quand la liste est sur "explorer.exe", l'application doit savoir réagir à ça.
Cordialement, Bacterius !
20 mars 2009 à 20:17
20 mars 2009 à 20:15
Cordialement, Bacterius !
20 mars 2009 à 20:14
Je ne suis pas d'accord - dans certaines situations on peut être amené à avoir plusieurs icônes (même si c'est inhabituel) pour une même application.
Cordialement, Bacterius !
20 mars 2009 à 20:12
Si Explorer redémarre, il envoie à toutes les applications un message, TaskBarCreated. Ces applications envoient ensuite ce message à leur fiche principale. Or, si le composant gère son propre handle, le message n'arrivera jamais au composant.
Mais la réponse doit se trouver dans le composant que tu m'as passé :)
Cordialement, Bacterius !
20 mars 2009 à 20:12
20 mars 2009 à 20:10
heuuu
>>>Pffff
Tu es administrateur, mais tu te calmes quand même, et tu restes respectueux, s'il te plaît...
>>>je t'envoie un lien pour te prouver qu'explorer peut être amené à redémarrer
C'est ça qui n'est pas normal, de deoir re-démarrer l'explorer...
>>>tu as déjà essayé d'afficher une instance de TApplication
Handle + Icon + Title --> TrayIcon de l'instance de l'application
>>>Callback tu surcharges un TApplication
En l'occurence, oui.
>>moi je déclare la procédure et l'utilise dans l'unité/objet dans le quel elle est utilisée.
moi, je fais un composant (ou une propriété) avec évènements, et je le pose sur la fiche...
>>>en l'occurrence ici le CallBack est déclaré et traité dans le composant
Il ne devrait y avoir qu'une seul trayicon par application !
20 mars 2009 à 20:10
Oui le callback est géré par le composant même.
Mais j'ai un problème. Si l'on utilise le handle de la fiche, ça ne marche plus, puisque les messages ne sont plus envoyés au composant, et donc par conséquent plus rien n'est traité. Non ?
Cordialement, Bacterius !
20 mars 2009 à 19:58
je t'envoie un lien pour te prouver qu'explorer peut être amené à redémarrer et toi tu reviens sur le fait que j'ai utiliser fiche à la place d'application !!!
alors oui je l'ai dit ... mais on s'en fout dans la pratique tu as déjà essayé d'afficher une instance de TApplication !!!
quand tu fais un Callback tu surcharges un TApplication toi ?
moi je déclare la procédure et l'utilise dans l'unité/objet dans le quel elle est utilisée.
en l'occurrence ici le CallBack est déclaré et traité dans le composant même !!!
pfff!!!
20 mars 2009 à 19:13
Si, si, j'apprends chaque jjour que Dieu fait...
Après lecture de http://msdn.microsoft.com/en-us/library/cc144179(VS.85).aspx#tbnotify_Adding_Deleting_Icons :
"Applications commonly put icons in the status area of the taskbar to serve as status indicators...
...The system notifies you of mouse and keyboard events by sending an application-defined callback message ..."
il semblerait que la taskbar soit utilisée par les "Applications", et non les "fenêtres" ou "fiches"... C'est d'ailleurs l'Application qui se doit de traiter les callback ! et non une fenêtre fille ...!
@Bactérius
En fait pour Title :
* tu n'as pas tort : cela allourdit l'écritur de TON composant...
* mais tu as tort : cela est plus agréable pour l'utilisateur du Designer de Delphi...
DH
20 mars 2009 à 18:35
il semblerait que tu n'aies plus rien à apprendre ... c'est bien, je suis content pour toi. ^^
Malgré tout je te conseil de jeter un oeil ici:
http://social.msdn.microsoft.com/Search/en-us/?query=TaskbarCreated
Bacterius:
je t'envoie un code tu comprendras mieux et ça te donneras des idées.
20 mars 2009 à 18:27
je connais TrayIcon->> voir PostitForEver
mais 77 m'a intrigué..
20 mars 2009 à 17:46
20 mars 2009 à 17:40
Cordialement, Bacterius !
20 mars 2009 à 17:38
Lol.
Cordialement, Bacterius !
20 mars 2009 à 17:29
C'est celui là :
Je suis en conception d'application, et je dépose ton compo... Je veux rapidement avoir, dans le designer, sans compilation, le visuel de tout changement...
20 mars 2009 à 17:25
L'utilisateur du composant voudrait faire apparaître un ballon.
[Avec la propriété Title] :
1. L'utilisateur du composant définit la propriété Title.
2. L'utilisateur appelle BalloonHint.
[Sans propriété Title] :
1. L'utilisateur du composant appelle BalloonHint en définissant Title à ce moment-là.
Ok, avec Title le gars gagne un paramètre dans BalloonHint. Mais sinon ?
Cordialement, Bacterius !
20 mars 2009 à 17:19
l'utilisateur ou le programmeur ?
lol
DH
20 mars 2009 à 17:17
Sinon je ne vois pas trop l'intérêt d'une propriété Title. Après tout, quand l'utilisateur a besoin d'un ballon il appelle cette méthode et passe un titre de ballon ... l'utilisation d'une propriété Title ne serait que lourde et pas rentable.
Cordialement, Bacterius !
20 mars 2009 à 17:14
procedure BalloonHint( // Shows a balloon hint :
Title: String; // The title of the balloon hint
Hint: String; // The text of the balloon hint
Timeout: Byte; // The timeout of the balloon, in seconds
Icon: TBalloonIcon); // The icon type
20 mars 2009 à 17:10
Cordialement, Bacterius !
20 mars 2009 à 17:08
*Custom contre Basic : le débat est ouvert (je n'aime pas les 'm' !)
*underscores : cela vient d'une notation assembleur/C, où tout ce qui est de "bas niveau" se veut commencer par un "underscore"... Quand nous en serons à utiliser des composants entiers, alors je n'utiliserais plus les "underscores"
*TrayIon relié à une fiche ? non, du tout... La tray icon est le reflet de l'icone prinipale d'un programme (éventuellement d'un thread)...Elle devrait proposer dans son menu un accès au menu principal de l'application, et un accès rapide aux fiches ouvertes !
*explorer redémarré : je ne souhaite à personne de faire tourner une appli qui te force à le redémarrer !
Conclusion : pas très constructif !
@Bacterius
Par contre, tu devrais rajouter la propriété Title:AnsiString, aisnsi qu'une propriété ShowBallon:Boolean, ce qui permets de tester la trayicon directeemnt depuis le Designer de Delphi...
DH
20 mars 2009 à 17:02
@Blueperfect : evidemment oui on peut faire une TCustomTrayIcon qui contient tout le code mais qui ne publie rien, et comme ça on peut s'en servir comme base pour n'importe quel composant. Mais bon, vu que toutes les propriétés sont normalement indispensables (a part peut-être TIconType ...). Pour le OnMouseMove ce n'était pas voulu, je n'ai pas fait attention :)
@Cirec : Ben dans ce cas dans le OnCreate :
constructor T(Custom)TrayIcon.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
if AOwner is TCustomForm then [utilise le handle de la fiche] else
[se crée son handle personnel]
...
end;
Non ?
Je vais prendre un petit goûter et j'arrive améliorer mon composant.
Cordialement, Bacterius !
20 mars 2009 à 11:20
WM_TRAYICON = WM_USER + 77;
77 ?
20 mars 2009 à 05:43
Tu as 18/20 à ce devoir...
@+
20 mars 2009 à 05:42
* pas de bug recensé
* pourquoi OnMove et pas OnMouseMove ?
j'ai créé une sous-classe TBasicTrayIcon, et TrayIcon descendant de celle-ci...
La différence :
TBasiTrayIcon ne publie aucune de ses propriétés, et TrayIton ne fait que les publier...
C'est un tour de passe-passe qui vient de chez Borland (et du C++), qui permets d'avoir en bout de chaine une classe "utilisable", mais en avant-dernier maillon une classe "dérivable", et dont les propriétés sont "publiables", et non "publiées"...
@+
20 mars 2009 à 04:51
Je te conseille (en complément de ce nouveau moyen d'afficher une infobulle), de consulter http://www.delphiarea.com/products/delphi-components/tooltips/
@+