Is it possible (adviseable) to display a WindowsForm while running a strategy?

[tradefaz]

I would like to show a real-time UI of what my strategy is doing, while it's running. This is mainly for when I run it on a live feed, so that I can really understand the state of the internal variables. I don't think it will have much value during backtesting, and the information would change too quickly.

In any event I'd like to throw up a WindowsForm that just displays variables. Perhaps I will even have a few knobs that let me tweak different variables to change the nature of the strategy while it's running.

Is this OK to do given the threading model of NS? I can run the UI on it's own Win32 thread msg pump. I just want to be sure it doesn't interfere with the main thread that the strategy uses and doesn't interfere in any way with the real-time execution of the system.

Anyone ever do this before?

Many thanks for any feedback.

[NinjaTrader_JoshP]

tradefaz,

As you probably would have guessed this is outside of the scope we can offer support for. I don't believe that having a form in and of itself will cause problems, but take caution when trying to confirm this statement for yourself because I have never tried. You are in uncharted territory. Good luck.

[NinjaTrader_Dierk]

You could try a non-modal form. You NEVER should try a modal form, since this could block your message queue.

Anyway, unfortunately this is beyond the scope of what we can provide support for.

[tradefaz]

You could try a non-modal form. You NEVER should try a modal form, since this could block your message queue.

Anyway, unfortunately this is beyond the scope of what we can provide support for.

Well since the NinjaScript doesn't run on a UI thread (it doesn't, does it?) a modal form would have no meaning. If I launched a non modal form on my own Win32 UI msg pump, and from there launched a modal form, I would be fine, since the script would be running on the original primary (1st) thread.

In any case, that is all semantics. Unless of course NS does run on a UI thread with a message queue, but that would be odd, since there are no UI controls attached to that thread that I know of.

The other way to maybe do this would be to use Win32 Named Pipes, which would not have any untoward effect on the thread that NT is running on. Instead I could have a sepearate process running that picks up data off the named pipes and displays it, and if necessary, communicates it back to the NT script through another named pipe.

[NinjaTrader_Dierk]

>> Well since the NinjaScript doesn't run on a UI thread
Sure it does.

[tradefaz]

>> Well since the NinjaScript doesn't run on a UI thread
Sure it does.

How so? If the strategy script ran on the UI thread, then the entire NT UI would be blocked from receiving messages until the strategy completed, unless the code that invokes the strategy's events poked the Win32 message queue in between market data and bar interval updates, which would be frightening if true.

The script has to be running on its own thread, spawned from the UI thread. That means its not running on the UI thread.

Please correct me if I'm wrong.

[NinjaTrader_Dierk]

It works as per my post below.

[tradefaz]

It works as per my post below.

Sorry, which post? You're confirming that a strategy does in fact run *on* the same UI thread that the NT interface receives messages on?

[NinjaTrader_Dierk]

That is correct

[tradefaz]

That is correct

Why is that? Why doesn't NT just launch a separate thread for the strategy to run on? That means NT is a single threaded app?

[NinjaTrader_Dierk]

Thanks for your suggestion. We'll add it to the list of future considerations.

[twtrader]

Traderfaz,
I have no knoweledge of NT internals, but I do know that threading has always been a problem on Windows and Windows forms. It is not as easy to make a multi threaded app in Windows as it is in say Linux, FreeBSD or OSX.

Why is that? Why doesn't NT just launch a separate thread for the strategy to run on? That means NT is a single threaded app?

[tradefaz]

Traderfaz,
I have no knoweledge of NT internals, but I do know that threading has always been a problem on Windows and Windows forms. It is not as easy to make a multi threaded app in Windows as it is in say Linux, FreeBSD or OSX.

I am not sure why you feel this way. Windows implements POSIX standards for threading, including pThreads, which is what *NIX implements. Beyond that, the threading support in Windows is very rich. There exists no richer and more powerful UI framework than WindowsForms, both from a performance perspective and from the perspective of a framework that is closely tied to the underlying windowing API, in this case Win32. I know WindowsForms is not without its warts, but I can tell you as someone who's implemented global trading systems that run in real time, and with high frequency updates, there is simply no story on Unix that can compete, short of writing it in OpenGL.

Threading in .NET is very easy as well. I would like to understand the internals of NT better myself. I will do some perfmon observations and see what I notice.

[mrlogik]

tradefaz,

I think the least intrusive (and dirtiest) way of getting data from a particular strategy to a non-modal windows form is by global variables. You can make an empty indicator with some design scheme, chart / form identifier, etc to set / get specific data.

I'm sure there is a more elegant way of passing data from one to the next like subscribing to an event that a strategy fires, or reading from a strategy object (if such exists). Maybe we can delve into the NT libraries and see what is open for use?

Just a few thoughts

[twtrader]

Then I am sure you will have no problem implementing what you want in Ninja.

Have a nice day.

I am not sure why you feel this way. Windows implements POSIX standards for threading, including pThreads, which is what *NIX implements. Beyond that, the threading support in Windows is very rich. There exists no richer and more powerful UI framework than WindowsForms, both from a performance perspective and from the perspective of a framework that is closely tied to the underlying windowing API, in this case Win32. I know WindowsForms is not without its warts, but I can tell you as someone who's implemented global trading systems that run in real time, and with high frequency updates, there is simply no story on Unix that can compete, short of writing it in OpenGL.

Threading in .NET is very easy as well. I would like to understand the internals of NT better myself. I will do some perfmon observations and see what I notice.