[Range] attribute on a property is not user-friendly

[ETFVoyageur]

The attribute does work -- it clamps the value as specified. The problem is that it gives no feedback when it does so. If you have the Indicators dialog up and configure an out-of-range value:

• If you move on to something else on the dialog, it silently replaces your input with the min or max value, as appropriate. There is no warning to the user, but at least there is the chance the user will notice the discrepancy.
• The much worse problem is when the user enters an out-of-bounds value and then clicks on "OK". The value is clamped and the dialog disappears. The user has no possible way to see that the value he entered is not the one the program will be using.

Please ... at least beep when clamping a value. If the action is triggered by the user clicking the "OK" button, then a confirmation dialog ought to also be put up so the user knows what is going on and has a chance to cancel the "OK" and fix the problem.

-EV

[NJA_MC]

Just as we are talking about the [Range] attribute, this is very unfriendly if a host script calls the indicator with values out of range. I think it throws an exception or something. haven't tried it recently, but just stopped using that attribute for scripts that will be hosted.

[koganam]

Just as we are talking about the [Range] attribute, this is very unfriendly if a host script calls the indicator with values out of range. I think it throws an exception or something. haven't tried it recently, but just stopped using that attribute for scripts that will be hosted.

When I need to clamp Property values, I use explicit properties. I think that they are more useful in that context.

[ETFVoyageur]

When I need to clamp Property values, I use explicit properties. I think that they are more useful in that context.

I think they are more useful most of the time, because of default value setting. In most cases you can do so at compile time, which I consider preferable. Also, if you place the backing variable next to the property, you have all of the information there in one place.

Clamping with an explicit property shares a problem with the [Range] attribute, though. Either way the user clicks OK and gets no notification that he got clamped. That is bad GUI. We need some way to clamp such that a user has to confirm the OK should go ahead with the clamped value.

--EV

[koganam]

...
Clamping with an explicit property shares a problem with the [Range] attribute, though. Either way the user clicks OK and gets no notification that he got clamped. That is bad GUI. We need some way to clamp such that a user has to confirm the OK should go ahead with the clamped value.

--EV

We, you and I, did this one last year. Have you tried using the [RefreshProperties(RefreshProperties.All)] attribute?

ref: http://ninjatrader.com/support/forum...56&postcount=7

[NinjaTrader_PatrickH]

Hello ETFVoyageur,

Thank you for your suggestion.

I have forwarded this to our development team.

[NinjaTrader_PatrickH]

We are tracking this request for the sound and/or message of parameters outside the valid range under SFT-610.