Standalone app not quite the same as IDE version

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10353
Joined: Wed May 06, 2009 2:28 pm

Standalone app not quite the same as IDE version

Post by dunbarx » Mon Feb 29, 2016 5:35 pm

In a stack in the IDE, a user selects menuItems among a handful of option buttons, and all works fine. But in a standalone of exactly that instance of the stack the very same process does not work at all.

I develop on a Mac, OS 10.9, LC 6.7. The standalone is on Windows 7. Anyone else see this?

Craig Newman

quailcreek
Posts: 746
Joined: Sun Feb 04, 2007 11:01 pm

Re: Standalone app not quite the same as IDE version

Post by quailcreek » Mon Feb 29, 2016 10:43 pm

You're not giving us a lot to go on there, Craig.
Tom
MacBook Pro OS Mojave 10.14

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10353
Joined: Wed May 06, 2009 2:28 pm

Re: Standalone app not quite the same as IDE version

Post by dunbarx » Mon Feb 29, 2016 10:54 pm

Well, I thought the internal mechanics of my app are likely not pertinent.

1- In the IDE, a user can select a handful of options, run a process, and get an answer.

2- In a standalone (splash type) made with that exact stack file attached, with the exact same options selected, I get no answer.

I have been able to rewrite small sections of code, essentially removing certain features that speed user selection by filtering illegal choices, and the standalone will work. But there are definitely subtle workings that do not travel.

So I could give my users the IDE stack, and avoid the issue. They could all run the community version of LC, and the problem goes away. But it does not really go away, I just don't have to deal with it. That's why I posted, to see if anyone else had noticed this behavior.

Craig

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7393
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Standalone app not quite the same as IDE version

Post by jacque » Tue Mar 01, 2016 6:11 pm

It isn't clear what exactly doesn't work. Do you mean option buttons aren't triggering correctly? Or do you get a selection but the script fails?
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10353
Joined: Wed May 06, 2009 2:28 pm

Re: Standalone app not quite the same as IDE version

Post by dunbarx » Tue Mar 01, 2016 10:02 pm

The selection of options proceeds normally. The main handler simply gathers the current labels of those option buttons for processing; it fails in the standalone, works in the IDE.

Craig

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7393
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Standalone app not quite the same as IDE version

Post by jacque » Tue Mar 01, 2016 10:45 pm

Should work. What label do you get? Empty? Some other line in the content? An error? "It doesn't work" isn't enough info.

What if you check the menuhistory instead?
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10353
Joined: Wed May 06, 2009 2:28 pm

Re: Standalone app not quite the same as IDE version

Post by dunbarx » Wed Mar 02, 2016 12:16 am

Jacque.

The process that I run is complex. It gets info from the labels of those option menus. I should not even have mentioned them, except for some simple routines that I made. What I mean is that a selection in one option menu adjusts the contents of other option menus, so that upcoming selections available in those others are filtered. If I do not do that, no problems. That is, when I removed the filtering of the contents of those buttons, based on choices in earlier selections, the standalone works as advertised. It is not the contents of the menus that matter since all buttons now have their full suite of menuItems. It just creates a longer list for the user. I was trying to reduce them

Again, the fully filter-enabled IDE stack works just fine. That is why I thought that the internal workings of my stack ought not to matter.

Something is different between the two environments. I can reproduce the effect. I am not sure anyone needs to dig into my stack; I have enough trouble doing so myself. It has 3600 lines of code.

Again, again, I can live with solving a problem without understanding it. I just wondered if anyone else had ever had a standalone that did not work like the development stack.

Craig

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7393
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Standalone app not quite the same as IDE version

Post by jacque » Wed Mar 02, 2016 7:56 am

That fills in some gaps, thanks. But I'm still not clear on the "wrong" response you're seeing. So far I have this info:

1. When a user chooses from an option menu, other option buttons change their content.
2. When the user chooses from the next option menu, the remaining buttons change their content...and so on.
3. After all selections have been made, a handler gathers all the option button labels for processing.
4. *something breaks*

What breaks? When you scan the labels, what's wrong with them? How does it differ from the IDE behavior?

If you're not looking for a solution, you don't need to say. But the buttons should work identically everywhere. I have had stacks that acted differently outside the IDE, but mostly those were mobile apps, which is a different animal and to be expected. Basic object behaviors, especially on desktop apps, should be consistent with the IDE behavior. That's a generic response though; since I don't know what's going wrong I can't be sure if it's a bug or something else.

You could try suspending the IDE and see if that reproduces the problem (Development -> Suspend Development Tools.) Suspension temporarily removes all the IDE scripts.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10353
Joined: Wed May 06, 2009 2:28 pm

Re: Standalone app not quite the same as IDE version

Post by dunbarx » Wed Mar 02, 2016 5:06 pm

Jacque.

The labels are all intact. The process simply stops, as if there was a script error.

I am not sure how to "debug" a standalone, apart from adding snippets of code here and there to output the state of things as it runs, perhaps halted in turns with answer dialogs.

I might just do that one day, since it is only a couple of small changes that make the distinction, and I know where they are. I just thought that the magic that changes a stack into a standalone (even from mac to PC!) simply worked, and this was the first time I found that it does not always just do so.

So that is a question: is there a way to find the line in a handler in a standalone where an error occurs? The real question is why the IDE stack works, of course.

Craig

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10353
Joined: Wed May 06, 2009 2:28 pm

Re: Standalone app not quite the same as IDE version

Post by dunbarx » Wed Mar 02, 2016 5:08 pm

Jacque,

Suspending development tools (I think) is not going to help. The IDE stack works fine. It is the standalone that fails.

Craig

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7393
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Standalone app not quite the same as IDE version

Post by jacque » Wed Mar 02, 2016 8:15 pm

Suspending the IDE attempts to duplicate the standalone experience. No IDE scripts run, plugins are disabled, and all IDE front/backscripts are removed. It's a shortcut to testing a standalone without needing to build one. Granted, I'm not sure what that will tell you though.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Post Reply