Konkret sieht das so aus: Ich habe ein Programm, das mit von CDocument abgeleiteten Dateien arbeitet. CDoc enthält diverse Properties und Methods, die über die Type-Library von einem externen VB-Programm angesprochen werden. Das funktioniert im Prinzip auch einwandfrei.

Nun wird vom MFC-Programm unmittelbar vor dem Speichern ein VB-Programm aufgerufen, das wiederum über das Interface diverse Daten eintragen soll, bevor vom MFC-Programm tatsächlich gespeichert wird. Bei Aufruf des externen Programms per _spawnl(P_WAIT,...) ist aber auch das Interface tot und kann nicht vom VB.exe angesprochen werden. Bei Aufruf per _spawnl(P_NOWAIT,...) legt das MFC.exe naturgemäß sofort mit dem Speichern los, bevor VB.exe auch nur das Interface aktivieren kann. Wenn VB.exe dann Daten einträgt, ist das Speichern längst erledigt. ShellExecute() oder ShellExecuteEx() statt spawnl() kommt im Prinzip auf's Gleiche raus.

Jetzt habe ich probehalber in IDocument einen Property-Wert eingebaut, der vor dem _spawnl(P_NOWAIT,...) vom MFC-Programm auf "Abwarten" gesetzt und solange abgefragt wird, bis er vom VB-Programm auf "Weitermachen" gesetzt wird. Eine Endlosschleife mit ständig wiederholter Abfrage dieses Werts würde natürlich den ganzen Rechner ausbremsen. Ein Versuch mit Abgabe des Timeslice per SleepEx(sekunden,TRUE) oder SleepEx(0,TRUE) legt aber auch das Interface und damit beide Programme lahm. Jetzt frage ich mich verzweifelt, wie man das MFC-Programm mit minimaler CPU-Last auf der Stelle treten, aber das COM-Interface am Leben lassen kann.

Der Aufruf des VB-Programms kann jedenfalls erst erfolgen, wenn vom Benutzer das Speichern angefordert wurde, also aus CDoc::OnSaveDocument() oder CDoc::OnFileSave(). Also bleibt mir auch nichts anderes übrig, als hier auf eine wie auch immer geartete Rückmeldung des VB-Programms zu warten. Oder hab' ich da einen grundsätzlichen Denkfehler?

Eigentlich funktioniert ShellExecuteEx und WaitForSingleObject auch schon ganz gut. (Siehe VCL FAQ bzw. Forum oder bestimmt auch im WinAPI Forum.)

-junix

WaitForInputIdle(...) nach dem Anwerfen und anschließend MsgWaitForMultipleObjectsEx(...) waren schließlich des Rätsels Lösung. Auch wenn man nur einen Processhandle, also eigentlich doch nur "single object" hat, ist es ganz nützlich, wenn man sich sämtliche Events für den Abbruch bzw. Unterbrechung der Warterei einzeln aussuchen kann. Die mussten dann nur noch per Peek- und PumpMessage() weitergeleitet werden, um das Interface am Leben zu halten. Wenn man's weiß, isses ganz einfach - und manchmal ganz nützlich, wegen doch nicht so ganz allmächtiger MFC mal wieder im WinAPI zu stochern...