CODEWITHSUNDEEP
wpfxamluser-controls
Jesse Hallam
Jesse Hallam

Reputation: 6964

Finding a better way to write complex WPF UIs

The WPF application I've inherited contains a significant amount of XAML which follows a pattern like:

<Window ...>
    <Grid>
        <z:SomeUserControl>
            <z:AnotherUc>
                <Label /> <Button /> <ComboBox />
            </z:AnotherUc>
            <z:AnotherUc>
                <Label /> <Button /> <ComboBox />
            </z:AnotherUc>
        </z:SomeUserControl>
    </Grid>
</Window>

In other words, we have UI sections grouped by UserControl, often nested inside other UserControls. At some point, the content is defined using basic WPF content controls.

The problem we're trying to cope with is that the x:Name attribute cannot be applied to any of the inner most controls due to the infamous WPF limitation:

Cannot set Name attribute value {0} on element {1}. {1} is under the scope of element {2}, which already had a name registered when it was defined in another scope

This presents a problem because the code-behind needs to be able to reference elements within the UserControls. UserControls were selected to group parts of the UI because all the styling and templating of default controls because too unwielding and the markup quickly turned in to a horrible, unreadable mess.

However, if Microsoft has no intention of resolving this so-called "limitation," a better way must be found. Considering has been placed in using CS + external XAML template file as seen in GaryGJohnson's work-around on the connect site. However this has a feeling of sphagetti and anything that interrupts bindings is a no-go.

Upvotes: 0

Views: 290

Answers (2)

user572559
user572559

Reputation:

Sounds like a mess by design. You can create your own AttachedProperty - MyNameProperty, set it in your XAML and write your own Logical/Visual tree helper, which'll work of it. I'm not saying I would do that, but if you need a quick workaround (w/out radical redesign of you UI composition model), that may do you.

Upvotes: 1

Reed Copsey
Reed Copsey

Reputation: 564333

The best option here is typically to avoid using code behind on those "inner" elements. You can still use data binding, so binding these to properties in your DataContext will work properly.

The other alternative, of course, is to expose the Label/Button/ComboBox directly as Dependency Properties of the AnotherUc class. This would allow you to usen them directly as members of the UserControl, which avoids the scoping issue.

The downside to this, of course, is that you must customize the user control for a specific combination of elements, instead of allowing any controls to be placed within it.

Upvotes: 1

Related Questions