Market Analyzer bug arising from DefaultValueAttribute?

[koganam]

I was trying to set up a scanner using the Market Analyzer, and I could not change any of the parameters of an indicator that I was adding.

A little sniffing around showed that the reason is that any Parameter that has the DefaultValueAttribute set becomes ReadOnly in the Market Analyzer. Setting a DefaultValue for a parameter is not supposed to make the parameter ReadOnly. Indeed if the indicator is added to a chart, the parameter remains read/write, thus making the point. I have not checked what happens in any other parts of NinjaTrader.

To restrict the setting of DefaultValues for parameters in this way just does not seem to make sense in any context, so I conclude that we must have a bug.

See the two pictures, that I have posted, that demonstrate the issue.

I have also posted 2 files, which differ ONLY in marking a DefaultValue for the Period parameter by using a DefaultValue attribute. The file names tell the story.

[NinjaTrader_Bertrand]

Thanks for the detailed report koganam, we will look into it.

[NinjaTrader_Bertrand]

koganam, playing with this a bit further I see your differences working with this property from a chart (not read only compared to MA), however changing the default value from the value entered in the private variable will not have any effect - so I would see limited value working with it on either the chart or MA windows. Our next major update will introduce a new way to very transparently create and work with script settings templates in general.

[koganam]

koganam, playing with this a bit further I see your differences working with this property from a chart (not read only compared to MA), however changing the default value from the value entered in the private variable will not have any effect - so I would see limited value working with it on either the chart or MA windows. Our next major update will introduce a new way to very transparently create and work with script settings templates in general.

Bertrand, of course it will not have any effect in this indicator. It was not intended to. The intent was simply to demonstrate that the the MA does not allow me to change the parameter. Sorry, but I was looking at the principle, not the minutiae.

As a developer, when I write/create a test case, I write the test case to test ONLY what is being tested, unvarnished by any other peripheral issues. That the parameter is not actually being used is irrelevant to its having been made incapable of being varied as and when needed. The files are called Demo... They are designed to demonstrate strange behavior from the MA, that prevents changing a parameter that must remain changeable, if it is to be used for meaningful analysis; they are not designed to demonstrate what happens if one changes a parameter.

Would you want me to post a set of indicators that actually use the parameter, so that you can see the deleterious effect of turning a parameter read only? Actually why not just change the OnBarUpdate() to something that uses the property (or its backing store field)? I can post new files, but it would bee faster if you just did that. Use SMA(Close, Period)[0] for example instead of the Close[0] that sets the Plot.

[NinjaTrader_Bertrand]

Thanks koganam, what we see documented via MSDN - https://msdn.microsoft.com/en-us/lib...(v=vs.90).aspx

is that this is really a property only meant to be for the Designer.

We tested in our next major update and here the value would not be read only for the MA as you had found for NT7, however we don't see any value in using it as it would have no effect on the actual value

'A DefaultValueAttribute will not cause a member to be automatically initialized with the attribute's value. You must set the initial value in your code.'

[koganam]

Hm. I do not even know how to respond without sounding rude. Either I have failed to explain what is happening, or we have NinjaTrader claiming to be infallible, digging in its heels, and refusing to acknowledge a defect.

For clarity, and maybe because the examples I gave were too abstract, let me try again. The attached file and picture again speak. The notes in the attached file shows clearly that the initial value (10) is different from the default value (13). Why they are different is irrelevant: that is what the client wants, and that is all that counts. The indicator shows how far price is away from the SMA: in this case SMA(10).

The indicator will when loaded, initially load with a value of 10, as specified in the assignment in the code. There was never an expectation that the indicator will load with the value from the DefaultValueAttribute, and I never stated such. Are you just talking down at me?

Regardless, now the client decides that instead of scanning for a price deviation from SMA(10), he wants instead to scan for deviation of Price from SMA(21), or SMA(13), or SMA(233) or any other value, and color a cell accordingly. I guess NinjaTrader has decided that that is a stupid idea, and so have decided that the value of 10 must not be changed. And the only reason is because we defined a DefaultValueAttribute? The picture shows what is shown in the Market Analyzer.

It just so happens that having a DefaultValue different from the initial value helps clarify the issue, even if it seems to make little sense not initializing to the default value in the code itself. The ONLY issue is why is the parameter made readonly just because a DefaultValue attribute has been applied, regardless of those values. Everything else is just dancing around the issue. My client wants to be able to change the values. Whether you think that makes sense or not is not really for you to say, though I wonder why we have a MarketAnalyser if we must be forced to use only initial values, and never change them to help in our analysis.

Now let me do a point to point riposte of your reply.

Thanks koganam, what we see documented via MSDN - https://msdn.microsoft.com/en-us/lib...(v=vs.90).aspx

is that this is really a property only meant to be for the Designer.

Huh? What am I, if not the designer? In any case, with all due respect, so what does that have to do with the matter?

I am a vendor, whose client has a requirement to set DefaultValue attributes on 36 parameters. I happen to know why, but that is irrelevant. The only thing relevant is that that is what the customer wants, and with 36 parameters, it makes sense that he wants to immediately see what is off the default value (which is one of the main purposes of setting the DefaultValueAttribute: to be able to see at a glance that which has been changed off default, as such will be bolded in the PropertyGrid).

Do you really want me to tell my client that NinjaTrader does not see the sense in what he is requesting, and therefore, will not even acknowledge that it is a defect? Is it really your purview to make the decision as to what makes sense to my client?

We tested in our next major update and here the value would not be read only for the MA as you had found for NT7,

Which fairly obviously means that the current implementation is defective. Until that new version comes out, it is vaporware, and while I wait for that to come up, my client has an immediate problem.

I am more than willing to lose this client if I cannot get this done, not the least reason being that I am pretty sure that any other vendor he goes to will have the same problem, as in my not so humble opinion, this is a NinjaTrader effect, and unless the vendor wants to poke around and override the NT internal implementation, this will be a non-starter for all.

...however we don't see any value in using it as it would have no effect on the actual value

I beg your pardon!!! You really cannot possibly mean that! There is no value in being able to change a parameter to an indicator, because changing the value of the parameter will not have any effect on the actual value? The actual value of what? The output Plot? Why the heck otherwise do we have parameters, other than to be able to change them as needed.

'A DefaultValueAttribute will not cause a member to be automatically initialized with the attribute's value. You must set the initial value in your code.'

I never said that it would, and the comment is irrelevant. The issue is not how the initial value is to be set. Whether the initial value is identical to the DefaultValue is appropos of nothing. The issue is that NinjaTrader prevents the change of that initial value. How else can I say it, so that NT support stops bringing up these red herrings?

[NinjaTrader_Bertrand]

koganam, thanks for the reply. With 'designer' we meant the VS designer interface accessing the property grid. I'll talk to development about this next week and be back in touch.

[koganam]

koganam, thanks for the reply. With 'designer' we meant the VS designer interface accessing the property grid. I'll talk to development about this next week and be back in touch.

May I have a response please?

[NinjaTrader_Brandon]

Hello koganam,

Thanks for your reply.

Unfortunately Bertrand has been out of office and it is unsure when he will return. I will review this and get back to you.

[NinjaTrader_Matthew]

Hi Kognanam,

Sorry for the late follow up here.

First of all, you have certainly identified a bug in the market analyzer implementation. Setting this attribute unexpectedly makes the property read-only. This was not by design. We acknowledge that, and the standard operation procedure for such cases in NT7 has been followed through.

For clarity, and to ensure there is no misinterpretation of disrespect: The behavior you seek is unrelated to the initial construction of the class variable, the behavior you seek is for the properties grid to visually notify you that the current user selected value differs from the "Default" value? I.e., where the usual behavior of this attribute would be to make it non-bold if that is the case?

My Value | 13 

vs

My Value | [b]15[/b]

You have made your case for why our implementation is wrong and we accept and agree that it makes no sense for the property to be read-only, but I guess the actual use case of setting the default value is still not fully understood. Apologize if there is some fundamental concept we're not familiar with here, but would like to get the full picture to A) provide a work around in NT7 and if not B) make sure this works in future releases.

While we know that this does not help you today, but regardless of the outcome, if this is a use case you wish to fulfill to satisfy a client's request, we will make it so in NT8. This is not something has come up before, and certainly cannot modify NT7 code base to resolve this bug in NT7.

Thanks.