ExpandableObjectConverter not working with Stroke Property

[NinjaTrader_ChelseaB]

Hello caryc123,

I've added your vote to SFT-5079.

"Is there a method or similar functionality that can be used to programmatically flag the indicators dialog as dirty so the Apply button becomes active?"

The Apply button only becomes enabled if a user manually makes a change to a property of a configured script in a property window such as the Indicators or Strategies window.

[caryc123]

Thanks Chelsea. Please also create a feature request or similar tracking item for the noted "force dirty" logic. That one should be easy to knock out.

[NinjaTrader_ChelseaB]

Hello caryc123,

What is the use case of this?

You can change properties in run-time from code without opening the UI properties window.

You can reload a script by right-clicking a chart and selecting Reload NinjaScript.

Why is making the Apply button enabled necessary?

[caryc123]

Hi Chelsea.

I’m aware user properties can be changed at runtime with or without the indicators dialog open and aware the active script can be programmatically reloaded. The issue is with indicators that have user properties organized into multiple levels of nested groups (for ease of use in the indicators dialog and for better alignment with class organization/hierarchy). For example, implementing a user property that is bound to an expandable class/type (decorated with [TypeConverter(typeof(ExpandableObjectConverter))]) which in turn has one or more levels of expandable properties that are based on simple data types (e.g. int, double, string, bool, etc.) works fine, however when one of the properties is a non-simple type (e.g. Brush/Color, Stroke, etc.) and is at the second level or deeper, its property change events don’t fully bubble up and/or cause the Apply button to become active after an associated value changes. The feature request that started this thread/topic relates to what I just explained, which I suspect will be quite a bit of work for your programmers (but immensely helpful), hence my second likely quicker-to-implement feature request.

The user case for the second feature request (enabling a means to mark the indicators dialog as dirty and thus trigger the Apply button to become enabled) is as a hack solution for compensating for lack of the first feature (e.g. if the Apply button doesn’t become enabled for changes to certain nested expander properties, then execute the hack). Other scenarios include out-of-band processes that are not related to user properties (in the indicators dialog) that want to notify the user the indicators dialog has changed without their explicit action). This out-of-band capability will become more important as more automation becomes the norm.

Thanks,
-Cary

[NinjaTrader_ChelseaB]

Hello Cary,

Thank you for clarifying this.

I've submitted your request for consideration.

[caryc123]

Thank you!