OnStateChange event does not get raised on chart window in AddOn

[codeowl]

Hi there,

I have created a very simple add on. All it does is get a reference to the chart window, and print to the ninjascript output window when events get raised. The addon was created with the ninjascript wizard which put the OnStateChange event in form me. The OnWindowCreated and OnWindowClose events are getting raised, and the OnStateChange event does get raised for some other windows, (You can see if you attached VS debugger with breakpoint) but not the Chart window.

Below is the code for the AddOn to replicate the issue, and I have also attached it as a cs.

Is this a bug?

Regards,

Scott

#region Using declarations
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Input;
using System.Windows.Media;
using System.Xml.Serialization;
using NinjaTrader.Cbi;
using NinjaTrader.Gui;
using NinjaTrader.Gui.Chart;
using NinjaTrader.Gui.SuperDom;
using NinjaTrader.Data;
using NinjaTrader.NinjaScript;
using NinjaTrader.Core.FloatingPoint;
using NinjaTrader.Gui.Tools;
#endregion

//This namespace holds Add ons in this folder and is required. Do not change it. 
namespace NinjaTrader.NinjaScript.AddOns
{
	public class TestOnStateChangeAddOn : NinjaTrader.NinjaScript.AddOnBase
	{
		private Chart _chartWindow = null;
		
		protected override void OnStateChange()
		{
			if (_chartWindow != null) {
				Print("TestOnStateChangeAddOn.OnStateChange - Event Raised - Chart Window");				
			}
			if (State == State.SetDefaults)
			{
				Description							= @"Enter the description for your new custom Add on here.";
				Name								= "TestOnStateChangeAddOn";
			}
			else if (State == State.Configure)
			{
			}
		}

		protected override void OnWindowCreated(Window window)
		{
			window.Dispatcher.Invoke((Action)(() =>
            {
                _chartWindow = Window.GetWindow(window) as Chart;
                if (_chartWindow != null)
                {
                    Print("TestOnStateChangeAddOn.OnWindowCreated - Event Raised - Chart Window");
                }
            }));
		}

		protected override void OnWindowDestroyed(Window window)
		{
			if (_chartWindow != null) { 
				Print("TestOnStateChangeAddOn.OnWindowDestroyed - Event Raised - Chart Window");
			}
		}

	}
}

[NinjaTrader_Jesse]

Hello,

Thank you for the question.

I wanted to check, are you trying to view what state the other window is in or the addons specific state?

The other window that is opened may or may not have NinjaScript objects applied so there may or may not be items in the other window with states to check. The OnStateChange in the Addons script would report the Addons specific state.

Can you tell me what specifically you need to do regarding the state and I could suggest an approach possibly.

I look forward to being of further assistance.

[codeowl]

Jesse,

Thanks for the response. I want to create a button in the toolbar of the chart that I can toggle a panel to the side of the chart like the Chart Trader panel.

I have seen the following topics in the Help Doco:

http://ninjatrader.com/support/helpGuides/nt8/en-us/using_bitmapimage_objects_with_buttons.htm

http://ninjatrader.com/support/helpGuides/nt8/en-us/?usercontrolcollection.htm

The first one seems to be doing it from an Indicator, and the second example really gives you no context at all as to where to put the code. I find this is a problem in a lot of the doco for NinjaScript. They may give you a code sample, but it has no context as to weather it is in an indicator, strategy, add on etc...
Without that information, I don't know how we spost to work out where to put it, other than posting more questions on the forum.... which is more work for everyone, us and you....

Also the two help topics above seem to contradict each other. The first one shows you how to add a button the the charts main menu, the second one says you shouldn't do that and you should instead use the UserControllCollection.... and then goes on to say in the notes:
This collection is provided "as-is" and does NOT contain any automatic layout options. By default, the last added framework element will reside on top of any previously added controls. This means it is possible for a user to install two NinjaScript objects which may be competing for an area of a chart.

This does not seem like a very robust option?

Anyway my reason for choosing an AddOn was because I am not creating an Indicator, or a Strategy, so it seemed like the logical choice.

I had attempted to wire up a handler to the _chartWindow.StateChange event, but this didn't get raised either.

Any direction you could give me would be much appreciated.

Regards,

Scott

[NinjaTrader_Jesse]

Hello,

Thank you for the reply.

You are correct for using an Addon if you want a Global option to add to all charts etc. Indicators would be good for adding a button to an individual chart but in this case it sounds like you need an addon.

I have created a sample that adds a button to the Toolbar, it also removes that button and handler on window closed.

You could of course apply the logic in the samples you provided that checks the active chart tab and so on for more complex uses, this would simply add a button to every chart that is opened. All buttons would then point to a single handler which you could see which button called the click.

Addons would work very similar to the Indicator example, in this case we just needed to get the correct parent object and basically all of the existing code fit after that point.


I look forward to being of further assistance.

[codeowl]

Jesse,

Thanks for the response and for taking the time to create an example. Much appreciated!!

A few questions:

Q1) On this page: http://ninjatrader.com/support/helpG...collection.htm
It has the following warnings:
1. This property should ONLY be accessed once your NinjaScript object has reached State.Historical or later
2. You MUST use a Dispatcher in order to account for any UI threading errors. Please see the example below for proper usage
3. It is imperative that you dispose of any custom control resources in State.Terminated to ensure there are no leaks between instances of the object

Your example does not use a Dispatcher. In the warning above the word MUST is in capitals and bold, suggesting it is pretty important. Is this not needed in AddOn's?

Q2) In the above page it also says:
...it is recommended to add it to this UserControlCollection rather than attempting to modify or add to any pre-existing NinjaTrader chart elements.

Your example does not do this. Is this not needed in AddOns?

I am assuming your example is a valid way of achieving my goal, yet it goes against these recommendations from the documentation?

Q3) In the above warnings it says:
This property should ONLY be accessed once your NinjaScript object has reached State.Historical or later
(This property being the UserControlCollection)

Is this not the case in AddOns? If this is the case, then I need the OnStateChange event of the AddOn to fire when the chart loads, so I can know when State.Historical is reached. But that is not happening...

In your first reply you said:
The other window that is opened may or may not have NinjaScript objects applied so there may or may not be items in the other window with states to check. The OnStateChange in the Addons script would report the Addons specific state.

So what does that mean in the context of what I am trying to do. Eg; I have some examples and strong recommendations from the documentation advising me that I MUST use Dispatchers and should use the UserControlCollection to add UI elements, and must ONLY do this when the State.Historical is reached, but as your example does none of these things, I am left wondering.... what is the correct way to do what I am trying to do?

Are you saying that the State.Historical will not be reached on a chart that just has bars, and no indicators or other objects loaded?
Or are you saying that an AddOn will not be notified of a Charts changes in state?

If that is the case, how can I follow the above recommendations from the documentation to add additional UI elements to the chart from an AddOn?

On top of all that we are told that if we write an NinjaScript object that does use the recommended way of adding elements to the chart via the UserControlCollection, that by default, the last added framework element will reside on top of any previously added controls.

This is something you have not addressed in your reply. How can we ensure that our NinjaScript objects will be able to work with others?

4) The next thing I wanted to do was get a panel to show on the side of the chart like the Chart Trader panel. With the Chart Trader panel it looks like the chart control is just re-sized and then Chart Trader controls are just placed on the chart window in the extra space. So I was going to take the same approach, but based on the above, maybe I would be better to do this in a separate window. If that is the case, how can I get a script in one window to read the data and indicators of a chart in another window?

In order to build robust NinjaScript objects that enhance the platform and do not result in unexpected behavior and bad experiences for the end user, we really need a solid set of API documentation and best practices for developing for the NinjaTrader platform.

Thank you for your time, I appreciate your input.

Regards,

Scott

[NinjaTrader_Jesse]

Hello,

Regarding your reply, the documentation provided here: http://ninjatrader.com/support/helpG...collection.htm

This documentation is not for an addon and would have different use cases/ syntax / precautions than an addon although the concepts and general usage are nearly the same. This would be similar to comparing two types of scripts like a indicator vs a strategy, although they do a lot of the same things they have different use cases.

All the notes on that page would directly apply to UserControlCollection, for Addon specific information you would need to see the appropriate addon documents.

Dispatchers are also used in addons but in this very specific example, one was not used. Dispatchers would be used as needed or when you are doing a cross thread operation.

For your Q2, these are different sections and are different use cases, for example a item that only needs to affect one chart like an indicator, it would be favored to use the UserControlCollection instead of an addon for that purpose. For affecting all windows without using a indicator, you would need to use the Addon base as this would be the only way to access all the other windows. In general it is not recommended to modify the UI as you can create problems or run into threading issues.

This section is reserved for advanced programmers so you will find a lot of warnings to pay attention to and not a lot of examples at this point because this is still a beta release. More common items will be fully documented but regarding Addons and the standard C# development side, there is not a lot of documented content but you will see the users on the forum are very active in this area currently. Advanced developers will have less problem with this section even though there is limited documentation as this begins to go into standard C# and WPF design so the documentation will largely come from MSDN or general C#/WPF tutorials for the items you create with this section of the platform.

For your Q3, again these are not the same topic at all so these questions would not really apply to Addons, the documents you find in the link you have provided would be specific to UserControlCollection.

Regarding OnStateChange, that would be a override for NInjaScript objects, this would not be called for anything except NinjaScript items that need a state. From an addon, only that specific addons state would be shown in its individual OnStateChange override. if you instead need to use OnStateChange for your logic from a specific indicator or other script, I would suggest looking into other options to find what best matches what you want to do and the overrides you need to use. A window its self would not have a state anyway, that is specific to NinjaScript types, like a Indicator or strategy, an addon would not see any states of other windows, only that it was created or destroyed.

Regarding the panel, that would be a even more complex item to develop and would depend if you need to just add a general panel to all charts or if that panel needed to do something specific like control a strategy, based on its use you could decide on what type of script to use.

This could be a panel in a chart or a new window, that would be up to you and would depend on its usage but again this would be a general WPF concept and not specific to NinjaTrader. The only specific portion of this to NInjaTrader would be where you execute the code that creates the panel/window and how you locate the place in the platform to create the object.

Please let me know if I may be of further assistance.

[codeowl]

Jesse,

Thanks for your clarifications mate. See my comments below in green

Regarding your reply, the documentation provided here: http://ninjatrader.com/support/helpG...collection.htm

This documentation is not for an addon and would have different use cases/ syntax / precautions than an addon although the concepts and general usage are nearly the same. This would be similar to comparing two types of scripts like a indicator vs a strategy, although they do a lot of the same things they have different use cases.

All the notes on that page would directly apply to UserControlCollection, for Addon specific information you would need to see the appropriate addon documents.

A fair point. I raised the question because, although I am developing an Add On, it will be working with all the same objects that are shown in the Chart - UserControlCollection example, and therefor it seemed logical that the same restrictions/best practices for adding UI elements, would apply.


Dispatchers are also used in addons but in this very specific example, one was not used. Dispatchers would be used as needed or when you are doing a cross thread operation.

I think, to discourage doing things that are considered bad practice, it would be good include to them in examples of how to correctly add elements to the NT UI. Or if they are omitted from an example it should be mentioned that they were omitted to keep it simple, but stated that they should always be included in production code.

How about some sort of guidelines as to how the multi-threading is implemented in NT. I am a programmer in my day job and have a decade of programming in C# under my belt, I have worked mainly in Winforms and ASP.NET, and I have done one Silverlight project and dabbled in a bit of WPF over the years. I have used background worker threads in WinForms projects, and am familiar with the concept of Dispatchers to update UI on different threads etc... But I knew the architecture of those projects as I built them.
For example:
* Is every window run in a separate thread?
* Is every chart control run in a separate thread?
* Are chart controls run in a separate thread from the window they are on?
* Is every indicator run in a separate thread?
* Are indicators run in a separate thread from the chart control they are plotted on?
* Is a strategy run in a separate thread to all the above?
* Is an add on run in a separate thread to all of the above?
* DrawingTool... etc...
* etc...
Knowing this information would help us design robust solutions, and optimize by only using Dispatchers where we need to.


For your Q2, these are different sections and are different use cases, for example a item that only needs to affect one chart like an indicator, it would be favored to use the UserControlCollection instead of an addon for that purpose. For affecting all windows without using a indicator, you would need to use the Addon base as this would be the only way to access all the other windows. In general it is not recommended to modify the UI as you can create problems or run into threading issues.

This section is reserved for advanced programmers so you will find a lot of warnings to pay attention to and not a lot of examples at this point because this is still a beta release. More common items will be fully documented but regarding Addons and the standard C# development side, there is not a lot of documented content but you will see the users on the forum are very active in this area currently. Advanced developers will have less problem with this section even though there is limited documentation as this begins to go into standard C# and WPF design so the documentation will largely come from MSDN or general C#/WPF tutorials for the items you create with this section of the platform.

Ok cool... Yes I see what you mean, it's fair to say the doco is a bit light on with pages like this:

http://ninjatrader.com/support/helpGuides/nt8/en-us/?ntwindow_class.htm

I have no problem coding correctly for multi-threading, using Dispatchers where needed, and standard C#/WPF programming. But I think some documentation on the threading model (eg; what objects spin up in new threads) you have used, would greatly assist design/development for NT partners.


For your Q3, again these are not the same topic at all so these questions would not really apply to Addons, the documents you find in the link you have provided would be specific to UserControlCollection.

Regarding OnStateChange, that would be a override for NInjaScript objects, this would not be called for anything except NinjaScript items that need a state. From an addon, only that specific addons state would be shown in its individual OnStateChange override. if you instead need to use OnStateChange for your logic from a specific indicator or other script, I would suggest looking into other options to find what best matches what you want to do and the overrides you need to use. A window its self would not have a state anyway, that is specific to NinjaScript types, like a Indicator or strategy, an addon would not see any states of other windows, only that it was created or destroyed.

This makes sense, thanks for the clarification.


Regarding the panel, that would be a even more complex item to develop and would depend if you need to just add a general panel to all charts or if that panel needed to do something specific like control a strategy, based on its use you could decide on what type of script to use.

This could be a panel in a chart or a new window, that would be up to you and would depend on its usage but again this would be a general WPF concept and not specific to NinjaTrader. The only specific portion of this to NInjaTrader would be where you execute the code that creates the panel/window and how you locate the place in the platform to create the object.

This makes sense, thanks for the clarification. I could create a new window from the AddOn and pass a reference to the active chart control to it. I could then wire up event handlers to that, kind of like the Data Box works. I think that would be the best approach, as then it will not interfere with any other Add On's or the Chart Trader.

Lets say I want to do something in my Add On, OnBarUpdate. The ChartControl does not expose an OnBarUpdate event, but I could develop a strategy or indicator and create a public event that I raised from OnBarUpdate in that. But the strategy or indicator I created to do this, would have no purpose outside the add on, so is there a flag I can set to have it not show up in the list of strategies/indicators, so I just create it from the Add on and the end user can't try and use it on it's own.

Thanks for your advise Jesse, much appreciated.

Regards,

Scott

[neoikon]

I have created a sample that adds a button to the Toolbar, it also removes that button and handler on window closed.

Thank you for this great example! Is there a way to make this AddOn object appear in the Hot Keys interface (the way that custom drawing tools automatically do, etc)?

Thanks!

[NinjaTrader_Jesse]

Hello,

Thank you for the question.

Currently I believe this is handled internally, I have put a question in for further clarification on this subject to see if a custom NinjaScript item has the possibility of being appended to the hotkey manager.

If not, likely you would need subscribe to the PreviewKey events to check for your own hotkeys.

Once I have further information I will reply back.

[neoikon]

Hello,
Currently I believe this is handled internally, I have put a question in for further clarification on this subject to see if a custom NinjaScript item has the possibility of being appended to the hotkey manager.

If not, likely you would need subscribe to the PreviewKey events to check for your own hotkeys.

I was hoping that it would appear in the Hot Key manager automatically (like the custom drawing tools), but I'm not seeing it. Perhaps I don't know the category/section to look for within the Hot Key manager?

Thanks again!

[NinjaTrader_Jesse]

Hello,

I have received a note back on this from development, it is currently not possible for a NinjaScript addon to appear in that menu for hotkeys but they have put in a feature request for this so it is now documented.

For the current time, any key events would need to be handled by either the hotkey manager for items that are already supported or you would need to add keyboard handling to your script for other types of keyboard input.

I look forward to being of further assistance.

[neoikon]

I have received a note back on this from development, it is currently not possible for a NinjaScript object to appear in that menu for hotkeys

Thank you for the update! That's unfortunate, but hopefully there is a change in the future.

Just to be clear, I've made a handful of custom, ninjascript drawing tools and they do appear in the Hot Key Manager (just not the AddOns).