This is peculiar. My Delphi XE5 was working properly and based on build switch would generate the EXE and put it in the appropriate folder (Win64\Debug or Win64\Release). Something unknown broke this functionality. If I create a new app, add 64-bit target, then compile, it creates a Win32 folder but no Win64 folder. It puts the EXE in the Win32\Debug folder (and there is no Win64 folder.
So I manually created the Win64 and Win64\Debug folders. I now try to run and get this error message (and there is no exe that gets deployed in Win64\Debug):
I'm at wits end on this one and things I have done:
verified run Delphi as administrator
killed Acronis (seems like someone ran into something similar)
Project options output folder is set to .\$(Platform)\$(Config)
The most likely explanation is that your anti virus software is interfering. Try disabling it to prove the point. If that is the problem, exclude your output directories from checking.
Double-check that the output folders in your Project Options are what they should be. Sounds like maybe the paths got altered.
OK - pilot error on my part, though have no idea how this happened. There was an environment variable set with a "user-override" that was set to Win32. I sure don't ever recall setting that nor know why I would. Deleting that override cured the problem.
Related
From time to time, when I load a project into the XE6 IDE, the following error occurs
This error results in the TZConnection component being removed from the Datamodule for some inexplicable reason. Note that the project has been loading without issue for ages and just out of the blue, this occurs.
Has anyone seen this before and know of a way of stopping it from occuring ?
It also occurs with other components, not always the TZConnection component but mostly ZConnection.
Like I said before, this appears randomly. I could close project A, open project B then close it and return to Project A and bang!, the error occurs.
Any clues ? (note that this also used to occur in Delphi 2007)
The Zeos libraries are themselves causing this problem.
To see why, and to fix it, use Delphi to launch a second instance of Delphi, and debug the issue directly.
I wrote a blog post showing exact steps here.
The key is to set the executable that will be run for your zeos package, be sure to build them in debug configuration, and then click the Run button on the Delphi IDE toolbar. A second delphi instance will start. Open the affected form but be sure to be using the IDE instance that is Being debugged as opposed to the one which is currently doing the debugging, when the exception occurs that is causing your component to delete itself, you will be able to step into the package code and see the problem.
I suspect a DLL-hell path issue. (Multiple copies of Zeos or other core BPL/DLLs in your path.)
Actually, it doesn't sound that inexplicable - it's probably caused by an exception occurring as the DataModule (or some form with db-aware components connected to it via properties) is being loaded into the IDE (see below). Have you tried checking that wherever your ZEOS .BPL files are located is on your system Path? Likewise any .BPLs they depend upon - see the "requires" clause in the .DPK file(s) for Zeos.
This sort of problem arises fairly frequently with flaky DB components, maybe more so than other types of component because db components more frequently involve linkages between datamodules and forms, e.g. when db-aware components on the forms are connected to others on the datamodule.
So, sometimes, whether this sort of problem shows up or not depends on the order in which the IDE will re-open them - try closing the project with only the dm open and then re-opening it. A bit of experimenting with which datamodules and forms are open in the IDE and in which order may help you pin down the problem. If/when you have a reproducible sequence of steps to provoke the problem, report it to the authors.
A fairly reliable way to determine whether the problem is being caused by an exception as a project loads is to run one instance of the IDE inside another. As long as the first ("outer") instance of the IDE has the debugger set to "Break on Language exceptions" it should be able to take you straight to the source of the exception (assuming it occurs, of course) when the project is loaded by the second instance. It may take a few goes to "catch it in the act" of course, but it is hugely satisfying when you manage to. Good luck!
Unlike MartynA I doubt this would be caused by an exception.
I would more likely expect such issues to be caused by windows path environment variable being too long.
Unfortunately still many component vendors and even some programs modify "windows path environment variable` to make their own files accessible by other programs.
And when windows path environment variable fails to provide sufficient information windows will try to find the files in default system directory which is C:\Windows\System32
So I would strongly advise checking the windows path environment variable to check its length.
The easiest way to do this is by simply starting the command prompt and typing in path directive or perhaps path >> D:\path.log to export the path environment variable information into a file for easier reading in case if it is long.
EDIT: BTW I just checked my path environment variable and I see that I will have to do some cleaning because it contains entries for both Delphi XE8 and Delphi XE 10 Seattle file locations even thou I have removed Delphi XE8 from my computer. Not to mention some entries from some programs that I have removed quite some time ago.
I think I have broken my Delphi DXE6? I'm trying to install Orpheus 4.08 so I can open some old forms with Orpheus design-time components.
It won't build, and I notice that it's creating Win64 folders where it should be creating Win32. ex:
\Orpheus\packages\Delphi XE6\Win64\Release
I have the Target Platform set to 32-bit Windows. I even deleted the 64-bit one, and it keeps creating that folder. Further inspection shows that regardless of which platform I'm targeting, it uses DCC64.exe for the compiler. This can't be right, can it? Have I broken Delphi somehow, or am I doing something wrong?
So I thought I was going crazy, and created a new VCL app from scratch, configured 32-bit, Debug. Sure enough, it is sent to: C:\Users\cthornto\Documents\Embarcadero\Studio\Projects\Win64\Debug
What is going on here?
I had the same problem. In my case, it happened because some other program created a System Environment Variable named Platform with the value "Win64" and Delphi uses a variable with the same name during compilation.
To solve it, I've overridden the system variable with and empty one in Tools > Options > Environment Variables.
David was right, a full uninstall/re-install did the trick.
Delphi 2007 sometimmes holds a handle to the EXE it's linker makes. Sometimes it works fine. But other times it's a whole day saying: "Cannot make EXE file" or something similar when trying to compile or build a solution.
When I try to launch EXE made from Delphi it says that another process is holding the file. Going to "unlocker" says: bds.exe. Even if I unlock it I must rename it to eg. app1.ex_ and copy it back to app1.exe. But still Delphi is holding the handle to that .ex_ file.
Needless to say it makes debugging (or even running) and developing quite slow: having to deal with locked exe...
Any suggestion? Workaroung or fix available - I've been looking for it but can seem to find it: I'm sure others have the same problems (I've seen it) - is there any fix for this?
env.: Win7 Ent. x64, Delphi CodeGear 2007
Thanks!
Going to "unlocker" says: bds.exe. Even if I unlock it I must rename
it to eg. app1.ex_ and copy it back to app1.exe. But still Delphi is
holding the handle to that .ex_ file.
Based on the fact that renaming file causes the BDS.exe to "hold the lock" of renamed file I seriously doubt the BDS.exe is actually the one that is holding the lock. If BDS would be holding the lock on that file you wouldn't even be able to rename it.
So I would seriously suspect that your AntiVirus software might be behind it.
I even remeber having similar difficulties years back using Delphi 7. The cause then was ma AntiVirus software (Nod32 version 2). First workaround I was unsing was to simply delete the application exe file prior compiling, but later I simply added entire Folder into the AV residental protection ignore list.
So try adding your project folder into ignore list and see if it solves the problem.
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.