Als Ausgangspunkt hat Telerik eine https://www.telerik.com/universal-windows-platform-ui/numericbox. Es ist auch in Open Source verfügbar: https://github.com/telerik/UI-For-UWP/blob/master/Controls/Input/Input.UWP/NumericBox/RadNumericBox.cs.

Was mir an ihnen gefällt, ist ihr Ansatz für die Formatierung mit der Eigenschaft ValueFormat.

Beispiel: ValueFormat="{}{0,0:C2}"

Bitte stellen Sie auch sicher, dass dies korrekt lokalisiert ist. Die Implementierung des Windows Community Toolkit weist einige Mängel auf:

Die TextBoxRegex-Erweiterung mit ValidationType="Decimal" unterstützt nicht alle Benutzeroberflächenkulturen. Stattdessen ist es auf InvariantCulture festgelegt. Im Englischen sind Dezimalwerte "10.1234" mit einem Punkt. Im Spanischen oder Deutschen werden Dezimalwerte "10.1234" geschrieben. Das Parsen des Englischen wird korrekt sein; spanische oder deutsche Benutzereingaben werden jedoch nur "101234" sein, wobei der Bruchteil verloren geht.

Siehe: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2700

Die Pfeile nach oben und unten sollten den Wert um einen Wert erhöhen oder verringern, den der Entwickler festlegen kann, aber der Standardwert sollte ein Int von 1 . sein

• Umlaufende Min/Max-Werte sind gut, z. B. wenn ein Winkel ausgewählt wird
• Möglichkeit, ein Suffix hinzuzufügen
• Klicken Sie auf das Textfeld und ziehen Sie nach oben/unten, um die Werte zu ändern, Adobe XD hat dies in den Zahleneingaben.

Meine Implementierung in WinRT XAML Toolkit unterstützt auch das Ziehen nach oben/unten, um Werte zu ändern, und macht sie in bestimmten Szenarien bei der Verwendung mit der Maus viel benutzerfreundlicher als das Klicken auf Schaltflächen.
https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

Hallo, @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar und @xyzzer! Ich wurde diesem Vorschlag zugeteilt.

Zunächst vielen Dank, @sonnemaf , für die Übermittlung. Ich habe es letzte Woche auf der Microsoft Build 2019 gezeigt und es wurde vom Publikum bejubelt! Die Community-Antwort hier in den Kommentaren spiegelt auch die Aufregung wider, die wir haben, NumberBox zu sehen.

Ich habe alle Kommentare gelesen und den Bereichsabschnitt aktualisiert, um die eingegangenen Beiträge widerzuspiegeln. Ich würde es begrüßen, wenn jeder die Gelegenheit nutzen könnte,

Hallo @SavoySchuler ,

Diese Woche arbeite ich an der Barrierefreiheitsfunktion meiner App. Dies wäre ein Pluspunkt, wenn die Barrierefreiheit mit dem neuen Steuerelement richtig gehandhabt würde, zum Beispiel kann die Schrittweite laut anstelle von "Plus", "Minus" ausgesprochen werden. Der Rest scheint mir in Ordnung.

Es ist wichtig sicherzustellen, dass der Erzähler die Werte richtig vorlesen kann, damit klar ist, was passiert.

Ich bin mir nicht sicher, ob der Xbox-Controller ein Tippen auf den Fokus benötigt, um sicherzustellen, dass die Analogsticks und das D-Pad richtig funktionieren

Kleine Korrektur - Ziehen zum Vergrößern/Verkleinern sollte auf dem Textfeld selbst funktionieren, bis es aktiviert wird. IIRC in meiner Implementierung musste ich eine transparente Überlagerung über dem Textfeld platzieren, um es zu aktivieren, und auch den Mauszeiger beim Ziehen ausblenden, damit die Ränder des Steuerelements oder Bildschirms den Ziehabstand nicht begrenzen und wenn Sie mit dem Ziehen fertig sind und ich zeige den Cursor wieder - er taucht dort auf, wo er zuerst verschwunden ist.

@SavoySchuler du hast eine schöne Aufgabe. Ich kann mit deiner Reichweite leben. Rechner ist nett zu haben (WinUI 3.0 oder 3.1). Ich habe in vielen Desktopumgebungen (VB6, WinForms, WPF und UWP) entwickelt und immer eine NumberBox vermisst. Endlich werden wir es bekommen.

Vielleicht können Sie auch das Mausrad für Up/Down hinzufügen. Blend für Visual Studio unterstützt dies.

Ich liebe auch Drag-to-Change, etwas, das ich in Expression Blend häufig verwendet habe.

Ich bin mir nicht sicher, was die Eingabevalidierung tun wird und was nicht. Wird es nur Min/Max oder auch Limit-Tastatur sein (Buchstaben az, etc)? Wird es mit dem Einfügen ungültiger Zahlen umgehen?

Ich würde gerne die vollständigen Spezifikationen lesen.

@ArchieCoder , ich höre dich laut und deutlich. Zugänglichkeit ist eine Priorität und wird am besten im Voraus behandelt. Ich habe einen Abschnitt zu Barrierefreiheit und Eingaben zu diesem Vorschlag erstellt, in dem ich Ihre Anmerkung hinzugefügt habe.

@mdtauk , tolle Frage wie immer. Ich habe dies dem Abschnitt "Zugänglichkeit und Eingaben" hinzugefügt, um es zu untersuchen.

@xyzzer , du hast recht. Beim Reorganisieren der Bereichsliste habe ich die Schaltflächen nach oben/unten gruppiert und als verwandte Funktionen per Drag-to-Change verschoben. Beim erneuten Lesen schien es, als würde ich vorschlagen, dass Drag-to-Change eine Funktion der Schaltflächen ist. Ich habe Drag-to-Change in einen eigenen Abschnitt verschoben, um Klarheit zu schaffen.

@sonnemaf ,

Alle , Mit einem Hinweis zur Taschenrechnerunterstützung - ich glaube an den Wert. Ich arbeite mit meinem Team zusammen, um herauszufinden, ob wir dies modularisieren sollten, falls die Funktionalität in der Plattform weiter genutzt werden könnte. Außerdem stellt sich die Frage, wie weit wir mit der Rechnerunterstützung gehen. Würde eine einfache Reihenfolge der Operationen auf +-/* ausreichen? Oder etwas umfassenderes, wie die Verbindung zu einer Art Wolfram-Alpha-Dienst? Die Erforschung einer modularen Route könnte es uns vielleicht ermöglichen, mit dem einfacheren Fall zu beginnen, ohne die Möglichkeit für eine umfassendere Form der Taschenrechnerunterstützung zu blockieren. Mich würde interessieren, was hier jeder braucht.

Zur Eingabevalidierung habe ich die gleiche Frage. Deckt es min, max, keine Buchstaben und kein ungültiges Einfügen ab?

Ich finde die Taschenrechnerfunktion süß, aber wie wird diese Funktion praktisch von einem Benutzer entdeckt? Wird es dazu einen kleinen Widget-Hinweis geben?

@ArchieCoder , glauben Sie, dass verblasster benutzerdefinierter Platzhaltertext in der NumberBox einen Benutzer angemessen auffordern könnte? Wenn ja, stelle ich mir vor, dass eine Zeichenfolge wie "a + b - c" oder "Gleichung eingeben" prägnante Möglichkeiten sein könnte, diese Informationen zu liefern. Excel hat auch einen Standard erstellt, bei dem "=" am Anfang einer Gleichung steht. Vielleicht erscheint, sobald der Benutzer auf die NumberBox klickt, ein unveränderliches "=" vorne, das der Benutzer dann dahinter eintippt?

Wir haben ToolTip oder den schwereren TeachingTip als Orientierungshilfe auf App-Ebene, auf die wir Entwickler bitten könnten, sich auf sie zu verlassen, aber ich bevorzuge es, dies in NumberBox selbst zu lösen.

Ich bin daran interessiert, Ihre Meinung hier zu hören!

Platzhalter wären in der Tat eine gute Möglichkeit, solange kein anderer Kontext aufgrund der Platzbeschränkung erforderlich ist. Ich würde denken, dass eine NumberBox-Breite beispielsweise kleiner ist als eine Textbox.

Sofern das Steuerelement NULL-Werte nicht unterstützt, wird immer ein Wert angezeigt,
Es wird also kein Platz für eine Platzhalterzeichenfolge darin sein.

Am Freitag, 17. Mai 2019 um 10:14 Uhr ArchieCoder [email protected]
schrieb:

Platzhalter wäre in der Tat eine gute Möglichkeit, solange der andere Kontext dies nicht ist
aus Platzgründen erforderlich. Ich würde denken, eine NumberBox-Breite wird
kleiner sein als beispielsweise ein Textfeld.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AANMBMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA
.

@ArchieCoder , @sonnemaf ansieht (danke noch einmal dafür), wäre jede NumberBox, die nicht breit genug ist, um Platzhaltertext für "a + b - c" anzuzeigen, auch nicht breit genug, um eine empfohlene Benutzererfahrung für zu erstellen Gleichungen eingeben. Insofern könnte ich mir vorstellen, dass diese Lösungsoption für diesen Zweck noch gangbar ist. Ich denke jedoch, Sie erschließen einen Bereich, den wir noch nicht angesprochen haben - Szenarien, in denen wir eine kompakte NumberBox/nur eine einfache Zahl eingeben möchten. Ich kann mir vorstellen, dass die Calculator-Unterstützung eine API zum Deaktivieren benötigen würde. In diesem Fall müssen wir uns weder mit langem Platzhaltertext noch mit dem Umgehen von Mindestabstandsbeschränkungen befassen, die die Gleichungsform von NumberBox sonst benötigen würde - obwohl einige Platzhaltertextoptionen für den Kompaktmodus immer noch nett sein können , auch wenn es nur für so etwas wie "#" oder "zB 2" steht.

@xyzzer , danke fürs

Ich habe eine Frage mit höherer Priorität für alle:

Hätten Sie lieber ein NumberBox-Steuerelement, das diese Funktionen unabhängig von einer Standard-TextBox konsolidiert, oder möchten Sie diese Funktionen lieber als native Funktionen in TextBox integrieren, die über APIs oder InputScope aktiviert werden könnten?

( @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar und @xyzzer)

Es ist eine bedeutende Änderung, all dies in ein TextBox-Steuerelement zu integrieren.

Die Validierung für eingegebene Zeichen.

Verwenden des richtigen Tastaturlayouts mit dem InputScope

Das unterschiedliche Mausverhalten.

Die Möglichkeit, Spinner-Schaltflächen wie in der FabricWeb-Version anzuzeigen.

Wenn all diese Dinge hinzugefügt werden könnten, mit einer Verhaltensaufzählung, um den TextBox-Typ zu definieren, ohne Auswirkungen auf alle anderen zu haben, die derzeit eine TextBox in ihrer App verwenden, dann gut.

Und Sie könnten sogar in Erwägung ziehen, andere TextBox-Verhalten wie ein Symbol zu kombinieren, das eine Suche darstellen könnte, oder einen Kalender, der wie eine Schaltfläche funktioniert. Masken für Dinge wie IP-Adressen oder URLs, die "http://" im Stil von Platzhaltertext anzeigen, wenn Sie Text daneben eingeben.

FabricWeb bietet mit seinen TextFields eine große Vielfalt.

https://developer.microsoft.com/en-us/fabric#/controls/web/textfield

https://developer.microsoft.com/en-us/fabric#/controls/web/spinbutton

Ich würde definitiv ein eigenes NumberBox-Steuerelement verwenden, anstatt all diese Funktionen in ein TextBox-Steuerelement zu backen (ähnlich wie es auch ein PasswordBox-Steuerelement und keine TextBox mit einem Eingabemodus "Passwort" gibt).

Das NumberBox-Steuerelement wird viel mehr sein als ein einfaches Eingabefeld beispielsweise für IP-Adressen. Es wird mit seinen eigenen Zugänglichkeits-/einzigartigen Scroll- und Drag-Funktionen, Taschenrechner-Unterstützung, ... kommen, was es ziemlich von der Art unterscheidet, wie ich bisher eine TextBox normalerweise verwendet habe (so einfache Fälle wie die Angabe eines Repräsentationsnamens für eine Gruppe von Dateien). Und da noch mehr spezielle Funktionen/Anforderungen für das NumberBox-Steuerelement vorgeschlagen werden, können wir eine schöne und saubere Trennung zwischen NumberBox und TextBox beibehalten.

Diese Spearation würde auch in der Dokumentation und im xaml-Layout der App auftauchen (NumberBox ist leichter zu erkennen als beispielsweise eine TextBox mit einer Reihe von Eigenschaften, von denen eine den Eingabemodus angibt). Anstatt die TextBox-Dokumentation über die numerischen Eingabemöglichkeiten zu lesen, wäre dieser Teil in einer spezifischen NumberBox-Steuerelementdokumentation nett und ordentlich (genau wie bei PasswordBox heute).

In Bezug auf das Erscheinungsbild des Steuerelements denke ich, dass die Einheit/das Suffix mit einer kleineren Größe/entsättigten Farbe beiseite angezeigt werden könnte, damit es sich vom Wert selbst unterscheidet:

Wenn die Maus über dem Steuerelement schwebt, können anstelle der Einheit Pfeile nach oben/unten eingeblendet werden:

Eine Alternative sind die Zahlensteuerelemente von figma.com, wenn Sie mit der Maus über die Einheit fahren, können Sie klicken + nach links / rechts ziehen, um den Wert zu ändern.

Links/Rechts ist interessant, weil es einfacher ist, die Maus nach links/rechts zu bewegen als nach oben/unten (Sie müssen Ihr Handgelenk nicht anheben).

Andere Dinge:

• Wenn Sie auf den nicht fokussierten Textbereich klicken, sollte der gesamte Inhalt ausgewählt werden. so dass Klick+Wert eingeben+Eingabe den Wert ändert
• Shift+Klick auf einen Pfeil oder Shift+Up/Down beim Fokussieren um 10 erhöhen oder verringern (dieser Wert sollte meiner Meinung nach auch anpassbar sein).
• Ich denke nicht, dass der Aufwärts-/Abwärtspfeil für den Benutzer sehr nützlich ist. Wenn der Benutzer einen genauen Wert möchte, gibt er ihn einfach ein. Wenn er sich nicht sicher ist, welchen Wert er möchte, kann er durch Klicken und Ziehen ein Spektrum von Wertänderungen visualisieren. Die Auf-/Ab-Pfeile sollten also wahrscheinlich zumindest optional sein.

@adrientetar Wenn Sie die Einheit im Steuerelement

• Lokalisierung
• Barrierefreiheit
• auswählen
• Einfügen
• Konvertierungen

All dies würde vermieden werden, indem dies in den Header, die Beschreibung oder einen separaten TextBlock eingefügt wird.

Ich würde mich für ein separates NumberBox-Steuerelement mit einer Value-Eigenschaft und möglicherweise nicht für eine Text-Eigenschaft entscheiden. Der Wert sollte ein Double sein, damit wir ihn mit Daten binden (x:Bind) können. Ich bin mir nicht sicher, ob wir auch den Decimal-Datentyp unterstützen sollten und wie.

Die Unterstützung für Nullable-Zahlen ist ein MUSS, denke ich (danke @xyzzer). Die Value-Eigenschaft sollte ein Nullable seinDatentyp. Ich bin mir nicht sicher, ob dies Bindungsprobleme verursacht, wenn es an einen nicht nullbaren Wert gebunden wird.

Während die Komposition Vorteile hat und ein angehängtes Verhalten für nummerierte
mode könnte implementiert und an eine TextBox angehängt werden - ich denke, es würde machen
es unnötig kompliziert und begrenzt.
Einige der größten Probleme, auf die Sie wahrscheinlich bei der Implementierung stoßen würden, beziehen sich auf
Barrierefreiheit. Ich glaube, einige der Zugänglichkeitsmuster zu unterstützen -
Sie müssten bei der Implementierung bestimmter Schnittstellen in TextBox backen
das würde es verwirrend machen, wenn sich eine TextBox nicht in einem Zahlenfeldmodus befindet.

Am Mo, 20. Mai 2019 um 02:33 Fons Sonnemans [email protected]
schrieb:

Die Unterstützung von Nullable-Zahlen ist ein MUSS, denke ich (danke @xyzzer
https://github.com/xyzzer ). Die Value-Eigenschaft sollte ein Nullable sein
Datentyp. Ich bin mir nicht sicher, ob dies beim Binden zu Bindungsproblemen führt
ein nicht nullwertbarer Wert.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMBGVIQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBJKTORDN5
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AANMBMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA
.

Ich habe noch eine Frage an alle. Benötigen/bevorzugen Sie eine Eingabevalidierung oder -maskierung?

( @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar , @xyzzer und @Felix-Dev )

Die Validierung ist unerlässlich, da Sie einer Zeichenfolge keine Zahl hinzufügen können. Und mathematische Operatoren müssen bewertet und verarbeitet werden.

Braucht es eine Fehlermeldung, die angezeigt wird, wenn es nicht berechnen kann, bei der ich mir nicht sicher bin.

Maskierung wäre nützlich, sollte aber wahrscheinlich in die Textbox selbst integriert werden, damit URL- und E-Mail-Eingaben verarbeitet werden können. NumberBox wäre Telefonnummern, IPs usw.

Ich denke nicht, dass eine NumberBox für Telefonnummern oder IPs verwendet werden sollte. Diese scheinen eher wie einfache Maskierungs-/Filtererweiterungen für eine TextBox zu sein. Eine NumberBox ist etwas, das Sie zum Eingeben eines einzelnen Werts verwenden möchten.
Vielleicht besteht die Möglichkeit, eine Währungsbox-Kontrolle zu haben, aber ich denke auch, dass es sich um eine separate Kontrolle handeln sollte, die sich von TB oder NB unterscheidet.

@xyzzer Die NumberBox für jede Art von numerischer Eingabe flexibler zu machen, scheint mir eine gute Idee zu sein. Es kann von einem TextBox-Steuerelement abgeleitet werden, und dieses Steuerelement könnte eine Mask-Eigenschaft sowie andere Verhaltenseigenschaften aufweisen.

Einige dieser Eigenschaften auf der NumberBox könnten sein:

• Spinner-Schaltflächen ein-/ausblenden
• Inkrementieren und Dekrementieren von Werten zulassen
• Berechnung von Werten zulassen
• Maskierte Eingabe zulassen
• Lokalisierte Masken wie Telefonnummern oder IP-Adressen

Eigenschaften, die der TextBox hinzugefügt werden könnten, könnten sein:

• Eine Mask-Eigenschaft – Eine XAML-Zeichenfolge zum Definieren eines benutzerdefinierten Formats ([email protected]) sowie lokalisierter Masken wie Postleitzahlen/Postleitzahlen
• Präfix/Suffix Textanzeige (z. B. _http://_ als Präfix)
• Aktionsschaltfläche anzeigen/ausblenden - mit einem Symbol und Klick auf die Ereigniseigenschaft
• Symbol (das Suchfeld der Fabric-Benutzeroberfläche zeigt sein Symbol auf der linken Seite an und wird animiert, wenn das Feld fokussiert wird)

Diese Bilder sind vom Fabric UI TextField – und es unterstützt all diese verschiedenen Zustände – wir sollten versuchen, Fluent WinUI 3.0-Steuerelemente nach Möglichkeit auf Parität zu bringen

Die Schaltflächen des Fabric UI Spinner sind zu klein für die Berührung, daher würde ich sie anders formatieren, sodass die Auf- und Ab-Tasten nebeneinander liegen und nicht übereinander gestapelt sind

Validieren ist für mich ein MUSS und Maskieren ein NICE TO HAVE. Ich mochte das Maskieren nie; es ist zu starr.

@rudyhuyn hat im Windows-Rechner- Repository eine nette Funktion vorgeschlagen. @mdtauk hat es kommentiert .

Sie können ein Taschenrechner-Popup aus der NumberBox öffnen, ähnlich einer Datums-/Uhrzeit-/Kalenderauswahl.

Ähnlich wie das, was @xyzzer oben gesagt hat. Es gibt einen grundlegenden Unterschied zwischen einer Zahl und einer Zeichenfolge, die eine Ziffernfolge enthält.
Der beste Weg, wie ich den beschriebenen Unterschied gehört habe, ist, dass Sie Multiplikations- und Divisionsoperationen an einer Zahl durchführen können. Sie können nach der Hälfte einer Zahl fragen und durch zwei teilen. Sie können nicht nach einer halben Postleitzahl oder einer "Telefonnummer" fragen und etwas Sinnvolles bekommen.

Das Mischen eines bestimmten NumberBox , das über mathematische Fähigkeiten verfügt, mit Funktionen zum Erfassen anderer Werte, die aus Ziffern bestehen, kann auch zu anderen Problemen führen.
"Telefonnummern" können mit führenden Nullen (oder einem Pluszeichen) beginnen und haben dort eine Bedeutung. Für eine _number_ tun sie es nicht und würden ausgezogen.
"Telefonnummern" werden oft auch mit Klammern und Bindestrichen formatiert. Wenn sie als mathematische Operationen verarbeitet werden, könnten diese leicht als Multiplikations- und Subtraktionsbedarf interpretiert werden.

Das Zulassen der Maskierung auf die gleiche Weise wie bei einem TextBox und als Möglichkeit zur Formatierung von Eingaben riskiert, den Unterschied zwischen einem NumberBox und einem TextBox verwirren und wann jeder verwendet werden sollte.

Einfache Validierung ist ein Muss , aber es muss darauf geachtet werden, dass die Validierung bei der Plattform nicht zu widersprüchlichen Validierungsmethoden führt oder Entwickler leicht dazu bringen könnte, ihre Validierung auf mehrere Standorte zu verteilen .

Ich würde die Validierung beibehalten, um nur auf diesen Eigenschaften zu basieren:

• Höchster Wert
• Mindestwert
• AllowDecimalPlaces

Getrennt davon muss angegeben werden,

• ungültige Ausgabe von Berechnungen
• wie mit einem eingegebenen/eingefügten/berechneten Wert umgegangen wird und was in einer Bindung verwendet wird. Es ist erforderlich, die Berechnung oder den ungültigen Wert anzuzeigen, um anzuzeigen, dass er ungültig ist, aber dies kann nicht an eine unterstützende Eigenschaft übergeben werden.

Masken benötigen ein visuelles Angebot, um zu verdeutlichen, was erforderlich ist, während grundlegende Berechnungseingaben nicht zusammen mit maskierten Eingaben verwendet werden.

Die Fabric Web-Textsteuerelemente scheinen dies gut zu handhaben - aber der Umfang für die NumberBox ist natürlich getrennt von allgemeinen Anpassungs- und Finish-Verbesserungen des standardmäßigen TextBox-Steuerelements.

Die Spinner-Schaltflächen (und vielleicht das optionale Calculator-Flyout) sind die einzigen visuellen Dinge, die für eine NumberBox spezifisch zu sein scheinen.

Was die Eigenschaften betrifft, so könnte vielleicht, wenn die Tasten zum Ändern des Werts der Tastatur nach oben und unten aktiviert sind, ein Schrittwert eingefügt werden, damit Sie auswählen können, wie viel beim Drücken der Taste erhöht oder verringert werden soll.

@mdtauk , ich mag den Step- Wert, aber nicht nur beim Tastendruck. Auch auf Scroll- und Up/Down-Taste.

@sonnemaf Sicher, der Schritt ist gut für etwas Binäres wie ein Mausrad-Tick, Tastendruck oder Tastendruck. Vielleicht könnte die Entfernung, die von der Box weggezogen wird, den Schrittbetrag erhöhen?

Also StepMinimum und StepMaximum vielleicht?

Also StepMinimum und StepMaximum vielleicht?

Ich habe keine Ahnung, worauf sich diese Werte beziehen könnten oder was ich von ihnen erwarten kann.
Wenn der Zweck von "Schritt" darin besteht, Inkremente zu definieren, dann nennen Sie es "Inkrement".

Dies würde es Max:100 Min:0 Increment:10 erlauben, nur die Werte 0, 10, 20, 30, 40, 50, 60, 70, 80, 90 und 100 anzugeben.

Wenn der Schritt-/Inkrementbetrag basierend auf der gezogenen Distanz variiert, kann dies zu unvorhersehbaren Wertänderungen führen. Wenn der Zweck dieses Steuerelements darin besteht, die Angabe numerischer Werte zu erleichtern, würde ich dies wahrscheinlich sehr frustrierend finden, wenn sich der Wert in unterschiedlichen Mengen ändert, was das zugrunde liegende Ziel eines dedizierten Steuerelements zunichte machen würde, um es einfach zu machen.

@mrlacey Ich verwende Step, da dies die Eigenschaft ist, die für den Schieberegler und die Fortschrittsbalken benannt ist, aber Inkrement kann verwendet werden, wenn dies bevorzugt wird. Der Wert geht auf und ab, solange die Erhöhung nicht nur mit einer Erhöhung des Wertes verwechselt wird.

Es gibt einen Vorschlag zum Klicken und Ziehen nach oben oder unten, um den Wert zu erhöhen oder zu verringern. Wenn der Benutzer erwartet, dass sich der Wert schneller ändert, je weiter Sie nach oben oder unten ziehen, können die Entwickler mit einem Stap Min- und Max-Wert dies steuern, wenn sich das Delta ändert. Ein kleiner Schleppabstand könnte also um 0,1 oder 1 gestuft werden - aber ein weiteres Ziehen könnte sich zum Beispiel in Schritten von 5 oder 10 ändern.

Ich sage nicht, dass der Widerstandsabstand die Geschwindigkeit der Wertänderung ändern muss - nur dass es eine Idee ist, die hilfreich sein kann, wenn sie sich natürlich anfühlt und dem Benutzer ein Gefühl von Selbstvertrauen und Kontrolle gibt.

Super Feedback, alle zusammen! Ich habe eine Spezifikation & PR geöffnet, um die Details auszuarbeiten.

@KevinTXY wird sich mir als Entwickler für dieses Steuerelement anschließen. Wir halten das Gespräch über die Anforderungen hier am Laufen und starten das API-/Beispiel-spezifische Gespräch im PR.

Bitte fühlen Sie sich ermutigt, mich beim Schreiben der Spezifikation zu unterstützen.

Die Spezifikation von TeachingTip ist ein voll funktionsfähiges Beispiel dafür, wie eine fertige Spezifikation aussehen wird. Die Hauptgliederung wird sein:

• Beschreibung
• Beispiele für jede API/Funktion
• Richtlinien
• API (IDL)

Tolle Ideen, ich mag, wohin das alles führt. Addiere meine zwei Cent:

• Ohne Frage denke ich, dass dies eine separate NumberBox sein sollte, anstatt in TextBox integriert zu sein. Darüber hinaus werden hier viele gute Funktionen besprochen, aber wir sollten die NumberBox auch leichtgewichtig halten. Daher schlage ich vor, von NumberBox eine CalculatorBox oder etwas Ähnliches abzuleiten, die die erweiterten "2+3"-Eingaben oder eine Schaltfläche zum Öffnen eines Taschenrechners haben kann.
• Die Lokalisierung muss in der Spezifikation im Voraus gut durchdacht sein. Darüber hinaus gibt es Fälle, in denen Sie die lokale Benutzeroberfläche überschreiben möchten. Daher kann das Festlegen einer NumberformatInfo-Eigenschaft oder CultureInfo sehr nützlich sein. Beispielsweise werden in einigen Anwendungen sowohl ein fremder als auch ein lokaler Wert verfolgt. Jeder könnte möglicherweise ein anderes Format haben.
• Das Steuerelement muss das Verschieben einer Dezimalstelle unterstützen. Dies ist kniffliger, als einfach ein Format für jeden geänderten Text zu validieren. Jede Zeicheneingabe muss nachverfolgt und die vorherige Dezimalstelle nach Bedarf ersetzt werden.
• Alle Inkrement-/Dekrement-Pfeile sollten so konfiguriert werden können, dass sie nur ein einfaches Eingabefeld haben. Auch hier benötigen wir ein leichtgewichtiges Steuerelement für die Fälle, in denen es als Teil anderer Steuerelemente benötigt wird.
• Etwas anderes, das noch nicht diskutiert wurde, ist, dass wir idealerweise mehrere Typen unterstützen müssen – Dezimal, Integer und möglicherweise Long, Double usw. Dies könnte viele Dinge grundlegend ändern und ich habe es selbst noch nicht vollständig durchdacht .
• Der Wert muss auf jeden Fall nullable sein. Ein nicht gesetzter Wert ist ungleich Null.
• Eine weitere unkritische Idee ist die Angabe der Dezimalgenauigkeit für Dezimal-, Doppel- oder Gleitkommatypen.

Ich bin mir sicher, dass weitere Ideen folgen werden. Ich freue mich darauf, die Spezifikation zu lesen!

( @mdtauk , @xyzzer , @mrlacey , @sonnemaf , @robloo , @Felix-Dev, @adrientetar , @ArchieCoder )

Ich habe die Spezifikation / PR mit APIs und Beispielen für jeden ausgefüllt. Ich glaube, ich habe die Formatierung an Ihre Spezifikationen angepasst, mit einer Aufzählung für grundlegende vordefinierte Typen (noch in Bearbeitung) sowie einer benutzerdefinierten Formatierungseigenschaft, die vordefinierte Typen überschreibt, wenn sie festgelegt ist.

Bitte überprüfen Sie es und lassen Sie es mich wissen, wenn es Ihre Bedenken nicht löst oder ob es ergänzt oder verbessert werden kann. Ich akzeptiere Pull-Requests, die zu den hier geforderten Spezifikationen beitragen.

• Die Validierung wird als ein Muss vermerkt. Ich habe dieses Steuerelement vorgeschrieben, um von TextBox abzuleiten, um Maskierung und andere unterstützende Eigenschaften kostenlos zu erhalten.

• Zum Anliegen von @mrlacey habe ich eine API zum Aktivieren/Deaktivieren des Entfernens führender Nullen hinzugefügt, die in Verbindung mit der benutzerdefinierten Formatzeichenfolge verwendet werden kann, um Szenarien für die Eingabe von benutzerdefinierten numerischen Zeichenfolgen zu ermöglichen (beachten Sie, dass internationale Telefonnummern und IP-Adressen bereits vorhanden sind auf der Liste der möglichen Grundformattypen).

• Dies gepaart mit der Möglichkeit, die Taschenrechnerunterstützung zu aktivieren/deaktivieren, ist für mich der Schnittpunkt für ein Steuerelement, das sowohl für numerische Werte/Strings leichtgewichtig sein kann als auch ausreichende Berechnungs- und Anpassungsunterstützung bietet. Ich glaube, die Prägnanz der Beispiele unterstreicht dies, aber ich bin daran interessiert, von jedem zu hören, der der Meinung ist, dass dies die zukünftige Kontrolle umständlicher machen würde.

• @sonnemaf Ich schätze die Neuheit und Intuitivität des Symbols > Popup-Rechner-Beispiel. Für mich leitet sich dies als Beispiel aus dem Konzept von CalendarDatePicker ab und könnte eine ausgezeichnete Überlegung für ein V2-Feature sein, es sei denn, es gibt einen starken Druck von allen hier, dass es für V1 in Betracht gezogen werden sollte?

Ein Popup-Rechner kann sinnvoll sein, wenn eine Abstimmung mit den Open-Source-Bemühungen des Rechners besteht. Sowohl für die Konsistenz im Look des Calculator Flyout, als auch in der Engine dahinter.

Ich bin mir nicht sicher, ob dies der richtige Ort ist, um dieses Bild zu veröffentlichen, aber hier sind Designs für die verschiedenen Staaten, die den Spezifikationen entsprechen.

Das Bild hat eine Skalierung von 200 %

@mdtauk Was ist der Zweck Ihrer Mockups?

Welchen Zustand versucht jedes Bild darzustellen? Ohne dass Sie dies klarstellen, können wir Annahmen treffen, die sich von Ihren unterscheiden.

Sind diese als pixelperfekte Referenzen gedacht?

Können Sie angeben, wo etwas in Ihren Bildern vom Standard der Plattform oder des Basissteuerelements abweicht, damit klar ist, was (wenn überhaupt) Sie hinzufügen oder ändern?

@mrlacey Ich könnte eine vollständigere Aufschlüsselung machen, wenn das hilfreich wäre? Ich habe nur versucht, einige der in der Spezifikation genannten Beispiele zu veranschaulichen.

Sie sollen veranschaulichen, wie diese Steuerelemente mit den verschiedenen vorgeschlagenen Steuerelementen wie Präfix, Suffix, Masken, Auf- und Ab-Schaltflächen aussehen könnten. Sie werden aus den FabricWeb-Steuerelemententwürfen extrapoliert, verwenden jedoch XAML-Elemente wie FocusReveal und die Steuerelementgröße für die Schaltflächen.

Die Beispiele zeigen Ruhe - Fokus - Deaktivierter Zustand

Der Popup-Rechner wäre ein nettes Feature für V2.

Ich bin mir nicht sicher, wo ich meine Bemerkungen platzieren soll. Muss ich eine PR auf Anfrage machen oder kann ich meine Gedanken in dieser Ausgabe weiterschreiben?

Ganze Zahl

Wäre ein Integer-Wert für NumberBoxFormatType nützlich?

enum NumberBoxFormatType
{
    IPAddress,
    InternationalTelephone,
    Currency,
    Integer,
}

Sprache

Würden Sie die Sprache verwenden , um die Währung, Dezimalzeichen-Gruppierungssymbole anzugeben?

Im nächsten Beispiel wird die Sprache auf nl-NL gesetzt. Bedeutet dies, dass das Präfix das Eurozeichen ist, das Dezimalzeichen ein Komma mit 2 Dezimalstellen dahinter und die Zifferngruppierung ein Punkt ist? Negative Währungen haben ein Minuszeichen vor und keine Klammern wie in den USA.

<TextBlock Header="Price" 
    PlaceholderText="0,00" 
    FormatType="Currency"
    Language="nl-NL" />

Ist dies genug, da es in Windows viele Optionen für das Zahlen- und Währungsformat gibt.

Wert Eigenschaft oder Eigenschaften

Benötigen wir eine Value-Eigenschaft und welchen (numerischen) Typ wäre sie? Ich würde es verwenden, um es zu datenbinden. Soll es ein Double, Dezimal oder Int sein. Benötigen wir Nullable-Unterstützung (double?, decimal?, int?). Ich möchte nicht die Text-Eigenschaft des geerbten TextBox-Steuerelements für die Datenbindung verwenden. Wir brauchen auch Unterstützung für Decimal, Double ist nicht genug.

<TextBlock Header="Price" 
    Value="{x:Bind ViewModel.Employee.Salary, Mode=TwoWay}"
    PlaceholderText="0.00" 
    FormatType="Currency"
    Language="nl-NL" />

Was ist, wenn das Gehaltseigentum des Mitarbeiters ein Nullwert ist?(Dezimal?). Benötigen wir die ValueNullableDecimal-Abhängigkeitseigenschaft. Das SelectedDate des DatePicker-Steuerelements ist ein Nullable. Nullable ist ein Problem, insbesondere bei der Datenbindung.

<TextBlock Header="Price" 
    ValueNullableDecimal="{x:Bind ViewModel.Employee.Salary, Mode=TwoWay}"
    PlaceholderText="0.00" 
    FormatType="Currency"
    Language="nl-NL" />

Gleiches gilt für MinValue und MaxValue. Sie sind jetzt Integer in der Spec, aber sollte dies nicht ein Double sein?.

@sonnemaf Da die Spezifikation besagt, dass das Steuerelement für alles gedacht ist, wo Ziffern eingegeben werden können, muss dies meiner Meinung nach bedeuten, dass der "Wert" als Text behandelt wird und der verbrauchende Code bei Bedarf konvertiert wird. Es ist nicht ideal, aber selbst wenn es sich bei einer Value Eigenschaft um eine Long- oder Floating-Eigenschaft handelt, gibt es immer noch viele Gelegenheiten, in denen Konvertierungen erforderlich sind.
Es ist besser als Überladungen für jeden numerischen Typ.
Dann gibt es Dinge, für die das Steuerelement entwickelt wurde und die nicht in einen "numerischen" Typ umgewandelt werden können, wie z. B. US-Postleitzahl, Telefonnummer oder IP-Adresse. Für diese Art von Werten scheint das Abrufen des Textes die beste (einzige) Option zu sein.
Ich denke, es ist einfacher (zumindest in der ursprünglichen Version, eine Möglichkeit zu haben, auf den eingegebenen Wert zuzugreifen und sich bei Bedarf auf Konverter zu verlassen. Ich kann einen Platz für eine Sammlung von Helfern (oder Unterklassen) sehen, die zunächst zum Toolkit kommen und dann einige davon sie werden auf der Grundlage von Feedback in die Hauptsteuerung integriert.

Ist eine Language Eigenschaft erforderlich? Warum sollte dies nicht dasselbe wie UILocale sein? Es mag gute Gründe geben, aber es scheint, als ob dies benutzerkonfigurierbar sein sollte (auf Betriebssystemebene) und die Möglichkeit, ein bestimmtes Format anzugeben, könnte zu mehr Problemen für Entwickler führen, wenn das Format woanders nicht übereinstimmt oder was der Benutzer von die Anwendung will. Aus dem Kopf: Was ist, wenn jemand einen Wert in einem anderen Format einfügt?

@mdtauk Was ist der Zweck Ihrer Mockups?

Welchen Zustand versucht jedes Bild darzustellen? Ohne dass Sie dies klarstellen, können wir Annahmen treffen, die sich von Ihren unterscheiden.

Sind diese als pixelperfekte Referenzen gedacht?

Können Sie angeben, wo etwas in Ihren Bildern vom Standard der Plattform oder des Basissteuerelements abweicht, damit klar ist, was (wenn überhaupt) Sie hinzufügen oder ändern?

@mrlacey Ist das das, was Sie wollten?

@mdtauk das ist etwas besser, da es einiges von dem erklärt, was Sie zu zeigen versuchen.

Die grundlegende Frage bleibt jedoch: Was ist Ihr Ziel, dies zu zeigen? Ist es nur eine Idee? Ist es Ihre bevorzugte Version, nachdem Sie verschiedene Ideen erforscht haben? Wenn ja, warum sind diese die besten/bevorzugten?

Der Vergleich der aktuellen Steuerelemente mit der Darstellung der neuen Steuerelemente in Ihren bevorzugten neuen systemweiten Stilen bedeutet, dass es nicht möglich ist, die spezifischen Elemente des Steuerelements von den Inhalten in Ihren bevorzugten neuen systemweiten Stilen zu trennen.

Sie erwähnen beispielsweise das Ändern der Transparenz eines Rahmens. Ist diese Änderung für alle Steuerelemente vorgesehen oder nur für diese? Und in welchen Staaten?

Das Angeben expliziter Größen (für Schaltflächen) kann in Design-Kompositionen problematisch sein, da sie nicht immer gleichmäßig übertragen werden, wenn die Größe ihres Containers geändert wird. Sollen sie immer quadratisch sein? oder ist ihre Breite basierend auf der Standardhöhe des Steuerelements festgelegt?

Wie wird der Hintergrundpinsel für Präfixe und Suffixe bestimmt? Ich vermute eine vorhandene Systembürste, aber welche?

Maskierung wird in dieser Spezifikation nicht abgedeckt. Sollen sich Ihre "maskierten" Beispiele auf Formatzeichenfolgen beziehen?
Wie entspricht Ihr maskiertes Beispiel einem Format?
Ich gehe davon aus, dass Ihr Beispiel den Eintrag einer IP-Adresse der Version 4 zeigt, aber es sieht so aus, als würden dort viele Annahmen getroffen, basierend darauf, wie sauber alles zu passen scheint. Sollen alle nicht eingebbaren Werte einen Hintergrund und Ränder haben? Was ist, wenn sie nicht immer angezeigt werden? Sollten Inhalte so gestreckt werden, dass sie den gesamten verfügbaren Platz ausfüllen, wie es in Ihrem Beispiel der Fall zu sein scheint? Wie wird der für nicht eingebbare Werte zugewiesene Speicherplatz behandelt, wenn Inhalte geschwenkt werden, die breiter als der verfügbare Speicherplatz sind?

@mdtauk das ist etwas besser, da es einiges von dem erklärt, was Sie zu zeigen versuchen.

Die grundlegende Frage bleibt jedoch: Was ist Ihr Ziel, dies zu zeigen? Ist es nur eine Idee? Ist es Ihre bevorzugte Version, nachdem Sie verschiedene Ideen erforscht haben? Wenn ja, warum sind diese die besten/bevorzugten?

Der Vergleich der aktuellen Steuerelemente mit der Darstellung der neuen Steuerelemente in Ihren bevorzugten neuen systemweiten Stilen bedeutet, dass es nicht möglich ist, die spezifischen Elemente des Steuerelements von den Inhalten in Ihren bevorzugten neuen systemweiten Stilen zu trennen.

Sie erwähnen beispielsweise das Ändern der Transparenz eines Rahmens. Ist diese Änderung für alle Steuerelemente vorgesehen oder nur für diese? Und in welchen Staaten?

Die NumberBox-Spezifikation enthielt keine visuellen Beispiele, und die Bilder im Originalvorschlag sind grobe Beispiele für die Funktionalität. Es gibt einen weiteren PR #524, bei dem die Steuerelementvorlagen mit CornerRadius-Werten bei 2epx aktualisiert werden, was auch die gleiche Rundung ist, die von Fabric Web verwendet wird.

Unter der Annahme, dass die von TextBox abgeleiteten Steuerelemente ebenfalls auf ähnliche Weise aktualisiert werden, habe ich dies als Leitfaden verwendet, um zu zeigen, wie die vorgeschlagene Funktionalität von NumberBox darin passen könnte. Fabric Web-Textfelder unterstützen bereits Präfix- und Suffix-Werte, also habe ich einfach dieses Design genommen und die XAML-Metriken verwendet.

Das Angeben expliziter Größen (für Schaltflächen) kann in Design-Kompositionen problematisch sein, da sie nicht immer gleichmäßig übertragen werden, wenn die Größe ihres Containers geändert wird. Sollen sie immer quadratisch sein? oder ist ihre Breite basierend auf der Standardhöhe des Steuerelements festgelegt?

Die aktuelle TextBox verfügt über einige integrierte Schaltflächen, wie z. B. die SearchBox, die Schaltfläche Password Reveal und die Schaltfläche Clear Text. Touch-Ziele für XAML schlagen vor, dass Schaltflächen 32 x 32 epx betragen - ich habe sie einfach quadratisch gehalten und diese Anleitung verwendet.

Wie wird der Hintergrundpinsel für Präfixe und Suffixe bestimmt? Ich vermute eine vorhandene Systembürste, aber welche?

In meinem Beispiel habe ich die Thema Vordergrundfarbe verwendet, aber eine Deckkraft von 15% verwendet. Die FabricWeb-Schaltflächen verwenden näher an 10 % und die XAML-Schaltflächen verwenden 20 %.
Es gibt ähnliche Pinselwerte wie ListLowBrush, aber möglicherweise ist ein neuer TextBoxAppendixBackground-Pinsel erforderlich. Der Text Foreground würde denselben PlaceholderTextForeground-Pinsel verwenden.

Maskierung wird in dieser Spezifikation nicht abgedeckt. Sollen sich Ihre "maskierten" Beispiele auf Formatzeichenfolgen beziehen?
Wie entspricht Ihr maskiertes Beispiel einem Format?
Ich gehe davon aus, dass Ihr Beispiel den Eintrag einer IP-Adresse der Version 4 zeigt, aber es sieht so aus, als würden dort viele Annahmen getroffen, basierend darauf, wie sauber alles zu passen scheint. Sollen alle nicht eingebbaren Werte einen Hintergrund und Ränder haben? Was ist, wenn sie nicht immer angezeigt werden? Sollten Inhalte so gestreckt werden, dass sie den gesamten verfügbaren Platz ausfüllen, wie es in Ihrem Beispiel der Fall zu sein scheint? Wie wird der für nicht eingebbare Werte zugewiesene Speicherplatz behandelt, wenn Inhalte geschwenkt werden, die breiter als der verfügbare Speicherplatz sind?

Ich werde nicht so tun, als hätte ich alle Antworten darauf, und wie es auf dem Steuerelement sichtbar angezeigt wird, hängt davon ab, wie die Maskenformatierung in den Steuerelementen implementiert ist.

Ich habe die IP-v4-Adresse verwendet, da sie das in der Spezifikation enthaltene Beispiel ist, und meine ursprüngliche Absicht war es, zu veranschaulichen, was vorgeschlagen wurde (obwohl die Beispiele für Präfix und Suffix fehlten, habe ich andere Werte gewählt).

Ich habe mir angesehen, wie andere Steuerelemente mit der Maskierung umgehen, und einige verwenden Inline-Text, der das Caret-Zeichen bei der Eingabe von Werten verschiebt. Andere geben bei der Eingabe einer Telefonnummer Dinge wie Klammern und Bindestriche ein. Einige verwenden Tabulator- oder Pfeiltasten, um zwischen den Segmenten zu wechseln. Das nächste Beispiel von Microsoft, das mir in den Sinn kommt, ist die Eingabe von Product Keys während der Windows-Installation.

Ich dachte, die Verwendung des gleichen Stils wie die angehängten Elemente würde zur Ästhetik passen, aber ich bin mir bewusst, dass dies die Länge des Steuerelements erhöht, um alles hineinzupassen, und Inline kann den Platz besser nutzen.

Nur eine Anmerkung, da ich jetzt mit TextBox arbeite, gibt es kein einzelnes Ereignis, das einen vom Benutzer geänderten Wert signalisiert (dh die Vereinigung von verlorenem Fokus und gedrückter Return-Taste), ähnlich wie bei https://doc.qt.io /qt-5/qlineedit.html#textEdited es wäre toll, das in der NumberBox zu haben, da es für diese Art von Bearbeitungen gedacht ist. Übrigens, wenn es alle Arten von Werten wie IP-Adressen verarbeiten soll, ist das Feld "Number" vielleicht ein zu enger Name? Es könnte ValueBox oder so sein

@adrientetar NumberBox scheint als Name in Ordnung zu sein, da alle Eingaben als Zahlen zählen. IP-Adresse hat 4 Zahlen, Telefonnummern, Währung, Maße usw.

DigitBox, NumeralBox usw. sind alle Varianten, die nicht ganz zum Microsoft-Namensstil passen.

Werte müssen auch nicht numerisch sein, daher kann ValueBox auch etwas irreführend sein.

@sonnemaf und @mdtauk , ich habe mit meinem Team über die Idee des eingebetteten Taschenrechners gesprochen und kurz gesagt, wir LIEBEN es - keine Übertreibung. Wir sind mehr als begeistert, wie Sie alle die Qualität und Kreativität der von uns gelieferten Steuerungen bereits verbessert haben.

Ich brauche etwas Hilfe von Ihnen, um dies zu erreichen. Die Art und Weise, wie wir über die Litanei großartiger Ideen, die durch unser Repo kommen, auf dem Laufenden bleiben, besteht darin, nicht nur ideenorientiert, sondern auch szenarioorientiert zu sein. (Ich teile dies, weil das Sprechen dieser Sprache Ihren Funktionsanfragen in unserem gesamten Repository einen konkreten Einfluss verleiht.)

Kann mir einer von Ihnen echte Szenarien für einen eingebetteten Taschenrechner in einer der von Ihnen entwickelten Apps ermöglichen? Kontext, Screenshots, Benutzerprofile helfen. (Meine E-Mail ist auch in meinem GitHub-Profil, wenn Sie es vorziehen, Details vertraulich zu behandeln.) @xyzzer , @mrlacey , @robloo , @Felix-Dev, @adrientetar und @ArchieCoder , bitte fühlen Sie sich ermutigt, Ihr Nutzungsszenario zu teilen, wenn diese Funktion verwendet wird ist auch für dich interessant.

Über diesen Schritt hinaus könnte diese Funktion nur durch das Risiko der DLL-Größe von WinUI mit der Engine der Taschenrechner-App einen Engpass haben. Ich werde dies parallel prüfen, um die Machbarkeit zu überprüfen.

Ich habe zuvor das Problem angesprochen, dieses Steuerelement für mehr als nur numerische Typen zu behandeln.

Es gibt einen grundlegenden Unterschied zwischen einer Zahl und einer Zeichenfolge, die eine Ziffernfolge enthält.

Dies war vor der Veröffentlichung des ersten Entwurfs der Spezifikation, daher gehe ich davon aus, dass dies in Betracht gezogen wurde und die Entscheidung getroffen wurde, dieses Steuerelement sowohl "herkömmliche numerische Werte" als auch "Strings mit Ziffern" behandeln zu lassen.

Ich glaube nicht, dass irgendjemand wirklich versuchen würde zu argumentieren, dass eine IPv4-Adresse eine "Zahl" nach einer anderen Definition ist, als die normalerweise nicht als formatierte Ziffernfolge dargestellt wird. In Wirklichkeit ist es nur ein 4-Byte-Wert.

@SavoySchuler

• Eingabe von Ausgaben vielleicht - Eingabe von Artikeln aus einer Quittung, bei denen einige Artikel persönlich sind und andere Teil der Arbeit sind.
• Restaurant-App beim Aufteilen einer Rechnung oder vielleicht Trinkgeldberechnung?
• Hex-Bearbeitungs-App, um einen Offset-Wert zu berechnen, auf den die Auswahl verschoben werden soll?

Ein Steuerelement, das IP-Adressen unterstützt, wäre eine großartige Ergänzung der Plattform, aber ich glaube nicht, dass NumberBox das richtige Steuerelement für dieses Szenario ist.

Wie bereits erwähnt, würde die NumberBox-Steuerung:

• Verwenden Sie die virtuelle Number Tastatur, wenn Sie sie auf einem Gerät ohne physische Tastatur verwenden
• habe 2 Tasten -/+
• ein Pop-up mit einem Taschenrechner anzeigen oder dem Benutzer erlauben, grundlegende arithmetische Operationen einzugeben

Keine dieser Funktionen macht bei einer IP-Adresse Sinn. Auch das Design der Steuerung ist sehr unterschiedlich.

Darüber hinaus sollten wir bedenken, dass wir, wenn wir IPv4-Adressen unterstützen, auch IPv6-Adressen unterstützen müssen, und zwar nicht mit Ziffern, sondern mit Hexadezimalzahlen.

Ich denke, es wäre sinnvoller, keine IP-Adressunterstützung in dieses Steuerelement aufzunehmen, sondern stattdessen an einem neuen MaskedTextBox Steuerelement für UWP zu arbeiten (unterstützt IPv4, IPv6, Telefonnummer, Postleitzahl, SSN usw.). mit einer umfangreichen Benutzeroberfläche (wie von @mdtauk demonstriert), um TextBoxMask aus dem Community Toolkit (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask) zu ersetzen/zu verbessern.

Ein Steuerelement, das IP-Adressen unterstützt, wäre eine großartige Ergänzung der Plattform, aber ich glaube nicht, dass NumberBox das richtige Steuerelement für dieses Szenario ist.

Wie bereits erwähnt, würde die NumberBox-Steuerung:

• Verwenden Sie die virtuelle Number Tastatur, wenn Sie sie auf einem Gerät ohne physische Tastatur verwenden
• habe 2 Tasten -/+
• ein Pop-up mit einem Taschenrechner anzeigen oder dem Benutzer erlauben, grundlegende arithmetische Operationen einzugeben

Keine dieser Funktionen macht bei einer IP-Adresse Sinn. Auch das Design der Steuerung ist sehr unterschiedlich.

Darüber hinaus sollten wir bedenken, dass wir, wenn wir IPv4-Adressen unterstützen, auch IPv6-Adressen unterstützen müssen, und zwar nicht mit Ziffern, sondern mit Hexadezimalzahlen.

denke, es wäre sinnvoller, keine IP-Adressunterstützung in dieses Steuerelement aufzunehmen, sondern stattdessen an einem neuen MaskedTextBox Steuerelement für UWP zu arbeiten (unterstützt IPv4, IPv6, Telefonnummer, Postleitzahl, SSN usw.) mit eine umfangreiche Benutzeroberfläche (wie von @mdtauk demonstriert) und Ersetzen/Verbessern von TextBoxMask aus dem Community Toolkit (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

@rudyhuyn Ich stimme größtenteils dem zu, was Sie gerade hier gesagt haben, und meine Illustrationen waren für die vorgeschlagene

Aber wie von anderen erwähnt wurde, muss ein maskiertes Textfeld nicht nur auf Ziffern beschränkt sein, sondern kann auch Strings enthalten. Das Microsoft Product Key-Feld ist ein gutes Beispiel, in dem 5 Sätze von 0-9 AZ-Zeichen akzeptiert werden.

Selbst wenn die Maskierung getrennt wurde, gibt es meiner Meinung nach immer noch gute Anwendungsfälle für das Einschließen von PrefixText- und SuffixText-Eigenschaften in das NumberBox-Steuerelement. Währung, Maße, alle erfordern eine Art Kontext.

Spin Buttons dienen ausschließlich zum Inkrementieren und Dekrementieren von Werten, sodass diese auch im Bereich eines NumberBox-Steuerelements liegen.

Präfix und Suffix könnten Eigenschaften des TextBox-Steuerelements selbst werden und somit von den anderen Steuerelementen geerbt werden. (Möglicherweise muss es eine Ausnahme für die PasswordBox geben, wenn sie Sicherheitslücken öffnet)

Masken für allgemeine Werte können eine Aufzählung (zusammen mit einer CustomFormatMask) für dieses getrennte Steuerelement sein. Einige dieser Masken können einen kulturellen Kontext beinhalten, wie z.

SW1A 2AA

Beispiel für britische Postleitzahl (für Nr. 10 Downing Street)

Es scheint, dass es mir heute Morgen nicht gelungen ist, die Seite zu aktualisieren, bevor ich meine Antwort gesendet habe ... Vielen Dank an alle Rockstars, die diesen Vorschlag auf eine ganz neue Ebene gebracht haben! Ich weiß, dass Wörter auf GitHub überstrapaziert werden, aber ich meine es ernst!

@mdtauk - deine Mock-ups sind fantastisch. Ich hatte noch keine Prototypentwürfe für diese Steuerung entworfen. Darf ich Ihr Modell aufschlüsseln und es als Prototypen in die Spezifikation aufnehmen, damit unsere Designer ihre Palette beginnen können? Ich werde heute einen Designer kontaktieren und fragen, ob ich ihn dazu bringen kann, auf Ihren Thread mit

@sonnemaf , danke nochmal! Ich möchte Sie ermutigen, Ihren Kommentar zu kopieren und hier auf dem Konversations-Tab des @mdtauk ).

@mdtauk : Ich stimme Ihnen zu, ein Präfix/Suffix wäre eine gute Ergänzung zu TextBox und nicht auf Zahlen beschränkt, einige Beispiele:

• Bitten Sie einen Mitarbeiter, seine E-Mail-Adresse einzugeben, wenn die Domäne immer dieselbe ist (z. B. @microsoft.com).
• Geben Sie den Namen eines Formulars ein, wenn es immer mit W- beginnt

etc...

Sie sollten ein weiteres Ticket eröffnen, damit wir eine Diskussion darüber starten können!

@rudyhuyn sehen Sie die Möglichkeit, so etwas wie eine IP-Adresse nicht zu unterstützen, aber die Möglichkeit, eine Telefonnummer oder Postleitzahl zu unterstützen, als praktikabel an?
Mein Gedanke ist, dass, wenn Sie beginnen, einige Dinge einzuschränken, andere jedoch nicht, die Regeln für das, was abgedeckt wird, sehr klar definiert werden müssen.
Allein die Unterstützung von Werten, die als Integer, Float usw. angezeigt werden können, macht die Dinge sehr klar und schafft dennoch ein Steuerelement, das viel Wert bietet.

@SavoySchuler Meine Designs stehen Ihnen vollständig zur Verfügung. Ich habe sie gepostet, um zu versuchen, die Kontrolle für alle Beteiligten zu visualisieren.

@rudyhuyn Wenn Sie einen Vorschlag für eine MaskedTextBox oder FormattedTextBox posten, kann dies mehr Gewicht haben! Wie bei der NumberBox freue ich mich über jede meiner Entwürfe, die in einen solchen Vorschlag aufgenommen werden, und kann bei Bedarf weitere Beispiele erstellen.

@mrlacey Telefonnummern (abgesehen von den Formatierungszeichen) sind reine Zahlen - fallen jedoch unter keinen Berechnungsanwendungsfall, passen sie also besser zu einer maskierten TextBox, oder ist es sinnvoll, diese in einer NumberBox zu unterstützen?

Bei der Erstellung des Steuerelements und der Dokumentation ist es wichtig, einen klaren Anwendungsfall und Beispiele dafür bereitzustellen, welches Steuerelement in welchem ​​Kontext verwendet werden soll.

@mrlacey : Ich nicht.

Wie Sie bereits sagten, sollten wir reelle Zahlen trennen, nicht nur mit 0-9 Zeichen, sondern mit einem arithmetischen Wert.

Eine IP-Adresse, Telefonnummer, SSN, Postleitzahl verwenden 0-9 Zeichen, haben aber keine arithmetischen Werte (Sie können 2 davon hinzufügen, wenn Sie am Ende ".00" hinzufügen, ändern Sie die Bedeutung des Werts usw.) . In diesen Fällen ist der Wert ein String, kein int/double, eine MaskedTextBox wäre sinnvoller.

Darüber hinaus verwendet eine Postleitzahl nur Ziffern in den USA, aber nicht in Kanada zum Beispiel, eine IPv6-Adresse kann AF-Zeichen enthalten, eine Telefonnummer kann ein +-Zeichen enthalten (555-123-4567 und +555-123-4567 sind 2 verschiedene Telefonnummern) usw...

Um meine Meinung zusammenzufassen, sollte NumberBox.Value ein Double sein, kein String.

@mrlacey Telefonnummern (abgesehen von den Formatierungszeichen) sind reine Zahlen - fallen jedoch unter keinen Berechnungsanwendungsfall, passen sie also besser zu einer maskierten TextBox, oder ist es sinnvoll, diese in einer NumberBox zu unterstützen?

Telefonnummern können vollständig aus Ziffern (plus Formatierung) bestehen, aber das macht sie nicht zu Zahlen. Sie können keine arithmetischen Operationen an ihnen durchführen und etwas Sinnvolles erhalten.
Einige können auch mit einem Pluszeichen beginnen.
Auch die Anzahl der führenden Nullen in einer Telefonnummer ist aussagekräftig. Bei einem numerischen Wert ist dies nicht der Fall.
Die anderen Funktionalitäten im Control, wie Berechnungen oder Up&Down-Buttons, machen bei einer "Rufnummer" keinen Sinn.

Dieses Steuerelement sollte auf Werte beschränkt werden, die ohne das Risiko eines Informationsverlusts in einen int/uint oder eine Dezimalzahl umgewandelt werden können.

Um sicherzustellen, dass ich dieses Feedback angemessen synthetisiere, geben Sie mir bitte einen Daumen nach oben für diesen Kommentar, wenn Sie der Meinung sind, dass dies der beste Ort für alle Arten von numerischen Zeichenfolgeneingaben ist (wie Telefonnummern und IPv4) über Formattypen und einen

Ich kann nicht garantieren, dass dies demokratisch entschieden wird, da ich die Entscheidung treffen werde, die für unsere Kunden weltweit den besten Return on Investment ergibt - aber es wird dazu beitragen, das zu bestätigen, was ich hier sehe: niemand bittet darum, die Zahlen zu unterstützen Saiten und würde dafür einen eigenen Regler bevorzugen.

@SavoySchuler Zahlen, die

Ich habe mich gerade mit dem Team hier synchronisiert und wollte Updates zu einigen unserer offenen Fragen teilen:

• Wir hören auf Ihr Feedback und sind uns einig, dass NumberBox nicht der richtige Ort für numerische Zeichenketten ist. Die Eigenschaften FormatKinds und CustomFormat wurden durch spezifischere APIs ersetzt, um das Zahlenformat auf intuitivere Weise zu steuern.
• Präfix und Suffix gehören wirklich in die TextBox (von der NumberBox sie erbt). Ich werde @mdtauk , @mrlacey oder jedem anderen ein paar Tage Vorsprung geben, um die Funktionsanfrage vorzuschlagen, ansonsten werde ich sie starten und hier verlinken. Damit wird vorerst verhindert, dass NumberBox bei der Lokalisierungs-/Automatisierungsausgabe blockiert wird.
• Der letzte Feed in einer NumberBox (nach Berechnung, Rundung usw.) wird als String in der Text-Eigenschaft beibehalten, die aus TextBox kommt UND als Double in einer neuen Value-Eigenschaft. Wir beabsichtigen, diese Rückmeldungen aneinander zu geben, damit sich Änderungen an einem im anderen widerspiegeln. Der Zweck ist, Ihnen so viel Arbeit wie möglich zu nehmen und den Wert bereit zu haben, auf den Sie bei Bedarf zugreifen können.
• StepSize fehlte als Eigenschaft in der Spezifikation.
• Integer-Typen werden in Double geändert.
• Wir sind immer noch begeistert von der Idee eines eingebetteten Rechners und suchen nach weiteren Szenarien, die uns helfen, dies zu verfeinern. @mdtauk , vielen Dank, dass Sie bereits auf diesen Punkt des Feedbacks
• In Bezug auf die Eingabevalidierung besteht die Idee darin, zuerst ein Ereignis des Typs ValueChanged zu senden, das dem Entwickler die Möglichkeit gibt, die Eingabe zu manipulieren oder sie bei der Übermittlung des End-/Blockformulars nach Bedarf zu verarbeiten. Wenn keine Korrekturmaßnahmen ergriffen werden (z. B. Erzwingen innerhalb von Min/Max, Entfernen ungültiger Zeichen usw.), zeigt NumberBox dem Benutzer stattdessen eine Fehleranzeige über seine Eingabe an. Dieser zweifache Ansatz gibt Entwicklern die Möglichkeit zu reagieren, wenn sie es vorziehen, ermöglicht aber auch, dass die Korrektur an den Benutzer verschoben wird.

Es gab unglaublich viele Rückmeldungen, auf die ich immer noch reagiere. Vielen Dank für Ihre Geduld, ich werde allen hier und auch im Spec-Repo antworten!

"Konzeptkunst von NumberBox mit einem eingebetteten Taschenrechner." WinUI-Community, Mai 2019. (farbig)

(Kompliment von @ryandemopoulos )

@SavoySchuler Sie haben nach einigen Szenariobeispielen gefragt, in denen die Art von Steuerelement(en), die wir besprechen, verwendet werden könnte. Ich habe zwei in meiner App, die gute Beispiele sein können.

Fall 1: Es gibt einen Einstellungseditor für 2D-Graphen, in dem Sie die Achse anpassen können.

• Dies erfordert nur eine einfache numerische Eingabe. Inkrementiere +/- Tasten wären hier nützlich.
• Ein doppelter Wert wäre in Ordnung, aber die Eingaben müssen beim Drücken von Zeichen validiert werden. Der Benutzer sollte nie in der Lage sein, 'a' zu drücken und es im Eingabefeld erscheinen zu lassen. Die Eingabevalidierung sollte den Rahmen nicht rot machen und den Benutzer warnen – es sollte einfach nicht möglich sein, einen ungültigen Wert einzugeben.
• Die Lokalisierung müsste vom Steuerelement unterstützt werden und das Verschieben der Dezimalstelle (ob Komma, Punkt usw.) als Sonderfall behandelt (ich erwähne das immer wieder, weil es leicht zu übersehen ist)

Fall 2: Es gibt ein Eingabefeld für einen Währungswert wie unten gezeigt. Dies ist ein benutzerdefiniertes Steuerelement "CurrencyBox"

• Dies könnte eine Taschenrechner-Schaltfläche verwenden und die Möglichkeit, die Gleichungen 2 + 3 einzugeben, hätte hier einen gewissen Wert (ich bin jedoch immer noch der Meinung, dass dies ein separates Steuerelement sein sollte)
• Ein doppelter Wert ist dafür NICHT ideal. Ich würde vorschlagen , die Spezifikation für Value von double auf decimal zu ändern , um diese Art von Anwendungsfall zu unterstützen . Andernfalls liegt es am Entwickler, den Zeichenfolgentext zu analysieren.
• Hier gibt es einen Sonderfall, bei dem das negative Vorzeichen separat behandelt wird. Das macht es für den Benutzer viel einfacher, beim Anmelden keinen Fehler zu machen. Ich erwarte jedoch nicht, dass die NumberBox dies out of the box unterstützt.
• Es ist wichtig, die Textausrichtung festzulegen, und ein Präfix/Suffix wäre äußerst nützlich, um ein Währungssymbol anzuzeigen (Die Lokalisierung wäre möglicherweise immer noch ein Problem, wenn man weiß, ob das Symbol rechts oder links angezeigt werden soll; die App selbst könnte jedoch diese Logik haben)
• Der Benutzer kann sowohl einen fremden als auch einen lokalen Wert eingeben. Die NumberFormatInfo und CultureInfo für diese beiden Werte KÖNNEN sich von der UI-Kultur unterscheiden. Daher muss das Steuerelement für die Lokalisierung das Überschreiben einer benutzerdefinierten NumberFormatInfo unterstützen.

Im Moment wird in der App Windows Community Toolkit für beide Fälle mit angehängten Eigenschaften an die TextBox wie folgt verwendet:
TextBoxRegex.ValidationMode="Dynamisch"
TextBoxRegex.ValidationType="Dezimal"

Einige abschließende Kommentare (sorry, das ist so lang!)

• Ich denke, wir diskutieren hier möglicherweise 3 verschiedene Kontrollen. Eine Bar-Bones NumberBox, eine CalculatorBox, die Gleichungen und erweiterte numerische Eingaben haben kann (Rechner-Button!) und schließlich eine MaskedTextBox für nicht-numerische Eingaben wie Telefonnummern und IP-Adressen. Wir sollten sie nicht verwirren, und eine Einigung darüber, wie diese Konzepte aufgeteilt werden können, ist der Schlüssel zum Fortschritt mit der Spezifikation.
• Wir können den Fokus nicht auf den grundlegendsten und wohl nützlichsten Anwendungsfall verlieren: Eine normal aussehende Textbox mit nichts weiter als Eingabefilterung, sodass nur eine gültige Zahl eingegeben werden kann. Alle anderen Optionen sollten abschaltbar sein (ich denke an die Inkrement +/- Tasten)
• Ich schlage immer noch vor, in der Spezifikation von Double zu Dezimal zu wechseln, um die Dezimalgenauigkeit im geparsten Wert genau zu erfassen. Darüber hinaus sollten wir die Eingabe ganzer Zahlen wahrscheinlich anders als die Eingabe rationaler Zahlen betrachten. Das ist wahrscheinlich eine neue Eigenschaft in der API "IsInteger = true", um den dezimalen Standardwert zu ändern.

Bearbeiten: Idee entfernt, für den NumberBox.Value-Typ von Double zu Dezimal zu wechseln. Ich war falsch in der Annahme, dass dies in der C++-WinRT-Welt existiert. Dies ist nicht der Fall und befindet sich stattdessen nur im .net-Kern/Framework.

@robloo , zu diesem letzten Kommentar gibt es in WinRT keinen Decimal-Typ.

Der Visual Tree-Debugger von XAML Toolkit ist ein Tool, das sich stark auf das NumericUpDown-Steuerelement des Toolkits stützt, bei dem das Inkrementieren/Dekrementieren mit Mausziehen, Schaltflächen und Tastatur wichtig ist. Rechnereingabe könnte auch helfen:

@robloo und @xyzzer , genau solche Infos suche ich!

Validierung/Maskierung

@robloo , ich interessiere mich besonders für Fall 1: Bullet 2 - Validierung vs. Maskierung. Lassen Sie uns das Szenario der "schlechten Eingabe" ab jetzt durchsprechen:

• Ein neuer Benutzer gibt "zwei" in Ihre NumberBox ein.
• Die NumberBox löst das "ValueChanged"-Ereignis aus, das Ihnen die Möglichkeit gibt, nicht-numerische Eingaben auf "0" - oder anders - zurückzusetzen, wenn Sie dies wünschen. Wenn nichts unternommen wird, dann...
• Validierungsstarts in NumberBox leuchtet rot und zeigt dem Benutzer eine Fehlermeldung an, die ihn darüber informiert, dass nur numerische Eingaben erlaubt sind (dieser Teil wurde noch nicht vollständig rationalisiert, daher ist dies nur eine Hypothese).

Gibt Ihnen diese Veranstaltungsreihe die Möglichkeit, die Erfahrung zu schaffen, die Sie benötigen?

Ich verstehe, dass Maskierung ein wünschenswerter Standard sein könnte, aber lassen Sie mich mitteilen, was mein Team letzte Woche besprochen hat - wir sind auf die Richtung gekommen, dass Validierung (Fehleranzeige/Meldung) in Fluent-Steuerelementen bevorzugt wird, da Maskierung frustrierend sein kann und verwirrend für Endbenutzer, wenn sie keine Ausgabe von ihrer Tastatureingabe erfahren. Eine andere Denkweise ist, dass die Validierung dem Benutzer ein Maß an Transparenz und Informationen bietet, das ihm die Erfahrung bewusster macht, anstatt stillschweigend gezwungen zu werden. Daher bestand unsere derzeitige Vorgehensweise darin, eine grundlegende Validierung einzubauen, ohne die Möglichkeit für den Entwickler zu blockieren, eine erweiterte Validierung (in Kürze in TextBox) oder eine Maskierung über das ValueChanged-Ereignis nach Bedarf hinzuzufügen. Nach unserem Verständnis ist dies flexibel genug, um alle Anforderungen zu erfüllen und gleichzeitig die empfohlene Erfahrung als Standard bereitzustellen.

Was sind Ihre Gedanken hier? Ich würde mich freuen, wenn Sie Ideen haben, um diese Konzepte weiterzuentwickeln oder ein noch besseres Erlebnis zu schaffen, wenn wir können.

Wertformatierung

Zu Ihren anderen Punkten, @robloo , habe ich der Spec eine DecimalPrecision-Präzisionseigenschaft hinzugefügt. Wenn Sie diesen Wert auf ="0" setzen, werden ganze Zahlen erreicht. Darüber hinaus kann das Festlegen von MinValue="0" dabei helfen, Zahlen nicht negativ zu halten (oder das ValueChanged-Ereignis ist eine weitere Möglichkeit, die Eingabe in absolute Werte zu erzwingen).

Hast du schon durch die Spec geschaut? Ich glaube, ich habe alle Eigenschaften aufgenommen, die erforderlich sind, um Ihre Erfahrungen vollständig zu ermöglichen (in Erwartung der Diskussion über die Validierung vs. Maskierung), aber ich bin gespannt, ob Sie der Meinung sind, dass ich etwas übersehen habe.

Maskierung, kann für Endbenutzer frustrierend und verwirrend sein, wenn sie keine Ausgabe von ihrer Tastatureingabe erfahren.

100% stimme zu, ja. Besser ist es, bei LosingFocus/EnterPressed zu validieren und den oldValue wiederherzustellen, wenn der eingegebene Wert nicht validiert wird, weshalb ein Signal, das bei LosingFocus/EnterPressed triggert und oldValue/newValue enthält, perfekt wäre.

@adrientetar , toller Punkt! Ist das eine Erfahrung, die Sie schaffen müssen? Wenn ja, werde ich sehen, was wir tun müssen, damit das ValueChanged-Ereignis sowohl den alten als auch den neuen Wert sendet.

@SavoySchuler Das möchte ich in der Tat in meiner App tun, ich würde dieses Verhalten selbst erstellen, es sei denn, das Steuerelement tut dies standardmäßig.

Die andere Sache, die ich möchte, ist Shift+↑/↓ für Inkremente von 10 und Strg+Shift+↑/↓ für Inkremente von 100, obwohl ich denke, dass Inkremente von 100 nicht immer sinnvoll sind.

Toller Punkt! Wir sollten sicherstellen, dass die Kontrolle von RangeBase abgeleitet wird, die
definiert sowohl SmallChange als auch LargeChange und wir verwenden beide bei
das allerwenigste.
Gibt es ein Beispiel für Standard-Tastaturkombinationen zum Aufrufen?
große Änderung auf RangeBase von UWP oder WinForms/ComCtl(?) NumericUpDown?

Am Mo, 3. Juni 2019 um 15:50 Uhr Adrien Tétar [email protected]
schrieb:

@SavoySchuler https://github.com/SavoySchuler Das ist etwas, was ich will
in meiner App in der Tat, ich würde dieses Verhalten selbst erstellen, es sei denn, die Steuerung tut dies
es standardmäßig.

Das andere, was ich möchte, ist Shift+↑/↓ für Inkremente von 10 und
Strg+Shift+↑/↓ für Inkremente von 100, obwohl ich Inkremente von 100 . rechne
nicht immer sinnvoll zu haben.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMFZBHJIE4DR2KN46TTPYWN3BA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBJ63LNWWB2
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AANMBMG4AWBK44VE4O4GYR3PYWN3BANCNFSM4HA4PBNA
.

Ich werde dies überprüfen, um dies zu überprüfen, aber ich bin ziemlich zuversichtlich, dass die Implementierung der Tastenkombinationen den Apps überlassen werden muss. Ich habe dies mit der Begründung für die Barrierefreiheit für # 21 versucht, und die Einführung neuer Tastenkombinationen ist ein riskantes Spiel, da fast alle von ihnen, die nicht von Windows beansprucht wurden, jetzt auf App-Ebene übernommen wurden (wobei TeachingTip in der Lage war, weiterzumachen) der F6-Zug) - aber ich werde prüfen, ob der Kontrollfokus hier eine Ausnahme zulässt!

Build 2018 war, als Validierungszustände für TextBox-Steuerelemente mit INotifyDataErrorInfo angekündigt wurden.
Dies wäre gut für die Verwendung mit Maskierung, um die aktuelle Textzeichenfolge zu validieren oder ungültig zu machen.

BEARBEITEN: Die Verwendung des Symbols und der dickeren unteren Rahmenfarbe soll die Erkennung in farbenblinden Situationen und bei Betrachtung in Schwarzweiß erleichtern. Der untere Fehlertext kann als Tooltip auf dem Symbol angezeigt werden, wenn der Platz knapp ist.

@mdtauk du bist phänomenal bei diesen Aufschlägen. Ich werde diese von unserem Designer ausführen, sie sehen für mich großartig aus!

@SavoySchuler Einfache Hochrechnung anhand des Beispiels auf der Build 2018

Und es gibt viele Beispiele zum Anschauen :)

Entschuldigung, das ist ein weiterer langer!

@SavoySchuler @adrientetar Ich sehe definitiv, woher du mit deinen folgenden Aussagen kommst. Ich werde nicht behaupten, dass dies in den allermeisten Fällen der beste Weg ist, um mit der Validierung umzugehen. Ich muss jedoch bedenken, dass es einige Sonderfälle gibt, in denen es sich offensichtlich nur um eine numerische Eingabe handelt, dass Sie dem Benutzer tatsächlich einen Gefallen tun, indem Sie ihm nicht erlauben, das falsche Zeichen mit dem dicken Finger zu berühren.

Maskierung, kann für Endbenutzer frustrierend und verwirrend sein, wenn sie keine Ausgabe von ihrer Tastatureingabe erfahren.

100% stimme zu, ja. Besser ist es, bei LosingFocus/EnterPressed zu validieren und den oldValue wiederherzustellen, wenn der eingegebene Wert nicht validiert wird, weshalb ein Signal, das bei LosingFocus/EnterPressed triggert und oldValue/newValue enthält, perfekt wäre.

Trotzdem habe ich beschlossen, in anderen Apps herumzustöbern, um zu sehen, wie es gehandhabt wird. Ich glaube nicht, dass jemand mehr über die Benutzerinteraktion recherchiert als Microsoft, also habe ich die Desktop-64-Bit-Version von Word und dann die UWP-Version von OneNote als Referenz aufgerufen. Es stimmt mehr oder weniger völlig überein, was Sie sagen. Ich kann jeden beliebigen Text in die Eingabefelder für Schriftgröße oder Formgröße eingeben, die eindeutig nur numerische Eingaben sind. Es validiert weitgehend den Fokusverlust und kehrt zur letzten gültigen Eingabe zurück.

| Titel | Bild | Kommentar |
|-----|-----|------------|
| Eingabe der UWP OneNote-Schriftgröße | | Jeder Wert kann über die Tastatur eingegeben werden, er wird automatisch validiert und bei Fokusverlust auf den letzten gültigen Wert zurückgesetzt |
| Eingabe der Desktop-Word-Schriftgröße | | Jeder Wert kann über die Tastatur eingegeben werden, er wird automatisch validiert, wenn der Fokus verloren geht und eine Fehlermeldung erscheint, wenn er ungültig ist. Beim Klicken auf [OK] wird auf den letzten gültigen Wert zurückgesetzt. |
| UWP OneNote 2D-Diagramm | | Jeder Wert kann über die Tastatur eingegeben werden. Ungültige Werte werden einfach ignoriert und die letzte gültige Eingabe in der Berechnung verwendet (gilt nicht bei Fokusverlust). Durch Drücken der Inkrement-Tasten +/- wird mit der letzten gültigen Eingabe inkrementiert. |
| Eingabe der Desktop-Wortformgröße | | Jeder Wert kann über die Tastatur eingegeben werden, er wird bei Fokusverlust automatisch validiert und bei Fokusverlust auf den letzten gültigen Wert zurückgesetzt. |

Ich schätze, ich habe mich gerade als falsch erwiesen, was bedeutet, dass ich dir zustimmen sollte!

Seitenkommentare:

• Wie bereits von jemand anderem erwähnt, sollte, wenn NumberBox den Tastaturfokus mit einer Touch-/virtuellen Tastatur hat, nur die numerische Tastatur angezeigt werden.
• Der Schritt nach unten links und Schritt nach oben rechts ist eine interessante Idee, um hier in Bezug auf das Styling zu diskutieren. Ich mag das!
  

• Ein neuer Benutzer gibt "zwei" in Ihre NumberBox ein.
• Die NumberBox löst das "ValueChanged"-Ereignis aus, das Ihnen die Möglichkeit gibt, nicht-numerische Eingaben auf "0" - oder anders - zurückzusetzen, wenn Sie dies wünschen. Wenn nichts unternommen wird, dann...
• Validierungsstarts in NumberBox leuchtet rot und zeigt dem Benutzer eine Fehlermeldung an, die ihn darüber informiert, dass nur numerische Eingaben erlaubt sind (dieser Teil wurde noch nicht vollständig rationalisiert, daher ist dies nur eine Hypothese).
  Gibt Ihnen diese Veranstaltungsreihe die Möglichkeit, die Erfahrung zu schaffen, die Sie benötigen?
  Was sind Ihre Gedanken hier? Ich würde mich freuen, wenn Sie Ideen haben, um diese Konzepte weiterzuentwickeln oder ein noch besseres Erlebnis zu schaffen, wenn wir können.

Ich verstehe vollkommen und stimme zu, dass das Hinzufügen einer Eingabevalidierung für die gesamte Plattform großartig ist. Sie haben jedoch im Wesentlichen nur die Eingabevalidierung ohne besondere Behandlung einer Zahl beschrieben. Was nützt also eine NumberBox, abgesehen von der automatischen Analyse eines Werts? Als Entwickler scheint eine TextBox mit Datenvalidierung mehr oder weniger gleich zu sein.

Ich denke, basierend auf meinen obigen Beispielen sollte die Out-of-Box-Funktionalität eine Mischung aus unseren beiden Ideen sein und ist das, was @adrientetar sagt. Der Benutzer kann einen beliebigen Wert eingeben, um das visuelle Feedback zu erhalten. Bei Verlustfokus wird der Wert jedoch automatisch validiert und die vorherige gültige Zahl (oder leer) wird automatisch wiederhergestellt. Dies erspart dem Entwickler die Mühe, sich selbst um die Eingabevalidierung kümmern zu müssen (wir wissen bereits, dass es eine Zahl in der NumberBox sein sollte). Es unterscheidet sich auch deutlich von einer reinen TextBox mit Datenvalidierung.

In Bezug auf Veranstaltungen möchte ich immer noch die Möglichkeit haben, Textänderungen abzubrechen, wenn dieser Anwendungsfall jemals klarer wird. Daher würde ich zusätzlich zu ValueChanged ein ValueChanging- und TextChanging-Ereignis empfehlen, damit Eingaben verglichen und abgebrochen werden können. Auf jeden Fall werden ein OldValue und NewValue benötigt, dies würde es uns zumindest ermöglichen, ihn bei Bedarf schnell wieder auf den OldValue zu ändern (obwohl UWP gerne abstürzt, wenn Sie den TextValue innerhalb eines Ereignisses ändern).

Bezüglich der Spezifikation: Gute Ideen mit DecimalPrecision, ich brauche jedoch mehr Zeit, um es durchzugehen und meine Kommentare hinzuzufügen. Es gibt viele kleine Nuancen, wie der Standardwert sollte String=Empty, Value=Null sein und wenn eine Inkrement-Taste +/- gedrückt wird, sollte der Wert stattdessen als Null anstatt als leer behandelt werden.

@mdtauk Es sollte nicht menschenmöglich sein, so schnell so gute Illustrationen zu machen :)

@robloo Danke für den
Es ist möglicherweise besser, bei den Aufwärts- und Abwärts-Symbolen zu bleiben, die in den aktuellen Spin-Buttons verwendet werden, um Verwechslungen mit den mathematischen Operationen zu vermeiden, die diese NumberBox ausführen kann.

iOS verwendet ein "Stepper"-Steuerelement, aber die Texteingabe ist separat und es gibt keine Inline-Berechnung.

Hier sind noch ein paar Designs, die ich gefunden habe

Das von mir gewählte Design scheint zum typischen Stil von Microsoft für dieses Steuerelement zu passen, aber ist es die beste oder die richtige Wahl. Mich würde interessieren, was andere dazu sagen.

BEARBEITEN: Einige Modelle alternativer Formen hinzugefügt (aber ich denke, die erste Idee ist am besten ...)

Ich stimme @mdtauk bezüglich des +/- Standorts zu, der erste ist der beste.

Es gibt ein XAML ControlTemplate, sodass der Benutzer (Entwickler) immer eine benutzerdefinierte Vorlage für die anderen beiden Layouts erstellen kann.

@robloo , Sie müssen sich nicht für detaillierte Antworten entschuldigen - besonders wenn sie ein paar gute Kicherer enthalten! Ausgezeichnete Idee mit der Touch- / virtuellen Tastatur - ich habe sie zum Abschnitt " Offene Fragen " der Spezifikation hinzugefügt, um von den Entwicklern / dem Team ausgeführt zu werden, und sicherzustellen, dass dabei kein inakzeptabler Leistungsaufwand entsteht. Ich denke, es wäre eine wunderbare Erleichterung für die Benutzer, wenn wir dies realisieren könnten.

Du bringst einen wichtigen Punkt zur Validierung an...

[1] Fragestunde: Wäre jemand gegen ein Validierungssystem, das inakzeptable Eingaben automatisch auf den vorherigen Wert zurücksetzt, während Ereignisse offengelegt werden, die es dem Entwickler ermöglichen würden, dieses Verhalten abzubrechen und stattdessen zu entscheiden, was zu tun/Fehleranzeigen oder -meldungen auszulösen?

Visuell sehe ich den Wert der disjunkten UpDownButtons in dem von Ihnen geposteten Beispiel. Ich glaube, @mdtauk und @sonnemaf sind auf dem richtigen Weg für die Standardeinstellung. Die Nähe der UpDownButtons ist ihre wahre Bequemlichkeit, egal ob man das Hin- und Her-Ergebnis verschiedener (aber nicht entfernter) Eingaben testet oder überschrittene Eingaben korrigiert. Entfernung, sofern sie nicht durch verbessertes Design oder verbesserte Funktionalität gerechtfertigt ist, scheint die Erfahrung vermeidbar zu machen und könnte auch die Klarheit bei Präfix/Suffix-Eigenschaften/Beschriftung beeinträchtigen, im Gegensatz zu einer eindeutigen Gruppierung als funktionaler Teil des Steuerelements, z. B.: $ [ - ] 192 [+]

Ich glaube, es gibt Szenarien für die disjunkten UpDownButtons. Ich denke an Aufgaben, die minimale und unidirektionale Eingaben erwarten, oder an Aufgaben, bei denen der Entwickler versucht, Eingabefehler schwerer zu machen. Ich glaube, das ist die Erfahrung, die verschiedene Anwendungen und Websites machen, wenn man zum Beispiel Kino- oder Konzertkarten kauft.

Meine Frage ist dann...

[2] Fragestunde: Sollten wir uns auf das Xaml ControlTemplate verlassen, um eine NumberBox mit disjunkten UpDownButtons zu erstellen (dh dies ist nicht üblich genug, um eine Unterstützung aus der Box zu rechtfertigen) oder sollten wir eine Eigenschaft einfügen, um festzulegen, ob die UpDownButtons zusammenhängend erscheinen? vs. disjunkt?

Ich werde @chigy für diese Frage

Ich sollte Überlegungen zur Barrierefreiheit für die UpDownButtons-Konversation einbeziehen: Die Nähe der UpDownButtons zueinander ermöglicht eine konzeptionelle Klarheit für Benutzer von Sprachausgabe-/Bildschirmleseprogrammen, während gleichzeitig die Navigationseffizienz für Tastaturnavigationsbenutzer erhalten bleibt, und es ist auch wichtig, dies nicht zu beeinträchtigen.

Wenn das Steuerelement nicht sehr breit ist, möchten Sie die Pfeile vertikal stapeln (ich weiß, dass ich das in meiner App brauche). Vielleicht könnte die Steuerung auf ihre eingestellte Breite reagieren? Das liegt an den fließenden Designrichtlinien, um es so zu spezifizieren, wenn sie es für sinnvoll halten.

Ich habe den Vorschlag mit unseren 3 offenen Fragen aktualisiert.

Danke @mdtauk für die Konzeptentwürfe!

@adrientetar Ich freue mich, dass Sie darauf hingewiesen haben. Klingt es so, als ob wir vielleicht eine Aufzählung für diese drei Konfigurationen brauchen?

Wenn das Steuerelement nicht sehr breit ist, möchten Sie die Pfeile vertikal stapeln (ich weiß, dass ich das in meiner App brauche). Vielleicht könnte die Steuerung auf ihre eingestellte Breite reagieren? Das liegt an den fließenden Designrichtlinien, um es so zu spezifizieren, wenn sie es für sinnvoll halten.

Es gab einen Vorschlag, den Steuerelementen zu ermöglichen, sich über den ihnen zur Verfügung stehenden Platz bewusst zu sein und darauf zu reagieren #677 Dies könnte verwendet werden, um die Spin-Buttons neu zu positionieren, wenn das Steuerelement schmaler wird. Vielleicht muss es eine Eigenschaft für NarrowWidth geben, die MinWidth ähnelt, oder vielleicht sogar eine NumberOfDigits, um als Hinweis zu dienen?

In Bezug auf das ausgegraute Textbeispiel - ich befürchte, dass dies den Benutzer ermutigen könnte, die angezeigten Werte einzugeben, anstatt als Hinweis auf das Endergebnis zu dienen. Es sieht genauso aus wie der PlaceholderText.

Wie wäre es mit der Verwendung von AccentColor und unterschiedlichen Schriftstärken, um sie hervorzuheben?

Toller Link, @mdtauk. Ich kann mir vorstellen, dass wir, wenn dies ein Weg ist, den wir gehen, dies mit einer Aufzählung mit Werten wie [Auto, Vertical, Horizontal, Detached] handhaben könnten, wobei Auto Horizontal bevorzugt, bis die Kompaktheit Vertikal vorgibt. Die Gedanken?

Außerdem habe ich das Bild aktualisiert! Ich denke, Sie haben Recht, dass ausgegrauter Text wie eine Eingabeaufforderung aussehen könnte, die, wenn sie befolgt wird, aufgrund des "=" zu einem Fehler führen würde.

Toller Link, @mdtauk. Ich kann mir vorstellen, dass wir, wenn dies ein Weg ist, den wir gehen, dies mit einer Aufzählung mit Werten wie [Auto, Vertical, Horizontal, Detached] handhaben könnten, wobei Auto Horizontal bevorzugt, bis die Kompaktheit Vertikal vorgibt. Die Gedanken?

Ein erster Gedanke ist, wird die Zahl im Container jemals groß genug sein, wo eine vertikale Ausrichtung erforderlich wäre? Die AutoCompleteBox verschiebt ihre Suchschaltfläche nicht, und Zeichenfolgen sind normalerweise länger als Zahlen.

Wenn es nur um den verfügbaren Speicherplatz geht, wäre ein automatisches Reaktionsverhalten (wenn diesem Vorschlag grünes Licht gegeben wurde) besser als eine Aufzählung. Den Entwicklern die Option im Steuerelement selbst zu geben, könnte zu einer weniger als konsistenten Verwendung des Steuerelements führen, aber ich denke, dies müsste etwas sein, das sich die Benutzerforschung meiner Meinung nach ansehen müsste, anstatt von uns allein auf github vorgeschrieben zu werden.

Die Entwickler haben immer die Möglichkeit der Re-Templating der Kontrolle , wenn sie ein anderes Layout für die Steuerung benötigt _really_, und es ist möglich , eine alternative Art enthält für dass , wenn Sie A wollen) sowohl zur Herstellung des standardmäßig auf die Mühe gehen und vertikaler Stil und Vorlagen - und B) stellen sicher, dass beide Stile richtig getestet wurden

@mdtauk Ich stimme zu, dass die Auf-/Ab-Symbole am besten sind. Ich wollte nur ein Beispiel mit den Pfeilen auf gegenüberliegenden Seiten der Eingabe zeigen. Wie bereits erwähnt, hilft dies sicherzustellen, dass der Benutzer nicht den falschen drückt, was in einer berührungsbasierten Benutzeroberfläche fast obligatorisch ist. Das Beispiel, das ich von OneNote gegeben habe, hatte zufällig +/- Symbole, aber ich hätte hinzufügen sollen, um die Symbole selbst zu ignorieren.

@SavoySchuler

[2] Fragestunde: Sollten wir uns auf das Xaml ControlTemplate verlassen, um eine NumberBox mit disjunkten UpDownButtons zu erstellen (dh dies ist nicht üblich genug, um eine Unterstützung aus der Box zu rechtfertigen) oder sollten wir eine Eigenschaft einfügen, um festzulegen, ob die UpDownButtons zusammenhängend erscheinen? vs. disjunkt?

Ich weiß, als UWP zum ersten Mal erstellt wurde, war es zuerst die Berührung - daher wären unzusammenhängende UpDownButtons wohl besser. Seitdem haben sich die Touch-First-Anforderungen gelockert und die Tasten nebeneinander sind sicherlich besser, wenn der Benutzer eine präzise Eingabemethode wie eine Maus hat (geringerer Weg). Da dies vom Anwendungsfall abhängig ist, stimme ich zu, dass eine Aufzählung nützlich ist, um anzugeben, wie die UpDownButtons angezeigt werden sollen.

Für Aufzählungswerte haben wir mehrere Zustände besprochen und verallgemeinernd können wir noch einige weitere hinzufügen:

• SeparatedHorizontal: Pfeil nach unten links, Pfeil nach oben rechts
• SeparatedVertical: Pfeil nach unten unten, Pfeil nach oben oben
• Links: Pfeile nach unten und nach oben nebeneinander auf der linken Seite (in horizontaler Ausrichtung)
• Rechts : Pfeile nach unten und nach oben rechts nebeneinander (in horizontaler Ausrichtung)
• Oben: Pfeile nach unten und oben nebeneinander oben (in vertikaler Ausrichtung)
• Unten : Pfeile nach unten und nach oben nebeneinander (in vertikaler Ausrichtung)

Wenn all dies zu komplex wird (was schnell passiert), freue ich mich, das Steuerelement für meine eigenen Anwendungsfälle in XAML neu zu erstellen.

Um noch eine andere Idee wegzuwerfen: Die Ausrichtung des Symbols für nicht verbundene UpDownButtons zu ändern, könnte ebenfalls sinnvoll sein [<] 123 [>] . Sie können diese zusätzliche Komplexität jedoch gerne ignorieren, da dies sicherlich pro App neu gestaltet werden könnte.

Außerdem wurden möglicherweise einige der Bedenken hinsichtlich der Barrierefreiheit bereits in OneNote angesprochen, aus dem ich das Beispiel gezogen habe.

@robloo Ich denke, die von Ihnen erwähnten linken und rechten Platzierungen sollten für die RtL- und LtR-Lokalisierung beibehalten werden - und nicht für diskrete Einstellungen.

Unten sind meine Meinungen

Ich bin mir auch nicht sicher, ob es semantisch sinnvoll ist, die Schaltflächen über dem Textfeld zu platzieren, geschweige denn, wenn Sie Ihren Finger auf die Schaltfläche legen, kann es schwierig sein, die Änderung der Zahl zu sehen.

Wenn jede Kombination in das Steuerelement integriert ist, führt dies zu einer chaotischen Verwendung, und all diese Dinge können bei dringendem Bedarf durch erneute Vorlagen erreicht werden.

Die Schaltflächen unter dem Textfeld können in räumlich begrenzten Bereichen und als Option auf dem Steuerelement selbst nützlich sein, da die Schaltflächen dadurch viel größer zum Tippen sind. Ob als Stil, der mit dem Steuerelement gebündelt ist, oder als Aufzählung zwischen:

NumberBox.SpinButtonOrientation = SpinButtonOrientation.Horizontal  
NumberBox.SpinButtonOrientation = SpinButtonOrientation.Vertical  

Nur eine kurze Frage möglicher Vorschlag: Theoretisch sollte man in einem Zahlenfeld nur Zahlen in ein Zahlenfeld eingeben können. Wie schwer wäre es, geschriebene Zahlen zu analysieren und in tatsächliche Zahlen für diese Felder zu übersetzen?

Zum Beispiel:
eins + zwei = 3
übersetzt
1 + 2 = 3

Oder
eins plus zwei gleich drei
wird übersetzt in
1 + 2 = 3

Es ist nur eine Idee.

Nur eine kurze Frage möglicher Vorschlag: Theoretisch sollte man in einem Zahlenfeld nur Zahlen in ein Zahlenfeld eingeben können. Wie schwer wäre es, geschriebene Zahlen zu analysieren und in tatsächliche Zahlen für diese Felder zu übersetzen?

Zum Beispiel:
eins + zwei = 3
übersetzt
1 + 2 = 3

Oder
eins plus zwei gleich drei
wird übersetzt in
1 + 2 = 3

Es ist nur eine Idee.

Das macht Sinn, für Englisch. Es wird zu einem Problem, wenn Sie diese Zeichenfolgen für andere Sprachen übersetzen und analysieren müssen. Und was ist mit einem polnischen Benutzer, der englische Wörter eintippt?

Bisher wurde nur die Form der Ziffern 0-9, Dezimalzahlen, Zahlentrennzeichen und mathematische Operatoren besprochen. Möglicherweise müssen jedoch andere Zahlensysteme berücksichtigt werden.

Das Hinzufügen von Sprachübersetzungen wird ein großer Aufwand sein, und es ist nicht klar, was der Nutzen sein wird.

Wenn nun diese Steuerung per Audioeingabe manipuliert werden soll, also die Nummer oder die Bedienung ausspricht, kann dies das Dolmetschen der gesprochenen Sprache beinhalten.

ERZÄHLER:
"Pixel NumberBox ohne Wert"

BENUTZER:
"Einhundertachtundzwanzig Pixel"

[ 128 _________ | Pixel ]

BENUTZER:
"Füge vierundsechzig Pixel hinzu"

[ 192 _________ | Pixel ]

ERZÄHLER:
"Einhundertzweiundneunzig Pixel"

[1] Fragestunde: Wäre jemand gegen ein Validierungssystem, das inakzeptable Eingaben automatisch auf den vorherigen Wert zurücksetzt, während Ereignisse offengelegt werden, die es dem Entwickler ermöglichen würden, dieses Verhalten abzubrechen und stattdessen zu entscheiden, was zu tun/Fehleranzeigen oder -meldungen auszulösen?

Wenn der eingegebene Text ungültig wird, warum sollte der Wert in einen älteren Value " aufrechtzuerhalten, etwas ist, für das die Kontrolle verantwortlich sein muss. Lassen Sie das Steuerelement einen einzelnen aktuellen Wert (oder Fehlerzustand) verarbeiten und lassen Sie die App über das Ereignis ValueChanged jede zusätzliche historische Verarbeitung nach Bedarf durchführen.

Für die erste Version denke ich, dass es in Ordnung ist, nur eine einzige Position der Auf/Ab-Tasten zu unterstützen, da sie bei Bedarf neu erstellt werden können.
Wenn die Möglichkeit, die Position der Auf-/Ab-Schaltflächen zu bestimmen, als notwendig erachtet wird, sollte jede hinzugefügte Aufzählung die Notwendigkeit beseitigen, die Eigenschaft UpDownButtonsEnabled und ein Aufzählungswert von Hidden könnte sein stattdessen hinzugefügt.
Beachten Sie auch, dass die eingebaute Unterstützung für die Manipulation der Position der Auf-/Ab-Schaltflächen die Komplexität für jeden erhöht, der die Vorlagen für etwas anderes als eine bereitgestellte Option anpassen muss.

@shaheedmalik und eine ausgezeichnete und intuitive Idee. Hast du dir die Spezifikation angesehen? Wir haben ein ValueChanged-Ereignis, das es Ihnen ermöglicht, diese Eingabe abzufangen und eingegebene Zahlen manuell in Zahlenwerte zu parsen - das wäre also eine mögliche Erfahrung, insbesondere wenn Sie eine bestimmte Sprache im Sinn haben. Was das Backen eines globalen Sprachparsers in der Standardversion V1 des Steuerelements betrifft - erhöhen , der eine erhebliche Begründung erfordern würde. Ein Vorteil der offenen Beschaffung dieser Kontrollen besteht darin, dass sie von der Community abgespalten werden können. In diesem Fall könnten Sie oder andere Community-Mitglieder sprachspezifische Varianten dieses Steuerelements erstellen. Ich glaube, dass dies der realistischste Weg wäre, um eine Sprachanalyseversion von NumberBox zu demokratisieren.

@mrlacey, haben Sie eine Chance haben zu bewerten @robloo ‚s vergleichende Analyse der NumberBox ähnliche Steuerung des gesamten Windows verwandt ? Das Verhalten beim Zurücksetzen dieser Felder auf die letzte gültige Nur-Zahlen-Eingabe hat tatsächlich einen systemweiten Präzedenzfall – was bedeutet, dass entweder das Steuerelement selbst oder die Entwicklerrichtlinien gedrückt werden, um sich an diesem Muster auszurichten. Meine Neigung wäre, dieses Steuerelement in Übereinstimmung mit der Standard-Windows-Erfahrung auszurichten und einen Weg für die notwendige Abweichung zu schaffen, anstatt ein Verhalten zu standardisieren, das vom Rest des Ökosystems abweicht, und Richtlinien festzulegen, um dieses Systemstandardverhalten zu erstellen, wie es letzteres schaffen würde einfach und effizient für den allgemeinen Fall. Ich ermutige zu Meinungsverschiedenheiten, also lassen Sie es mich bitte wissen, wenn Sie der Meinung sind, dass dies die Kontrolle unnötig kompliziert macht oder wir diesen Präzedenzfall vielleicht neu bewerten sollten.

| Titel | Bild | Kommentar |
|-----|-----|------------|
| Eingabe der UWP OneNote-Schriftgröße | | Jeder Wert kann über die Tastatur eingegeben werden, er wird automatisch validiert und bei Fokusverlust auf den letzten gültigen Wert zurückgesetzt |
| Eingabe der Desktop-Word-Schriftgröße | | Jeder Wert kann über die Tastatur eingegeben werden, er wird automatisch validiert, wenn der Fokus verloren geht und eine Fehlermeldung erscheint, wenn er ungültig ist. Beim Klicken auf [OK] wird auf den letzten gültigen Wert zurückgesetzt. |
| UWP OneNote 2D-Diagramm | | Jeder Wert kann über die Tastatur eingegeben werden. Ungültige Werte werden einfach ignoriert und die letzte gültige Eingabe in der Berechnung verwendet (gilt nicht bei Fokusverlust). Durch Drücken der Inkrement-Tasten +/- wird mit der letzten gültigen Eingabe inkrementiert. |
| Eingabe der Desktop-Wortformgröße | | Jeder Wert kann über die Tastatur eingegeben werden, er wird bei Fokusverlust automatisch validiert und bei Fokusverlust auf den letzten gültigen Wert zurückgesetzt. |

@mdtauk und notieren Sie Ihren Kommentar zu LTR- und RTL-Sprachen und der Seite des Steuerelements, auf der die UpDownButtons angezeigt werden. Ich werde dies von Lokalisierungsexperten durchführen, um sicherzustellen, dass dies eine Überlegung ist, die berücksichtigt werden muss.

@mrlacey Sie haben auch Recht, dass der boolesche

@adrientetar , Sie sind unser Hauptkunde für vertikale Schaltflächen. Haben Sie Bildschirmausschnitte oder Kontext, die mir helfen könnten, Ihre Platzbeschränkungen besser zu verstehen? @mdtauk hat mich mit dieser Antwort früher zum Nachdenken gebracht:

Ein erster Gedanke ist, wird die Zahl im Container jemals groß genug sein, wo eine vertikale Ausrichtung erforderlich wäre? Die AutoCompleteBox verschiebt ihre Suchschaltfläche nicht, und Zeichenfolgen sind normalerweise länger als Zahlen.

@SavoySchuler (in Bezug auf das Zurücksetzen auf den letzten guten Wert) Da die Spezifikation der NumberBox mehr Möglichkeiten für die Fehlerbehandlung und -berichterstattung bietet als die Steuerelemente in der Rezension von

Bedenken Sie:

1. NumberBox mit AllowsCalculations=True
2. manuell 1100 eingeben und zum nächsten Steuerelement wechseln
3. Erkenne, dass dies nicht das ist, was eintreten wollte
4. Gehen Sie zurück zur Steuerung und geben Sie "99 x 12" ein
5. Tab zum nächsten Steuerelement und der Wert zeigt wieder "1100" an ('x' ist nicht dasselbe wie '*', so dass es im Berechnungsschritt fehlschlägt. Oder betrachten Sie jede andere ungültige Berechnung, die fehlschlägt, wenn 'x' dies tun würde' t angezeigt werden, wenn sie gedrückt wird.)
6. Es zeigt jetzt einen Wert an, der nicht das Ergebnis der Berechnung ist, es wird keine Fehlermeldung angezeigt und die eingegebene Summe geht verloren, sodass keine Aufzeichnungen über das Geschehene vorhanden sind.

Was ich tun möchte, wenn in Schritt 5 zum nächsten Steuerelement getippt wird, ist

• "99 x 12" bleibt der Text Wert
• Fehlerstatus wird angezeigt.
• ValueChanged Ereignis ausgelöst und übergeben (Text='99 x 12', OldValue=1100, NewValue=Double.NaN)
• Der Benutzer kann dann sehen, dass etwas nicht stimmt
• Der Benutzer kann das Problem beheben, ohne die gesamte Summe erneut eingeben zu müssen.
• Code/App-Logik ist in der Lage, bei Bedarf etwas Passendes zu tun.

Wenn Sie bei der Eingabe automatisch zum letzten bekannten guten Wert zurückkehren möchten:

• Wann, außer wenn in einem Pflichtfeld kein Wert eingegeben wird, wird der Fehlerzustand angezeigt?
• Ist der Wert des ValueChanged Ereignisses nicht stark verringert, da es niemals einen ungültigen Status melden würde?

@SavoySchuler @mrlacey Betrachten Sie diese Beispiele in anderen Microsoft-Apps ...

Alle modalen Popups sollten ausgeschlossen werden. Stattdessen sollte dies durch einen Validierungsstatus auf dem Steuerelement selbst behandelt werden.

BILD

Wenn ein Wert ungültig ist, sollte der Inhalt möglicherweise in diesem ungültigen Zustand verbleiben, jedoch nur, während das Steuerelement im Fokus ist. Wenn der Fokus verloren geht, wird der Textfeldwert zurückgesetzt, aber der Validierungshinweis zeigt an, was der Benutzer eingegeben hat?

InputScope: Zahl oder FormelZahl?

Wie bereits erwähnt (in einem PR-Kommentar), enthält FormulaNumber kein 'Leerzeichen', das alle Berechnungsbeispiele hier und in der Spezifikation enthalten. FormulaNumber enthält auch mathematische Symbole, die von diesem Steuerelement nicht unterstützt werden

Ich stimme für "Zahl"

Nummer

Formelnummer

@SavoySchuler Ich meine, ich erstellen ). Ich denke, ich werde die Pfeile einfach ganz deaktivieren, das Ziehen mit der Maus reicht aus, denke ich. Wenn das Ziehen mit der Maus geplant ist, sollte die Wertänderung dann möglicherweise bei jeder Änderung ausgelöst werden, da der Benutzer in diesem Fall eine Vorschau auf eine Reihe möglicher Änderungen anzeigen möchte. Die Seitenleiste:

Übrigens wird der Inhalt der TextBox nicht vertikal zentriert, und dies ist mit VerticalContentAlignment="Center".

Es sieht ähnlich aus wie die Eigenschaftsseitenleiste, die Paint 3D verwendet (die auch einen eigenen Steuerelementstil mit dünneren, helleren Rändern verwendet und wie eine Suffix-Eigenschaft aussieht).

Wenn das Ziehen nicht implementiert werden soll, können Sie immer das tun, was Paint 3D getan hat, und einen Schieberegler an die NumberBox gebunden haben.

Es ähnelt auch dem, was Adobe tut, indem es einen Dropdown-Schieberegler auf seinem Steuerelement hat.

@adrientetar Du scheinst dort deine eigene Version einer NumberBox zu erstellen. Der Text in Ihrer TextBox hätte eine Grundlinienausrichtung, da die Schriftarten Unterlängen haben, die berücksichtigt werden müssen.

Für die NumberBox könnte es einen Grund geben, visuell zentrierte Zeichen zu haben, aber dann würden diese NumberBoxes nicht ausgerichtet, wenn sie neben einer Standard-TextBox oder einem von TextBox abgeleiteten Steuerelement wie ComboBoxen platziert würden.

Beim Erstellen der Standardvorlagen und Windows.UI.Xaml.Documents.Typography berücksichtigen ...

• Typography.CaseSensitiveForms
• Typography.NumeralAlignment + Typography.NumeralStyle (tabellarisch gegenüber proportional vorzuziehen)

@mrlacey , Sie machen ein gültiges Argument. Basierend auf der Antwort von @adrientetar , was ist mit dem folgenden Szenario:

Wert-/Textänderungsereignisse werden bei _jeder_ Änderung ausgelöst (für Fälle, in denen Drag-/Scroll-Benutzer den Bereich testen) und daher kann die Validierung kontinuierlich erfolgen, wobei die Fehlermeldung und der Indikator angezeigt werden, bis "Enter" gedrückt wird / der Fokus verloren geht, in In diesem Fall tritt die Überschreibung des Validierungswerts in Kraft und überschreibt den letzten gültigen Wert (es sei denn, dieses Verhalten ist durch die entsprechende Eigenschaft deaktiviert).

Ich werde heute Nachmittag mit dem Team plaudern, um zu überprüfen, ob diese ständige Ereignisauslösung/-validierung eine realistische Idee ist - andernfalls können wir die Reichweitenbegrenzung auf andere Weise einbauen.

@mdtauk , aber ich glaube, Sie haben mit Ihren Behauptungen zur visuellen Darstellung der Validierung @LucasHaines , kannst du mich überprüfen?

@jevansaks , können Sie die folgende Erwägung von InputScope abwägen?

Wie bereits erwähnt (in einem PR-Kommentar), enthält FormulaNumber kein 'Leerzeichen', das alle Berechnungsbeispiele hier und in der Spezifikation enthalten. FormulaNumber enthält auch mathematische Symbole, die von diesem Steuerelement nicht unterstützt werden

Ich stimme für "Zahl"

Nummer

Formelnummer

@SavoySchuler re this

Wert-/Textänderungsereignisse werden bei jeder Änderung ausgelöst (für Fälle, in denen Drag-/Scroll-Benutzer den Bereich testen) und daher kann die Validierung kontinuierlich erfolgen, wobei die Fehlermeldung und der Indikator angezeigt werden, bis "Enter" gedrückt wird / der Fokus verloren geht, in In diesem Fall tritt die Überschreibung des Validierungswerts in Kraft und überschreibt den letzten gültigen Wert (es sei denn, dieses Verhalten ist durch die entsprechende Eigenschaft deaktiviert).

ValueChanged Ereignis sollte nur ausgelöst , wenn die tatsächlichen Value ändert, nicht auf jeder Zeit die Text Änderungen.

es sei denn, dieses Verhalten ist durch seine jeweilige Eigenschaft deaktiviert

Was ist diese neue Immobilie?

Ich weiß nicht, wie häufigere Ereignisse das Problem von falschen Werten und dem Verlust von Fehlerzuständen beheben, wenn zu einem letzten bekannten guten Wert zurückgekehrt wird.
Ich habe das Gefühl, dass hier einige Experimente erforderlich sind, um zu verstehen, wie dies tatsächlich aussehen wird. (Wenn ich nur die Zeit finden könnte...)

In einem verwandten Hinweis.

Ich gehe davon aus, dass das vorhandene TextChanged Ereignis, das von TextBox geerbt wurde, für den Verbraucher nicht geändert wird. Aber was ist mit dem TextChanging Event? Wird dies der Ort sein, an dem eine neue steuerungsspezifische Verarbeitung erfolgt? Wird der Verbraucher des Steuerelements auch dieses Ereignis verarbeiten können?

Zugegeben - eine Erkundung wert, aber am besten vermeidbar. Ich habe den Abschnitt zur Validierung überarbeitet und eine IsInvalidInputOverwrite-Eigenschaft hinzugefügt, die standardmäßig deaktiviert ist. Was denken alle über folgendes:

• Eingaben, die nicht numerisch sind oder die Min-/Max-Werte überschreiten, lösen eine Warnung zur Eingabevalidierung aus .
• Der Entwickler kann die ValueChanged- oder TextChanged-Ereignisse (die die geänderte Eigenschaft und die zu aktualisierende Eigenschaft verfügbar machen) abfangen und ungültige Eingaben manuell bearbeiten, bevor eine Warnung zur Eingabevalidierung angezeigt wird.
• Durch Aktivieren der Eigenschaft IsInvalidInputOverwrite werden ungültige Eingaben in den letzten gültigen Zustand zurückgesetzt, ohne dass eine Warnung zur Eingabevalidierung angezeigt wird. Wenn zB IsInvalidInputOverwrite aktiviert ist, StepSize=0.2, MaxValue=3.0 und der Wert 2.9 erhöht wird, wird 3.1 als ungültig registriert und zurück auf 2.9 überschrieben.

Vieles davon könnte mit der Frage zusammengefasst werden, ob die Validierung während der Eingabe oder danach erfolgen sollte. Ich lehne mich aus Gründen der Leistung und weil die Erfahrung, Validierungen während der Eingabe zu erhalten, erschütternd und schwer zugänglich sein kann - was dazu führt, dass die oben genannte Implementierung meine derzeit bevorzugte Implementierung ist.

FWIW, Adobe Photoshop und Illustrator kehren zum vorherigen Wert zurück, wenn Sie versuchen, einen ungültigen Wert einzugeben. Dies hat das Berechnungsverhalten, aber das Maßeinheitssuffix ist Teil des Textes, was an sich Validierungsprobleme verursachen kann :)

Wollte eine Idee einbringen, über die ich mich selbst in Konflikt gebracht habe - ich kann mich an viele frühere Erfahrungen erinnern, in denen ich ein Sortiernummernfeld mit Inkrement- / Dekrementierungsfunktion hatte. und umgekehrt. Ich wollte sehen, ob hier so etwas wie eine _ValuesWrap_-Eigenschaft Sinn macht.

Dies ist offensichtlich nicht in jedem Fall sinnvoll, aber in Fällen mit begrenztem Zahlenbereich war es in der Vergangenheit für mich intuitiv, Zahlenumbrüche in Fällen wie bei der Eingabe von Age oder DateOfBirth oder für andere Fälle mit kleinem Bereich anzunehmen. Auf der anderen Seite tritt dies manchmal nur auf, weil in diesen Fällen eine Multiple-Choice-Auswahlbox verwendet wird und diese normalerweise Werte umbrechen, anstatt zu stoppen. Wollte nur prüfen, ob es eine Rechtfertigung oder Notwendigkeit dafür gibt - es könnte natürlich wahrscheinlich auch auf Entwicklerseite durch jedes onValueChanged-Ereignis mit zusätzlichem Aufwand implementiert werden.

cc @SavoySchuler

Tolle Idee, @KevinTXY. Wenn einer unserer Entwickler hier so etwas benötigt, können wir versuchen, es hinzuzufügen!

Fragestunde: Hat jemand echte Anwendungsszenarien, die eine Unterstützung für hexadezimale oder binäre Anwendungen rechtfertigen? Max/Min-Werte umbrechen?

Ich wollte sehen, ob hier so etwas wie eine ValuesWrap-Eigenschaft Sinn macht.

Ja, wenn Sie eine Winkeleigenschaft haben, möchten Sie 359 → 0 gehen, im Grunde Mod 360. Das Lustige ist, dass ich das Steuerelement immer noch unterklassen musste (war in Qt), weil MaxValue nur inklusiv sein konnte, also könnte ich 359 oder angeben 360, aber ich wollte wirklich 359,99 schreiben können, aber nicht 360 (dh ich wollte <, nicht ≤).

Die QSpinBox hat zu diesem Zweck eine Wrapping-Eigenschaft https://doc.qt.io/qt-5/qabstractspinbox.html#wrapping -prop

@SavoySchuler In Bezug auf Hexadezimal vermute ich, dass ein Hex-Editor dies wünschen könnte, aber es scheint ein wirklich Nischenanwendungsfall zu sein. In Qt verfügt das Steuerelement über eine Methode, die den Textfeldstring in den numerischen Wert (entweder int oder double) umwandelt, der überschrieben werden kann.

Wenn zB IsInvalidInputOverwrite aktiviert ist, StepSize=0.2, MaxValue=3.0 und der Wert 2.9 erhöht wird, wird 3.1 als ungültig registriert und zurück auf 2.9 überschrieben.

Sie könnten in diesem Fall wahrscheinlich auf MaxValue klemmen.

@SavoySchler @xyzzer @mrlacey Ich habe auf Twitter gesehen, dass in 20H1 etwas kommt, das eine vorausschauende Texteingabe bietet.

Dies kann die besprochene Vorschau-Vervollständigungsfunktion beeinträchtigen und muss möglicherweise im NumberBox-Steuerelement unterdrückt werden. Bei Win32- und XAML-Steuerelementen scheint es ...

https://twitter.com/thebookisclosed/status/1137012461616488448?s=20

Ich würde davon ausgehen, dass der Umgang mit Hex oder Binär noch spezialisiertere Szenarien sind als der Umgang mit "Zeichenfolgen, die wie Zahlen aussehen" wie Telefonnummern und Postleitzahlen. (und bringen ihre eigene Komplexität mit)
Daher denke ich, dass sie außerhalb des Geltungsbereichs des NumberBox-Steuerelements liegen sollten.

Apropos Vorschau-Berechnungsfunktion, falls sie übersehen wurde, würde ich vorschlagen, einem Benutzer die Wahl zu geben, sie ein- oder auszuschalten. Also vielleicht eine Eigenschaft hinzufügen wie

public bool ShowPreviewResult { get; set; }

Warum sollten Sie das Vorschauergebnis anzeigen? 🤔 Nicht, dass der Benutzer seine Formel je nach Ergebnis ändern würde, wenn er das gewünschte Ergebnis kennt, wird er es einfach sofort eingeben

Warum sollten Sie das Vorschauergebnis anzeigen? 🤔 Nicht wie der Benutzer würde, was er je nach Ergebnis eintippt, wenn er weiß, was er will, wird er es einfach sofort eingeben

Eine der Funktionen des Steuerelements besteht darin, in eine Berechnung eingeben zu können, z. B. 32 * 4, die als 128 aufgelöst würde - die Vorschaufunktion würde das Ergebnis anzeigen, wenn das Steuerelement den Fokus verliert oder die Eingabetaste gedrückt wird.

@adrientetar Die Vorschau ist ab

Danke nochmal für das Feedback an alle! Es sieht so aus, als ob es derzeit keine dringende Notwendigkeit oder kein berechtigtes Interesse an einer binären oder hexadezimalen Unterstützung gibt. Es kann auch nach Bedarf untergeordnet, als neues Steuerelement vorgeschlagen oder für V2 vorgeschlagen werden.

@SavoySchuler in Bezug auf "Hat jemand echte App-Szenarien, die eine Unterstützung für Hexadezimal- oder Binärdateien rechtfertigen?" Ein Beispiel ist das eigene ColorPicker-Steuerelement von WinUI. Es enthält ein hexadezimales Eingabefeld. Es enthält auch eine Reihe anderer Textfelder für die Zahleneingabe. Es könnte sich lohnen, die Möglichkeit zu prüfen, ColorPicker zu aktualisieren, um das neue NumberBox-Steuerelement zur Überprüfung des neuen Steuerelements zu verwenden. Wenn NumberBox die aktuelle Implementierung von ColorPicker vereinfachen kann, wäre das ein Gewinn.

Falls das dünnere Rahmendesign für die Textfelder nicht an

@kmahone - zugestimmt. Wie Sie heute Morgen beim Wasserkühler erwähnt haben, könnte die Möglichkeit, viel Code aus ColorPicker zu entfernen, indem die Instanzen von TextBox + lokale Validierungslogik durch NumberBox ersetzt werden, ein eigener Gewinn sein.

@mdtauk - habe ich dir zu oft gesagt, dass deine Mock-ups unglaublich aussehen? Ich werde diese in Kürze in die Spezifikation aufnehmen!

@SavoySchuler Wenn sich das Windows Design-Team entscheiden würde, sich auf die Seite des Fabric Web-Teams zu stellen und von 2 epx dicken Rändern zu 1 epx-Rändern überzugehen - ich denke, das würde am besten mit der NumberBox funktionieren - aber praktisch kann das Windows Design-Team graben ihre Fersen ein und behalten die dickeren Ränder.

Klar, @mdtauk! Ich hoffe, die funktionalen Anforderungen für @KevinTXY hier in festlegen zu können, und werde dann zu diesem Design-Konvergenz-Gespräch mit @chigy übergehen (der bei #524 einen tollen Job gemacht hat)!

Vielen Dank für die Diskussion an alle, ich freue mich sehr, diesen Sommer als Praktikant an diesem Feature zu arbeiten!

Wenn es für jemanden relevant ist, habe ich einen C#-Prototyp des Steuerelements im folgenden Repository gestartet.
https://github.com/KevinTXY/NumberBox

Dies ist im Wesentlichen das erste Mal, dass ich C#/UWP lerne, daher wird es langsam vorankommen und wenn sich jemand damit befasst, freue ich mich über Feedback, was besser gemacht werden könnte!

Folgende Features sind grob umgesetzt:

• Numerische Eingabe Validierung (folgt noch nicht den Spezifikationen des
• Wertspeicherung/Bindung
• Null trimmen
• Vollständige Unterstützung für Rechner/Formeleingabe

Arbeite derzeit an Spinner-Buttons und Test-Apps sowie an der Min/Max-Validierung.

Danke schön!

Timeline-Update!

Ich habe mehrere Updates, Vorschläge und Feedback in die Spezifikation integriert, die ich heute (Donnerstag) mit dem WinUI-Team validieren werde. Ich hoffe, damit die API und die Verhaltenskomponenten für V1 mehr oder weniger fertigzustellen.

Jetzt werde ich zu Eingaben und Zugänglichkeit, Daten & Intelligenz und visuellen Komponenten wechseln.

Der letzte Schritt ist das Aufräumen der Dokumentation und das Erstellen von Richtlinien.

Ich denke, die unzusammenhängende und zusammenhängende Option ist eine sehr Nische ohne einen Anwendungsfall, den die Erstanbieter-Apps / Shell-Benutzeroberfläche von Microsoft entweder in WPF oder Win32 ausführen musste.

Wenn Sie es einschließen möchten, wäre es mir lieber, wenn es ein eingeschlossener Stil ist, den Sie auf das Steuerelement anwenden können, als eine Option. Wie würden neu erstellte NumberBox-Steuerelemente mit dieser Eigenschaft in ihren neuen Vorlagen umgehen?

Wenn der Konsens darin besteht, dass dieser Modus eingeschlossen werden sollte, könnte ich vorschlagen, dass er als Teil von SpinButtonPlacementMode ein Aufzählungswert wird. Ich bin mir nicht sicher, wie diese Option heißen würde. _Straddled_ ist vielleicht nicht professionell genug, lol, und ich bin mir nicht sicher, ob _Bookended_ besser ist.

Ich habe mir gerade den neuesten Canary-Build von Edge angesehen und das Design eines <input type="number"/> das einem NumberBox-Steuerelement am nächsten kommt.

Ich dachte nur, ich würde dieses Bild davon teilen.

@mdtauk - stimmt zu, SpinButtonPlacementMode wäre der richtige Ort, um alternative SpinButton-Platzierungsoptionen hinzuzufügen.

Zum Thema Namen ist @Felix-Dev zu Recht auf die Angabe aufgetaucht, dass SpinButton möglicherweise nicht der intuitivste oder bekannteste Name ist. SpinBox und UpDownButtons haben auch im Windows-Ökosystem Vorrang. Ich werde in Kürze näher darauf eingehen, aber bitte lassen Sie es mich wissen, wenn jemand etwas gegen eine dieser Optionen hat.

@mdtauk - Danke, dass du das

@SavoySchuler Ich verwende das Flag "Fluent Controls" aktiviert (einschließlich experimenteller Kontrollen)

Ich denke, die WinUI-Implementierung wäre ein durchdachteres Design, auf das Fabric Web und Edge achten sollten, aber die Ausrichtung ist eine gute Sache.

w3schools Eingabetyp Nummer

Auch dieser Schieberegler ist in der Nähe, aber nicht ganz identisch mit dem, was WinUI beabsichtigt (umrissener Kreisdaumen im Vergleich zu einem gefüllten Kreisdaumen).

Ich bin mir immer noch nicht sicher, wie ich die Lokalisierungsfunktionen einstellen kann. In den USA wird der Punkt als Dezimaltrennzeichen verwendet. In den Niederlanden (wo ich lebe) verwenden wir das Komma. Das Gruppierungstrennzeichen in den USA ist das Komma, aber in den Niederlanden ist es der Punkt.

Beispiel:

Soll ich die Language-Eigenschaft des Framework-Elements verwenden, um das Trennzeichen für Ziffer und Gruppierung anzugeben?

<StackPanel Spacing="12" Padding="12" Width="200">
    <NumberBox Header="Dollar (US)"
               Value="1234.56"
               FractionDigits="2"
               Language="en-US" />
    <NumberBox Header="Euro (Netherlands)"
               Value="2345.67"
               FractionDigits="2"
               Language="nl-NL"/>
</StackPanel>

Ich habe mir gerade den neuesten Canary-Build von Edge angesehen und das Design eines <input type="number"/> das einem NumberBox-Steuerelement am nächsten kommt.

Ich dachte nur, ich würde dieses Bild davon teilen.

@mdtauk , @SavoySchuler ,
Ich weiß nicht, woher diese Kontrolle kam. Laut meinem Kontakt im Edge-Team sind hier die Steuerelemente, die sie verwenden würden.

Schieberegler: https://explore.fastdna.net/components/slider/
Nummernfeld: https://explore.fastdna.net/components/number-field/

Ich bin mir nicht sicher, ob sie das Visual aktualisieren werden, und die endgültige Ausgabe sieht möglicherweise nicht genau so aus (ich nehme an, aber das ist meine wilde Vermutung).

@chigy Dieses Bild stammte aus dem aktuellen Canary-Build von Edge, aber wie ich bereits bemerkt habe, handelt es sich um ein WIP und um ein optionales Flag, das Sie aktivieren.

Ich denke, das erklärt, wofür dieses fastdna-Projekt gedacht ist, das ich in einer früheren Ausgabe erwähnt habe. 🙂

Soll ich die Language-Eigenschaft des Framework-Elements verwenden, um das Trennzeichen für Ziffer und Gruppierung anzugeben?

Diese Einstellungen stammen normalerweise aus der "Region", daher denke ich, dass wir die HomeGeographicRegion einfach an den DecimalFormatter-Konstruktor übergeben würden. Ich sehe keine anderen Stellen in der API, an denen wir Benutzern erlauben, die Region anzupassen (unsere Datums-/Uhrzeitformatierer scheinen nicht anpassbar zu sein?), aber die Auswahl ermöglicht die Anpassung der Formatzeichenfolge, also könnten wir es vielleicht zulassen das auch hier.

Ich sehe keine Möglichkeit, die Trennzeichen in der DecimalFormatter-API anzupassen, sodass diese aus den Spracheinstellungen abgerufen werden müssen. 😖

@jevansaks , danke für den Einblick! Ich werde @sonnemaf markieren , um sicherzustellen, dass er die Antwort sieht.

@jevansaks können Sie ein xaml-Beispiel zum DecimalFormatter für die NumberBox schreiben? Ich möchte es in XAML und nicht aus CodeBehind definieren. Die Eigenschaften DecimalSymbol und GroupingSymbol würden auch für mich funktionieren. Dies könnte jedoch zu einfach sein.

<StackPanel Spacing="12" Padding="12" Width="200">
    <NumberBox Header="Dollar (US)"
               Value="1234.56"
               FractionDigits="2"
               DecimalSymbol="."
               GroupingSymbol="," />
    <NumberBox Header="Euro (Netherlands)"
               Value="2345.67"
               FractionDigits="2"
               DecimalSymbol=","
               GroupingSymbol="." />
</StackPanel>

* Does anyone have any real app scenarios that justify needing support for hexadecimal or binary?

Entschuldigung für den Einbruch Ich habe dieses Thema gerade erst entdeckt, aber JA JA JA. Beides fehlt oft in numerischen Steuerelementen und ich und viele andere Entwickler auf github müssen dafür Workarounds erstellen. Insbesondere beim Rechnerbeispiel soll es nicht nur eine Zahl in Hex formatieren, sondern die Eingabe vollständig unterstützen.

An dieser Stelle möchte ich vorschlagen, dass Sie das Präfix von Hexadezimalzahlen anpassbar machen. Irgendwann ist es besser, überhaupt kein Präfix zu haben und an anderen Stellen ist es nicht immer 0x

Können Sie ein xaml-Beispiel zum DecimalFormatter für die NumberBox schreiben? Ich möchte es in XAML und nicht aus CodeBehind definieren. Die Eigenschaften DecimalSymbol und GroupingSymbol würden auch für mich funktionieren. Dies könnte jedoch zu einfach sein.

@sonnemaf Alles,

Es scheint jedoch richtig zu sein, die Region des Benutzers für diese Einstellungen zu respektieren - haben Sie ein Szenario, in dem Sie sie überschreiben müssen?

@sonnemaf

Hat jemand echte App-Szenarien, die eine Unterstützung für hexadezimal oder binär rechtfertigen?

Tut mir leid, dass ich das bemerkt habe und etwas spät geantwortet habe. Ich glaube, Hex/Binär-Unterstützung wäre sehr hilfreich. Ich bin stark in das .NET IoT- Projekt involviert und wir arbeiten hauptsächlich in der Hex/Binär-Welt, da wir Bits/Bytes manipulieren, die Register und Pins lesen/schreiben, um Dinge zu steuern.

Die Unterstützung von Hex/Binär wäre sehr dankbar. Danke

Ich brauche weder Hex noch Binär. Es wäre ein "nice to have", insbesondere binär.

Entwickler-Update

Hallo allerseits! Wir werden mit der NumberBox-Spezifikation zufrieden, und ich möchte nur darauf hinweisen, dass ich aktiv an der Steuerung arbeite , idealerweise wird sehr bald, möglicherweise heute Abend, eine erste PR mit den wichtigsten Funktionalitäten erstellt.

Einige Notizen:

• Wir haben uns entschieden, TextBox aufgrund einiger Designkomplikationen mit InputValidation nicht zu subclassen, NumberBox wird ein eigenes Steuerelement sein, das eine TextBox enthält.
  
  
  
  • Dies bedeutet, dass nicht alle TextBox-Eigenschaften verfügbar gemacht werden. Ich bin gespannt, ob einer davon wichtig ist, um NumberBox herauszubringen - ich könnte den Wunsch nach _Header, PlaceHolderText_ und vielleicht auch nach _Text_ sehen? Ich wollte dieses auf jeden Fall ein wenig öffnen, weil es für mich eine sehr einfache Änderung ist.
  
  
• Ich habe sehr kleine Änderungen an der Spezifikation vorgenommen, dies sind im Moment meistens nur Formulierungskorrekturen, aber es gibt noch offene Fragen wie die Wertvorschau, und während ich das Steuerelement schreibe, generiere ich einige meiner eigenen Designfragen. Dies ist immer noch ein guter Zeitpunkt, um Input hinzuzufügen 😄

@KevinTXY Es gab einen Vorschlag, der eher von der Slider-Basis als von der TextBox abgeleitet werden sollte - wurde dies ausgewählt?

• Platzhaltertext
• Header
• Text
• Validierungssymbol
• Bestätigungsnachricht
• AuswahlVordergrund
• AuswahlHintergrund
• Fokusstatus/Ressourcen usw.

Dies sind einige der TextBox-Dinge, die meiner Meinung nach erforderlich sind. Ich bin mir bei der Schaltfläche "Klartext" nicht sicher, die bei langen Textfolgen sinnvoller ist.

Wertvorschau Ich dachte, es wäre eine V2-Funktion, aber hat sich das geändert? Das Slider-Steuerelement verfügt über eine QuickInfo, die den Wert anzeigt, während der Daumen gleitet. Ich habe dies als eine Möglichkeit vorgeschlagen, dies zu handhaben, sowie die Validierungsnachricht zu verwenden, um dies zu handhaben, oder es inline anzuzeigen.

Inline hat ein Problem mit der Tatsache, dass Windows Insider-Builds mit der vorausschauenden Textvervollständigung experimentieren, die entweder als QuickInfo oder in den Textfeldern angezeigt wird. Welche Vorschaumethode auch immer ausgewählt ist, sie sollte nicht mit diesen kollidieren oder die Vorhersagefunktion für dieses Steuerelement deaktiviert sein.

@KevinTXY Es gab einen Vorschlag, der eher von der Slider-Basis als von der TextBox abgeleitet werden sollte - wurde dies ausgewählt?

NumberBox ist derzeit ein eigenes Steuerelement (erweitert Windows.UI.Xaml.Controls.Control), das eine TextBox in ihrem Markup enthält, anstatt TextBox zu erweitern. Slider klingt interessant, aber ich denke, es würde die Implementierung etwas hackig machen, es gibt auch viele Eigenschaften in diesen Steuerelementen, die wir in NumberBox nicht zugehörig fühlten. Ich bin kein PM, aber aus meiner Erfahrung bei der Entwicklung dieses Artikels glaube ich, dass dies ein guter Weg ist, um die Entwicklung zu vereinfachen und für die zukünftige Erweiterbarkeit.

Dies sind einige der TextBox-Dinge, die meiner Meinung nach erforderlich sind. Ich bin mir bei der Schaltfläche "Klartext" nicht sicher, die bei langen Textfolgen sinnvoller ist.

Das ist super - genau das habe ich gesucht! Ich stimme zu, dass all das einen Wert hat. Die Schaltfläche Alle löschen ist derzeit vorhanden, da sie eine Standardfunktion der TextBox ist - ich nehme an, sie hat einen Wert für große Einträge oder Benutzer von Touchscreens, obwohl ich noch nicht wirklich daran gedacht habe, sie zu deaktivieren. Ich werde auf jeden Fall zumindest versuchen, die drei genannten (Header, PlaceholderText, Text) in die Vorschau zu bekommen.

Was die Wertvorschau angeht, ist dort nichts abgeschlossen und nur in der Spezifikation als offene Frage enthalten. Ich nehme an, die einfachste vorübergehende Lösung wäre, den Vorschauwert einfach für Entwickler freizugeben , um sie nach @SavoySchuler & Co., Anrufe zu tätigen. Berechnungen werden wahrscheinlich sowieso zumindest für ein paar Tage nicht einmal den Schnitt in meine PR schaffen, während ich nach Mathe-Engines recherchiere, also ist es kein dringendes Detail. Ich schätze die durchgeführte Forschung, es gibt viele interessante Ideen hier!

@KevinTXY Idealerweise würde eine Zusammenarbeit mit dem Calculator-Team stattfinden, um eine grundlegende Berechnungs-Engine zu erstellen, die eingebettet werden könnte - sowie für die zukünftige Verwendung mit der CalculatorPicker- Idee, die neben diesem Steuerelement diskutiert wurde. (Ein Steuerelement mit einer Rechnerschaltfläche, das ein Flyout mit einem Standardrechner anzeigt)

Eigentlich klingt die Zusammenarbeit mit Calculator-Betreuern nach einer großartigen Idee. Sie könnten einen App-Dienst von Calculator bereitstellen, der die mathematischen Berechnungen durchführt, sodass Sie nicht einmal die WinUI-Binärdatei hochladen müssen – sprechen Sie einfach mit dem App-Dienst, wenn die App installiert ist und andernfalls – schlagen Sie einfach im Hintergrund fehl.

Was die Ableitung von Slider betrifft - ich habe tatsächlich

Ach ja, RangeBase, das war's.

Calculator hat erst vor kurzem daran gearbeitet, einen immer im Vordergrund stehenden CompactOverlay-Modus zu unterstützen - also ist es einfacher, ein kleineres Tastenfeld in ein Flyout zu bringen, das in der Größe dem CalendarFlyout ähnelt. (Wenn das CalculatorBox-Steuerelement zur Aufnahme genehmigt wird.

Ich bin mir nicht sicher, ob es sich um einen App-Dienst handelt (der WinUI-Updates halbabhängig von Updates des Calculator-Stores verknüpfen würde - oder ob es sich um eine Dienstbinärdatei handelt, die zu WinUI hinzugefügt und von der Calculator-Engine abgeleitet werden kann.

Update: Es existiert jetzt eine Code PR 🎆!

Ich verfolge einige Probleme dort, obwohl die meisten nicht mit dem Design zu tun haben.

Danke, @xyzzer und @mdtauk! Wir haben RangeBase ausgecheckt und es scheint genauso viel Gepäck zu tragen wie eine Unterklassifizierung von TextBox. Ab sofort bleiben wir dabei, eine TextBox in das Steuerelement aufzunehmen und nur die erforderlichen Eigenschaften und Eingabehilfen hinzuzufügen. Dies war immer noch eine lohnende Überlegung und hat dazu beigetragen, unser Gespräch über die Barrierefreiheit zu informieren, das jetzt stattfindet.

@mdtauk , danke für die Startliste! @KevinTXY hat damit begonnen, die von Ihnen aufgeführten APIs

Vorschau und Popup-Rechner, wie @KevinTXY erwähnt, in Gesprächen (obwohl hier keine v1-Garantie). Wir unterhalten uns aktiv mit Calculator über Ausrichtung und Leverageable Work. Ihr seid fantastisch! Vielen Dank, dass Sie die Innovation bei dieser Steuerung weiterhin vorantreiben. Es ist toll. @KevinTXY hat seinen Code PR oben gepostet. Ich werde alle verbleibenden losen Enden der Spezifikation zusammenbinden, kurz bevor ich zum Entwurf von Leitlinien und Dokumentation übergehe.

Benennung

Es gab so viele Kommentare, die mir die Spec entzogen hat, also fange ich gerade erst an, mich darum zu kümmern, wie sich die Dinge beruhigt haben. Zuerst fiel mir eine Benennung auf, die nicht wirklich der C#-Konvention entspricht – ja, ich weiß, dass diese Steuerelemente in C++ geschrieben sind, aber ich denke immer noch, dass sie mit anderen Namen auf der Plattform nicht vereinbar ist.

| Typ | Aktueller Name | Vorgeschlagener Name |
|-------|----------------|------------------|
| Boolean | AkzeptiertBerechnung | IsCalculationAccepted |
| Boolean | HyperDragEnabled | IsHyperDragEnabled |
| Boolean | HyperScrollEnabled | IsHyperScrollEnabled |

Schrittfrequenz

Und was ist StepFrequency? Dies ist in der Spezifikation nicht definiert und ich habe keine Erfahrung mit "XAML Toolkit's NumericUpDown". Je nachdem, was dies bewirkt, ist das Hinzufügen des Wortes Häufigkeit möglicherweise nicht sinnvoll. Es ist wahrscheinlich nur ein "Schritt"? Im Slider-Steuerelement ist TickFrequency sinnvoll, da die Ticks auf einem Modul des gesamten Max-Min-Bereichs angezeigt werden. Bei diesem Steuerelement denke ich jedoch, dass dies nur die minimale Schrittweite / Schrittgröße ist. Kann der Benutzer grundsätzlich einen Wert eingeben, der außerhalb des Schrittes liegt?

Zum Beispiel MinValue = 0, MaxValue = 6, StepFrequency = 2. Die Verwendung des Aufwärtspfeilwerts ist {2, 4, 6} angemessen. Kann der Benutzer 0,5 als gültigen Wert eingeben? Oder wird das je nach RoundingMode auf 0 oder 2 gerundet?

Min/MaxWert

Für die beiden folgenden Eigenschaften sollten diese meiner Meinung nach nur Minimum und Maximum sein, wie in anderen Steuerelementen (Slider, RangeBase). APIs sollten konsistent sein.
Doppelter MinWert;
Double MaxValue;

UpDown-Wiederholungstasten

Eine weitere Funktion, die meines Wissens nicht diskutiert wurde, ist, ob die Auf-/Ab-Tasten tatsächlich zu RepeatButtons gemacht werden sollen (ich denke, sie sollten es sein). Wenn es sich um Wiederholungsschaltflächen handelt, sollten die Delay/Interval-Eigenschaften wie das Slider-Steuerelement hinzugefügt werden: Slider.Interval Slider.Delay

Ziffern

Können Sie eine Beschreibung für das hinzufügen, was IntegerDigits und FractionDigits darstellen? Ich vermute, dass sie die Anzahl der Ziffern für jeden Teil der Nummer begrenzen. IntegerDigits = 2 bedeutet, dass der Maximalwert 99 betragen kann. FractionDigits = 3 bedeutet, dass der MaxValue 0,999 betragen kann. Wie überschreibt SignificantDigits diese beiden Eigenschaften?

Negative Null?

Warum wird diese Eigenschaft benötigt? Ist das eine Lokalisierungssache selbst? Ich habe noch nie "-0.0" oder "-0" gesehen. Es ist immer nur "0".
Boolean IsZeroSigned;

Lokalisierung

Ich benötige dieses Steuerelement unbedingt, um das Überschreiben der UI-Lokalisierung und des Zahlenformats zu unterstützen. Ich habe mehrere Verwendungen (Finanz-Apps), bei denen ich inländische und ausländische Beträge benötige, die unterschiedlich angezeigt werden sollen. Ich sehe das nirgendwo in der Spezifikation.

Die Konvertierung von Double in Text sollte über ValueConverter im Sinne von Slider.ThumbToolTipValueConverter anpassbar sein. Auf diese Weise könnte das komplexeste Teil an alle Bedürfnisse angepasst werden, wie in einigen realen Beispielen unten:

Beachten Sie, dass Dezimaltrennzeichen für Zahlen und Geld unterschiedlich sein können, ebenso wie die Bezeichnung der negativen Summen, daher ist der wahrscheinlich sicherste Ansatz für NumericBox ohne ValueConverter, im Integer-Modus zu arbeiten. Calculator könnte auch als ValueConverter implementiert werden, es besteht keine Notwendigkeit, die Steuerung mit dieser Arbeit zu überladen.

@eugenegff Sie haben eine wirklich gute Idee, die Konvertierung von Zahlen in Zeichenfolgen generisch zu gestalten. Auf diese Weise kann ich die Lokalisierung übernehmen, aber auch Entwicklern ermöglichen, alles andere zu tun, was sie möchten, z. B. Einheiten hinzuzufügen.

Die einzige Komplexität, die ich sehe, besteht darin, eine Culture/NumberFormatInfo in Bezug auf das Steuerelement beizubehalten. Ich denke, dies könnte ein Konverterparameter in XAML sein, der zu benutzerdefiniertem IValueConverter geht, aber es sollte wahrscheinlich eine sauberere Möglichkeit geben, dies im Steuerelement selbst zu handhaben.

Warum wird diese Eigenschaft benötigt? Ist das eine Lokalisierungssache selbst? Ich habe noch nie "-0.0" oder "-0" gesehen. Es ist immer nur "0".

Es ist eine Eigenschaft der DecimalFormatter- Klasse in Windows. Es ist seltsam? Wahrscheinlich. Es gibt einige Eigenschaften wie IsGrouped und Lokalisierungseigenschaften, die wir weggelassen haben, so dass diese vielleicht auch nicht notwendig ist. Gleichzeitig ist es auch bereits implementiert, so dass das Entfernen keinen anderen Zweck hätte, als 3 Zeilen Code aufzublähen. Interessanterweise gibt es Verwendungen und IEEE-Voraussetzungen, um Nullen mit Vorzeichen zu haben .

Ich benötige dieses Steuerelement unbedingt, um das Überschreiben der UI-Lokalisierung und des Zahlenformats zu unterstützen. Ich habe mehrere Verwendungen (Finanz-Apps), bei denen ich inländische und ausländische Beträge benötige, die unterschiedlich angezeigt werden sollen. Ich sehe das nirgendwo in der Spezifikation.

@SavoySchuler vielleicht sollten wir die Spracheinstellungen in der DecimalFormatter-Klasse unterstützen? Ich kenne das Verhalten allerdings nicht.

Ok, ich glaube, ich verstehe das grundlegende Problem hier. In der C++-Welt haben Sie Zugriff auf DecimalFormatter, aber in der C#-Welt (wenn ich WinUI verwende) würde ich normalerweise einen IFormatProvider (NumberFormatInfo aus einer angegebenen Kultur) verwenden. NumberFormatInfo hat bereits die meisten Eigenschaften (IsZeroSigned fehlt zufällig), also dachte ich, dass ich einfach Entwicklern erlauben kann, dies oder einen IFormatProvider anzugeben. Nun, da gibt es das Problem, C++ kann keinen IFormatProvider verwenden, da er aus der .net-Welt stammt.

Wie also unterstützt dieses Steuerelement die Lokalisierung in C# und C++ vollständig, wenn man bedenkt, dass es zwei verschiedene Möglichkeiten gibt, dies zu tun? Nun, wenn Microsoft keine clevere Lösung hat, fallen mir nur zwei Möglichkeiten ein:

1. Fügen Sie alle Eigenschaften für die Zahlenformatierung vollständig hinzu (effektive Neuimplementierung von NumberFormatInfo und DecimalFormatter). Wenn Sie nur IsZeroSigned, IntegerDigits, FractionalDigits usw. hinzufügen, wird dies nicht abgedeckt. NumberNegativePattern, NumberGroupSeparator, NumberGroupSizes usw. sind ebenfalls erforderlich.
2. Tun Sie, wie @eugenegff vorgeschlagen hat, und erlauben Sie den Entwicklern, die Formatierung mit einer Art Rückruf zu überschreiben. Ehrlich gesagt scheint dies der einfachste Ansatz zu sein.

Ich bin etwas besorgt darüber, wie sich die Lokalisierung in diesem Steuerelement entwickelt. Ich habe die Lokalisierung von Anfang an angesprochen (3. Kommentar zu diesem Thema!). Es muss eine Möglichkeit geben, das Zahlenformat vollständig anzupassen, wenn das Steuerelement in eine Zeichenfolge konvertiert wird. Ohne dies wird diese Kontrolle in der realen Welt ziemlich eingeschränkt sein.

Wie also unterstützt dieses Steuerelement die Lokalisierung in C# und C++ vollständig, wenn man bedenkt, dass es zwei verschiedene Möglichkeiten gibt, dies zu tun?

Wir hören dich! Es ist etwas, das wir offline untersucht haben, aber grundsätzlich macht .NET seine eigene Lokalisierung getrennt von der Plattform. Ich denke, ein Rückruf zum Überschreiben ist eine großartige Fluchtmöglichkeit, aber ich hoffe, dass Ihre Option 1 der Weg ist, den wir gehen können. Im Moment verfügen die WinRT-APIs zum Formatieren und Analysieren nicht über alle Anpassungsknöpfe, die wir benötigen. Wir ermitteln noch.

Ich habe nicht nachgesehen, ob dies bereits diskutiert wurde, wollte aber schnell fragen, ob jemand einen großen Bedarf oder, was noch wichtiger ist, einen Präzedenzfall für Funktionsunterstützung für Berechnungen sieht, was Folgendes bedeutet oder mehr:
cos(), sin(), tan(), asin(), acos(), atan(), sqrt(), log(), abs(), ceil(), floor(), degree equivalents of trig functions, hyperbolic functions, etc

Ich stelle mathematische Parser zusammen, um unseren Bedürfnissen zu entsprechen und Funktionen erschweren den Prozess der Konvertierung in RPN (das heißt, ich habe bereits eine Version, die diese mit einigen Fehlern unterstützt), also bin ich daran interessiert zu sehen, ob sich eine davon lohnt das Problem oder wenn es wie Blähungen aussieht. Ich persönlich denke nicht, dass es so gut passt, aber wenn es viele Präzedenzfälle gibt, ist es nicht allzu schwierig.

Ich denke, diese wären in den meisten Fällen nicht sehr auffindbar, und wenn jemand Unterstützung für kompliziertere Funktionen benötigt, ist es besser, das Parsing für ein Callback-Ereignis zu öffnen, damit Benutzer ihre eigene Parsing- oder Vorverarbeitungslogik implementieren können.

Wertvoller wäre es, die Eingabe von Text mit einem Operator zu ermöglichen. Wenn Sie also auf den Text klicken, wird standardmäßig alles ausgewählt und Sie können entweder einen neuen Wert eingeben, ohne zuerst die Löschtaste drücken zu müssen, um den vorherigen zu löschen, oder Geben Sie einfach etwas wie "*1.2" oder "x1.2" [Enter] und lassen Sie den aktuellen Wert mit 1,2 multiplizieren, auch wenn der eingegebene Text den eingegebenen Wert nicht mehr enthält. Das gleiche würde für "+2", "-5", "/3", "%120" usw. funktionieren.

Es wird in einigen professionellen Anwendungen verwendet.

Wir (BeLight Software, Live Home 3D Projekt) benötigen steckbaren ValueConverter zur Wert <=> Textkonvertierung, sonst wäre NumberBox für uns ungeeignet.

Ich denke, die Verwendung dieser Funktionen wäre ziemlich selten, ich habe eine Winkeleingabe in meiner App, aber es ist nur ein Gradwert. Die wichtigste Verwendung für mich ist, in der Lage zu sein, einen Wert zu einem bestehenden hinzuzufügen oder einen bestehenden durch eine Zahl zu dividieren, nur um Zeit zu sparen und diese Berechnung nicht im Kopf durchzuführen. (Übrigens, ich denke, das haben Adobe-Apps, die 4 arithmetischen Operatoren: https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12992463-support-math-operators-in-number -Felder)

Auch Funktionen wie cos () möchten Sie wahrscheinlich nicht dort, wo es keinen Sinn macht, es sei denn, Sie erstellen eine Art Excel-App.

Die wichtigste Verwendung für mich ist, einen Wert zu einem bestehenden hinzuzufügen oder einen bestehenden durch eine Zahl zu dividieren, nur um Zeit zu sparen und diese Berechnung nicht im Kopf zu machen

Okay super! Klingt ähnlich wie das, was @xyzzer vorgeschlagen hat. Ich werde mir ähnliche Implementierungen ansehen und sehen, ob es Raum gibt, dies auf eine Weise zu tun, die sich natürlich und intuitiv anfühlt.

Wir (BeLight Software, Live Home 3D Projekt) benötigen steckbaren ValueConverter zur Wert <=> Textkonvertierung, sonst wäre NumberBox für uns ungeeignet.

Ich habe mir das Slider-Beispiel angesehen, das Sie gegeben haben, und es klingt sehr vernünftig - ich konnte einen Wert in einem IValueConverter für NumBox sehen. Ich werde es demnächst prüfen und wir werden versuchen zu entscheiden, ob es angemessen in die Spezifikation passt. Allerdings noch keine Versprechungen!

@KevinTXY Ich vermute , dass die Funktionen hinzufügen , die Sie erwähnen oben würde die Tür zu mehr Probleme öffnen als der Wert , den sie bieten kann. Dies liegt daran, dass es die Eingabe einer größeren Anzahl von Zeichen (im Grunde jeder Buchstabe) in das Steuerelement ermöglichen würde. Dies wiederum würde es einfacher machen, versehentlich etwas Ungültiges einzugeben, und würde auch die Validierungs- und Parsing-Komplexität erhöhen.
Es würde auch die erste Zeile der Beschreibung am Anfang der Spezifikation "Zahlenfeld ist ein reines numerisches Textsteuerelement ..." unterbrechen.

Ich bin überrascht, dass es immer noch Fragen zur Lokalisierung gibt. Da das Steuerelement von FrameworkElement erben wird (muss?), hat es Zugriff auf die Language-Eigenschaft und unterstützt daher, wie jedes andere FrameworkElement, das direkte Festlegen des Gebietsschemas und ist nicht auf die UI-Einstellungen des Systemgebietsschemas angewiesen.
Das bedeutet, dass Dinge wie Dezimal- und Gruppierungszeichen pro Instanz festgelegt werden können.

Ich bin überrascht, dass es immer noch Fragen zur Lokalisierung gibt.

Das Problem ist, dass die Sprache nicht die Formatierung steuert, sondern die Regions-/Kultureinstellungen. Bei der Lokalisierung geht es darum, die UI-Strings so zu aktualisieren, dass sie in der richtigen Sprache angezeigt werden, während die Formatierung von Zahlen/Währung/Datum/Uhrzeit nach Region gesteuert wird. Weitere Informationen hier: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. Und um die Sache noch komplizierter zu machen, können Sie in Windows Ihre Gebietsschemaeinstellungen in der Benutzeroberfläche anpassen, indem Sie die Standardeinstellungen überschreiben – so können Sie sagen, dass Ihr Dezimaltrennzeichen ein beliebiges zufälliges Zeichen anstelle des Standardzeichens sein soll. Darüber hinaus ermöglicht .NET Apps, dies auch anzupassen, sodass Entwickler hier ein solches Maß an Anpassung erwarten.

Das Problem ist, dass die Sprache nicht die Formatierung steuert, sondern die Regions-/Kultureinstellungen. Bei der Lokalisierung geht es darum, die UI-Strings so zu aktualisieren, dass sie in der richtigen Sprache angezeigt werden, während die Formatierung von Zahlen/Währung/Datum/Uhrzeit nach Region gesteuert wird. Weitere Informationen hier: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. Und um die Sache noch komplizierter zu machen, können Sie in Windows Ihre Gebietsschemaeinstellungen in der Benutzeroberfläche anpassen, indem Sie die Standardeinstellungen überschreiben – so können Sie sagen, dass Ihr Dezimaltrennzeichen ein beliebiges zufälliges Zeichen anstelle des Standardzeichens sein soll. Darüber hinaus ermöglicht .NET Apps, dies auch anzupassen, sodass Entwickler hier ein solches Maß an Anpassung erwarten.

Language nimmt einen Wert an, der in CultureInfo Beachten Sie, dass eine Kultur in der nicht verwalteten Codeentwicklung als Gebietsschema bezeichnet wird. Dies enthält eine NumberFormat Eigenschaft vom Typ NumberFormatInfo , die Eigenschaften für Dezimalstellen, Gruppierungen, negative Vorzeichen und mehr enthält.

Wenn Sie eine bestimmte Formatierung oder andere Lokalisierungsmerkmale für ein Steuerelement erzwingen möchten, anstatt sich auf die Systemeinstellungen zu verlassen, können Sie dies tun, indem Sie Language angeben.

In der Beschreibung für die Eigenschaft heißt es eindeutig, dass sie "Lokalisierungs-/Globalisierungssprachinformationen festlegt, die für ein FrameworkElement gelten".

Oder vielleicht habe ich die Dokumente, auf die ich verweise, falsch verstanden, aber sie alle scheinen das zu unterstützen, was auf der Seite behandelt wird, auf die Sie verlinkt haben.
Vielleicht ist es ein Terminologieproblem, wenn C++ und C# unterschiedliche Begriffe verwenden.
Was ich weiß, ist, dass ich beim Festlegen der Sprache in XAML eine Kultur/ein Gebietsschema in jeder anderen App und mit jedem anderen Steuerelement erzwingen würde.

Die Fragen, die ich zur Lokalisierung gesehen habe, betrafen das Erzwingen bestimmter Zahlenformate oder Gruppen- und Dezimaltrennzeichen. Oder ist das eigentliche Problem, wie man diese steuert, ohne die Lokalisierung der textbasierten Eigenschaften (Header, PlaceholderText usw.) des Steuerelements zu beeinträchtigen?

Language nimmt einen Wert an, der in CultureInfo

Nicht in native/WinRT, wir erhalten nur einen BCP-47-Langs-String. Und das ist das Problem. In .NET bündeln Sie CultureInfo, das die Spracheinstellungen und die Formateinstellungen enthält. In WinRT ist es separat und es gibt kein Äquivalent zum CultureInfo-Objekt.

Ich habe gehört, dass die ICU-APIs möglicherweise das ermöglichen, wonach wir suchen, aber wir hatten noch keine Gelegenheit, dies zu untersuchen.

Ich denke, Microsoft wird in Betracht ziehen müssen, in den sauren Apfel zu beißen und einen Konvertierungsmechanismus zwischen .net-Kulturen/Lokalisierung (CultureInfo) und nativem/WinRT vollständig zu implementieren. Idealerweise denken Sie nicht über eine neue Vorgehensweise nach:

Ich denke, dass verwalteter Code in die meisten LOB-Apps geschrieben wird und dies von Anfang an richtig gemacht werden muss. WinRT benötigt die gleichen Lokalisierungsmechanismen/-techniken wie .net und die Konvertierungen müssen automatisch erfolgen.

Wäre das viel mehr Arbeit? Kurzfristig: ja, langfristig: nein. Würde dies wahrscheinlich die Veröffentlichung des NumberBox-Steuerelements verzögern? Wahrscheinlich, es sei denn, Rückrufe wurden kurzfristig eingesetzt.

Dies muss jedoch richtig gemacht werden, sonst gibt es woanders Probleme. Ich kann bereits einige ähnliche Probleme mit anderen Szenarien wie dem bearbeitbaren CalendarDatePicker usw. vorhersehen (#735)

@SavoySchuler @jevansaks @chigy @mrlacey @KevinTXY
Anscheinend arbeitet das FastDNA-Team auch an seiner Spinner-Steuerung für das Design des Eingabenummernfeldes und hat einen Vorschlag gemacht, der eine Überlegung wert sein könnte.

Sie fragten auch, warum wir Chevrons statt Arrows verwenden.

https://github.com/microsoft/fast-dna/issues/2202

Selbst wenn wir die Tasten nebeneinander halten und das gestapelte erweiterte Design als Hover haben, könnte dies eine Idee sein, wenn die Breite des Steuerelements zu schmal ist? Könnte es vielleicht einen Konsens über ein Layout geben, das in allen Microsoft-UI-Frameworks funktioniert?

@mdtauk , danke für den
Informieren Sie sich bei FastDNA-Mitarbeitern, ob dies das Design ist, das sie testen und die Benutzerfreundlichkeit validieren.

Zurück auf NumberBox

Okay Team,

Entschuldigung für die unerwartete Unterbrechung. Ich bin wieder bei NumberBox Vollgas und @teaP kommt als unser Feature-Entwickler zu mir! Wir streben immer noch Ende November für die Vorschau dieses Steuerelements an, bei der wir uns eine stabile Version mit WinUI 2.4 ansehen.

Im alten Workflow steckt viel Gepäck, daher werde ich alle offenen oder beantworteten Fragen aufbewahren und sie in eine neue Spezifikations-PR @teaP und ich unsere verbleibenden offenen Themen zu folgenden Themen

• Lokalisierung
• Design (insbesondere in Bezug auf Up/Down-Tasten)
• Hyperscroll/Hyperdrag

Beachten Sie, dass das Validierungsthema gelöst wurde. Mit @LucasHaines ' Eingabevalidierung Arbeit für WinUI geplant wird 3.0 und NumberBox Planung Veröffentlichung vor , dass haben wir NumberBox V1 unterstützte Validierung Modi reduziert:

enum NumberBoxBasicValidationMode
{
Behinderte,
InvalidInputOverwrite,
};

Mit WinUI 3.0 und den begleitenden Eingabevalidierungsarbeiten werden wir versuchen, diese Enumeration mit den ursprünglich geplanten Validierungsmodi IconMessage und TextBlockMessage in einer NumberBox V2 zu erweitern.

Ich werde jetzt alle unsere früheren Fortschritte zusammenfassen und je nach Relevanz Fragen stellen und Feedback einholen. Danke, dass Sie bei uns bleiben. 😄

Puh. Es kam mir nahe, dies selbst zu tun.

Haha, ich hätte gerne passiv weitergearbeitet, aber dieses Semester hat mich überrollt. Freut mich zu sehen, dass es fertig wird, ich behalte es im Auge!

Erster Commit von NumberBox jetzt live!

BITTE - Denken Sie daran , ist dies immer noch ein work-in-progress mit aktiver Problemverfolgung sowohl auf den Entwickler und PM - Seite der Dinge. Wenn Sie Fehler oder allgemeine lose Enden bei Funktionen sehen, die noch nicht unter den entsprechenden Links angegeben wurden, können Sie uns dies mitteilen. 😊

@SavoySchuler , werden Sie eine neue PR für die Spezifikation eröffnen? Haben Sie auch zur Kenntnis genommen, was ich in diesem Kommentar speziell zum Thema NaN-Display schreibe? Vielen Dank.

@SavoySchuler Einige Kommentare zum bisherigen Spec/NumberBox-Code. Hoffentlich können Kommentare dazu auch in der Spezifikation/Dokumentation landen. Insgesamt ist es großartig zu sehen, dass das zusammenkommt!

Schrittfrequenz

Das Wort "Frequenz" hier zu verwenden, passt einfach nicht zu mir. Im Slider-Steuerelement ist TickFrequency sinnvoll, da die Ticks auf einem Modul des gesamten Max-Min-Bereichs berechnet und angezeigt werden. In diesem Steuerelement ist es jedoch nur die Inkrement-/Schrittgröße. Es ist eher ein 'StepAmount' oder 'StepValue' -- besser noch 'Step' ähnlich wie 'Minimum' anstelle von 'MinimumValue'.

Kann der Benutzer auch einen Wert eingeben, der außerhalb des definierten Schritts liegt?
Zum Beispiel Minimum = 0, Maximum = 6, StepFrequency = 2. Die Verwendung des Aufwärtspfeilwerts ist {2, 4, 6} angemessen. Kann der Benutzer 0,5 als gültigen Wert eingeben? Oder wird das auf 0 oder 2 gerundet?

Rundung

Wie wird mathematisches Runden gehandhabt? Dies ist besonders wichtig, wenn Währungswerte mithilfe von Ausdrücken eingegeben werden. Wir müssen in der Lage sein, benutzerdefinierte Rundungen anzugeben oder bereitzustellen, nachdem ein Ausdruck berechnet wurde. HalfAwayFromZero ist das, was ich für den Anfang suche, aber andere Rundungsmodi sollten auch erlaubt sein.

Lokalisierung

Bitte bestätigen Sie, dass NumberBox jede INumberFormatter/ INumberFormatter2- Implementierung akzeptiert – und dies auch in Zukunft tun wird (so ist es im Code implementiert, ich möchte nur sicherstellen, dass die Spezifikation es auch aufruft). Dies sollte im Vergleich zur Verwendung eines vorhandenen CurrencyFormatter/DecimalFormatter eine vollständige Kontrolle über die Lokalisierung des Textes ermöglichen. Schön, dass wir dafür eine Lösung haben!

Textumbruch

Edit: Ich sollte beim nächsten Mal die ganze Spezifikation lesen.

Warum haben Sie eine neue 'IsWrapEnabled'-Eigenschaft erstellt? Liegt es daran, dass der Begriff 'Text' Ihrer Meinung nach nicht sehr gut auf eine NumberBox zutrifft?

Außerdem verstehe ich, dass Wrap und WrapWithOverflow vielleicht gleich implementiert sind, aber dann nur beide Enumerationswerte äquivalent sein lassen und die Funktionalität in der Dokumentation beschreiben.

Korrekter Umgang mit KeyboardAccelerators

Bitte stellen Sie sicher, dass dieses Steuerelement die Verwendung der Tastaturbeschleunigung besser unterstützt als die TextBox. Vielleicht kann das nicht getan werden, bis TextBox behoben ist, aber #1435 ist wirklich ein Problem für mich, das viele hässliche Umgehungen verursacht. Die TextBox verarbeitet ein 'Strg+V'-Einfügen selbst und dann wird ein beliebiger KeyboardAccelerator ausgelöst. Es gibt jedoch keine Möglichkeit innerhalb des KeyboardAccelerator zu wissen, dass die TextBox einfach ihr eigenes Ding gemacht hat.

Ein kurzer Gedanke. Sollte es einen Winkel -

°

Oder würde dieses Anhängsel in Zukunft mit meinem Suffix-Vorschlag für die TextBox #784 besser gehandhabt werden?

@mdtauk , Das Hinzufügen des

Zum Umschließen ist die IsWrapEnabled-Eigenschaft eigentlich dafür da... Ich muss das nächste Mal das Ende der Dokumentation lesen.

Fazit Ich denke, wir können mit der bestehenden API alles machen, was Sie wollen.

@mdtauk , Das Hinzufügen des

Zum Umschließen ist die IsWrapEnabled-Eigenschaft eigentlich dafür da... Ich muss das nächste Mal das Ende der Dokumentation lesen.

Fazit Ich denke, wir können mit der bestehenden API alles machen, was Sie wollen.

Ich weiß, dass Min, Max, Wrap damit umgehen, aber sind Grade üblich genug, um einen expliziten Winkelmodus für die Box zu haben? Und sollte das Symbol in der TextBox Text angezeigt werden, während der interne Wert nur die Zahl ist.

@teaP Wäre es mit Blick auf den neuen Compact SpinButtonMode möglich, den überlagerten Spin-Buttons eine Animation zum Ein- und Ausblenden hinzuzufügen?

Haben Sie auch daran gedacht, Acryl hinzuzufügen, um ComboBoxen und andere Formularfelder besser mit Flyout-Elementen abzugleichen?

Bearbeiten: Es würde dieses Problem der Sichtbarkeit im Dark Theme beheben. Soll die fokussierte Farbe der TextBox oder die aktuellen Themenfarben angepasst werden? Wie auch immer, Acryl löst dies.

@SavoySchuler , werden Sie eine neue PR für die Spezifikation eröffnen? Haben Sie auch zur Kenntnis genommen, was ich in diesem Kommentar speziell zum Thema NaN-Display schreibe? Vielen Dank.

@adrientetar auf Value auf NaN gesetzt (wie Sie es angefordert haben) und PlaceholderText wird angezeigt.

@SavoySchuler Einige Kommentare zum bisherigen Spec/NumberBox-Code. Hoffentlich können Kommentare dazu auch in der Spezifikation/Dokumentation landen. Insgesamt ist es großartig zu sehen, dass das zusammenkommt!

Schrittfrequenz

Das Wort "Frequenz" hier zu verwenden, passt einfach nicht zu mir. Im Slider-Steuerelement ist TickFrequency sinnvoll, da die Ticks auf einem Modul des gesamten Max-Min-Bereichs berechnet und angezeigt werden. In diesem Steuerelement ist es jedoch nur die Inkrement-/Schrittgröße. Es ist eher ein 'StepAmount' oder 'StepValue' -- besser noch 'Step' ähnlich wie 'Minimum' anstelle von 'MinimumValue'.

Ich habe dieses Feedback mit @MikeHillberg geteilt und wir sprechen jetzt darüber. Um neben all den anderen Eigenschaften hier selbstdokumentierend zu sein, ziehen wir etwas in der Art von "SpinButtonStep" in Betracht, sollte diese Argumentation Rechtfertigung genug sein, um abzuweichen. Ich lasse es dich wissen. Danke, dass du den Punkt ansprichst!

Kann der Benutzer auch einen Wert eingeben, der außerhalb des definierten Schritts liegt?
Zum Beispiel Minimum = 0, Maximum = 6, StepFrequency = 2. Die Verwendung des Aufwärtspfeilwerts ist {2, 4, 6} angemessen. Kann der Benutzer 0,5 als gültigen Wert eingeben? Oder wird das auf 0 oder 2 gerundet?

Der Benutzer kann jede beliebige numerische oder rechtlich formelhafte Eingabe eingeben. Im Abschnitt Formatierung finden Sie ein Beispiel zur Verwendung der NumberFormatter-Eigenschaft, um diese Eingabe dann in Ihre konfigurierte Formatierung zu erzwingen.

Der SpinButton erhöht oder verringert diesen Wert nur um die definierte SpinButton-Schrittgröße (API-Name steht jetzt aus). Stellen Sie also sicher, dass Sie Formatierung und Schrittgröße konfigurieren, die gut zusammenspielen.

Die verwendete Rundungsstrategie wird über Ihre Formatierung festgelegt . Um das DecimalFormatter-Beispiel zu erläutern, finden Sie hier ein Beispiel für eine Rundungseigenschaft, die Sie konfigurieren können.

Rundung

Wie wird mathematisches Runden gehandhabt? Dies ist besonders wichtig, wenn Währungswerte mithilfe von Ausdrücken eingegeben werden. Wir müssen in der Lage sein, benutzerdefinierte Rundungen anzugeben oder bereitzustellen, nachdem ein Ausdruck berechnet wurde. HalfAwayFromZero ist das, was ich für den Anfang suche, aber andere Rundungsmodi sollten auch erlaubt sein.

Das Runden wird durch die Formatierung gehandhabt. Hier ist ein Beispiel für eine Rundungseigenschaft, die für DecimalFormatter festgelegt werden kann. Ich werde den Richtlinien ein Beispiel hinzufügen, um dies klarer zu machen. Danke noch einmal. 😊

Lokalisierung

Bitte bestätigen Sie, dass NumberBox jede INumberFormatter/ INumberFormatter2- Implementierung akzeptiert – und dies auch in Zukunft tun wird (so ist es im Code implementiert, ich möchte nur sicherstellen, dass die Spezifikation es auch aufruft). Dies sollte im Vergleich zur Verwendung eines vorhandenen CurrencyFormatter/DecimalFormatter eine vollständige Kontrolle über die Lokalisierung des Textes ermöglichen. Schön, dass wir dafür eine Lösung haben!

Das ist die Absicht der aktuellen Implementierung. Was die Zukunftssicherheit angeht, wird NumberBox auch weiterhin eine Lösung für Lokalisierungs- und Formatierungsanforderungen haben. Für jetzt und auf absehbare Zeit haben wir das umgesetzt.

Textumbruch

Edit: Ich sollte beim nächsten Mal die ganze Spezifikation lesen.

~Warum haben Sie eine neue 'IsWrapEnabled'-Eigenschaft erstellt? Dies verstößt gegen die TextBox/XAML-Konvention der Verwendung von TextBlock.TextWrapping und der TextWrapping Enum. Liegt es daran, dass der Begriff 'Text' Ihrer Meinung nach nicht sehr gut auf eine NumberBox zutrifft?~

~Außerdem verstehe ich, dass Wrap und WrapWithOverflow vielleicht gleich implementiert sind, aber dann nur beide Enumerationswerte äquivalent sein lassen und die Funktionalität in der Dokumentation beschreiben. Das Erstellen einer neuen Eigenschaft hier bedeutet nur, dass wir neue Wertkonverter usw. benötigen. Ich denke, es gibt keinen Grund, eine bestehende Konvention zu brechen.~

Korrekter Umgang mit KeyboardAccelerators

Bitte stellen Sie sicher, dass dieses Steuerelement die Verwendung der Tastaturbeschleunigung besser unterstützt als die TextBox. Vielleicht kann das nicht getan werden, bis TextBox behoben ist, aber #1435 ist wirklich ein Problem für mich, das viele hässliche Umgehungen verursacht. Die TextBox verarbeitet ein 'Strg+V'-Einfügen selbst und dann wird ein beliebiger KeyboardAccelerator ausgelöst. Es gibt jedoch keine Möglichkeit innerhalb des KeyboardAccelerator zu wissen, dass die TextBox einfach ihr eigenes Ding gemacht hat.

NumberBox enthält eine TextBox und fügt darüber Eigenschaften und Konfigurationen hinzu. Ich werde @jevan markieren, da er möglicherweise ein umfassenderes Verständnis hat, aber meine Intuition ist, dass dies möglicherweise auf TextBox-Ebene behoben werden muss.

Alles in allem tolles Feedback @roloo! Ich schätze die Zeit, die Sie sich genommen haben, um sicherzustellen, dass wir mit V1 NumberBox so umfassend und vollständig wie möglich sind! Bitte lassen Sie mich wissen, wenn Sie weitere Fragen haben. 😊

@mdtauk

Ein kurzer Gedanke. Sollte es einen Winkel -

°

Oder würde dieses Anhängsel in Zukunft mit meinem Suffix-Vorschlag für die TextBox #784 besser gehandhabt werden?

Bisher unterstützt NumberBox keine Anzeige von nicht-numerischen Zeichen (da sogar Formelzeichen bei der Auswertung von Ausdrücken entfernt werden).

Ich denke, Ihr Vorschlag für #784 ist bei weitem der umfassendste für unsere Plattform. Wenn dieser Vorschlag nicht umgesetzt wird, erscheint mir dies als ein geeignetes V2-Feature NumberBox als Fallback.

Wir planen bereits eine V2, die neben oder kurz nach WinUI 3.0 veröffentlicht wird, da zwei der stark nachgefragten Eingabevalidierungsmodi für NumberBox blockiert sind, wenn WinUI 3.0 benötigt wird. Also werde ich ein V2-Problem eröffnen, nachdem V1 live gegangen ist, und ich werde versuchen, dies auch dort zu vermerken.

Um neben all den anderen Eigenschaften hier selbstdokumentierend zu sein, ziehen wir etwas in der Art von "SpinButtonStep" in Betracht, sollte diese Argumentation Rechtfertigung genug sein, um abzuweichen

Ich sehe, dass Slider StepFrequency verwendet, also denke ich, dass wir versucht haben, mit dieser Terminologie konsistent zu sein. Vergessen Sie nicht, dass dies nicht nur für Drehschaltflächen gilt, sondern auch für das Ziehen und die Änderungswerte des UIAutomation-Anbieters.

@robloo und @mdtauk , ich hätte weiter in den Thread lesen sollen, bevor ich über ° Text anzuzeigen, da NumberBox Text und Value eng synchron hält, damit Sie als Entwickler greifen können welchen Typ Sie auch immer benötigen, ohne den Aufwand für die Konvertierung. Ich habe keine Möglichkeit gesehen, dies durch die verfügbaren Formatierungseigenschaften zu erreichen, aber wenn Sie einen Weg kennen, lassen Sie es mich bitte wissen!

Wir stehen jetzt direkt vor der V1-Version, aber für V2 werden wir uns noch einmal Präfix/Ausreichend/Sonderzeichen ansehen. In der Zwischenzeit glaube ich, dass der Vorschlag von

@adrientetar , Scroll-to-Change hat es für V1 geschafft, aber Drag-to-Change wurde auf V2 verzögert. Da wir immer noch daran arbeiten, diese Funktionen zu vervollständigen, haben wir es noch nicht geschafft, Ihre Anfrage zu besprechen, dass Umschalt+Auf/Ab in Einheiten von 10 und Strg+Umschalt+Auf/Ab in Einheiten von 100 fortschreiten.

Könnten Sie mir mehr Kontext zu den Szenarien geben, in denen Sie diese Funktion verwenden würden? Woher wissen Ihre Benutzer, dass dies verfügbar ist? Können Sie mir helfen zu verstehen, warum dies in allen NumberBoxen standardmäßig (oder zumindest verfügbar) sein sollte, verglichen mit der lokalen Implementierung in Ihrer Lösung?

@SavoySchuler

Vielen Dank für Ihre Kommentare.

Um neben all den anderen Eigenschaften hier selbstdokumentierend zu sein, ziehen wir etwas in der Art von "SpinButtonStep" in Betracht, sollte diese Argumentation Rechtfertigung genug sein, um abzuweichen

Ich mag diese Terminologie sehr, aber ich habe übersehen, dass Slider bereits die StepFrequency-Eigenschaft hat. Da dies der Fall ist, macht es keinen Sinn, von der Konvention abzuweichen, wie @jevansaks angegeben hat.

Die Rundung erfolgt durch Formatierung. Hier ist ein Beispiel für eine Rundungseigenschaft, die für DecimalFormatter festgelegt werden kann.

Nehmen wir an, der Benutzer gibt "1 / 3" in die NumberBox ein. Ist dann folgende Reihenfolge richtig:

• Bei Fokusverlust / Eingabe wird der Ausdruck ausgewertet und der Double-Wert von 0,3333333...34 berechnet
• Die 0.33333333...34 werden an den DecimalFormatter übergeben
• Die 0,3333333...34 könnten je nach Ihren Einstellungen auf "0,30" gerundet werden (nur um schwierig zu sein)
• Dieser "0.30"-Wert wird dann in die TextBox zur Anzeige für den Benutzer eingefügt
• Das doppelte Value ist jetzt {0,33333333...34} und der Text ist jetzt "0,30".
• Beim Lesen des doppelten Value wird NICHT die gerundete Zahl zurückgegeben, die in Text angezeigt wird
  (Oder wird der dezimal formatierte Wert nach der Umwandlung in einen String irgendwie noch einmal geparst? und dann das Ganze neu ausgewertet?)

Ich bin auch besorgt, dass die Eigenschaften Value und Text intern so eng gekoppelt sind. Die Dokumentation definiert diese Kopplung nicht und wenn sie nicht stark strukturiert ist, machen wechselseitige Abhängigkeiten keinen Spaß.

Ich bin mir noch nicht sicher, wie dies intern implementiert wird, aber es scheint der richtige Weg zu sein, den doppelten Wert als einzige reale Eigenschaft zu behandeln. Text ist nur eine formatierte Version von Value. Dann könnte der Entwickler den Wert beliebig formatieren, damit er in der TextBox und der Text-Eigenschaft angezeigt wird (wir würden das Gradsymbol oder die zuvor angeforderten Fuß-/Zoll-Symbole erhalten). Das wäre überhaupt nicht schwierig, wenn alles bereits intern von der Value-Eigenschaft gesteuert wird. Texteingaben des Benutzers werden sowieso nicht gespeichert und würden nur verwendet, um den Wert neu zu berechnen, der dann für die Anzeige erneut formatiert wird.

Reihenfolge sollte sein:

• Benutzertexteingabe -> Parser -> Doppelter Wert -> Formatierung -> Text

Das Ändern des Textwerts aus dem Code würde so aussehen, als ob der Benutzer Text eingegeben hätte. Wenn Sie den Wert direkt ändern, müssen Sie nur den Formatierungs- und den Textschritt durchlaufen.

Um die Rundung zwischen Wert- und Textsequenz genau zu halten, würde dies eher so aussehen:

• Benutzertexteingabe -> Parser -> Wert -> Rundung -> Wert -> Formatierung -> Text

Bearbeiten: Um das Runden im Ausdrucks-/Eingabe-Parser und der Auswertungs-Engine (wie auch immer es genannt wird) zu implementieren, müssten Sie wahrscheinlich eine neue Eigenschaft hinzufügen, um den Algorithmus wie RoundingAlgorithm zu definieren. Diese Aufzählung ist bereits in Windows.Globalization.NumberFormatting definiert, wie Sie bereits erwähnt haben. INumberFormatter2 sollte zum Formatieren verwendet werden und für nichts anderes – halten Sie die Phasen zwischen Berechnung und schließlich angezeigtem Text entkoppelt.

@adrientetar , Scroll-to-Change hat es für V1 geschafft, aber Drag-to-Change wurde auf V2 verzögert. Da wir immer noch daran arbeiten, diese Funktionen zu vervollständigen, haben wir es noch nicht geschafft, Ihre Anfrage zu besprechen, dass Umschalt+Auf/Ab in Einheiten von 10 und Strg+Umschalt+Auf/Ab in Einheiten von 100 fortschreiten.

Könnten Sie mir mehr Kontext zu den Szenarien geben, in denen Sie diese Funktion verwenden würden? Woher wissen Ihre Benutzer, dass dies verfügbar ist? Können Sie mir helfen zu verstehen, warum dies in allen NumberBoxen standardmäßig (oder zumindest verfügbar) sein sollte, verglichen mit der lokalen Implementierung in Ihrer Lösung?

Einer sollte ein größeres Inkrement sein und der andere sollte kleiner sein – ähnlich wie beim Anstoßen ausgewählter Bereiche/Objekte in Adobe-Apps

Könnten Sie mir mehr Kontext zu den Szenarien geben, in denen Sie diese Funktion verwenden würden?

Es ist großartig, wenn Sie einen Wert mit visuellen Auswirkungen ändern möchten (z. B. die Drehung eines Objekts), aber nicht sicher sind, wie weit Sie gehen möchten. Es ist also gut für die visuelle Gestaltung.

Woher wissen Ihre Benutzer, dass dies verfügbar ist?

Es ist nur eine Funktion, die moderne Tools haben, zB Adobe XD, Framer...

Können Sie mir helfen zu verstehen, warum dies in allen NumberBoxen standardmäßig (oder zumindest verfügbar) sein sollte, verglichen mit der lokalen Implementierung in Ihrer Lösung?

Ich denke, es ist gut, dies zu haben, wenn Sie sich auf einem Touch-Gerät befinden. Dies ist eine bequeme Möglichkeit, einen bestimmten Wert durch Tippen und Ziehen zu optimieren (ein bisschen wie das Telefonzeitauswahl-Widget, bei dem Sie durch Tippen und Ziehen durch die Werte scrollen).

Einer sollte ein größeres Inkrement sein und der andere sollte kleiner sein – ähnlich wie beim Anstoßen ausgewählter Bereiche/Objekte in Adobe-Apps

RangeBase hat die Eigenschaften SmallChange und LargeChange. Wir bei BeLight Software in unserer Version von NumericUpDown werden von RangeBase abgeleitet und ändern den Wert durch SmallChange mit den Tastenkombinationen ArrowUp und ArrowDown und von LargeChange mit den Tastenkombinationen PageUp und PageDown

Und wir sind hier nicht allein,
https://help.syncfusion.com/uwp/numeric-updown/gestures
https://docs.telerik.com/devtools/wpf/controls/radnumericupdown/features/navigation

Nur eine Bemerkung zum Ziffernblock der Tastatur, die mir während des Community-Calls in den Sinn kam...

In den meisten Apps wird das "." Tastenfeldtaste ist immer noch dem "." zugeordnet. Zeichen, das sich vom Dezimaltrennzeichen unterscheidet, wenn eine nicht englische Sprache verwendet wird (zum Beispiel "," auf Französisch). Wenn Sie also auf "." drücken. Geben Sie in den Notizblock ein, es schreibt ein "." Charakter.

Einige Apps (Excel ist die bekannteste dafür) ändern dieses Tastenverhalten, um jeden Tastendruck auf der Tastatur neu zu interpretieren "." als Dezimaltrennzeicheneingabe. Es ist besser mit dem "Taschenrechner"-Design der Tastatur kompatibel.

Die Rechner-App schreibt auch das "." drücken, um es als Dezimaltrennzeichen zu interpretieren.

Da die Nummernbox mehr als "Rechner" arbeiten darf, könnte das Steuerelement die Verwendung des "." als Dezimaltrennzeichen im Tastenfeld eingeben ? Oder zumindest eine Möglichkeit für den Entwickler bieten, diese Funktion hinzuzufügen, ohne mit Schlüsselfiltern und Ereignissen kämpfen zu müssen?

Vielleicht könnte eine Eigenschaft es ermöglichen, die Funktion zu aktivieren (bei Opt-in) oder zu deaktivieren (bei Opt-out). Zum Beispiel KeyPadDotAsDecimalSeparator="false" ?

V2 NumberBox-Vorschlag: https://github.com/microsoft/microsoft-ui-xaml/issues/1736

Hallo wundervolle WinUI-Community! Vielen Dank, dass Sie uns dabei geholfen haben, unsere erste von der Community vorgeschlagene Kontrolle nach Hause zu bringen, um die Veröffentlichung zu sehen. Wir wissen, dass dies ein riesiges Unterfangen war und dass Sie alle viel Zeit in die Erstellung der besten Sammlung von V1-Funktionen investiert haben, die wir gemeinsam entwerfen konnten.

Wir wissen auch, dass es nicht alles in die V1-Version geschafft hat. Einige sehr erwünschte Eingabevalidierungskonfigurationen hängen von der Arbeit mit WinUI 3.0-Funktionen ab, einige gewünschte Funktionsanforderungen sind erst spät in der Validierung/Anwendung aufgetaucht und einige Funktionen, von denen wir wussten, dass sie nach der Veröffentlichung von V1 besser erforscht werden würden.

Wir möchten unsere beabsichtigte NumberBox-Funktionsarbeit mit einer WinUI 3-Version abschließen. Ich habe ein Problem geöffnet, um Feedback zu benötigten Funktionen zu sammeln, die in V1 fehlen. Wenn NumberBox etwas fehlt, das Sie brauchen, hinterlassen Sie bitte hier einen Kommentar: https://github.com/microsoft/microsoft-ui-xaml/issues/1736