Page 5 of 6

Re: Repairing the amnesia of standalones

Posted: Tue Oct 24, 2017 10:04 pm
by jacque
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

Re: Repairing the amnesia of standalones

Posted: Tue Oct 24, 2017 11:37 pm
by kresten
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.

Re: Repairing the amnesia of standalones

Posted: Wed Oct 25, 2017 12:30 am
by jacque
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.

Re: Repairing the amnesia of standalones

Posted: Fri Oct 27, 2017 2:33 pm
by kresten
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 ?

Re: Repairing the amnesia of standalones

Posted: Wed Nov 01, 2017 10:01 pm
by bogs
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.

Re: Repairing the amnesia of standalones

Posted: Thu Nov 02, 2017 1:18 am
by kresten
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

Re: Repairing the amnesia of standalones

Posted: Thu Nov 02, 2017 5:21 am
by bogs
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.

Re: Repairing the amnesia of standalones

Posted: Thu Nov 02, 2017 11:40 am
by kresten
on mouseUp
phenoupdate
close stack "phenomenalog"
open stack "e-diary"
show stack "e-diary"
end mouseUp

Re: Repairing the amnesia of standalones

Posted: Thu Nov 02, 2017 3:44 pm
by bogs
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"

Re: Repairing the amnesia of standalones

Posted: Thu Nov 02, 2017 7:42 pm
by bogs
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.

Re: Repairing the amnesia of standalones

Posted: Thu Nov 02, 2017 9:21 pm
by kresten
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.

Re: Repairing the amnesia of standalones

Posted: Thu Nov 02, 2017 10:05 pm
by bogs
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.

Re: Repairing the amnesia of standalones

Posted: Fri Nov 03, 2017 7:26 am
by jacque
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.

Re: Repairing the amnesia of standalones

Posted: Fri Nov 03, 2017 2:01 pm
by bogs
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.

Re: Repairing the amnesia of standalones

Posted: Fri Nov 03, 2017 9:44 pm
by jacque
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.