Registry multi strings - help!

[Andy]

I'm reading registry multi strings now, no problem, but I'm not sure I'm saving them correctly.

You are supposed to save them in this format:

string1\0string2\0string3\0\0

where the \0 represents a null character, plus an extra null at the end of the entire string.

I'm using an edit box for the input string (multi edit), and each character is saved into an istring.

Now for each end of line there are chr$(13) and chr$(10) characters generated by the edit control.

When writting back to the registry, I have tried transposing these two characters to \0 or chr$(0) - that doesn't work, so I've used \n instead.

Some sites suggest L"string1\0string2\0string3\0\0" - are they suggesting / hinting at a word string here? - that's something I've really never touched.

I'm not sure I've got the writting back quite correct yet - anyone got any thoughts / help on this?

Thanks,
Andy.

[Brian]

Andy,

I was curious, so I tested this with a small console program

I PRINTed "Carriage Return\n" and when I viewed it with a hex editor, there was just one 0D 0A
at the end of the line, which is a carriage return, linefeed. You would expect the PRINT statement
to put a CRLF at the end as standard anyway, but I expected that there would be two CRLFs

When I printed "Carriage\nReturn" the \n returned a 0D 0A as well as a 0D 0A at the end of the line

A Macintosh only puts a 0A at the end of a line (just a linefeed). Well, it used to, could have changed!

Brian

[Andy]

Brian,

I have never fully trusted a console output, I tend to open a text file, send the output there, then I can check it.

But thanks for the interest.

[LarryMc]

when you get through editing try creating a CHAR buffer that is longer than all your strings + all the required nuls
then copy each string to its corresponding location in the buffer
when through copy the buffer to the registry

since a nul signifys the end of a string to IWB you have to use some sort of CHAR buffer to get more than one string in there

[Andy]

Thanks Larry,

CHAR is the answer, and that's how I cracked the binary side of things, so this morning I amended the reading of binary section (to check) to also read in / save mutli strings -

The hex representation of the multi string was completely correct, and I amended a multistring (using hex) and the string was written correctly to the registry, more over, regedit displayed it correctly and when editing it and then saving the string in regedit everything was just perfect.

It just now remains for me to amend my program so the user can type in characters rather than hex values.

Thanks again!

Andy.