Re: Standalone build workaround
> On 20 Sep 2018, at 2:51 pm, Brian Milby via use-livecode > wrote: > > What about a front script for the build process that would intercept and > discard these messages? Could be inserted just before each action that used > to be protected by lock messages (close/open stack). I think if that solution could work then lock messages could work. The issue is some components actually need those open messages to function correctly. We are working on a complete replacement to the standalone builder scripts which will resolve this kind of issue but it will still be a some time before they can become part of the IDE. I’ve proposed a stop gap solution internally which I think would work well but will probably need to wait until Ali is back next week before we can throw it around. The idea is to not move the entire standalone build to a separate process (we will likely do that when we move to our complete replacement) but to just move the bits that modify the stackfiles (copy resources, set passwords etc). So we would have a command line app that took the path to the stackfiles on disk and all the settings, modified the stackfiles and saved them somewhere else. Then the IDE can continue on and can do the whole process without closing the stack at all. Cheers Monte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
Maybe it's a little of both. I was helping out over screen sharing and only saw the openstack handler. The app uses a splash-screen model and we did get the conflict Bob described, where the stack the app opens threw a large number of repeated warnings about same-named stack conflicts. It took several dismissals to get rid of them. I don't know what handlers are in the separate mainstack but he said he fixed "all of them" that had open* and close* handlers. This was before we had a check to see if the revStandaloneProgress stack existed. Also during builds, a blank script error dialog appeared. It was unresponsive and empty so we don't know what it was trying to report. A stream of other error messages popped in and out of existence so fast we couldn't read them, so they weren't modal but their content is unknown. All this happened in LC 9 so I had him move back to LC 8. I told him to remove the content stack from memory and from inclusions and try building only the splash app, and that worked, so the problem points to the content stack. When he added it back into the Stacks pane in Standalone Settings the "can't find stack" error happened because the incorrect workaround handler was still in place. I've sent him the updated handler Panos posted and haven't heard back yet, but that should fix it. The release notes need updating so we have a record of the correct workaround. Like I said, it isn't the adaptation we need to do that bothers me as much as the idea that a lot of people won't know what's happening and will blame LC. That's what this person did. He had a bit of a rant about how LC didn't test enough and are producing shoddy software. I spent some time explaining what the real issue was and he then understood. But I'm concerned about other customers out there. On 9/20/18 6:40 AM, Ali Lloyd via use-livecode wrote: Just out of interest, what sorts of things are causing problems in openStack while building a standalone that do not happen when opening stacks for the first time in the IDE? To put it another way, is it simply the re-running of openStack that is causing problems, or is something going wrong? Something like a ‘cascade of errors’ sounds like the latter. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
And the engine itself can support multiple stacks open with the same name. If you do though, you have to use the long name to be sure you access the correct one and the IDE isn't built to always do that. (I've created a demo that validates that the engine can handle this. The engine does prevent opening different files with the same stack name though, so I had to clone and then save the clones with different file names but the same stack name.) For what Bob mentions, it sounds like the stand alone builder isn't keeping track of all the stacks that get opened so that it can set destroyStack to true and close them. Possibly could be as easy as getting a list of open stacks at the end and if the long name of any happens to be in the temp location, then close them before reopening the stack for use in the IDE post-build. Brian On Thu, Sep 20, 2018 at 9:37 AM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > When I build a standalone, I use a splash stack, which when run in a > standalone opens the mainStack. I do not typically have the mainstack > already open, because as has been mentioned multiple times, any stacks > already open after a build, say when building for a separate platform (I > still cannot build for multiple platforms in one pass like I used to) will > pop up stack already open dialogs and ask me to ignore or purge (no > uninitiated user wants to "purge" any of his stacks it's quite unnerving > the first time you see it). > > So I always QUIT LC, and relaunch to avoid any stack already open errors. > What I think is happening is that the copys of the stacks in the standalone > are being left open, so subsequent opening of the stacks produces this > error. Otherwise, subsequent opening of the stacks are opening the > standalone versions instead of the originals because LC gets confused about > stack name references. > > That's just me blind guessing though. > > Bob S > > > > On Sep 20, 2018, at 04:40 , Ali Lloyd via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > Just out of interest, what sorts of things are causing problems in > > openStack while building a standalone that do not happen when opening > > stacks for the first time in the IDE? To put it another way, is it simply > > the re-running of openStack that is causing problems, or is something > going > > wrong? Something like a ‘cascade of errors’ sounds like the latter. > > > > On Thu, 20 Sep 2018 at 06:11, Curry Kenworthy via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > >> > >> Brian: > >> > >>> What about a front script for the build process that would > >>> intercept and discard these messages? > >> > >> There you go! That might be a smooth solution. Or close the stack during > >> build, and offer a user preference of whether to automatically reopen. > >> > >> Usually there are some fairly good solutions possible, better than > >> doubling-down on a dilemma and the lesser of two evils. This could turn > >> out rather nicely. :) > >> > >> Best wishes, > >> > >> Curry Kenworthy > >> > >> Custom Software Development > >> LiveCode Training and Consulting > >> http://livecodeconsulting.com/ > >> > >> ___ > >> use-livecode mailing list > >> use-livecode@lists.runrev.com > >> Please visit this url to subscribe, unsubscribe and manage your > >> subscription preferences: > >> http://lists.runrev.com/mailman/listinfo/use-livecode > >> > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
When I build a standalone, I use a splash stack, which when run in a standalone opens the mainStack. I do not typically have the mainstack already open, because as has been mentioned multiple times, any stacks already open after a build, say when building for a separate platform (I still cannot build for multiple platforms in one pass like I used to) will pop up stack already open dialogs and ask me to ignore or purge (no uninitiated user wants to "purge" any of his stacks it's quite unnerving the first time you see it). So I always QUIT LC, and relaunch to avoid any stack already open errors. What I think is happening is that the copys of the stacks in the standalone are being left open, so subsequent opening of the stacks produces this error. Otherwise, subsequent opening of the stacks are opening the standalone versions instead of the originals because LC gets confused about stack name references. That's just me blind guessing though. Bob S > On Sep 20, 2018, at 04:40 , Ali Lloyd via use-livecode > wrote: > > Just out of interest, what sorts of things are causing problems in > openStack while building a standalone that do not happen when opening > stacks for the first time in the IDE? To put it another way, is it simply > the re-running of openStack that is causing problems, or is something going > wrong? Something like a ‘cascade of errors’ sounds like the latter. > > On Thu, 20 Sep 2018 at 06:11, Curry Kenworthy via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> >> Brian: >> >>> What about a front script for the build process that would >>> intercept and discard these messages? >> >> There you go! That might be a smooth solution. Or close the stack during >> build, and offer a user preference of whether to automatically reopen. >> >> Usually there are some fairly good solutions possible, better than >> doubling-down on a dilemma and the lesser of two evils. This could turn >> out rather nicely. :) >> >> Best wishes, >> >> Curry Kenworthy >> >> Custom Software Development >> LiveCode Training and Consulting >> http://livecodeconsulting.com/ >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
Just out of interest, what sorts of things are causing problems in openStack while building a standalone that do not happen when opening stacks for the first time in the IDE? To put it another way, is it simply the re-running of openStack that is causing problems, or is something going wrong? Something like a ‘cascade of errors’ sounds like the latter. On Thu, 20 Sep 2018 at 06:11, Curry Kenworthy via use-livecode < use-livecode@lists.runrev.com> wrote: > > Brian: > > > What about a front script for the build process that would > > intercept and discard these messages? > > There you go! That might be a smooth solution. Or close the stack during > build, and offer a user preference of whether to automatically reopen. > > Usually there are some fairly good solutions possible, better than > doubling-down on a dilemma and the lesser of two evils. This could turn > out rather nicely. :) > > Best wishes, > > Curry Kenworthy > > Custom Software Development > LiveCode Training and Consulting > http://livecodeconsulting.com/ > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
Brian: > What about a front script for the build process that would > intercept and discard these messages? There you go! That might be a smooth solution. Or close the stack during build, and offer a user preference of whether to automatically reopen. Usually there are some fairly good solutions possible, better than doubling-down on a dilemma and the lesser of two evils. This could turn out rather nicely. :) Best wishes, Curry Kenworthy Custom Software Development LiveCode Training and Consulting http://livecodeconsulting.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
What about a front script for the build process that would intercept and discard these messages? Could be inserted just before each action that used to be protected by lock messages (close/open stack). Thanks, Brian On Sep 19, 2018, 11:41 PM -0500, J. Landman Gay via use-livecode , wrote: > I do understand the dilemma and I can adapt. But to be fair, an > uninitialized variable doesn't require a restart of the IDE. It's possible > to script around that too, it's usually a one-liner, and doesn't have to be > inserted in as many places. > > But what mainly concerned me was how it affected someone who couldn't > explain the change and the inexplicable cascade of errors, and was > frustrated enough to leave the platform behind. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > On September 19, 2018 5:49:20 PM Monte Goulding via use-livecode > wrote: > > > > On 20 Sep 2018, at 6:18 am, Richard Gaskin via use-livecode > > > wrote: > > > > > > Building a standalone is the whole point of the process of developing with > > > LC, and now that it's so disruptive it kills the joy of choosing LiveCode. > > > > > > For more than a decade I've believed making the SB into a separate process > > > would be a good idea. > > > > > > It's no longer a good idea. It's now a necessity. > > > > Unfortunately we are caught between leaving the stack in a state where any > > local variables that are meant to be initialised are unset or letting the > > engine do its thing when the stack reopens and send messages that allow > > those initialisations to occur. The latter, while a big change, was > > considered the lesser of two evils because at least it allows you to code > > around the situation rather than just ending up with a stack in a state > > where you need to quit and restart the IDE. > > > > Ideally, yes, standalone building (at least the parts that manipulate the > > open stacks causing them to need to be reverted) would be a separate > > process. > > > > Cheers > > > > Monte > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
I do understand the dilemma and I can adapt. But to be fair, an uninitialized variable doesn't require a restart of the IDE. It's possible to script around that too, it's usually a one-liner, and doesn't have to be inserted in as many places. But what mainly concerned me was how it affected someone who couldn't explain the change and the inexplicable cascade of errors, and was frustrated enough to leave the platform behind. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On September 19, 2018 5:49:20 PM Monte Goulding via use-livecode wrote: On 20 Sep 2018, at 6:18 am, Richard Gaskin via use-livecode wrote: Building a standalone is the whole point of the process of developing with LC, and now that it's so disruptive it kills the joy of choosing LiveCode. For more than a decade I've believed making the SB into a separate process would be a good idea. It's no longer a good idea. It's now a necessity. Unfortunately we are caught between leaving the stack in a state where any local variables that are meant to be initialised are unset or letting the engine do its thing when the stack reopens and send messages that allow those initialisations to occur. The latter, while a big change, was considered the lesser of two evils because at least it allows you to code around the situation rather than just ending up with a stack in a state where you need to quit and restart the IDE. Ideally, yes, standalone building (at least the parts that manipulate the open stacks causing them to need to be reverted) would be a separate process. Cheers Monte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
Jacqueline: > So yeah, there's repercussions. I do understand the choice the > team had to make, but most of us were used to the old way and > had already accommodated. I would go further. I would say that change is not always value-free; it's not simply a question of what people are accustomed too. (Although that can be important too.) But no, I would say that objectively there is such a thing as a bad change, a wrong choice, and this is a good example. The side effects of the cure seem to be worse than the original problem. We could probably find a way to measure and compare before/after in terms of user efforts and user problems. This issue doesn't affect me much personally because of my own coding habits, thank goodness, but it is an excellent example of how solving a problem the wrong way can lead to bigger problems. Interesting Best wishes, Curry Kenworthy Custom Software Development LiveCode Training and Consulting http://livecodeconsulting.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
That's what happened to the person I'm helping. He's not a sophisticated coder and needed someone else to write a basic openstack handler a few years ago. He's been tinkering with the stack now and then and building new apps occasionally as it changed. He called me, very distressed, and was ready to throw out LC entirely. He'd been trying for a week to build the app and was getting infinite repeated error dialogs that couldn't be dismissed. The error dialog was empty so there was no clue what was wrong and clicking the Script button did nothing. He had contacted support but couldn't afford the rate they wanted to debug the problem. He had no idea why the build suddenly failed all of a sudden. He's a paying Indie customer and LC would have lost him. So yeah, there's repercussions. I do understand the choice the team had to make, but most of us were used to the old way and had already accommodated. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On September 19, 2018 6:22:05 PM Graham Samuel via use-livecode wrote: I am very late to this conversation, but does this mean that a very naive user, devising a simple app that is going to end up as a standalone, will suddenly be plunged into weird unguided coding issues just because the code contains ‘preOpenStack’ and similar handlers, maybe even a ‘Startup’ handler (I use those a lot myself)? If this is true, then I agree with Richard that LiveCode has suddenly got a loss less attractive in its central function - the creation of software that runs on the developer’s chosen platform(s). Just tell me I’m wrong. Graham On 20 Sep 2018, at 00:47, Monte Goulding via use-livecode wrote: On 20 Sep 2018, at 6:18 am, Richard Gaskin via use-livecode wrote: Building a standalone is the whole point of the process of developing with LC, and now that it's so disruptive it kills the joy of choosing LiveCode. For more than a decade I've believed making the SB into a separate process would be a good idea. It's no longer a good idea. It's now a necessity. Unfortunately we are caught between leaving the stack in a state where any local variables that are meant to be initialised are unset or letting the engine do its thing when the stack reopens and send messages that allow those initialisations to occur. The latter, while a big change, was considered the lesser of two evils because at least it allows you to code around the situation rather than just ending up with a stack in a state where you need to quit and restart the IDE. Ideally, yes, standalone building (at least the parts that manipulate the open stacks causing them to need to be reverted) would be a separate process. Cheers Monte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
Read my post, but yes if your handlers do something that can potentially interfere with the standalone builder running (like opening a stack modally) then things can get wiggy. You cannot simply suspend messages before building (as I understand it) because the standalone builder needs to send messages itself. Bob S > On Sep 19, 2018, at 16:20 , Graham Samuel via use-livecode > wrote: > > I am very late to this conversation, but does this mean that a very naive > user, devising a simple app that is going to end up as a standalone, will > suddenly be plunged into weird unguided coding issues just because the code > contains ‘preOpenStack’ and similar handlers, maybe even a ‘Startup’ handler > (I use those a lot myself)? If this is true, then I agree with Richard that > LiveCode has suddenly got a loss less attractive in its central function - > the creation of software that runs on the developer’s chosen platform(s). > Just tell me I’m wrong. > > Graham ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
I am very late to this conversation, but does this mean that a very naive user, devising a simple app that is going to end up as a standalone, will suddenly be plunged into weird unguided coding issues just because the code contains ‘preOpenStack’ and similar handlers, maybe even a ‘Startup’ handler (I use those a lot myself)? If this is true, then I agree with Richard that LiveCode has suddenly got a loss less attractive in its central function - the creation of software that runs on the developer’s chosen platform(s). Just tell me I’m wrong. Graham > On 20 Sep 2018, at 00:47, Monte Goulding via use-livecode > wrote: > > > >> On 20 Sep 2018, at 6:18 am, Richard Gaskin via use-livecode >> wrote: >> >> Building a standalone is the whole point of the process of developing with >> LC, and now that it's so disruptive it kills the joy of choosing LiveCode. >> >> For more than a decade I've believed making the SB into a separate process >> would be a good idea. >> >> It's no longer a good idea. It's now a necessity. > > Unfortunately we are caught between leaving the stack in a state where any > local variables that are meant to be initialised are unset or letting the > engine do its thing when the stack reopens and send messages that allow those > initialisations to occur. The latter, while a big change, was considered the > lesser of two evils because at least it allows you to code around the > situation rather than just ending up with a stack in a state where you need > to quit and restart the IDE. > > Ideally, yes, standalone building (at least the parts that manipulate the > open stacks causing them to need to be reverted) would be a separate process. > > Cheers > > Monte > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
Oh THIS is the issue I was having where I launch a modal stack to ask for a password when I open my mainstack! Jacques informed me I can shift-ctrl-cmd right-click the stack and set the style to topLevel and the compiler would proceed as normal, but Panagiotis solution looks better. I will implement that instead. Bob S > On Sep 18, 2018, at 23:31 , J. Landman Gay via use-livecode > wrote: > > The standalone builder no longer locks messages; the docs say this: > > "As an attempt to improve this situation, the code that locks messages when > closing and opening stacks for standalone builds has been removed. This means > that where previously mainstacks would not receive openStack and closeStack > messages during standalone build, they now do." > > First off, is this true only for openstack and closestack, or for all > open*/close* messages, such as opencard, openbackground, etc.? > > Secondly, if the suggested workaround is placed into an openStack handler: > > on openstack > if the environment is "development" and the mode of stack > "revStandaloneProgress" > 0 then >exit openStack > end if > end openstack > > The IDE throws an error: can't find stack > > Suggestions? I'm trying to help someone debug this problem, as the stack has > an openStack handler that needs to run. If the issue only applies to > openStack messages, then we can change the handler to openCard instead. If > the problem is for all open* messages then we need another solution. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
> On 20 Sep 2018, at 6:18 am, Richard Gaskin via use-livecode > wrote: > > Building a standalone is the whole point of the process of developing with > LC, and now that it's so disruptive it kills the joy of choosing LiveCode. > > For more than a decade I've believed making the SB into a separate process > would be a good idea. > > It's no longer a good idea. It's now a necessity. Unfortunately we are caught between leaving the stack in a state where any local variables that are meant to be initialised are unset or letting the engine do its thing when the stack reopens and send messages that allow those initialisations to occur. The latter, while a big change, was considered the lesser of two evils because at least it allows you to code around the situation rather than just ending up with a stack in a state where you need to quit and restart the IDE. Ideally, yes, standalone building (at least the parts that manipulate the open stacks causing them to need to be reverted) would be a separate process. Cheers Monte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
Jacqueline: > I'm finding that the workaround is more trouble than the > initial issues. Amen. This kind of workaround, I could understand if we were doing it ourselves; although I would hope for it to be a little more elegant even then. But as an official workaround that comes with the product - it doesn't work. This, and the approach that led to this, needs to be rethought. Richard: > so disruptive it kills the joy of choosing LiveCode. Yep, LC/RR started out designing the IDE (if memory serves, I do vaguely and fondly remember the days of v1, not to mention 273) and as important as the engine is, it's good never to forget your roots. This is the face of LiveCode that everyone sees and experiences. Seeing/touching/interacting really is very necessary to the user, as important as it ever was. :) (BTW I hasten to add, not needing another total makeover, just giving appropriate attention to high IDE quality. Sometimes that involves changes, other times maybe thinking twice about changes - looking before leaping is an old but excellent philosophy. Changes don't always have to be big. Hone is a good word for a tool.) > For more than a decade I've believed making the SB into a > separate process would be a good idea. > It's no longer a good idea. It's now a necessity. Indeed a good idea - another perhaps easy option (if it works) might be to close the stack completely during the build, and open it again when completely finished, or let us do so. We don't really need to see the stack sitting there in the IDE during the build, it doesn't accomplish anything. Either way, the current solution is not viable. PS - one person who mentioned this issue to me a few days ago could have had a quick fix for his project, but may have talked himself out of it. I'm always here if needed - to talk yes, but more especially to fix. ;) Best wishes, Curry Kenworthy Custom Software Development LiveCode Training and Consulting http://livecodeconsulting.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
J. Landman Gay wrote: On Tue, Sep 18, 2018 at 11:31 PM J. Landman Gay via use-livecode < use-livecode at lists.runrev.com> wrote: The standalone builder no longer locks messages; the docs say this: "As an attempt to improve this situation, the code that locks messages when closing and opening stacks for standalone builds has been removed. This means that where previously mainstacks would not receive openStack and closeStack messages during standalone build, they now do." Where in the docs does it say this (or what is the "situation" the code is trying to improve)? The Release Notes, page 3. The situation it tries to fix: "The standalone builder has always needed to close the stacks it builds for reasons pretty deeply ingrained in the code. However this causes a few problems, for example: values in script locals become empty behaviors are broken when the parent script is on / in a stack which closes" I'm finding that the workaround is more trouble than the initial issues. The stack I'm helping with has multiple open* and close* handlers, and they all need to be updated. ^ this Building a standalone is the whole point of the process of developing with LC, and now that it's so disruptive it kills the joy of choosing LiveCode. For more than a decade I've believed making the SB into a separate process would be a good idea. It's no longer a good idea. It's now a necessity. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
On 9/19/18 1:05 PM, Geoff Canyon via use-livecode wrote: On Tue, Sep 18, 2018 at 11:31 PM J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: The standalone builder no longer locks messages; the docs say this: "As an attempt to improve this situation, the code that locks messages when closing and opening stacks for standalone builds has been removed. This means that where previously mainstacks would not receive openStack and closeStack messages during standalone build, they now do." Where in the docs does it say this (or what is the "situation" the code is trying to improve)? The Release Notes, page 3. The situation it tries to fix: "The standalone builder has always needed to close the stacks it builds for reasons pretty deeply ingrained in the code. However this causes a few problems, for example: values in script locals become empty behaviors are broken when the parent script is on / in a stack which closes" I'm finding that the workaround is more trouble than the initial issues. The stack I'm helping with has multiple open* and close* handlers, and they all need to be updated. I'd like a toggle somewhere so we can choose whether to use the new build behavior. Backward compatibility is broken now. His build was throwing dozens of errors and always failed, and he was ready to drop LC entirely after a week trying to fix it himself. Not everyone reads this list or the release notes, and even if he had, the release notes are wrong. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
On Tue, Sep 18, 2018 at 11:31 PM J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: > The standalone builder no longer locks messages; the docs say this: > > "As an attempt to improve this situation, the code that locks messages > when closing and opening stacks for standalone builds has been removed. > This means that where previously mainstacks would not receive openStack > and closeStack messages during standalone build, they now do." > Where in the docs does it say this (or what is the "situation" the code is trying to improve)? ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Standalone build workaround
Hello Jacque, The Standalone Builder closes and opens the stack when building a standalone, so this means that all the messages that are sent when closing and opening the stack will be sent. So yes, all the (pre)open*/close* messages are expected to be sent. The "if" block should change to: if the environment is "development" AND there is a stack "revStandaloneProgress" AND the mode of stack "revStandaloneProgress" > 0 then exit handlerName end if as when you open the stack for the first time (without having built a standalone before), the stack "revStandaloneProgress" is not loaded yet (thus the "can't find stack error). So you could write a function: function isBuildingStandalone return the environment is "development" AND \ there is a stack "revStandaloneProgress" AND \ the mode of stack "revStandaloneProgress" > 0 end isBuildingStandalone and then in e.g. the openstack handler: on openstack if isBuildingStandalone() then exit openstack end if .. .. end openstack Similar in all other (pre)open*/close* messages. Kind regards, Panos -- On Wed, Sep 19, 2018 at 9:31 AM J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: > The standalone builder no longer locks messages; the docs say this: > > "As an attempt to improve this situation, the code that locks messages > when closing and opening stacks for standalone builds has been removed. > This means that where previously mainstacks would not receive openStack > and closeStack messages during standalone build, they now do." > > First off, is this true only for openstack and closestack, or for all > open*/close* messages, such as opencard, openbackground, etc.? > > Secondly, if the suggested workaround is placed into an openStack handler: > > on openstack >if the environment is "development" and the mode of stack > "revStandaloneProgress" > 0 then > exit openStack >end if > end openstack > > The IDE throws an error: can't find stack > > Suggestions? I'm trying to help someone debug this problem, as the stack > has an openStack handler that needs to run. If the issue only applies to > openStack messages, then we can change the handler to openCard instead. > If the problem is for all open* messages then we need another solution. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Standalone build workaround
The standalone builder no longer locks messages; the docs say this: "As an attempt to improve this situation, the code that locks messages when closing and opening stacks for standalone builds has been removed. This means that where previously mainstacks would not receive openStack and closeStack messages during standalone build, they now do." First off, is this true only for openstack and closestack, or for all open*/close* messages, such as opencard, openbackground, etc.? Secondly, if the suggested workaround is placed into an openStack handler: on openstack if the environment is "development" and the mode of stack "revStandaloneProgress" > 0 then exit openStack end if end openstack The IDE throws an error: can't find stack Suggestions? I'm trying to help someone debug this problem, as the stack has an openStack handler that needs to run. If the issue only applies to openStack messages, then we can change the handler to openCard instead. If the problem is for all open* messages then we need another solution. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
