I noticed one more problem in setformat, when you place the &#13&#10 inside the string specifier so that each entry is on a seperate line, the outputed file contains extra &#13 characters.

File: test.zip

Desc: test file

....

When you use WordPad to open the generated file, it displays the the lines as:

File: test.zip Desc: test file File: test2.zip Desc: test 2 file.......

Where notepad displays the file as:

File: test.zip
Desc: test file

File: test2.zip
Desc: test 2 file

If you open the resulting file in a hex editor you will see the extra &#13 character. It looks like this extra &#13 character is only outputed when &#10 is specified in the string specifier.

Changing the format of the string specifier to:

string="File: %f.zip
Desc: %d
"

Fixes the generated file to display correctly in WordPad.

File: test.zip
Desc: test file
....

Any ideas as to why using 
 adds this extra &#13 in the string specifier?

Get a real editor 8)

It's the old story of ANSI / DOS Format. Some editors don't understand a single 0xa etc., others do.
I prefer TextPad (and notepad for smaller stuff) and both work fine with the current linefeed/newline commands.


Roman Scherzer

> Get a real editor 8)
>
> It's the old story of ANSI / DOS Format. Some editors don't understand a single
> 0xa etc., others do.
> I prefer TextPad (and notepad for smaller stuff) and both work fine with the
> current linefeed/newline commands.
>
I would expect Clrmame Pro to output both the string format and the seperator format the same. But if you specify &#10 in the string format, it adds an extra &#13 character before the &#10 character in the generated file.

Place the following tests into setformat01.xml:

<SetFormat>
<Format name="Test 1 &#13&#10" pre="" post="" separator="&#13;&#10;" string="Test 1&#13;&#10;"/>
<Format name="Test 2 &#10" pre="" post="" separator="&#13;&#10;" string="Test 2&#10;"/>
</SetFormat>

Scan a collection in Clrmame Pro, and use the export set list to output both formats. Then use a hex editor to open both files.

The Test 1 generated file looks like:

54 65 73 74 20 31 0d 0d 0a 0d 0a

when it should have been generated as:

54 65 73 74 20 31 0d 0a 0d 0a

The Test 2 generated file looks like:

54 65 73 74 20 32 0d 0a 0d 0a

when it should have been generated as:

54 65 73 74 20 32 0a 0d 0a

It's just strange that the 'separator' gets output correctly, while the 'string' contains an extra &#13 in these two tests.

Most likely a sideeffect of MFC's CFile::WriteString() which is used to save the final string to a file...iirc it automatically adds a linefeed or something.
I will recheck that later at home.


Roman Scherzer

It's indeed caused by the library function CFile::WriteString(...). Any newline character in the given string is written to the file as a carriage return–linefeed pair. So that's where the doubling comes from.

Copy to Clipboard works correct though ;)


try this: www.clrmame.com/cmpro.zip



Roman Scherzer

> It's indeed caused by the library function CFile::WriteString(...). Any newline
> character in the given string is written to the file as a carriage
> return–linefeed pair. So that's where the doubling comes from.
>
> Copy to Clipboard works correct though ;)
>
>
> try this: www.clrmame.com/cmpro.zip
>
>
Thanks for fixing the problem