ModalPopupMode

Remember this post?  It was where I described the newly added PopupMode and PopupParent properties to TCustomForm.  Lets fast-forward to now, in the midst of the DeXter release of Delphi.  It seems that this change highlighted some shortcomings in the implementation of, not only, Borland supplied components but also of many third-party components... Well.. maybe shortcomings is too strong of a word... let's just say “issues.”  One of the original goals of VCL visual components was to delay the construction of the underlying window handle to the last possible moment.  It was also a goal for all visual components that use a window handle to also properly survive a handle recreation.  The visual component should save off any state that is internally associated with the window handle and then properly restore it once the new handle was created.  The reason for this is that there are some window styles and/or states that cannot be change on the fly without destroying and creating a new window handle.  This was especially true back in Win16.  Thankfully, this is less of an issue for Win32, but there still are a few cases.  So when the PopupMode properties were introduced, the only way to change the “owner” of a window handle was to destroy it and then recreate.  There is no SetOwner API similar to SetParent. (Ok, if there is, I haven't found it..)  So why is it important that the correct owner be set for modal UI?  Raymond Chen explains one reason quite well here.  In fact, I encourage you to peruse a lot of what Raymond has to say regarding the inner workings of Windows.  In today's modern world of frameworks and abstraction layers, rarely do folks ever need to really understand the raw Windows API level functionality, however sometimes it is good to go back and revisit why and how things are done the way they are.  Raymond rarely disappoints in that regard.

So back to the subject at hand... In order to properly guarantee that modal forms were “owned” properly, the ShowModal method on TCustomForm was changed to force a recreation of the handle if the PopupMode was set to pmNone.  What this did was ensure in CreateWnd, the proper owner was selected for the new window handle.  This seemed to wreak no end of havoc on existing VCL applications.  It also served to highlight how “recreate brittle” many of our own VCL components were.  The good thing about this is that for DeXter, we've corrected all those issues and our VCL components are now “recreate tolerant.”  In fact, if you're a third-party component developer, I encourage you to review your own components to determine their “recreate brittleness.” 

Now the standard technique for “fixing” this issue was to simply set the PopupMode property on all your forms that are intended for modal operation to pmAuto.  This would ensure that when ShowModal was called, no recreates were nessesary because the correct owner would have, presumably, been selected.  There are cases where this may still not be the case, especially when you don't create and destroy your modal forms near the point they're needed.  In response to the feedback regarding this issue and the fact that when you are bitten by it, it is extremely difficult to determine the cause, we'll be introducing a new TApplication property that controls this modal behaviour at the global level in the DeXter release.  The new TApplication.ModalPopupMode property does this.  For consistency sake the type of this property is TPopupMode, which is an enumeration with three elements.  The default value for this is pmNone, which makes ShowModal behave the same as the Delphi 7 version of VCL and earlier.  Setting this property programatically to anything other than pmNone (pmAuto or pmExplicit), will enable the current Delphi 8 and Delphi 2005 behaviour.  So now you can choose when and if you need to support this new behaviour.

For component developers, the IDE code explicitly sets this value to pmAuto, so if you have any modal dialogs as part of the component/property editors associated with your components, then you'll still need to ensure that those dialog's PopupModes are either set to pmAuto, or they are not “recreate brittle.” This is simply because your VCL components are running on top of the same core VCL that  the IDE is using.

Passionate producers = passionate consumers

I consider Nick to be a good friend, not only personally, but also a good friend to the Delphi community.  His zealous, passionate support for Delphi and the Delphi Development team certainly does not go unnoticed within these walls.  More than once, I've heard or have been known to say “Did you read Nick's latest blog post?”  Now, Nick, before you're cranial cavity expands beyond the point of comfortably traversing a doorway, I also have to say that Nick is most definately a human being as well.  With that, comes all the faults and foibles so many of us share.  I certainly have my fair share of faults... just ask my wife... It's probably a list in a 10meg Word document by now ;-)...

I highlight Nick because he is the epitomy of what he himself is talking about in this most recent blog post where he references this blog post by Kathy Sierra.  Nick is a passionate Delphi user.. you know the type.. “You'll get my Delphi when you pry it from my cold, dead fingers.”  You know where he got that?  From the Delphi team.  Members come and member go, but at the core and at the very heart of what is Delphi is a group of passionate, dedicated, engineers.  More than once I've heard from former Delphi team members where they say “I remember my time on the Delphi team as some of the most fun and exciting time in my career.”  Even folks who were peripherally involved, such as former Developer Relations team members.  They all say the same thing.

So why has the Delphi team continued to be so passionate and driven despite any level of corporate maelstrom-du-jour?  I think everyone of you, the loyal, vocal, sometimes irritating, often combative, highly opinionated, yet consistently unwavering and passionate.  When Borland or even the Delphi team makes a mistake, we hear about it... I mean boy do we ever.  But the flip side is also what makes working on Delphi so rewarding; when we do it right, we also hear about it!

Doesn't Borland seem to be heading down this course of “professionalism” and straying away from the “passionate” and why?  In a word... ok a symbol “$”.  In and of itself, that isn't a bad thing.. I mean what would all the recent hurricane victims do if there wasn't a huge influx of “$”?  So overall money is good... 

Borland is currently in a transition, it's growing up.  Is that good?  According to Ms. Sierra and Mr. Graham, it's not and, frankly I think I agree.  Is Borland a lost cause?  Not at all.  I think what is happening is that is that this transition is more painful because it is so committed to making it happen.  I've been saying for a long time, that Borland is too small to act big, and too big to act small.  Being a publically traded company certainly complicates things and increases the pain level... because there is this other group that is neither its customers, nor its employees... they're the shareholders.  They're an impatient lot... hmmm.. sounds familier. I'd say that the Delphi community is just as impatient (when do we get a Unicode VCL?, what about 64bit?,  Is this .NET thing ever going to be real?).. but I digress.  There is certainly a desire throughout the management ranks to rekindle some of these ideas throughout the development teams.  Will they succeed?  Time will tell.

For my part, being a torch bearer for Delphi has been a tough position to be in.  But I see a few glimmers of hope.  Recently, I was involved with a lengthly email thread that involved Rick Jackson, the Borland Chief Marketing Officer (CMO) regarding “why isn't Delphi 'just an IDE'?”  I don't pretend to take credit for this by any means, since there were many, many others involved, but the result of that thread was this posting.  In fact here's some excerpts from what I wrote:

About the Delphi customer/fan base:

“Maybe this has been said before and maybe this is news to some... but pigeonholing Delphi into the "its just an IDE" space is really, really missing the whole point.  Delphi is far more than simply an IDE.  In fact, for Delphi the IDE is merely a convenient place for all the technologies that surround Delphi to converge.  Delphi is a proprietary language (one that Borland wholly owns), it is a component framework from which many others are measured, including Microsoft .NET Windows Forms Framework. <snip>.  The Delphi customer base is a loyal, rabid fan base.  What other product has this kind of following, at Borland or any other company for that matter?  The near cult-like following that is the Delphi market is not one to be shunned or scorned, either directly or indirectly by gross omission.  It is one that should be nurtured and cultivated...from all facets of the company.”

How is Delphi different from other “IDE” products such as JBuilder, or even Eclipse?

“Why is it that Delphi seems to continually and consistently bring in a stable revenue stream?  Consider the difference between JBuilder and Delphi. Borland doesn't own the language, the compiler, or even the frameworks.  JBuilder was, in effect, just an IDE.  Of course that market suffered from erosion from Eclipse and other entries in the Java IDE market.  It was relatively easy for someone to move between the different IDEs.  The same language and the same frameworks existed and worked with all the different IDEs.  The IDEs could only compete on features, JDK support, J2EE support, etc..  <snip>”

Please, if you're a JBuilder customer, don't take this as some attack on JBuilder because, frankly JBuilder is an absolutely awesome tool!  I have nothing but respect and admiration for how much JBuilder has served to “raise the bar” among all IDEs.

My summary on what Delphi truly is:

“So, no, Delphi is not just an IDE.  Take away any one of these three things; the language, framework, development environment, and Delphi ceases being Delphi.”

Not to leave it out, but I also included C++Builder as well.

“What about C++Builder?  It is very similar situation as well.  While, yes it is based on the widely used C++ language, it is no less proprietary.  In order to properly support the Delphi VCL framework, and since we also control both the C++ and Delphi compilers, we were able to extend the C++ language in such a way as to allow the use of the Delphi/Pascal VCL framework to be used with C++.  In fact, C++Builder would have not existed without Delphi.  The Delphi compiler actually directly generates all the necessary supporting files and libraries required for a C++Builder application.  The relationship between Delphi and C++Builder is very symbiotic.  Like the Delphi market, the C++Builder market is no less loyal and near cult-like.  <snip>  Remember the open letter from the C++Builder community to Borland?  What customer base, even a C++ customer base, would take the time to create a letter and get signatures from many rather large installations?”

And finally, about the Delphi/C++Builder team:

“This rabid following both for Delphi and C++ Builder translates directly to the development teams.  Most of the members of the Delphi/C++Builder team love working on the product not only because they believe in the product, but also because they know and understand the Delphi and C++Builder market and its customers.”

So any place you see “<snip>”, they're just a few places were some internally sensitive statements were made.. but that amounts to about 4 sentences and don't really add any more to the tone of what I was trying to say.  By all counts, this message was heard loud and clear.  Within the next two weeks, corporate marketing (not to belabor the point but, yes, folks there actually is a group called “marketing” in Borland :-) was requesting an audience with nearly all the members of the Delphi team.  We sat down in a conference room for 2.5 hours where we got to explain Delphi, the Delphi team, the Delphi market, and the Delphi product to this team.  There were about 4 members of the marketing team listening and writing furiously as many members of the Delphi team proceeded to enthusiastically, passionately and fevently explain why Delphi is important.  Many points were raised, most of which I've already covered above.  The level of detail was intense.

So what about all this recent bruhaha surrounding the idea of Delphi being bought out?  Well, if I did actually know anything, I couldn't comment, that's for sure... but one thing I will say is that it is certainly fun to fantasize and ponder “what would the world be like if..?“  Then once you begin to follow that train of thought, with the logistics, the turmoil, the FUD, all of which would be obsticles that I shudder to think about it.  Maybe, maybe not..  let's move on folks.

So will this post get me fired?  I don't know, I doubt it.  I just wanted folks to know that we're not a passive team, and that there are still many champions within Borland for Delphi.  The tireless efforts of John Kaster, Anders Ohlsson, and David I, should be commended as well.  As should other Delphi team members, such as Danny, Steve Trefethen, Chris Hesik, and others for their continued blogging efforts.

The rumors are true...FastMM

There has been some speculation into the recent Delphi Roadmap announcements regarding the inclusion of FastMM4.  Some have speculated that this memory manager is only use for the IDE.  Well, that is simply not true.  FastMM4 is now the default memory manager in the Delphi RTL.  It wholly replaces the existing Delphi memory manager and will from now on be included in any Delphi Win32 application compiled with DeXter.  Yes, the IDE also uses this new memory manager and in fact, by simply replacing the memory manager in my informal tests I saw the IDE startup time drop from 25 seconds to 13 seconds... folks that is nearly a 50% increase in performance!

One thing to note about this move is that it highlights the unique relationship the Delphi Development team has with its customers.  There are very few products in almost any industry that has this strong of a community.  It is the commitment and tenacity of the Delphi community that helps make things like this happen.  So, be sure to support Pierre le Riche, the author of FastMM4, in his endeavours.  For my part, I'll be ensuring that he receives a complimentary copy of next version of Delphi... I'll also be looking into making sure he gets a copy of each version from now on as well.

Fix for the Fix..

The ever present, Chee Wee Chua, reminded me of something that you may have already encountered with yesterday's fix.  Be sure you run sn -Vr on the Borland.Studio.Vcl.Design.dll assembly.  That will disable strong-name validation for that assembly so that it will load properly.  Thanks, Chee Wee! Duh!  If that doesn't fix it, you can simply not install the Borland.Studio.Vcl.Design.dll assembly until I can figure out how to get it strong-named... I guess I'll have to see about grabbing our strong name private key from the integration team.

Update:  I've now strong named the Borland.Studio.Vcl.Design.dll assembly and updated the d2005_update.zip file.  You'll need to re-download this file.

Udpate 2: There is now a CodeCentral entry that has these updates.  I'll probably be removing the files from homepages.borland.com in a few days in favor of using CodeCentral.

Update 3: Ok... for now, ignore the Borland.Studio.Vcl.Design.dll assembly until I can get the assembly version number garbledygook figured out.

Delphi 2005 Fix Roll-up... and then some.

OK, I admit, it was getting a little unwieldy; Pushing out all these little fixes for Delphi 2005 with separate little zip files.  So i've now created a single cumulative zip file that contains all the previous fixes I've posted.  However, I wasn't content with just leaving things alone so I've also included some other little items.  Some of you have complained that in certain circumstances non-visual DB components are unselected when several are multi-selected and they are moved around on the form or data module.  You know what, you're right, that sucks!  The QC report can be found here.  So included in this roll-up is also a fix for that issue.  This may also fix some issues with collections and reording them in the structure view, but I haven't tested that fully.  So, that makes this patch a little more dicey since a lot more was changed in order to actually fix this issue.  Yes, this has already been checked into the DeXter branch and will be appearing in an internal build within the next day or so.  In fact, if you jump on this now, you may actually get to see this fix in Delphi 2005 before Borland's own internal QA gets a crack at it in DeXter... yep folks, it is that fresh!  Same disclaimers and warnings apply.  So, if you like the stinging feel of sweat dripping in your eyes as you launch the IDE for the first time after installing this patch, then by all means grab it here!

Marco Cantu is now blogging.

The venerable Marco Cantu, the perennial author of the highly regarded and extremely popular “Mastering Delphi” book series, has now graced the Delphi community with what I'm sure will be an excellent source of information and insights.  You can can get to his new blog here.  Linked and blogrolled!

Extreme Delphi...

Call me crazy... but I suppose I'm just flirting with disaster...  So by paying homage to all the extreme sports out there, I've just uploaded a new patch.  I guess you can call it Extreme Delphi.  Just like extreme sports are not for the faint of heart, so too these patches should be approached the same way.  So if you've donned your knee and elbow pads and your helmet, you may proceed to the Extreme Delphi half-pipe and get the latest installment here.  This latest patch will hopefully cover some cases of random hangs and may also serve to reduce the occurance of the dreaded  “amount >= dest - startDest“ assertion.  This latest installment comes by way of Extreme Delphi team member, Adam “Sparky” Markowitz.  So in our quest to extinguish as many bugs and issues as we can out of the next Delphi release, code named, DeXter, Adam happened across this simple but effective fix.  So, I hope you are able to catch some big air with this patch...