My system configurations are a follows Delphi2010 on windows 7 professional. I have a problem with some of .dfm files in the project.
I got it as follows. First of all I needed to change some datatypes of TOraQuery component fields from TStringField to TWideStringField and I started it doing manually like opening .dfm change one by one (Find-Replace) everything was fine later on because our project is huge I decided to change everything at once so by using Notepad++ editor and by using option Find in Files and replace all I did replacement. So after this operation I started getting this error like 'TWideStringF class not found' when I wanted to open particular .dfm file. I cannot open this .dfm files even if I press ignore.
PS: Even when I try to open files that has errors in Notepad++ editor to get the line TWideStringF I cannot find it.
How to solve this problem ?
Can anyone give me a clue ?
thank you.
Try finding the "TWideStringF" in ALL your source code first to know where the problem is comming, after that, well, all dependes on what you find!
The Delphi IDE need to be able to find the classes specified in the DFM. It creates instance of these on the design surface for you to interact with.
Editing a DFM by hand is a common practice. I do it often, as sometimes it is faster than any other method. However, it comes with a problem if the class or property can not be found it can cause the DFM not to load. So extra care must be taken to insure that manual edits done correctly.
In this case you can restore the file, and redo the search and replace, or to look at the instances where it's broken and fix them all by hand.
Search for: TWideStringF I suspect you will find that is missing the remaining ield required. Note: Searching in IDE will not work as it won't search DFM files.
Related
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.
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.
I just run into a problem that came out of nowhere...
A DFM file gets read just fine from Delphi when project is built, but when I build it from command line (dcc32) I get error Error: RLINK32: Error reading file "update.dfm" Failed read
What is more stranger another project containing same file builds with no error from both Delphi and dcc.
Does anyone have a clue of what could cause something like this?
I tried to build from another location, still same.
Operating system is Windows Server 2008. Permissions seems correct.
Use SysInternals Process Monitor, and watch when it goes looking for update.dfm.
You'll probably see DCC32 frantically searching everywhere for update.dfm (except the place where it is). Or maybe it will find it, but OpenFile fails with an error.
Either way: you'll find out what exactly is going on.
To try and narrow the cause of the problem down, open the dfm with a text editor, and gradually remove properties and save until the build works. That would at least indicate if it's a problem with a particular component in the dfm.
The main thing that is different with a dcc32 is the library path in the environment options. When you build from the IDE this is used. When you run dcc32 you need to specify this.
You can do this by setting the library path for the -I and -U options on dcc32, or you can use a dcc32.cfg file to hold all your configuration for the build.
RLINK32 can signify duplicate resource so consider renaming one of the forms so as to avoid the clash. Having said that hopefully the library path should resolve the issue.
I've seen this happen when you remove a value from an enum type and that value was being used in the dfm. The next time you opened the dfm the IDE would put garbage text in where the value was. Delphi 2010 if that helps.
I would just open the dfm in a text editor and remove the corrupt text.
I found this after having the same problem which seemed to happen randomly from time to time if I changed a bit of code of added a copied a component, this time the only difference I made was changing an = to <> but changing it back worked fine except now I've changed something else it's happening again - hence the reason how I found this. Being quite a newb I didn't really understand some of the other bits mentioned here but I just found by building the project first before pressing F9 seemed to work.. just for now at least.
Hope this helps someone! :)
Is there a rule of thumb that .pas, .dfm and .dpr files should not be removed?
While opening/working with concerned project files ,Unit1.pas,Form1,Unit1.dpr etc are automatically created by the IDE in the same project-folder.As they were not related to my proj,I inadvertently deleted them.Will that cause any issue?
Further should the same project be saved with a new name every time one saves it?
Like PfojDel.dpr
edit then save as PfojDel1.dpr
edit then save as PfojDel2.dpr etc
Kindly help
Thanks and Regards
Vas
Your first question's pretty straightforward. Any file that you need to compile into your project needs to be present on the disc. Anything else can go.
As for changing your project file name, that's a big hassle. Sounds like you're trying to keep a history of your changes. If so, I'd look into version control if I were you. TortoiseSVN makes it pretty easy to create a simple source code repository, either on your own hard drive or a networked system, that you can check changes into to keep a history.
See http://delphi.about.com/od/beginners/a/aa032800a.htm for an explanation on all most file extensions you come across when developing a Delphi application.
The dfm file contains the component information for the form (or data module). The dpr is the basic pascal program file. It is also the base of the project (normally contains the list of files in the project).
Deleting them is not a disaster, but you need some time to recreate them (specially if the form is big). But if you have the choice, do not delete them.
The dfm files are created because they contain the information you provide with the form designer (position of controls and the value of their published properties).
If you have renamed your project, you can delete the other files without problem. This is also true for units that are not used anymore.
You don't have to use a different name every time you save the project. If you want to keep track of changes, use source control. (Every wise programmer should use source control and backup the files frequently).
Under normal circumstances you shouldn't have any Unit1/Form1 files on your system. The first time you save/compile/run a project with a new file the IDE will prompt you for the filename and location.
If you have a file named Unit1/Form1 then it would indicate that you have a unit or form which hasn't been given a name, but it may still be used as part of your project. If it is used as part of your project then it is not safe to delete it. The only way to know if is used is to go through each of the uses clauses in your project, or to use an automated tool to do this for you.
We have a Delphi 5 application, that is built without runtime packages, dlls or external resources (i.e. a single executable). when we install it on a clients PC we get the following error messages:
Class TListView not found
or
Class TImage not found
We have installed it on dozens of PCs before without incident, but this latest install is problematic.
The target PC is a fresh install of Windows XP (Service pack 3) with no other software installed.
It does not complain about all of the classes however just one or two. for example TPanel/ TForm/ TEdit are all OK.
Can anyone think what is causing this?
EDIT
The exe on the new PC is on 30 or so other PCs that I know of, ranging from windows XP Sp1,2,3, Windows Vista and Windows embedded. both old and new PCs were installed with an old version and then updated with the newest version. The only difference is that the version jump was higher for the latest install.
This is typically an error during the streaming of a .DFM. Usually this error occurs with TLabel components because many folks remove the TLabel fields from the form or frame in order to cut down on the clutter and reduce the instance size of the form. The common and confusing mistake they make, however, is that in their over-zealousness, they remove all TLabel references. That is when bad things start to happen. Let me run down how the streaming system locates a component's class.
Remember that the class reference in the .DFM is just a string. The streaming system has to convert this string into a class reference (TComponentClass). There are two mechanisms that the streaming system uses to do this. The first one is very simple and involves a global list of class references. You can call RegisterClass or RegisterClasses to explicitly make the streaming system aware of it. The second is much more subtle and not very well known; in fact it is all part of the "magic" of Delphi :-). When the compiler builds the form, all the fields that represent the components on the form are processed and an internal table is built as part of the RTTI or metadata for the form/frame/datamodule itself. This table contains a list of references to all the individual component types represented by the component fields. So even if a component is not in the global list, it can still be found by scanning through this compiler generated table. That is what the Classes.TReader.GetFieldClass() method does.
Back to my TLabel example, this problem is easily fixed by simply ensuring that at least one of a given component type has a field. So as long as there is at least field of type TLabel, all the other TLabels will load just fine. So in your case, make sure the TListView or TImage fields haven't been deleted.
Re0sless,
I suggest you open and close every form of your application and do a fresh build after that. If memory serves me well, that was the solution when we encountered similar problems.
You might also take a look at DFM Check to open and close all your dfm's automatically and at CnPack to help you clean your uses clause.
Regards,
Lieven
I think Lieven is definitely on the right track: simple base classes not being found during runtime are a Delphi (linker) problem. This exception is not caused by the Operating System.
My experience with similar problems: the linker generates a project with the units wrongly arranged.
Example: a form unit is linked in before the base units. Forcing the project to completely recompile/relink itself should make this exception go away.
A simple [Rebuild All] will probably not suffice. You might try to recompile without optimizations.
I have tried to reproduce this error but I have not been able to. The Delphi compiler/linker is one of the best - speed of compilation/speed of compiled exes - but this bug is definitely a show stopper.
Note: I have only experienced
this error in D5. Has anybody else
experienced this error with other
Delphi versions?
I had the same problem. Class TCheckBox not found. I usually edit large set of components through .DFM of form(for example renaming large amount of component). This error comes when I rename all CheckBox on my form through it .DFM.
I just cut all the checkbox and paste them again(So .DFM file is refreshed). The error disappeared.
I've seen a similar problem due to a file copy error. To make matters more confusing, the fault was on an intermediate media device. The issue was resolved by simply recopying the file from the existing release build.
It is probably impossible to confirm now, but it is quite possible that the problem was 'solved'; not because of the removal of an unnecessay uses clause item, but because it also involved a new copy of the executable.
The solution for all errors of this type "Class XXX not found" is simple. Open DFM file of a form in text editor and manualy remove the definition of the XXX object in it.
Change the name of the Form and save the .pas with other name. Change all references to create the new unit name if this is used in other units. Build All.
With this the error disappeared.