More FM7 upgrade pain.

Trim(x) no longer strips carriage returns. What a pain!

Is this a bug or intended behaviour? Unlike the GetAsText stuff I posted
earlier about, this one apepars to represent a departure from previous
versions.

Whats the best way to handle it now? For single word entry I can use
LeftWords(x,1), but in for multi-word entries all my solutions just get
ugly and tedious looking.

And for my thinking Trim(x) is a better semantic representation of what
I'm doing than Leftwords(x,1) is. (yeah yeah, I'm an aspiring
programming language designer in my spare time... ha! what spare time?!)

/sigh

In article <MPG.1d387697b3767f64989bd3 (AT) shawnews (DOT) vf.shawcable.net>, 42
<nospam (AT) nospam (DOT) com> wrote:

Ummm ... Trim isn't supposed to remove carriage returns, only extra
spaces.

Trim
Returns the supplied text, stripped of all leading and
trailing spaces.


To remove carriage returns you only need to use the Substitute command.
ie. Substitute(TextField, ReturnChar, "")

where ReturnChar can be either a field with a carriage return typed in
or the ¶ character from the buttons available in the define calculation
windows. Depending on your needs, the "" which is used to replace the
carriage return with 'nothing' may need to be a " " (space character)
instead, or anything else you want to use.



Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

In article <090720051135139495%helpful_harry (AT) nom (DOT) de.plume.com>,
helpful_harry (AT) nom (DOT) de.plume.com says...

Actually removing leading and trailing 'whitespace' is the standard
implementation of trim().

Yes. I read the help file, and with all due respect that's a pretty
narrow-minded interpretation of trim().

Every other language I've worked with including php, java, c/c++/c#, sql
(yeah, most implementations of SQL have Trim), and even FM 3 thru 6
trimmed whitespace, not merely 'spaces' by default.

Whitespace includes spaces, tabs, carriage returns, linefeeds, (all non-
visible characters).

FM7s Trim now only considers -spaces- ?!

If only it were that simple.

What about <tab>? And I'm not confident it can be relied on for all
variations of CR/LF, CR, and LF with just your one substitution.

Moreover if the field contains:
A<space><enter><space>B<space><enter><space>

The trim funtion should return: A<space><enter><space>B
Yours will return A<space><space>B<space>

The trailing space can be dealt with by wrapping it in Trim... the
erroneously deleted return however is not so forgivable.

This is a bug,imo. FM3/4/5/6 did it correctly.

In article <MPG.1d38b6f7604dd302989bd6 (AT) shawnews (DOT) vf.shawcable.net>,
nospam (AT) nospam (DOT) com says...
Followup:

I found a cleaner workaround the ugly messes I was trying:

MiddleWords(string;1;WordCount(string))

Its still overwrought to get a proper trim, but it works.

42 wrote:
Well, 42 (btw, does 42 have a name?)...I agree with you 100%. I stopped
using trim() back with FM4 when I came to realize that it never did what
I wanted it to do (I had other pre-FMP programming backgrounds, as
well). I'd be extremely surprised if it worked in 6 the way you are
expecting it to, but I suppose it's possible. No time to test it just now.

Well I agree that this is one more thing you should report to FMI as a
bug. If they ever responded to such things, they would certainly say
"works as expected" because it probably does work the way they meant it
to work. It's just not what a lot of other people would expect.

Ever since FM4, I've been using leftwords(Text, 999) for most occasions
when I need to accomplish this. Problem is when there is punctuation at
the end that you want to keep, it gets cut off with leftwords()...so
it's still not nearly as good as trim() should be.



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

42 wrote:

Our messages crossed. See my comments in the last post about
leftwords(), as they also apply to middlewords().

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

In article <11cu6qe8vkb3p18 (AT) corp (DOT) supernews.com>,
howard (AT) antispahm (DOT) fmprosolutions.com says...
Indeed and your right.

No easy trim() for me after all.

regards
Dave

-
I used to post here a lot under my full name back in... geez... 2000ish.
Lynn Allen was around back then, although John Weinshel seems to be
gone.. I've been working on mostly non-FM projects in the last few
years. The 42 thing came around when coworkers/clients/employers found
out you could google peoples names... saw a lot of friends get pretty
humiliated...i recall one in particular who had some of his juvenile
flamewars in the Nintendo group pulled out of google. And I've seen
people in the news get sacked over stuff like that.

I don't much mind having my contributions to comp.* recorded for
posterity and attributable to me... but I didn't care for my (then)
hobbies (e.g. rec.games.trading-cards.magic-the-gathering.rules ) to be
coming up in the same search , and I've been too lazy to setup
multiple sending accounts in my newsreader and bind specific identities
to specfic groups so I don't have to click on the right one for each
post... not even sure if its possible, actually.

Anyhow... 42 is a trivial cpher for my initials. Given the 3 clues in
this post anyone could figure out my surname in probably 1 minute flat,
(yup... a properly formed advanced google search is a scary thing!) I'll
leave it as an excerise for the readers; lol; some old timers might
remember me... or not.

At any rate its nice to be back doing more Filemaker work... but this
FM7 stuff really feels half baked in a lot of places. Overall its a big
step forward though, despite my numerous vocal complaints.

42 wrote:

Glad to have you here, as you seem very knowledgable about things. As
for John Weinshel, I know he lurks here now and then, and he is active
on some more developer-oriented other lists. What part of the world are
you in (feel free to back-channel me if you'd like)?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

In article <MPG.1d38b6f7604dd302989bd6 (AT) shawnews (DOT) vf.shawcable.net>, 42
<nospam (AT) nospam (DOT) com> wrote:

FileMaker's Trim has never trimmed anything except spaces - not tabs,
not returns, and not whitespaces.

I've just tried it in both FileMaker 5.5 and 4.1 to make sure and only
leading and trailing spaces are removed ... or at least it works that
way on a Mac, so maybe the Windows version does something different,
but I wouldn't have thought so. )



Sorry, I thought you just wanted to remove ALL carriage returns from
the text.

With FileMaker 7's recursive functions you should be able to easily
write a function to remove any trailing tabs / carriage returns /
spaces by simply checking the last character by using Right(Text, 1)
and removing it if it's a whitespace character, and keeping doing that
until the last character is a "legal" one.

There may be a plug-in around that adds this "other" Trim function too.



Nope. See above. Technically removing anything else would be the bug
since that's not what FileMaker says it's Trim function does.

The Trim function in both Excel and Claris/AppleWorks actually removes
all extra spaces between words (leaving just one) as well as any
leading and trailing spaces. Of course, a spreadsheet doesn't have to
bother about tabs and carriage returns since you can't put them in a
cell.



Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

In article <090720051359241292%helpful_harry (AT) nom (DOT) de.plume.com>,
helpful_harry (AT) nom (DOT) de.plume.com says...
Yeah. The developer definable functions are -very- cool.

And if not I could always write one.

I'll take your word for it, but I'd swear I've previously successfully
relied on it to clean up carriage returns when parsing. (addresses in
particular) back in v3 on Macs, and I never noticed anything break in
5/5.5./6. That's a strange streak of luck. Creepy.

Good to know. I'm sure some developer is up in arms about that one too.
And at least its clearly documented in Excel.

Granted Filemakers is documented accurately, but it almost should say
"trims spaces (yeah spaces, just spaces, and nothing but spaces)"
because it deviates significantly from what's normally expected of trim
by people with database or general programming backgrounds.