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.
:
Verschoben durch User
> 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
Irgendwie fehlen da Monate oder Jahre.. Lass dir's von jemandem zeigen, der's kann.
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...
Angehängte Dateien:
-
clip_image0014.jpg
120 KB
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.
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.