I was a little disappointed that the preview webinar this morning was little more than a re-run of the same content from a little over a week ago, albeit with some downloadable PowerPoint slides this time.
It was at least an opportunity for some more Q&A and a couple of interesting Q’s got A’d.
1. Generics Support For Event Types
In my series of posts on multicast events I speculated that if generics support included using event types as parameters then things could be made a little easier. David I demonstrated that it does appear to be possible:
TEventList = TList<TNotifyEvent>;
So it appears that in a future D2009 revision of my multicast events implementation we should be able to write:
TMultiCastNotify = TMultiCast<TNotifyEvent>;
It won’t, as far as I can tell, eliminate all the work in deriving a new multicast event class, but it will remove the drudgery of implementing Add() and Remove() methods, at the very least.
2. Release Timeframe
In response to the inevitable questions about when it (Delphi 2009) will be released, the stock response is still “When it’s ready“. The supplemental question “When will it be ready?” triggered a stack overflow exception:
Q. When will it be ready?
A. When it’s ready.
Q. Cool, so when will it be ready?
A. When it’s ready.
etc
🙂
However, it was mentioned that these preview webinars will continue on a weekly basis through to the end of September. So I think it’s not unreasonable that we might optimistically hope for an October timeframe for an actual release.
3. Ribbon is Not Entirely VCL Code
At the previous preview I got the distinct impression that the ribbon control support was entirely CodeGear VCL code. This time around it was mentioned that it is a VCL wrapper around Microsoft code. I’m not sure that this is particularly important one way or the other, but some people might find it interesting.
Update: Nick Hodges (Delphi Product Manager, so he should know) has clarified that there is in fact no wrapper or Microsoft code involved, only VCL code.
What was certainly interesting was the indication that if you use the ribbon control in an application then you will need to obtain a ribbon UI license from Microsoft to then deploy that application.
This in itself is already controversial and one school of thought has it that the license is not only undesirable, but quite possibly unenforceable.
4. No Generics Enrichments in the VCL
Apart from the Generics.Collections support, the VCL itself has not been enriched with generics support. I find this surprising. It strikes me that it should have been quite straightforward to enable us to write:
TCustomerComboBox = TComboBox<TCustomer>;
To create type-safe access to the data associated with the items in a combobox, for example.
It should be relatively easy to create these extensions ourselves, but it would have been nice to have that support built in to the VCL. Having said that, design-time support would have been a bit difficult I suppose. i.e. dropping a regular combo-box on a form and then specifying the type of the items data via the property inspector.
5. Insight Into the Interested Customer Base
Aside from the information on Tiburon itself, the QA provided an interesting insight into the parts of the community that are actively interested in Delphi 2009. Some of the questions appeared to demonstrate a lack of familiarity with more recent changes in the language, such as support for dotted unit names (Delphi 7) and strict private visibility (Delphi 2006, I think).
I am not ridiculing the people that asked those questions. Far from it. I think it is positively encouraging that users who – it would appear – were perhaps previously “left behind” are once again interested in this new version of Delphi.
It reinforces a general impression that I am increasingly forming, that a new spark of life has appeared in the Delphi community.
🙂
More To Come
As mentioned, it appears there will be more previews to come, on a weekly basis. The schedule currently only runs to the end of August, not September, but whether David I misspoke or the full schedule simply isn’t finalised yet, I don’t know.
For local visitors, the 11am PDT time slot is 6am the following day in “Auckland Time”.
The future is bright. The future is Delphi.
Jolyon —
If someone said that the Ribbon controls weren’t pure VCL, then they were wrong. There is no “wrapping of MS code” going on.
Nick Hodges
Hi Nick
I was a little surprised to hear David I’s comments on this score, as my understanding of the ribbon was that it only existed as a design/specification, not a common control for example, so I didn’t think there was any Microsoft code that existed to be wrapped, although there was always the possibility that that had changed.
As I said, I don’t think it’s too important either way, but thanks for the clarification – I’ve updated the post.
Nick – you might want to add a comment to Tim Anderson’s write-up of the webinar too then.
Personally, I think the MS Ribbon license is a good thing as you then have to ensure that your Ribbon behave like other Ribbons – ensuring a consistent user experience. If it is based on a duck, and named as a duck, it should quack like a duck. Think of it as duck certification 🙂
Personally I favour a well designed and usable UI, designed to suit the particular application, over an arbitrarily consistent one.
In fact, arguably the license is specifically intended to ensure INconsistency between Microsoft Office and anyone setting out to create an alternative, since in this case the license to the look and feel is not free. Or at least, if you pay whatever the fee is to enable you to compete directly in look and feel as well as functionality, Microsoft then get a slice of your pie.
If it came to fighting a “look and feel” case in the courts against a potentially significant competitor, the history of such cases would not bode well for a Microsoft victory. By attempting to establish a priori that a basis for such a case exists, as enshrined in a license for said look-and-feel, Microsoft might believe that they can – or indeed have – reduced any such case to a much more actionable basis, and one more likely to succeed.
Bottom line – I don’t believe they care whether your non-Office suite application has a UI that is 100% consistent – with all i’s dotted and all t’s crossed – with Office or not.
And neither should they. And neither, frankly, should we.