Re: Thinking Clearly

David Clegg wrote:
My point is that it's not uncommon for new .NET initiatives to be
strongly tied to, or only target, other Microsoft technologies such as
SQL Server.

Right, I agree.

Not saying it's bad business sense on Microsoft's part, but I tend to
find that you get better support for non Microsoft technologies from

In the specific example of BDP.NET though, the problem is that Oracle,
IBM, etc. aren't going to offer drivers there. Third party support is
just starting to take hold with guys like Core labs building drivers

IMO, the lack of documentation for BDP.NET is a killer for third party
support, but I still think it's hopeless to get someone like an Oracle
or IBM to build their own drivers.

Plain ADO.NET OTOH, will have all of these guys and more building
drivers for it.

I guess my view on this point is that it's not a clear cut winner for
Borland/DevCo here since MS has a way of encouraging other vendors to
work with them. ;)

if you don't use the {$AUTOBOX ON} directive, the ImplicitBoxing
procedure won't compile, and you have to use explicitly cast to TObject
as in the ExplicitBoxing example :-

Gotcha, thanks.

I actually prefer explicit boxing, as it makes the developer think when
an expensive boxing operation is required. As in the String.Format
method shown above, it might not always be obvious to the novice .NET
developer that this boxing is occurring.

Then again, others may find this to be unproductive, and the AUTOBOX
directive lets them choose which style they use in their code.

Indeed, that is a useful feature.

It was when developing my first production WinForms app that I really
started to feel the pain.

Sure, that's where pain becomes nearly impossible to avoid. ;)

Another area that is quite badly done in
WinForms is VFI.

I agree.

I would probably choose VCL or VCL.NET (the latter only if I was coding
an ECO app).

And only in Highlander. ;)

Native Win32 still makes the best sense to me for rich
client applications, but ECO is cool enough to make me consider .NET as
a viable option as well.

I agree. I'd like to see something like ECO for Win32 (not Bold due to
the data binding issues) and I think it's feasible to do. I have a plan. ;)

I used to say that WinForms would weigh heavily in my decision making,
due to the ECO support for it. But I think I could quite happily code a
VCL.NET ECO app, and not be too bothered about the lack of databinding

Could be.

Do you use the included Grid in Delphi Win32? I don't. ;)

Nah, I usually use TListView and populate it manually from my BOs :-)

But in this case, I was taking the lazy approach and using ECOs
databinding support.


Brian Moelk
Brain Endeavor LLC

Relevant Pages

  • Re: How would you steer Delphi if you were Nick?
    ... Adding generics, namespace and multipass compiler, ... h) Restructuring of the Datasource and TDataset and include the support of Interface ... When Rolf Lampa says that Borland don't know what they have, ... I'm sure that in some year, ECO will be very performant but until now I think that Bold is richer in some aspect ...
  • Re: Is there a future for Borland in .NET?
    ... > A detailed comparison chart would be very welcome! ... probably aren't knowledgeable enough on ECO to do it justice. ... - UML representation of your model, with full support to bring this UML ...
  • Re: Thinking Clearly
    ... ECO is useful without VCL.NET support. ... ECO supports WinForms, ECO is a competitive advantage for BDS. ... What if it provides a different but superior solution? ...
  • Re: Thank you Borland!
    ... > port the good ECO to Win32 ... ECO type support should ... The people that I know who prefer win32 could not care less about ECO ... Unicode support today and 64bits in a year or so is much ...
  • Re: [realtime kernel 2.6.21-rt2 and up] Extremely slow bootup for x86_64
    ... # ACPI (Advanced Configuration and Power Interface) Support ... # CPUFreq processor drivers ... # DCCP Kernel Hacking ...