>>>>>How does that differ from any other team?
>>>>>
>>>>>>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.
>>>>
>>>>Designer does not necessisarily mean programmer.
>>>
>>>In many cases, the designer is experienced with the controls and tools used and also knowledgeable of current design standards. He/she will likely design the appearance and behavior of base controls so they all look according to the overall desired design. He/she may not even do any actual development but work with skins or setting appearance behavior and standards for developer to follow. However, the developer will actually use the controls in the app. Other shops work differently.
>>
>>
>>You illustrated my point. This whole concept of putting some portions in XAML and some in C# adds a level of ambiguity that seem rather stupid and makes the code more prone to maintenance problems
>>
>>Now if the WPF was simply design tags realted to UI presentation, then I see a clear separation between UI and code. But from what I can see, WPF blends the two together. If someone could go in and change the XAML and that resulted in the app's look changing, and this didn't require a recompile, then I'd say cool.
>
>Say 'Cool'

Am I mistaken in that XAML is compiled in. There's no way to change the UI's look without a recompile? If so, that's just another code
file that has to be maintained - and it's in a different format. Just something else to learn.