> 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
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
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
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
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?
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
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
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
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
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
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
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’
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
> 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
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
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
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
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
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 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
20 matches
Mail list logo
