Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have a multi-file project that was created in Delphi5 and I am attempting to compile in Delphi XE6.
In my DSPack.pas file I get the error: "'jedi.inc' could not be found..." related to the code line:
{$I jedi.inc}
... there are also many, mostly "undeclared identifier", errors shown as errors - but named as initial errors, which I presume are because the compiler can't find the jedi.inc file...
I have located the jedi file - jcl- in my Comps folder.
My question is three-fold:
One: Why does XE6 not register jedi.inc whereas it did in Delphi 5?
Two: Where is jedi file usually located?
I believe I have downloaded an updated version of jcl file (jcl-2.6.0.5178).
Three: What do I need to do in my project so that the compiler and find the jedi.inc file?
I imagine you're aware that you can add a .Pas to a project by clicking the Add File to Project button in the D5..XE6 IDE. You can do likewise with an .Inc file. However ...
When you do that for a .Pas file, you can see in the Project Manager pop-up that it has recorded the path to it, and this is sufficient for the compiler to be able to find it. But, for some reason, the same is not the case for an .Inc file. This evidently by design, because this difference has existed at least as far back as D5, IIRC. TBH, I'm not sure why, because several times I've seen problems that would have been avoided if the compiler had been able to find an .Inc file from what the Project Manager obviously knows about its location. So, I can't answer your "why?" query, though I dare say the compiler designers could.
To enable the compiler to find an .Inc file, you have two alternatives to deal with your "how" query (apart from moving the .Inc file, which in the case of a thing as large and complex as the JCL/JVCL is probably not such a good idea):
Include the path to the .Inc file in the {$I } directive. In my case, the JCL stuff is located two folders below a Jedi folder which is itself below a Delphi directory on my D: drive, so I would write the "{$I ...}" line as
{$I D:\Delphi\Jedi\JCL\Source\Include\Jedi.Inc}
Add the path to the .Inc file to the list of paths under
Project|Options\Delphi compiler|Search path. The first of these methods is probably preferable, because it only involves the .Inc file, whereas the second tells the compiler to look in that path for anything it hasn't already found, which may not always be desirable.
As to your "where" point, as you may have gathered from one of the comments, the location of the Jedi.Inc file(s) in the JCL/JVCL distribution seems to have been moved since olden days to where it is now, which I think is why you're having this problem with something which used to compile under D5.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
After a voted closing of this Thread/Question, i had my Problem fixed.
But i still want to give it a shot to re-write my Problem/Question, so others could benefit from it. So here i go:
Main Problem:
I´ve got a Project using two external Dependencies. Those Dependencies represent Elements which are Visually shown in the Form-Editor.
The Exact Problem is, that the "Main" Project can´t seem to find these Dependencies, therefore the Visual Representation of the Form can´t get generated.
This Error gets Displayed with the Message "Class can´t be found.", and therefore i can choose to either ignore the Error - which results in deleting all occurences of the missing class in the opened form - or i can cancel the opening of the Form-Editor.
I also read somewhere - correct me if i´m wrong - that these Dependencies in my case are called Units in Delphi.
I got the Sourcecode to these Dependencies, which in my case are a *.dcu, a *.pas and a *.dpk file.
So the Question would be:
How does one add external Units to a Delphi Project?
The Path to the Solution:
The first hint to solve my problem was given by #fpiette:
But a developer can write his own component. To be usable by Delphi IDE, this component needs to be "installed". That is build in a package (A special kind of project in a .dpk file)
So now i needed to search for a *.dpk file, which i "conveniently" have for each dependency.
After a little bit of further investigation, i found this - or more specifically:
The directory where you store the .dcp file—and the .dcu files, if they are included with the distribution—must be in the Delphi Library Path.
Now i knew, i also need to add the Path of these Sources to my Library.
The last step missing was now only to "add" these Files to my Project. After playing a bit around with the IDE, i found the Prompt "Install Component", under the "Components" Tab.
In the upcoming Wizard i selected to install the Unit into a new package, and selected the *.pas File for the Dependency. The next Windows asked for a "Name" in form of a *.dpk File, which i also have in the sourcefolder.
So after selecting the *.dpk File, my Project was converted into a Projectgroup, and had the newly added Dependency as a second Project besides my "Main" Project.
So i did these Steps with all Dependencies needed, compiled all Dependencies and now the IDE wouldn´t show the Error anymore but open the Form-Editor correctly.
I also want to mention why it didn´t work for me earlier - or at least what i think what my Error was:
In the Described "Install Component"-Wizard, i selected the *.dcu file instead of the *.pas File. The Dependency was still added to my ProjectGroup, but didn´t solve my main Problem.
So i "reverted" back to my starting-point, and selected the *.pas file instead of the *.dcu file.
I hope my Problem is now better explained and formatted, im open for criticism!
Thanks for your help earlier, and have a nice day!
What you named "Picture" and designated as .dfm file is actually named a "form".
When you open a form, the IDE make a visual representation of it and for that need all components referenced in it. There are hundreds of components delivered with Delphi (Well know such a button, edit, combobox and much much more).
But a developer can write his own component. To be usable by Delphi IDE, this component needs to be "installed". That is build in a package (A special kind of project in a .dpk file). That package must be compiled and the installed (right click in project manager).
If a component used by a form is not installed, you get the error you said. Do NOT click "ignore" in the messagebox but click "Cancel". Then close the form, install the component and reopen the form. If you click "ignore", then IDE will REMOVE that component and your application will be broken (Do NOT save it then).
You have been given the source code, so search for a .dpk file (or several). Then open it, compile it and install it. Only then you can open the form giving the error.
By the way, you should really buy a good book about Delphi. There are a lot of Delphi books. I suggest you start with Object Pascal Handbook
I have all the files needed to open the unit and code but I can't make any changes or compile because the Project.dproj and Project.dpr files are missing. However, I have the .exe file. Is there any way by which the aforementioned files can be extracted from the .exe file?
If you have all of the source files, meaning the .pas and .dfm files, then the first thing I'd do is add them all into a new project and try to compile it. It'll either work, meaning you've got everything you need, or it will generate errors.
There would be three kinds of errors:
The first is the most likely -- the forms might use components that you don't have installed. This will be obivous if you try to open the forms in the IDE. If they open without fanfare, GREAT! If you get a warning box saying "Cannot locate component: remove references to it?" or something like that, then you're probably hosed.
The second is version-specific errors -- stuff that's old and crufty and no longer supported by the language.
Third, the program may use run-time libraries that you don't have.
The compiler adds RTTI metadata, including unit names, when it builds, and if you know about how the RTTI tables are laid out it's possible to extract this. The unit list is the principal component of the DPR file, but it takes some serious work to access it and I'm not aware of any tools out there that read the RTTI tables that have been kept up to date beyond the Delphi 7 era.
As for the .dproj file, you're out of luck. That doesn't actually contain any code that gets "compiled in" to the EXE; it's a set of build instructions for how to produce the EXE. But if the Delphi IDE doesn't have one, it can generate a default .dproj from the .dpr, if you can produce that.
I'm curious, though. How did you obtain the .pas files but not the .dpr?
I'm running RAD Studio Delphi XE2. Something strange appears to have been done to one of my .pas files. Many of the lines from my unit1.pas have been replaced with simply 'º' and others are missing. I am left with a small section of code from somewhere in the middle of my original file. Can I get the original unit1.pas back by somehow decompiling unit1.dcu?
Also, why would this happen? Have you heard of this before? The code runs but, obviously, I can't edit anything I can't see.
Even if you could decompile it, it would likely be an unmaintainable mess compared to your original.
Instead, try looking in the __History folder for your project. You should find older versions of your code. Pick the newest one ;-)
why would this happen?
Any number of reasons. Bug in the IDE? Bug in an IDE plugin or a custom component? Bug in your code that overwrites a source file, maybe?
You cannot decompile a .dcu file to the original source. Information is lost in the translation from source code to executable code. Type declarations, variable names, method names, code layout and so on are simply not present in the compiler's output. Compilation is a one way process.
If you use revision control, you'll just be able to pull the latest version from the repository. If you don't use revision control, you've just learnt a lesson the hard way and you will never again attempt to perform software development without revision control.
How can i fix this error and from where I get dxDBGrid file,i'm a new in Delphi,i'm getting the: [Fatal Error] File not found: 'dxDBGrid.dcu'
As others have already told you, that's the file that contains Developer Express's TdxDBGrid. It's quite an expensive product, so before you go off and purchase it, it would be wise to see if you actually need it (I'll explain why I have a hunch you might not in a moment).
First thing to do is do a Find in Files search through all the units in your project, to see which of them lists dxDBGrid in the Uses list in its Interface section. Once you've found the file try and open it and see if the form contains a component of type TdxDBGrid. If it doesn't, remove dxDBGrid from the unit's uses list and try recompiling.
The error may go away, in which case, problem solved. The reason I think the error might go away is that typically, using a TdxDBGrid on a form causes a lot of other units from the DevEx package to be added to the unit, in addition to dxDBGrid, and usually they would appear in the unit's Uses list ahead of dxDBGrid, so if Delphi really can't find the files of the DevEx library, it's surprising Delphi isn't complaining about not being able to find those before it gets to dxDBGrid. So if it uses dxDBGrid alone of the Devex package (other units in their package typically begin with dx or cx), it's possibly only there is a historical hangover. Otoh, if the unit does use other dxXXX or cxXXX units and Delphi isn't complaining about not being able to find their DCU files, it must be finding them (in .DCU or .PAS form) ok.
If you're still stuck, post the Interface section of the unit which provokes the compiler error you described.
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.