für Bedienoberflächen scheint c# prädestiniert. Ich kenne mich nur in C aus. Ein bisschen. Jz möchte ich eine simple Bedienoberfläche in Vs 2019 basteln. hat jmd Tipps? Muss das ganze dann später über entsprechende Schnittstellen mit messgeräten verbinden. Ich habe davon aber keinen Plan. Ganz ehrlich. Ganz transparent
Um was für Schnittstellen handelt es sich? Muss es unbedingt C sein? Dann ist GTK vermutlich die beste Wahl. Ansonsten gäbe es z.B. Qt für C++. Eventuell ließen sich die Schnittstellen dann auch aus C++ heraus nutzen.
Key schrieb: > Muss das ganze dann > später über entsprechende Schnittstellen mit messgeräten verbinden. Ich > habe davon aber keinen Plan. Dann ändere das. Das Zauberwort heißt LERNEN.
c-hater schrieb: > Key schrieb: > >> Muss das ganze dann >> später über entsprechende Schnittstellen mit messgeräten verbinden. Ich >> habe davon aber keinen Plan. > > Dann ändere das. Das Zauberwort heißt LERNEN. Vielleicht fragt er genau deshalb. Weil er von Menschen, die es wissen, etwas lernen möchte. Dabei hilft ihm deine Antwort wenig. Er braucht Menschen, die ihr Wissen auch weitervermitteln möchten, indem sie HELFEN.
C geht ist in Windows easy, such dir die MSDN Beispiele raus, oder nimm die Petzold Sourcen (https://github.com/yottaawesome/programming-windows-5th-edition). Ansonsten kannst du C auch einfach mit C++ mischen, das ist zu C abwärtskompatibel. Da kannst du dann die MFC oder den Open Source Nachbau Win32++ verwenden (http://win32-framework.sourceforge.net/downloads.htm).
@c-hater: Du kommst mir manchmal vor wie Marie Antoinette. Sie versuchte ja auch, den hungrigen Menschen zu helfen mit ihrem Ausspruch: "Wenn sie kein Brot haben, sollen sie doch Kuchen essen". Du sagst jemandem, der etwas lernen möchte und nach Tipps fragt, "Das Zauberwort heißt lernen". Das finde ich einfach geschmacklos und in höchstem Maße ARROGANT.
Key schrieb: > Muss das ganze dann > später über entsprechende Schnittstellen mit messgeräten verbinden. Welche Schnittstellen sind das? Diese dürften die Auswahl der Programmiersprache/Umgebung einschränken. Grafische Oberflächen kann man mit fast jeder Sprache erstellen.
Man kann auch die Oberfläche in C# basteln und die Kommunikation mit den Messgeräten in C/C++ (wenn das einfacher ist). C/C++- Libs lassen sich ohne weiteres in C# ansprechen. merciless
An sich entscheidet ja nicht die Programmiersprache darüber wie gut sich eine GUI bauen lässt sondern das Framework welches man in der Regel dazu einsetzt. Wenn du gerne in der C-Welt bleiben möchtest, was ja durchaus legitim ist, dann lohnt sich ein Blick auf das sehr verbreitete GTK. Nimm dir mal ein paar Minuten Zeit für das "Getting Started", dann solltest du recht schnell voran kommen: https://www.gtk.org/docs/getting-started/hello-world/ Viele Grüße Dennis
Die Frage ist auch wieviel Power die zu verbindenden Messgeräte haben und ob man die SW selber in der Hand hat oder auf ein vorhandenes Protokoll aufsetzen muss. Wenn das eine eigene Entwicklung ist und Ethernet hat, dann ist die Bedienung über einen Webbrowser möglich, das wäre platformunabhängig und die Installation zusätzlicher Software entfällt.
Key schrieb: > für Bedienoberflächen scheint c# prädestiniert. > Ich kenne mich nur in C aus. Ein bisschen. Jz möchte ich eine simple > Bedienoberfläche in Vs 2019 basteln. hat jmd Tipps? Muss das ganze dann > später über entsprechende Schnittstellen mit messgeräten verbinden. Ich > habe davon aber keinen Plan. Ganz ehrlich. Ganz transparent Im Prinzip ist C# easy und wenn man das Prinzip von VS verstanden hat, bekommt man schnell eine Oberfläche hin. Die kritische Sache ist deine HW Anbindung. Du musst dich informieren, ob du die Treiber DLL's in C# benutzen kannst, manchmal muss man eine wrapper klasse schreiben und daran scheitern die meisten. Die Messgräte können meist über USB, RS232, LAN oder GPIB angebunden werden. Hier wäre z.B. RS232 am einfachsten.
Herr Bärt schrieb: > https://www.fltk.org/ Warum eine C++-Lib wenn es direkt für C doch sehr gut brauchbares gibt? So völlig ohne Argumente ist mir das ja immer etwas suspekt. Johannes S. schrieb: > Die Frage ist auch wieviel Power die zu verbindenden Messgeräte haben > und ob man die SW selber in der Hand hat oder auf ein vorhandenes > Protokoll aufsetzen muss. Die UI soll doch nicht auf den Messgeräten laufen oder?
Dennis S. schrieb: > Die UI soll doch nicht auf den Messgeräten laufen oder? Sowas soll es geben. Der TO war mit seinen Informationen aber sehr spärlich, darum gibt es wieder Vorschläge in alle Richtungen. UI auf dem Gerät hatte ich mir geklemmt, ich habe Webserver genannt. Aber UI auf Embedded Geräten ist auch schon lange realisierbar, ich mache gerade einiges mit Mbed und lvgl, eine gute Kombination. Ok, lvgl wäre schöner in C++, aber für OpenSource ist das schon genial.
Key schrieb: > Jz möchte ich eine simple > Bedienoberfläche in Vs 2019 basteln. hat jmd Tipps? npn schrieb: > @c-hater: > ... > Du sagst jemandem, der etwas lernen möchte und nach Tipps fragt, "Das > Zauberwort heißt lernen". > Das finde ich einfach geschmacklos und in höchstem Maße ARROGANT. Nein, ist es nicht. Nach meiner Erfahrung lernt man am besten, wenn man es sich selbst erarbeitet und am schlechtesten oder gar nicht, wenn man es von anderen fertig vorgelegt kriegt. Lernen ist eine aktive Tätigkeit - im Gegensatz zum dressiert-werden. So, und nun an den TO: Du machst einschränkende Vorbedingungen, für diese kann ich dir keinerlei Rat geben. Wenn du dich jedoch dazu bequemen könntest, Pascal zu lernen, dann hättest du mit aktuellem Delphi und/oder Lazarus etwas, mit dem du sehr effizient ordentliche Bedienoberflächen und auch deren eigentliche Funktionalität schreiben kannst. Und man kann damit auch sehr effizient mit angeschlossenen µC und anderem Zeugs kommunizieren. Schau einfach mal bei den Projekten nach dem Z180 Soft-System, da hab ich ein Terminalprogramm in Pascal (per Lazarus) gepostet. Dort kannst du dir anschauen, wie das geht. Ansonsten kannst du dir auch mein STM32-Brennprogeamm 'STM32Prog' anschauen und einschätzen, ob dir so etwas als Oberfläche gefällt. Das ist mit Delphi gemacht. Die einfachste kostenlose Version reicht völlig aus. Aber: um damit zu Potte zu kommen, ist Pascal angesagt. W.S.
W.S. schrieb: > am schlechtesten oder gar nicht, wenn man es > von anderen fertig vorgelegt kriegt Ich kann mich irren, aber ich glaube, der TO bat lediglich um Tipps und wollte nicht, (wie du es unterstellst) etwas fertiges vorgelegt bekommen.
also für mich kommen momentan zwei Optionen in Frage: entweder arbeite ich mit GTK oder mit Windows Forms App Für den Fall GTK: soll ich mir Glade herunterladen? (respektive andere Designwerkzeuge)Bin mir nicht ganz ´sicher, welcher Zusammenhang zw. den Tools und VS 2019 besteht. habe auf Wikipedia den Beispielscode zu GTK durchgearbeitet, scheint mir auf Anhieb unübersichtlicher, als wenn ich mit Windows Forms App arbeite Im Falle WFA: ich würde mir die Grafik zusammenbasteln (wäre ja C#), die Logik etc würde ich gerne in C erstellen. Soll ich beispielsweise für jedes Messgerät eine eigne Wuelldatei erstellen? Wie wären eure Ansätze?
Key schrieb: > Bin > mir nicht ganz ´sicher, welcher Zusammenhang zw. den Tools und VS 2019 > besteht. Keiner. GTK und Glade sind komplett unabhängig zu VS. Key schrieb: > die Logik etc > würde ich gerne in C erstellen. Wozu? Warum nicht alles in C#? Das dürfte viel einfacher sein.
Programmierer schrieb: > Wozu? Warum nicht alles in C#? Das dürfte viel einfacher sein. wieso sollte das in meinem Fall einfacher sein? C# ist mir unbekannt
Key schrieb: > wieso sollte das in meinem Fall einfacher sein? Weil C# und C völlig unterschiedliche Laufzeitsysteme haben und es relativ umständlich ist, beide ineinander zu integrieren. Key schrieb: > C# ist mir unbekannt Das lernt man schnell. Wenn du es schaffst in C# eine GUI zu bauen, klappt der Rest auch. Wenn nicht, ist C# sowieso die falsche Wahl; C in C# zu integrieren gehört schon zu den fortgeschrittenen Sachen.
welche "simple" Möglichkeiten bleiben denn dann noch für VS 2019 und C? oder soll ich den Ansatz über den Haufen werfen und mich entweder für GTK oder WFA entscheiden?
Nuklear - single header immediate mode GUI in C89 https://github.com/vurtun/nuklear
:
Bearbeitet durch User
Key schrieb: > welche "simple" Möglichkeiten bleiben denn dann noch für VS 2019 > und C? Keine. VS unterstützt C sowieso nicht gut, VS hat kein gutes GUI-Framework für C dabei, was man also extern (z.B. Gtk+) einbinden müsste (umständlich) - ansonsten bliebe nur das Win32 API direkt nutzen, was super umständlich und lästig ist. > oder soll ich den Ansatz über den Haufen werfen und mich entweder für > GTK oder WFA entscheiden? WFA = Windows Forms? Dann, ja eins von beiden. Wobei "Alles in C# + Windows Forms" wahrscheinlich am Einfachsten ist, es sei denn deine Messgeräte können nur in C angesteuert werden, was du ja bis jetzt nicht verraten hast. Key schrieb: > Soll ich beispielsweise für jedes > Messgerät eine eigne Wuelldatei erstellen? Wenn schon eine eigene Klasse, die von einer gemeinsamen Basis ableitet, o.ä.
Programmierer schrieb: > Messgeräte können nur in C angesteuert werden, was du ja bis jetzt nicht > verraten hast C# ist möglich
Programmierer schrieb: > Wenn schon eine eigene Klasse, die von einer gemeinsamen Basis ableitet, > o.ä. da fängts an. Kenne keine Klassen aus C
Key schrieb: > welche "simple" Möglichkeiten bleiben denn dann noch für VS 2019 und C? > oder soll ich den Ansatz über den Haufen werfen und mich entweder für > GTK oder WFA entscheiden? GTK kannst du unter Windows vergessen, wenn du nicht >5 Jahre Programmiererfahrung hast. Die Exoten wie fltk genauso, das wird ja seit Jahren nicht mehr richtig weiterentwickelt. Wenn du bei C bleiben möchtest, dann bleibt das Win32 Api. Das ist recht einfach gestrickt, sofern dein Anwendung nur ein Menü und ein paar Dialoge braucht. Schau dir die Petzold Beispiele aus dem Link oben an, nimm dir das Beispiel, das dich anspringt, und compiliere das mal in VS2019. Dann siehst du ja, ob du damit zurechtkommst. Sonst bleibt nur, C++ / C#. Das kann dann aber länger dauern.
Key schrieb: > da fängts an. Kenne keine Klassen aus C Sollte man aber für GUI Programmierung, denn objektorientierte Programmierung passt da sehr gut zu. Die allermeisten GUI Systeme sind objektorientiert, auch solche für C inklusive Gtk+. Ist da nur umständlicher... Key schrieb: > sind die Operatoren in C und C# identisch? Die arithmetischen, weitgehend ja. Udo K. schrieb: > Wenn du bei C bleiben möchtest, dann bleibt das Win32 Api. Das will sich nun wirklich keiner antun. Udo K. schrieb: > Sonst bleibt nur, C++ / C#. Das kann dann aber länger dauern. C++ und C# sind grundverschieden. Die kann man nicht so über einen Kamm scheren. Und wieso soll das damit länger dauern? Win32 API Code ist ja wohl deutlich länger, und für C# + WPF hat VS schon Designer integriert... Udo K. schrieb: > GTK kannst du unter Windows vergessen, wenn du nicht >5 Jahre > Programmiererfahrung hast. So ein Quatsch, damit eine GUI zu erstellen ist viel einfacher als mit dem Win32 API. Aber immer noch umständlicher als mit WPF im VS.
Programmierer schrieb: > ansonsten bliebe nur das Win32 API direkt nutzen, > was super umständlich und lästig ist. Udo K. schrieb: > Wenn du bei C bleiben möchtest, dann bleibt das Win32 Api. > Das ist recht einfach gestrickt mhhhh
Programmierer schrieb: > als mit WPF im VS. hab gelesen, das WPF zwar das aktuelle ist, aber umfangreicher und somit für kleine Anwendungen irrelevant. Also bleiche ich lieber bei Windows forms?
Key schrieb: > und somit für kleine Anwendungen irrelevant. Das ist eine verkehrte Folgerung. Windows ist auch komplex und du benutzt es trotzdem...
Wenn es bei ein paar Buttons und so bleibt, ist Windows-API ziemlich beständig und wirklich "rein", also ohne irgendwelche Abhängigkeiten. Wenn es aber auch vielleicht irgendwann mal auf einem Messgerät laufen soll, sind auch die vielen Fenstersysteme aus dem Embedded-Bereich möglich, falls Du sowas hast. Z.B. EMWin von Segger, was ja auf dem PC genauso gut läuft wie embedded.
Programmierer schrieb: > Das ist eine verkehrte Folgerung. Windows ist auch komplex und du > benutzt es trotzdem... du warst mir fast sympathisch
Beitrag #6330849 wurde von einem Moderator gelöscht.
es gibt doch imgui für c++. und für c gibt es die Alternative (es gibt auch wrapper für imgui) https://github.com/Immediate-Mode-UI/Nuklear Schau wie schnell da ein Fenster mit verschiedenen Widgets erzeugt wird.
Miauuu schrieb im Beitrag #6330849: > Hallo, > > also GUI in C++ ist cancer. Das macht keinen spaß. C++ ist eine > Programmiersprache bei der man für die einfachsten Dinge ganz viele > Codezeillen schreiben muss. Prädestiniert ist C#. Aber Cross-Platform? > Dann lieber QT. Alternativ Python + QT? Man kann sogar per > HTML/JS/Angular und den ganzen Frameworks eine GUI proggen, dann mit > einem weiteren Framework standalone machen. lol. Dann kann man auch > C++/CLI nutzen und stinknormal mit .NET entwickeln. Oder man schreibt > eine Wrapper-Library in C++/CLI und interfaed zwischen nativem C++ und > der GUI in C#. da hatte wieder mal jemand keinen Bock, die Beiträge zu lesen...
Warum so kompliziert. Der TO hatte nach einer GUI in C gefragt und nicht nach "was gibts noch so" Da du wohl unter windows unterwegs bist, einfach die winapi nutzen. Easy. Keine 100 Zeilen und du hast nen Fenster mit Steuerung Geräte ansprechen ist auch einfach, wenn diese sich z.b. per COM port melden. Verhält sich wie eine Datei. Hier nen gutes Beispiel: https://docs.microsoft.com/en-us/windows/win32/learnwin32/your-first-windows-program Kleine Einführung, mit den Standard Buttons und Controls solltest du eig. alles wichtige schnell hinbekommen. Das beste: Wenn du VS2019 hast, hast du die nötigen Dateien bereits drauf. Einfach ein
1 | #include <Windows.h> |
und los gehts. VS2019 hat sogar Beispielcode für ein Fenster. Programme sind klein, laufen überall, und brauchen nicht erstmal Gigabyteweise frameworks und sonstige Abhängigkeiten
Beitrag #6331156 wurde von einem Moderator gelöscht.
Bufferoverflow schrieb: > Keine > 100 Zeilen und du hast nen Fenster mit > Steuerung Wow, doch so wenige. Gtk+ sind 3 Zeilen. WPF 0 Zeilen, da der Designer das macht. Klassische Win32-GUIs sind völlig überholt, sehen uralt aus und sind kompliziert zu programmieren und vermutlich nichtmal skalierbar (HiDPI und so). Bufferoverflow schrieb: > Programme sind klein, laufen > überall, und brauchen nicht erstmal Gigabyteweise > frameworks und sonstige Abhängigkeiten Genau wie bei C# .net - das Framework ist bei Windows vorinstalliert. Man muss also bloß die .exe starten.
Programmierer schrieb: > Klassische Win32-GUIs sind völlig überholt, sehen uralt aus > und sind kompliziert zu programmieren Quark. Nur weil Du's nicht kannst, ist es nicht automatisch schlecht. Programmierer schrieb: > und vermutlich nichtmal skalierbar > (HiDPI und so). Wer vermutet denn sowas? "Richtige" HiDPI Unterstützung gibt es seit Vista, also 2007. Und seitdem können meine API Anwendungen auch vernünftig HiDPI. Bereits 2012 kam dann die Unterstützung für per Monitor DPI Awareness, nebst passenden Funktionen im API. Und ab dem Creators-Update (1703) haben per Monitor V2 DPI Awareness, nebst passenden neuen Funktionen im API. Und seitdem kostet mich die Skalierung (HiDPI und so) in meinen API Anwendungen nur noch ein müdes Arschrunzeln. Aber gut, wir hatten schon festgestellt, dass Du vom API nichts verstehst. Programmierer schrieb: > Genau wie bei C# .net - das Framework ist bei Windows vorinstalliert Wie schön, wunderbar, bei VB.net ebenfalls. Aber was hat das nochmal mit C zu tun?
Mox schrieb: > Und seitdem kostet mich die Skalierung (HiDPI und so) in meinen API > Anwendungen nur noch ein müdes Arschrunzeln. Ah, wie positionierst du denn die Steuerelemente dynamisch, sodass sie bei variabler Schriftgröße nicht überlappen? Die Win32-GUI enthält schließlich keine Layout Manager wie moderne Systeme, welche das komplett automatisch machen. Etwa manuell mit Pixeln hantieren? Wie lästig. Mox schrieb: > Aber was hat das nochmal mit C zu tun? Dass man genau gleich wenig Frameworks wie bei C-Win32-Apps installieren muss, nämlich 0.
Programmierer schrieb: > Ah, wie positionierst du denn die Steuerelemente dynamisch, sodass sie > bei variabler Schriftgröße nicht überlappen? Die Win32-GUI enthält > schließlich keine Layout Manager wie moderne Systeme, welche das Beim DPI-Wechsel überlasse ich dem System die Positionierung, das ist doch gerade der Witz am 1703 Update gewesen. Dafür brauche ich keinen "modernen" Layout Manager. Nur weil Du keine Ahnung vom API hast, heißt das noch lange nicht, dass damit gar nichts geht!
Mox schrieb: > Beim DPI-Wechsel überlasse ich dem System die Positionierung, das ist > doch gerade der Witz am 1703 Update gewesen. Ach, wie funktioniert das? Ich habe nur das gefunden: https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows
1 | #define INITIALX_96DPI 50
|
2 | #define INITIALY_96DPI 50
|
3 | #define INITIALWIDTH_96DPI 100
|
4 | #define INITIALHEIGHT_96DPI 50
|
5 | |
6 | |
7 | // DPI scale the position and size of the button control
|
8 | void UpdateButtonLayoutForDpi(HWND hWnd) |
9 | {
|
10 | int iDpi = GetDpiForWindow(hWnd); |
11 | int dpiScaledX = MulDiv(INITIALX_96DPI, iDpi, 96); |
12 | int dpiScaledY = MulDiv(INITIALY_96DPI, iDpi, 96); |
13 | int dpiScaledWidth = MulDiv(INITIALWIDTH_96DPI, iDpi, 96); |
14 | int dpiScaledHeight = MulDiv(INITIALHEIGHT_96DPI, iDpi, 96); |
15 | SetWindowPos(hWnd, hWnd, dpiScaledX, dpiScaledY, dpiScaledWidth, dpiScaledHeight, SWP_NOZORDER | SWP_NOACTIVATE); |
16 | }
|
Da muss man manuell auf die DPI-Änderung achten, die Pixelgrößen umrechnen und auf die Steuerelemente anwenden. Bei GUI-Frameworks mit Layoutmanagern entfällt das alles komplett. Mox schrieb: > Nur weil Du keine Ahnung vom API hast, heißt das noch lange nicht, dass > damit gar nichts geht! Es geht nicht darum ob es "geht". Wahrscheinlich können alle genannten GUI-Frameworks das, was der TO braucht. Die Frage ist nur, wie einfach oder umständlich es ist. Wenn das mit dem Win32-API alles so einfach ist, warum macht MS sich die Mühe und entwickelt WPF?
Muss man nicht, das System macht das automatisch für die Standard Dialoge und Menüs. @Programmierer: warum hälst du dich nicht raus, wenn du noch nie Win32 Api programmiert hast? Kannst ja deinen eigenen Thread über das rückständige Win32 aufmachen.
Udo K. schrieb: > Muss man nicht, das System macht das seit Urzeiten. Kannst du einen Link und/oder Beispiel zur Erläuterung zeigen? Udo K. schrieb: > @Programmierer: warum hälst du dich nicht raus, > wenn du noch nie Win32 Apis programmiert hast? Die Win32-API-Fraktion hat anscheinend auch noch nie mit moderneren Systemen programmiert und hält sich auch nicht raus. Oder hat hier jemand wirklich sowohl Gtk+, WPF, Win32-API, Qt genutzt und kann das qualifiziert vergleichen?
Udo K. schrieb: > für die Standard > Dialoge und Menüs. Ah, da ist die Crux. GUIs bestehen halt nicht nur daraus.
Programmierer schrieb: > Ach, wie funktioniert das? Das ist im einfachsten Fall ein Opt-In im Manifest, der Dialog-Manager regelt dann den Rest (sofern Du das möchtest, Du kannst jederzeit hin- und her schalten). Und um auch mal 'ne Funktion beim Namen zu nennen: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setdialogdpichangebehavior Mit dieser Funktion kannst Du nämlich das automatische Resizen und/oder Re-Layouten ein-/abschalten. Ansonsten, wenn Dich das tatsächlich interessiert, schaust Du Dir das mal an: https://channel9.msdn.com/events/Build/2017/P4085?term=DPI&lang-en=true Programmierer schrieb: > Da muss man manuell auf die DPI-Änderung achten, Wenn man das, was das System zu bieten hat, nicht nutzen möchte, stimmt das. Man kann sich aber durchaus auch helfen lassen.
Programmierer schrieb: > Ah, da ist die Crux. GUIs bestehen halt nicht nur daraus. Meine Güte. Du verstehst ja wirklich gar nichts. Werde glücklich mit C#, aber erlaube Dir bitte kein Urteil mehr über Dinge, von denen Du nichts verstehst.
Programmierer schrieb: > Die Win32-API-Fraktion hat anscheinend auch noch nie mit moderneren > Systemen programmiert und hält sich auch nicht raus. Oder hat hier > jemand wirklich sowohl Gtk+, WPF, Win32-API, Qt genutzt und kann das > qualifiziert vergleichen? Ich mache fast nur embedded und habe wenig Erfahrungen mit Designern, angefangen von Delphi über MFC, C# etc. Als ich vor ein paar Jahren eine PC-Emulation unseres Steuergerätes schreiben wollte, habe ich mich gegen den Rat aller Kollegen durch die WIN32-Api gequält, mit Dem Uralten Petzold-Buch (falls doch noch jemand haben möchte :-) Am Ende bot die WIN32-Api einige Vorteile, die so zusammen mit kaum einem Framework einfach gewesen wären (zumindest nicht über die Zeit): * Buttons: Ja, anordnern per Hand. Dafür kann ich einfach die jeweils aktuelle Tastaturfolie projektabhängig in die Tasten bitblitten (statt jeweils neu designen oder von hinten durch die Brust). * Bildschirm: Im Grafikmodus kann relativ schnell der ORiginalcode laufen, im Textmodus kann ich per Bitblitten die original-Zeichen der Steuerung (also Bitmap abgelegt, unicode, > 40.000 Zeichen) bitblitten. Ich hab dann nicht das gleiche, sondern wirklich dasselbe. * Seit XP jeder Win-Version problemlos. Die Kollegen kammen von Zeit zu Zeit und haben dies geht nicht mehr mit das. * keine IDE oder irgendein Designer erforderlich. Also einfach den button 10 Pixel nach rechts und mit gcc im normalen Workflow mit erzeugen. * keine Lib, keine Installation, keine Spezialkenntnis. Für die Basics kann die paar Zeiten Quelltext jeder durchwühlen. Ja, das Windows-Handling nicht, aber wo halt ein Button was tut. In anderen Worten: Mit Win-API konnte ich den Windows-Part inj ein paar Hundert zeilen dem eigentlichen Projekt hinzufügen. Mit allen anderen Frameworks hätte ich das eigentliche Projekt für das Framework verbiegen müssen. Nicht, dass ich WIN-Api liebe oder freiwillig da ein Tool mit machen wollte. Aber ... es hat auch Vorteile.
Mox schrieb: > Meine Güte. Du verstehst ja wirklich gar nichts. Welche Informationen habe ich jetzt genau falsch verstanden? Nur wenn man etwas spezifisches nicht weiß, heißt das nicht, dass man "nichts versteht". Kann man denn nur mit Dialogen eine vernünftige GUI bauen? Wenigstens bin ich nicht der einzige mit dieser Meinung: https://stackoverflow.com/a/2484956/4730685 "Win32 API -- I'd forget about it, if I were you.... Programming UIs directly through the Win32 API is tiresome, messy, and you need to deal with lots of details. It's also not platform-independent at all, but you may or may not be concerned about that."
A. S. schrieb: > Dafür kann ich einfach die jeweils > aktuelle Tastaturfolie projektabhängig in die Tasten bitblitten (statt > jeweils neu designen oder von hinten durch die Brust). Keine Ahnung was eine Tastaturfolie ist, aber Bitmaps darstellen kann wohl jedes Grafik-API. A. S. schrieb: > * Seit XP jeder Win-Version problemlos. Aber gerade die HiDPI-Sache braucht anscheinend allerneuestes Windows... A. S. schrieb: > * keine IDE oder irgendein Designer erforderlich. Also einfach den > button 10 Pixel nach rechts und mit gcc im normalen Workflow mit > erzeugen. Der TO hat schon VS, welches alle Annehmlichkeiten von WPF mitliefert... A. S. schrieb: > * keine Lib, keine Installation, Bei WPF auch nicht. A. S. schrieb: > Mit allen anderen > Frameworks hätte ich das eigentliche Projekt für das Framework verbiegen > müssen. Wieso das? Alle anderen Frameworks können Grafikelemente auch manuell im Code pixelgenau erzeugen, wenn es denn sein muss.
Programmierer schrieb: > Kann man denn nur mit Dialogen eine vernünftige GUI bauen? Nein, das kann man natürlich nicht. Das siehst Du doch in Deinen modernen Umgebungen. Hier gibt es hier keinerlei Container, die Steuerelemente beinhalten. Da fliegt auch alles unkontrolliert über den Bildschirm, das ist mal Modern! Programmierer schrieb: > Wenigstens bin ich nicht der einzige mit dieser Meinung: Du hast NULL Erfahrung und weißt absolut nicht, wovon Du redest. Aber immerhin, nachplappern funktioniert. Applaus!
Programmierer schrieb: > Aber gerade die HiDPI-Sache braucht anscheinend allerneuestes Windows... Interessanter Einwand. Wenn ich mit 'ner modernen Anwendung bekomme ich also das Gleiche ohne Unterstützung des Systems? Aber wie bekomme ich das neueste Framework aus ein so altes System installiert?
Mox schrieb: > Hier gibt es hier keinerlei Container, die > Steuerelemente beinhalten. Da fliegt auch alles unkontrolliert über den > Bildschirm, das ist mal Modern! Was für wirre Gedankengänge. Mox schrieb: > Du hast NULL Erfahrung und weißt absolut nicht, wovon Du redest. Du scheinst ja Bescheid zu wissen. Mox schrieb: > Aber wie bekomme ich > das neueste Framework aus ein so altes System installiert? .Net geht auf jeden Fall auch auf älteren Systemen als Windows 10 1703. Gtk+ und andere, welche schon ewig automatische Layout-Manager haben, liefen auch schon unter XP oder Win2k, wenn ich mich recht erinnere. Aktuelle Versionen natürlich nicht mehr.
Programmierer schrieb: > Du scheinst ja Bescheid zu wissen. Weiß ich auch. Programmierer schrieb: > .Net geht auf jeden Fall auch auf älteren Systemen als Windows 10 1703 API erst recht. Wie kommst Du darauf, dass man dafür die neuesten Windows Versionen benötigen sollte?
Mox schrieb: > Wie kommst Du darauf, dass man dafür die neuesten > Windows Versionen benötigen sollte? Du schriebst es selbst: Mox schrieb: > Und ab dem > Creators-Update (1703) haben per Monitor V2 DPI Awareness, nebst > passenden neuen Funktionen im API.
kennt ihr eine Übersicht über die wichtigsten Methoden in C#. Vllt auf mein Problem zugeschnitten?
Programmierer schrieb: > Du schriebst es selbst: > > Mox schrieb: >> Und ab dem >> Creators-Update (1703) haben per Monitor V2 DPI Awareness, nebst >> passenden neuen Funktionen im API. Ach so, verstehe, Du bekommst per Monitor DPI Awareness ohne Unterstützung des Betriebssystems für Deine Desktopanwendungen. Hast Du weitere Informationen zu diesem Thema?
Key schrieb: > kennt ihr eine Übersicht über die wichtigsten Methoden in C# Da gibt es ziemlich viele... .net ist riesig! IMO lernt man so etwas sowieso nicht durch Durchgehen von Methoden-Listen, sondern indem man jeweils das sucht was man braucht. Fang z.B. hiermit an: https://docs.microsoft.com/de-de/dotnet/framework/wpf/getting-started/walkthrough-my-first-wpf-desktop-application Und Google dann jeweils das was du brauchst.
Programmierer schrieb: > liefen auch schon unter XP oder Win2k, wenn ich mich recht erinnere. > Aktuelle Versionen natürlich nicht mehr. Per Monitor DPI Aware? Zur Erinnerung: Einfache DPI Awareness kam erst mit Vista. Und für DPI Awareness braucht es nicht zwingend einen Layout Manager, zumindest nicht unter Windows.
Mox schrieb: > Ach so, verstehe, Du bekommst per Monitor DPI Awareness ohne > Unterstützung des Betriebssystems für Deine Desktopanwendungen. Hast Du > weitere Informationen zu diesem Thema? Ach, ich hatte etwas durcheinander geworfen. Das was Frameworks wie Gtk+ schon lange können, kann das Win32-Api bis heute nicht (automatische Layout-Manager). Was ab 1703 hinzukommt, ist damit nicht vergleichbar.
Mox schrieb: > Und für DPI Awareness braucht es nicht zwingend einen Layout > Manager, zumindest nicht unter Windows. Nicht zwingend, nein. Aber der macht es einfacher. So einfach, dass man kaum darüber nachdenken muss. Und um einfache Möglichkeiten ging es von Anfang an.
Programmierer schrieb: > Nicht zwingend, nein. Aber der macht es einfacher. So einfach, dass > man kaum darüber nachdenken muss. Genau, also einfach schnell einen Dialog gebastelt und fertig ist's. Per Monitor DPI Awareness bekomme ich sogar noch frei Haus, sofern vom System unterstützt. Einfacher geht's nicht. Programmierer schrieb: > Und um einfache Möglichkeiten ging es > von Anfang an. Und C.
Mox schrieb: > Genau, also einfach schnell einen Dialog gebastelt und fertig ist's. Nur ein Dialog und die GUI ist fertig? Ich dachte das reicht nicht: Mox schrieb: > Programmierer schrieb: >> Kann man denn nur mit Dialogen eine vernünftige GUI bauen? > > Nein, das kann man natürlich nicht. Mox schrieb: > Und C. C# war von Anfang an eine Option. Eine sehr gute.
OK, Du stellst Dich künstlich doof. Aber ich versuch's trotzdem mal: Programmierer schrieb: > Nur ein Dialog und die GUI ist fertig? Ich dachte das reicht nicht: Ein Dialog ist ein Container, der Steuerelemente beinhaltet (der sich beim Wechsel der Skalierung z.B. um die neue Positionierung dieser Steuerelemente kümmert). Gut, das überrascht Dich jetzt. Aber nur mit Containern macht man tatsächlich kein vernünftiges GUI, zumindest ich nicht.
Schon lustig, auf der einen Seite
beschweren sich Leute über 100 Zeilen Code,
schreiben aber 1000 Zeilen Begründung. Die
GUI könnte schon 10mal fertig sein ;)
Es geht dem TO nicht darum eine Mega-GUI
zu bauen die das Marketing beeindrucken kann.
Er will was funktionales, um Messgeräte
anzusteuern. Die GUI ist notwendiges Mittel
zum Zweck des Messens.
Kann man sich da mit angular und sonstigen
fancigen Frameworks die in 5 Jahren wieder
veraltet sind ("das ist ja sooo 2020 die GUI")
eine schöne GUI bauen? Klar.
Kann man die GUI in 3 Zeilen starten und sich
freuen wie schnell das doch ging, nachdem man
grade eine Stunde lang ein Intro-Video über
den GUI-Builder gesehen hat und sich immernoch
fragt warum der horizontale Container nicht
in den Grid Übercontainer will? (Qt macht das gern)
Klar.
Oder, man fokussiert sich auf das Messsystem,
baut die 5 Buttons die man braucht zum starten
und stoppen eben ein, vielleicht noch ne Liste
zum Anzeigen der Messwerte, und kann sich dann
wieder dem eigentlichem Problem wenden, was damit
messen!
Aber gut, heute muss selbst ein Taschenrechner
andockbare Dialoge haben.
Angehängte Dateien:
-
schliessen.PNG
36 KB
kurze Frage: ich möchte mit einem Button eine Form schließen. Ich habe die form über showdialog aufgerufen. Wie muss ich dann vorgehen?
W.S. schrieb: > Nein, ist es nicht. Nach meiner Erfahrung lernt man am besten, wenn man > es sich selbst erarbeitet und am schlechtesten oder gar nicht, wenn > man es von anderen fertig vorgelegt kriegt. Lernen ist eine aktive > Tätigkeit - im Gegensatz zum dressiert-werden. Also darf man in einem Forum keine Fragen stellen und nicht nach Rat und Empfehlungen fragen? :D Am besten erklären wir aktive Leute auch zu selbstverliebten Angebern. Wieso posten Leute ihr Wissen und ihre Projekte im Forum? Das ist doch sinnlos. Die Leute sollen doch aktiv lernen, wozu zeigen andere was sie machen oder wissen? Bestimmt alles dekadente Angeber :D Überhaupt das ganze Forum ist unnötig. Was machst du eigentlich hier? Husch husch zum aktiven lernen und wenn was weißt oder gebaut hast verhalte dich bitte passiv :D
Am besten lernt man, wenn man von gescheiten Leuten abschauen kann. Die gescheiten Leute profitieren davon auch, Wissen nur des Wissens willens wird schnell eine Einbahn. Siehe die grossen Künstler, Leonardo da Vinci, Rembrand, Dürrer etc. Aber auch der wissenschaftliche Nachwuchs ist dort stark, wo die Lehrer an der Spitze der Forschung stehen.
Richtig. Der Mensch lernt durch Abschauen und Nachahmung. Mit zunehmender Erfahrung kommt dann immer mehr Varianz in das abgeschaute so dass man neues Wissen hervorbringen kann. Ohne diese elementare menschliche Eigenschaft wäre jede neue Generation dazu verdammt an der Steinzeit anzuknüpfen und das Rad neu zu erfinden.
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.