Dazu gibt es einen Haken in den Einstellungen der Gruppe.

Man kommt daran, wenn man die Zeile markiert und dann mit der rechten Maustaste in das graue Kästchen neben der Tabelle klickt.
Oder über die Gruppen-Ebenen, wenn man sich das Fenster eingeblendet hat.

Hat aber jetzt nicht so viel mit C# zu tun, oder?

Eines der schlimmsten Beispiele ist in meinen Augen Excel.

Wenn man Formeln eindeutscht, wird´s echt kurios. Und die Möglichkeit etwas online zu recherchieren, senkt sich von weltweit auf den deutschsprachigen Raum.
Getoppt wird das nur noch von Microsoft PowerApps und PowerAutomate.

Daher bin ich auch dafür: Eigenständige, englische Begriffe beizubehalten.

Die embedded Geräte mit denen ich gearbeitet habe, hatten im worst case 128MB RAM und 512MB Speicher.

Da hat ein Log(-file) schnell den Platz belegt, wenn man nicht aufgepasst hat. Daher habe ich immer offline als Ringspeicher geloggt und sofern eine Netzwerkverbindung bestand, an eine Datenbank übertragen.

BTT: Persönlich finde ich es am Besten einmal im Konstruktor einen Logger mitzugeben. Ist dieser null, greift eine standard implementierung. Im Zweifel Abt´s ThrowAwayLogger, der nix tut.

So kann ich eine Library ohne viel Aufwand testen und ein Gefühl dafür bekommen ob sie das macht was ich brauche. Entspricht sie meiner Erwartung, programmiere ich den Logger aus.

Das senkt die Einstiegshürde. Es gibt nix nervigeres als erstmal 10 Klassen schreiben zu müssen um dann zu merken, dass die Library gar nicht tut was man sucht!

Moin,

wie kommst Du darauf dass Deine Berechnung Dir Zoll zurückliefert?

Du hast Width und Density. In diesem Fall gibt die Breite die Anzahl der Pixel an. Da die Screens heutzutage alle extrem hochauflösend sind, hättest Du nun bei allen Apps winzige Symbole und Schriften.
Um das zu kompensieren, gibt es die "Density". Also wie viele echte Pixel einem dargestellten Pixel entsprechen.

Das Ergebnis hat also nichts mit Inches zu tun.

Das hat ja nix mit dem Webservice an sich zu tun.

Du fängst einen etwaigen Error mit catch im Task ab. Aber nicht ob der Webservice selbst korrekt durchläuft.

Daher nehme ich an, erhältst Du nur den Fehler des Tasks.

Versuch mal sowas in der Art:

t = Task.Run(() =>
        {
            try{
                BuchblattService.Create(UserData.BuchblattAB, ref buchblatt);
                }
                catch(Exception ex)
                {
                	MessageBox.Show(ex.Message);
                }
        });

Problematisch an den Webservices, die automatisch per Webreferenz hinzufügen erstellt wurden, Du hast keinen Zugriff auf den echten WebResponse. Aber aus der o.g. Nachricht sollte sich schon was sinnvolleres extrahieren lassen!

In Navision/Business Central musst Du die Meldungen praktisch auf zwei Ebenen abprüfen:

Klassischer http-Error (403, 404, usw.) mit dessen Beschreibung. Nicht Authorisiert, nicht gefunden, etc.

Bei einem 500, bekommst Du per SOAP eine Antwort im Body mit. Und genau dort steht 1:1 die Fehlermeldung aus Nav.

Die muss man dann aber natürlich aus dem XML noch auspacken.

Sofern !HttpResponseMessage.IsSuccessStatusCode

Dann im Response auf den XML-Knoten "faultstring" prüfen.

Sicher dass das am Framework liegt und nicht am Wechsel von z.B. Windows Forms auf WPF?

In WPF kannst Du folgendes verwenden:

Mouse.OverrideCursor = Cursors.Wait;
//Reset
Mouse.OverrideCursor = null;

Danke für Deine Rückmeldung 🙂

Und schön, dass Du meinen ersten Eindruck von ScottPlott bestätigst.

Ich probiere morgen mal ScottPlot aus. vielleicht klappt das ja besser.

Das verwende ich in einem kleinen Projekt und ich bin begeistert! Das ist echt flott, einfach und zu verwenden.

Es gibt ein paar minimale Einschränkungen, wo man sich etwas mit Workarounds helfen kann/muss. Z.B. ist die Darstellung von Tooltips, so wie ich sie mir z.B. vorstelle, etwas kompliziert.
Funktioniert aber mit ein bisschen Programmierung.

111.822 Datenpunkte laden zügig (unter 1 Sekunde), siehe Anhang.

Okay, der Text ist in der Tat identisch zu den anderen Daten zu behandeln.
Einzelne Bytes werden in char gewandelt und können ausgegeben werden.

Durch die ganze Rumprobiererei mit den Encodings und den Anfangs vielversprechenden Ergebnissen, habe ich mich da aber offensichtlich in eine Sackgasse manövriert.

Des Rätsels Lösung ist tatsächlich:
Einlesen der Datei mit dem BinaryReader ohne Encoding.
Die Längen der "Texte" sind < 256, die kann ich unmittlebar so verwenden. Die Texte selbst, werden dann stumpf von Links nach Rechts ausgelesen und in char umgewandelt.

Dann kommen die Längenangaben, welche aus der Anzahl Bytes bestehen, gefolgt von dem Wert.
Hier war mein Irrweg 04 00 00 F4 01 .. als Block zu erwarten. Korrekt ist aber 04 00 ist die Byte-Angabe und F4 01 00 00 der Wert.
Und das Ganze als Big Endian zu lesen, also von Rechts nach Links.

Das erste Datenpaket ist dann ein Timestamp, welcher ebenfalls in BigEndian definiert ist. Offenbar kommt das alles aus der Applikation selbst.
Alle weiteren Daten sind dann wiederum in LittleEndian abgelegt, da diese auch so eingelesen werden.

Dadurch dass der Anfang der Daten für mich encodiert absolut Sinn gemacht hat, war ich da vernagelt die Werte einfach rückwerts zu berechnen. Die Daten kannte ich und auch da habe ich mich zu sehr drauf versteift...

Vielen Dank! Manchmal braucht man einen kleinen Reset im Kopf 🙂