I have an old app (Delphi 5) which I want to give it some changes.
I have set a manifest for it, but speedbuttons are not following the Windows theme. What should I do?
Delphi 5 doesn't know anything about Windows visual styles (no big surprise :-)). If you really want to stay with D5, your best bet is probably to use Mike Lischke's Windows XP Theme Manager.
Your best bet, in my view, is to upgrade to the latest Delphi which fully supports XP themes out of the box. Trying to get a Delphi 5 app to look native on modern Windows is quite a labour (I have done it myself so I speak from experience) and if you can upgrade it will be the least painful route.
Even though this post is not answering directly your question, MAYBE it will help you somehow:
I agree with others that the easy way will be to upgrade to the latest edition of Delphi. However, this is a fast (if you ignore the UNICODE conversion) but not cheap solution. A cheaper solution (and even faster) may be to 'pimp' your application using a Delphi skin package. Your application may look even better than the 'classic' Windows Vista/7 themes.
Related
There is a code base in delphi 2006 with no development for last many years. If the development needs to be activated what are the options.
Continue developing in 2006. (Not sure of IDE support etc.)
Migrate to Delphi XE2. (Not sure of what it takes)
Recode it in Java.
It seems the second option is more viable but what it would involve to do that? I read some things on Unicode support and also not sure of graphics library support.
Just to put thing in perspective, I am a Java programmer all along with experience on C/C++. However I am trying to understand it more from the perspective of what is the least resistance path to go to market strategy.
Thanks in advance.
I cannot say anything about recoding it in Java. Depending on whatever the code base does, it might be a good option, given that you say you are experienced with Java (and, I assume, not with Delphi).
Regarding Upgrading to Delphi XE2:
Check whether any 3rd party components have been used.
If not, you will probably be able to upgrade to Delphi XE2 with very few changes.
If yes, check whether the source code of these components is already available.
If not, you will have to buy new licenses of these components (and this time take the license that includes the source code!) if you want to upgrade to Delphi XE2. If you are really unlucky, the company who developed these components has gone belly up. Then you are either stuck with Delphi 2006 or you will have to find a replacement for these components.
If you already got the component's source code, you might still want to check whether to upgrade them to Delphi XE2. It might save you some headaches. Upgrading well written components is not a problem for an experienced Delphi developer (I have done so countless times over the years), but might prove nearly impossible for somebody who doesn't know the possible pitfalls.
The only breaking change between Delphi 2006 and XE2 (actually it happened between Delphi 2007 and Delphi 2009) is the switch to Unicode strings. Switching an existing code base might be painless or a real pain in the lower back, depending on how well written it is to begin with and how it (ab)used strings.
Another option you have not yet mentioned, might be upgrading to Delphi 2007, which basically was more of a bugfix to Delphi 2006 than a real release in its own right. If I remember correctly Delphi 2006 packages worked with Delphi 2007 without even recompiling.
A year ago I moved from 2006 to XE (not XE2). This was quite painless. The biggest thing was unicode. But even that was relatively easy (in my specific case probably). Most is handled by Delphi in a correct way. Biggest problems were the import components, especially when character strings were used as byte strings, which in my field (music, midi) is the norm. There is a white paper on strings conversion on Embarcadero.
I only use components with source available. If you don't, you might have have to repurchase the licenses.
It is a long jump taking 2006 to 2011/2012!
But it is possible if you consider that:
You have to convert String variables using the new conversions methods ;
You have to check all the versions between 2006 and xe/xe2 to know how the libraries have changed, bacause some have been spplited, others merged, and a few deleted ;
You have to buy/download the upgrade (if any) of your 3rd party components.
If you do that 3 things, the applications will compile just fine.
It's always easier to upgrade the IDE than rewriting the code, if there's any complexity in code beyond trivial cases like "Hello, World".
Big road blocks in Delphi 2006 might be: old components without source code, unicode issues, possible use of obsolete technologies (BDE mainly), and possible some low level hacking, like using undocumented features.
You get old versions of Delphi free when you buy XE2 licence. However Delphi 2006 is not there. Delphi 2007 is almost same (but better). It may even be possible to use D2006 binary packages with Delphi 2007.
When rewriting, first task for you is to find out what the software actually does. Line by line. Then you need to duplicate that in Java, hopefully in Java style, and then you need to verify against the old software that the functionality is actually there, duplicated.
So, you can choose between complete rewrite or something between recompile and partial rewrite, if there's problem with old components.
Read also this, old but good text: Things You Should Never Do, Part 1
That said, you need business reason for rewrite, and someone willing to pay for it.
I have an Delphi 7 Application that uses Halcyon dbf component. It works well in Windows ME.
Unfortunately in Windows XP data aware controls which are bound to Halcyon xBase Engine do not behave correctly. In addition pack command almost hangs the application. I tried compiling in XP. But no joy. Does that mean that API calls work differently? May be Data types mean different things....
Thanks for all help
A well written Delphi 7 application will work on any version of WIndows from 98 onwards. If you have managed to make an application that doesn't work on XP, then you should debug the problem on XP, not recompile and then give up. (no joy!? what? you're done already? Is that how you troubleshoot and debug?).
For posterity I should point out that if you change Delphi versions then of course, some things change. For example, If you build your Delphi application in Delphi 2009 or later, it will work properly on Windows XP, but not on Windows 98 or ME any more. But if you build your application using the same version of Delphi, why would you expect any changes in the application's bugs?
As David says; Rebuilding your application on a different computer, from the same code, and with the same compiler, produces the same binary. If you have a fundamental problem on Windows XP it is because you made a mistake in your code somewhere.
In general, windows 98/ME to 2000/XP was an easy transition, but that was a decade ago.
The only API I remember that was in Windows 98/ME that was not in XP, was the Windows 98 text-to-speech API which was removed and replaced with a different API in XP.
I believe your confusion is that windows contains something that affects Data Aware controls. It does not. Data Aware Controls are a purely Delphi thing, and they are not a part of Windows XP, they are 100% implemented inside Delphi. If you have some funny custom control that is badly written, perhaps it might not work. We have no idea what your code contains, and you haven't even described the nature of the failure.
You need to provide more information, or this question should be closed as unanswerable, or too localized. (My app doesn't work! Help! No other info given.)
Should I upgrade from Delphi 2009 to delphi XE?
As I don't use all the technologies, such as mobile, cloud computing, profiling, 64 bit, new database drivers, I don't need to change to the new XE?
What would change my mind?
Does the new Delphi IDE help me to write less code? Is the package management better?
Do you feel that the IDE gives more automation? And is it worth the upgrade?
I use Delphi XE all day every day, and I wouldn't use anything else.
It is the most stable version of the IDE that I have ever used. The compiler has had a huge amount of attention paid to it, and it works, and doesn't have the many internal failures, internal access violations, or other ways that compilers fall down, that every Delphi release since Delphi 2005 has. So the main feature that makes Delphi XE the best version ever is stability. It is even more stable than my old standby - Delphi 7. And delphi 7 is pretty stable, but working all day in Delphi 7, I did experience regular crashes, something that is finally a thing of the past, with Delphi XE. Okay, I've crashed XE's IDE a couple times, but it's rare.
The second reason is that it comes with great tools; A version of final builder, a version of CodeSite, and a version of AQTime are included. CodeSite was new to me with XE, but I love it, and now that I have used it I couldn't live without it. AQTime is an old friend of mine, and the version included with XE does most of the things that the full standalone AQTime will do, that I need it to do. The final builder version included, is also a huge time saver, especially if you have complex builds to do, including several Delphi application compiles, and an installer script to run, and perhaps other steps.
I like the code-formatter. I am not a big fan of Generics, but you can use them now, and they don't kill the compiler. I still prefer simple readable code, to a morass of generics, and I don't like the way that you do constraints with generics using IUnknown-style reference counted interfaces. Not nice, and not fun.
I don't use much of the database, cloud, or multi-tier application development features. I can't report on that aspect, but I do know that there's a lot more in the RAD XE product than any single developer, however intrepid, can probably even discover.
(Ethical Disclosure Footnote; I work for embarcadero. But even if I didn't, I'd still say everything above. Perhaps, I'd state it even more strongly.)
Does the new Delphi IDE help me to
write less code? Is the package
management better? Do you feel that
the IDE gives more automation?
No real changes there I think.
The area with possibly the most noticeable differences is generics. If you use generics at all then you should upgrade. The versions that followed 2009 have far fewer bugs and wrinkles in the implementation of generics.
In addition to what David said, there also is the new RTTI in Delphi XE which might make the upgrade worthwhile.
Besides the generics improvements, there are new features in the IDE. The addition of a code formatter, IDE Insight improvements to help you find things, integration of SVN, the reworking of the configuration manager, custom build tools, form designer changes, and more. There's also a bunch of new stuff in RTTI.
See this page for a list of what's new in XE, and go up a level from there to see a listing of what's changed specifically from 2009 to XE.
I think it's worth it...
Many bug fixes - they have focused alot on closing out issues. You cannot discount this...you'll never get any more fixes in your current version and the time saved by not having to work around just a single bug or two certainly pays for the upgrade cost if your time is valuable.
SVN integration is handy.
"Show In Explorer" from the project manager. (I don't know if it's just me, but I use this alot and it saves me time.)
If you like code formatters, there's a new option to format all sources in the project.
Debugger visualizers are kinda cool
Third Party Tools included: somewhat crippled, but very usable versions of: AQTime, Beyond Compare, CodeSite, IPWorks, Finalbuilder (depending on Pro/Enterprise)
Online help updated quite a bit
Can it help you write less code? Yes, as you can now rely on generics more due to many fixes from 2009, 2010 and XE. There's also some additional live templates added if that's what you are after.
What would change your mind? I'd say the bug fixes, additional Third party tools, and Online Help improvements make it a no-contest upgrade for the Pro edition. If you are going for Enterprise upgrade, and not using dbExpress, or other enterprise features, then it might be a little less convincing of an update depending on your budget.
The Help has been improved a great deal in XE - in 2010 it was a (bad) joke. 'Show in Explorer' is also great, although not enough reason to lay out that much money. Also much better support for REST, JSON etc. And XE just feels very mature and stable - I don't work for Embarcadero, but I use XE every day, as much as possible - unfortunately I am currently working on a project that uses components compiled for Delphi 5 without source code so I can't use XE for everything. There are some VS guys in my shop who think 'Delphi is Dead' and give me some grief - I am proving them wrong with XE...
I started occupational programming with Delphi when the Turbos came out , and have licenses for Delphi 2006 Turbo Pro and Delphi 2009 Professional. I have been asked to support another in-house tool, written by another occupational programmer, who has since retired.
It's a Windows program, but it was developed with Delphi 6 using the CLX library rather than the VCL.
From what I gather, the CLX library was QT based and was removed prior to Delphi 2006.The support only consists of a few bug fixes and some minor tweaks, so I would rather not port the code to VCL, if i can avoid it.
Is it possible to install CLX support into either Delphi 2006 or 2009?
Maybe not a direct answer but if you upgrade to Delphi XE, you will also get license keys for some of the older versions of Delphi down to 7, and Delphi 7 included CLX (it was dropped in Borland Delphi 2006).
The short answer is: no. Unfortunately I don't know any long answer which could tell you how to workaround this.
No, you can't add support for CLX to your other Delphi versions.
If it's in-house software, then your company should still have the in-house Delphi installation used to develop it. Multiple Delphi versions can co-exist on the same system; install earlier versions before installing later versions.
If the former employee took that installation with him when he left, can you get it back? I wouldn't expect it really belongs to him anyway. You said he retired; that wasn't a euphemism for died, was it? If not, then you can still contact him.
If there isn't an easy way (and I suspect that there is not), you may need to continue using D7. D2009 is going to introduce the hassle of Unicode, and even going to D2006 is going to cause problems with 3rd-party libraries.
You could run both versions of Delphi on the same machine, but another option would be to use a VM for the legacy development. Either set up a new instance, or you could use the VMWare Converter to convert the other developer's entire machine into a VM image, which you could run on your machine, via the free VMWare Player.
BTW, VMWare Converter is a GREAT way to preserve old environments, to allow maintenance on older software that really needs to use a particular Delphi version, on a particular OS, "just like I left it". If you have a bunch of dusty computers under your desk, consider this option. VMWare Converter is the only tool I know of that will easily convert a physical machine to a useable VM that will run anywhere.
I developed an application using also third party components (developed on D7, WinXP).
When I deploy this application on XP everything works fine. When I run it on Vista, the application cease to work properly:
Toolbuttons on Toolbar does not size equally, when I switch visibility on/off, thats why (third party) skins are not properly nested and then it looks ugly. It bothers, it's annoying but it is not fatal as the next point.
Third party text processing component cease to write. I wrote some routines, which allows writing on this component under certain circumstances. It was a big shock to find out, that I can not write anything (probably these routines return false for writing, but I do not see any reason, why on XP it should work fine, but on Vista not).
The application runs (at last), but not in the way, like it supposed to !!!!
I would like to debug it, but how?
Should I install Delphi 7 on this problematic Vista computer and compile project on it? (this is it, what I am going to do...)
Is it problem of third party components?
Is there any possibility to use some compiler directives to ensure, that application will run on Vista flawless ? (be honest I do not know if Vista is to claim in general).
Is Delphi 7 too old for Vista?
NOTE:
When I run the same application on Win98, I get error message about invalid floating point operation...
Has anybody solved such problem?
Thanks
If Delphi 7 is compatible with Windows Vista, it only really means one or both of the following:
You can run Delphi 7 on Windows Vista
Delphi 7 can be used to write programs that can run on Windows Vista
It does not automatically mean that
All programs I create in Delphi 7 runs on Windows Vista
All programs I create in Delphi 7 runs properly on Windows Vista
Let me give you an analogy: That you can use a hammer to get a nail into your wall without hurting yourself does not mean that no matter what you do, you won't hurt yourself.
If your program, either in your own code, or as part of the third party components you use, use parts of Windows that has changed or possibly even been removed (although that's far less), then you need to fix your program, there's no way around it.
There's no silver bullet either, so no compiler directives or whatnot. The most I can think of is that perhaps Windows Vista has some compatibility settings for the shortcuts that might turn on some XP-compatibility layer in Vista that fixes the particular issues you have.
However, the only long-term solution is to change your program so that it is properly compatible with Windows Vista, and probably Windows 7 as well.
Since you say you're using third-party components, have you verified if the particular versions of them that you use happen to be Vista-compatible? You need to go check on the websites of the authors to find that. Perhaps it can be solved by simply upgrading those components.
However, it might also be that you need to make changes to your own code.
The best way to move forward is to install Vista and possibly Windows 7 and start debugging to try to find the underlying cause of the problems.
Note that just installing Delphi 7 on Vista and recompiling will not fix anything. The compiler does not produce a different program if you compile it on a particular Windows version. Only changes to the code will apply the necessary changes.
The easiest solution is to make sure your Delphi version and 3rd party components are Vista compatible.
Delphi versions since 2007 are.
Recent TMS, DevExpress and Raize components are.
The hard solution is to do all the changes yourself.
Be prepared to modify the VCL sources from 2002, carefully modify them to bring them up to Delphi 2007 level.
Then do the same for your 3rd party components.
--jeroen
I never really investigated, but I noted that in some apps that I have, in all skinned modes (XP-teletubbie, and Vista/W7 non classic) I had paint artifacts with all delphi verrsions if I put buttons and labels directly on tframes or ttabsheets.
The problems went away when I inserted a panel inbetween.