Once you develop a nice containercontrol, you put it on a Window to test it. So far so good.
If you leave it on a Window and continue working on the control itself, some changes you have made take effect immediately, some changes only work when you remove the control from the Window and insert it again.
What is the thought behind this ?
I never had to remove a container from a window and insert it again. What isn’t working for you?
Same here, all changes take effect immediately in my experience.
Everything that is window editor related is applied once only, when you add an instance to a window. So for certain things you indeed have to delete and insert a new instance.
@Eli Ott - this is what I would like to state and how it works.
I have found that the property editor stays the same even if I expose more properties or add properties for the editor. In this instance it works if you get the IDE to refresh the already set container by highlighting another control and then reselecting the container control. Also, clicking on the gear at the top of the editor to toggle sometimes works.
This is the trick to get the inspector updated.
When you place a control on the window, it gets its own copy of all the property values that are exposed in the inspector. Subsequent changes to those properties in the original class/container are not propagated to the instance already on the window. So, yes, depending on the change you made, you may have to remove/replace the control, or make those changed in both places.
Thanks Tim.
Bit annoying, especially when you have multiple instances of a containercontrol on more than one window. If you forget one you can get messed up. But it works as it works.
Imagine you drop a button on a window
And you set its caption to “Done”
Then we change push buttons so the default caption is no longer “untitled” but “foo”
Would you want every one of your buttons to change ?
This is exactly the situation you’re describing just this time its a control you created and exposed properties on
Perhaps another way to look at it is
Functionality (code) is shared between all instances. Changes to the class definition propagate out.
Values (properties) are private to each instance. Changes to the class definition do not propagate.
No, of course you are right here Norman. But I just would like to state clear how it works and since it may be interesting information for starters I posted this question here in “Getting started”.
This approach seems to be using a wide brush to paint with… Alternately, perhaps this might shed a little thought clarity.
Would it be reasonable to say that a property is different to the content(s) carried by the property.
Should this be true there is sound reasoning to expect a new property to be displayed in the inspector. It should be expected that also if a property be removed say from re-factoring, that the inspector should change the participation of a property appearing in the inspector for the object.
When a value is set for a property in the inspector of an instance then sure as already stated this should retain the set value, and yet the property could still be updated with the rest of its attributes like say name or type etc. What is the fear a new property brings to the inspector for an object that is being introduced as an additional property.
When painting thought patterns with a wide brush things are over looked that perhaps should not be brushed aside easily. If looking at this with a finer brush then surely it could be thought reasonable that the value of a property should not be touched once set for the instance yet the rest of the property of this instance could very well be updated without having to burden the developer with repetitive trivia as such mundane actions.
Perhaps first reactions are just that… reactions. Some-things deserve contemplation.
It does, if you have checked the entry for the new computed property in the “Inspector Behavior” dialog.