Page 2 of 2

Re: Answer Dialogs Not Working in Standalone

Posted: Sun Oct 07, 2018 9:51 pm
by stephenmcnutt
I can confirm some of the above. When I choose to manually select inclusions, three are automatically pre-selected (cursors, answer dialog, and ask dialog), and at least the answer and ask dialogs can't really be deselected as they're re-selected automatically next time you look.

When I do manual selection of inclusions, my answer dialogs don't work in the standalone despite their being checked in the inclusions list. It's possible this is because I've failed to select some OTHER required inclusion(s), but I honestly have no idea which inclusions I need. For example, that "Mac native button" thing. Seems like I'd need that, but I didn't check it. Who knows? Well I don't, I guess.

When I use automatic inclusion selection, my answer dialogs work, BUT I get the problem with tsNet.bundle being included unnecessarily (I believe) in my standalone, and the inclusion of tsNet gives me other problems as described in a post I made in this forum, I believe, yesterday.

So yes, I'd say we have a bug here. Keep in mind (from my early posts in this thread) that I erased the SSD on my MacBook Pro and did a clean install of macOS Mojave as a troubleshooting measure, and that doesn't seem to have helped. Well, actually, it did help because before I did that, my standalone's answer dialogs wouldn't work at all, regardless of whether automatically or manually selecting inclusions. So maybe that's a tiny clue, but something is definitely wrong.

Should I create a bug report, or has someone already done that? And thanks for all the help.

Steve

Re: Answer Dialogs Not Working in Standalone

Posted: Mon Oct 08, 2018 11:12 pm
by stephenmcnutt
Should I do a bug report then? If so, where do I do that?

Re: Answer Dialogs Not Working in Standalone

Posted: Mon Oct 08, 2018 11:39 pm
by jacque
Are you building for mobile or desktop? Have you tried remote debugging? It may be that the handler is erroring and aborting before the answer dialog is called. It would be good to eliminate that possibility before submitting a report.

If you just want the team to look at it instead, reports go here: http://quality.livecode.com

Re: Answer Dialogs Not Working in Standalone

Posted: Tue Oct 09, 2018 1:09 am
by dunbarx
Jacque wrote:
It may be that the handler is erroring and aborting before the answer dialog is called.
But then wouldn't the handler throw an error and halt in the IDE? Worth checking carefully, but when my users complain that something in particular fails to work in a standalone, I always find an error in the code.

Craig

Re: Answer Dialogs Not Working in Standalone

Posted: Tue Oct 09, 2018 3:27 am
by jacque
But then wouldn't the handler throw an error and halt in the IDE?
If it's a coding error, yes. If it's an error related to the standalone status it can fail silently and put the error in the result instead. Missing extensions or stacks can do that, for example.

Re: Answer Dialogs Not Working in Standalone

Posted: Tue Oct 09, 2018 10:22 pm
by stephenmcnutt
What is remote debugging?

Re: Answer Dialogs Not Working in Standalone

Posted: Wed Oct 10, 2018 7:56 pm
by jacque
stephenmcnutt wrote:
Tue Oct 09, 2018 10:22 pm
What is remote debugging?
Remote debugging is the ability to use the debugger when running a standalone. If you've used the debugger in the past, the process is the same. I still don't know if you are building for mobile or desktop; on mobile devices, if you cable your phone to the computer and use the Test button in the toolbar, remote debugging is automatically set up. If the phone is not cabled, or if you are building for desktop, you must include the Remote Debugger extension as an inclusion.

Set breakpoints normally in the script(s) before you build. When the standalone hits a breakpoint, the remote debugger will look for an open copy of LC on your computer and if it finds one, it will open the debugger script window as usual. You can then step through the code, check variable values, etc. on the computer.

This is a relatively new feature and there are still some glitches. You may find that if you change a script and rebuild the standalone, the debugger will show the older script rather than the newly changed one. The only workaround I've found until this is fixed is to restart LC to clear its cached copy. But for simply checking to see if a handler is aborting, as you would be doing, it should work well enough.