Compiling PriceActionSwingPro

[Chart]

Hello,

Anyone using PriceActionSwingPro have issues compiling?

I'm getting this error:

NinjaTrader.Strategy.Strategy.PriceActionSwing(int , double, PriceActionSwing.Base.SwingStyle, bool)' is a 'method', which is not valid in the given context

When attempting to compile this:

if(PriceActionSwingPro(35, 7, PriceActionSwing.Base.SwingStyle.Ticks, false).DoubleTop[0] > CurrentDayOHL().CurrentOpen[0])

Thanks in Advance

[NinjaTrader_CodyB]

Hello,
Due to the nature of the PriceActionSwingPro indicator you will need to add in a using declaration for PriceActionSwing.Base. Once that is added in you can call the SwingStyle by using SwingStyle.Ticks.

I have provided an example below:

#region Using Declarations
//Below The other Declarations
using PriceActionSwing.Base;
#endregion

 protected override void OnBarUpdate()
 {
    if(PriceActionSwingPro(35, 7, SwingStyle.Ticks , false).DoubleTop[0] >      CurrentDayOHL().CurrentOpen[0])
    //DoSomething
}

Do to having to add in the using statement you would not be able to export this indicator and have it import. The developer of this indicator would need to make a change to it or have some other work around for calling this indicator within NinjaScript.

[bltdavid]

Do to having to add in the using statement you would not be able to export this indicator and have it import.

[Do != Due.]

Whaaaa? You sure about that?

For someone who only uses the indicator on their charts, and not in NinjaScript, this is simply not true. But, for all others, it's not true either: the use of "using" is no impediment to exporting.

The developer of this indicator would need to make a change to it or have some other work around for calling this indicator within NinjaScript.

Whaaaa? Do you really mean that as something that is important?

The same statement could be said about using MessageBox() -- which requires the NinjaScript writer to specify,

using System.Windows.Forms;

Sorry, Cody, I disagree with your two statements. They are incomplete and misleading, or relatively useless.

[koganam]

It is not an impediment to exporting the class: it is an impediment to importing the exported class on another system.

[bltdavid]

It is not an impediment to exporting the class: it is an impediment to importing the exported class on another system.

How so?

What import errors should one expect?

[koganam]

How so?

What import errors should one expect?

An inability to access the public property in the custom namespace, when calling the instance constructor.

[bltdavid]

An inability to access the public property in the custom namespace, when calling the instance constructor.

But, if all files are added to the exported .zip file correctly at the time of export, then I contend this problem won't occur. Why? Because the file(s) containing the custom namespace, if added to the export, means accessing said public property in that custom namespace should now succeed during the silent compile.

I mean, if PASPro has one or more auxiliary files with additional namespaces used by the main indicator file, then just click the arrow button in the export dialog to manually add those auxiliary files to the export.

If NT does not detect and add all needed auxiliary files to the export automatically, then the undetected files must be added manually. There are add/delete "arrow" buttons in the export dialog specifically for this.

[koganam]

But, if all files are added to the exported .zip file correctly at the time of export, then I contend this problem won't occur. Why? Because the file(s) containing the custom namespace, if added to the export, means accessing said public property in that custom namespace should now succeed during the silent compile.

I mean, if PASPro has one or more auxiliary files with additional namespaces used by the main indicator file, then just click the arrow button in the export dialog to manually add those auxiliary files to the export.

If NT does not detect and add all needed auxiliary files to the export automatically, then the undetected files must be added manually. There are add/delete "arrow" buttons in the export dialog specifically for this.

Would that it were so simple. But that is easy to check. Do it and see. This is not a theoretical argument: many have already been tripped up by the situation.

After you do the necessary and come a cropper, we can continue this discussion.

Part of the problem is that NT recompiles your exported, and then imported code again into its gumball. The namespace may be exported: its reference is a different kettle fish during a recompilation.

[bltdavid]

Would that it were so simple. But that is easy to check. Do it and see.

Rats. You beat me to it. I was about to ask you for an example.

After you do the necessary and come a cropper, we can continue this discussion.

Ok, I will make an attempt and get back to you, but give me a couple days. Monday is coming, always busy then.

[Btw, I had never heard the expression 'come a cropper' ... that was something new I had to lookup, lol.]