Rekan otomatisasi kustom
Menjelaskan konsep rekan otomatisasi untuk Microsoft UI Automation, dan bagaimana Anda dapat memberikan dukungan otomatisasi untuk kelas UI kustom Anda sendiri.
UI Automation menyediakan kerangka kerja yang dapat digunakan klien otomatisasi untuk memeriksa atau mengoperasikan antarmuka pengguna dari berbagai platform dan kerangka kerja UI. Jika Anda menulis aplikasi Windows, kelas yang Anda gunakan untuk UI Anda sudah menyediakan dukungan Automation UI. Anda dapat berasal dari kelas yang sudah ada dan tidak disegel untuk menentukan jenis kontrol UI atau kelas dukungan baru. Dalam proses melakukannya, kelas Anda mungkin menambahkan perilaku yang seharusnya memiliki dukungan aksesibilitas tetapi dukungan Automation UI default tidak tercakup. Dalam hal ini, Anda harus memperluas dukungan Automation UI yang ada dengan berasal dari kelas AutomationPeer yang digunakan implementasi dasar, menambahkan dukungan yang diperlukan ke implementasi serekan Anda, dan memberi tahu infrastruktur kontrol aplikasi Windows bahwa itu harus membuat rekan baru Anda.
Automasi UI tidak hanya memungkinkan aplikasi aksesibilitas dan teknologi bantuan, seperti pembaca layar, tetapi juga kode jaminan kualitas (pengujian). Dalam kedua skenario, klien Automation UI dapat memeriksa elemen antarmuka pengguna dan mensimulasikan interaksi pengguna dengan aplikasi Anda dari kode lain di luar aplikasi Anda. Untuk informasi tentang Automasi UI di semua platform dan maknanya yang lebih luas, lihat Gambaran Umum Automasi UI.
Ada dua audiens berbeda yang menggunakan kerangka kerja Automation UI.
- Klien Automation UI memanggil API Automation UI untuk mempelajari semua UI yang saat ini ditampilkan kepada pengguna. Misalnya, teknologi bantuan seperti pembaca layar bertindak sebagai klien Automation UI. UI disajikan sebagai pohon elemen otomatisasi yang terkait. Klien Automation UI mungkin hanya tertarik pada satu aplikasi pada satu waktu, atau di seluruh pohon. Klien Automation UI dapat menggunakan API Automation UI untuk menavigasi pohon dan membaca atau mengubah informasi dalam elemen otomatisasi.
- Penyedia Automation UI menyumbangkan informasi ke pohon Automation UI, dengan menerapkan API yang mengekspos elemen di UI yang mereka perkenalkan sebagai bagian dari aplikasi mereka. Saat membuat kontrol baru, Anda sekarang harus bertindak sebagai peserta dalam skenario penyedia Automation UI. Sebagai penyedia, Anda harus memastikan bahwa semua klien Automation UI dapat menggunakan kerangka kerja Automation UI untuk berinteraksi dengan kontrol Anda untuk tujuan aksesibilitas dan pengujian.
Biasanya ada API paralel dalam kerangka kerja Automation UI: satu API untuk klien Automation UI dan API lain yang bernama sama untuk penyedia Automation UI. Sebagian besar, topik ini mencakup API untuk penyedia Automation UI, dan khususnya kelas dan antarmuka yang memungkinkan ekstensibilitas penyedia dalam kerangka kerja UI tersebut. Terkadang kami menyebutkan API Automasi UI yang digunakan klien Automation UI, untuk memberikan beberapa perspektif, atau menyediakan tabel pencarian yang berkorelasi dengan API klien dan penyedia. Untuk informasi selengkapnya tentang perspektif klien, lihat Panduan Programmer Klien Automation UI.
Catatan
Klien Automation UI biasanya tidak menggunakan kode terkelola dan biasanya tidak diimplementasikan sebagai aplikasi UWP (biasanya aplikasi desktop). Automasi UI didasarkan pada standar dan bukan implementasi atau kerangka kerja tertentu. Banyak klien Automation UI yang ada, termasuk produk teknologi bantuan seperti pembaca layar, menggunakan antarmuka Model Objek Komponen (COM) untuk berinteraksi dengan Automasi UI, sistem, dan aplikasi yang berjalan di jendela anak. Untuk informasi selengkapnya tentang antarmuka COM dan cara menulis klien Automation UI menggunakan COM, lihat Dasar-Dasar Automasi UI.
Menentukan status dukungan Automation UI yang ada untuk kelas UI kustom Anda
Sebelum Anda mencoba menerapkan peer otomatisasi untuk kontrol kustom, Anda harus menguji apakah kelas dasar dan serekan otomatisasinya sudah menyediakan dukungan aksesibilitas atau otomatisasi yang Anda butuhkan. Dalam banyak kasus, kombinasi implementasi FrameworkElementAutomationPeer , serekan tertentu, dan pola yang mereka terapkan dapat memberikan pengalaman aksesibilitas dasar tetapi memuaskan. Apakah ini benar tergantung pada berapa banyak perubahan yang Anda buat pada paparan model objek ke kontrol Anda versus kelas dasarnya. Selain itu, ini tergantung pada apakah penambahan Anda ke fungsionalitas kelas dasar berkorelasi dengan elemen UI baru dalam kontrak templat atau ke tampilan visual kontrol. Dalam beberapa kasus, perubahan Anda mungkin memperkenalkan aspek baru pengalaman pengguna yang memerlukan dukungan aksesibilitas tambahan.
Bahkan jika menggunakan kelas peer dasar yang ada memberikan dukungan aksesibilitas dasar, ini masih merupakan praktik terbaik untuk menentukan serekan sehingga Anda dapat melaporkan informasi ClassName yang tepat ke Automasi UI untuk skenario pengujian otomatis. Pertimbangan ini sangat penting jika Anda menulis kontrol yang ditujukan untuk konsumsi pihak ketiga.
Kelas peer Automation
UWP dibangun berdasarkan teknik dan konvensi Automasi UI yang ada yang digunakan oleh kerangka kerja UI kode terkelola sebelumnya seperti Formulir Windows, Windows Presentation Foundation (WPF) dan Microsoft Silverlight. Banyak kelas kontrol dan fungsi dan tujuannya juga memiliki asalnya dalam kerangka kerja UI sebelumnya.
Menurut konvensi, nama kelas serekan dimulai dengan nama kelas kontrol dan diakhpuni dengan "AutomationPeer". Misalnya, ButtonAutomationPeer adalah kelas peer untuk kelas Kontrol tombol.
Catatan
Untuk tujuan topik ini, kami memperlakukan properti yang terkait dengan aksesibilitas sebagai yang lebih penting ketika Anda menerapkan peer kontrol. Tetapi untuk konsep dukungan Automation UI yang lebih umum, Anda harus menerapkan serekan sesuai dengan rekomendasi seperti yang didokumentasikan oleh Panduan Programmer Penyedia Automasi UI dan Dasar-Dasar Otomatisasi UI. Topik tersebut tidak mencakup API AutomationPeer tertentu yang akan Anda gunakan untuk memberikan informasi dalam kerangka kerja UWP untuk Automasi UI, tetapi mereka menjelaskan properti yang mengidentifikasi kelas Anda atau memberikan informasi atau interaksi lainnya.
Serekan, pola, dan jenis kontrol
Pola kontrol adalah implementasi antarmuka yang mengekspos aspek tertentu dari fungsionalitas kontrol ke klien Automation UI. Klien Automation UI menggunakan properti dan metode yang diekspos melalui pola kontrol untuk mengambil informasi tentang kemampuan kontrol, atau untuk memanipulasi perilaku kontrol pada waktu proses.
Pola kontrol menyediakan cara untuk mengategorikan dan mengekspos fungsionalitas kontrol secara independen dari jenis kontrol atau tampilan kontrol. Misalnya, kontrol yang menyajikan antarmuka tabular menggunakan pola kontrol Kisi untuk mengekspos jumlah baris dan kolom dalam tabel, dan untuk mengaktifkan klien Automation UI untuk mengambil item dari tabel. Sebagai contoh lain, klien Automation UI dapat menggunakan pola Kontrol panggilan untuk kontrol yang dapat dipanggil, seperti tombol, dan pola kontrol Gulir untuk kontrol yang memiliki bilah gulir, seperti kotak daftar, tampilan daftar, atau kotak kombo. Setiap pola kontrol mewakili jenis fungsionalitas terpisah, dan pola kontrol dapat digabungkan untuk menjelaskan serangkaian fungsionalitas lengkap yang didukung oleh kontrol tertentu.
Pola kontrol berkaitan dengan UI sebagai antarmuka yang terkait dengan objek COM. Di COM, Anda dapat meminta objek untuk menanyakan antarmuka apa yang didukungnya dan kemudian menggunakan antarmuka tersebut untuk mengakses fungsionalitas. Dalam Automasi UI, klien Automation UI dapat meminta elemen Automation UI untuk mengetahui pola kontrol mana yang didukungnya, lalu berinteraksi dengan elemen dan kontrol yang di-peering melalui properti, metode, peristiwa, dan struktur yang diekspos oleh pola kontrol yang didukung.
Salah satu tujuan utama serekan otomatisasi adalah untuk melaporkan ke klien Automation UI yang mengontrol pola yang dapat didukung elemen UI melalui rekan-rekannya. Untuk melakukan ini, penyedia Automation UI menerapkan rekan-rekan baru yang mengubah perilaku metode GetPattern dengan mengambil alih metode GetPatternCore. Klien Automation UI melakukan panggilan yang dipetakan penyedia Automation UI untuk memanggil GetPattern. Klien Automation UI mengkueri untuk setiap pola tertentu yang ingin mereka berinteraksi. Jika serekan mendukung pola, ia mengembalikan referensi objek ke dirinya sendiri; jika tidak, itu mengembalikan null. Jika pengembalian tidak null, klien Automation UI mengharapkan bahwa ia dapat memanggil API antarmuka pola sebagai klien, untuk berinteraksi dengan pola kontrol tersebut.
Jenis kontrol adalah cara untuk menentukan fungsionalitas kontrol yang diwakili oleh rekan. Ini adalah konsep yang berbeda dari pola kontrol karena sementara pola menginformasikan Automation UI info apa yang bisa didapatkan atau tindakan apa yang dapat dilakukannya melalui antarmuka tertentu, jenis kontrol ada satu tingkat di atasnya. Setiap jenis kontrol memiliki panduan tentang aspek Otomatisasi UI ini:
- Pola kontrol Automation UI: Jenis kontrol mungkin mendukung lebih dari satu pola, yang masing-masing mewakili klasifikasi info atau interaksi yang berbeda. Setiap jenis kontrol memiliki serangkaian pola kontrol yang harus didukung kontrol, set yang opsional, dan set yang tidak boleh didukung kontrol.
- Nilai properti Automation UI: Setiap jenis kontrol memiliki sekumpulan properti yang harus didukung kontrol. Ini adalah properti umum, seperti yang dijelaskan dalam Gambaran Umum Properti Automasi UI, bukan properti yang spesifik dengan pola.
- Peristiwa Automasi UI: Setiap jenis kontrol memiliki serangkaian peristiwa yang harus didukung kontrol. Sekali lagi ini umum, bukan khusus pola, seperti yang dijelaskan dalam Gambaran Umum Peristiwa Automasi UI.
- Struktur pohon Automation UI: Setiap jenis kontrol menentukan bagaimana kontrol harus muncul di struktur pohon Automation UI.
Terlepas dari bagaimana rekan otomatisasi untuk kerangka kerja diimplementasikan, fungsionalitas klien Automation UI tidak terkait dengan UWP, dan pada kenyataannya kemungkinan klien Automation UI yang ada seperti teknologi bantuan akan menggunakan model pemrograman lain, seperti COM. Di COM, klien dapat QueryInterface untuk antarmuka pola kontrol COM yang mengimplementasikan pola yang diminta atau kerangka kerja Automation UI umum untuk properti, peristiwa, atau pemeriksaan pohon. Untuk pola, kerangka kerja Automation UI marshals yang memasukkan kode antarmuka ke dalam kode UWP yang berjalan terhadap penyedia Automation UI aplikasi dan serekan yang relevan.
Saat Menerapkan pola kontrol untuk kerangka kerja kode terkelola seperti aplikasi UWP menggunakan C# atau Microsoft Visual Basic, Anda dapat menggunakan antarmuka .NET Framework untuk mewakili pola ini alih-alih menggunakan representasi antarmuka COM. Misalnya, antarmuka pola Automation UI untuk implementasi penyedia Microsoft .NET dari pola Invoke adalah IInvokeProvider.
Untuk daftar pola kontrol, antarmuka penyedia, dan tujuannya, lihat Mengontrol pola dan antarmuka. Untuk daftar jenis kontrol, lihat Gambaran Umum Tipe Kontrol Automasi UI.
Panduan tentang cara menerapkan pola kontrol
Pola kontrol dan apa yang dimaksudkan adalah bagian dari definisi yang lebih besar dari kerangka kerja Automation UI, dan tidak hanya berlaku untuk dukungan aksesibilitas untuk aplikasi UWP. Saat menerapkan pola kontrol, Anda harus memastikan bahwa Anda menerapkannya dengan cara yang cocok dengan panduan seperti yang didokumentasikan dalam dokumen ini dan juga dalam spesifikasi Automation UI. Jika Anda mencari panduan, Anda umumnya dapat menggunakan dokumentasi Microsoft dan tidak perlu merujuk ke spesifikasi. Panduan untuk setiap pola didokumentasikan di sini: Menerapkan Pola Kontrol Automasi UI. Anda akan melihat bahwa setiap topik di bawah area ini memiliki bagian "Panduan dan Konvensi Implementasi" dan bagian "Anggota yang Diperlukan". Panduan ini biasanya mengacu pada API tertentu dari antarmuka pola kontrol yang relevan dalam referensi Antarmuka Pola Kontrol untuk Penyedia . Antarmuka tersebut adalah antarmuka asli/COM (dan API mereka menggunakan sintaks gaya COM). Tetapi semua yang Anda lihat di sana memiliki namespace layanan Windows.UI.Xaml.Automation.Provider yang setara.
Jika Anda menggunakan rekan otomatisasi default dan memperluas perilakunya, rekan-rekan tersebut telah ditulis sesuai dengan pedoman Automation UI. Jika mendukung pola kontrol, Anda dapat mengandalkan dukungan pola tersebut sesuai dengan panduan di Menerapkan Pola Kontrol Automasi UI. Jika serekan kontrol melaporkan bahwa itu adalah perwakilan dari jenis kontrol yang ditentukan oleh Automation UI, maka panduan yang didokumentasikan di Mendukung Jenis Kontrol Automasi UI telah diikuti oleh rekan tersebut.
Namun demikian Anda mungkin memerlukan panduan tambahan untuk pola kontrol atau jenis kontrol untuk mengikuti rekomendasi Automation UI dalam implementasi serekan Anda. Itu akan sangat benar jika Anda menerapkan dukungan jenis pola atau kontrol yang belum ada sebagai implementasi default dalam kontrol UWP. Misalnya, pola untuk anotasi tidak diimplementasikan dalam salah satu kontrol XAML default. Tetapi Anda mungkin memiliki aplikasi yang menggunakan anotasi secara ekstensif dan oleh karena itu Anda ingin memunculkan fungsionalitas tersebut agar dapat diakses. Untuk skenario ini, rekan Anda harus menerapkan IAnnotationProvider dan mungkin harus melaporkan dirinya sebagai jenis kontrol Dokumen dengan properti yang sesuai untuk menunjukkan bahwa dokumen Anda mendukung anotasi.
Kami menyarankan agar Anda menggunakan panduan yang Anda lihat untuk pola di bawah Menerapkan Pola Kontrol Automasi UI atau jenis kontrol di bawah Mendukung Jenis Kontrol Automasi UI sebagai orientasi dan panduan umum. Anda bahkan dapat mencoba mengikuti beberapa tautan API untuk deskripsi dan komentar tentang tujuan API. Tetapi untuk spesifikasi sintaksis yang diperlukan untuk pemrograman aplikasi UWP, temukan API yang setara dalam namespace Layanan Windows.UI.Xaml.Automation.Provider dan gunakan halaman referensi tersebut untuk informasi selengkapnya.
Kelas peer otomatisasi bawaan
Secara umum, elemen menerapkan kelas peer otomatisasi jika mereka menerima aktivitas UI dari pengguna, atau jika berisi informasi yang diperlukan oleh pengguna teknologi bantuan yang mewakili UI aplikasi interaktif atau bermakna. Tidak semua elemen visual UWP memiliki rekan otomatisasi. Contoh kelas yang mengimplementasikan rekan otomatisasi adalah Tombol dan Kotak Teks. Contoh kelas yang tidak menerapkan rekan otomatisasi adalah Batas dan kelas berdasarkan Panel, seperti Kisi dan Kanvas. Panel tidak memiliki peer karena menyediakan perilaku tata letak yang hanya visual. Tidak ada cara yang relevan dengan aksesibilitas bagi pengguna untuk berinteraksi dengan Panel. Elemen turunan apa pun yang dikandung Panel dilaporkan ke pohon Automation UI sebagai elemen turunan dari induk berikutnya yang tersedia di pohon yang memiliki representasi serekan atau elemen.
Batasan proses UI Automation dan UWP
Biasanya, kode klien Automation UI yang mengakses aplikasi UWP berjalan di luar proses. Infrastruktur kerangka kerja Automation UI memungkinkan informasi untuk melintasi batas proses. Konsep ini dijelaskan secara lebih rinci dalam Dasar-Dasar Automasi UI.
OnCreateAutomationPeer
Semua kelas yang berasal dari UIElement berisi metode virtual yang dilindungi OnCreateAutomationPeer. Urutan inisialisasi objek untuk rekan otomatisasi memanggil OnCreateAutomationPeer untuk mendapatkan objek peer otomatisasi untuk setiap kontrol dan dengan demikian untuk membangun pohon Automation UI untuk penggunaan run-time. Kode Automasi UI dapat menggunakan serekan untuk mendapatkan informasi tentang karakteristik dan fitur kontrol dan untuk mensimulasikan penggunaan interaktif melalui pola kontrolnya. Kontrol kustom yang mendukung otomatisasi harus mengambil alih OnCreateAutomationPeer dan mengembalikan instans kelas yang berasal dari AutomationPeer. Misalnya, jika kontrol kustom berasal dari kelas ButtonBase, objek yang dikembalikan oleh OnCreateAutomationPeer harus berasal dari ButtonBaseAutomationPeer.
Jika Anda menulis kelas kontrol kustom dan ingin juga menyediakan serekan otomatisasi baru, Anda harus mengambil alih metode OnCreateAutomationPeer untuk kontrol kustom Anda sehingga mengembalikan instans baru rekan Anda. Kelas serekan Anda harus berasal secara langsung atau tidak langsung dari AutomationPeer.
Misalnya, kode berikut menyatakan bahwa kontrol NumericUpDown
kustom harus menggunakan serekan NumericUpDownPeer
untuk tujuan Automasi UI.
using Windows.UI.Xaml.Automation.Peers;
...
public class NumericUpDown : RangeBase {
public NumericUpDown() {
// other initialization; DefaultStyleKey etc.
}
...
protected override AutomationPeer OnCreateAutomationPeer()
{
return new NumericUpDownAutomationPeer(this);
}
}
Public Class NumericUpDown
Inherits RangeBase
' other initialization; DefaultStyleKey etc.
Public Sub New()
End Sub
Protected Overrides Function OnCreateAutomationPeer() As AutomationPeer
Return New NumericUpDownAutomationPeer(Me)
End Function
End Class
// NumericUpDown.idl
namespace MyNamespace
{
runtimeclass NumericUpDown : Windows.UI.Xaml.Controls.Primitives.RangeBase
{
NumericUpDown();
Int32 MyProperty;
}
}
// NumericUpDown.h
...
struct NumericUpDown : NumericUpDownT<NumericUpDown>
{
...
Windows::UI::Xaml::Automation::Peers::AutomationPeer OnCreateAutomationPeer()
{
return winrt::make<MyNamespace::implementation::NumericUpDownAutomationPeer>(*this);
}
};
//.h
public ref class NumericUpDown sealed : Windows::UI::Xaml::Controls::Primitives::RangeBase
{
// other initialization not shown
protected:
virtual AutomationPeer^ OnCreateAutomationPeer() override
{
return ref new NumericUpDownAutomationPeer(this);
}
};
Catatan
Implementasi OnCreateAutomationPeer tidak boleh melakukan apa pun selain menginisialisasi instans baru dari peer otomatisasi kustom Anda, meneruskan kontrol panggilan sebagai pemilik, dan mengembalikan instans tersebut. Jangan coba logika tambahan dalam metode ini. Secara khusus, logika apa pun yang berpotensi menyebabkan penghancuran AutomationPeer dalam panggilan yang sama dapat mengakibatkan perilaku runtime yang tidak terduga.
Dalam implementasi umum OnCreateAutomationPeer, pemilik ditentukan sebagai ini atau Saya karena metode mengambil alih berada dalam cakupan yang sama dengan definisi kelas kontrol lainnya.
Definisi kelas serekan aktual dapat dilakukan dalam file kode yang sama dengan kontrol atau dalam file kode terpisah. Definisi serekan semuanya ada di namespace layanan Windows.UI.Xaml.Automation.Peers yang merupakan namespace terpisah dari kontrol yang disediakan rekan-rekan. Anda dapat memilih untuk mendeklarasikan rekan-rekan Anda di namespace terpisah juga, selama Anda mereferensikan namespace yang diperlukan untuk panggilan metode OnCreateAutomationPeer.
Memilih kelas dasar serekan yang benar
Pastikan AutomationPeer Anda berasal dari kelas dasar yang memberi Anda kecocokan terbaik untuk logika serekan yang ada dari kelas kontrol yang Anda inginkan. Dalam kasus contoh sebelumnya, karena NumericUpDown
berasal dari RangeBase, ada kelas RangeBaseAutomationPeer yang tersedia yang harus Anda dasarkan serekan Anda. Dengan menggunakan kelas serekan yang paling cocok secara paralel dengan cara Anda mendapatkan kontrol itu sendiri, Anda dapat menghindari penimpaan setidaknya beberapa fungsionalitas IRangeValueProvider karena kelas peer dasar sudah mengimplementasikannya.
Kelas Kontrol dasar tidak memiliki kelas serekan yang sesuai. Jika Anda memerlukan kelas serekan yang sesuai dengan kontrol kustom yang berasal dari Kontrol, dapatkan kelas serekan kustom dari FrameworkElementAutomationPeer.
Jika Anda berasal dari ContentControl secara langsung, kelas tersebut tidak memiliki perilaku serekan otomatisasi default karena tidak ada implementasi OnCreateAutomationPeer yang mereferensikan kelas serekan. Jadi pastikan untuk mengimplementasikan OnCreateAutomationPeer untuk menggunakan rekan Anda sendiri, atau untuk menggunakan FrameworkElementAutomationPeer sebagai serekan jika tingkat dukungan aksesibilitas tersebut memadai untuk kontrol Anda.
Catatan
Anda biasanya tidak berasal dari AutomationPeer daripada FrameworkElementAutomationPeer. Jika Anda berasal langsung dari AutomationPeer , Anda harus menduplikasi banyak dukungan aksesibilitas dasar yang jika tidak akan berasal dari FrameworkElementAutomationPeer.
Inisialisasi kelas peer kustom
Peer otomatisasi harus menentukan konstruktor jenis aman yang menggunakan instans kontrol pemilik untuk inisialisasi dasar. Dalam contoh berikutnya, implementasi meneruskan nilai pemilik ke basis RangeBaseAutomationPeer, dan pada akhirnya itu adalah FrameworkElementAutomationPeer yang benar-benar menggunakan pemilik untuk mengatur FrameworkElementAutomationPeer.Owner.
public NumericUpDownAutomationPeer(NumericUpDown owner): base(owner)
{}
Public Sub New(owner As NumericUpDown)
MyBase.New(owner)
End Sub
// NumericUpDownAutomationPeer.idl
import "NumericUpDown.idl";
namespace MyNamespace
{
runtimeclass NumericUpDownAutomationPeer : Windows.UI.Xaml.Automation.Peers.AutomationPeer
{
NumericUpDownAutomationPeer(NumericUpDown owner);
Int32 MyProperty;
}
}
// NumericUpDownAutomationPeer.h
...
struct NumericUpDownAutomationPeer : NumericUpDownAutomationPeerT<NumericUpDownAutomationPeer>
{
...
NumericUpDownAutomationPeer(MyNamespace::NumericUpDown const& owner);
};
//.h
public ref class NumericUpDownAutomationPeer sealed : Windows::UI::Xaml::Automation::Peers::RangeBaseAutomationPeer
//.cpp
public: NumericUpDownAutomationPeer(NumericUpDown^ owner);
Metode inti AutomationPeer
Untuk alasan infrastruktur UWP, metode yang dapat diambil alih dari serekan otomatisasi adalah bagian dari sepasang metode: metode akses publik yang digunakan penyedia Automation UI sebagai titik penerusan untuk klien Automation UI, dan metode kustomisasi "Core" yang dilindungi yang dapat diambil alih kelas UWP untuk memengaruhi perilaku. Pasangan metode disatukan secara default sewaktu-waktu sehingga panggilan ke metode akses selalu memanggil metode "Core" paralel yang memiliki implementasi penyedia, atau sebagai fallback, memanggil implementasi default dari kelas dasar.
Saat menerapkan serekan untuk kontrol kustom, ambil alih salah satu metode "Core" dari kelas peer otomatisasi dasar tempat Anda ingin mengekspos perilaku yang unik untuk kontrol kustom Anda. Kode Automasi UI mendapatkan informasi tentang kontrol Anda dengan memanggil metode publik kelas serekan. Untuk memberikan informasi tentang kontrol Anda, ganti setiap metode dengan nama yang diakhir dengan "Core" saat implementasi dan desain kontrol Anda membuat skenario aksesibilitas atau skenario Automasi UI lainnya yang berbeda dari apa yang didukung oleh kelas peer otomatisasi dasar.
Minimal, setiap kali Anda menentukan kelas peer baru, terapkan metode GetClassNameCore , seperti yang ditunjukkan pada contoh berikutnya.
protected override string GetClassNameCore()
{
return "NumericUpDown";
}
Catatan
Anda mungkin ingin menyimpan string sebagai konstanta daripada langsung dalam isi metode, tetapi itu terserah Anda. Untuk GetClassNameCore, Anda tidak perlu melokalisasi string ini. Properti LocalizedControlType digunakan kapan saja string yang dilokalkan diperlukan oleh klien Automation UI, bukan ClassName.
GetAutomationControlType
Beberapa teknologi bantuan menggunakan nilai GetAutomationControlType secara langsung saat melaporkan karakteristik item di pohon Automation UI, sebagai informasi tambahan di luar Nama Automasi UI. Jika kontrol Anda secara signifikan berbeda dari kontrol yang Anda turunkan dan Anda ingin melaporkan jenis kontrol yang berbeda dari apa yang dilaporkan oleh kelas peer dasar yang digunakan oleh kontrol, Anda harus menerapkan serekan dan mengambil alih GetAutomationControlTypeCore dalam implementasi serekan Anda. Ini sangat penting jika Anda berasal dari kelas dasar umum seperti ItemsControl atau ContentControl, di mana peer dasar tidak memberikan informasi yang tepat tentang jenis kontrol.
Implementasi GetAutomationControlTypeCore menjelaskan kontrol Anda dengan mengembalikan nilai AutomationControlType. Meskipun Anda dapat mengembalikan AutomationControlType.Custom, Anda harus mengembalikan salah satu jenis kontrol yang lebih spesifik jika secara akurat menjelaskan skenario utama kontrol Anda. Berikut adalah contoh.
protected override AutomationControlType GetAutomationControlTypeCore()
{
return AutomationControlType.Spinner;
}
Catatan
Kecuali Anda menentukan AutomationControlType.Custom, Anda tidak perlu menerapkan GetLocalizedControlTypeCore untuk memberikan nilai properti LocalizedControlType kepada klien. Infrastruktur umum Automation UI menyediakan string yang diterjemahkan untuk setiap kemungkinan nilai AutomationControlType selain AutomationControlType.Custom.
GetPattern dan GetPatternCore
Implementasi peer GetPatternCore mengembalikan objek yang mendukung pola yang diminta dalam parameter input. Secara khusus, klien Automation UI memanggil metode yang diteruskan ke metode GetPattern penyedia, dan menentukan nilai enumerasi PatternInterface yang menamai pola yang diminta. Penimpaan GetPatternCore Anda harus mengembalikan objek yang mengimplementasikan pola yang ditentukan. Objek itu adalah serekan itu sendiri, karena serekan harus mengimplementasikan antarmuka pola yang sesuai setiap kali melaporkan bahwa ia mendukung pola. Jika rekan Anda tidak memiliki implementasi kustom pola, tetapi Anda tahu bahwa basis serekan memang menerapkan pola, Anda dapat memanggil implementasi getPatternCore jenis dasar dari GetPatternCore Anda. GetPatternCore serekan harus mengembalikan null jika pola tidak didukung oleh serekan. Namun, alih-alih mengembalikan null langsung dari implementasi Anda, Anda biasanya akan mengandalkan panggilan ke implementasi dasar untuk mengembalikan null untuk pola yang tidak didukung.
Ketika pola didukung, implementasi GetPatternCore dapat mengembalikan ini atau Saya. Harapannya adalah bahwa klien Automation UI akan mentransmisikan nilai pengembalian GetPattern ke antarmuka pola yang diminta setiap kali tidak null.
Jika kelas serekan mewarisi dari serekan lain, dan semua dukungan dan pelaporan pola yang diperlukan sudah ditangani oleh kelas dasar, menerapkan GetPatternCore tidak diperlukan. Misalnya, jika Anda menerapkan kontrol rentang yang berasal dari RangeBase, dan rekan Anda berasal dari RangeBaseAutomationPeer, rekan tersebut mengembalikan dirinya sendiri untuk PatternInterface.RangeValue dan memiliki implementasi kerja antarmuka IRangeValueProvider yang mendukung pola.
Meskipun bukan kode harfiah, contoh ini memperkirakan implementasi GetPatternCore yang sudah ada di RangeBaseAutomationPeer.
protected override object GetPatternCore(PatternInterface patternInterface)
{
if (patternInterface == PatternInterface.RangeValue)
{
return this;
}
return base.GetPatternCore(patternInterface);
}
Jika Anda menerapkan serekan di mana Anda tidak memiliki semua dukungan yang Anda butuhkan dari kelas peer dasar, atau Anda ingin mengubah atau menambahkan ke kumpulan pola yang diwariskan dasar yang dapat didukung rekan Anda, maka Anda harus mengambil alih GetPatternCore untuk memungkinkan klien Automation UI menggunakan pola.
Untuk daftar pola penyedia yang tersedia dalam implementasi UWP dukungan Automation UI, lihat Windows.UI.Xaml.Automation.Provider. Setiap pola tersebut memiliki nilai yang sesuai dari enumerasi PatternInterface, yaitu bagaimana klien Automation UI meminta pola dalam panggilan GetPattern.
Serekan dapat melaporkan bahwa ia mendukung lebih dari satu pola. Jika demikian, penimpaan harus menyertakan logika jalur pengembalian untuk setiap nilai PatternInterface yang didukung dan mengembalikan peer di setiap kasus yang cocok. Diharapkan bahwa penelepon hanya akan meminta satu antarmuka pada satu waktu, dan terserah pemanggil untuk mentransmisian ke antarmuka yang diharapkan.
Berikut adalah contoh penggantian GetPatternCore untuk serekan kustom. Ini melaporkan dukungan untuk dua pola, IRangeValueProvider dan IToggleProvider. Kontrol di sini adalah kontrol tampilan media yang dapat ditampilkan sebagai layar penuh (mode pengalih) dan yang memiliki bilah kemajuan di mana pengguna dapat memilih posisi (kontrol rentang). Kode ini berasal dari sampel aksesibilitas XAML.
protected override object GetPatternCore(PatternInterface patternInterface)
{
if (patternInterface == PatternInterface.RangeValue)
{
return this;
}
else if (patternInterface == PatternInterface.Toggle)
{
return this;
}
return null;
}
Pola penerusan dari sub-elemen
Implementasi metode GetPatternCore juga dapat menentukan sub-elemen atau bagian sebagai penyedia pola untuk hostnya. Contoh ini meniru bagaimana ItemsControl mentransfer penanganan pola gulir ke serekan kontrol ScrollViewer internalnya. Untuk menentukan sub-elemen untuk penanganan pola, kode ini mendapatkan objek sub-elemen, membuat serekan untuk sub-elemen dengan menggunakan metode FrameworkElementAutomationPeer.CreatePeerForElement , dan mengembalikan peer baru.
protected override object GetPatternCore(PatternInterface patternInterface)
{
if (patternInterface == PatternInterface.Scroll)
{
ItemsControl owner = (ItemsControl) base.Owner;
UIElement itemsHost = owner.ItemsHost;
ScrollViewer element = null;
while (itemsHost != owner)
{
itemsHost = VisualTreeHelper.GetParent(itemsHost) as UIElement;
element = itemsHost as ScrollViewer;
if (element != null)
{
break;
}
}
if (element != null)
{
AutomationPeer peer = FrameworkElementAutomationPeer.CreatePeerForElement(element);
if ((peer != null) && (peer is IScrollProvider))
{
return (IScrollProvider) peer;
}
}
}
return base.GetPatternCore(patternInterface);
}
Metode Inti lainnya
Kontrol Anda mungkin perlu mendukung setara keyboard untuk skenario utama; untuk informasi selengkapnya tentang mengapa ini mungkin diperlukan, lihat Aksesibilitas keyboard. Menerapkan dukungan kunci tentu merupakan bagian dari kode kontrol dan bukan kode serekan karena itu adalah bagian dari logika kontrol, tetapi kelas serekan Anda harus mengambil alih metode GetAcceleratorKeyCore dan GetAccessKeyCore untuk melaporkan ke klien Automation UI yang kuncinya digunakan. Pertimbangkan bahwa string yang melaporkan informasi kunci mungkin perlu dilokalkan, dan karenanya harus berasal dari sumber daya, bukan string yang dikodekan secara permanen.
Jika Anda menyediakan serekan untuk kelas yang mendukung koleksi, yang terbaik adalah berasal dari kelas fungsional dan kelas serekan yang sudah memiliki dukungan koleksi semacam itu. Jika Anda tidak dapat melakukannya, serekan untuk kontrol yang mempertahankan koleksi anak mungkin harus mengambil alih metode serekan terkait koleksi GetChildrenCore untuk melaporkan hubungan induk-anak dengan benar ke pohon Automation UI.
Terapkan metode IsContentElementCore dan IsControlElementCore untuk menunjukkan apakah kontrol Anda berisi konten data atau memenuhi peran interaktif di antarmuka pengguna (atau keduanya). Secara default, kedua metode mengembalikan true. Pengaturan ini meningkatkan kegunaan teknologi bantuan seperti pembaca layar, yang dapat menggunakan metode ini untuk memfilter pohon otomatisasi. Jika metode GetPatternCore Anda mentransfer penanganan pola ke serekan sub-elemen, metode IsControlElementCore peer sub-elemen dapat mengembalikan false untuk menyembunyikan peer sub-elemen dari pohon otomatisasi.
Beberapa kontrol mungkin mendukung skenario pelabelan, di mana bagian label teks menyediakan informasi untuk bagian non-teks, atau kontrol dimaksudkan untuk berada dalam hubungan pelabelan yang diketahui dengan kontrol lain di UI. Jika memungkinkan untuk memberikan perilaku berbasis kelas yang berguna, Anda dapat mengambil alih GetLabeledByCore untuk memberikan perilaku ini.
GetBoundingRectangleCore dan GetClickablePointCore digunakan terutama untuk skenario pengujian otomatis. Jika Anda ingin mendukung pengujian otomatis untuk kontrol, Anda mungkin ingin mengambil alih metode ini. Ini mungkin diinginkan untuk kontrol jenis rentang, di mana Anda tidak dapat menyarankan hanya satu titik karena di mana pengguna mengklik ruang koordinat memiliki efek yang berbeda pada rentang. Misalnya, peer automasi ScrollBar default mengambil alih GetClickablePointCore untuk mengembalikan nilai Titik "bukan angka".
GetLiveSettingCore memengaruhi default kontrol untuk nilai LiveSetting untuk Automasi UI. Anda mungkin ingin mengambil alih ini jika Anda ingin kontrol mengembalikan nilai selain AutomationLiveSetting.Off. Untuk informasi selengkapnya tentang apa yang diwakili LiveSetting, lihat AutomationProperties.LiveSetting.
Anda dapat mengambil alih GetOrientationCore jika kontrol Anda memiliki properti orientasi yang dapat diatur yang dapat dipetakan ke AutomationOrientation. Kelas ScrollBarAutomationPeer dan SliderAutomationPeer melakukan ini.
Implementasi dasar dalam FrameworkElementAutomationPeer
Implementasi dasar FrameworkElementAutomationPeer menyediakan beberapa informasi Automation UI yang dapat ditafsirkan dari berbagai properti tata letak dan perilaku yang ditentukan pada tingkat kerangka kerja.
- GetBoundingRectangleCore: Mengembalikan struktur Rect berdasarkan karakteristik tata letak yang diketahui. Mengembalikan Rect 0-value jika IsOffscreen benar.
- GetClickablePointCore: Mengembalikan struktur Titik berdasarkan karakteristik tata letak yang diketahui, selama ada BoundingRectangle nonzero.
- GetNameCore: Perilaku yang lebih luas daripada yang dapat dirangkum di sini; lihat GetNameCore. Pada dasarnya, ia mencoba konversi string pada konten ContentControl yang diketahui atau kelas terkait yang memiliki konten. Selain itu, jika ada nilai untuk LabeledBy, nilai Nama item tersebut digunakan sebagai Nama.
- HasKeyboardFocusCore: Dievaluasi berdasarkan properti FocusState dan IsEnabled pemilik. Elemen yang tidak mengontrol selalu mengembalikan false.
- IsEnabledCore: Dievaluasi berdasarkan properti IsEnabled pemilik jika merupakan Kontrol. Elemen yang tidak dikontrol selalu mengembalikan true. Ini tidak berarti bahwa pemilik diaktifkan dalam arti interaksi konvensional; itu berarti bahwa serekan diaktifkan meskipun pemilik tidak memiliki properti IsEnabled .
- IsKeyboardFocusableCore: Mengembalikan true jika pemilik adalah Kontrol; jika tidak, itu salah.
- IsOffscreenCore: Visibilitas Diciutkan pada elemen pemilik atau salah satu induknya sama dengan nilai sebenarnya untuk IsOffscreen. Pengecualian: objek Popup dapat terlihat meskipun orang tua pemiliknya tidak.
- SetFocusCore: Memanggil Fokus.
- GetParent: Memanggil FrameworkElement.Parent dari pemilik, dan mencari rekan yang sesuai. Ini bukan pasangan penimpaan dengan metode "Core", sehingga Anda tidak dapat mengubah perilaku ini.
Catatan
Serekan UWP default menerapkan perilaku dengan menggunakan kode asli internal yang mengimplementasikan UWP, tidak harus dengan menggunakan kode UWP aktual. Anda tidak akan dapat melihat kode atau logika implementasi melalui refleksi common language runtime (CLR) atau teknik lainnya. Anda juga tidak akan melihat halaman referensi yang berbeda untuk penggantian khusus subkelas perilaku peer dasar. Misalnya, mungkin ada perilaku tambahan untuk GetNameCore dari TextBoxAutomationPeer, yang tidak akan dijelaskan pada halaman referensi AutomationPeer.GetNameCore , dan tidak ada halaman referensi untuk TextBoxAutomationPeer.GetNameCore. Bahkan tidak ada halaman referensi TextBoxAutomationPeer.GetNameCore . Sebagai gantinya, baca topik referensi untuk kelas serekan paling langsung, dan cari catatan implementasi di bagian Keterangan.
Rekan dan AutomationProperties
Peer otomatisasi Anda harus memberikan nilai default yang sesuai untuk informasi terkait aksesibilitas kontrol Anda. Perhatikan bahwa kode aplikasi apa pun yang menggunakan kontrol dapat mengambil alih beberapa perilaku tersebut dengan menyertakan nilai properti terlampir AutomationProperties pada instans kontrol. Penelepon dapat melakukan ini baik untuk kontrol default atau untuk kontrol kustom. Misalnya, XAML berikut membuat tombol yang memiliki dua properti Automation UI yang disesuaikan: <Button AutomationProperties.Name="Special" AutomationProperties.HelpText="This is a special button."/>
Untuk informasi selengkapnya tentang properti terlampir AutomationProperties , lihat Informasi aksesibilitas dasar.
Beberapa metode AutomationPeer ada karena kontrak umum tentang bagaimana penyedia Automation UI diharapkan melaporkan informasi, tetapi metode ini biasanya tidak diimplementasikan dalam rekan kontrol. Ini karena info tersebut diharapkan disediakan oleh nilai AutomationProperties yang diterapkan ke kode aplikasi yang menggunakan kontrol di UI tertentu. Misalnya, sebagian besar aplikasi akan menentukan hubungan pelabelan antara dua kontrol berbeda di UI dengan menerapkan nilai AutomationProperties.LabeledBy. Namun, LabeledByCore diimplementasikan dalam serekan tertentu yang mewakili hubungan data atau item dalam kontrol, seperti menggunakan bagian header untuk melabeli bagian bidang data, melabeli item dengan kontainer mereka, atau skenario serupa.
Menerapkan pola
Mari kita lihat cara menulis serekan untuk kontrol yang mengimplementasikan perilaku expand-collapse dengan menerapkan antarmuka pola kontrol untuk expand-collapse. Peer harus mengaktifkan aksesibilitas untuk perilaku expand-collapse dengan mengembalikan dirinya sendiri setiap kali GetPattern dipanggil dengan nilai PatternInterface.ExpandCollapse. Rekan kemudian harus mewarisi antarmuka penyedia untuk pola tersebut (IExpandCollapseProvider) dan memberikan implementasi untuk setiap anggota antarmuka penyedia tersebut. Dalam hal ini antarmuka memiliki tiga anggota untuk diambil alih: Perluas, Ciutkan, ExpandCollapseState.
Sangat membantu untuk merencanakan ke depan untuk aksesibilitas dalam desain API kelas itu sendiri. Setiap kali Anda memiliki perilaku yang berpotensi diminta baik sebagai akibat dari interaksi umum dengan pengguna yang bekerja di UI atau melalui pola penyedia otomatisasi, berikan satu metode yang dapat dipanggil oleh respons UI atau pola otomatisasi. Misalnya, jika kontrol Anda memiliki bagian tombol yang memiliki penanganan aktivitas kabel yang dapat memperluas atau menciutkan kontrol, dan memiliki keyboard yang setara untuk tindakan tersebut, minta penanganan aktivitas ini memanggil metode yang sama dengan yang Anda panggil dari dalam isi implementasi Perluas atau Ciutkan untuk IExpandCollapseProvider di serekan. Menggunakan metode logika umum juga dapat menjadi cara yang berguna untuk memastikan bahwa status visual kontrol Anda diperbarui untuk menunjukkan status logis dengan cara yang seragam, terlepas dari bagaimana perilaku dipanggil.
Implementasi umumnya adalah api penyedia pertama kali memanggil Pemilik untuk akses ke instans kontrol pada waktu proses. Kemudian metode perilaku yang diperlukan dapat dipanggil pada objek tersebut.
public class IndexCardAutomationPeer : FrameworkElementAutomationPeer, IExpandCollapseProvider {
private IndexCard ownerIndexCard;
public IndexCardAutomationPeer(IndexCard owner) : base(owner)
{
ownerIndexCard = owner;
}
}
Implementasi alternatif adalah bahwa kontrol itu sendiri dapat mereferensikan rekan-rekannya. Ini adalah pola umum jika Anda meningkatkan peristiwa otomatisasi dari kontrol, karena metode RaiseAutomationEvent adalah metode serekan.
Peristiwa Automasi UI
Peristiwa UI Automation termasuk dalam kategori berikut.
Kejadian | Deskripsi |
---|---|
Perubahan properti | Diaktifkan saat properti pada elemen Automation UI atau pola kontrol berubah. Misalnya, jika klien perlu memantau kontrol kotak centang aplikasi, klien dapat mendaftar untuk mendengarkan peristiwa perubahan properti di properti ToggleState. Ketika kontrol kotak centang dicentang atau tidak dicentang, penyedia mengaktifkan peristiwa dan klien dapat bertindak seperlunya. |
Tindakan elemen | Diaktifkan saat perubahan UI dihasilkan dari pengguna atau aktivitas terprogram; misalnya, ketika tombol diklik atau dipanggil melalui pola Panggil . |
Perubahan struktur | Diaktifkan ketika struktur pohon Automation UI berubah. Struktur berubah ketika item UI baru menjadi terlihat, tersembunyi, atau dihapus di desktop. |
Perubahan global | Menembak ketika tindakan minat global kepada klien terjadi, seperti ketika fokus bergeser dari satu elemen ke elemen lain, atau ketika jendela anak ditutup. Beberapa peristiwa tidak selalu berarti bahwa status UI telah berubah. Misalnya, jika tab pengguna ke bidang entri teks lalu mengklik tombol untuk memperbarui bidang, peristiwa TextChanged diaktifkan bahkan jika pengguna tidak benar-benar mengubah teks. Ketika memproses peristiwa, mungkin perlu bagi aplikasi klien untuk memeriksa apakah ada yang benar-benar berubah sebelum mengambil tindakan. |
Pengidentifikasi AutomationEvents
Peristiwa Automasi UI diidentifikasi oleh nilai AutomationEvents. Nilai enumerasi secara unik mengidentifikasi jenis peristiwa.
Menaikkan peristiwa
Klien Automation UI dapat berlangganan peristiwa otomatisasi. Dalam model serekan otomatisasi, serekan untuk kontrol kustom harus melaporkan perubahan pada status kontrol yang relevan dengan aksesibilitas dengan memanggil metode RaiseAutomationEvent. Demikian pula, ketika nilai properti Automation UI kunci berubah, rekan kontrol kustom harus memanggil metode RaisePropertyChangedEvent.
Contoh kode berikutnya menunjukkan cara mendapatkan objek serekan dari dalam kode definisi kontrol dan memanggil metode untuk menembakkan peristiwa dari peer tersebut. Sebagai pengoptimalan, kode menentukan apakah ada pendengar untuk jenis peristiwa ini. Menembakkan peristiwa dan membuat objek serekan hanya ketika ada pendengar menghindari overhead yang tidak perlu dan membantu kontrol tetap responsif.
if (AutomationPeer.ListenerExists(AutomationEvents.PropertyChanged))
{
NumericUpDownAutomationPeer peer =
FrameworkElementAutomationPeer.FromElement(nudCtrl) as NumericUpDownAutomationPeer;
if (peer != null)
{
peer.RaisePropertyChangedEvent(
RangeValuePatternIdentifiers.ValueProperty,
(double)oldValue,
(double)newValue);
}
}
Navigasi serekan
Setelah menemukan serekan otomatisasi, klien Automation UI dapat menavigasi struktur serekan aplikasi dengan memanggil metode GetChildren dan GetParent objek serekan. Navigasi di antara elemen UI dalam kontrol didukung oleh implementasi serekan dari metode GetChildrenCore. Sistem Automasi UI memanggil metode ini untuk membangun pohon sub-elemen yang terkandung dalam kontrol; misalnya, mencantumkan item dalam kotak daftar. Metode GetChildrenCore default di FrameworkElementAutomationPeer melintasi pohon visual elemen untuk membangun pohon rekan otomatisasi. Kontrol kustom dapat mengambil alih metode ini untuk mengekspos representasi elemen turunan yang berbeda ke klien otomatisasi, mengembalikan rekan otomatisasi elemen yang menyampaikan informasi atau mengizinkan interaksi pengguna.
Dukungan otomatisasi asli untuk pola teks
Beberapa rekan otomatisasi aplikasi UWP default menyediakan dukungan pola kontrol untuk pola teks (PatternInterface.Text). Tetapi mereka memberikan dukungan ini melalui metode asli, dan rekan-rekan yang terlibat tidak akan mencatat antarmuka ITextProvider dalam pewarisan (terkelola). Namun, jika klien Automation UI terkelola atau tidak dikelola meminta peer untuk pola, klien akan melaporkan dukungan untuk pola teks, dan memberikan perilaku untuk bagian pola ketika API klien dipanggil.
Jika Anda ingin mendapatkan dari salah satu kontrol teks aplikasi UWP dan juga membuat serekan kustom yang berasal dari salah satu rekan terkait teks, periksa bagian Remarks agar rekan mempelajari lebih lanjut tentang dukungan tingkat asli untuk pola. Anda dapat mengakses perilaku dasar asli di serekan kustom jika Anda memanggil implementasi dasar dari implementasi antarmuka penyedia terkelola Anda, tetapi sulit untuk memodifikasi apa yang dilakukan implementasi dasar karena antarmuka asli pada peer dan kontrol pemiliknya tidak terekspos. Umumnya Anda harus menggunakan implementasi dasar apa adanya (hanya basis panggilan) atau sepenuhnya mengganti fungsionalitas dengan kode terkelola Anda sendiri dan tidak memanggil implementasi dasar. Yang terakhir adalah skenario lanjutan, Anda akan membutuhkan keakraban yang baik dengan kerangka kerja layanan teks yang digunakan oleh kontrol Anda untuk mendukung persyaratan aksesibilitas saat menggunakan kerangka kerja tersebut.
AutomationProperties.AccessibilityView
Selain menyediakan peer kustom, Anda juga dapat menyesuaikan representasi tampilan pohon untuk instans kontrol apa pun, dengan mengatur AutomationProperties.AccessibilityView di XAML. Ini tidak diimplementasikan sebagai bagian dari kelas serekan, tetapi kami akan menyebutkannya di sini karena jerman untuk dukungan aksesibilitas keseluruhan baik untuk kontrol kustom atau untuk templat yang Anda sesuaikan.
Skenario utama untuk menggunakan AutomationProperties.AccessibilityView adalah dengan sengaja menghilangkan kontrol tertentu dalam templat dari tampilan Automation UI, karena tidak berkontribusi secara bermakna pada tampilan aksesibilitas seluruh kontrol. Untuk mencegah hal ini, atur AutomationProperties.AccessibilityView ke "Raw".
Melemparkan pengecualian dari rekan otomatisasi
API yang Anda terapkan untuk dukungan serekan otomatisasi Anda diizinkan untuk melemparkan pengecualian. Diharapkan setiap klien Automation UI yang mendengarkan cukup kuat untuk melanjutkan setelah sebagian besar pengecualian dilemparkan. Dalam semua kemungkinan bahwa pendengar melihat pohon otomatisasi all-up yang mencakup aplikasi selain milik Anda sendiri, dan itu adalah desain klien yang tidak dapat diterima untuk menurunkan seluruh klien hanya karena satu area pohon melemparkan pengecualian berbasis serekan ketika klien memanggil API-nya.
Untuk parameter yang diteruskan ke rekan Anda, dapat diterima untuk memvalidasi input, dan misalnya melemparkan ArgumentNullException jika diteruskan null dan itu bukan nilai yang valid untuk implementasi Anda. Namun, jika ada operasi berikutnya yang dilakukan oleh serekan Anda, ingatlah bahwa interaksi serekan dengan kontrol hosting memiliki sesuatu dari karakter asinkron bagi mereka. Apa pun yang dilakukan serekan tidak akan selalu memblokir utas UI dalam kontrol (dan mungkin tidak seharusnya). Jadi Anda bisa memiliki situasi di mana objek tersedia atau memiliki properti tertentu ketika serekan dibuat atau ketika metode peer otomatisasi pertama kali dipanggil, tetapi sementara itu status kontrol telah berubah. Untuk kasus ini, ada dua pengecualian khusus yang dapat dilemparkan oleh penyedia:
- Throw ElementNotAvailableException jika Anda tidak dapat mengakses pemilik serekan atau elemen serekan terkait berdasarkan info asli API Anda diteruskan. Misalnya, Anda mungkin memiliki serekan yang mencoba menjalankan metodenya tetapi pemilik telah dihapus dari UI, seperti dialog modal yang telah ditutup. Untuk klien non-.NET, ini memetakan ke UIA_E_ELEMENTNOTAVAILABLE.
- Throw ElementNotEnabledException jika masih ada pemilik, tetapi pemilik tersebut berada dalam mode seperti IsEnabled
=
false yang memblokir beberapa perubahan terprogram tertentu yang coba dicapai rekan Anda. Untuk klien non-.NET, ini memetakan ke UIA_E_ELEMENTNOTENABLED.
Di luar ini, rekan-rekan harus relatif konservatif mengenai pengecualian yang mereka lemparkan dari dukungan serekan mereka. Sebagian besar klien tidak akan dapat menangani pengecualian dari rekan-rekan dan mengubahnya menjadi pilihan yang dapat ditindak lanjuti yang dapat dilakukan pengguna mereka saat berinteraksi dengan klien. Jadi terkadang tanpa operasi, dan menangkap pengecualian tanpa menjatuhkan kembali dalam implementasi serekan Anda, adalah strategi yang lebih baik daripada melemparkan pengecualian setiap kali sesuatu yang coba dilakukan rekan tidak berfungsi. Pertimbangkan juga bahwa sebagian besar klien Automation UI tidak ditulis dalam kode terkelola. Sebagian besar ditulis dalam COM dan hanya memeriksa S_OK di HRESULT setiap kali mereka memanggil metode klien Automation UI yang akhirnya mengakses serekan Anda.
Topik terkait
Windows developer