Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection to Levure Framework breaks when turning off Messages and on again in the LC IDE #184

Open
Tonaras opened this issue Jun 24, 2022 · 1 comment

Comments

@Tonaras
Copy link

Tonaras commented Jun 24, 2022

During development, there are often situations (mostly during debugging) where you need to disable Message Passing in the LC IDE. As soon as you turn Message Passing on again, LC throws an error related to the first Levure function it encounters which is in the Message Path. It seems that the connection to all Levure served functions and handlers get lost and the app gets stuck. To get out of the trouble, you have to turn off message passing again (to get rid of the error message bombing) and quit and restart LC and your Levure Project again.

Forgot to mention: I'm on Win 7 x64 with LC 9.6.8rc and Levure v.0.9.4.0.

@Tonaras Tonaras changed the title Connection to Levure Framework breaks when turning of Messages and on again in the LC IDE Connection to Levure Framework breaks when turning off Messages and on again in the LC IDE Jul 3, 2022
@trevordevore
Copy link
Owner

I've never used the messages feature in the IDE so I haven't dealt with this before. Here is the IDE code in stack "revidelibrary" of LC 9.6.7. (edit script of stack "revidelibrary"). The code removes all front scripts, back scripts, and libraries from the message path in that order. It then restores the scripts in that same order.

Levure loads scripts in the opposite order: libraries, back, and then front. See https://github.com/trevordevore/levure/blob/develop/framework/levure.livecodescript#L1739

It could be that the different order causes the problem. I know the window management front script that is part of the window manager helper relies on a library handler being present. If the IDE code loads the front script, triggers a message that is processed by the front script, but the library stack isn't in use, then an error would occur.

global gRevSuppressMessages
 put "suppressMessages" into tToggleMessage
 
 local tLine
 if not gREVSuppressMessages then
    put true into gREVSuppressMessages
    # Send the suppress messages toggle message before actually suppressing messages
    ideMessageSend "ideToggleChanged:" & tToggleMessage
    set the lockCursor to false
    repeat for each line tLine in the pendingMessages
       if not revIDEObjectIsOnIDEStack(item 4 to -1 of tLine) then
          cancel (item 1 of tLine)
       end if
    end repeat
    repeat for each line tLine in the frontScripts
       if not revIDEObjectIsOnIDEStack(tLine) then
          put tLine & cr after sRestoreState["front"]
          remove script of tLine from front
       end if
    end repeat
    repeat for each line tLine in the backScripts
       if not revIDEObjectIsOnIDEStack(tLine) then
          put tLine & cr after sRestoreState["back"]
          remove script of tLine from back
       end if
    end repeat
    repeat for each line tLine in the stacksInUse
       if not revIDEObjectIsOnIDEStack(tLine) then
          put tLine & cr after sRestoreState["inUse"]
          stop using stack tLine
       end if
    end repeat
    revInternal__LoadLibrary "revNoMessagesLibrary"
    exit revIDEToggle
 else
    revInternal__UnloadLibrary "revNoMessagesLibrary"
    put false into gREVSuppressMessages
    repeat for each line tLine in sRestoreState["front"]
       insert script of tLine into front
    end repeat
    repeat for each line tLine in sRestoreState["back"]
       insert script of tLine into back
    end repeat
    repeat for each line tLine in sRestoreState["inUse"]
       start using stack tLine
    end repeat
    delete variable sRestoreState
 end if
 break

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants