Hi

How do I remove carriage return(s) from the end of a text field.

Daibhead

In case this text field has multiple paragraphs, you will only want to remove the very last

To replace all Carriage returns with a space:

Substitute(MyTextField;"

Ehm...

If(Position(text;

Ahhhh, you all forgot the most obvious answer:

Put your cursor at the end of the field and press the backspace key!

Thank you one and all.

I'm new to filemaker, so forgive the newbie questions.

I am not sure what the "

It tags the end of the text, so that the carriage returns removed are only those at the end.

Welcome to FM Forums,

What version of FileMaker are you using? If you are using FM Developer 7 then perhaps the pros around here could work with you on creating a recursive function. This would in effect provide the looping type action that you need in your calculation.

Greg

Ok, I'll give it a try. I'm new to recursive functions myself... and I don't use Developer.

For those using Developer:

1. Create a custom function called:

TrimEndReturn (textfield)

2. The calc part of it should be something like:

Let ([rightcharacter = Right (textfield ; 1);

lengthremaining = Length (textfield) - 1];

If (rightcharacter = "

This has the unfortunate effect of stripping ALL punctuation from the end (as well as the beginning) of the text.

hmmm, good point. How about:

If(Right(MyTextField; 1) = "

Edited July 19, 200520 yr by Guest
Added IF statement

That's a neat idea.

If a text field could contain more than 30 returns in a place other than the end of the field then you would just need to add more

Nice, Thats even better. I think that may be as close to actually stripping trailing carriage returns as you can get (without developer). That is of course until FM adds the TrimCR function to version 24 of Filemaker Pro.

Just for fun, here's Bob Weaver's post on optimum nested substitutes.

I actually tried that at first, but couldn't find a way to restrict it to the end of the text.

For general use, I believe that method has become obsolete in v.7 - see here.

Recursive Function I just built.

name: Recursive_Remove(txtfield)

Let([

a = If ( Right ( txtfield ; 1 ) = "

Edited July 20, 200520 yr by Guest

For general use, I believe that method has become obsolete in v.7

It's time for be fried for believes!!! When will internal functions be ....or which of the native functions are slower than the dealings of iteration max check's when making a recursive CF.

The question is if we always should recurse if a chance occures??

If a native function aready have some sort of recursivity inside, should it then be used moderately?

Wishfull thinking is if we like in assembler had a list of each native commands utilization of processer time. It's a waste of a developers time to build homebrewed tests each time in doubt, even worse sometimes you should even think up ways, which would give the most reliable measurements!

--sd

Thank you for replying, Søren - even if it's after more than two years. Unfortunately, your point is not clear. Please explain why you think I should be fried?

Do you know it's obsolete??

--sd

Is this a Socratic question? I know nothing. But I do believe, even now, that it *is* obsolete - because the number of substitutions needs to be limited in advance. Your point is still not clear.

because the number of substitutions needs to be limited in advance

Only if we have absolutely no idea as to why these extra pilcrow's have sneedked themselves into our field in question.

I have found that a lot of these problems in my solutions, have been avoided by the use of this:

http://www.briandunning.com/cf/39

...which perhaps isn't particular fast but it could be stached away in the buttons oneline script if needed!

--sd

I am sorry, but could you explain your point, without branching into another? I don't quite see how knowing the REASON for extra characters being in the field would also tell you HOW MANY of them are there.

So, given a choice between two methods, one limited to removing up to 2 or 4 or 10 or 40 etc. consecutive characters, and the other unlimited (at least theoretically), I would go for the unlimited one - all other things being equal. Fry me for it, if you will.

and the other unlimited (at least theoretically), I would go for the unlimited one

It seems that you have caught my point! But the excess pilcrows will never creap upon your solution by themselves, so the issue is here pre-emptiveness vs. remedy after deed is done, is the other issue here.

Since they have no will of their own, is it usually down to the developers habits to avoid it happens, eventhough he later might know the strongest "Roundup" or posion known to mankind.

I could mention 1 NF's one fact per field, that is an attempt to avoid inefficient designs, why should we bother if we always could think up an unlimited method? - Does you statement imply??

No! By propper preparation, isn't recursions always required or are they?? I'm not in doubt that your sense of balance is very good and something a lot of us admires. But impeccable instincts isn't something all of us is graced with, to keep the competititors away with, this is why I ask ...in a simple hope for an explanation:

When to develope preemptively, and when to break the rules becasue we always have a posion that can kill the artifact, right at hand.

Should we allways develop our recursive functions as tail recursions, simply because they are even more "unlimited"???

Bob Weavers method would with just 4 nested substitutes zap up to 42 successive pilcrows or what ever, isn't it more efficient - when the lions share of the problems only encounters 3-4 if it's done on a regular basis???

--sd

It seems that you have caught my point!

I am afraid not.

Bob Weavers method would with just 4 nested substitutes zap up to 42 successive pilcrows

I believe the actual number is 40, but that's not the point. The point is that my algorithm can zap ANY NUMBER of successive characters, using just 4 substitutions and a TrimAll. In case you haven't noticed, my algorithm is NOT recursive.

So why would I ever want to implement Bob Weaver's method, now when TrimAll() is available?

I have accused you wrongly here, I appologize!

The TrimAll() method is definately the way to do it!

--sd

That's a relief. Can I go for another two years without being fried?