I have a project that makes heavy use of TAdvSmooth* controls. Around 360 definitions and 400+ instances at runtime.
I have noticed that a single control (eg. TAdvSmoothComboBox) adds around 1000 lines to the DFM file with just default properties and it seems that the many (18 here) instances of TGDIPFill is the major culprit.
On examining GDIPFill.TGDIPFill, there are in fact 'default' values against 8 of these properties *but* they're commented out.
I'm tempted to enable these defaults but wondering if there is a good reason to leave them out.
Closely related to this is that 20 X TAdvSmoothListBoxItem are created in the control at design time. This makes up 720 lines of the DFM on its own. The items are a nuisance at design time and waste runtime since I always clear the list and build the items dynamically.
It would be appreciated if this could be looked into for the next update.
The default items added are just to show something useful in the control when it is created at design-time. You can of course delete all items that were auto created and they'll not take up DFM space. With respect to the GDIPFill, it is not as simple as this unfortunately. GDIPFill is used in many different controls and with different default initializations, so putting a single default value on its color settings will unfortunately break behavior of the many controls that use it in different scenarios. We'll investigate if perhaps we can do something with the stored specifier at GDIPFill level.
I can appreciate the wide use of GDIPFill and differing values. I just figured that it is normal for a TPersistent property to have a default value that matches the initial value assigned in Create() so that it doesn't need to be stored. (ColorMirror is just one example, btw) I don't think that will affect design or run time use but I'm going to give it a test myself and I can report back any results.
Re the 20 items, I can remove them but I have many to work with. Pre-populating them at design time is good for demos, not real life :-) cf regular VCL list and combobox controls
ps I'll remove the initialisation in procedure TAdvSmoothListBox.InitPreview; to try it out.
Yes, but in some controls, it is desired that ColorMirror has some color by default and in other controls it is desired that it has a color set to clNone. So, there is not really one unique value that should be set in the constructor.
Bruno Fierens2018-10-31 10:06:53
Every control that uses the TGDIPFill class as property somewhere needs to be checked. When we had to remove a default setting, there was always a reason that a control using TGDIPFill needed a different default initialization.
Again, as the GDIPFill is used in different controls, different controls expect different property values in GDIPFill to be initialized properly to look good. So, there is no such thing as a default, always used property setting for many of the GDIPFill properties.
I'm not suggesting changing any default values. The constructor is untouched. Adding 'default' simply saves writing out to the DFM those values that happen to be the default. It does not impact any initialization at load time at all.
Note: Declaring a default value does not set the property to that value.
In summary: yes, many non-default GDIPFill properties are set, but those that are not just add fat to the DFM. 168 lines vs 1001 lines for TAdvSmoothComboBox (including culling the items).
We know very well what the 'default' attribute means and what it does and we do use it where possible.
I regret that even when I explained it multiple times, you do not understand that it will lead to problems when GDIPFill needs to have different color initializations for different components.
The defaults for TAdvSmoothListBox, TAdvSmoothButton etc... per needed GDIPFill class are not necessarily the same, hence, we cannot set default values at GDIPFill class level. Please accept this as my final answer.