weird and severe language issue

[Klaus]

Hallo Jürgen,

the only thing I can imagine is that this variable gets overridden somewhere! (Ach was!? )
Is it a local or global variable?


Best

Klaus

[[-hh]]

I detected a lot of problems with "answer" and some other commands with LC 8 in the HTML5-standalone builder that may also apply here.

When using *short* forms like

= answer/ask <prompt>
= go next

the result was unpredictable, but using the long/'complete' form like

= answer/ask <prompt> with "OK"
= go next card

worked as expected.
Perhaps the 'long' form works, depending on your LC version?

[They changed some default behaviour in newer LC versions ...]

[bn]

Hi Klaus and Hermann,

I have looked at the stack and the problem shows in Livecode Versions < 7.x.x.

It is a 5.5 format stack. My hunch is that Jürgen opened the stack in a 7.x.x. Version and the text somehow was "contaminated". Waiting for Jürgen to tell me if he actually did a save in LC 7.x.x.

Kind regards
Bernd

[jawall]

Thank you all for your ideas.

I have sent my stack to Bernd and he did a great job on checking it with various versions of livecode. What he came up with, though I do not fully understand it, makes perfect sense as to how the issue came up:

I have been using my stack for a long time. I created it originally with a livecode version 5.x. I updated livecode versions as they appeared. After using version 7 I had some problems with my stack and downgraded to 6.5.1. This is when the issue appeared.

Bernd can explain the whys,which I, as I said do not understand really. Anyhow, I need to get my stack working again by Tuesday and hope I will - Bernd gave me instruction fpr it.

So, thank you Bernd!

Jürgen

[bn]

The long story is:

What Jürgen said, he changed the stack in 7.x and saved.

The styledText of the field that were change showed "unicodeText". This was not really a problem because the text worked ok as shown by putting it into the message box.

But the combination of selectedText, a list field and answer the selectedText led to the problem that only the first char was displayed in the answer dialogue.

When asking for the text of line 1 for the answer dialogue it worked.
When unchecking "list behavior" it worked.

Only selectedText + list behavior + answer was a combination that did not work.

The cure in LC 6.x is to set the htmlText of the affected fields to the htmlText of themselves.

Code: Select all

set the htmlText of field "myField" to the htmlText of field "myField"

this resets the "unicodeText" to "text" in the styledText.

I did not check for the phase of the moon nor the barometric pressure...

For all those that would like to have a look I attach a stack in 5.5 format created in LC 7.x and you open it in LC 6.x

Kind regards
Bernd

[jawall]

Still not solved (in my environment)

Actually my problem is not that message Box and answer dialog show different resuts (by the way in my case it is not the first character that is being shown in the answer dialog, but everything to the first appearance of the character "2"). I don't need to "answer" or "put" anything, it just came up as I was trying to narrow down the issue I had. My actual problem is as follows:

I have a line in a field "fldX" with list behavior that is compared against a some text in a fld "fldY" that has no list behavior. Even if "fldY" contains the text that is selected in "fldX" it is not found there.

In my case Bernd's solution to set the HTMLtext of both flds to themselves did not solve the problem.

Jürgen

[Klaus]

Hi Jürgen,

can you show us your "comparing" script?


Best

Klaus

[jawall]

Hi Klaus,

well,, the "comparing" is not the issue. No problems with the script itself (it also worked perfectly for a few years now).

Bernd and I have narrowed down the problem. It has to do with the fact that LiveCode 7 stored text in some (but not all) flds (sorry for being very vague, more is not known yet) as unicode. After downgrading to Livecode 6, the text of "some fields" isn't identified by the "comparing" as being identical, even though it looks as if it was.

"Hüstel"

The solution so far:
I "repaired" the data in 6. and avoid using 7

Jürgen

[bn]

The problem with Jürgens stack in LC 6.x is that the changes he did in LC 7 were stored as unicode within ASCII code, so a simple transform with unidecode of the whole field was not working.

I resorted to htmlText and just deleted

&#0;

from the htmlText of the field and set the htmlText of the field back to the "cleaned" html.

This worked probably because it was basically all ASCII.

The script to clean the text for all fields in a stack placed in button on card 1 of the stack:

Code: Select all

on mouseUp
   lock screen 
   set the cursor to busy
   repeat with i = 1 to the number of cards
      go card i
      repeat with j = 1 to the number of fields
         put the htmlText of field j into tText
         replace "�" with "" in tText
         set the htmlText of field j to tText
      end repeat
      set the cursor to busy
   end repeat
   go card 1
   unlock screen
end mouseUp

This left ASCII alone and just removed the unicode 0 of the html.

Jürgen tried this on his stack, he even went on to make changes in LC 7 and reopening in LC 6 applying the script and it worked. Before when making changes in LC 7 and reopening in LC 6 gave the same error as before.

I think (not quite sure) that this happens because Jürgen's script addresses "put char x to y of z into char a to b of c". That somehow led to a mix of ASCII and Unicode in the field that led to the trouble in LC 6.

Kind regards
Bernd