XProfan

- Seite 2 -

Dürfte das selbe Problem sein.

Nico
Madysa

Suppi, also ist das hier der/die/das Walk-Around:
Kompilieren Markieren Separieren

 $H windows.ph
 $H messages.ph

Proc XAddWindow

    Parameters C1$
    declare IPar1%, C2$
    C2$ = Space$(32767)
    IPar1% = ~GetWindow(~GetDesktopWindow(), ~GW_Child)
    IPar1% = ~GetWindow(IPar1%, ~GW_HWndFirst)
    SendMessage(IPar1%, ~wm_GetText, 32767, Addr(C2$))

    While (Left$(C2$, Len(C1$)) <> C1$) And (IPar1% <> 0)

        IPar1% = ~GetWindow(IPar1%, ~GW_HWndNext)
        SendMessage(IPar1%, ~wm_GetText, 32767, Addr(C2$))
        AddString C2$

    EndWhile

EndProc

Oder?

Nico Madysa

- Seite 3 -

Hallo Nico...

Nö, ich glaube nicht. Das Problem dürfte bei SendMessage(IPar1%, ~wm_GetText, 32767, Addr(C2$)) liegen.

Nochmals.. bin da kein Experte, habe aber im Augenblick folgenden Eindruck:
Manche Fenster, u.a. unsichtbare und unlistbare Systemfenster unter XP (und wohl auch unter ME) verarbeiten die Message WM_GETTEXT nicht richtig. Sendet man eine Message mittels Sendmessage, wartet das Programm auf eine Antwort von der WNDProc des angesprochenen Fensters. Kommt diese nicht, wartet @Sendmessage ewig -> Programm stürzt ab. Verwedet man SendMessageTimeOut wartet diese API eine gewisse Zeit und bricht dann den Vorgang ab => das müßte dann gehen und laut meinen Tests unter XP geht das auch.

Gruß

Andreas

...die Fenster die ich da unter XP meine, sind die Fenster mit den Handle direkt über %Desktop. Diese Fenster werden vom Prozess CSRSS.EXE erzeugt, und zwar vom selben Thread, der auch %Desktop erzeugt.
Der Titel des einen Fensters heißt Message, die anderen Fenster sind Kindfenster dieses Fensters.
Wie gesagt, da scheint irgendwas mit SendMessage schiefzulaufen, was wiederum mit SendMessageTimeOut funktioniert - und da liegt wohl auch das Problem mit FindWindow und AddWindows unter ME - kanns leider nicht testen, da mir ME fehlt.

Demnach sollte Roland innerhalb seines FindWindow / addwindows besser SendMessageTimeOut verwenden...!?

Mal versuchen, ob das besser geht meine ich. Bei mir klappts.

RGH

Demnach sollte Roland innerhalb seines FindWindow / addwindows besser SendMessageTimeOut verwenden...!?

Das wäre in der Tat eine Maßname für künftige XProfan-Versionen!

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Sebastian
Sprenger

Ich persönlich finde GetWindowText aber sinnvoller als SendMessageTimeout.
GetWindowText hat unter Windows ME immer richtig funktioniert, auch bei Fenstern, die laut Taskmanager gar nicht reagiert haben.
SendMessageTimeout mit WM_GETTEXT hat bei reagierenden Fenstern zwar funktioniert, aber bei den Nichtreagierenden müsste man doch wohl eher länger warten und bekäme evtl. nicht mal ein zuverlässiges Ergebnis... oder übersehe ich hier was?
Gruß, Sebastian

Profan² 7.0e, XProfan 9, 11.2a, FreeProfan32

Windows Vista Home Premium 32-Bit, 2.8 Ghz, 4 GB RAM

Windows Me, 1.8 Ghz, 256 MB RAM

Hallo Sebastian

Nein, richtig. Dafür hat GetWindowText andere Nachteile. Deswegen

Mal versuchen, ob das besser geht meine ich

- das GetWindowText immer richtig funktioniert (in Bezug auf Abstürze), kann ich bestätigen. GetWindowText liefert aber bei manchen Fenstern kein Ergebnis, obwohl ein Fenstertext vorhanden ist.

Leider habe ich kein ME und komme auch nur sporadisch mal an XP ran, kann deshalb diesen Fehler nicht komplett nachvollziehen und auch nicht testen, was da besser klappt.

Gruß

Andreas

Oha: GetWindowText cannot retrieve the text of a control in another application [...]

...sendet also auch nurn SendMessage

und der hier ist auch nicht schlecht: [...]

Erklärend? [...]

an edit control.

Was zu GetWindowText noch wichtig wäre:

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. If the window does not have a caption, the return value is a null string. This behavior is by design. It allows applications to call GetWindowText without becoming unresponsive if the process that owns the target window is not responding. However, if the target window is not responding and it belongs to the calling application, GetWindowText will cause the calling application to become unresponsive.

Und das hier sollte man da auch überdenken:

To retrieve the text of a control in another process, send a WM_GETTEXT message directly instead of calling GetWindowText.

Es gibt sehr viele Arten, eine Message zu senden. Warum sollten alle SendMessage aufrufen?
InSendMessage
PostMessage
SendMessageCallback
SendMessageTimeout
...