code is breaking LC 6.5.2-->LC 7.1 / colouring of a chunk

[okk]

Hi,
I have a short piece of code that works fine in LC 6.5.2. When moving to LC 7.1. or LC 8 DP13 the code breaks in a way that puzzles me:

Code: Select all

 put ((trunc((selectline-1)/3)*3)+1) into blockstartline
put (((selectline-1)/3) - trunc((selectline-1)/3))*3 into lineshift
-- extracting and placing the next 3 lines of text in the subtitle field
put uniDecode(the unicodeText of line blockstartline to blockstartline+2  of field "alltext","UTF8") into linedecoded
set the unicodeText of fld "subtitles" to uniEncode(linedecoded,"UTF8")
set the foregroundcolor of line 0 to lineshift of field "subtitles" to "red"
-- set the foregroundcolor of line 0 to 1 of field "subtitles" to "red"

The idea is that the user clicks on a line "selectline" in a longer text-field "alltext", the routine than takes a block of 3 lines (lines 1-3 or lines 4-6 or line 7-9 etc.) out of this longer text-field and places them in a field called "subtitles". Depending on which line the user had clicked, a part of the lines of the field "subtitles" should be coloured in red. e.g. if the user clicks on line 5 in field "alltext" the routine extracts line 4 to 6, places them in the field "subtitles" and colours the first line in field "subtitles" in red.

So now comes the mysterious part: In LC 6.5.2 this routine works without a problem. IN LC 7.1. this works sometimes, sometimes not. For example when I click line 6 the routine does what it is supposed to do, when I click in line 5, it doesn't. It gets even more mysterious (at least for me): If I click line 5 in field "alltext" the variable "lineshift" is calculated with 1. I checked it in various ways. If lineshift= 1 why then the following DOESN'T work:

Code: Select all

 set the foregroundcolor of line 0 to lineshift of field "subtitles" to "red"

but the following DOES work:

Code: Select all

set the foregroundcolor of line 0 to 1 of field "subtitles" to "red"

I spent the whole day to get my head around this; it most likely has to do something with the change in unicode treatment, still I cannot see the issue. How would I treat this piece of code in the 7.1 environment? Any help would be appreciated. I must say the upgrade from LC 6.5.2 to LC 7.1. has been bloody. So far my software has just get a lot worse and I would stay with 6.5.2. for now, but I need need to be able to use Thai language.

Best
Oliver

[bn]

Hi Oliver,

EDIT

I thought I had a solution but at a closer look it did not work in the way you need it. Still looking

Kind regards

Bernd

[bn]

Hi Oliver,

I think you found a bug in LC 7 and up

somehow LC 7 and up don't resolve lineShift correctly when the value of lineshift is 1, and that probably has to do with the computation. So setting "the value of" makes LC think again and makes 1 a valid number.

your code works if you change to

Code: Select all

set the foregroundcolor of line 1 to value (lineshift) of field "subtitles" to "red"

By the way when using LC 7 and up you don't need to do the unicode conversions

Code: Select all

put line blockStartLine to blockStartLIne + 2 of field "alltext" into field "subtitles"

works with Thai text.

Once you try my workaround and it works for you I would like to file a bug report against this, unless you want to do it.

Kind regards
Bernd

[okk]

Hi Bernd,
I can confirm that your suggested workaround is fixing the code. Please file a bug report. Thanks a lot for helping out so quickly.
Best
Oliver

[bn]

Hi Oliver,

I filed a bug report against this bug

Bug 16740

http://quality.livecode.com/show_bug.cgi?id=16740

Kind regards

Bernd

[bn]

Hi Oliver,

I think at the root of this bug is that by your computations you made LC dizzy...

So it marked your lineshift variable internally as "maybe" and the chunk expression dutifully did a "maybe" coloring of the lines...

Since I am bad at math I fully understand the engine doing this

Kind regards
Bernd

[okk]

Thanks for filing the bug report. It was very well described. Still a bit puzzled though. Btw. I keep the unicode conversions for compatibility reasons, since I prefer to save my standalones from within the 6.5.2. environment, when it's possible. Does the unicode conversions do any harm when left in the code in the LC 7 and up environment?
Best
Oliver

[bn]

Hi Oliver,

Btw. I keep the unicode conversions for compatibility reasons, since I prefer to save my standalones from within the 6.5.2. environment, when it's possible. Does the unicode conversions do any harm when left in the code in the LC 7 and up environment?

It works as you can see in your stack, but I don't know much about unicode. I am just glad that I don't have to use it.

Kind regards
Bernd

[bn]

Oliver,

it has been confirmed as a bug

Bug 16740

http://quality.livecode.com/show_bug.cgi?id=16740

if you register for the Quality Control Center you can add yourself to the mailing list for this bug and you will be informed of the progress.

Kind regards

Bernd

[bn]

Hi Oliver,

the bug has been merged and is awaiting build for LC 8 DP14

This is amazingly fast: reported the 18th and fixed the 20th.

Thank you Livecode.

have a look at the bug

http://quality.livecode.com/show_bug.cgi?id=16740

Panos explains what he did to pin down the bug and what it was. Nice example of the intricacies of calculations and conversion to integers. (internally all calculations are floating point)

Kind regards
Bernd

[okk]

Thanks Bernd and Livecode team, amazing work. It was great to read the teams response how they tackled the bug. This gives me hope with the rest of my issues. I of cause would insist that my use case is not at all "weird" as you mentioned in the comments to the bug report. It's a karaoke software, so coloring of characters is part of the basics.

Best
Oliver