Vault Data Standard on ComboBox Selection Changed

[BruceMcKee]

Is there a way to capture the actual ComboBox.SelectedItemChanged Event rather than having to use a data trigger for every possible option.

We have possibly converting several clients from other DM systems and they are used to highly customizable cascading dropdowns that can be up to 5 or 6 levels deep and they have the ability to modify the linked data which is in SQL tables to update the dropdowns as needed. This makes it highly ineffecient in using DataTriggers that are depending on the VALUE selected.

Thanks

Bruce McKee

[marco.mirandola]

Hi Bruce, yes, you can subscribe all the events that WPF offers from within PowerShell. The syntax is a bit different from Visual Studio. The reason is that Visual Studio hides some complexity (sounds ridiculous) while with PowerShell in this case we have to use the native code.

usually in C# you would do something like class.EventHandler += myEventHandler. This would basically add your function myEventHandler to the internal list of event handers for the given event.
The += symbol traduces internal into add_EventHandler(). so the PowerShell syntax would be class.AddEventHandler({myEventHandler})

In your case, let's assume you have a comboBox with the name myCombo. subscribing the SelectionChanged would translate into:

$dsWindow.FindName("myCombo").add_SelectionChanged({
param($sender,$e)
$dsDiag.Trace("selected value:"+$sender.SelectedValue);
})

Add the lines above into the InitializeWindow function so that the event handler is subscribed immediately when the dialog gets initialised.

the $dsDiag is basically the complete WPF dialog object. with FindName you'll get to the control you like to work with. obviously you have to name the controls. Then you can subscribe any event you lie just with add_xxxxx. With the internal param you can name the passed arguments as you like. in my case $sender, which is the control it self, and $e which are as usual the event arguments which differ from event to event.

However, i personally like to keep things simply. In WPF there is the concept of binding. so, i personally prefer to bind the value to a property and subscribe to the PropertyChange event of the bound property. this way, i don't case if the event is fired because of the control or the value of the property has been changed from any source. In order to illustrate how cascading combos works, i've created a sample some time ago on our blog: http://blog.coolorange.com/2014/02/14/picking-the-right-folder/

again, i personally suggest the approach from my blog. Create as many comboboxes as you need, bind the SelectedValue to a property and subscribe the PropertyChanged event. Within that even you can set the ItemsSource for the next level combo.
It's basically the same approach as yours, but just somewhat "cleaner" in terms of binding mechanics.

i hope this helps!

ciao
marco