aktives Control ermitteln

186 views
Skip to first unread message

Stefan Simon

unread,
Oct 5, 2009, 4:52:17 AM10/5/09
to
Hallo,

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

unread,
Oct 5, 2009, 6:11:27 AM10/5/09
to
Habs jetzt noch mit

[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]

unread,
Oct 5, 2009, 9:34:40 AM10/5/09
to
Stefan Simon schrieb:

> 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

unread,
Oct 5, 2009, 2:39:43 PM10/5/09
to
Hallo Stefan,

> 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]

unread,
Oct 5, 2009, 3:11:05 PM10/5/09
to
Frank Dzaebel schrieb:

> 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

unread,
Oct 5, 2009, 3:29:56 PM10/5/09
to
>> [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".

Thorsten Doerfler

unread,
Oct 5, 2009, 4:02:03 PM10/5/09
to
Hallo Frank,
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

unread,
Oct 5, 2009, 4:56:02 PM10/5/09
to
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."


> "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]

unread,
Oct 5, 2009, 5:32:35 PM10/5/09
to
Hallo Frank!

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

unread,
Oct 5, 2009, 6:26:35 PM10/5/09
to
Hallo Frank,
Frank Dzaebel schrieb:
>> "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.

Wenn das so w�re, w�re es dokumentiert.

Frank Dzaebel

unread,
Oct 5, 2009, 6:50:22 PM10/5/09
to
Hallo Herfried,

>> 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]

unread,
Oct 5, 2009, 8:13:05 PM10/5/09
to
Hallo Frank!

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]

unread,
Oct 5, 2009, 8:18:47 PM10/5/09
to
Hallo Stefan!

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]

unread,
Oct 5, 2009, 8:21:41 PM10/5/09
to
Nachtrag:

> 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

unread,
Oct 6, 2009, 2:33:09 AM10/6/09
to
Hallo Stefan,

(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

unread,
Oct 6, 2009, 3:56:24 AM10/6/09
to
Frank Dzaebel wrote:

> 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

unread,
Oct 6, 2009, 4:05:58 AM10/6/09
to
Immo Landwerth wrote:

> Was Dur schreibst ist nicht ganz korrekt ist.

<yoda>
Nicht gut schreiben, ich kann.
</yoda>

--
Immo Landwerth

FrankDzaebel

unread,
Oct 6, 2009, 4:08:20 AM10/6/09
to
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.
Ist für mich jetzt aber EOT.


ciao Frank

Immo Landwerth

unread,
Oct 6, 2009, 4:26:15 AM10/6/09
to
FrankDzaebel wrote:

> 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

unread,
Oct 6, 2009, 4:47:20 AM10/6/09
to
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?

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

unread,
Oct 6, 2009, 5:00:28 AM10/6/09
to
Hallo Frank,
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

unread,
Oct 6, 2009, 5:12:08 AM10/6/09
to
Hall oThorsten,

> > · 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]

unread,
Oct 6, 2009, 7:24:51 PM10/6/09
to
FrankDzaebel schrieb:

>> *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.

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

unread,
Oct 7, 2009, 12:24:41 AM10/7/09
to
Hallo Immo,

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

unread,
Oct 7, 2009, 6:50:46 AM10/7/09
to
Hallo Frank Dzaebel! Du schriebst folgendes:

> 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

unread,
Oct 7, 2009, 3:00:42 PM10/7/09
to
Hallo Ulf,

>> 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

unread,
Oct 7, 2009, 3:30:11 PM10/7/09
to
Hallo Frank!
Frank Dzaebel schrieb:
> 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

Genau so kommt das auch r�ber.

Herfried K. Wagner [MVP]

unread,
Oct 7, 2009, 3:31:46 PM10/7/09
to
Hallo Frank!

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

unread,
Oct 7, 2009, 4:37:56 PM10/7/09
to
Hallo Frank Dzaebel! Du schriebst folgendes:

>> 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

unread,
Oct 7, 2009, 5:00:49 PM10/7/09
to
Hallo Ulf,

>> 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

unread,
Oct 8, 2009, 1:58:38 AM10/8/09
to
Hallo Frank Dzaebel! Du schriebst folgendes:

>> 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

unread,
Oct 8, 2009, 2:32:52 AM10/8/09
to
Ulf,

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:

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]

unread,
Oct 8, 2009, 8:02:55 AM10/8/09
to
"Frank Dzaebel" <Po...@FranksSeite.de> schrieb:

> 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

unread,
Oct 8, 2009, 8:35:25 AM10/8/09
to
mein Fazit-Posting vom Anfang:

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]

unread,
Oct 8, 2009, 8:42:41 AM10/8/09
to
Hallo 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.

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

unread,
Oct 8, 2009, 8:53:42 AM10/8/09
to
Hallo Jochen,

> 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]

unread,
Oct 8, 2009, 9:43:39 AM10/8/09
to
Hallo 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, 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

unread,
Oct 8, 2009, 10:05:34 AM10/8/09
to
Hallo Jochen,

> >> 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]

unread,
Oct 8, 2009, 11:18:43 AM10/8/09
to
"FrankDzaebel" <po...@franksseite.de> schrieb:
>> >> 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.

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]

unread,
Oct 8, 2009, 11:17:35 AM10/8/09
to
Hallo 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.

FrankDzaebel

unread,
Oct 8, 2009, 11:43:38 AM10/8/09
to
Hallo Jochen,

> > 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]

unread,
Oct 8, 2009, 12:01:04 PM10/8/09
to
Hallo Frank!

"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]

unread,
Oct 8, 2009, 12:44:36 PM10/8/09
to
Hallo Herfried!

> ... 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

unread,
Oct 8, 2009, 5:57:11 PM10/8/09
to
Der Code von Jochen ist ja nicht sichtbar,
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]

unread,
Oct 9, 2009, 1:27:21 AM10/9/09
to
Hallo Frank!

> /// <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

unread,
Oct 9, 2009, 2:46:09 AM10/9/09
to
Hallo Jochen,

> 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]

unread,
Oct 9, 2009, 3:22:50 AM10/9/09
to
Hallo Frank!

>> 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

unread,
Oct 9, 2009, 4:08:27 AM10/9/09
to
Hallo Jochen,

> 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]

unread,
Oct 9, 2009, 4:34:35 AM10/9/09
to
Hallo FrankDzaebel!
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

unread,
Oct 9, 2009, 4:54:53 AM10/9/09
to
Hallo Jochen,

> 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]

unread,
Oct 9, 2009, 6:44:36 AM10/9/09
to
Hallo FrankDzaebel!

>> 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

unread,
Oct 9, 2009, 7:27:42 AM10/9/09
to
was mir übrigens auffällt ist, dass Du in Deinem
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]

unread,
Oct 9, 2009, 7:48:26 AM10/9/09
to
Hallo FrankDzaebel!

> 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

unread,
Oct 9, 2009, 8:30:58 AM10/9/09
to
Hallo Jochen,

> > 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

unread,
Oct 9, 2009, 8:37:05 AM10/9/09
to
nur zur Sicherheit: AttachThreadInput ist in Deinem
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]

unread,
Oct 9, 2009, 8:51:42 AM10/9/09
to
"FrankDzaebel" <po...@franksseite.de> schrieb:

>> > 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:

Niemand spricht hier von 'GetFocus' -- es tut auch nichts zur Sache. Warum
der Themenwechsel?

Herfried K. Wagner [MVP]

unread,
Oct 9, 2009, 8:53:59 AM10/9/09
to
"FrankDzaebel" <po...@franksseite.de> schrieb:

>nur zur Sicherheit: AttachThreadInput ist in Deinem
>Quellcode "vorhanden", aber Du sagst halt im Artikel
>es ist �berfl�ssig, was es in unserem Fall nicht ist.

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

unread,
Oct 9, 2009, 9:03:47 AM10/9/09
to
Jochen, falls Du GetFocus suchst,
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]

unread,
Oct 9, 2009, 9:32:59 AM10/9/09