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.
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 know a lot of questions have been asked about VB6 migration (and I've read most of them), but I'm still not entirely certain on what the best way to go about this is.
We have a client that we built an order tracking application for about a decade back and they came to us this week saying they were having some issues with it. The app was written entirely in VB6, which has been something of a hassle as tracking down the necessary tools to work with a project so old took some considerable effort. In an effort to make any future maintenance less of a headache, my boss wants to pitch the idea to them of updating the app to .net and wants to know what exactly that would entail. I've never done anything like this before, but what I've read (both here and elsewhere) suggests that Microsoft's "auto-update" from VB6 to .net simply doesn't work very well and I'd pretty much have to rebuild the app from the ground up.
To get to the crux of my question: is this the case? Would I pretty much just need to rewrite it, or is there another means of going about this that could/would save me a lot of time/effort?
Any insight would be greatly appreciated.
VB6 and VB.NET are radically different. The syntax has changed, and so has the underlying structures, forms, custom controls, and almost every single aspect you can possibly think about.
A complete redesign and reassessment of needs and functionality is imperative. With .NET the plethora of new libraries and features supersede the antiquated VB6 libraries, OCXs, etc. Also if you feel bold, you can migrate your code to C# and other CIL languages aside from VB.
Out of hand, the Microsoft migration tool will not do much. Moreover, it also depends on whether you have your business logic well separated from your GUI. Otherwise, it will make it even harder. Depending on the size of your application, it might make it quite expensive. Another possible solution you might consider is to run your app in a virtual environment or on a remote app http://technet.microsoft.com/en-us/library/cc730673(v=ws.10).aspx that will ease the deployment pain.
I have also researched this topic.
Try the smart rewrite solution that converts 95% of the code automatically.
first, run your app through the assessment wizard to determine estimated costs and resources needed.
http://visualwebgui.com/Gizmox/Solutions/InstantbCloudmoveb/tabid/744/Default.aspx
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.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
How to improve our productivity when starting new project using Delphi?
For me, I create a template project including splash screen, primary data module with default component and all data-aware subroutines (open, close, query, default when failed to open DB, etc), and save the template in my repository. (I use all my own frames and unit in the project, so everything always be created automatically when I choose : New Project and choosing my template.)
Questions:
Is there any other way to improve reusability using Delphi?
What free open source framework (like Jedi) / IDE PLugins (like GExpert) you think is best to use using Delphi?
Pardon me if this question has been asked before.
For Q1: Use mature libraries which do for you the grunt work: DevExpress -or- TMS for UI (JEDI's JVCL also is very good), FastReport for reporting. Choose also a good connectivity framework (it depends on your db back-end) in order to have many day-to-day tasks solved OOTB. Also, if you're familiar with OPF have a look at InstantObjects. I heard that's very nice.
For Q2: See the IDE enchancements from cnpack.org
Also it will help to slowly build your own specialized framework/set of tools. Not something very big but as a quick way to get some things done in your way. Always try to design for reuse, even if it takes a little bit longer in the beginning.
For larger applications, the key to productivity is to work at a higher abstraction level than data module and database.
The database has a small set of types. In your domain you are likely to have default mappings from domain types to database types. You'll also have validators and formatters for them.
You'll have default reports, filters and search (windows, panels, sql queries) for your domain entities. You'll have role-based access control to them.
Take a look at domain-driven development.
One of my big gains in reusability in recent years has been moving to an ORM layer (I use tiopf) to separate out my business objects from the database.
As an example, I have db persisted, background threaded email objects. To add them to another application, I add in the required units and add a few lines of configuration (table/field mapping). Similarly I have user objects, generic lookup lists and the like all of which can be added to different projects for the price of initial configuration. This works on different databases without any changes other than configuration.
tiopf is my ORM of choice (read my overview here) but there are numerous others.
Defining the exact range of applications you want to make is a good first step. Improving productivity is nearly always related to specialization. General tools is just an extremely small percentile of productivity. I'd rather search (or make) specialized frameworks in my line of work if I really wanted to boost productivity.
I don't use GExperts, or another plugin. I don't benefit greatly (being able to grep just fine on the cmdline) in productivity, and any crash that can be avoided due to problems in the plugin is then a pre.
I used ModelMaker with Delphi. It is really nice tool that lets you draw objects and then can generate code based on templates you write.
It can speed up things when there is number of similar classes in project.
For Q2: GExperts is useful. The grep search comes in particularly handy, although the search / replace can cause odd side affects (inserting characters it shouldn't!).
I know you mentioned free / open source, but Castalia is very good. The refactoring methods work well and I like the structural highlighting, which makes it much easier to work with code (I did originally use CodeRush for this but it went Visual Studio only). The Bookmark stack is also handy for quick going back and forth through code.
Also, if you are a team, look for ways to improve your development process. Besides using Delphi as your implementation language, what are your project management methods? What source code management system do you use? What is your build system? Do you use automated testing methods? etc.
When I introduced Scrum at a previous employer, we got an almost immediate 50% improvement in team productivity. So check out the various Agile methodologies.
For true reusability, try to think in interfaces and try to black box as much as possible. Patterns are everywhere, research them and put them into practice.
When dealing with objects, as much as possible use the abstract, or an interface rather than a concrete implementation. Just be careful of taking this too far. Too many abastractions can add complexity and make debugging harder.
Units containing your business rules should be used by your gui. Units containing business rules should never themselves directly use gui units.
When I ask questions like this about "what is the best thing to do or to use" they are quickly removed from the site by the moderators.
In my opinion, you are right to use the sample template. Also #John Thomas is correct. But you can go beyond:
Use a template for database procedures and functions to work with requests;
Try to put the most of the database logic inside the database using stored procedures and functions. This way you don't have to worry about selecting what is common use and what is specific to current project;
Use a template for main menu and main screen;
Instead of crating many windows, create one TFrame for each module of your application and reserve a place in the main screen to load them. Create an object of this frame in memory only when the user clicks it's menu. This way, your system gets faster and more memory economic;
Reuse those frames by creating base frames with the common functionality and layout and them create new frames descendants from it.
Just great!
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.