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

[ETFVoyageur]

The original suggestion was to just make the line transparent. My concern was over how to make that robust as long as the user is free to mess with the line configuration. At first I thought that was a problem, but I think I see how I can deal with that. Handling lines from expandable objects would provide a couple of other benefits, though -- open up some design choices.

1. I could place the lines' properties wherever I want them -- for example the lines at the top and bottom of the center band could be grouped with the rest of the center band parameters.
2. I could, if I desired, remove the center band lines from the display whenever the center band is disabled. I currently do that with the other center band properties.

I cannot do either of those with lines as they are. I need to handle them from an expandable property to do that. I guess that, until we can figure out the serialization issue, I could:

• When the center band is disabled, turn the lines transparent
• When the band is re-enabled check the line color. If it is no longer transparent, the user must have changed it, so leave it alone.
• There is one big usability drawback, though -- the user will see the line property change color (I think). That should not happen -- logically, the line has not changed color -- it just got hidden. No way to make that be clean with the current setup. It would be perfectly clean with the expandable property approach, though.
• I'll do that for now, as the only hack available until I get serialization working.

I still want to understand the serialization, though -- it is absurd not to be able to do that. Especially when the Point class handles it just fine -- that is a pretty strong hint there is a way, just one i do not yet understand.

BTW: when I first thought of properties coming and going I thought that would be pretty strange. I have that implemented now, though, and when used judiciously it is rather nice. It helps un-clutter the interface in certain cases. One side-effect of my recent searching for property handling info is that I am now happily graying or removing properties in the interface as appropriate. Now that my infrastructure is st up, it is pretty easy to do. I have my convention as to when each is appropriate, and so far I like the result.

--EV

[ETFVoyageur]

Folks, the simple plan to cache the line color and later restore it fails because of NT's attempts at cleverness. I need to think this through. Some of it sure looks like an NT bug, but I'm rusty enough that perhaps I am just misunderstanding something.

The basic problem is that calls to the property are all happening in the gap between leaving OnInitialize() and entering OnStartUp(). The only thing significant about being in that gap is that is where NT is busy creating objects initialized from storage values. In a nutshell, here is what is happening:

• The user is normally using DarkGray, so that is the initial state, and that is the state of the stored data that NT is depending on (and keeps trying to inject).
• The user is in a good mood, and so resets his line to Aqua and then disables the center band
• The indicator caches the Aqua and set the line to Transparent. So far, so good.
• NT makes up a new set of objects, starting with the line at the stored value -- in this case DarkGray
  • I tentatively think this is a huge bug -- the new line should be the same color as the old line
  
  
• NT calls the indicator to set the state to disabled. The indicator does what it always does when disable is called -- it caches the line color and ssets the line transparent. Notice that it has just overwritten its record of the user value (Aqua) with the bogus value NT just forced in (DarkGray).
• The user re-enables
• The indicator loads its cached -- by now wrong -- value. The user's line is forced back to DarkGray, instead of being left at Aqua as it should be.

I need to see how to deal with this. Perhaps you think I should keep a flag so that only the first enable/disable counts. Subsequent ones do not do anything with line colors. Well, that is an other thing that sounds good, but will not work -- I'm getting called in a new object instance, not the old one, and no one bothered to copy the cached value from the old instance to the new one!

The bottom line is that my assumptions are not valid. I'm not sure which should be and which should not, so some of you who are more experienced in this environment please help here:

• Am I supposed to provide a copy constructor? The wizard-generated indicators do not have a one, nor to the built-in indicators as far as I recall.
• I have assumed that my environment would be the same unless I changed it. For example, once my indicator sets its line to Aqua, I have assumed the line would always be Aqua until the indicator does something else. That turns out to be false -- an NT bug, if you ask me, but tha's the way it is.

Basically, with things the way they are:

• I guess I need to add a copy constructor so that my internal values are preserved. Would they automagically get preserved if I made them properties instead of simple variables? Having my storage get reset behind my back is not nice.
• If my flag would be persistent, I think I could tell which calls are made by the user -- the first disable after being enabled is user, and the first enable after being disabled is user. All other calls are NT doing it's thing and I should not let that upset my caching -- in fact I might need to force line color to what the user want on those calls.

What a can of worms! I need to do some yard work ... perhaps some great idea will come to me as I do!

--EV

[ETFVoyageur]

Quick summary:

• I can hide the line when the user says to disable it.
• I can make the line visible again when the user say to re-enable it
• The problem is that the line may not be the color the user expected when I re-enable it. That is a deal-killer
• I do not now how to get around that without:
  • Reliable persistent storage -- possibly making it a property, or implementing a copy constructor would do that
  • Finding a way to tell which calls matter for line color setting. My current code is written as if all do, and that is a mistake.
  
  

--EV

[koganam]

Quick summary:

• I can hide the line when the user says to disable it.
• I can make the line visible again when the user say to re-enable it
• The problem is that the line may not be the color the user expected when I re-enable it. That is a deal-killer
• I do not now how to get around that without:
  • Reliable persistent storage -- possibly making it a property, or implementing a copy constructor would do that
  • Finding a way to tell which calls matter for line color setting. My current code is written as if all do, and that is a mistake.
  
  

--EV

You are talking about colors, so let me ask you: "Have you arranged to serialize the colors?"

[ETFVoyageur]

You are talking about colors, so let me ask you: "Have you arranged to serialize the colors?"

Yes. Works fine.

--EV

[koganam]

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
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

You will need to write a TypeConverter, then apply it as an attribute to the Property definition.

ref: http://msdn.microsoft.com/en-us/libr...=vs.90%29.aspx