Moin moin

Ich habe ein WPF-Programm geschrieben, mit dem man die Volumen von diversen Körpern ausrechen kann, die z.B. einen quadratischen oder kreisförmigen Querschnitt haben. Im Programm gibt es diverse Textfelder, in denen man die Maße für die Körper eintragen kann. Durch eine Klick auf den "Berechnen"-Butten wird dann das Volumen berechnet und in einem weiterem Textfeld ausgegeben.

Ich will mein Programm nun dahingehend erweitern, dass die Berechnung zusätzlich auch durch die Betätigung der Enter-Taste durchgeführt werden kann und zwar ohne dass man den Button z.B. durch den Tabulator vorwählen muss.

Schematisch sieht man Programm zur Zeit so aus:



Ich weise nochmal darauf hin, dass das Programm wesentlich umfangreicher ist als wie es die schematische Darstellung zeigt. Aber für mein Problem sollte das Schema ausreichend sein.

Also: Wie muss ich das Ergänzen, damit auch durch Betätigen der Enter-Taste das Volumen berechnet wird (auch wenn der Button nicht vorgewählt wurde mit z.B. dem Tabulator)



PS: Meine Kenntnisse sind nicht besonders umfangreich, deswegen schmeißt mir bitte nicht einfach irgend nen Quellcode vor die Füße, sondern erklärt denn zumindest auch ein wenig

Ohne auf Deine Frage einzugehen: OPTION STRICT ON. Danach können wir über das Problem reden.

Bei WinForms hat die Form eine AcceptButton Eigenschaft, also ein Button, dessen Klickevent geraist wird wenn Enter gedrückt wird.
Ist das nicht übertragbar ?

Ist auf ON. (Hab aber nicht verstanden was mir das nun für Vorteile und Nachteile bringt. ist jetzt aber auch nciht wichtig für mein Problem)

Edit: Das geht ja fix mit euch

ThePlexian schrieb:

Bei WinForms hat die Form eine AcceptButton Eigenschaft, also ein Button, dessen Klickevent geraist wird wenn Enter gedrückt wird.

Weiß gerade nicht so recht, was du meinst. Ist WinForms der Teil meiner WPF-Anwendung in Visual-Studio, in der ich das Design festlege und z.B. Button und Textfelder einfüge? Falls ja, eine Eigenschaft bei den Buttons namens "AcceptButton" kann ich nicht finden.

ElBarto schrieb:

Eigenschaft bei den Buttons namens "AcceptButton"

ThePlexian schrieb:

die Form eine AcceptButton Eigenschaft

Ich kenn mich zwar mit WPF nicht aus, aber:

Ist auf ON.

und

widersprechen sich.

In WPF hat ein Button u.a. die Eigenschaften IsDefault und IsCancel.

Ist IsDefault auf True, dann reagiert der Button auch ohne Fokus auf Enter, ist IsCancel auf True, reagiert er auch ohne Fokus auf die Escape-Taste.

RushDen schrieb:

widersprechen sich.

Ich gehe zugunsten des TE davon aus, dass er Option Strict erst nach SpaceyX' Hinweis eingeschaltet hat, und da war der Code ja schon gepostet.

@ Arby:
Super! Das ist genau das, was ich gesucht hatte. Danke! Funktioniert prima

@ RushDen:
Da wiederspricht sich nichts. Zumindest solange der Benutzer auch wirklich nur Zahlen eingibt. Denn eine Zeichenkette aus Zahlen ist selbst eine Zahl.
Und auch davon abgesehen, dass ich die dritte Varibale vergessen habe hier zu deklarieren, habe ich extra geschrieben, dass es nur eine schmeatische Darstellung ist und meine wirkliches Programm anders aussieht. Dort existieren Kontrollstrukturen, welche eine Berechnung nur zulassen, wenn wirklich nur Zahlen eingegeben wurden.
Die paar Zeilen Code sollten nur dazu dienen, um besser zu verstehen worum es mir geht.

@ ThePlexian:
Ist "Form" ein Sammelbegriff für sowas wie Textfelder, Button, Checkboxen etc? Wenn ja: In WPF gibt es nur einen einzigen Button und keinen AcceptButton

Mir springt da irgendwie ins Auge das mit Textboxen gerechnet wird....
So weit ich weiß rechnet man NICHT mit Strings

Ich würde mir die Rechnung als Integer/Double wie auch immer in einer Variable Speichern und NUR zur Ausgabe
in einer Textbox anzeigen.

Denn eine Zeichenkette aus Zahlen ist selbst eine Zahl

Das schreib ich mir Zuhause aufn Kalender sry aber sag mir bitte das Ergebnis der Rechnung: Sauerkraut + Knödel + Mega Stück Fleisch?

In WPF gibt es nur einen einzigen Button und keinen AcceptButton

ein Button hat Eigenschaften die man einstellen kann, auf das wollte er hinaus.

Nein nein nein

Ich habe keinen Plan von WPF, aber wenn du ein Programm codest, dann hast du i.d.R. eine GUI, eine Oberfläche wie du es nennen willst.
Diese GUI ist natürlich auch ein Object, undzwar eins vom Typ Form. Eine Instanz von Form hat eine Property namens AcceptButton. So


Geht sowas niocht ? :oo

---

Da ist doch die Lösung von @Arby::

In WPF hat ein Button u.a. die Eigenschaften IsDefault und IsCancel.

Ist IsDefault auf True, dann reagiert der Button auch ohne Fokus auf Enter, ist IsCancel auf True, reagiert er auch ohne Fokus auf die Escape-Taste.

ElBarto schrieb:

@ RushDen:
Da wiederspricht sich nichts. Zumindest solange der Benutzer auch wirklich nur Zahlen eingibt. Denn eine Zeichenkette aus Zahlen ist selbst eine Zahl.
Und auch davon abgesehen, dass ich die dritte Varibale vergessen habe hier zu deklarieren, habe ich extra geschrieben, dass es nur eine schmeatische Darstellung ist und meine wirkliches Programm anders aussieht. Dort existieren Kontrollstrukturen, welche eine Berechnung nur zulassen, wenn wirklich nur Zahlen eingegeben wurden.
Die paar Zeilen Code sollten nur dazu dienen, um besser zu verstehen worum es mir geht.

Text erwartet einen String, du übergibst ihr jedoch einen Double.
Deswegen .ToString() nutzen um Double zu string zu konvertieren.
Andersrum genauso, du deklarierst als Double übergibst ihr jedoch den Text und dann rechnest du mit diesen.

textbox.text = String
String <> Double

bei Strict on hätte wenigstens ein CDbl davor stehen müssen

Snaptu schrieb:

sry aber sag mir bitte das Ergebnis der Rechnung: Sauerkraut + Knödel + Mega Stück Fleisch?

Ergebnis dürfte sein: Ein leckeres Mittagessen
Klar kann der Rechner das nicht zusammen rechnen. Es dürfen eben nur Zeichenkette in den Textfeldern stehen, die gleichzeitig auch Gleitkommazahlen sind. 123 wäre z.B. eine solche Zeichenkette (nämlich aus den Zeichen 1, 2 und 3), die gleichzeitig eine Gleitkommazahl ist (nämlich Einhundertdreiundzwanzig). Sonst würde das Programm abschmieren, bei dem Versuch etwas auszurechnen.

RushDen schrieb:

Text erwartet einen String, du übergibst ihr jedoch einen Double.

Text bekommt doch einen String. Wenn ich in das Textfeld 12345 eingebe, steht dadrin ein String mit dem Wert 12345. Und da 12345 eine Gleitkommazahl ist, kann ich diese auch problemlos in einer Variable des Typs Double speichern.

Kann natürlich auch sein, dass wir hier voll aneinander vorbei reden. Schließlich sind meine Kenntnisse in VB mehr als beschränkt.
Mein Programm macht jedenfalls das was es soll, somit scheine ich auch alles richtig gemacht zu haben. Falls Interesse besteht, poste ich hier gerne mal meinen gesammten Quellcode. Dann kannst du/könnt ihr euch selbst davon Überzeugen, dass es funktioniert oder mir erklären, was ich alles falsch gemacht habe

ThePlexian schrieb:

Geht sowas niocht ? :oo

Keine Ahnung ob das funktioniert. Mit Classen habe ich mich noch nicht beschäftigt. Wie gesagt, meine Kenntnisse sind äußerst beschränkt und ich könnte von mir behaupten: Wenn Visual Basic ein eigenes Universum darstellt, dann habe ich gerade erst entdeckt, dass die Erde keine Scheibe ist.

Nochmals Danke an Arby! Hatte in den Eigenschaften auch schon drin rumgesucht, aber wenn man nicht weiß wonach man ausschau halten muss, ist es schwer die Lösung zu erkennen. Hast mir sehr geholfen

ElBarto schrieb:

Text bekommt doch einen String. Wenn ich in das Textfeld 12345 eingebe, steht dadrin ein String mit dem Wert 12345. Und da 12345 eine Gleitkommazahl ist, kann ich diese auch problemlos in einer Variable des Typs Double speichern.

Falsch, im String steht kein Wert 12345, sondern eine Zeichenkette "12345". Und Zeichenketten lassen sich nicht in einer Double-Variablen speichern.

Du solltest wirklich langsam die Unterschiede der einzelnen Variablentypen lernen. Ein Text ist ein String, eine Zeichenfolge, eine Verkettung von irgendwelchen Characteren. Und genauso wird das intern auch gehandhabt, da ist kein "Wert", mit dem eine CPU rechnen kann oder ähnliches. Wenn du nun versuchst so eine Zeichenfolge einer Variablen vom Typ Integer oder Double zuzuweisen, dann ist das streng genommen ein Fehler.

Das Problem ist, dass VB in der Standardeinstellung eben nicht so streng ist und durch "Option Strict Off" einen Mechanismus eingebaut hat, der dafür sorgt, dass in solchen Fällen eine automatische Typumwandlung versucht wird. Das kann mal gutgehen, kann aber auch derb in die Hose gehen und am Ende funktioniert im Programm nichts so wie es soll, weil der Programmierer einfach "übersehen" hat, dass der ach so böse Benutzer in einem Textfeld plötzlich mal keine Zahl, sondern womöglich gar ein chinesisches Schriftzeichen eingeben kann. Und der Benutzer sagt nur "Das Programm stürzt ab", und der Programmierer hat keine Erklärung, denn bei ihm "funktioniert doch alles".

Und genau deshalb predigen hier alle fortgeschrittenen VB-Programmierer, dass man diese Option namens "Strict" grundsätzlich einschalten soll, denn dann ist es absolut unmöglich sowas wie Dim zahl As Double = TextBox1.Text zu schreiben - das Programm ließe sich so erst gar nicht kompilieren. Sieht auf den ersten Blick übel aus, wieso also Option Strict einschalten wenn man solche Fehler damit "ausschalten" kann? Weil du dann anhand dieses Fehlers schnell erkennst: Da ist ein Text und der muss irgendwie in eine Zahl gequetscht werden. Text kann ALLES sein, also muss ich mein Programm so ergänzen, dass all die Fälle, in denen im Text mal keine Zahl steht, auch vernünftig behandelt werden. Sieht nach Mehraufwand aus, ist es aber nicht, weil du damit den anderen Mehraufwand bei der Wartung und Pflege deines Programms bei den Benutzern extrem reduzierst, eben weil dann sowas wie zuvor beschrieben gar nicht erst passieren kann.

Ok,

steht dadrin ein String mit dem Wert 12345

. Soltle eigentlich auch "Zeichenkette" und nicht "Wert" heißen.
Also darf man streng genommen garkeine Textboxen verweden um Werte, die durch einen Benutzer eingegeben werden sollen, einzulesen? Aber wie macht man es dann?

Wie gesagt, ich bin noch ganz am Anfang was Programmieren angeht. Warum ich im Moment überhaupt programmiere liegt daran:

Ich studiere Maschinenbau. Und dieses Semester haben wir unter anderem Hochsprachenprogrammierung mit Visual Basic, einmal als Vorlesung und einmal als so eine Art Pratktikum. Mag sein das dort nicht so sehr ins Detail gegangen wird (eben weil ich Maschinenbau studiere und keine Informatik), aber von Strict ON hat da auch noch keiner was erwähnt.

Im Praktikum hat man es uns so gezeigt, wie man in WPF Werte einlesen kann um mit diesen zu rechnen:

Beispiel: Addition von zwei Zahlen. Zur verfügung stehen im WPF 3 Textfelder (2 für die Eingabe, eins zur Ausgabe) und ein Button


Ist das jetzt grundlegend Falsch? Oder ist das einfach nur ausreichend um erste Grundlagen zu erwerben?
Schließlich stehen hinter dieser Methode ein sehr erfahrener Professor und eine Informatikeren.

Schreibt mir doch bitte den gerade genannten Quellcode so hin, wie es euer Meinung nach richtig sein müsste. Ich druck das dann gerne mal aus und konfrontiere meinen Professor und die Informatikerin damit. Mich interessierts jetzt wirklich, ob wir totalen Quatsch beigebracht bekommen oder ob uns einfach nur weniger beigebracht wird, weil wir keine Infomatiker sind.

Anstelle der Messagebox kannst du natürlich auch eine Textbox oder ein Label verwenden.
Die Einstellungen die ich ins Form_Load gepackt habe würde ich im normalfall im Designer einstellen.
Damit hättest du nur noch das Button.Klick event.

Den Inhalt der NumericUpDown's in eine Variable zu speichern ist nicht notwendig.

ElBarto schrieb:

Im Praktikum hat man es uns so gezeigt, wie man in WPF Werte einlesen kann um mit diesen zu rechnen:

Hmm hmm - ich hab den Eindruck, da hat man euch v.a. gezeigt, wie mans nicht macht.
Wpf ist ganzngar auf Databinding ausgerichtet, so Button-Click-Events nutzen nur Leuts, die das Konzept des MVVM–Patterns nicht verstanden haben.

Nun sollte ich eiglich einen Vorschlag bringen, wie mans richtig lernt, aber ich kann mich nicht entscheiden: Soll man gleich richtig mittm Wpf-Binding-System anfangen? oder erstmal überhaupt, OOP, Klassen und Krimskrams lernen - vlt. gar an Konsole-Anwendungen? Oder lieber erst mit WinForms einsteigen - da sind so Button-Klicksereien ja das übliche.

ElBarto schrieb:

Ist das jetzt grundlegend Falsch?

Grundlegend nicht, aber so sollte man eine Programmiersprache nicht lernen, denn auf die Art und Weise kann man später keine größeren oder gar großen Projekte sicher umsetzen.

Da ist zum einen die Sache, die @ErfinderDesRades schon erwähnt hat: Wenn man schon WPF nutzt, sollte man auch dessen Möglichkeiten nutzen. Ein "Handles Button.Click" ist da absolut fehl am Platz. Wenn der Professor euch sowas beibringt, sollte er sich erstmal selbst mit WPF ausgiebig befassen, bevor er sein "Wissen" auf die Studenten loslässt.

An der Vorgehensweise, Zahleneingaben in Textboxen vornehmen zu lassen, ist zunächst mal nichts verwerfliches. Ein NumericUpDown-Steuerelement kann eine Alternative sein, muss es aber nicht zwangsläufig - das hängt teilweise auch davon ab, was für Zahlen und in welchem Format sie eingegeben werden sollen.

Dann sehe ich, dass sogar sowas wie eine Validierung durchgeführt wird, d.h. die Inhalte der Textboxen werden daraufhin überprüft, ob tatsächlich numerische Werte drinstehen. Das mit dem "." ist allerdings wieder so eine Sache. Was ist, wenn der Benutzer doch mal das in Deutschland übliche Komma als Dezimaltrennzeichen benutzt?

Allerdings ist da ein ganz dicker Brummer drin: Findet er einen ungültigen Zahlenwert, wird "brav" eine Message-Box angezeigt, aber wenn der Benutzer die bestätigt, geht die Funktion trotzdem weiter, weist die Inhalte der TextBox einer numerischen Variablen zu und versucht dann damit zu rechnen. Es gibt also nach wie vor Fehler. Textboxen haben ein Validate-Ereignis, das (auf Wunsch, sprich: wenn entsprechend kofiguriert) immer dann eintritt, wenn sie den Fokus verlieren. Das passiert immer dann, wenn der Cursor in eine andere Textbox, auf ein anderes Control oder einen Button gesetzt wird. Wird der Button geklickt (auch aus dem Programm heraus) verliert die Textbox dadurch ebenfalls automatisch den Fokus und das Validate-Ereignis tritt ein. Dort könnte man dann prüfen, ob der eingegebene Text sicher in eine Zahl umgewandelt werden kann (mit TryCast zum Beispiel) und ggf. die Validierung unterbinden, wodurch auch der Fokus nicht umgesetzt (und folglich auch der Button nicht geklickt) werden kann.

Und sag deinem Professor und allen anderen, die dir irgendwann VB beibringen wollen, dass sie ihre Kurse _immer_ damit beginnen sollten, den Kursteilnehmern zu erklären, was es mit Option Strict auf sich hat und warum (und vor allem wie) man die Standardeinstellung "Off" grundsätzlich auch "On" ändern sollte.

Arby schrieb:

Dann sehe ich, dass sogar sowas wie eine Validierung durchgeführt wird, d.h. die Inhalte der Textboxen werden daraufhin überprüft, ob tatsächlich numerische Werte drinstehen. Das mit dem "." ist allerdings wieder so eine Sache. Was ist, wenn der Benutzer doch mal das in Deutschland übliche Komma als Dezimaltrennzeichen benutzt?

Allerdings ist da ein ganz dicker Brummer drin: Findet er einen ungültigen Zahlenwert, wird "brav" eine Message-Box angezeigt, aber wenn der Benutzer die bestätigt, geht die Funktion trotzdem weiter, weist die Inhalte der TextBox einer numerischen Variablen zu und versucht dann damit zu rechnen. Es gibt also nach wie vor Fehler.

Da muss ich ich dir aber sagen, dass du nun einen Fehler gemacht hast
Das mit dem "." hast du falsch verstanden. In der If-Abfrage wird kontrolliert ob der in die Textbox eingegebene Wert nicht numerisch ist oder ob er einen "." enthält. Der Benutzer soll nämlich mit einen "," arbeiten, da Visual Studio mit einem Punkt falsch rechnet. Beispiel: 5 + 5,5 = 10,5. Mit Punkt rechnet Visual Studio folgendes aus: 5 + 5.5 = 60 (der Punkt wird ignoriert)

Und der dicke Brummer ist auch keiner: Die Berechnung befindet sich im Else-Zweig der If-Abfrage. Somit wird nur gerechnet, wenn die Eingabe den Vorgaben entspricht (also keine Messagebox mit Fehlermeldung erschienen ist).
Der PC arbeitet eine IF-Abfrage ja nur solange ab, bis er die erste Bedingung findet, die erfüllt wird. Alles was danach kommt wird nicht weiter ausgeführt.


Ich vermute mal, dass wir das eben deswegen nicht so genau betrachten, weil wir Maschinenbau studieren und keine Informatik. Wahrscheinlich macht das die Vorlesung schlanker und vom Verständnis her einfacher, mal abgesehen davon, dass Maschinenbau alleine umfangreich genug ist.
Die ganze Vorlesung hat auch hauptsächlich den Sinn, dass man ein Gefühl dafür bekommt, was mit einem Programm alles machbar ist (Stichwort Automatisierung). Als fertig ausgebildeter Ingenieur wird es uns auch eher weniger passieren, dass man mal selbst was programmieren muss. Wir sollen aber erkennen können, wann es sinvoll ist ein Programm mit in die Maschine einzubinden und wir sollen wissen was dieses Programm erreichen soll. zum Schluss gibt man dann diese Anforderungen an einen Informatiker weiter, der das Programmieren übernimmt.
Nichts desto trotz werde ich meinen Professor mal auf Option Strict ON/OFF ansprechen. Mich interessiert das Programmieren doch schon ein bischen und es wäre dann doch äußerst schade, wenn man es mir gelich "falsch" beibringt.

Zur Eingabe von Zahlen empfehle ich dennoch das NummericUpDown Control.
Damit brauchst du keine Prüfung zu machen ob es Numerisch ist, es gibt nämlich nur nummerische Eingaben. Auch die "." abfrage fällt weg.