I have updated the DFMCheck IDE plugin to support RAD Studio 2010 and XE. Version 1.41 also fixes an “out of memory” bug that was introduced in 2008.
DFMCheck converts the object structure of all DFM files that are used in the project file to a *.pas unit. This special unit is then sent to the compiler which will fail if there are components in the DFM file that are missing in the corresponding form/frame/datamodul class. The plugin does not check for missing properties or events. Only the class names are checked.
| Name | IDE Version | File | Size | Downloads | Added |
|---|---|---|---|---|---|
| DFMCheck 1.6 | 5-10.3 | DfmCheckSetup16.7z | 717.43 KB | 3090 times | 2018-12-08 |
Pingback: DFMCheck 1.41 released
Apart from optimization and ease when developing in notepad (not having a IDE with form designer) is there any other solid reason to use .pas intead of .dfm? Maybe I miss something?
The version of the installer shows 0.0.0.0 and the installer seems a bit big for what it contains. Maybe you haven’t used high compression like LZMA2?
The installer contains the plugin for all supported Delphi version. That means there is a DFMCheck5.bpl, DFMCheck6.bpl, DFMCheck7.bpl, … in the installer. And then there is the installation helper CompInstall.dll file that is 536 kB (it contains parts of the JCL).
Hi Andy,
I’m sorry for posting comment in the wrong thread, but the original post’s comment is now disabled. (You may delete this comment after viewing it.)
In your IDE fix pack 4.0 RC2 for XE, there seem to be a bug in dcu caching.
The bug manifests when two projects are loaded, the first is a package and the second is an executable, and the executable project *has dependency* on the package. And then, if you modify the source of the package, and compile the executable project.
Normally, this would trigger recompile of the package and then the executable. But with IDE fix pack RC2, after compiling the package, the IDE *often* stops compiling and prompts a strange error, saying that some unit in the package is compiled for another architecture. The faulting unit changes on different tries, and the name of the architecture also varies, sometimes “x86 MacOSX”, sometimes “ARM Linux”, and sometimes “MIPS …”
I suspect it is because the IDE fix pack fail to update some dcu cache, which leads to mis-alignment of the architecture flag fields from the IDE’s perspective.
> sometimes “x86 MacOSX”, sometimes “ARM Linux”, and sometimes “MIPS …”
Are you sure that this comes from the compiler?
RC 3 will come soon.
I was quite confused too when first I see these error messages… 😛 Not sure where they come from, possibly the compiler or some IDE internal module…
When I disable the IDE fix pack, this type of error stoped occuring.
Hmm, I just found another (less obscure) way to reproduce the error. Hope this can help you find out the bug.
1. I was experimenting on customizing RTL, so I have a project with unit search path pointing to my own directory with my custom system.dcu and sysinit.dcu.
2. After some compilations, I decided to close the project, and create a new test project that uses stock RTL to verify some code behavior. But then, the IDE refuse to compile the new project, claiming the system.dcu was compiled differently.
3. I closed and restarted the IDE, now it compiles the new project fine.
So it seems that the dcu cache didn’t update when the IDE is switching between projects. The correct behavior will be to check the dcu file in unit search path, and update if the file is newer, or the matched file path is different from the cached one (or — just flush all dcu cache when switching projects, if that’s easier to do :P)
@Gad: AFAIR (haven’t tried 1.41 yet) the *.pas files are generated just for the checking process and are removed by DFMCheck when it’s done. You probably think of GExperts’ Components to Code (http://www.gexperts.org/tour/components_to_code.html).
The installer doesnt support delphi 5 version ;S
Pingback: DFMCheck 1.41 released