How to disable drawing a line from the Lines[] array

[ETFVoyageur]

I want the user to be able to enable/disable one of the lines in the Lines[] array. How can I dynamically control whether or not that line gets drawn?

Things like coloring it transparent or removing it from the Lines[] array have occurred to me. I'm just hoping there is some straightforward direct control over whether or not it gets drawn.

Thanks,
EV

[NinjaTrader_CalH]

Hello EV,

You have the right method to hide the Line. Doing Transparent will get you the results that you more likely looking for.

[ETFVoyageur]

I have LinesConfigurable=true set. I am worried about scenarios like:

• User disables the line
• I save the current color, and set the color to transparent
• The user then configures the line
  • Configuration will show transparent, not the color the user thinks it is. This is a usability issue.
  • If the user changes the color, then it will no longer be hidden. You can argue that he gets what he asked for though
  
  
• The user then re-enables the line
• I restore the (by now wrong) color for the line

That's just one scenario. Basically, setting the line transparent seems like a huge hack that is likely to not work very well. It is true that a transparent line will not be visible, but I am worried about usability issues such as the above.

The reason I want to be able to leave the line's configuration alone and just enable/disable drawing it is that will be much more robust than the transparent hack. Isn't there some way I can do that? If I cannot do that, can I gray out the line so that the user cannot reconfigure it while hidden?

Is there some reason that my misgivings are misguided?

--EV

[NinjaTrader_CalH]

Hello EV,

You can use the [ReadOnlyAttribute(true)] for the properties of the Line so that the user can not configure it

[ETFVoyageur]

Hello EV,

You can use the [ReadOnlyAttribute(true)] for the properties of the Line so that the user can not configure it

That might be workable. How do I do that?

--EV

[NinjaTrader_CalH]

EV,

After rethinking this, the ReadOnlyAttribute may not be the solution for you.

If you are looking for only have certain items configurable by the user then what you want to do is set the PlotsConfigurable to false and then create public variables for say color and then pass those through the Plot Class in the Initialize section.

[ETFVoyageur]

EV,

After rethinking this, the ReadOnlyAttribute may not be the solution for you.

If you are looking for only have certain items configurable by the user then what you want to do is set the PlotsConfigurable to false and then create public variables for say color and then pass those through the Plot Class in the Initialize section.

I'm still not following you. I do not understand "certain items configurable by the user". All I want is some workable way to enable/prevent displaying two of my three Lines at run time. (Lines, not Plots, if that matters.)

Are you suggesting that I create ordinary properties for all 4 line attributes (Color, Dash style, Value, Width) for each of my three lines? If I do that, is there any way to get the "+" button effect that the built-in Line configuration has? If not, the resulting display will be bulky and non-standard.

BTW: the changing will not be in the Initialize() method -- it will be in the "set" method of the property the user changes to make this needed.

--EV

[NinjaTrader_CalH]

EV,

You would need to create your own logic and then set the Lines[0].Pen.Color = Color.Transparent;

[ETFVoyageur]

Is there any way to get the "+" effect that the built-in lines configuration has?

--EV

[koganam]

Is there any way to get the "+" effect that the built-in lines configuration has?

--EV

To do that you will have to create a class that holds the properties. Inside that class, make sure that the Properties, have the [NotifyParentPropertyAttribute(true)] applied.

Why use a class to such a trivial purpose? Because you must. Sorry.

ref: http://www.ninjatrader.com/support/f...est#post255995

The example there was a proof of concept for the failure, and does not have all the fancy stuff applied.

[ETFVoyageur]

Mr. K, what are you saying?

I loaded your file ClassPassesWhereStructFails.cs. It compiles fine, When I went to add it to a chart I looked at the parameters -- it just had:

• Label: "FoldingStruct" -- OK
• Value: "Test Struct" -- I guess that is what is expected -- the default ToString()?

There is, however, no "+" sign, and I could not do anything with either the value. or the label. What am I missing here?

I also tried making something similar of my own. I did use a class. It compiled fine, but got a run time error of failure unable to convert the class to itself. Much like your experience, except I was using a class, and it happened at run time instead of compile time.

-----

Question for support: one can obviously create properties with a "+" sign to expand into sub-properties. Proof by example: NT presents Lines and Plots that way. How can I add a property in my custom indicator that works the same way.? That is what I need to do to implement the suggestion you made earlier in this thread.

--EV

[koganam]

Mr. K, what are you saying?

I loaded your file ClassPassesWhereStructFails.cs. It compiles fine, When I went to add it to a chart I looked at the parameters -- it just had:

• Label: "FoldingStruct" -- OK
• Value: "Test Struct" -- I guess that is what is expected -- the default ToString()?

There is, however, no "+" sign, and I could not do anything with either the value. or the label. What am I missing here?

I also tried making something similar of my own. I did use a class. It compiled fine, but got a run time error of failure unable to convert the class to itself. Much like your experience, except I was using a class, and it happened at run time instead of compile time.

-----

Question for support: one can obviously create properties with a "+" sign to expand into sub-properties. Proof by example: NT presents Lines and Plots that way. How can I add a property in my custom indicator that works the same way.? That is what I need to do to implement the suggestion you made earlier in this thread.

--EV

Oops. I did tell you that that was only a proof of failure concept. It was mainly to demonstrate that a struct fails, where a class works, so does not have the other attributes that make things work right. Sorry.

To get a foldable property, you must apply the attribute:

[TypeConverter(typeof(ExpandableObjectConverter))]

to the Property that is exposed in the PropertyGrid. You will also have to override the String() method in the (folding) class that is being used to display the Property.

[ETFVoyageur]

I have been working on my own expandable property from before Mr K's latest posting. I had my own version working -- there were a few quirks to work through, but I figured them out. (See comments in the code for the quirks.)

• Ignore code comments about static initializer not working -- I was back and forth between using a constructor and not. The code I included here here has basic properties that do need the constructor. An earlier version I was working with has properties that had coded get/set to use the initialized values & did not need the constructor. Sorry for the confusion. Initializer works fine.

There is one thing I have been unable to figure out, though, so any help would be appreciated. My class cannot be serialized. I created a fresh class, and then added the following code to it:

 
        #region This is the code I added
        
        // This is the class for the property
        [TypeConverter(typeof(ExpandableObjectConverter))]
        // [Serializable]                                        // Does not seem to matter whether or not this is here
        public class Name
        {
            // Constructor is needed because the static initializers do not seem to be happening
            // Initializing in the constructor works fine
            // If you comment out the constructor, the ToString() returns empty names
            // (as shown in both the indicator panel legend and the configuration property dialog
            public Name() { FirstName="James"; LastName="Buck"; }
            
            private string firstName = "John";                    // Initializer does not work; comment out the constructor to see this
            //[NotifyParentPropertyAttribute(true)]                // No visible effect; cannot serialize either way
            [Description("The person's first name")]
            [DisplayName("\t\t\tEnter first name")]                // Must use [DisplayName] here; [Gui.Design.DisplayName} is ignored
            public string FirstName { get; set; }
            
            private string lastName = "Doe";                    // Initializer does not work; comment out the constructor to see this
            //[NotifyParentPropertyAttribute(true)]                // No visible effect; cannot serialize either way
            [Description("The person's last name")]
            [Gui.Design.DisplayName("\t\tEnter last name")]        // Note that this gets ignored; the label is still "LastName"
            public string LastName { get; set; }
            
            public override string ToString() { return "Name(" + LastName + ", " + FirstName + ")"; }
        }
        
        // This is the expandable property.  It works well, but there are a couple of things to know:
        //
        //    * [DisplayName] has no discernable effect for this property, but [Gui.Design.DisplayName] works fine
        //      Interesting: must use [DisplayName] in the object's properties, but [Gui.Design.Displayname] here
        //      In both cases the wrong ones compile but have no effect in the property grid
        //
        //    * You can use either [Category] or [GridCategory] -- they have different semantics -- but:
        //        * They work fine when combined into another attribute. as below
        //        * The stand-alone version of these atributes is commented out because they produce errors in the Magic Code:
        //            CS0246: The type or namespace name 'Name' could not be found
        private Name _name = new Name();
        [GridCategory("Parameters"), Description("Demonstration of a class as a property")]
        [Gui.Design.DisplayName("Person's Name")]                // Just plain "DisplayName" has no effect
        //[Category("Parameters")]                                // Produces an error in the Magic Code
        //[GridCategory("Parameters")]                            // Produces an error in the Magic Code
        public Name testName
        {
            get { return _name; }
            set { _name = value; }    // Needed for serialization to work
        }
        #endregion

The resulting indicator compiles fine. The problem is that I cannot serialize it! The trace file reports the following

2014-02-15 16:56:47:919 ERROR: Failed to set property 'testName' for indicator 'DemoClassAsProperty': Object of type 'NinjaTrader.Indicator.DemoClassAsProperty+Name' cannot be converted to type 'NinjaTrader.Indicator.DemoClassAsProperty+Name'.
2014-02-15 16:57:07:552 Gui.Chart.ChartControl.SaveToXml: indicator=NinjaTrader.Indicator.DemoClassAsPropert y: System.InvalidOperationException: Unable to generate a temporary class (result=1).
error CS0572: 'Name': cannot reference a type through an expression; try 'NinjaTrader.Indicator.DemoClassAsProperty.Name' instead
error CS0572: 'Name': cannot reference a type through an expression; try 'NinjaTrader.Indicator.DemoClassAsProperty.Name' instead

at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
at System.Xml.Serialization.TempAssembly.GenerateAsse mbly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
at System.Xml.Serialization.TempAssembly..ctor(XmlMap ping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
at System.Xml.Serialization.XmlSerializer.GenerateTem pAssembly(XmlMapping xmlMapping, Type type, String defaultNamespace)
at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
at NinjaTrader.Cbi.XmlSerializerDictionary.get_Item(T ype type)
at NinjaTrader.Cbi.Serializer.Serialize()
at NinjaTrader.Gui.Chart.ChartControl.SaveToXml(XmlDo cument doc, XmlElement element, String[] elements, Boolean asTemplate)

Any help on how to get this to serialize would be appreciated. It must be doable -- the system Lines and Plots work just fine. FWIW:

• I have tried the object as both a class and a struct -- both can work, and neither can be serialized.
• I have replaced my class with "Point". That serializes just fine, so either the serialization code special-cases Point, or else my class is missing something.

I have attached the entire indicator, in case that helps.

TIA
--EV

[ETFVoyageur]

Lest someone thing this thread has wandered off track, it has not. Here is how the answer to the original question is shaping up in my mind. (Comments are welcome.)

1. Set LinesConfigurable false
2. Make all lines be expandable properties that include all of the normal line configuration stuff
3. These properties
   1. Would keep the real lines up to date any time they got a change
   2. Are properties I know how to get my hands on, unlike a Line from Lines -- so I can either hide them or make them read-only
   3. Could go in any configuration dialog category the indicator chooses
      1. The "Lines" category if desired -- that way things would look exactly normal to the user.
      2. A more specific category, such as a "Center Band" category or an "Oscillator Lines" category.
      3. That choice does not exist for a line in Lines, so this has some advantages even without worrying about hiding lines.
      
      
   
   
4. When the user disables a line
   1. Either remove the line from the configuration dialog or else make it read-only. I have working demo code for doing both of those, so the choice is just a design choice.
   2. Change the actual line's pen to transparent, because as far as I know there is no way to just inhibit drawing it
   
   
5. When the user re-enables the line, reverse the process
   1. Change the actual line's pen back to the correct color
   2. Restore the normal state of the line's property
   
   

It seems to me that this should work well. There is still one missing piece, though. I have spent a lot of time with my good friend Mr. Google tonight and I still have not figured out how to make my expandable property class serializable. It works just fine in the indicator -- no flaws that I have yet noticed. The problem comes when I try to save to a template -- no can do. (Trace file error messages posted earlier.)

I am looking for two things now:

1. Any help on why it cannot be serialized
2. Any comments on the above steps to effectively hide a line

One further comment -- after reviewing the above steps, it is obvious what a work-around (i.e. hack) they are. It sure would be swell if NT would just provide a method or property on Line to hide it! It would be much simpler if one could just say "Line.visible = false;" and be done with it!

Support: please make a Version 8 feature request for something like Line.visible !!!

--EV

[koganam]

Lest someone thing this thread has wandered off track, it has not. Here is how the answer to the original question is shaping up in my mind. (Comments are welcome.)

1. Set LinesConfigurable false
2. Make all lines be expandable properties that include all of the normal line configuration stuff
3. These properties
   1. Would keep the real lines up to date any time they got a change
   2. Are properties I know how to get my hands on, unlike a Line from Lines -- so I can either hide them or make them read-only
   3. Could go in any configuration dialog category the indicator chooses
      1. The "Lines" category if desired -- that way things would look exactly normal to the user.
      2. A more specific category, such as a "Center Band" category or an "Oscillator Lines" category.
      3. That choice does not exist for a line in Lines, so this has some advantages even without worrying about hiding lines.
      
      
   
   
4. When the user disables a line
   1. Either remove the line from the configuration dialog or else make it read-only. I have working demo code for doing both of those, so the choice is just a design choice.
   2. Change the actual line's pen to transparent, because as far as I know there is no way to just inhibit drawing it
   
   
5. When the user re-enables the line, reverse the process
   1. Change the actual line's pen back to the correct color
   2. Restore the normal state of the line's property
   
   

It seems to me that this should work well. There is still one missing piece, though. I have spent a lot of time with my good friend Mr. Google tonight and I still have not figured out how to make my expandable property class serializable. It works just fine in the indicator -- no flaws that I have yet noticed. The problem comes when I try to save to a template -- no can do. (Trace file error messages posted earlier.)

I am looking for two things now:

1. Any help on why it cannot be serialized
2. Any comments on the above steps to effectively hide a line

One further comment -- after reviewing the above steps, it is obvious what a work-around (i.e. hack) they are. It sure would be swell if NT would just provide a method or property on Line to hide it! It would be much simpler if one could just say "Line.visible = false;" and be done with it!

Support: please make a Version 8 feature request for something like Line.visible !!!

--EV

Would it not be simpler to just have yet another bool parameter to control each line, and then group these parameters, leaving alone, and using, NT's implementation of Line Properties.

MidLineColor = ShowMidLine ? [I]UserSelectedColor : [/I]Color.Transparent[I];[/I]

        [Description("Show line.")]
        [GridCategory("Line Visibility")]
        public bool ShowMidLine
        {
            get { return showMidLine; }
            set { showMidLine = value; }
        }

etc.