About your 2nd observation I think that it can be solved using the following notation:

Private Sub Button1_Click(ByVal sender As Object, ByVal e As EventArgs) _
Handles Button1.Click, Button2.Click, MyControl.MyEvent

Just my two cents, regards!

Hey Rocky,

I don't really get you're claim that you can wire events without knowing the control name. I assume you mean a "reference" to the control, not it's actual "Name" property. There is a similarity between those due to the way designers work, but they aren't the same. If you don't have an object reference you can't hook into it's events.

If you are talking about looping through child controls or something similar, it's probably a lot cleaner to use a conatiner and let the events buble up to the container and decleratively handle the container's events.

Using AddHandler certainly is not less work. Handles is actually less as the designer will emit the correct code for you if you use the drop down combos. (note a build is needed in Orcas at present)
And the nice thing about Handles is if you set the WithEvents variable to Nothing all the events get **unwired**. Tryign to manage unwiring events when the code is added via AddHandler is a maintenance nightmare. It's even worse when that code is hidden in designer generated code al la C#.

Declerative code is beautiful : be it XAML or declerative event handlers :D

Rocky

I noticed a problem with Observation ichi.

The loaded events is like the Activate event in VB6. It fires every time the object is put in focus. I discovered this when clicking between tabs. I have same usercontrol that exists on different tabs in a tabcontrol. Each tab contains a different instance of the usercontrol. Everytime I switch between tabs the loaded event fires for the usercontrol instance, not only when the usercontrol is initially loaded. Not sure if its a bug or a feature. LOL.

Hey Rocky,

Ah, I can now see what you are talking about.. still don't agree, but at least I understand what you're saying <g>
There's 3 ways to wire up event handlers to the code behind (excluding data binding). All of them eventually use AddHandler. Those ways are :
(1) Wire up the event to a method yourself using AddHandler in one of the Window's Load or Init kind of events.
(2) Use Handles to declaratively mark a method as handling an event.
(3) Use implicit binding by typing the name of the method in the XAML for the Event you wish to wire up.

So it appears you are talking about (3) even though you never actually type AddHandler, and as said (1), (2) and (3) all use AddHandler at some part. ;)

As to coupling, the code behind file is meant to be coupled, and it is in all cases (1), (2) and (3).
(2) has advantages over (1) of being clearer as to what the code is handling and provides for simpler swapping of controls at runtime and unwiring. It makes code maintenance easier.
So form (1) and (2), I think (2) wins hands down. And it was (1) I thought you were referring to when you said AddHandler because it is the only one when you actually type AddHandler.

So, the discussion is now about (2) versus (3). I'd call (3) implicit wiring but it doesn't really decouple the UI from the code behind, in fact it intertwines the two. Let's say we have two people working on this team, one doing purely the XAML design using Blend, the other doing purely the code behind. Here we haven't separated the XAML from the code behind, we have separated design and coder roles ;) So using (3) the XAML designer crew member adds some buttons and says button1's click event will fire the Button1_Clicked method. Can that crew member compile the code ? No, they are reliant on the code behind developer to add the method stub. They have to check out the code behind file before they can proceed. The coder has to check it in before they can proceed. They are ground to a single person working at a time ONLY.
Later in the process consider what happens when the coder wants to refactor the method names, be it because of a conflict with another interface, or just to make it clearer as to the code intent. To do so, the coder has to check out the designer's XAML file, so the designer has to check that in and stop working on it. Again, ground to a single person working ONLY.

Now let's revisit this using (2) instead of (3). The designer can add controls at will and compile. They don't have to worry about what will trigger events or how. The coder can add the events based on the last checked in version... doesn't need the current one. If the designer changes/removes a control, they get a compile error and they can fix that by simply applying the same name to the new control. And the coder can refactor their work as much as they like. And on top of this the coder has clearer code because it declaratively marks what it handles.

Hi Rocky,

a few comments. Catching unhandled exceptions in WPF can be done at the dispatcher level for async calls (Dispatcher.UnhandledException event) but also at the AppDomain like every other .net application (AppDomain.UnhandledException). Have you encountered a case where these events don't get fired?

And about your previous WPF navigation post I just read (replying here as the commetns are closed on the other one), WPF always keeps the Page alive when you navigate using the Page object reference. It won't keep a Page alive when navigation is done by uri (either relative or pack syntax).

As for the values still being in the controls, all the journalled properties will get restored when navigating by object reference, and should have been restored by navigating by URL. Note that in the latter case, the value will get restored but you will loose the binding as wpf doesn't restore it properly. This will be fixed in SP1 and is fixed in 3.5 beta 2.

Hope it helps,

SerialSeb