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.
Related
I want to create *.bpl file but I am failing to do so.
Specifically, I am trying to make JEDI plugins, but I have tried an empty pure Delphi package, too.
If I create a new package in Delphi XE3, I get an empty unit - if I "make" this project called "Package1.bpl", I get a .dcu file in "debug/win32/", but no .bpl file.
No error is reported by the compiler.
An empty JEDI plugin (bpl-style) only gives a .dcu, too, while an empty dll-style JEDI plugin gives a .cdu and a .dll file in "debug/win32/".
This is the first time I am trying to make a new package, so I am completely lost.
What am I missing?
Go to the Tools menu and navigate to Environment Options -> Delphi Options -> Library.
There you find the Package Output Directory and the DCP Output Directory. These directories are the default output directories for BPLs and DCPs, so the bpl will be created if your packages is compiled, but in a different directory from what you expect.
The JEDI plugins probably have their output directory configured otherwise in Project -> Options.
For those that don't want to travel into Delphi IDE/options etc, lately in Delphi XE it's something like this:
"C:\Users\Public\Documents\Embarcadero\Studio\17.0\Bpl;"
Your exact folder might be different based on 17.0
These folders also end up in the path environment variable of your system, bit dangerous and can lead to some mighty magic loading confusion ?!
"How's that BPL still loading after it was deleted from my local project folder ?" :)
Another solution is to add "." to your project settings without the "". Prevents you from having to modify your delphi environment options/settings, something you probably never want to do since JEDI and other projects may rely on these default settings to function properly. Only change it if you know what you are doing and how to correctly make JEDI and others work if it was changed, this may get tricky/hairy, probably requires search paths to be added.
We have a little annoying problem with our delphi 2007 IDE, from time to time for no obvious reason the delphi IDE changes absolute paths in the <DCC_DependencyCheckOutputName> node to relative paths.
for example before we saved the project this was written in the dproj file:
<DCC_DependencyCheckOutputName>D:\DcProgs\ProgUtils\ConvertToSmw\ConvertToSmw.exe</DCC_DependencyCheckOutputName>
and after saving in the delphi 2007 ide it changes to
<DCC_DependencyCheckOutputName>..\..\..\ProgUtils\ConvertToSmw\ConvertToSmw.exe</DCC_DependencyCheckOutputName>
My question is why and when does delphi do this and is there a way to stop delphi from doing this ?
You see we have made a custom buildscript that makes nightly builds for our projects and packs the executables using upx after a successfull build. To know the exe files location we use the "DCC_DependencyCheckOutputName" node, but upx doesn't like the relative paths so we need absolute paths. It would be nice that delphi stopped changing this or that we at least know when or why this happening so we know what not to do inside the ide to prevent this.
Any idea's ?
The IDE does this when the project and the referenced files are on the same drive.
Delphi tries to do you a favour into making your project and references using relative paths, so you can move around the directory tree to another location or machine with more ease.
Sometimes this fires back (for instance when you want to include parts from the Delphi example code).
The only way to do this is to make sure the parts you want to have absolute pathnames be on a difference drive letter than the main project.
It might also be (I didn't try yet) that you can enforce this by having them on a different UNC 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 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.