warten bis anwendung gestartet wird...

[agm65]

hallo leute, hab da mal ne frage...
also ich möchte, dass mein progg wartet bis zB der IE geöffnet wird und dann sollen erst meine funktionen ausgeführt werden...geht sowas? also ich könne ja checken lasses ob die iexplorer.exe bereits ausgeführt ist und dann erst loslegen. dachte vielleicht gibts dafür ne function.. ? thx cu agm65

[Mr_G]

Vielleicht hilft dir das hier:

Delphi-Quellcode:

uses ..., tlhelp32 ...
function GetProcessID(sProcName: String): Integer;
  var
    hProcSnap: THandle;
    pe32: TProcessEntry32;
  begin
    result := -1;
    hProcSnap := CreateToolHelp32SnapShot(TH32CS_SNAPPROCESS, 0);
    if hProcSnap = INVALID_HANDLE_VALUE then exit;

    pe32.dwSize := SizeOf(ProcessEntry32);

    //wenn es geklappt hat
    if Process32First(hProcSnap, pe32) = true then
      //Prozess suchen
      while Process32Next(hProcSnap, pe32) = true do
      begin
        if pos(sProcName, pe32.szExeFile) <> 0 then
          result := pe32.th32ProcessID;
      end;
    CloseHandle(hProcSnap);
  end;

Ich glaue ich habs sogar hier aus dem Forum...

[Olli]

ShellExecuteAndWait (Direktlink) tut's auch. Einziges Problem: du weißt nie genau ab wann das Programm auch wirklich komplett geladen ist. Mit beiden Methoden nicht.

@Mr_G: Auf NT4 wird das nicht gehen ;)

[SirThornberry]

@Mr_G: außerdem müsstest du eine repeat-until-scheilfe nehmen da du sonst den ersten prozess den du bereits mit Process32Fist überspringst bei der Prüfung

[Christian Seehase]

Moin Olli,

Zitat:

Zitat von Olli

Einziges Problem: du weißt nie genau ab wann das Programm auch wirklich komplett geladen ist.

und wenn Du jetzt mal WaitForSingleObject durch WaitForInputIdle austauschst?
Letzteres ist ja schliesslich genau dafür da zu warten, bis der Prozess auf anwenderseitige Eingaben wartet.

[agm65]

danke jungs ich werde das heute abend mal testen ...

[SirThornberry]

@Christian Seehase: Das ist trotzdem nicht eindeutig. Grund sind da die bösen Programmierer von diversen Programmen. Hat man zum Beispiel einen Splashscreen und aktuallisiert den mit Application.ProcessMessages so werden die ersten Nachrichten abgearbeitet und für Windows müsste es so aussehen als ob das Programm jetzt fertig geladen ist und auf nutzereingaben wartet.

[Olli]

Zitat:

Zitat von Christian Seehase

und wenn Du jetzt mal WaitForSingleObject durch WaitForInputIdle austauschst?
Letzteres ist ja schliesslich genau dafür da zu warten, bis der Prozess auf anwenderseitige Eingaben wartet.

Ja, ist prinzipiell natürlich möglich. Aber die Einschränkung beachten:

Zitat:

If this process is a console application or does not have a message queue, WaitForInputIdle returns immediately.

Beim IE müßte es aber gehen, denke ich.

[Mr_G]

Zitat:

Zitat von SirThornberry

@Mr_G: außerdem müsstest du eine repeat-until-scheilfe nehmen da du sonst den ersten prozess den du bereits mit Process32Fist überspringst bei der Prüfung

Ich versteh nicht was du mir sagen willst...

P.S.: Hab mich nicht wirklich damit auseinander gesetzt. :oops: War nur eine Function die im Rahmen des Prozessekillens brauchte...

[SirThornberry]

woran macht dann die funktion WaitForInputIdle intern fest ob die Anwendung fertig ist? Ich hätte gedacht das dies der fall ist sobald die erste message abgearbeitet ist, aber wenn keine message queue vorhanden wäre würde es nach meiner Theorie ewig warten.

@Mr_G:

Delphi-Quellcode:

if Process32First(hProcSnap, pe32) = true then 
   //An dieser Stelle wurde bereits der erste prozess in pe32 eingelesen
   while Process32Next(hProcSnap, pe32) = true do //un hier liest du schon den nächsten prozess in pe32 ein. Wenn du also nach dem ersten aufruf (Process32First) in pe32.szExeFile den richtigen Namen hast wird dieser einfach ignoriert und nie gefunden

[Christian Seehase]

Moin SirThornberry,

wodurch erkannt wird, dass WaitForInputIdle zurückkehren kann weiss ich leider auch nicht, aber gemäss PSDK kehrt die Funktion erst dann zurück (Einschränkung siehe Ollis Posting), wenn der angegebene Prozess auf Eingaben vom Benutzer wartet.
Demzufolge sollte dann auch dessen Initialisierung abgeschlossen sein.

[SirThornberry]

naja, was heißt "auf eingaben wartet". Letzendlich mach ein win-programm doch nichts anderes als ständig in der messagequeue zu hängen, und dementsprechend kann doch nur daran fest gemacht werden das es auf eingaben wartet.

[Olli]

Zitat:

Zitat von SirThornberry

naja, was heißt "auf eingaben wartet".

Wenn keine Nachrichten mehr anhängig sind.

Zitat:

Zitat von SirThornberry

Letzendlich mach ein win-programm doch nichts anderes als ständig in der messagequeue zu hängen, und dementsprechend kann doch nur daran fest gemacht werden das es auf eingaben wartet.

So ist es. Steht ja oben implizit auch in meinem Beitrag ;)

[SirThornberry]

Zitat:

Zitat von Olli

Zitat:

Zitat von SirThornberry

naja, was heißt "auf eingaben wartet".

Wenn keine Nachrichten mehr anhängig sind.

Hmm, das hört sich mal glaubhaft an.

[Mr_G]

@ SirThornberry: Besten Dank! Nun weiß ich auch was du meinst... :coder:

[Olli]

Zitat:

Zitat von SirThornberry

Hmm, das hört sich mal glaubhaft an.

Hoffe ich doch. Man schaue sich doch nur mal die Nachrichtenschleife an. Die ist doch in den Teil aufgeteilt, wo die Nachricht abgeholt wird (GetMessage/PeekMessage) und den wo die Nachricht zum Fenster dispatcht wird. Der erste Teil würde sich hervorragend eignen um dort zu anzusetzen.

Leider habe ich nicht die Zeit um mir in der User32.dll die entsprechenden Stellen anzugucken. Aber wenn ich es hinbekomme, mache ich das auch nochmal.

[SirThornberry]

wenn es wirklich so ist dann müsste durch den Aufruf von Applicaiton.ProcessMessages aber die Anwendung das Signal geben das sie fertig ist und auf Nutzereingaben wartet denn Application.ProcessMessages arbeitet doch alle Messages ab die zu dem Zeitpunkt anstehen und nicht nur eine.

[Olli]

Zitat:

Zitat von SirThornberry

wenn es wirklich so ist dann müsste durch den Aufruf von Applicaiton.ProcessMessages aber die Anwendung das Signal geben das sie fertig ist und auf Nutzereingaben wartet denn Application.ProcessMessages arbeitet doch alle Messages ab die zu dem Zeitpunkt anstehen und nicht nur eine.

Das ist wahr. Müßte man testen. Aber ich stimme deiner Ansicht zu.

[Christian Seehase]

Moin Zusammen,

Application.ProcessMessages ist ja nun aber auch ein Sprachfeature von Borland, auf das Microsoft kaum Rücksicht nehmen wird.
Stellen an denen man das verwendet dürften in anderen Sprachen in Threads ausgelagert werden.

[SirThornberry]

@Christian Seehase: Es geht mehr darum das in so gut wie jedem splashtutorial für delphi mit Applicaiton.processmessages gearbeitet wird und somit WaitorInput.. nicht funktionieren dürfte, in anderen Sprachen wird es ähnliche Funktionen geben die mal schnell die messages abarbeiten.. Naja, da hilft nur probieren.

[brechi]

@SirThornberry Process32First ist immer der SystemProcess von daher ist es total bob ob man ne repeat oder while schleife nimmt, schöner ist aber die repeat schleife.

[Olli]

Zitat:

Zitat von brechi

@SirThornberry Process32First ist immer der SystemProcess von daher ist es total bob ob man ne repeat oder while schleife nimmt, schöner ist aber die repeat schleife.

Dies ist eine unzulässige Annahme, genauso wie die Annahme, daß ein Integer 32bit breit sei, oder ein Byte auf jedem Compiler 8 Bit habe. Vergiß es also lieber wieder ;)

[brechi]

das ist keine unzulässige annahme, genausowenig wie Module32First immer das exe-progamm selbes (exename, exehandle etc) liefert

und was das mit dem byte und integer zu tun hat weiß ich auch nicht, nen byte hat 8 bits (0..255) sonst wäres kein byte, wie es intern gehandelt wird, d.h. trotzdem als integer etc. muss dich ja nicht interessieren, wenn die API nunmal so funktioniert kann man das auch benutzen.

Edit:
du meinst bestimmt es wäre keine Spezifikation da MS dies nie so gesagt hat. eine Annahme ist das so lange bis es mir einer widerlegt hat

[Olli]

Zitat:

Zitat von brechi

das ist keine unzulässige annahme, genausowenig wie Module32First immer das exe-progamm selbes (exename, exehandle etc) liefert

Da du keinen Einfluß darauf hast, ist diese Annahme unzulässig!

Die Größe eines Bytes läßt sich mit sizeof() ermitteln. Die Annahme, daß der Rückgabewert bei einem Byte 1 ist, ist unzulässig! Hat etwas mit portablem Code zu tun.

Zitat:

Zitat von brechi

wenn die API nunmal so funktioniert kann man das auch benutzen.

Das tut sie aktuell, und du kannst sie durchaus selber so benutzen, allerdings sollte man nicht in einem Forum, wo sich Programmierer und nicht "Coderz" unterhalten solche Tips geben, die auch mal schnell in die Hose gehen können - oder zumindest über die Nebenwirkungen aufklären. In die Hose gehen kann das nämlich genaugenommen mit jedem einzelnen neuen Patch der aus Redmond kommt.

Du kannst dagegen "argumentieren" wie du willst. Da die von dir genutzte Funktionalität nicht dokumentiert ist, kann sie sich jederzeit ändern - genau wie bspw. die Native APIs in einem gewissen Rahmen sich ändern können. Entweder man weist explizit darauf hin und nimmt diese Möglichkeit in Kauf, oder man eben nicht. Aber da du nicht darauf hinweist, überläßt du nicht etwa dem Fragesteller die Entscheidung darüber, sondern enthältst ihm eine vitale Information vor.

Zitat:

Zitat von brechi

du meinst bestimmt es wäre keine Spezifikation da MS dies nie so gesagt hat. eine Annahme ist das so lange bis es mir einer widerlegt hat

Dazu brauche ich nur einen Toolhelp-API-Ersatz für NT4 einführen, bei dem dies nicht der Fall ist. Damit ist die Annahme bereits widerlegt. Wie du siehst, ist nicht eine Zeile Code von MS nötig um deine Bedingung zu erfüllen.

[SirThornberry]

@brechi: ein Integer hat zur Zeit bei den meisten 32 Bit, früher war er mal 16 Bit und in naher Zukunft ist er 64 bit.
Ich würde auch nicht davon ausgehen das der erste Prozess immer der Systemprozess ist solange es nicht explizit im msdn steht.
Die Annahme ist ähnlich wie die das FindFist, FindNext die Dateinamen in alphabeticher Reihenfolge zurück gibt (ist nur bei NTFS laut msdn so), es ist eben abhängig von den äußeren Umständen. Und vielleicht ist bei der nächsten Windowsversion der erste Prozess nicht mehr der Systemprozess - und dann müsste man sein Programm umbauen. Also am besten immer gleich richtig machen so wie es im msdn steht.

[brechi]

1) du meintest ein byte besteht nicht immer aus 8 bit, das tu es wohl, wie es intern gespeichert ist ist es egal
wenn ich also nen byte benutze kann ich ausgehen, dass ich zahlen von 0 bis 255 darstellen kann. das nen sizeof nicht 1 zurückgeben muss hat doch nichts damit zu tun das das byte trotzdem aus 8 bits besteht.

also könntest höchstens sagen nen byte hat 8 setzbare bits muss aber nicht 8 bit groß sein, desweiteren kann man wenn schon bei sizeof nicht davon ausgehen das es bei einem byte halt imemr 1 liefert. das da eventl was falsches rauskommt liegt halt an dem sizeof und nicht etwa an dem aufbau von nem byte

2) anders ist es bei nem integer, das muss nicht immer 32 bit groß sein, und wie man sieht ist es nunmal so das für 64 bit eben die programme umgeschireben werden müssen, das liegt aber nicht daran das der programmierer davon ausgeht, dass es halt immer 32 bit hat.
davon kann man und jeder programmierer muss sogar davon ausgehen, schließlich programmieren wir hier immer noch mit delphi für nen x86 und windows. die programme werden halt nicht auf nem 64bit system laufen, deshalb gibt es halt da noch die 32bit emulierung - oder wie auch immer es MS macht.

als beispiel hättest vielleicht char nehmen könne was in delphi 8bit und in java 16bit groß ist
aber auch hier darf ich in meinem delphi programm selber davon ausgehen, dass es nunmal 8bit groß ist.

das man durhc irgendwleche hacks den verlauf immer ändern kann ist auch klar. aber es gibt halt auch annahmen wie z.b. GetModuleHandle('kernel32.dll') ist immer gültig, die deiner auffassung ja von MS nie so gesagt werden, aber meiner meinung nach immer stimmen. sollten sie nicht stimmen, muss halt jemand etwas gehackt haben (dll aus der <nameeintragen> tabelle gelöscht haben etc.)

@FindFist, FindNext die Dateinamen in alphabeticher Reihenfolge: MS sagt ja selbst das es nur für NTFS gilt, dann kann man sich auch nicht drauf verlassen :)
und es stimmt ja auch bei fat nicht, aber du kanns mir auch kein windows/irgendwleche einstelleungen ala (fat32/ntfs) sagen wo meine 3 behauptungen/annahmen (module32firs,process32first,getmodulehandle('kern el32.dll')) nicht stimmen

desweiteren unterstütz ich das mit der while schleife auch nicht, und bin auch sehr pingelig wenns um sowas geht. aber grundsätzlich wäre es egal - wenn die repeat scleife acuh schöner/besser/sicherer ist.

aber manchmal bruacht man halt doch annahmen wie z.b. wie kommt man an des modulhandle ohne GetModuleHandle etc. und wenn man des dann weiß ist es besser, wenn mans auch für andere benutzungen nicht verwenden sollte

[SirThornberry]

@brechi: Du hast schon recht, olli und ich (zumindest ich) wollten einfach damit sagen das man nicht immer von etwas ausgehen kann nur weil nicht das gegenteil irgendwo geschrieben ist.

Es ist doch zum Beispiel bedeutend einfacher ein Projekt von Delphi32 zu nehmen und einfach mit einem 64Bit Delphicompiler zu kompilieren als das Projekt dann neu zu schreiben.

Wenn solche Annahmen sind as zum Beispiel der erste Prozess immer der Systemprozess ist sollte man explizit dazu schreiben das dies nur eine Annahme ist die unter dem aktuellen Betriebssystem zutrifft. Ansonsten könnte das ein Unwissender so aufgreifen und wundert sich später das etwas nicht funktioniert weil der davon ausgeht das deine Annahme (die nicht als Annahme markiert war) eine Festlegung war.

[Olli]

Zitat:

Zitat von brechi

1) du meintest ein byte besteht nicht immer aus 8 bit, das tu es wohl, wie es intern gespeichert ist ist es egal
wenn ich also nen byte benutze kann ich ausgehen, dass ich zahlen von 0 bis 255 darstellen kann. das nen sizeof nicht 1 zurückgeben muss hat doch nichts damit zu tun das das byte trotzdem aus 8 bits besteht.

Wenn du es so sagen willst, dann müßte es heißen: Mindestens 8 Bit.

Zitat:

Zitat von brechi

das man durhc irgendwleche hacks den verlauf immer ändern kann ist auch klar. aber es gibt halt auch annahmen wie z.b. GetModuleHandle('kernel32.dll') ist immer gültig, die deiner auffassung ja von MS nie so gesagt werden, aber meiner meinung nach immer stimmen. sollten sie nicht stimmen, muss halt jemand etwas gehackt haben (dll aus der <nameeintragen> tabelle gelöscht haben etc.)

Im Falle von Kernel32.dll wird es vermutlich auch auf zukünftigen Systemen stimmen (müssen), aber man sollte sich dennoch nicht darauf verlassen, sondern den Rückgabewert auch hier testen.

Zitat:

Zitat von brechi

aber manchmal bruacht man halt doch annahmen wie z.b. wie kommt man an des modulhandle ohne GetModuleHandle etc. und wenn man des dann weiß ist es besser, wenn mans auch für andere benutzungen nicht verwenden sollte

Wohl wahr. Daß ich es weißt, sollte dir klar sein. Solche Annahmen sollten aber in einem engen Rahmen eingesetzt werden und wenn möglich sollte (zB in so einem Forum wie hier) auf die Nebenwirkungen hingewiesen werden.

[brechi]

ich bin ja auch eigentlich deiner meinung. imho läuft das auf allen BS, aber man sollte halt nichst benutzen was in der zukunft geändert sein könnte.