TrayIcon & Position
-
GetWindowText ist ja in user32.dll definiert. Die DLL ist im Adressraum von deinem Programm, somit kann sie auch dort schreiben. Wie jetzt user32.dll an den Namen kommt ist Sache von Windows und deren Handle-Verwaltung. Mit SendMessage wird die Nachricht direkt an das Fenster im fremden Prozess gechickt. Wenn das Fenster deinen Pointer nutzt greift es auf die Adresse im eigenen Adressraum zu.
-
OK, dann sach ich halt statt GetWindowText eben WM_GETTEXT.
Wo ist da der Unterschied zu TB_GETITEMRECT?
-
WebFritzi schrieb:
Wo ist da der Unterschied zu TB_GETITEMRECT?
OK, ich gebe zu, ich weiß es nicht.
Aber da mich das jetzt interessiert hab ich mal im Internet nachgeschaut. Windows behandelt manche Nachriten, unter anderem WM_GETTEXT (, WM_SETTEXT, WM_COPYDATA), anders, wenn diese Prozess-Grenzen überschreiten (um abwärtskompatibel zu den Real-Modus-Windows zu bleiben). Laut dieser Seite: http://www.mvps.org/vcfaq/sdk/16.htm regelt Windows das über Memory Mapped Files.
Und in der Tat bekommt das fremde Fenster in meinem Test nicht die Adresse, die ich bei WM_GETTEXT in lParam übergebe, welch Überraschung.
-
D@niel $chumann schrieb:
Und in der Tat bekommt das fremde Fenster in meinem Test nicht die Adresse, die ich bei WM_GETTEXT in lParam übergebe, welch Überraschung.
Es war mir schon klar, dass der Text kopiert wird. Aber so könnte es sich doch auch mit der RECT-Struktur verhalten, oder?
-
Die Windowsentwickler werden sich schon was dabei gedacht haben, warum sie das nicht bei jeder Nachricht machen.
Wen interessiert schon irgendeine RECT-Struktur von nem anderen Prozess -> so gut wie niemanden und da muss man Windows ja net noch mehr ausbremsen...
bei WM_GETTEXT kann man es ja noch einigermassen verstehen (wahrscheinlich hat Microsoft irgendein Produkte, das WM_GETTEXT prozessübergreifend verwendet und das muss ja auch auf nem Protected-Mode-Windows noch laufen).
-
Eine Toolbar ist ein CommonControl. Die CommonControls werden, wie das auch bei eigenen Controls üblich ist, über Nachrichten des Typs WM_USER gesteuert:
#define TB_GETITEMRECT (WM_USER + 29)Woher soll Windows jetzt wissen, daß ein RECT kopiert werden muß? Es könnte doch auch sein:
#define RB_GETBANDINFOA (WM_USER + 29) #define TTM_UPDATE (WM_USER + 29) #define TBM_SETTOOLTIPS (WM_USER+29)Wann ist jetzt RECT, wann nicht?
-
-King- schrieb:
Woher soll Windows jetzt wissen, daß ein RECT kopiert werden muß?
Na, das erkennt Windows wohl daran, dass die Message an eine ToolBar geschickt wurde.
-
WebFritzi schrieb:
Na, das erkennt Windows wohl daran, dass die Message an eine ToolBar geschickt wurde.
Bedenke, daß die Toolbar kein natives Control ist.
-
Meinst du mit "nativ" sowas wie Button & Co? Und was soll man da bedenken? Die Toolbar hat doch auch ihre eigene WindowProc, oder?
-
Natürlich hat auch die Toolbar eine WndProc. Und diese WndProc behandelt jetzt irgendwie die Nachricht (WM_USER + 29). Was da passiert, weiß das System natürlich nicht und kann deswegen auch nicht eingreifen. Anders sieht es bei WM_SETTEXT aus, da weißt Du sehr wohl vorher, was passiert.
Mit native meine ich, daß die Toolbar nicht zum System gehört, sondern nur eine art AddOn ist. Schau Dir den von Dir angesprochenen Button an, der versteht 'echte' Nachrichten und nicht WM_USER. Z.B.:
#define BM_GETCHECK 0x00F0
-
Ah OK. Ich fange an zu kapieren.