Related
I have an old Delphi application and i want to migrate it to the newest Delphi version. The problem is that the application is huge and migrating whole app at once would be too complex. I wonder what is the best approach to do this... Maybe form by form, placing a form into a dll and then using older forms in the new Delphi app and replacing them one by one (after clients confirm one form is working ok to continue with the next one). Not sure if this would be possible at all...Any other ideas?
I presume that based on your comments you do not have comprehensive test cases. In that case, you are simply in a world of pain, and there is nothing that will truly mitigate that. Without test cases, any approach you take will generate errors and bugs that will take you quite a while to catch them all. Build that into your expectations. In fact, with those as your expectations then you need to schedule a large testing phase and maybe that is a good approach. Upgrade all at once and test over the course of a few months.
You could first identify all 3rd party components that will eventually be needed and upgrade them to the latest version one at a time. That way you can at least identify bugs in a controlled manner per 3rd party component. Again, since you are relying on manual testing, this also will be error prone, but maybe you can focus on areas that use the upgraded component preferentially.
here my advice.
Before you start migrate, do a refactoring of your existing source-base.
1.) Remove un-used stuff.
2.) Try to move as much as possible to standard delphi components.
3.) Remove "un-used" units from your uses-statements.
4.) If needed, try to do some layering (App-UI,App-Logik,DB-Layer,Libraries)
5.) Look for 3rd-Party Components/Libraries, which might be not needed anymore in the latest Delphi Version, because the functionallity is now included in Delphi. If you spot such components/libraries, try to encapsulate them.
Now you have a new version of your software (still in the old delphi). Test it as exact as possible (Unit-Tests would be perfect).
If this is done, then you start to migrate to newer Delphi. I recommend to do it in one go (instead of dll and one by one).
I do not think there is enough information presented to give you specific advice.
My answer would be to bring in knowledgeable experts to look at your code, talk to your staff, look over your documentation and tests, and then present you with smart options. This can likely all be done via Zoom/Skype online. If you think about how much money you are going to end up spending on the conversion, and how much money you will spend on fixing problems because you went off in the wrong direction (and how many customers you could lose due to bugs/performance issues) this would be an extremely cheap investment.
There are a number of firms with Delphi experience that could help you. (I do not work for one and this is not an ad.) There are some well-known Delphi consultants that would likely have some free, or small flat-fee type, initial conversation.
If you are using a version before the Unicode switch in Delphi 2009, there are a number of online resources to assist. Delphi Conversion Unicode Issues
If you want some real-time advice and chatting about specific issues, check out a Telegram server dedicated to Delphi programming with nearly 800 members. There are nearly always some Delphi experts online answering questions. https://t.me/delphidevelopers You should be able to get some consultancy contacts from that server.
I have inherited a legacy app written in C++ (VS2003) MFC that was not updated in years.
I have limited experience in C++, being mainly a Delphi developer. All other apps of the company are written in Delphi.
Going forward, I see a few choices:
1) Keep the app as is and become a C++ MFC developer. But I don't like the idea of using an outdated technology (MFC) for years to come, trying to keep up with new Windows versions and UI standards. It somehow feels like making several steps backwards and I don't think this is the best way to go (?)
2) Convert the app to any modern UI technology offered with C++ and become a C++ developer, but at least using modern technology. Might be a lot of work, not sure.
3) Rebuild the app from scratch in Delphi, where I will be a lot more productive thinking about the future. It's a lot more work right now, but it might pay off later.
Obviously, I personally prefer 3) but I would like to know from your experience which way is the best for the product.
It's a long term decision to make and I will have to stick with it, therefore I don't want to rush into one direction.
(I have intentionally not tagged this question as C++, trying to get answers from Delphi developers in similar situations)
EDIT:
Thanks to all for your answers.
After learning that it is possible to switch to C++ Builder with a MFC application, this seems to be the best solution.
It combines the least amount of modifications to the current app with the possibility to go forward using the VCL for future GUI improvements.
EDIT2:
It's not possible to combine MFC and VCL in one app, therefore C++ Builder won't be an option. (thanks David for pointing this out)
In general everything depends on how complex the application's logic is and what is the projected life time of the application. If it requires maintenance for another 20 years, then
I'd rewrite the UI in Delphi and move the business logic into C++ DLL (for beginning and possibly rewrite it in Delphi either). Then it can turn that the application can be maintained this way for another 10 years and relatively easily ported to other platforms if needed (less work would be required).
This is a hard question to answer generically. Can you provide any more information about your specific app? What sort of technologies does it use? How separated is the UI from underlying layers and logic?
Some general-ish points though:
Rewriting an app is generally a bad idea, for the following reasons:
It's surprisingly hard to get an accurate idea of the requirements. You're sure you know what it does (after all, it's right there in front of you!), but then you release your rewritten app and you get complains that functionality you didn't know was there is missing, that functionality is harder to access if you've changed something, etc.
It introduces bugs. The code, especially if it's old, is full of bugfixes, tweaks, etc. You will lose all that if you rewrite, especially if it's a different language and you can't reuse any code at all.
When using a different UI layer (MFC to something else) separating the UI can be very hard if the app wasn't written well in the first place. You will probably end up doing a lot of refactoring, even if you don't do a complete rewrite and simply move from MFC to 'something else'.
MFC is kept up to date (ish) - there is a MFC Ribbon control, for example, as well as modern controls and Windows 7 support. The least amount of work, probably, would be to upgrade to a modern version of Visual C++ and become a C++ developer. However, you're quite right that MFC is an old technology and is unpleasant to use, not only because of its design, but also because modern form designers etc are great to use.
You're a Delphi developer. Without rewriting the entire thing, you could consider migrating to C++Builder. Consider this:
You can use old versions of MFC with C++Builder. I've never done this, since the VCL is miles ahead, but it's possible and there are a number of people who do it. Check out this forum, for example. (Credit for that link: this thread.)
Once you have your app compiling and working with C++Builder, you can start migrating to the VCL. As a Delphi developer you'll find using this, even with C++, very familiar. It's the same form designer of course, and using it from C++ is pretty simple - it's a different language but code is often line-for-line translatable. Everything you're used to (DFM files, units, event handlers, etc) all translate.
Not only that, but Delphi code can be used in C++ projects. Just add the units to the project, and in your C++ code include the auto-generated unitname.hpp file. You can't (easily) use C++ code from Delphi, but you could create new modules in Delphi and use them from C++. As you do this, more and more of your app will slowly become Delphi code - ie, you don't need to rewrite in a different language all in one go.
As a Delphi developer, I'd suggest going the C++Builder route. Get it working with MFC, and then migrate your windows to the VCL. At that point, you could start rewriting modules in Delphi, or you may find yourself comfortable enough in C++ to continue developing as is.
Edit: I noticed in a reply above you like the idea above of making it a C++ DLL. The link I gave a paragraph or two above of using C++ object from Delphi might be more applicable than I thought. It would fit the RAD Studio (mix of C++ and Delphi) method as well.
Keeping the app as is, tying you to MFC, is likely not very productive - You'll need to learn a GUI toolkit you'll most likely never use for something else (Delphi is great for GUI, MFC doesn't even come close IMO), in addition to a new language.
That leaves you with the choice of rewriting it in a somewhat unfamiliar language using an unfamiliar GUI toolkit, which'll take a lot more time than rewriting it in a familiar language using a familiar GUI toolkit. So you should just get started porting this to Delphi.
Rewriting C++ code in Delphi isn't as easy as you think. A better way to rewrite it is by just redesigning it from scratch, without looking at the old code. Feel free to look how the old application worked, so you can rebuild it. Just don't look at the code. That way, you should get a more modern result.
Of course, if you use the RAD Studio then you have both the C++ as Delphi compiler, thus it should be able to continue to develop the C++ application, although this means you have to learn C++. Then again, any good programmer should be able to just move to another programming language and learn to use it within 2 weeks to a month. C++ can be complex but still, learning C++ and then maintaining the legacy app should take a lot less time than a complete rewrite.
Do keep in mind that any generic C++ application should be able to be compiled for any platform, although the MFC will probably restrict this to just Windows. Still, it's a language that has an even better backwards compatibility than Delphi!
But to keep in mind, will this app run on a different platform in the future? Should it become a .NET application? Or run on Linux? Should it support tablet computers? Android? Your choices today might be outdated again in two years. And since Delphi has a bit uncertain future right now, mostly because C#/.NET became so popular, you might have a more safe bet with C++. Try to replace the MFC libraries with a more modern UI technology, preferably one that's available for multiple platforms, and think very, very well about the future usages of this application.
In general I'd say:
If it's a tiny tool application, and it takes just a couple of days to do a full rewrite: go for it. Don't waste your time creating dll wrappers or to interface with the existing code in other ways. Just do a full rewrite and be done with it.
Otherwise: you'll probably be making changes in one specific area of the application at the time only. Unless the code is a complete spaghetti, you could even get away with making some local changes without fully understanding the implementation details of the rest of the code.
In any case, you need to invest some time into understanding the application and its language + frameworks.
You have a great opportunity to learn C++ and MFC. Take advantage of it. When Delphi goes astray you will have the required knowledge to keep on coding with a language that won't go away so easily, and you can even broaden your development horizons to areas Delphi (and C++ Builder) will never reach. MFC is no more outdated than the VCL is (although I agree the original design is worse).
Good UI programming has nothing to do with the ability to drop controls on a form visually. Many great applications are not built that way. Actually, trying to rewrite it in Delphi could bring you issue in the future, as long as Embarcadero delivers slowly, and without a credible roadmap.
I recommend
1) Keep the app as is and become a C++ MFC developer. But I don't like the idea of using an outdated technology (MFC) for years to come, trying to keep up with new Windows versions and UI standards. It somehow feels like making several steps backwards and I don't think this is the best way to go (?)
Since MFC is well supported and keeps going with the time. MFC is also a what-you'd-call intrusive framework, meaning that the framework dependencies are usually not easily refactored. (The author of CPPDepend published some nice stats on that IIRC, but I can certainly vouch for this from my own experience with large MFC applications).
If you're gonna rewrite to any modern UI framework, don't code the UI in C++ (judging from the fact that Delphi is an option, it is not about realtime visualizations or something like that).
(I'll unask the unasked question here: I you're gonna rewrite, XXXXXXXXXXXXX?) please gentle(wo)men, let's not do the flame
Does the app come with a descent amount of automated tests? If not you're pretty much stuck with option 1 and hope for the best. If there are many tests you can do a lot more with the code without breaking all kinds of things you didn't know were there.
I'm in the middle of sorting out a nested set of if/then begin/end pairs, and missing the heck out of CodeRush's structural highlighting (which I used to have in Delphi 6, and loved). Is there a freeware IDE add-in out there that will accomplish the same for Delphi 2007?
Note: I know Castalia does this as well. I tried Castalia a while back, and had trouble w/its stability; also don't really feel like spending $99 at the meoment for just this one feature, (plus maybe the split-editor feature). I may anyway, but thought I'd ask here first to see if there are cheaper alternatives.
Thanks in advance.
cnPack has a feature like this (draws a tree showing the structure)
Step 1: edit the code to simply visually align the nested blocks according to good practice, with consistent indenting etc.
You might be able to use a "pretty printer" to assist in this one-off activity. There are lots of these out there (including one built in to Delphi 2010 these days, as of Delphi 2010, which is no use to you I imagine). I don't know how many of them work on code snippets, rather than relying on complete units however.
Step 2: if the number and level of nested blocks is such that it remains confusing and unclear, refactor to reduce the number and level of nesting.
The result: code that is readable in any medium, without needing to lean on IDE confections which won't always be available to you (e.g. if using SVN and viewing diffs via WebSVN or some other collaborative code review process that doesn't use an IDE with lots of bells and whistles installed).
GExpert is my favorite addin for Delphi. It is free, mature and I use it every day.
Some highlights:
VERY fast search in source. This is so valuable for me.
Convenient find function dialog by typing some characters en the name.
Match parantheses, begin/end, and some other types.
Everything can be handled by a shortcut.
Many other things that I don't use so much at the moment.
I need to speed up my coding, too much work, so I need be able to generate code.
Any tools, any ideas?
Delphi includes Live Templates, a completely scriptable and configurable system for generating code constructs of any size or complexity.
Live Templates are, in my view, one of the more under-appreciated features in Delphi.
Find out how to use them at: http://delphi.wikia.com/wiki/Delphi_Live_Templates
and
http://delphi.wikia.com/wiki/Live_Templates_Technical_Info
Live templates are completely scriptable, meaning you can write Delphi code to do whatever you want with them.
An extendable example can be found here:
http://cc.codegear.com/Item/26420
Not a very good idea IMHO. If you need generator, then probably you have lots of code that looks very similar, so instead of generator, better thing would be to rethink and refactor code you have.
That should result in less code that is easier to maintain and less code in future for similar tasks.
If you are doing database application, then you could use some good visual SQL query builder to help you create queries. That is part that Delphi was not very good (I don't know if it improved in D2007 and D2009)
EDIT - Regarding SQL generation
There's lots of comments about query builder.
Well, I suppose I'm spoiled. As I remember, Delphi before version 6 (or maybe even 5?), had decent visual query builder. I had 0 (zero) bugs in SQL when I selected fields in query designer, opposed to writing SQL by myself.
SQL is just string in Delphi, there is no compiler checking, so this was the best way to ensure that SQL is correctly written.
If you mean something like a modeling tool, you could try out ModelMaker.
Rather than trying to code generate, you should probably just obtain code to do the bulk of what you want to do.
There are hundreds of free products at Sourceforge for Delphi.
And there are hundreds of thousands of code samples at Google Code Search that you can use.
Plus lots thousands of free or purchaseable components at repositories such as Torry's Delphi Pages or Embarcadero's Code Central for Delphi
Using components already made is the fastest way to speed up your coding, and to add capabilities that you would never have been able to.
For me best way is by creating custom components, and then create designer for this component.
I have find that i spent most of the time writing code that read/write values from controls. So i created control that can read, write, validate values, and automatically fill form or stored procedure or directly generate SQL and execute.
Custom designer allows you to setup all properties easy. Now i don't write code for such trivial task i just put control , open designer and set properties and rules that must be satisfied.
ModelMaker Code Explorer speed up my coding in times. It has a nice hotkeys for synchronising implementation and declaration, so if you changed one, you don't have to search for it pair. Also, very nice feature is, method editing dialog. And many more.
Have you tried GExpert? It is a set of tools built to increase the productivity of Delphi and C++Builder programmers by adding several features to the IDE. GExperts is developed as Open Source software.
Other alternative is using project template by saving a framework into the IDE Repository, create your own components and frames.
I wrote a code generator calle CodeTypo. I'm used it in many production environment. You can find it here: http://dade2000.altervista.org/index.php?page=CodeTypo
It's still in beta phase but is usable and reasonably stable.
I'll migrate all content of this old site in the new one (www.danieleteti.it) in english. And I'll add some other info about CodeTypo and code generators.
The thing that sped up my Delphi coding the most was getting CodeRush for Delphi (via a DevExpress VCL subscription for Delphi 5, 6, 7) and setting up a ton of templates.
I am re-writing and/or consolidating a bunch of my "app framework" classes (basic mainform, about box, locking routines & purchase linking, auto-update, datamodule initializer, etc) -- Basically, I have a number of small potential shareware apps that I'm wanting to get out the door, and want to re-use code where I can, as well as build a framework for later apps to save time.
In one app I have auto-updating, I'm using LMD's WebUpdate, and am reasonably happy with it, but given that I'm re-vamping everything, I thought I'd see what the consensus is for "best approach" on this. I don't mind paying for commercial, nor using open source if that's best... just would rather not reinvent the wheel. (I've read: Delphi: How do you auto-update your applications?)
What is the best Auto-update component for Delphi Win 32 apps?
I use TmxWebUpdate. It's free, simple and easy to customize. I also own TMS Component Pack with TWebUpdate, but never really found a good incentive to switch.
I use TWebUpdate from TMS Components and am very happy with it. I haven't used LMD so unfortunately am not able to provide a comparison.
TMS also supply a whole raft of other components so if your re-writes require any else, especially if you want some shiny UI enhancements (TMS have a range of iPhone-style components) then the website is certainly worth a visit.
They seem fairly active in their support forums (although I haven't had need to use them for the WebUpdate component) and they have a fairly regular release cycle.
I have heard good compliment about TWebUpdate from Tmssoftware
also torry has much components for the same job, some are free and others are commericals.
Now what's the best?, it's depend on your needs, you already using one from LMD, which is a good company and I have very good experince with their components, but never used this one.
If you need a specific functionality, or you have some problems with the current one you are using, it's will be better to list them, so you will get a better answers, but it's hard to define the best, because every one has different experience and views.
I use TWebUpdate myself. It works, but the docs are a bit limited and it seems a bit buggy sometimes.
I have looked into LMD's (I have their full component pack), but it seemed to be much more limited than TWebupdate.
I'm also using TWebUpdate, and have to echo stg's comments on quality of support (good), and quality of documentation (spotty -- it's old, and doesn't always reflect their new features immediately).
You'll also find some places that stress the "roll your own" approach.
Remember that part of the auto-update issue is the tools that you will need to create the update "package" at your end. TMS Software makes a tool available for use with TWebUpdate, and it's reasonably well done. In my case, I'm "misusing" the component to deal with multiple files so that I can refresh additional related libraries, text files, etc. The update builder tool isn't really good for that. So there's some manual editing. But the updating part works well.
I'll also add a caution that you need to be careful with updates in Vista (and probably Windows 7). Writing to the protected places in the Program Files hierarchy was problematic for me. You may want to check that out with whatever component you use.
Have you considered Appwave from Embarcadero. It's not free and I don't know the price.