>>>>>>>>>Is it just me, or is WPF REALLY difficult to learn?? I picked up a book and got a few chapters into it and walked away thinking "WTF????".
>>>>>>>>
>>>>>>>>That was my take on it.
>>>>>>>>
>>>>>>>>I got a couple of chapters into the book hoping for something that would allow me to do visual development, and all I saw was grinding code in XML, mostly a little different thant anything else so you get to start over learning it.
>>>>>>>
>>>>>>>I posted on this a few weeks again, but you can define event names in the XML file. So you can define a button, and the name of the
>>>>>>>event in C# that is raised when the button is clicked.
>>>>>>>
>>>>>>>Now my (limited) understanding is that WPF is structured so that a designer can do the WPF and the coders write the C#. So that means a desinger could break your code by changing the name of an event.
>>>>>>
>>>>>>No. They can write XAML that doesn't work - but the *can't* break code. I'm working at the moment on C# code with two other guys playing with the look and feel of the front end. They can't break anything as long as they don't touch the C# files.
>>>>>
>>>>>If I define an method called OkButton_Click and attach it to the Ok button, and it's defined that way in the XAML file, then some designer who know zip about programming comes along and changes that name - he/she just broke the code. It won't compile.
>>>>
>>>>Firstly, for that scenario, I would use a Command rather than an event handler. But let's break it down a bit:
>>>>The C# guy defines the OKButton_Click handler.
>>>>The XAML guy that needs to use the method can wire up the Click event in the XAML. If he tries to wire up to a non-existent handler then of course it fails. What other behaviour would you expect or want?
>>>>
>>>>Maybe the problem here is that we are using the term 'broken code' in different ways. I wouldn't regard the above example as 'breaking code' - it's simply writing XAML that won't work.
>>>>
>>>>Best,
>>>>Viv
>>>
>>>
>>>Look at it from the other direction.
>>>
>>>C# Programmer develops an app with a button's Click event wired. The XAML is pointed to this event. Later the designer decides to rename the event in the XAML file. Code is most assuredly broken.
>>
>>Firstly the C# guy shouldn't be the one providing the button (that's a XAML job) only the event. It's up to the XAML to wire up to the event. C# shouldn't worry about how or where the event is raised. If the XAML chooses not to raise the event that's up to them.
>>IAC you can't change an event in XAML....
>
>

><TextPanel xmlns="http://schemas.microsoft.com/2003/xaml" 
>           xmlns:def="Definition" def:Language="C#" 
>        HorizontalAlignment="Center" 
>        Background="Yellow"> 
>    <Button Click="ButtonClick" FontSize="68"> 
>        Click Here 
>    </Button> 
>    <def:Code> 
>        <![CDATA[ 
>            void ButtonClick(object el, ClickEventArgs args) 
>            { 
>                MessageBox.Show("The button was clicked."); 
>            } 
>        ]]> 
>    </def:Code> 
></TextPanel> 
>

Hey that's cheating :-}
But seriously, my point still stands. There's nothing there that breaks my C# code. If the XAML tries to hijack a C# event handler by using the same name it won't compile. If they want to define another handler in XAML for an event that's up to them. In fact it can be a valid strategy - for example updating the appearance of other UI elements etc.
BTW what's a TextPanel ?