ctodx

This Blog

News

Favorite Posts

Archives

June 2007 - Posts

  • Delay in C++Builder 2007 support for our VCL products

    Our VCL team has run into a problem in adding support for C++Builder 2007. The issue at hand is a compiler problem: in generating the interface .hpp files for the VCL suite (which of course is written in Delphi), the compiler creates structures that are incompatible with the Delphi version.

    After that, of course, customers' C++ code will no longer properly interface to the Delphi compiled code.

    The issue has been reported to CodeGear (QC47943). Until the compiler issue has been fixed we will not be able to provide support for C++Builder 2007.

    UPDATE: The just-released Update 2 for Delphi 2007 and C++Builder 2007 does not contain the fix for this bug.To quote Nick Hodges: "This bug was marked fixed on 24 July, after the cutoff for Update 2. However, it will be delivered as part of the next update, which isn't too far away." To say we are disappointed by this turn of events is an understatement. The next update is most likely to be Highlander, making the release of C++Builder 2007 a complete and utter waste of time for both our customers and ourselves.

    YET FURTHER UPDATE: We've now confirmed that Update 2 for C++Builder does contain the bug fix and Build 27 of our VCL Subscription Suite does work with C++Builder 2007 with Update 2. 

  • Fahrenheit VCL

    Reading between the lines is not fun. After all, what's there is merely implied and not made explicit: it's just blank space with BackColor = clWhite. Seeing anything involves looking askance, or perhaps with prior expertise.

    And that's what I feel like when I read the news coming from CodeGear. This is what they're saying in black and white, but there's a faint echo in there which can almost be resolved into text. It's sounds fun but really isn't.

    So, it's with some reluctance that I note

    • There's no mention of the WinForms designer. Indeed, as I understand it, it's kaput. You should be using the forms designer that targets VCL.NET.
    • There's no mention of C#Builder. Now this maybe because the roadmap I'm looking at is, quote, for Delphi and C++Builder, unquote, but it is more realistically kaput too.
    • Despite having untold time to understand and support generics as implemented in .NET 2.0 (which was released in 2005, remember, and we're now in 2007), the Delphi for .NET in Highlander (later this year) will only consume generic types, you won't be able to create your own. You'll have to wait until Tiburón in 2008 sometime in order to do that in Delphi for .NET as well as your common-or-garden Delphi.[Update: in a further change to their roadmap, CodeGear stated that Highlander will be able to generate as well as consume generics.]

    Set against all that are some great additions that are slated to appear over the next year or so, including, ASP.NET 2.0 support in Highlander, Unicode in the 32-bit version of Delphi and, much later, native 64-bit support. I even see that Tiburón is "expected to be given new support for UI elements such as Ribbon controls, theming, skinning, and other UI improvements." Nice. [Update: ever since I originally posted this, people haven't noticed I was being sarcastic here. Oh well.]

    So, I look at all this with my Developer Express hat firmly in place, including all my biases from my deep history in the Delphi/VCL third-party marketplace.

    First of all, a huge sigh of relief: no more WinForms in Borland Developer Studio (or whatever name it will now have). We can and will now firmly and rightly say: no, our .NET controls just won't work in BDS. Sure, you can still manually type code to create them and set their properties and assign event handlers, but our controls never will never work in BDS at design-time. If you want to use our .NET WinForms controls and have a rich, interactive design experience, you should be using Visual Studio 2005 or later.

    Second, VCL.NET. I see the usual canard is still repeated in the CodeGear roadmap: "VCL developers will be able to easily migrate code to managed code using VCL.NET." On some projects maybe, but certainly not with our VCL controls. In fact, it's with some reluctance that I note that we just don't have the resources to even try. (The last product that supported VCL.NET was ExpressQuantumGrid 5.) So I'd have to say enhancing our VCL.NET support is no longer something we'll actively do, and we'll no longer market our support for it.

    Third, Highlander's ASP.NET 2.0 support. The roadmap is very wishy-washy about what this will comprise (and my reading between the lines fails miserably), so I really can't say how this would impact us with regard to our ASP.NET products. Again there is the large issue of the design-time interface: we write our designers for Visual Studio not BDS, and I have no idea what would be involved in converting/rewriting them.

    Fourth, at least a year away from Tiburón and major changes in the language. Part of me heaves a sigh of relief; part of me shakes my head in disbelief -- I really don't know what to think about this. VS2008 will appear with .NET 3.5 and C# 3.0 and a designer for WPF well before Tiburón. So, let's see: LINQ and lambda expressions and quasi-functional programming and WPF controls and other fun things for us to design and develop, before Delphi even gets the ability to create a single generic type. [Update: again, CodeGear changed the roadmap, and Highlander will support creation of generics in Delphi for .NET.] I think it's fair to say that VS2008 will have a huge impact on us as a company. So, in equal parts, disbelief (CodeGear are continually rebuked for being slow to catch up) and relief (I can perhaps reallocate some of our VCL team to writing WPF controls in the interim).

    Fifth, Unicode. Love it, approve wholeheartedly, should have been there years ago, but, man, do I worry what it's going to do to our codebase and, by extension, to our customers. I see this as being a much bigger change than from 16-bit to 32-bit, but maybe I'm just a scaredy-cat. More on this when we know more.

  • Thinking of impossible things before breakfast

    As is my wont, I was musing to myself this morning about what seemed to be an impossible feature and how great it would be to have.

    It all came of a comment made to me at TechEd last week.

    Oh, yes, that reminds me: TechEd was last week and we were there. What with one thing and another I forgot to make the announcement here on this blog. Sheesh, what is the world coming to? This particular TechEd was an interesting one: we had a one-off t-shirt printed and gave them all away (so, sorry, but you can't have one, but the crowds we had at the booth all got one), we moved our booth to a more favorable place (so if you tried to find us on the map we weren't there, but you'd have found us eventually due to the huge crowd getting a t-shirt), we were showing off the new C# 3.0 refactorings and getting daily builds so if you came back the next day you'd have probably seen something new (cue more crowds and a morning of Orcas crashing during demos), and I did a presentation at a talk for the first time in a while (with no crowds at all).

    Where was I? Oh, yes, impossible things. Someone asked me for this at TechEd.

    Imagine this: you work in a team, maybe a large team. For whatever reason not everyone in the team uses the same plug-ins. Sure they all have Visual Studio 2005 installed, but some people use no extra plug-ins, some use CodeRush and Refactor! Pro, some Resharper, some something else entirely. You, you're the guru mentor for the team and often help developers out while at their machine. Of course, the most intractable problems occur with those people who don't have your favored environment of CodeRush. You're suddenly reduced to typing it all out longhand. You are no longer programming at the speed of thought (say, that's a good slogan).

    Don't you just wish for CodeRush on a Stick? A full install of CodeRush and Refactor! Pro on a USB memory stick that you can plug into a USB port and say the magic incantation and, hey presto, it's there in the other developer's Visual Studio IDE.

    Done? Unplug the stick and walk away and CodeRush is no longer available in that install of Visual Studio.

    Possible or not?

    First off, you might say it's all files and registry entries. Just have a super-light "install" program that sets up all the right registry keys that point to the files on the USB drive. Then start Visual Studio and program away with the full support of CodeRush and Refactor! Pro. Unfortunately, when you want to unplug, you've got to remove all those registry keys otherwise things will get really dicey, And that would probably require Visual Studio to be shut down at the minimum and the use of some super-light uninstall program.

    Second issue is that DXCore, the part of CodeRush that talks to Visual Studio, uses COM. It has to: the VSIP interfaces it wraps are all COM interfaces. Even after all these years, I think this is the big problem: you can't install COM stuff on-the-fly and just have it work.If COM weren't in the picture we might be able to swing it.

    Third issue is the GAC. We install our CodeRush assemblies in the GAC. Big problem if we don't want to copy files all over the place when we insert the USB stick. Now I may be wrong here, but I think we could get away from having to do this; I haven't had a chance to talk to Mark or Dustin about it.

    So, all in all, I think it's impossible, unless the plug-in architecture for Visual Studio was drastically changed.

    But how about this? Visual Studio on a stick? You install VS and all your preferred plug-ins on a USB drive and carry that around with you. Again, impossible at the moment, but I think it could be oh so tantalizingly close...
     

     

LIVE CHAT

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2017 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners