Re: Problems with null in a report with Informix-4GL

Well, I stand corrected. Still sad you lost your argument. With this use of ASCII 0 it's prety hard to get it into a variable to actually print it. To write print ..., ascii 0, ... isn't very usefull. You can't easily control printers that way. Anyway, we have put our solution totaly outside of 4GL by now so it's no problem for us any longer. (We print generic codes and translate those via a filter before they are printed. In that way we can even make column xx work in a fashion.) I allways thought it very unfortunate that Informix never put proper printer support and a few other things into 4GL. With that they would still have had one of the greates reporting tools on the market. As it is now it's barly adequate, but still hard to replace for advanced reporting purposes. On Sun, 15 Feb 1998 02:45:33 GMT, yosemite@netcom.com (Alan Denney) wrote: >In article <34e02f8d.6262187@gate.idg.no>, >Nils Myklebust <Nils.Myklebust@nmdata.com> wrote: >>This is because 4GL is based on C and uses the strange C idea of a 0 >>byte as a terminator for a string. It doesn't change your 0 byte to a >>blank. It stops printing when it finds the null byte. Anyting after >>that is not printed at all. >> >>>(let a = ascii 0, ...etc. ) to a report to use it with an HP printer. >>> >>>I think it changes it to a blank character. > >No, it's actually deliberate -- starting with 4.1-something, ASCII 0 >was documented to produce SPACE when used in all statements except >PRINT, but to actually produce a zero-byte when used in PRINT. Check >the release notes or the 1996 editions of the 4GL Supplements. > >(Don't shoot the messenger -- I fought the SPACE interpretations tooth >and nail at the time... but, as usual, I lost...) > > >-- >Alan Denney yosemite_at_netcom.com > >"Virtuous motives, trammeled by inertia and timidity, are no match for > armed and resolute wickedness." -- W. S. Churchill > Nils Myklebust NM Data AS Norway E-mail: Nils.Myklebust@nmdata.com