Page 1 of 1

BUG ?

Posted: Sun Jul 17, 2022 10:52 pm
by ZoOoOoP
- Create a new stack.

- Create a button.

- Button code :

Code: Select all

on mouseUp
   
   put "*/*" into XYZ
   if 1 = 1 then
      answer XYZ
   end if
   
end mouseUp
- No problem, all works as expected.

- On code page, click after "then", and after press "Enter/Return", bug ?

(i'm on MAC, and same on 9,6,6 and 10)

Re: BUG ?

Posted: Mon Jul 18, 2022 4:03 am
by dunbarx
Fascinating. LC freezes just a bit.

It is the string "*/*" that is the issue. I tried a few others and they all acted appropriately.

If you hit Cmd-period a few times LC unfreezes itself, but if you hit return again it freezes again.

Anyone? Is that string some sort of odd regex/escape oddity that confounds the SE?

Craig

Re: BUG ?

Posted: Mon Jul 18, 2022 4:15 am
by dunbarx
The handler actually runs fine if one does not try to append a return after that line. But I find that oftentimes the SE itself will close after several Cmd-period keypresses. Other times it just unfreezes LC.

The string "*" works fine.
The string "*/" works fine.
The string "*/* shows the issue.
Any random string at all, of any length, if it contains "*/*" somewhere within it, the issue appears.

Craig

Re: BUG ?

Posted: Mon Jul 18, 2022 10:08 am
by bn
This only happens if "Control Structure Completion" is turned on in the Script Editor.

I know who the culprit is: it is yours truly...

See
https://quality.livecode.com/show_bug.cgi?id=22396

Also note that a proposed fix was not merged.
I tested with the proposed fix by applying the fix temporarily and it does prevent the hang.

Kind regards
Bernd

Re: BUG ?

Posted: Mon Jul 18, 2022 2:36 pm
by dunbarx
Fascinating again.

Bernd, can you explain how a quoted literal of any kind can wreak such havoc in a simple handler? In other words, what is the significance of that particular string?

Craig

Re: BUG ?

Posted: Mon Jul 18, 2022 3:04 pm
by stam
dunbarx wrote:
Mon Jul 18, 2022 2:36 pm
Fascinating again.

Bernd, can you explain how a quoted literal of any kind can wreak such havoc in a simple handler? In other words, what is the significance of that particular string?

Craig
I suspect it’s because block commenting starts with /* and ends with */

But yeah, it’s surprising this is happening inside a string literal denoted by quotes…

Re: BUG ?

Posted: Mon Jul 18, 2022 3:10 pm
by stam
Perhaps @ZoOoOoP can add to Bernd’s bug report above, might help bring to the forefront again for the dev team?

Re: BUG ?

Posted: Mon Jul 18, 2022 3:14 pm
by bn
stam wrote:
Mon Jul 18, 2022 3:10 pm
Perhaps @ZoOoOoP can add to Bernd’s bug report above, might help bring to the forefront again for the dev team?
ZoOoOoP has already reported this as a bug
https://quality.livecode.com/show_bug.cgi?id=23822

I have added a comment to that bug report

Kind regards
Bernd

Re: BUG ?

Posted: Mon Jul 18, 2022 3:32 pm
by stam
FWIW, you can avoid the bug by constructing he string variable if you absolutely need this:

Code: Select all

on mouseUp
    local XYZ
    put "*/" into XYZ
    put "*" after XYZ
    if 1 = 1 then
        answer XYZ
    end if
end mouseUp
does not trigger the IDE stall... it's just the string literal */* that causes mayhem...

Re: BUG ?

Posted: Mon Jul 18, 2022 4:18 pm
by bn
dunbarx wrote:
Mon Jul 18, 2022 2:36 pm
Bernd, can you explain how a quoted literal of any kind can wreak such havoc in a simple handler? In other words, what is the significance of that particular string?
In this particular instance of the problem it was me searching for /* to eliminate comments. My code did not guard against quoted literals. The proposed fix is to eliminate all quoted literals because they are not necessary for formatting.

In a more general sense regarding the Script Editor the problem boils down to a difference between token and word as defined in LC.

try this
put
"/*"
into the field (including the quotes)

in the message box type
put word 1 of field "x" & return & token 1 of field "x"

The script editor uses different techniques to circumvent the problems but each "patch" has its own problems.

Kind regards
Bernd