Hi Zusammen,
ich muss für ein Projekt eine Benutzerobfläche für ne
Mikroprozessorsteuerung basteln. Da die Hauptsächlich von Medizinern
bedient wird, sollte es möglichst selbsterklärend sein.
Dafür wurde mir das Visual Studio 2010 Professional zur Verfügung
gestellt, was ich natürlich auch gerne verwenden würde.
Nur stellt sich nun die Frage, wo man den besten Einstieg dafür findet.
Gibt es irgendwelche guten Tutorials oder Übungen, die einem da bissi
helfen?
(Ach ja, Programmiersprache ist C)
Vielen Herzlichen Dank schon mal!!!
Gruß
p.S.: Nur um vor zu beugen, habe schon etliche Zeit mit dem Herrn Google
verbracht, aber leider nix gscheids gefunden.
> Ach ja, Programmiersprache ist C
GUI-Programmierung hat nix mit der Programmiersprache zu tun. Du musst
erstmal entscheiden, was du möchtest. Auch eine Konsolenapplikation kann
eine (rudimentäre) GUI implementieren und trotzdem intuitiv sein :)
Ich würde vorschlagen du liest dich in Windows.Forms und WPF ein und
entscheidest welches besser zu deinem Projekt passt - ich würde fast
vermuten WPF.
> Nur um vor zu beugen, habe schon etliche Zeit mit dem Herrn Google> verbracht, aber leider nix gscheids gefunden.
Kommt drauf an was du erwartet hast. Genau deine Problemstellung wirst
du nicht finden, nur Grundsätze, was man wie tun sollte und was zu
vermeiden ist - z.B. sollte die Programmlogik im Idealfall von der GUI
losgelöst sein, was ein Grundsatz von WPF ist.
Was du brauchst ist erstmal n Block und n Stift sowie eine genaue
Beschreibung der Software. Und dann malste einfach mal auf, welche
Funktion wie erreichbar ist (sein soll / sein sollte) und überlegst dir
ob das intuitiv ist. Und zieh ruhig auch Symbole in Betracht (aber sorg
dafür dass es nicht klickibunti wird).
Ralf
Das hier ist sehr gut und bietet Schritt-für-Schritt Beispiele für den
Einstieg in Oberflächenprogrammierung mit C++/MFC. Laß dich nicht davon
abschrecken, daß es schon sehr alt ist. An der MFC hat sich (fast)
nichts geändert. Der Autor, David Kruglinsky, ist leider in den späten
90er Jahren beim Drachenfliegen tödlich verunglückt. Ich kenne kein
späteres Werk, das didaktisch so gut aufgearbeitet ist (ist aber auch
immer Geschmackssache).
http://www.amazon.de/Inside-Visual-6-0-m-CD-ROM/dp/3860634615
Ralf schrieb:>> Ach ja, Programmiersprache ist C> GUI-Programmierung hat nix mit der Programmiersprache zu tun.
GUI ansich natürlich nicht, aber die Programmiersprache schränkt schon
mal die zur Verfügung stehenden GUI-APIs/Frameworks ein. Mit C kannst du
schon mal zwischen der WinAPI oder GTK+ wählen (die hab ich mal im
Gedächnis, du findest sicher noch andere). Allerdings ist C und GUI so
eine Sache, sehr "unschön" zu verwenden und möglicherweise auch
aufwändig. Wenn du C++ kannst, dann nimm das, da hast du richtig gute
GUI-Frameworks wie MFC oder Qt (und eine Menge andere sehr gute).
Bevor du planen kannst, wie die GUI aussehen und sich zu verhalten hat,
musst du dich für eine Technologie (GUI-API) entscheiden, weil sich alle
APIs anders verhalten und anders aussehen.
Bist du sicher, dass es C sein soll? Für eine GUI Anwendung?
Damit machst du dir das Leben nur unnötig schwer. Mit einer High-Level
Sprache bist du vermutlich besser bedient (C# oder VB.NET). Da geht dann
auch die GUI Erstellung ohne größeren Aufwand über den Visual Studio
Designer.
http://letmegooglethatforyou.de/?q=microsoft+visual+studio+tutorial
Wenn man dann (im ersten link) nicht rafft das msdn eine Hilfebibliothek
ist für microsoft visual studio und all seinen sprachen. dann weiß ich
auch nicht.
Ok früher war das beim installer dann also option das auf die platte zu
installieren aber... früher dürfte dir die das auch nix geholfen haben
:)
So dann schaue man sich auf der seite um.
Oh was sieht man. Geil da gibts ja Videos und die sind alle für
unterschiedliche Themen.
Oh die sind aber für 2008! Hm.
dann geh ich doch mal rechts auf die Schlagwortlist unter
VIDEOANLEITUNGEN!!!
So und wenn man dann nicht auf der seite landet wo es zum kotzen viele
Videos und Samples und alles noch so schön strukturiert findet, weiß ich
auch nicht mehr
http://msdn.microsoft.com/de-de/default.aspx
viel spaß
Ulli N. schrieb:> Das hier ist sehr gut und bietet Schritt-für-Schritt Beispiele für den> Einstieg in Oberflächenprogrammierung mit C++/MFC. Laß dich nicht davon> abschrecken, daß es schon sehr alt ist. An der MFC hat sich (fast)> nichts geändert. Der Autor, David Kruglinsky, ist leider in den späten> 90er Jahren beim Drachenfliegen tödlich verunglückt. Ich kenne kein> späteres Werk, das didaktisch so gut aufgearbeitet ist (ist aber auch> immer Geschmackssache).>> http://www.amazon.de/Inside-Visual-6-0-m-CD-ROM/dp...
Also ich würde heute keine MFC mehr anpacken, es war MS erster Versuch,
die API objektorientiert zu kapseln, weil seinerzeit Borland mit dem
CBuilder schon weitaus komfortableres Programmieren ermöglichte.
Auch wenn die aktuellen VS-Versionen MFC noch unterstützen, würde ich
als Einstieg direkt in eine .NET-Sprache die wertvolle Zeit investieren,
statt später dann noch einmal umsatteln zu müssen - zumindest unter
Windows.
Hi,
achso, des ist jetzt bissi falsch rüber gekommen mit dem C bzw. falsch
beschrieben worden.
Also ich habe für den uC bereits ein Programm in C geschrieben, dass
auch funktioniert. Bisher habe ich es über Teraterm gesteuert, was den
Herren aber zu kompliziert oder was weiß ich was ist.
Letztendlich ist das Prog. nicht so kompliziert, es werden lediglich ein
paar Variablen geändert, um PWM-Zeiten zu variieren oder ähnliches.
Dafür wird aber eine schöne Benutzeroberfläche gewünscht, am besten mit
Dropdown-Menüs etc.
Da das verwendete Programm später ein bissi erweitert werden soll, kommt
mir die Benutzeroberfläche in dem Sinne entgegen, dass ich den ganzen
Begrüßungstext, Anleitung, ... nicht mehr auf dem uC direkt habe und
somit Speicher sparen könnte.
Also zusammengefasst: Die Programmiersprache der Benutzeroberfläche ist
Wurscht, wäre nur cool, wenn man einfach ein C-Programm integrieren
könnte. Und genau dafür würde ich ein Tutorial/Einstieg suchen :)
Tut mir leid, dass ich mich da unklar ausgedrückt habe.
Gruß Max
Wenn das so ist, schau dir doch mal C# und WPF oder WinForms an.
Das dürfte deine Anforderungen recht gut erfüllen und ist relativ
einfach zu verwenden...
Gun B. schrieb:> Also ich würde heute keine MFC mehr anpacken, es war MS erster Versuch,> die API objektorientiert zu kapseln, weil seinerzeit Borland mit dem> CBuilder schon weitaus komfortableres Programmieren ermöglichte.
Du bringst da, so glaube ich, die zeitlichen Zusammenhänge etwas
durcheinander. Die MFC wurde 1992 mit dem C/C++-Compiler 7.0 eingeführt,
den CBuilder aber gab es erst deutlich später. Davor gab es von Borland
nur die OWL, die sich nicht durch besondere Brauchbarkeit auszeichnete
und wohl nicht ohne Grund durch die Delphi-basierte VCL-Architektur
ersetzt wurde.
Komfortables Windows-Programmieren gab es zu 16-Bit-Windows-Zeiten
überhaupt nicht, und was Borland zu Anfangszeiten von 32-Bit-Windows
rausbrachte, war gelinde gesagt Schrott (Borland C++ 4.0 wurde großartig
als 32-Bit-fähig beschrieben, lief aber selbst gar nicht unter
32-Bit-Windows-Versionen).
Nicht, daß ich damit die MFC als was besseres darstellen wollte; wer
heute anfängt, GUI-Programme für Windows zu entwickeln, sollte einen
Bogen um die MFC machen, auch wenn die MFC mit den letzten paar
Compilerrevisionen sogar tatsächlich noch weiterentwickelt wurde.
Stattdessen rate ich zu plattformunabhängigen GUI-Toolkits à la Qt oder
wxWidgets.
Wer nicht in C++ programmieren möchte, der kann natürlich auch das
.Net-Geraffel verwenden (und etwas, was zwar so ähnlich heißt wie C++,
aber damit nicht viel zu tun hat: C++/CLI bzw. "Managed C++").
Rufus Τ. Firefly schrieb:> Wer nicht in C++ programmieren möchte, der kann natürlich auch das> .Net-Geraffel verwenden (und etwas, was zwar so ähnlich heißt wie C++,> aber damit nicht viel zu tun hat: C++/CLI bzw. "Managed C++").
Und in dem Fall würde ich dann sogar von diesem Managed-C++ abraten. Das
war von MS meinem Dafürhalten dazu gedacht, den alten MFC-Hasen den C++
Umstieg auf .Net zu erleichtern bzw. schmackhaft zu machen. Tatsächlich
ist das aber ziemlich unbrauchbar. Wenn schon .Net, dann C# oder
VB-.Net.
So macht dann das ganze .Net (welches zweifellos ein sehr mächtiges und
gut aufgebautes Framework darstellt) wieder Sinn. Aber mit dem
Managed-C++ Geraffel macht das wenig Sinn. C++ eignet sich von seiner
Gesamtkonstruktion nicht wirklich für einen derartigen Einsatz, speziell
dann nicht, wenn man das .Net ausreizen will, bzw. das Programm
hauptsächlich aus GUI besteht. Da ist man dann nur noch am
umkonvertieren um C++ Klassen mit der .Net Welt über Wrapper zu
verheiraten.
Und gerade so GUI-lastige Programme sind eigentlich ein Paradebeispiel
für den Einsatz von VB oder C#.
> Also zusammengefasst: Die Programmiersprache der Benutzeroberfläche> ist Wurscht, wäre nur cool, wenn man einfach ein C-Programm> integrieren könnte.
Ähm. Du verwechselst da was. Du 'integrierst' dein C-Programm überhaupt
nicht. Du schreibst ein Frontend für den PC, welcher zb über eine
serielle Schnittstelle Kommandos zum µC schickt. In welcher
Programmier-Sprache der µC diese Kommandos auswertet, interessiert das
PC-Programm nicht. Die gemeinsame Schnittstelle zwischen dem PC und dem
µC sind die Kommandos bzw. die 'Messages' die zwischen den beiden hin
und her flitzen.
Oder hattest du das ganze so angedacht, dass die GUI auf dem µC-Board
selber läuft? Gibt es dort einen Bildschirm, Maus, Tastatur,
Touch-Screen? Welches BS läuft da drauf? Wie wird dieses Board von VS
unterstützt? Das alles sind Dinge, die in diesem Fall wichtig werden.
Also auf dem µC läuft eben das C-Programm...
Die Verbindung zwischen µC und PC ist mit nem Arduino Bluetoothboard
realisiert worden (weil es in einem Raum ungebunden bewegt werden soll).
Ich merke schon, dass ich an meiner Formulieren ein bissl mehr arbeiten
muss :)
Also der µC sollte möglichst das C-Programm behalten und eben nur die
Variablenänderung von dem PC empfangen und verarbeiten. Für das senden
der Änderungen sollte eben eine Benutzeroberfläche entwickelt werden,
die nicht auf dem µC gespeichert ist, sondern nur an den µC sendet...
Karl Heinz Buchegger schrieb:> So macht dann das ganze .Net (welches zweifellos ein sehr mächtiges und> gut aufgebautes Framework darstellt) wieder Sinn.
Nur leider ist die Software zusammen mit dem .NET Zeugs sehr begrenzt
haltbar. Das Framework 1.1 ist von 2003, wird aber bereits unter Windows
7 x64 von 2009 nicht mehr unterstützt. Das sind gerade mal 6 Jahre! Zum
Vergleich: VB6 Anwendungen (1998) werden noch unter Windows 8 voll
unterstützt.
Und eigentlich ist .NET doch auch schon wieder Schnee vom gestern, wir
haben doch jetzt WinRT. Jedenfalls haben wir das noch so lange, bis es
als zu unsicher erkannt und einfach abgeschaltet wird (wie es gerade mit
den Windows 7 Gadgets und der Vista Sidebar passiert ist, pünktlich zum
Release von 8).
Mox schrieb:> Und eigentlich ist .NET doch auch schon wieder Schnee vom gestern, wir> haben doch jetzt WinRT.
Huch, das kenn ich noch gar nicht.
Ich hab den Umstieg von MFC auf .Net noch gar nicht vollzogen!
(C# war mir als alter C++ Programmierer 'zu umständlich'. Ich hab gern
meine Speicherallokierungen unter Kontrolle, Destruktoren mit denen man
auch arbeiten kann und das meiste aus dem .Net brauch ich sowieso nicht.
Was allerdings nicht heißt, dass ich einem Neueinsteiger in GUI
Programmierung die MFC empfehlen würde)
> Vergleich: VB6 Anwendungen (1998) werden noch unter Windows 8> voll unterstützt.
VB6. ANfangs hab ich mich dagegen gesträubt. Aber nach ein paar
Versuchen festgestellt - das ist gar nicht schlecht.
> Und eigentlich ist .NET doch auch schon wieder Schnee vom gestern, wir> haben doch jetzt WinRT.
Naja, ganz so ist es ja nicht.
WinRT ist nur für Metro-Style-Apps vorgesehen. Desktop-Anwendungen
sollen nach wie vor auf .NET basieren.
Mox schrieb:> Nur leider ist die Software zusammen mit dem .NET Zeugs sehr begrenzt> haltbar. Das Framework 1.1 ist von 2003, wird aber bereits unter Windows> 7 x64 von 2009 nicht mehr unterstützt. Das sind gerade mal 6 Jahre!
aber der aufwand das auf .net2.0 zu portierne ist sehr gering.
Dafür Läuft das Programm aber auf einem ARM Prozessor.
> Vergleich: VB6 Anwendungen (1998) werden noch unter Windows 8 voll> unterstützt.
nein, nicht auf einem ARM.
Boris B. schrieb:>> Und eigentlich ist .NET doch auch schon wieder Schnee vom gestern, wir>> haben doch jetzt WinRT.>> Naja, ganz so ist es ja nicht.> WinRT ist nur für Metro-Style-Apps vorgesehen. Desktop-Anwendungen> sollen nach wie vor auf .NET basieren.
Ja und nein... WinRT ist mehr oder weniger ein aufgefrischtes COM (wer
sich noch daran erinnern kann) und z.T. ein Ersatz für das Win32-API,
Anwendungen können sowohl mit C++/CX (noch eine Erweiterung), C#, VB und
JavaScript entwickelt werden. Das .NET-Framework kann ebenso in
Metro-Apps (jetzt wohl .NET for Windows Store apps genannt) genutzt
werden (mit Einschränkungen), wie Desktop-NET-Anwendungen auf
WinRT-Funktionen zugreifen können...
Das habe ich dann irgendwie anders verstanden. Ich hatte mich auf obige
Grafik bezogen, wo die WinRT APIs eindeutig NICHT unter dem .NET
Framework liegen. Sehr verwirrend das ganze ;-)
(ARgh, warum ist der Anhang jetzt 2x drin? Sorry!)
Diese Graphik ist sowieso irreführend, weil falsch. Sowohl der Internet
Explorer als auch .Net setzen auf Win32 auf und sind keine "daneben"
anzusetzenden Alternativen. Beide nutzen nicht direkte
Kernelschnittstellen, sondern wie alle anderen Usermode-Programme auch
die Win32-API.
Mox schrieb:> Das Framework 1.1 ist von 2003, wird aber bereits unter Windows> 7 x64 von 2009 nicht mehr unterstützt. Das sind gerade mal 6 Jahre!
Und das ist auch gut so!
Ganz ehrlich wer damals mit 1.1 gearbeitet hat, weiß warum. Es ist im
Vergleich zu 2.0 einfach nur Schrott! Es gab nicht einmal Generika und
die WinForms gabs auch nur im alten Win2000 Style ;). Gut so schlecht
war es nicht, es war halt noch nicht ganz ausgereift. Es ist also eine
gute Tat, es nicht mehr zu unterstützen. Außerdem gab es zu der Zeit
auch noch keine großen .NET Programme, da Java damals einfach
ausgereifter war, deshalb wird man es schon verschmerzen können.
Christopher C. schrieb:> Außerdem gab es zu der Zeit> auch noch keine großen .NET Programme,
Beispielsweise von AutoCAD gibt es Versionen, die das Framework 1.1
benötigen. Und die sollen jetzt einfach nicht mehr laufen dürfen, weil
es keine Generika gibt?
Mox schrieb:> Christopher C. schrieb:>> Außerdem gab es zu der Zeit>> auch noch keine großen .NET Programme,>> Beispielsweise von AutoCAD gibt es Versionen, die das Framework 1.1> benötigen. Und die sollen jetzt einfach nicht mehr laufen dürfen, weil> es keine Generika gibt?
Tatsächlich? In dem Fall ist es natürlich blöd, allerdings wird es davon
nicht allzu viele geben.
Zu 1.1:
"Die offizielle Unterstützung für diese Version endete am 14. Oktober
2008, die erweiterte Unterstützung endet am 8. Oktober 2013."
Das war dann wohl zu erwarten.
