August 9, 2013
One of the big problems migrating old Delphi applications is they use components that aren't available any more. Which ones have caused you trouble or are blocking you?
This is a slightly unusual blog post, because it is basically an answer...
As I blogged last week, migrating Delphi applications written with old versions of Delphi (say Delphi 6 or Delphi 7) is at times challenging. Unicode migration is often at stake, and so are other RTL and compiler changes. In this blog post, let's focus on components that are blocking migration. These can be:
- Components that used to be part of the product (like Bold or the Socket Client/Server components)
- Components that were made by third-parties but shipping with the product (like reporting engines or older versions of Indy)
- Third-party components available freely, or as paid components, with or without source code
The migration can be difficult because the component or library is not available any more, doesn't recompile (in case you have the sources), or has many changes making migration difficult. With this scenario in mind, my question is simple:
Which components have caused you most trouble when you migrated Delphi 6/7 applications
or are still blocking the migration of your application?
posted by
marcocantu @ 3:22PM | 31 Comments
[0 Pending]
31 Comments
Migrating Delphi Code Which Components Are Blocking You?
Hi Marco! I notice that you mention "Older versions
of Indy". In fact Indy itself (not only older
versions) is often a showstopper when upgrading.
Indy is currently version 10, and has been since
Delphi 7, but it seems to me that it never left the
"beta stage", and a lot of the components in the Indy
suite is not mature. The number of QC reports on Indy
is numerous and the issues are not getting solved.
I really like the new IP*Works suite of components
that ships with newer versions of Delphi, but if you
need functionality beyond what is included in the
standard components, they are quite expensive (though
worth every penny, if you ask me). And even if
IP*Works is excellent components, it is quite a job
replacing Indy with IP*Works just to be able to
migrate old projects to new Delphi versions.
Best regards
Thomas Vedel
Comment by Thomas Vedel
[http://www.veco.dk]
on August 9, 16:03
Migrating Delphi Code Which Components Are Blocking You?
ASTA is our big stumbling block. Our own code is no
picnic either with well over 3 million lines. Delphi not
having a compiler directive for String->AnsiString has
essentially kept our shop frozen in time since a
retrofit would take months and a big check.
Comment by Cameron on August 9, 16:30
Migrating Delphi Code Which Components Are Blocking You?
The ASTA folks contacted to let me know they do indeed
have an upgrade path available with version 4 that is
available now. Good thing I posted here and they read it
otherwise I would have gone on unaware.
Comment by Cameron on August 9, 19:02
Migrating Delphi Code Which Components Are Blocking You?
Where I work we are finally migrating from D2007 to
D2010. We have licenses for all versions up to XE4 but
it will probably be a while before we attempt
migrating again. The problem hasn't been any
particular component but the sheer number of
components we use (30+ and this is after making an
effort to cull redundant components). I'd say about
20% are freeware/OSS while the rest are commercial.
In both cases we'd much prefer the original author
take on the responsibility for ensuring their
components work with newer versions. This isn't always
possible. Many of the components are not actively
maintained any more. Even in the case of commercial
components many of the authors do little more than
recompile a package.
Those that do actively maintain their work usually
take a few months after an IDE release before they
release updates of their own (usually due to new
features and bug fixes).
We only have one or two components for which we do not
have source (either it wasn't offered or it wasn't
worth the cost). All the others we've incorporated
into our CI server and rebuild using the compiler(s)
we are transitioning from/to. This has worked out well
as it has allowed us to migrate applications with
waiting on component vendors to officially support a
new version.
The biggest hurdle is regression testing. UI testing
is hard to automate and many of the glitches caused by
a migration are visual and can only be caught by
manual testing.
Comment by Kenneth Cochran
[http://codeelegance.blogspot.com]
on August 9, 19:25
Migrating Delphi Code Which Components Are Blocking You?
Unicode has been a disaster in it's implementation.
If Embarcadero had modified the compiler to use STRING
as an alias to TAnsiString or TUnicodeString, (and
CHAR to TANsiChar/TWideChar) migration could have run
SO much more smoothly for older components such as
dbRock's TSyntaxMemo (one of my stumbling blocks).
Just have an ANSIWindows and ANSIMessages to run
parallel with Windows,Messages and unicode migration
could have been near effortless.
Because that was NOT the way Unicode was forced on us,
I still spent a LOT of time in D2007 and there are all
sorts of broken edges in uncode strings.
Examples are easy.
Var
A : AnsiString;
U : UnicodeString;
begin
A:= #$80;
U := A;
If (A<>U) Then ShowMessage('Test 1a failed');
If ('0080'<>INtToHex( Integer( U[1]),4)) Then
ShowMessage('Test 1a Failed');
A := Chr($80);
U := A;
If (A<>U) Then ShowMessage('Test 2a failed');
If ('0080'<>INtToHex( Integer( U[1]),4)) Then
ShowMessage('Test 2b Failed');
A:= #$80;
U := #$80;
If (A<>U) Then ShowMessage('Test 3a failed');
If ('0080'<>INtToHex( Integer( U[1]),4)) Then
ShowMessage('Test 3b Failed');
A := Chr($80);
U := Chr($80);
If (A<>U) Then ShowMessage('Test 4a failed');
If ('0080'<>INtToHex( Integer( U[1]),4)) Then
ShowMessage('Test 4b Failed');
A:= #$80;
U := #$0080;
If (A<>U) Then ShowMessage('Test 5a failed');
If ('0080'<>INtToHex( Integer( U[1]),4)) Then
ShowMessage('Test 5b Failed');
A := Chr($80);
U := Chr($80);
If (A<>U) Then ShowMessage('Test 6a failed');
If ('0080'<>INtToHex( Integer( U[1]),4)) Then
ShowMessage('Test 6b Failed');
end;
Before you run it, try to decide whether there should
be any failures, and if so - which ones.
You MIGHT be able to get your code to compile, there
is a lot of room for strange unexpected outcomes with
you need to deal with 8bit data in the "unicode"
world.
Comment by C Johnson on August 9, 19:27
Migrating Delphi Code Which Components Are Blocking You?
TSVG (in APESuite) from Arcana (Sivv) makes us sticked
to XE2.
Comment by Pierre Yager
[http://www.crisalid.com]
on August 9, 20:12
Migrating Delphi Code Which Components Are Blocking You?
hello mr.
cantu, i am
very pleased
about your
attempt to
understand
your
customers.
as already
mentioned i
am stuck
because of
bold.
this is huge/
powerfull
framework
and i do not
expect it
will be
updated by
emb(would be
nice and we
would pay
money for
that), but i
expect from
emb to make
it open-
source.
there is a
petition
running from
mr. bengtson
about this
issue.
i have
already
spent
hunderts of
hours in my
sparetime to
make bold
compile and
install on
newer delphi
version. i
now need
other
interested
people to
review/
constribute/
test my
changes.
this can
only become
possible if
it gets a
place at
sourceforge
for example.
please let
us go a step
a head and
clean up the
situation.
thank you.
Comment by sam on August 9, 21:35
Migrating Delphi Code Which Components Are Blocking You?
MPHexEditor. It is a good hex editor for Delphi, but
now it's abandoned - and we really need an hex editor
in our application.
EmbeddedWB, which is a fairly more complete IE engine
wrapper, now the bsalsa.com site has disappeared.
And there are a lot of FastXXXXX functions missing a
64 bit version.
Comment by Luigi D. Sandon on August 9, 21:39
Migrating Delphi Code Which Components Are Blocking You?
This site may help someone looking for older component
updates.
Bob
======================================================
From the website:
This project gives abandoned Delphi units and
components a chance to continue as open source, with a
public home and a modern version controlled system.
Comment by Bob Lawrence
[https://code.launchpad.net/dcr]
on August 10, 02:04
Migrating Delphi Code Which Components Are Blocking You?
I agree with Sams comment earlier. Very positive that Marco really
try to understand customers needs. Sometimes it is other things
that money and the price that matters. Long term stability is very
valuable when choose platform and the components. About the
situation with Bold I am hopeful. My advice to Sam and other
customers in same situation is to watch my blog for updates and be
patient.
Comment by Roland Bengtsson
[http://boldfordelphi.blogspot.fi]
on August 10, 04:20
Migrating Delphi Code Which Components Are Blocking You?
We are finally embarking on moving our program from
Delphi 6 to XE3.
We currently use 3 third party components.
InfoPower
DevExpress
AceReporter
We are going to keep DevExpress and AceReporter but
trying to remove InforPower components.
Comment by Sukhjit Singh
[http://www.codesingh.com]
on August 10, 08:49
Migrating Delphi Code Which Components Are Blocking You?
IMHO, the main problem is a conversion from VCL to FM.
For my applications I heavily depend on:
1. Grids with tree-like capabilities (parent-child
hierarchies) like in EhLib and others and grouping.
2. Calendar displays like VPlanIt and some commercial
packs.
3. Map views.
4. WebBrowser.
It's not a problem to adjust and recompile components
even from their pre-unicode variants. But FM is an
another thing and the component market is almost
empty.
If FM is a true perspective then it whould be great if
Embarcadero provided some basic data visualisation
components: tree-grid, calendar (day/week/month) view,
map view and WebBrowser (preferrably WebKit/Chrome
based).
If you look at Web-based toolkits, jQuery (including
mobile) components just have all this now.
When I consider making my application modern and run
them on mobile devices I feel that
HTML5/JavaScript/(with jQuery, SQLite, PhoneGap...) is
the more complete solution than Delphi/FM.
Comment by Maxim Shiryaev on August 10, 09:49
Migrating Delphi Code Which Components Are Blocking You?
I am suprise that nobody mention DLangExtension.
It add very comfortable extension to delphi language:
case with string.
I have about 1000 places in my 800k sources where I use
it.
Because there is no good looking and easy to maintanace
subsitutes of this I will no upgrade until you implement
this feature (or Andy add DLangExtension for XE).
Comment by Macedonczyk on August 10, 11:55
Migrating Delphi Code Which Components Are Blocking You?
Hi,
We can't migrate 2006 to xe4 Because of the themeengine suite.
We use this components suite every where in our software...
Comment by Nicolas on August 10, 12:28
Migrating Delphi Code Which Components Are Blocking You?
Unicode is our bugbear, partially because of fear of regressions
from the change, partially because our big customers don't really
want to know about a change that increases memory usage and
potentially reduces speed for no obvious benefit (these customers
being English speaking of course). If we could compile an ansistring
version on XE3/4 then we would already be on those versions so
we could use generics etc. Instead 2007 is our main environment
still.
Comment by David Brennan on August 10, 12:29
Migrating Delphi Code Which Components Are Blocking You?
The only component "blocking" to migrate one elder project to XE4
is Halcyon, a component dealing natively with DBF's. But maybe I'm
only lazy, as I have the XE4 compatible source code of TDBF, so it
just would be a matter of hours to migrate that last project. Or to
migrate the database to SQL, which would be a far better solution.
But this is the customer's decision.
Some time ago, I had a hard time to migrate some projects from
Delphi 6 to Delphi 2010. Since that time, I only use well known and
supported components (e.g. TMS), for the remaining, I try to write
my own libraries. This made the migration of my major projects to
XE4 a snap.
Comment by Yannick
[http://www.abracadabra.lu]
on August 10, 18:54
Migrating Delphi Code Which Components Are Blocking You?
Cameron - is that estimate based on actual
experimentation?
I've migrate two different code bases from Ansi to
Unicode, and both turned out to be a few days, rather
than a few weeks. One of these ports failed due to a
datagrid component that was not available, but that was
a entirely different issue. A component was relying on
the internal workings of bookmarks in tables.
Comment by Lars Fosdal
[http://plus.lars.fosdal.com]
on August 10, 19:13
Migrating Delphi Code Which Components Are Blocking You?
If we are talking about Firemonkey then like Maxim I
am a bit concerned that grids and other advanced
controls might be lacking. I haven't tried the TMS
controls enough to find out if they will fill the gaps.
However one thing that I have tried and was definitely
disappointed with was the layouts. They seem very
anemic and in particular they provide next to no
support for automatic sizing of controls in the layout.
To give the most glaring example why isn't there a
layout that allows you to proportionally size
components? (ie specify that this control is fixed
size, this control is 30% of 'spare' width, this
control is 100 wide + 10% of spare width, etc). This
would be great in VCL but in FMX where devices have
such different screen sizes it seems essential. I'm
really astounded it doesn't seem to exist for either
platform.
I was hoping that Firemonkey would be a definite step
up from laying out VCL forms, instead it seemed
clunkier to design with. This was in Delphi XE4
Enterprise.
Comment by David Brennan on August 10, 20:46
Migrating Delphi Code Which Components Are Blocking You?
We were stuck in D2007 for a particular project due to a
component that support was dropped for. We have dropped
support for the functionality that it provides and
migrated to XE - we are currently in the testing phase.
I will probably look at upgrading to XE2, but beyond
that might be a bit challenging because of a 3 way
dependency QuickReports, QRDesign and TeeChart, but
would love to get it into XE4 (or XE5).
Comment by Alister Christie
[http://LearnDelphi.tv]
on August 11, 20:17
Migrating Delphi Code Which Components Are Blocking You?
@Kenneth If you have licenses for all Delphi version I
suggest you go to XE2 directly, why bother with D2010?
For others going to XE2+: If you don't need the new
FireMonkey, stick with XE2. There's major rewrites in
XE3 that make it slow (e.g.
http://qc.embarcadero.com/wc/qcmain.aspx?d=111942)
Comment by Jan Doggen
[]
on August 12, 07:09
Migrating Delphi Code Which Components Are Blocking You?
ExpressWeb from DevEx, discontinued long ago.
We have it working quite well on Delphi 2010 and
WebAppDbg, but haven't tried Isapi yet, and so nothing
production-ready.
It has been our main stumbling block.
Comment by Tor Helland
[http://gitek.no]
on August 12, 07:48
Migrating Delphi Code Which Components Are Blocking You?
Stuck converting Top Grid to any version of Delphi
later than 2007. Changes to the String type and
datasets bookmarks are causing problems
Comment by Peter
[]
on August 13, 07:00
Migrating Delphi Code Which Components Are Blocking You?
We are moving along because we strictly limited the
number of third party components and made sure we had
source for them - after my first experience going
from D3 to D5 and D5 to D7. We are on XE2 - no
problems with Indy (the architecture change to get to
V10 was hard but successful). Bit the bullet on
Unicode by retyping our storage strings to
AnsiString. The program modules (750K lines) compile
both in D2006 and XE2.
Comment by Tom Hansen
[http://www.drms.org]
on August 13, 21:24
Migrating Delphi Code Which Components Are Blocking You?
What about Kylix?
I have produced specialized DataSnap servers with
TProvider, TClientDataset components by using Kylix3
which runs on Linux + Apache.
Clients are using Windows.
But some codes shared with clients and servers.
So, I continue to use Delphi 7. Because Delphi 7
compiler is compatible with Kylix3.
Should I move my server programs to Windows,
or wait until Linux support again.
Other commonly used 3rd parties are DevExpress, Quick
Report and Indy.
Regards.
Hur
Comment by Hur AKDULGER on August 18, 17:32
Migrating Delphi Code Which Components Are Blocking You?
What I'm missing most is a current version of NativeExcel.
Comment by Achim Kalwa on August 19, 08:54
Migrating Delphi Code Which Components Are Blocking You?
I'm glad to know that we're not the only ones that got
stuck on an old version due to string issues. But
we've just finished the conversion of about 500K lines
from D7 to XE2 and I think we've got things working now.
We also had some old Turbopower routines, removed the
visual ones and replaced with either XE2 native stuff
(preferred) and in some cases TMS - especially the grid.
I have XE4 plus the mobile pack, but except for
playing around to make IOS HelloWorlds we have not
really worked with it yet. I plan to use it for small
IOS clients to our main program, although we only have
Professional now so we can't use Datasnap.
But as to your overall question, we are no longer
"blocked" now that we have our string issues handled.
Of course the XE4 immutable string thing makes me
nervous, although I don;t fully understand how that works.
Comment by John Mitchell on August 20, 20:54
Migrating Delphi Code Which Components Are Blocking You?
QuickReport
migrating from Delphi 2 to XE2
Comment by Mirco on August 26, 08:08
Migrating Delphi Code Which Components Are Blocking You?
How do i set a mask in an edit component?. need a
maskedit to format data input, ex. phone . date etc?
Comment by cesar molina on September 4, 14:33
Migrating Delphi Code Which Components Are Blocking You?
A list of components that have caused us problems:
Practically all open source components from Delphi 7
era, except for the trival ones (and sometimes even them)
ReportBuilder (no complete source - may as well get
the dcu's only)
KOL
Few JEDI
I am also going to twist the question, and give a list
of components that have not been problematic:
Debenu PDF
TMS Components
Raize Components
Delphi Inspiration
LMD Components
Most JEDI
Comment by B. Hunter on September 17, 02:41
Migrating Delphi Code Which Components Are Blocking You?
TopGrid is the only thing currently blocking my company from
upgrading our software from Delphi 7 to Delphi XE..
Comment by Kim Pedersen
[http://daniit.com]
on July 27, 07:14
Migrating Delphi Code Which Components Are Blocking You?
I realize this is an old thread, but I wanted to
mention that I wrote and posted a PDF on the community
site that describes how to modify the Halcyon source
code to make it compatible with more recent versions
of Delphi. It assumes that the developer has the
source code to the latest version that Mr. Griffin
released, which was just after the Unicode transition.
Comment by Tom Marchione on September 6, 20:28
Post Your Comment
Click
here for posting
your feedback to this blog.
There are currently 0 pending (unapproved) messages.
