default setting remain when properties hidden

[pbcah]

Hi Guys,

I'm currently removing attributes from the properties grid for a strategy where they were previously tune-able and I got in quite a spin trying to test using in code defaults that were not being recognised.

I eventually used my imagination and re-introduced the attribute visibility again and set default values to what I expected and re-ran the test and all worked correctly. I then used a conditional compile statement to effectively comment out the visibility of the attributes and re-ran the test and viola the test now succeeded as expected but with the properties no longer visible.

You're not updating the visible property list when you make changes to the strategy and seem to be simply using any defaults that are in the database to set non-visible properties. This is a very subtle bug and will be causing problems that are extremely hard to find (a bit like forgetting to declare canonical form base classes virtual in C++ which results in ending up with 2 instances of the base class but can only affect 1 of them).

Regards,

Paul

[zweistein]

Hello,

one of my recent posts was dealing with this, dirk replied and gave a solutiuon.

Strategy parameters should have the visible attribute otherwise they don't work as expected


regards

andreas

[pbcah]

Hello,

one of my recent posts was dealing with this, dirk replied and gave a solutiuon.

Strategy parameters should have the visible attribute otherwise they don't work as expected


regards

andreas

Hi Andreas,

Thanks for this. I think you were referring to "Strategy Properties persistence, attributes".

If this was the case, I think this was on a slightly different problem to the one I described. In my case, visual attributes appear to persist even after the visual attributes have been removed. Sure they are still public attributes and probably get serialised however should they be?

Regards,

Paul

[NinjaTrader_Bertrand]

Paul, I'm not 100% sure I follow you on your initial report, however would this post's info here help? http://www.ninjatrader.com/support/f...76&postcount=7

[zweistein]

you should copy the non-visible attributes inside your Clone() function of the strategy, because with all the Clone logic you never know which of the Cloned objects gets really into execution.

The default (NinjaTrader) implementation of Clone() does all this , but only for Visible properties.

That is what I deduced from Dierks hint and for me it works out...

andreas

p.s. Just have to read your first post better.
So it looks that you change the Visibility attribute (Browsable(true/false)) dynamically in your code. and you would like this attribute change to be propagated to all instantiated objects?

[pbcah]

Paul, I'm not 100% sure I follow you on your initial report, however would this post's info here help? http://www.ninjatrader.com/support/f...76&postcount=7

Bertrand, this is the issue.

private bool myProperty = false; // default setting

#if !ANONYMOUS
[Description("a property description")]
[Category(" A Category")]
[Gui.Design.DisplayName("A property")]
#endif
public bool MyProperty
{
get { return myProperty; }
set { myProperty= value; }
}

I'd like to protect our IP so I've created a compiler switch #define that removes the visibility of the properties with conditional compilation. I don't want to do this dynamically and will produce a different dll when shipping to third parties.

When I turn off ANONYMOUS, I use the property grid as normal to set values and I then use NT7s "Set Defaults" right click to save the values that then overwrite the values set in the code initializers.

After using the off version, I turn ANONYMOUS on then re-compile and expect that it should use the in code initializers however, the new classes continue to use the initializers saved with the "Set Defaults".

Regards,

Paul

[NinjaTrader_Bertrand]

Paul, thanks for clarifying, please recheck with a fresh indicator template, as it would just 'grab' the defaults you've set from there.

[pbcah]

Paul, thanks for clarifying, please recheck with a fresh indicator template, as it would just 'grab' the defaults you've set from there.

These are large and complex classes. Are you saying its necessary to create a new template when-ever I switch ANONYMOUS as we want to run it in both modes from time to time.

Does the object persistence mechanism only store the visible defaults or does it store all private attributes of the class, visible or not?

This issues has resulted in erratic behaviour when removing the visibility of properties in the grid when the NT7 "Set Defaults for ..." context menu is selected. As we are working in Beta, I recommend correcting this bug to prevent others falling into this trap with properties. The only way I could pre-set an attribute that had been set to default was to make it visible again set the property to what I required then make it invisible again.

Can you talk to your team again as this is a serious flaw in my view.

Paul

[roonius]

Bertrand, this is the issue.

private bool myProperty = false; // default setting

#if !ANONYMOUS
[Description("a property description")]
[Category(" A Category")]
[Gui.Design.DisplayName("A property")]
#endif
public bool MyProperty
{
get { return myProperty; }
set { myProperty= value; }
}

I'd like to protect our IP so I've created a compiler switch #define that removes the visibility of the properties with conditional compilation. I don't want to do this dynamically and will produce a different dll when shipping to third parties.

When I turn off ANONYMOUS, I use the property grid as normal to set values and I then use NT7s "Set Defaults" right click to save the values that then overwrite the values set in the code initializers.

After using the off version, I turn ANONYMOUS on then re-compile and expect that it should use the in code initializers however, the new classes continue to use the initializers saved with the "Set Defaults".

Regards,

Paul

if this is a strategy and not an indicator I suggest "hiding" entire property not only attributes

[zweistein]

Why don't you just look into the template or serialise your class yourself into an xml file? Then you see what is actually saved.

regards
andras

[pbcah]

Why don't you just look into the template or serialise your class yourself into an xml file? Then you see what is actually saved.

regards
andras

I could do that however why do I need to do anything as a strategy developer it should be handled correctly for me by the base class and this is a side affect of new behaviour added in NT7. It should be fixed so others don't fall into this trap. I don't particularly need to save these properties as defaults. This is a case of the framework getting in the way or normal development and its a new feature in NT7, it should work correctly.

We do have plans to eventually save our Strategy configuration as named xml templates as they vary per instrument and we need to save them separately. In our licensed release we need to set these defaults in code to protect our IP. We have an internal strategy configuration version and a licensed version and they share the same code with one having visible attributes and the other anonymous.

Regards,

Paul

[zweistein]

Paul,

currently I have time as I am sitting in the high speed train from Bologna to Milano and I have set my strategies for the day on my office computer using my NinjaTinyMobileTrader, so trading wise nothing much to do...

My hint to serialise was only meant for testing. By looking at was is actually serialised by your strategy you learn the internal logic of NT7. Once understood you write your code accordingly.

We know for properties: all is working correctly if they are visible and have a GridCategory() attribute. (Thus we call it a parameter).
This is the NT supported way to do.

You can vary the property attributes on your own, some attributes are, Browseable, GridCategory, Category, ...

just do a methodic variation of these and see how the serialise() output behaves, e.g. find out about persistence.
It would be nice if you could report this back here on the forum.

For the second aspect, parameter sets relative to the instument used (and saved in xml files) , I have done this in my StrategyPersistence implementation. In the end it is quite a complex code , especially considering that RELIABILITY is my PRIMARY concern, but I use it for more than 6 month now and it is absolutely bulletproof.


regards

Andreas
www.zweisteintrading.eu

P.S. Why not just use conditional compilation to replace your Property with some hard coded value? Just omit the property completely for the distribution ...

[NinjaTrader_Bertrand]

Paul, the template would store the private attributes as well - you could take a look for example into the created XML file in the MyDocuments\NinjaTrader 7\templates\Strategy folder.