View Issue Details

IDProjectCategoryView StatusLast Update
0005910JEDI VCL00 JVCL Componentspublic2014-12-04 16:33
ReporterAriochAssigned ToArioch 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionsuspended 
Product Version 
Target VersionFixed in Version 
Summary0005910: JvValidators should have validators collection visible in Object inspector
DescriptionCurrently 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.
TagsNo tags attached.

Activities

obones

2012-06-18 11:36

administrator   ~0020013

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.

Arioch

2012-06-18 14:50

developer   ~0020019

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 ;-)

obones

2012-06-18 15:21

administrator   ~0020024

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.

Arioch

2012-06-18 15:39

developer   ~0020026

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.

obones

2013-12-13 11:33

administrator   ~0020791

So, what do we do here?

Arioch

2013-12-13 12:31

developer   ~0020815

postpone

even if we had more time, doing major change just before release would be a bad idea

obones

2014-12-04 16:33

administrator   ~0021117

No news, suspending the issue

Issue History

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