Aracılığıyla paylaş

Stillenebilir Denetimleri Tasarlama Yönergeleri

  • Makale

Bu belgede, kolayca stilize ve cazip olmasını amaçladığınız bir denetim tasarlarken göz önünde bulundurmanız gereken en iyi yöntemler kümesi özetleniyor. Yerleşik WPF denetim kümesi için tema denetimi stilleri üzerinde çalışırken çok sayıda deneme ve hata aracılığıyla bu en iyi yöntemler kümesine geldik. Başarılı bir stil oluşturmanın, stilin kendisi kadar iyi tasarlanmış bir nesne modelinin işlevi olduğunu öğrendik. Bu belge için hedeflenen hedef kitle, stil yazarı değil denetim yazarıdır.

Terimler

"Stil oluşturma ve şablon oluşturma", denetim yazarının denetimin görsel yönlerini denetimin stiline ve şablonuna ertelemesini sağlayan teknoloji paketine başvurur. Bu teknoloji paketi şunları içerir:

  • Stiller (özellik ayarlayıcıları, tetikleyiciler ve görsel taslaklar dahil).

  • Kaynaklar.

  • Denetim şablonları.

  • Veri şablonları.

Stil oluşturmaya ve şablon oluşturmaya giriş için bkz . Stil oluşturma ve Şablon Oluşturma.

Başlamadan Önce: Denetiminizi Anlama

Bu yönergelere geçmeden önce, denetiminizin ortak kullanımını anlamanız ve tanımlamış olmanız önemlidir. Stil oluşturma, genellikle akla aykırı olasılıklar sunar. Yaygın olarak kullanılmak üzere yazılan denetimler (birçok uygulamada, birçok geliştirici tarafından), stilin denetimin görsel görünümünde çok kapsamlı değişiklikler yapmak için kullanılabilmesi zorluğuyla karşı karşıya kalır. Aslında, stil denetimi denetim yazarının amacına benzemeyebilir. Stil tarafından sunulan esneklik temelde sınırsız olduğundan, kararlarınızın kapsamını daraltmanıza yardımcı olması için ortak kullanım fikrini kullanabilirsiniz.

Denetiminizin ortak kullanımını anlamak için denetimin değer teklifi hakkında düşünmek iyi olur. Denetiminiz, başka hiçbir denetimin sunabildiği tabloya ne getirir? Ortak kullanım, belirli bir görsel görünümü değil, denetimin felsefesini ve kullanımı hakkında makul bir beklenti kümesini ifade eder. Bu anlayış, oluşturma modeli ve ortak örnekte denetimin stil tanımlı davranışları hakkında bazı varsayımlarda bulunmanıza olanak tanır. ComboBoxÖrneğin, ortak kullanımı anlamak, belirli ComboBox bir köşenin yuvarlatılıp yuvarlanmadığı hakkında size içgörü ComboBox sağlamaz, ancak büyük olasılıkla bir açılır pencereye ihtiyaç duyduğu ve açık olup olmadığı konusunda size bir fikir verir.

Genel Yönergeler

  • Şablon sözleşmelerini kesinlikle zorunlu kılmayın. Denetimin şablon sözleşmesi, bir denetimin düzgün çalışması için gereken veya beklenen öğeler, komutlar, bağlamalar, tetikleyiciler ve hatta özellik ayarlarından oluşabilir.

    • Sözleşmeleri mümkün olduğunca en aza indirin.

    • Tasarım sırasında (bir tasarım aracı kullanılırken) bir denetim şablonunun tamamlanmamış durumda olması beklentisine göre tasarlayın. WPF bir "oluşturma" durum altyapısı sunmaz, bu nedenle denetimlerin böyle bir durumun geçerli olabileceği beklentisiyle derlenmesi gerekir.

    • Şablon sözleşmesinin herhangi bir yönü izlenmediği durumlarda özel durumlar oluşturmayın. Bu çizgiler boyunca, çok fazla veya çok az alt öğeye sahip olmaları durumunda paneller özel durumlar oluşturmamalıdır.

  • Çevre birimi işlevselliğini şablon yardımcı öğelerine dönüştürme. Her denetim, temel işlevlerine ve gerçek değer teklifine odaklanmalıdır ve denetimin ortak kullanımı tarafından tanımlanmalıdır. Bu amaçla, denetimin temel işlevselliğine katkıda bulunmayan çevre birimi davranışlarını ve görselleştirmelerini, yani bu davranışları ve görselleştirmeleri etkinleştirmek için şablondaki oluşturma ve yardımcı öğeleri kullanın. Yardımcı öğeler üç kategoriye ayrılır:

    • Tek başına yardımcı türleri, bir şablonda "anonim olarak" kullanılan genel ve yeniden kullanılabilir denetimler veya ilkel öğelerdir; bu da yardımcı öğenin veya stil denetiminin diğerini algılamadığı anlamına gelir. Teknik olarak, herhangi bir öğe anonim bir tür olabilir, ancak bu bağlamda terim, hedeflenen senaryoları etkinleştirmek için özel işlevleri kapsülleyen türleri açıklar.

    • Tür tabanlı yardımcı öğeleri, özel işlevleri kapsülleyen yeni türlerdir. Bu öğeler genellikle yaygın denetimlere veya temel öğelere göre daha dar bir işlev aralığıyla tasarlanmıştır. Tek başına yardımcı öğelerden farklı olarak, tür tabanlı yardımcı öğeleri kullanıldıkları bağlamın farkındadır ve genellikle verileri, şablonuna ait oldukları denetimle paylaşmaları gerekir.

    • Adlandırılmış yardımcı öğeleri, bir denetimin şablonunda ada göre bulmayı beklediği yaygın denetimler veya ilkel öğelerdir. Bu öğelere şablon içinde iyi bilinen bir ad verilir ve bu da denetimin öğeyi bulmasına ve program aracılığıyla etkileşim kurmasına olanak sağlar. Herhangi bir şablonda belirli bir ada sahip yalnızca bir öğe olabilir.

    Aşağıdaki tabloda bugün denetim stilleri tarafından kullanılan yardımcı öğeler gösterilmektedir (bu liste kapsamlı değildir):

    Öğe Tür Kullanan
    ContentPresenter Tür tabanlı Button, CheckBox, RadioButton, Frameve benzeri (tüm ContentControl türler)
    ItemsPresenter Tür tabanlı ListBox, ComboBox, Menuve benzeri (tüm ItemsControl türler)
    ToolBarOverflowPanel Adlı ToolBar
    Popup Bağımsız ComboBox, ToolBar, Menu, ToolTip, vb.
    RepeatButton Adlı Slider, ScrollBar, vb.
    ScrollBar Adlı ScrollViewer
    ScrollViewer Bağımsız ListBox, ComboBox, Menu, Frame, vb.
    TabPanel Bağımsız TabControl
    TextBox Adlı ComboBox
    TickBar Tür tabanlı Slider

  • Yardımcı öğelerde kullanıcı tarafından belirtilen gerekli bağlamaları veya özellik ayarlarını en aza indirin. Bir yardımcı öğenin denetim şablonu içinde düzgün çalışması için belirli bağlamaları veya özellik ayarlarını gerektirmesi yaygın bir durumdur. Yardımcı öğe ve şablonlu denetim, mümkün olduğunca bu ayarları oluşturmalıdır. Özellikleri ayarlarken veya bağlamalar oluştururken, kullanıcı tarafından ayarlanan değerleri geçersiz kılmamaya dikkat edilmelidir. Belirli en iyi yöntemler şunlardır:

    • Adlandırılmış yardımcı öğeleri üst öğe tarafından tanımlanmalıdır ve üst öğe yardımcı öğesinde gerekli ayarları oluşturmalıdır.

    • Tür tabanlı yardımcı öğeler, gerekli ayarları doğrudan kendileri üzerinde oluşturmalıdır. Bunu yapmak için yardımcı öğenin, içinde kullanıldığı bilgi bağlamını TemplatedParent (kullanıldığı şablonun denetim türü) sorgulaması gerekebilir. Örneğin, ContentPresenter türetilmiş bir ContentControl türde kullanıldığında özelliğini TemplatedParent özelliğine Content otomatik olarak bağlarContent.

    • Tanım gereği ne yardımcı öğe ne de üst öğe diğerini bilmediğinden, tek başına yardımcı öğeler bu şekilde iyileştirilemez.

  • Bir şablondaki öğelere bayrak eklemek için Name özelliğini kullanın. Program aracılığıyla erişmek için bir öğeyi stilinde bulması gereken bir denetim, özelliği ve FindName paradigması kullanarak Name bunu yapmalıdır. Bir öğe bulunamadığında denetim özel durum oluşturmamalı, ancak bu öğeyi gerektiren işlevselliği sessiz ve düzgün bir şekilde devre dışı bırakmalıdır.

  • Denetim durumunu ve davranışını bir stilde ifade etmek için en iyi yöntemleri kullanın. Aşağıda, denetim durumu değişikliklerini ve davranışını bir stilde ifade etmek için en iyi yöntemlerin sıralı listesi verilmiştir. Senaryonuzu etkinleştiren listedeki ilk öğeyi kullanmanız gerekir.

    1. Özellik bağlama. Örnek: ve ToggleButton.IsCheckedarasında ComboBox.IsDropDownOpen bağlama.

    2. Tetiklenen özellik değişiklikleri veya özellik animasyonları. Örnek: bir Buttonöğesinin vurgulama durumu.

    3. Komut. Örnek: LineUpCommand / LineDownCommand içinde ScrollBar.

    4. Tek başına yardımcı öğeler. Örnek: TabPanel içinde TabControl.

    5. Tür tabanlı yardımcı türleri. Örnek: ContentPresenter içinde Button, TickBar içinde Slider.

    6. Adlandırılmış yardımcı öğeleri. Örnek: TextBox içinde ComboBox.

    7. Adlandırılmış yardımcı türlerden kabarcıklı olaylar. Bir stil öğesinden kabarcıklı olayları dinlerseniz, olayı oluşturan öğenin benzersiz olarak tanımlanabilmesini gerektirmelisiniz. Örnek: Thumb içinde ToolBar.

    8. Özel OnRender davranış. Örnek: ButtonChrome içinde Button.

  • Stil tetikleyicilerini (şablon tetikleyicilerinin aksine) tedbirli kullanın. Şablondaki öğelerdeki özellikleri etkileyen tetikleyiciler şablonda bildirilmelidir. Şablonu değiştirmenin tetikleyiciyi de yok etmesi gerektiğini bilmiyorsanız, denetimdeki özellikleri etkileyen tetikleyiciler (hayır TargetName) stilde bildirilebilir.

  • Mevcut stil desenleriyle tutarlı olun. Çoğu zaman bir sorunu çözmenin birden çok yolu vardır. Mümkün olduğunda mevcut denetim stili desenleriyle tutarlı ve farkında olun. Bu, özellikle aynı temel türden (örneğin, ContentControl, ItemsControl, RangeBasevb.) türetilen denetimler için önemlidir.

  • Genel özelleştirme senaryolarını yeniden düşünmeden etkinleştirmek için özellikleri kullanıma sunma. WPF takılabilir/özelleştirilebilir parçaları desteklemez, bu nedenle denetim kullanıcısı yalnızca iki özelleştirme yöntemiyle kalır: özellikleri doğrudan ayarlama veya stilleri kullanarak özellikleri ayarlama. Bunu göz önünde bulundurarak, çok yaygın, yüksek öncelikli özelleştirme senaryolarında hedeflenen sınırlı sayıda özelliğin ortaya konulacağı ve aksi takdirde yeniden düşünmenin gerekeceği uygun olacaktır. Özelleştirme senaryolarının ne zaman ve nasıl etkinleştirileceğine ilişkin en iyi yöntemler şunlardır:

    • Çok yaygın özelleştirmeler denetimde özellik olarak sunulmalı ve şablon tarafından kullanılmalıdır.

    • Daha az yaygın (nadir olmasa da) özelleştirmeler ekli özellikler olarak gösterilmelidir ve şablon tarafından kullanılmalıdır.

    • Bilinen ancak nadir özelleştirmelerin yeniden düşünme gerektirmesi kabul edilebilir.

Temayla İlgili Dikkat Edilmesi Gerekenler

  • Tema stilleri tüm temalar genelinde tutarlı özellik semantiğine sahip olmalı, ancak hiçbir garanti vermemelidir. Belgelerinin bir parçası olarak, denetiminizin özellik semantiğini, yani denetimin özelliğinin "anlamını" açıklayan bir belgesi olmalıdır. Örneğin, denetimi içinde ComboBox özelliğinin BackgroundComboBoxanlamını tanımlamalıdır. Denetiminizin varsayılan stilleri, tüm temalar genelinde bu belgede tanımlanan semantiği izlemeye çalışmalıdır. Denetim kullanıcıları ise özellik semantiğinin temadan temaya değişebileceğinin farkında olmalıdır. Belirli durumlarda, belirli bir özellik belirli bir temanın gerektirdiği görsel kısıtlamalar altında ifade edilemeyebilir. (Örneğin, Klasik temanın birçok denetim için Thickness uygulanabilecek tek bir kenarlı yoktur.)

  • Tema stillerinin tüm temalarda tutarlı tetikleyici semantiğine sahip olması gerekmez. Tetikleyiciler veya animasyonlar aracılığıyla bir denetim stili tarafından ortaya konan davranış, temadan temaya farklılık gösterebilir. Denetim kullanıcıları, bir denetimin tüm temalar genelinde belirli bir davranış elde etmek için mutlaka aynı mekanizmayı kullanmayacağının farkında olmalıdır. Örneğin bir tema, başka bir temanın tetikleyici kullandığı vurgulama davranışını ifade etmek için bir animasyon kullanabilir. Bu, özelleştirilmiş denetimlerde davranış korumasında tutarsızlıklara neden olabilir. (Örneğin, arka plan özelliğinin değiştirilmesi, söz konusu durum bir tetikleyici kullanılarak ifade edilirse denetimin vurgulama durumunu etkilemeyebilir. Ancak, vurgulama durumu bir animasyon kullanılarak uygulanırsa, arka plana geçmek, animasyonu onarılamaz bir şekilde bozabilir ve dolayısıyla durum geçişi.)

  • Tema stillerinin tüm temalarda tutarlı "düzen" semantiğine sahip olması gerekmez. Örneğin, varsayılan stilin bir denetimin tüm temalarda aynı boyutta yer kaplayacağını veya bir denetimin tüm temalar arasında aynı içerik kenar boşluklarına / doldurmaya sahip olacağını garanti etmemesi gerekmez.

Ayrıca bkz.