LiveCode Forums.

Does anyone know how to force LiveCode to return a string instead of calculating the result when using "<" and ">" and "</" ?
With the PUT command there is no problem, but I need it with ANSWER or RETURN to deliver a result within a routine.

For example:

answer "<" & aaa & ">" & 555 & "</" & aaa & ">"

returns 555, but I want it to return:

<aaa>555</aaa>

Thank you very much.

Hola Fermin,

I'm afraid you can't!
Because this is a "feature" of the answer dialog, if a string starts with < and ends with >
LC will see this as HTML tags and if LC does not know the actual tag(s), it only supports a
very basic set of HTML tags, it will just neglect them.

You could do:
1. Report an enhancement request so we can switch this behavior (interpreting as HTML) on and off
and/or
2. Create your own custom dialog -> a little modal stack with a "OK" button to close the stack.

Best

Klaus

Hi Fermin,

if you just want to check the syntax you could put it into the message box:
(&& the long time added to make sure it is a current message in the message box)

or into a separate field for development Kind regards
Bernd

Fake It!
-

Thank you for your answers. I understand the problem now and will try to find another way to fix it.

As a curiosity:
I presented the problem to ChatGPT and it's clear that it doesn't have any complexes. It may not have any idea what it's saying, but at least it says it with a lot of confidence.
Although none of them are useful, here are some of the proposals it has made:

answer quote & "<" & aaa & ">" & 555 & "</" & aaa & ">" & quote
--
answer quote("<" & aaa & ">" & 555 & "</" & aaa & ">")
--
answer "\<" & aaa & "\>" & 555 & "\</" & aaa & "\>"
--
put "<aaa>" & 555 & "</aaa>" into myString
put replaceText(myString, "<", "&lt;") into myString
put replaceText(myString, ">", "&gt;") into myString
answer myString
--

This is my kind of action.

And if one is going to fake it, at least try to keep it in the ballpark.

Jimi nailed it, mostly.

Playing around a bit, anyone tell me why: works, but this, which seems to me pretty much the same, does not: Both a field and a variable are a container. So a field must have "properties" that a variable does not, especially when dealing with text, or in this case, htmlText. This is my kind of action because this is an instance where I see that "container" is not all-inclusive. That is, there are two kinds of container.

I thought that a "do" construction might work on the variable version, but it does not seem to. There is something besides inadequate levels of evaluation that a field does with text that a variable does not.

Craig

Craig-

Variables don't have "properties", so "the htmlText of" a variable doesn't exist.
You can set and retrieve the htmlText of a field because it's a property you can manipulate.
A variable is just a container for a value, nothing more or less.

I had little hope for this, but had to try: Nope.

So placing the text string into a field and then into a variable did not "format" the string in any way, or at least whatever "advantages" or "differences" the string had by virtue of living in a field were lost when transferring to a variable.

What is different when extracting "the htmlText" from a field rather than from a variable?

Craig

Mark.

What threw me was I read the construction of the string itself as "containing" the htmlText information intrinsically. Not so.

I guess that makes sense. So conceptually, for me always a challenge, the string "inherits" the htmlText property from a field. The string is always just a string.There are indeed more than one "kind" of container, in that there are different properties among containers. Variables have a text properly, as does a field, but not an htmlText property.

Just thinking out loud...

OK, I feel better. Thanks.

Craig

The original didn't work for me, but there was a syntax error in the html. I removed the slash from "</" just before the second instance of "aaa". This works for me:

answer "<" & aaa & ">" & 555 & "<" & aaa & ">"

Jacque.

Good find. I don't use HTML so I never would have known it was wrong.

But Klaus, how does this play into what you said, about "answer" dialogs being very particular about html-formatted strings?

Craig

Maybe i was not very precise in what I said:

... if a string starts with < and ends with >

should read ... and ends with a HTML end tag -> </xxx> (remember that LC first resolves the complete string)
then:

LC will see this as HTML tags and if LC does not know the actual tag(s), it only supports a
very basic set of HTML tags, it will just neglect them.

Or just treat it like a pair of <p> and </p>, at least LC presumes this to be HTML, no matter if
you "don't use HTML".

I wouldn't have caught the error either if I hadn't got an error message when testing it using "do" which also didn't work. The dictionary says:

The prompt can be either formatted text (in the htmlText property's format) or plain text. If the prompt contains <p> or a start/end tag pair, the answer command assumes the text is in the same format as the htmlText property. Otherwise, the answer command assumes the text is plain text.

The </ was used as a tag opener, which is wrong, it's an end designator. So I assume that was the error. But that doesn't explain why LC didn't see the prompt as html after the fix, because after the fix it still is.

I know that concatenation turns text into plain strings, but then why did the original example not stay as a string? It did have a legitimate tag ooen/close pair. Curious.

IIRC the original rule for LC to treat Ask and Answer prompts as htmlText was to require what all htmlText has: "<p>" at the beginning and "</p>" at the end.

Resuming that rule would allow other uses.

If the rule has not formally changed perhaps this is a bug.