Meiner Meinung nach ist die Notwendigkeit von Inhalten, die gescrollt werden können, und Inhalten, die gezoomt werden können, sehr unterschiedlich. Ich verstehe, dass beim Zoomen von Inhalten oft auch gescrollt werden muss, aber ich bin gespannt, ob es in Erwägung gezogen wurde, diese separaten Steuerelemente zu erstellen? Möglicherweise mit einem zoombaren Steuerelement, das sich von einem scrollenden erstreckt.
Meine Bedenken sind: 1) Der ScrollViewer wird übermäßig komplex, indem Zoomfunktionen hinzugefügt werden, die von den meisten nicht benötigt werden; 2) Es ist für jemanden, der nach einem Steuerelement zum Zoomen von Inhalten sucht, nicht offensichtlich, dass der ScrollViewer dies unterstützt.

Darüber hinaus würde ich im Angebot gerne die Möglichkeit sehen, zu einem bestimmten Element im Scroll-Viewer zu scrollen. Theoretisch könnte dies von einem Entwickler getan werden, indem er alle Elemente davor misst und dann zum entsprechenden Offset scrollt, aber dies kann mit virtualisierten Listen schwierig sein und ist (meiner Meinung nach) ein häufig genug Szenario, dass viele Apps ( und Entwickler) würde davon profitieren, dass dies integriert ist.
Überlegen Sie, wo ein Artikel zu einer "Liste" hinzugefügt wird und der Entwickler sicherstellen möchte, dass dieser Artikel sichtbar ist. Oder betrachten Sie eine Seite mit einer Master-/Detailansicht, bei der die Seite bei einem Detailelement weiter unten in der Liste geöffnet wird, der Entwickler jedoch sicherstellen möchte, dass das ausgewählte Element in der Masterliste angezeigt wird, sodass es Kontext für das bietet, was in der . angezeigt wird Detailansicht.

In ähnlicher Weise wäre es auch nützlich, sicherzustellen, dass ein Element im sichtbaren Bereich bleibt, während andere Elemente innerhalb der scrollbaren Bereiche aus dem visuellen Baum entfernt (oder zu ihm hinzugefügt) werden. Ich bin mir nicht sicher, wie dies am besten wäre, aber es ist sehr schlecht, wenn sich das ausgewählte Element innerhalb eines scrollbaren Bereichs bewegt, weil eine Hintergrundaktion (oder ein Thread außerhalb der Benutzeroberfläche) andere Elemente entfernt oder dem scrollbaren Bereich hinzufügt.
Wenn sich ein Element beim Klicken/Tippen bewegt, führt dies zu einer schrecklichen Benutzerfreundlichkeit. Auch das Verschieben von fokussierten/ausgewählten Elementen aus dem sichtbaren Bereich kann zu Problemen bei Eingabehilfen und Bildschirmleseprogrammen führen.
Ich bin mir bewusst, dass es potenzielle Probleme gibt, wenn Sie versuchen, ein Element an derselben Position zu halten, während sich die Umstehenden bewegen (insbesondere wenn dieses Element an anderer Stelle gelöscht wird), aber nichts zu tun scheint nicht gut genug zu sein.

Danke @mrlacey. Ich kann sehen, dass die Zoomfunktionalität im vorhandenen ScrollViewer sowie in diesem Vorschlag weniger auffindbar wäre. Ich habe dies als offene Frage zur Diskussion hinzugefügt, da dies ein weiterer Ausgangspunkt für den bestehenden UWP ScrollViewer wäre (vielleicht zum Besseren?).

Die Virtualisierung macht die Sache knifflig, da das jeweilige Element möglicherweise zuerst erstellt und durch das Layoutsystem laufen muss, um eine Position zu erhalten, zu der Sie dann scrollen können. Aus diesem Grund hatten in der Vergangenheit bestimmte Steuerelemente (zB ListView) ihre eigene ScrollIntoView-Methode , die das oben StartBringIntoView-Methode , die verwendet werden kann, um sehr einfach zu einem Element zu scrollen, und verfügt über eine Reihe von Optionen , um eine fein abgestufte Kontrolle darüber bereitzustellen, wo es im Ansichtsfenster landet, wenn es angezeigt wird. Der StartBringIntoView-Ansatz funktioniert sogar in Szenarien mit verschachtelten Bildlaufoberflächen, da er eine Anforderung generiert, die für jedes Bildlaufsteuerelement aufspringt, um zu antworten. Dies geschieht im Wesentlichen, wenn ein Element den Fokus auf Tastatur/GamePad/Sprecher erhält. Voraussetzung ist natürlich, dass Sie zunächst über ein UIElement verfügen, das Sie in einem Virtualisierungsszenario nicht ohne eine Möglichkeit zur expliziten Auslösung eines zu realisierenden Elements verwenden dürfen. Wäre es sinnvoll, die Realisierung eines Elements explizit auszulösen? Unter anderem könnte man damit dann einen StartBringIntoView auslösen.

Betreff: Die Position eines Elements beibehalten, wenn andere Inhalte hinzugefügt/entfernt werden oder sich in der Größe ändern... Stimme voll und ganz zu, dass Nichtstun nicht gut genug ist. Genau aus diesem Grund gibt es die Funktion zur Scrollverankerung . :) Es ist eine wenig bekannte Funktion, die in der Vergangenheit in die virtualisierenden Panels für ListView/GridView integriert wurde. In den letzten Versionen haben wir uns ausdrücklich bemüht, solche Dinge von der Verfügbarkeit nur in ListView zu entkoppeln.

Wenn die Idee eines erweiterten ScrollViewers untersucht werden soll, können die Fluent Design-Teams Sie vielleicht zum Umgang mit Parallaxe und Elementen mit standardmäßig eingestellten Z-Tiefenwerten beraten.

Wenn XAML in 3D-Darstellungen für MR-Apps übergeht und wenn Tiefe und Schatten zu 2D-XAML kommen – wie das Scrollen Elemente mit unterschiedlichen Tiefenwerten verschieben würde, wie die Schatten über oder hinter den Scroll-Indikatoren gerendert werden können und andere Probleme, die auftreten können in den 3D-Experimenten des XAML-Teams - könnte in den neuen Standard integriert werden, da die Windows-UI-Bibliothek langsam zum neuen Standard wird.

Meiner Meinung nach ist die Notwendigkeit von Inhalten, die gescrollt werden können, und Inhalten, die gezoomt werden können, sehr unterschiedlich.

Außer in Webbrowsern, Grafikdesign-Apps, Office-Apps, PDF-Viewern..... alles, was ein Inhaltsdokument anzeigt.

Stimmen Sie @mrlacey zu, dass es wichtig ist, ein bestimmtes Element in die Ansicht zu bringen und anzugeben, wo es in der Ansicht angezeigt wird (oben, mittig, unten usw.). Es muss auch eine Möglichkeit geben, zu erkennen, ob das Element vollständig sichtbar oder abgeschnitten ist. Auf diese Weise muss ich nicht in der Ansicht scrollen, um ein Element anzuzeigen, wenn ich weiß, dass das Element bereits ganz oder teilweise sichtbar ist.

Danke an alle! Wir haben einige Telemetriedaten zu den Eigenschaften gesammelt, die Apps in ihrem Markup festlegen, und der ZoomMode wird direkt nach dem *ScrollMode und *ScrollBarVisibility angezeigt. Meistens ändern Apps keine Eigenschaften. Was ich beim Festlegen der Eigenschaften ScrollMode und ScrollBarVisibility beobachtet habe, ist, dass häufig ein horizontales Scrollen des Inhalts aktiviert wird. Die Einführung der ContentOrientation-Eigenschaft soll dies erleichtern. Nach dem horizontalen Scrollen ist das Zoomen das zweithäufigste Szenario.

Anstatt ein separates (abgeleitetes) Steuerelement einzuführen, um die Auffindbarkeit des Zoomens zu verbessern, glaube ich, dass die richtige Dokumentation / Beispiele effektiver sein könnten.

Wie wäre es mit dem Hinzufügen einer Verhaltens- oder Kontextaufzählung?

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom;
ScrollViewer.ScrollBehaviour = ScrollBehaviour.Scroll;
ScrollViewer.ScrollBehaviour = ScrollBehaviour.ParallaxScroll;

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom; ist jedoch sehr verwirrend. Ich denke, ZoomMode sollte so bleiben, wie es ist.

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom; ist jedoch sehr verwirrend. Ich denke, ZoomMode sollte so bleiben, wie es ist.

Ich hätte den Vorschlag wahrscheinlich voranstellen sollen, um Kommentare zu adressieren, die der Meinung sind, dass es ein abgeleitetes Steuerelement für das Zoomen von Inhalten geben sollte, anstatt für das Scrollen

Für mich ist es tatsächlich sinnvoll, die Zoom-Funktionalität mit ScrollViewer eingebaut zu haben, insbesondere auf Touch-Geräten. Es gibt derzeit keine einfache Möglichkeit, ein Bild/ein Steuerelement in UWP frei zu schwenken/zoomen/drehen, und viele verwandte Fragen wurden auf StackOverflow und GitHub gestellt (z. B. Add draggable content control ).

@micahl , ich nehme an mit Zoomen und

Unterstützen Sie Rotationsgesten

würde dieses Szenario in Zukunft nativ unterstützt werden?

Für mich ist es tatsächlich sinnvoll, die Zoom-Funktionalität mit ScrollViewer eingebaut zu haben, insbesondere auf Touch-Geräten. Es gibt derzeit keine einfache Möglichkeit, ein Bild/ein Steuerelement in UWP frei zu schwenken/zoomen/drehen, und viele verwandte Fragen wurden auf StackOverflow und GitHub gestellt (z. B. Add draggable content control ).

Wenn Sie mehr Kontrolle über Zoomen und Scrollen haben möchten...

ScrollViewer.ScrollBehaviour = ScrollBehaviour.ZoomAndScroll;

Auf Touch-Geräten fühlt es sich jedoch natürlich an, das Einklemmen und Gleiten der Finger zuzulassen. Beim Zoomen ohne Berührung müssen jedoch die Tasten [ + ] und [ − ] angezeigt werden. Oder wenn es nur Zoom war, würde das Ziehen des Scrollbar-Daumens hinein- und herauszoomen.

Wenn Sie sich die Microsoft Word-Benutzeroberfläche ansehen, befindet sich in der Statusleiste ein Zoom-Steuerelement. Und Bildlaufleisten für den Dokumentbereich.

Ist die Mauszoomunterstützung etwas, das in das neue ScrollViewer-Steuerelement integriert werden sollte? Wenn also ZoomMode aktiviert ist oder eine Verhaltenseigenschaft Zoom zulässt - erscheinen dann Plus- und Minus-Schaltflächen?

@JustinXinLiu Die Unterstützung von Rotationsgesten würde wahrscheinlich die Unterstützung von InteractionTracker (@likuba) erfordern.

@mdtauk Der neue ScrollViewer würde das Zoomen mit dem Mausrad über ein Strg + Mausrad ähnlich dem vorhandenen ScrollViewer unterstützen. Mir ist unklar, ob das Steuerelement bei aktiviertem Zoom standardmäßig über eine Plus-/Minus-Schaltfläche verfügen soll. Mein derzeitiger Eindruck ist, dass die Arten von Apps, die normalerweise das Zoomen ermöglichen (z. B. eine Inhaltsdokument-App), diese Schaltflächen auf unterschiedliche Weise in ihre App-Erfahrung integrieren. Zum Beispiel ein - / + in einer Statusleiste, die durch einen Schieberegler getrennt ist (zB Office) oder einfach ein -/+, das vertikal unter anderen Befehlen (zB Maps) erscheint.

@micahl Ich verstehe nicht, warum ScrollFrom so heißt. Ist es nicht wie ScrollBy, aber mit einem Velocity-Parameter?

@adrientetar fragen Sie, warum nicht eine weitere Überladung von ScrollBy mit einem anderen Satz von Parametern verwendet wird, anstatt sie ScrollFrom zu benennen?

Ja, denke ich 😃 aber ich stelle mir vor, dass das Konzept hinter ScrollFrom darin besteht, sich mit einer bestimmten Geschwindigkeit in eine Richtung zu bewegen? im Gegensatz zu ScrollBy, das nur zu einem bestimmten Punkt bewegt wird.

Korrekt. Wir haben uns 3 Situationen vorgestellt:

1. Es ist mir egal, was meine aktuelle Position ist. Ich möchte zu einem bestimmten Ziel scrollen/zoomen.
2. Meine aktuelle Position ist mir wichtig und ich möchte um einen bestimmten Betrag relativ zu dieser Position scrollen/zoomen.
3. Es ist mir egal, was das endgültige Ziel ist. Ich möchte nur von meiner aktuellen Position scrollen/zoomen.

Ein Szenario für letzteres könnte so etwas wie das Mausrad-Klicken zum Schwenken sein. Abhängig von der Position des Cursors relativ zu dem Zeitpunkt, an dem darauf geklickt wurde, wird eine gewisse Trägheit eingefügt, um von der aktuellen Position (was auch immer das ist) zu scrollen.

Danke, das klärt die Sache. Ich denke, ich möchte ScrollBy eher für mein eigenes Mausrad-Klick-Erlebnis verwenden, aber ich kann sehen, dass ScrollFrom in bestimmten Fällen nützlich ist.

Im aktuellen ScrollViewer-Steuerelement ist es möglich, an die Eigenschaften ViewportWidth und ViewportHeight zu binden, aber dies scheint derzeit im neuen ScrollViewer-Steuerelement nicht möglich zu sein. Wird das hinzugefügt?

@lhak , an was würden Sie diese Werte binden? Sie hinzuzufügen wäre keine große Veränderung. Abhängig vom Kontext für Ihr Szenario kann es sein, dass wir einen anderen Ansatz empfehlen als verbindlich. Wir möchten zwar sensibel für Unterschiede sein, die den Übergang von einem zum anderen erschweren, aber wir möchten auch Alternativen fördern, wenn sie besser sind.

@micahl Ich bin mir ziemlich sicher, dass ich diese Werte in der Vergangenheit auch für einige Berechnungen verwendet habe. Ich bin mir nicht sicher, ob ich an sie gebunden bin.

@michael-hawker Um das klarzustellen, werden die Eigenschaften im ScrollViewer verfügbar sein. In der vorgeschlagenen API werden sie jedoch als reguläre Eigenschaften und nicht als DependencyProperties bereitgestellt. Dieselben Werte sind als Teil der ExpressionAnimationSources-Eigenschaft für Situationen verfügbar, in denen jemand eingabegesteuerte Animationen basierend auf Komposition erstellt.

Ich verwende derzeit einen Code ähnlich dem folgenden in meiner Anwendung:

<ScrollViewer x:Name="outputScrollViewer">
  <Viewbox MaxWidth="{x:Bind outputScrollViewer.ViewportWidth, Mode=OneWay}" MaxHeight="{x:Bind outputScrollViewer.ViewportHeight, Mode=OneWay}">
    <TheXamlElement Width=X Height=Y/>
  </Viewbox>
</ScrollViewer>

Dies ermöglicht es, das innere xaml-Element (das eine feste Größe hat) zu scrollen/zu zoomen, während das Seitenverhältnis beibehalten wird. Das Verhalten ist ähnlich wie bei der Foto-App, die ein Bild anzeigt, mit der Ausnahme, dass das xaml-Element nie kleiner ist als das Ansichtsfenster des Scrollviewers.

@lhak , gutes Szenario! Ich denke laut darüber nach, wie dieses Szenario im aktuellen Vorschlag berücksichtigt werden könnte ... Ich

• Keine = Keine Vorzugsorientierung. Geben Sie dem Inhalt unendliche verfügbare Größe in beide Richtungen.
• Horizontal = Geben Sie dem Inhalt nur horizontal eine unendliche verfügbare Größe und beschränken Sie die Höhe während des Layouts auf das Ansichtsfenster.
• Vertikal = Horizontales transponieren

Eine vierte Option wäre, sowohl die Höhe als auch die Breite während des Layouts auf die Größe des Ansichtsfensters zu beschränken. Im Moment nenne ich dies eine "Viewport" -Orientierung, obwohl ich gemischte Reaktionen darauf habe, sie als solche zu benennen.
Zumindest im (häufigeren?) Fall eines Bildes würde es meiner Meinung nach die Viewbox und Bindungen überflüssig machen, da "das Richtige" nur als Teil des Layoutprozesses passieren sollte.

<ScrollViewer ContentOrientation="Viewport">
  <Image Stretch="Uniform" .../>
</ScrollViewer>

Bei komplexeren Inhalten können Sie diese in eine Viewbox einschließen und trotzdem die Bindungen überspringen.

<ScrollViewer ContentOrientation="Viewport">
  <Viewbox>
    <TheXamlElement Width=X Height=Y/>
  </Viewbox>
</ScrollViewer>

@micahl Habe eine andere Frage: Ich möchte die Handhabung des Mausrads von Scroller ändern, um den Zoom schneller zu machen (größere Schritte) und die Glättungsanimation zu entfernen. Es scheint, als ob es keine API gibt, um das Zoomen des Rads zu optimieren. Muss ich das Mausrad-Ereignis manuell verarbeiten?

Möglicherweise müssen Sie das Mausrad manuell bedienen, aber es wäre bedauerlich, wenn sich herausstellt, dass Sie die Funktion des Steuerelements erneut implementieren müssen. Wir glauben, dass es einen Weg geben könnte, das zu erreichen, wonach Sie suchen. Der Kern davon wäre, die ZoomInertiaDecayRate auf einen Wert nahe 1,0 zu setzen und dann einen wiederholten Zoom-Fangpunkt zu definieren. Es ist etwas, das Sie ausprobieren sollten, sobald wir die ZoomInertiaDecayRate-Eigenschaft hinzugefügt und einige Probleme im Zusammenhang mit obligatorischen Fangpunkten behoben haben.

Wenn das nicht funktioniert, können Sie versuchen, es selbst zu handhaben, indem Sie IgnoredInputKind="Mousewheel" festlegen und dann entweder den Scroller in eine Unterklasse überschreiben, um OnPointerWheelChanged zu überschreiben, oder einen Ereignishandler für das PointerWheelChanged-Ereignis auf Scroller hinzufügen.

@micahl Danke! Ich bin mir nicht sicher, für welches Szenario Sie das Mausradverhalten kalibriert haben, persönlich gefällt mir die Art und Weise, wie es z. Scroller-Mausrad-Zoom-Animation fühlt sich etwas träge an und hat imo wirklich kleine Zoom-Schritte.

@adrientetar , gutes Feedback. Wir können prüfen, ob wir es anpassen.

Jede Art von Variable, die Inkremente und Werte steuert - könnte zu überschreibbaren Eigenschaften gemacht werden

Rechts. Eine Herausforderung für uns hier besteht darin, dass unter Win10 Version 1809 und höher die Steuerung die Mausradeingabe an den zugrunde liegenden InteractionTracker übergibt, damit sie für flüssigere Bewegungen vom UI-Thread verarbeitet werden kann. Diese überschreibbaren Eigenschaften müssten zuerst auf der unteren Ebene verfügbar gemacht werden. Für Versionen von Win10 vor 1809 fügen wir Logik hinzu, damit der Steuerungsprozess Mausradeingaben auf dem UI-Thread hat.

Wir könnten ein Verhalten in Betracht ziehen, bei dem wir einige überschreibbare Eigenschaften bereitstellen und wenn explizit festgelegt werden, dann auf das Mausrad des Steuerungsprozesses im UI-Thread zurückgreifen. Wenn diese Eigenschaften auf der unteren Ebene vorhanden sind, können wir uns auf sie verlassen und sie wieder an den Compositor übergeben. Scrollen wäre wahrscheinlich nicht so glatt für das Mausrad. Vielleicht ist das hier in Ordnung?

Das aktuelle Zoomverhalten ist also in InteractionTracker integriert, ohne dass es überschrieben werden kann? Und ich denke, jetzt gibt es keine Möglichkeit, es zu ändern, weil es die Abwärtskompatibilität brechen würde 🤔 cc @likuba

Ich denke, es gibt einige Optionen auf InteractionTracker, die hier helfen könnten 😊. Insbesondere haben wir Funktionen wie PointerWheelConfig und DeltaScaleModifier entwickelt , um diese Arten von Anpassungen zu ermöglichen. Wir werden eine Synchronisierung durchführen und sehen, ob die Verwendung dieser Elemente innerhalb des Steuerelements hier ohne die oben genannten Probleme/Risiken passieren kann.

@micahl Ich habe eine interessante Situation bei einem Projekt, an dem ich arbeite und musste meinen eigenen Scrollviewer für den PoC schreiben - aber ich würde gerne wissen, ob Sie Pläne haben (oder ob das Steuerelement dies bereits unterstützt) für folgendes Szenario:
Angenommen, Sie haben eine riesige Leinwand, 10000 x 5000. Um sich darauf zu bewegen, kapseln Sie sie in einen Scrollviewer.
Jetzt haben Sie auf der Leinwand 2 InkCanvases (oder mehr) und möchten auf beiden (oder mehr) schreiben, mit verschiedenen Fingern oder mit 1 Finger und 1 Mauszeiger. Wie würden Sie das mit dieser Steuerung erreichen (oder ist das überhaupt möglich)? :)
Was ich gesehen habe, ist das Standardverhalten, sobald Sie beim Zeichnen auf einer InkCanvas etwas anderes berühren, feuert diese bestimmte InkCanvas "PointerLost" und das war's - nichts anderes zu tun.
Offensichtlich ist mein Scrollviewer alles andere als perfekt, da ich ihn selbst geschrieben habe - also versuche ich zu sehen, ob dies mit diesem Steuerelement möglich ist?

Dankesehr !

Hallo @stefangavrilasengage , interessantes Szenario. :) Was ist von Ihrem PoC aus zu erwarten, wenn ein Finger auf eine InkCanvas fällt und sich dann zu bewegen beginnt? Zieht oder schwenkt es?

Hallo @micahl - danke für die Antwort! Ich nehme an, Sie haben inzwischen erraten, dass es sich um eine digitale Whiteboard-App handelt.
Jetzt präsentiere ich, was aktuell passiert:

• ScrollViewer (Standard): Ein Fingerzeichnen auf einer InkCanvas ist in Ordnung. 2. Finger führt dazu, dass die 1. InkCanvas Eingabe verliert.
• ScrollViewerEx (benutzerdefiniertes Steuerelement): Verwenden Sie so viele Finger und so viele InkCanvases zum Zeichnen und es funktioniert.

Hilft das? :)
Dankeschön !

@stefangavrilasengage Ich habe gefragt, was

@micahl Entschuldigung - vergessen zu erwähnen, wie ich den Konflikt gelöst habe.
Die Objekte, die wir auf der Leinwand haben, haben ihre Tinte in einem Win2D-Container. Nur wenn Sie für jedes Objekt einen Bearbeitungsmodus aktivieren, wird oben eine InkCanvas zur Bearbeitung angezeigt (mit benutzerdefinierter Trocknung).
Daher sollte in meiner Situation (nicht sicher, ob dies auf andere zutrifft), wenn Sie eine InkCanvas aktiv "drawable" haben, nichts zum ScrollViewer hochgehen.
Mich würde ein Anwendungsfall interessieren, bei dem dies Ihrer Meinung nach nicht zutrifft, wenn überhaupt?

Vielen Dank !

Kaum zu glauben, dass @micahl und ich zum ersten Mal in eine Github-Ausgabe geraten sind!

Kaum zu glauben, dass @micahl und ich zum ersten Mal in eine Github-Ausgabe geraten sind!

Das tut mir leid ! Bearbeitet!

@micahgodbolt Es ist vielleicht nicht das letzte Mal. ;)
@stefangavrilasengage danke! Das beantwortet meine Frage. Mir ist aufgefallen, dass das Austauschen eines ScrollViewer mit etwas anderem wie einem Border als übergeordnetes Element eines Canvas mit mehreren InkCanvas-Steuerelementen nicht das gleiche Problem hat. Ich habe mich also intern an einige Leute gewandt, um zu verstehen, was dazu führen kann, dass die Multi-Input / Multi-InkCanvas-Funktionalität zusammenbricht, wenn dies in einem ScrollViewer passiert.

@stefangavrilasengage , herauszufinden, warum es nicht funktioniert, wird einige Zeit / Untersuchung dauern. Lassen Sie uns das getrennt von diesem Vorschlag verfolgen. Eröffnen Sie ein Thema dafür?

@micahl Ich habe ein Problem mit Scroller, bei dem das Scrollen und Zoomen um meinen Inhalt in OnControlLoaded mich in eine falsche Position bringt. Wenn ich nur scrolle, lande ich an der richtigen Position, aber wenn ich direkt nach dem Scrollen zoome, befinde ich mich in einer völlig falschen Position, obwohl ich centerPoint=null angegeben habe, sodass es standardmäßig in der Mitte des Ansichtsfensters angezeigt wird (vom Betrachten des Codes, weil es noch keine Dokumentation). Mit diesem Code .

Danke fürs Ausprobieren, @adrientetar! Lassen Sie uns diesen Thread auf den Vorschlag konzentrieren. Können Sie für das, was Sie sehen, ein separates Problem öffnen? Je nachdem, wo wir in dieser Diskussion ankommen, möchten wir vielleicht zu diesem Thread zurückkehren, um zu diskutieren, ob Änderungen am Vorschlag erforderlich sind.

@micahl Warum haben ExtentChanged/StateChanged/ViewChanged-Ereignisse ein Objekt als Argument und nicht zB StateChangedEventArgs mit einem State-Member? Da InteractionTracker in einem anderen Thread ausgeführt wird, wird das Nachrichtenübergabemuster (Ereignis mit einem Argument) nicht dem Abfragen der Steuerelementeigenschaft im Ereignishandler vorgezogen?

https://github.com/XeorgeXeorge/Extended-Image-Viewer

Keine große Sache, aber der erste Teil dieses Repos zeigt, wie man das Zoomen implementiert, auch wenn die horizontalen / vertikalen Bildlaufleisten gesperrt sind (deaktiviert).

In einfacheren Worten:
Ermöglicht das Schwenken eines eingezoomten Inhalts, während die Anpassung immer noch erzwungen wird
effektives vertikales/horizontales Ansichtsfenster.

Zum Zeitpunkt der Veröffentlichung ist es zwingend erforderlich, die HorizontalScrollbarVisibility-Eigenschaft in einem ScrollViewer zu aktivieren, um tatsächlich einen funktionsfähigen Zoom-Vorgang zu erhalten genug.

@micahl Ich sehe, dass Scroller keine StateChanged-Ereignisse sendet, wenn ein nicht animierter Zoom ausgeführt wird, ist das beabsichtigt?
Ich stelle meine CanvasVirtualControl-Skalierung ein, wenn Scroller inaktiv wird, wie Sie in https://github.com/microsoft/microsoft-ui-xaml/issues/541#issuecomment -488749469 vorgeschlagen haben, damit das Steuerelement nicht zu groß gerastert wird Teile der Leinwand relativ zum Zoomfaktor. Aber bei einem nicht animierten Zoom muss ich das tun, wenn ich die ZoomTo-Methode aufrufe, obwohl die Zoomänderung nicht (afaikt) realisiert wurde.

@adrientetar , das Erstellen von Ereignisargumenten, die zwischen dem Framework und der App hin und her

Ja, das aktuelle Design besteht darin, dass StateChanged in einem nicht animierten Zoom, den Sie programmgesteuert aufrufen, nicht ausgelöst wird. Die ZoomCompleted- und ScrollCompleted-Ereignisse würden als Reaktion auf programmgesteuerte Änderungen ausgelöst. IIRC werden sie nicht durch Änderungen des Benutzers ausgelöst. Sie könnten eines davon verwenden, vielleicht in Kombination mit StateChanged. Zu Ihrer Information wird das ViewChanged-Ereignis immer ausgelöst, wenn sich die Ansicht ändert (Benutzer oder programmgesteuert), was es zu einem sehr leistungsempfindlichen Codepfad macht und nicht das ist, was Sie verwenden möchten.

Wir hören immer noch auf Feedback. Wenn die Dinge stumpf erscheinen, lassen Sie es uns wissen.

Ja, das aktuelle Design besteht darin, dass StateChanged in einem nicht animierten Zoom, den Sie programmgesteuert aufrufen, nicht ausgelöst wird.

Ah okay, jetzt verstehe ich. Vielleicht könnte das Ereignis immer ausgelöst werden und einen Ursprungsparameter wie SetFocus enthalten, aber vielleicht ist das mit etwas Aufwand verbunden.

Die ZoomCompleted- und ScrollCompleted-Ereignisse würden als Reaktion auf programmgesteuerte Änderungen ausgelöst. IIRC werden sie nicht durch Änderungen des Benutzers ausgelöst.

Okay, für meinen Anwendungsfall muss ich also ZoomCompleted und StateChanged behandeln, wenn State == Idle, je nachdem, ob die Änderung programmgesteuert ist oder nicht. Ist das nicht seltsam? Ich meine, verschiedene Events mit unterschiedlichen Namen für die gleiche Sache zu haben, hat nur einen anderen Weg ausgelöst 🤔

@RBrid und ich hatten ein kurzes Gespräch über die Einführung eines neuen Zustands "Übergang" und einige kleinere Umbenennungen. Lassen Sie uns wissen, ob dies für Ihren Anwendungsfall sinnvoller wäre.

Die diskutierte Idee war, dass wir das StateChanged-Ereignis auslösen und den aktuellen Status als Transitioning melden, wenn eine Änderung an der Scroll-/Zoom-Position durchgeführt werden soll (ob vom Benutzer initiiert oder programmgesteuert). So würde die Sequenz für ein programmatisches Scrollen (animiert und nicht animiert) aussehen:

// Programmatische Anfrage, animiert
myScrollInfo = ScrollTo(100, animate=true);
// ein paar Zecken
StateChanged ausgelöst (Scroller.State == Transitioning)
// ein paar Zecken
StateChanged ausgelöst (Scroller.State == Animation)
// viele Zecken
StateChanged ausgelöst (Scroller.State == Idling)

// Programmatische Anfrage, keine Animation
myScrollInfo = ScrollTo(100, animate=false);
// ein paar Zecken
StateChanged ausgelöst (Scroller.State == Transitioning)
// ein paar Zecken
StateChanged ausgelöst (Scroller.State == Idling)

Wir würden wahrscheinlich die InteractionState-Enumeration in etwas wie ScrollState umbenennen wollen, da sie mehr als nur die Interaktionen darstellen würde.

enum ScrollState
{
    Idling = 0,
    Transitioning = 1,
    Interacting = 2,
    Inertial = 3,
    Animating = 4,
};

@micahl Ja, das sieht sehr nach dem aus, was ich erwarten würde! Jemand, der nur animierte Änderungen verarbeiten möchte, kann den Animating-Status abfangen. Für die Namen würde ich Idle not Idling ("Scroller is empty"/"Scroller is animating"), Transitioning → Stirring? (Übergänge sind sehr verwirrend, ich möchte lieber vermitteln, dass es am Anfang der Bewegung ist, so dass Imo-Rühren besser funktionieren könnte ), Trägheit könnte Drifting sein 😛 aber ich denke, API Review wird auch einspringen.

Beim Rühren dachte ich anfangs ans Mischen. :) API-Review wird abwägen wollen, wenn wir Namen finalisieren und neigt dazu, nach Präzedenzfällen zu suchen. Es ist immer gut, einige Optionen zu haben. Andere Alternativen könnten Unbekannt oder Ausstehend sein. Es gibt einen Präzedenzfall in bestehenden APIs für beide zusammen mit Idle, was bedeutet, dass wir Idling wahrscheinlich nicht machen würden.

Cool Cool. Pending sgtm, imo Unknown ist noch verwirrender als Transitioning.

@micahl -- Funktionale Anforderung Nummer 3 enthält diesen Unterpunkt:

nimmt an effektiven Ansichtsfensteränderungen teil (Muss)

Dieser Unterpunkt bezieht sich auf das bereits vorhandene Ereignis FrameworkElement.EffectiveViewportChanged . Reicht dieser Unterpunkt aus, um (indirekt) zu sagen, dass das asynchrone teilweise Laden von Inhalten bei Bedarf auch eine Anforderung/Priorität ist? Ich meine zum Beispiel das Äquivalent dazu, wie der ScrollViewer funktioniert, wenn MS Edge eine vergrößerte Seite eines PDF-Dokuments (oder SVG oder eines anderen komplexen Dokuments) anzeigt. Wenn der Zoom beispielsweise 900 % beträgt, wird die gesamte PDF-Seite aus folgenden 2 Gründen nicht mit 900 % vorgerendert:

• Diese Rendering-Aufgabe (bei hohem Zoom-Prozentsatz) benötigt je nach Komplexität des Dokuments (Anzahl der Vektorelemente, Effekte usw.), Dokumentgröße und Zoom-Prozentsatz ungefähr 3 .. 20 Sekunden. Diese Verzögerung ist für Endbenutzer zu groß, um sie zu akzeptieren.
• Ein gerendertes Bild (Bitmap) der gesamten PDF-Seite kann bei einem hohen Zoom-Prozentsatz Hunderte von Megabyte RAM verbrauchen, da dies dem Rendern mit einer sehr hohen DPI entspricht.

MS Edge rendert Teile der vergrößerten PDF-Seite bei Bedarf, dh wenn der Benutzer diese Teile in die Ansicht scrollt. Diese Technik vermeidet die lange Verzögerung, bevor die Seite angezeigt wird. Ich schlage vor, dass die funktionalen Anforderungen dieses Szenario explizit erwähnen, aber auch mit indirekter Unterstützung für async Task . Wenn ein nicht gerenderter (oder anderweitig nicht sofort verfügbarer) Teil in die Ansicht gescrollt wird, kann ScrollViewer diesen Platz vorübergehend mit einem konfigurierbaren Brush füllen und dann ein Ereignis auslösen, und der Ereignishandler kann ein async Task starten um das Teil zu rendern (oder anderweitig abzurufen/zu laden). Später, wenn Task abgeschlossen ist, wird der gerenderte/abgerufene/geladene Teil im ScrollViewer angezeigt und deckt den Platz ab, der vorübergehend mit Brush gefüllt wurde.

Bei diesem Problem geht es nicht nur um die hohen Kosten für das Rendern bei einem hohen Zoom. Sie gilt auch für Inhalte, die bei Bedarf abgerufen werden. Stellen Sie sich beispielsweise eine Karte oder ein Satellitenbild vor, die in ScrollViewer angezeigt werden. Teile der Karte werden nur dann vom Server heruntergeladen, wenn der Benutzer sie in die Ansicht scrollt.

Sollten die Zoom-bezogenen APIs in ein abgeleitetes Steuerelement (z. B. ZoomViewer) unterteilt werden, so dass es bei ScrollViewer ausschließlich um das Scrollen geht?

Obwohl ich das Hinzufügen von ScrollViewer.ZoomFactor sehr geschätzt habe, war ich überrascht zu sehen, dass es direkt zu ScrollViewer hinzugefügt wurde. Ich nahm an, dass es einfacher und zuverlässiger wäre, Zoom in eine separate Klasse (nicht unbedingt eine abgeleitete Klasse) zu legen. Mindestens 3 Wege sind möglich:

1. Eine Klasse namens vielleicht ZoomViewer , die ScrollViewer NICHT erbt, sondern eine ScrollViewer -Instanz als untergeordnetes Element verwendet (in ihrer ControlTemplate ).
2. Eine Klasse namens ZoomableScrollViewer , die ScrollViewer erbt.
3. Direkte Unterstützung des Zooms innerhalb von ScrollViewer , wenn es nicht übermäßig kompliziert oder unordentlich ist.

17 Stellen Sie eine Standard-UX bereit, um einen mittleren Mausklick und ein Scrollen zu unterstützen. (Sollen)
18 Unterstützen Sie einen Modus zum Klicken und Verschieben mit der Maus (z. B. Verschieben von Inhalten in einem PDF-Viewer). (Sollen)

Ich schlage vor, darüber nachzudenken, ob die Unterstützung für 17 aufgehoben werden soll, da 18 viel besser funktioniert als 17 und kaum jemand 17 in der Praxis verwendet. Zugegeben, ich denke vielleicht, dass 17 etwas anderes bedeutet als Ihre beabsichtigte Bedeutung (die Beschreibung von 17 ist nur ein Satz und ich bin mir nicht 100% sicher, ob es das bedeutet, was ich denke). Ist es nicht richtig zu sagen, dass 18 sehr benutzerfreundlich und einfach zu verwenden ist, während 17 eine umständliche Sache ist, die jeder nur schwer verwenden kann und vermeidet?
(Dieses Problem ändert sich, wenn 17 aus Gründen der Zugänglichkeit erforderlich ist, aber bisher habe ich noch nie jemanden sagen hören, dass 17 ein Zugänglichkeitsproblem ist.)

4 Kann eingabegesteuerte Animationen ausführen

Nummer 4 ist ein Problem im Zusammenhang mit der Barrierefreiheit. Ich möchte darum bitten, dass ScrollViewer (und alle anderen Steuerelemente in WinUI) die Eingabehilfeeinstellungen respektieren:

Windows 10 -> Start -> Einstellungen -> Benutzerfreundlichkeit -> Anzeige -> Animationen in Windows anzeigen (Ein oder Aus).

Leider sind mir im Laufe der Jahre viele Beispiele aufgefallen, bei denen Microsoft-Apps die Eingabehilfen von Windows ignorieren. Animationen sind ausgeschaltet, aber Microsoft-Apps zeigen trotzdem Animationen an. Dies verursacht echte Schwierigkeiten für die Benutzer, die sich auf diese Zugänglichkeitseinstellungen verlassen. Nicht jeder hat die Möglichkeit, Animationen zu genießen, ohne negative Nebenwirkungen zu erleiden. Benutzer, die keine Schwierigkeiten beim Anzeigen von Animationen usw. haben, können die Bedeutung der Eingabehilfeeinstellungen in Windows nur schwer verstehen.

Hallo @verelpode , @predavid wird die Arbeit rund um den neuen ScrollViewer vorantreiben, also überlasse ich sie ihr.

17 Stellen Sie eine Standard-UX bereit, um einen mittleren Mausklick und ein Scrollen zu unterstützen. (Sollen)
18 Unterstützen Sie einen Modus zum Klicken und Verschieben mit der Maus (z. B. Verschieben von Inhalten in einem PDF-Viewer). (Sollen)

Ich schlage vor, darüber nachzudenken, ob die Unterstützung für 17 aufgehoben werden soll, da 18 viel besser funktioniert als 17 und kaum jemand 17 in der Praxis verwendet. Zugegeben, ich denke vielleicht, dass 17 etwas anderes bedeutet als Ihre beabsichtigte Bedeutung (die Beschreibung von 17 ist nur ein Satz und ich bin mir nicht 100% sicher, ob es das bedeutet, was ich denke). Ist es nicht richtig zu sagen, dass 18 sehr benutzerfreundlich und einfach zu verwenden ist, während 17 eine umständliche Sache ist, die jeder nur schwer verwenden kann und vermeidet?
(Dieses Problem ändert sich, wenn 17 aus Gründen der Zugänglichkeit erforderlich ist, aber bisher habe ich noch nie jemanden sagen hören, dass 17 ein Zugänglichkeitsproblem ist.)

@verelpode Ich denke, Sie verstehen 17 richtig und ich stimme zu, dass 18 wichtiger und normalerweise intuitiver ist als 17. Aber es kann Szenarien geben, in denen "Linksklick und Ziehen" bereits für andere Zwecke verwendet wird, z . Für solche Szenarien wäre es gut, wenn die App das Scrollen durch Mittelklick ermöglichen könnte (17).

Ich persönlich verwende von Zeit zu Zeit das Scrollen mit einem mittleren Klick in Browsern, bei dem Linksklick + Ziehen entweder eine Textauswahl oder Drag + Drop von Bildern bewirkt. Bei einem UWP-Browser wären 18 deaktiviert und 17 aktiviert. Beide sollten über separate Eigenschaften aktiviert werden.

@lukasf

Ich persönlich verwende von Zeit zu Zeit das Scrollen mit einem mittleren Klick in Browsern, bei dem Linksklick + Ziehen entweder eine Textauswahl oder Drag + Drop von Bildern bewirkt.

Ein guter Punkt in Bezug auf die Notwendigkeit, zu vermeiden, dass die Textauswahl usw. nicht mehr funktioniert. Was halten Sie von dieser möglichen Lösung: Lassen Sie mit einem Mittelklick den mausbasierten Schwenkmodus (18) starten, anstatt den umständlichen 17-Modus zu starten.

Wenn ich mir anschaue, was andere Apps tun, können Sie bei einigen Apps das mausbasierte Schwenken starten, indem Sie die Leertaste gedrückt halten, während Sie mit der linken Maustaste in den scrollbaren Inhaltsbereich klicken. Diese Lösung ermöglicht es, dass Linksklick innerhalb des scrollbaren Inhaltsbereichs normal funktioniert, da der Panning-Modus nur über Leertaste + Klick gestartet wird. Schwenken per Leertaste+Klick finde ich sehr komfortabel und bequem und schnell.

Diese Leertaste+Klick-Lösung ist jedoch einfacher in Apps zu implementieren, die keine bearbeitbaren Textfelder innerhalb des scrollbaren Inhaltsbereichs anzeigen müssen. Wenn im scrollbaren Inhaltsbereich bearbeitbare Textfelder vorhanden sind, wäre es ein Problem, dass die Panning-Funktion Benutzer nicht in die Lage versetzt, Leerzeichen in Textfelder einzugeben. Daher sollte diese Funktion, wie Sie bereits sagten, über eine Eigenschaft aktiviert werden. Verwenden Sie alternativ nicht die Leertaste, sondern starten Sie mit einem mittleren Klick den mausbasierten Schwenkmodus (18), wodurch das Problem beseitigt wird, dass Benutzer keine Leerzeichen in Textfelder eingeben können.

@verelpode
Bei allen Browsern und auch einer Reihe anderer Anwendungen (Word, Adobe Reader, Outlook,...), die den Modus 17 unterstützen, würde ich dies immer noch finden. Nur weil Sie es persönlich unangenehm finden, heißt das nicht, dass es für andere nicht nützlich ist. Beide Modi sollten natürlich aktiviert sein, dann können die Entwickler entscheiden, was in ihrer App verwendet werden soll. Dies würde auch Ihr Leertaste+Klick-Verhalten ermöglichen, wenn es für eine App sinnvoll ist: Modus 18 bei Leertaste unten aktivieren, bei Leertaste oben wieder deaktivieren.

@lukasf – OK, hört sich gut an. Ich dachte, Sie meinen, wenn der Schwenkmodus (18) die Textauswahl oder das Ziehen und Ablegen von Bildern usw. nicht verhindern würde, würden Sie den Modus 17 nicht mehr verwenden und zu 18 wechseln, aber jetzt sehe ich, dass Sie beide Modi bevorzugen unterstützt werden.

Vielen Dank für Ihr Feedback @verelpode und @lukasf , ich stimme Ihnen zu, dass wir letztendlich wollen, dass öffentliche Knöpfe am Scroller-Steuerelement die Nummern 17 und 18 ein- und ausschalten. Nennen wir sie 17 = mausbasiertes Konstantgeschwindigkeits-Panning und 18=Mausbasiertes Schwenken.

Ich habe gerade eine PR https://github.com/microsoft/microsoft-ui-xaml/pull/1472 verschickt, um einige meiner Recherchearbeiten hinzuzufügen. Ich wollte sehen, wie nah ich mit dem heutigen Scroller sowohl 17 als auch 18 unterstützen kann.

Beim 18 = mausbasierten Schwenken lief es ziemlich gut, obwohl die Lösung im Gegensatz zu den berührungsbasierten oder Mausrad-basierten Erfahrungen zu 100 % UI-Thread-gebunden ist. Ich habe die ScrollTo-Methode verwendet, während ich das PointerMoved-Ereignis der Maus abgehört habe. Letztendlich möchten wir, dass die zugrunde liegende InteractionTracker-Komponente Mausbewegungen wie Fingerbewegungen behandelt.

Die Dinge sind viel schwieriger für 17 = Maus-basiertes Schwenken mit konstanter Geschwindigkeit (eine Erfahrung, die ich persönlich nicht mag). Der Prototyp ist alles andere als ideal und ich habe nicht versucht, alle Probleme anzugehen, aber zwei sind besonders besorgniserregend:

• Während eines Pannings mit konstanter Geschwindigkeit (dh 0-Velocity-Decay-Panning) glaube ich nicht, dass es mit dem aktuellen Scroller eine Möglichkeit gibt, die Bewegung zu stoppen, ohne zu einer älteren Position zurückzukehren (mit ScrollBy(0, 0)) . Es ist einfach nicht zuverlässig möglich zu wissen, wie weit der Kompositionsthread dem UI-Thread voraus ist. Daher wäre eine neue öffentliche Scroller-API erforderlich, um die Geschwindigkeit störungsfrei zu stoppen.
• Ich konnte die Mauserfassung nach dem PointerReleased-Ereignis der Maus nicht beibehalten. Es scheint, dass dafür ein neues Xaml-Framework-Feature erforderlich wäre.
  Wie auch immer, dies kann ein weiterer Fall sein, in dem wir möchten, dass der zugrunde liegende InteractionTracker einen Teil der Erfahrung direkt verarbeitet.
  Ich werde diese unbedingt im Hinterkopf behalten, wenn ich zukünftige Scroller/InteractionTracker-Funktionen bespreche.

@RBrid

Für 18=mausbasiertes Schwenken lief es ziemlich gut, …...
Die Dinge sind viel schwieriger für 17 = Maus-basiertes Schwenken mit konstanter Geschwindigkeit (eine Erfahrung, die ich persönlich nicht mag).

Interessante Ergebnisse! Angesichts der Schwierigkeiten mit 17 = konstanter Geschwindigkeit und der Tatsache, dass 18 auf eine Weise implementiert werden kann, die die normale Verwendung von Linksklick nicht verhindert, denke ich, dass der Vorschlag meiner persönlichen Meinung nach wahrscheinlich aktualisiert werden sollte geben Sie 17 auf und unterstützen Sie stattdessen 18, aber zugegebenermaßen weiß ich nicht, wie viele Benutzer sich beschweren würden, wenn 17=constant-velocity aufgegeben wird.

Danke @RBrid für diese Untersuchungen. Schön zu hören, dass Modus 18 bereits funktioniert! Ich stimme zu, dass es idealerweise von InteractionTracker gehandhabt werden sollte, um einen reibungslosen Betrieb auch während des Ladens des UI-Threads zu ermöglichen.

@verelpode Beide Modi sind als "Sollte" eingestellt. Wenn also der Aufwand zu hoch ist, um Modus 17 zu realisieren, könnte er einfach weggelassen (und ggf. später hinzugefügt werden). Aber vielleicht findet jemand einen Weg, dies ohne zu viele Änderungen zu realisieren.

Ich hoffe, der neue ScrollViewer kann Zoom mit der Taste "Strg" deaktivieren oder anpassen.