Re: %trim

Bob Cozzi wrote:
> But if the field was fixed length, and we needed to do a %Len() on it,
> would first moving it to a VARYING field be any different? Wouldn't we
> have had to do a %trimR(fixed-field) on it to get it in the varying
> field in the first place?

The answer is to use varying length strings everywhere if possible,
and if necessary, redesign your database appropriately.

If you can't change your database, then at least use varying length
string variables in your program, and then you only have to do the
%TRIM() once.

> Also, when will you add the second parameter to %TRIM/R/L that supports
> a character string value, so we can trim off more than just blanks?

Uh, that will be when a sufficient number of people vote for it when
(or if) there's another RPG enhancement poll.

> One last thing, you recently suggested using CHECKR instead of %TRIMR on
> a field to find its length.
> Is %TRIMR slower than CHECKR in this situation? If so, why?

Really?  I suggested %CHECKR() as an alternative?  I suppose that
would work, but in a more verbose manner than %TRIMR(), since you'd
then have to use the length returned by %CHECKR() in a %SUBST
expression.  Off-hand, though, I doubt if it would be any faster
than %TRIMR() since it would still have to loop through the
characters of the string.

BTW, you've just suggested a good alternative to the idea of
specifying which characters to trim off a string.
"%TRIMR(STR:'xyz')" could just as easily be coded *today* by
somthing like "%SUBST(STR:1:%CHECKR('xyz':STR))".  Since the
functionality can be achieved today, that moves the suggestion lower
down on the priority list.

Cheers!  Hans