Re: simple problem with string handling

Hi Dale

Varying-length variables will perform better than fixed-length ones, generally. Because a varying knows where the data ends, so concatenation and other text operations are easier.

At least one caveat - if you fill a varying from a fixed, the length includes any trailing blanks in the fixed - trimming is not performed automatically.

Of course, the performance benefits apply most when there are lots of concatenation, for example. I had an app that built HTML strings, and changing it to use a varying for the output string made the thing pop. There were lots of concatenations like webDta = webDta + 'some more text'; (This was before the += operator).

Putting varying data into a fixed variable is no problem, so feeding it to a DSPF field is not a concert - there'd be no disadvantage that I know of.

So if you have a fair amount of concatenation, I suggest making a varying work field, trimming on input, then completing the work, then output to the display.

For some reason I think there is *TRIM option somewhere, maybe on a parameter, if so, make a procedure with that, then it's REALLY simple and nice.

HTH
Vern

On 2/20/2013 12:37 PM, dale janus wrote:

Thanks for the TRIM and TRIMR advice.

I would consider a varying length field except this is going to be
printed on a form, so the length will end up fixed anyway. Besides, how
much new stuff do you expect me to put into this old program? Next think
you know I'll be asking /FREE questions.
Actually, I did copy of bit of /Free code to fill an array in another
program. I was surprised at how clean and simple it ended up . Maybe
this /free thing might catch on...

It's taking this old dog a long time to learn some of these tricks. But
I'm trying.

---Dale