views:

29

answers:

2

Hi,

VS has thrown a useless exception which I think is caused by the fact I have multiple DP's in two similar classes with the same name.

the classes are add/edit contact so they share a number of properties, my problem is this.

I can register a property as:

DependancyProperty.Register( /*...*/ );

or:

MyDP.AddOwner( /*...*/ )

problem being that I have no way of knowing whether the add or edit class will be instantiated first (depends on user choice), since they're defined as static, I can't put anything fancy in their initialisation logic... I'm out of ideas that can be self contained within the 2 classes.

So how do I set up the dependancy properties in this scenario?

Edit:

Type Initialization Exception: The type initializer for 'CharterHouseTouchScreenDemo.Views.Membership.AddMembershipView' threw an exception.

I know that it's one of the dependancy property initialisers because when stepping through it doesn't even get to the constructor.

also, in this case, they don't share enough similarities to be the same class. in a nutshell, the only thing they share is the information stored in this dependency property.

Edit 2

I'm suprised this isn't better documented, in any medium-large scale applications the chances of accidentally naming a dependancy property the same thing are pretty large. Especially for generic things like "BackgroundColour" or "HeadingText" "CurrentXYZ"...

I always assumed you passed the type of the owner class so that it wouldn't cause issues like this.

A: 

First, sorry this isn't being posted as a comment. I don' tyet have the reputation to leave comments.

With classes named things like "AddContact and EditContact" it seems to me you are building these classes to edit what is probably a Contact class?

You may be going about your solution completely wrong and causing yourself a much bigger headache.

Can you give more details on the code? If, for example, you have a GUI that displays contact information and you wish to edit it, there are much better solutions than having Add/Edit classes. The depencey properties should be a part of your contact class rather than their own separate edit class.

Perhaps you may wish to read up on Model View View-Model and the WPF command framework

Spending a half hour reading up on these two topics may lead you to a much more elegant solution that is less of a hastle for you.

brandon
Contacts are stored in a database which is accessed through a web-service, which is built o the principles of a design pattern (which for the life of me I can't remember the name of)anyway.. it's accessed by filling in command classes which are sent to the service, the UpdateContactCommand and CreateContactCommand are programmatically entirely isolated, while they share the same property names. Hence separating create and edit Contact classes (p.s. there are advantages to the service, just not really coming across here...)
Dead.Rabit
A: 

Not really a kosher answer, but it works:

#region SubscriptionFee

/// <summary>
/// SubscriptionFee Dependency Property
/// </summary>
public static readonly DependencyProperty SubscriptionFeeProperty =
    DependencyProperty.Register( "SubscriptionFee_2", typeof( decimal ), typeof( EditMembershipViewModel ),
        new FrameworkPropertyMetadata( (decimal)0 ) );

/// <summary>
/// Gets or sets the SubscriptionFee property. This dependency property
/// indicates the new subscription fee for the customer.
/// </summary>
public decimal SubscriptionFee
{
    get { return (decimal)GetValue( SubscriptionFeeProperty ); }
    set { SetValue( SubscriptionFeeProperty, value ); }
}

#endregion SubscriptionFee
Dead.Rabit