Hallo, es geht mal wieder um mein Interpreterprojektchen, dass ohne das Forum hier noch nicht so weit wäre. ;-) ich habe: Eine Visual C++ MFC-Dialogfenster-Applikation die einen vollfunktionsfähigen Interpreter (eine Klasse) enthält. Der Interpreter wird innerhalb eines Threads gestartet, der in der MFC-Anwendung läuft und z.B. Befehle aus einer Textbox ausführt, und Windows-PostMessages an die MFC zurück schickt, die diese wiederum in einem ListControl-Element aufbereitet, kategorisiert und anzeigt. Der Interpreter verwendet auch GUI-Einstellungen aus der MFC-Anwendung z.B. welcher COM-Port für eine Aufgabe zu nutzen ist aus einer ComboBox, oder Filtereinstellungen für das ListControl. ich möchte: Den Interpreter komplett aus der MFC herauslösen und z.B. wie einen PHP-Interpreter per Konsole nutzen können. Die Befehle können dazu entweder direkt per STDIN im Konsolenfenster eingegeben werden, oder aus einer Datei kommen. Die Ausgabe erfolgt in STDOUT. Zusätzlich können z.B. Ein-/Ausgabe-Parameter per Kommandozeilen-Parameter bestimmt werden. Soweit alles kein Problem, da bekomm ich schon hin, aber: Ich möchte die MFC-Applikation so umbauen, dass sie den Interpreter komplett fernsteuert und ich so weiterhin den Komfort einer Dialoganwendung nutzen kann aber auch die Option für die Kommandozeile habe (beispielsweise für einen automatisierten Testlauf). Also z.B. eine Textbox die STDIN ersetzt und per "Senden"-Button an den Interpreter schickt, das o.g. ListControl-Element die STDOUT und diverse Buttons, Checkboxen usw. die entsprechenden Kommandozeilenparameter setzen sowie die Interpreter-Anwendung generell, starten, stoppen, abbrechen, "abschießen" usw. können. Wie gehe ich da am besten vor? Gibt's da eine gute Standardlösung? Bestimmt, oder? Vielen Dank schonmal!
Pipes könnten dir weiterhelfen. Oft aber verpasst man solchen Subsystemen einfach einen Netzwerksocket an den sich eine beliebige Applikation andocken kann und Kommandos absetzen kann. Du könntest zb einen Telnet Server studieren und anstelle des Echo Teils der die Kommandos an die Shell weiterleitet, deinen Interpreter einbauen. Auch RPC wäre denkbar, oder CORBA
OK, Pipes könnten klappen. Funktionieren die anderen Methoden auch ohne jegliche Installation oder Adminrechte? Also einfach gesagt eine GUI.EXE und eine INTERPRETER.EXE die miteinander quatschen können ohne besondere Vorkehrungen oder Installationen zu tätigen? Wäre auch denkbar, dass die GUI einfach bei jedem Mal "senden"-Button drüclen den Interpreter startet, fernsteuert und dieser sich nach abarbeiten der empfangenen Aufgaben wieder beendet.
Alexander I. schrieb: > OK, Pipes könnten klappen. Funktionieren die anderen Methoden auch ohne > jegliche Installation oder Adminrechte? Also einfach gesagt eine GUI.EXE > und eine INTERPRETER.EXE die miteinander quatschen können ohne besondere > Vorkehrungen oder Installationen zu tätigen? Hab das schon lange nicht mehr gemacht. Im schlimmsten Fall kommt dir die Firewall in die Quere. > Wäre auch denkbar, dass die > GUI einfach bei jedem Mal "senden"-Button drüclen den Interpreter > startet, fernsteuert und dieser sich nach abarbeiten der empfangenen > Aufgaben wieder beendet. In dem Fall würde ich den eigentlichen Interpreter in eine DLL auslagern. Deine GUI Anwendung lädt die DLL direkt. Eine kleine Konsolenanwendung kapselt die DLL mit einer zusätzlichen Kommandline für sonstige Benutzung (und zb einem Netzwerksocket)
Vielleicht ist das hier hilfreich. Es macht eigentlich nichts mysteriöses, sondern lässt ein Programm ausführen (das wäre deine Konsolenapplikation) und fängt vorher dessen stdin und stdout ab. Mit einer selbstdefinierten Funktion, die als eigener Thread läuft, wird stdin des Programms gefüttert, mit einer weiteren das stdout abgefangen und nach Belieben verwurstet. Das alles könnte man auch zu Fuß machen, aber so ist es vielleicht bequemer. Ein Beispiel ist mit dabei. Nachtrag: Ich habe es schon lange nicht mehr angefasst; falls es zickt, bitte Bescheid sagen.
Den Vorschlag mit der DLL finde ich gar nicht schlecht. Ich denke das werde ich morgen mal testen. Ich könnte mir vorstellen, dass das unproblematischer ist, als die Fernsteuerung und ich könnte mir den Umweg über STDIN und STDOUT sparen. Danke auch für das Beispiel. Das werde ich mir auch mal ansehen.
@alexander es gibt mehrere möglichkeiten. in einem aktuellen projekt nutze ich gleich 2 möglichkeiten : - mailslots - virtuelle schnittstelle (com0com auf sourceforge) adminrechte dürften bei beiden wegen nicht unbedingt das problem sein (glaub ich jedenfalls nicht). bei der com0com (also eine virtuelle com-schnittstelle) - lösung dürfte es die allerwenigsten probleme geben (bis auf die installation des treibers, die kann nur von einem admin ausgeführt werden). die com0com-lösung hat weiterhin den vorteil das sich die anwendung völlig transparent zu einer seriellen schnittstelle verhält, sprich wenn beispielsweise als zielsystem ein arm/avr/msp/irgendwas mit uart dahintersteckt verhält es sich durch die com-schnittstelle entsprechend gleich. der mailslot ist für größere datenmengen geeignet (damit lassen sich ohne probleme mehrere kilobytes/ms hin und herschubsen). dabei wird ein mailslot (dieser kann nur empfangen) erstellt und über ein bestimmtes file "\\.\mailslot\xyz" werden daten abgeschickt (ganz normal per writefile) und im mailslot können die abgeschickten pakete direkt empfangen werden (auch die blockzuordnung lässt sich damit erhalten). weiterhin kann man noch per post/sendmessage arbeiten (ist aber nicht unkritisch), memory-mapped-files (benötigt dann aber eine ringpuffer struktur) oder eben netzwerk-sockets. netzwerk-sockets sind elegant wenn man eben die anwendung verteilt laufen lassen möchte. allerdings ist der aufwand zu mailslot und dergleichen deutlich höher. wenn du fragen zu mailslot hast kann ich dir gerne weiterhelfen.
Hallo, eine Lösung mit einer Installation von Drittanbieter-Produkten ist für mich nicht akzeptabel. Ich habe es jetzt mit einer DLL realisiert. Die EXE-Datei startet einen Thread innerhalb der DLL der alles weitere managed. Das "Host-Programm" (entweder MFC GUI oder Konsole) startet außerdem einen Überwacherthread der den Zustand des Dll-Threads pollt und auswertet und entsprechend entweder PostMessages() für die GUI generiert oder mit der Konsole interagiert. Das funktioniert bis jetzt recht zufriedenstellend. Danke soweit.
na dann analysier' halt den fensterbaum, bis du das passende handle gefunden hast, und dann schickst tolle messages an das fenster. win32api läßt grüßen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.