It’s likely that the WordPress system deleted parts between angle brackets because it thinks it’s invalid HTML and WordPress is PHP.
Achim Kalwa:
That is a long living bug: https://quality.embarcadero.com/browse/RSP-11308
Still exists in Berlin Update 2.
Jeroen Wiert Pluimers
For more than a decade, the IDE rewriting dproj files in different order/indentation/spacing, properties appearing/disappearing in DFM files and writing DFM files despite no changes have driven me even more nuts than I was.
Walter Prins
+Jeroen Wiert Pluimers Yes. Given that .dproj is XML I’ve been almost annoyed enough to look at making some kind of pre-checkin script to force sort things to try and avoid the issue. Almost… Edit: Ah, just checked that RSP, which references this: https://github.com/joshkel/RadCli Seems someone has already done it.
Lübbe Onken
Did you try tidy_proj +Walter Prins? For me it fails with a “Unicode Encode Error” when I try to write an output file. In my case this is caused by German umlauts in the excluded bpl section descriptions. Changing the umlauts to something low-ascii allows tidy_proj to finish.
Walter Prins
+Lübbe Onken No, but I have just done so. Unicode bites again. To fix that error, change line 125 from:
print(proj.toxml())
to:
print(proj.toxml().encode(‘utf-8’))
Note: This will likely not display correctly if you allow the output to go to the console but will ensure it is correct if redirected back to file.
Edit: Ha, I was about to go report this issue ad suggest this fix, but I see you’ve already suggested essentially the same fix. ;)
Jeroen Wiert Pluimers’s profile photo
Jeroen Wiert Pluimers
+Walter Prins interesting tool! Do you know of a tool that can downgrade .dproj files so you can use them with older Delphi versions? (the opposite of what the IDE does)?
Or someone that has written more than my XSD on .dproj files? My one is so small that’s hardly a real attempt. https://wiert.me/2013/08/31/delphi-first-try-on-an-xsd-for-groupproj-files/
Walter Prins
+Jeroen Wiert Pluimers No, but interesting idea. I suppose you’re probably aware that the JEDI JCL/JVCL takes a somewhat similar (ish) related approach, in that it generates project and package files that are compatible with every desired version of Delphi from minimalist (XML) template files. Every so often I think it might be worth looking whether one can re-use the code from there easily but haven’t gotten around to it. Always something else to do first. :/
Jeroen Wiert Pluimers
+Walter Prins no I didn’t. Where should I start reading on that minimalist template approach?
Walter Prins
+Jeroen Wiert Pluimers Sorry I see I missed out the word installer in my comment: It’s the Jedi JCL/JVCL installers that uses xml templates etc.
But the point stands: I guess it should be (perhaps) possible to reuse its infrastructure for ones own projects, though as I say I keep meaning to look into this but haven’t really done so.
(BTW I’m assuming you are familiar with the JCL/JVCL and in in particular their installers that bootstrap from source code? If not then perhaps my comments may not be that useful?)
Anyway, not sure if or where there’s particular documentation about this (kind of doubt it), but if you have the JCL/JVCL installed somewhere, then first of all have a look at the “xml” folders e.g. “<jclroot>\jcl\packages\xmls” and “<jvclroot>\jvcl\packages\xml”.
These files appear to define projects and packages in a seemingly abstract/somewhat minimal way using XML. This seemingly is then used to automatically produce .dproj and .dpk files which are placed in e.g. “<jclroot>\jcl\packages\dXX” and “<jvclroot>\jvcl\packages\dXX” where dXX corresponds to a folder for each of the supported Delphi versions and compiled/used during installation.
Having just looked into this briefly a bit further as a result of this conversation: Key units here (in the case of JVCL) seems to be “<jvclroot>\devtools\PackagesGenerator\PackageGenerator.pas”, “<jvclroot>\install\JVCLInstall\PackageUtils.pas” and “<jvclroot>\devtools\common\PackageInformation.pas” (used predictably by <jvclroot>\JVCLInstall.dproj)
(Additionally, having looked at this a bit more closely, it also appears that the JCL does not actually replace all or even most of its .dproj and .dpk files after all, but ships version specific .dproj and .dpk files in most cases, though the JVCL does appear to mostly do so. )
Edit: The JCL also has this interesting sounding unit “jclroot>\source\windows\JclMsBuild.pas” which appears to be an MSBuild project file parser…
The Wiert Corner - irregular stream of stuff 