It makes no sense that the image does not appear. It says I must be signed in to see it but I AM signed in.
Well it is the same image indicated in the link on post #7.
I suspect that the forum logged you out between posts. I can see the image just fine here.
Due to a noxious forum bug, please protect yourself with a "Select-All, copy to your clipboard" action just before submitting a private message or comment to this forum. The bug can lose your comment and log you out of the forum--forcing you to sign back in and re-enter the comment or message. By copying to the clipboard before posting, you can re-enter your message by pasting from the clipboard instead of having to retype it all over again.
And from the lack of progress fixing this issue, I must conclude that the RightNow programmers remain clueless...
Thank you, Phil! That is good to know. :-)
Thank you for your post.
I am unable to replicate the issue with FileMaker Pro 13.0v3 under Windows 7. Here are the steps I took:
1. I created a new table with a Text field named "TEXT".
2. In Layout Mode, I selected TEXT, changed the Font to Tahoma (since that is the only font I can see a non-breaking hyphen), 12 points, and I sized the field for 144 point Width and 59 point Height.
3. Saving the layout and returning to Browse mode, I created a record and entered the following:
TV-4, TV-5, TV-6, TV-7, TV-8
4. The wrap-around occurred in "TV-7" between "V" and the hyphen, so "-7, TV-8" appears on the second line.
5. With my cursor still in TEXT, I pulled down the Records menu and selected "Replace Field Contents..."
6. In the Replace Field Contents dialog box, I selected the last option "Replace with calculated result:".
7. In the Specify Calculation dialog box, I entered:
Substitute ( TEXT ; "-" ; Char (8209) )
8. I clicked OK to exit Specify Calculation, and then clicked Replace.
I do not get any extra spaces. I get "TV-4, TV-5, TV-6" on the first line, and "TV-7, TV-8" on the second line.
Let me know what I'm doing differently than you so I can replicate the issue.
Wow, thank you so much for your prompt and thorough answer! I explained how to replicate it - the issue is when it is a calculation. Changing the text itself will not be helpful ... we cannot have Users typing the data and be required to stop and reformat each hyphen as they go. Char ( 8209 ) should work as a calculation; in fact, that is its purpose.
Knowing it works at the data level may help us narrow it to the calculation. Others have already validated the same behavior ... reading the link I referenced will help showing what other Windows Users have gotten, as will viewing the file I provided in Post #7 with the simple example).
Maybe it is fixed with 13.0v3 on Windows! :-) I am Mac and I cannot test on Windows.
TSGal's test seemed very reasonable to me as it uses the same substitute function.
I decided to do a few different takes on this.
But every test that I tried, did not produce the
I used char ( 8209) both with and without substitute in the data viewer first and then in calculation fields on a layout.
Then I went to the other forum, downloaded her test file and sure enough, there was the extra space.
I then messed with her file, adding my own fields and they all also showed the added space just like hers.
My tests were all done in WIndows 7, FileMaker 13.0v3. I started with the Known Bugs database for my testing and since that file is a) converted from .fp7 format and b) uses classic themed layouts. I then tried this with an enlightened theme using calculation fields identical to LaRetta's in a brand new file and was able to reproduce this issue.
Just as described in the other forum, I got a "box" at 100% magnification and the extra space after I zoomed the layout.
That led me to playing with the Tahoma font and zooming the layout.
What I found was that no extra space was visible at 100% but if I zoomed to 150%, it was visible. I then went back to the Known Bugs List database copy where I started the testing and was able to reproduce this behavior there--ruling out the possibility that this is either theme related or can be have different results in files converted from the .fp7 format.
Thus, the key detail is to zoom the layout.
Thanks for the information. I am now able to replicate when viewing at 150%. This does not occur under Mac OS X 10.9.2 at 150%.
I have sent along this forum thread along with my findings to Development and Testing for review. When I receive any feedback, I will let everyone know.
An entry in the Known Bugs List has been linked to this Issue Report. Any Comments/Questions/Suggested Corrections should be posted here or in a new thread. Please do not post such comments to the Known Bugs List thread.
LaRetta and PhilModJunk:
I apologize for the late response.
Our testers were able to replicate the issue, but as a possible workaround, they following Windows fonts did not exhibit this issue:
Lucida Sans Unicode
Segoe UI Symbol
MS UI Gothic