Prozessproblem...
-
Surkevin:
Er mein die anderen Programme von Hand (Maus) zu starten, nicht in seinem Code!code_pilot:
Betrifft das nur Office-Dokumente oder auch andere Programme wie z. B. Notepad, den Taschenrechner usw?
-
ich denke das WaitForSingleObject blockiert das ganze Prozessmanagment
-
@Hepi: Das ist ja das lustige: Wenn ich z.B. Notepad mit dieser Methode starte, und dann auf TXT-Dateien doppelklicke, kein Problem öffnen sich sofort
. Nur halt bei den Office-Dokumenten ist es mir bzw. dem Kunden aufgefallen, das er solange nicht weiterarbeiten kann, bis er das gestartete Excel beendet... vielleicht ist das ja ein M$-Bug
naja es ist auf jeden Fall äusserst seltsam. Und beim durchstöbern der MSDN hab ich auch nirgendwo gelesen, das dadurch andere Programme blockiert werden oder so... *grummel* hmm... liegt das vielleicht an den SatrtUp-Informationen oder so?? *grübel* 
Grüsse,
code_pilot
-
Surkevin schrieb:
ich denke das WaitForSingleObject blockiert das ganze Prozessmanagment
Nein, wieso sollte es?
Es legt den aufrufenden Thread so lange schlafen, bis das KernelObjekt (in diesem Fall der ProzessHandle durch Beendigung des Prozesses) signalisiert wird. Arbeitest Du nicht MultiThreaded, reagiert deine Anwendung auf keine Nachrichten mehr (der berühmte Satz "Diese Anwendung reagiert nicht mehr" bzw. "Keine Rückmeldung").
Aber andere Prozesse/Programme interessiert das nicht...
-
mh auch ich kann mal falsch liegen

-
Funktioniert es denn ohne das WaitForSingleObject( pi.hProcess, INFINITE ); - also wenn du dein Programm ganz normal weiterlaufen lässt?
-
Ich sag dazu nix mehr. Ich weis echt nicht warum das in meinem grossen Programm nicht geht. Ich hab jetzt gerade ein Testprogramm geschrieben, das nur einen Prozess - also Excel - startet; Fazit: Ich kann alles öffnen, jedes Dokument startet sofort die dafür vorgesehene Anwendung.
Jetzt mache ich dasselbe in meinem großem Programm, siehe da: Dasselbe Problem mit genau demselben Code. Ich kapier das nicht. Verbraucht mein Prog mehr speicher oder wie? Was mir auch noch aufgefallen ist, bei meinem großem Programm: Wenn er Excel geladen hat, und ich mit der Maus auf z.B. dem Desktop eine DOC-Datei anklicke, kommt als Cursor der Mauszeiger mit einer Sanduhr. Wenn ich nun das Excel-Fenster verschiebe updated sich gar nix mehr auf dem Desktop, d.h. ich kann die Icons sozusagen damit "wegwischen". Beende ich die Anwendung nun starten alle geklickten files. Wenn ich nix doppelklicke kann ich das Fenster verschieben und Windows läuft ganz normal...Schalte ich da vielleicht irgendwie was aus, was das halbe System lahmlegt? Ich kann das Programm leider hier nicht posten da es Strenger Geheimhaltung unterliegt ... und im Testprogramm gehts
blödes Windows
... ich verstehe das einfach nicht...Gruss,
~code_pilot
-
beantworte mal flenders Frage
-
ok aber kann ich erst heut abend machen habe die Sourcen nicht hier - ausser die vom laufendem Testprog *grummel*
~cp
-
Hast du evtl. ein Memory-Leak? Und wird dein Fenster denn noch korrekt aktualisiert (z.B. nach dem Minimieren)?
-
flenders schrieb:
Hast du evtl. ein Memory-Leak? Und wird dein Fenster denn noch korrekt aktualisiert (z.B. nach dem Minimieren)?
Hallo,
habs heute getestet ohne das WaitForSingleObject() ... funkt alles wunderbar! Was genau meinst du mit Memory-Leak? Meine Anwendung hat kein direktes Fenster, die Fenster werden nur als Dialoge bei Bedarf eingeblendet. Ein Hauptfenster existiert nicht. Aber es muss ja irgendwas mit meinem Programm-Framework zu tun haben und nicht mit dem WaitForSingleObject() selber ... hmmm warum kann es nicht einfach abstürzen wenn da was falsch allokiert ist oder so? Dann hätte man wenigstens einen Ansatz woran es liegt, in diesem Fall kann es ja an allem möglichen liegen...
Liegt das vielleicht an der Fensterklasse?
Grüsse,
~code_pilot
-
ne falsch allokaliert kann es eigentlich kaum sein...höchstens wenn es beim ersten Start geht, du falsch aufräumst und beim nächsten Start funktionierts dann nicht mehr....na wenigstens lag ich mit dem WaitForSingleObject doch richtig! ha!

An deiner Stelle würde ich soweit in einem externen Programm rekonstruieren bis der Fehler auftritt, so kannste den Heuhaufen dezimieren.Gruß,
Kevin
-
ähh? Wie meinst du das?

-
Hattest du das WaitForSingleObject in deinem Testprogramm eigentlich auch eingebaut?
-
Ja na sicher hatte ich das da eingebaut, sonst würde ich mich ja nicht so wundern (ich habs mit WaitForSingleObject UND WaitForSingleObjectEx probiert, und das Testprogramm einmal in einer Konsolen- und einmal in einer WinAPI-Version (wiefolgt) implementiert):
#include <windows.h> #include <string.h> #include <fstream.h> #include <stdlib.h> #include <stdio.h> #pragma hdrstop #include <condefs.h> //--------------------------------------------------------------------------- #pragma argsused WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int) { STARTUPINFO si; PROCESS_INFORMATION pi; SECURITY_ATTRIBUTES saProcess; ZeroMemory( &si, sizeof(si) ); si.cb = sizeof(si); ZeroMemory( &pi, sizeof(pi) ); si.dwFlags = STARTF_USESHOWWINDOW; saProcess.nLength = sizeof(saProcess); saProcess.lpSecurityDescriptor = NULL; saProcess.bInheritHandle = FALSE; si.wShowWindow = SW_SHOW; /*Lasst euch hiervon nicht irritieren, bei mir im Hauptprogramm geschieht der aufruf nunmal fast so ;), deshlab string und ein Array of Char ;) */ char text[1024+1]; string TempStr1 = "D:\\Programme\\Microsoft Office\\Office\\excel.exe"; strcpy(text, TempStr1.c_str()); MessageBox(NULL, "Starting process...", "", 0); if( !CreateProcess( NULL, text, &saProcess, NULL, FALSE, 0, NULL, NULL, &si, &pi) ) { return -1; } else { DWORD dwCode = WaitForSingleObjectEx(pi.hProcess,INFINITE, false); GetExitCodeProcess(pi.hProcess,&dwCode); } MessageBox(NULL, "Done", "", 0); return 0; }
-
Hey,
wozu brauchst du das WaitForSingleObject eigentlich? Gibt es vielleicht eine andere Möglichkeit als CreateProcess? ZB WinExec? Sag doch mal konkret was du erreichen willst...man muss ja nicht immer das Problem aus dem Weg schaffen sondern kann einen anderen Weg außenrum wählen
Gruß,
Kevin
-
@Surkevin: Ich will ein Programm so starten, dass das startende Programm wartet, bis das gestartete Programm beendet wurde - danach soll es normal weiterlaufen. Zudem benötige ich den Rückgabewert des gestarteten Programms (GetExitCodeProcess()) und es sollen Modis wie SW_SHOW, SW_HIDE, SW_MINIMIZED usw. übergeben werden können - das alles bieten ja Prozesse - nur hab ich da (oder Windows :D) wohl irgend einen Bug, denn es geht ja im kleinen Testprogramm aber nicht im großem Hauptprogramm. Da es ja im kleinen geht muss es ja mit meinem Hauptprogramm zu tun haben, nur kann es da 1000de Faktoren geben die das (irgendwie) beeinflussen können ... Hmmmm ... und WinExec() erlaubt nicht das Warten bis eine Anwendung beendet wurde, hab ich jedenfalls noch nie gehört.
Als denn, gute Nacht

code_pilot
-
Hallo,
PSDK schrieb:
Note This function is provided only for compatibility with 16-bit Windows. Applications should use the CreateProcess function.
Wozu braucht man noch WinExec?
MfG
tuküe
-
Der Einfachkeithalber?
Hast du mal Rebuild All gemacht? Im Release und Debugmodus ausprobiert und es verschiedene Betriebssysteme/Computer getestet? Spiel mal ein bisschen mit den Parametern bei CreateProcess rum...andere Priority etc.
Gruß,
Kevin
-
ich glaube nicht daß das Problem am Speicherverbrauch o.ä. liegt. Die einzelnen Office-Anwendungen versuchen jam, mit einer Anwendung auszukommen.
D.h: Du öffnest ein Dokument in Word, und doppelklickst ein zweites. Word wird zwar Zwei Einträge in der Taskleiste anzeigen (seit Word 2000 glaub ich), aber es gibt nur einen Prozeß (Taskmanager, Prozeßliste).
jetzt Schritt 2: In Word Hilfe/Info... (modalen Dialog öffnen), und Word-Dokument doppelklicken. Word kommt in den Vordergrund, aber nix passiert - bis du den Modalen Dialog schließt. Interessanterweise läuft die ganze Zeit keine zweite Instanz, obwohl der "Öffnen" Befehl eine startet - ich vermute (auch aus anderen Gründen), Office startet für jedes Dokument einen eigenen thread.
Nun versteh ich trotzdem nicht wieso das auch zwischen Excfel und Word passiert. Aber ich denke, daß Du den Office-Dokumenthandler irgendwie "durcheiunanderbringst".
Also kleine Ahnung, aber ich denke das Problem liegt in der Richtung
