C++: Messwerte in Fenster anzeigen

[Paul (Gast)]

Hallo,

ich suche nach einer Lösung Werte in einem Windows Fenster anzuzeigen.
Bin neu was Windows Programmierung an geht und komme nach Stunden 
googlen und rumprobieren zu einer Lösung.

Ich habe Messwerte, welche über eine COM-Schnittstelle eingelesen 
werden. Zurzeit geben ich diese über eine Konsole aus, was sehr unschön 
ist und würde gerne eine Windows WIN32 Applikation (C++) schreiben 
welche die Werte in einem Fenster anzeigt.

Habe über Visual Studio 2015 bereits ein WIN32 Application erstellt 
welche ein Hauptfenster und einen Dialog anzeigt aber ich weiß nicht wie 
ich dort ein Fenster mit Messwerten füllen kann.

Gruß Paul

[Dirk B. (dirkb2)]

Möchtest du eine Tabelle und/oder eine Grafik haben?

[Peter II (Gast)]

Paul schrieb:
> Habe über Visual Studio 2015 bereits ein WIN32 Application erstellt
> welche ein Hauptfenster und einen Dialog anzeigt aber ich weiß nicht wie
> ich dort ein Fenster mit Messwerten füllen kann.

mit was hast du das gemacht, Windows Forms ist doch beim VS2015 nicht 
mehr dabei?

Wenn du flexibel bist, ist das schnelle es mit C# zu machen. Bietet 
alles für eine GUI und die Seriellen Schnittstelle an.

[Sven B. (scummos)]

Ich würde QtCharts nehmen.

[Paul (Gast)]

Hab keine Erfahrung mit C#, aber wenn das der einfachste Weg ist werde 
ich mich mal in C# einarbeiten.

Windows Forms gibt es bei Visual Studio 2015 noch für C# Projekte.

Dirk B. schrieb:
> Möchtest du eine Tabelle und/oder eine Grafik haben?

Eine einfache Tabelle würde vollkommen ausreichen.
Würde die Daten wohl nicht direkt aus der COM-Schnittstelle auslesen, 
sondern aus der Registry lesen aber das sollte unter C# auch kein 
Beinbruch sein.

[Rolf M. (rmagnus)]

Paul schrieb:
> Eine einfache Tabelle würde vollkommen ausreichen.
> Würde die Daten wohl nicht direkt aus der COM-Schnittstelle auslesen,
> sondern aus der Registry lesen aber das sollte unter C# auch kein
> Beinbruch sein.

Du speicherst Messdaten in der Registry!?

[Peter II (Gast)]

Paul schrieb:
> Hab keine Erfahrung mit C#, aber wenn das der einfachste Weg ist werde
> ich mich mal in C# einarbeiten.
>
> Windows Forms gibt es bei Visual Studio 2015 noch für C# Projekte.

Wie hast du denn bis jetzt dein Hauptfenster und den Dialog erzeugt?

[Sheeva P. (sheevaplug)]

Paul schrieb:
> Hab keine Erfahrung mit C#, aber wenn das der einfachste Weg ist werde
> ich mich mal in C# einarbeiten.

Ach, der Peter mal wieder: jedes Problem erschlägt er mit C#, und rührt 
hier immer wieder gerne die Werbetrommel für das proprietäre Zeug. 
Leider vergißt er dabei häufig, daß manche eine Programmiersprache nicht 
zum Selbstzweck lernen und benutzen, sondern, um damit schnell und 
effizient ihre Probleme zu lösen. Naja, Peter kann halt nur C#, und für 
einen, der nur einen Hammer hat, sieht jedes Problem wie ein Nagel aus.

Denn, mal ehrlich -- nur um ein paar Meßwerte in einem Fenster 
anzuzeigen, gleich eine Programmiersprache lernen? Obendrein eine 
proprietäre, mit der man sich in die Einsperrung eines Herstellers und 
seiner Plattform begibt? Obwohl man bereits eine (mindestens) 
gleichwertige, plattformunabhängige und äußerst leistungsfähige 
Programmiersprache wie C++ beherrscht? Das ist nicht einmal mit Kanonen 
auf Spatzen geschossen, sondern mit strategischen Kernwaffen auf 
Pantoffeltierchen.

Wenn Du schon eine neue Sprache für so etwas lernen willst, warum nicht 
eine moderne Skriptsprache wie Python? Damit ist das Anzeigen von 
Meßdaten aus der seriellen Schnettstille eine Sache von wenigen Zeilen, 
und solange Du keine Millionen Meßwerte auf einmal anzeigen willst, ist 
das zweifellos auch mehr schnell genug.

Aber das, was Du vorhast, das geht natürlich auch in C++, ebenso einfach 
und mit einem GUI-Framework wie Qt, GTK oder wxWidgets sogar vollkommen 
ohne irgendwelche Abhängigkeiten und Einsperrungen durch einen 
Hersteller und seine Plattform. Das ist spätestens dann von Vorteil, 
wenn Du Dein Programm irgendwann mal auf einem Raspberry Pi benutzen 
oder vielleicht einmal auf MacOS oder Linux wechseln willst.

> Würde die Daten wohl nicht direkt aus der COM-Schnittstelle auslesen,
> sondern aus der Registry lesen aber das sollte unter C# auch kein
> Beinbruch sein.

Du liest Deine Meßdaten aus der Registry? Wie kommen die denn da hin?

[Paul (Gast)]

Die Messwerte sind Werte die von einem Treiber in die Registry geladen 
werden.

Habe mal mit einem C# Projekt begonnen. Mein Problem ist eigentlich nur 
noch wie ich es erreiche das
private void Form1_Load(object sender, EventArgs e) kontinuierlich 
ausgeführt wird so das der aktuelle Wert immer angezeigt wird.
Im Moment wird es vermutlich nur einmal beim Laden aufgerufen.
Ich möchte keinen Aktualisierungsbuttondas soll automatisch geschehen.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

using Microsoft.Win32;

namespace BatteryDisplayApp
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void textBox1_TextChanged(object sender, EventArgs e)
        {

        }

        private void Form1_Load(object sender, EventArgs e)
        {
                object X = Registry.GetValue("HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum\\ROOT\\BATTERY\\0000\\Device Parameters\\BatteryDriver", "Voltage", 0);
                if(X != null)
                { 
                    this.textBox1.Text = X.ToString();
                }
           
        }
    }
}

[Peter II (Gast)]

Sheeva P. schrieb:
> Ach, der Peter mal wieder: jedes Problem erschlägt er mit C#, und rührt
> hier immer wieder gerne die Werbetrommel für das proprietäre Zeug.

Er wollte eine einfach GUI für Windows - das ist C# eine einfache 
Lösung. Die auf jeden Windows einfach läuft. im Gegensatz zu Python.

Paul schrieb:
> Habe mal mit einem C# Projekt begonnen. Mein Problem ist eigentlich nur
> noch wie ich es erreiche das
> private void Form1_Load(object sender, EventArgs e) kontinuierlich
> ausgeführt wird so das der aktuelle Wert immer angezeigt wird.

das ist der falsche weg. Nimmer einen Timer dieser Ruft dann regelmäßig 
eine Funktion auf.

Etwas besser würde ich es noch mit einen Backgroundworker (Thread) 
gehen, ist aber etwas schwerer.

[Sebastian E. (Gast)]

Für ein einfaches regelmäßiges Auslesen der Registry sollte ein Timer 
reichen. Den findest du als Komponente in der Toolbox-Leiste bei deb 
anderen Steuerelementen.

Für alles was länger braucht solltest du eine. BackgroundWorker nehmen, 
der dann vom Timer regelmäßig gestartet wird. Damit würde diw Arbeit auf 
einen HintergrundThread ausgelagert und die GUI bleibt bedienbar.

[Paul (Gast)]

Anwendung läuft jetzt und ging super fix mit C#.

Aktuallisiere den Wert jetzt mit einem Timer das reicht für meine zwecke 
vollkommen aus.

[nicht"Gast" (Gast)]

Moin,

sry für OT

aber lasst micht mal zusammenfassen.

Paul schrieb:
> Hab keine Erfahrung mit C#, aber wenn das der einfachste Weg ist
> werde
> ich mich mal in C# einarbeiten.

das war um 7:20

Paul schrieb:
> Anwendung läuft jetzt und ging super fix mit C#.

und das um 10:18

Wenn man mal daran denkt, dass das die ersten Gehversuche in C# waren 
ist und zwischendrin eine Frage noch im gestellt wurde ist das eine echt 
kurze Zeit.
Das Selbe in Python hätte warscheinlich deutlich länger gedauert, weil 
die Sprache sich schon in den Grundzügen deutlich unterscheidet.


Leider werde Hater wie Sheeva Plug das nicht wirklich zur Kenntnis 
nehmen.

Grüße

[Rufus Τ. F. (rufus)]

Paul schrieb:
> Die Messwerte sind Werte die von einem Treiber in die Registry geladen
> werden.

Ist das dieses merkwürdige Ding mit dem Usermode-Treiber von letzter 
Woche?

[Thomas (Gast)]

Hallo Zusammen,


noch einfacher und in rund 30 Zeilen Code geht alles in PureBasic.

Null Runtime  kurzes Programm und Sehr schnell.

www.purebasic.de

Gruß Thomas

[nicht"Gast" (Gast)]

Thomas schrieb:
> noch einfacher und in rund 30 Zeilen Code geht alles in PureBasic.


Paul schrieb:
> object X =
> Registry.GetValue("HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum\\ 
ROOT\\BATTERY\\0000\\Device
> Parameters\\BatteryDriver", "Voltage", 0);
>                 if(X != null)
>                 {
>                     this.textBox1.Text = X.ToString();
>                 }


Das ist der code, den Paul selber schreiben musste^^. Mit deinen 
30Zeilen bist du schon hinten dran :)

[Sheeva P. (sheevaplug)]

Peter II schrieb:
> Sheeva P. schrieb:
>> Ach, der Peter mal wieder: jedes Problem erschlägt er mit C#, und rührt
>> hier immer wieder gerne die Werbetrommel für das proprietäre Zeug.
>
> Er wollte eine einfach GUI für Windows - das ist C# eine einfache
> Lösung.

Genau wie mit C++, Python, Lua, Ruby, Perl, und so ziemlich jeder 
anderen Programmiersprache auch.

> Die auf jeden Windows einfach läuft. im Gegensatz zu Python.

Python und alle anderen Genannten laufen auch auf jedem Windows.

> Paul schrieb:
>> [...]
>
> das ist der falsche weg. Nimmer einen Timer dieser Ruft dann regelmäßig
> eine Funktion auf.
>
> Etwas besser würde ich es noch mit einen Backgroundworker (Thread)
> gehen, ist aber etwas schwerer.

...wohl doch nicht so einfach wie zuerst behauptet...

[Peter II (Gast)]

Sheeva P. schrieb:
> Genau wie mit C++, Python, Lua, Ruby, Perl, und so ziemlich jeder
> anderen Programmiersprache auch.

scheinbar nicht, sonst hätte er es ja in C++ auch so schnell 
hinbekommen.

und Python, Lua, Ruby, Perl finde ich auf meine Windows PC nicht. Seint 
also nicht üblich zu sein, im Gegensatz zu .net

> ...wohl doch nicht so einfach wie zuerst behauptet...
es gibt immer einfach und komplexe Lösungen. Hier war scheinbar C# eine 
gute Lösung, es hat schnell zum ziel geführt auch wenn du es nicht wahr 
haben willst.

[Sheeva P. (sheevaplug)]

nicht"Gast" schrieb:
> das war um 7:20
>
> Paul schrieb:
>> Anwendung läuft jetzt und ging super fix mit C#.
>
> und das um 10:18
>
> Wenn man mal daran denkt, dass das die ersten Gehversuche in C# waren
> ist und zwischendrin eine Frage noch im gestellt wurde ist das eine echt
> kurze Zeit.

Ach, das kann man sich ziemlich schnell aus dem Internet 
zusammenkopieren. Die Frage von 09:06 zeigt ja, daß er es nicht wirklich 
verstanden hat.

> Das Selbe in Python hätte warscheinlich deutlich länger gedauert, weil
> die Sprache sich schon in den Grundzügen deutlich unterscheidet.

Du kennst Python nicht, oder?

> Leider werde Hater wie Sheeva Plug das nicht wirklich zur Kenntnis
> nehmen.

"Hater", wie süß. Haste's nicht noch ein bisschen größer? Komm, da geht 
doch bestimmt noch was. ;-) Nee, im Ernst: mir geht nur dieses ständige 
Fänboi-Gesülze vom Peter auf den Keks, der bei jedem Problem mit seinem 
hüperdüper C#-Zeug ankommt, auch wenn eigentlich nach etwas ganz anderem 
gefragt worden war. Hammer, Nagel halt.

[Dumdi D. (dumdidum)]

Sheeva P. schrieb:
> hüperdüper C#-Zeug ankommt, auch wenn eigentlich nach etwas ganz anderem
> gefragt worden war. H

Wobei in diesem Fall das ja eigentlich ganz passend war. Visual Studio 
war schon funktionsbereit und das Microsoft forms dings builder ist ja 
eigentlich ganz ok, geht halt nur mit c#.

[nicht"Gast" (Gast)]

Sheeva P. schrieb:
>> Das Selbe in Python hätte warscheinlich deutlich länger gedauert, weil
>> die Sprache sich schon in den Grundzügen deutlich unterscheidet.
>
> Du kennst Python nicht, oder?

gewagte These. Warum denkst du, dass ich geschrieben habe, was ich 
geschrieben habe.

Python ist von der Syntax und der Art, wie man Sachen umsetzt deutlich 
weiter weg von C++ als C#.

Wenn du von C++ kommst, kannst du nur grobe Programmierkonzepte mit 
benutzen. Schon eine einfache For Schleife sieht in Python deutlich 
anders aus.

Wenn ich schon C++ etwas kann, und schnell was machen möchte, dann nehme 
ich nun mal eine Sprache, die C++ als Vorbild hat und nicht alles anders 
macht.

Dazu kommt noch, das der TE schon VS installiert hat. Da bekommt er C# 
gleich mit dazu. Er muss sich nicht erst Python/QT/Basic irgend wo 
herunter laden.

[nicht"Gast" (Gast)]

Sheeva P. schrieb:
> "Hater", wie süß. Haste's nicht noch ein bisschen größer? Komm, da geht
> doch bestimmt noch was. ;-) Nee, im Ernst: mir geht nur dieses ständige
> Fänboi-Gesülze vom Peter auf den Keks, der bei jedem Problem mit seinem
> hüperdüper C#-Zeug ankommt, auch wenn eigentlich nach etwas ganz anderem
> gefragt worden war. Hammer, Nagel halt.

Lies mal deinen Text selber durch. Du bist hier der einzige, der 
durchgedreht ist.

In dem Fall war das schon ganz gut. Der TE hatte eine Schraube und hat 
gefragt, wie er sie mit dem Hammer reinbekommt. Ihm den Schraubendreher 
zu zeigen war schon nicht schlecht.

BTW nicht alles, was hinkt ist ein Vergleich.

[H-G S. (haenschen)]

Etwas ähnliches habe ich früher mit OpenGL und C++ (DEVC++) gemacht um 
mein Bastel-DSO über den Druckerport am PC anzeigen zu lassen.

[Sheeva P. (sheevaplug)]

nicht"Gast" schrieb:
> gewagte These. Warum denkst du, dass ich geschrieben habe, was ich
> geschrieben habe.

Weil Du nix anderes als C# kennst, Peter. Darum.

> Python ist von der Syntax und der Art, wie man Sachen umsetzt deutlich
> weiter weg von C++ als C#.

Heilige Krabbe, im Ernst? ;-)

[nicht"Gast" (Gast)]

Sheeva P. schrieb:
> Weil Du nix anderes als C# kennst, Peter. Darum.

Falsch, ich bin nicht Peter.

Sheeva P. schrieb:
>> Python ist von der Syntax und der Art, wie man Sachen umsetzt deutlich
>> weiter weg von C++ als C#.
>
> Heilige Krabbe, im Ernst? ;-)


Oh je, was soll man da sagen. Lassen wir doch mal einfachen Code für uns 
sprechen

C++

class foo{
    
    int bar;
      
    public:
         foo(int foobar){
             bar = foobar;
         }         

         void JustDoIt(int foobar){
             for(int i=0;i<=foobar;i++){
                  bar += i;
             }
         }
};

C#

class foo{
    int bar;
    
    public foo(int foobar) {
        bar = foobar;
    }

    public void JustDoIt(int foobar) {
        for(int i = 0; i < foobar; i++) {
            bar += i;
        }
    }
}

Python

class foo:
    def __init__(self,foobar):
         self.__foobar = foobar
         
    def JustDoIt(self,foobar):
         for i in range(100):
               self.__foobar += foobar

Noch ein kleiner Tip hinten dran. Ich habe nie behauptet, dass C# == 
C++. C# ist als Sprache am Ende des Tages deutlich anders. Nur die 
Grundlagen sind deutlich ähnlicher als bei Python. Das macht den Umstieg 
einfacher, wenn man C++ schon kann.

*Hier stand gerade nocht was zum Nachtreten. Hab ich wieder gelöscht*

[Peter II (Gast)]

Sheeva P. schrieb:
> Weil Du nix anderes als C# kennst, Peter. Darum.

ich kenne Perl, C++, VB, ASM(AVR), C# - und entscheide mich für die 
Sprache mit der ich ein Problem am schnellsten lösen kann. Und schließe 
dabei nicht einfach eine Sprache aus nur weil sie von MS ist.
Für eine GUI unter Windows setze ich ungern C++ ein, weil ICH damit 
einfach zu lange brauche dafür noch extra Zeug brauche (QT, WX, 
WindowsForms).
.net läuft das gleiche Binary als 64, 32 oder ARM. Im Framework ist 
alles enthalten was man so braucht.

Ich sehe ja ein, das du C# nicht verwenden willst. Aber höre mit den 
sinnlosen Geschimpfe auf wenn jemand (ich) C# er Lösung vorschlage, du 
aber sonst nichts sinnvolle zum Thread beigetragen hast.

[Karl Käfer (Gast)]

Peter II schrieb:
> Für eine GUI unter Windows setze ich ungern C++ ein, weil ICH damit
> einfach zu lange brauche dafür noch extra Zeug brauche (QT, WX,
> WindowsForms).

Gibt's die guten alten MFC denn nicht mehr im Visual Studio?

[Karl Käfer (Gast)]

nicht"Gast" schrieb:
> Python
>

> class foo:
>     def __init__(self,foobar):
>          self.__foobar = foobar
> 
>     def JustDoIt(self,foobar):
>          for i in range(100):
>                self.__foobar += foobar
>

Das Beispiel ist erstens fehlerhaft und zweitens sieht man die 
Unterschiede nicht sonderlich gut -- das bisschen Syntax und Benamsung 
dürfte erfahrene Entwickler wohl kaum abschrecken:

class foo:
  def __init__(self, foobar):
    self._bar = foobar

  def JustDoIt(self, foobar):
    for i in range(foobar):
      self._bar += i

Bezogen auf die Ausgangsfrage des TO sieht man, daß die Unterschiede 
deutlich größer sind, gerade in der hier gezeigten einfachen, 
Nicht-OO-Variante:

from Tix import Tk, END, Text, mainloop
from Microsoft.Win32 import Registry

def f():
    t.insert(END, Registry.GetValue("HKEY_LOCAL_MACHINE\\SYSTEM"+ 
      "\\CurrentControlSet\\Enum\\ROOT\\BATTERY\\0000\\Device"+
      "Parameters\\BatteryDriver", "Voltage"))
    t.after(500, f)

t = Text(Tk(), height=20, width=30)
t.pack()
t.after(500, f)
mainloop()

Auch die OO-Version arbeitet die Unterschiede IMHO besser heraus:

from Tix import Tk, END, Text, mainloop
from Microsoft.Win32 import Registry

class MainWin(Tk):
  def __init__(self):
    Tk.__init__(self)
    self.t = Text(self, height=20, width=30)
    self.t.pack()
    self.t.after(500, self.f)
    
  def f(self):
    self.t.insert(END, Registry.GetValue(
      "HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet" + 
      "\\Enum\\ROOT\\BATTERY\\0000\\Device"+
      "Parameters\\BatteryDriver", "Voltage"))
    self.t.after(500, self.f)

MainWin().mainloop()

[Chris F. (chfreund)]

Wozu denn das .net-Zeug? Da reicht auch eine Windowsanwendung wie der TO 
erfragt.

Frameworks die das nativ können sind z.B.:

- MFC
-- Ultimate-Toolbox
-- Ultimate-Grid
-- XListCtrl (von Codeproject)
- qt
- wxWidgets

Für so eine Anwendunge die man monolithisch baut und später sicher so 
gut wie nie aktualisiert ist es immer besser ein Framework wie wxWidgets 
zu nehmen, bei dem der Einstieg nicht so schwer ist und welches mit 
einer statischen Linkage auf allen üblichen Windosen läuft. Obendrein 
hat man damit direkt eine spätere Portabilität vorbereitet. Dann gibt es 
keine Runtimes die nachinstalliert werden müssen und viele weitere 
Vorteile.

Wenn man schon C/C++ kann und einen schnellen und einfachen Einstieg in 
Windows-GUIs zusammen mit hardwarenaher Entwicklung will ist C#-.net 
nicht unbedingt die 1. Wahl.

[Peter II (Gast)]

Chris F. schrieb:
> Frameworks die das nativ können sind z.B.:
>
> - MFC

MFC gibt es nicht mehr bei der Expressversion vom VS.

> Für so eine Anwendunge die man monolithisch baut und später sicher so
> gut wie nie aktualisiert ist es immer besser ein Framework wie wxWidgets
bis man das auf den Rechner lauffähig hat (incl. Gui Editor) hat man in 
.net die Anwendung fertig.

> Dann gibt es
> keine Runtimes die nachinstalliert werden müssen und viele weitere
> Vorteile.
.net ist bei alle aktuellen Windows Versionen schon drauf, also warum 
nicht dinge einfach nutzen die da sind.

> Obendrein hat man damit direkt eine spätere Portabilität vorbereitet.
.net läuft sogar ohne neu Kompilierung auf Linux - was will man mehr.

[nicht"Gast" (Gast)]

Karl Käfer schrieb:
> Das Beispiel ist erstens fehlerhaft und zweitens sieht man die
> Unterschiede nicht sonderlich gut -- das bisschen Syntax und Benamsung
> dürfte erfahrene Entwickler wohl kaum abschrecken:

Huch, du hast recht. Erst waren alle drei Beispiele so und aus irgend 
einem Grund habe ich das bei den andern beiden dann geändert.

Ich glaube nicht, das der TE ein erfahrener Entwickler ist :).

Dein Beispiel ist allerdings besser geeignet, die Unterschiede 
darzustellen.


Grüße

[Chris F. (chfreund)]

Peter II schrieb:
>> Für so eine Anwendunge die man monolithisch baut und später sicher so
>> gut wie nie aktualisiert ist es immer besser ein Framework wie wxWidgets
> bis man das auf den Rechner lauffähig hat (incl. Gui Editor) hat man in
> .net die Anwendung fertig.

Eine Anwendung mit einer Tabellendarstellung ist in wxWidgets in ein 
paar dutzend Codezeilen erledigt und man braucht ausdrücklich keinen 
GUI-Editor dafür.

Bekommst Du Provision für den proprietären Kram, Peter?

---

Von allen plattformübergreifenden Bibliotheken ist mono mit c# das mit 
Abstand mieseste was man einsetzen kann. Das ist dafür da, dass man mit 
einer breiten c#-codebasis schneller auf andere Plattformen kommt und 
nicht um ganz neue Sachen zu machen.

Wer, der hardwarenah arbeitet und schon C++ kann, fängt denn für eine 
grafische Darstellung von ein paar Messwerten an .net-c# zu lernen?

C++ ist am Ende immer schneller plattformunabhängig, performanter und 
einfacher in der Wartung als java, .net oder andere 
vm-runtime-interpreter-Systeme. Nativer Code ist einfach nativer Code.

C# hat auf jeden Fall Vorteile, für diesen Anwendungsfall aber leider 
nicht.
Das ist hier nichts wo ich mehrere "Fachinformatiker 
Anwendungsentwicklung" daran setze monatelang eine Anwendung mit einer 
komplexen modularen GUI zu stricken und dann zu betreuen. Dafür hat C# 
und java natürlich Vorteile weil ich günstigere Entwickler nehmen kann 
oder "Nichtprogrammierer" die das fachliche Knowhow einer Anwendung 
reinbringen schneller die grundlegende Verwendung beigebracht habe. Das 
ist auch der Grund warum heute .net und java so langsam Cobol in 
Geschäftsanwendungen ablöst.

[Peter II (Gast)]

Chris F. schrieb:
> Eine Anwendung mit einer Tabellendarstellung ist in wxWidgets in ein
> paar dutzend Codezeilen erledigt und man braucht ausdrücklich keinen
> GUI-Editor dafür.

ja, wenn man Erfahrung hat eventuell. Jemand der es noch nicht auf dem 
PC hat, braucht dafür ein Stück länger

> Bekommst Du Provision für den proprietären Kram, Peter?

welcher proprietären Kram?

.net ist teilweise Opensource und ECMA-Standardisiert. Genau wie 
Javascript und andere Sprachen.

[Chris F. (chfreund)]

Peter II schrieb:
> .net ist teilweise Opensource und ECMA-Standardisiert. Genau wie
> Javascript und andere Sprachen.

Proprietär bedeutet, dass .net core, xamarin, mono usw. alle einer Firma 
gehören die selber entscheidet wohin die Reise geht.

"Teilweise quelloffen" und das die Sprache standardisiert ist heißt 
nicht das es nicht proprietär ist. Das ganze Konstrukt wird eigentümlich 
und ausschließlich von einer einzigen Firma erstellt und 
weiterentwickelt und genau das bedeutet proprietär. Es ist unfreie 
Software.

Ich wünsche Dir eine gute Nacht. ;-)

[Jemand (Gast)]

Chris F. schrieb:
> Peter II schrieb:
> .net ist teilweise Opensource und ECMA-Standardisiert. Genau wie
> Javascript und andere Sprachen.
>
> Proprietär bedeutet, dass .net core, xamarin, mono usw. alle einer Firma
> gehören die selber entscheidet wohin die Reise geht.
>
> "Teilweise quelloffen" und das die Sprache standardisiert ist heißt
> nicht das es nicht proprietär ist. Das ganze Konstrukt wird eigentümlich
> und ausschließlich von einer einzigen Firma erstellt und
> weiterentwickelt und genau das bedeutet proprietär. Es ist unfreie
> Software.
>
> Ich wünsche Dir eine gute Nacht. ;-)

.NET core sowie Mono ist unter der MIT Lizenz verfügbar und damit 
eindeutig freie Software!

[Markus (Gast)]

nicht"Gast" schrieb:
> Schon eine einfache For Schleife sieht in Python deutlich
> anders aus.

Na und? Ich muss doch verstehen was eine Schleife macht. Ob ich dann 
Python, C++ oder sonst eine Syntax benutze ist doch recht egal.

Generell hat so ziemlich jede Sprache ihre Berechtigung. Informatiker 
lieben halt ihr .Net, da sie ja auch immer genug Performance zur 
Verfügung haben. Andere haben dieses Glück nicht und beziehen sich dann 
auf Sprachen wie C++, Python, ...

Ich habe auch mit Visual Basic damals angefangen zu programmieren. Heute 
nutze ich auch nur noch C/C++ und Python. Gründe hierfür sind einfach, 
dass man viel mehr Freiheiten mit diesen Sprachen hat, andersum aber 
auch deutlich mehr Fallstricke.

[nicht"Gast" (Gast)]

Markus schrieb:
> nicht"Gast" schrieb:
>> Schon eine einfache For Schleife sieht in Python deutlich
>> anders aus.
>
> Na und? Ich muss doch verstehen was eine Schleife macht. Ob ich dann
> Python, C++ oder sonst eine Syntax benutze ist doch recht egal.

Sehr schön gemacht. Etwas genommen, den Zusammenhang entfernt und einen 
unnützen Kommentar drunter geschrieben.

Markus schrieb:
> Generell hat so ziemlich jede Sprache ihre Berechtigung. Informatiker
> lieben halt ihr .Net, da sie ja auch immer genug Performance zur
> Verfügung haben. Andere haben dieses Glück nicht und beziehen sich dann
> auf Sprachen wie C++, Python, ...
>
> Ich habe auch mit Visual Basic damals angefangen zu programmieren. Heute
> nutze ich auch nur noch C/C++ und Python. Gründe hierfür sind einfach,
> dass man viel mehr Freiheiten mit diesen Sprachen hat, andersum aber
> auch deutlich mehr Fallstricke.

Alles Sch?ampen außer Mutti oder? So Klingt dein Gesülze.

[Rolf M. (rmagnus)]

Peter II schrieb:
> .net ist teilweise Opensource und ECMA-Standardisiert.

Und mit Patenten vermint.
http://en.swpat.org/wiki/.NET,_C-sharp,_and_Mono

Jemand schrieb:
> .NET core sowie Mono ist unter der MIT Lizenz verfügbar und damit
> eindeutig freie Software!

Nein, unter MIT-Lizenz ist es keine freie Software, aber das ist ein 
anderes Thema. Es ist immerhin OpenSource.
Ist aber auch egal, denn mit Patenten kann man auch freie Software 
kontrollieren. Die sind unabhängig von der Lizenz, da sich die Lizenz 
nur auf die konkrete Umsetzung bezieht, das Patent dagegen auf die Ideen 
dahinter. Damit hat das Patent eine viel größere Auswirkung, da es nicht 
nur die Nutzbarkeit der einen Implementation einschränken kann, sondern 
auch die alternativer Implementationen wie Mono.

[Peter II (Gast)]

Rolf M. schrieb:
> Peter II schrieb:
>> .net ist teilweise Opensource und ECMA-Standardisiert.
>
> Und mit Patenten vermint.
> http://en.swpat.org/wiki/.NET,_C-sharp,_and_Mono

und welche Sprache ist das nicht? Nur weil niemand patente auf eine 
Sprache erstellt hat, heißt das noch lange nicht das jemand anderes 
nicht ein Patent auf einen Teil davon hat. (Google vs Oracle)

Schau dir doch mal Video-Codec' an, es ist fast unmöglich eine neuen 
guten Codec zu entwickeln ohne irgendwelche Patente zu verletzen.

Und wer Software für Windows entwickelt (muss oder will) hängt mehr oder 
weniger eh an MS. Das stellt zumindest für mich bis jetzt kein Problem 
dar.

Vermutlich gibt es überall Patente, nur bei ein paar OpenSource 
Entwicklung kann man halt auf viele Millionen $$$ verklagen.

[Chris F. (chfreund)]

Jemand schrieb:
> .NET core sowie Mono ist unter der MIT Lizenz verfügbar und damit
> eindeutig freie Software!

Das ist weder freie Software noch sollte man freie Software damit bauen.

https://www.fsf.org/de/wieso-freie-software-nicht-von-mono-oder-c-abhaengen-sollte

Informiere Dich mal genauer. Ich habe allgemein nichts gegen c# und 
setze das auch in Projekten ein und ich finde es toll, dass Du etwas 
gefunden hast was Dir gefällt. Aber auch ein Fanboy sollte bei den 
Fakten bleiben. Finde erstmal heraus was freie Software ist und wie 
proprietär definiert ist.

[Peter II (Gast)]

Chris F. schrieb:
> Finde erstmal heraus was freie Software ist und wie
> proprietär definiert ist.

hast du es denn gemacht?

https://de.wikipedia.org/wiki/Propriet%C3%A4r

insbesondere der Abschnitt

Unterschiede zwischen den Definitionen 2.2 und 3

Nach 3 ist es nicht Proprietär, weil es ein ISO Standard ist.

[Chris F. (chfreund)]

Du windest und wendest Dich hier immer weiter, antwortest nur zur Hälfte 
mit ergoogeltem Zeug.

Was ist für Dich freie Software? Das ist nicht das Gegenteil von 
"proprietär".

Proprietär (lateinisch für Besitzer) bedeutet, dass der Rechteinhaber 
seine Besitzrechte gültig macht und nur eine herstellergebundene 
Verwendung ermöglicht. Das steht auch so in ganz wesentlichen Teilen 
aller .net-EULA's.

Genauso wie die java-vm von oracle keine freie Software ist, ist die 
.net-Runtime auf Windows keine freie Software und proprietär. Beides 
kann aber als Plattform für freie Software dienen. Sobald der Proprietär 
der Runtimesoftware aber sein Lizenzmodell ändert ist diese Software (in 
Teilen) nicht mehr einsetzbar.

Das ist ja auch nicht schlimm. Es ist aber Unsinn das nicht zu benennen. 
Das da die Programmiersprache standardisiert ist und ausgewählte Teile 
der Runtime quelloffen (ohne echte Möglichkeit eigene Änderungen zum 
laufen zu bringen) sind ist nur Augenwischerei. Es gibt nicht ein 
bisschen schwanger. ;)

[Arc N. (arc)]

Chris F. schrieb:
> Peter II schrieb:
>>> Für so eine Anwendunge die man monolithisch baut und später sicher so
>>> gut wie nie aktualisiert ist es immer besser ein Framework wie wxWidgets
>> bis man das auf den Rechner lauffähig hat (incl. Gui Editor) hat man in
>> .net die Anwendung fertig.
>
> Eine Anwendung mit einer Tabellendarstellung ist in wxWidgets in ein
> paar dutzend Codezeilen erledigt und man braucht ausdrücklich keinen
> GUI-Editor dafür.
>
> Bekommst Du Provision für den proprietären Kram, Peter?

Was ist denn an .NET noch proprietär 1) abgesehen von einigen 
GUI-Sachen, die man nicht unbedingt nutzen muss und für die es 
Alternativen, auch von MS, wie bspw. Xamarin.Forms gibt 2)

1) bspw.:
- Roslyn-Compilerplatform Apache-Lizenz
- .NET Core MIT-Lizenz
- ASP.NET Core Apache-Lizenz
usw.usf https://dotnetfoundation.org/projects?type=project
C# an sich ist seit Ewigkeiten ein ECMA-Standard

2)
- https://github.com/xamarin/Xamarin.Forms (MIT-Lizenz)
- AvaloniaUI https://github.com/AvaloniaUI wäre eine 
Nicht-MS-Alternative (ebenso unter MIT Lizenz)

>
> ---
>
> Von allen plattformübergreifenden Bibliotheken ist mono mit c# das mit
> Abstand mieseste was man einsetzen kann. Das ist dafür da, dass man mit
> einer breiten c#-codebasis schneller auf andere Plattformen kommt und
> nicht um ganz neue Sachen zu machen.
>
> Wer, der hardwarenah arbeitet und schon C++ kann, fängt denn für eine
> grafische Darstellung von ein paar Messwerten an .net-c# zu lernen?
>
> C++ ist am Ende immer schneller plattformunabhängig,

Schön wär's... damit die User eine Anwendung haben, die sich nicht wie 
ein Fremdkörper anfühlt oder so aussieht, ist immer haufenweise 
plattformabhängiger Code notwendig. Je nach Anwendung und Framework mal 
mehr mal weniger

> performanter und

Qt ist es schon mal nicht. Weder bei den Programmstartzeiten noch bei 
UI-Updates noch sonst wo

> einfacher in der Wartung als java, .net oder andere

Sieht man an den ständigen Sicherheitslücken in C/C++-Anwendungen und 
den div. Anwendungen die ihre eigenen Versionen von Libraries 
mitbringen/nutzen wollen und mit nichts anderem laufen.

> vm-runtime-interpreter-Systeme. Nativer Code ist einfach nativer Code.

.NET Native/CoreRT https://github.com/dotnet/corert


> C# hat auf jeden Fall Vorteile, für diesen Anwendungsfall aber leider
> nicht.
> Das ist hier nichts wo ich mehrere "Fachinformatiker
> Anwendungsentwicklung" daran setze monatelang eine Anwendung mit einer
> komplexen modularen GUI zu stricken und dann zu betreuen. Dafür hat C#
> und java natürlich Vorteile weil ich günstigere Entwickler nehmen kann

Autsch... Das geht auch dort ebenso schief wie bei C++ oder irgendeiner 
anderen Sprache

> oder "Nichtprogrammierer" die das fachliche Knowhow einer Anwendung
> reinbringen schneller die grundlegende Verwendung beigebracht habe.

Zumindest beim UI liegt dies schlicht an der strikteren und besseren 
Trennung von Präsentation und Code wie sie in neueren Frameworks (XAML, 
QML etc.) umgesetzt ist.

Rolf M. schrieb:
> Peter II schrieb:
>> .net ist teilweise Opensource und ECMA-Standardisiert.
>
> Und mit Patenten vermint.
> http://en.swpat.org/wiki/.NET,_C-sharp,_and_Mono

Vielleicht sollten die mal ihre Seiten updaten (es wurde u.a. seit 
Bestehen der Seite noch nicht einmal ansatzweise versucht eine Liste der 
"gefährlichen" Patente zu benennen...) und/oder mit der Realität 
abgleichen  (nichts von dem was dort herbeigeredet wird und wurde hat 
sich bestätigt).

C++ ist weniger gefährdet? Wie wär's mit C++-Bibliotheken, vielleicht 
gar objektorientierten: AT&T 
http://www.freepatentsonline.com/EP0696770B1.html
"A library of C++ classes for use in writing data visualization 
programs. The library embodies a general design principle for class 
libraries: that the classes are partitioned into entity classes and 
functionality classes."
oder entwickelt Benutzeroberflächen 
https://patents.google.com/?q="user+interface"; Viel Spaß bei den "about 
2,741,088 results" oder den 191779 Ergebnissen die C++ und Library 
liefern (https://patents.google.com/?q=c%2b%2b&q=library)


> Jemand schrieb:
>> .NET core sowie Mono ist unter der MIT Lizenz verfügbar und damit
>> eindeutig freie Software!
>
> Nein, unter MIT-Lizenz ist es keine freie Software, aber das ist ein
> anderes Thema. Es ist immerhin OpenSource.

https://www.gnu.org/licenses/license-list#X11License
"Eine nicht strenge, freizügige freie Softwarelizenz ohne Copyleft und 
mit der GNU GPL vereinbar...Diese Lizenz wird manchmal MIT License 
genannt, aber dieser Begriff ist irreführend, da MIT viele Lizenzen für 
Software benutzt hat."
Dann den verlinkten Text der Lizenz lesen 
(https://directory.fsf.org/wiki/License:X11) und mit dem der MIT-Lizenz 
vergleichen, den MS verwendet (z.B.: 
https://github.com/dotnet/corert/blob/master/LICENSE.TXT)


> Ist aber auch egal, denn mit Patenten kann man auch freie Software
> kontrollieren. Die sind unabhängig von der Lizenz, da sich die Lizenz
> nur auf die konkrete Umsetzung bezieht, das Patent dagegen auf die Ideen
> dahinter. Damit hat das Patent eine viel größere Auswirkung, da es nicht
> nur die Nutzbarkeit der einen Implementation einschränken kann, sondern
> auch die alternativer Implementationen wie Mono.

Mono = Xamarin und Xamarin gehört seit einiger Zeit zu MS. Wen soll MS 
da also verklagen? Sich selbst?

[Peter II (Gast)]

Chris F. schrieb:
> Proprietär (lateinisch für Besitzer) bedeutet, dass der Rechteinhaber
> seine Besitzrechte gültig macht und nur eine herstellergebundene
> Verwendung ermöglicht. Das steht auch so in ganz wesentlichen Teilen
> aller .net-EULA's.

das mag ja für dich sein, aber ich glaube an der Stelle lieber Wiki und 
dort steht das Software Proprietär ist wenn "nicht veröffentlichten 
Standards basiert" das ist bei .net nicht der Fall auch wenn du es nicht 
glauben willst.

[Rolf M. (rmagnus)]

Arc N. schrieb:
>> performanter und
>
> Qt ist es schon mal nicht. Weder bei den Programmstartzeiten noch bei
> UI-Updates noch sonst wo

Also ich hab schon mehrere Qt-Programme geschrieben, bei denen die 
Grafik schnell sein muss und hatte nie Probleme damit. Und 
Programmstartzeiten liegen selbst bei sehr großen Programmen in schon 
fast nicht mehr wahrnehmbaren Bereichen.

> https://www.gnu.org/licenses/license-list#X11License
> "Eine nicht strenge, freizügige freie Softwarelizenz ohne Copyleft und
> mit der GNU GPL vereinbar...

Hmm, ich hatte freie Software immer mit Copyleft in Verbindung gebracht 
und deshalb angenommen, alle Lizenzen ohne Copyleft seien keine freien 
Softwarelizenzen. Nach dem Motto: Software ist nur dann frei, wenn auch 
garantiert ist, dass alle davon abgeleiteten Werke ebenfalls frei sind. 
Aber das ist dann wohl nicht so.

Peter II schrieb:
> Chris F. schrieb:
>> Proprietär (lateinisch für Besitzer) bedeutet, dass der Rechteinhaber
>> seine Besitzrechte gültig macht und nur eine herstellergebundene
>> Verwendung ermöglicht. Das steht auch so in ganz wesentlichen Teilen
>> aller .net-EULA's.
>
> das mag ja für dich sein, aber ich glaube an der Stelle lieber Wiki und
> dort steht das Software Proprietär ist wenn "nicht veröffentlichten
> Standards basiert" das ist bei .net nicht der Fall auch wenn du es nicht
> glauben willst.

Zitat aus dem von dir genannten Wikipedia-Link:

Protokolle, Dateiformate und Ähnliches werden als „proprietär“ 
bezeichnet, wenn sie nicht oder nur mit Schwierigkeiten von Dritten 
implementierbar und deshalb nicht zu öffnen oder zu lesen sind, weil sie 
z. B. lizenzrechtlich, durch herstellerspezifisches Know-how oder durch 
Patente beschränkt sind.

[Peter II (Gast)]

Rolf M. schrieb:
> Zitat aus dem von dir genannten Wikipedia-Link:
>
> Protokolle, Dateiformate und Ähnliches werden als „proprietär“
> ...

bitte auch noch eine Absatz weiter lesen

> Unterschiede zwischen den Definitionen 2.2 und 3

[Rolf M. (rmagnus)]

Peter II schrieb:
> bitte auch noch eine Absatz weiter lesen
>
>> Unterschiede zwischen den Definitionen 2.2 und 3

Ja, ok, wenn man sich die Definition raussucht, die einem gerade am 
besten passt, dann kann man damit vieles für nicht proprietär erklären.

[Chris F. (chfreund)]

Rolf, gehe da einfach nicht drauf ein.

Er hat doch schon geschrieben, dass die EULA für das .net-Framework auf 
Windows für ihn nicht relevant ist und er nur ausgesuchte Teile von 
Wikipedia-Artikeln auf ausgesuchte Teile der Mono-Lizenz mit Hilfe von 
selektivem Glauben anwendet.

Das ist für ihn ein spiritueller Akt und eine religiöse Bekehrung. :-D

Gute Nacht zusammen.