OOP Grundaufbau

Hmm ich weiß halt nur noch nicht, wie ich das für meine Anwendung umsetzen soll. Ich komme von C auf Mikrocontrollern. Da habe ich immer sehr viel Wert darauf gelegt, dass das Programm an keiner Stelle hängt, und immer etwas macht. Jetzt möchte ich zum Test eine Anwendung programmieren, die mit dem Mikrocontroller kommuniziert. Das werde ich wahrscheinlich über RS232 machen. Jetzt brauche ich halt ein Menü, wo ich verschiedene Befehle an den Controller senden kann, aber auch der Controller permanent Daten sendet, welche dann vom PC verarbeitet werden.

Wenn ich jetzt aber zum Beispiel ein Menü mache muss ich ja mit einer Eingaberoutine dem Benutzer die Möglichkeit geben sich durch die Menüs zu arbeiten. Aber an dieser Stelle hängt ja dann das Programm.

Wie könnte man das am besten realisieren?

SeppJ

Das Thema wurde letzte Woche in der "Expertenrunde" diskutiert:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-261900.html

Das Ergebnis war, dass es mit reinen Standardmitteln nicht möglich ist.

Und würde es mit einer Grafischen Oberfläche gehen? Denn da gibt es ja ein quasi Multitasking, denn die Eingabe blockiert ja nicht, oder?

SeppJ

Markus W. schrieb:

Und würde es mit einer Grafischen Oberfläche gehen? Denn da gibt es ja ein quasi Multitasking, denn die Eingabe blockiert ja nicht, oder?

Umgekehrt: Das ist keine Eigenschaft grafischer Oberflächen, sondern eine Eigenschaft von Multitasking. Ob man Multitasking mit grafischer Oberfläche macht oder ohne, ist egal.

Der Punkt ist nur, dass man ohne Multitasking keine vernünftig bedienbare grafische Oberfläche bauen kann. Eigentlich genau das gleiche Problem, was du gerade in Textform hast.

Programme ohne Multitasking haben daher normalerweise andere Bedienkonzepte.

Die Frage ist, was ist der Zweck deines Programms:
- Eine coole Oberfläche haben? Multitasking lernen und Oberfläche programmieren. Egal ob als Text oder als Grafik.
- Etwas anderes? Konzentrier dich auf diese Kernfunktionalität. Lass dich bei der Bedienung von anderen Konsolenprogrammen inspirieren.

Du kannst auch ohne threads nicht blockiernde abfragen machen
http://www.c-plusplus.net/forum/viewtopic-var-t-is-39320.html

Oder schau dir GUI tutorials an Google: qt tutorial

Also vorerst soll es einfach nur funktionieren, so wie ich es vorhin beschrieben habe. Und es kam so herüber, als wäre das mit einer Konsolen Oberfläche nicht möglich.

Wenn grafisch würde ich gerne mit einer IDE Arbeiten also käme ja MFC in frage. Mit grafische Oberfläche habe ich bis jetzt nur mit Delphi gearbeitet, als wir das in der Schule hatten. Dort ging das eigentlich ganz gut.

SeppJ schrieb:

Der Punkt ist nur, dass man ohne Multitasking keine vernünftig bedienbare grafische Oberfläche bauen kann.

Windows 3.11, das auf DOS aufsetzt, hatte auch kein Multitasking und war "vernünftig bedienbar"

Markus W. schrieb:

Wenn grafisch würde ich gerne mit einer IDE Arbeiten also käme ja MFC in frage.

Mit VS und MFC kannst Du dir ein Grundgerüst für eine grafische Anwendung generieren lassen, z.B. eine Dialogbox. Steuerelemente lassen sich per Drag'n'Drop einfügen und VS erzeugt Handler-Funktionen für Butten-Klicks, Menü-Klicks, usw.

Also was wäre denn für meine Anwendung besser geeignet, Konsole oder MFC. Wenn MFC gibt es da ein gutes Tutorial? Das einzig brauchbare, was ich gefunden habe ist dieses, aber das basiert auf einer Veralteten Version von VS.

http://www.henkessoft.de/C++/MFC/mfc_einsteigerbuch_kapitel1.htm

SeppJ

Z schrieb:

SeppJ schrieb:

Der Punkt ist nur, dass man ohne Multitasking keine vernünftig bedienbare grafische Oberfläche bauen kann.

Windows 3.11, das auf DOS aufsetzt, hatte auch kein Multitasking und war "vernünftig bedienbar"

Komisch, dann müssen die das Feature wohl wieder entfernt haben. Windows 1.0 konnte noch Multitasking...

Also das Tutorial hilft mir leider auch nicht weiter, da alles total anders geworden ist in der 2008 Version.

Was wäre denn nun für mein Vorhaben einfacher? In der Konsole bleiben? Wenn ja wie kann ich dann ein Menü programmieren, was unabhängig vom Rest arbeitet, also wo im Hintergrund quasi die Hauptschleife ganz normal weiter arbeitet?
Oder ist es vlt. doch einfacher so ein Programm mit Visual Studio und MFC aufzubauen?

SeppJ schrieb:

Z schrieb:

SeppJ schrieb:

Der Punkt ist nur, dass man ohne Multitasking keine vernünftig bedienbare grafische Oberfläche bauen kann.

Windows 3.11, das auf DOS aufsetzt, hatte auch kein Multitasking und war "vernünftig bedienbar"

Komisch, dann müssen die das Feature wohl wieder entfernt haben. Windows 1.0 konnte noch Multitasking...

Das halte ich für ein Gerücht. Beide liefen unter MS-DOS. Multitasking konnten erst die Windows-NT Versionen. Hattest Du eine Endlosschleife in ein Windows-Programm unter 3.11, dann hing der ganze Computer fest.

Markus W. schrieb:

Was wäre denn nun für mein Vorhaben einfacher? In der Konsole bleiben? Wenn ja wie kann ich dann ein Menü programmieren, was unabhängig vom Rest arbeitet, also wo im Hintergrund quasi die Hauptschleife ganz normal weiter arbeitet?
Oder ist es vlt. doch einfacher so ein Programm mit Visual Studio und MFC aufzubauen?

Ich finde Menüs sind einfacher unter Windows. Mit VS2008 sollte es auch möglich seine, eine MFC-Dialoganwendung zu erzeugen (Ich habe nur VS2005, damit gehts definitiv).
Du brauchst aber die Vollversion. In der Express Edition sind die MFC nicht enthalten.

Nexus

Als Einstieg in die OOP würde ich nicht gerade mit GUI anfangen. In C++ gibt es viele GUI-Frameworks, und ein grosser Teil davon benutzt fragwürdiges und veraltetes, hässliches C++. Damit würdest du dir wahrscheinlich schlechte Dinge angewöhnen, zumal du noch nicht wirklich ein Gefühl für "schönes Design" hast.

Wenn du wirklich parallel programmieren willst, kannst du Threads benutzen. Aber nur "um den Computer ausgelastet zu haben", auch wenn du die Leistung eigentlich gar nicht benötigst, würde ich das nicht tun. Denn Programmierung mit Threads ist nicht ganz trivial.

Falls du dich doch für diesen Weg entscheidest: Ich kenne zwei plattformunabhängige Bibliotheken, die Funktionalität für Multithreading bereitstellen. Zum einen wäre das Boost, eine Sammlung diverser C++-Bibliotheken, die den Schwerpunkt auf die Sprache selbst legt. Zum anderen hättest du mit SFML ein Multimedia-Framework, das neben Threads auch Funktionalität für 2D-Grafik, Sound und Netzwerk anbietet.

SeppJ

Z schrieb:

SeppJ schrieb:

Z schrieb:

SeppJ schrieb:

Der Punkt ist nur, dass man ohne Multitasking keine vernünftig bedienbare grafische Oberfläche bauen kann.

Windows 3.11, das auf DOS aufsetzt, hatte auch kein Multitasking und war "vernünftig bedienbar"

Komisch, dann müssen die das Feature wohl wieder entfernt haben. Windows 1.0 konnte noch Multitasking...

Das halte ich für ein Gerücht. Beide liefen unter MS-DOS. Multitasking konnten erst die Windows-NT Versionen. Hattest Du eine Endlosschleife in ein Windows-Programm unter 3.11, dann hing der ganze Computer fest.

Ich habe nicht gesagt, dass sie es gut konnten. Aber schon die erste Windows Version konnte im Prinzip mehrere Programme ausführen. Und was viel wichtiger ist: Schon damals erlaubte es dem Programmierer, sich sich nicht selber um die grafischen Fensterobjekte kümmern zu müssen, sondern dass die zu den Fensterteilen gehörenden Funktionen bei Benutzung automatisch aufgerufen werden. Dies ermöglicht erst, komplexe GUIs zu schreiben. Man kann sowas natürlich selber schreiben. Habe ich auch schonmal, aber das ist wirklich kein Spaß.

SeppJ schrieb:

Ich habe nicht gesagt, dass sie es gut konnten. Aber schon die erste Windows Version konnte im Prinzip mehrere Programme ausführen.

Ja, aber nur wenn die WndProc, die die Messages abhandelt, auch wieder verlassen wurde. Esrt dann hat Windows die WndProc der nächsten Anwendung bedient. Es war "Multitasking", wenn alle Anwendungen mitspielen. Zeigte sich Eine störrisch, dann ging garnichts mehr. :p

Nexus

SeppJ schrieb:

Schon damals erlaubte es dem Programmierer, sich sich nicht selber um die grafischen Fensterobjekte kümmern zu müssen, sondern dass die zu den Fensterteilen gehörenden Funktionen bei Benutzung automatisch aufgerufen werden.

Das geht eigentlich gut ohne Threads, wenn die GUI-Komponenten hierarchisch aufgebaut sind und klare Zuständigkeiten haben. Dann hat der Benutzer eine Hauptschleife, in der eine GUI-Funktion aufgerufen wird, die sich um den Rest kümmert.

Nebenläufigkeit bei GUIs ist vor allem dann wichtig, wenn rechenintensive Vorgänge laufen, während der Benutzer mit der Oberfläche interagieren soll. Oder sonstige Routinen, die am Stück laufen müssen und denen es nicht ausreicht, einmal pro Frame die Kontrolle zu erhalten.

Also ich habe gerade mal ein Wenig mit Visual Studio herum gespielt und eigentlich komme ich damit recht gut zurecht. Mit so einem Programm hat man halt sehr schnell eine lauffähige GUI aufgestellt. In der Konsole braucht man ja schon für das Menü eine gewisse Zeit. So erstelle ich einen Button und kann festlegen, was passieren soll, wenn ich drauf klicke.
Also ist mir auf jeden Fall wichtig, dass wenn die Oberfläche läuft permanent noch im Hintergrund mit dem Mikrocontroller kommuniziert werden kann.
Ich habe jetzt mit Visual Studio eine Windows Form Anwendung erstellt. Wie kann ich denn da jetzt in die Hauptschleife meine Kommunikation einbauen, die im Hintergrund erfolgen soll?

Ah ich habe gerade entdeckt im Visual Studio gibt es direkt ein Tool "Background Worker" das scheint genau das zu sein, was ich suche.

Markus W. schrieb:

Ah ich habe gerade entdeckt im Visual Studio gibt es direkt ein Tool "Background Worker" das scheint genau das zu sein, was ich suche.

Ja, das hört sich verdächtig nach einem separaten Thread an, den Du für Hintergrundprozesse verwenden kannst. Du scheinst eine gute Auffassungsgabe zu haben, weil Du mit Vs schnell zurechtkommst. Mach weiter so, experimentiere und spiel damit rum. Bei Unklarheiten kosultiere Google mit den passenden Stichwörtern.