NumericTextbox - Zahleneingaben einfach gemacht. Update vom 09.07.2014

us4711 schrieb:

ToDo:

Verhalten, wenn über die Datenbinung Daten ausserhalb des Wertebereiches Minimum/Maximum zur Verfügung gestellt werden.

Du kannst doch schon jetzt die Anzahl Digits einstellen?
Und hängt der Maxmalwert nicht von der Anzahl der Digits ab, gerade bei HexDec?
Beispiel:
65535=&HFFFF
Maximalwert muss dann <= 65535 sein

Rrrrrrrrrichtig.
Dennoch kannst Du auch bei HexValueDefinitions eine Maximalwert angeben. Solange der o.a. Automatismus noch fehlt, ist das die Eselsbrücke ...

Die neue Version ist nunmehr fertiggestellt.
Änderungen/-Ergänzungen und Download in Post#1

Bei der Überarbeitung sind ein paar interessante Dinge aufgefallen:

• Das dynamische Ausblenden von Properties über das Browsable-Attribut funktioniert - allerdings bei sämtlichen Instanzen des Controls gleichzeitig.
  Wenn man sich den Code anschaut, ist dies logisch. Man greift nämlich auf das <Browsable>-Attribut der Klasse zu, und nicht auf das der Instanz. Zur Zeit kenne ich keine Möglichkeit, dies nur für die Instanz zu erreichen - Hinweise sind sehr willkommen.
  Die jetzt verwendete Technik zur Anzeige der Settings des ausgewählten NumberFormates ist aber auch ganz tricky:
  Definiere eine Property NumberFormat Settings mit dem Typ Object, und weise ihr in der Property NumberFormat dasgewünschte Zahlenformat (jeweils eine eigene Klasse unbterschiedlichen Typs) zu.
  Und siehe da: Im Designer kann das Zahlenformat editiert werden.
  
• SmartTags sind ganz hilfreich, deshalb habe ich sie hier auch eingeführt. Damit können die Properties gesetzt werden, die für die NumericTextBox spezifisch sind. Dabei hatte ich etliche Probleme mit der Persistierung der so gesetzen Werte. Der Weg über TypeDescriptor.GetProperties(m_NumericTextBox)("PropertyName").SetValue(m_NumericTextBox, value) führte dann schliesslich zum Erfolg.
  
• Ich habe auch festgestellt, das verschiedene, von Textbox geerbte Properties das Verhalten der NumericTextBox unvorhersehbar machen können.
  Mit ControlDesigner.Protected Overrides Sub PostFilterProperties werden daher diese potentiell "gefährlichen" Eigenschaften sit der geerbten Instanz entfernt (und nicht nur ausgeblendet).
  
• Des Debuggen in der Control-Entwicklung its nicht ganz so trivial, wie beim normalen Code, da Brekpoints nicht gesetzt werden können. Die Lösung:
  In einer separaten Form zieht man ein Control auf die Form, sowie ein PropertyGrid. Dessen Eigenschaft SelectedObject bindet man an die Instanz des Controls. Man startet die Form, und kann nun Properties nach Beleiben verändern, und die Auswirkungen mit Breakpoints nachverfolgen. Das funktioniert auch schon bei der Initialisierung der Komponente.
  

Ein wichtiges Merkmal der NumericTextBox ist die Vorgabe eines Minimal- und Maximalwertes für die Eingabe. @sonne75 hat mit Recht gefragt: Ja, was ist denn mit Werten von bestehenden Datenquellen, an die das Control gebunden ist. Da kann man ja mit vertretbarem Aufwand keine Voraussage über die anstehenden Werte machen.
Da was zu frickeln, macht nach meiner Meinung keinen Sinn. Per Default sind die Min-/Maxwerte des jeweiligen Zahlenformats auf Decimal.MinValue und Decimal.MaxValue gesetzt, beim Zahlenformat HexaDecimal auf Int64.MinValue und Int64.MaxValue. Grössere/kleinere Werte sind wegen des Werteberechs der Datentypen aus dem Framewerk schlicht nicht möglich. Bei unbekannten Dateninhalten sollten diese Default-Werte einfach unverändert bleiben, bzw. auf die Min/Maxwerte des in der Spaltendefinition der Datatable verwendeten DataTyps. Vorsicht beim Wert Double: Der überschreitet im Wertebereich des in NumericTextBox verwendeten Basis-Datentyp Decimal bzw. Int64 für HexaDecimal.

Bei neu zu erstellenden Datenquellen muss man sich ja ohnehin Gedanken über Wertebereiche machen, sodaßß diese Probleme nicht auftreten sollten (Wenn im Currency-Zahlenformatwirklich Werte von Decimal.MaxValue benötigt werden ... bitte Information an mich, in DAS Projekt möchte ich UNBEDINGT einsteigen ;-))

Du hast Option Strict Off geproggt, hat das einen Grund?

Dies hat mich stark verstört, da ich mich eigentlich für den stärksten Verfechter von Strict On halte.

Hab dann grad auch in diesem Projekt nachgegeschaut unter Projekt->kompilieren. Da stand die Einstellung "Option Strict" auf BENUTZERDEFINIERT - was auch immer das bedeutet. Ich war eigentlich der Meinung, das ich nach der Installation von VS unter Extras=>Optionen=>Projekte und Projektmappen=>VB Standard=>Standard-Projekteinstellungen Option Strict auf On gestellt hatte. Überprüfung ergab, das dies auch so ist.
Nun ja, muss ich wohl jedes neue Projekt händisch prüfen ... Gruß an MS.

Hab's also auch hier auf ON umgestellt, zusätzlich als Option im Programmcode eingeführt, und den Download in Post 1 angepasst.

@sonne75
Erklärt aber immer noch nicht, warum die Vorgaben aus den Optionen nicht ins neu erstellte Projekt übernommen werden? Bin da ratlos.

@ErfinderDesRades, @sonne75
Nein, Option Strict On meint Option Strict On und nix anderes. Der Rest ist anders benamst, guckst Du MyProject=>Kompilieren

Nix verändert. Aber lass mal, ich muss mir angewöhnen, den grundsätzlichen Settings von VS nicht zu vertrauen. Ich werde mir Die Einstellungen immer "von Hand" anschauen.
Danke für Eure Bemühungen.

Ist schlicht und eregreifend 'ne Windows-Forms-Textbox, die um Funktionalität erweitert wurde.
Ist zum Einen im täglichen Gebrauch ganz nützlich, aber aus Sicht des programmierenden Menschen (m/w) ist zum Anderen vielleicht auch das eine oder andere Code-Goodie dabei.