Bagikan melalui

Gambaran umum panel kustom XAML

  • Artikel

Panel adalah objek yang menyediakan perilaku tata letak untuk elemen anak yang dikandungnya, ketika sistem tata letak Extensible Application Markup Language (XAML) berjalan dan UI aplikasi Anda dirender.

API Penting: Panel, ArrangeOverride, MeasureOverride

Anda dapat menentukan panel kustom untuk tata letak XAML dengan mengambil kelas kustom dari kelas Panel. Anda memberikan perilaku untuk panel Anda dengan menimpa MeasureOverride dan ArrangeOverride, menyediakan logika yang mengukur dan mengatur elemen anak.

Kelas dasar Panel

Untuk menentukan kelas panel kustom, Anda dapat berasal dari kelas Panel secara langsung, atau berasal dari salah satu kelas panel praktis yang tidak disegel, seperti Grid atau StackPanel. Lebih mudah untuk berasal dari Panel, karena mungkin sulit untuk bekerja di sekitar logika tata letak yang ada dari panel yang sudah memiliki perilaku tata letak. Selain itu, panel dengan perilaku mungkin memiliki properti yang sudah ada yang tidak relevan untuk fitur tata letak panel Anda.

Dari Panel, panel kustom Anda mewarisi API ini:

  • Properti Anak-anak.
  • Properti Latar Belakang, ChildrenTransitions dan IsItemsHost, dan pengidentifikasi properti dependensi. Tidak satu pun dari properti ini virtual, jadi Anda biasanya tidak mengambil alih atau menggantinya. Anda biasanya tidak memerlukan properti ini untuk skenario panel kustom, bahkan untuk membaca nilai.
  • Metode penggantian tata letak MeasureOverride dan ArrangeOverride. Ini awalnya didefinisikan oleh FrameworkElement. Kelas Panel dasar tidak mengambil alih ini, tetapi panel praktis seperti Grid memang memiliki implementasi penggantian yang diimplementasikan sebagai kode asli dan dijalankan oleh sistem. Menyediakan implementasi baru (atau aditif) untuk ArrangeOverride dan MeasureOverride adalah upaya massal yang Anda butuhkan untuk menentukan panel kustom.
  • Semua API FrameworkElement, UIElement, dan DependencyObject lainnya, seperti Tinggi, Visibilitas, dan sebagainya. Anda terkadang mereferensikan nilai properti ini dalam penimpaan tata letak Anda, tetapi tidak virtual sehingga Anda biasanya tidak mengambil alih atau menggantinya.

Fokus di sini adalah untuk menjelaskan konsep tata letak XAML, sehingga Anda dapat mempertimbangkan semua kemungkinan tentang bagaimana panel kustom dapat dan harus bersifat tata letak. Jika Anda lebih suka melompat ke kanan dan melihat contoh implementasi panel kustom, lihat BoxPanel, contoh panel kustom.

Properti Anak

Properti Anak relevan dengan panel kustom karena semua kelas yang berasal dari Panel menggunakan properti Anak sebagai tempat untuk menyimpan elemen turunan yang terkandung dalam koleksi. Anak-anak ditetapkan sebagai properti konten XAML untuk kelas Panel , dan semua kelas yang berasal dari Panel dapat mewarisi perilaku properti konten XAML. Jika properti ditunjuk sebagai properti konten XAML, itu berarti markup XAML dapat menghilangkan elemen properti saat menentukan properti tersebut dalam markup, dan nilai diatur sebagai turunan markup langsung ("konten"). Misalnya, jika Anda memperoleh kelas bernama CustomPanel dari Panel yang tidak menentukan perilaku baru, Anda masih dapat menggunakan markup ini:

<local:CustomPanel>
  <Button Name="button1"/>
  <Button Name="button2"/>
</local:CustomPanel>

Ketika pengurai XAML membaca markup ini, Children diketahui sebagai properti konten XAML untuk semua jenis turunan Panel, sehingga pengurai akan menambahkan dua elemen Tombol ke nilai UIElementCollection properti Children. Properti konten XAML memfasilitasi hubungan induk-turunan yang disederhanakan dalam markup XAML untuk definisi UI. Untuk informasi selengkapnya tentang properti konten XAML, dan bagaimana properti koleksi diisi saat XAML diurai, lihat panduan sintaks XAML.

Jenis koleksi yang mempertahankan nilai properti Anak adalah kelas UIElementCollection. UIElementCollection adalah koleksi dengan jenis kuat yang menggunakan UIElement sebagai jenis item yang diberlakukan. UIElement adalah jenis dasar yang diwarisi oleh ratusan jenis elemen UI praktis, sehingga penegakan jenis di sini sengaja longgar. Tetapi itu memberlakukan bahwa Anda tidak dapat memiliki Brush sebagai anak langsung dari Panel, dan umumnya berarti bahwa hanya elemen yang diharapkan terlihat di UI dan berpartisipasi dalam tata letak akan ditemukan sebagai elemen anak dalam Panel.

Biasanya, panel kustom menerima elemen anak UIElement apa pun oleh definisi XAML, hanya dengan menggunakan karakteristik properti Anak apa adanya. Sebagai skenario lanjutan, Anda dapat mendukung pemeriksaan jenis elemen anak lebih lanjut, ketika Anda melakukan iterasi atas koleksi dalam penimpaan tata letak Anda.

Selain mengulangi koleksi Anak dalam penimpaan, logika panel Anda mungkin juga dipengaruhi oleh Children.Count. Anda mungkin memiliki logika yang mengalokasikan ruang setidaknya sebagian berdasarkan jumlah item, daripada ukuran yang diinginkan dan karakteristik item individual lainnya.

Mengesampingkan metode tata letak

Model dasar untuk metode penggantian tata letak (MeasureOverride dan ArrangeOverride) adalah bahwa mereka harus melakukan iterasi melalui semua turunan dan memanggil metode tata letak spesifik setiap elemen turunan. Siklus tata letak pertama dimulai ketika sistem tata letak XAML mengatur visual untuk jendela akar. Karena setiap induk memanggil tata letak pada turunannya, ini menyebarluaskan panggilan ke metode tata letak ke setiap elemen UI yang mungkin yang seharusnya menjadi bagian dari tata letak. Dalam tata letak XAML, ada dua tahap: ukur, lalu atur.

Anda tidak mendapatkan perilaku metode tata letak bawaan untuk MeasureOverride dan ArrangeOverride dari kelas Panel dasar. Item di Anak tidak akan dirender secara otomatis sebagai bagian dari pohon visual XAML. Terserah Anda untuk membuat item yang diketahui oleh proses tata letak, dengan memanggil metode tata letak pada setiap item yang Anda temukan di Anak melalui pass tata letak dalam implementasi MeasureOverride dan ArrangeOverride Anda.

Tidak ada alasan untuk memanggil implementasi dasar dalam penimpaan tata letak kecuali Anda memiliki warisan Anda sendiri. Metode asli untuk perilaku tata letak (jika ada) berjalan terlepas dari itu, dan tidak memanggil implementasi dasar dari penimpaan tidak akan mencegah perilaku asli terjadi.

Selama lulus pengukuran, logika tata letak Anda mengkueri setiap elemen anak untuk ukuran yang diinginkan, dengan memanggil metode Pengukuran pada elemen turunan tersebut. Memanggil metode Pengukuran menetapkan nilai untuk properti DesiredSize. Nilai pengembalian MeasureOverride adalah ukuran yang diinginkan untuk panel itu sendiri.

Selama pass susun, posisi dan ukuran elemen anak ditentukan dalam ruang x-y dan komposisi tata letak disiapkan untuk penyajian. Kode Anda harus memanggil Atur pada setiap elemen turunan di Anak sehingga sistem tata letak mendeteksi bahwa elemen berada dalam tata letak. Panggilan Atur adalah prekursor untuk komposisi dan penyajian; ini menginformasikan sistem tata letak tempat elemen tersebut pergi, ketika komposisi dikirimkan untuk penyajian.

Banyak properti dan nilai berkontribusi pada cara kerja logika tata letak pada runtime. Cara untuk memikirkan proses tata letak adalah bahwa elemen tanpa anak (umumnya elemen yang paling berlapis dalam di UI) adalah elemen yang dapat menyelesaikan pengukuran terlebih dahulu. Mereka tidak memiliki dependensi pada elemen anak yang memengaruhi ukuran yang diinginkan. Mereka mungkin memiliki ukuran yang diinginkan sendiri, dan ini adalah saran ukuran sampai tata letak benar-benar terjadi. Kemudian, pass pengukuran terus berjalan di atas pohon visual sampai elemen akar memiliki pengukurannya dan semua pengukuran dapat diselesaikan.

Tata letak kandidat harus pas dalam jendela aplikasi saat ini atau bagian lain dari UI akan diklip. Panel sering kali adalah tempat di mana logika kliping ditentukan. Logika panel dapat menentukan ukuran apa yang tersedia dari dalam implementasi MeasureOverride , dan mungkin harus mendorong pembatasan ukuran ke anak-anak dan membagi ruang di antara anak-anak sehingga semuanya sesuai dengan yang terbaik. Hasil tata letak idealnya adalah sesuatu yang menggunakan berbagai properti dari semua bagian tata letak tetapi masih pas dalam jendela aplikasi. Itu membutuhkan implementasi yang baik untuk logika tata letak panel, dan juga desain UI yang yudiktif pada bagian dari kode aplikasi apa pun yang membangun UI menggunakan panel tersebut. Tidak ada desain panel yang akan terlihat bagus jika desain UI keseluruhan mencakup lebih banyak elemen anak daripada yang mungkin cocok di aplikasi.

Sebagian besar yang membuat sistem tata letak berfungsi adalah bahwa elemen apa pun yang didasarkan pada FrameworkElement sudah memiliki beberapa perilaku melekatnya sendiri saat bertindak sebagai anak dalam kontainer. Misalnya, ada beberapa API FrameworkElement yang menginformasikan perilaku tata letak atau diperlukan untuk membuat tata letak berfungsi sama sekali. Ini termasuk:

MeasureOverride

Metode MeasureOverride memiliki nilai pengembalian yang digunakan oleh sistem tata letak sebagai desiredSize awal untuk panel itu sendiri, ketika metode Pengukuran dipanggil pada panel oleh induknya dalam tata letak. Pilihan logika dalam metode sama pentingnya dengan apa yang dikembalikannya, dan logika sering memengaruhi nilai apa yang dikembalikan.

Semua implementasi MeasureOverride harus diulang melalui Turunan, dan memanggil metode Pengukuran pada setiap elemen anak. Memanggil metode Pengukuran menetapkan nilai untuk properti DesiredSize. Ini mungkin menginformasikan berapa banyak ruang yang dibutuhkan panel itu sendiri, serta bagaimana ruang itu dibagi di antara elemen atau ukuran untuk elemen anak tertentu.

Berikut adalah kerangka yang sangat mendasar dari metode MeasureOverride:

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

Elemen sering memiliki ukuran alami pada saat mereka siap untuk tata letak. Setelah lulus pengukuran, DesiredSize mungkin menunjukkan bahwa ukuran alami, jika ukuran tersedia yang Anda lewati untuk Pengukuran lebih kecil. Jika ukuran alami lebih besar dari availableSize yang Anda lewati untuk Pengukuran, DesiredSize dibatasi untuk availableSize. Begitulah perilaku implementasi internal Pengukuran, dan penimpaan tata letak Anda harus memperhitungkan perilaku tersebut.

Beberapa elemen tidak memiliki ukuran alami karena memiliki nilai Otomatis untuk Tinggi dan Lebar. Elemen-elemen ini menggunakan ukuran tersedia penuh, karena itulah yang diwakili nilai Otomatis: mengukur elemen ke ukuran maksimum yang tersedia, yang dikomunikasikan induk tata letak langsung dengan memanggil Pengukuran dengan availableSize. Dalam praktiknya, selalu ada beberapa pengukuran yang berukuran UI (bahkan jika itu adalah jendela tingkat atas.) Akhirnya, pass pengukuran menyelesaikan semua nilai Otomatis ke batasan induk dan semua elemen Nilai otomatis mendapatkan pengukuran nyata (yang bisa Anda dapatkan dengan memeriksa ActualWidth dan ActualHeight, setelah tata letak selesai).

Secara hukum untuk meneruskan ukuran ke Ukuran yang memiliki setidaknya satu dimensi tak terbatas, untuk menunjukkan bahwa panel dapat mencoba mengukur dirinya sendiri agar sesuai dengan pengukuran kontennya. Setiap elemen anak yang diukur menetapkan nilai DesiredSize menggunakan ukuran alaminya. Kemudian, selama pass pengaturan, panel biasanya mengatur menggunakan ukuran tersebut.

Elemen teks seperti TextBlock memiliki ActualWidth dan ActualHeight yang dihitung berdasarkan string teks dan properti teksnya meskipun tidak ada nilai Tinggi atau Lebar yang diatur, dan dimensi ini harus dihormati oleh logika panel Anda. Mengklip teks adalah pengalaman UI yang sangat buruk.

Bahkan jika implementasi Anda tidak menggunakan pengukuran ukuran yang diinginkan, yang terbaik adalah memanggil metode Pengukuran pada setiap elemen anak, karena ada perilaku internal dan asli yang dipicu oleh Pengukuran yang dipanggil. Agar elemen berpartisipasi dalam tata letak, setiap elemen anak harus memiliki Pengukuran yang dipanggil selama pass pengukuran dan metode Atur yang dipanggil selama pass pengaturan. Memanggil metode ini mengatur bendera internal pada objek dan mengisi nilai (seperti properti DesiredSize ) yang dibutuhkan logika tata letak sistem saat membangun pohon visual dan merender UI.

Nilai pengembalian MeasureOverride didasarkan pada logika panel yang menginterpretasikan DesiredSize atau pertimbangan ukuran lainnya untuk setiap elemen turunan di Children saat Pengukuran dipanggil. Apa yang harus dilakukan dengan nilai DesiredSize dari anak-anak dan bagaimana nilai pengembalian MeasureOverride harus menggunakannya hingga interpretasi logika Anda sendiri. Anda biasanya tidak menambahkan nilai tanpa modifikasi, karena input MeasureOverride sering kali merupakan ukuran tetap yang tersedia yang disarankan oleh induk panel. Jika Anda melebihi ukuran tersebut, panel itu sendiri mungkin terpotong. Anda biasanya akan membandingkan ukuran total anak dengan ukuran panel yang tersedia dan membuat penyesuaian jika perlu.

Tips dan panduan

  • Idealnya, panel kustom harus cocok untuk menjadi visual sejati pertama dalam komposisi UI, mungkin pada tingkat segera di bawah Halaman, UserControl atau elemen lain yang merupakan akar halaman XAML. Dalam implementasi MeasureOverride, jangan secara rutin mengembalikan Ukuran input tanpa memeriksa nilai. Jika Ukuran yang dikembalikan memiliki nilai Infinity di dalamnya, ini dapat melemparkan pengecualian dalam logika tata letak runtime. Nilai Infinity dapat berasal dari jendela aplikasi utama, yang dapat digulir dan karenanya tidak memiliki tinggi maksimum. Konten lain yang dapat digulir mungkin memiliki perilaku yang sama.
  • Kesalahan umum lainnya dalam implementasi MeasureOverride adalah mengembalikan Ukuran default baru (nilai untuk tinggi dan lebar adalah 0). Anda mungkin mulai dengan nilai tersebut, dan itu bahkan mungkin nilai yang benar jika panel Anda menentukan bahwa tidak ada anak yang harus dirender. Tapi, Ukuran default menghasilkan panel Anda tidak berukuran benar oleh host-nya. Ini tidak meminta ruang di UI, dan karena itu tidak mendapatkan ruang dan tidak dirender. Semua kode panel Anda mungkin berfungsi dengan baik, tetapi Anda masih tidak akan melihat panel atau isinya jika sedang disusam dengan tinggi nol, lebar nol.
  • Dalam penimpaan, hindari godaan untuk mentransmisikan elemen anak ke FrameworkElement dan gunakan properti yang dihitung sebagai hasil dari tata letak, terutama ActualWidth dan ActualHeight. Untuk skenario yang paling umum, Anda dapat mendasarkan logika pada nilai DesiredSize anak dan Anda tidak memerlukan properti terkait Tinggi atau Lebar dari elemen anak. Untuk kasus khusus, di mana Anda mengetahui jenis elemen dan memiliki informasi tambahan, misalnya ukuran alami file gambar, Anda dapat menggunakan informasi khusus elemen Anda karena itu bukan nilai yang secara aktif diubah oleh sistem tata letak. Termasuk properti yang dihitung tata letak sebagai bagian dari logika tata letak secara substansial meningkatkan risiko menentukan perulangan tata letak yang tidak disengaja. Perulangan ini menyebabkan kondisi di mana tata letak yang valid tidak dapat dibuat dan sistem dapat melempar LayoutCycleException jika perulangan tidak dapat dipulihkan.
  • Panel biasanya membagi ruang yang tersedia antara beberapa elemen anak, meskipun persis bagaimana ruang dibagi bervariasi. Misalnya, Grid mengimplementasikan logika tata letak yang menggunakan nilai RowDefinition dan ColumnDefinition untuk membagi ruang menjadi sel Grid, mendukung nilai ukuran bintang dan piksel. Jika nilai piksel, ukuran yang tersedia untuk setiap anak sudah diketahui, jadi itulah yang diteruskan sebagai ukuran input untuk Pengukuran gaya kisi.
  • Panel sendiri dapat memperkenalkan ruang yang dipesan untuk padding antar item. Jika Anda melakukan ini, pastikan untuk mengekspos pengukuran sebagai properti yang berbeda dari Margin atau properti Padding apa pun.
  • Elemen mungkin memiliki nilai untuk properti ActualWidth dan ActualHeight berdasarkan kode tata letak sebelumnya. Jika nilai berubah, kode antarmuka pengguna aplikasi dapat menempatkan handler untuk LayoutUpdated pada elemen jika ada logika khusus untuk dijalankan, tetapi logika panel biasanya tidak perlu memeriksa perubahan dengan penanganan peristiwa. Sistem tata letak sudah membuat penentuan kapan harus menjalankan ulang tata letak karena properti yang relevan dengan tata letak mengubah nilai, dan MeasureOverride atau ArrangeOverride panel dipanggil secara otomatis dalam keadaan yang sesuai.

ArrangeOverride

Metode ArrangeOverride memiliki nilai pengembalian Ukuran yang digunakan oleh sistem tata letak saat merender panel itu sendiri, ketika metode Arrange dipanggil pada panel oleh induknya dalam tata letak. Biasanya input finalSize dan Ukuran yang dikembalikan ArrangeOverride sama. Jika tidak, itu berarti panel mencoba membuat dirinya ukuran yang berbeda dari apa yang tersedia oleh peserta lain dalam klaim tata letak. Ukuran akhir didasarkan pada setelah sebelumnya menjalankan pass pengukuran tata letak melalui kode panel Anda, jadi itulah sebabnya mengembalikan ukuran yang berbeda tidak khas: itu berarti Anda sengaja mengabaikan logika pengukuran.

Jangan mengembalikan Ukuran dengan komponen Infinity . Mencoba menggunakan Ukuran seperti itu melempar pengecualian dari tata letak internal.

Semua implementasi ArrangeOverride harus diulang melalui Turunan, dan memanggil metode Atur pada setiap elemen turunan. Seperti Pengukuran, Susun tidak memiliki nilai pengembalian. Tidak seperti Pengukuran, tidak ada properti terhitung yang ditetapkan sebagai hasilnya (namun, elemen yang dimaksud biasanya mengaktifkan peristiwa LayoutUpdated).

Berikut adalah kerangka yang sangat mendasar dari metode ArrangeOverride:

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
}

Pass susun tata letak mungkin terjadi tanpa didahului oleh pass pengukuran. Namun, ini hanya terjadi ketika sistem tata letak telah menentukan tidak ada properti yang berubah yang akan memengaruhi pengukuran sebelumnya. Misalnya, jika perataan berubah, tidak perlu mengukur ulang elemen tertentu tersebut karena DesiredSize-nya tidak akan berubah saat pilihan perataannya berubah. Di sisi lain, jika ActualHeight berubah pada elemen apa pun dalam tata letak, diperlukan pass pengukuran baru. Sistem tata letak secara otomatis mendeteksi perubahan ukuran yang benar dan memanggil kembali pass pengukuran, lalu menjalankan pass pengaturan lain.

Input untuk Arrange mengambil nilai Rect. Cara paling umum untuk membangun Rect ini adalah dengan menggunakan konstruktor yang memiliki input Titik dan input Ukuran. Titik adalah titik di mana sudut kiri atas kotak pembatas untuk elemen harus ditempatkan. Ukuran adalah dimensi yang digunakan untuk merender elemen tertentu. Anda sering menggunakan DesiredSize untuk elemen tersebut sebagai nilai Ukuran ini, karena menetapkan DesiredSize untuk semua elemen yang terlibat dalam tata letak adalah tujuan dari lulus pengukuran tata letak. (Lulus pengukuran menentukan ukuran semua elemen dengan cara berulang sehingga sistem tata letak dapat mengoptimalkan bagaimana elemen ditempatkan setelah sampai ke pass pengaturan.)

Apa yang biasanya bervariasi antara implementasi ArrangeOverride adalah logika di mana panel menentukan komponen Titik tentang bagaimana ia mengatur setiap anak. Panel posisi absolut seperti Canvas menggunakan info penempatan eksplisit yang didapatkannya dari setiap elemen melalui nilai Canvas.Left dan Canvas.Top. Panel pembagi ruang seperti Grid akan memiliki operasi matematika yang membagi ruang yang tersedia menjadi sel dan setiap sel akan memiliki nilai x-y di mana kontennya harus ditempatkan dan disusun. Panel adaptif seperti StackPanel mungkin memperluas dirinya sendiri agar sesuai dengan konten dalam dimensi orientasinya.

Masih ada pengaruh penempatan tambahan pada elemen dalam tata letak, di luar apa yang Anda kontrol langsung dan teruskan ke Atur. Ini berasal dari implementasi asli internal Arrange yang umum untuk semua jenis turunan FrameworkElement dan bertambah oleh beberapa jenis lain seperti elemen teks. Misalnya, elemen dapat memiliki margin dan perataan, dan beberapa dapat memiliki padding. Properti ini sering berinteraksi. Untuk informasi selengkapnya, lihat Perataan, margin, dan padding.

Panel dan kontrol

Hindari menempatkan fungsionalitas ke dalam panel kustom yang seharusnya dibangun sebagai kontrol kustom. Peran panel adalah menyajikan konten elemen turunan apa pun yang ada di dalamnya, sebagai fungsi tata letak yang terjadi secara otomatis. Panel mungkin menambahkan dekorasi ke konten (mirip dengan cara Batas menambahkan batas di sekitar elemen yang disajikannya), atau melakukan penyesuaian terkait tata letak lainnya seperti padding. Tetapi sejauh itu Anda harus pergi ketika memperluas output pohon visual di luar pelaporan dan menggunakan informasi dari anak-anak.

Jika ada interaksi yang dapat diakses oleh pengguna, Anda harus menulis kontrol kustom, bukan panel. Misalnya, panel tidak boleh menambahkan viewports gulir ke konten yang disajikannya, bahkan jika tujuannya adalah untuk mencegah kliping, karena bilah gulir, jempol, dan sebagainya adalah bagian kontrol interaktif. (Konten mungkin memiliki bilah gulir setelah semua, tetapi Anda harus membiarkannya hingga logika anak. Jangan paksa dengan menambahkan pengguliran sebagai operasi tata letak.) Anda dapat membuat kontrol dan juga menulis panel kustom yang memainkan peran penting dalam pohon visual kontrol tersebut, dalam hal menyajikan konten dalam kontrol tersebut. Tetapi kontrol dan panel harus menjadi objek kode yang berbeda.

Salah satu alasan perbedaan antara kontrol dan panel penting adalah karena Microsoft UI Automation dan aksesibilitas. Panel menyediakan perilaku tata letak visual, bukan perilaku logis. Bagaimana elemen UI muncul secara visual bukan aspek UI yang biasanya penting untuk skenario aksesibilitas. Aksesibilitas adalah tentang mengekspos bagian aplikasi yang secara logis penting untuk memahami UI. Ketika interaksi diperlukan, kontrol harus mengekspos kemungkinan interaksi ke infrastruktur Automation UI. Untuk informasi selengkapnya, lihat Rekan otomatisasi kustom.

API tata letak lainnya

Ada beberapa API lain yang merupakan bagian dari sistem tata letak, tetapi tidak dideklarasikan oleh Panel. Anda dapat menggunakannya dalam implementasi panel atau dalam kontrol kustom yang menggunakan panel.

  • UpdateLayout, InvalidateMeasure, dan InvalidateArrange adalah metode yang memulai kode tata letak. InvalidateArrange mungkin tidak memicu pass pengukuran, tetapi dua lainnya melakukannya. Jangan pernah memanggil metode ini dari dalam metode tata letak mengambil alih, karena hampir pasti menyebabkan perulangan tata letak. Kode kontrol biasanya tidak perlu memanggilnya juga. Sebagian besar aspek tata letak dipicu secara otomatis dengan mendeteksi perubahan pada properti tata letak yang ditentukan kerangka kerja seperti Lebar dan sebagainya.
  • LayoutUpdated adalah peristiwa yang diaktifkan ketika beberapa aspek tata letak elemen telah berubah. Ini tidak spesifik untuk panel; peristiwa didefinisikan oleh FrameworkElement.
  • SizeChanged adalah peristiwa yang diaktifkan hanya setelah kode tata letak diselesaikan, dan menunjukkan bahwa ActualHeight atau ActualWidth telah berubah sebagai hasilnya. Ini adalah peristiwa FrameworkElement lainnya. Ada kasus di mana LayoutUpdated diaktifkan, tetapi SizeChanged tidak. Misalnya konten internal mungkin diatur ulang, tetapi ukuran elemen tidak berubah.

Referensi

Konsep