Das Problem mit dem vergessenem TrayIcon

[shmia]

Zitat:

Zitat von Popov (Beitrag 1154104)

Wie gesagt, ich habe keine Komponente.

Es gibt ja 3 Ansätze für Tray Icons:
a.) Komponente
Vorteile: Wiederverwendbar, für den Programmier leicht zu benützen, in der Regel "idiotensicher" und Fehlerfrei
Nachteile: muss installiert werden, bringt gewissen Overhead mit sich
b.) eine Klasse (von TObject abgeleitet)
Vorteile: Wiederverwendbar, relativ leicht zu benützen
Nachteile: keine
c.) direkter Aufruf von Windows API-Funktionen
Vorteile: erlaubt auch spezielle Anpassungen
Nachteile: nicht wiederverwendbar, Fehlerträchtig, Code verschmutzt die Anwendung,
schlecht auf Veränderungen anpassbar

Ein professioneller Programmierer kann eigentlich nur die Ansätze a.) oder b.) verwenden.
Die Variante c.) ist für Cowboy-Programmierer.

[EWeiss]

Zitat:

direkter Aufruf von Windows API-Funktionen

Da ich lieber direkt mit der API arbeite anstatt wie bei b.) über umwegen mit der API
bin ich doch lieber ein Cowboy-Programmierer

Anstatt wie du "Ein professioneller Programmierer"
Der alles in doppelter ausführung abgelegt haben muss letztendlich ruft auch deine Klasse die selbe API auf
halt nur über Umwege und das soll professional sein?

Zum Thema da gab es immer schon diverse probleme mit den Tray Icons das diese nicht oder schlecht aktualisiert wurden.
Gab irgendwo mal einen Patch vom MS dafür .. hab ihn aber vergessen.

gruss

[Popov]

Zitat:

Zitat von turboPASCAL (Beitrag 1154116)

Inder IDE per Stopp oder bei einem "normalem" Beenden des Programmes ?

Beides

Zitat:

Zitat von Aphton

Ich glaube das ist dann der Fall, wenn das Programm abrupt terminiert wird,

Das ist schon in paar hundert mal in paar hundert Programmen passiert. Ich glaube nicht, dass ich sie alle terminiert habe. Nein, soweit hat alles schon seine Richtigkeit und spätestens bei FormDestroy wird alles beendet.

Zitat:

Zitat von shmia

Es gibt ja 3 Ansätze für Tray Icons:

a) ich hab nichts gegen Komponenten und nehme sie wenn es sein soll, aber aufgrund einige schlechte Erfahrungen gehe ich sehr sparsam mit zusätzlichen Komponenten. Ich investiere (privat) liebe einen Tag mehr in das Programm und kann mir sicher sein, dass ich in 10 Jahren in der fünf höheren Version das Programm aus dem Archiv holen kann und es funktioniert ohne Probleme, und ohne dass ich etwas nachinstallieren muß was vielleicht nicht mehr kompatibel ist. Wie gesagt - privat.

b) gegen eine Klasse habe ich nichts und wenn alles fehlerfrei funktioniert, dann mache ich es sofort. Aber auch wenn die letzte Version relativ gut funktioniert, so nicht 100% fehlerfrei. Mich wundert es, dass es hier noch keinem aufgefallen ist, allerdings ist es nicht ein Problem einzig von mir. Ich hatte schon einige Delphi-Fremdprogramme bei denen auch diese Probleme vorkamen.

c) mag sein, aber nicht selten schreibe ich die paar Zeilen schneller als das ich eine Unit oder Klasse erst suchen muß. Im Grunde genommen sind es nur paar Zeilen Code, wenn man nichts komplexes will, wie z.B. wechselnde Icons, Reaktionen auf verschiedene Aktionen, usw. Wenn man nur ein PopupMenu aufrufen will, sind es nur paar Zeilen.

Aber hier geht es nicht drum was die einzig richtige Methode ist, sondern warum das Problem besteht. Soll ich irgendwann im hohen Alter meinen Enkeln erzählen, ich hatte da ein Problem, ich habe es aber nicht gelöst, ich habe einfach eine Fremdkomponente genommen?

[EWeiss]

Du hast doch ne CallBack in der Shell_NotifyIcon API
Welche Message verwendest du denn dafür?

Und das wäre eine möglichkeit!

FindWindowEx
GetClientRect
SendMessage

gruss

[shmia]

Zitat:

Zitat von EWeiss (Beitrag 1154139)

Da ich lieber direkt mit der API arbeite anstatt wie bei b.) über umwegen mit der API
bin ich doch lieber ein Cowboy-Programmierer

Ich weiss! So sieht dein Sourcecode dann halt auch aus.
Hauptsache es funktioniert irgendwie, ist wohl deine Einstellung.
Als "Profi" kann ich mir so etwas nicht leisten.
Jede Unsauberkeit rächt sich später irgendwann (zumindest dann wenn man eine Software über mehr als 10 Jahre erweitern, verbessern und warten muss).
Ich hab' hier mehrere Projekte mit zusammen 1,4 Mio Zeilen.
Um dies zu bewältigen, muss man einfach jeden Zugriff auf die Windows API der etwas komplizierter ist auf irgendeine Art und Weise kapseln.
Wenn Windows ein Handle zurückliefert mit dem weitere API-Funktionen aufgerufen werden, ist das ein ganz klares Zeichen, dass man das Handle mit einer Klasse kapseln muss.

Auch Programmierer die nur so zum Spaß programmieren können noch was dazulernen indem sie ihre "Hauptsache es funktioniert" Einstellung ablegen.

[Popov]

Zitat:

Zitat von EWeiss (Beitrag 1154145)

Du hast doch ne CallBack in der Shell_NotifyIcon API
Welche Message verwendest du denn dafür?

Guck dir mal das Beispiel hier an: http://www.delphipraxis.net/30716-post2.html In wichtigen Punkten waren meine Zeilen gleich. Unterschiede lagen in Details, wie z. B. andere Bezeichner usw. Wobei ich durchaus experimentierfreudig war, denn es gibt viele Möglichkeiten um ans Ziel zu kommen, aber alle waren in wichtigen Punkten gleich.

Wobei sich das obere Beispiel in einem Punkt von allen meinen Versuchen unterscheidet: es führt in FormDestroy die ganze Prozedur ein zweites Mal durch. Ich, und eigentlich auch die anderen Beispiele, führten in FormDestroy einfach nur

Delphi-Quellcode:

Shell_NotifyIcon(NIM_DELETE, @NotifyIconData)

aus, hier ward alles noch mal zugewiesen. Aber bis auf NotifyIconData.Wnd Zuweisung sehe ich da keinen nennenswerten Unterschied. Trotzdem funktioniert der Code besser als die anderen. Aber auch nicht perfekt.

Zitat:

Und das wäre eine möglichkeit!

FindWindowEx
GetClientRect
SendMessage

Ich hab sehr vieles versucht, auch den Tray Bereich mit Messages Mausklick Simulationen bombardiert. Richtig gebracht hat nichts.

[EWeiss]

Zitat:

Zitat von Popov (Beitrag 1154150)

Zitat:

Und das wäre eine möglichkeit!

FindWindowEx
GetClientRect
SendMessage

Ich hab sehr vieles versucht, auch den Tray Bereich mit Messages Mausklick Simulationen bombardiert. Richtig gebracht hat nichts.

Du solltest halt auch dafür sorgen das die Icons angesprochen werden.
Das sollte gehen. (Auf die schnelle zusammengetippt (Ungetestet))
Warnung API vom Cowboy-Programmierer

Delphi-Quellcode:

procedure CleanTray;
  {Entfernt ungenutzte icons vom system tray}
var
   TrayNotifyHwnd: HWND;
   ParentHwnd: HWND;
   TrayWindowRect: TRect;
   x: integer;
   y: integer;
begin
   ParentHwnd := FindWindow('Shell_TrayWnd', '');
   //Hwnd vom TrayNotifyWnd ermitteln
   TrayNotifyHwnd := FindWindowEx(ParentHwnd, 0, 'TrayNotifyWnd', '');
   //ClientRect von der Classe TrayNotifyWnd einlesen
   GetClientRect(TrayNotifyHwnd, TrayWindowRect);

   x :=0;
   y :=0;

   while x < TrayWindowRect.Right do begin
     while y < TrayWindowRect.Bottom do begin
       SendMessage(TrayNotifyHwnd, WM_MOUSEMOVE, 0, (y shl 16) + x);
       y := y + 5;
     end;
     x := x + 5;
   end;
end;

gruss

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1154139)

und das soll professional sein?

Wenn sich an der API mal was ändert, oder neue Features hinzukommen, oder man von Windows auf Mac wechselt,
dann muß man nur an einer Stelle, in dieser Klasse, etwas ändern.

Außerdem hat man den Code so an einer Stelle vereint, anstatt die verschiedenen Aufrufe/Funktionen eventuell noch sonstwo verteilt zu haben. (leichter zu finden)
Und wenn diese Klasse dann auch noch mindestens in 2 Programmen verwendet wird, dann hast du gleich alle Programme automatisch angepaßt.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1154153)

Zitat:

Zitat von EWeiss (Beitrag 1154139)

und das soll professional sein?

Wenn sich an der API mal was ändert, oder neue Features hinzukommen, oder man von Windows auf Mac wechselt,
dann muß man nur an einer Stelle, in dieser Klasse, etwas ändern.

Außerdem hat man den Code so an einer Stelle vereint, anstatt die verschiedenen Aufrufe/Funktionen eventuell noch sonstwo verteilt zu haben. (leichter zu finden)
Und wenn diese Klasse dann auch noch mindestens in 2 Programmen verwendet wird, dann hast du gleich alle Programme automatisch angepaßt.

Ich meine professional im sinne von Doppelt Gemoppelt ;)

Grundsätzlich hast du aber schon recht. (Was Delphi angeht)

PS:

Delphi-Quellcode:

NotifyIconData.uCallbackMessage := WM_TASKABAREVENT;

sollte
WM_MOUSEMOVE sein.
Deshalb meine Frage nach der CallbackMessage.

gruss

[Popov]

Zitat:

Zitat von shmia (Beitrag 1154149)

Auch Programmierer die nur so zum Spaß programmieren können noch was dazulernen indem sie ihre "Hauptsache es funktioniert" Einstellung ablegen.

Also den Punkt müssen wir dann doch ausdiskutieren. "Hauptsache es funktioniert" habe ich noch nie programmiert. Und so wie ich dich verstanden habe geht es hier nur das Problem auszulagern in dem man alles dazukauft was es zu kaufen gibt. Auf dem Programm lagern dann 50 Komponenten die alles für mich erledigen und ich hab einen pflegeleichten 10 Zeilen langen Code.

Natürlich kann ich alles kapseln und ob du es glabst oder nicht, das mache ich auch, aber nicht immer. Warum soll ich die Funktion zum einlesen alle Daten eines Ordners auslagern, wenn das Programm selbst nie mehr als 30 Zeilen haben wird.

Es gibt immer einen Unterschied ob man ein professionelles Programm schreibt oder schnell ein Problemlöser.