I think the answer is probably "no", but I thought I would ask.

The application I have in mind would mainly need to display the pilcrow for returns and the small right arrow for tabs. It would be a special-purpose, display-only field to show "literal text". IOW, the field would not need to print. I suppose parsing and replacing individual characters with WingDing symbols would work. But is there something easier? A setting or a special font?

Thanks for any advice.

Easier than substituting 2 characters?

Easier than substituting 2 characters?

Expressed like that, I guess is does sound silly. But the "environmentals" of the actual problem make it a bit more complicated. The contents of the field can't actually be changed because it has other uses. So it means having a calculated parallel field which precludes direct edits — which is why I was hoping for something simpler ( e.g., interpreted on the fly, leaving the underlying content "as is".)

Anyway, thanks for giving it thought.

So it means having a calculated parallel field which precludes direct edits

Isn't that what you wanted - "a special-purpose, display-only field"?

Isn't that what you wanted - "a special-purpose, display-only field"?

Yep, you've got me on a technicality: It is what I said. But I guess what I meant (was hoping to find) was a way to display the same text "differently" — like in a special font — but still have it editable. ("have cake; eat, also")

I'll work with the replacement approach. Maybe I can fashion something close to what I've (re)described.

a way to display the same text "differently" — like in a special font — but still have it editable.

I don't know of a font that would display non-printing characters. I don't even know if it's possible to construct such font without totally messing up the display (if carriage returns are being displayed, then what breaks a line?).

Perhaps you could use script triggers or auto-entered calcs to convert from one form to another.

I'll work with the replacement approach. Maybe I can fashion something close to what I've (re)described.

I do not see any difficulty...

control chars.zip

I don't think it's that easy. In your demo, the edits are not saved - but that's not the point. There are many things to manage when you edit the 'display' field: if you add a carriage return, it should also add a ¶ marker and show it immediately. If you delete one, the ¶ marker should also disappear - and your cursor should move 2 places to the left. Those are just two examples of the many scenarios that need to be handled.

Raybaudi, that is an excellent solution.

In only a couple of minutes, I was able to adapt it to give the editable result I was after. Although I appreciate Comment's points about directly editing the interpreted field, the 5-starResult I'm attaching is a straightforward implementation that is 1) adaptable for many purposes and 2) easy to understand by the end user.

Thank you very much.

5-starResult.zip

Well, it is very simple (could be even simpler if you used a calculation field). But it is also very limited. For one thing, the two fields will not scroll in sync - so it won't work as well for longer texts. The other problem - which IMHO is more critical - is that the number of characters in a line is not necessarily the same in both fields; this can cause lines to break at different words - so that when you click into the "field" you'll see the text re-arranged and the cursor jumping to another position.