View Issue Details

IDProjectCategoryView StatusLast Update
0005911JEDI VCL00 JVCL Componentspublic2014-12-04 16:32
ReporterAriochAssigned ToArioch 
Status acknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0005911: default values for published properties should be tested
Descriptionsee 0005695 fo example

There are hard to see bugs, when property values in Constructors and in "default" modifiers are out of sync.

There should be testing generic framework, that enumerates all JVCL classes (or at least all registered into VCL by design-time packages) and make simple test on them: create each class instance, scan published properties with "Default" values and check that their value match default one.
Additional InformationAlso good thing would be to scan all published properties with "stored" predicate - for tabula rasa just created object they should probably return False. If not affected by other properties and their cross-dependancy. It is not that obvious as "default" modifier.
TagsNo tags attached.



2012-06-18 11:23

administrator   ~0020009

If you can create the tool, then please do it


2012-06-18 14:56

developer   ~0020021

that would split into 3 questions

1) most clear - how to test given class for default properties
2) somewhat misty - how to test for "stored" qualifiers, which might be affected by other properties
3) how to integrate it all with JVCL?

Should we keep separate database of controls and manually sync it with Register design-time units ?
Should we override all Register*** calls allowing a hook ?
Should we try to hook IDE by in-memory patching of those function ?
Some other approach like making custom DesignIntf unit ?


2012-06-18 15:19

administrator   ~0020023

I was thinking more of a separate tool that is to be run once in a while.
To do that, it would "use" all units in the run folder and then use RTTI to find the properties.
Or maybe a tool that parses the files in the design folder, and then generates a project that does the above.
It does not need to be integrated in the final files installed by the users. Something inside the devtools folder is enough.


2012-06-18 15:29

developer   ~0020025

Last edited: 2012-06-18 15:30

it could be integrated in "developer" installation mode

running separate tool is easy to forget, easy to never know how to do it, easy to get out of sync with classes list.

building mega-exe would hit the requirements wall. For example on Winx64 there is no BDE. On Win32 there is Win32 BDE, but i don't have it installed and would not check those BPL's. There can be other features that certain developer would prefer not to install. For example search in RUN for *cx*.pas - a lot of DevExpress-related units, that probably are obsolete given radikal changes in DevExpress utils, and that are not everywhere affordable given price of DevExpress subscriptions.

That means to me that the tool should choose particular design-time BPLs. Not all components but only some selected ones.

And that means that since those Register procedures do already have knowledge about used controls, they are better be reused, than cloned. Which suggests some kind of hook, that can be nil on mere user machine, but that can be enabled on devel's box.


2013-12-13 11:34

administrator   ~0020792

Any news?


2013-12-13 12:29

developer   ~0020814


Issue History

Date Modified Username Field Change
2012-06-14 16:09 Arioch New Issue
2012-06-18 11:23 obones Note Added: 0020009
2012-06-18 11:23 obones Status new => feedback
2012-06-18 14:56 Arioch Note Added: 0020021
2012-06-18 15:19 obones Note Added: 0020023
2012-06-18 15:29 Arioch Note Added: 0020025
2012-06-18 15:30 Arioch Note Edited: 0020025
2012-06-28 08:49 Arioch Assigned To => Arioch
2013-12-13 11:34 obones Note Added: 0020792
2013-12-13 12:29 Arioch Note Added: 0020814
2014-12-04 16:32 obones Status feedback => acknowledged