F5 -- how can I make that happen?

[koganam]

I note that you use the word "plot" in the singular, and talk of PlotsConfigurable, which is an all-or-nothing setting.

Well, I was demonstrating a concept to find out where we are talking at cross-purposes, it would seem. So there is only one plot in the sample.

[ETFVoyageur]

OK, I looked at the sample, and it is pretty much what we have talked about. You are right to point out that I have been assuming displaying the traditional plot configuration. Yes, you can reduce it to just the F5 problem if you are willing to provide an alternate configuration for each of the lines.

That is a mouthful. You need to provide color, dash style, plot style, and width for at least 3 lines: the moving average, inner band lines and outer band lines, for a total of 12 configuration entries. That is a lot of configuration real estate in a configuration that is already pretty big, and it is not the NT-standard way to configure how plot lines look.

The non-standard part does bother me -- people expect, and should be entitled to, a consistent GUI and this breaks that. From a usability point of view, GUI consistency is a Big Deal.

Adding those 12 parameters would make the configuration dialog almost full height (unscrolled) on my 23" monitor! I'd also have to think about how I could set it up so that it would not be confusing to the user, but I'm confident that something can be found.

Still, I agree that it can be done and it avoids the need to know when the Indicators dialog goes up and down. To me it is a pretty undesirable work-around for an architectural problem.

Of course that still leaves us with the F5 problem. The last I was aware, the NT people considered it dangerous and something they do not want to see. We need to get past that for this to work well.

-- Bob

[koganam]

(The non-standard part does bother me -- people expect, and should be entitled to, a consistent GUI and this breaks that.)

It is not an all or nothing proposition. The problem as I understood it was to retain knowledge of the user colors, but be able to control the plot color. There is nothing to prevent showing the plots (again, the ubiquitous PlotsConfigurable), and retaining the user selected colors, in the relevant section. This is especially true is you are NOT also trying to retain the style of the plots, just the color.

You get the best of both worlds. You can see what the user configures for color, and you can feedback where you have turned off the plot because that is what the indicator paradigm calls for. Incidentally, for me once I made the MovAvgType to be None, the plot disappeared from the DataBox. No need to even refresh manually.

Actually we also have a philosophical difference about the GUI presentation. I can find qute a few reasons why an indicator writer may not want Plots to be changed. It would appear that NT thinks so too, which is why they gave us PlotsConfigurable in the first place?

[ETFVoyageur]

> The problem as I understood it was to retain knowledge of the user colors, but be able to control the plot color.

No, the problem was for the plot configuration on the dialog to show the user's color, even though the actual plot may be transparent when the dialog is down. This problem goes away if I keep the plots out of the configuration dialog and just put in explicit value fields. That is a waste of valuable space and a violation of GUI consistency, but given the architecture we have to work with may be the best choice available.

> There is nothing to prevent showing the plots (again, the ubiquitous PlotsConfigurable), and retaining the user selected colors, in the relevant section.

Having plot configuration split into two places is not attractive. If the plot is showing, it should be the correct color and setting it should get the job done. There is no way for the object to set the plot color in the configuration dialog -- as far as I know it is irretrievably what the plot's current actual color is. For the reasons discussed elsewhere in the message, I am leaning towards just setting PlotsConfigurable=false and living with the (ugly) result.

> This is especially true is you are NOT also trying to retain the style of the plots, just the color.

But we are trying to retain the styles -- it is valuable to set the style, width, etc for the moving average. One could argue less so for the band edges, but I am not sure. Will people with worse eyesight want those edges wider? Could be.

> You get the best of both worlds. You can see what the user configures for color, and you can feedback where you have turned off the plot because that is what the indicator paradigm calls for.

That feedback would be valuable only if it matched the user's current configuration choices elsewhere in the dialog (whether or not the bands are enabled). Otherwise it is misleading, confusing, or both. I have turned in a feature request asking for support for more dynamic configuration.

> Actually we also have a philosophical difference about the GUI presentation. I can find qute a few reasons why an indicator writer may not want Plots to be changed. It would appear that NT thinks so too, which is why they gave us PlotsConfigurable in the first place?

You lost me on that remark.

---------

I just noted another problem with having to control the Data Box indirectly. The plot label in the indicator box is taken from the plot's actual name. That is a problem. The name reflects the user's last choice, because that is what is needed to get it to show in the Data Box. Unfortunately, it may not be right in the current configuration dialog. In the configuration dialog it needs to either be a permanent neutral constant value, such as "Indicator line", or else it needs to dynamically match the user's choice from the enum variable above. Unfortunately, neither is possible.

This dealing with the data box is so ugly, because you cannot deal directly with it, that I am tempted to can the plots ever being displayed in the configuration dialog and go to the non-standard GUI plot configuration as the lesser of two evils. At least that will also get rid of the interactions / side effects and worrying about when the Indicators dialog goes up and down.

Brett (or whoever else is listening) -- you need to get your architectural person to get rid of all of this side-effects and interactions crap. It is bad design. For starters, we need to be able to interact with the Data Box directly and not try to control it with side effects (Computer Science 101 -- the issue is coupling, which is generally a Bad Thing). For another, the idea that the plot's name is used for both the Data Box label and the plot label in the Indicators dialog is just plain crazy -- the two uses are NOT the same, so making one value serve both is poor design (even if most of the time no harm is done). Once again, an issue of undesirable coupling.

--EV

[koganam]

>
No, the problem was for the plot configuration on the dialog to show the user's color, even though the actual plot may be transparent when the dialog is down. This problem goes away if I keep the plots out of the configuration dialog and just put in explicit value fields.

I must still be lost somehow. Why would you be hiding the plot if the user has specifically configured it? I thought the idea was to hide that which was not configured. I would have thought that if the plot is not needed (hence you set its color transparent), what is the need to bother with any configuration at all.

Having plot configuration split into two places is not attractive.

Second thoughts have me agreeing with you there. It is rather kludgy.

> Actually we also have a philosophical difference about the GUI presentation. I can find qute a few reasons why an indicator writer may not want Plots to be changed. It would appear that NT thinks so too, which is why they gave us PlotsConfigurable in the first place?

You lost me on that remark.

I was talking about the question of capturing Plot configuration in a place other than where it is in the so-called standard position.

I just noted another problem with having to control the Data Box indirectly. The plot label in the indicator box is taken from the plot's actual name. That is a problem. The name reflects the user's last choice, because that is what is needed to get it to show in the Data Box.

Brett (or whoever else is listening) -- you need to get your architectural person to get rid of all of this side-effects and interactions crap. It is bad design. For starters, we need to be able to interact with the Data Box directly and not try to control it with side effects (Computer Science 101 -- the issue is coupling, which is generally a Bad Thing). For another, the idea that the plot's name is used for both the Data Box label and the plot label in the Indicators dialog is just plain crazy -- the two uses are NOT the same, so making one value serve both is poor design (even if most of the time no harm is done). Once again, an issue of undesirable coupling.

They seem to be treating the DataBox as a read-only reflector, rather than as an object.

[ETFVoyageur]

OK -- here is my summary of all this discussion, and what I have done

• I decided that the problems with Data Box, Plot settings (name and transparency) and the Indicators dialog are intractable. There are fundamental design problems in that area having to do with side effects, unwanted coupling, and the software being unaware of when the dialog box comes and goes. After extensive discussion, it is clear that there is nothing I can do to work around those problems.

• The only other thing to do is to avoid the need to deal with those things. I have done so. I no longer show plots in the Indicators dialog; instead, I have a streamlined version of setting the plot parameters that need to be under user control. (My thanks to koganam for helping me to realize that this is the only realistic way to go.)

• Although there are issues with when Data Box will recognize the plot name and transparency, I have gone ahead and set them in OnStartUp() anyway. Data Box will eventually see them (subsequent Indicators dialog that is dismissed with OK or Apply, user-given F5, or new copy of Data Box brought up). In the meantime, users who know and care will just have to give F5 manually. (Note that this is an issue only immediately after the user changes the type of moving average in use, disables a band, or enables a band.)

I do not really like configuring the moving average line in this non-standard way, because GUI consistency is a Big Deal, and this way does not follow the NT GUI convention / standard. In the end, however, I decided that this is the only realistic way to do it in the current system.

I would like to programmatically poke Data Box so the values get updated right away. The only way I know to do that is to SendKeys F5. I have not done so because of two problems:

• I would have to figure out how to prevent an infinite loop. I am willing to do that, but not until the next point has been resolved.

• NinjaTrader folks believe that doing so would be dangerous and against their policy, because it risks generating unwanted trades as strategies get disabled and re-enabled.

Frankly, this does not make sense to me. The same thing happens if the user gives the F5 manually. Granted that the user chooses to give the F5, and knows he is doing so, but I think you are asking an awful lot of a user to think about a refresh possibly generating an unwanted trade. If that is a real possibility, then IMHO there is some system architecture redesign that needs to happen.

I would appreciate it if someone would confirm/deny that this indicator giving an F5 programmatically is indeed a serous risk, and one that NT believes should not happen.

-- EV

[NinjaTrader_Brett]

Hello,

NinjaTrader is simply not designed with this idea in place for your specific indicator design/ integration with the data box. The Data Box in its current form is a read only and only displays plots you designate. It is something that is on our suggestion list however. This is the reason for the unsupported response I gave when you first brought this up to me as its simply not supported.

Instead of going through all the extra coding and workaround to get multiple / user customizable plots to work. Heres what I suggest. Maybe once your done with the strategy code you make 2, 3, or 4 versions of the indicator each with there own number of plots. This way the user can choose how many plots they want by choosing which indicator they load. This is a supported method of this in NinjaTrader since NinjaTrader does not support dynamic setting of Plots, They must be hard coded.

Any action you take to get around such unsupported methods of not hard coding the plots you take at your own risk. I cannot confirm or deny that this will cause risk or any issues as pragmatically pressing the F5 key, though it should work is something that we dont officially support or cannot guarantee we will make any changes here that will cause this to no longer work.


Let me know if I can be of further assistance.

[ETFVoyageur]

Hello,

NinjaTrader is simply not designed with this idea in place for your specific indicator design/ integration with the data box. The Data Box in its current form is a read only and only displays plots you designate. It is something that is on our suggestion list however. This is the reason for the unsupported response I gave when you first brought this up to me as its simply not supported.

Instead of going through all the extra coding and workaround to get multiple / user customizable plots to work. Heres what I suggest. Maybe once your done with the strategy code you make 2, 3, or 4 versions of the indicator each with there own number of plots. This way the user can choose how many plots they want by choosing which indicator they load. This is a supported method of this in NinjaTrader since NinjaTrader does not support dynamic setting of Plots, They must be hard coded.

Any action you take to get around such unsupported methods of not hard coding the plots you take at your own risk. I cannot confirm or deny that this will cause risk or any issues as pragmatically pressing the F5 key, though it should work is something that we dont officially support or cannot guarantee we will make any changes here that will cause this to no longer work.


Let me know if I can be of further assistance.

Brett,

Thanks for the comments. I have stated what actions I have taken, and why. I am no longer going to a lot of work to get around anything. The current version of the indicator is actually pretty streamlined. It is simpler and less work than the old way.

Furthermore, my current way of handling the situation actually removed unsupported code -- the old way required saving and restoring the user's colors, which there is no supported way to do. My new way does not require that. As far as I know, I no longer have any unsupported code in the indicator.

Multiple indicators is not an option in my mind -- the point of the indicator is flexibility and multiple hard coded indicators is antithetical to that. They are bad for the user, and they would be a code maintenance nightmare.

Integration with the Data Box -- all I am trying to do is to get it to show reality. It seems obvious to me that there is a bug (possibly a design bug) when Data Box shows one thing, and after a refresh shows something else.

The only remaining issue in my mind is whether or not to programmatically generate an F5. Everything else works well now. Unless there is some confirmation that generating an F5 would cause a problem for anyone, I'll look into doing that -- but not right now -- I'll give it a rest for a day or so first.

--EV

[NinjaTrader_Brett]

Sounds good. Happy Programming and Trading!

Let me know if I can be of further assistance.

[koganam]

... I have a streamlined version of setting the plot parameters that need to be under user control. (My thanks to koganam for helping me to realize that this is the only realistic way to go.)

Unfortunately, much as we hate it, we sometimes have to break our own coding rules, in order to fit into a predesigned framework. In that case, we MUST document for ourselves, at any rate, why we broke the rules. That, you have evidently done. There is little more that you can do other than to suggest to the developers that the framework design may have some flaws. That you have also done.

All in all, you have done everything that could possibly be done. And educated me to boot. Thanks.

[ETFVoyageur]

All in all, you have done everything that could possibly be done. And educated me to boot. Thanks.

Thanks for the kind words.

-- EV