I have a problem with setting Browsing Path in Delphi 2009:
When I install a new component, I add DCU path to Delphi's Library Path, and source path to Delphi's Browsing Path. The application compiles fine, but holding Ctrl and clicking on any of the unit names for that component does not open the source file!
It seems the only way to make it work is to add source path to Library Path, but this means I have to compile all the units belonging to third-party components every time I build my project!
This problem does not exist for Delphi's standard units, or even JCL and JVCL units which are installed by JCL\JVCL installer, and their source paths are added to Browsing Path.
Is this a bug, or it is me doing something wrong?
Regards
I was struggling with this problem for a long time. Changing REFERENCEINFO in package settings from "none" to "definitions only" did the trick. Hope this will help you also.
Are any of these units listed in the .dpr ? Units there with a wrong path can cause pretty funky behaviour.
Setting "Symbol Reference Info" to "Reference Info" does indeed fix the issue with Browsing Path.
But at least for Delphi XE the change has to be made in "Build Configuration -> Base" for it to work.
I would ensure the dcu's were compiled with debugging turned on. If this is a third party component and the source is provided with it this is usually the case but not always.
Related
The Embarcadero website describes the Delphi Browsing path as follows:
Browsing path
Specifies the directories where the Code Browsing feature of the Code Editor looks for unit files when it cannot find an identifier on the project search path or source path.
http://docwiki.embarcadero.com/RADStudio/XE4/en/Code_Editor
I have some DevExpress components and the paths to the .pas files are in my browsing path. Somehow, the code browser doesn't find these files. I also cannot step into these files when debugging. Only the .dcu files are in my library path.
Is the Embarcadero website wrong?
People seem to say adding the path to the .dcu should be enough to step into the .pas when debug .dcus is set to True:
Organizing the search path
I don't find that to be true. What's up with that?
The documentation is accurate. It correctly describes the browsing path.
However, it's not uncommon for the IDE to get confused. If the project doesn't compile then code browsing doesn't work. Often a full re-build will be enough to make code browsing work again. But sometimes that's not enough. In which case any attempt to help solve your problem would likely require an SSCCE.
But as to the question you asked, the documentation is correct in its description of the browsing path.
Iam using Delphi 2005 and i have included a unit to the main unit using compiler directive i.e.{$I sample.pas} whenever I try to build the main pas file I get the below error . F 1026 File not found and it shows the path where the sample.pas file is available. I tried different options like tried adding the path of the pas file in the project options- search path and also in the tools-options -library path and it doesnt work. I googled it and found a solution which says to do the following:
In the IDE from the main menu, navigate to
“Tools|Options|Environment Options|Compiling and Running”
switch “Show Commandline” ON
AND set sure you have “Verbosity” set to “Diagnostic”.
The problem is Iam using Delphi 2005 and unable to find the “Verbosity” option in Delphi 2005. It would be great if some one can help me
In Delphi 2009 it is right under the Show Commandline setting:
However, unfortunately for you the verbosity option isn't present in D2006, so I guess it was introduced in either 2007 or 2009.
Oh, and as far as the include directive goes: if your sample pas isn't in the same folder as the unit in which it is included, you could try adding the path to the $I directive:
{$I ..\..\General\sample.pas}
Put the file in the same folder as your project units, and change its extension to ".inc" ( not mandatory but I think that by convention directives files are named like this).
A possible solution could be to get the code working in a package and then have the package keep that part of things compiled. I have been able to use include files in other paths with packages, but it is quite tempermental. It can start rejecting them even with packages for reasons I don't know. This is indeed a VERY annoying problem.
You might also look into doing your builds via your own batch files where you can take full control of the command-line settings that are being used.
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.
I've just noticed that whenever I do an incremental compile (ctrl-F9) of any of my Delphi 2010 projects, all JEDI units referenced in my project are recompiling although they have not been changed in any way. In fact, if I create a new project, drop a JEDI control on the form and compile, I see all JEDI dependencies getting recompiled. If I think hit ctrl-F9 a second time without making any changes in my project, the same thing happens.
Anyone know what's causing this?
Update: The problem appears to be related to the subdirectory jvcl\run on my system. All units in this folder are getting recompiled each time I do a Delphi compilation (even without touching my project source). The compiled dcus are getting and left in this subdirectory on every compilation, even though the compiled dcus already exist in jvcl\lib\d14. I do not have jvcl\run on my library path.
Additionally, if I move the jvcl\run directory elsewhere on my hard disk my project compiles and links successfully, presumably finding the dcus in jvcl\lib\d14 (which is on my path).
Sometimes you will see the unit name flash by on the compile progress screen, even when it is not being recompiled.
To know for sure, check the date of the Jedi DCU's before and after compile.
Also, how did you install the Jedi controls? If you use the default installer, then they shouldn't compile ever (they are compiled at install). If you just dropped all the source into your library path, then they will recompile on a build, or if they are changed (and various other conditions).
There are a few placed to check for your "jvcl\run" path in your settings.
The first two:
Tools|Options
Environment Options|Delphi Options|Library-Win32
(1) "Library Path:" Edit Box
(2) "Debug DCU Path:" Edit Box
The Third is:
Open Your Project
Project | Options
Directories/Conditionals
(3) Search Path: Edit Box
And finally if you compile via the command line you need to check what you are passing in the DCC32.CFG and/or PROJECTNAME.CFG and the command line parameters to DCCC32.
The reason your compiled DCU's are getting placed in directory your source is in is because you have not set an "Unit Output Directory"
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.