How to convert DFM to Text?

wolbrink · Post by **wolbrink** » Wed Sep 30, 2009 11:48 am

Just like how IA now creates *.mia.txt files to better help developers track changes to their scripts, I'm trying to build a tool that can create *.dfm.txt files so that I can better track changes to my dialogs.

I was guessing that Delphi's Classes.ObjectBinaryToText() would be able to handle this for me. But I'm finding that's not the case. Any clues or hacks that might help me?

Thanks!
Troy

paulm · Post by **paulm** » Thu Oct 01, 2009 3:54 am

If you have Delphi you could use the convert.exe found in the BIN folder

Command line something like...
"C:\\Program Files\\CodeGear\\RAD Studio\\5.0\\bin\\Convert.exe" c:\\temp\\welcome.dfm c:\\temp\\welcome.txt

Paul

wolbrink · Post by **wolbrink** » Thu Oct 01, 2009 8:28 am

paulm wrote:"C:\\Program Files\\CodeGear\\RAD Studio\\5.0\\bin\\Convert.exe"

That worked great. Thanks, Paul.

--Troy

wolbrink · Post by **wolbrink** » Thu Oct 01, 2009 8:33 am

wolbrink wrote:Delphi's Classes.ObjectBinaryToText()

I just noticed it's actually: ObjectResourceToText().

I'm glad I can track my dfm changes in version control now!

--Troy

neillans · Post by **neillans** » Fri Oct 02, 2009 3:29 pm

One question for you guys ....

How would you feel if InstallAware natively supported TXT DFM's and allowed saving scripts as XML files (natively) ?

wolbrink · Post by **wolbrink** » Fri Oct 02, 2009 3:42 pm

neillans wrote:One question for you guys ....
How would you feel if InstallAware natively supported TXT DFM's and allowed saving scripts as XML files (natively) ?

TXT DFM's would be great. One less process I must run after editing dialogs.

Saving scripts as XML files natively? While that might be better than the current binary format for the *.mia file, I still like the *.mia.txt file because it closely reflects the script editor in which I'm used to working. I can imagine the XML file wouldn't be quite as intuitive to look at as the *.mia.txt file.

--Troy

DThrasher · Post by **DThrasher** » Mon Oct 05, 2009 11:32 am

I support having a serializable format for the .dfm files. It would make version control so much easier. Having a .txt or .xml representation of all InstallAware script files would be a big help.

It doesn't really matter which format is used, as long as I can compare changes using a tool like WinMerge or BeyondCompare.

Chris Miller · Post by **Chris Miller** » Mon Oct 05, 2009 3:33 pm

I would prefer the text format too. Much easier to resolve the diffs.

MikeOnline · Post by **MikeOnline** » Mon Oct 05, 2009 9:49 pm

neillans wrote:How would you feel if InstallAware natively supported TXT DFM's and allowed saving scripts as XML files (natively) ?

Changing from a TXT export to an XML export does not necessarily address a key limitation: the current text export of MIA scripts omits parameters for several commands (e.g. CALL DLL, MESSAGEBOX, etc). So comparing two versions of an MIA script's TXT files using a diff tool may not reveal several key differences. People seem to think they can store the TXT file in their source code repository and be able to track script changes over time, but this only works to an extent.

To address this limitation, and provide other advantages, I suggest the following:

1) Have the text exports contain full parameters for each command, in an easy-to-read, one-line format. If possible, a generalized export format (e.g. a list of field values, listed sequentially after the main command name, delimited by a semicolon) would be available even for plug-in commands. A future specification for plugins would call for an optional, one-line text format, so text exports of never-before-seen plug-in commands would be more readable than if they relied on the generalized export format.

2) Save TXT exports of both Script and Dialog files upon every save (presently happens only when saving MIA files)

3) If it makes sense to do so, abandon DFM and MIA files: replace both with corresponding XML files, which the InstallAware IDE and command line builder would use instead of the old files. These would be easier to programatically inspect (or edit) than the current files. Ideally, the XML schemas and basic XSLT's (for reporting purposes) would be made publicly available. And (ideally) there would be no need for GUIDs.

4) Combine the dialog rules file (MIAF) and diaglog definition file (DFM) into a single XML file; when exporting this file to text, include the rules at the end, in their own section.

Regards,
- Michael Litwak

ALive · Post by **ALive** » Tue Oct 06, 2009 11:25 am

Great idea, Mike!!! Especially about XML (and no *.mia at all)

I hope IA would hear you!!

I would add Unicode support! And much better Localization mechanism.

Cheers.

MikeOnline · Post by **MikeOnline** » Tue Oct 06, 2009 12:39 pm

When I have encountered runtime errors with InstallAware installers, I have wished that I had the means to validate my InstallAware project files. It would be a great boon to be able to verify that InstallAware project files were not corrupt in any way.

If all the project files -- including .MIA, .MIAF, .DFM, .MPR and any others -- were XML files (with publicly-available detailed schemas), then validation would be a snap. The XML's would simply be validated against the corresponding schema file.

- M

Bikedude · Post by **Bikedude** » Mon Nov 02, 2009 3:57 am

MikeOnline wrote:3) If it makes sense to do so, abandon DFM and MIA files: replace both with corresponding XML files, which the InstallAware IDE and command line builder would use instead of the old files. These would be easier to programatically inspect (or edit) than the current files.

...but a .dfm file (as text) is really easy to read and understand for humans.

And as I recall from my Delphi days, it is not too hard to stream in a .dfm file either so you can deal with it programmatically. (XML? Easy to programatically inspect..? Really? Are we discussing about the same messed-up standard?)

But anyway: I was very surprised and disappointed when I realized IA's .dfm files were binary. That is so... 1995. Delphi fixed that in D2 as I recall. I've been very careful saving all my .dfms as text ever since. (for extremely obvious reasons!)

Tommy · Post by **Tommy** » Mon Nov 25, 2013 4:53 am

Hello,

Among many different project files just the DFM file is binary, which makes more difficult to work with revisions, as former posts claim.

Is there any progress or plan on the roadmap to eliminate this obstacle and render all project related files to a text file ?

Regards,
Tommy

Post by **FrancescoT** » Mon Nov 25, 2013 12:52 pm

Unfortunaly, this is not currently in our plans.

Regards