If you use a TPageControl, and you set certain Tabsheets to invisible, and then you set the OwnerDraw property to true on the PageControl (like the code listed below), you will not get the proper page selected. This is due to a new method, TPageControl.SetTabIndex, that doesn't take visible tabs/pages into account before trying to set the PageControl.ActivePage property. In Delphi 6, this method didn't exist, and everything worked fine. However, in Delphi 2005, things are different. When you set OwnerDraw, the underlying window is recreated. During the destroy of the window, the current tab index is saved off so that it can be restored when the window is later recreated. It is at this point that the new SetTabIndex method is called, and in that method, notice that no effort is made to determine that any tabs have been set invisible, therefore, the wrong page is selected.

The simple workaround is to set OwnerDraw in the DFM, or at the very least, set OwnerDraw prior to setting any tabs to invisible.

Tabsheet2.TabVisible := false;
Pagecontrol1.ActivePage := Tabsheet4;
Pagecontrol1.OwnerDraw := true;

I also submitted this to Quality Central (QC) as issue 11978. You will find a test case in that entry, too.

Lastly, thanks to both Chris Hesik (Borland) for helping me out with some debugger issues, and Rich Werning for helping debug this to the point where we could come up with a valid test case.

SQLQuery1.SQL.Text := 'select * from MyTable where ID = :ID';
SQLQuery1.Params.ParamByName('ID').DataType := ftInteger;

In Delphi 6, everything works fine. In Delphi 2005, TSQLQuery.QueryChanged has been updated to use TSQLQuery.SetParamsFromSQL internally. This means that if you don't have a SQLConnection assigned when updating the query text, then the params will be cleared. This means that an exception will be thrown when trying to do the ParamByName call.

I'm not sure that this would qualify as a bug, per se, but it definitely changes your application's behavior when all of these circumstances are present.

Thesis: I believe the IDE and personalities should be broken out into separate SKUs.

Since the Galileo IDE can support multiple languages, it might make more sense to break up the SKUs better. With VS.NET, you buy VS.NET and get VB.NET, C#, and C++ - whether you want them all or not. My thought is that you could have the IDE be sold as the base item. It would contain things like source code integration, StarTeam integration, Caliber/RM integration, Refactoring, and maybe some more core bits. The personalities could then be sold as add-on packages. Delphi would contain Win32 and .NET. The C# personality would be separate from that, as would the C++ personality. Each personality would be sold as Pro, Enterprise, or Architect. The add-on packages would plugin to the main IDE and contain all of the bits that pertain to that personality (e.g. VCL, VCL.NET, debugger, designers, etc.).

While this would be more work initially for Borland, I think the benefits would be huge over the long-run. If someone reports a bug in the IDE that is truly an IDE bug, the IDE can be fixed and a patch released and you would get that fix for all personalities. If there is a bug in a personality, just update the personality. If the fix touches both, then both parts can be updated. This independence would be ideal for the consumer. For example, if there is a bug that is causing IDE performance bottlenecks, the consumer may be forced to wait for an entirely new release of Borland Developer Studio (BDS), since fixing those problems may require breaking changes to the interface compatibility initially released with Delphi 2005. By adopting this model, Borland could start to release more frequent patches, and also dedicate resources to the appropriate codebase based on SKU sales and profitability.

I could also see a tool used in the Borland R&D department where you would have dependancy graphs used to tell the team which files would be affected by a specific change. For example, pretend there is a unit named "CoreIDEServices.pas" that needs a patch. The developer would fix the patch, run the tool, and it would say that the only file that needs to be updated is coreide90.bpl. Perhaps a VCL for Win32 bug fix would result in only the PAS file, DCU file, and corresponding BPL file needing deployment.

People have been asking for the VCL to be more of an "a la carte" model forever. This could be a step in that direction. I'm not advocating that this be done today. Iron out some of the current problems, but keep an eye on this model. I think it would serve everyone well.

The new BorCon format has a good side: it appears that Borland is getting back to their roots in making this more of a developer-centric event.

On the bad side, speakers will no longer be given their extremely modest stipend, but more importantly, Borland will not cover travel or hotel expenses for their speakers.

My take on this is that this move will kill BorCon. It looks like others are in violent agreement with me on the ramifications of this move. I'm sorry to see this happen, as I absolutely love BorCon. I sent a polite response to the Call For Papers explaining that I will not be speaking this year, nor will we be sending 2 other attendees to the event. My fear is that this will be nothing more than a glorified user group meeting. Don't get me wrong - user group meetings are valuable, but they are not BorCon. There is no accountability to keep speakers in line (what if they miss a deadline? what if they just don't bother to show up without telling anyone?). Dr. Bob - a long-time fixture at BorCon - also appears to be taking a pass on BorCon this year.

As the infomercial says, "Stop the insanity!!"... :-(

My buddy, Rich Werning, and I were talking about some possible plugins that we may develop after we convert the SDK files to Delphi:

• ZIP plugin - Scan through ZIP files to find items inside a ZIP
• Blog/FeedDemon plugin - Search your locally downloaded blog entries, and have it take you to the original author's page when an item is found
• Database plugin - Not entirely certain on this one, but if you provided a full connection string, maybe you could search a DB schema for fields/tables/etc. Or maybe even search a table for specific text.

I'll certainly blog anything we do on this front.