F5 -- how can I make that happen?

[ETFVoyageur]

There is a chart window context menu entry "Reload NinjaScript", with hot key F5.

How can I accomplish the same thing from OnStartUp()?

Thanks,
EV

[NinjaTrader_Brett]

Hello,

Thanks for your note.

Why would you want to do this? This would put you in a loop that you would never be able to recover from...

I look forward to assisting you further.

[NinjaTrader_Brett]

Also, I know of no way to reload NinjaScript from the strategy. As their is not a supported case where you should have to do this.

Let me know if I can be of further assistance.

[ETFVoyageur]

Hello,

Thanks for your note.

Why would you want to do this? This would put you in a loop that you would never be able to recover from...

I look forward to assisting you further.

I see you point that it would cause an infinite loop, and I certainly don't want that.

What I had in mind is still my Data Box issues. If I stop and restart the Data Box (by hand), it picks up what I want it to. If I use F5 on the chart, that also causes Data Box to update itself.

I just want something I can do from OnStartUp() that will force the Data Box to update itself.

--EV

[NinjaTrader_Brett]

Hello,

Gotcha, yea was a good idea but not supported unfortunately. All strategies must be enabled by hand by the user. This is a liability issue from our standpoint as we never want an automated strategy enabled unless the user specifically chooses to enable it. AKA, NinjaTrader will never place trades unless you specify it to do so.

Let me know if I can be of further assistance.

[ETFVoyageur]

I understand your liability concern.

I do not understand what wanting to force the Data Box to refresh itself has to do with either strategies or placing trades, though.

--EV

[NinjaTrader_Brett]

Hello,

Has to do with the fact that you cant enable a strategy programatically.

Which is what a reload NinjaScript does.

Disables the Strategy then Enables the strategy.

Let me know if I can be of further assistance.

[ETFVoyageur]

Let me know if I can be of further assistance.

Don't worry ... I'll think of something ...

--EV

[ETFVoyageur]

Reloading NinjaScript is a pretty heavyweight way to do it anyway.

What I would really like is DataBox.Refresh() as long as I have to live with a Data Box that is driven by side effects.

(Remember my other thread request for direct Data Box access?)

--EV

[NinjaTrader_Brett]

Hello,

Right and its still not supproted. I will be unable to assist with this. Sorry.

[koganam]

Sending the F5 key is a small issue. The problem is how to ensure that it is sent only once after using the configuration dialog. It seems you have to be able to trap when the configuration dialog is closed and then send the F5 key once only. Of course, if you can figure out how to use any other persistent state variable, one could do the same thing by checking the state variable. I can think of creating a temp file and using it as a check, but that sounds really cumbersome and error prone.

Anyhow, here is how you send the key:

System.Windows.Forms.SendKeys.Send("{F5}");

[ETFVoyageur]

Sending the F5 key is a small issue. The problem is how to ensure that it is sent only once after using the configuration dialog. It seems you have to be able to trap when the configuration dialog is closed and then send the F5 key once only. Of course, if you can figure out how to use any other persistent state variable, one could do the same thing by checking the state variable. I can think of creating a temp file and using it as a check, but that sounds really cumbersome and error prone.

Anyhow, here is how you send the key:

System.Windows.Forms.SendKeys.Send("{F5}");

Thanks for the suggestion. I'll have to think about the related issues.

• The plot name is the easier one -- no saving and restoring. The only real issue is sending the F5 and then when the instance gets created to replace the current instance it has to know that no further F5 is needed. I think I can handle that one. Since a real F5 gets the right result, it makes me think that Plot.Name is preserved. If so, that is my state variable -- all I have to do is check to see whether it is already set correctly. If so, no new setting and no more F5.

• Transparency is a bigger deal, because I have to know when to change the plot colors

• • We have already established that no one can think of a way to know when the Indicators dialog is opening, so we cannot restore the colors as we must. Note: Dispose() does not work -- it is called on the wrong instance. I could not find anything that is called on the correct instance to do the restore. That is a deal killer.
  
  

• • Even if I could get the colors restored, I need to save them and go back to transparent when the dialog closes. OK and Apply are fine -- I'll get a new instance and OnStartUp() will be called. The problem is with Close -- I have no idea at all how to catch that.
  
  

When the dialog comes up, two instances are created. One is Disposed quickly and the other not until the dialog goes down. I do not know how to tell that any given instance is that second one, however. Perhaps if it could do something like in its Dispose() method see whether the dialog is still up. I have no idea how to do that, though. Unless this is solved, that is a deal killer.

• • Finally, the question of whether doing this is even a good idea. I am especially worried about the earlier comments in the thread that doing so could cause things like a strategy to reset and place an unexpected order.
  
  

Bottom line: I think I could make the label part work. Setting plots transparent has a couple of deal killers unless we can think of a way around those problems. But the overriding issue is whether or not is a safe thing to do to the system.

I'll be glad to take a shot at handling the label, but only if Brett can assure me that doing so will not cause any other problems in the system.

--EV

[koganam]

As usual, once I made the suggestion, my intransigence would not let me stop thinking about it. This is the simplistic solution that I came up with:

#region Variables

private bool boolAlreadyRefreshed = false;

OnBarUpdate() method:

 if (!this.boolAlreadyRefreshed && !Historical  && FirstTickOfBar) 
            {
                this.boolAlreadyRefreshed = true;
                System.Windows.Forms.SendKeys.Send("{F5}");
            }

This should ignore all historical data, then pass F5 once on the realtime data

[ETFVoyageur]

1) What if there is only historical data? Back testing, not real time would have that case?

2) After an OK or Apply, you will be on a new instance, so your local variable cannot carry the correct state. A static could, but that will not work because it is entirely reasonable to have multiple instances of the indicator.

Am I missing something?

--EV

[koganam]

How about divorcing the user parameters set from the processing parameters. That way, you only have to capture the user parameters when the dialog is closed, but any changes you make are never reflected in the user parameters set.

Example:

userColor is set by user in config dialog

In code, you use this instead:

int codeParm = userColor;
// then make all changes/calculations using codeParm

Thus, the user parameters are preserved, because they are never touched; just used to pass their values to the code parameters that can be manipulated all willy nilly. It means that every time the indicator is loaded, the user's existing parameters are reloaded too from the template.