Getting Started Common Acronyms FAQ Forum Help Forum Tips FTP Site Helpful GuidelinesInserting and Attaching images, videos, or files to postsProduct Community Directory SELECTsupport
The first post in this thread explains the issue.
We use InRoads and some clients requested SF and Acres to be annotated on all properties like this:
100000 SF or 2.296 Acres
We found we could Annotate our closed parcels like this:
100000 SF 2.296 Acres
And we could search for the " SF" and use the reg expr option to insure that only the InRoads data is found and could replace it with" SF\010or" to get the result desired.In XM, we found that the firstreplacement left some type of unprintable character in the text instead of the \010. But we found that if we immediately repeat the search and replace, only this time, the search and replace strings were the same " SF" and the result was the desired added linefeed/carriage return.
In V8i if does nothing as I recall.
Would it be possible for you to provide an example of it not working? It's not clear to me what the problem is.
Additionally, the find/replace tool got a major overhaul for V8i select update 1, so you may want to try that out (although the special character find/replace won't come until select update 2).
The silence is deafening...
Does anyone have a work-around for this change in functionality?
I don't recall where I first learned of this trick, but apparently it does not work in XM.
To insert a cariage return into a piece of text, you used to be able to search for some unique text that preceded the location where you wanted to insert the carriage return and replace it with the same searched for text plus the following characters:
\010
And if you pressed Replace All, the \010 would create a carriage return, turning your text into a two line text node. It could also be used on a multi-line text node to add extra lines.
In XM, the result is some unprintable character. If you select the text for edit and accept it without actually making any edits, the unprintable character will turn into a carriage return.
We also discovered that a second find and replace, where the Find and Replace fields are identical and equal to the initial unique text string, will cause the unprintable character to turn into a carriage return.
So we have a work-around, but it is hardly a desirable workflow.