>Hi Dragan:
>
>Up to now I never found this special character on a PRG file (ascii 0 to ascii 31 are special control codes, where 0=null, 7=tab, 10=LF, 13=CR, 26=EOF, and so on), but found some on the "methods" memo field of some SCX and VCX files. As you probably know, these memo fields contains the method source code of those VFP binaries, and are compiled into another memo named "objcode" (the FXP part)
>
>With this methods you can create a real PRG and can compile normally without warnings when a null character leaks into the source code (in example, at the end of a LPARAMETERS line) that you normally can't see with VFP editor, but can see with other editors or hex editors.
>
>This case is known one, and is a bug, but what I am asking is if someone know a case in which this special character can be there on purpose.
>
>You can emulate this case with something like this:
>
>

>strtofile( "LPARAMETERS aa,bb,cc" + chr(0), "my_prog.prg" )
>COMPILE my_prog
>

Theoretically possible. VFP uses nul terminated strings (file field in a pjx file, for one; lots of nulls in dbc binaries as well), and if you wrote some code to manipulate these, you could use a nul character in a string literal. Though I don't know why would anyone have that, as these are invisible in the editor and then easily edited out accidentally, which would then break such code. We have tools like chr(0) and 0h00 to express the null character, which are rather obvious and kind of self-documenting.

If you suspect that you got some stray nul characters in your code... occurs(chr(0), filetostr("myprg.prg") or the or occurs(chr(0), myvcx.methods) (on every vcx/scx, every record) would tell you.