Board index » delphi » Delphi 2005 and Delphi 2006

2006-10-05 02:33:19 AM
delphi215
I've been using Delphi since D1, but stopped upgrading at D5 because I
wasn't doing much with Delphi at that point, having moved on to Java for a
time. Once I got used to the JavaX (Enterprise) IDE, things were great.
The refactoring stuff in particular enabled me to make sweeping changes in
almost no time, when compared to similar activities in D5 and BCB5.
I bought D2005 Pro when it first came out, but then never had any reason to
use it until this summer when I picked up a new Delphi project. All in all,
it's been a dreadful experience: BDS seems to be terribly unstable, and the
refactoring stuff was missing some of the best parts that JavaX had (e.g.,
Implement Interface). To make matters worse, what refactoring there is
mostly just doesn't work (e.g., "find all references" or "rename" will miss
most of the things it should've seen) and so it can not be trusted.
Since Borland is not likely to address any of these issues in D2005, I've
been contemplating upgrading to D2006, particularly since it now include
C++. Here are my questions:
I have a number of commercial (i.e., not free) third-party controls. How
likely is it that I will be able to use the D2005 versions with D2006? Or
will I run the risk of having to buy these controls yet again?
It's my understanding that D2006 is much more stable and useable than D2005.
Is this true? Anyone?
I don't use .NET and probably won't for the forseeable future. I maintain
and extend a number of older applications that began life using D3, BCB3 or,
in scome cases stuff even older than that. In other words, I need VCL and
Win32 support and don't care about .NET. How is D2006 at supporting VCL and
Win32?
I can probably get by with D2006 Pro, but based on my experience with Java
X, where the Enterprise edition added some significantly useful features, I
was considering upgrading to Enterprise or even Architect. ISTM that
Enterprise might be worth the money because it brings along a lot of Web
stuff that might be useful someday, but AFAICT, Architect only adds the UML
round-trip stuff. Would anyone care to offer any advice on this?
Thanks for your time.
--
________________________
Michael D. Spence
Mockingbird Data Systems, Inc.
 

Michael D. Spence writes:
support new compiler versions. The language differences between 2005
and 2006 are such that components for 2005 ought to compile without
difficulty.
are still very much alive.
 

Michael D. Spence writes:
have an IFDEF missing
if you only have dcu's then yes, you'd need to buy again
runs a bit, if you have src you can install the components by hand
using the good old
var x : tmyfavecomp;
begin
x:=tmyfavecomp.create(self);
...
end;
see how it runs for you.
--
Liz the Brit
Delphi things I have released: www.xcalibur.co.uk/DelphiThings
 

Michael D. Spence writes:
projects and find myself missing stuff. Funny, it is the small details that
matter. Not Big Hyped New Technology X (WS, ECO, .NET etc) but really tiny
things, e.g. code folding, block completion (have forgotten how to type
"end;"), folder view in Project Manager, live templates (for-loop,
try-finally etc), which hardly make the top-level feature list, but have
immediate and conitnuous impact on your work in BDS. Also, the new memory
manager and FastCode functions in the RTL are definitely helping improve
performance. Old Delphi 6 benchmarks (self-rolled optimisations vs RTL functions)
are generally upset for this reason, but that is one "compatability break" I
don't mind too much :-)
OK, D2006 is not perfect, it has its share of annoyances, but they are no
more intrusive on the average than those of my previous favorite D6.
with the Win32 support in D2006.
--
Kristofer
 

To Devco,
How about making it so that when the Version of Delphi changes,
third party components still work without having to buy a version of
the component written for the new Delphi version? I know that may
kill the third party component vendors, but they can differentiate by
adding more features to their components. If they haven't added any
new features to the components, I don't see why we have to buy a new
version anyway.
The only exception I see is if somehow the VCL itself changes so that
we'll need new versions of the 3rd party components. Am I wrong in
assuming that the Vcl didn't change that much since Delphi 6 (the CLX
episode)?
Michael D. Spence writes:

In article <45246771$XXXX@XXXXX.COM>, Phillip Woon says...
registered them you most likely will have and certainly /should/ have if
you are relying on these other components, if for no other reason than
to ensure exactly this sort of thing isn't a problem).
For many components the only differences for the different Delphi
versions are in the provided package projects supplied for building and
installing.
+0.02
 

What I mean was, make it more seamless, and not depend on different
package projects to install the components. For example, instead of in
the package project it says requires rtlxxxx, just make it use the
current rtl. I know we can create a different dpk ourselves based on
the old one, but wouldn't it be great if the same dpk worked on all
Delphi versions from now on? I mean, if nothing else changed in the
way components worked, why would I have to have a different dpk for the
new version of Delphi?
How about a feature in the new version of Delphi to
transfer/copy/rebuild the third party components in the previous
version of Delphi to the new one? That would be sweet.
Jolyon Smith writes:
 

Phillip Woon writes:
correct reference : +2 on the sweet scale
< snip top-post (-1 sweet) bad phillip>
--
Kenneth Weeks
 

In article <XXXX@XXXXX.COM>, Phillip Woon says...
version installations (e.g. editor colors etc) is beyond the engineers,
so how likely is this?
;D
--
Jolyon Smith
 

But you know it could be done. it is just some registry entries, and
file copying, building, and relaxing the restriction on DCU's built on
another version.
Jolyon Smith writes:
 

In article <4525af8e$XXXX@XXXXX.COM>, Phillip Woon says...
dcu header) other times the dcu restriction will be insurmountable, e.g.
because the format of the dcu has fundamentally, or even just subtley,
changed such that they can not be used by the newer compiler/linker.
Similarly for any packages (dcp and bpl, both of which would also have
to be supported, not just the dcu's).
Oh, and not forgetting the de{*word*81} and all the IDE magic that
references DCU's.
All of which would need to support initially 2 different dcu and then N
as each new dcu version appears
--
Jolyon Smith
 

But even the dcu/dcp/bpl issue can be overcome. I am sure if they
really tried, they could make it work, but perhaps no-one has requested
it.
Jolyon Smith writes:
 

In article <4525c977$XXXX@XXXXX.COM>, Phillip Woon says...
:D
(This is one of those perennial requests that pops up periodically)
But honestly, if you have the source for components, it is a non-issue,
and if you are building serious apps with components you should have the
source.
--
Jolyon Smith