string manipulation question

[Fairlight]

At Sat, Dec 11, 2004 at 03:10:26PM -0500 or thereabouts, 
suspect Kenneth Brody was observed uttering:
> Fairlight wrote:
> [...]
> > Then your edit solution for Bob, while elegant, would be subject to failure
> > if the expansions cause the data to overflow--while a processing-oriented
> > soliution would allow the opportunity to trim to the correct length if
> > necessary.
> 
> True.  You could, of course, make sure that the destination field was
> 1-1/2 times as long as the source field, to allow for a "worst case"
> scenario.
> 
> (Question 1.5: Why 1-1/2 times, and not 2 times, when you are replacing
> one character with two?  And, in what case[s] would 1-1/2 times be short
> by one character, making the answer for those cases "1-1/2 times plus 1"?)

Because the edit as supplied won't touch single quotes that are doubled up
already.  In that event, the worst case need for alternation is a single
quote every other character, so you only need to account for a maximum 50%
increase in string size.

> > Incidentally--the @ in your edit is not officially documented in the
> > online help.  I checked a 5.0.6 and a 5.0.10, Tony checked 5.0.14.  The
> > -only- place I could find it was on a system that had Laura's help files
> > installed.
> 
> I'll have to check the official fPTech help files, but the online manual
> does list it under "References/Edit/Edits Syntax".

Nope...not in fp/lib/edits.hlp on SCO.  If it's in the 'doze .hlp file or
some HTML file, that may be another story.

> Obviously you didn't try it, as there is no syntax error there.  (Check
> the global edits table for numerous examples.)

Obviously.  :)  I've gotta log into someone else's system to test this
stuff, and I was just doing it mentally.  Didn't know you could get away
without quotes around string literals in edits.

> Given a (9,monexp) field, it will successfully convert:
> 
>     Jan --> January
>     Feb --> February
>     Mar --> March
> 
> and so on.
> 
> So, back to my original "second question to ponder", given the fact that
> the first edit will fail without the trailing-space removal, due to the
> reason you pointed out:
> 
>     Why does this not fail, even though we are not stripping trailing spaces?

I conceded defeat.  Unless it has something to do with checking
multi-character strings versus a single character and an internal coding
difference, I can't think of a logical reason.

2 out of 3 isn't bad going up against you.  I'll take it.  :)

I give on this one, though.  "Uncle."

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html