Controlling indicator configuration GUI

[ETFVoyageur]

I have several indicators that I think of as part of the same family. Some of them need the same kind of configuration for certain aspects. Configuration aspects that are the same for two indicators should have the same GUI -- the same labels, the same descriptions, the same parameter section, etc. For example, those indicators that have a center band may all need top level, bottom level, whether to shade the center band, shading color, shading transparency, whether to display a zero line, whether to display band edges, etc.

My question is how I get multiple indicators to all present the same GUI for configuring their center bands. I could, of course, just enter the same text in all relevant indicators, but that is so 1950's, with all the known problems of retaining consistency as bugs are fixed and the feature is evolved. There must be a good way to handle this, but I am having difficulty thinking of what it could be.

Note that this is a source-level question. I want to provide several indicators that will all present the identical GUI for configuring their center bands (for example). What is Best Practices for doing that?

--EV

[koganam]

I have several indicators that I think of as part of the same family. Some of them need the same kind of configuration for certain aspects. Configuration aspects that are the same for two indicators should have the same GUI -- the same labels, the same descriptions, the same parameter section, etc. For example, those indicators that have a center band may all need top level, bottom level, whether to shade the center band, shading color, shading transparency, whether to display a zero line, whether to display band edges, etc.

My question is how I get multiple indicators to all present the same GUI for configuring their center bands. I could, of course, just enter the same text in all relevant indicators, but that is so 1950's, with all the known problems of retaining consistency as bugs are fixed and the feature is evolved. There must be a good way to handle this, but I am having difficulty thinking of what it could be.

Note that this is a source-level question. I want to provide several indicators that will all present the identical GUI for configuring their center bands (for example). What is Best Practices for doing that?

--EV

You did not like my suggestion to use separate development environment with properties defined in a suitable partial class?

ref: http://www.ninjatrader.com/support/f...162#post362162 to your original question which seems to be the same as this one.

[ETFVoyageur]

As far as I can see, a separate environment is both a big hassle and not flexible enough, so I was not sure that my question had been clear.

Suppose there were 5 groups of parameters, with various indicators needing various sets of parameters, but no indicator needing all of them. I'd like the effect of something like one indicator being able to do:
#include <parameter group #1>
#include <parameter group #3>
#include <parameter group #4>

It looks as if multiple inheritance would also solve the problem -- but that, too, is C++, not C#.

The code supporting them is no problem. The variables are not even a problem. The problem is getting the properties defined for precisely those indicators that need them. It seems to me to be a source-level problem that I know how to handle in C++, but not in C#

--EV

[NinjaTrader_JC]

Hello EV,

Just for clarification, you are looking at having multiple indicators like the SMA and EMA having some of the same parameters if I am understanding your correctly?

If so, we do not really have best practices on this but you may try a few options to see what would suit you best. First one, would be to have a single file for this family of Indicators uses that has a list of all of the settings so that when you use one it will read this file in so that all of the settings are the some.

Another option would be to combined all of the indicators in the same family into one Indicator so that they are all the same. This may require a switch or a toggle for each one if one is wanted but another is not.

[ETFVoyageur]

Hello EV,

Just for clarification, you are looking at having multiple indicators like the SMA and EMA having some of the same parameters if I am understanding your correctly?

If so, we do not really have best practices on this but you may try a few options to see what would suit you best. First one, would be to have a single file for this family of Indicators uses that has a list of all of the settings so that when you use one it will read this file in so that all of the settings are the some.

Another option would be to combined all of the indicators in the same family into one Indicator so that they are all the same. This may require a switch or a toggle for each one if one is wanted but another is not.

My question is about custom indicators I write. (If I care about built-in ones like SMA and EMA I can always wrap them.) I want my indicators, the ones that I write, to have a common GUI for those parameters that they have in common. I do not want any indicator to display any irrelevant parameters.

Your first suggestion mentions "reading a file in". Are you suggesting that I can set up the parameter properties at run time? If so, that might be do-able. Not as nice as compile-time, but do-able. Just what did you have in mind?

I do not understand your second suggestion "require a switch or a toggle for each one if one is wanted but another is not". What do you have in mind?

Question: can my indicator get at the XML information and then manipulate it to set attributes such as XmlIgnore and Browsable? If that works, I could have a common base class with all of the variables disabled, and then each final class would just enable those it wanted. If that works, how do I do it? Where would be the best place to do that manipulation -- constructor? Initialize()? OnStartUp()? I'd really prefer a build-time solution, but run-time is acceptable.

--EV

[ETFVoyageur]

To restate my question as a Basic Principle:

It is well-established that when two pieces of code have something in common it is best to have only one source for the common part. I do not know how to do that for sets of parameter properties. I am asking for best practices in addressing that problem.

--EV

[NinjaTrader_CalH]

Hello EV,

I have attached a sample reference that will help guide you on the right path for this request.

[koganam]

To restate my question as a Basic Principle:

It is well-established that when two pieces of code have something in common it is best to have only one source for the common part. I do not know how to do that for sets of parameter properties. I am asking for best practices in addressing that problem.

--EV

Why not then create a base empty indicator with the required properties, and let the others be derived from it?

[ETFVoyageur]

Why not then create a base empty indicator with the required properties, and let the others be derived from it?

Because of the mix-and-match. That works for a fixed set of properties, but not (AFAIK) for choosing m of n properties. If there is some way to define all of them in the base class, and then let each subclass turn off those it does not want, that would work. Is there a way to do that?

--EV

[ETFVoyageur]

Hello EV,

I have attached a sample reference that will help guide you on the right path for this request.

Thanks for the sample code. What I am missing when I look at it is how the derived class controls which of the base class properties are live. Without that ability, all derived indicators will show all of the base class properties, which is not what I need.

--EV

[koganam]

Because of the mix-and-match. That works for a fixed set of properties, but not (AFAIK) for choosing m of n properties. If there is some way to define all of them in the base class, and then let each subclass turn off those it does not want, that would work. Is there a way to do that?

--EV

Sounds like what you want then is to have all the Properties defined but hidden, then expose them as necessary. I can give you the concept of how I would go about it, but I have not yet written any example code.

1. Define all the properties and their datastores in a partial class, or base class if you prefer.
2. Explicitly mark all the properties with the Browsable attribute: in this case, false. (Very important, or all Properties, in all NT indicators that are not explicitly marked will behave in an unpredictable manner ).
3. Write a method that uses the PropertyDescriptor to get a TypeDescriptor; query it for the Browsable attribute, and change the necessary field to true for the Properties that you want to show.
4. Call the method as necessary, to expose those Properties in the indicator where you want them exposed. It should work either in Initialize() or in OnStartUp(), I should think. One could even use a hidden dummy parameter to manipulate the attributes by calling the method in its setter.

[ETFVoyageur]

Thanks for the suggestion. That is the sort of thing I am thinking about. I have run across similar suggestions when Googling around. It's on my list, but I have not gotten to trying it just yet. Busy off on another track for the short term.

If anyone has some example code, that would be much appreciated. If not, I'll get to it one of these days on my own.

One of the things I have been unsure of is whether an indicator can run its code in time to matter. I'm hoping that somewhere between constructor, Initialize() and OnStartUp() will work, but I don't really have NT timing locked down enough yet to be sure. As I understand it:

• OnStartUp() is after the user has set values in the configuration dialog, and so is too late
• Initialize() is before that -- but I do not know how locked down the configuration dialog is by that point
• Constructor -- I presume would work if Initialize() turns out to be too late. After all, getting the XML stuff in final form sounds like construction to me.

--EV

[ETFVoyageur]

OK -- I looked further into it, and here is something that is working for me. I have verified it works with charts and with market analyzer.

In the base class add the attributes (with Browsable=false) and the following method. (I presume I'll want something more general, and I'll do that as needed.)

        protected void setBrowsable(string strPropertyName, bool bIsBrowsable)
        {
            // Get the Descriptor's Properties
            PropertyDescriptor theDescriptor = TypeDescriptor.GetProperties(this.GetType())[strPropertyName];

            // Get the Descriptor's "Browsable" Attribute
            BrowsableAttribute theDescriptorBrowsableAttribute = (BrowsableAttribute)theDescriptor.Attributes[typeof(BrowsableAttribute)];
            FieldInfo isBrowsable = theDescriptorBrowsableAttribute.GetType().GetField("Browsable", BindingFlags.IgnoreCase | BindingFlags.NonPublic | BindingFlags.Instance);

            // Set the Descriptor's "Browsable" Attribute
            isBrowsable.SetValue(theDescriptorBrowsableAttribute, bIsBrowsable);
        }

Then, in the subclass' Initialize() add lines like the following, as needed:

            setBrowsable("BullColor", true);
            setBrowsable("BearColor", true);

That allows Initialize() to enable and disable display in the indicator dialog. It is true that all subclass indicators will have the property implemented (in the base class) whether or not it is displayed. The hit seems minimal, though, and this does achieve the objective of showing the user only those properties any given indicator uses.

I could see adding other things, such as a similar capability for tailoring the description and display name values for the specific indicator subclass.

--EV

[koganam]

OK -- I looked further into it, and here is something that is working for me. I have verified it works with charts and with market analyzer.

In the base class add the attributes (with Browsable=false) and the following method. (I presume I'll want something more general, and I'll do that as needed.)

        protected void setBrowsable(string strPropertyName, bool bIsBrowsable)
        {
            // Get the Descriptor's Properties
            PropertyDescriptor theDescriptor = TypeDescriptor.GetProperties(this.GetType())[strPropertyName];

            // Get the Descriptor's "Browsable" Attribute
            BrowsableAttribute theDescriptorBrowsableAttribute = (BrowsableAttribute)theDescriptor.Attributes[typeof(BrowsableAttribute)];
            FieldInfo isBrowsable = theDescriptorBrowsableAttribute.GetType().GetField("Browsable", BindingFlags.IgnoreCase | BindingFlags.NonPublic | BindingFlags.Instance);

            // Set the Descriptor's "Browsable" Attribute
            isBrowsable.SetValue(theDescriptorBrowsableAttribute, bIsBrowsable);
        }

Then, in the subclass' Initialize() add lines like the following, as needed:

            setBrowsable("BullColor", true);
            setBrowsable("BearColor", true);

That allows Initialize() to enable and disable display in the indicator dialog. It is true that all subclass indicators will have the property implemented (in the base class) whether or not it is displayed. The hit seems minimal, though, and this does achieve the objective of showing the user only those properties any given indicator uses.

I could see adding other things, such as a similar capability for tailoring the description and display name values for the specific indicator subclass.

--EV

Intersting. We ended up with the same implementation from what I described. Even a part of my method signature is the exact same. I called mine: ShowProperty(string strPropertyToShow, bool boolShowProperty)

Very nice.

[ETFVoyageur]

There turns out to be a problem with what I posted. It works fine for a single subclass. However, there is a problem when I have two indicators subclassed from the same base class and both in the same chart. Either one's Initialize() method works -- but the last one wins and sets the value for both. The code does not allow one indicator to have the attribute live and the other have it hidden.

I hope there is just some simple thing I am overlooking, since I have not dealt with reflection previously.

--EV