Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Panel, Genişletilebilir Uygulama Biçimlendirme Dili (XAML) düzen sistemi çalıştırıldığında ve uygulama kullanıcı arabiriminiz işlendiğinde içerdiği alt öğeler için düzen davranışı sağlayan bir nesnedir.
Önemli API'ler: Panel, ArrangeOverride, MeasureOverride
Panel sınıfından özel bir sınıf türeterek XAML düzeni için özel paneller tanımlayabilirsiniz. MeasureOverride geçersiz kılarak ve ArrangeOverridealt öğeleri ölçen ve yerleştiren mantığı sağlayarak paneliniz için davranış sağlarsınız.
Paneli temel sınıfı
Özel bir panel sınıfı tanımlamak için doğrudan Panel sınıfından türetebilir veya Kılavuz veya StackPanel gibi korumalı olmayan pratik panel sınıflarından birinden türetebilirsiniz. Panel'den türetmek daha kolaydır, çünkü hali hazırda yerleşim davranışına sahip bir panelin mevcut yerleşim mantığını etkisiz hale getirmek zor olabilir. Ayrıca davranışa sahip bir panel, panelinizin düzen özellikleriyle ilgili olmayan mevcut özelliklere sahip olabilir.
Panelözel paneliniz şu API'leri devralır:
- Çocuklar özelliği.
- Arka Plan, ChildrenTransitions ve IsItemsHost özellikleri ve bağımlılık özelliği tanımlayıcıları. Bu özelliklerden hiçbiri sanal değildir, bu nedenle genellikle bunları geçersiz kılmaz veya değiştirmezsiniz. Bu özelliklere, değerleri okumak için bile özel panel senaryoları için genellikle ihtiyacınız yoktur.
- Düzen geçersiz kılma yöntemleri MeasureOverride ve ArrangeOverride. Bunlar başlangıçta FrameworkElement tarafından tanımlanmıştı. Temel Panel sınıfı bunları geçersiz kılmaz, ancak Grid gibi pratik panellerde yerel kod olarak uygulanan ve sistem tarafından çalıştırılan geçersiz kılma uygulamaları vardır. ArrangeOverride ve MeasureOverride için yeni (veya katkılı) uygulamalar sağlamak, özel panel tanımlamak için gereken çabanın büyük bir kısmıdır.
- FrameworkElement, UIElement ve DependencyObjectgibi Height, Görünürlük vb. API'lerin tümü. Bazen düzen geçersiz kılmalarınızda bu özelliklerin değerlerine başvurursunuz, ancak bunlar sanal değildir, bu nedenle bunları genellikle geçersiz kılmaz veya değiştirmezsiniz.
Bu odak, XAML düzeni kavramlarını açıklamaktır, böylece özel bir panelin düzende nasıl davranabileceği ve davranması gerektiğiyle ilgili tüm olasılıkları göz önünde bulundurabilirsiniz. Doğrudan içeri atlayıp örnek bir özel panel uygulaması görmek isterseniz bkz. BoxPanel,örnek bir özel panel.
Çocuk özelliği
Children özelliği özel bir panelle ilgilidir çünkü Panel sınıfından türeyen tüm sınıflar, içerdikleri alt öğeleri bir koleksiyonda depolamak içinChildren özelliğini kullanır. Children, Panel sınıfı için XAML içerik özelliği olarak belirlenmiştir ve Panel sınıfından türetilen tüm sınıflar XAML içerik özelliği davranışını miras alabilir. Bir özellik XAML içerik özelliği olarak belirlenmişse, XAML işaretlemesi, işaretlemede bu özelliği belirtirken bir özellik öğesini atlayabilir ve değerler anında işaretleme alt öğeleri ("içerik") olarak ayarlanır. Örneğin, Panel'den yeni bir davranış tanımlamadan CustomPanel adlı bir sınıf türetirseniz, yine de şu işaretlemeyi kullanabilirsiniz:
<local:CustomPanel>
<Button Name="button1"/>
<Button Name="button2"/>
</local:CustomPanel>
Bir XAML ayrıştırıcısı bu işaretlemeyi okuduğunda, Children tüm Panel türetilmiş türler için XAML içerik özelliği olarak bilinir, bu nedenle ayrıştırıcı iki Button öğesini Children özelliğinin UIElementCollection değerine ekler. XAML içerik özelliği, bir kullanıcı arabirimi tanımı için XAML işaretlemesinde üst-alt ilişkisini daha akıcı hale getirir. XAML içerik özellikleri ve XAML ayrıştırıldığında koleksiyon özelliklerinin nasıl doldurulduğundan daha fazla bilgi için XAML söz dizimi kılavuzuna bakın.
Alt özelliğinin değerini koruyan koleksiyon türü, UIElementCollection sınıfıdır. UIElementCollection, zorlanan öğe türü olarak UIElement kullanan kesin olarak belirlenmiş bir koleksiyondur. UIElement , yüzlerce pratik UI öğesi türü tarafından devralınan bir temel türdür, bu nedenle buradaki tür zorlaması kasıtlı olarak gevşektir. Ancak, bir Paneliiçinde doğrudan bir Fırça bulunduramayacağınızı gerektirir ve genel olarak, yalnızca kullanıcı arayüzünde görünmesi ve düzenin bir parçası olması beklenen öğelerin Paneliiçinde alt öğe olarak bulunabileceği anlamına gelir.
Genellikle, özelleştirilmiş bir panel, XAML tanımına göre herhangi bir UIElement alt öğesini, as-isAlt özelliğinin özelliklerini kullanarak kabul eder. Gelişmiş bir senaryo olarak, düzen geçersiz kılmalarınızdaki koleksiyon üzerinde yineleme yaptığınızda alt öğelerin daha fazla tür denetimini destekleyebilirsiniz.
Geçersiz kılmalarda Çocuklar koleksiyonu üzerinde döngü yapmanızı yanı sıra, panel mantığınız da Children.Counttarafından etkilenebilir. Öğe sayısına kısmen de olsa dayanan, istenen boyutlar ve tek tek öğelerin diğer özellikleri yerine alan ayıran bir mantığınız olabilir.
Düzen yöntemlerini geçersiz kılma
Düzen geçersiz kılma yöntemlerinin (MeasureOverride ve ArrangeOverride) temel modeli, tüm alt öğeleri yinelemeleri ve her alt öğenin özel düzen yöntemini çağırmaları gerektiğidir. İlk düzen döngüsü, XAML düzen sistemi kök pencere için görseli ayarlarken başlar. Her bir üst öğe kendi alt öğelerinde düzeni çağırdığında, bu, düzenin bir parçası olması gereken her olası UI öğesine düzen yöntemlerine yapılan bir çağrının yayılmasını sağlar. XAML düzeninde iki aşama vardır: ölçü ve sonra düzenleme.
Temel Panel sınıfından MeasureOverride ve ArrangeOverride için yerleşik bir düzen yöntemi davranışı edinemezsiniz. içindeki öğeler, Alt öğeleri, XAML görsel ağacının bir parçası olarak otomatik olarak işlenmez. Children'nde bulduğunuz her bir öğede, MeasureOverride ve ArrangeOverride uygulamalarınız aracılığıyla bir düzenleme geçişi yaparak düzenleme yöntemlerini çağırmak ve bu şekilde öğelerin düzen sürecinde tanınmasını sağlamak size bağlıdır.
Kendi devralma işleminiz olmadığı sürece düzen geçersiz kılmalarında temel uygulamaları çağırmak için bir neden yoktur. Düzen davranışı için yerel yöntemler (varsa) her durumda çalışır ve geçersiz kılmalardan baz uygulama metodunu çağırmamak yerel davranışın oluşmasını engellemez.
Ölçüm geçişi sırasında, yerleşim mantığınız, bu alt öğe üzerindeki Measure yöntemini çağırarak her bir alt öğeyi istenen boyutuna göre sorgular. Measure yöntemini çağırmak DesiredSize özelliğinin değerini oluşturur. MeasureOverride dönüş değeri, panelin kendisi için istenilen boyuttur.
Düzenleme aşaması sırasında, alt öğelerin konumları ve boyutları x-y uzayında belirlenir ve düzenleme kompozisyonu oluşturulur. Kodunuzun, düzen sisteminin öğenin düzene ait olduğunu algılaması için, Alt içindeki her alt öğede Düzenleme çağrısı yapması gerekir. Düzenleme çağrısı, oluşturma ve işlemenin bir öncüsüdür; oluşturma işlemi için gönderildiğinde düzen sistemini bu öğenin nereye gittiğini bildirir.
Birçok özellik ve değer, düzen mantığının çalışma zamanında nasıl çalışacağına katkıda bulunur. Düzenleme sürecini düşünmenin bir yolu, alt öğe içermeyen öğelerin (genellikle kullanıcı arabirimindeki en derin iç içe geçmiş öğe) ölçümlerini önce sonlandırabilen öğeler olmasıdır. İstedikleri boyuta etki eden alt öğelere bağımlılıkları yoktur. Kendi tercih ettikleri boyutlar olabilir ve düzen gerçekleşene kadar bunlar boyut önerileridir. Ardından ölçüm aşaması, kök öğenin ölçümlerine sahip olmasına ve tüm ölçümlerin sonlandırılmasına kadar görsel ağaçta yukarı doğru yürümeye devam eder.
Aday düzeni, geçerli uygulama penceresine sığmalı, aksi takdirde kullanıcı arayüzünün bölümleri kırpılacaktır. Paneller genellikle kırpma mantığının belirlendiği yerdir. Panel mantığı, MeasureOverride uygulamasının içinden hangi boyutun kullanılabilir olduğunu belirleyebilir ve boyut kısıtlamalarını alt öğelere göndermesi ve her şeyin en iyi şekilde sığması için alanı çocuklar arasında bölmesi gerekebilir. Düzenin sonucu ideal olarak, düzenin tüm bölümlerinin çeşitli özelliklerini kullanan ancak yine de uygulama penceresine sığan bir şeydir. Bunun için hem panellerin düzen mantığı için iyi bir uygulama hem de bu paneli kullanarak bir kullanıcı arabirimi oluşturan herhangi bir uygulama kodunun parçası olarak mantıklı bir kullanıcı arabirimi tasarımı gerekir. Genel kullanıcı arabirimi tasarımı, uygulamaya sığabilecekten daha fazla alt öğe içeriyorsa hiçbir panel tasarımı iyi görünmeyecektir.
Düzen sisteminin çalışmasını sağlayanların büyük bir kısmı, FrameworkElement temel alan tüm öğelerin kapsayıcıda alt öğe olarak hareket ederken kendi doğal davranışlarından bazılarını zaten içermesidir. Örneğin, FrameworkElement'in, düzen davranışını etkileyen veya düzenin çalışması için gerekli olan birkaç API'si vardır. Bunlar şunları içerir:
- DesiredSize (aslında bir UIElement özelliği)
- ActualHeight ve ActualWidth
- Yükseklik ve Genişlik
- Kenar Boşluğu
- LayoutUpdated etkinliği
- YatayHizalama ve DikeyHizalama
- ArrangeOverride ve MeasureOverride yöntemleri
- Düzenleme ve Ölçme yöntemleri: Bunlar, öğe düzeyi düzen eylemini işleyen FrameworkElement düzeyinde tanımlanan yerel uygulamalara sahiptir
Ölçü Aşımı
MeasureOverride yöntemi, düzenleme sistemi tarafından panelin başlangıç DesiredSize olarak kullanılan bir dönüş değerine sahiptir, bu değer panelin üst öğesi tarafından düzende Measure yöntemi çağrıldığında belirlenir. Yöntemin içindeki mantıksal seçimler, ne döndürdüğü kadar önemlidir ve mantık genellikle hangi değerin döndürüldüğüne etki eder.
Tüm MeasureOverride uygulamaları Childreniçinde döngü yapmalı ve her alt öğede Measure yöntemini çağırmalıdır. Measure yöntemini çağırmak DesiredSize özelliğinin değerini oluşturur. Bu, panelin kendisine ne kadar alan gerektiğini ve bu alanın öğeler arasında nasıl bölündüğünü veya belirli bir alt öğe için nasıl boyutlandırıldığını bildirebilir.
İşte çok temel bir MeasureOverride yönteminin iskeleti:
protected override Size MeasureOverride(Size availableSize)
{
Size returnSize; //TODO might return availableSize, might do something else
//loop through each Child, call Measure on each
foreach (UIElement child in Children)
{
child.Measure(new Size()); // TODO determine how much space the panel allots for this child, that's what you pass to Measure
Size childDesiredSize = child.DesiredSize; //TODO determine how the returned Size is influenced by each child's DesiredSize
//TODO, logic if passed-in Size and net DesiredSize are different, does that matter?
}
return returnSize;
}
Öğeler genellikle düzen için hazır olduklarında doğal bir boyuta sahiptir. Ölçü geçtikten sonra, eğer Measure için geçirdiğiniz availableSize daha küçükse, DesiredSize doğal boyutu gösterebilir. Doğal boyut, kullanılabilirSize boyutunuz için Measure'te geçtiğiniz boyuttan büyükse, DesiredSize, kullanılabilirSizeile sınırlandırılır. Ölçü'in iç uygulaması böyle davranır ve düzen geçersiz kılmalarınız bu davranışı dikkate almalıdır.
Bazı öğelerin doğal bir boyutu yoktur çünkü Yükseklik ve Genişlikiçin Otomatik değerleri vardır. Bu öğeler, tam kullanılabilir boyutukullanır, çünkü Otomatik değeri tam olarak bunu temsil eder: öğeyi kullanılabilir en yüksek boyuta boyutlandırın. Bu boyut, hemen üst düzen yerleşim elemanının Measure çağrısı yaparak kullanılabilir boyutlailetişim kurduğu zamandır. Uygulamada, her zaman bir kullanıcı arabiriminin boyutlandırıldığı bazı ölçümler vardır (en üst düzey pencere olsa bile). Sonuç olarak, ölçü geçişi tüm Otomatik değerlerini üst kısıtlamalara çözer ve tüm Otomatik değer öğeleri gerçek ölçümler alır (düzen tamamlandıktan sonra ActualWidth ve ActualHeightdenetleyerek elde edebilirsiniz).
En az bir boyutu sonsuz olan Ölçü için bir boyut belirlemek yasaldır; bu, panelin kendisini içerikle uyumlu hale getirmek için boyutlandırmayı deneyebileceğini belirtir. Ölçülen her alt öğe, doğal boyutunu kullanarak DesiredSize değerini ayarlar. Ardından, düzenleme geçişi sırasında panel genellikle bu boyutu kullanarak düzenler.
TextBlock gibi metin öğeleri, Height veya Width değeri ayarlanmamış olsa bile metin dizesine ve metin özelliklerine göre hesaplanan ActualWidth ve ActualHeight değerine sahiptir ve bu boyutlar panel mantığınız tarafından dikkate alınmalıdır. Metni kırpmak özellikle kötü bir kullanıcı arabirimi deneyimidir.
Uygulamanız istenen boyut ölçülerini kullanmasa bile, her alt öğede Ölçü yöntemini çağırmak en iyisidir; çünkü Ölçü'in çağrılmasıyla tetiklenen içsel ve yerel davranışlar vardır. Bir öğenin düzene katılması için, ölçü geçişi sırasında her alt öğe üzerinde Ölçü çağrılmış olmalı ve düzenleme geçişi sırasında Düzenleme yöntemi çağrılmış olmalıdır. Bu yöntemlerin çağrılması nesnede iç bayraklar ayarlar ve görsel ağacı oluştururken ve kullanıcı arabirimini işlerken sistemin düzen mantığının ihtiyaç duyduğu değerleri (DesiredSize özelliği gibi) doldurur.
İpuçları ve rehberlik
- İdeal olarak, özel bir panel kullanıcı arabirimi bileşiminde ilk gerçek görsel olarak uygun olmalıdır; belki de Page'in hemen altında, UserControl, veya XAML sayfası kökü olan başka bir öğe düzeyinde olabilir.
uygulamalarında, değerleri incelemeden düzenli olarak SizeMeasureOverride giriş döndürmeyin. Dönüş Boyut içinde Infinity değeri varsa, bu çalışma zamanı yerleşim mantığında istisnalar ortaya çıkarabilir. Sonsuzluk değeri, kaydırılabilir ve bu nedenle maksimum yüksekliğe sahip olmayan ana uygulama penceresinden gelebilir. Diğer kaydırılabilir içerik aynı davranışa sahip olabilir. - MeasureOverride uygulamalarında yapılan bir diğer yaygın hata da yeni bir varsayılan Boyut döndürmektir (yükseklik ve genişlik değerleri 0'dır). Bu değerle başlayabilirsiniz ve paneliniz, çocukların hiçbirinin işlenmemesi gerektiğine karar verirse bu, doğru değer olabilir. Ancak varsayılan Boyut, panelinizin konağı tarafından doğru şekilde boyutlandırılmamasına neden olur. Kullanıcı arabiriminde alan istemez, bu nedenle alan almaz ve görüntülenmez. Aksi takdirde tüm panel kodunuz düzgün çalışıyor olabilir, ancak sıfır yükseklik, sıfır genişlikle oluşturulmuşsa yine de panelinizi veya içeriğinizi görmezsiniz.
- Geçersiz kılmalar içinde, alt öğeleri FrameworkElement'e atama ve düzenin sonucu olarak hesaplanan özellikler olan özellikle ActualWidth ve ActualHeightkullanmaktan kaçının. En yaygın senaryolar için, mantığı çocuk elemanın DesiredSize değerine dayandırabilirsiniz ve bu durumda çocuk elemanın Height veya Width ile ilgili özelliklerine ihtiyacınız olmaz. Öğenin türünü bildiğiniz ve bir görüntü dosyasının doğal boyutu gibi ek bilgilere sahip olduğunuz özel durumlar için, öğenizin özel bilgilerini kullanabilirsiniz çünkü düzen sistemleri tarafından etkin olarak değiştirilen bir değer değildir. Düzen mantığının bir parçası olarak düzen hesaplanan özellikleri dahil etme, kasıtsız düzen döngüsü tanımlama riskini önemli ölçüde artırır. Bu döngüler geçerli bir düzenin oluşturulamama durumuna neden olur ve döngü kurtarılamazsa sistem bir LayoutCycleException oluşturabilir.
- Paneller genellikle mevcut alanlarını birden çok alt öğe arasında böler, ancak alanın tam olarak nasıl bölündüğü değişir. Örneğin Kılavuz, boşluğu Kılavuz hücrelerine bölmek için RowDefinition ve ColumnDefinition değerlerini kullanan düzen mantığı uygular ve hem yıldız boyutlandırmayı hem de piksel değerlerini destekler. Bunlar piksel değerleriyse, her alt öğe için kullanılabilen boyut zaten bilinir; bu nedenle kılavuz stili bir Ölçüiçin giriş boyutu olarak geçirilen boyut budur.
- Paneller, öğeler arasında dolgu için rezerv alan oluşturabilir. Bunu yaparsanız, ölçümleri Margin veya herhangi bir Padding özelliğinden ayrı bir özellik olarak tanımladığınızdan emin olun.
- Öğelerin ActualWidth ve ActualHeight özelliklerinin, önceki bir düzen geçişine dayanan değerleri olabilir. Değerler değişirse, uygulama kullanıcı arabirimi kodu, çalıştırılacak özel bir mantık varsa öğelere LayoutUpdated işleyicileri yerleştirebilir, ancak panel mantığının genellikle olay işlemeyle ilgili değişiklikleri denetlemesi gerekmez. Düzen sistemi, düzenle ilgili bir özellik değeri değiştiği için ve panelin MeasureOverride veya ArrangeOverride uygun koşullarda otomatik olarak çağrıldığından, düzenin ne zaman yeniden yapılması gerektiğini belirlemektedir.
YerleştirmeGeçersizKılma
ArrangeOverride yöntemi, panelin kendisini oluştururken düzen sistemi tarafından kullanılan bir Boyut dönüş değerine sahiptir ki bu, paneldeki üst öğe tarafından düzende Yerleştir yöntemi çağrıldığında geçerlidir. finalSize girişi ve ArrangeOverride tarafından döndürülen Size'nin aynı olması yaygındır. Değilse, bu, panelin kendisini düzen talebindeki diğer katılımcıların mevcut olandan farklı bir boyuta dönüştürmeye çalıştığı anlamına gelir. Son boyut, panel kodunuz aracılığıyla düzenin ölçü aşamasının daha önce çalıştırılmasına dayanıyordu, bu nedenle farklı bir boyut iade etmek tipik değildir: bu, ölçü mantığını kasıtlı olarak yoksaydığınız anlamına gelir.
Boyut, Infinity bileşenine sahip olarak geri döndürmeyin. Böyle bir Boyutu kullanılmaya çalışılması, iç düzenden bir istisna oluşturur.
Tüm ArrangeOverride uygulamaları Altarasında döngü yapmalı ve her alt öğede Düzenleme yöntemini çağırmalıdır. Ölçügibi, Düzenle'in bir dönüş değeri yoktur. Ölçüden farklı olarak, sonuç olarak hiçbir hesaplanan özellik ayarlanmaz (ancak söz konusu öğe genellikle bir LayoutUpdated olayı tetikler).
Bir ArrangeOverride yönteminin çok temel bir iskeleti aşağıdadır:
protected override Size ArrangeOverride(Size finalSize)
{
//loop through each Child, call Arrange on each
foreach (UIElement child in Children)
{
Point anchorPoint = new Point(); //TODO more logic for topleft corner placement in your panel
// for this child, and based on finalSize or other internal state of your panel
child.Arrange(new Rect(anchorPoint, child.DesiredSize)); //OR, set a different Size
}
return finalSize; //OR, return a different Size, but that's rare
}
Düzenin ayarlanması, önünde ölçü geçişi olmadan gerçekleşebilir. Ancak, bu yalnızca düzen sistemi önceki ölçümleri etkileyebilecek hiçbir özelliğin değişmediğini belirlediğinde gerçekleşir. Örneğin, bir hizalama değişirse, belirli bir öğeyi yeniden ölçmeye gerek yoktur çünkü hizalama seçimi değiştiğinde DesiredSize değişmez. Öte yandan, ActualHeight düzendeki herhangi bir öğede değişirse yeni bir ölçüm işlemi gerekir. Düzen sistemi, gerçek ölçü değişikliklerini otomatik olarak algılar ve ölçü geçişini yeniden çağırır ve sonra başka bir düzenleme geçişi çalıştırır.
Düzenle girişi bir değerini alır. Bu Rect oluşturmanın en yaygın yolu, Noktası girişi ve Boyutu girişi olan oluşturucuyu kullanmaktır. Noktası, öğe için sınırlayıcı kutunun sol üst köşesinin yerleştirilmesi gereken noktadır. Boyut, bu öğeyi işlemek için kullanılan boyutlardır. Bu öğe için genellikle DesiredSize değerini, yani bu Boyut değerini kullanırsınız, çünkü düzen yerleşimindeki tüm öğeler için DesiredSize oluşturmak ölçü geçişinin amacıydı. (Ölçüm aşaması, düzen sisteminin düzenleme aşamasına ulaştığında, öğelerin yerleştirilme şeklini optimize edebilmesi için öğelerin yinelemeli bir şekilde boyutlandırmasını belirler.)
Genellikle ArrangeOverride uygulamaları arasında değişiklik gösteren şey, panelin her alt öğeyi nasıl düzenlediğini belirleyen mantığın Point bileşenidir. Canvas gibi mutlak bir konumlandırma paneli ,Canvas.Left ve Canvas.Top değerleri aracılığıyla her öğeden aldığı açık yerleştirme bilgilerini kullanır. Grid gibi bir boşluk bölme panelinde, kullanılabilir alanı hücrelere ayıran matematiksel işlemler yapılır ve her hücrenin içeriğinin yerleştirileceği yer için bir x-y değeri olur. StackPanel gibi uyarlamalı bir panel, içeriği yönlendirme boyutuna sığdırmak için kendisini genişletiyor olabilir.
Düzendeki öğeler üzerinde, doğrudan denetlediğiniz ve Yerleştir'e geçirdiğiniz öğelerin ötesinde hala ek konumlandırma etkileri vardır. Bunlar, tüm FrameworkElement türetilmiş türler için ortak olan ve metin öğeleri gibi diğer bazı türler tarafından genişletilen Düzenleme'in iç yerel uygulamasından gelir. Örneğin, öğelerde kenar boşluğu ve hizalama olabilir, bazılarında ise iç boşluk bulunabilir. Bu özellikler genellikle etkileşim kurar. Daha fazla bilgi için bkz. hizalama, kenar boşluğu ve doldurma.
Paneller ve denetimler
Özelleştirilmiş bir denetim olarak derlenmesi gereken işlevleri özelleştirilmiş bir panele yerleştirmekten kaçının. Panelin rolü, içinde bulunan tüm alt öğe içeriklerini, otomatik olarak gerçekleşen bir düzen işlevi olarak sunmaktır. Panel içeriğe süslemeler ekleyebilir (Kenarlık sunduğu öğenin çevresine kenarlık eklemesine benzer) veya doldurma gibi düzen ile ilgili diğer ayarlamaları gerçekleştirebilir. Görsel ağaç çıktısını raporlama ve alt öğelerden gelen bilgileri kullanma işlemlerinin ötesine taşırken sadece bu kadar ileri gitmelisiniz.
Kullanıcı tarafından erişilebilen herhangi bir etkileşim varsa, panel değil özel bir denetim yazmanız gerekir. Örneğin, kaydırma çubukları, başparmaklar vb. etkileşimli denetim parçaları olduğundan, amaç kırpmayı önlemek olsa bile panel, sunduğu içeriğe kaydırma görünüm penceresi eklememelidir. (sonuçta içerikte kaydırma çubukları olabilir, ancak bunu çocuğun mantığına bırakmanız gerekir. Kaydırmayı düzen işlemi olarak ekleyerek zorlamayın.) Bir denetim oluşturabilir ve söz konusu denetimde içerik sunma söz konusu olduğunda, denetimin görsel ağacında önemli bir rol oynayan özel bir panel yazabilirsiniz. Ancak denetim ve panel ayrı kod nesneleri olmalıdır.
Denetim ve panel arasındaki ayrımın önemli olmasının bir nedeni, Microsoft UI Otomasyonu ve erişilebilirliktir. Paneller, mantıksal bir davranış değil görsel düzen davranışı sağlar. Kullanıcı arabirimi öğesinin görsel olarak nasıl göründüğü, genellikle erişilebilirlik senaryoları için önemli olan kullanıcı arabiriminin bir yönü değildir. Erişilebilirlik, bir uygulamanın kullanıcı arabirimini anlamak için mantıksal olarak önemli olan bölümlerini ortaya çıkarmaktır. Etkileşim gerektiğinde, denetimler etkileşim olanaklarını UI Otomasyonu altyapısında kullanıma sunmalıdır. Daha fazla bilgi için bkz. Özel otomasyon ara birimleri.
Diğer düzen API'leri
Düzen sisteminin parçası olan ancak Panel tarafından bildirilmeyen başka API'ler de vardır. Bunları bir panel uygulamasında veya panel kullanan özel bir denetimde kullanabilirsiniz.
- UpdateLayout, InvalidateMeasure ve InvalidateArrange , düzen geçişi başlatan yöntemlerdir. InvalidateArrange bir ölçü geçişi tetiklemeyebilir, ancak diğer ikisi tetikleyebilir. Bu yöntemlerin neredeyse kesinlikle bir düzen döngüsüne neden olacağından, onları hiçbir zaman bir düzen yöntemini geçersiz kılma içinde çağırmayın. Denetim kodunun da genellikle bunları çağırması gerekmez. Çoğu düzen yönü, Genişlik gibi çerçeve tanımlı düzen özelliklerinde yapılan değişikliklerin algılanmasıyla otomatik olarak tetiklenir.
- LayoutUpdated , öğenin düzeninin bazı yönleri değiştiğinde tetiklenen bir olaydır. Bu panellere özgü değildir; olayı FrameworkElement tarafından tanımlanır.
- SizeChanged, yalnızca düzen geçişleri sonlandırıldıktan sonra tetiklenen ve ActualHeight ya da ActualWidth değiştiğini gösteren bir olaydır. Bu başka bir FrameworkElement olayıdır. LayoutUpdated'nin tetiklendiği, ancak SizeChanged'in tetiklenmediği durumlar vardır. Örneğin iç içerik yeniden düzenlenebilir, ancak öğenin boyutu değişmedi.
İlgili konular
Referans
Kavramlar
Windows developer