User defined parameter type gives error when using "save as"

[ds1111]

I'm creating an indicator with many multiple choices under properties using several user defined parameter types enum according to the 'sampleuniversalmovingaverage' example ( http://www.ninjatrader.com/support/f...ead.php?t=3420 )

The challenge I have is that as I'm improving the indicator and developing new versions, I need to go to each one of those and rename, otherwise I get an error similar to this if you save the example with another name: "The namespace '<global namespace>' already contains a definition for 'UniversalMovingAverage'".

Anybody has a suggestion on how to define these enum groups so I wouldn't have to go through this everytime I create a new version of my indicator?

I guess this may be more of a C# question for the C# gurus out there...

Thanks for any help!

[NinjaTrader_Bertrand]

ds1111, I'll leave this open for other community members to respond with their experiences, but we can only support enums in the scope as outlined in the reference sample, with this practice a unique enum per script would be needed.

[sh_daggett]

I'm creating an indicator with many multiple choices under properties using several user defined parameter types enum according to the 'sampleuniversalmovingaverage' example ( http://www.ninjatrader.com/support/f...ead.php?t=3420 )

The challenge I have is that as I'm improving the indicator and developing new versions, I need to go to each one of those and rename, otherwise I get an error similar to this if you save the example with another name: "The namespace '<global namespace>' already contains a definition for 'UniversalMovingAverage'".

Anybody has a suggestion on how to define these enum groups so I wouldn't have to go through this everytime I create a new version of my indicator?

I guess this may be more of a C# question for the C# gurus out there...

Thanks for any help!

I haven't tried this, but if your enum values don't change, maybe you could put the enum definition in the UserDefinedMethods.cs indicator file, editable from the indicator editor. This way, they are defined only in one place. You can do a move and rename to your final version once you get the kinks out of your logic. If your enum values are changing from version to version, then this idea won't work so well.

HTH.

[sh_daggett]

User defined parameter type gives error when using &quot;save as&quot;

Hello ds1111,

I couldn't get your question off my mind, so I played with it a bit and tested four approaches to solving the problem. All four worked, but one worked the best. You can have your cake and eat it too. That's the good news. I'll leave it to NinjaTrader Support to let us know if there is any bad news. I haven't found any yet.

Basically, all you have to do is put the enum definition in the scope of the class itself and then, when defining the property in the properties section, make sure you fully qualify the enum type with the full namespace and classname. This way, when you do a save as, the enum is in a new scope, and you won't get the same errors you did before. Interestingly, when I tried this, NinjaTrader automatically reset the fully qualified property type for me. Wonderful! (This still allows the user to make a selection in the Indicators properties dialog, too.)

I've attached a PDF file that describes the full test. Also, the zip file contains all four tests, but you need to read the installation instructions at the end of the PDF to be able to install it properly.

Thanks for the interesting challenge. Unless Ninja Support identifies a problem with this approach, I am going to make it standard practice.

sh_daggett

[ds1111]

wow... this is great... love it.. thanks a lot. This solution should be rolled into the example I think.

Another question if you don't mind, if I use this solution (#4), when I export my indicator will userdefinedmethods.cs be included in the 'exported' zip file of my indicator? The reason I'm asking is because I'm distributing this indy to some friends, I wouldn't want them have to mess up with the userdefinedmethods.cs. I can test that, but if you know from the top of your head would be great, so I can go ahead and implement on my indy.

Thanks again! Really appreciate.

[sh_daggett]

Approach #4 doesn't use the UserDefinedMethods.cs file. It puts the enum in the scope of the indicator class itself, so your indicator does not need to rely on any outside files. When you export, it will not include the UserDefinedMethods.cs file. That's one thing I like about this approach.

I have a hunch that the good folks at NinjaTrader do not allow you to export that file for fear that it could mess with the custom work of our dear friends and customers. Just a guess, but I believe it's on purpose.

Happy coding!

sh_daggett

[NinjaTrader_Bertrand]

Thanks for the creative sharing here guys - correct UserDefinedMethods could not be exported, as it could easily corrupt working installs then.

For the enums we've tested several concepts and can unfortunately only support and recommend the practice shared in our reference sample. This would also work as expected when scripts are protected / exported as assembly, so generally our official guideline.

[sh_daggett]

Thanks for that important info, Ninja Bertrand!

So, ds1111, you could use approach #4 while doing your development, then, when you're ready to create a protected assembly for distribution, move the enum definition to the default C# namespace (end of the given namespace), unqualify the property's type, recomplie, export and ship.

At least this way, you would get your errors out of the way while you're working, and could still have a supported method in your shipping code. (You just have to remember to do this, and always test the file you actually ship!)

HTH

sh_daggett

[ds1111]

cool.. thanks a lot once more!

[koganam]

Thanks for that important info, Ninja Bertrand!

So, ds1111, you could use approach #4 while doing your development, then, when you're ready to create a protected assembly for distribution, move the enum definition to the default C# namespace (end of the given namespace), unqualify the property's type, recomplie, export and ship.

At least this way, you would get your errors out of the way while you're working, and could still have a supported method in your shipping code. (You just have to remember to do this, and always test the file you actually ship!)

HTH

sh_daggett

You have run into the problem that comes from polluting the global namespace all willy-nilly; a fault for which one of my professors automatically took a perpetrator down one full grade point. It is part of Programming 101. There have been quite a few threads on the issue. here are some for your edification.

http://www.ninjatrader.com/support/forum/showthread.php?t=37521&highlight=pollute+global+namespace

http://www.ninjatrader.com/support/forum/showthread.php?t=37662&highlight=pollute+global+namespace

http://www.ninjatrader.com/support/forum/showthread.php?t=43938&highlight=pollute+global+namespace

If you want to see a few more, you can search on the words, global, namespace and pollute together.

[Radical]

koganam: I'm a newbie, so forgive the simple question, but by 'global namespace', do you mean possibility #1, or possibility #2 in my example below? I'm guessing #1? I followed your links but I'm still not completely sure.

Edit: I added a possibility #3!

using things;

//possibility #3

namespace NinjaTrader.Indicator
{
    //possibility #1
    public class SMA : Indicator
    {
        //possibility #2
        protected override void Initialize()
        {
        }
        protected override void OnBarUpdate()
        {
        }
    }
}

[ds1111]

Koganam,

Thanks for the links. Truly enlightening and I'm glad about my initial question so I can now have a better understanding of all the issues related initially with a small annoyance (having to change the enum name).

Seems to me that until NT support custom namespaces, unfortunately the best option is to 'pollute' the global namespace, because if I understood correctly strategies using the indicator will not work. Additionally, I would have another small annoyance having to add my namespace into the zip file in every release (although I totally understand that it's a better programming practice).
Maybe for now, and my small number of users, I will create a super encrypted enum name that will be impossible to conflict with any vendor or indicator in the world... I know that may make your professor cringe, but until NT comes up with a more elegant solution, I guess that's what I'm left with...

Thanks a lot, and great discussion!

[koganam]

koganam: I'm a newbie, so forgive the simple question, but by 'global namespace', do you mean possibility #1, or possibility #2 in my example below? I'm guessing #1? I followed your links but I'm still not completely sure.

Edit: I added a possibility #3!

using things;
 
//possibility #3
 
namespace NinjaTrader.Indicator
{
    //possibility #1
    public class SMA : Indicator
    {
        //possibility #2
        protected override void Initialize()
        {
        }
        protected override void OnBarUpdate()
        {
        }
    }
}

"possibility 3" is outside the class, and hence, as defined, is in the global namespace.