The strangest compile error.

[koganam]

Please look at the picture first. NT is complaining that is cannot test for equality between types of the exact same definition. This is happening in the NT Magic Code section, no less. And NO, I have not touched that section of code; I simply clicked on the error to highlight the location. The definition happens to be a struct. However, if I change that very definition to a class, NT has no problem. (Which, of course, shows that I did not touch the MagicCode).

I have attached 2 files to demonstrate the issue. Look at line 13 of the files, and you will see that the ONLY change is declaring TestStruct as a class in the file that compiles and as a struct in the one that does not. Naturally, you cannot have both files in the compilation tree at the same time, as in accordance with NT support instructions, both the class and the struct have been declared in the global namespace. (I needed to demonstrate that the ONLY change was the substitution of class for struct, which is why I did not change the name of the object from TestStruct). IOW, to demonstrate the problem, you need only one file. Just edit it, changing line 13 to read struct instead of class and try to compile. That should show the problem.

I have isolated the problem to what seems improbable: the problem only occurs if we try to expose the properties of the struct in ANY GridCategory. Rem out the GridCategory attribute, and the problem disappears. That is not an acceptable solution. I want the struct exposed for user input via code if required, so it cannot go into the default "Misc" category for unassigned properties.

[NinjaTrader_Bertrand]

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

[NinjaTrader_Bertrand]

koganam, I could reproduce this here and check into with my developers but we could unfortunately not support this use of structs in the properties. I will though forward it to product management as an enhancement suggestion.

Thanks again for taking the time to look into this and post a detailed report here.

[koganam]

koganam, I could reproduce this here and check into with my developers but we could unfortunately not support this use of structs in the properties. I will though forward it to product management as an enhancement suggestion.

Thanks again for taking the time to look into this and post a detailed report here.

Bertrand, I have to disagree with your statement here. This is not a matter of support: it is a bug. Here is why.

1. NinjaScript is claiming to be unable to compare 2 objects of the same type, but has no problem comparing other structs, or even class objects as all the primitives in .NET, int, double, bool, float, long, the whole nine yards, are all declared as structs, (ref: http://msdn.microsoft.com/en-us/library/s1ax56ch.aspx) and all the NT indicators are class objects.
2. It is not a problem with value types, as enums are properly handled.
3. Both class and struct are objects composed of other primitives and entities, and there is no problem with a class. Of course, that follows, as NT indicators are class objects. In fact, as most of the literature suggests, the differences between a class and a struct are not very great, and many times, it is recommended to use a struct instead of a class if the data set is not large.
   
   From the Microsoft site: "In general, classes are used to model more complex behavior, or data that is intended to be modified after a class object is created. Structs are best suited for small data structures that contain primarily data that is not intended to be modified after the struct is created."
   
   ref: http://msdn.microsoft.com/en-us/library/ms173109.aspx
   
   
4. If we prevent NT from iterating through the parameter, as by not placing it in a GridCategory, there is no problem.

Believe me, I do understand the support burden any product brings, and for a framework as elaborate as NT, it can be large, even daunting, but Attributes are a key part of .NET, and dare I say of the NT user interface experience.

In this case, the more or less blanket statement, which says in effect that "if NT cannot handle it, then we cannot support its use" (I did not ask for support in using it; I am using it in the standard .NET fashion), sounds like sweeping a bug under a rug in order to not deal with it.

[NinjaTrader_Bertrand]

koganam, thanks for the reply - to clarify our reasoning and approach better: structs are supported in the general C# programming structure in our NinjaScript editor (as you noted as well), however they would not be in the GridCategory / properties section as it would unfortunately be not compatible to the NS wrappers employed. This is a current limitation here and I have already asked product management to track your find as enhancement suggestion for NinjaTrader, this is now done under # 1283.

Thanks again,

[koganam]

koganam, thanks for the reply - to clarify our reasoning and approach better: structs are supported in the general C# programming structure in our NinjaScript editor (as you noted as well), however they would not be in the GridCategory / properties section as it would unfortunately be not compatible to the NS wrappers employed. This is a current limitation here and I have already asked product management to track your find as enhancement suggestion for NinjaTrader, this is now done under # 1283.

Thanks again,

Fair enough. I guess it is just different points of view. I call it a bug in the NS wrapper; you call it a limitation.

Thanks for pushing it up the chain though. Very proactive.

Now I just have to figure how to code around that. Actually the behavior of the NS wrapper has told me what I need to do.