| |
| |
|
| - Seite 1 - |
|
Nico
Madysa | Ich weiß nicht so recht, woran es liegt, aber seit Kruzem spinnen die Funktionen zum Finden von Fenstern.
FindWindow() schmiert ab, wenn kein Fenster zu der Maske passt.
AddWindows klappt garnicht. (macht beim Verwenden den Adler)
Liegt das an XProfan10 oder eher an ME? |
|
| |
| |
| |
|
| |
| |
| - Seite 2 - |
|
|
GDL | Hallo Nico,
bei mir läufts auch.
Servus
Georg |
|
| |
| |
| |
|
|
Frank
Abbing | Bei mir auch.
Hast vielleicht was mit COM oder OLE nicht in Ordnung? Eine der Dlls |
|
| |
| |
| |
|
|
| | Geht bei mir auch Windows98 SE). |
|
| |
| |
| |
|
|
Sebastian
Sprenger | Hallo zusammen,
ich hab die Quelltexte in diesem Thread jetzt zwar nicht getestet, kann Nicos Probleme aber nachvollziehen. Meine Programme in Profan 7.0e haben sich früher unter Windows ME (und wenn ich mich recht erinnere, auch unter Windows 98) wegen der Profan-Funktion FindWindow auch aufgehängt. Inzwischen hab ich sie durch die API-Funktion ersetzt, seitdem passierte es in denselben Programmen nie wieder.
Gerade eben hatte ich nochmal ein Testprogramm mit FindWindow und AddWindows geschrieben und jeweils im Interpreter und in der Runtime von Profan 5.0 und Profan 7.0e gestartet. Hat sich auch wieder alles aufgehängt. Nach einem Neustart von Windows ME funktionierte es tadellos und ich konnte danach keine Abstürze mehr reproduzieren.
Programmcode scheint übrigens völlig egal zu sein, es passierte wie gesagt schon in meinen fertigen Programmen (nicht unter 500 Zeilen) sowie in sinnfreien Einzeilern (also ohne Variablen oder irgendwelche Ausgaben).
Unter Windows XP dagegen funktionierte alles immer.
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 | 25.11.2006 ▲ |
|
| |
|
|
| Wie genau sieht das Aufhängen aus?
Welche API verwendest du, um Findwindow zu ersetzen?
Unter der API EnumWindows findet man das hier:
The EnumWindows function does not enumerate child windows.
This function is more reliable than calling the GetWindow function in a loop. An application that calls GetWindow to perform this task risks being caught in an infinite loop or referencing a handle of a window that has been destroyed.
Welche API steckt hinter FindWindow? Könnte ja auch solche Ursachen haben... |
|
| |
| |
| |
|
|
Sebastian
Sprenger | Hallo Andreas,
beim Aufhängen gibts nicht viel zu sehen: Profan macht zuerst seine Arbeit, und sobald es auf die Profan-Funktion FindWindow stößt, macht Profan gar nichts mehr und lässt sich nur noch über Strg+Alt+Entf und ca. 10 Sekunden warten beenden. Keine Fehlermeldungen, BlueScreens oder dergleichen.
Ich benutze die API FindWindow mit lpClassName = 0 und lpWindowName = Stringadresse.
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 | 26.11.2006 ▲ |
|
| |
|
|
RGH | Da es bei der Profan-Funktion FindWindow() möglich sein soll, nur den Anfang des Fenstertitels anzugeben (wichtig bei Programmen, die den aktuellen Dateinamen an den Fenstertitel anhängen), verwende ich nicht die API FindWindows (oder FindWindowEx), sondern folgende Funktion (Delphicode):
KompilierenMarkierenSeparierenIPar1 := GetWindow(GetDesktopWindow,GW_Child);
IPar1 := GetWindow(IPar1,GW_HWndFirst);
SendMessage(IPar1,wm_GetText,32767,LongInt(Addr(C2)));
While (StrLIComp(C1,C2,E)<>0) And (IPar1 <> 0) Do Begin
IPar1 := GetWindow(IPar1,GW_HWndNext);
SendMessage(IPar1,wm_GetText,32767,LongInt(Addr(C2)));
End;
In C1 (nullterminierter String) steht der an FindWindow übergebene Parameter, IPar1 wird zurückgegeben. Was macht die Funktion genau?
Zeile 1: Ich ermittele das erste Kindfenster des Bildschirmhintergrundes (GetDeskTopWindow)
Zeile 2: Ich ermittele das erste Anwendungsfenster. Gibt es keins, hat IPar1 den Wert 0.
Zeile 3: Ich ermittele den Fenstertitel dieses Fensters. Dieser steht nun in C2 (nullterminierter String).
Zeile 4: Solange String C1 nicht dem Anfang des Strings C2 entspricht und IPar 1 ungleich 0 ist ... (mit anderen Worten: die Schleife wird abgebrochen, wenn kein weiteres Fenster existiert oder ein passendes gefunden wurde)
Zeile 5: Da noch kein passendes Fenster gefunden wurde, ermittele ich das nächste Fenster ...
Zeile 6: ... und dessen Fensteritel
Zeile 7: Und weiter mit der Schleife (entspricht dem EndWhile in Profan).
Kurz: Die Schleife wird verlassen, wenn ein Fenster gefunden wurde, dessen Fenstertitel mit dem übergebenen String beginnt (dann hat IPar1das entsprechende Handle) oder kein weiteres Fenster existiert (dann hat IPar1 den Wert 0).
Es sollte also keinen Fall geben, in dem diese Schleife endlos läuft.
Bei mir tritt dieser Fall auch nie auf. Bei wem es anders ist, der sollte einfach mal obige Routine in XProfan umsetzen und ausprobieren. Dann müßte sich ermitteln lassen, was da schief läuft. Hier die Rouitine in XProfan:
KompilierenMarkierenSeparieren $H windows.ph
$H messages.ph
Proc XFindWindow
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$))
EndWhile
Return IPar1%
EndProc
CLS
Print Ergebnis = + Str$(XFindWindow(XProfan))
WaitInput
End
Für jegliche Infos bin ich dankbar.
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 | 26.11.2006 ▲ |
|
| |
|
|
Sebastian
Sprenger | Hallo Roland,
habs unter Windows ME probiert. Es liegt auf jeden Fall an WM_GETTEXT in Zusammenhang mit Fenstern, die nicht reagieren.
Ich hab erstmal irgendein Programm abstürzen und dann die FindWindow-Routine laufen lassen. Diese lief erst weiter, als ich das nicht mehr reagierende Programm über den Taskmanager beendet hatte.
Irgendwann gab GetWindow(IPar1, GW_HWndNext) dann auf einmal ein Handle zurück, bei dem WM_GETTEXT stecken blieb, zu dem sich auch sonst nichts ermitteln ließ und das mit Sicherheit auch nicht im Taskmanager auftauchte.
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 | 26.11.2006 ▲ |
|
| |
|
|
| Unter XP hatte ich bei einigen speziellen Fenstern ebenfalls mal das Problem, das mein Proggi ([...]  ) beim Ermitteln des Fenstertextes über WM_GETTEXT einen Abgang machte. Ich habe dann die API GetWindowText verwendet, das klappte bestens (ist aber nicht der idealste Weg). Auch die API SendMessageTimeout könnte man mal versuchen, damit regele ich das jetzt in [...] . |
|
| |
| |
| |
|
|
Nico
Madysa | OK, danke für die Hilfe an alle. Damit wäre zumindest FindWindow() geklärt.
Aber was ist mit AddWindows? Gibt es dafür auch ein Walk-Around? |
|
| |
| |
| |
|
|
| | Dürfte das selbe Problem sein. |
|
| |
| |
| |
|
|
Nico
Madysa | Suppi, also ist das hier der/die/das Walk-Around:
KompilierenMarkierenSeparieren $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? |
|
| |
| |
| |
|
(501)
Deutsch
English
Français
Español
Italia