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
Related
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.
good day! i have a project and it runs perfectly, i did that project 3 months ago. Then, i tried to put some changes and even BUILD ONLY the project (no additional codes). When i open the .EXE it appears errors like this.
when i clicked DON'T SEND
and when i clicked OK
When i opened the form this message appers:
How to fixed it? I really need to add some functions to that project.
Thanks in advance!
Your .dfm file refers to a property that is not published by the component which is being streamed. The streaming framework is attempting to read into a property named Quality of an object named frxPDFExport1. And that object does not publish a property of that name.
Most likely there's a mismatch between the design time package that you used to generate the .dfm file, and the run time component that is reading that .dfm file. Have you upgraded one and not the other recently?
I'm afraid I cannot give you precise steps to fix the problem, but what I describe above is what is happening. Hopefully that will be enough to lead you to the solution.
You must have updated the component used, which looks like Fast Reports. You need to open up the form in Delphi and the new property will be added by Delphi. Any other forms that use the same component will also need to be opened up to update the properties.
When the error reading form message comes up, click ignore. This should add the missing property. You will want to view the DFM as text to make sure the property has been added.
In delphi, creating ActiveX controls was something that was once more popular than it is now. However it remains possible to create ActiveX controls with Delphi. This question assumes Delphi 2007, but it should be the same no matter what Delphi version you use.
There are some strange errors in Delphi when you create ActiveX controls. IN my case, I can
now no longer import a certain class that I am trying to import and wrap, and Delphi won't tell me why any more, just that it could not load the unit "symbol information".
In this case, I am wrapping an open source control, and my first few attempts to wrap it worked fine, but I found that I had to redo the import once I found properties that were written in a way that the ActiveX wrappers were missed. It's easier to regenerate an ActiveX wrapper than to fix it by hand. Until you get stopped cold like this:
Error
Could not load unit [unit] symbol information for [TClassName].
Do you want to try to find this file yourself?
If I click Yes, I get a browse (file open) dialog and it has the file filter set to "DCU". Which means, it wants me to find the DCU file for this unit. If I browse to it, or if I don't, the results are the same. No amount of recompiling will clear this error condition.
does anyone know what this error really means, and better yet, how to fix it? Googling this particular error message shows it comes up in forums other than English, but is so obscure nobody has yet documented it.
There is an issue with the Library Path in Delphi, that for the ActiveX Control wizard to work properly, all sources needed for the parser to parse the unit in question must be in the library path. Since the ActiveX control wizard functions outside your project, your project search paths are NOT included in the list of folders that are used to parse the sources of the VCL control that is to be wrapped and turned into an ActiveX Control.
Solution:
Fix the library path.
I am a .Net programmer and I'm currently debugging a Delphi application and as I go along
I encountered the following error:
Could you explain to me what is this error, and how I can resolve it?
I am new to using Delphi.
Error Explanation
The error that is been presented to you is telling you that a component on that form is not registered in the IDE, in this case TsStatusBar which is from the AlphaControls library: http://www.alphaskins.com/
The form would have been saved at some point with TsStatusBar placed on the form. When any component is added onto a form they leave references to the component in both the forms source file (*.pas) and the inside the forms dfm. This is why you are getting this error, because the component cannot be found, yet the references linking to it still remain.
Option 1 - Install the AlphaControls packge
The best option would be to install the components that are missing, this will solve your error problem as shown in your question.
Option 2 - Convert Project
AlphaControls provides a tool to convert a project from standard VCL to AlphaControls and vice versa, this may be an easier option then installing the AlphaControls package or manually editing source files, the convert tool is free. Just remember to make a backup before converting should anything go wrong.
Option 3 - Manually Editing the Source Files
You could manually remove these references yourself. Do note though, if you remove the references then Delphi will no longer know that the TsStatusBar was ever there, and without a doubt there will be code somewhere that would have interacted with this component which will create compiler errors.
As an alternative to removing the references, you could rename them from TsStatusBar to TStatusBar, which is a standard statusbar from the VCL. At worst there may be some small syntax errors that may need correcting. If you do decide to edit the forms source and dfm files then I would suggest you do it before loading the form into the IDE.
Option 4 - GExperts
You can also install an IDE Expert such as GExperts which can automate the process of renaming/converting component references.
I would however advise against removing or renaming the references in this circumstance as it seems the project is reliant on the AlphaControls package.
Summary
I can see there are more components from the AlphaControls package been used, so fixing the TsStatusBar error manually will only fix part of the problem.
If the project must remain in its current state then Installing the AlphaControls package is the way to go, if you are able to edit it then I would also suggest the project convert option, this way you won't even need the AlphaControls package.
If you do chose to install the package, it is important to realise that once you install the package Delphi knows where the source files are to be able to compile. After installing the packages, goto Menu > Tools > Options from the IDE, then you need to go to Library and add the folder for the AlphaControls source to the library path. The source folder will be the one containing the most .pas files, but you could add all folders if you are unsure. If you don't add to the Library path then Delphi will not be able compile when using the new components.
Your IDE does not have the package which contains TsStatusBar installed. Find that package, build it, and install it.
Design time components need their code to be integrated into the IDE. This is done using what are called packages. The package project has extension .dpk. You should find this package project in your revision control system. Load the .dpk file in Delphi, click Build from the package manager, and finally, when built, click Install. Now that the package with your component is known to the IDE, your form will load. Whoever maintains this code in your organisation will be able to help with all the details.
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.