$readini quote handling issue - mIRC Discussion Forums

Hi guys,

I discovered various MSL (mIRC Scripting Language) differences between mIRC 6.35 and newest v7.02 BETA.

Example ($readini):
File: some.ini
Content:

Code:

[Section]
item="+p "

Command used:
//echo -a $readini(%some.ini,n,Section,item)
mIRC 6.35 brings:

Code:

+p

(including the space)

mIRC 7.02 brings:

Code:

"+p "

So here is my question: is there anywhere a MSL changelog? Just good to know for us scripters.

Kind regards,
$me

The full list of changes is included in the versions.txt file that comes with each release. In the case of ini file handling, this issue is related to number 2 in the change list:

2. mIRC now uses its own custom ini routines to ensure more reliable ini file handling. They should work almost identically to the standard Windows ini routines.

The issue with quotes for ini file section/item/data has been fixed for the next version.

Originally Posted By: Khaled

The issue with quotes for ini file section/item/data has been fixed for the next version.

Cool, thanks for quick response & help :-) .

Kind regards,
$me

Originally Posted By: Khaled

The full list of changes is included in the versions.txt file that comes with each release. In the case of ini file handling, this issue is related to number 2 in the change list:

2. mIRC now uses its own custom ini routines to ensure more reliable ini file handling. They should work almost identically to the standard Windows ini routines.

The issue with quotes for ini file section/item/data has been fixed for the next version.

one small thing: I just checked the link and it still has the non-beta v6.35 info there. so your reference to item #2 on the beta changelog is not there. is it possible to keep the versions.txt that comes with the beta installation online somewhere too simply for our reference?

[edit:] I just noticed the forum automaticcaly parses the 'version . txt' text into a link so it wasn't actually khaled's intent to post a link I guess ;-]

Yeah, the file is in your mirc install folder. It just links to the current non-beta version here if you type the filename so that people can easily link to it if someone needs it.

Reading works fine (7.04). However, re-writing the INI file, as caused by writeini on a different section/key, screws up entries that had quotes before.

Here is an example:
INI file (before):

Code:

[blah]
suffix=" \x02\x0315~~\x03"

(\x02 and \x03 are stored in their actual byte representation, not escaped or hex-encoded)

Calling GetPrivateProfileStringW on that reads the value just fine.

However, after writeini has been issued, the INI file looks like this:

Code:

[blah]
suffix= \x02\x0315~~\x03

...which causes GetPrivateProfileStringW to return the value stripped of \x02 and \x03 (only "15~~" is left), which of course, presents a major incompatibility.

I'd suggest to either keep track of whether an entry was in quotes when rewriting the INI, or adding quotation marks to every value that contains characters below 32.

Thanks, Khaled!

It looks like v7.04 is not using quotes to enclose lines that begin or end with spaces, so that should be fixed for the next version. Would that resolve the issue that you are seeing?

Hey, thanks for replying so fast. Unfortunately, I'm afraid that won't solve the issue. The problem are $chr(2) and $chr(3), not the leading space.

Quick examples:

Code:

[Blah]
Test=\x02Bold\x02

GetPrivateProfileStringW returns "Bold" (42 6F 6C 64 in hex).
Not what we want! Different to what has been stored in the INI file before.

Code:

[Blah]
Test="\x02Bold\x02"

GetPrivateProfileStringW returns "\x02Bold\x02" (02 42 6F 6C 64 02). Correct!

I have no idea why Windows is doing this, but it's an incompatibility between mIRC's INI routines, and Windows'.

Thanks!

Keep in mind that $chr(2) and $chr(3) are non-printable characters. It's unreasonable to expect non-printable characters to behave correctly in a file format that is designed to be modified with a standard text editor -- even if you can get away with using them in mIRC.

It would be preferable to replace any non-printable characters with an escape sequence instead, or use a more appropriate file structure.

Originally Posted By: drum

It would be preferable to replace any non-printable characters with an escape sequence instead, or use a more appropriate file structure.

Unfortunately, that's not an option in my case because I need to support .ini files written by old applications. Also, mIRC 6.x has never destroyed INI files with these characters in it, so I would certainly expect mIRC 7 to keep them intact as well.

In the past, I often received reports from users that INI files were being corrupted over time whenever non-printable characters were written to them, so previous versions of mIRC prevented the writing of color/bold/etc. control codes to INI files by stripping them out.

It looks like you are trying to bypass that by writing these characters to INI files using Windows INI routines in an external application?

The new version of mIRC uses its own INI routines to ensure that you can write any characters to INI files without the Windows INI file routines corrupting them. So by design, INI files containing these characters will not be compatible with the Windows INI routines.

That said, I can't be sure of what is happening without having a method that reproduces the issue.

Quote:

I'd suggest ... adding quotation marks to every value that contains characters below 32.

This change will be in the next version, ie. it will only affect lines that contain characters below 32. Please let me know if that resolves the issue for you.