non-breaking space at the end of a line

[dysong3]

Hi,

 

I would like to make a calculation that substitutes a non-breaking space for an ordinary space but only between the last two words at the right end of the line of text.  Would someone be able to give me some pointers in the right direction ?

[doughemi]

Try

 

LeftWords (YourTable::YourField; WordCount(YourTable::YourField)-1)  & Char(160) & RightWords(YourTable::YourField; 1)

 

Edited per comment's correction to remove extra ")".

Edited December 9, 2014 by doughemi

[comment]

I would like to make a calculation that substitutes a non-breaking space for an ordinary space but only between the last two words at the right end of the line of text.

 

Could you explain a bit more what this is about, perhaps provide an example? It seems quite a strange request.

 

 

LeftWords (YourTable::YourField; WordCount(YourTable::YourField)-1) ) & Char(160) & RightWords(YourTable::YourField; 1)

 

That will remove any punctuation that might exist between the two last words. More precisely, it would remove any such punctuation, if the parentheses were balanced.

[Josh Ormond]

Clarify if you mean a string of text...or the end of a line visually on the screen.  The latter is nearly impossible, too many variables.

 

What determines if something is at the "end of a line of text"?

[dysong3]

Sorry for not being precise enough.  Here's my problem.  I live in Switzerland where the normal street address format is "name of street" & "space" & "street number".  This means that depending on how you are formatting your addresses and the length of text lines, you often get things like :

 

"Boulevard du Chévrier

46"

 

Instead of 

 

"Boulevard du Chevrier 46" or

"Boulevard du

Chevrier 46"

 

My desire is to have a calc that automatically formats the street field so that there is a non-breaking space between the second last word in the string and the street number, which is the last word in the string.  I hope that is clearer.

[comment]

doughemi's suggestion should work for most, if not all of your cases. To make it extra safe - for example in cases such as "Rue du Rhone 45-B" or "Avenue of Joes' 1503", I would go with =

Let (
pos = Position ( Address ; " " ; Length ( Address ) ; - 1 )
;
Case ( pos ; Replace ( Address ; pos ; 1 ; Char ( 160 ) ) ; Address )
)

[dysong3]

Thanks very much for that.  However when I went to test it I found that all the spaces were "&#160" and not just the one before the last word in the string. So it appears as though the calc above works much the same as

Substitute(address; Char ( 32 );Char ( 160 )) 

Is that right, or am I missing something here?

[comment]

No, that is not right. How exactly are you testing this?

[Matthew F]

With your example why not just use:

Name of street  &  Char(160)  &  Street number

[dysong3]

Comment,

 

I tested this by applying the resulting text into an Ascii conversion site like http://www.unit-conversion.info/texttools/ascii/ and seeing the resulting ascii numbers.  All the spaces are #160.

 

Mathew F.

 

For the moment my "address" field concatenates street name and number.  If i can avoid it, I would prefer not having to separate them.

[comment]

Well,

 

I tested this by applying the resulting text into an Ascii conversion site like http://www.unit-conversion.info/texttools/ascii/ and seeing the resulting ascii numbers.  All the spaces are #160.

 

What happens if you test the original Address field in the same way?

[dysong3]

The spaces are #032.

[comment]

I am afraid I am unable to reproduce the problem. Starting with "Boulevard du Chevrier 46":

066 111 117 108 101 118 097 114 100 032 100 117 032 067 104 101 118 114 105 101 114 032 052 054

I get:

066 111 117 108 101 118 097 114 100 032 100 117 032 067 104 101 118 114 105 101 114 194 160 052 054

The 194 is a garbage result, so I wouldn't trust that site too much anyway. Why don't you test this using the Code() function in Data Viewer? The original should be:

540005200032001140010100105001140011800101001040006700032001170010000032001000011400097001180010100108001170011100066

and the result:

540005200160001140010100105001140011800101001040006700032001170010000032001000011400097001180010100108001170011100066

[dysong3]

Here are the results of the address "Avenue des Pléiades 1  " using the code function.

 

This result uses your calc

16000160000490016000115001010010000097001050023300108000800003200115001010010000032001010011700110001010011800065

and this one doesn't

16000160000490003200115001010010000097001050023300108000800003200115001010010000032001010011700110001010011800065

Hmm.  Am I missing something here ?

[comment]

What exactly does "this one doesn't" mean? Is that the code of the original Address field? If yes, it already has two trailing non-breaking spaces:

"Avenue des Pléiades 1◊◊"

and the calculation correctly replaces the last normal space with a non-breaking one, resulting in:

"Avenue des Pléiades◊1◊◊"

Note that the two normal spaces preceding the last one are preserved.