Bir önceki yazımda WPF’de kontrol içerisindeki kontrollerde oluşan “event” sorunundan bahsetmiştim. Aslında sorun değil, WPF’deki “event” yaklaşımının biraz farklılaştığını belirtmeye çalışmıştım. Bu yazıda biraz daha derinlere girip, WPF’deki “Routed Events”‘den bahsetmeye çalışacağım.

WPF, kullanıcı deneyiminin uygulamalarda daha rahat bir şekilde uygulanmasını amaçlıyordu hatırlarsanız. WPF’in ortaya ilk çıktığından beri Microsoft’un altını çizdiği nokta bu yönde. Bu bağlamda, standart bilgisayar uygulamalarında ki standart arayüzler yerine kullanıcının çok daha kolay kullanabileceği bir arayüz sunmak ve bu arayüz ile sunulan bilgileri de daha anlamlı bir görsellikte sunarak kullanıcı deneyimini uygulamalara katmak WPF’in ilerlediği yollardan bir tanesi diyebiliriz. Bu yaklaşımdan dolayı, WPF ile beraber alıştığımız kullanıcı kontrollerinden farklı bir yapı karşımıza çıkıyor. Tıkladığımız düğmeler WPF ile beraber daha farklı amaçlar için kullanılabilir hale geliyor. Ya da bir çok elemandan, seçim yapabileceğimiz kullanıcı kontrolleri içerik olarak daha anlamlı bilgiler içermeye başlıyor.

Mesela bir düğme(button)nin içine resim koyarak, düğmenin görselliğine farklı anlamlar yükleyebiliyoruz.Bu çok basit bir örnek oldu gerçi ama demek istediğim, WPF’de kullanıcı kontrollerini, farklılaştırarak zenginleştirebiliyoruz. Kontrolleri iç içe kullanabiliyoruz. Bir “button”(düğme) içine “image”(resim) kontrollü koymak gibi. Katmanlı bir kullanıcı kontrolü yapısı var demek biraz daha netleştirebilir belki.

“Routed Events” kavramı da bu yapıdan dolayı ortaya çıkıyor. Yukarıda bahsettiğim kontroller üzerinden örneklendirmek daha anlaşılır olacak sanırım. Aşağıdaki uyduruk resimde(:)) bir “button” içinde “image” var.

Şimdi “button”a tıklandığı zaman “click” olayı oluşur bildiğiniz üzere. Ve tıklandığı zaman ne olmasını istiyorsanız bu olaya(event) denk gelen metodda ilgili kodu yazarsınız. “button” tıklandığı zaman ne oluyorsa, aynı işlem üzerinde “image” kontrolü olan “button”a tıklandığında da olmalı. Tıklanan alan “image” kontrolüne denk geliyorsa tıklama işleminin “button” tarafından da anlaşılıyor olması lazım. Bundan dolayı “image” üzerinde bazı işlemlerin, “image”ı içeren kontroller tarafından da algılanabiliyor olması lazım. WPF bu işlemi “routed events” kavramı ile gerçekleştiriyor.Özetle WPF’de bir “event” başka elemanlara yönlendirilebiliyor.

Bir önceki yazıda gerçekleşen olayın sebebi bu yani. WPF’de bir uygulama geliştirirken, “routed events” kavramını kendi geliştireceğiniz kontrollerde kullanmanız kaçınılmaz olacaktır. İlerleyen yazılarda bununla ilgili çok basit bir örnek göstermeye çalışıyor olacağım…Şimdilik bu kadar.

Not: “button” ve “image” anlaşılır bir örnek olması açısından kullandığım kavramlar. WPF’deki mevcut tüm yapılar için “routed events” kavramı geçerlidir.

Geçen gün bir arkadaşımın WPF(Windows Presentation Foundation)’den çektiği dertleri Twitter’dan gördüm ve benzer bir sorunu yaşadığım için şaşkınlığını çok iyi anladım. WPF kavram olarak çok güzel şeyler vaad ediyor olsa da, açıkcası tam olarak oturmuş bir yapı olduğuna inanmıyorum. İlk çıktığı zamandan beri kendimce küçük uğraşlar ile WPF’i elimden geldiğince takip etmeye öğrenmeye çalıştım,çalışıyorum da. Diğer .NET Framework yapıları ile kıyaslandığında farklılıkları ve değişiklikler ciddi anlamda uğraştırıyor.Neyse çok dağıtmadan konuyu, özüne dönelim.

WPF’de “control” yapısı, ASP.NET ve Windows yapısına göre biraz daha farklı. Bu farklara değinmek şimdi uzayacağından sadece farklı olduğunun altını çizmek yeterli olacaktır şu aşamada.

Sorunumuz ne peki? TabControl içinde kullandığımız Listbox,Combobox gibi yapılarda “SelectionChanged” event’i(olayı) çalıştığı zaman tabcontrol’ün de “SelectionChanged” event’i çalışmakta.Bunun nedenlerini inceleyerek sorunu çözmek, WPF’i anlamak adına daha faydalı olacağından olayın en temeline inerek çözümü sunmaya çalışacağım.

WPF’de “Selector” diye bir sınıf var. Listbox,Combobox gibi seçme işleminin yapılabileceği kullanıcı kontrolleri bu sınıftan türemekte.  “Select” operasyonunun yapılacağı kontrollerin “Selector”dan türemesi kavram olarak bakıldığında çok normal. WPF’de TabControl diye bildiğimiz sekmeli bir yapı sunan kontrolde WPF’de “Selector”dan türemekte.Yani ListBox,Combobox ve TabControl aynı kategoride diyebiliriz daha basitçe.Bu kontrollerin “SelectionChanged” event’i Selector sınıfından gelmekte ve dinlenmekte. TabControl’ün veya Combobox’ın ne yazık ki kendilerine özgü düzenlenmiş bir SelectionChanged event’i yok.Bundan dolayı “Selector.SelectionChanged” event’i tetiklendiği zaman Selector sınıfından türeyen sınıflarda bu event’i kontrol etmeye çalıştıklarında başarılı olacaklardır.Yani daha açık bir şekilde; TabControl’ün SelectionChanged event’inde çalışan bir metodu olduğunu varsayalım:

Aynı şekilde Tabcontrol’ün içindeki bir ComboBox’ın da aynı event’de çalışacak bir metodu olduğunu varsayalım:

Uygulama çalıştığı zaman ComboBox’dan bir seçim yaptığınızda, ComboBox’ı içeren kontrolün(TabControl oluyor bu durumda) de SelectionChanged olduğu zaman çalışacak metod da çalışacaktır…Çok ilginç değil mi? Bunun nedeni yukarıdaki kısa açıklama. Ama asıl nedeni WPF’de ki event mekanizması.WPF ile beraber Routed Events diye bir kavram hayatımıza giriyor.Bir sonraki yazımda bunun ne olduğunu anlatmaya çalışacağım, çünkü WPF ile uğraşanlar için oldukça önemli bir şey olduğuna inanıyorum.Neyse sorunumuza dönelim…Şimdi en son combobox’ı seçmiştik ve tab kontrolününde metodu çalışmıştı. Bunu istemiyoruz tabi ki…Peki ne yapacağız…

Event argümanlarının(e parametresi oluyor metoddaki) “Handled” diye bir özelliği var. Bu özelliği “true” olarak değiştirdiğiniz zaman oluşan olayı(event) yakalamış olduğumuzu belirtiyoruz.

Bu sayede TabControl’ün event’i çalışmamış oluyor…WPF ile geliştirme yaparken, bu tarz sorunları aslında sorun olarak değilde, değişiklik olarak algılamak gerekiyor sanırım.Neyse şimdilik bu kadar…Her türlü soru,sorun,düşünce fikir paylaşımına açığım,bekliyorum…(: