Hallo, ich habe vor ca. 12 Jahren ein paar kleine Windows Programme mit Visual Studio erstellt. Nun hätte ich wieder eine Aufgabe: Empfang von Daten und Speichern in Dateien. Das Fenster soll folgende Felder haben: * Auswahl COM-Schnittstelle * Auswahl Baudrate * Checksumme ja/nein * Auswahl Pfad, in dem die Dateien gespeichert werden sollen * Button Start/Stopp * Tabelle, in dem die Empfangsdateien aufgelistet werden, mit folgenden Spalten: - Dateiname - Übertragungsfortschritt als Balken - Status (z.B. Fehlermeldungen) (wenn das mit Tabelle zu aufwändig wird, würde auch das Ganze mit einer Zeile reichen -> der aktuelle Datensatz, der übertragen wird) Ich würde nach und nach Daten über die Schnittstelle an das Programm senden. Der Aufbau des Datenstreams wäre wie folgt: 1. Header mit Dateiname, Datenlänge, Checksumme des Headers 2. Daten (die in der Datei gespeichert werden sollen) 3. Ende-Kennung mit Checksumme über die Daten. Eventuell noch Rückmeldung an den Sender, ob es geklappt hat. 4. nächstes Datenpaket, beginnend wie 1 Das Ganze soll mindestens auf Windows 10 laufen. Ich würde Visual Studio 2022 verwenden. Wäre es sinnvoll, das mit Visual Basic zu realisieren? Oder gibt es auch "einfachere" Möglichkeiten? Ich habe bisher nur Erfahrung in Programmierung mit C (nicht C++). Und etwas Visual Basic.
Nimm lieber C und besorg dir ein passendes Buch vom Charles Petzold.
Rbx schrieb: > Nimm lieber C und besorg dir ein passendes Buch vom Charles Petzold. Aber bei C kann man doch die Fenster nicht mit Drag&Drop gestalten, oder?
Micha schrieb: > Wäre es sinnvoll, das mit Visual Basic zu realisieren? Das würde ich zu 100% mit "ja" beantworten. Ich habe ein paar Jahre VB programmiert und dafür ist es sehr gut geeignet. Und es nimmt einem sehr viel Arbeit ab. Die Empfehlung von "C" ist eher ein schlechter Scherz. Kann nur Ironie gewesen sein. Geht ja, aber..... Wenn dann C#, wäre auch gut geeignet.
:
Bearbeitet durch User
Micha schrieb: > Das Ganze soll mindestens auf Windows 10 laufen. Ich würde Visual Studio > 2022 verwenden. Wäre es sinnvoll, das mit Visual Basic zu realisieren? Ich programmiere seit Jahren in C# und für Windows ist für mich die erste Wahl. Wenn Du C kannst, kommst Du in die Sprache schnell rein. OOP ist noch ein anderer Schnack. "Alte Hasen" haben damit eher mehr Probleme als Junge, die direkt damit anfangen. Aber bei C# stehst Du vor der Entscheidung für Windows Forms (lange veraltet, aber schnell und leicht verständlich) oder WPF mit XAML. Ich habe mich lange gegen letzteres gewehrt, ist eher schwieriger, mehr Lernaufwand und manchmal "Pain in the ass...". Halt hübscher für Klicki-Bunti. Bin gespannt auf die Empfehlungen der anderen, aber wenn es für mich schnell gehen muß, nehme ich immer noch die Winforms. Bedenke, dass Du das COM-Control von Hand nachinstallieren musst. Es ist nicht von Haus aus im C#-Workload enthalten. Viel Spaß dabei!
Angehängte Dateien:
900ss schrieb: > Das würde ich zu 100% mit "ja" beantworten. Ich werde es mal probieren. Ich habe aber nun das Problem, dass beim Erstellen von Visual Basic nichts zur Auswahl erscheint (siehe Bild). Was muss ich bei dem Link dann zum Installieren auswählen? Ich babe da auf die Schnelle nichts mit "Visual Basic" gesehen.
Micha schrieb: > Ich babe da auf die Schnelle nichts mit "Visual Basic" gesehen. Dann schau mal genau hin.
:
Bearbeitet durch User
Micha schrieb: > Aber bei C kann man doch die Fenster nicht mit Drag&Drop gestalten Doch, im Visual Studio Dialog Editor. Micha schrieb: > Wäre es sinnvoll, das mit Visual Basic zu realisieren? Nein da du C kannst. ChatGPT verwendet keinen Dialogeditor und schlägt vor: Um ein solches Windows-Programm in C mit Visual Studio zu erstellen, kannst du die Windows API oder MFC (Microsoft Foundation Classes) verwenden. Alternativ kannst du auch WinForms in C++/CLI nutzen, falls du ein Framework suchst. Hier ist eine allgemeine Anleitung zur Umsetzung des Projekts mit Windows API: --- 1. Projekt einrichten 1. Starte Visual Studio und erstelle ein neues Projekt. 2. Wähle Win32 Project oder Windows Desktop Application aus. 3. Stelle sicher, dass du keine vorkonfigurierte Konsole benötigst, sondern eine Windows-Anwendung erstellst. --- 2. Hauptkomponenten Das Programm benötigt folgende Hauptfunktionen: 1. GUI erstellen (Dialogfelder und Buttons). 2. COM-Port ansprechen (z. B. über CreateFile und ReadFile). 3. Dateien speichern (z. B. über fopen oder ofstream). 4. Tabelle aktualisieren (für den Fortschrittsbalken und Status). --- 3. GUI-Design mit Windows API Die Oberfläche wird mit CreateWindow und den zugehörigen Steuerelementen (Controls) aufgebaut. Du kannst folgende Steuerelemente verwenden: Beispiel für die GUI-Komponenten: HWND hComboCOM, hComboBaud, hCheckSum, hEditPath, hBtnStartStop, hListView; // COM-Schnittstelle auswählen hComboCOM = CreateWindow("COMBOBOX", NULL, WS_CHILD | WS_VISIBLE | CBS_DROPDOWN, 10, 10, 200, 300, hwnd, NULL, hInst, NULL); SendMessage(hComboCOM, CB_ADDSTRING, 0, (LPARAM)"COM1"); SendMessage(hComboCOM, CB_ADDSTRING, 0, (LPARAM)"COM2"); // Baudrate auswählen hComboBaud = CreateWindow("COMBOBOX", NULL, WS_CHILD | WS_VISIBLE | CBS_DROPDOWN, 10, 50, 200, 300, hwnd, NULL, hInst, NULL); SendMessage(hComboBaud, CB_ADDSTRING, 0, (LPARAM)"9600"); SendMessage(hComboBaud, CB_ADDSTRING, 0, (LPARAM)"19200"); // Checkbox für Checksumme hCheckSum = CreateWindow("BUTTON", "Checksumme aktivieren", WS_CHILD | WS_VISIBLE | BS_CHECKBOX, 10, 90, 200, 30, hwnd, NULL, hInst, NULL); // Edit-Feld für den Pfad hEditPath = CreateWindow("EDIT", NULL, WS_CHILD | WS_VISIBLE | WS_BORDER, 10, 130, 300, 20, hwnd, NULL, hInst, NULL); // Start/Stopp Button hBtnStartStop = CreateWindow("BUTTON", "Start", WS_CHILD | WS_VISIBLE | BS_PUSHBUTTON, 10, 160, 100, 30, hwnd, (HMENU)ID_BTN_START, hInst, NULL); // Tabelle für Dateien hListView = CreateWindow(WC_LISTVIEW, "", WS_CHILD | WS_VISIBLE | LVS_REPORT, 10, 200, 400, 200, hwnd, NULL, hInst, NULL); --- 4. COM-Port ansprechen Verwende die Windows API, um die serielle Schnittstelle zu konfigurieren. Beispiel für den Zugriff auf einen COM-Port: HANDLE hComm; DCB dcbSerialParams = { 0 }; hComm = CreateFile("COM1", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (hComm == INVALID_HANDLE_VALUE) { MessageBox(NULL, "Fehler beim Öffnen des COM-Ports", "Error", MB_OK); } else { dcbSerialParams.DCBlength = sizeof(dcbSerialParams); GetCommState(hComm, &dcbSerialParams); dcbSerialParams.BaudRate = CBR_9600; // Beispiel-Baudrate dcbSerialParams.ByteSize = 8; dcbSerialParams.StopBits = ONESTOPBIT; dcbSerialParams.Parity = NOPARITY; SetCommState(hComm, &dcbSerialParams); } --- 5. Dateien speichern Die empfangenen Daten kannst du direkt in eine Datei schreiben. Beispiel: FILE *file; file = fopen("output.txt", "w"); if (file) { fwrite(buffer, sizeof(char), bytesRead, file); fclose(file); } --- 6. Tabelle aktualisieren Verwende eine ListView, um die Dateien anzuzeigen. Die Fortschrittsbalken können durch den Fortschritt der Übertragung aktualisiert werden. Hinzufügen eines ListView-Elements: LVITEM lvItem; lvItem.mask = LVIF_TEXT; lvItem.iItem = 0; // Index lvItem.iSubItem = 0; // Spalte lvItem.pszText = "Dateiname.txt"; // Text ListView_InsertItem(hListView, &lvItem); Aktualisieren eines Fortschrittsbalkens: HWND hProgressBar = CreateWindow(PROGRESS_CLASS, NULL, WS_CHILD | WS_VISIBLE, 10, 220, 300, 20, hwnd, NULL, hInst, NULL); SendMessage(hProgressBar, PBM_SETPOS, (WPARAM)progress, 0); --- 7. Event-Handling Im Window-Procedure (WndProc) behandelst du die Events: Button-Klicks Auswahländerungen in den ComboBoxen Empfang von Daten und Fortschrittsaktualisierung. Beispiel: switch (message) { case WM_COMMAND: if (LOWORD(wParam) == ID_BTN_START) { // Empfang starten } break; } --- Zusammenfassung Mit den oben beschriebenen Schritten kannst du das Programm erstellen. Die genaue Implementierung hängt von den Anforderungen ab (z. B. Empfangsprotokoll, Dateiformate, usw.). Für eine vollständige Lösung könntest du auch Bibliotheken wie Boost.Asio in Betracht ziehen, falls du später zu C++ wechseln möchtest.
Franko S. schrieb: > Micha schrieb: >> Ich babe da auf die Schnelle nichts mit "Visual Basic" gesehen. > Dann schau mal genau hin. Jetzt habe ich es gesehen. Manchmal sieht man den Wald vor lauter Bäumen nicht. Nun geht es.
Ich würde auch dazu raten, bei C zu bleiben, denn das kennst du und Windows wurde selbst ebenfalls in C geschrieben. Du kannst also alle Windows Funktionen direkt ohne Schnickschnack aufrufen und du eirst die Programmierbeispiele verstehen. Falls du Lust auf objektorientierte Franeworks hast, dann würde ich eher C# als C++ empfehlen, weil C# sich ernsthaft darum bemüht, einfacher und besser zu sein. Microsoft scheint diese Sprache auch zu bevorzugen.
Lazarus hier hier DAS Mittel der Wahl https://www.lazarus-ide.org/ https://frank-kaden.hier-im-netz.de/homepage/Inter3/info18b.html Deine Programme können damit unter Windows UND Linux usw. laufen, du hast eine vernünftige GUI/RAD bekommt unendlich viel gute Hilfe in den Foren(Im Gegensatz zu C(++ wo dir immer nur empfohlen wird dich damit zu beschäftigen etc) Und es dauert nur Minuten, das erste Grundgerüst stehen zu haben inkl Oberfläche! Und wenn du später doch unbedingt C lernen willst(brauchst du nicht, wen du es nicht beruflich benötigst) hast du alle Grunderfahrungen bereits in Pascal gesammelt und der Umstieg ist dann einfach. ICh nutze bis heute PAscal programmiere damit auch AVR und ARM(Mikroe Compiler z.B.) ist aber auch mit FreePascal möglich
Sherlock 🕵🏽♂️ schrieb: > Ich würde auch dazu raten, bei C zu bleiben, denn das kennst du und > Windows wurde selbst ebenfalls in C geschrieben. Hmmm..... hast du schonmal ein C-Programm für Windows geschrieben? Das mach ich nie wieder. Umständlicher weil recht low-level geht es nicht. Wenn dann C#, da braucht man sich um vieles nicht mehr kümmern weil es einem einfach abgenommen wird. C hat in meinen Augen nichts mehr in der Anwendungsprogrammierung zu suchen. Dafür gibt es inzwischen Sprachen, die dafür wesentlich besser geeignet sind. C nur für embedded. C#, VB, Python, was weiß ich. Vieles ist besser geeignet als C. Für solch ein kleines Programm wie der TO sich programmieren möchte, würde ich sogar Purebasic nutzen da es z.B. nur ein standalone Executable erstellt und das dann weiter keine Abhängigkeiten hat. Und man kann es ohne Probleme auf Linux portieren. Purebasic läuft auch unter Linux. Und es hat eine hilfreiche IDE auch zum Fenster designen.
Lazarus Pascal und Basic nehmen sich hier nicht. Wobei die GUI von lazarus wohl eine der besten überhaupt ist und auch der Vorteil das man alles in eine exe packen kann(geht bei C wohl auch) aber ist bei Lazraus pascal und Basic ja eigentlich Standard. Python ist für den Zweck blöd, also klar geht ees auch, ist aber immer ein Umweg...mit Pascal, Basic oder C# hat das eher Hand und Fuß:-) Klar, einfach ist Python natürlich auch Und Lazarus funktioniert out of the Boxn, wie # und Basic ebenfalls, keine Fummelei, keine Einrichtung, nichts, runterladen, installieren, benutzen
900ss schrieb: > hast du schonmal ein C-Programm für Windows geschrieben? Ja, vor langer Zeit. > Wenn dann C# Sage ich ja. OOP ist aber nicht jedermanns Sache. Gerade hier im Forum sind auffällig viele, die OOP Sprachen ablehnen. Ich bin bei dir: C# vereinfacht vieles erheblich, wenn man denn bereit ist, sich mit OOP zu beschäftigen.
:
Bearbeitet durch User
Und hat es Spaß gemacht? Oftmals führt sowas in C /++ eher zu Frust, Pascal, und Basic bzw Python machen aber eher Spaß und die erstgenannten sind auch sehr vielseitig einsetzbar, stehen C bzw C++ in nichts nach, zumindest PAscal, wie sich Bsic über die Jahre weiterentwickelt hat, weiß ich nicht genau
Geli schrieb: > Und hat es Spaß gemacht? (Du meinst das Programmieren einer Windows Anwendung in C, nehme ich an.) In meinem Fall war es ein Empfänger für eine IR Fernbedienung für Multimedia Wiedergabe. Das war sehr Systemnah mit rekativ wenig GUI. Ja, es hat Spaß gemacht. Ich würde es heute aber nicht mehr so machen, weil ich OOP in diesem Umfeld bevorzuge.
Micha schrieb: > ich habe vor ca. 12 Jahren ein paar kleine Windows Programme mit Visual > Studio erstellt. > > Nun hätte ich wieder eine Aufgabe: > > > Das Ganze soll mindestens auf Windows 10 laufen. Ich würde Visual Studio > 2022 verwenden. Wäre es sinnvoll, das mit Visual Basic zu realisieren? Wenn du VB kannst, dann nimm VB. Wenn du C kannst, dann nimm das. Sinnvoll ist die Sprache, die du verstehst. Bleib bei deinem alten Visual Studio, die neueren sind nicht unbedingt besser. > Oder gibt es auch "einfachere" Möglichkeiten? Ich habe bisher nur > Erfahrung in Programmierung mit C (nicht C++). Und etwas Visual Basic. Einfacher als VB oder C/C# wird es nicht werden. Ich habe mir den Spass gemacht, und deine Anwendungsbeschreibung mit dem Visual Studio C# GUI Editor umzusetzen. Für 10 Minuten Aufwand und für mein erstes C# Programm ist das Ergebnis gar nicht so schlecht - siehe zip File :-) Auf meinem 4k Monitor schaut das Programm allerdings nicht besonders gut aus - die Fonts sind viel zu klein. Ich muss die DPI Kompatibilitätsssettings händisch auf "Application" setzen, damit alles passt. Als Vergleich habe ich dir ein 250 Zeilen C Programm angehängt, dass ich vor einiger Zeit hier mal veröffentlicht hatte. Das kannst du relativ leicht mit dem Visual Studio GUI Designer anpassen. Gruss Udo
Geli schrieb: > Und hat es Spaß gemacht? Oftmals führt sowas in C /++ eher zu Frust, > Pascal, und Basic bzw Python machen aber eher Spaß und die erstgenannten > sind auch sehr vielseitig einsetzbar, stehen C bzw C++ in nichts nach, > zumindest PAscal, wie sich Bsic über die Jahre weiterentwickelt hat, > weiß ich nicht genau Mir macht es Spass Windows in C/C++ zu programmieren. Ich gebe aber zu, dass ich da keinen Ergebnisdruck habe, ist ein Hobby. Ist auch egal, welche Sprache man verwendet, man muss sich damit gut auskennen, und vor allem muss das GUI Framework gut sein. Der Aufwand in so ein Framework reinzukommen ist viel grösser, als die Sprache zu lernen. Ich habe auch schon mit Tk/Tcl GUIs gemacht, und das war beeindruckend einfach. Ein guter Startpunkt für C/C++ und Windows GUI ist auch das Win32++ Projekt auf Sourceforge. Das ist eine Open Source GUI Lib ähnlich wie Microsoft Foundation Class. MFC ist für technische Anwendungen mit vielen Fenstern und komplizierten Dialogen immer noch sehr gut geeignet. Wobei der kommerzielle Ableger https://codejock.com/downloads/samples/ heute empfehlenswerter ist.
:
Bearbeitet durch User
Udo K. schrieb: > Wenn du C kannst, dann nimm das. Für Windows-GUI-Programmierung ist das allerdings 'ne sehr harte Nummer. Ja, man kann mit der Win32-API in reinem C auch GUI-Programme schreiben, aber die Lernkurve ist hier sehr steil, weil man das nachrichtenbasierte Konzept von Windows verstehen muss, d.h. man muss verstehen, wie man Nachrichtenschleifen schreibt, und eben auch, daß so ein Programm nicht einen klar vorgegebenen Ablauf hat, sondern immer nur auf Ereignisse reagiert und dann auf das nächste Ereignis wartet. Wenn man bislang nur herkömmliche Konsolenprogramme geschrieben hat, dann ist bereits das ein sehr harter Umstellungsprozess. Das ganze in C++ mit einer Klassenbibliothek zu machen, versteckt viel von dem nötigen Code, hilft aber auch nicht beim Verständnis. Und das ganze noch in zusätzliche Abstraktionsebenen zu verpacken, wie es manche plattformunabhängige GUI-Toolkits machen, macht die Sache noch schwieriger bzw. entfernt "die Denke" noch viel weiter von dem, was man mit C mal gelernt hat. Für den Gelegenheitsprogrammierer ist es an dieser Stelle im Grunde genommen egal, ob er sich dann auch gleich 'ne andere Programmiersprache aneignet, das ist dann nur noch etwas syntaktischer Zucker auf einem großen Berg Neuland. Wenn das Ziel das Schaffen von Grundlagenwissen ist, auf dem man die nächsten Jahre aufbauen kann, halte ich die Wahl eines plattformunabhängigen Ansatzes für nicht so besonders schlecht, denn vielleicht möchte man sich ja auch mal mit was anderem als Windows beschäftigen. Und damit sind die ganzen .Net-Varianten 'raus. Zwar gibt es für die auch Portierungen auf andere Betriebssysteme, aber das ist eher nur ein angeflanschter Stummel mit reduziertem Umfang. Wird schon Gründe haben, warum kaum jemand freiwillig .Net jenseits von Windows verwendet und man in freier Wildbahn auch nicht über entsprechende Projekte stolpert. Wenn es nur um ein jetzt-mal-benötigtes Programm geht, und keine sehr langfristige Perspektive dahintersteckt, dann ist der Weg des geringsten Widerstandes zu wählen. Dann kann man sich auch irgendwas mit dem Visual-Studio-Moloch zusammenklicken. Achtung: Nicht miteinander verwechseln, "Visual Studio" und "Visual Studio Code" sind zwei komplett unterschiedliche Dinge. "Visual Studio Code" ist ein universell erweiterbarer Editor, hilft hier aber (ohne viele zusätzliche Dinge) überhaupt nicht. Wenn, dann "Visual Studio" in Form der "Community Edition". Das gibts für lau, und enthält je nachdem, welche Checkboxen man bei der Installation setzt, alles mögliche und noch viel mehr.
Udo K. schrieb: > Wobei der kommerzielle Ableger > https://codejock.com/downloads/samples/ heute empfehlenswerter ist. Das ist kein "kommerzieller Ableger" der MFC, sondern ein kommerzielles auf der MFC aufbauendes Toolkit. Andere ebenfalls auf der MFC aufbauende kommerzielle Toolkits sind https://bcgsoft.com/Products/Bcgcontrolbarpro und https://www.perforce.com/products/stingray Eine Alternative zur MFC selbst hingegen ist wxWidgets (https://www.wxwidgets.org/), das ist gerade für Umsteiger von der MFC ganz gut geeignet, weil die grundlegende Architektur ähnlich ist. Das ist Open Source und plattformunabhängig; ein bekanntes Open-Source-Projekt, das wxWidgets verwendet, ist der Audio-Editor Audacity. Für wxWidgets gibt es auch "language bindings" für andere Programmiersprachen, das lässt sich beispielsweise mit Ruby oder Python verwenden.
Harald K. schrieb: > weil man das nachrichtenbasierte Konzept von Windows verstehen muss Ich denke, das gehört unabhängig von der Programmiersprache zu den Grundlagen, weil das ganze Windows Systen darauf beruht. Selbst mit einem abstrahierenden Framework sollte man verstehen, wie es funktioniert. > Wenn man bislang nur herkömmliche Konsolenprogramme geschrieben hat, dann ist bereits das ein sehr harter Umstellungsprozess. Ja, aber ein notwendiger.
:
Bearbeitet durch User
Harald K. schrieb: >> Wenn du C kannst, dann nimm das. > > Für Windows-GUI-Programmierung ist das allerdings 'ne sehr harte Nummer. > Ja, man kann mit der Win32-API in reinem C auch GUI-Programme schreiben, > aber die Lernkurve ist hier sehr steil, weil man das nachrichtenbasierte > Konzept von Windows verstehen muss, d.h. man muss verstehen, wie man > Nachrichtenschleifen schreibt, und eben auch, daß so ein Programm nicht > einen klar vorgegebenen Ablauf hat, sondern immer nur auf Ereignisse > reagiert und dann auf das nächste Ereignis wartet. Das geht erstaunlich einfach über die Bühne. Zumindest solange man nur ein Haupt-Fenster oder Dialog mit einem Menu hat, wie es bei Micha der Fall ist. Das GUI macht der Visual Studio Grafik Editor, da kommt eine Resource Datei raus mit einem Programmgerüst. Die Resource Datei enthält die Grafikelemente und deren Position, die kann man auch händisch editieren. Die Dummy Funktionen muss man dann noch mit was sinnvollem ausfüllen. Die RS232 Schnittstelle ist dann auch kein Hexenwerk. Das Programmgerüst ist etwas umständlich geschrieben, das kann man selber kompakter und verständlicher machen. Das Nachrichtenkonzept muss man nicht im Detail verstehen. Man muss nur wissen, dass bei einem Mausklick oder einem Knopfdruck eine Funktion aufgerufen wird. Wenn man an dieser Nachricht interessiert ist, muss man eine Funktion dafür bereitstellen. In der Praxis läuft das dann auf ein grosses Switch-Statement raus - am Beispiel unten für das RS232CMD Programm muss man nur mehr die OnSendButton() und die OnCommandButton() Funktionen erstellen, wo die eigentliche Arbeit stattfindet.
1 | /*
|
2 | * Windows Prozedur für den Dialog.
|
3 | * Bearbeitet die Windows Nachrichten der Prozedur.
|
4 | */
|
5 | INT_PTR CALLBACK DialogProc(HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam) |
6 | {
|
7 | switch(uMsg) |
8 | {
|
9 | // Dialog wird erzeugt, ist aber noch nicht sichtbar
|
10 | case WM_INITDIALOG: |
11 | {
|
12 | return TRUE; |
13 | }
|
14 | |
15 | // Button-ID
|
16 | case WM_COMMAND: |
17 | {
|
18 | INT id = LOWORD(wParam); |
19 | |
20 | if (id == IDCANCEL || id == IDM_EXIT) |
21 | {
|
22 | // Beende den Dialog mit WM_CLOSE
|
23 | SendMessage(hDlg, WM_CLOSE, 0, 0); |
24 | return TRUE; |
25 | }
|
26 | |
27 | if (id == IDC_SEND) |
28 | {
|
29 | // Der SEND Button wurde gedrückt - mach was damit
|
30 | OnSendButton(hDlg); |
31 | }
|
32 | |
33 | if (id >= IDC_BUTTON1 && id <= IDC_BUTTON32) |
34 | {
|
35 | // Einer der 32 Kommand Buttons wurde gedrückt - mach was damit
|
36 | OnCommandButton(hDlg, id - IDC_BUTTON1); |
37 | }
|
38 | |
39 | if (id == IDM_HELP) |
40 | {
|
41 | // Zeige den Hilfe Dialog an
|
42 | DialogBox(g_hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hDlg, AboutProc); |
43 | }
|
44 | |
45 | break; |
46 | }
|
47 | |
48 | // Anwender hat den Close Button gedrückt
|
49 | case WM_CLOSE: |
50 | {
|
51 | if (MessageBox(hDlg, _T("Program beenden?"), _T("Exit"), MB_ICONQUESTION | MB_YESNO) == IDYES) |
52 | {
|
53 | DestroyWindow(hDlg); |
54 | }
|
55 | return TRUE; |
56 | }
|
57 | |
58 | // Dialog wird zerstört, kommt nach WM_CLOSE
|
59 | case WM_DESTROY: |
60 | {
|
61 | // Beende das Programm
|
62 | PostQuitMessage(0); |
63 | return TRUE; |
64 | }
|
65 | }
|
66 | |
67 | return FALSE; |
68 | }
|
:
Bearbeitet durch User
Harald K. schrieb: > Eine Alternative zur MFC selbst hingegen ist wxWidgets > (https://www.wxwidgets.org/), das ist gerade für Umsteiger von der MFC > ganz gut geeignet, weil die grundlegende Architektur ähnlich ist. Das > ist Open Source und plattformunabhängig; ein bekanntes > Open-Source-Projekt, das wxWidgets verwendet, ist der Audio-Editor > Audacity. wxWidgets ist übel. Da ist alles nur halbherzig implementiert. Ja, man kann damit optisch ansprechende Programme schreiben, aber nur mit wirklich viel Durchhaltevermögen. Das einzige Open Source Framework, mit dem man out of the box ansprechende Windows GUIs hinbekommt ist Qt. Das ist aber ein richtiger Moloch.
https://lcc-win32.services.net/ damit habe ich erste WindowsProgramme erstellt. Aber Programmieren muß man trotzdem lernen.
Aus meiner Sicht ein lästiges Problem: Programme mit C#, .net, Visual Irgendwas oder Java brauchen allesamt eine zusätzlich installierte Laufzeitbibliothek ... Ich verwende seit über 10 Jahren Xojo, früher mal "RealBasic", später "Real Studio", aktuell "Xojo". Ok, das ist nicht kostenlos, aber seitdem kann ich völlig problemlos Programme für Windows, MacOS und Linux (X86 und Raspi) aus ein und dem selben Quellcode per Knopfdruck erstellen. GUI-Designer in der IDE inklusive. Mobilgeräte unter Android und iOS sind mit etwas mehr Aufwand ebenso zu bedienen. Es gibt nichts was nicht geht: Grafik, Netzwerk, Datenbanken, Hardware, Schnittstellen ... Aber immer: Beim Compilieren entsteht ein Ordner, in dem alles drin ist, was nötig. Keine zusätzliche "Installation", einfach kopieren, Doppelklick ... läuft. https://www.xojo.com/
:
Bearbeitet durch User
Frank E. schrieb: > Aus meiner Sicht ein lästiges Problem: Programme mit C#, .net, Visual > Irgendwas oder Java brauchen allesamt eine zusätzlich installierte > Laufzeitbibliothek ... Visual C++ kann auch statisch linken, und .NET ist schon länger beim Betriebssystem dabei.
Hmmm schrieb: > Frank E. schrieb: >> Aus meiner Sicht ein lästiges Problem: Programme mit C#, .net, Visual >> Irgendwas oder Java brauchen allesamt eine zusätzlich installierte >> Laufzeitbibliothek ... > > Visual C++ kann auch statisch linken Hmm, hast du rein gar nicht verstanden wovon Frank schreibt ?
Angehängte Dateien:
-
1200px-Lazarus_1.0_Carbon.png
540 KB -
tek492.webp
27 KB
Die Lazraus Freepascal Oberfläche dürfte eine der besten überhaupt nach Visuall C von MS sein bzw Delphi Und keinerlei Einschränkungen, auch wenn du was verkaufen willst etc. Absolut keine So sähe ein Programm z.B. in Lazarus (Freepascal) aus program SerialReceive;
1 | program SerialReceive; |
2 | {$mode objfpc}{$H+}
|
3 | |
4 | uses |
5 | Classes, SysUtils, synaser; |
6 | |
7 | var |
8 | Serial: TBlockSerial; |
9 | ReceivedString: string; |
10 | begin |
11 | // Serielle Schnittstelle initialisieren |
12 | Serial := TBlockSerial.Create; |
13 | try |
14 | Serial.Connect('/dev/ttyS0'); // Ersetze mit dem richtigen Port (z. B. COM1 unter Windows)
|
15 | Serial.Config(9600, 8, 'N', SB1, False, False); // 9600 Baud, 8 Datenbits, keine Parität, 1 Stoppbit |
16 | |
17 | Writeln('Warte auf Daten von der seriellen Schnittstelle...');
|
18 | |
19 | // Daten empfangen |
20 | while True do |
21 | begin |
22 | if Serial.CanRead(1000) then // 1000 ms Timeout |
23 | begin |
24 | ReceivedString := Serial.RecvString(1000); // String empfangen |
25 | if ReceivedString <> '' then |
26 | begin |
27 | Writeln('Empfangen: ', ReceivedString);
|
28 | end; |
29 | end; |
30 | end; |
31 | finally |
32 | Serial.Free; |
33 | end; |
34 | end. |
Michael B. schrieb: > Hmm, hast du rein gar nicht verstanden wovon Frank schreibt ? Mit Visual Studio (was man als "Visual irgendwas" begreifen könnte), kann man sehr wohl statisch gelinkte Programme erstellen - vorausgesetzt, man verwendet C oder C++, aber nicht eine der .Net-Sprachen, zu denen auch C++/CLI oder "Managed C++" gehört. Nutzt man die MFC, so ist das echtes C++, also keine .Net-Sprache, und MFC-Anwendungen kann man statisch linken, wie auch andere C++- und erst recht C-Programme auch. Dann ist noch nicht mal "vcredist" in irgendeiner seiner aktuellen Versionen nötig.
Micha schrieb: > Das Ganze soll mindestens auf Windows 10 laufen. Ich würde Visual Studio > 2022 verwenden. Wäre es sinnvoll, das mit Visual Basic zu realisieren? Natürlich. Könnte man genausogut auch in C# machen, aber wenn du VB (.net) wenigstens schon etwas kennst, ist es natürlich in VB leichter für dich. > Oder gibt es auch "einfachere" Möglichkeiten? Eher nein. Was könnte einfacher sein als ein .Net-Programm? Das ist managed code, der dir deine Fehler (meistens) völlig unverblümt und mit genauem Fehlerort präsentiert. Schon zur Entwurfszeit wirst du mit Komfort geradezu zugeschissen. Er bemeckert jeden Fehler, der hier bereits erkennbar ist. Keine u.b.-Scheiße wie bei C oder C++, wo du selbst dahinter kommen musst, wo du den Mist gebaut hast, weil der Compiler zu blöd ist, dir das zu melden. Aber nicht zu bescheuert, um trotzdem ein Programm zu generieren. Manchmal sogar eins, was ohne Laufzeitfehler läuft. Es macht dann halt nur nix sinnvolles, zumindest aber nicht das Gewünschte... Naja, inzwischen gibt es wenigstens meistens Warnungen. Aber oft auch nicht sehr hilfreich. Die Texte der Warnungen weisen oft nicht auf das eigentliche Problem hin. Also, ich kann dir nur empfehlen: .net. Macht vieles um vieles einfacher.
Je nachdem, was einem liegt, oder mehr entgegen kommt, oder was man aktuell zusammenbekommt. Python ist ja so gesehen auch gar nicht so schlecht. Viele Experten damals hatten sehr zuverlässige Windows-Programme in c und asm geschrieben. So manche Visual Basic - Programme von Ingenieuren waren aber oft fehlerhaft oder wirkten unprofessionell. Die Pascal-Programmierpackete waren auch toll, und auch super dokumentiert, und das lcc-Win Compilerpacket hatte wohl auch gute Windows-Programmierdoku und -Bib dazu, bzw. ein wichtiges Help-File.
Frank E. schrieb: > Aus meiner Sicht ein lästiges Problem: Programme mit C#, .net, Visual > Irgendwas oder Java brauchen allesamt eine zusätzlich installierte > Laufzeitbibliothek ... > > Ich verwende seit über 10 Jahren Xojo, früher mal "RealBasic", später > "Real Studio", aktuell "Xojo". Braucht mit Sicherheit ebenfalls irgendwelche Laufzeit-Bibliotheken. Es gibt praktisch keine Anwendung für irgendein OS, die keine braucht. Der Punkt ist einfach: das OS bringt diese Bibliotheken mit. Hoffentlich. Wenn nicht, müssen sie halt nachinstalliert werden. Laß' doch einfach mal eins deiner tollen Xojo-Programme testweise mal unter WindowsXP laufen. Geht das? In vollem Umfang? Falls ja: wie groß ist der Umfang, was tut das Programm?
Harald K. schrieb: > Dann ist noch nicht mal "vcredist" in irgendeiner seiner aktuellen > Versionen nötig. Aber immer noch "kompatible" Versionen der grundlegenden OS-Libraries. Da sind zwar (was Windows betrifft) fast durchgängig abwärtskompatibel, aber nur eingeschränkt auch aufwärtskompatibel. Schöner Test ist also immer: Laß' das stolze Produkt auch mal unter unter einem "frischen" WindowsXP laufen...
Sherlock 🕵🏽♂️ schrieb: > Ich würde auch dazu raten, bei C zu bleiben, denn das kennst du und > Windows wurde selbst ebenfalls in C geschrieben. Trotz dieser starken Argumente entwickelt Microsoft seine Flaggschiffe Word, Excel und Powerpoint laut Wikipedia alle in C++. Warum nur?
Geli schrieb: > Python ist für den Zweck blöd, [...] Warum? Für mich wären Python mit Tix (oder Flask, Jinja2 und eventuell Svelte) gerade für solchen Kleckerkram die erste Wahl.
stimmt schon, aber ich selber mag immer richtige EXE Files:-) Und mi Lazarus Pascal geht das nicht schwieriger als mit Python ISt halt Geschmackssache. Und PAscal Programme starten so schön schnell:-) Keine Ahnung, wie das bei Python ist
Angehängte Dateien:
-
Datalog.png
290 KB
Ich war dieses Jahr auch auf Suche nach einer neuen IDE, ich habe lang Delphi benutzt aber inzwischen keine Lizenz mehr. Delphi wäre mir persönlich zu teuer gewesen. Ich habe einige IDE's durchgetestet - auch Freeware in Verbindung mit wxWidgets aber ich möchte Anwendungen erstellen und nicht Stunden lang versuchen eine lauffähige Entwicklungsumgebung aufzusetzen. Ich bin bei C# gelandet und mit der Rider IDE von Jetbrains wunschlos glücklich. Die IDE ist bei Nicht-Kommerzieller Nutzung kostenlos, ansonsten kostet diese 177€/Jahr für Einzelpersonen. Top IDE, einwandfreier Debugger und tatsächlich sinnvolle Vorschläge zur Autovervollständig. Eines meiner ersten Projekte damit war auch ein Datenlogger. Allerdings mit tcp/ip und der Speicherung in einer SQLite Datenbank - mit der Möglichkeit die Daten anschließend graphisch anzeigen zu lassen.
Wie sieht es mit Mono aus? hast du da Erfahrungen? Sonst ist man so auf Windows beschränkt und muss bald wieder umsteigen, deshalb bevorzuge ich Lazarus als langfristige Alternative
Ein T. schrieb: > rotz dieser starken Argumente entwickelt Microsoft seine Flaggschiffe > Word, Excel und Powerpoint laut Wikipedia alle in C++. Warum nur? Weil die von Leuten entwickelt werden, die damit Geld verdienen, und ständig damit arbeiten. Hier will jemand, der nur einige sehr alte C-Kenntnisse hat, sich selbst ein Programm basteln. > Ich habe bisher nur Erfahrung in Programmierung > mit C (nicht C++). Davon, daß er groß "in die Programmierung einsteigen" will, war nicht die Rede, auch nicht, daß er sich eine Karriere als Softwareentwickler erträumt.
Harald K. schrieb: > Weil die von Leuten entwickelt werden, die damit Geld verdienen, und > ständig damit arbeiten. Ich würde eher sagen, weil sie in C++ entwickelt wurden und das nun niemand mehr komplett neu schreibt.
Geli schrieb: > stimmt schon, aber ich selber mag immer richtige EXE Files:-) Und mi > Lazarus Pascal geht das nicht schwieriger als mit Python > ISt halt Geschmackssache. > Und PAscal Programme starten so schön schnell:-) > Keine Ahnung, wie das bei Python ist Das hängt davon ab, wie man es macht. Man kann Python ja auch in Executables übersetzen oder verpacken, und je nachdem, wie es dabei gewünscht ist, auch standalone, so daß der Interpreter ins Executable eingebettet ist und nicht separat installiert werden muß. Allerdings: auch wenn das mit Python möglich ist, erhöht es die Entwicklungszeit und invalidiert damit genau das, weswegen man eine Skriptsprache benutzen möchte. Andererseits habe ich lange gezögert, ob ich dem TO für seine Aufgabe Python empfehlen möchte, und mich dann bewußt dagegen entschieden. Denn der TO hat zwar Erfahrungen mit C und VisualBasic, jedoch keine mit Python oder Pascal. Ich würde niemandem, der in zeitlich sehr großen Abständen was anderes als C braucht, empfehlen, eine neue Sprache zu lernen. Da ist die Kosten-Nutzen-Relation IMHO einfach viel zu schlecht. Ich ganz persönlich würde die Aufgabe des TO allerdings heutzutage ohnehin anders lösen und, vermutlich mit Golang, eine Websoftware schreiben. Dies hätte einige interessante Vorteile: Golang läßt sich sehr einfach in ein einfaches Executable mit eingebetteten Ressourcen (Templates, CSS, SVGs, ECMAScript, Grafiken) übersetzen, das standalone überall läuft -- und das gleichzeitig auch sofort netzwerk- (und sogar mobil-)fähig gemacht werden kann. Das Admintool PgAdmin4 für PostgreSQL machen es vor. Sowas finde ich persönlich ausgesprochen schick und nützlich.
Harald K. schrieb: > Ein T. schrieb: >> rotz dieser starken Argumente entwickelt Microsoft seine Flaggschiffe >> Word, Excel und Powerpoint laut Wikipedia alle in C++. Warum nur? > > Weil die von Leuten entwickelt werden, die damit Geld verdienen, und > ständig damit arbeiten. Dasselbe wäre allerdings der Fall, wenn sie diese Programme in C entwickeln würden, das hier im Thread ja mehrmals empfohlen worden ist. > Davon, daß er groß "in die Programmierung einsteigen" will, war nicht > die Rede, auch nicht, daß er sich eine Karriere als Softwareentwickler > erträumt. Das ist mir ebenso bekannt wie bewußt. Dennoch paßt die Objektorientierung besser zur Entwicklung von GUIs als irgendein anderes Paradigma. Das sieht recht schön beim GTK, das ziemliche Klimmzüge unternimmt, um C mit so etwas Ähnlichem wie OO-Features aufzupeppen. Ich würde vermuten, daß das bisschen Objektorientierung von C++ für einen erfahrenen C-Entwickler einfacher zu lernen ist, als wenn er sich gleichzeitig eine neue Sprache aneignen muß.
Sherlock 🕵🏽♂️ schrieb: > Ich würde eher sagen, weil sie in C++ entwickelt wurden und das nun > niemand mehr komplett neu schreibt. Oh, so was wurde schon gemacht, das beliebte PaintShopPro in C wurde als Paint.Net in C# neu geschrieben. Neuer besser moderner - and it sucks, ist gross, langsam und braucht halt DotNET.
Sherlock 🕵🏽♂️ schrieb: > Harald K. schrieb: >> Weil die von Leuten entwickelt werden, die damit Geld verdienen, und >> ständig damit arbeiten. > > Ich würde eher sagen, weil sie in C++ entwickelt wurden und das nun > niemand mehr komplett neu schreibt. Okay, Kontext... meine Frage zielte darauf ab, warum sie in C++ geschrieben worden sind, obwohl die Entwickler das doch auch in dem damals ebenfalls zur Auswahl stehenden C hätten tun können, wenn ich den Argumenten in diesem Thread einmal konsequent folgen möchte. :-)
Ein T. schrieb: > meine Frage zielte darauf ab, warum sie in C++ geschrieben worden sind, > obwohl die Entwickler das doch auch in dem damals ebenfalls zur Auswahl > stehenden C hätten tun können Weil C++ OOP hinzugefügt hat, welches zum besseren Strukturieren komplexer Programme erfunden wurde. Vererbung passt wie die Faust auf's Auge zu GUI Elementen.
:
Bearbeitet durch User
Geli⚡ schrieb: > Wie sieht es mit Mono aus? hast du da Erfahrungen? Mono gibt es für alle verbreiteteten Distributionen. Und es funktioniert. Solange du ein reines .Net-Programm hast (und dieses sauber programmiert ist), wird es auch unter Mono laufen, ggf. allerdings mit leichten Einschänkungen, die aus der unterschiedlichen Infrastruktur resultieren. Sobald darin allerdings in irgendeiner Form auf nativen, plattformspezifischen Code zugegriffen wird, wird es schwierig. > deshalb bevorzuge ich Lazarus als langfristige Alternative Das Problem mit dem Zugriff auf nativen, plattformspezifischen Code hast du da allerdings genauso.
Michael B. schrieb: > Oh, so was wurde schon gemacht, das beliebte PaintShopPro in C wurde als > Paint.Net in C# neu geschrieben. Nein.
Michael B. schrieb: > Oh, so was wurde schon gemacht, das beliebte PaintShopPro in C wurde als > Paint.Net in C# neu geschrieben. So ein Unsinn. Allenfalls mutet das GUI (ein ganz klein wenig) ähnlich an. Aber nicht viel ähnlicher als z.B. das GUI von GIMP. Die Ähnlichkeiten dürften also vor allem aus der gemeinsamen Aufgabe jeglichen Programms zu Bildbearbeitung resultieren. Der Code hat mit dem von PaintShopPro auf jeden Fall absolut nix gemein.
Ein T. schrieb: > Okay, Kontext... meine Frage zielte darauf ab, warum sie in C++ > geschrieben worden sind, obwohl die Entwickler das doch auch in dem > damals ebenfalls zur Auswahl stehenden C hätten tun können, wenn ich den > Argumenten in diesem Thread einmal konsequent folgen möchte. :-) Diesen Unfug hast Du in Aussagen hineininterpretiert, die Du einfach nicht verstanden hast oder verstehen wolltest.
Na dann ist ja alles in Butter. Der Threadstarter scheint übrigens schon vorgestern die Abbiegung in Richtung vb.net genommen zu haben.
Dann hat er doch alles richtig gemacht. Ich hätte dennoch Lazarus Pascal genommen, aber mit VB macht er sicher auch nichts falsch Harald K. schrieb: > Na dann ist ja alles in Butter. > > Der Threadstarter scheint übrigens schon vorgestern die Abbiegung in > Richtung vb.net genommen zu haben.
Morning! Hier mal ein Beispiel für die Kommunikation mit der RS232-Schnittstelle und zum Schreiben in eine Datei. Letztere habe ich zum Auslesen eines EPROMMS (U555) erstellt. Viel Spass damit Jürgen
Hallo Andreas H., keine Lizens für Delphi mehr? Die letzte Version wurde doch freigestellt, d.h. die Autorisierung veröffentlicht. Habe die CD von "Delphie für KIDS" installiert und dann auch freigeschaltet.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.