Please make AddOn be a DependencyObject, not just a plain Object

[ETFVoyageur]

The problem with being a plain Object is that means AddOns cannot have dependency properties. I need the callback for property change that dependency properties have. Given AddOn as is I'll just have to implement a private custom callback system. It would be so much easier if AddOn was a DependencyObject so I could have dependency properties and use their existing callback mechanism. That would be the WPF way to handle the issue.

--EV

[ETFVoyageur]

Perhaps make AddOn be a DependencyObject, not just a plain Object?

To be clear -- this is a product question / suggestion, not a personal request. I already have my code working using C# events instead of dependency properties.

It still seems to me, though, that AddOn might want to be a DependencyObject instead of a plain Object.

• Fundamental type in WPF, and NT is a WPF app
• Enables AddOns to do things that they cannot do as is

--EV

[NinjaTrader_Brett]

Thanks for feedback. Since Add On's can be anything we do not want to force it to be a dependency object else we would be removing part of the use case of add ons.

[ETFVoyageur]

Thanks for feedback. Since Add On's can be anything we do not want to force it to be a dependency object else we would be removing part of the use case of add ons.

I do not understand. What would you be removing? As a DependencyObject it would still be an Object. It seems to me that your current way is what is limiting AddOn users.

--EV

[NinjaTrader_Brett]

Object is the base class of all .net objects and as such is the least limiting option technically. You can always build upon Object and create your own Dependency object, thus the power of how its implemented.

[ETFVoyageur]

Object is the base class of all .net objects and as such is the least limiting option technically. You can always build upon Object and create your own Dependency object, thus the power of how its implemented.

Huh?

Any subclass of Object, such as DependencyObject IS an Object, can be used wherever an Object is needed, and can do everything an Object can do -- and more besides.

I have no idea what you have in mind when you say "You can always build upon Object and create your own Dependency object".

--EV

[NinjaTrader_Brett]

public MyAddOn : AddOnBase
{
public MyDependencyObject MyCoolDepencyObject;
}

public MyDependencyObject : DependencyObject
{
...
}


Add On is not necessarily a UI object therefor it does not make sense to force it into that role, which is what you do when inheriting from DependencyObject.