View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005910 | JEDI VCL | 00 JVCL Components | public | 2012-06-14 14:54 | 2014-12-04 16:33 |
| Reporter | Arioch | Assigned To | Arioch | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | suspended | ||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| Summary | 0005910: JvValidators should have validators collection visible in Object inspector | ||||
| Description | Currently to setup those particular testcases user have to double-click over the component. And he must KNOW it or random;ly find it. It is not really obvious where all those validators are to be found, on pallette maybe ? So those validators are to be visible in Object Inspector like usual array/collection of components. Either disguising them in design-time editor, or refactoring the control to really use some descendant for TCollection. Latter would also give buns support of GetEnumerator and for-in loops. | ||||
| Tags | No tags attached. | ||||
|
|
Well, having to double click on a non visual component is part of the "default behavior" of the IDE. However, I agree that not having the collection visible in the object inspector is not very convenient. Should you find a way to have those, while allowing transparent migration from old DFM, please send a patch. |
|
|
if EVERY component had some unique reaction to double click - then it would really be so. However does dbl-click over a form or label or editbox bring some design-time editor ? So that is not that straightforward as one might think. Maybe i'd try one day. However i don't think that "transparent migration" with "all IDE versions suport" is always a merit, when man power is very limited ;-) |
|
|
I talked about "non visual", it's written in the documentation for delphi. Double click for "visual" components is also documented, it creates the default event for the control. So really, it is clear, but not necessarily known to many. I know that man power is limited, but considering that almost 80% of our users are regular users, they would be very upset (as they have already been a few times) if their DFMs were suddenly useless. Especially because a DFM issue only occurs at runtime. |
|
|
Then they should actively participate in testing and fixing incompatibilities. No one can just get more manpower out of nowhere. Ether vast and slow, or narrow and faster. I was de facto maintainer of Delphi 5 and i remember BCB 5 guy. So i cannot think of big value in supporting those users, who do not want to support themselves. I can hardly test for compatibility of complex internal DFM guts with all those Delphi versions. Neither can u - u only can reject patch and pass by. It does slow down development, it also probably alienate those, who potentially could participate on some new fancy stuff, but consider D7 compatibility just dull and redundant. > DFM issue only occurs at runtime. That is a bad bad thing. Yet most of such bugs would manifest themselves when IDE would open the Form, at developer's hands yet. |
|
|
So, what do we do here? |
|
|
postpone even if we had more time, doing major change just before release would be a bad idea |
|
|
No news, suspending the issue |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-06-14 14:54 | Arioch | New Issue | |
| 2012-06-18 11:36 | obones | Note Added: 0020013 | |
| 2012-06-18 11:36 | obones | Status | new => feedback |
| 2012-06-18 14:50 | Arioch | Note Added: 0020019 | |
| 2012-06-18 15:21 | obones | Note Added: 0020024 | |
| 2012-06-18 15:39 | Arioch | Note Added: 0020026 | |
| 2012-06-28 08:47 | Arioch | Assigned To | => Arioch |
| 2013-12-13 11:33 | obones | Note Added: 0020791 | |
| 2013-12-13 12:31 | Arioch | Note Added: 0020815 | |
| 2014-12-04 16:33 | obones | Note Added: 0021117 | |
| 2014-12-04 16:33 | obones | Status | feedback => resolved |
| 2014-12-04 16:33 | obones | Resolution | open => suspended |
