في رأيي ، فإن الحاجة إلى وجود محتوى يمكن تمريره ومحتوى يمكن تكبيره مختلفة تمامًا. أفهم أنه عند تكبير المحتوى ، غالبًا ما يحتاج أيضًا إلى التمرير ، لكنني أشعر بالفضول إذا كان هناك أي اعتبار لعمل عناصر التحكم المنفصلة هذه؟ ربما مع عنصر تحكم قابل للزووم يمتد من عنصر التمرير.
اهتماماتي هي: 1) أصبح ScrollViewer معقدًا بشكل مفرط عن طريق إضافة وظائف ذات صلة بالتكبير / التصغير والتي لن يحتاجها معظم الأشخاص ؛ 2) ليس من الواضح لشخص يبحث عن عنصر تحكم لتكبير المحتوى أن ScrollViewer يدعم هذا.

بالإضافة إلى ذلك ، ضمن الاقتراح ، أود أن أرى القدرة على التمرير إلى عنصر معين داخل عارض التمرير. من الناحية النظرية ، يمكن للمطور القيام بذلك عن طريق قياس جميع العناصر قبله ثم التمرير إلى الإزاحة المناسبة ، ولكن قد يكون من الصعب القيام بذلك مع القوائم الافتراضية وهو (في رأيي) سيناريو شائع بدرجة كافية للعديد من التطبيقات ( والمطورين) من أن يكون هذا مدمجًا.
ضع في اعتبارك مكان إضافة عنصر إلى "قائمة" ويريد المطور التأكد من أن هذا العنصر مرئي. أو ضع في اعتبارك صفحة بها عرض رئيسي / تفصيلي حيث يتم فتح الصفحة بطريقة عنصر تفصيلي أسفل القائمة ، لكن المطور يريد التأكد من عرض العنصر المحدد في القائمة الرئيسية ، لذا فهي توفر سياقًا لما هو معروض في عرض التفاصيل.

وبالمثل ، سيكون من المفيد أيضًا أن تكون قادرًا على ضمان بقاء العنصر في المنطقة المرئية بينما تتم إزالة العناصر الأخرى الموجودة داخل المناطق القابلة للتمرير من (أو الإضافة إلى) الشجرة المرئية. لست متأكدًا من أفضل طريقة للقيام بذلك ، ولكنها سيئة للغاية عندما يتحرك العنصر المحدد داخل منطقة قابلة للتمرير لأن إجراء الخلفية (أو مؤشر ترابط خارج واجهة المستخدم) يزيل أو يضيف عناصر أخرى إلى المنطقة القابلة للتمرير.
يؤدي تحريك عنصر ما أثناء النقر فوق / النقر فوقه إلى تجربة استخدام رهيبة. يمكن أن يتسبب نقل العناصر المركزة / المحددة خارج المنطقة المرئية أيضًا في حدوث مشكلات لأدوات إمكانية الوصول وقارئات الشاشة.
أدرك أن هناك مشكلات محتملة في محاولة الاحتفاظ بالعنصر في نفس الموضع أثناء تحرك من حوله (خاصة إذا تم حذف هذا العنصر من مكان آخر) ولكن عدم القيام بأي شيء لا يبدو جيدًا بما فيه الكفاية.

شكراmrlacey. أستطيع أن أرى كيف ستكون وظيفة التكبير / التصغير أقل قابلية للاكتشاف في ScrollViewer الحالي بالإضافة إلى هذا الاقتراح. لقد أضفت هذا كسؤال مفتوح للمناقشة لأنه سيكون نقطة انطلاق أخرى من UWP ScrollViewer الحالي (ربما للأفضل؟).

تجعل المحاكاة الافتراضية الأشياء صعبة نظرًا لأن العنصر المحدد قد يحتاج أولاً إلى الإنشاء والتشغيل من خلال نظام التخطيط للحصول على موضع يمكنك التمرير إليه بعد ذلك. هذا هو السبب في أن بعض الضوابط في الماضي (مثل ListView) كان لها طريقة ScrollIntoView الخاصة بها والتي تتعامل مع ما سبق لتسهيل الأمر. هل هذا هو نوع الطريقة التي تتخيلها؟ بدلاً من ذلك ، يحتوي كل UIElement على طريقة StartBringIntoView يمكن استخدامها للتمرير بسهولة شديدة إلى عنصر ولديه عدد من الخيارات لتوفير تحكم دقيق في المكان الذي يهبط فيه في منفذ العرض عند عرضه. يعمل أسلوب StartBringIntoView حتى في السيناريوهات مع أسطح التمرير المتداخلة نظرًا لأنه يولد طلبًا يتصاعد حتى يستجيب كل عنصر تحكم تمرير. هذا هو ما يحدث بشكل أساسي عندما يتلقى عنصر تركيز لوحة المفاتيح / لوحة الألعاب / الراوي. بالطبع ، يتطلب الأمر أن يكون لديك أولاً UIElement والذي قد لا يكون في سيناريو ظاهري بدون طريقة لتشغيل عنصر بشكل صريح ليتم تحقيقه. هل سيكون من المفيد أن يكون لديك طريقة لتحريك تحقيق عنصر بشكل صريح؟ من بين الأشياء الأخرى التي يمكنك استخدامها بعد ذلك لتشغيل StartBringIntoView.

إعادة: الحفاظ على موضع عنصر ما عند إضافة / إزالة محتوى آخر أو تغيير حجمه ... أوافق تمامًا على أن عدم القيام بأي شيء ليس جيدًا بما يكفي. هذا هو بالضبط سبب وجود ميزة إرساء التمرير . :) إنها قدرة غير معروفة تم دمجها في الماضي في اللوحات الافتراضية لـ ListView / GridView. في الإصدارات الأخيرة ، كنا نبذل جهدًا واضحًا لفصل أشياء مثل هذه عن كونها متاحة فقط في ListView.

إذا كان من المقرر استكشاف فكرة ScrollViewer الموسعة ، فربما يمكن لفرق Fluent Design تقديم النصح لك حول التعامل مع اختلاف المنظر والعناصر ذات قيم z-deep التي تم تعيينها افتراضيًا.

عندما ينتقل XAML إلى تمثيلات ثلاثية الأبعاد لتطبيقات MR ، وعندما يصل العمق والظلال إلى 2D XAML - كيف يمكن للتمرير نقل العناصر ذات قيم العمق المختلفة ، وكيف يمكن أن تظهر الظلال أعلى أو خلف مؤشرات التمرير ، والمشكلات الأخرى التي قد تظهر في تجارب فريق XAML ثلاثية الأبعاد - يمكن دمجها في ما يمكن أن يصبح افتراضيًا جديدًا ، حيث تصبح مكتبة Windows UI ببطء الافتراضي الجديد.

في رأيي ، فإن الحاجة إلى وجود محتوى يمكن تمريره ومحتوى يمكن تكبيره مختلفة تمامًا.

باستثناء متصفحات الويب ، تطبيقات تصميم الرسومات ، تطبيقات المكتب ، عارضات PDF ..... أي شيء يعرض مستند محتوى.

اتفق مع mrlacey على أن عرض عنصر معين أمر مهم بالإضافة إلى تحديد مكان عرضه في العرض (أعلى ، وسط ، أسفل ، إلخ ...). يجب أيضًا أن تكون هناك طريقة لاكتشاف ما إذا كان العنصر معروضًا بالكامل أو مقطوعًا. بهذه الطريقة ، لا يتعين علي التمرير في العرض لإظهار عنصر إذا كنت أعرف أن العنصر معروض بالكامل أو حتى جزئيًا.

شكرا لكم جميعا! لقد جمعنا بعض أدوات القياس عن بُعد بخصوص الخصائص التي تميل التطبيقات إلى تعيينها في ترميزها ويظهر ZoomMode مباشرةً بعد * ScrollMode و * ScrollBarVisibility. في معظم الأوقات ، لا تغير التطبيقات أي خصائص. ما لاحظته عند تعيين خصائص ScrollMode و ScrollBarVisibility هو أنه غالبًا ما يتم تمكين التمرير الأفقي على المحتوى. يهدف إدخال خاصية ContentOrientation إلى تسهيل ذلك. بعد التمرير الأفقي ، يكون السيناريو التالي الأكثر شيوعًا هو التكبير / التصغير.

بدلاً من تقديم عنصر تحكم منفصل (مشتق) لمعالجة قابلية اكتشاف التكبير ، أعتقد أن التوثيق / العينات الصحيحة يمكن أن تكون أكثر فعالية.

ماذا عن إضافة سلوك أو سياق تعداد؟

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

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom; محير للغاية بالرغم من ذلك. أعتقد أن ZoomMode يجب أن يبقى كما هو.

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom; محير للغاية بالرغم من ذلك. أعتقد أن ZoomMode يجب أن يبقى كما هو.

ربما كان ينبغي أن أكون قد أعدت الاقتراح على أنه معالجة التعليقات التي تعتقد أنه يجب أن يكون هناك عنصر تحكم مشتق لتكبير المحتوى ، بدلاً من التمرير

بالنسبة لي ، من المنطقي أن يكون لديك وظيفة تكبير / تصغير مضمنة بـ ScrollViewer ، خاصة على الأجهزة التي تعمل باللمس. لا توجد حاليًا طريقة سهلة للقيام بالتحريك الحر / التكبير / التدوير على صورة / عنصر تحكم في UWP ، وقد تم طرح العديد من الأسئلة ذات الصلة على StackOverflow و GitHub (على سبيل المثال ، إضافة عنصر تحكم في المحتوى القابل للسحب ).

micahl ، أفترض مع التكبير و

دعم إيماءات الدوران

سيتم دعم هذا السيناريو محليًا في المستقبل؟

بالنسبة لي ، من المنطقي أن يكون لديك وظيفة تكبير / تصغير مضمنة بـ ScrollViewer ، خاصة على الأجهزة التي تعمل باللمس. لا توجد حاليًا طريقة سهلة للقيام بالتحريك الحر / التكبير / التدوير على صورة / عنصر تحكم في UWP ، وقد تم طرح العديد من الأسئلة ذات الصلة على StackOverflow و GitHub (على سبيل المثال ، إضافة عنصر تحكم في المحتوى القابل للسحب ).

إذا كانت هناك حاجة لمزيد من التحكم في التكبير والتمرير ...

ScrollViewer.ScrollBehaviour = ScrollBehaviour.ZoomAndScroll;

ولكن في الأجهزة التي تعمل باللمس ، من الطبيعي السماح بقرص الأصابع وانزلاقها. ومع ذلك ، فإن التكبير بدون لمس سيحتاج إلى ظهور أزرار [+] و [-]. أو ربما إذا كان التكبير فقط ، فسيتم تكبير وتصغير سحب الإبهام لشريط التمرير.

إذا نظرت إلى Microsoft Word UI ، فهناك عنصر تحكم Zoom في شريط الحالة. وأشرطة التمرير الخاصة بمنطقة المستند.

هل يدعم تكبير الماوس شيئًا يجب تضمينه في عنصر تحكم ScrollViewer الجديد؟ لذلك عندما يكون ZoomMode قيد التشغيل ، أو عندما تسمح خاصية السلوك بالتكبير / التصغير ، تظهر أزرار زائد وناقص؟

JustinXinLiu من المحتمل أن تتطلب إيماءات التدوير دعمًا من InteractionTracker (likuba).

mdtauk سيدعم ScrollViewer الجديد تكبير عجلة الماوس عبر Ctrl + عجلة الماوس على غرار ScrollViewer الحالي. ليس من الواضح بالنسبة لي ما إذا كان يجب أن يحتوي عنصر التحكم على زر زائد / ناقص افتراضي عند تمكين التكبير / التصغير. انطباعي الحالي هو أن أنواع التطبيقات التي عادةً ما تتيح التكبير (مثل تطبيق مستند المحتوى) تختار دمج هذه الأزرار في تجربة التطبيق الخاصة بهم بطرق متنوعة. على سبيل المثال ، a - / + في شريط الحالة الذي يتم فصله بواسطة شريط تمرير (مثل Office) أو مجرد - / + بسيط يظهر عموديًا أسفل الأوامر الأخرى (مثل الخرائط).

micahl لا أفهم سبب تسمية ScrollFrom بهذه الطريقة. أليس تمامًا مثل ScrollBy ولكن بمعامل سرعة؟

adrientetar هل تسأل لماذا لا يوجد حمل زائد آخر لـ ScrollBy مع مجموعة مختلفة من المعلمات بدلاً من تسميتها ScrollFrom؟

نعم أعتقد 😃 لكني أتخيل أن المفهوم الكامن وراء ScrollFrom هو التحرك في اتجاه بسرعة معينة؟ على عكس ScrollBy الذي هو مجرد الانتقال إلى نقطة معينة.

هذا صحيح. كان لدينا 3 مواقف في الاعتبار:

1. لا يهمني ما هو منصبي الحالي. أريد التمرير / التكبير إلى وجهة معينة.
2. يهمني ما هو موقعي الحالي وأريد التمرير / التكبير بمقدار معين بالنسبة لهذا الموضع.
3. لا يهمني ما هي الوجهة النهائية. أريد فقط التمرير / التكبير من موقعي الحالي.

قد يكون السيناريو الخاص بالأخير شيئًا مثل تجربة النقر مع عجلة الماوس. اعتمادًا على موضع المؤشر بالنسبة إلى وقت النقر فوقه ، يتم إدراج بعض القصور الذاتي في التمرير من الموضع الحالي (أيًا كان ذلك).

شكرا ، هذا يوضح الامور. أعتقد أنني أتطلع أكثر إلى استخدام ScrollBy لتجربة النقر بالماوس الخاصة بي ، ولكن يمكنني رؤية ScrollFrom يكون مفيدًا في حالات محددة.

في عنصر تحكم ScrollViewer الحالي ، من الممكن الارتباط بخصائص ViewportWidth و ViewportHeight ، ولكن لا يبدو هذا ممكنًا حاليًا في عنصر التحكم ScrollViewer الجديد. هل سيضاف هذا؟

lhak ، ما الذي

micahl أنا متأكد من أنني استخدمت هذه القيم في الماضي أيضًا لبعض الحسابات. لست متأكدًا مما إذا كنت ملتزمًا بهم.

@ michael-hawker للتوضيح ، ستكون الخصائص متاحة على ScrollViewer. ومع ذلك ، في واجهة برمجة التطبيقات المقترحة ، يتم عرضها كخصائص عادية بدلاً من خصائص التبعية. ستكون هذه القيم نفسها متاحة كجزء من خاصية ExpressionAnimationSources للمواقف التي يقوم فيها شخص ما ببناء رسوم متحركة تعتمد على المدخلات بناءً على التركيب.

أستخدم حاليًا بعض التعليمات البرمجية المشابهة لما يلي في تطبيقي:

<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>

هذا يجعل من الممكن تمرير / تكبير عنصر xaml الداخلي (الذي له حجم ثابت) مع الحفاظ على نسبة العرض إلى الارتفاع الخاصة به. يشبه السلوك تطبيق الصور الذي يعرض صورة ، باستثناء أن عنصر xaml لا يكون أبدًا أصغر من منفذ عرض برنامج scrollViewer.

lhak ، سيناريو جيد! التفكير بصوت عالٍ في كيفية استيعاب هذا السيناريو في الاقتراح الحالي ... أعتقد أنه يمكننا إضافة خيار آخر لخاصية ContentOrientation. الخيارات الحالية في الاقتراح:

• بلا = لا يوجد اتجاه مفضل. امنح المحتوى الحجم المتاح غير المحدود في كلا الاتجاهين.
• أفقي = امنح المحتوى حجمًا متاحًا غير محدود أفقيًا فقط وقصر الارتفاع على منفذ العرض أثناء التخطيط.
• عمودي = تبديل الأفقي

الخيار الرابع هو تقييد كل من الطول والعرض أثناء التخطيط بحجم إطار العرض. في الوقت الحالي سأسمي هذا اتجاه "منفذ العرض" ، على الرغم من أن لدي ردود فعل متباينة حول تسميته على هذا النحو.
أعتقد على الأقل في حالة الصورة (الأكثر شيوعًا؟) أنها ستجعل Viewbox والارتباطات غير ضرورية لأن "الشيء الصحيح" يجب أن يحدث كجزء من عملية التخطيط.

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

لمزيد من المحتوى المعقد ، ستتمكن من لفه في Viewbox ولا يزال بإمكانك تخطي الروابط.

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

micahl لديك سؤال آخر: أود تغيير معالجة عجلة الماوس في Scroller لجعل التكبير أسرع (زيادات أكبر) وإزالة الرسوم المتحركة السهلة. يبدو أنه لا توجد واجهة برمجة تطبيقات لتعديل تكبير العجلة ، فهل أحتاج للتعامل مع حدث عجلة الماوس يدويًا؟

قد تضطر إلى التعامل مع عجلة الماوس يدويًا ، ولكن سيكون من المؤسف أن ينتهي بك الأمر إلى إعادة تنفيذ ما يفعله عنصر التحكم. نعتقد أنه قد تكون هناك طريقة لتحقيق ما تسعى إليه. سيكون جوهر ذلك هو تعيين ZoomInertiaDecayRate إلى قيمة قريبة من 1.0 ثم تحديد نقطة تكبير / تصغير متكررة. إنه شيء يجب تجربته بمجرد إضافة خاصية ZoomInertiaDecayRate وإصلاح بعض المشكلات المتعلقة بنقاط المفاجئة الإلزامية.

إذا لم يفلح ذلك ، فيمكنك الرجوع لمحاولة التعامل مع الأمر بنفسك عن طريق تعيين IgnoredInputKind = "عجلة الماوس" ثم إما تصنيف Scroller لتجاوز OnPointerWheelChanged ، أو إضافة معالج حدث لحدث PointerWheelChanged في Scroller.

micahl شكرا! لست متأكدًا من السيناريو الذي قمت بمعايرة سلوك عجلة الماوس وفقًا له ، فأنا شخصياً أحب الطريقة التي تكون عليها على سبيل المثال في Adobe XD: هناك القليل من الرسوم المتحركة المتسارعة على ما يبدو ولكنها سريعة ولديها زيادات كبيرة في التكبير / التصغير. تبدو الرسوم المتحركة لتكبير عجلة الماوس Scroller بطيئة بعض الشيء ولديها زيادات صغيرة في التكبير / التصغير imo.

adrientetar ، ردود فعل جيدة. يمكننا النظر في تعديله.

أي نوع من المتغيرات التي تتحكم في الزيادات والقيم - يمكن تحويلها إلى خصائص قابلة للتجاوز

حق. يتمثل أحد التحديات التي تواجهنا هنا في أنه في الإصدار 1809 من Win10 وما بعده ، ترفع يد التحكم عن إدخال عجلة الماوس إلى InteractionTracker الأساسي للسماح بمعالجتها خارج UI-thread لحركة أكثر سلاسة. يجب أولاً كشف تلك الخصائص القابلة للتجاوز على المستوى الأدنى. بالنسبة لإصدارات Win10 قبل 1809 ، نضيف منطقًا لإدخال عجلة الماوس في عملية التحكم في مؤشر ترابط واجهة المستخدم.

يمكننا التفكير في وجود بعض السلوكيات حيث نكشف عن بعض الخصائص القابلة للتجاوز وإذا تم تعيين أي منها بشكل صريح ، فإننا نعود إلى وجود عجلة الماوس في عملية التحكم في مؤشر ترابط واجهة المستخدم. إذا / عندما توجد هذه الخصائص في المستوى الأدنى ، فيمكننا التبديل إلى الاعتماد عليها والركل مرة أخرى إلى المكون. ربما لن يكون التمرير سلسًا لعجلة الماوس. ربما هذا جيد هنا؟

لذا فإن سلوك التكبير الحالي يتم وضعه في InteractionTracker دون أي طريقة لتجاوزه؟ وأعتقد الآن أنه لا توجد طريقة لتغييره لأنه سيعطل التوافق مع الإصدارات السابقة 🤔 cclikuba

أعتقد أن هناك بعض الخيارات على InteractionTracker التي يمكن أن تساعد هنا 😊. على وجه التحديد ، قمنا ببناء ميزات مثل PointerWheelConfig و DeltaScaleModifier لتمكين هذه الأنواع من التخصيصات. سنقوم بالمزامنة ونرى ما إذا كان استخدام هذه العناصر داخل عنصر التحكم يمكن أن يؤدي إلى حدوث شيء ما هنا دون المشاكل / المخاطر التي ذكرتها أعلاه.

micahl لدي موقف مثير للاهتمام في مشروع أعمل عليه واضطررت إلى كتابة برنامج Scrollviewer الخاص بي لـ PoC - لكني أود أن أعرف ما إذا كان لديك أي خطط (أو إذا كان عنصر التحكم هذا يدعم هذا بالفعل) من أجل السيناريو التالي:
لنفترض أن لديك لوحة قماشية عملاقة ، 10000 × 5000 لتحريكها ، تقوم بتغليفها في ScrollViewer.
الآن على اللوحة القماشية لديك 2 InkCanvases (أو أكثر) وتريد الكتابة على كليهما (أو أكثر) ، بأصابع مختلفة أو بإصبع واحد ومؤشر ماوس واحد. كيف يمكنك تحقيق ذلك (أو حتى ممكن) بهذه السيطرة؟ :)
ما رأيته هو السلوك الافتراضي بمجرد أن تلمس أي شيء آخر أثناء الرسم على InkCanvas ، هذا InkCanvas المحدد يطلق "PointerLost" وهذا كل شيء - لا شيء آخر تفعله.
من الواضح أن برنامج Scrollviewer الخاص بي بعيد جدًا عن الكمال كما كتبته بنفسي - لذلك أتطلع لمعرفة ما إذا كان هذا ممكنًا باستخدام هذا التحكم؟

شكرا لك أيها الطيب !

مرحبًا stefangavrilasengage ، سيناريو مثير للاهتمام. :) من PoC الخاص بك ، ما هو السلوك المتوقع عندما ينزل إصبع على InkCanvas ثم يبدأ في التحرك؟ هل هو رسم أم مقلاة؟

مرحبًا هناك micahl - شكرًا لك على الرد! أفترض الآن أنك خمنت أنه شيء مثل تطبيق السبورة البيضاء الرقمية.
سأقدم الآن ما يحدث حاليًا:

• ScrollViewer (افتراضي): الرسم بإصبع واحد على InkCanvas جيد. الإصبع الثاني يجعل أول لوحة InkCanvas تفقد الإدخال.
• ScrollViewerEx (عنصر تحكم مخصص): استخدم العديد من الأصابع وأكبر عدد من InkCanvases للرسم وهو يعمل.

هل هذا يساعد؟ :)
شكرا لك !

stefangavrilasengage كنت أسأل ما الذي يزيل الغموض بين ما إذا كانت إيماءات اللمسة الواحدة (السلوك الافتراضي لـ ScrollViewer) أو ترسم الحبر. هناك صراع متأصل هناك. كيف تحلها؟ تتطلب إصبعين للتمرير مثل الخريطة؟ استخدم زر التحرير للدخول / الخروج من وضع التحرير؟ إلخ...

micahl اعتذاري - نسيت أن أذكر كيف تمكنت من حل النزاع.
الكائنات التي لدينا على القماش لها حبرها داخل حاوية Win2D. فقط إذا قمت بإدخال وضع تحرير لكل كائن ، فسيتم تقديم InkCanvas في الأعلى للتحرير (مع تجفيف مخصص).
لذلك في موقفي (لست متأكدًا مما إذا كان هذا ينطبق على أي شخص آخر) ، إذا كان لديك InkCanvas نشط "قابل للرسم" ، فلا شيء يجب أن يصل إلى ScrollViewer.
سأكون فضوليًا لمعرفة حالة استخدام حيث تعتقد أن هذا لا ينطبق ، إن وجد؟

شكرا !

من الصعب تصديق أن هذه هي المرة الأولى التي نخلط فيها أنا و

من الصعب تصديق أن هذه هي المرة الأولى التي نخلط فيها أنا و

اسف بشأن ذلك ! تم تحريره!

micahgodbolt قد لا يكون الأخير. ؛)
تضمين التغريدة هذا يجيب على سؤالي. لقد لاحظت أن تبديل ScrollViewer بشيء آخر مثل Border حيث أن أصل لوحة Canvas التي تحتوي على عناصر تحكم InkCanvas متعددة لا يواجه نفس المشكلة. لذلك ، لقد تواصلت مع بعض الأشخاص داخليًا لفهم ما قد يتسبب في تعطل وظيفة الإدخال المتعدد / متعدد InkCanvas عندما يحدث داخل ScrollViewer.

stefangavrilasengage ، فإن معرفة سبب عدم

micahl لدي مشكلة مع Scroller حيث يؤدي التمرير والتكبير / التصغير حول المحتوى الخاص بي في OnControlLoaded إلى وضعني في موضع خاطئ. إذا قمت بالتمرير فقط ، ينتهي بي الأمر في الموضع الصحيح ، ولكن إذا قمت بالتكبير مباشرة بعد التمرير ، فأنا في وضع إيقاف التشغيل تمامًا ، على الرغم من أنني حددت centerPoint = فارغًا ، لذلك يتم تعيينه افتراضيًا على مركز منفذ العرض (من النظر إلى الكود لأنه يوجد لا توجد وثائق بعد AFaict). مع هذا الرمز .

شكرًا لتجربة الأشياء ،adrientetar! دعونا نحافظ على تركيز هذا الموضوع على الاقتراح. هل يمكنك فتح مشكلة منفصلة لما تراه؟ اعتمادًا على المكان الذي نتوصل إليه في تلك المناقشة ، قد نرغب في العودة إلى هذا الموضوع لمناقشة ما إذا كان يستدعي إجراء تغييرات على الاقتراح.

micahl لماذا يكون للأحداث ExtentChanged / StateChanged / ViewChanged كائنًا كحجة وليس على سبيل المثال ، StateChangedEventArgs مع أحد أعضاء الدولة؟ بالنظر إلى أن InteractionTracker يعمل على سلسلة رسائل مختلفة ، أليس نمط تمرير الرسالة (حدث مع وسيطة) مفضلًا للاستعلام عن خاصية التحكم في معالج الحدث؟

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

ليس بالأمر الكبير ، ولكن الجزء الأول من هذا الريبو يعرض كيفية تنفيذ التكبير حتى عندما تكون أشرطة التمرير الأفقية / الرأسية مقفلة (معطلة) ،

بكلمات أبسط:
يسمح بالتحريك على محتوى مكبّر مع الاستمرار في فرض الملاءمة لـ
منفذ عرض رأسي / أفقي فعال.

في وقت نشر هذا ، من الضروري تمكين خاصية HorizontalScrollbarVisibility في ScrollViewer من أجل الحصول فعليًا على عملية Zoom وظيفية ، وعلى الرغم من أنه قد تكون هناك طرق أفضل للتغلب على هذا ، أعتقد أن حل scrollViewer المزدوج الذي ألغيت معًا قد يكون كافيًا يكفي.

micahl أرى أن Scroller لا يرسل أحداث StateChanged عند إجراء تكبير غير متحرك ، فهل هذا حسب التصميم؟
أقوم بضبط مقياس CanvasVirtualControl الخاص بي عندما يصبح Scroller خاملاً ، كما اقترحت في https://github.com/microsoft/microsoft-ui-xaml/issues/541#issuecomment -488749469 ، بحيث لا ينتهي الأمر بتنقيط عنصر التحكم كبير جدًا أجزاء من اللوحة القماشية بالنسبة إلى عامل التكبير / التصغير. ولكن مع التكبير غير المتحرك ، أحتاج إلى القيام بذلك في الوقت الذي أسمي فيه طريقة ZoomTo ، على الرغم من أن تغيير التكبير / التصغير لم يتحقق (AFAICT).

adrientetar ، هناك بعض النفقات العامة لإنشاء

نعم ، التصميم الحالي هو أنه في التكبير غير المتحرك ، تستدعي برمجيًا حالة StateChanged لا تنطلق. سيتم رفع الحدث ZoomCompleted و ScrollCompleted استجابة للتغييرات البرمجية. IIRC لا يتم تشغيلها بواسطة تغييرات من المستخدم. يمكنك استخدام واحد من هؤلاء ، ربما بالاشتراك مع StateChanged. كما لمعلوماتك ، يتم رفع حدث ViewChanged في أي وقت يتغير فيه العرض (مستخدم أو برمجي) مما يجعله مسار رمز حساس للغاية وليس ما تريد استخدامه.

ما زلنا نستمع إلى التعليقات ، لذا إذا بدت الأمور غير واضحة ، فأخبرنا بذلك.

نعم ، التصميم الحالي هو أنه في التكبير غير المتحرك ، تستدعي برمجيًا حالة StateChanged لا تنطلق.

آه حسنًا ، فهمت الآن. ربما يمكن إطلاق الحدث دائمًا ويحتوي على معلمة أصل ، مثل SetFocus ، ولكن ربما يكون هناك بعض الجهد للقيام بذلك.

سيتم رفع الحدث ZoomCompleted و ScrollCompleted استجابة للتغييرات البرمجية. IIRC لا يتم تشغيلها بواسطة تغييرات من المستخدم.

حسنًا ، بالنسبة لحالة الاستخدام الخاصة بي ، يجب أن أتعامل مع ZoomCompleted و StateChanged iff State == Idle ، اعتمادًا على ما إذا كان التغيير برمجيًا أم لا. أليس هذا غريب؟ أعني ، أن يكون لديك أحداث مختلفة بأسماء مختلفة لنفس الشيء يؤدي فقط بطريقة مختلفة 🤔

أجرينا محادثة قصيرة مع

كانت الفكرة التي تمت مناقشتها هي أنه عندما يكون هناك تغيير في موضع التمرير / التكبير / التصغير على وشك الخدمة (سواء كان ذلك من قِبل المستخدم أو بشكل برمجي) ، فسنقوم برفع حدث StateChanged والإبلاغ عن الحالة الحالية كـ Transitioning. إليك ما سيبدو عليه التسلسل للتمرير الآلي (متحرك وليس متحركًا):

// طلب برمجي ، متحرك
myScrollInfo = ScrollTo (100، animate = true) ؛
// قليل من القراد
رفع StateChanged (Scroller.State == Transitioning)
// قليل من القراد
رفع StateChanged (Scroller.State == Animating)
// العديد من القراد
رفع StateChanged (Scroller.State == Idling)

// طلب آلي ، بدون رسوم متحركة
myScrollInfo = ScrollTo (100، animate = false) ؛
// قليل من القراد
رفع StateChanged (Scroller.State == Transitioning)
// قليل من القراد
رفع StateChanged (Scroller.State == Idling)

ربما نرغب في إعادة تسمية InteractionState enum إلى شيء مثل ScrollState لأنه يمثل أكثر من مجرد التفاعلات.

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

micahl نعم ، هذا يشبه إلى حد كبير ما أتوقعه! يمكن للشخص الذي يريد التعامل مع التغييرات المتحركة فقط اعتراض حالة الرسوم المتحركة. بالنسبة للأسماء ، سأبقي Idle ليس Idling ("Scroller is idle" / "Scroller is animated") ، الانتقال → Stirring؟ (الانتقال محير للغاية ، أفضل أن ننقل أنه في بداية الحركة لذا قد يعمل التحريك imo

جعلني التحريك في البداية أفكر في المزج. :) سترغب مراجعة واجهة برمجة التطبيقات في التأثير عندما ننتهي من الأسماء ونميل إلى البحث عن سابقة. من الجيد دائمًا أن يكون لديك بعض الخيارات. قد تكون البدائل الأخرى غير معروفة أو معلقة. هناك سابقة في واجهات برمجة التطبيقات الحالية لكل من تلك الموجودة مع Idle مما يعني أننا ربما لا نفعل الخمول.

رائع رائع. في انتظار sgtm ، يعد imo Unknown أكثر إرباكًا من الانتقال.

micahl - يتضمن المتطلب الوظيفي رقم 3 هذه النقطة الفرعية:

يشارك في تغييرات منفذ العرض الفعالة (يجب)

تشير هذه النقطة الفرعية إلى الحدث الموجود مسبقًا FrameworkElement.EffectiveViewportChanged . هل هذه النقطة الفرعية كافية للقول (بشكل غير مباشر) أن التحميل الجزئي غير

• تتطلب مهمة العرض هذه (عند نسبة تكبير / تصغير عالية) ما يقرب من 3 .. 20 ثانية ، اعتمادًا على تعقيد المستند (كمية عناصر المتجه ، التأثيرات ، إلخ) ، حجم المستند ، ونسبة التكبير / التصغير. هذا التأخير أكبر من أن يقبله المستخدمون.
• يمكن أن تستهلك الصورة المقدمة (صورة نقطية) لصفحة PDF بأكملها مئات الميجابايت من ذاكرة الوصول العشوائي عندما تكون نسبة التكبير / التصغير عالية ، لأنها تعادل العرض بدقة عالية جدًا لكل بوصة.

يعرض MS Edge أجزاء من صفحة PDF المكبرة عند الطلب ، مما يعني أنه عندما يقوم المستخدم بتمرير هذه الأجزاء للعرض. تتجنب هذه التقنية التأخير الطويل قبل عرض الصفحة. أقترح أن المتطلبات الوظيفية تشير صراحةً إلى هذا السيناريو ، ولكن أيضًا مع دعم غير مباشر لـ async Task . عندما يتم تمرير جزء غير معروض (أو غير متوفر على الفور) إلى العرض ، يمكن لـ ScrollViewer ملء هذه المساحة مؤقتًا باستخدام Brush للتكوين ثم تشغيل حدث ، ويمكن لمعالج الحدث بدء async Task لتقديم (أو استرداد / تحميل) الجزء. في وقت لاحق ، عندما يكتمل Task ، يتم عرض الجزء الذي تم عرضه / استرداده / تحميله في ScrollViewer ، مما يغطي المساحة التي تم ملؤها مؤقتًا بـ Brush .

لا تتعلق هذه المشكلة فقط بالتكلفة العالية للتصيير بسرعة عالية. كما أنها قابلة للتطبيق على المحتوى الذي يتم استرداده عند الطلب. على سبيل المثال ، تخيل خريطة أو صورة قمر صناعي معروضة في ScrollViewer. يتم تنزيل أجزاء من الخريطة من الخادم فقط عندما يقوم المستخدم بتمريرها للعرض.

هل يجب فصل واجهات برمجة التطبيقات المتعلقة بالتكبير / التصغير إلى عنصر تحكم مشتق (مثل ZoomViewer) بحيث يكون ScrollViewer يتعلق بالتمرير بشكل صارم؟

على الرغم من أنني أقدر كثيرًا إضافة ScrollViewer.ZoomFactor ، إلا أنني فوجئت برؤيتها تمت إضافتها مباشرة إلى ScrollViewer. افترضت أنه سيكون من الأسهل والأكثر موثوقية وضع التكبير في فئة منفصلة (وليس بالضرورة فئة مشتقة). 3 طرق ممكنة على الأقل:

1. فئة تسمى ربما ZoomViewer لا ترث ScrollViewer ، لكنها تستخدم مثيل ScrollViewer كعنصر فرعي (في ControlTemplate ).
2. فئة تسمى ربما ZoomableScrollViewer ترث ScrollViewer .
3. دعم التكبير مباشرة في حدود ScrollViewer ، إذا لم يكن الأمر معقدًا أو فوضويًا بشكل مفرط.

17 قم بتوفير UX الافتراضي لدعم النقر الأوسط بالماوس والتمرير. (يجب)
18 دعم وضع النقر والتحريك عبر الماوس (على سبيل المثال ، نقل المحتوى داخل عارض PDF). (يجب)

أقترح التفكير في إزالة الدعم لـ 17 ، لأن 18 يعمل بشكل أفضل بكثير من 17 ، وبالكاد يستخدم أي شخص 17 في الممارسة. من المسلم به أنني قد أفكر في أن 17 تعني شيئًا آخر غير المعنى المقصود (وصف 17 هو جملة واحدة فقط ولست متأكدًا بنسبة 100٪ أنه يعني ما أعتقد أنه يعني). أليس صحيحًا أن نقول إن 18 سهل الاستخدام للغاية وسهل الاستخدام ، في حين أن 17 أمر محرج يكافح الجميع لاستخدامه ويتجنب استخدامه؟
(تتغير هذه المشكلة إذا كانت هناك حاجة إلى 17 لأسباب تتعلق بإمكانية الوصول ، ولكن حتى الآن لم أسمع أي شخص يقول إن 17 مشكلة تتعلق بإمكانية الوصول.)

4 قادرة على أداء الرسوم المتحركة التي تحركها المدخلات

الرقم 4 هو مسألة متعلقة بإمكانية الوصول. أود أن أطلب من ScrollViewer (وجميع عناصر التحكم الأخرى في WinUI) احترام إعدادات الوصول:

Windows 10 -> ابدأ -> الإعدادات -> سهولة الوصول -> العرض -> إظهار الرسوم المتحركة في Windows (تشغيل أو إيقاف).

لسوء الحظ ، على مر السنين ، لاحظت العديد من الأمثلة حيث تتجاهل تطبيقات Microsoft إعدادات الوصول إلى Windows. تم إيقاف تشغيل الرسوم المتحركة ولكن تطبيقات Microsoft تعرض الرسوم المتحركة على أي حال. يتسبب هذا في صعوبات حقيقية للمستخدمين الذين يعتمدون على إعدادات الوصول هذه. لا يتمتع كل شخص بالقدرة على الاستمتاع بالرسوم المتحركة دون التعرض لآثار جانبية سلبية. قد يجد المستخدمون الذين لا يواجهون أي صعوبات في عرض الرسوم المتحركة وما إلى ذلك صعوبة في فهم أهمية إعدادات إمكانية الوصول في Windows.

مرحبًا verelpode ، predavid ستقود العمل حول ScrollViewer الجديد لذا سأحترمها.

17 قم بتوفير UX الافتراضي لدعم النقر الأوسط بالماوس والتمرير. (يجب)
18 دعم وضع النقر والتحريك عبر الماوس (على سبيل المثال ، نقل المحتوى داخل عارض PDF). (يجب)

أقترح التفكير في إزالة الدعم لـ 17 ، لأن 18 يعمل بشكل أفضل بكثير من 17 ، وبالكاد يستخدم أي شخص 17 في الممارسة. من المسلم به أنني قد أفكر في أن 17 تعني شيئًا آخر غير المعنى المقصود (وصف 17 هو جملة واحدة فقط ولست متأكدًا بنسبة 100٪ أنه يعني ما أعتقد أنه يعني). أليس صحيحًا أن نقول إن 18 سهل الاستخدام للغاية وسهل الاستخدام ، في حين أن 17 أمر محرج يكافح الجميع لاستخدامه ويتجنب استخدامه؟
(تتغير هذه المشكلة إذا كانت هناك حاجة إلى 17 لأسباب تتعلق بإمكانية الوصول ، ولكن حتى الآن لم أسمع أي شخص يقول إن 17 مشكلة تتعلق بإمكانية الوصول.)

verelpode أعتقد أنك تفهم 17 بشكل صحيح وأوافق على أن 18 أكثر أهمية وعادة ما تكون أكثر سهولة من 17. ولكن يمكن أن تكون هناك سيناريوهات حيث يتم استخدام "النقر بالزر الأيسر والسحب" بالفعل لأغراض أخرى ، مثل التحديد أو السحب + الإفلات . بالنسبة لمثل هذه السيناريوهات ، سيكون من الجيد أن يتمكن التطبيق من تمكين التمرير عبر النقر الأوسط (17).

أنا شخصياً أستخدم النقر الأوسط للتمرير في المتصفحات من وقت لآخر ، حيث يؤدي النقر بزر الماوس الأيسر + السحب إما إلى تحديد النص أو سحب + إسقاط الصور. سيكون متصفح UWP معطلاً 18 وتمكين 17. يجب أن يكون كلاهما مشتركًا عبر خصائص منفصلة.

تضمين التغريدة

أنا شخصياً أستخدم النقر الأوسط للتمرير في المتصفحات من وقت لآخر ، حيث يؤدي النقر بزر الماوس الأيسر + السحب إما إلى تحديد النص أو سحب + إسقاط الصور.

النقطة الجيدة هي الحاجة إلى تجنب التسبب في توقف اختيار النص وما إلى ذلك عن العمل. ما رأيك في هذا الحل المحتمل: اجعل النقر الأوسط يبدأ في وضع التحريك المستند إلى الماوس (18) بدلاً من بدء وضع 17 المحرج.

عندما ألقي نظرة على ما تفعله التطبيقات الأخرى ، تسمح لك بعض التطبيقات ببدء التحريك المستند إلى الماوس عن طريق الضغط باستمرار على مفتاح المسافة أثناء النقر بزر الماوس الأيسر في منطقة المحتوى القابلة للتمرير. يسمح هذا الحل بالنقر بزر الماوس الأيسر للعمل بشكل طبيعي داخل منطقة المحتوى القابلة للتمرير لأن وضع التحريك يبدأ فقط عبر مفتاح المسافة + النقر. أجد التحريك عبر مفتاح المسافة + النقر مريحًا جدًا ومريحًا وسريعًا.

ومع ذلك ، فإن حل spacebar + click أسهل في التنفيذ في التطبيقات التي لا تحتاج إلى عرض أي مربعات نصية قابلة للتحرير داخل منطقة المحتوى القابلة للتمرير. إذا كانت المربعات النصية القابلة للتحرير موجودة في منطقة المحتوى القابلة للتمرير ، فستكون هناك مشكلة في أن ميزة التحريك تجعل المستخدمين غير قادرين على كتابة مسافات في مربعات النص. لذلك ، كما قلت ، يجب تفعيل هذه الميزة عبر أحد العقارات. بدلاً من ذلك ، لا تستخدم مفتاح المسافة ، وبدلاً من ذلك ، اجعل النقر الأوسط يبدأ في وضع التحريك المستند إلى الماوس (18) ، وهذا يلغي مشكلة عدم قدرة المستخدمين على كتابة مسافات في مربعات النص.

تضمين التغريدة
مع جميع المتصفحات وأيضًا مجموعة من التطبيقات الأخرى (Word ، Adobe Reader ، Outlook ، ...) التي تدعم الوضع 17 ، ما زلت أعتقد أنه يجب تنفيذ ذلك. فقط لأنك تجده محرجًا شخصيًا لا يعني أنه غير مفيد للآخرين. يجب أن يكون كلا الوضعين قابلين للاشتراك بالطبع ، ثم يمكن للمطورين تحديد ما يجب استخدامه في تطبيقهم. سيسمح هذا أيضًا بسلوك spacebar + click ، ​​إذا كان ذلك منطقيًا لأحد التطبيقات: قم بتمكين الوضع 18 على مفتاح المسافة لأسفل ، وقم بتعطيله مرة أخرى على مفتاح المسافة لأعلى.

lukasf - حسنًا ، يبدو جيدًا. اعتقدت أنك تقصد أنه إذا لم يمنع وضع التحريك (18) تحديد النص أو سحب + إسقاط الصور وما إلى ذلك ، فستتوقف عن استخدام الوضع 17 والتبديل إلى 18 ، ولكن الآن أرى أن تفضيلك هو في الواقع لكلا الوضعين كن داعما.

شكرًا لك على ملاحظاتك verelpode و lukasf ، أنا أتفق معك في أننا لنسميها 17 = سرعة ثابتة تعتمد على الماوس وتحريكها و 18 = بالغسل على أساس الماوس.

لقد أرسلت للتو PR https://github.com/microsoft/microsoft-ui-xaml/pull/1472 لإضافة بعض الأعمال الاستقصائية التي قمت بها. أردت أن أرى مدى قربي من دعم كل من 17 و 18 باستخدام Scroller اليوم.

سارت الأمور على ما يرام بالنسبة لـ 18 = التحريك المستند إلى الماوس ، على الرغم من أن الحل مرتبط بواجهة مستخدم بنسبة 100٪ ، على عكس التجارب القائمة على اللمس أو التي تعتمد على عجلة الماوس. لقد استخدمت طريقة ScrollTo أثناء الاستماع إلى حدث PointerMoved الخاص بالماوس. في النهاية ، نرغب في أن يتعامل مكون InteractionTracker الأساسي مع حركات الماوس كما هو الحال مع حركات الأصابع.

الأمور أكثر تعقيدًا بالنسبة لـ 17 = تحريك السرعة الثابتة المستند إلى الماوس (تجربة لا أحبها شخصيًا). النموذج الأولي بعيد كل البعد عن المثالية ولم أحاول معالجة جميع القضايا ، ولكن هناك قضيتان على وجه الخصوص مقلقة:

• أثناء تحريك السرعة الثابتة (أي 0-speed-decay panning) ، لا أعتقد أن هناك طريقة باستخدام Scroller الحالي لإيقاف الحركة دون القفز إلى موضع أقدم (باستخدام ScrollBy (0 ، 0)) . ليس من الممكن بشكل موثوق معرفة المدى الذي تقدم فيه مؤشر ترابط التكوين أمام مؤشر ترابط واجهة المستخدم. لذلك ستكون هناك حاجة إلى بعض واجهة برمجة تطبيقات Scroller العامة الجديدة لإيقاف السرعة بطريقة خالية من الأخطاء.
• لم أتمكن من الحفاظ على التقاط الماوس بعد حدث PointerReleased الخاص بالماوس. يبدو أن ميزة إطار عمل Xaml الجديدة ستكون مطلوبة لتحقيق ذلك.
  على أي حال ، قد تكون هذه حالة أخرى حيث نرغب في InteractionTracker الأساسي أن يتعامل مع بعض التجربة مباشرة.
  سأضع هذه الأمور في الاعتبار بالتأكيد عند مناقشة ميزات Scroller / InteractionTracker المستقبلية.

تضمين التغريدة

سارت الأمور بشكل جيد بالنسبة لـ 18 = التحريك باستخدام الماوس ، ... ...
الأمور أكثر تعقيدًا بالنسبة لـ 17 = تحريك السرعة الثابتة المستند إلى الماوس (تجربة لا أحبها شخصيًا).

نتائج مثيرة للاهتمام! في هذه الحالة ، مع الأخذ في الاعتبار الصعوبات مع 17 = سرعة ثابتة ، وبالنظر إلى أنه يمكن تنفيذ 18 بطريقة لا تمنع الاستخدام العادي للنقرة اليسرى ، فأنا في رأيي الشخصي أعتقد أنه من المحتمل أن يتم تحديث الاقتراح إلى التخلي عن 17 ودعم 18 بدلاً من ذلك ، لكن من المسلم به أنني لا أعرف عدد المستخدمين الذين سيشتكون إذا تم التخلي عن 17 = السرعة الثابتة.

شكرًا لك RBrid على هذه التحقيقات. من الرائع سماع أن الوضع 18 يعمل بالفعل! أوافق على أنه يجب التعامل معه بشكل مثالي بواسطة InteractionTracker ، للسماح بالتشغيل السلس حتى أثناء تحميل مؤشر ترابط واجهة المستخدم.

verelpode تم تعيين كلا الوضعين على "should". لذلك ، إذا كانت الجهود عالية جدًا لتحقيق الوضع 17 ، فيمكن تركها (وربما إضافتها لاحقًا ، إذا لزم الأمر). لكن ربما يجد شخص ما طريقة لإدراك ذلك دون الكثير من التغييرات.

آمل أن يكون لدى ScrollViewer الجديد القدرة على تعطيل أو تخصيص Zoom باستخدام مفتاح "Ctrl".