Eigene Menuitems in taskbar-popup einschleusen

[Luckie]

Das Systemmenü gehört zum Fenster. Und es werden WM_SYSCOMMAND Nachrichte an dein Fenster verschickt, wenn dort draufgeklickt wird.

[helgew]

Abend,

ich habe nun mal

Delphi-Quellcode:

 if PCWPSTRUCT(lParam)^.message = WM_SYSCOMMAND then
   Windows.MessageBeep(1);

eingebaut und festgestellt, dass diese Message nur kommt, wenn das Menü aufgerufen wird, jedoch nicht, wenn ein Item geklickt wird. Gibt es dazu weitere Messages, die mir vielleicht den Item-Index liefern oder muss ich mir das Menu-Handle merken und danach bei einer WM_LBUTTONDOWN Message das passende menuitem-rectangle suchen? Ich denk ich probier das mal eben aus...

[Luckie]

WM_SYSCOMMAND wird auch aufgerufen, wenn ein Menüpunkt angeklickt wird.

[helgew]

ja schön wäre das... wieso bekomme ich dann bei dem Test keinen weiteren Beep?
Wird eigentlich das Erzeugen einer SW_MINIMIZE Message beim Klicken des standardmäßigen Menüpunktes von Windows durchgeführt oder von der DefWindowProc? irgendwer muss doch die Messages bekommen, wenn schon nicht der globale hook

[helgew]

Hallo,

so... wieder einen Schritt weiter. Es sind übrigens keine WM_SYSCOMMAND Messages, die da versandt werden.
Als HookID muss man WH_SYSMSGFILTER angeben. Weiter bekommt man sehr seltsame Messages. Ich habe mal ein paar
in einen Stream abgezweigt ( die WM_NULL, WM_MOVE, WM_CREATE, WM_DRESTROY etc sind unterdrückt )

nun bekommt man bei mehrmaligem Betätigen des SystemMenüs folgende messages (beim hovern):

Zitat:

A083F120 // Wiederherstellen (grayed)
A080F010 // Verschieben (normal)
A080F000 // Größe ändern (normal)
A080F020 // Minimieren (normal)
A080F030 // Maximieren (normal)
A080F060 // Schließen (normal)

Bei meinem eigenen Menu Item wird folgendes ausgegeben

Zitat:

A0800000 // vermutl mouseenter über eigenem Element mit 0000 anstelle Fxx0 (normal)
A8030000 //
A0800000 // hovering (normal)
00000001 // WM_CREATE
FFFF0000 // ???

Schlussfolgerungen (jeweils Hi-Word(message))

Zitat:

A090 : Linksclick auf ein Systemmenü
0000 : Menü wird erzeugt / geöffnet
FFFF : Menü wird geschlossen / entfernt
A08X : MouseEnter für einen Menüpunkt (Menüpunkt-ID : Lo-Word(message))

Nachtrag 21:02 :
Ok ich habs zum Laufen gekriegt... jetzt räume ich den code noch etwas auf und dann könnt ihr euch den mal anschauen

[helgew]

-

[helgew]

So, bevor ich nun rausfinde, wie man den thread anders kennzeichnet, sei an dieser Stelle in chronologischer Reihenfolge toms, axellang, Crazy Ivan und insbesondere Luckie für die fachliche und moralische Unterstützung gedankt

Thema erledigt.

Verbesserungen:
Momentan gibt es noch einige Ausnahmen, wo keine MenuItems gesetzt werden, wie zum Beispiel Firefox und Explorer. Dies zu ergründen ist aber nicht Kernbereich meines Interesses.
Außerdem könnte man noch den Index des MenuItem anders setzen und noch einen Trenner einfügen.
Zuletzt könnte man den Überwachungstimer durch das Abfangen der WM_CREATE messages für Hauptfenster ersetzen und so direkt eingreifen, wenn das Fenster und sein Menü erzeugt wird.

Ciao

[helgew]

Es ist vollendet.

Dieses kleine Progrämmchen wird später mal als Dienst im Hintergrund laufen und Menüerweiterungen bereitstellen.
Momentan fügt es den Systemmenüs den Punkt "Process priority ..." hinzu, der beim Anklicken ein Fenster anzeigt, mit dem man die Prozesspriorität setzen kann ( bei jenem Prozess, dem das Fenster gehört )

http://c.imagehost.org/0652/ppGUI.png


Funktionsprinzip:

• es werden beim Starten und alle 2.5 Sekunden bei jenen Systemmenüs, die noch kein selbstdefiniertes Item besitzen, ein "Set Process Priority ..." - Item mit ID $FCC0 hinzugefügt. (Die Standardbuttons rangieren im Bereich $F000-$F120 soweit ich das gesehen habe)
• Die Callback-Prozedur ist in eine dll ausgelagert, diese wird geladen und der Hook mit dem Modulhandle hDLL angesprochen.
• SetWindowsHookEX(WH_SYSMSGFILTER, ...,hDLL) setzt einen Hook, durch den insbesondere die Messages $A08XFXXX laufen, wobei $A080FXXX für MouseEnter in einen aktivierten MenüItem-Eintrag steht. Das Klick-Ereignis führt, wie auch das Bestätigen durch Enter, unter anderem zur $FFFF0000 Message, die ich als "menu close" interpretiere.
• War die zuletzt durch $A08XFXXX festgestellte ID die selbstdefinierte Item ID $FCC0, so wird mit RegisterWindowMessage ein Messagetyp "WM_PROCESSPRIORITYSET_EXT" zum Broadcast registriert und mithilfe von SendMessageTimeout(HWND_BROADCAST, ...) und dieser Message eine Message mit ProcessID und Handle des Prozess-Hauptfensters als WParam und LParam ausgesandt. Ein Aufruf des Hauptprogrammes aus der DLL, welche in diesem Fall vom System genutzt wird, ist mit ShellExecute nicht möglich, da der Programmpfad nicht gespeichert werden kann ( wie auch? Ich sehe hier nur die Möglichkeit, irgendwie an den Pfad des Moduls heranzukommen, wenn überhaupt )
• Das Hauptprogramm startet sich der Einfachheit halber und für mehr Crashsicherheit selbst erneut mit drei Parametern "setpriority <ProcessID> <hwndmainwindow>", wodurch das Formular randlos wird, nur das Steuerpanel anzeigt und sich an die Stelle der Clientfläche des angegebenen Fensters setzt. Die aktuelle priority class wird geladen und in die GUI übernommen. Ein Bestätigen setzt die neue Priorität und schließt das eingeblendete tool.
  

[extrem]

@helgew Editiere bitte trotzdem das nächste Mal deine Beiträge. Es wird hier nicht gerne gesehen wenn jemand innerhalb von 24 Stunden 4 Beiträge hintereinander verfasst.

[rotfc]

Zitat von extrem:

@helgew Editiere bitte trotzdem das nächste Mal deine Beiträge. Es wird hier nicht gerne gesehen wenn jemand innerhalb von 24 Stunden 4 Beiträge hintereinander verfasst.

Und die katholische Kirche verbietet Sex vor der Ehe

Wenn ich ein paar Tage lang an einem Delphi-Problem hängen bleibe und das Problem dann aufgrund einer Antwort aus der DP gelöst wird, würde ich meinen letztbezüglichen alten Beitrag in der DP nicht editieren, sondern - aus Freude über die geschaffte Problemlösung - "pushen".

Seid doch nicht immer päpstlicher als der Papst! Sterben tun wir früh genug