Kommandozeilenprogramm in GUI ausführen
-
Hallo,
ich plane gerade ein Projekt und würde gerne wissen ob meine Vorstellungen umsetzbar sind bzw. falls ja, worauf ich im Vorfeld beim Aufbau achten muss.
Es geht um ein Programm welches (sehr viele) Daten in Form von Zahlenreihen bearbeiten soll. Dies soll auf zwei verschiedenen Wegen erledigt werden können. Einmal aus der Konsole heraus und einmal mittels GUI.
Mein Plan ist momentan zuerst ein Programm zu erstellen welches aus der Konsole heraus bedient wird. Als zweiten Schritt erstelle ich ein GUI welches das Konsolen-Programm "bedient", also die Befehle quasi zum anderen Programm weiterleitet.Die Frage ist: Kann man ein Programm schreiben welches Eingaben an ein anderes weiterleitet und die Ausgaben wieder zurückgibt. Das GUI sollte z.B. Ausgaben die das Konsolenprogramm macht in eine Textbox umleiten und darstellen.
Muss das Konsolenprogramm bestimmte Voraussetzungen erfüllen?Weitere möglicherweise wichtige Infos:
Bei der Wahl des GUI Managers (heißt das so?) habe ich mich noch nicht entschieden (bin bisher immer bestens mit Konsolen Ein-/Ausgaben zurechtgekommen). Ich schwanke zwischen wxWidgets und Qt, würde aber auch ein anderes nehmen falls diese beiden so etwas nicht umsetzen können.
Alles sollte Plattformunabhängig werden (mindestens Linux & Windows).
Da es sich um sehr große Datenmengen handelt muss es ein (/zwei) 64bit-Programm(e) werden.Besten Dank für jede Ratschlag!
-
Guck mal hier: https://support.microsoft.com/de-de/kb/190351
-
Es wäre dann wohl besser, du erstellst eine Library für die eigentliche Funktionalität und benutzt diese dann in dem Kommandozeilen- und GUI-Projekt.
-
Wenn DU beide Programme, also das konsolenprogramm und das GUI Programm, selbst erstellst, dann steht dir ja alles offen ^^
2 unterschiedliche prozesse miteinander Kommunizieren lassen -> IPC (https://de.wikipedia.org/wiki/Interprozesskommunikation)
Für jeden Anwndungsfall gibts da was mehr oder wniger gut geeignetes
Shared memory, pipes (stdin stdout), Filezugriff, Netzwerk .....damit kannst ohne Probleme Kommunikation auf und abbauen wie lustig bist ... das verhalten implementierst selbst. Also konsolen programm starten, Gui programm spaeter starten und Komm aufbauen und damit das Programm setuern ... alles kein problem. Nur ne Frage des Aufwands
Tipp, fang mal klein an, und nimm als erstes stdin/stdout. Ohne piping geht das auch unter windows, unter linux isses eh mehr als nur gebräuchlich ...
Falls später mal die Standard ausgabekanäle anderweitig brauchst, und dir die komm die ned zu müllen soll, kannst immer noch auf ne named/unnamed pipe umstellen ... oder netzwerk, oder .... ^^
wichtig nur, definier dir gleich nen gescheites Kommunikationsprotokoll am besten auf TEXT(ascii/utf8) basis, da bist am flexibelsten und kriegst den meisten support und umschiffst ganz paar probleme ^^Ciao ...
-
Hallo, Danke für die Infos.
@roflo:
Dieser Link: https://support.microsoft.com/de-de/kb/190351 sieht leider sehr nach windows-only aus, und ist daher nicht das was ich suche.@Th69:
das ist zwar generell möglich, würde aber wahrscheinlich mehr Programmieraufwand bedeuten.@PHBaum:
Beide Programme werden von mir erstellt. Der Artikel zu IPC sieht genau nach dem aus was ich suche. Kennt jemand ein gutes Einsteiger-Tutorial zu dem Thema?
-
Nobody-86 schrieb:
@Th69:
das ist zwar generell möglich, würde aber wahrscheinlich mehr Programmieraufwand bedeuten.Eher das Gegenteil!
-
Nobody-86 schrieb:
Hallo, Danke für die Infos.
@roflo:
Dieser Link: https://support.microsoft.com/de-de/kb/190351 sieht leider sehr nach windows-only aus, und ist daher nicht das was ich suche.@Th69:
das ist zwar generell möglich, würde aber wahrscheinlich mehr Programmieraufwand bedeuten.@PHBaum:
Beide Programme werden von mir erstellt. Der Artikel zu IPC sieht genau nach dem aus was ich suche. Kennt jemand ein gutes Einsteiger-Tutorial zu dem Thema?IPC ist viel aufwändiger als eine Library. Eine Library ist das einzige, was hier Sinn macht. Es macht sowieso immer Sinn, Funktionalität von der Darstellung zu trennen. Eine Lib mit einer sauberen API lässt sich dann sehr einfach mit einen kleinen Wrapper ausstatten, welches die Lib über die Kommandozeile versorgt und auch genauso einfach aus einer GUI ansprechen.
Bei IPC musst Du Dir Gedanken machen, wie Du Deine Daten serialisierst und deserialisierst um sie zwischen Prozessgrenzen hinweg zu transportieren. Und auch über Timeouts und alle möglichen Fehlerzustände, die Du auch noch sinnvoll über eine IPC kommunizieren musst.
Eine Library stellt im einfachsten eine Funktion mit Parametern zur Verfügung. Im Fehlerfall kannst Du einfach eine Exception liefern, die bei der GUI in einem Dialog landet und bei einem Kommandozeilentool die Fehlermeldung auf std::cerr ausgibt.
-
Ein Kommandozeilenprogramm, welches über Parameter gesteuert wird und bei Bedarf Eingaben und Ausgaben über stdin und stdout macht, ist auch nicht viel schwieriger als eine Bibliothek. Das wird oft in der Unixwelt gemacht, wenn die Entwicklung des Kommandozeilenprogramms und der GUI zwei verschiedene Projekte sind (außerdem ist man in der Unixwelt sehr darauf bedacht, dass Kommandozeilenprogramme obigem Ideal folgen, daher ist es einfach, GUIs dafür zu schreiben). Wenn aber GUI und Kommandozeilenprogramm aus dem gleichen Projekt kommen, bietet es sich tatsächlich an, das Backend als Bibliothek zu gestalten und dann eben zwei verschiedene "Oberflächen" für diese Bibliothek anzubieten. Es macht schließlich keinen Sinn, mit der GUI die Parameter zu verpacken, diese im Kommandozeilenprogramm dann wieder zu entpacken, um dann die Bibliothek damit zu steuern, wenn man es auch gleich direkt machen könnte. Außerdem ist man dann offener für spätere Entwicklungen.
