Hi,
I’ve a very deep object hierarchy (about 8 levels) with many public properties and during development I’ve changed many many many… times property names, default values, properties order, group names etc…
It seems that for every subclass, the IDE initially COPY the parent behavior and then handle it like a separate data (thus not all changes made into an object of the hierarchy propagate to childs).
It also seems that for every object dragged into the layout another COPY of the behavior data are made to allow own setting.
When all those COPIES become very messed, it could be very useful to have a way that allow to sync data into the hierarchy (e.g. when I change a default value into the inspector behavior, a panel could popup allowing me to specify the subclasses to with propagates the new value).
Even a simple button into the inspector behavior that reset all data to initial state (like when the subclass was created) could be very useful.
Now is time for me to polish things: what is the best way to proceed?
What do you mean with copy? Can you post some screenshots or code about what you mean?
I can’t even imagine an 8 level object hierarchy. You know the answer to fix messy stuff: refactor to a different and simpler design. You should use composition and not hierarchy.
Copy means that when you create a subclass, the parent class inspector behavior is copied the first time and then handled as separate data (because the subclass can have its own settings). Since the data are not completely independent each other (because of hierarchy) a form of syncronization is in place but now it seems limited to the minimum, i.e. property names: if you add or change a parent property all subclass will be updated but if you change a default value or the order or the properties group, there is no way to propagate those changes to the subclasses and you need to edit all of them manually.
Some years ago I’ve done this “cleaning” by exporting all classes into XML, edit them manually by removing inspector data for all subclasses, rearranging base class and then reimporting all the subclasses one at a time after editing their inspector behavior at each step.
I’m wondering if there is a better and faster way to do this.
Are you speaking of placing control subclasses onto window and later changing the subclass or do you mean the default value text field for class properties (be it a control or not)?
Mainly the second case.
The first case usually can be handled by closing and reopening the window although sometimes (depending on RB,RS,XOJO version) there is the need to remove and re-assign the class to the object.
[quote=228107:@Pier Luigi Covarelli]Hi,
When all those COPIES become very messed, it could be very useful to have a way that allow to sync data into the hierarchy (e.g. when I change a default value into the inspector behavior, a panel could popup allowing me to specify the subclasses to with propagates the new value).
[/quote]
There is no way to force all control instances to revert to the default values from the property inspector
Once you put new values that override the defaults in the instance they stick with those
Hi Norman,
a simple button into the inspector behavior panel that reset data to initial state (at least for the edited class and its subclasses) should be not so difficult to implement because the code needed to handle this is already into the IDE (it is the same used the first time you create a subclass and open its inspector behavior).
However:
for a class hierarchy a “manual” way to reset inspector behavior data is to export project into XML format, remove all text inside the tags “…” for each desired class definition and the reopen the project. The first time you reopen inspector behavior for a given class al data are restored to the initial state (like the first opening)
for class instances used into the project, a “manual” way to reset the properties values to initial state is to export the project into XML format and remove the tags "… for each desired property to reset (of each object instance) and then reopen the project. The removed items will be recreated using class hierarchy and will use values from the class inspector behavior
I’ll hope that future version od IDE will be able to handle this in a much smart and quick way.
I still have difficulties to understand, what exactly you are trying to achieve. But two things strike me: an eight level deep class hierarchy and the need to make changes in the super class after you have create subclasses of it.
No offense, but the first is adventurous and might be a sign, that there is something wrong with your control hierarchy. The latter could be an indication that you subclass to early (the superclass is not “mature” in its development) or your superclass has too many tasks to fulfill.
@Eli Ott
Probably due to my poor English you missed that my core question is NOT related to software design: I simply want to polish things after a development stage in which I changed my mind many many times (also because the needs to implement new features while sharing the maximum amount of code into the class hierarchy).
However:
“an eight level deep class hierarchy”
The hierarchy is deep because each child is designed to be usable individually (so I need to create a nice inspector behavior for each object to allow easy usage into the IDE)
An example branch:
WindowsNoFlickerCanvas (remove flicker on Windows when canvases are stacked while maintaining transparency)
SizeManagedCanvas (handle object resize with min/max width/height, resize to content, weighted flexible resize inside toolbars… )
View (simplified iOS like views with subviews, zindex… )
ImageView (a view that contain a picture: handle resize, scale, fill X/Y/Both, fit X/Y/Both, aspectKeep, min/max size, borders capping… )
MultiStateImageView (take a single image divided in frames (disposed horizontally or vertically) ad visualize each frame by index, also base class for timed animation view)
BaseButton (8 state MultiStateImageView: On/Off in normal/disabled/over/pressed, with custom apperance for each state, caption/icon aligments, menu, …about 30 properties exposed and configurable)
Button (predefined styles for BaseButton like Default, Transparent, OSNative, Leopard, Yosemite, LinuxGnome, Win7… for easy one-line of code usage)
Obviously each of this class could act as a base class for other branches like View -> ScrollView -> TableView -> MultiPanelTableView or View -> TableCellView -> (TableCellHeaderView, TableCellContentView … so you can imagine how the inspector behaviors of each class appears (properties order and visibility, default values, custom enumerations…) after tons of changes.
“the need to make changes in the super class after you have create subclasses of it”
Yes, I admit that I’m not a great developer but when I want to implement a new feature I usually identify the minimum base class to modify in order to optimize/minimize code, maximize maintainability and allow further extension without breaking so much existing things… this is also often called software development process.