Repairing the amnesia of standalones

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

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, robinmiller

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3977
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Repairing the amnesia of standalones

Post by jacque » Tue Oct 24, 2017 10:04 pm

Is the menu group placed on every card? Here is a description of how menu groups work in LC:

http://www.hyperactivesw.com/mctutorial ... Menus.html
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

kresten
Posts: 98
Joined: Tue Sep 30, 2008 3:01 pm
Location: Copenhagen
Contact:

Re: Repairing the amnesia of standalones

Post by kresten » Tue Oct 24, 2017 11:37 pm

Thank you, On Mac no problems, it was the disappearance of menus in same stack on windows , which - after two weeks of frustrations - had brought me to a point of desperation, enough to bother you with it.
After my posting I returned on windows to look for a solution......and alas: I did find it ! I am a little unsure of how, but the essence was to make what was not visible visible. Thus emerged the menu button group, I could move it to its optimal position, and create the launcher-type standalone.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3977
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Repairing the amnesia of standalones

Post by jacque » Wed Oct 25, 2017 12:30 am

If you set the menubar of the stack to the short name of the group, LC will handle the visibility for you. The menu group will show on Windows and move to the system menu on Mac. Note that the height of the stack will change depending on platform when that happens.

The link I posted explains more about that. Also see "menubar" in the dictionary.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

kresten
Posts: 98
Joined: Tue Sep 30, 2008 3:01 pm
Location: Copenhagen
Contact:

Re: Repairing the amnesia of standalones

Post by kresten » Fri Oct 27, 2017 2:33 pm

So I reached a situation, where mainstack and substack with menu ( including dialogs for deleting cards and updating) and link to mainstack works perfectly on windows.
However the standaloning of the launcher stack (myDiary.livecode) produces a MyDiary.exe file, which has the full menu, including functional dialogues e.g. for delete this card, but no result from the phenoupdate, and a paralysed link to the mainstack.
The standalone application settings requires advanced options (in order to keep ask-answer dialogues and browser.)
I try including or not including e-diary among script inclusions there, but same negative result.
Any advice how to get out of this quagmire ?

bogs
Posts: 715
Joined: Sat Feb 25, 2017 10:45 pm

Re: Repairing the amnesia of standalones

Post by bogs » Wed Nov 01, 2017 10:01 pm

I apologize, kresten, but after reading this a few times, I am not sure I am understanding the issue correctly.

Btw, impressive description on the website for this. I've gone ahead and sent you an email in response to your pm.
ImageImage

kresten
Posts: 98
Joined: Tue Sep 30, 2008 3:01 pm
Location: Copenhagen
Contact:

Re: Repairing the amnesia of standalones

Post by kresten » Thu Nov 02, 2017 1:18 am

The issues are two . and only on windows standalone.
In substack "phenomenalog" :
a) there is a button, which is supposed to open the mainstack and close that substack, but it doesn't work
b) there is a menu called "Tools" in which one option is called "phenoupdate", and precisely that option doesn't work (while the others do work)
Basically the openstack handler calls a phenoupdate handler which checks date and time, and if date and time is later than the last daycard
a) copies the text of last daycard to an accumulating html file
b) creates a new daycard
None of these "automatic" operations takes place in the windows standalone (while working perfectly in the windows original, and also in the macstandalone

bogs
Posts: 715
Joined: Sat Feb 25, 2017 10:45 pm

Re: Repairing the amnesia of standalones

Post by bogs » Thu Nov 02, 2017 5:21 am

kresten wrote:
Thu Nov 02, 2017 1:18 am
The issues are two . and only on windows standalone.
In substack "phenomenalog" :
a) there is a button, which is supposed to open the mainstack and close that substack, but it doesn't work
Let us start here, copy and paste the code so we can see what is going on with this button, then we will move on.
ImageImage

kresten
Posts: 98
Joined: Tue Sep 30, 2008 3:01 pm
Location: Copenhagen
Contact:

Re: Repairing the amnesia of standalones

Post by kresten » Thu Nov 02, 2017 11:40 am

on mouseUp
phenoupdate
close stack "phenomenalog"
open stack "e-diary"
show stack "e-diary"
end mouseUp

bogs
Posts: 715
Joined: Sat Feb 25, 2017 10:45 pm

Re: Repairing the amnesia of standalones

Post by bogs » Thu Nov 02, 2017 3:44 pm

A few thoughts and questions.
  • phenoupdate <- the code for this handler is... ?
    close stack "phenomenalog"
Why are we closing this, instead of iconifying or hiding it?
i.e. - set the visible of stack "phenomenalog" to false
  • open stack "e-diary"
    show stack "e-diary"
if you are trying to get this stack to open, why not use -
  • go to stack "e-diary"
This assumes that "e-diary" is a substack of main program or launched stack. If you need a specific card of "e-diary", you might write it to test and make sure it is available, such as -
  • if there is a stack "myStack" then go card "e-diary" of stack "myStack"
ImageImage

bogs
Posts: 715
Joined: Sat Feb 25, 2017 10:45 pm

Re: Repairing the amnesia of standalones

Post by bogs » Thu Nov 02, 2017 7:42 pm

By the way, you should have received 2 emails from me, in the subject of both is the line "Re: Repairing the amnesia of standalones", but I have received no response.

The sending address will start with rdbar814, not 'bogs', so please check your trash and spam boxes if you don't see them in your inbox.

I included a simple utility to get the code from your stacks and dump it to a simple text file, which is easier for me to work with usually. And yes to the question in the pm, if you feel comfortable with it I will be happy to review the stacks themselves as time permits.
ImageImage

kresten
Posts: 98
Joined: Tue Sep 30, 2008 3:01 pm
Location: Copenhagen
Contact:

Re: Repairing the amnesia of standalones

Post by kresten » Thu Nov 02, 2017 9:21 pm

Dear Bogs,
Seen from here you should have received 2 replies, one of which contains the 2 text files I produced with your program, and one which merely tells, that i clarified the problems in a post to this thread. This means, that you should have the full text of the phenoupdate handler , which - in this windows standaloning - is the root of evil.

bogs
Posts: 715
Joined: Sat Feb 25, 2017 10:45 pm

Re: Repairing the amnesia of standalones

Post by bogs » Thu Nov 02, 2017 10:05 pm

I do apologize Kresten, apparently I was not *quite* patient enough, both replies arrived this afternoon while I was out :oops: Will be reviewing the text output.
ImageImage

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3977
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Repairing the amnesia of standalones

Post by jacque » Fri Nov 03, 2017 7:26 am

Why are we closing this, instead of iconifying or hiding it?
i.e. - set the visible of stack "phenomenalog" to false
Closing a stack is the standard. Iconifying and hiding stacks are much rarer.

I haven't had time to follow this thread completely but the problem sounds to me like a script is calling a handler that isn't currently in the message path. That can be fixed by using "send" or by putting the script in use. But it would be difficult to diagnose this without knowing the stack structure and where the handlers are located.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

bogs
Posts: 715
Joined: Sat Feb 25, 2017 10:45 pm

Re: Repairing the amnesia of standalones

Post by bogs » Fri Nov 03, 2017 2:01 pm

I completely agree that closing it is the more usual of the two, but in reading his last few posts, I took this -
kresten wrote:
Fri Oct 27, 2017 2:33 pm
... the standaloning of the launcher stack (myDiary.livecode) produces a MyDiary.exe file, which has the full menu, including functional dialogues...
to mean that the main launcher is still in use for some of the program related functions, instead of being *just* a launcher, if you see what I mean.

Of course, It is more than possible that I have a misunderstanding of the procedure myself, I know that just closing the stack doesn't necessarily remove it from memory ( like 'destroyStack' set to true would, I think), so this is a good time for me to learn something else from you :D

I did find that in the stacks he sent me, there was an active breakpoint from a debugging session, I seem to remember** reading about that recently, causing issues when the program was running live outside the IDE. Still going through the rest of the code.

**Edit - Ross was the one that pointed it out in the 'standalone failed' thread.
RossG wrote:
Thu Oct 26, 2017 3:37 am
I've developed a great way to make a stand-alone fail.

Just leave a break-point set when you compile.

Works every time.
ImageImage

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3977
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Repairing the amnesia of standalones

Post by jacque » Fri Nov 03, 2017 9:44 pm

In general, standalones will ignore breakpoints because they don't include a debugger. One exception is if you are testing mobile in the IDE with a cabled device, using the Test button. In that case the remote debugger is automatically installed and will stop at breakpoints (you can turn off the auto-installation in the latest LC 9dp10.) Another exception is if the remote debugger has been specifically included in any standalone (desktop or mobile) by selecting it in the Inclusions list.

If a compiled, independent standalone is stopping at an accidentally preserved breakpoint, and the remote debugger is not installed, I'd consider that a bug. Regardless, it's good practice to use the "Clear all breakpoints" menu item in the script editor before building a standalone for distribution.

I haven't had time to follow this thread thoroughly, so I shouldn't be commenting on the OP's issues. However, the script of the mainstack has to be put in use if its handlers need to function when called from another stack. I vaguely recall this wasn't always necessary but either things have changed or I remember wrong.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Post Reply

Return to “Talking LiveCode”