Firstly I can't really update the version because I would have to re-write my software which uses the dated components.
I initially had alot of success by re-installing the packages (around 40) to the fresh D5 install on the new Win7 machine. If it told me the .Bpl file was missing it works when I move it to the directory:
C:\Program Files(x86)\Borland\Delphi5\Projects\Bpl
and similarly if the .dcu is missing I move it to the Delphi5\lib directory.
However my next obstacle is when I load any form which has an Advantage table (all of my software uses Adt files and AdsConnections). It gives me the error:
TableX.StoreActive : property does not exist
for many tables and a few more properties including LoginPrompt.
It seems these are not included in my components which were included on my previous installation. I've tried updating to the most recent version of Delphi Sp1 but cannot find any information on how to add these properties.
I've carried out a similar migration: several projects developed in Delphi 5 on XP were moved to Windows 7. Unlike you, I also updated to Delphi 2010 at the same time.
The biggest difficulty I had was the lack of unicode support in my Delphi 5 components - I had to edit a lot of third party code. Of course, if I'd not upgraded to Delphi 2010 I wouldn't have needed to do that. Everything else went swimmingly. Here's how I did it.
First I made a copy of the project on the old machine, went through each form and replaced each of the third-party VCLs with run-time creation. It's a slog writing code to assign all the properties and events, but when I was finished there were only standard Delphi components on my forms but the project still ran correctly. Then I was able to move the project and the third-party .pas files to the new machine, open the project in Delphi 2010 and deal with the unicode issues.
The process was gruelling but straightforward.
Since then I've migrated another older project down the same path, but this time built a new application framework in Delphi 2010 and copied the units across piecemeal. In some cases I used the original .pas and .dfm files, in others I created new forms and copied the functional code. In all these cases I installed into Delphi 2010 the latest equivalents of the original third party components. This took a little longer than the original method.
However you tackle this, best of luck.
Related
My general question is how do you troubleshoot "My BPL won't load due to a dependency that just won't go away, no matter how much I clean up and recompile". Update You may think you have a clean recompiled system, but thanks to the inverse-miracle that is Windows and its file system virtualization mis-features, you haven't.
When I try to load my designtime package (in this case named dclFsTee.bpl) into my Delphi IDE (it's the fast report 4 teechart wrapper component package), it complains:
The program can't start because tee7100.bpl is missing from your computer. Try reinstalling ...
That tee7100.bpl is not referenced on any DCP or DCU file on my system THAT I KNOW OF. But clearly, something is wrong, and I can't find the problem.
All Delphi users face a hundred "won't compile or won't load" problems with BPLs. The universal refrain when asked what to do is to clean up your computer.
However, I've now spent hours cleaning up my computer, and while everything compiles file, clearly there must be something out of date hiding somewhere, because the resulting BPL file that I'm trying to load still wants to load a version of a TeeChart BPL that I removed from this system days ago, along with every trace I could find.
The traces of TeeChart stuff in Delphi 2007 that I removed include everything in the $(BDS)\Lib and $(BDS)\Lib\debug folder, and all DCP and BPL folders on the system. Also every TeeChart-unit-named dcu file is gone.
Once you've gotten to the end of the road, what do you try next? (Format the hard drive, buy new computer.) Seriously. I think I'm a smart guy, but I have a 1 tb hard drive, a library path that runs to 80+ folders, and a source code repository that seems to be well organized, but clearly something is hiding where I can't find it.
I have TeeChart Standard 2012, with full source code, and as far as I know, my development machine no longer contains any old TeeChart BPLs or DCP files from the "tee chart tee7100.bpl" version that ships with delphi.
I have run the "recompile.exe" wizard that comes with teechart, which appears to just run MSBuild and build the packages, after writing a {$DEFINE x} declaration to the tee.inc files (there are two of them in the source distribution).
However, somehow, silently it seems like one of the implicit imports into one of the packages is drawing in some stale file which has not been rebuilt, and which therefore tries to load the tee7100.bpl. The new bpl name is tee911.bpl.
Rather than ask the pretty-specific-to-fastreport question, I'm only mentioning it as a specific instance of a general world of hurt that I have faced dozens of times while developing in Delphi.
I'm only giving the fast-report details so you can see that this is in fact a specific instance of a general problem that one faces sometimes inside Delphi IDE when dealing with a component source code or package, or set of packages, with dependencies. Cleaning up your computer so that your code even builds can be tricky.
So here is my Delphi package-to-package-dependency-resolution question:
What is the most effective way to find or trace implicit-load-of-some-no-longer-wanted BPL-problems so that my code (which builds and compiles just fine!) will actually load into the Delphi IDE. The BPL file that results from running Recompile seems to be linking properly to the right DCP files, and no old/stale DCP or DCU files are present. The new DCP file name is tee911.dcp, for instance.
Can you get somehow, any idea of what package is actually stale, and what is being read and linked and imported statically when the .bpl links? (I'm thinking maybe like a special MAP-like file for BPL files?)
Update After many hours of fighting with this, and using every trick I know, I realized I hadn't checked for some VirtualStore related issues caused by file virtualization in Windows 7. That means that Windows 7 lies to the programs that run on top of it. It gives you another version of the file, that isn't the one you want. This can be deadly in several ways; One; You recompile a BPL but that's not the one that loads. The BPL that was killing me was in the SysWow64 folder that was part of the VirtualStore. Note that the virtualstore basically makes phantom files appear that are only there if you're a certain "low privelege" program, which Delphi 2007 on Win7/64 bit, apparently is. To remove BPL files in your SysWow64 VIRTUALSTORE folder for your current user account:
del %HOMEPATH%\AppData\Local\VirtualStore\Windows\SysWow64\*.bpl
... Some days I just hate Windows architecture. Anyways, I'm not going to put the above as the answer, because I'd like to know if anyone has a better way or any tip or suggestion that might help next time.
Okay nobody else answered so I'll put this here to be helpful for future people:
-- Remember Windows VirtualStore when cleaning up broken systems which have old versions of DLLs on them including TeeChart, FastReport, Indy and so on which tend to be involved in messes because they can exist both as "out of box packages that ship with delphi" as well as frequently installed as upgraded versions if you purchased and installed them from the vendors directly, or third, you may have your own compiled copy in your company's mega-component-pack-directory.
-- When searching for duplicate or out of date BPLs, doing a file search in windows doesn't look in the virtualstores, you'll have to locate and zap the whole virtualstore area for your process or user, or program, manually.
The second level of this issue is this:
The dependency graph for FastReports is complex:
It depends on Indy and you might have your own version of Indy, and Delphi itself has one, and other things on your hard drive might have their own copy of Indy.
It supports various editions of TeeChart, including the binaries that come with Delphi, and perhaps the Standard version or other purchased version of TeeChart that you might have bought from Steema.
It uses a precompiled header include file to do the compilation and not just ONE but TWO different copies of an identically named include (.inc) file.
When you use their own compiler tool (recompile FastReport) it works pretty reliably but isn't the best for when you want to build everything in your project from a single build script, thus the source of my problem.
The key is to learn everything there is to know about the dependencies of all the components in your giant pile of packages, and to organize your system cleanly so that you don't have old stuff (like Indy and TeeChart bpls, dcp, or dcu files) lying around. Cleaning that up is quite a complex job if you don't know what you're doing.
A utility to really remove all traces of the version of Indy and TeeChart that ship with your system, and the "Embarcadero edition" of FastReports is key to getting this situation resolved. A general tip is that "if a version of X ships with Delphi and you are going to install a new version, prepare to suffer until your system is really cleaned up".
A really amazing technique to avoid all this crap is to just not install Indy, FastReport or TeeChart (uncheck them or skip them) during your initial Delphi IDE install, then install them yourself, one by one, from sources. Just because a version comes pre-installed in Delphi doesn't make that a good thing. (Update: You can no longer unselect Indy during install, it's part of the base Delphi product since at least Delphi XE8. A clean-up utility to remove the built-in Indy from Delphi's own lib dirs is necessary for anyone who builds their own.)
Another really amazing technique is to run the Installers for commercial components on a virtual machine, then just collect up the pascal source code and transfer that onto your clean development machine, and build it yourself. That way you can avoid the terrible things that happen when you've got BPLs and stuff scattered around your system, and even installed into C:\Windows\System32 (on 32 bit systems) and C:\Windows\SysWow64 (the equivalent path on 64 bit systems).
put that BPL (tee7100.bpl) under $(BDSCOMMONDIR)\Bpl
for XE: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\8.0"
for XE5: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\12.0"
The other issue that can cause this, is not having the folder where you've stored your .bpl files in your system path.
This happens because Delphi attempts to call the WinAPI function LoadLibrary with a file name, instead of an absolute path. So if Windows can't find the file, Delphi can't load it.
See this forum post for more information.
This seems to be an issue in Windows 7, though not in Windows 10.
I'm trying to make a package for a custom component I made. It's based on several libraries, including Graphics32, GraphicEx and CCR.Exif.
I created a Package project, wrote the unit including its Register procedure, added some extra references Delphi notified me about to the requires section (including dbrtl.dcp, inet.dcp, soaprtl.dcp, vclimg.dcp, xmlrtl.dcp and dclGraphicEx140.dcp) and added many units to the contains section to avoid warnings about it happening implicitly. The project compiles and can be installed and used on my own machine without issues. However, when I want to install it on another machine, the troubles begin. In the end, I had to copy about all DCUs from all 3rd party components I used, plus both the DCP and BPL from GraphicEx, which I had to install even.
Supplying a lot of files is a bummer, yet surmountable, but having to install other packages as well is a no go. I could get rid of that DCP and BPL by putting even more units in the contains section, but that resulted in error messages on my own machine where GraphicEx is actually installed. This is confusing to me, because with Graphics32 nothing like that occurs...
Anyway, how do I keep my distribution to a minimum and avoid such situations? I want other developers on my team to be able to use the package without worrying about what I used to build it. For a start, can't all the 3rd party units be compiled into my own DCU?
What you experienced is an usual thing to the ones who write components. The distribution is always like that. Packages do not carry other packages, insted they reference them. It´s in their nature.
In order to overcome such a situation I always treat my components in the same way I would if they were a product to sell: I build a setup wizard that distributes and registers everything the package needs.
In my case InnoSetup works very well (http://www.jrsoftware.org/isinfo.php).
Summary
Haven't use Delphi for a while, but, did develop my custom visual controls (Last version I work was Delphi 6).
There are 2 issues when dealing with packages dependencies. One is installing at the Delphi enviroment, making controls appear on the component palette, plus, component editors & property editors.
And another when distributing the compiled packages into customers machines.
It also depends, on which version on Delphi you are running.
Design Time
When developing a custom package, there is a tab for package options, that indicates the destination folders.
The manuals usually tell the developers to leave those textboxes empty. That sometimes works, sometimes doesn't. I explicity write each folder path, in the respective textbox.
There is a textbox path for the ".dcp" files, other for the ".dcu", and so on.
If you have visual controls and stuff like property editors or component editors, its better to split the code in 2 packages ("Runtime" & "Designtime").
I usually put the delphi (packages) projects outside the delphi installation folder.
Run Time
Usually, the quick way is to put the "*.bpl" ".dcp" files in the Windows (32) / system folder, or similar "DLL" windows folder.
Packages folder structure source code suggestion
Managing packages can be difficult. I don't know how much the installation process has changed with Embarcadero, and the newer versions of Delphi. The following chart,is an example on how organize the source code. Hope it helps.
[-]--+--c:
.....|
.....+--[-]--+--software
.............|
.............+--[+]-----java
.............|
.............+--[+]-----php
.............|
.............+--[-]--+--delphi (not the delphi folder in program files)
.....................|
.....................+--[+]-----apps (source code for delphi programs)
.....................|
.....................+--[+]-----other
.....................|
.....................+--[-]--+--packages (all delphi packages source code here)
.............................|
.............................+--[+]-----lib (a single package for non visual controls, libraries)
.............................|
.............................+--[+]-----tools (package pair for non visual tcomponent descendants)
.............................|
.............................+--[+]-----json (example)
.............................|
.............................+--[+]-----xml (example)
.............................|
.............................+--[-]--+--mycontrols (folder custom visual controls)
.............................|.......|
.............................|.......+--[-]--+--delphi40 (folder for delphi40 version of "mycontrols")
.............................|.......|.......|
.............................|.......|.......+----------dsgvclctrls40.dpk (design-time package "mycontrols")
.............................|.......|.......|
.............................|.......|.......+----------runvclctrls40.dpk (run-time package "mycontrols")
.............................|.......|.......|
.............................|.......|.......+--[+]--+--demos (individual example for each "mycontrol")
.............................|.......|.......|
.............................|.......|.......+--[+]--+--design ("*.pas" component editors destination folder)
.............................|.......|.......|
.............................|.......|.......+--[+]--+--sources ("*.pas" source code destination folder)
.............................|.......|.......|
.............................|.......|.......+--[+]--+--bin ("*.dcu" destination folder)
.............................|.......|........
.............................|.......+--[+]--+--delphi50 (folder for delphi50 version of "mycontrols")
.............................|.......|........
.............................|.......+--[+]--+--delphi60 (folder for delphi60 version of "mycontrols")
.............................|.......|........
.............................|.......+--[+]--+--delphi70 (folder for delphi70 version of "mycontrols")
.............................|................
.............................+--[-]-----etc...
Cheers.
Thijs, you simply cannot do that with only a package. The target developer will require almost everything you added to the package. But there is an alternate way of doing what you want: Build a DLL with all the components/libraries you are using in your own component and wrap all those external components/libraries into some code you will export from the DLL. Then build your component without using the external components directly but the DLL you've built. You cannot in you component "use" any unit of the other external components/Libraries. You have to build a new unit with all the datatypes and required declaration for anything you export from your DLL. All this is perfectly working but will quickly becomes very complex for a large number of external components or libraries.
I think AlexSC has the best answer, but I think there might be an alternative if you ansolutely must have a custom component that has no dependencies.
I ran into the Delphi dependency frustrations a little while back trying to create an in-house component for our developers. My suggestion:
Uninstall all dependencies your component uses
In your component package, remove the above dcp from the requires section from your package.
Copy the source files of your dependencies to your components
When you distribute the component, you'll have to distibute it with the code of the required dependecies
You'll run into issues if you want to use the dependcies separately since Delphi won't allow you to have duplicate unit names in installed packages.
Also, the reason you don't want to use DCUs is the fact that the DCUs are compiled for a specific platform and compiler. So unless you are sure that all devolpers are on the same platform ad using the same version of Delphi, dependency code needs to be recompiled.
Again, AlexSC has the best answer and InnoStudio is a great little tool.
After many years of trouble-free use, Delphi 7 is now throwing an Access violation at address
40233A3E in module 'vclx70.bpl'. Read of address 0000021C.
When starting the IDE, the default empty project and unit/form appear and compile and run fine.
I'm developing Windows apps, running on Windows 7 (x64).
I haven't installed any new packages or tools in many, many months.
I stopped, dead in the water, unable to work.
Any suggestions other than a complete rip and re-install (which takes many hours...)
EDIT: I un-installed and re-installed Delphi 7. Now I'm getting Access violation in vcl70.bpl. I would have thought that uninstalling D7 would completely remove all of its libraries, etc... Are there folders that I should manually delete after uninstalling D7?
Problem fixed (and major machine rebuild averted)!
Gerrit Beuze of ModelMaker Tools suggested elsewhere:
Remove all .dsk (project desktop) files for the project you try to load, Temp remove all *.dst (desktop files) from C:\Program Files\Borland\Delphi7\Bin
After performing these steps, the problem appears to have been fixed.
A read at that low a memory address is typically a problem in a third-party component. However, you say you haven't installed anything new in months.
The other thing that's strange is that you're getting the error in vclx70, which is one of the CLX libraries. Are you doing anything using the CLX (leftover cross platform - Kylix) forms or dialogs?
If not, you might do a search in your source for QDialogs, QForms, or any of the other units in %PROGRAMFILES%\Borland\Delphi7\Source\Clx, and see if something mistakenly was added that you didn't intend that's pulling CLX into your project. If so, change it to the VCL version instead (by just removing the 'Q' from the front of the unit name in your source).
EDIT: You might try going into the registry (D7 would be HKCU\Software\Borland\Delphi\7.0) and temporarily changing the name of the delphiCLXide entry in Known IDE Packages to something else (put an underscore in front of the name or something). Then start the IDE. You should get an error message about Delphi being unable to load the package, and asking if you want to try and load it again in the future. Answer 'Yes', and let the IDE continue to load. Then try again with your project and see what happens.
The step above removes CLX temporarily from loading in the IDE designer. (Don't worry, you can just rename the key again to put it back if it's not the problem. If it doesn't come back, make sure the IDE didn't add an entry in the Disabled Packages entry; if it did, just remove it.)
If this works, you can open the project options (.DOF) file for your project, and remove the CLX libraries from the Packages list. This prevents it from being included when your project is loaded.
Once you've established whether the problem actually
My first suggestion would be to use XP Mode or another VM infrastructure to run such an old Delphi version on Windows 7 (I do it that way).
Another potential method is to use the compatibility settings in Windows 7 to set it to XP and to exempt the Delphi 7 process from DEP (data execution prevention) policies the system may otherwise impose. I've had some trouble with enabled DEP with older Borland IDEs and also VS 2003.
Just a quick question for those of you that know. Is it possible to have both Delphi (ver 7) and Lazarus installed at the same time. I want to make sure the Lazarus install will not interfere with my current Delphi install in ANY WAY. I would have asked this on the Lazarus fourms but thought I would get quicker reply here.
Anyway if you have both Delphi & Lazarus installed please tell me any problems you have encountered (if any) thanks.
Chris
Lazarus does not interfere with any version of Delphi, they can live along very happily.
The only interference is for commandline building, both projects have a make.exe file which are not the same.
This is easily solvable by not adding FPC to the path (removing it via control-panel system), and do a
set PATH=c:\fpc\2.5.1\bin\i386-win32;%PATH%
or wherever you installed as first line in your batch files.
I generally don't bother, but a previous employer we did a lot of cmdline building with dcc, and then it matters.
File associations are another, but already named. (but not such a big problem since the project extensions vary (.dpr vs .lpr, .dproj vs .lpi) )
Btw: Other development products (cygwin,mingw, and maybe even VS) have their own respective make.exe files and the same kind of problems.
I currently have Delphi 5 and Lazarus both installed on my Windows 7 laptop. As near as I can tell they don't interfere with each other.
I don't really use Lazarus though, as I prefer Delphi 5 which is what I've used forever.
I have Delphi 2006, Delphi 2010 and Lazarus installed. No problems at all. I am sure Delphi 7 will be the same. The only problem I can see could be the use of .pas extension in Lazarus. I mean because of association problems. But you can use a different extension for Lazarus (free pascal) source files. I think the installer asks you that.
I have Lazarus "installed" on a USB drive. It interferes with nothing whatsoever. It is actually a checkout of the Git repository that mirrors the SVN repository. I installed the latest stable FPC to C:\FPC, and then copied that folder to inside my lazarus source folder, e.g. \lazarus\FPC\ (and then uninstalled the C:\FPC installation), and then whenever I like I build the latest lazarus like this:
X:\lazarus\> git fetch
[...fetch messages...]
X:\lazarus\> FPC\2.4.0\bin\i386-win32\make.exe clean all
[...compiler output messages...]
X:\lazarus\> startlazarus
[...IDE starts up...]
The main advantage of this is that if you find an IDE bug, the source is immediately available and you can make and submit a patch instantly.
We recently converted our long-running Delphi project to Open Source. Multiple people have contributed patches already, which is great, but unfortunately forms and frames when saved with Delphi 2006 (and later) contain new properties in the .dfm that are not handled by older versions. Forms are handled quite gracefully by the IDE ("ignore propery?"), but frames are loaded at runtime and result in errors. Not an option, as far as I'm concerned.
I now removed those properties from the .dmf files by hand, but I am really wondering if there is a more elegant solution. There is no way to save in a backwards compatible format from the new IDE's, is there? Are there existing tools to strip the nonsupported properties from the .dfm's ? Any other elegant solution I am missing?
Normally, with a commercial project, I'd just upgrade the project to the most recent version applicable... but as this is open source I really don't want to loose out on those developers still working on Delphi 7. That includes myself, actually.
The JEDI JVCL project uses a little utility dc.exe (delphi cleaner) and a list of properties in DFMs that are not present in older versions of delphi, mine contains the following text:
*.PopupMode
*.PopupParent
*.ExplicitLeft
*.ExplicitTop
*.ExplicitWidth
*.ExplicitHeight
*.BevelKind
*.BufferDocument
*.DoubleBuffered
*.ParentDoubleBuffered
*.DisableHyperlinks
*.AlwaysEnquoteFloats
*.PixelsPerInch
I run this dc.exe utility from a batch file which cleans my dfms before I commit
changes to subversion. The syntax in my batch file for this is:
dc.exe -s -fd10.txt *.dfm -i
You can grab my stuff at:
http://sites.google.com/site/warrenpostma/files
You can try Andy's DFMCheck. It can automatically open and close all forms and frames in a project, which makes the IDE remove unknown properties (as Marco wrote).
Well, for sake of completeness:
Open the dfms in the oldest Delphi supported, let it remove all unknown properties, change a property and save.
For your purposes, Warren's solution is better, but it can be a workaround. I did it for a while when we were dual D7-D2006ing.