NTb9 Cant install Dockpanel anymore.

[marty087]

Hi,

I have been installing Stackpanels and Dockpanels to hold buttons int NT8

The code i am using is based on the example attached here and provided by Sim22 in the forum below. (based on Edges concept originally)

http://ninjatrader.com/support/forum/showthread.php?t=74225

NTb9 can't install the dockpanel whereas NTb8 had no problem. NTb9 now crashes the chart window upon adding the indicator. The only solution is to Ctrl Alt Del.

The line of code causing the hang is this
Chart myChart = Window.GetWindow(cc.Parent) as Chart;

Can someone tell me what changes in beta 9 would be causing this and suggest where to from here?

Thanks.

[karlomacariola]

I'm having the same issue. Thank you for bringing this up. I'll be watching this space.

[NinjaTrader_ChelseaB]

Hi marty087,

Thanks for reporting the behavior. I am doing some testing now and I will get back with my findings.

[NinjaTrader_ChelseaB]

Hi marty087,

It looks like due to some threading changes on the backend, Dispatcher.Invoke((Action)(() => { })); should be changed to Dispatcher.BeginInvoke((Action)(() => { }));

Note: As best practice, always be sure to use Dispatcher.BeginInvoke() to ensure that your action is one asynchronously to any internal NinjaTrader actions. Calling Dispatcher.Invoke() (synchronous) can potentially result in a deadlock scenario.

[dotnet]

You can not use BeginInvoke in dispose/Terminate state, async dispose is calling for disaster to happen.

Now we have two options:
Either hang ninjatrader with Invoke , or
use BeginInvoke which sometimes run too late in Terminate state (after the next cycle of Configure state) and trash the indicator.

Another thing for BeginInvoke, it looks like in tickreplay the UI thread is now frozen from Configure state to finish. So if the indicator run for 5 minutes, then BeginInvoke (calling from Configure) will 'hang' 5 minutes and run after the last bar replayed.
It is hard to understand why would the ui thread is locked/frozen for that long in a multithreaded environment.
The "thread change" you mention is more likely a new thread lock bug introduced in B9.

[NinjaTrader_Brett]

Hi dotnet,

I did discuss your comments with our development team.

Frankly they were surprised that Dispatcher.Invoke() was even working reliably prior to B9 since on our development team we had to switch to primarily using BeginInvoke() as a primary dispatcher invoking method in our code base.

I myself just got educated on the BeginInvoke vs Invoke use case and will be adding this information to our help guide to make it more clear for future users.

- Invoke() will block the invoking thread until that invoke action has been completed.
- If you use Invoke() you can get into what's known as a 'deadlock' scenario where the invoking thread ends up waiting for the target thread to be available and simultaneously the target thread now is also waiting on the callee thread for something. What results in no further work being possible to be done since we're stuck in a infinite wait loop aka 'deadlock'.
- BeginInvoke() resolves this by not blocking the current threads execution and completely removes a big component of the complexity of multi threaded design and as such is the recommended way to go considering you don't have a hand in how we under the hood work with multiple threads.

As to your concerns about OnTermination and BeginInvoke being too late resulting in a race condition with OnTermination then please provide a quick example so I could consult our development team. Since on first discussion with them they didn't see how it could be an issue since in principle you should only be using the dispatcher to interact with the UI.

[cls71]

The attached indicator changes the margin right of the chartcontrol in the Historical state. In the Terminated state returns the original margin right to the chartcontrol.

If in the Terminate state you use "BeginInvoke" the chartcontrol never returns to its initial margin right. Try reloading several times the indicator, not just one. The margin right is widening with each reload (each two reloads really).

If in Terminate state you use "Invoke" the chartcontrol retrieves his original margin right when the indicator is terminated with each reload.

PD: In my indicators I am using Invoke in the Terminated state and BeginInvoke in the rest of the code, and everything works fine so far.

[dotnet]

UI locked in tickreplay

Hello Brett,

The attached indicator demonstrate with BeginInvoke that the UI thread is fully locked,
the Print message from the BeginInvoke show up at the very end of the bar replay.

dotnet

[NinjaTrader_Matthew]

The attached indicator changes the margin right of the chartcontrol in the Historical state. In the Terminated state returns the original margin right to the chartcontrol.

If in the Terminate state you use "BeginInvoke" the chartcontrol never returns to its initial margin right. Try reloading several times the indicator, not just one. The margin right is widening with each reload (each two reloads really).

If in Terminate state you use "Invoke" the chartcontrol retrieves his original margin right when the indicator is terminated with each reload.

PD: In my indicators I am using Invoke in the Terminated state and BeginInvoke in the rest of the code, and everything works fine so far.

Thanks for the example, however the way you're pulling the intial bar value is flawed. You needed to pull the original value from the same thread that the charts UI is running. If you instead move that logic within Dispatcher.BeginInvoke() action, it works as one would expect and does not have the issue where you it continually increases the margin.

Dispatcher.BeginInvoke(new Action(() =>
{
	initialBarMarginRight = ChartControl.Properties.BarMarginRight; // pull this from within same thread that the chart UI property runs
	if (ChartControl != null)
		ChartControl.Properties.BarMarginRight += 100;
}));

Anytime you're using Invoke(), you're risking a possible deadlock scenario. At this time, we still stand by the stance that these actions should be done async to avoid possible dead locks with internal actions as we may implicitly lock the UI for various actions.

If you have another example where you can demonstrate issues from BeginInvoke/InvokeAsync we'll be happy to look into it.

[NinjaTrader_Matthew]

Hello Brett,

The attached indicator demonstrate with BeginInvoke that the UI thread is fully locked,
the Print message from the BeginInvoke show up at the very end of the bar replay.

dotnet

It is expected that the UI will be locked as tick replay is processed. This is because these events happen on that UI thread.

Thanks again for the sample, however we're not 100% what you are demonstrating. If you're using this to interact with the UI, this can happen any time before or after the historical data is processed.

Can you help us qualify this problem for development? What is the exact scenario where you needed the UI control before tick replay is ran?

[dotnet]

tickreplay block the UI thread

"It is expected that the UI will be locked as tick replay is processed. This is because these events happen on that UI thread."

No this is not expected, no these events does not happened in the UI so far.

Now that the UI thread is locked, the indicator can't show any kind of status information.
The user stare a blank chart for half an hour without anything to happen visually.

Why do you run tickreplay in the ui thread (since B9)? This is a multithreaded environment, how does locking the UI thread with a long running task make sense?

[dotnet]

B9 main thread lock

Just checked it, you really do block the main UI thread, every chart and every windows is locked (not updating,non responsive), because of 1 chart has an indicator playing tickreplay.

[NinjaTrader_Matthew]

As an update, we are listening and we understand our locking strategy has many downstream implications that are creating complications for 3rd party developers and as such we are reviewing our policies under NTEIGHT-9462.

Aside, for consistency and best practices, our lead engineer is recommending the more modern .NET 4.5 InvokeAsync over BeginInvoke and our docs will reflect this where possible.

We are working through the various use cases of running Invoke vs InvokeAsync, but as previously stated - 3rd parties are still advised to try to use InvokeAsync where possible to completely avoid deadlocks in the future.

We will be sure to update this thread when that is finalized.

[NinjaTrader_Brett]

Dotnet,

Your issue on the UI becoming unresponsive as a tick replay simulation is running has been looked into by our development team.

We ran through various test cases and scenarios and, in the end, we will unfortunately be expecting UI unresponsiveness when running complex long running tick replay simulations. This is due to a design pattern which is put in place to ensure reproducibility of data in the charts.

You would experience the same in NinjaTrader 7 with long loading indicators and even though NinjaTrader 8 is multi-threaded and we have a lot of advantages that we enjoy because of that, having a responsive chart while the Tick Replay simulation is in process was not achievable.

Thanks for taking the time to report your experience with NinjaTrader 8. It made us go back to our code base to ensure what we have implemented is really what at a technical level was expected and allowed us the opportunity to challenge our own design. We can both agree it is preferable to have a responsive UI from a user's perspective, which is why we will continue to evaluate any new design approach which would allow us to remove that limitation in the future.

-Brett