Good Day,
I am in the process of trying to open a legacy software project in Delphi XE. Whenever I try to open the IDE, I get around 100 - 110 error messages, one error message per DevExpress component not loading. This happens when I open the IDE itself AND when I open an existing project now.
The funniest part is that the paths to these BPLs are correct and all the "missing" BPL files are in those paths. The Environment variables point to these folders as well, and yet it just doesn't work. I attached a few pictures for ease of reference. You will notice the "missing" files in the Folder displayed in the screenshots. The BPLs are there, the paths are correct, but these modules just will not load...
What am I doing wrong? Why can't Delphi see these files and load them, even though these files are indeed present in those specified folders? Is there another setting I can try?
Thank you very much in advance!
Attached Images:
After a bunch of attempts, in the end it was necessary to completely remove both RemObjects as well as DevExpress, and then re-installing them one-by-one. Everything was fine after that.
Related
I'm still using Delphi 5.
I have a program which is a rewrite of an earlier program and in fact uses the root unit from the earlier program. When I compile it, Delphi doesn't link the BPLs into the EXE for some reason. New programs and old programs compile fine, so the problem is obviously with this one program. I've compared the project options for Linking and Compiling with other programs which are linking just fine. The compiler options in the main unit are the standard ones.
While the program is on my development box, it runs as expected, obviously reading the BPLs in the development area. But of course it won't run on another machine unless I copy the BPLs over, which is obviously not very clever.
I've read everything I can find on the subject, but although I've found references to linking not working, I haven't found anything which helps to work out why the linking isn't working in just this one case.
Can anyone point me at some documentation about this or point out something I've obviously missed looking at? I know it's something I've done, but despite spending hours on it I can't work out why!
Since there are no errors generated, I can't show you where it went wrong. Any suggestions about where I might find the problem would be much appreciated.
If you go to the Packages tab of your Project Options, is the Build with runtime packages checked?
If it is, you need to deploy the other packages to other machines if they aren't already on those machines at locations where they can be found by the OS.
If it isn't, Delphi will compile and link your project as an .Exe file and the code from the DCUs in the packages will be statically linked into your .Exe so you won't need to deploy the .BPLs (and they would be ignored even if you did).
AFAIK, when Delphi compiles a project to an .Exe (that is, if Build with runtime packages isn't checked), the compiler gets the other units' code to link from the .DCU files, rather than from the .BPL files. If it can't find the .DCU files, or you have told the compiler to do a "Build" it will attempt to generate the .DCUs them from the corresponding .PAS files if it can find them either in the project directory or via the Seach Path under Directories/Conditionals.
Compiling some old code, my application will no longer run. Newly compiled exe-file won't start "because qtintf70.dll is missing from your computer".
Strange thing: an older exe file compiled from exact same code runs just fine. Both exe files tested on same system, but compiled on different Delphi installations (both Delphi 7 running on VirtualBox).
Googling, someone suggested "You have pulled in Clx somehow. Clx apps require the QT library. Look for units in your uses clauses that start with Q." but again: this is the exact same code. I've checked and can't find anything.
Suggestions?
In D7, the only source code units which reference qtintf70.dll are QForms.Pas and Qt.Pas.
So, what you need to do is to
Move all instances of these two files and their corresponding .DCU files to somewhere not on your project's search paths. Use a utility like SwiftSearch to make sure you find all of them.
Do a full build of the project.
The build should grind to a halt somewhere with a complaint that the compiler can't find one or other of these units. The source unit that is being compiled at the time is the one which contains a reference to one or other of them.
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 followed the advice received in a previous discussion ( Should "Library path" point to the source files of packages? ) and now my Library Path points to folders containing the compiled code (DCU) and NOT to the source code of my controls.
The problem is that I have to duplicate the RES and DFM files and copy them from the 'source code' folder to the 'compiled' folder. It is not a elegant solution at all since, every time I change something (and I do often) to my controls I have to remember to copy the new resource files to the compiled folder.
There must be an elegant way to solve the mystery of the paths! All I want is to push the compile button and to have my program compiled. It doesn't seem so complicated. Right? Well, actually it work with my previous setup (point Delphi to source code of all controls). I just changed it to do it the way the 'good people' are doing it.
Addendum
I still think this is the wrong approach since Delphi's (scarce) documentation says that Library path should point to the "source files for the package".
Using:
Delphi 7, Win 7 (32), simple Delphi setup (single developer with no versioning system installed).
You have two solution:
Use a build tool to build and copy all files where they should be properly deployed (my preferred solution) after each build
Put the .pas/.dfm/.res directory after the .dcu ones. It will find the .dcu first and won't recompile unless you build, and it will keep on looking for .res/.dfm, etc.
If you look inside a D2007 project file (*.dproj) you'll see that the search path occurs multiple time for each configuration. There is
<DCC_UnitSearchPath>,
<DCC_ResourcePath>,
<DCC_ObjPath> and
<DCC_IncludePath>.
Maybe you can point <DCC_ResourcePath> to the source directory containing the resource files while you point the other variables to the DCU directory.
NB: I haven't tried this and can't check if the situation is different in other Delphi versions.
Though answers provided here by others are definitively good and correct (everybody receives a vote up), after experimenting a bit I decided to keep my previous (KISS) set up. It worked for years and it will work for many more. I know, it trades speed (recompiling the source code) for stability but it keeps the "paths, libraries, source, browsing and output folders" madness at bay. I just don't have to worry about settings paths anymore (except first time when I install Delphi but this can be automated) or to quit current DPR Delphi project and load a DPK library and compile it every time I add changes to it.
This is an odd behaviour by my D2006 as it happens sometimes only. I have a project I want to debug. The file I want to debug is named 'Main.pas'. I have another unrelated project with the same Unit name and sometimes the Debug prompt me the wrong Main file instead of the Main unit from the current project. This have happened to me with other files with the same name. I can't debug then as the debug keys don't work (they just don't do anything). Do you have experienced the same problem? How can I fix it?
Thanks.
Do you use relative paths?
If yes, I found out it helps to set the working directory to my projects directory y loading a file from my projects dir using File->Open. The navigating and loading apparantly sets the working dir, fixing the case where you THINK you are using paths relative to your project, but delphi interprets them relative to the working dir of the IDE.
Close all other tabs first though, to avoid mistakes. Since the delphi compiler is a dll, it interacts deeply with the IDE, and probably has access to which files are opened. (it can compile unsaved files!)
If not, it might a freak occurance, but still have the same origin. Developing a habit to first close other files (right click on tab->close all other), and fixate the working dir (with the load unit via file-Open workaround) might help.
I've the feeling the BDS series of IDEs seem to suffer from this more than the classic ones, but the problem existed in the classic ones too. Could be as simple as using more fancy opendialog options in BDS, increasing the chance on working dir change.
update Also only opening projects when no other projects are open helps. So always click the old project before opening the new, and don't click a project in the windows explorer if the IDE is open with another project loaded.
Delphi XE still suffers from this
I have run into that too, and now I tend to give files unique names, like instead of Main.pas, it might be ProjectNameMain.pas
Check your Library paths and Browsing paths in the Environment Options
Take a look at the output and DCU directories of the project. You're probably picking up an old DCU from a shared DCU directory. Clear out the DCUs and re-build.