2 Fragen zum Thema: Prog in die TNA verschieben

[Marco Steinebach]

Hallo,
ich hab noch zwei Verständnisfragen zum Thema, daß ein Programm beim Minimieren in die TNA verschoben wird:

In der Unit von Luckie wird eine Message mittels RegisterWindowMessage registriert, die dann ausgelöst wird, wenn
Zitat:
Die Taskbar im System registriert wird.

Wann wird sie das, sprich: durch was wird die Message ausgelöst?

Es gibt zwei Wege, das Programm in der TNA abzulegen. Einmal eine Message-Prozedur für
WM_TASKBAREVENT
zu schreiben, und, zum Zweiten, die
WndProc
zu erweitern.
Ist eine davon zu bevorzugen, warum?

Vielen Dank für eure Antworten!

Marco

[Muetze1]

Ich gehe mal davon aus, dass die RegisterWindowMessage die Explorer Nachricht ID ermittelt. Diese Nachricht wird vom Explorer per Broadcast an alle Top Level Fenster verschickt um ihnen zu signalisieren, dass die Taskbar zur Verfügung steht und Registrierungen von Icons in der TNA vorgenommen werden können. Wenn der Explorer abstürzt und neu gestartet wird, dann wird diese Nachricht von ihm verschickt und dein Programm kann darauf reagieren und das Icon neu registrieren.

Die WndProc oder die direkten MessageHandler sind soweit nicht gross unterschiedlich. Ein MessageHandler kann immer nur eine Message behandeln und das auch nur, wenn zum Erstellunsgzeitpunkt die ID der Nachricht bekannt ist. Die oben genannte Nachrichten ID wird durch RegisterWindowMessage() ermittelt und ist somit nicht bekannt zur Erstellungszeit und kann somit nicht mit einer solchen Methode behandelt werden. Da ist dann die WndProc die einzige Wahl zwischen den beiden Möglichkeiten. Auch wenn man z.B. mehrere Nachrichten abfangen will und alles themenverwandt ist, würde ich persönlich das überschreiben der WndProc bevorzugen, da es sonst unnötig aufgebläht wird.

Nachteil von WndProc: Man muss den Typ TMessage auf bestimmte Nachrichtenstrukturen erst noch typecasten, bei den einzelnen MessageHandlern kann man schon einen speziellen Typ angeben. Dafür kann man afaik in der WndProc die weitere Behandlung der Nachricht unterbinden (in der Klassenhiarchie) durch weglassen des inherited Aufrufes. Bei den MessageHandlern geschieht dies afaik immer.

[SirThornberry]

@Muetze: So weit ich weiß liefert RegisterWindowMessage eine freie MessageID zurück. Manche nutzen feste ID's wie "wm_user + 1" und andere lassen sich per RegisterWindowMessage eine freie ID zurück geben um Konflikte zu vermeiden.

[Marco Steinebach]

Hi Muetze,
vielen herzlichen Dank für die rasche, verständliche und schlicht sehr gute Antwort!
Jetzt bin ich schon 'n erhebliches Stück weiter!

Viele Grüße
Marco

[Muetze1]

Zitat von SirThornberry:

@Muetze: So weit ich weiß liefert RegisterWindowMessage eine freie MessageID zurück. Manche nutzen feste ID's wie "wm_user + 1" und andere lassen sich per RegisterWindowMessage eine freie ID zurück geben um Konflikte zu vermeiden.

Ja, richtig. Eine freie aus dem Pool der von RegisterWindowMessage() belegbaren Bereich. Die in einer App privat deklarierten wie du sie hier nennst, gilt das nicht. Diese werden dort nicht "ausgetragen" und können somit theoretisch mit diesen überschneiden.

RegisterWindowMessage() wird in so fern genutzt um eine eindeutige ID innerhalb von Windows zu bekommen. Der Identifier (String-Parameter) ist eindeutig - die erste App mit diesem String bekommt eine freie ID. Alle darauffolgenden Aufrufe mit dem gleichen String liefert die gleiche ID. Damit wird sicher gestellt, dass sich vor allem unterschiedliche Programme verständigen können. Der Explorer nutzt auch daher diese Funktion und definiert nicht eine globale Konstante in der WinAPI - und genau das spricht gegen Nutzung eines direkten MessageHandlers wie oben genannt. Da kann man dann nur noch mit der WndProc arbeiten.