Moin, ich muss endlich mal lernen, kleine Windows-Anwendungen zu schreiben, um etwas komfortabler meine eigene Hardware auszulesen Daten Kommandos per Windows-Knopfdruck senden & empfangen etcpp. Habe bisher "nur" 8-32-bit uCs (C und ASM) programmiert. Anwendung wäre zB über COM Port oder VCP Daten einzulesen und grafisch (einfach, zB Eingangsdaten über Zeit(grob)) darzustellen. Nur, womit, wie anfangen? Es sollte: - möglichst umsonst sein - nah an C sein (noch besser wäre natürlich ANSI-C :-) ). - nicht Gigabytes an Festplattenplatz benötigen Tipps? Danke, X
??? Du kaufst dir ein Buch für C->öffnest den Editor->programmierst Kompilieren kannst du mit dem freien GCC.
X- Rocka schrieb: > Es sollte: > - möglichst umsonst sein > - nah an C sein (noch besser wäre natürlich ANSI-C :-) ). > - nicht Gigabytes an Festplattenplatz benötigen Vielleicht ANSI-C? Z.B. in Form von MinGW: http://www.mingw.org/ Ziemlich nahe an C (weitgehend abwärtskompatibel) ist C++ (MinGW, Visual C++). Damit sind GUIs leichter zu programmieren. Einige GUI-Bibliotheken setzen C++ sogar voraus.
Yalu X. schrieb: > Einige GUI-Bibliotheken > setzen C++ sogar voraus. Wobe "einige GUI-Bibliotheken" vor allem voraussetzt, daß man solche überhaupt hat, Wws bei "möglichst kostenlos" nicht immer der Fall ist. Ohne wird es arg mühsam. Am schnellsten kommt man mE. für ein paar Buttons etc. mit Java ans Ziel (oder mit Visual Basic, aber das ist nicht jedermanns Sache). Ob Java mit Sun's NetBeans oder mit Eclipse, ist Geschmackssache. Oliver
Zwar kann man Windows-Programme auch in klassischem ANSI-C (resp. C89/C99) schreiben, aber sobald sie eine Programmoberfläche mit Dialogen, Knöpfen etc. bekommen sollen, wird das ziemlich aufwendig. Ein großes Problem hierbei ist der Paradigmenwechsel zwischen der gewohnten Ablaufprogrammierung und der ereignisorientierten Programmierung, die Windows erforderlich macht. Eine gute und ausführliche Einleitung in das Thema bietet das Buch "Programming Windows" von Charles Petzold. Spätestens nach der Lektüre dieses Buches versteht man, warum C++ mit Klassenbibliotheken eine gar nicht so schlechte Idee ist ...
Eine sehr nützliche Sprache wäre AutoIt. Nachteil: langsam und BASIC-ähnlich, nur für Windows Vorteil: gratis, braucht wenig Platz auf der Platte, kann so ziemlich alles
Rufus Τ. Firefly schrieb: > Eine gute und ausführliche Einleitung in das Thema bietet das Buch > "Programming Windows" von Charles Petzold. Oliver schrieb: > Am schnellsten kommt man mE. für ein paar Buttons etc. mit Java ans Ziel > (oder mit Visual Basic, aber das ist nicht jedermanns Sache). Ob Java > mit Sun's NetBeans oder mit Eclipse, ist Geschmackssache. Yalu X. schrieb: > Vielleicht ANSI-C? Z.B. in Form von MinGW: > > http://www.mingw.org/ Danke schon mal, werde ich mir alles ankucken! Hmmm, Java?
Oliver schrieb: > Am schnellsten kommt man mE. für ein paar Buttons etc. mit Java ans Ziel > (oder mit Visual Basic, aber das ist nicht jedermanns Sache). Ob Java > mit Sun's NetBeans oder mit Eclipse, ist Geschmackssache. Wenn dann schon die besser passende Variante ohne VB, also C# + .NET. Entweder mit dem Visual Studio Express oder mit SharpDevelop (http://www.icsharpcode.net/OpenSource/SD/Download/)
Hi, man sollte sich vielleicht auch nochmal Qt anschauen. Integriert ins Visual Studio via Plugin ist das derzeitig mein Favorit. Gruß
X- Rocka schrieb: > Es sollte: > - nah an C sein (noch besser wäre natürlich ANSI-C :-) ). GUI-Programmierung mit ANSI-C ist was für Leute, die kein Schmerzempfinden haben. Natürlich musst du machen, was du selber willst, aber nur um ein bisschen Hardware auszulesen, würde ich es mir so einfach wie möglich machen und C# nehmen. > - möglichst umsonst sein Visual C# Express 2010 > - nicht Gigabytes an Festplattenplatz benötigen Warum nicht? Wenn man in einem Bruchteil der Zeit fertig werden kann, ist der Plattenplatz doch völlig schnurz, oder?
willibald schrieb: >> - nicht Gigabytes an Festplattenplatz benötigen > Warum nicht? Wenn man in einem Bruchteil der Zeit fertig werden kann, > ist der Plattenplatz doch völlig schnurz, oder? Nein, das ist keinesfalls "schnurz". Klar, Du bist in einem Bruchteil der Entwicklungszeit fertig. Oftmals zahlst Du dafür aber bei jedem Programmstart und bei der Ausführungszeit -jedesmal ein wenig- an Zeit drauf. Im Endeffekt kann es effektiver sein, in die Entwicklung zu investieren.
Beim "Gigabyte" Problem geht's eher um meinen ziemlich vollen Arbeitsrechner... Kann mir jemand in max. 3 Sätzen den Unterschied zwischen C++ und C# nennen? Bitte! :)
Bei C++ ist an zweiter und dritter Stelle je ein '+'. Bei C# ist an zweiter Stelle ein'#'. Eine dritte Stelle gibt es bei C# nicht. :)
X- Rocka schrieb: > Kann mir jemand in max. 3 Sätzen den Unterschied zwischen C++ und C# > nennen? Oh oh.. Mit der Frage wirst du vermutlich (zumindest nach meiner Erfahrung mit den Leuten hier) den totalen Flamewar vom Zaun brechen. Besser ist vermutlich, wenn du dir dein eigenes Bild machst. Wikipedia ist da sehr hilfreich. Und, selbst ausprobieren auf jeden Fall empfehlenswert. Es gibt für beide Sprachen kostenlose Entwicklungsumgebungen. Mein persönlicher Favorit ist C#. Hab mal mit c und c++ angefangen, aber mit c# komme ich deutlich schneller zu Lösungen und ich fühle mich mit c# einfach viel viel wohler, als mit c++. Kurz nen paar Unterschiede: In c# basiert alles, ja, wirklich alles, auf Klassen. Sogar Wertetypen, wie integer sind Klassen. In c# gibt es keine Pointer mehr. (nicht ganz richtig, aber der Bruttonormalprogrammierer braucht sie nicht mehr) Die Weiterentwicklung von c# wird in erster Linie von einer Firma gesteuert. Das hat zur Folge, dass hinter der Sprache und der Weiterentwicklung ein Konzept steht. (Wird c++ eigentlich noch weiter entwickelt, oder nur ergänzt durch neue Bibliotheken?) Du merkst schon, ich bin Fan von c#. Sicherlich gibt es mindestens genau so viele tolle Gründe, die für jede beliebige andere Sprache stehen. Schlussendlich musst du für dich entscheiden, womit du am besten klar kommst. Wenn du nur einfache Windowsanwendungen programmieren willst, tut das so ziemlich jede Sprache...
Sven H. schrieb: > Wird c++ eigentlich noch weiter entwickelt Selbstverständlich: http://en.wikipedia.org/wiki/C%2B%2B0x
Sven H. schrieb: > Kurz nen paar Unterschiede: Und noch einer: C# verwendet im Gegensatz zu C++ eine sogenannte "verwaltete" Laufzeitumgebung. Das heißt, dein Programm erzeugt seine Objekte so, wie es sie braucht (mit new), gibt sie aber nicht mit delete wieder frei, sondern lässt sie einfach fallen. Was in C++ ein schlimmer Fehler ist (Speicherleck), ist in C# das Normalste von der Welt, denn es gibt einen Garbage-Collector, der sich um alle runtergefallenen Objekte kümmert und sie wegräumt. Das hat zwei große Vorteile: 1. Speicherfehler (vergessenes delete oder mehrfaches delete) können nicht mehr auftreten 2. Das Zerlegen alter Objekte findet dann statt, wenn das System etwas freie Zeit hat und nicht dann, wenn der Programmierer meint, das tun zu müssen. Das verringert kurzzeitige Lastspitzen und sorgt für eine insgesamt bessere Performance (solange das System Speicherreserven hat). Wahr ist, dass im Mittel mehr Speicher belegt ist als bei Systemen ohne Garbagecollector. Für manche Leute ist diese Tatsache unerträglich, andere nehmen das angesichts der Vorteile ohne Zögern in Kauf.
Treffend gesagt - es sollte aber auch nicht unerwähnt bleiben, daß (hier droht schon der nächste Flamewar, ist klar) mit C# + .NET keine monolithischen Applikationen erzeugt werden können. Vom USB-Stick starten und läuft? Ist nicht. Das Framework ist immer erforderlich, und kann nicht "eingelinkt" werden. Für meine Anwendungen ein absolutes Ausschlußkrierium, aber bei großen Projekten als Problem vernachlässigbar.
willibald schrieb: > GUI-Programmierung mit ANSI-C ist was für Leute, die kein > Schmerzempfinden haben. Hast du denn schon einmal ein GUI für Windows in C programmiert? Arg viel schlimmer als das, was danach kam (C++ mit MFC), ist das gar nicht. Gerade bei anspruchsvolleren GUI-Anwendungen ist der Unterschied in der Quellcodegröße nicht riesig. Die einzige wesentliche Neuerung war die automatische Generierung von dem sowohl für WinAPI als auch MFC leider unvermeidlichen Boilerplate-Code, was aber keine Errungenschaft von MFC oder C++, sondern von Visual Studio war. In C musste man eben mehr Copy/Paste machen. Sicher hat sich das mittlerweile mit Windows Forms, WPF und was es da sonst noch so alles gibt, deutlich geändert. Nur hätte dann deine Aussage richtigerweise lauten müssen: "GUI-Programmierung mit GUI-Bibliotheken vor Windows Forms und WPF ist was für Leute, die kein Schmerzempfinden haben." :)
Ich benutze für sowas Code Blocks. Das ist frei erhältlich sogar mit c++ compiler. Beim erstellen des Projektes gibst du an was es werden soll (konsolenprogramm, Gui usw) Hilfe für eine kleine Gui findendest du massenweise im netz! Grüße :-)
Ich habe vor ein paar Wochen angefangen mich mit C# zu beschäftigen und komme mittlerweile gut klar und kann einiges damit erreichen. Zuvor habe ich nur uC in C programmiert (AVR, C2000). Das Galileo Openbook zum Thema ist nicht schlecht - kann ich als Einstieg auf jeden Fall empfehlen. Ich hatte auch lange überlegt ob C++ oder C# und habe mich für letzteres entschieden, da mir der Einstieg einfacher erschien. Klar: wirklich plattformunabhängig ist das Ganze nicht, aber muss man das wirklich immer sein? Und die IDE (Visual Studio) ist IMO klasse.
Yalu X. schrieb: > willibald schrieb: >> GUI-Programmierung mit ANSI-C ist was für Leute, die kein >> Schmerzempfinden haben. > > Hast du denn schon einmal ein GUI für Windows in C programmiert? Arg > viel schlimmer als das, was danach kam (C++ mit MFC), ist das gar nicht. Der "alte" Petzold hat Windows-Programmierung mit Hilfe der reinen Win32-API eigentlich recht plausibel und sehr schön nachvollziehbar erlärt (ein tolles Buch). Für geübte C-Programmierer ist das denke ich eingängiger als sich in C++, also das programmieren in Klassen mit allem was dazu gehört, reinzufuchsen. Zumindest kleinere Progrämmchen bleiben da noch überschaubar. Kann man noch immer gelegentlich gut benutzen. Für kleinere Tools genügt oftmals auch ein Konsolenprogramm. Auch dort lässt sich schön die Win32-API einsetzen (falls Windows genügt und es nicht auch noch unter Linux laufen soll). Und ansonsten lohnt C# eine Einarbeitung auf jeden Fall. Ich glaube das ist um Windows Programme zu erstellen im Endeffekt leichter zu erlernen und weniger fehlerträchtig als C++.
Platinenschwenker .. schrieb: > Der "alte" Petzold hat Windows-Programmierung mit Hilfe der reinen > Win32-API eigentlich recht plausibel und sehr schön nachvollziehbar > erlärt (ein tolles Buch). Absolut. Ich habe die Ausgabe fuer Windows 3.1 1993 geholt. Ich frage mich, ob managed Code (Java, C#) irgendwann auch für Mikrocontroller / embedded programming der Standard wird.
Platinenschwenker .. schrieb: > Der "alte" Petzold hat Windows-Programmierung mit Hilfe der reinen > Win32-API eigentlich recht plausibel und sehr schön nachvollziehbar > erlärt (ein tolles Buch). Das trifft zwar zu, aber Windows-Programme in C zu schreiben steht kaum über dem Programmieren von Windows-Programmen in x86-Assembler. Der Petzold ist wichtig, um zu verstehen, wie Windows funktioniert, und das wiederum ist wichtig, um zu verstehen, was eine Klassenbibliothek wie die MFC macht, und das wiederum ist wichtig, um damit halbwegs erträgliche Programme hinzubekommen. Ich spreche hier von mehreren Jahren harter Einarbeitungszeit. Wer sich all das nicht antun will, sollte eine Klassenbibliothek oder Programmierumgebung verwenden, die weitere Abstraktionsschichten vorsieht, wie es einerseits die verschiedenen .Net-Ansätze (WinForms, Silverlight etc.) vornehmen, wie es andererseits auch im Qt umgesetzt wird.
Rufus Τ. Firefly schrieb: > Platinenschwenker .. schrieb: >> Der "alte" Petzold hat Windows-Programmierung mit Hilfe der reinen >> Win32-API eigentlich recht plausibel und sehr schön nachvollziehbar >> erlärt (ein tolles Buch). > > Das trifft zwar zu, aber Windows-Programme in C zu schreiben steht kaum > über dem Programmieren von Windows-Programmen in x86-Assembler. Das geht in der Tat per invoke auch ganz prächtig http://www.movsd.com/masm.htm Ist aber nach meinem Gefühl etwas schlechter überschaubar als ein Gründgerüst mit C-Construct. > Der Petzold ist wichtig, um zu verstehen, wie Windows funktioniert, Ganz bestimmt. Großartiges Buch. > Wer sich all das nicht antun will, sollte eine Klassenbibliothek oder > Programmierumgebung verwenden Wäre der modernere Weg.
C# Beginner schrieb: > Ich frage mich, ob managed Code (Java, C#) irgendwann auch für > Mikrocontroller / embedded programming der Standard wird. Abgesehen von iOS sind (die meisten) Anwendungen z.B. für Android, webOS und Windows Phone 7 managed Code (Java, Javascript bzw. C#/VB/F#). (auch wenn ObjC mittlerweile Garbage Collection kennt) Für kleinere Systeme gibt's z.B. das .NET Micro Framework (vollständig unter Apache-Lizenz). Klein im Sinne von 32-Bit Microcontrollern mit min. 256 kiB-Flash und 64 kiB-RAM (was mittlerweile viele neuere Controller erfüllen)...
Arc Net schrieb: > Klein im Sinne von 32-Bit Microcontrollern mit > min. 256 kiB-Flash und 64 kiB-RAM (was mittlerweile viele neuere > Controller erfüllen)... Zu embedded zählt man aber auch die 8-bit (z.B. Atmel) und 16-bit. Und diese werden wohl die Masse aller embedded Hardware ausmachen. Wann werden wohl die Kaffeemaschinen mit managed code programmiert werden?
C# Beginner schrieb: > Arc Net schrieb: >> Klein im Sinne von 32-Bit Microcontrollern mit >> min. 256 kiB-Flash und 64 kiB-RAM (was mittlerweile viele neuere >> Controller erfüllen)... > > Zu embedded zählt man aber auch die 8-bit (z.B. Atmel) und 16-bit. > Und diese werden wohl die Masse aller embedded Hardware ausmachen. OT: Ein paar Zahlen: ARM bzw. deren Partner haben alleine im letzten Jahr 6000000000 (6 Mrd) ARM-Controller ausgeliefert... 1) MIPS (nur 32-Bit und 64-Bit): 0.51 Mrd 2) Microchip 1.3 Mrd 3) Gesamtmarkt waren etwa 14 Mrd USD 4) Durchschnittspreis für 8-Bit Controller 0.6 USD 5) D.h. wären das nur 8-Bit Controller gewesen, wären es 24 Mrd Stück Da die 16-Bit und 32-Bit Controller im Schnitt teurer sind, dürfte der Marktanteil von ARM größer als 25% sein. 1) http://www.arm.com/about/newsroom/arm-innovation-further-recognized-with-queens-award-for-enterprise-2011.php 2) http://www.mips.com/media/files/ir/MIPSInvestorPresOctober2010.pdf 3) http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2059&mcparam=en552607 4) http://dataweek.co.za/article.aspx?pklarticleid=6668 5) http://www.avnetondemand.com/Technology%20Trends/Microcontroller+Market+overview+2010/channel/40/video/537/
Danke nochmals an alle Antwortenden! Leider bin ich noch nicht wirklich weiter mit der Entscheidung. Ein Bekannter hat mir nochmal zu Visual Basic geraten, er meint das wäre der einfachste Weg schnell mal ne Windows Oberfläche zu bauen. Eigentlich brauche ich vor allem sowas wie ein Scope für reinkommende Daten, und die Möglichkeit Daten (zB VCP input) umzuformatieren und abzuspeichern. Sowas "schwer" in Visual Basic? Ich kommme einfach noch nicht zum ausprobieren... muss mal ein paar Nachtschichten einlegen...
Mein Tipp Back to the roots .... schau Dir mal freebasic an. Komme auch aus der Controllerwelt und wollte schnell mal ein paar Kommunikationsroutinen für den PC schreiben, ohne viel Einarbeitszeit zu vergeuden. Ging schnell und problemlos mit freebasic. noch einen schönen Tag
Hallo auch, Ich bin nach über 10 Jahren Delphi (= effizient und schnell beliebig komplexe Windows Apps entwickeln) nun auf Visual Studio 2010 C# umgeschwenkt. In ca. 3 Tagen hatte ich schon eine App mit relativ komplexen Funktionen. GUI-bauen nahezu identisch zu Delphi (= sehr effizient / einfach). Einzige Bedingung: WinXP+NET oder gleich Win7. Ich kann mir nicht vorstellen, daß es eine einfacher und effizientere Umgebung für Windows gibt, die den Semi/Hobby-Coder glücklicher macht. BTW: Ich habe quasi eine "alte" Delphi-App nahezu 1:1 nach C#/VStudio portiert. Im Vergleich (gleicher Rechner/OS) ist die Delphi App natürlich um Faktoren schneller; komplexe Tabellen/Grid-Operationen per GUI sind ca. Faktor 10 langsamer per VStudio. (sind halt alles keine echten binaries) Aber einen Tot muß man halt sterben. Ich kann C# speziell für Einsteiger nur empfehlen. Und ja, Eclipse, GCC, Linux, Apple - alles ist besser - wenn man sich einschränken will! Basic hab ich immer vermieden. Wenns wirklich schnell gehen soll, nehme ich AutoIt+Scite (= kleine, schnell, "compilierbar", aber stark limitiert bei GUI und komplexeren Systemzugriffen) Achja, die verfügbare "internet Community" darf man auch nicht unterschätzen. Bei M$ mit C# gibt es massenhaft Code den man einfach so aus dem INet ziehen kann. greez, lou
Dann schau dir auch mal Tcl/Tk an. Damit kann man sehr schnell ein GUI bauen. Kann wunderbar mit der seriellen Schnittstelle umgehen. Ist plattformunabhängig.
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.