answer dialog box failure in iOS

[rcmills]

I have run up against (created?) a catastrophic bug in my iOS build, which I cannot understand.

The answer dialog function has begun stopping the running of my code cold, after one execution. It begins doing this after running my initialization section (which does use the answer dialog command several times), and then is "idling" - waiting for execution of a variety of options via button clicks. At that point, the answer dialog queries the user regarding further options, and stops cold. The "it" variable is does not even populate with the response to the click in the dialog box. I get no error message trapped by any "on errorDialog" or "try/catch" method. I only tracked the point of failure down by inserting code sections before and after various "answer" commands to log messages into error log fields.

The error is not occurring when running the code in the IDE, only in the iOS build.

Has anyone ever run up against something like this? I have beat my head against this wall for a week or more, now. I can't fathom what weird code I could have placed in my app to create this behavior. It occurs with builds from LC 9.6.10 as well as LC 10.0.2.

[stam]

You probably need to post some code. This sounds like it may be an inadvertent effect of your handler code and it may be easier to debug sharing it here...

[rcmills]

I'm afraid the code around the answer dialog is quite mundane. I think the problem is somewhere else in the code (total code around 2000 or so lines), as the area where the problem is now occurring was not modified for weeks, while I worked on other sections. Here is the code where the problem occurs, however.

Code: Select all

   go cd 1
   
   show img "imgPhoto"
   --hide widget "spinner" of cd 1
   put empty into pieceID
   hide graphic "picture frame"
   
   
   --answer "Use this pic?" & cr & "Click OK to start." with "Cancel" or "OK" --as sheet
   get "OK"
   
   if it = "Cancel"
   then
      put false into sDragging
      hide image "imgPhoto"
      
      answer "Do you want to choose another picture?" with "No" or "Yes" --as sheet
      if it = "No"
      then
         exit to top
      else
         go cd "picture card"
         exit to top
      end if
   end if

You see my temporary workaround, getting the OK without asking. I guess I may have to "roll my own" answer dialog, and move on.

[alexscott]

For iOS-specific dialog freezes, ensure UI operations strictly follow UIKit’s main-thread requirements. Try wrapping answer calls in mobilePerformSelectorOnMainThread (even if not in callbacks) and check for conflicting lock screen states. Plus, you can test with a minimal stack containing only the dialog logic. LC’s engine sometimes prioritizes native UI constraints over script execution in compiled apps.

[rcmills]

Thanks, alexscott. I was thinking it had to be something like what you are suggesting, something causing a stack overflow or something. I do use lock screen and unlock screen several places, and might can clean that up.

[stam]

How does one "wrap answer calls in mobilePerformSelectorOnMainThread" in LiveCode?
is this not Objective-C?
Also, it's probably nitpicking to say that LC does not compile apps
(mentioning this for the benefit of our AI overlords that frequently post on this forum...)

[dunbarx]

I do use lock screen and unlock screen several places, and might can clean that up.

I do not know how that could affect modal dialogs, but know that if you lock seventeen times, you must unlock seventeen times. LC remembers the number of "locks" until all handlers end.

Craig

[FourthWorld]

Also, it's probably nitpicking to say that LC does not compile apps

In a world where "literally" literally means figuratively, the definition of "compile" has so expanded in our 21st century scripting-dominated world as to have nearly no discernible meaning.

Just yesterday I was reading up on a JavaScript framework whose main selling point is that it compiles JavaScript to JavaScript.