Delphi 2011: What components to use?

We’re heading to Delphi 2011 (which will bring Delphi on Macs and Linux) and after this we’ll have yet another hurdle which is 64-bit compiling. With so many convoluted paths (ok, ok, the team will do the best to make the transition(s) as smooth as possible, but still…) a question arises: What components shall we use?…
The short answer is obvious: Use any components you wish. Here we will NOT speak about the quality of certain components neither we’ll say that some are better than others, we will just make some interesting comments about a phenomenon which is to be found in the Delphi community.

In fact, choosing the components for your project seems a very easy and pleasant task (like arranging the dices in the picture above) but when you’ll look closer you’ll see that getting it right might be harder than it seems. And here, because as time passes by, there were some component vendors which went out of business and (hence) didn’t provide an upgrade path to newer Delphi versions, that’s why there is a thinking current saying that: We will use only the components which ships out of the box. Well, knowing the Delphi community for enough years now, I’d say that this policy isn’t quite the best (even if I can understand the reasoning) and it can be greatly enhanced.

On one side, there are enough very big vendors of Delphi components which can provide support and upgrade paths for new Delphi versions (not to mention there – they are outside of the scope of this post), and on the other hand, there are other components which are so well written and small enough that one can afford to maintain them if their original author(s) choose to not support them anymore.

But this post is mainly about another kind of components: Let’s call them The VCL Cousins. There are components which, even if they aren’t shipped with Delphi, have different ties with the product and most probably they will get updated for a new version when this will appear.

DISCLAIMER: Sons, this doesn’t mean that they will be updated – only God knows this. But because (again) these components have some special relations with the product they most probably will be updated. Don’t complain here if some of the following components won’t have a Delphi 2011 version.

Having in mind the above disclaimer, read on:

JEDI – The well known library with more than 600 components powers the Delphi’s IDE AIR subsystem (AIR stands for ‘Automatic Incident Reporting’ – no connection with Adobe or Nike – sorry, folks). AIR is the Gallileo’s exception handler: the part which when IDE encounters a problem (read: throws an exception / crashes etc.) pops up that window full of info about our system, stack trace etc. and offers to generate a Quality Central report based on your info. Also, DavidI (VP of Developer Relations at Embarcadero) stated that [we] “make sure that JEDI works”. Link here, screenshot bellow:

Also, a very interesting thing in David’s comment is that he mention FreeCLX (guys, the FreeCLX’s page is hosted at SourceForge and not at Borland’s site – take care). See, even if the last public activity on FreeCLX project was 1600 days ago, David I mentions it. Perhaps we will assist at a FreeCLX revival under Embarcadero’s blessing? A cross-platform counterpart for JEDI? Sounds really interesting, in theory. And, like someone said, in theory, there isn’t difference between theory and practice. But in practice there is.

Virtual TreeView – The famous component written by Mike Lischke is one of the basic pieces of RAD Studio’s IDE since at least Delphi 2005. See the Virtual TreeView’s gallery for a small notice. (Search in page for ‘Borland Delphi’). And because one of the main stress tests for any new Delphi release is exactly the IDE (re)build one can confident enough that the component will be updated.

DeHL and RADTweet – two pet projects written by Alex Ciobanu (the former) and by Andreano Lanusse (the latter). DeHL is older and much more known. Enough hints and advertising done by other ‘team members’ give a clue that DeHL is on their radar and most probably enough features will be included in D2011’s RTL. On the other hand, RADTweet is a much newer project (a very nice one btw, even if it is still in beta) on which Andreano put enough effort. Have a look.

TurboPower ecosystem – As some of you know, there are enough users who depend on these components hence upgrading TurboPower toolset is an important thing for Embarcadero. That’s why Nick made a poll and supervises the TurboPower arena, even if it seems that he’s more focused on TSmiley 🙂 (dunno if we’ll have a TCrossSmilley though…)

What’s interesting is that Nick is Administrator (together with Roman Kassebaum) on another SourceForge project: PowerPDF and developer to the Subversion Plugin for Delphi’s IDE. Interesting. Very interesting… If you are interested in these project be sure to give a helping hand.

At the end, perhaps it is worth mentioning that the IDE took a lot of attention lately. Andreas Hausladen’s Component Toolbar is included in Delphi 2010 – so, be sure to check out his IDE fixes and enhancements. You never know what will be included in Delphi 2011… Also, Nick Hodges (the link points to Nick’s poll about GExperts) and Allen Bauer (see on the 2nd link the Nick’s comment and Allen’s response) gave clear hints that at least a part from GExperts will be, most probably, included in the IDE, besides the fact that they ‘work very closely with the GExperts team to make sure that it is ready for every new release of Delphi, and Delphi 2009 was no different.’. On the other hand, the other similar (and bigger) project, CnPack became Embarcadero Technology Partner thing which is very interesting for a free, open-source project.

Well, I state once again that this doesn’t mean that the above components will get updated for Delphi 2011 – we never know – perhaps the 3rd World War will start soon – and then…

But, given the persons involved in the projects and their relation with the main product, I do think that most probably these components will have a future and if not, at least, it is interesting to see the company’s areas of interest and give the appropriate feedback.

What do you think?

PS: Did I missed something? 🙂

44 thoughts on “Delphi 2011: What components to use?

  1. Using just Delphi controls today means to deliver subpar interfaces. Good in some scenario, but in others is not advisable.
    Are you sure all these components would work in a Qt based Delphi? Some of them are still strictly tied to Windows API. The non-visual one could be easy ported, but the visual ones? Which subset, if ever, will be available of most of them?
    But the big question is *IF* the professional libraries (DevExpress, TMS, etc) will be ported.
    And good luck to TurboPower stuff, if it is going to be managed by Hodges, a guy who has a so clear understanding of the development world that asked why PCs still have serial ports and other questions alike.

    • “Are you sure all these components would work in a Qt based Delphi?”
      I am sure that they will NOT work (except of FreeCLX of course, and enough non-visual parts from eg. DeHL, JCL etc). But don’t forget that there will be also an enhanced VCL alongside with VCLX. Mind you, Delphi 2011 isn’t VCLX only.

      “But the big question is *IF* the professional libraries (DevExpress, TMS, etc) will be ported.”
      Hmmm… don’t know but having some experience with some of them (DevExpress) I don’t think that’s feasible an one-to-one port. They are very tied to Win32 API. But, I do think that they are determined (both DevEx and TMS) to provide a solution for VCLX part of D2011.

      • VCL slept so much in the past years that we were forced to move to other controls to deliver state of the art applications. Now it would be much more difficult to step back on standard controls. If I were Embarcadero I would not spend resources in trying to kill partners that often kept Delphi alive while BorCodeDero chased the most fashionable butterfly ot the time. I would spend more time in building sound fundamentals and cover those areas that are still a bit shaky – for example container classes, the TCP library and remoting – and I am avoiding to speak about the 64-bit compiler…

        • “… I would not spend resources in trying to kill partners…”
          Where do you see this?
          I rather see the opposite: They use (pieces of) code from these partners giving them more goodwill. In fact, at least for me, including eg. JEDI code in IDE this means a clear ‘approval’ message and not a ‘killing’ one.

          “I would spend more time in building sound fundamentals and cover those areas that are still a bit shaky”…
          Absolutely. We agree on this. That’s why, I think, ‘borrowing’ (where feasible) ready-made code from FOSS projects in order to conserve resources for the things which only they can do, is the way to go, IMHO.

  2. On long-term projects, prefer to roll your own.

    Whenever I hear “why reinvent the wheel”, I say, “do cartwheels fit on a Ferrari?”

    Take the ancestor of 3rd party components, the grid control. You choose one and you go with it. Development is fast. Then your needs expand and the grid you chose doesn’t quite fit your requirements. The longer you use it, the more you fight against the smaller details of what the original developer intended and development slows whilst software quality suffers. Grid controls have grown into mini Excel monsters, yet you still cannot be sure the one you select covers what you need.

    Something simple, like TurboPower’s edit box. According to the manual, there is a property that allows you to get rid of the border. Great! But when I actually try this, I discover it only turns the color of the border to the parent. The border is physically still there, overlapping neighboring controls! Unfortunately, by then we had purchased and committed to TurboPower.

    • “On long-term projects, prefer to roll your own.”

      Of course, your point is valid. But only for a certain part of developers. I think that the golden path is somewhere in the middle. If someone can afford and needs a highly customised, performant, targeted (etc.) component, then is better to do it by itself. On commercial components there is always the risk of misfit. But in some cases (especially in the case of the free ones which are actively maintained) one can hope that his patches will be committed in the main distro.

      • From Delphi 1 to Delphi 4 we relied more heavily on in-house made components, then we switched to rely more on commercial libraries. The issues were you need highly skilled Delphi developers to build, improve, test and mantain them. Up to a point where the best developers were more busy working on them than on applications. Unless your business becomes selling components, or you can afford enough skilled dedicated resources, buying high quality libraries may become a better approach.

  3. Good blog entry. I have been working recently with a colleague on upgrading our major projects from Delphi 5 to 2010 and this has caused issues with upgrading components and backward compatibility to the original source. The components we had used in general were available in the new version of the IDE but after 5 months we are still not at a release state, mainly due to resource constraints on the project and the fact that the Delphi 5 version is still being developed due to new and existing customers of the product.

    My main reason for posting a comment is that my colleague is mainly a Visual Studio fan after extensive work in the C# environment and has spent much of the last five months complaining about features that he is used to in his IDE which he certainly did not have in Delphi 5, and dont work in quite the same way in 2010. He was also of the opinion that he did not want to use any components which were not included in the delphi box. I have worked with Delphi since its first release in the early nineties so am used to its foibles and the vast amount of components available to either purchase or open source.

    We now mainly use Dev Express components, there support team and forums are excellent with a good turnaround time on questions, and some minor components in the JEDI suite.

    Long Live Delphi 🙂

    • 🙂

      “He was also of the opinion that he did not want to use any components which were not included in the delphi box”

      Yeah, this was one of the main reasons for this blog post.

  4. [rant]
    I think Jedi has too many components and not enough documentation. I understand that it’s more fun to write components than document it (hey Embarcadero i’m looking at you too). It’s often faster to hack existing default component than trying to figure out if you can do it with jedi component. It also doesn’t help that some Jedi components are very similar and it’s hard to understand why there even are 2 components.

    Don’t get me wrong, i appreciate the work they have done. I am just saying that without documentation a big part of their hard work is actually not useable.

    • “I am just saying that without documentation a big part of their hard work is actually not useable.”

      Sure. But you can Use The Source, Luke. 🙂
      Also, there is a new NNTP news server at – you can ask there. Also you can ask on Embarcadero’s forums as well on StackOverflow. I bet that you will receive an answer especially if your question is concrete.

      Also JVCL ships with many demos (see the folders in the distribution) from which one can figure out what the components do.

      Of course, this doesn’t mean that they (AND Embarcadero) shouldn’t enhance the documentation. This is a permanent complain point against (almost) any company. 😉

      • “Of course, this doesn’t mean that they […] shouldn’t enhance the documentation.”

        The problem is that the current JVCL team hasn’t written most of the components. They only “bugfix” them. So they have to read and understand the source code but only the part they want to fix. That means they would have a hard time to write documentation for components they haven’t written themselves.

        • Yes, I know. That’s why I put there ‘documentation is a constant complain point’. But you can enhance it (seeing the word ‘documentation’ in a broader perspective) by writing demos (for example asking the community to write a small demo or enhancing an existing one) there are many guys which aren’t so skilled at writing docs but putting together a small demo will look a much easier task for a programmer.
          I know that this is the rule for the new components. But it can be applied also for the old ones. Especially in the case in which old demos (eg. Globus) doesn’t work or work partially. Also, perhaps you can ask for ‘one liners’ from donors: The ‘one liners’ are small pieces of documentation (usually one line only, hence the name) written in not so literal manner by the someone who knows the code:

          Caption – text shown on screen
          Tag – integer free to use for developer

  5. >>He was also of the opinion that he did not want to use any components which were not included in the delphi box.
    –> For several reasons this is a thinking that is wide spread assuming that components shipped are provided by “the” vendor.

    There exist several reasons and some have to do with some customers want to have all the source code that makes up there software indepent from being in the positon to recompile that Software after 10 years.

    Why reinvent the wheel?
    I personally think component orientation which is accepted in economy for decades now is still young in Software industry. It is inevitable…
    Early beginnings with libraries, class libraries, later on M$ with OLE/COM/COM+/.net seperated the tasks for the domain specialist in a certain technical area and the “developer/user” holding to knowledge how to apply the component to a certain problem or implementation.

    A library is another kind of component … I have read an interesting article about 7 kinds of component orientation in industrial manufacturing. Currently we have 2 in software development (Class library is one, component library the other) and both are related also outside software industry.

    For me it is some kind of narcissm to investigate the best “Delphi component set” and accept only components written in Delphi overlook professional supported alternatives in the area of Active X … and then to go for a half baked solution provided by on Delphi hobbyist:-) or one man show with the result that the vendor is no longer supporting the product … that’s clumsy.

    There really exist good reasons to consider implementation >>on ones own < WOW –> You are right simply use it … I’m adding – but don’t take into account the speedup of components and IDE concerning the development processes and pricing. The day will come and you (not you personally) maybe have to rewrite from scratch – and none wants to pay for…

    For me it is important to have at least the component layer seperated from the library part and not only a delayed XXX.Create of a visual/nonvisual component – really a layer/layers where you can have a different kind of integration into kind of applications built and for sure a lot better chance for adoption to ones own purposes but not starting from nothing … This aspect is maybe not considered very often … and this is my point for choosing components …

    btw: I hope delphi 2011 is out before WW3 and our only device is netbook with Linux:-) and you cannot register the copy of windows you are trying to install because windows registration server was blown away by “terorrits” speaking and writing a language called J…:-). At least we should have the opportunity to crosscompile first.

    • “For me it is some kind of narcissm to investigate the best “Delphi component set” and accept only components written in Delphi overlook professional supported alternatives in the area of Active X … and then to go for a half baked solution provided by on Delphi hobbyist:-) or one man show with the result that the vendor is no longer supporting the product … that’s clumsy.”

      I think that the reason behind this is the source code. If one have the component’s source code, he thinks that he will be able to enhance the code, (re)compile against a newer Delphi version (etc.) even if the original vendor is out of business. But I give you credit for the point.

      “btw: I hope delphi 2011 is out before WW3 and our only device is netbook with Linux:-)”

      …hmmmm…. Don’t be so sure. Anyway, being serious now, I think that even in the case of WW3, Delphi is / will be a good investment. (Ok, I wish for them to not screw up the things in the Quality department).

      • >>I think that the reason behind this is the source code.
        I agree with you on this point totally. Maybe “fanatism” is the better word for the reason of the search. Sometimes it makes sense as automation libs are shipped with a product … sometimes this is really overseen, especially if a component is used very seldom or for a specific purpose. There is not always a need to go down to the underlying DLL, port the headerfile and build components upon.

        I can remember 5 years ago a Web Browser Control originally written for “MFC” + Active X developped in C++. This really rocked. The developer simply flattend the methods to functions and this piece was somewhat easy to integrate into the application.

        Sometimes it is really lack of experience or knowledge about the Windows OS that brings uncertainty into the decison for a way to go.

  6. hm, as i understand, the 64bit development is going to be available in nearest release(Delphi2011), right?

    i have to say that i can’t believe that they would ship Mac/Linux solution before 64bit

    • Michael S: I do not agree, totally. The only thing that has to be considered is that between Delphi X and the compiler 64bit there is a version inbetween that focuses on fixes. This can mean 2 years … from this point in time I agree somehow. But we will see. and on the roadmap it looks like this.

      I personally don’t know about an application that requires … the only thing I agree is infrastructure based on 64bit windows and no 32bit database API installed on the server side. If we follow the discusstion about 64bit Delphi in the very detail – the arguments are ok and we all would be happy to hold a 64bit Delphi in our hands press F9 recompile the old stuff and benfit from 64bit … some arguments espcially from those who cry out very very loud and this fits wonderfull into this discussion is to decide for right components – in this case between different technolgies is Office integraion via add-in-express for example … (The Delphi haters blog … ) – I hate the Delphi haters blog, so I’m a meta delphi hater or something like this – but I still love it.

      As I mentioned before … Being somewhat more realistic – the existing infrastructure is XP on 32bit and some machines, but I see an increasing number in 2011 too based on 64bit Windows 7. But this does not mean that the existing app does not work the opposite is true.

      For me 64bit only for more memory is not enough – video and rendering is an argument this profits from increased memory. This would have been a perspective 3 years ago. For this WOW has at least provided an alternative. *) but you still need a server for this.
      On64 bit: In the end you need a good strategy to avoid memory fragementation. Java 6 garbage collector can do this and spreads several threads that reorganize the memory continously, next is multicores … Just one example of what to consider. Mulit core support ist another thing. To make this available to broader audience to benefit from within one application requires a very clever compiler and for sure a different compiler architecture. What goes beyond is a matter of C++ compilers provided by the processor vendors … and processor specific inline assembling.

      The problem with M$ is that they do not provide us all a strategy – they build something put it to the market and say eat dog or die … and the longer one waits the more clean IA64 machines one will find … but with 64bit we not only face different OSes we face differnet processor architectures … this is one dimension more than we are used too.

      LDS’s response;-) in the article mentioned. The main reason for 64bit is the Oracle database – because it simply the one where most of the business apps run also on windows. AWE works with Oracle too for 32bit machines but this was really an intermediate solution for a lot more huge SGA … I think the buffered pool can be increased and this really helped to reduce the time a former long running query took. Especially some comps run up to 4 instances of an oralce DB on one 32bit server to keep the apps seperated. Making use of > 16GB for Oracle consindering the masses of data is somehow understandable, but I’m not assuming a Windows server for these scenarios.

  7. Most comps won’t work in Delphi 2011! You are seeing the same problem already in Lazarus. Most Win-APIs are not available on Mac and Linux. Please keep in mind: this will be a multi platform dev environment!

    • Not quite. There will be two libraries. Remember Kylix / Delphi 6 (IIRC). There will be VCL and VCLX. Of course for VCLX the components which require VCL and / or Win32 API won’t work. See also my response to Luigi.

  8. If you’re willing to roll your own, why not contribute to an open source project instead? They’re as supported as the community is willing to make them.

    Every one of the TurboPower libraries would be dead if a few people hadn’t released their modifications. None of the remaining commercial zip vendors is interested in supporting Kylix (even if I contribute patches), and I still need it, so I updated Abbrevia. Thanks to Sebastian Zierer and Roman Kassebaum, the Delphi 2010 port was done before I even had a chance to start it. It’s great that Nick’s brought more attention our efforts, but at least so far the updates done haven’t been by him or Embarcadero.

    The JEDI project is also being updated because of a dedicated core of volunteers, and not because the IDE uses it. The IDE runs on Windows; Embarcadero doesn’t need to update it for OS X or Linux or VCLX, and they may not need to recompile the IDE for 64-bit either.

    • “If you’re willing to roll your own, why not contribute to an open source project instead?”
      Totally agree. This is my POV also. But I DO understand someone who is so exigent / demanding / picky (etc.) vs. some sort of component. Anyway there is also the possibility of forking. One should contribute to a certain FOSS project and when he need / is forced to take another path, he can simply fork that project internally (legal issues aside).

      “…It’s great that Nick’s brought more attention our efforts, but at least so far the updates done haven’t been by him or Embarcadero.”
      (emphasis mine)

      – and –

      “The JEDI project is also being updated because of a dedicated core of volunteers, and not because the IDE uses it…”
      Nobody said that.

      🙂 – The Embarcadero’s involvement in these projects isn’t so much technical (code etc.) but rather human: brand goodwill, safety, taking them in account on a new release etc.
      OTOH, IMHO Embarcadero will try to push the things up if an important (for them) FOSS project will go belly up. This was exactly the case with TurboPower (see your own quote above) was also the case with JEDI (Borland gave them hosting IIRC, see also the David I’s quote about “making sure that JEDI works” etc.).

  9. @Craig
    Yes we (Project JEDI) do update our stuff, because we need it ourselfs.
    I guess Embarcadero will make the IDE 64-bit compatible, but for sure they won’t release it for now, because this requires additional changes and testing of the installation process.
    Nick is since about a year a developer of DelphiSVN. Nick said (*) that their Subversion integration will be released as open source project and when the new release is out we will see what that means in practice.

    see “Delphi 2010 Subversion Support?” in .delphi.non-technical
    see “Delphi 2010 and Subversion” in .delphi.ide

      • That’s another show of poor management and marketing: by the time SVN support is added, it is no longer the fashionable VCS it was five years ago. And I wonder what is the share of each VCS among Delphi developers – I am not sure SVN has that large share.
        Although Delphi OTA always allowed VCS integration, Delphi lacked a real VCS integration API to ease adding VCS support without writing everything from scratch. Adding just SVN support in 2011 or so is not a great selling point.

        • I think the Subversion support is an excellent addition. Every open source Delphi project I use uses it; my own company still uses it; tons of other companies still use it, and it’s not going away anytime soon.

          As great as Git, Mercurial and all the other DVCSs are, they’re still not as polished on Windows as Subversion and TortoiseSVN are, and there are plenty of developers who will have trouble with the switch from centralized to distributed.

          I’m not sure I agree with adding a new API and expecting all the version control vendors to support it, but I see that as a separate issue.

          • Subversion is not the dominant VCS. It got much attention because they were good at marketing it, but outside open source you’re going to find many others, from ClearCase to MS solutions to Perforce, to the old CVS(NT) and the newer distributed kids on the block. And none of them is going away anytime soon too.
            If an expensive tools like Delphi Enterprise or Architect was delivered just with the low-end Subversion integration it would just shows how narrow minded they are and how little the “development surface” of the actual Delphi is. What Delphi needs in an API alike the MS SCC API to ease VCS integration without fighting with the whole OTA.

  10. I do NOT wish to be “the bad guy” in this post but I’ve tried JEDI few years ago and did NOT like it, except for the JvInterpreter component most of them are there just for the counting(“over 600 components”) and not for practical use, I strongly recommend using the components shipped with the IDE as much as possible — reason is very obvious in next upgrade you do NOT know how much time is needed to upgrade projects and let’s be honest we don’t use Delphi just because the language is simple and we like it, we use Delphi for productivity!
    If you ever wish to use third party components(let’s say a pack) find the ones you really need and split it from the pack, then you can modify it at any time(just few of them not the entire pack), REMEMBER that most open source components/projects appear today and in few months they are left by the guys who developed them mostly because they need to invest time, time is money and they do not make too much money.

  11. @Craig Peterson: “If you’re willing to roll your own, why not contribute to an open source project instead?”

    Because, as LDS points out (above), they then take on a life of their own and you expend time and resources trying to squeeze everyones wishes into them. They force us into the YAGNI trap. They require overhead that, with each change, also needs to be maintained without adding value to the project at hand.

    You have two choices.

    Either learn to program and learn the OS and GDI platform you are targeting. Think carefully before being tempted to create formal components.

    Or buy in 3rd party components. They are easy to justify to your boss and provide an initial rush of productivity. But with time, you end up building workarounds, suppressing events that get triggered at the wrong moment, etc, etc, etc. And whoever does that work will end up becoming your critical key specialist, precisely the situation you tried to avoid when you started using components.

    All these layers upon layers upon layers slow us down, slow down the application, lock us into vendors, generate non-solution-specific overhead and may or may not be there at the next OS or programming tool release.

    For quick’n’dirty programs that solve a specific immediate problem – by all means. Use components. The productivity curve rises fast. But for long term, critical applications, rather learn how to get and keep skilled staff. Your customers will appreciate the quality and you will keep control of your project.

    There is no such thing as a black box (see Joel Spolsky).

  12. Instead of writing your own components, you should write your own adapter-classes that isolates the implementation of the component set in use. This also makes its easy to replace deprecated components with new components later.

    If you add an abstract adapter-class as a base class for the adapter-implementation, you may even switch to a different component-set with a single line of code.

    Unfortunately, the RAD designer isn’t very well suited for this kind of VCL abstraction.
    I would very much like to see a GUI-designer that handles abstract VCL-components rather than concrete VCL-components (something like a wire frame solution). At a later stage (or at a higher level in the designer), you may specify which components that should be linked to the abstract components, and other implementation related issues.

    With this solution it would be easy to replace the entire component set, or just some of the components. It would also be easier to target different platforms, because you deal with “Selectable” and “Editable” , and not TRadioGroup and TdxTextEdit.

    (And don’t get me started on the screen builder solution that makes it easier to target different devices with different resolutions, color depths etc…)

    • The thing is that if you add an abstraction layer over the top, then you’ll program against that abstraction layer only. This can have advantages (as you point it out) – in fact this approach is taken by most (if not all) cross-platform frameworks – one of them will be present as a library in D2011. But there are some caveats which I think it’s worth mentioning: first of all, when someone choose to use a specific component, he cannot have access to the specific parts of the said component. Also, there is an added complexity which must be managed / maintained. Sometimes, another caveat can be the the lack of speed (if the abstraction layer virtualizes speed-sensitive subsystems).

      …but a screen builder will be indeed a nice thing to see. Can you give more details?

      • Do we really need to access more than the abstract layer offers?
        If so, add the missing features to the abstract layer or redesign the solution.

        When programming, you have to make a stand.
        Are you an application programmer, or a component/framework programmer?

        I think that there is a big difference. In the component/framework setting you may throw exceptions, but the application programmer should try to prevent/handle the errors. Likewise, an application programmer should not need to access every single property of the components, but the component/framework programmer should offer flexible and generic solutions.

        There are about 50 properties and 20 events in a TEdit component. How many of these do you actually need to access run time? In fact, most of them shouldn’t be modified at all. (A lot of the properties/events should be managed centralized to ensure a consistent look&feel and behavior).

        Some components should of course be added as-is without an abstraction layer. Especially the non-visual components.

        When it comes to the speed issue, the adapter layer may actually improve the speed feeling by introducing lazy loading, proxy behavior, thread management etc.

      • About the screen builder…
        (And we are of the D2011-topic).

        Well, the thoughts I had in mind aren’t actually new or innovative. It is just a GUI-specific version of the GoF’s builder pattern, combined with some inspiration from James D. Foleys design process.

        The idea is, again, that you abstract the purpose of each visual UI-“form”. Not on the component level, but at the higher visual UI-elements level. I say “form” because the final result doesn’t necessarily have to be one single form. Elements that may fit in one single large screen form may be split into several forms on smaller screens (e.g. using drill down, pop-up or wizard).

        Instead of adding TLabel, TButton, TEdit and TRadioGroup to a form, you define UI-areas and UI-elements and like a “Label-thing”, “Editable-thing”, “Clickable-thing” and “Selectable-thing”.

        Then the GUI-builder renders the UI-structure and produces the appropriate visual solution – according to the builder rules. The builder decides witch UI-elements to show, how to lay them out, and how the visual appearance should be (borders, colors, padding etc).

        The essence here is that you also have an abstract builder interface that gives you the opportunity to add all the UI-elements you need. It is the concrete GUI-builder descendants that decides how the UI-elements are visualized.

        With a very simple example, the Win-builder could create a form with a labeled edit field, a radiogroup, and some help information in a panel on the side.
        The iPhone-builder on the other hand creates a labeled edit field, the radiogroup is replaced with a dropdownlist and the help is accessible via a help-button.

        You work with the purpose at a higher level, and not the concrete implementation.
        This is not the traditional Delphi-way of doing tings, but I believe that we must move the focus from to the abstract level if we want to target different devices and different platforms.

        Regarding the speed and complexity-issue. This code doesn’t need to be deployed, it may be a feature of a code generating tool…

        • “About the screen builder…”
          (Somewhat) In this way will work D2011 with VCLX. Because VCLX / Qt widgets (eg. TqtEdit, TqtLabel etc.) will, in fact, map to their “native” controls on each platform.

  13. Any RAD Studio XE reactions/beta blogging yet ? … Your RAD Studio 2010 rampant blogs were quite a pleasure to read … I really miss them 😦

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s