Example AddOn with Multiple Different Tabs?

[jeronymite]

Is there an example AddOn that demonstrates how to create an AddOn with multiple different tabs? Or can anyone advise on this, please?

The goal is to have a window with one or more initial different tabs and allow new tabs to be added that are selected from the "+" button in the tabs field. One would also want to be able to edit the tabs available for creation to avoid duplication of specific (but not all) tabs.

The examples already available create a single tab only, and adding a tab merely duplicates the single tab.

Assistance most gratefully received. Thanks!

[NinjaTrader_Jesse]

Hello jeronymite
,
The Addon Sample Basic listed in the help guide is a multi-tab example:

https://ninjatrader.com/support/helpGuides/nt8/addon_development_overview.htm

The tab function is provided by the structure of the addon,

In the file you can see a few classes being used, the point of interest for tabs would be how the AddOnFrameworkWindowFactory class is created from the AddOnFrameworkWindow class and then TabControlManager.SetFactory is used to define what generates the tabs.

The AddOnFrameworkWindowFactory class is a simple interface that returns new windows or tabs when requested. You can then specify a type to return which is the tab class AddOnFrameworkTab.

The help guide sample is targeted for multi instrument use similar to the rest of the tools in the platform, if you follow that design pattern you can use the NinjaScript addon interfaces for instrument subscription and other addon related tasks shown in that sample.


I look forward to being of further assistance.

[jeronymite]

Thanks, Jesse.

In a separate post (https://ninjatrader.com/support/foru...ror-in-vs-2017), you will see I have been looking closely at that Basic example and the Visual Studio example.

It is not clear how one should create/modify a popup list of tab types to choose from when the "+" is clicked. Neither is it clear how to create more than one different tab type from the one factory. It seems there must be separate factories for each tab type? If so, how do they integrate into the code?

For example, if I want the initial tab to be a UI to a general set of functions, but with the ability to use "+" to choose from a list of tabs to open individual different functional tabs, how is that done?

Many thanks for your kind assistance!

[NinjaTrader_Jesse]

Hello jeronymite,

It is not clear how one should create/modify a popup list of tab types to choose from when the "+" is clicked.

Thanks for the clarification, I was not able to take this question specifically from your original post. This is not something which is currently shown in any example as this would rely on some of your C# knowledge to accomplish. I have added a sample of a multi tab addon which uses the context menu + to display tabs and then uses the factory to switch types.

The main points to take away from this sample:

1. There is not a method that I am aware of to access the + menu so you need to override it yourself and create it.
2. The tab factory is already set up in a way which it gets a parameter however that relies on you overriding the + menu.
3. This has to be done after the tab loads because the + button is part of the WPF template.

Here is the actual code for overriding the + which is very simple:

NTMenuItem addTabMenuItem = Utilities.FindVisualChild<NTMenuItem>(tc, "PART_AddTabMenuItem");

NTMenuItem newMenuItem = new NTMenuItem()
{
    Header = "Tab Type 1",
    Style = Application.Current.TryFindResource("TabControlMenuItem") as Style,
    Command = TabControlCommands.AddTab,
    CommandParameter = typeof(AddOnFrameworkTabOne) // you could pass anything, this is the typeName parameter
};   

NTMenuItem newMenuItem2 = new NTMenuItem()
{
    Header = "Tab Type 2",
    Style = Application.Current.TryFindResource("TabControlMenuItem") as Style,
    Command = TabControlCommands.AddTab,
    CommandParameter = typeof(AddOnFrameworkTabTwo) // you could pass anything, this is the typeName parameter
};

addTabMenuItem.Command = null;
addTabMenuItem.Items.Add(newMenuItem);
addTabMenuItem.Items.Add(newMenuItem2);

I look forward to being of further assistance.

[jeronymite]

Many thanks, Jesse. Very helpful!

A further question: In an AddOn, how does one declare global variables? I know it seems a trivial question, and perhaps it's a more C# question, but if I want global variables available in several class declarations and their methods, how might I do that?

I'm trying to integrate existing complex strategies into an AddOn.

Thanks!

[NinjaTrader_Jesse]

Hello jeronymite,

Yes this is going to lean more on general C# structure and how C# works. Global variables really depend on the type of design you want to do and the purpose of the variable/complexity of the variable. This could involve using a passed in object when the object that requires the variables is created, it could also include partial or static classes.

The long answer here would be that I would suggest brushing up on some of the C# OOP fundamentals. What I mean is to review general C# class design, static class design and partial class design along with Passing objects. Understanding these areas of C# and how they can be leveraged will help greatly with addons.

For a more simple answer I would likely need to know what part of your addon needs to use the variable and if that is something which is only read or needs to also be set from each class.

A static class could likely be used here however I often suggest avoiding that design pattern if possible. Static could be used in a variety of areas as an easy way to accomplish a task but without a good understanding of static you can also really cause yourself a headache. If you just need to expose a constant value that classes need to read that is a good use case for static.


I look forward to being of further assistance.

[jeronymite]

Really appreciate your continuing assistance, Jesse!

I have created some very complex strategies that perform tasks that, essentially, I want to encapsulate in an AddOn. This would allow the extra functionality of the AddOn to be used to offer greater flexibility and range of use of those strategies and the extensive UI within which they are offered.

I need to be able to access variables in the Strategies namespace for read/write throughout the AddOn, or bring the strategies themselves into the AddOn, but with the same availability of those variables throughout the entire AddOn. Going static throughout is not really an option. There are many hundreds of variables, ranging from int to complex classes.

I suppose the best way to summarise is to say I need full read/write access (in all forms, static and non-static) to my Strategies namespace from the AddOn namespace.

I hope that helps.

Thanks!

[NinjaTrader_Jesse]

Hello jeronymite,

I'm not clear on the scope of what your addon is trying to do. Are you trying to access running instances of strategies and get/set variables?

I was under the impression that by global variables you meant that you were trying to define some form of constants for the strategies to read or use, are you trying to do the reverse and make variables in each strategy that the addon can read?

Could you provide a simplistic explanation of what your addon is trying to do in relation to the strategies and global variables?


I look forward to being of further assistance.

[jeronymite]

Thanks, Jesse. And apologies for any confusion.

In NT7, I developed strategies with an extensive, single integrated UI. I am now migrating these strategies and UI to NT8 and want to be able to execute the strategies and the UI from within the context of an AddOn, but with additional features and functionality that are only available in AddOns. I want to understand if I can execute the migrated strategies code (approx 80K lines) within the AddOn but in situ (i.e. within the Strategies namespace) or will it need somehow to be moved into the AddOns namespace. (I understand the migration requires WPF vs WinForms and many other adjustments, but that is a given of the migration. I have already successfully migrated a significant amount of non-UI code, but within the Strategies namespace only.)

So, for example, I have a large number of internal constants and read/write variables (from int to complex classes, static and non-static) and many methods that can be used by all methods of the strategies and the UI. They all exist within the Strategies namespace.

The AddOn will provide the existing, but much enhanced, UI capabilities (using new available-in-AddOn-only functions), and I want to be able to perform the functions of the strategies in the AddOn. Essentially, I am upgrading from a strategy-based approach to an AddOn-based approach for the same, but much enhanced, activities and capabilities.

One of the aspects of the UI is that it has several windows with some windows having multiple tabs, all of which are "global" in nature, meaning that whatever is done or set in any window/tab is able to be seen/used in any other window/tab. It is one coherent execution environment.

I hope this makes sense.

Thanks again for your much appreciated assistance!

[NinjaTrader_Jesse]

Hello jeronymite,

Thanks for the added details.

I believe this part of your reply is the most important:

The AddOn will provide the existing, but much enhanced, UI capabilities (using new available-in-AddOn-only functions), and I want to be able to perform the functions of the strategies in the AddOn. Essentially, I am upgrading from a strategy-based approach to an AddOn-based approach for the same, but much enhanced, activities and capabilities.

It sounds like you intend to upgrade all of the existing strategy based logic to the addon approach so I believe that will be an important factor to keep in mind here. If you specifically don't need to use Strategy type, you don't need backtesting or the isolated trade performance etc. and intend on using a Addon completely then it would be important to avoid using the term strategy at all as that can lead to confusing feedback in this area.

From the description it sounds like you intend to create an order entry tool window that applies logic to orders that it submits or manages. If that is an accurate description I believe what you detailed about the existing constants and other structures you made can likely just be put in the addon namespace. The only major changes I could see here would be if you are dealing with specific Strategy base properties like the trade performance collections or a Strategy instance. If you are passing strategy specific types or other strategy specific logic in the structures you made you will have to update those to addon ways of doing that task.

Now that I have further clarification lets revisit your question:

I need to be able to access variables in the Strategies namespace for read/write throughout the AddOn, or bring the strategies themselves into the AddOn, but with the same availability of those variables throughout the entire AddOn. Going static throughout is not really an option. There are many hundreds of variables, ranging from int to complex classes.

Very likely you need to just move your existing structures and constants to the addon namespace. If you are not specifically going to be interacting with a strategy instance in some way we can avoid using the term strategy here and also avoid using the strategy namespace. What you have now will need rebuilt by the sounds of it so I would suggest to slowly bring over your structures into the addon namespace and make sure they all make sense before moving past this part. You can consider the addon and its classes as your strategy now and would have to incorporate how you used those structures in that context.

I look forward to being of further assistance.

[jeronymite]

Many thanks, as always, Jesse. This is very helpful.

I can move to the AddOns space for many things, I'm sure. I do not envisage running Strategy instances from the AddOn. Rather, I will try to do all the things that are currently done in the Strategies space from an AddOn. I say "from an AddOn", as I may not be able to do everything directly from within the AddOn space, as you note some exceptions.

My concerns are about the multitude of global instance variables and methods (not just constants and classes) that are not encapsulated within classes (other than the NT7 Strategy class itself). Also, you mention trade performance information. Since I will be submitting and managing trades from the AddOn, I must be able to monitor trade performance in real-time. There may be other areas too, but that is something I will have to examine as I migrate.

I can make many methods/variables static, but some are "more logically" instances, for example, per trade/order. I want to have methods/variables that are "globally visible/callable/modifiable" in all classes/methods in the AddOn. The current AddOn structure, from what I can tell, does not allow declarations of methods/variables outside of the classes it declares. In the Strategies space, this is allowed, presumably as it is a partial class. In the AddOn space, is there a way to declare such methods/variables in a partial class (or other form) that would make this "global visibility/callability/modifiability" possible?

You mention "AddOn ways of doing things" vs the strategy ways. It seems I am "bumping up against" those differences. Is there a summary of the major differences and equivalent alternative ways of doing things?

The one thing I notice that presents the most obvious change is that in the AddOns space, all things are encapsulated within classes. So, for example, if I have a multitude of methods, I would have to encapsulate them as static methods in a class, and then invoke them from that class, I presume. This is quite different from the NT7 Strategy approach.

I will also have multiple windows, each potentially with multiple different types of tabs. These need to form a single, coherent, "globally transparent" execution environment. In other words, if I change something in a tab in one window, I must be able to "see" that change anywhere else, and possibly change the same thing from anywhere else.

I hope this makes sense. I'm happy to adopt and adapt to the AddOns way of doing things, so long as I understand what that is, and as long as it can achieve the current functionality I have, and of course, the extended functionality that only AddOns provide. If I need to use a "hybrid" approach of AddOn with "callouts" to other spaces, I would need to understand that before trying to "force a square peg into a round hole".

Thanks again for your kind assistance, Jesse. (If a support call would be useful, please let me know so we can arrange one. Many thanks!)

[NinjaTrader_Jesse]

Hello jeronymite,

My concerns are about the multitude of global instance variables and methods (not just constants and classes) that are not encapsulated within classes (other than the NT7 Strategy class itself).

I would suggest to put this concern on pause for the time being.

Previously when using strategies you were working with multiple instances so you needed some separation of code. You also needed that code visible in multiple areas. Now that you are working in an Addon you have 1 central location that runs all the code.

When you say you need global variables and shared methods in this context that sounds to me like the existing structures and design does not fit with what you are creating. You may need to rethink your design pattern here because you are not working with more than 1 instance now so making things global or shared is not really needed at all.

Also, you mention trade performance information. Since I will be submitting and managing trades from the AddOn, I must be able to monitor trade performance in real-time. There may be other areas too, but that is something I will have to examine as I migrate.

For performance and other account related items I would suggest looking at the addon sample we provide. That demonstrates attaching to the account and viewing values and changes along with submitting and managing orders/retrieving orders. When working in the addon you have to remember the convenience items the strategy provided are no longer there, you now get to design everything and how you want it to work. If you need trade performance I would suggest searching the forums for suggestions on how to approach that, one way would be to create your own trade collection: https://ninjatrader.com/support/foru...407#post844407

I can make many methods/variables static, but some are "more logically" instances, for example, per trade/order. I want to have methods/variables that are "globally visible/callable/modifiable" in all classes/methods in the AddOn. The current AddOn structure, from what I can tell, does not allow declarations of methods/variables outside of the classes it declares. In the Strategies space, this is allowed, presumably as it is a partial class. In the AddOn space, is there a way to declare such methods/variables in a partial class (or other form) that would make this "global visibility/callability/modifiability" possible?

I believe there is still some confusion here revolving around strategies, also please ignore my prior comments related to partial/static as that no longer applies here.

You are now working with an addon so you can completely ignore strategies, that namespace and that portion of the help guide. The addons have their own section of the help guide and their own namespace and they work separately from strategies.

If you are looking at the addon sample in the help guide: https://ninjatrader.com/support/help...t_overview.htm
Your code needs to be structured like that. If you need another class for something, make another class and put it in the same namespace. It can be in the same file or not, it really doesn't matter because we are using C# and using specific namespaces.

You mention "AddOn ways of doing things" vs the strategy ways. It seems I am "bumping up against" those differences. Is there a summary of the major differences and equivalent alternative ways of doing things?

There is not a comparison as they are not similar, this is more like Indicator VS strategy or BarsType vs Strategy, they are completely different types with different use cases. Addons are tools which let you create it however you want to. That could include a window or not, that can modify other windows or run in the background, really the possibilities are endless.

A strategy is a very specific type that does specific actions and can be used in specific tools like the strategy analyzer. The strategies purpose is to isolate trade performance and execute a task. Your addon does not have that requirement and does not utilize strategy syntax to accomplish its tasks, you can see the separation in the help guide sections:

https://ninjatrader.com/support/helpGuides/nt8/strategy.htm

https://ninjatrader.com/support/helpGuides/nt8/add_on.htm

Addons have a lot of objects with sub properties and methods, for example in an addon to submit an order you also need to find an account so you would need to navigate to the Addon -> Account sample to do that part, then navigate to the Addon -> Account -> Submit() page for an example of using that found account to submit an order.

The one thing I notice that presents the most obvious change is that in the AddOns space, all things are encapsulated within classes. So, for example, if I have a multitude of methods, I would have to encapsulate them as static methods in a class, and then invoke them from that class, I presume. This is quite different from the NT7 Strategy approach.

The addon is just using C# structure which involves multiple classes, those different parts are all being called from somewhere in other parts of the addons code.

If you had a multitude of methods you very likely just need to make a class that has them and then create an instance of that class which your addon uses. Again this is a C# concept here which will hinge on your C# education. For this aspect of your addon I highly suggest to seek external education for C# OOP design patterns, C# structure design, C# passing objects, C# inheritance. These concepts will be critical in moving forward and not running into a lot of roadblocks.

I will also have multiple windows, each potentially with multiple different types of tabs. These need to form a single, coherent, "globally transparent" execution environment. In other words, if I change something in a tab in one window, I must be able to "see" that change anywhere else, and possibly change the same thing from anywhere else.

This again will hinge on your C# education and how you design your addons structure, really all I can suggest here is to continue educating yourself on C# design patterns to better understand how you can leverage the object oriented nature of C#. The addon sample is the base framework which is a working sample, how you expand on that structure is up to you and your C# knowledge.

For the tabs we previously discussed this over in the topic: https://ninjatrader.com/support/foru...different-tabs


I look forward to being of further assistance.

[jeronymite]

Many thanks yet again, Jesse. I very much appreciate the time and effort you have put into responding to me!

I will take some time to work on all the things we have discussed. As I progress, I will almost certainly have more questions, but for now, I will get on with the doing of things and see what happens.

Again, my sincere thanks.

[jeronymite]

Hi Jesse. You have already kindly provided an example of creating an AddOn window that can create different tab types. Thanks.

May I ask for an example where a tab in an AddOn window can create another new AddOn window (not a new tab in the same window) where that new window may have a completely different set of tabs, please. And if the example could demonstrate accessing objects from one window in another window, that would be helpful too.

Generally, there may be multiple different AddOn windows that can be created from within a single AddOn execution, just as there may be multiple different tabs created within a single AddOn window.

Many thanks!

[NinjaTrader_Jesse]

Hello jeronymite,

You already have the code for that in your addon, you would just need to call the same code which you call now which is in the control center menu items event:

Core.Globals.RandomDispatcher.BeginInvoke(new Action(() => new AddOnFrameworkWindow().Show()));

If you needed it to do something different this time like open a different default tab can do that in a few ways. If you want to use the existing addon and its tabs you need to structure your addon to accept parameters. You are creating a new window and showing it so If you want options for that you could use its constructor or public properties while creating it.

A simple way to do this would be to pass a parameter in the constructor, the path to that would be: new AddOnFrameworkWindow(someParameter).Show() which then goes to its constructor where it sets the default tab. That also involves changing the window factory class to support that because it also uses the AddOnFrameworkWindow.

You could also create a new separate window class that has a different set of tabs. You would just use the code above to create a new instance of that window just like you control center menu item created an instance of your first window.

If they need to share data in some way you would also need to structure them in that way to pass the data or use a common data class such as a static class.



I look forward to being of further assistance.