Default value in Indicators dialog working?

[ETFVoyageur]

The [DefaultValue] attribute does not seem to be working for me. I can change the value in the Indicators dialog and it does not get bolded.

Is indicating user changes away from default values in the Indicators dialog working for everyone else? If not, could one of the NT folks please please ensure there is a bug report -- that would be definite usability regression from V7.

--EV

[NinjaTrader_Matthew]

Hi EV,

Thanks for posting - this has come up before so I have added your vote in SFT-569

Regarding the behavior difference between NT7 and NT8: We are using a new 3rd party property grid which does not support this behavior out of the box. We can definitely consider modifying the custom property grid to support this function in the future, and I can appreciate that doing so will be mutually beneficial for our developers/UI's as well as 3rd parties. But as it stands right now, we have larger issues we would like to address before we go back to fix items of this nature.

Just some background, we did not add this behavior in the initial spec for NT8 because we were not aware of this use case in NT7 until it was too late. In fact, it was not working correctly in all areas in NT7 and had some bugs as a result of our lack of experience with the property.

I've added your vote and we'll review this property when the time comes in the future.

[ETFVoyageur]

Thanks, Matthew.

FWIW: I do not see it as a problem for developers. I do see it as a nice usability feature for end users.

BTW: does the [DefaultValues ...] attribute do anything at all l in V8?

--EV

[NinjaTrader_Matthew]

Applying DefaultValues attribute does not do anything in NT8 at this time.

[ETFVoyageur]

BTW: if you are using a different property grid is there any good documentation on it?

What differences should we expect compared the the one you used in V7, or compared to the Microsoft documentation?

Thanks,
EV

[NinjaTrader_Matthew]

We do not have any documentation on this subject, but if you are looking for your own customization purposes, you can refer the projects repo: https://github.com/DenisVuyka/WPG/wiki

We have customized some behavior which I do not have a list handy which I can provide for expectations. If you plan on working on anything here, some of your efforts may require some trial and error.

[ETFVoyageur]

Thanks, Matthew. I'm not planning to customize the property grid -- I am just looking for any information I might want to know as a consumer of the grid.

--EV

[NinjaTrader_Matthew]

In that case, we only support what is documented here: http://ninjatrader.com/support/helpG...attributes.htm

Anything beyond these attributes is not supported and behavior is not guaranteed.

[ETFVoyageur]

The documentation you refer to says it is describing "some commonly-used attributes". I took that to mean the documentation is incomplete -- not surprising for a beta product.

One that is conspicuously absent from that documentation is [TypeConverter ...] I sure hope you are not telling me that V8 will not support type converter attributes! They worked fine for me in V7.

FWIW: my experience is that my type converter that is a subclass of ExpandableObjectConverter does work, but not all of my type converters do work -- I posted a bug report this morning about one that does not seem to be working for me. I have no idea what the difference is.

--EV

[NinjaTrader_Matthew]

No, I am not saying they will not work.

Our policy is we only provide support (i.e., we will help you if something isn't working/changes between releases) for what we have reviewed and guaranteed to work. End users can verify this by looking for it in documentation (we have documented considerably more in NT8 beta than we ever supported in NT7, and will continue to document and support more throughout its lifecycle).

The general policy is the same as NT7 was: you may use these undocumented types, but we do not guarantee their functionality and we reserve the right to introduce changes that may break their functionality between releases. Our support staff is also not necessarily equipped to help with these items, but we'll often to try and help out if that particular rep feels comfortable working on a subject.

With that said, you are free to use a type converter (we use them internally and in our own custom project), but we're not a stage where we're ready to fully support and documented those types, among others.

[koganam]

Thanks, Matthew. I'm not planning to customize the property grid -- I am just looking for any information I might want to know as a consumer of the grid.

--EV

Careful! Even in NT7, it was broken in some important places.

ref: http://ninjatrader.com/support/forum...ad.php?t=72230

[ETFVoyageur]

Koganam,

Thanks for the pointer. That discussion must have been frustrating for you -- I was frustrated with the initial responses even before seeing your reaction to them. I also noted the following from Matthew's final response:

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.

That sure sounds to me as if he expected default values to be included in NT8. Too bad they got overlooked. I hope they can be included in the next NT8 beta release.

I was also interested to see the idea of a settable default value come up, because I have a use case where default values must be set at runtime -- there is no way to set them at design time. This is not a client whim, it is logically necessary. Consider an expandable property -- that is a class, whose purpose is to contain other properties, and which will be used as a property itself. The expandable property does not, in general, have the information it needs to set the default values of the included properties until it gets instantiated with its own initial values. That means the default values for the included properties must be set at run time (not design time).

Just having the plain vanilla design time case work (even in Market Analyzer) would be a good start. I hope we can get that in the next NT8 beta release.

NT folks: now that this discussion has come up, please add to your list that default values need to also be settable at runtime. As I described above, sometimes there is no other way to set the default value correctly. It might be sufficient to have a way for the [DefaultValue ...] attribute, or some new attribute, to declare that the initial value is to be used as the default value. I'm not sure about that -- I have not thought it through. What I do know is that making the default value a static design-time setting is not, in general, adequate. My assertion is because of the program logic, not because of anyone's whim.

--EV

[ETFVoyageur]

I just ran across this interesting piece of code indicating that runtime setting of a property's default value may be possible in client code. I have not tested it out yet, but post it because it may interest others. (This example comes from Stack Overflow.)

[CategoryAttribute("Section Name"),
DescriptionAttribute("My property description")]
public string MyPropertyName
{
    get { return _MyPropertyName; }
    set { _MyPropertyName = value; }
}
private bool ShouldSerializeMyPropertyName()
{
    //RETURN:
    //      = true if the property value should be displayed in bold, or "treated as different from a default one"
    return !(_MyPropertyName == "Default value");
}
private void ResetMyPropertyName()
{
    //This method is called after a call to 'PropertyGrid.ResetSelectedProperty()' method on this property
    _MyPropertyName = "Default value";
}
private string _MyPropertyName;

--EV

[ETFVoyageur]

I would like to add a request for the default value attribute with no parameters to be interpreted to mean the initial value is the default value. This would simplify most cases, and more importantly it would enable setting a default value in some cases where it is not possible as is.

The current situation, where the initial value can be set at runtime, but the default value only at design time, just does not work in some cases. I believe this request would address the majority of such cases.

[ETFVoyageur]

Does SFT-569 include my request for a way to indicate that the initial value is the default value? If not, please add it to the request.

My suggestion was [DefaultValue] with no parameters.