View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005911 | JEDI VCL | 00 JVCL Components | public | 2012-06-14 16:09 | 2014-12-04 16:32 |
| Reporter | Arioch | Assigned To | Arioch | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | acknowledged | Resolution | open | ||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| Summary | 0005911: default values for published properties should be tested | ||||
| Description | see 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 Information | Also 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. | ||||
| Tags | No tags attached. | ||||
|
|
If you can create the tool, then please do it |
|
|
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 ? |
|
|
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. |
|
|
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. |
|
|
Any news? |
|
|
no |
| 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 |
