Re: The problem of Delphi

From: Allen Bauer (abauer_at_spicedham.borland.com)
Date: 08/11/04 

Date: Wed, 11 Aug 2004 11:50:20 -0700

> I'm sure you know it better than me, and want simply to know,
> whether I know what I'm speaking about ;-) However, I'm ready
> to give you some explanations:

I presumed you knew about which you spoke. I just wanted to take the
opportunity to get some feedback.

> 1) All WinForms controls have underline OS controls, there is
> no concept of the TGraphicControl. This makes it possible to
> invalidate small regions, not entire controls (see InvalidateXXX
> methods). More over, it makes it possible to implement Tranformation
> property for each control (AFAIK this will be done in .NET 2.0).
> With Transformation property you are able to scale, rotate or
> move your controls relative to parent controls.

TGraphicControl was introduced as a lightweight control in order to
conserve, what used to be, a precious system resource, window handles. Why
burn window handles for the hundreds of labels on a complex input form? Of
course that is less of an issue with current OSs, but I think there is still
validitiy in conserving them. Also, you *can* invalidate just the region of
the TGraphicControl by calling TControl.Invalidate. That should only
invalidate the rect that is the control.

> 2) Management of control layout is organized much better.
> There are SuspendLayout and ResumeLayout which make it
> possible to set control properties in a single transaction an
> thus overcome many align problems (bugs) of the VCL.

Yes, there are some aligning issues with VCL (are they reproduced and
reported into QC? ;-)... Have you looked at TWinControl.DisableAlign and
TWinControl.EnableAlign?

> 3) WinForms uses GDI+ graphics, which is more consistent
> and powerful than GDI which struck roots in VCL. WinForms
> controls do *not* maintain Canvas property. You get Graphics
> object only in the context of the Paint event. If you need you may
> call CreateGraphics method to get temporary Graphics for drawing
> at any time (on any event), and it does not interfere with other drawing.

This is just a different design philosophy. GDI+ thing is a bit of a red
herring since it was not available at the inception of VCL. Also, GDI+ is
less performant than straight GDI calls. Although, I think that will
eventually change. Finally, a critical design goal of VCL for .NET was to
allow the easy movement of application level code from native Win32 to .NET.

> 4) There are asynchronous delegates in WinForms controls,
> BeginInvoke and EndInvoke methods. WinForms is better
> for multithreaded applications.

True. Again, VCL's inception was on a platform that didn't support a good
threading model. Also simplicity was a critical design-goal as well.
WinForms is in the enviable position of being able to look back. VCL is
not.

> 5) WinForms terminology is more clear, consistent and right.
> Somebody may say that it is a refactored version of the VCL and
> I would agree with this point of view - they both have the same authors.

I have to disagree here. The naming convention of delegates and events are
completely backwards, IMO. You should hook your event handler to an
"OnXXXX" event. *NOT* call an OnXXXX method to fire the event.

> To some extent, yes. This means creating dev. tools, which are
> not only ready for future .NET features, but making a scientific
> devision which will push .NET and investigate directions of
> .NET evolution.

We view .NET as a *platform* and not as some tacked on technology. Windows
itself is a platform, and within that platform it offers various
technologies, one of them happens to be .NET. As for going above what MS is
providing, have you seen or used the DBWeb controls for ASP.NET
applications?

> You should have started creation of Delphi
> for Longhorn, not doing it half a year before Longhorn release.
> You should be ready to explain your position e.g. on the following
> project http://research.microsoft.com/Comega/ and know, how
> its concepts could look in BDS 4.0. You should keep step with
> Anders in understanding of the programming languages evolution
> and the current software revolution.

Are you absolutely sure that we aren't? We don't talk about future
developments, even to those under NDA. The next release of Delphi, which
will be extensively covered at this year's Borland Conference, is the only
thing we'll be discussing. http://www.borland.com/conf2004.

> Sorry for saying "you should", I know reality is different and
> you do your best to create nice things for Delphi community.
> But IMHO you should target Borland on all .NET community
> and on the future.

I took the "you should" as simply being your opinion, to which everyone is
entitled ;-).. 

-- 
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corporation.
http://blogs.borland.com/abauer