aktives Control ermitteln
Stefan Simon
ich versuche, von einer Fremdanwendung das aktivierte Steuerelement zu
ermitteln.
\\\
IntPtr windowThreadProcessId =
GetWindowThreadProcessId(GetForegroundWindow(), IntPtr.Zero);
IntPtr idAttach = GetWindowThreadProcessId(base.Handle,
IntPtr.Zero);
if (AttachThreadInput(idAttach, windowThreadProcessId, true))
{
IntPtr focus = GetFocus();
if (focus != IntPtr.Zero)
{
Control ctrl = Control.FromHandle(focus);
if (ctrl != null)
{
this.Text = ctrl.Name;
}
else
{
StringBuilder lpClassName = new StringBuilder(0xff);
GetClassName(focus, lpClassName, 0xff);
this.Text = lpClassName.ToString();
}
}
AttachThreadInput(idAttach, windowThreadProcessId, false);
}
///
GetFocus() gibt auch ein Handle zur�ck, aber Control.FromHandle() kein
Object. Vielleicht funktioniert das ja nur mit .Net-Objects. Gibt es noch
eine andere M�glichkeit, an Informationen �ber das Steuerelement zu kommen?
Mich interessiert vor allem der Name, damit ich an das Handle komme, ohne
dass das Control den Fokus hat.
tia
Stefan
Stefan Simon
[DllImport("user32.dll")]
public static extern int SendMessage(IntPtr hwnd, int wMsg, int wParam,
byte[] lParam);
int msg =
GetWinFormsId.NativeMethods.RegisterWindowMessage("WM_GETCONTROLNAME");
int size = 65536;
byte[] buff = new byte[size];
int retLength = GetWinFormsId.NativeMethods.SendMessage(hwnd, msg, size,
buff);
return System.Text.Encoding.UTF8.GetString(buff);
probiert, leider bleibt buff leer ...
Hat jemand eine Idee?
Stefan
Herfried K. Wagner [MVP]
> GetFocus() gibt auch ein Handle zur�ck, aber Control.FromHandle() kein
> Object. Vielleicht funktioniert das ja nur mit .Net-Objects.
'Control.FromHandle' funktioniert nur f�r Steuerelemente der eigenen
Anwendung.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Frank Dzaebel
> ich versuche, von einer Fremdanwendung das aktivierte Steuerelement zu
> ermitteln.
ok.
> if (AttachThreadInput(idAttach, windowThreadProcessId,
> [...] IntPtr focus = GetFocus();
das ist vollkommen richtig so.
Jetzt "hast" Du das Control, bzw. den Handle des Controls.
Du kannst/solltest nun Windows-APIs benutzen, keine managed
Control-Klasse, denn es sind ja ggf. unmanged Controls.
Die Frage ist also schlicht, was willst Du denn nun
mit dem aktiven Control machen? Du sagst zwar
"der Name interessiert Dich", aber auf Windows Ebene
haben wir keinen direkten Namen. Vielleicht meinst Du die
"Steuerelement-ID", oder die "Fensterbeschriftung".
Der "Name" wird �ber Programmiersprachen sp�ter
Control-Handles intern zugeordnet.
Mit:
[pinvoke.net: getwindowtext (user32)]
http://www.pinvoke.net/default.aspx/user32/getwindowtext.html
kannst Du die Beschriftung [window's title bar (if it has one)]
des Controls herausbekommen.
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET
Herfried K. Wagner [MVP]
> Die Frage ist also schlicht, was willst Du denn nun
> mit dem aktiven Control machen? Du sagst zwar
> "der Name interessiert Dich", aber auf Windows Ebene
> haben wir keinen direkten Namen. Vielleicht meinst Du die
> "Steuerelement-ID", oder die "Fensterbeschriftung".
> Der "Name" wird �ber Programmiersprachen sp�ter
> Control-Handles intern zugeordnet.
>
> Mit:
>
> [pinvoke.net: getwindowtext (user32)]
> http://www.pinvoke.net/default.aspx/user32/getwindowtext.html
>
> kannst Du die Beschriftung [window's title bar (if it has one)]
> des Controls herausbekommen.
... oder bei Steuerelementen dann passender 'SendMessage' + 'WM_GETTEXT'.
Frank Dzaebel
>> http://www.pinvoke.net/default.aspx/user32/getwindowtext.html
>> kannst Du die Beschriftung [window's title bar (if it has one)]
>> des Controls herausbekommen.
>
> ... oder bei Steuerelementen dann passender 'SendMessage' +
> 'WM_GETTEXT'.
GetWindowText sendet selber WM_GETTEXT und
geht f�r Fentster und "Steuerelemente".
Thorsten Doerfler
Frank Dzaebel schrieb:
>>> [pinvoke.net: getwindowtext (user32)]
>>> http://www.pinvoke.net/default.aspx/user32/getwindowtext.html
>>> kannst Du die Beschriftung [window's title bar (if it has one)]
>>> des Controls herausbekommen.
>> ... oder bei Steuerelementen dann passender 'SendMessage' +
>> 'WM_GETTEXT'.
>
> GetWindowText sendet selber WM_GETTEXT und
> geht f�r Fentster und "Steuerelemente".
Die Dokumentation zu GetWindowText ist Dir ja sicher bekannt:
GetWindowText Function
http://msdn.microsoft.com/en-us/library/ms633520.aspx
"To retrieve the text of a control in another process, send a WM_GETTEXT
message directly instead of calling GetWindowText."
Im Fall des OP handelt es sich um einen anderen Prozess. Weiter sind
auch die Grenzen und Seiteneffekte von GetWindowText beschrieben.
Thorsten D�rfler
--
Microsoft MVP Visual Basic
vb-hellfire visual basic faq | vb-hellfire - einfach anders
http://vb-faq.de/ | http://www.vb-hellfire.de/
Frank Dzaebel
>> GetWindowText sendet selber WM_GETTEXT und
>> geht f�r Fentster und "Steuerelemente".
>
> Die Dokumentation zu GetWindowText [...]
.. besagt:
"GetWindowText causes a WM_GETTEXT message to be sent
to the specified window *or* control."
> "To retrieve the text of a control in another process, send a
> WM_GETTEXT message directly instead of calling GetWindowText."
das gilt f�r Szenarien *ohne* AttachThreadInput.
Durch das erzeugte Sharing bei AttachThreadInput
(siehe Doku dazu) k�nnen die Messages analog dem
Focus weitergeleitet werden (was sonst nicht m�glich w�re).
F�r den OP hier noch ein paar Implementations-Beispiele:
[CodeProject: Window Hiding with C#]
http://www.codeproject.com/KB/cs/windowhider.aspx?msg=2005709
Herfried K. Wagner [MVP]
Frank Dzaebel schrieb:
>>> GetWindowText sendet selber WM_GETTEXT und
>>> geht f�r Fentster und "Steuerelemente".
>>
>> Die Dokumentation zu GetWindowText [...]
>
> .. besagt:
> "GetWindowText causes a WM_GETTEXT message to be sent
> to the specified window *or* control."
Ja, und:
>> "To retrieve the text of a control in another process, send a
>> WM_GETTEXT message directly instead of calling GetWindowText."
Die zweite Aussage schr�nkt die erste ein.
Au�erdem steht da gleich zu Beginn der Dokumentatin der Funktion
'GetWindowText':
| However, 'GetWindowText' cannot retrieve the text of
| a control in another application.
GetWindowText Function ()
<URL:http://msdn.microsoft.com/en-us/library/ms633520(VS.85).aspx>
Eindeutiger geht es nicht mehr.
> das gilt f�r Szenarien *ohne* AttachThreadInput.
> Durch das erzeugte Sharing bei AttachThreadInput
> (siehe Doku dazu) k�nnen die Messages analog dem
> Focus weitergeleitet werden (was sonst nicht m�glich w�re).
> F�r den OP hier noch ein paar Implementations-Beispiele:
Wo ist das dokumentiert? Das st�nde im Widerspruch zur Dokumentation von
'GetWindowText'.
Thorsten Doerfler
Frank Dzaebel schrieb:
>> WM_GETTEXT message directly instead of calling GetWindowText."
>
> das gilt f�r Szenarien *ohne* AttachThreadInput.
Wenn das so w�re, w�re es dokumentiert.
Frank Dzaebel
>> das gilt f�r Szenarien *ohne* AttachThreadInput.
>> Durch das erzeugte Sharing bei AttachThreadInput
>> (siehe Doku dazu) k�nnen die Messages analog dem
>> Focus weitergeleitet werden (was sonst nicht m�glich w�re).
>> F�r den OP hier noch ein paar Implementations-Beispiele:
>
> Wo ist das dokumentiert? Das st�nde im Widerspruch zur Dokumentation von
> 'GetWindowText'.
Die Dokus (AttachThreadInput, GetWindowText) widersprechen
sich in keiner Weise. Durch die dokumentierte Bindung an den
externen Thread (das ist mehr als der Prozess) kann (bzgl. der
Doku GetWindowText) vom gleichen Prozess augegangen
werden, da ein Sharing stattfindet. Es wird exakt diese Thread-
MessageQueue zug�nglich, wodurch die Message (�brigens auch
aus Erfahrung) dann von GetWindowText sauber in diese Queue
gesendet und schliesslich abgearbeitet werden kann.
Ich mache jetzt mal bzgl. der API-Interpretaion ein EOT.
Wenn noch C# relevante Fragen kommen, gern.
Herfried K. Wagner [MVP]
Frank Dzaebel schrieb:
>>> das gilt f�r Szenarien *ohne* AttachThreadInput.
>>> Durch das erzeugte Sharing bei AttachThreadInput
>>> (siehe Doku dazu) k�nnen die Messages analog dem
>>> Focus weitergeleitet werden (was sonst nicht m�glich w�re).
>>> F�r den OP hier noch ein paar Implementations-Beispiele:
>>
>> Wo ist das dokumentiert? Das st�nde im Widerspruch zur Dokumentation
>> von 'GetWindowText'.
>
> Die Dokus (AttachThreadInput, GetWindowText) widersprechen
> sich in keiner Weise.
Nein, aber Du der Dokumentation!
> Durch die dokumentierte Bindung an den
> externen Thread (das ist mehr als der Prozess) kann (bzgl. der
> Doku GetWindowText) vom gleichen Prozess augegangen
> werden, da ein Sharing stattfindet. Es wird exakt diese Thread-
> MessageQueue zug�nglich, wodurch die Message (�brigens auch
> aus Erfahrung) dann von GetWindowText sauber in diese Queue
> gesendet und schliesslich abgearbeitet werden kann.
"�brigens auch aus Erfahrung" -- darauf w�rde ich mich nicht verlassen.
Das Zielfenster wird nicht automatisch zu einem Fenster des Prozesses,
der 'AttachThreadInput' aufgerufen hat, sondern bleibt ein Fenster des
anderen Prozesses.
Besonders stutzig sollte einen machen, da� Microsoft 'GetWindowText' so
dokumentiert, da� die Funktion nur bei Fenstern des Prozesses
funktioniert. Wenn 'GetWindowText' einfach nur 'SendMessage' +
'WM_GETTEXT' w�re -- einer L�sung, die sowohl im eigenen wie auch
anderen Prozessen funktioniert -- h�tte Microsoft sich den Hinweis, die
Funktion bei fremden Fenstern nicht zu verwenden, sparen k�nnen.
Herfried K. Wagner [MVP]
Stefan Simon schrieb:
> [DllImport("user32.dll")]
> public static extern int SendMessage(IntPtr hwnd, int wMsg, int
> wParam, byte[] lParam);
>
> int msg =
> GetWinFormsId.NativeMethods.RegisterWindowMessage("WM_GETCONTROLNAME");
> int size = 65536;
> byte[] buff = new byte[size];
> int retLength = GetWinFormsId.NativeMethods.SendMessage(hwnd, msg,
> size, buff);
> return System.Text.Encoding.UTF8.GetString(buff);
>
> probiert, leider bleibt buff leer ...
Bei benutzerdefinierten Fensternachrichten, wie "WM_GETCONTROLNAME" eine
ist, �bernimmt Windows nicht automatisch das Marshalling der Parameter.
Deshalb kann nicht einfach ein Puffer an 'SendMessage' �bergeben werden,
denn der Zeiger darauf weist auf den Speicherbereich des eigenen
Prozesses und nicht den des fremden Prozesses, aus dem die Daten
ausgelesen werden sollen. Deshalb kann Windows die Daten nicht
erfolgreich in den Puffer kopieren.
L�sung: Der Puffer mu� f�r die fremde Anwendung sichtbar sein.
Derartigen Speicher kann man �ber die Klasse
'System.InteropServices.Marshal' anfordern. Alternativ k�nntest Du den
Speicher des anderen Prozesses mit 'ReadProcessMemory' lesen.
Ein Beispiel in VB (VB6) findet sich in folgendem Artikel, dort wird
auch explizit auf die Thematik eingegangen:
Automatisieren von Windows Forms
<URL:http://msdn.microsoft.com/de-de/library/ms996405.aspx#ID0EZF>
Herfried K. Wagner [MVP]
> Ein Beispiel in VB (VB6) findet sich in folgendem Artikel [...]
Und hier in C#:
Brian McMaster's Blog on QA, .NET, and VS : Getting the WinForms ID of a
Control
<URL:http://blogs.msdn.com/brianmcm/archive/2006/01/17/getting-the-winforms-id-of-a-control.aspx>
Frank Dzaebel
(da jetzt EOT bzgl. der Doku-Interpretation)
Es gibt es weitere typische Dinge, warum ein direktes
SendMessage ggf. nicht funktionieren "kann" ist:
Ab Vista / Server 2008 / Windows 7 und sp�ter gilt die: UIPI
Anwendungen auf niedrigeren Berechtigungsstufen k�nnen grunds�tzlich keine
Mitteilungen an Anwendungen auf h�heren Berechtigungsstufen senden, sofern
die Anwendung der h�heren Berechtigungsstufe dies nicht ausdr�cklich durch
Aufruf von ChangeWindowMessageFilter() erlaubt. Gleicherma�en k�nnen
Anwendungen mit niedrigeren Berechtigungsstufen ein HWND einer Anwendung mit
einer h�heren Berechtigungsstufe zwar lesen, aber nicht modifizieren. Aus
Kompatibilit�tsgr�nden geben SendMessage und andere APIs eine Erfolgsmeldung
zur�ck, auch wenn die API aufgrund von Berechtigungsproblemen blockiert
wurde. Wenn die Kompatibilit�tsauswirkung hoch und das Sicherheitsrisiko
gering ist, d�rfen auch Anwendungen mit niedriger Berechtigungsstufe in
einigen F�llen unaufgefordert Meldungen an Anwendungen mit h�heren
Berechtigungsstufen senden.
[Windows Vista f�r Entwickler: Kochbuch zur Anwendungskompatibilit�t]
http://msdn.microsoft.com/de-de/library/aa480152.aspx#ID0EAWBG
[So werden in Windows Nachrichten versandt]
http://msdn.microsoft.com/de-de/library/bb979347.aspx
[SendMessage Function ()]
http://msdn.microsoft.com/en-us/library/ms644950.aspx
[User Interface Privilege Isolation - Wikipedia, the free encyclopedia]
http://en.wikipedia.org/wiki/User_Interface_Privilege_Isolation
_____________
Empfohlene Ma�nahmen sind u.a.:
� Use thread hooks to attach to a higher-privileged process
(siehe -> AttachThreadInput)
� Use journal hooks (SetWindowsHookEx) to monitor a higher-privileged
process
� Perform DLL injection to a higher-privileged process
Immo Landwerth
> Hallo Thorsten,
>
> > > GetWindowText sendet selber WM_GETTEXT und
> > > geht f�r Fentster und "Steuerelemente".
> >
> > Die Dokumentation zu GetWindowText [...]
>
> .. besagt:
> "GetWindowText causes a WM_GETTEXT message to be sent
> to the specified window or control."
Was Dur schreibst ist nicht ganz korrekt ist.
Raymond Chen hat das Verhalten und die Unterschiede zwischen
GetWindowText() und WM_GETTEXT hier deutlich beschrieben:
http://blogs.msdn.com/oldnewthing/archive/2003/08/21/54675.aspx
Relevanter Ausz�ge:
| * If you are trying to GetWindowText() from a window in your own
| process, then GetWindowText() will send the WM_GETTEXT message.
|
| * If you are trying to GetWindowText() from a window in another
| process, then GetWindowText() will use the string from the "special
| place" and not send a message.
[...]
| The documentation simplifies this as "GetWindowText() cannot retrieve
| text from a window from another application."
HTH
--
Immo Landwerth
Immo Landwerth
> Was Dur schreibst ist nicht ganz korrekt ist.
<yoda>
Nicht gut schreiben, ich kann.
</yoda>
--
Immo Landwerth
FrankDzaebel
> > > Die Dokumentation zu GetWindowText [...]
> > .. besagt:
> > "GetWindowText causes a WM_GETTEXT message to be sent
> > to the specified window or control."
>
> Was Dur schreibst ist nicht ganz korrekt ist.
Das schreibe nicht ich, sondern es steht in der Doku.
Ist für mich jetzt aber EOT.
ciao Frank
Immo Landwerth
> Hallo Immo,
>
> > > > Die Dokumentation zu GetWindowText [...]
> > > .. besagt:
> > > � � "GetWindowText causes a WM_GETTEXT message to be sent
> > > � � � to the specified window or control."
> >
> > Was Dur schreibst ist nicht ganz korrekt ist.
>
> Das schreibe nicht ich, sondern es steht in der Doku.
...es gibt das Konzept der unzul�ssigen K�rzung?
*If the target window is owned by the current process*
GetWindowText causes a WM_GETTEXT message to be sent to the specified
window or control.
*If the target window is owned by another process and has a caption,
GetWindowText retrieves the window caption text.*
> Ist f�r mich jetzt aber EOT.
Ja, es hat sich nicht viel ver�ndert hier...
== footnotes ==
--
Immo Landwerth
FrankDzaebel
> > > > > Die Dokumentation zu GetWindowText [...]
> > > > .. besagt:
> > > > "GetWindowText causes a WM_GETTEXT message to be sent
> > > > to the specified window or control."
>
> > > Was Dur schreibst ist nicht ganz korrekt ist.
>
> > Das schreibe nicht ich, sondern es steht in der Doku.
>
> ...es gibt das Konzept der unzulässigen Kürzung?
Das Quoting stammt von Dir.
Deine Aussage ist halt falsch.
> *If the target window is owned by the current process*
genau und das wurde hier lang breit diskutiert.
AttachThreadInput führt hier die Bindung
an den Prozess durch einen Thread Hook aus.
Thorsten Doerfler
Frank Dzaebel schrieb:
> Empfohlene Ma�nahmen sind u.a.:
>
> � Use thread hooks to attach to a higher-privileged process
> (siehe -> AttachThreadInput)
> � Use journal hooks (SetWindowsHookEx) to monitor a higher-privileged
> process
> � Perform DLL injection to a higher-privileged process
Wo wird das bitte empfohlen? Das was Du dort auflistest ist genau das,
was durch UIPI *nicht* m�glich ist.
The Windows Vista and Windows Server 2008 Developer Story: Windows Vista
Application Development Requirements for User Account Control (UAC)
http://msdn.microsoft.com/en-us/library/aa905330.aspx
Zitat:
"A lower privilege process cannot:
* Perform a window handle validation of higher process privilege.
* SendMessage or PostMessage to higher privilege application
windows. These Application Programming Interfaces (APIs) return
success but silently drop the window message.
* Use thread hooks to attach to a higher privilege process.
* Use Journal hooks to monitor a higher privilege process.
* Perform DLL injection to a higher privilege process."
Langsam werden Deine Postings schon gef�hrlich, wenn Du Aussagen derart
falsch widergibst.
FrankDzaebel
> > · Use thread hooks to attach to a higher-privileged process
> > (siehe -> AttachThreadInput)
> > · Use journal hooks (SetWindowsHookEx) to monitor a higher-privileged
> > process
> > · Perform DLL injection to a higher-privileged process
>
> Wo wird das bitte empfohlen?
meine Zusatz "empfohlen .." ist genau falsch herum.
Richtige Überschrift ist "A lower privilege process cannot",
wie Du es nachgegoogelt hast, danke.
Nichst desto trotz ändert das die eigentlich Aussage
nichts, dass ein direktes SendMessage ggf. nicht
funktionieren "kann".
Herfried K. Wagner [MVP]
>> *If the target window is owned by the current process*
>
> genau und das wurde hier lang breit diskutiert.
> an den Prozess durch einen Thread Hook aus.
Durch Wiederholung wird dieser Hinweis nicht weniger falsch/gef�hrlich.
Noch einmal: Es gibt in der Dokumentation zu 'GetWindowText',
'SendMessage' + 'WM_GETTEXT' und 'AttachThreadInput' keinen Widerspruch.
Lediglich Deine Sichtweise widerspricht der Dokumentation.
Frank Dzaebel
jetzt fangen hier Wiederholungs-Postings
von anderen an, die l�ngst EOT sind.
Kurz res�miert, meine Ansicht :
AttachThreadInput f�hrt hier die Bindung
an den Prozess durch einen Thread Hook aus.
und ist deshalb auch konform zur Dokumentation.
Das ist ebenfalls aus der Praxis best�tigt.
Deswegen ist GetWindowText hier m�glich
und f�r mich auch einfacher.
Ansicht anderer scheinbar: AttachThreadInput
kann nicht so interpretiert werden.
Die API-Interpretation ist f�r mich aber lange EOT
und wurde gen�gend oft wiederholt.
![Ulf [Kado] Kadner's profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWS0V3TJwJ-07-NWcLG9HZ4SMFbgzyAMxottO1QqD5V2n_1h37R=s40-c)
Ulf [Kado] Kadner
> jetzt fangen hier Wiederholungs-Postings
> von anderen an, die l�ngst EOT sind.
Ich wollts mir eigentlich verkneifen aber was solls:
Nein das sind sie nicht! Auch nicht wenn Du v�llig sinnfrei Theads in OT
o.�. umbenennst.
Da mir das hier und ausschlie�lich hier in der Gruppe bereits seit
l�ngeren auff�llt das Du dich manchmal v�llig daneben benimmst folgende
Bitte an Dich:
Reiss Dich zusammen und versuch nicht anderen das Wort verbieten zu
wollen. Wenn Du dazu nicht diskutieren willst schreib das einfach in der
Antwort und halt Dich dannach raus. Oder noch einfacher und wenigstens
Mediumsgerecht: Setzte das Follow-Up to Poster.
Das ist nicht b�se gemeint! Aber es w�r wirklich nett wenn Du mal nen
bischen zur�ck schalten w�rdest.
Fup2Poster gesetzt...
Danke, Ulf
Frank Dzaebel
>> jetzt fangen hier Wiederholungs-Postings
>> von anderen an, die l�ngst EOT sind.
>
> [...] Nein das sind sie nicht!
doch, ich hatte das seit langem angemerkt,
das die API Interpretation f�r "mich" EOT ist:
Zitat:
"Ich mache jetzt mal bzgl. der API-Interpretaion ein EOT.
Wenn noch C# relevante Fragen kommen, gern."
Das heisst nicht, dass andere da munter weiterdiskutieren
k�nnen, sondern nur f�r andere der Hinweis:
"ich werde an weiteren API-Interpretationen nicht
mehr beteiligen". Also ich meine "ich", nicht andere.
> Auch nicht wenn Du v�llig sinnfrei Theads in
> OT o.�. umbenennst.
Das sind mitunter Deine Threads, in denen
Du vollkommen absurde Privat-Gespr�che
f�hrst, das habe ich Dir schon oft gesagt, dass
Du dies bitte sein lassen sollt. Ich gehe mal nicht
ins Detail, ich denke jeder kennt hier bereits Deine
Privat-Chats ;-)
Aber ich mache Dich normal schon gar nicht
mehr darauf aufmerksam. Nur, wo wir hier OT
schon diskutieren und Du mich ansprichst..
Eigentlich kann man es der Netiquette entnehmen,
beim Thema zu bleiben.
Ich bennen den Thread auch nicht "um",
sondern schreibe nur in den Betreff OT, weil ich
denke, "meine" Aussage ist jetzt OT.
Du kannst, wenn Du meinst Deinen Betreff auch
wieder eintragen beim Posten.
> anderen das Wort verbieten zu wollen
also hier nicht. Das EOT war nur f�r "mich" gemeint,
als Info, dass ich meine Meinung zur API-Interpretation
gesagt habe und vorhabe nicht weiter dar�ber zu diskutieren.
Trotzdem kommen dann von gewissen Leuten immer
wieder Wiederholungs-Postings, sie h�tten Recht.
Daran beteilige ich mich nicht.
Ich habe nur mal bei einem Deiner Postings
(wo Du wieder mit deinen [Fu�n�gel-Fu�fetisch]
Spezialit�ten anfingst) angemerkt, die Diskussion
ggf. in eine andere Gruppe zu verlegen ;-)
> Follow-Up to Poster.
Das ist kein guter Stil von Dir, denn so bleibt
ein �ffentlich Posting unbeantwortet. Wenn Du
privat reden m�chtest, dann einfach privat anmailen.
Dann bleibt es normal auch privat.
Thorsten Doerfler
Frank Dzaebel schrieb:
> "Ich mache jetzt mal bzgl. der API-Interpretaion ein EOT.
> Wenn noch C# relevante Fragen kommen, gern."
> Das heisst nicht, dass andere da munter weiterdiskutieren
> k�nnen
Genau so kommt das auch r�ber.
Herfried K. Wagner [MVP]
Frank Dzaebel schrieb:
>>> jetzt fangen hier Wiederholungs-Postings
>>> von anderen an, die l�ngst EOT sind.
>>
>> [...] Nein das sind sie nicht!
>
> doch, ich hatte das seit langem angemerkt,
> das die API Interpretation f�r "mich" EOT ist:
> Zitat:
> "Ich mache jetzt mal bzgl. der API-Interpretaion ein EOT.
> Wenn noch C# relevante Fragen kommen, gern."
> Das heisst nicht, dass andere da munter weiterdiskutieren
> k�nnen, sondern nur f�r andere der Hinweis:
> "ich werde an weiteren API-Interpretationen nicht
> mehr beteiligen". Also ich meine "ich", nicht andere.
Weshalb h�ltst Du Dich dann nicht daran? Du darfst Dich nicht wundern,
da� auf Deine "OT"-Beitr�ge reagiert wird, wenn Du doch noch
themenrelevantes darin erw�hnst.
Ich finde diese �nderung des Betreffs irritierend. Wenn Du Dich einfach
ausklinkst, dann kannst Du das jederzeit innerhalb des Beitrags
schreiben, aber dazu braucht es keinen Betreffwechsel (der normalerweise
mit "<Neuer Betreff> (was: <Alter Betreff>)" als Betreff gekennzeichnet
wird.
>> Auch nicht wenn Du v�llig sinnfrei Theads in
>> OT o.�. umbenennst.
>
> Das sind mitunter Deine Threads, in denen
> Du vollkommen absurde Privat-Gespr�che
> f�hrst, das habe ich Dir schon oft gesagt, dass
> Du dies bitte sein lassen sollt. Ich gehe mal nicht
> ins Detail, ich denke jeder kennt hier bereits Deine
> Privat-Chats ;-)
Wenn es Dich so st�rt, dann regle das �ber Deine Filter. Die Newsgroup
w�re todlangweilig, w�rde nicht ab und zu auch etwas �ber den Tellerrand
hinaus diskutiert.
>> anderen das Wort verbieten zu wollen
>
> also hier nicht. Das EOT war nur f�r "mich" gemeint,
> als Info, dass ich meine Meinung zur API-Interpretation
> gesagt habe und vorhabe nicht weiter dar�ber zu diskutieren.
> Trotzdem kommen dann von gewissen Leuten immer
> wieder Wiederholungs-Postings, sie h�tten Recht.
Deine Beitr�ge wirken f�r Au�enstehende, als wolltest Du
Newsgrouppolizist spielen. Newsgroups leben gerade dadurch, da� sie ohne
Moderation auskommen. Deshalb scheiterst Du auch regelm��ig mit Deinen
Moderationsversuchen. Ich lese zahlreiche Newsgroups mit und derartige
Eingriffsversuche sind mir in den letzten 7 Jahren nur sehr selten begegnet.
Ulf [Kado] Kadner
>> Auch nicht wenn Du v�llig sinnfrei Theads in
>> OT o.�. umbenennst.
>
> Das sind mitunter Deine Threads, in denen
> Du vollkommen absurde Privat-Gespr�che
> f�hrst
Es ging nicht um mich es ging um Dich! Bitte lenke nicht von Thema ab.
> das habe ich Dir schon oft gesagt, dass
> Du dies bitte sein lassen sollt.
Und ich habe Dir im letzten Posting gesagt das Du mir oder anderen bitte
nicht den Mund verbieten sollst. Aber nach Deiner obigen Antwort tust Du
das ja nicht. Dann is ja alles gut oder?
> Ich gehe mal nicht
> ins Detail, ich denke jeder kennt hier bereits Deine
> Privat-Chats ;-)
Sorry aber auf Deine Sticheleien geh ich nicht ein. Das kannste bei
anderen probieren.
> schon diskutieren und Du mich ansprichst..
> Eigentlich kann man es der Netiquette entnehmen,
> beim Thema zu bleiben.
Ja dann entnimm doch bitte auch gleich der Netiquette das man einen
Wunsch eines anderen Nutzers des Mediums auch entsprechen sollte. Nun
magst Du mir vieleicht sagen warum Du mein Fup2Poster nicht beachtest
hast? Von Dieser Unterhaltung sollte ja schlie�lich nach Deiner eben
festgelegten Definition, da "Privatchat", nicht diese Gruppe
frequentiert werden.
> Ich bennen den Thread auch nicht "um",
> sondern schreibe nur in den Betreff OT, weil ich
> denke, "meine" Aussage ist jetzt OT.
Aha...
> Du kannst, wenn Du meinst Deinen Betreff auch
> wieder eintragen beim Posten.
Nein es w�r nett wenn Du das unterlassen w�rdest, dann m�ste sich kein
anderer die Arbeit des erneuten umbenennens machen! Und lies Dir bei der
Gelegenheit gleich mal durch wie man korrekt Betreffzeilen �ndert:
[Titel�nderungen im Usenet (Subject-Wechsel)}
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/usenet_subjectwechsel_de
> also hier nicht. Das EOT war nur f�r "mich" gemeint,
Und warum wiederholst Das das st�ndig wenn darauf einer antwortet, und
das auch nocht an dich selbst? Ne sorry, aber das sind alles nur plumpe
Ausreden.
> Ich habe nur mal bei einem Deiner Postings
> (wo Du wieder mit deinen [Fu�n�gel-Fu�fetisch]
> Spezialit�ten anfingst) angemerkt, die Diskussion
> ggf. in eine andere Gruppe zu verlegen
OK jetzt haste mich. Das war Spass das mit dem Fu�fetisch. Aber das
scheinst Du ja nicht zu kennen. Erspar mir bitte Deine Antwort darauf.
>> Follow-Up to Poster.
>
> Das ist kein guter Stil von Dir
Es ist kein guter Stil einen Wunsch zu �u�ern? Geh bitte und versuche
anderen Deine Spielchen aufzudr�cken. Ich dachte ich kann Dir helfen zu
erkennen das auch Du nicht fehlerfrei hier rumeierst das aber st�ndig
von anderen verlangst. Hat scheinbar keinen Sinn!
Frank Dzaebel
>> Das sind mitunter Deine Threads [Ulf], in denen
>> Du vollkommen absurde Privat-Gespr�che
>> f�hrst
>
> Es ging nicht um mich es ging um Dich!
Das meine ich aber so Ulf.
Ich denke, solche Fu�pilz- und F��n�gel-
Ges�lze geh�rt nicht in technische Newsgroups.
Ich weise Dich dann ja auch nur sehr milde
darauf hin, dies nicht zu tun.
>> Ich gehe mal nicht
>> ins Detail, ich denke jeder kennt hier bereits Deine
>> Privat-Chats ;-)
>
> Sorry aber auf Deine Sticheleien geh ich nicht ein.
Gerne auch Links dazu, wenn Du das nicht zugeben
willst:
http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/d9de2d942f7d1312
> einen Wunsch eines anderen Nutzers des Mediums auch entsprechen sollte.
Mein Wunsch w�re es, private Postings nicht
in technischen Gruppen zu stellen, sondern
in privaten Mails. Ich hoffe Du entsprichst diesen.
>> Ich bennen den Thread auch nicht "um",
>> sondern schreibe nur in den Betreff OT, weil ich
>> denke, "meine" Aussage ist jetzt OT.
>
> Aha...
ja, im Prinzip, das was ich eintrage.
Es korrelliert nat�rlich sehr oft damit, dass bereits
der Vorposter OffTopic war.
Ich setze OT gern auch auch ein, um (wie etwa bei
Deinen Postings) darauf aufmerksam zu machen,
dass hier ein technische Newsgroup ist und hier
die technische Nettiquette gilt.
Nochmals speziell f�r Dich Ulf die hier g�ltige Nettiquette:
[Newsgroup - Netikette]
http://support.microsoft.com/?scid=fh;DE;NGNetikette
"Bleiben Sie beim Thema der Newsgroup
Die User m�chten in einer Newsgroup nur Postings zum
jeweiligen Thema sehen, weil sonst schnell der �berblick
verloren geht."
>>> Follow-Up to Poster.
>>
>> Das ist kein guter Stil von Dir
>
> Es ist kein guter Stil einen Wunsch zu �u�ern?
Es ist kein guter Stil, wenn Du eigentlich privat
angesprochen werden m�chtest, erstmal den
anderen �ffentlich zu beleidigen und dann
zu erwarten, dass dieser nicht mehr �ffentlich
dazu Stellung nimmt. Deswegen ist es
normal bei ernst gemeinten privaten Korrespondenz-
W�nschen diese Dinge auch selber privat zu mailen.
So nehme ich nat�rlich auch dazu Stellung.
Ulf [Kado] Kadner
>> Es ging nicht um mich es ging um Dich!
>
> Das meine ich aber so Ulf.
> Ich denke, solche Fu�pilz- und F��n�gel-
> Ges�lze geh�rt nicht in technische Newsgroups.
> Ich weise Dich dann ja auch nur sehr milde
> darauf hin, dies nicht zu tun.
Was f�r ein feiner Mensch Du bist wa? Gehts nocht?
>>> Ich gehe mal nicht
>>> ins Detail, ich denke jeder kennt hier bereits Deine
>>> Privat-Chats ;-)
>>
>> Sorry aber auf Deine Sticheleien geh ich nicht ein.
>
> Gerne auch Links dazu, wenn Du das nicht zugeben
> willst:
> http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/d9de2d942f7d1312
Dazu hab ich bereits was gesagt wozu Du leider nicht in der Lage warst
zu anworten. Wird zeit das Du aus dem Kindergarten kommst.
Frank Dzaebel
Ich denke, die Meinungen zu OffTopic, Fup2Poster,
Netiquette und privaten Chats sind gesagt und ich
merke, dass Du das auch bi�chen verstehst.
Eine guten Anhaltspunkt liefert immer die hier g�ltige
Netiquette - kann man ruhig zum Abschluss noch mal
verlinken:
[Newsgroup - Netikette]
http://support.microsoft.com/?scid=fh;DE;NGNetikette
Dann h�nge ich mal zum Abschluss mein Fazit-Posting
von vorhin wieder an:
________________
Kurz res�miert, meine Ansicht :
AttachThreadInput f�hrt hier die Bindung
an den Prozess durch einen Thread Hook aus.
und ist deshalb auch konform zur Dokumentation.
Das ist ebenfalls aus der Praxis best�tigt.
Deswegen ist GetWindowText hier m�glich
und f�r mich auch einfacher.
Ansicht anderer scheinbar: AttachThreadInput
kann nicht so interpretiert werden.
Die API-Interpretation ist f�r mich aber lange EOT
und wurde gen�gend oft wiederholt.
Herfried K. Wagner [MVP]
> Ich denke, die Meinungen zu OffTopic, Fup2Poster,
> Netiquette und privaten Chats sind gesagt und ich
> merke, dass Du das auch bi�chen verstehst.
In diesem Ton spricht man mit Kindern.
> Eine guten Anhaltspunkt liefert immer die hier g�ltige
> Netiquette - kann man ruhig zum Abschluss noch mal
> verlinken:
Abschlu�?
> Dann h�nge ich mal zum Abschluss mein Fazit-Posting
> von vorhin wieder an:
Abschlu�?
Hier schlie�t niemand eine Diskussion ab.
> Ansicht anderer scheinbar: AttachThreadInput
> kann nicht so interpretiert werden.
> Die API-Interpretation ist f�r mich aber lange EOT
> und wurde gen�gend oft wiederholt.
Dennoch ist sie die richtige Interpretation. Es k�nnte Dir doch zu denken
geben, wenn Du eine Meinung vertrittst, die sonst niemand teilt und die auch
nicht von der Dokumentation gedeckt ist.
FrankDzaebel
Kurz resümiert, meine Ansicht :
AttachThreadInput führt hier die Bindung
an den Prozess durch einen Thread Hook aus.
und ist deshalb auch konform zur Dokumentation.
Das ist ebenfalls aus der Praxis bestätigt.
Deswegen ist GetWindowText hier möglich
und für mich auch einfacher.
Ansicht anderer scheinbar: AttachThreadInput
kann nicht so interpretiert werden.
Die API-Interpretation ist für mich aber lange EOT
und wurde genügend oft wiederholt.
Jochen Kalmbach [MVP]
> Kurz res�miert, meine Ansicht :
> AttachThreadInput f�hrt hier die Bindung
> an den Prozess durch einen Thread Hook aus.
> und ist deshalb auch konform zur Dokumentation.
> Das ist ebenfalls aus der Praxis best�tigt.
> Deswegen ist GetWindowText hier m�glich
> und f�r mich auch einfacher.
Es ist sinnlos... hast Du es probiert?
Poste bitte Deine beiden Beispielprojete, wo es sich so verh�lt... meine
hast Du ja schon bekommen, wo es sich nicht so verh�lt...
Vielleicht ist mein Beispiel ja falsch...
Soviel Ignoranz hab ich selten erlebt...
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
FrankDzaebel
> hast Du es probiert?
ja klar, das wurde hier doch mehrfach erwähnt.
Der Code wurde hier bereits gepostet.
Du musst dann nur irgendeinen externen Prozess
von ausserhalb automatisieren sprich die
Handles der entsprechenden Controls einsetzen.
Das funktioniert mit GetWindowText mit
AttachThreadInput ohne Probleme in den
Applikationen.
> meine hast Du ja schon bekommen,
? ich habe keine von Dir.
ciao Frank
Jochen Kalmbach [MVP]
>> hast Du es probiert?
>
> ja klar, das wurde hier doch mehrfach erw�hnt.
> Der Code wurde hier bereits gepostet.
Es w�re sch�n, wenn Du zwei Projekte posten k�nntest, denn nur dan kann
man wirklich nachvollziehen, was Du meinst.
> Du musst dann nur irgendeinen externen Prozess
> von ausserhalb automatisieren sprich die
> Handles der entsprechenden Controls einsetzen.
Mit _irgendeinem_externen Prozess geht das ja wohl nicht, da dieser
Prozess eben *selber* das WM_GETTEXT verarbeiten muss! SOnst geht
nat�rlich GetWindowText *immer*, da es ja auf den _internen_ Puffer
zugreift, der dann immer stimmt.
> Das funktioniert mit GetWindowText mit
> AttachThreadInput ohne Probleme in den
> Applikationen.
Tut es eben nicht.
Oder Du redest die ganze Zeit von was anderem alls alle anderen...
>> meine hast Du ja schon bekommen,
>
> ? ich habe keine von Dir.
Wenn Du mein Posting erstes Posting hier anschaust und den Anhang
nimmst, dann hast Du beide Projekte...
Ich kann es Dir auch noch im Detail erkl�ren, was da passiert und Dir
somit zeigen, warum Deine Aussage falsch ist.
Also:
Das Projekt "TargetApp" ist das Projekt, von welchem durch das Projekt
"SpyApp" der Text via "getWindowText" abgefragt werden soll.
Und damit man auch beweisen kann, dass die GetWindowText Methode nicht
geht, behandelt das TargetApp die "WM_GETTEXT" Nachricht selber und gibt
einen anderen text zur�ck als bei CreateWindow angelegt wurde.
lt. Doku m�sste jetzt ein *lokaler* Aufruf der Funktion GetWindowText
das *korekte* ergebnis liefern, n�mlich den selbst verarbeiteten Text.
DIes kannst Du nachpr�fen, indem Du "Info|About" ausw�hlst, dan wird in
einer MessageBox dieser Text angezeigt (n�mlich "Booga!").
W�hrend dieses Programm l�uft, starte des zweite "SpyApp". Rufe dort
ebenfalls "info|About" auf.
Dies macht jetzt das was Du machen willst:
1. Es ermittelt zuerst mal das Zielfenster (via FindWindow mit dem
Classname "TARGETAPP", welcher dort so registriert wurde)
2. Es ermittelt die ThreadIDs des lokalen Threads und des RemoteThreads
3. Es ruft AttachThreadInput auf und zeigt in einer MessageBox an, ob
dies erfolgreich war
4. Es liest den Text via GetWindowText des Remote-Fensters aus
5. Es zeigt diesen Text an
6. Jetzt darfst Du raten was angezeigt wird; soviel verrate ich:
"Booga!" ist es *nicht*!
q.e.d.
FrankDzaebel
> >> hast Du es probiert?
>
> > ja klar, das wurde hier doch mehrfach erwähnt.
> > Der Code wurde hier bereits gepostet.
>
> Es wäre schön, wenn Du zwei Projekte posten könntest,
wie ich diese Späteinsteiger liebe, denen man alles
noch mal von vorne erklären muss.
Schau Dir den Code des OPs an,
das ist in der Essenz der Code. Jetzt
gibst Du einfach an der Stelle, wo er GetClassName
macht Dein GetWindowText(...) mit der
entsprechenden Deklaration und den Handle des
Controls des externen Prozesses an und schwupp
wird Dir der richtige Text geliefert, (jedenfalls dann,
wenn Dir auch SendMessage den Text liefert).
Ich teste meine Aussagen hier vorher immer
aufs genaueste.
> > Du musst dann nur irgendeinen externen Prozess
> > von ausserhalb automatisieren sprich die
> > Handles der entsprechenden Controls einsetzen.
>
> Mit _irgendeinem_externen Prozess geht das ja wohl nicht,
> Prozess eben *selber* das WM_GETTEXT verarbeiten muss!
> natürlich GetWindowText *immer*, da es ja auf den _internen_ Puffer
> zugreift, der dann immer stimmt.
Hieraus lese ich aber, dass Du das noch
wirklich nicht verstanden hast SCNR.
Du bekommst den Text des Controls der
externen App. Die Auswahl des Prozesses ist -
wie bereits mehrfach erklärt von Dingen wie
UIPI etc. begrenzt.
> > Das funktioniert mit GetWindowText mit
> > AttachThreadInput ohne Probleme in den
> > Applikationen.
>
> Tut es eben nicht.
> Oder Du redest die ganze Zeit von was anderem
> alls alle anderen...
Stefan, es steht hier vielfach wovon ich rede.
Es ist GetWindowText bei vorherigem
AttachThreadInput. Und es tut!
> Wenn Du mein Posting erstes Posting hier anschaust
> und den Anhang nimmst,
habe keinen Anhang hier, sorry. Wir sind im UseNet
Stefan, Zugriff über Web. Man postet hier normal keine Anhänge.
> Und damit man auch beweisen kann,
> dass die GetWindowText Methode nicht
> geht
vermutlich hast Du AttachThreadInput nicht
mit drin, prüfe das mal (ich kann es hier nicht beurteilen).
Herfried K. Wagner [MVP]
>> >> hast Du es probiert?
>>
>> > ja klar, das wurde hier doch mehrfach erw�hnt.
>> > Der Code wurde hier bereits gepostet.
>>
>
>wie ich diese Sp�teinsteiger liebe, denen man alles
>noch mal von vorne erkl�ren muss.
Spar Dir den �berheblichen Ton. Im Gegensatz zu Dir hat Jochen immerhin
Beispielprojekte erstellt, anhand derer Deine These �berpr�ft werden kann.
>Schau Dir den Code des OPs an,
>das ist in der Essenz der Code. Jetzt
>gibst Du einfach an der Stelle, wo er GetClassName
>macht Dein GetWindowText(...) mit der
>entsprechenden Deklaration und den Handle des
>Controls des externen Prozesses an und schwupp
>wird Dir der richtige Text geliefert, (jedenfalls dann,
>wenn Dir auch SendMessage den Text liefert).
Sieh Dir doch bitte das Beispiel von Jochen an. Er hat genau die von Dir als
funktionierend bezeichnete Vorgangsweise gew�hlt und mit dem Beispiel
gezeigt, da� sie nicht funktioniert:
\\\
DWORD tid = GetWindowThreadProcessId(remotehwnd, &pid);
DWORD mytid = GetCurrentThreadId();
BOOL bRet = AttachThreadInput(mytid, tid, TRUE);
if (bRet)
MessageBox(hWnd, _T("AttachThreadInput called sucessfully"), _T(""),
MB_OK);
TCHAR sz[100];
GetWindowText(remotehwnd, sz, 100);
MessageBox(hWnd, sz, _T(""), MB_OK);
///
>Ich teste meine Aussagen hier vorher immer
>aufs genaueste.
Deine Aussage bzgl. 'AttachThreadInput' und 'GetWindowText' ist aber
offensichtlich falsch. Das versuchen Dir hier schon in einigen Beitr�gen
mehrere zu sagen -- sogar mit Beispiel, anhand dessen dies nachvollziehbar
ist.
> > Du musst dann nur irgendeinen externen Prozess
> > von ausserhalb automatisieren sprich die
> > Handles der entsprechenden Controls einsetzen.
>
> Mit _irgendeinem_externen Prozess geht das ja wohl nicht,
> Prozess eben *selber* das WM_GETTEXT verarbeiten muss!
> nat�rlich GetWindowText *immer*, da es ja auf den _internen_ Puffer
> zugreift, der dann immer stimmt.
Der Satz ist nicht Deutsch und sein Sinn nicht feststellbar.
>Du bekommst den Text des Controls der
>externen App.
Eben nicht.
>Die Auswahl des Prozesses ist -
>wie bereits mehrfach erkl�rt von Dingen wie
>UIPI etc. begrenzt.
Das tut in dem Fall nichts zur Sache und ist ein g�nzlich anderes Thema.
>Stefan, es steht hier vielfach wovon ich rede.
Stefan? Jochen.
>Es ist GetWindowText bei vorherigem
>AttachThreadInput. Und es tut!
Und diese Aussage ist falsch und gef�hrlich.
>> Wenn Du mein Posting erstes Posting hier anschaust
>> und den Anhang nimmst,
>
>habe keinen Anhang hier, sorry. Wir sind im UseNet
>Stefan, Zugriff �ber Web. Man postet hier normal keine Anh�nge.
Stefan? Jochen.
>> Und damit man auch beweisen kann,
>> dass die GetWindowText Methode nicht
>> geht
>
>vermutlich hast Du AttachThreadInput nicht
>mit drin, pr�fe das mal (ich kann es hier nicht beurteilen).
Doch (siehe Codeausschnitt oben). F�r wie naiv h�ltst Du Jochen (nicht
Stefan) eigentlich?
Jochen Kalmbach [MVP]
> Stefan, es steht hier vielfach wovon ich rede.
> Es ist GetWindowText bei vorherigem
> AttachThreadInput. Und es tut!
Fritz: F�r mich hat es sich erledigt.
FrankDzaebel
> > Stefan, es steht hier vielfach wovon ich rede.
> > Es ist GetWindowText bei vorherigem
> > AttachThreadInput. Und es tut!
>
> Fritz: Für mich hat es sich erledigt.
ok, dann hast Du das also wahrscheinlich
reproduzieren können, dass es mit GetWindowText
funktioniert. Bei mir läuft es ja auch.
BTW: Der Namens-Tauscher "Stefan" war
keine Absicht, sorry, hatte Dich ja auch
mit "Hallo Jochen" angesprochen.
Herfried K. Wagner [MVP]
"FrankDzaebel" <po...@franksseite.de> schrieb:
>> > Stefan, es steht hier vielfach wovon ich rede.
>> > Es ist GetWindowText bei vorherigem
>> > AttachThreadInput. Und es tut!
>>
>> Fritz: F�r mich hat es sich erledigt.
>
>ok, dann hast Du das also wahrscheinlich
>reproduzieren k�nnen, dass es mit GetWindowText
>funktioniert. Bei mir l�uft es ja auch.
Es funktioniert nicht. 'AttachThreadInput' + 'GetWindowText' mit dem Fenster
im anderen Proze� liefert ein anderes Ergebnis als 'SendMessage' +
'WM_GETTEXT'. Letzteres liefert das erwartete Ergebnis:
\\\
BOOL bRet = AttachThreadInput(mytid, tid, TRUE);
if (bRet)
MessageBox(hWnd, _T("AttachThreadInput called sucessfully"), _T(""),
MB_OK);
TCHAR sz[100];
GetWindowText(remotehwnd, sz, 100);
MessageBox(hWnd, sz, _T(""), MB_OK);
///
... liefert "TargetApp". Folgender Code hingegen (nur schnell
hingeschrieben) f�hrt zum richtigen Ergebnis:
\\\
TCHAR sz[100];
SendMessage(remotehwnd, WM_GETTEXT, 100, (LPARAM)sz);
MessageBox(hWnd, sz, _T(""), MB_OK);
///
... liefert "Booga!", auch �ber Proze�grenzen hinweg. "Booga!" ist der Wert,
der von TargetApp bei 'WM_GETTEXT' zur�ckgegeben wird.
Deine Aussage "GetWindowText sendet selber WM_GETTEXT und geht f�r Fentster
und "Steuerelemente" gilt daher nur (wie auch in der Dokumentation
beschrieben) innerhalb des Prozesses, nicht aber f�r andere Prozesse (selbst
dann nicht, wenn zuvor 'AttachThreadInput' erfolgreich aufgerufen wird).
Hingegen funktioniert 'SendMessage' + 'WM_GETTEXT' auch problemlos mit
Fenstern in anderen Prozessen.
Bevor Du jetzt wieder die gleiche falsche Antwort wiederholst: Teste das
Beispielprojekt, Du wirst nachvollziehen k�nnen, was ich oben extra noch
einmal ausf�hrlich beschrieben habe.
Jochen Kalmbach [MVP]
> ... liefert "Booga!", auch �ber Proze�grenzen hinweg. "Booga!" ist der
> Wert, der von TargetApp bei 'WM_GETTEXT' zur�ckgegeben wird.
>
> Deine Aussage "GetWindowText sendet selber WM_GETTEXT und geht f�r
> Fentster und "Steuerelemente" gilt daher nur (wie auch in der
> Dokumentation beschrieben) innerhalb des Prozesses, nicht aber f�r
> andere Prozesse (selbst dann nicht, wenn zuvor 'AttachThreadInput'
> erfolgreich aufgerufen wird). Hingegen funktioniert 'SendMessage' +
> 'WM_GETTEXT' auch problemlos mit Fenstern in anderen Prozessen.
Es ist sinnloss... Frank wird *nie* einen Fehler eingestehen... deswegen
hat es auch keinen Sinn, sich dar�ber aufzuregen.
ich wollte es nur beweisen, nicht damit ein anderer Poster denkt, es
w�re richtig, nur weil Frank es sagt...
Frank Dzaebel
deswegen kann ich dazu nichts sagen.
Hier nochmal das Projekt, mit dem ich die
Tests auf Vista *erfolgreich* durchgef�hrt habe,
da es angefragt wurde:
[DllImport("user32.dll", SetLastError = true)]
static extern uint GetWindowThreadProcessId(
IntPtr hWnd, out uint lpdwProcessId);
[DllImport("user32.dll")]
static extern IntPtr GetForegroundWindow();
[DllImport("user32.dll", SetLastError = true)]
static extern bool AttachThreadInput(uint idAttach,
uint idAttachTo, bool fAttach);
[DllImport("user32.dll")]
static extern IntPtr GetFocus();
private void Form1_Load(object sender, EventArgs e)
{
}
int maxSB = 0xff;
uint winProcessId;
/// <summary>Control Handle.. z.B. mit Spy++ von externem Prozess</summary>
IntPtr handle = new IntPtr(0x014B0396);
/// <summary>Window Handle des externen Prozesses</summary>
IntPtr foreGroundHandle = new IntPtr(0x0210096E);
void GetText(int capability, IntPtr handle, ref StringBuilder sb)
{
sb = new StringBuilder(capability);
int retVal = SendMessage(handle, WM_GETTEXT, new IntPtr(capability), sb);
}
[DllImport("user32.dll", CharSet = CharSet.Auto)]
static extern int SendMessage(IntPtr hWnd, int msg,
IntPtr wParam, StringBuilder lParam);
public const int WM_GETTEXT = 0x000D;
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
static extern int GetWindowText(IntPtr hWnd, StringBuilder lpString, int
nMaxCount);
[DllImport("user32.dll")]
public static extern bool SetForegroundWindow(IntPtr hWnd);
private void button1_Click(object sender, EventArgs e)
{
uint idAttach;
SetForegroundWindow(foreGroundHandle);
IntPtr foreWindow = GetForegroundWindow();
IntPtr pt = base.Handle;
if (pt == foreWindow) return;
GetWindowThreadProcessId(foreWindow, out winProcessId);
GetWindowThreadProcessId(base.Handle, out idAttach);
if (AttachThreadInput(idAttach, winProcessId, true))
{
IntPtr focus = GetFocus();
if (focus != IntPtr.Zero)
{
Control ctrl = Control.FromHandle(focus);
if (ctrl != null)
{
this.Text = ctrl.Name;
}
else
{
StringBuilder lpClassName = new StringBuilder(maxSB);
// GetClassName(focus, lpClassName, maxSB); //Ursprung
// GetText(maxSB, handle, ref lpClassName); //SendMessage
GetWindowText(handle, lpClassName, maxSB); //GetWindowText
this.Text = lpClassName.ToString();
}
}
AttachThreadInput(idAttach, winProcessId, false);
}
}
[DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto)]
static extern int GetWindowTextLength(IntPtr hWnd);
public string GetText(IntPtr hWnd)
{
int length = GetWindowTextLength(hWnd);
StringBuilder sb = new StringBuilder(length + 1);
GetWindowText(hWnd, sb, sb.Capacity);
return sb.ToString();
Jochen Kalmbach [MVP]
> /// <summary>Control Handle.. z.B. mit Spy++ von externem Prozess</summary>
> IntPtr handle = new IntPtr(0x014B0396);
Und wie sieht der externe Prozess aus?
Der *muss* WM_GETTEXT selbst verarbeiten, sonst bringen Deine ganzen
Tests nichts... (oder Du hast das Problem nicht verstanden).
Mein Code in ausz�gen (die anderen k�nnen sich ja den Anhang anschauen):
TargetApp:
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM
lParam)
{
int wmId, wmEvent;
PAINTSTRUCT ps;
HDC hdc;
switch (message)
{
case WM_COMMAND:
wmId = LOWORD(wParam);
wmEvent = HIWORD(wParam);
// Parse the menu selections:
switch (wmId)
{
case IDM_ABOUT:
{
TCHAR sz[100];
GetWindowText(hWnd, sz, 100);
MessageBox(hWnd, sz, _T(""), MB_OK);
}
break;
case IDM_EXIT:
}
break;
case WM_GETTEXT:
lstrcpyn((LPTSTR)lParam, _T("Booga!"), (int)wParam);
return lstrlen((LPTSTR)lParam);
case WM_GETTEXTLENGTH:
return 7; // lstrlen(_T("Booga!")) + null
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}
SpyApp:
HWND remotehwnd = FindWindow(_T("TARGETAPP"), NULL);
if (remotehwnd != NULL)
{
DWORD pid;
DWORD tid = GetWindowThreadProcessId(remotehwnd, &pid);
DWORD mytid = GetCurrentThreadId();
BOOL bRet = AttachThreadInput(mytid, tid, TRUE);
if (bRet)
MessageBox(hWnd, _T("AttachThreadInput called
sucessfully"), _T(""), MB_OK);
TCHAR sz[100];
GetWindowText(remotehwnd, sz, 100);
MessageBox(hWnd, sz, _T(""), MB_OK);
}
Getestet unter XP-SP3 / Vista SP1
Frank Dzaebel
> Und wie sieht der externe Prozess aus?
beliebig. Ich habe mal ne externe WinForms-App
benutzt mit einem normalen TextBox-Control.
Der Prozess muss nur eine MessageQueue haben
(s.Doku) und die hier mehrfach beschrieben Einschr�nkungen
(UIPI) etc. gen�gen (was aber ebenfalls bei SendMessage
Bedingung ist).
> [C++] Getestet unter XP-SP3 / Vista SP1
ok, bei mir [C#] bisher nur Vista, teste das mal heute
abend auch unter XP, es ist aber nicht zu erwarten, dass
das Ergebnis nicht ebenso erfolgreich ist. Vista ist
diesbzgl. eher strenger. Ich versuche auch mal, ob ich
Deinen (jetzt endlich geposteten) Quellcode irgendwie
zum Laufen bringen kann. Ansich d�rften hier
unmanaged / managed keine Unterschiede sein.
Danke f�r Dein Quellcode.
Jochen Kalmbach [MVP]
>> Und wie sieht der externe Prozess aus?
>
> beliebig. Ich habe mal ne externe WinForms-App
> benutzt mit einem normalen TextBox-Control.
Ich glaube Du hast das Problem nicht verstanden...
Damit Dein Test funktioniert, musst Du *sicherstellen* das das Fenster
das WM_GETTEXT *selbst* behandelt!..
> Ich versuche auch mal, ob ich
> Deinen (jetzt endlich geposteten) Quellcode irgendwie
> zum Laufen bringen kann.
Wenn Du Deinen Newsreader bedienen kannst, sollte das ja kein Problem
sein... einfach die ZIP-Datei entpacken und die beiden Projekte
�bersetzen und starten... so schwierig wird das ja nicht sein, oder?
N�tigenfalls kann ich sie Dir auch zumailen...
FrankDzaebel
> das das Fenster das WM_GETTEXT *selbst* behandelt!..
Ich glaube Jochen, Du hast mein(e) Posting(s) nicht gelesen.
Wenn ein Prozess ne MessageQueue hat, behandelt
er "normal" WM_GETMESSAGE *selber*.
Windows Forms Anwendungen haben eine ganz
normale MessageQueue und diese wird - wie bereits
mehrfach erwähnt - benutzt.
> Wenn Du Deinen Newsreader bedienen kannst,
Kannst Du vielleicht mal der gängigen Praxis nachkommen
nicht Anhänge ins Usenet zu posten.
Lass Dir ggf. von anderen MVPs erklären, den
Grund kannst Du Dir wohl langsam vorstellen.
> Nötigenfalls kann ich sie Dir auch zumailen...
sehr gerne. Ich stelle diese Dinge normal
online in meinen Artikeln, so hat jeder Zugriff.
Das ist für die Community besser.
Jochen Kalmbach [MVP]
schrieb:
> sehr gerne. Ich stelle diese Dinge normal
> online in meinen Artikeln, so hat jeder Zugriff.
> Das ist f�r die Community besser.
Ich mach ja alles f�r Dich...
http://blog.kalmbach-software.de/de/2009/10/09/getwindowtext-und-wm_gettext/
FrankDzaebel
> Ich mach ja alles für Dich...http://blog.kalmbach-software.de/de/2009/10/09/getwindowtext-und-wm_g...
nur zur Info, das, was in Deinem Artikel-Titel steht, ist hier nicht
strittig.
Wann SendMessage und wann GetWindowText
benutzt wird steht bereits in der Doku (ist hier mehrfach
erwähnt). Es geht hier darum, inwieweit ein Thread Hook die
von der Doku geforderte Prozess-Bindung herstellen kann.
Ich werde Deine Quellcode prüfen und schauen welche
Unterschiede zu meinem C# Code bestehen, der ja funktioniert.
Jochen Kalmbach [MVP]
>> Ich mach ja alles f�r Dich...http://blog.kalmbach-software.de/de/2009/10/09/getwindowtext-und-wm_g...
>
> Es geht hier darum, inwieweit ein Thread Hook die
> von der Doku geforderte Prozess-Bindung herstellen kann.
> Ich werde Deine Quellcode pr�fen und schauen welche
> Unterschiede zu meinem C# Code bestehen, der ja funktioniert.
Ja, genau... Du kannst gerne mein TargetApp nehmen um es mit Deiner
C#-App zu testen... der einfachheit halber hab ich das WM_GETTEXT in dem
Hauptzfenster implementiert... also musst Du einfach das hWnd des
Hauptfensters nehmen...
Greetings
Jochen
FrankDzaebel
Artikel sagst, AttachThreadInput wäre überflüssig.
Das ist definitiv (für unseren Thread hier) nicht so.
Hier in diesem Thread benutzen wir GotFocus
(das machst Du in Deinem Code nicht).
Dazu ist AttachThreadInput *unbedingt* notwendig
und das fehlt auch in Deinem Code.
Dies aber nur nebenei, weil es einem sofort ins Auge fällt.
> C#-App zu testen...
> der einfachheit halber hab ich das WM_GETTEXT in dem
> Hauptzfenster implementiert... also musst Du einfach das hWnd des
> Hauptfensters nehmen...
wie gesagt, für meinen Code ist es relativ egal welcher
externe Prozess das ist. Man muss es da auch nicht
in der WndProc behandeln - es sind nur die bekannten
Einschränkungen, weswegen auch SendMessage
oft nicht funktioniert.
Jochen Kalmbach [MVP]
> Dazu ist AttachThreadInput *unbedingt* notwendig
> und das fehlt auch in Deinem Code.
Ich glaube Du hast meinen Code gar nicht angeschaut...
> wie gesagt, f�r meinen Code ist es relativ egal welcher
> externe Prozess das ist.
Na, welcher Text wird jetzt bei meinem TargetApp angezeigt?
Greetings
Jochen
FrankDzaebel
> > Dazu ist AttachThreadInput *unbedingt* notwendig
> > und das fehlt auch in Deinem Code.
>
> Ich glaube Du hast meinen Code gar nicht angeschaut...
ich glaube Du hast es nicht verstanden. Lies Dir
den oberen Satz nochmal durch. Oder lies Dir die
Doku zu GetFocus durch. AttachThreadInput ist
*unbedingt* notwendig, wenn man - wie in
unserem Thread hier (siehe auch das Posting des OP -
GetFocus über Prozess-Grenzen benutzt:
[GetFocus Function ()]
http://msdn.microsoft.com/en-us/library/ms646294(VS.85).aspx
FrankDzaebel
Quellcode "vorhanden", aber Du sagst halt im Artikel
es ist überflüssig, was es in unserem Fall nicht ist.
Siehe auch die Doku-Hinweise.
ciao Frank
Herfried K. Wagner [MVP]
>> > Dazu ist AttachThreadInput *unbedingt* notwendig
>> > und das fehlt auch in Deinem Code.
>>
>> Ich glaube Du hast meinen Code gar nicht angeschaut...
>
>ich glaube Du hast es nicht verstanden. Lies Dir
>den oberen Satz nochmal durch. Oder lies Dir die
>Doku zu GetFocus durch. AttachThreadInput ist
>*unbedingt* notwendig, wenn man - wie in
>unserem Thread hier (siehe auch das Posting des OP -
Niemand spricht hier von 'GetFocus' -- es tut auch nichts zur Sache. Warum
der Themenwechsel?
Herfried K. Wagner [MVP]
>nur zur Sicherheit: AttachThreadInput ist in Deinem
>Quellcode "vorhanden", aber Du sagst halt im Artikel
Es ist nicht �berfl�ssig, sondern wirkungslos in Bezug auf 'GetWindowText'.
Mit oder ohne 'AttachThreadInput' kann 'GetWindowText' nicht f�r Fenster
fremder Prozesse verwendet werden. Warum, hat Jochen schon erkl�rt: Weil die
Funktion dann kein 'WM_GETTEXT' sendet, sondern lediglich Daten aus einem
"geheimen" Puffer kopiert.
FrankDzaebel
schau Dir die Frage des OP an und
[Strg-F] GetFocus ;-)
Nochmal: AttachThreadInput ist im Szenario
des OP unbedingt notwendig! Mehr soll nicht
ausgesagt sein. Du hast es in Deinem Artikel
falsch dargestellt.
ciao Frank
Herfried K. Wagner [MVP]
K�nntest Du bitte beim Thema bleiben? Um 'GetFocus' geht es jetzt nicht,
sondern einzig um Deine Aussage, da� 'GetWindowText' auch bei
Fenstern/Steuerelementen fremder Prozesse funktioniert, wenn zuvor
'AttachThreadInput' aufgerufen wurde. Diese Ausage ist nachweislich falsch.
FrankDzaebel
schau Dir die Frage des OP an und
[Strg-F] GetFocus ;-)
Nochmal: AttachThreadInput ist im Szenario
des OP unbedingt notwendig! Mehr soll nicht
ausgesagt sein. Du hast es in Deinem Artikel
falsch dargestellt.
ciao Frank
Jochen Kalmbach [MVP]
> Nochmal: AttachThreadInput ist im Szenario
> des OP unbedingt notwendig! Mehr soll nicht
> ausgesagt sein. Du hast es in Deinem Artikel
> falsch dargestellt.
Ich habs ja verstanden... mich interressiert aber trotzdem *Dein* C#
Beispielprogramm, damit _ich_ es gegen mein TargetApp testen kann, damit
wir dann diesen Thread hier endlich beenden k�nnen!
Greetings
Jochen
Herfried K. Wagner [MVP]
Ist Dein Newsreader kaputt? Da kommen Beitr�ge gleichen Inhaltes �fter mal
doppelt an...
SCNR
FrankDzaebel
> > Nochmal: AttachThreadInput ist im Szenario
> > des OP unbedingt notwendig! Mehr soll nicht
> > ausgesagt sein. Du hast es in Deinem Artikel
> > falsch dargestellt.
>
> Ich habs ja verstanden...
ok danke, reicht mir aber nicht ganz.
Du könntest hier eigentlich fairerweise sagen, dass Du
mit mir hier einer Meinung bist, o.ä.
(natürlich nicht, wenn Du es nicht wärst).
Ich denke, ich maile Dir lieber privat die
Ergebnisse und Korrespondenz. Hier kann man
sich momentan kaum mehr richtig fachlich austauschen.
ciao Frank
Jochen Kalmbach [MVP]
>>> Nochmal: AttachThreadInput ist im Szenario
>>> des OP unbedingt notwendig! Mehr soll nicht
>>> ausgesagt sein. Du hast es in Deinem Artikel
>>> falsch dargestellt.
>> Ich habs ja verstanden...
>
> ok danke, reicht mir aber nicht ganz.
> Du k�nntest hier eigentlich fairerweise sagen, dass Du
> mit mir hier einer Meinung bist, o.�.
> (nat�rlich nicht, wenn Du es nicht w�rst).
Ich bin nur in soweit Deiner Meinung, dass die Doku eindeutig ist.
ich bin aber nicht Deiner Meinung, dass AttatchThreadInput irgend etwas
an dem Verhalten �ndert.
> Ich denke, ich maile Dir lieber privat die
> Ergebnisse und Korrespondenz. Hier kann man
> sich momentan kaum mehr richtig fachlich austauschen.
Es w�re von Dir fair, wenn Du Dein Testprojekt auch ver�ffentlichen w�rdest.
Greetings
Jochen
Herfried K. Wagner [MVP]
>> > Nochmal: AttachThreadInput ist im Szenario
>> > des OP unbedingt notwendig! Mehr soll nicht
>> > ausgesagt sein. Du hast es in Deinem Artikel
>> > falsch dargestellt.
>>
>> Ich habs ja verstanden...
>
>ok danke, reicht mir aber nicht ganz.
>mit mir hier einer Meinung bist, o.�.
>(nat�rlich nicht, wenn Du es nicht w�rst).
So einfach ist das nicht. Du �nderst einfach wieder mal das Thema und willst
dann Zustimmung. Wir bleiben vorerst weiterhin beim Thema dieses
Teilthreads, zu dem 'GetFocus' /nicht/ geh�rt.
Der Beitrag im Blog von Jochen ist inhaltlich korrekt. Die Begr�ndung, warum
'GetWindowText' hier nicht funktioniert (auch mit vorherigem
'AttachThreadInput') kannst Du, wie Jochen auch ausf�hrt, in folgendem
Artikel von Raymond Chen [MSFT] nachlesen:
The Old New Thing : The secret life of GetWindowText
<URL:http://blogs.msdn.com/oldnewthing/archive/2003/08/21/54675.aspx>
-> "Can you give an example where this makes a difference?"
>Ich denke, ich maile Dir lieber privat die
>Ergebnisse und Korrespondenz. Hier kann man
>sich momentan kaum mehr richtig fachlich austauschen.
Woran das wohl liegen mag? Vielleicht daran, da� Du Beitragstitel in "OT"
�nderst und Beitr�ge ohne fachlichen Inhalt mehrfach an die Newsgroup
sendest?
Fachliche Diskussionen sind hier ganz richtig.
FrankDzaebel
Weisst Du, bei derart offensichtlichen Sachen
hier nicht zuzugeben, dass ich da Recht habe,
finde ich ich keine gesunde Basis einer privaten
Korrespondenz. Ich denke, nicht, dass es
dann Sinn macht, private Postings auszutauschen.
> wenn Du Dein Testprojekt auch veröffentlichen würdest
Mein Code liegt offen. Er ist in diesem Thread
veröffentlicht. Du musst nur die angegeben
Handles einsetzen.
Herfried K. Wagner [MVP]
>> Ich bin nur in soweit Deiner Meinung, dass die Doku eindeutig ist.
>
>Weisst Du, bei derart offensichtlichen Sachen
>hier nicht zuzugeben, dass ich da Recht habe,
>finde ich ich keine gesunde Basis einer privaten
>Korrespondenz. Ich denke, nicht, dass es
>dann Sinn macht, private Postings auszutauschen.
Es geht nicht darum /wer/ recht hat, sondern /was/ richtig ist.
Jochen Kalmbach [MVP]
> Mein Code liegt offen. Er ist in diesem Thread
> ver�ffentlicht. Du musst nur die angegeben
> Handles einsetzen.
Dein Code ist einfach nur M�ll... hast Du mal geschaut, weas Du da machst...
Quote:
GetWindowThreadProcessId(foreWindow, out winProcessId);
GetWindowThreadProcessId(base.Handle, out idAttach);
if (AttachThreadInput(idAttach, winProcessId, true))
Hast Du mal die Doku zu "AttachThreadInput" gelesen?
Die liefert hier *nie* true zur�ck...
Nachdem ich es korrigiert habe, liefert es immer noch das *falsche* zur�ck.
Und jetzt will ich nur noch etwas von Dir h�ren, wenn Du *Fakten*
lieferst! Das bedeutet: DEIN Beispielprojekt irgendwo postest!
Frank Dzaebel
Du lenkst wieder von Deinem Fehler ab.
Du schreibst offensichtlichen Quatsch (siehe
etwa AttachThreadInput) in Deinen
Artikeln, und stellst das nicht richtig. F�r
mich keine Basis f�r etwaige C# Hilfestellungen
mit "Beispielprojekten".
Herfried K. Wagner [MVP]
Jochen Kalmbach [MVP] schrieb:
>> Mein Code liegt offen. Er ist in diesem Thread
>> ver�ffentlicht. Du musst nur die angegeben
>> Handles einsetzen.
>
> Dein Code ist einfach nur M�ll... hast Du mal geschaut, weas Du da
> machst...
>
> Quote:
> GetWindowThreadProcessId(foreWindow, out winProcessId);
> GetWindowThreadProcessId(base.Handle, out idAttach);
> if (AttachThreadInput(idAttach, winProcessId, true))
>
> Hast Du mal die Doku zu "AttachThreadInput" gelesen?
> Die liefert hier *nie* true zur�ck...
Ich hatte es gestern auch probiert dies festgestellt...
> Nachdem ich es korrigiert habe, liefert es immer noch das *falsche* zur�ck.
Dito.
Alles in allem eine ziemliche Zeitverschwendung.
Herfried K. Wagner [MVP]
> Du lenkst wieder von Deinem Fehler ab.
Jochens Beitr�ge sind bisher zu 100 % inhaltlich korrekt.
> Du schreibst offensichtlichen Quatsch (siehe
> etwa AttachThreadInput) in Deinen
> Artikeln, und stellst das nicht richtig.
Der Artikel von Jochen ist korrekt. Deine Ausdrucksweise hingegen skandal�s.
> F�r mich keine Basis f�r etwaige C# Hilfestellungen
> mit "Beispielprojekten".
Willst Du Dich total l�cherlich machen?
Dein Code funktioniert �berhaupt nicht, da bei 'AttachThreadInput' immer
'false' zur�ckgeliefert wird. Warum das der Fall ist: Das steht in der
Dokumentation zur Funktion 'AttachThreadInput' (die mir im �brigen
bekannt ist, das Lesen und Verstehen kann /Dir/ niemand abnehmen).
Noch einmal:
* Du behauptest etwas ('GetWindowText' + 'AttachThreadInput'
funktioniert auch bei Fenstern/Steuerelementen fremder Prozesse), das
offensichtlich im Widerspruch zur Dokumentation steht.
* Du belegst diese Behauptung mit einem Beispiel, das nicht
funktioniert, weil 'AttachThreadInput' falsch aufgerufen wird. Dieses
Beispiel w�rde auch dann das /falsche/ Ergebnis zur�ckgeben, wenn
'AttachThreadInput' �berhaupt nicht aufgerufen w�rde.
* Das Beispiel von Jochen hast Du offenbar nicht getestet, sonst w�rst
Du nicht weiterhin davon �berzeugt, da� Deine Vorgangsweise nicht
funktioniert.
* Du versuchst, das Thema der Diskussion umzubiegen, indem Du nicht
themenrelevante Dinge wie 'GetFocus' einbringst.
* Du wirfst anderen, die Dich darauf mit funktionierenden Beispielen und
Dokumentationsausz�gen darauf aufmerksam machen wollen, da� sie
"Quatsch" schreiben etc.
Das sollte Dir zumindest zu denken geben.
Jochen Kalmbach [MVP]
> Du lenkst wieder von Deinem Fehler ab.
> Du schreibst offensichtlichen Quatsch (siehe
> etwa AttachThreadInput) in Deinen
> Artikeln, und stellst das nicht richtig. F�r
> mich keine Basis f�r etwaige C# Hilfestellungen
> mit "Beispielprojekten".
Wir halte mal Fest:
- Ich habe zwei Beispielprogramme zur Verf�gung gestellt, wo jeder
nachvollziehen kann, dass eben nicht "Booga!" zur�ck geliefert wird; und
es wird AttachThreadInput aufgruefen, wie von Dir gew�nscht.
- Du bist uns immer noch den Beweis schuldig, dass Deine Aussage stimmt
Frank Dzaebel
kurz in den Queelcode von Jochens App hereinzuschauen ...
Er macht ein:
HWND remotehwnd = FindWindow(_T("TARGETAPP"), NULL);
Dann nach AttachThreadInput macht er:
GetWindowText(remotehwnd, sz, 100);
Was soll jetzt anderes herauskommen als "TargetApp"?
Das kommt auch heraus. Nat�rlich auch mit GetWindowText.
Das ist eigentlich meine Aussage.
Jochen Kalmbach [MVP]
> jetzt hab ich mich doch mal dazu hinreissen lassen
> kurz in den Queelcode von Jochens App hereinzuschauen ...
Juhu!
> Er macht ein:
> HWND remotehwnd = FindWindow(_T("TARGETAPP"), NULL);
> Dann nach AttachThreadInput macht er:
> GetWindowText(remotehwnd, sz, 100);
>
> Was soll jetzt anderes herauskommen als "TargetApp"?
"Booga!"
> Das kommt auch heraus. Nat�rlich auch mit GetWindowText.
Ja eben... h�te ich "WM_GETTEXT" verwendet w�re das *richtige* rausgekommen!
> Das ist eigentlich meine Aussage.
...
Herfried K. Wagner [MVP]
> jetzt hab ich mich doch mal dazu hinreissen lassen
> kurz in den Queelcode von Jochens App hereinzuschauen ...
Ah, dazu mu�t Du Dich hinrei�en lassen?!
> Er macht ein:
> HWND remotehwnd = FindWindow(_T("TARGETAPP"), NULL);
> Dann nach AttachThreadInput macht er:
> GetWindowText(remotehwnd, sz, 100);
>
> Was soll jetzt anderes herauskommen als "TargetApp"?
> Das kommt auch heraus. Nat�rlich auch mit GetWindowText.
> Das ist eigentlich meine Aussage.
Geschickter Versuch, die Diskussion zu drehen.
Deine Aussage war, da� ein 'GetWindowText' dann ein 'WM_GETTEXT' sendet.
Diese Aussage ist falsch. Deine Aussage, deretwegen wir hier
diskutieren im Wortlaut:
| GetWindowText sendet selber WM_GETTEXT und
| geht f�r Fentster und "Steuerelemente".
Gem�� Deiner oben zitierten Aussage d�rfte nicht "TargetApp" (die Daten
aus dem "geheimen" Puffer) zur�ckgeliefert werden, sondern "Booga!".
Dies ist n�mlich der Text, der bei 'WM_GETTEXT' zur�ckgegeben wird.
Frank Dzaebel
>> Er macht ein:
>> HWND remotehwnd = FindWindow(_T("TARGETAPP"), NULL);
>> Dann nach AttachThreadInput macht er:
>> GetWindowText(remotehwnd, sz, 100);
>>
>> Was soll jetzt anderes herauskommen als "TargetApp"?
>
> "Booga!"
es kommt "TargetApp" logischerweise.
> Ja eben... h�te ich "WM_GETTEXT" verwendet w�re das *richtige*
> rausgekommen!
?? Das w�re nicht das richtige. Es muss "TargetApp"
herauskommen.
In meinem Code mache ich ja auch keine Fenster-
Handle, sondern Control-Handle, vielleicht ist das
Dein Denk-Fehler.
Normal halt TextBox-Controls. Das funktioniert bei
mir immer mit GetWindowText.
Und �ndere doch mal Deinen falschen Text bzgl.
AttachThreadInput in Deinem Artikel. Mach doch
einen Hinweis bzgl. GetFocus o.�. ... das ist
ja Anf�nger-Doku zu GetFocus Jochen. Du
musst hier AttachThreadInput benutzen.
Du brauchst doch in C# ja auch gar nicht in
den WndProcs herumzustochern wie in C++.
Frank Dzaebel
>> Ja eben... h�te ich "WM_GETTEXT" verwendet
und auch hier unterscheidet sich unser Code.
Ich benutze SendMessage-API Du nicht.
Irgendwo in dieser Richtung muss ja der Unterschied
liegen, dass es bei Dir nicht funktioniert ...
und bitte korrigiere Deine AttachTheadInput-Mist
in Deinem Artikel ...
ciao Frank
Jochen Kalmbach [MVP]
Es ist unfassbar.
Frank Dzaebel
Das best�tige ich (Konsens).
Es wird richtigerweise "TargetApp" zur�ckgegeben.
Also ist GetWindowText hier richtig.
Ich muss trotzdem sagen, dass nur "einer" verstehen
wird, was f�r einen Unsinn Du da im Code machst.
Nimmst den Window-Handle und erwartest, es soll
nicht die Beschriftung des Windows herauskommen.
Allerdings darf ich sagen, dass ich meinen Code
nicht mit Window-Handles sondern mit Control-Hanlde
getestet habe, weil dies das eigentliche Problem des OP
war.
Jochen Kalmbach [MVP]
> Ich muss trotzdem sagen, dass nur "einer" verstehen
> wird, was f�r einen Unsinn Du da im Code machst.
> Nimmst den Window-Handle und erwartest, es soll
> nicht die Beschriftung des Windows herauskommen.
Du hast den Unterschied zwischen GetWindowText und WM_GETTEXT nicht
verstanden.
Thorsten Doerfler
Frank Dzaebel schrieb:
>>> Er macht ein:
>>> HWND remotehwnd = FindWindow(_T("TARGETAPP"), NULL);
>>> Dann nach AttachThreadInput macht er:
>>> GetWindowText(remotehwnd, sz, 100);
>>>
>>> Was soll jetzt anderes herauskommen als "TargetApp"?
>> "Booga!"
>
> es kommt "TargetApp" logischerweise.
Wenn es nach der Logik Deiner Behauptung ginge, dass GetWindowText()
auch bei Fremdprozessen nichts anderes macht als SendMessage +
WM_GETTEXT an das Fenster zu schicken, solange man vorher brav
AttachThreadInput() aufruft, d�rfte aber nicht "TargetApp" zur�ckkommen!
Hier befindest Du Dich im Irrtum und im Widerspruch zur Dokumentation.
> Normal halt TextBox-Controls. Das funktioniert bei
> mir immer mit GetWindowText.
Ist aber nicht die in der Dokumentation empfolene Vorgehensweise.
> Und �ndere doch mal Deinen falschen Text bzgl.
> AttachThreadInput in Deinem Artikel.
Der Text ist v�llig korrekt. AttachThreadInput ist im beschriebenen
Kontext mit GetWindowText() unsinnig.
> GetFocus
Ist hier gar nicht Thema.
> Du brauchst doch in C# ja auch gar nicht in
> den WndProcs herumzustochern wie in C++.
Soll das jetzt Deine falsche Behauptung retten?
Thorsten D�rfler
--
Microsoft MVP Visual Basic
vb-hellfire visual basic faq | vb-hellfire - einfach anders
http://vb-faq.de/ | http://www.vb-hellfire.de/
Thorsten Doerfler
Frank Dzaebel schrieb:
> wird, was f�r einen Unsinn Du da im Code machst.
Schau Dir bitte erst einmal Deinen eigenen Code an, den Du hier als
Beispiel geliefert hast.
> Allerdings darf ich sagen, dass ich meinen Code
> nicht mit Window-Handles sondern mit Control-Hanlde
> getestet habe
Windows macht keinen Unterschied zwischen Window- und Control-Handles.
Das hast Du gerade erfunden.
> das eigentliche Problem des OP war.
Es geht hier ja schon lange nicht mehr um das eigentliche Problem des OP.
Frank Dzaebel
>> wird, was f�r einen Unsinn Du da im Code machst.
>> Nimmst den Window-Handle und erwartest, es soll
>> nicht die Beschriftung des Windows herauskommen.
>
> Du hast den Unterschied zwischen GetWindowText und WM_GETTEXT nicht
> verstanden.
:-) Dein Quellcode sieht f�r mich wirklich sinnfrei
aus, SCNR.
Vielleicht hilft die Doku:
"GetWindowText function copies the text of
the specified window's title bar".
Das ist genau das, was die Funktion hier *richtig* macht
(also eher doch mich best�tigt, eben selbst bei
externen Prozessen)
Wieso wundert Dich das? Es funktioniert so bei mir,
es funktioniert bei Deinem Code so. Da ist
irgendwo ein ganz massives Missverst�ndnis ;-)
Thorsten Doerfler
Frank Dzaebel schrieb:
> "GetWindowText function copies the text of
> the specified window's title bar".
> Das ist genau das, was die Funktion hier *richtig* macht
> (also eher doch mich best�tigt, eben selbst bei
> externen Prozessen)
Nein, denn Du hast etwas v�llig anderes behauptet. Es hat keiner einen
Zweifel daran, dass GetWindowText() sich so verh�lt, wie es in der
Dokumentation niedergeschrieben ist.
> Da ist irgendwo ein ganz massives Missverst�ndnis
Siehst Du es endlich ein?
Frank Dzaebel
> dass GetWindowText() auch bei Fremdprozessen
> nichts anderes macht als SendMessage +
> WM_GETTEXT
nein, das ist nicht so, es *benutzt* dies nur,
schau in die Doku, da stehts genau drin:
"GetWindowText causes a WM_GETTEXT message
to be sent to the specified window or control."
Das System ist aber mehr als die Summe seiner
Teile. GetWindowText liefert bei einem Window-Handle
nat�rlich das was es soll. Du hattest ja gesagt, das w�rde
gef�hrlich sein, weil es ein anderer Prozess w�re, worauf
ich antwortete, das dies mit AttachThreadInput eben doch
geht, was jetzt im Prinzip durch den Code von Jochen
IMHO auch bewiesen ist. Es liefert das, was es soll.
ciao Frank
Herfried K. Wagner [MVP]
>> Ja eben... h�te ich "WM_GETTEXT" verwendet w�re das *richtige*
>> rausgekommen!
>
> ?? Das w�re nicht das richtige. Es muss "TargetApp"
> herauskommen.
Du hast also zumindest den Punkt eingesehen, da� 'GetWindowText' bei
einem Fenster eines fremden Prozesses nicht per 'SendMessage' eine
'WM_SETTEXT' sendet.
Da� Du das nicht eingestehen, sondern durch eine Themen�nderung
kaschieren willst, ist bei dir schon bekanntes Verhalten. Ich halte es
aber f�r eine ziemliche Unversch�mtheit, wie Du Dich gegen�ber Jochen im
Ton vergreifst.
> In meinem Code mache ich ja auch keine Fenster-
> Handle, sondern Control-Handle, vielleicht ist das
> Dein Denk-Fehler.
Das tut in dem Fall nichts zur Sache.
> Und �ndere doch mal Deinen falschen Text bzgl.
> AttachThreadInput in Deinem Artikel. Mach doch
> einen Hinweis bzgl. GetFocus o.�. ... das ist
> ja Anf�nger-Doku zu GetFocus Jochen. Du
> musst hier AttachThreadInput benutzen.
Was was hat 'GetFocus' damit zu tun? �berhaupt nichts.
Jochen Kalmbach�s Blog � Blog Archive � GetWindowText und WM_GETTEXT
<URL:http://blog.kalmbach-software.de/de/2009/10/09/getwindowtext-und-wm_gettext/>
Im gesamten Artikel von Jochen stand nie etwas von 'GetFocus'. Im
Gegensatz zu Deinem Beispiel ruft au�erdem Jochens Beispiel
'AttachThreadInput' korrekt auf.
> Du brauchst doch in C# ja auch gar nicht in
> den WndProcs herumzustochern wie in C++.
Themenbezug?
Frank Dzaebel
> Schau Dir bitte erst einmal Deinen eigenen
> Code an, den Du hier als Beispiel geliefert hast.
brauchen wir fast nicht mehr, denn es scheint
jetzt eher auf der Ebene eines Missverst�ndnisses
zu liegen.
Der Code von Jochen reicht eigentlich als Beweis,
das GetWindowText den richtigen Text auch bei
externen Prozessen liefert. Es hat halt als "richtig"
etwas anderes angenommen. BTW: mein Code
ist sicher nicht fehlerfrei (stammt aus einer ge�nderten
Kopie), aber sollte ja auch nur helfen, dass Jochen
dass mal nachvollziehen kann. Aber der Code
ist ja im Prinzip �hnlich und GetWindowText funktioniert
in externen Prozessen richtig, also - what shall's.
>> Allerdings darf ich sagen, dass ich meinen Code
>> nicht mit Window-Handles sondern mit Control-Hanlde
>> getestet habe
>
> Windows macht keinen Unterschied zwischen
> Window- und Control-Handles.
Handle selber sind nur IntPtr Thorsten.
Wichtig ist, dass die Referenz auf andere
Klassentypen zeigt bei diesen beiden Varinaten,
weswegen die Dokus auch oft von Controls und
Windows sprechen.
> Es geht hier ja schon lange nicht mehr um
> das eigentliche Problem des OP.
ja, das war IMHO durch GetWindowText
schon gel�st. Aber es wurde es hier ja auch
OT-Subjekt.
Frank Dzaebel
> Du hast etwas v�llig anderes behauptet.
n�. Am besten Zitate gegen�berstellen.
ciao Frank
Herfried K. Wagner [MVP]
>> Wenn es nach der Logik Deiner Behauptung ginge,
>> dass GetWindowText() auch bei Fremdprozessen
>> nichts anderes macht als SendMessage +
>> WM_GETTEXT
>
> nein, das ist nicht so, es *benutzt* dies nur,
> schau in die Doku, da stehts genau drin:
> "GetWindowText causes a WM_GETTEXT message
> to be sent to the specified window or control."
... bei Steuerelementen/Fenstern im eigenen Proze�, wie die
Dokumentation auch sagt.
> GetWindowText liefert bei einem Window-Handle
> nat�rlich das was es soll. Du hattest ja gesagt, das w�rde
> gef�hrlich sein, weil es ein anderer Prozess w�re, worauf
> ich antwortete, das dies mit AttachThreadInput eben doch
> geht, was jetzt im Prinzip durch den Code von Jochen
> IMHO auch bewiesen ist. Es liefert das, was es soll.
* Aus der Dokumentation zu 'GetWindowText':
| If the target window is owned by another process
| and has a caption, 'GetWindowText' retrieves the
| window caption text. If the window does not have
| a caption, the return value is a null string.
-- GetWindowText Function ()
<URL:http://msdn.microsoft.com/en-us/library/ms633520.aspx>
Das willst Du nicht einsehen. Du behauptest stattdessen, da� Windows
auch in diesem Fall, wenn der Proze� mit 'AttachThreadInput' verbunden
wurde, Windows 'SendMessage' + 'WM_GETTEXT' sendet.
Damit widersprichst Du der Dokumentation. Andererseits widersprichst Du
Dir in Deinen neueren Beitr�gen selbst, indem Du das Ergebnis
"TargetApp" f�r richtig befindest (obwohl dieses eben der Beweis daf�r
ist, da� nicht 'SendMessage' + 'WM_GETTEXT' aufgerufen wird).
* 'AttachThreadInput' hat keinen Einflu� auf das Ergebnis, das Windows
bei Aufrufen von 'GetWindowText' f�r Fenster anderer Prozesse liefert.
Das willst Du nicht einsehen, indem Du behauptest, dies w�rde
funktionieren, nachdem 'AttachThreadInput' verwendet wurde. Egal ob mit
oder 'AttachThreadInput', in keinem Fall liefert 'GetWindowText' bei
einem Fenster eines fremden Prozesses den Wert, der bei 'WM_GETTEXT'
zur�ckgeliefert wird, sondern den Wert aus dem "geheimen" Puffer.
Frank Dzaebel
nachweislich �ber AttachThreadInput auch
mit Fremdprozessen funktioniert (->liefert
unbestritten "TargetApp", den richtigen Wert
nach Doku) ist fachlich f�r mich die Sache, so wie
ich sie in den ersten Postings beschreiben habe,
beendet.
Ich freue mich :-)
Guts N�chte allen.
Herfried K. Wagner [MVP]
> ich denke mal, da GetWindowText jetzt
> nachweislich �ber AttachThreadInput auch
> mit Fremdprozessen funktioniert
Hat mit 'AttachThreadInput' �berhaupt nichts zu tun.
> (->liefert unbestritten "TargetApp", den richtigen Wert
> nach Doku)
Das stimmt. Aber Du oder Dein Namensvetter haben etwas anderes behauptet.
> ist fachlich f�r mich die Sache, so wie
> ich sie in den ersten Postings beschreiben habe,
> beendet.
Hast Du einen Namensvetter hier? Der "andere" "FrankDzaebel" (liegt es
an der anderen Schreibweise?) hat n�mlich behauptet, da� 'GetWindowText'
bei Steuerelementen fremder Prozesse 'SendMessage' + 'WM_GETTEXT' sendet
-- was offenbar nicht der Fall ist...
Thorsten Doerfler
Frank Dzaebel schrieb:
Gut, lassen wir die Begr��ung in Zukunft wieder entfallen.
>> Du hast etwas v�llig anderes behauptet.
>
> n�. Am besten Zitate gegen�berstellen.
Gerne:
http://groups.google.com/groups?as_umsgid=epKI9KfRKHA.220%40TK2MSFTNGP02.phx.gbl
Gerne auch im Kontext des Diskussionsfadens:
http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/browse_thread/thread/3649c40ee49c57b4/90f0b3105ce866e3?#90f0b3105ce866e3
Aber es d�rfte ja jetzt klar sein, dass AttachThreadInput keine
Auswirkung auf das Verhalten von GetWindowText() bei Fremdprozessen hat.
Frank Dzaebel
>>> Du hast etwas v�llig anderes behauptet.
>>
>> n�. Am besten Zitate gegen�berstellen.
>
> Gerne:
> http://groups.google.com/groups?as_umsgid=epKI9KfRKHA.220%40TK2MSFTNGP02.phx.gbl
>
> Gerne auch im Kontext des Diskussionsfadens:
http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/browse_thread/thread/3649c40ee49c57b4/90f0b3105ce866e3?#90f0b3105ce866e3
Quote ggf. einfach nur den Text (ist einfacher ;-).
Ich mach das mal f�r Dich. Der erste und zweite Link
sind soweit mein NG-Reader es richtig macht:
Frank schrieb:
"GetWindowText sendet selber WM_GETTEXT und
geht f�r Fentster und "Steuerelemente".
und das ist nat�rlich richtig, sagt ja auch die Doku.
Mein Posting davor sprach u.a. von:
"GetWindowText function copies the text of
the specified window's title bar".
und ... dass es die Funktion hier *richtig* macht.
auch das ist nur reine Doku, bzw. beide Dinge stehen
in der Doku. Kann eigentlich nicht strittig sein und
ich sehe keinen Widerspruch.
> Aber es d�rfte ja jetzt klar sein, dass AttachThreadInput
> keine Auswirkung auf das Verhalten von
> GetWindowText() bei Fremdprozessen hat.
Das halte ich f�r eine sehr gewagte neue Aussage
und es ist Deine Meinung, nicht meine.
Ich sage nur: GetWindowText kann eben auch f�r
Fremdprozesse eingesetzt werden (wie in meinen ersten
Postings erw�hnt) - ist benutztbar wenn mit AttachThreadInput
(was u.a. durch die Nutzung von GetFocus hier unbedingt
n�tig ist! ) im Kontext.
Das war ja auch meine Aussage am Anfang.
Thorsten, danke und guts N�chtle :-)
F�r mich das jetzt fachlich abgeschlossen.
Herfried K. Wagner [MVP]
> Thorsten, danke und guts N�chtle :-)
> F�r mich das jetzt fachlich abgeschlossen.
Dann ist alle weitere M�he zwecklos. Du hast offenbar immer noch nicht
verstanden, weshalb Deine Aussage falsch war.
Frank Dzaebel
ich habe noch weitere Fehler in Deinem Quellcode gefunden,
neben denen im Artikel selber.
Wieder AttachThreadInput ... was f�r einige hier ein Buch
mit sieben Siegeln bleiben wird ;-)
BOOL bRet = AttachThreadInput(mytid, tid, TRUE);
Die Zeile ansich ist (in C++) korrekt, nur *wenn* Du sowas machst,
sollte das Gegenst�ck mit "false" auch sehr zeitnah dahinter
aufgerufen werden. Das fehlt in Deinem Quellcode. Schau Dir das in
meinem Quellcode an, oder schau Dir entsprechende Beispiele aus
der MSDN an.
Mit "true" (Parameter fAttach) verbindest Du die beiden
Threads der beiden Prozesse. Mit "false" trennst Du sie wieder.
[Fenster in den Desktop-Vordergrund bringen]
http://msdn.microsoft.com/de-de/library/bb979463.aspx
Jochen Kalmbach [MVP]
> Der Code von Jochen reicht eigentlich als Beweis,
> das GetWindowText den richtigen Text auch bei
> externen Prozessen liefert.
Tut es nicht.
Es verwendet eben intern *nicht* WM_GETTEXT.
> Es hat halt als "richtig"
> etwas anderes angenommen.
RIchtig ist das, was WM_GETTEXT liefert.
> BTW: mein Code
> ist sicher nicht fehlerfrei (stammt aus einer ge�nderten
> Kopie),
Der hat aber och *nie* funktioniert.
> GetWindowText funktioniert
> in externen Prozessen richtig, also - what shall's.
GetWindowText funktiniert hier nicht richtig, weil es kein WM_GETTEXT
verwendet. Auch nicht, wenn man sinnlose Funktionen vie
AttachThreadInput oder GetFocus aufruft...
>> Windows macht keinen Unterschied zwischen
>> Window- und Control-Handles.
>
> Handle selber sind nur IntPtr Thorsten.
> Wichtig ist, dass die Referenz auf andere
> Klassentypen zeigt bei diesen beiden Varinaten,
> weswegen die Dokus auch oft von Controls und
> Windows sprechen.
Das macht hier keinen Unterschied... dan teste es halt mit einem *Custom
Control*! Es wird genauso den falschen Text zur�ck liefern...
> ja, das war IMHO durch GetWindowText
> schon gel�st.
Sag mal, wie alt bist Du denn?
Jochen Kalmbach [MVP]
> Die Zeile ansich ist (in C++) korrekt, nur *wenn* Du sowas machst,
> sollte das Gegenst�ck mit "false" auch sehr zeitnah dahinter
> aufgerufen werden.
Was hat dass bitte damit zu tun, dass "GetWindowText" intern *nicht*
WM_GETTEXT verwendet?
Frank Dzaebel
>> Der Code von Jochen reicht eigentlich als Beweis,
>> das GetWindowText den richtigen Text auch bei
>> externen Prozessen liefert.
>
> Tut es nicht.
> Es verwendet eben intern *nicht* WM_GETTEXT.
Jochen, f�r mich ist das Thema schon fachlich
abgeschlossen. Jetzt kommen Deine Versuche
Deinen Unsinn in Deinem Code zu rechtfertigen.
GetWindowText benutzt intern WM_GETTEXT.
Schau Dir das in der Doku an.
> RIchtig ist das, was WM_GETTEXT liefert.
Richtig ist, was GetWindowText liefert, obwohl
Dein Quellcode absolut sinnfrei ist. Du fragst
in der Essenz von einem WindowHandle den
Titel ab, der auch richtig erscheint. Zuz�glich
wirklich handfesten Fehler in der Artikel-Beschreibung
bzgl. GetFocus/AttachThreadInput und dem
Vergessen des Unattach bei AttachThreadInput.
Ein Wunder, dass GetWindowText am Ende trotzdem
noch das richtige liefert, um meine Aussage zu
beweisen ;-)
Jochen Kalmbach [MVP]
> GetWindowText benutzt intern WM_GETTEXT.
> Schau Dir das in der Doku an.
Ok, das wollte ich h�ren!
DANKE!
(Somit hast Du uns alle best�tigt)
Frank Dzaebel
>> GetWindowText benutzt intern WM_GETTEXT.
>> Schau Dir das in der Doku an.
>
> Ok, das wollte ich h�ren!
>
> DANKE!
BITTE! :-)
Habe ich zwar schon �fter hier von mir
gegeben, aber wenn es Dir jetzt klar wird:
"GetWindowText causes a WM_GETTEXT message
to be sent to the specified window or control."
aus:
http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/4abf4a5da607529d
(ziemlich am Anfang)
> (Somit hast Du uns alle best�tigt)
ich kann nur von mir reden, dass ich mich best�tigt f�hle,
f�r andere w�rde ich nicht sprechen wollen. GetWindowText
liefert das richtige bei externen Prozessen, wenn es an
den Prozess gebunden wird.
Wie gesagt, das Thema ist f�r mich fachlich abgeschossen.
ciao Frank