How to add a new parameter to an indicator?

[ETFVoyageur]

Is there a detailed description of how to add another parameter to an indicator?

I know about adding the property and the private value. That gets it to show up in the configuration dialog the user sees, and makes it available for the indicator to use. That's fine as far as it goes, such as for parameters that only affect visual aspects of a plotted indicator.

However, for any parameters that affect the indicator calculation, I believe the situation is more involved. My concern is that knowledge of these parameters seems to be baked into the code under
"#region NinjaScript generated code. Neither change nor remove."

I am suspicious that I do in fact need to also change that code to pass the new parameters to constructors, etc.

I could just go barging in, but I'd really rather first look at a written description of just what needs to be done.

Thanks,
EV

[NinjaTrader_Bertrand]

EV, I'm not sure I follow you - first of all : the NinjaScript editor generated section should never be touched.

If you want to add a user input, here are the steps needed - http://www.ninjatrader.com/support/f...ead.php?t=5782

After recompilation, the overloads would then list it as well.

[ETFVoyageur]

EV, I'm not sure I follow you - first of all : the NinjaScript editor generated section should never be touched.

If you want to add a user input, here are the steps needed - http://www.ninjatrader.com/support/f...ead.php?t=5782

After recompilation, the overloads would then list it as well.

I do not understand. I have done as the document says, but I do not see how that is going to modify the code in the do-not-change part. That unchanged code now has constructors that are inadequate -- they do not pass along my added parameters.

The document works fine if all I want to do is have the indicator be added to a chart and function with the new parameters. No problem -- I have done that and it works. I presume that the do-not-touch stuff is used when the indicator is called from another script. That is not going to work, because there is no way to pass the needed parameters.

--EV

[NinjaTrader_Bertrand]

When I test it here, the wrappers do get amended as expected - can you please try to copy the code to a new indicator and then recompile to see if that would amend it for you?

Thanks,

[RJay]

I do not understand. I have done as the document says, but I do not see how that is going to modify the code in the do-not-change part. That unchanged code now has constructors that are inadequate -- they do not pass along my added parameters.

The document works fine if all I want to do is have the indicator be added to a chart and function with the new parameters. No problem -- I have done that and it works. I presume that the do-not-touch stuff is used when the indicator is called from another script. That is not going to work, because there is no way to pass the needed parameters.

--EV

EFTVoyageur,

There is an easy way to remove parameter from the "do not change section".

Simply make the following change and compile.

--------------------------------------------------------------------------------

From:

[Description("")]
[Category("Parameters")]
public int LowerVolLimit
{
get { return lowerVolLimit; }
set { lowerVolLimit = Math.Max(1, value); }
}

--------------------------------------------------------------------------------------

To:

[Description("")]
[Category("General")]
public int LowerVolLimit
{
get { return lowerVolLimit; }
set { lowerVolLimit = Math.Max(1, value); }
}

---------------------------------------------------------------------------------------------


All references to this parameter in the "do not change" section are automatically removed.

If you ever want to remove a parameter from an indicator, you MUST do this step before removing the parameter from the code or you will blow up the indicator.

Merry Christmas,

RJay

[ETFVoyageur]

rt6176,
That is good info. However my need is the reverse -- I am trying to add more parameters.

--EV

[NinjaTrader_Brett]

Hello,

Simply add the parameters as you would any normal parameter. This will work for the chart input parameters and also for when you use the indicator from another script.

The section under DoNotChange when you compile gets regnerated with new code to relfect your parameter additions. Therefor change it once and it will change everywhere else it is needed.

[ETFVoyageur]

When I test it here, the wrappers do get amended as expected - can you please try to copy the code to a new indicator and then recompile to see if that would amend it for you?

Thanks,

Since you say please

I tried it with a brand new custom indicator, and it works as you say.

Unfortunately, with my own custom indicator, that is not so. When I do exactly the same thing to it, the bottom code is not updated.

Next I tried commenting out the generated code in my test indicator, to see that the bottom code would get regenerated -- it did -- the commented bottom code got removed and new code generated. The only problem was that the new bottom code was preceded by a line containing just a single slash (/), and so failed to recompile. It compiled fine after I removed that line. (Sound like a minor system bug. )

So I tried the same thing with my real indicator and the result was quite different. The commented out bottom code was not removed, and no new bottom code was generated.

It looks as if the regenerated code is not being regenerated in my real indicator. Any idea why that would be? I'll try to isolate the problem, but anything you know about what could prevent the regeneration would be helpful.

--EV

[NinjaTrader_Brett]

Hello,

Most likely something may have been corrupted or changed that broke this behaivior.

Please copy the indicator contents into a new container file with an untouched wrapper sections please to see if this does the trick.

[ETFVoyageur]

Hello,

Most likely something may have been corrupted or changed that broke this behaivior.

Please copy the indicator contents into a new container file with an untouched wrapper sections please to see if this does the trick.

What do you mean by a "wrapper section"? Anything other than the generated code that I need to be careful of?

--EV

[ETFVoyageur]

I h ave been able to replicate the problem in my new test indicator as well. I have a theory about the problem.

Does making any change at all to the generated code break the system? Perhaps a checksum is retained and verified before the generated code will be replaced?

I did not add or remove change any code in my generated area, but I did alter it a bit -- I changed the spelling of a property and the result would not compile. I then updated the spelling in the generated code, and it compiled.

Could that have broken things?

--EV

[ETFVoyageur]

OK -- I have fixed the problem.

I saved the entire text of my class, deleted the bad indicator, created a new vanilla one of the same name, and replaced the indicator class text with what I had saved.

This one seems to work fine -- I can add, remove, or rename variables and the bottom part gets regenerated just fine.

I have no idea what got corrupted before that was preventing code regeneration. Either the system has a bug that I do not know how to reproduce, or else there is something a bit fragile that I need to be careful of. In the latter case I sure wish I knew what the issue is so that I could be careful.

--EV

[NinjaTrader_JoshP]

EV,

Yes that would have broken something. You cannot modify anything in that section at all. I suggest you delete those scripts and start with a clean slate without touching those sections.

[ETFVoyageur]

EV,

Yes that would have broken something. You cannot modify anything in that section at all. I suggest you delete those scripts and start with a clean slate without touching those sections.

As you see, we crossed in the mail. I have done exactly that.

That leaves the interesting question of why the compile failed to begin with... I guess we'll never know that.

--EV

[ETFVoyageur]

Next question about the generated code

For my next question, how does the code generation decide which parameters to pass?

My indicator has two classes of parameters. Some are needed for its logic, and must be passed when it is accessed programmatically. Others are for cosmetics (such as color) and are important for plotting, but there is no good reason to require a programmatic caller to supply them.

How can I make that separation?

Thanks,
EV