Hello everyone. I've been a Delphi developer since before Delphi, back into Turbo Pascal for DOS. Have you ever noticed that a lot of the things that made Delphi 1.0 so highly productive were in fact not FEATURES but the LACK of them? How many properties were there in TButton in Delphi 1.0 and 2.0, and how many are there now? This is an interesting dilemma in component driven development; Now that TButton [and every other VCL Control] supports Vista Glass, Touch and Gestures, Unicode, and about 500 things more in its source code that Delphi 1 didn't support. Remember the VCL Database forms wizard? How about the undocked form designer mode where you leave your forms on your screen, each not covering the other, and when you run your application everything stays right at the same position it was when you designed it. Archaic? Yes, but productive, definitely. What if Delphi could hide all you don't want, and show only what you want. Imagine your 20 favorite properties get their own category, and these other 900 require you to expand a tree node which is always visible on the screen, but defaults to collapsed state. Not as horrible as the current hidden-category-right-click filtering system, because it's discoverable, but usable for new users and experts alike.... Just my $0.02 Canadian.
For anyone craving a reminder of the simplicity of Delphi 1.0's TButton (and yes, all its limitations!), here's a picture of the original properties:
ReplyDeletehttp://i.imgur.com/dWgBp.png
I think, that VCL components (not only TButton) follow the possibilities of the target operating system. Today's versions of windows are miles away from Windows 3.1(1) (for which the Delphi 1 were written)... The marking of not used properties and collapsing them is interesting idea.
ReplyDeleteIf I was designing a framework today, I'd have mixins/helpers that provided functionality. Imagine a "Touch Pack" that added touch properties to VCL controls (if you want them). Imagine the "Glass Pack" added glass support. Take them out, the feature is gone, and the properties are gone. However the basic Delphi/VCL/DFM design could never accomodate such a flexible-framework. We still get asked in the year 2012 if we want to delete our TSuperButton instances from our form when we open it, if TSuperButton 's package isn't currently loaded. Some basic re-engineering of the core of delphi, every 20 years or so, would not go amiss, I think. I think Marco is just the right guy to go look in on the product and provide such direction. I'm quite confident that the team will do amazing things in the next few years.
ReplyDeleteWarren, I think you're wrong here. I believe the basic Delphi/VCL/DFM design could support and accomodate such a framework.
ReplyDeleteAll you needed to do is design and register a new component that implements such a filter. I can't remember the ToolsAPI interface name, but during my time at Borland/CodeGear, I worked on such a component that allows streaming of sets and records and added virtual properties to components.
This could conceivably be extended to filter out properties.
If that's so, why can't the system accomodate missing classes, and missing properties better than it does? Look at how gross it is even having to deal with properties like "ExplicitLeft".
ReplyDeleteThat could be due to lack of resources, and prioritization of work to be done.
ReplyDeleteEven when I was at Borland/CodeGear, I could never answer these questions, much less now, since I no longer work there.