how do you develop and test components for all IDE versions? - delphi

The following question has had me wondering for some time now as to how 3rd party component developers are able to ensure there components are compatible with all the various IDE versions?
I am just a single developer who uses Delphi XE and occasionally Lazarus, if I developed some components in Delphi XE how would I ensure they are compatible up to Delphi XE6 for example, and also compatible with older IDEs?
I don't mean in a coding sense because I believe you use the IFDEF flags when checking the Delphi version numbers. I mean if you don't have access to different Delphi versions how do you test the component?
It is not possible for me right now to purchase XE6 or a new Delphi IDE for a while - if it all, and even if I could I would not have previous IDE's like Delphi 5,6,7 etc.
So how do other component developers do it?
Purchase all the IDEs? which seems unlikely
Download Trials for the IDEs? which also seems unlikely
Get people to test the component if they have another IDE? Seems possible
Make it Open Source and let others test it? Also seems possible unless you want it Close Sourced
What it comes down to is I want to make a few simple components but I want them to be compatible with as many Delphi versions as possible should they ever be released to the public.
I don't have the means to get all the Delphi IDE versions and downloading trials may also not be possible. Even if I bought XE6 or the next release I would not be able to test with Delphi 8 for example.
So, how do 3rd party component developers make there components compatible and tested on various IDEs? Am I missing something obvious here, how can you have access to every Delphi IDE Version?

As a component vendor myself (I am the primary developer of Indy) who needs to support multiple versions, I can only speak for myself, but here is how I do it:
Purchase all the IDEs?
If possible, yes. I have a number of IDE versions installed in VMs, which I use for testing purposes. And for some versions that I do not have installed, I do have their RTL source code for reference purposes, at least. On the other hand, as a member of TeamB, I get free IDE licenses, which helps. Not everyone can afford to purchase every version, although newer versions do provide free licenses for older versions, so you should take advantage of that. I recently installed Delphi 7 through this. If a components works in Delphi 7 and Delphi XE6 then there is a good chance it will work in all versions in between (barring any version-specific RTL bugs, etc).
Download Trials for the IDEs?
N/A for me, but that might be a viable option for some people.
Get people to test the component if they have another IDE?
I do this with Indy. Although I do have several versions, I don't have every version. Other users who have versions I don't have myself do help. If nothing else, for setting up version-specific project files and testing install procedures.
Make it Open Source and let others test it?
This also helps. If you want to develop closed-source components, you could setup a private repository and give access to select users/volunteers. Most users want/need source code (to find and fix bugs when used in their projects, to satisfy corporate policy requirements, etc), so you should make sure you offer an option to pay for source code.

When you buy the latest you get access to all the previous versions (from v7 on - thanks Uwe Raabe)
Previous versions

I am using the first approach: Buy all versions. I have all Delphi versions back to version 3 (from 1997), but only 6 to XE6 are installed on my machine (with the exception of Delphi 8 which in my opinion should better be forgotten). But of course I didn't buy them all at the same time, I started with Delphi 3 and updated from there on.
Unfortunately it becomes more and more complicated to get older versions installed and running on "modern" operating systems (currently Windows 8.1 so far) so sooner or later I will be forced to switch to virtual machines. Not yet, though. Switching to VMs has the drawback that you can't batch compile using different Delphi versions:
call CompileForDelphi6.cmd
call CompileForDelphi7.cmd
etc.
like I do for GExperts.

Related

Installing kbmWM with a newer Indy

We have some legacy software programmed in Delphi 2007. I had to upgrade Indy to something quite new from their source snapshot to be able to support TLS v1.2 in my application.
Old Indy was removed and new packages compiled and installed. Note that Indy changed also naming of the packages, currently they are called IndyCore110.bpl etc - with 110 suffix for D2007. Which probably doesn't even matter, since the packages are in any case newly build and the library itself is modified slightly.
Of course, the compiled packages and units from kbmMW CodeGear edition which we used in other parts of the system (and which need to be in the same Delphi environment on the same build machine) are not compatible with the new Indy neither by naming nor by whatever stands for version there, I can't re-install the kbmWM's packages.
If I understand it right, I need to obtain sources for kbmWM in order to be able to re-build and re-install it (while, possibly, fixing some compatibility issues where it comes in contact with new Indy). (Please correct me if this is wrong).
What I don't know is - which edition of kbmWM do I even need, what is the difference between Professional and Enterprise - are they different by component structure or only by licensing/support features? The CodeGear edition - which edition with sources does it correspond to - Professional or Enterprise?
I've attempted to compose a list of components and classes which are definitely explicitly used in our source, maybe this could help in answering the question. Here it is:
TkbmMWClientQuery
TkbmMWClientStoredProc
TkbmMWClientConnectionPool
TkbmMWBinaryStreamFormat
TkbmMWTCPIPIndyClientTransport
TkbmMWPooledSession
TkbmMWSimpleClient
TkbmMWServer
TkbmMWTCPIPIndyServerTransport
TkbmMWPooledSession
TkbmMWDBXConnectionPool
TkbmMWMSSQLMetaData
TkbmMWADOXConnectionPool
TkbmMWCustomConnection
TkbmMWClientIdentity
TkbmMWAccessPermissions
TkbmMWCustomServiceForm
TkbmMWCustomService
TkbmMWBinaryStreamFormat
TkbmMemTable
TkbmMWBinaryStreamFormat
I hope somebody can either consult me on what edition I might be able to use or advise me on installing the precompiled CodeGear edition together with the updated Indy. The Indy version is 10.0.52 downloaded from here: http://www.indyproject.org/Sockets/Download/Files/Indy10.DE.aspx
Again, for record keeping.
CodeGear edition is, in fact a subset of them all, quite close, but not quite as big as Professional. That was actually visible in the Features section of the website.
We did purchase a Professional license and in the end I was able to find a combination of versions of MW and MemTable that compiled on D2007
It was also possible to hack it a little bit in the part of interface with Indy to accomodate for the changes in the newest packages. I won't go into details here, this remains yet to be tested, for now I just know that it all builds together and projects open and compile.

NMUUE library for Delphi 7

I' m trying to run a project on Delphi 7 and getting file not found error 'NMUUE.dcu'. It is needed to create TNMUUProcessor object. Reinstalling doesn't help . So where can I find this library for my project?
I assume you've migrated this project from a lower version of Delphi. If I remember correctly, NMUUE is the UUE encoding unit for the Fastnet internet components. These didn't ship with Delphi 7 (I think Delphi 5 was the last version that supported them). I'm not sure if there's a download available for it still as NetMasters have gone out of business. Your best bet would be to migrate the project to use something like Indy.
That component is part of FastNet. It is not distributed with Delphi 7: http://edn.embarcadero.com/article/29766
The Fastnet components are no longer bundled with Delphi. It appears Netmasters does have a version compatible with Delphi 7 which can be purchased at: http://www.netmastersllc.com/
You probably will need to upgrade to a paid version of FastNet that supports Delphi 7, if such a thing can still be obtained, or switch to Indy.
On the other hand, if you are not actually doing anything more than uuencoding you could easily find a Delphi uuencode function with a websearch.
You probably ought to try to understand your program and what its requirements are before you proceed much further. Blindly solving missing dependencies without understanding why your program needs them is usually a recipe for future pain.

Delphi: Upgrade 2009 to XE?

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...

Supporting Delphi 7 apps in D2006 / D2009

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.

New Version of Third Party COM DLL - How to Install and Keep Old Versions in Delphi?

I need to have my Delphi program use a new version of a third party DLL. I'd like to be able to use the new version but revert to the old version if I need to.
Some of the objects are invisible objects on a form in the app. Others I instantiate at runtime.
How do I install the new version of the DLL into Delphi while maintaining the existing version? I'm using Delphi 2007.
We have several products. Some of them are developed with different versions of Delphi and different versions of external components. (Sometimes porting/upgrading is not an option).
To solve this problem we have (network)shares for each product. And if we start working on a product, we map the standard drive (in our case w:) to that share and start the required version of Delphi. That way each product has its own environment and its own version of the components.
Downside is that you have to kill some popups sometimes, at startup, but the system works fine.
Another solution is to use virtual pc's. But not al licensing systems allow that use.
At runtime (including deployment), you should be able to use Win32 assembly side-by-side sharing (WinSxS) to make the new version of the component available to your application, while letting the rest of the system continue to work with any existing version. Disclaimer: I've never done this in practice.
However, at design time (in Delphi), I think you have no other choice than to work with a specific version at the time, unless they generated new interfaces and coclasses (in which case you can generate different names in the Delphi wrapper) for everything that was changed. Solutions such as those offered by Gamecat would probably be your best bet.

Resources