Now in Tokyo.

Just a quick note.  I'm now in Tokyo, Japan.  Just arrived at the KEIO Plaza Hotel in the Shinjuku district.  Across the street is the Borland/CodeGear offices.  Looks like I have a full day tomorrow as I'll be meeting the folks in the office here and will also meet with some local press and some customers.  I'll post a wrap-up when I return along with some photos (although I did upload a bunch to my Flickr account while still in Sydney).

Saturday in Sydney.

Tonight, March 28th, I'll be flying out from Sydney to Melbourne for the first of my two ADUG engagements.  Tomorrow night, I'll fly to Brisbane for the second ADUG symposium.  Finally on Friday night I'll be back in Sydney.  It looks like I'll be free all day Saturday.  If anyone is going to be in Sydney this coming Saturday, March 31st, send me an email and maybe we could meet at a local pub.  I'll be checking my email periodically over the next couple of days.  My email is the standard pattern, firstname dot lastname at CodeGear dot com.  It'd be good to meet up with some customers here in the Sydney area as well.  I'll be flying out to Tokyo, Japan early morning, Sunday, April 1st.

From Sydney.

Greetings from Sydney, Australia!  I'm sitting in the Borland/CodeGear office in downtown Sydney.  It is just about a 5 minute walk down to Circular Quay where you can get a great view of the world-famous Sydney Opera house and the Harbor Bridge.  Other than that, downtown Sydney feels like any other modern city.  Of course there is the whole driving on the other side of the road thing that you have to used to.  Especially at the crosswalks.  I rode in the front seat the limo from the airport to the hotel and it was just so odd to not have a steering wheel in front of me for being on that side of the car.  Of course all you folks that think we Americans drive on the wrong side of the road, probably feel the same way when you come to the States.  So now I know the feeling :-).

Delphi, Installers, and Gangstas

No doubt you've heard that Delphi 2007 has been released and sports a brand new installer built using InstallAware's excellent Delphi-built tool.  We've also bundled a copy of InstallAware Express so you can get a taste of this easy-to-use tool.  During the development of Delphi 2007, I had the pleasure of working closely with Sinan Karaca, the main developer and owner of InstallAware.  He spent a while here in Scotts Valley helping us get the new installer up and working.  His help was extremely valuable and I certainly credit his expertise and responsiveness as one of the reasons we were able to get Delphi 2007 out the door within our schedule.

While we did work very closely togther on a tight schedule by day (and they were long days ;-), we also had some very fun times and there was a few stories from this experience we won't soon forget.  Sinan explained in this post one such interesting story from his visit here.  I remember being in that meeting with Sinan when he got that phone call for his good buddy, Anthony.  At the time we all thought nothing of it.  It was just a wrong number, right?  It wasn't until the next day that he came back into the office for some more meetings and began to explain his phone call later that night from Anthony himself.  I don't think that meeting was very productive because we were on the floor laughing so hard that it hurt...  The best line is “Just tell them you don’t know anything about me and hang up.”  Good thing Sinan really doesn't know Anthony ;-)! What are the odds!  Sinan flies in, luggage is lost, needed a local phone number where British Airways can contact him so he gets a cheap cell phone.  Then it turns the phone number once belonged to what appears to be some “gangsta” from the San Francisco or Oakland area.

I also invited Sinan over a couple of times for dinner with me and my family.  It turns out that one of Sinan's favorite dishes was one that my wife has recently perfected.  When Sinan mentioned it, I knew exactly what we would have for dinner when I invited him over.  My good freind Nick, who has been out here away from his family, was also invited over since this dish was one of his favorites as well.  I must say a good time was had by all and that we had no leftovers.  This is also one of my children's favorite dishes as well and it was a real treat for them as well.

Travel time.

The following is a snap-shot itenerary of my up-coming trip to Australia and (hopefully) India.  If you're in or near these cities while I'm there, be sure to look me up, or better yet make sure to come to the ADUG Symposia.  I'll be speaking in Brisbane and Melbourne at the ADUG 2007 Symposia on March 29th and 30th.  Best thing to do is to contact Malcolm Groves in the CodeGear office in Sydney, Australia and maybe we can meet up.

Sydney, Australia: March 27-28, 2007
Melbourne, Australia: March 29, 2007
Brisbane, Australia: March 30, 2007
Bangalore, India: April 1-4, 2007

At the ADUG Symposia, I'll be talking about Delphi 2007, Delphi for PHP, CodeGear, and whatever else comes to mind :-).  I'll also be sure to schedule enough time in my talks to allow for a good Q&A session.

Seventy Five Point Seven Million Dollars in 2006

“Borland Reports CodeGear Sales As 'CodeRage' Rally Rolls“

I certainly don't feel 'beleaguered'!  As a matter of fact, $75.7M dollars is pretty darn good. What is funny is that throughout all the divestiture proceedings last year there were a lot of the “arm-chair quarterbacks” out there “speculating” on the Developer Tools Group, now CodeGear's revenue.  The amazing low-ball numbers I saw these folks bantering around like $15M, $20M, some even went as high as $50M.  Nobody could say anything to confirm or deny any of that wild speculation out there, and it was so frustrating to not be able to just say, “you're all way too low here.”  Now that it's public and the cat is out of the bag and we can can finally talk about it.  Of course we can't be more specific about the breakdown of that number, but I can say that a huge amount of painstaking effort went into properly separating out those numbers from the rest of Borland's financials.  Since the Developer Tools Group has been such an integral part of the Borland business for so long, its understandable that yanking out numbers will take a lot of work and time.

I also really enjoyed reading Cass McNutt's opinion of the CodeRage online conference.  Even though we got off to a “bandwidth challenged” start, Cass' graciousness and patience was greatly appreciated.  David I's team should be commended for all the hard effort they put into pulling this conference off.  I suspect that if you ask Christine Ellis, our CodeGear Technology Partner coordinator and conference organizer extraorninaire, she'd probably say this was about as difficult to do as a live conference would have been.  I know that they certainly worked similar hours as if it'd been a live conference!

So if $75.7M is what we do when we're “beleaguered,” just imagine how well we'll do in 2007!  Delphi 2007 for Win32 is imminent, Delphi for PHP is almost out of the oven... and I wonder why CodeRage had a couple of sessions about Ruby on Rails?

Well, gotta go check the latest Spacely build... it's so close I can taste it!

When it is ready.

The following is a editorialized quote from Ben Smith, CodeGear CEO;  As we've been wrestling all those last minute details to the ground, and getting far less sleep than we should, Ben stopped by my office the other day.  It was a short conversation since I was in the midst of tackling the issue du jour, but the overall jist of the conversation went kind of like this:

Ben: “So are we going to ship Spacely? How's the quality looking?” 
Me, with my all-too-often habit of being brutally honest: “Well, we're having a few last minute glitches with some of the file deliveries and installer scripts we're trying to get ironed out.  It's going to be very tight, but I think we can make it.  The product itself is solid and quick”
Ben: “You know that this product has got to get released soon, but I don't want to ship something we're not proud of.  Just make sure it is right.”

Some would say that this is so far out of the norm for many of the past Borland CEOs, that they may find it hard to believe that this actually was the conversation I had.  Quite refreshing, actually.

Crunch-time

Well here it is, another Saturday and I'm sitting at my desk waiting for the latest build bits so I can do some testing on patching, updating, installing, etc..  One thing we've added to the upcoming Delphi 2007 release is a new “Check for updates” process.  No longer will you have to always keep up on reading the newsgroups, blogs, the CodeGear website (although it's great that many of you do), you'll be able to simple launch the IDE and if there is an update available you'll be told about it.  You will also be able to manually check using a shortcut from the Start Menu (on XP) or that little circled flag button thingy (on Vista... what ever it is).  As shocking as it may sound, there are many of our customers that simply don't puruse the newsgroups, blogs, and other Delphi or CodeGear related sites.  This will be a way for us to connect with them and make sure we're keeping their Delphi experience the most up-to-date and the best it can be.

I like to think of this update system as similar to purchasing an insurance policy.  Nobody ever hopes to have to use it, but it is comforting to know that it is there in case that 5 pound meteor come crashing through your roof, or that bright bulb in the car beside you decides he absolutely must be where you are...  Just like you never plan on making a claim against your insurance policy, we do not actually plan on using the auto-updates (well.. almost ;-).

Once I am able to actually come back to the surface and think about something other than “ship the product, ship the product, ship the product,” I'll have to answer the tag from Ben Smith enumerating 5 things I like about Delphi.  I doubt it'll be a list of top fives... but rather simply a list of the top five that popped into my head at the time.  I also see that Ben mentioned our little brief conversation the other day...  We're close to the finish line folks.  Time for that last burst of energy for the final sprint.

Beta blogging

I'm sure by now many of you have seen some of the various references to a new unprecidented program called “BetaBloggers.”  Usually when we conduct a field-test it is under strict non-disclosure where those that participate agree to not discuss the content of the program or even reveal that they are even involved.  However, in keeping with CodeGear becoming more involved with those ongoing public conversations we've initiated this program by releasing some of our field-testers from their NDA and allow them to talk openly about project Spacely, which is the upcoming Delphi 2007 release.  Here are some links to many of them:

Hallvard Vassbotn - long time Delphi user and all-around smart guy.
Jacob Thurman - Of Castilia fame.
Jan Goyvaerts - A few nice words.
Primoz Gabrijelcic - Really likes our integration with MSBuild.
Holger Flick - On the new Windows Vista support in VCL.
Marco Zehe - Blind programmer excited about increased accessibility support.
Andrew Raimodi - All over the map, from DBX 4 to better performace and stability.
Jeremy North - Specific information about the new GlassFrame propery on TCustomForm.
David Clegg - Some great information on the help system improvements.

Delphi 2007 is poised to be an excellent release.  Don't take my word for it, just look at what these folks are saying.  This is going to be the “must-have” release for Delphi.

How to add a "published" property without breaking DCU compatibility

First off, if you are an OOP or framework purist and have a weak stomach, you can stop reading now.  In the upcoming Delphi 2007 for Win32, we took an unprecidented approach to adding functionality to the VCL.  If you've used Delphi for more than a couple of versions, you can fully appreciate that when the VCL framework changes, you have to also get updates to your third-party components.  Now I'm not going to discuss the reasons why, since I've covered this in detail over the years as to why this happens.  Basically it boils down to having the flexibility to make changes to existing classes and the compiler itself as we see fit to provide the best overall experience that we can.  So, for all of you who will make the knee-jerk comments about “why don't you just do this for every release!”  Had we done that, you'd never have packages, interfaces, class variables, inline functions, and in a post-Delphi 2007 release, generics.  Just browse through some of my past posts for more details.

With that said, we decided to take a slightly different approach for Delphi 2007.  D2007, is being touted as a “non-breaking” release.  What exactly does this mean?  In a nutshell, it simply means that you should be able to take most of your components for BDS2006 and install them into D2007.  I say most because there will, of course, be some fringe cases that this isn't possible.  For example, if you have a component package that likes to reach around the existing design-time interfaces and muck with things behind the scenes, that is out of the scope of the non-breaking change.  As long as your existing component design-time package sticks with the existing published interfaces it should work without a recompile.

Uh... so what's new then??  It is true that a lot of the changes we've made have been in the “implementation” section only and so there is no DCU breakage there.  But there are also quite a few changes that manifest as either whole new components or in one case a brand-new published property on TForm!  The rules for type compatibility with the Delphi compiler is deceptively simple.  Basically, for any structured type (class, record, object, etc...), the “version” of that type or symbol is derived from all the embedded symbols and types.  So you cannot modify an existing class type or method declaration without causing this “version” to change.  This is the cause of the error message “xxx” was compiled with a different version of “yyy.”

For the astute among you that have been following along so far, you are probably already jumping ahead here and thinking.. of course, class helpers!  Well, yes, you'd be right on that count, to a point.  I did say that the new property is “published” which means it also shows up in the Object Inspector in the IDE.  So there is a little more gong on than just a class helper.  As it turns out, using a class helper will make this new property appear from the user's source code to be on  TCustomForm, which is the desired effect.  So we just added a property without actually touching the original TCustomForm declaration.  Then there is the streaming and the storage of the property in the instance.  This is where you should avert your eyes if you're a little queasy ;-).  We simply take and overload an existing, little-used, private field on the TCustomForm instance and create an internal (implementation section only) structure that has a field of the type of this overloaded field to now hold its value along with whatever fields are going to store the class helper's property data.  Then we go through all the places in Forms.pas that access this field and to some casting tricks to use that field as a pointer to that structre.  Since it is a private field, there is no effect of any descendants outside the Forms.pas unit.  This is actually a place where the OOP tennet of encapsulation helped us acheive this.  We were able to make this change and no code or classes that use an instance of this class are any more the wiser.

That takes care of the storage of the data behind the scenes. Now how about streaming this data since I did actually say that this was suppose to be a “published” property?  This is someplace where some past changes to the framework helped us.  TCustomForm had already overridden the DefineProperties method, so now it was a simple matter of adding some more code that method to handle the streaming of the property data.  This is also where the class helper came in handy because we could put the read and write methods on it.  Again, without changing the TCustomForm class.  So now we have a new property on the TCustomForm class, the streaming is all hooked up and you can now access this property on any TCustomForm or decendant instance.  The final piece now is how to get this property to show up in the Object Inspector.

This is where the ISelectionPropertyFilter interface comes in.  You may or may not have seen this little one-method interface that was introduced in BDS2006 in the DesignIntf unit.  For those of you with BDS2006, you can open DesignIntf.pas and read the usage comments there about where and how to implement this interface.

  { ISelectionPropertyFilter
    This optional interface is implemented on the same class that implements
    ISelectionEditor.  If this interface is implemented, when the property list
    is constructed for a given selection, it is also passed through all the various
    implementations of this interface on the selected selection editors.  From here
    the list of properties can be modified to add or remove properties from the list.
    If properties are added, then it is the responsibility of the implementor to
    properly construct an appropriate implementation of the IProperty interface.
    Since an added "property" will typically *not* be available via the normal RTTI
    mechanisms, it is the implementor's responsibility to make sure that the property
    editor overrides those methods that would normally access the RTTI for the
    selected objects.

      FilterProperties
        Once the list of properties has been gathered and before they are sent to the
        Object Inspector, this method is called with the list of properties.  You may
        manupulate this list in any way you see fit, however, remember that another
        selection editor *may* have already modified the list.  You are not guaranteed
        to have the original list.
  }

  ISelectionPropertyFilter = interface
    ['{0B424EF6-2F2F-41AB-A082-831292FA91A5}']
    procedure FilterProperties(const ASelection: IDesignerSelections;
      const ASelectionProperties: IInterfaceList);
  end;

So the basic trick is to register a selection editor for TCustomForm that implements this inteface.  When FilterProperties is called, we can now completely manipulate the whole list of IProperty interfaces in the ASelectionProperties argument.  You can add and remove properties.  For instance, if you drop a TFlowPanel on a form, then drop components onto it, you'll notice that the embedded components don't have a Left and a Top property.  Not because the component doesn't have them, but because they are useless at design-time so they get removed from the ASelectionProperties list.  In the TCustomForm case we actually want to add a property.  So we search through the list of properties, find the insertion point, instantiate a class that implements IProperty.  Now your “published” property shows up in the Object Inspector!

While this all seems like a lot of work to go through just to maintain compatibility, the good news is that in a post Delphi 2007 release we can fold these changes back into the TCustomForm class, delete the class helper and the ISelectionPropertyFilter, and the existing DFM files will work just fine.  So will all your source code that accesses these new properties.  One interesting thing is that this proof-of-concept could lead to being able to add some significant functionality into interim releases without breaking existing components/DCUs.  It could even be that every other release is a breaking release.  Just some things for us to consider for the future.