Here begins the voting for differences. I actually do not care for the inclusion of the extra Var1.F variables as, mentioned earlier, is that variable used elsewhere? Plus, it implies that it maybe part of a calculation instead of an upcoming, disposable CRT statement.
Will I rot as I use this CRT statement? CRT OCONV(VAR1,"MD0")"R#6':" ":OCONV(VAR2,"MD2")"R#10":" ":OCONV(VAR3,"MD4")"R#14". If so, I wonder how much company I'll have. My 1 cent. Oddly enough, to make things more interesting, I would have coded it this way: CRT VAR1"R0#6":" ":VAR2/100"R2#10":" ":VAR3/10000"R4#14" Less typing. For output, the only time I use OCONV is a "MTx" time conversion or if the value isn't justified and I want the all the decimals. I use DATE()"D2/" beaucoups of times. ----- Original Message ----- From: "Brutzman, Bill" <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> Sent: Monday, November 19, 2007 2:41 PM Subject: RE: [U2] OCONV Extraction Question - Good Practice > The problem of printing non-atomic data gets worse when doing reports with > tables, that is, long lines with several variables. Consider the following > remedy. The alternative is a nightmare. > > --Bill > > >>> Speaking of mis-used commands and side-stepping some of the given code > >>> craziness... > >>> > >>> It is better practice to atomize the code into discrete elements such > >>> as... > > Var1.F = oconv(Var1, 'MD0') > Var2.F = oconv(Var2, 'MD2') > Var3.F = oconv(Var3, 'MD4') > > Crt.Str = Var1.F 'R#6 > Crt.Str := Var2.R 'R#12' > Crt.Str := Var3.F 'R#14' > crt Crt.Str > > > >>> rather than to try to kill two birds with one stone by including an > >>> oconv statement inside a crt statement such as... > >>> > >>> crt oconv(Var1, 'MD0') > >>> > >>> --Bill> > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
