confirmed.. happening here… I've been getting this since 8.1.5, never cause
serious problem, and had no recipe, so could not report it.. but yes exactly
this
debug breaking on preopenstack
when closing up stacks.
BR
On 8/4/17, 11:06 PM, "use-livecode on behalf of Richmond Mathewson via
On 07.09.2014 at 17:18 Uhr -0500 J. Landman Gay apparently wrote:
It seemed non-intuitive to me too that you could put a preOpenStack
handler in a card, because the card wasn't open yet. That was
wrong-thinking. I asked Mark Waddingham about it some years ago and
he said that the entire stack
On 9/7/2014, 3:55 PM, William Prothero wrote:
I understand that if a stack is opened, then the preOpenStack handler
is triggered (it is in the first card), but if I go to another card
on the same stack with a different preOpenStack handler on it, I
would assume the preOpenStack handler wouldn’t g
Richard,
sorry for not being more clear.
I understand that if a stack is opened, then the preOpenStack handler is
triggered (it is in the first card), but if I go to another card on the same
stack with a different preOpenStack handler on it, I would assume the
preOpenStack handler wouldn’t get
William Prothero wrote:
> Richard:
> Tnx for the comments, all.
> Just to check my understanding of this issue:
>
> So, the “on preopenstack” message, in a card script, will only get
> triggered once, when the stack is opened? It won’t get triggered when
> you go to another card with an “on preOpe
Richard:
Tnx for the comments, all.
Just to check my understanding of this issue:
So, the “on preopenstack” message, in a card script, will only get triggered
once, when the stack is opened? It won’t get triggered when you go to another
card with an “on preOpenStack” handler??
Bill
On Sep 7,
Terence Heaford wrote:
> Putting it in the card script does seem to be the answer.
>
> Had a quick look in the dictionary and I couldn’t find where it says
> do not put it in the stack script.
> The dictionary just says the message is sent to the destination card
> when you open a stack.
Whether
I encourage everyone who would like the notes to be updated to do so yourself
by adding comments to the dictionary items.
This is a great feature of the documentation. Just scroll all the way down on a
dictionary entry.
Bill Vlahos
_
InfoWallet (http://www.infowallet.com) is abo
You really have to understand the message path for this kind of thing to be
clear. If you master the way messages get sent, passed, and handled, then it's
actually obvious. If you don't know the message path, it seems
counterintuitive. Knowing the message path backwards and forwards to the point
I guess it's part of flexibility of LiveCode where you can have things like
'mouseup' handlers in a group, field, card or stack - but for sure the
dictionary could be tweaked to make things clearer...
-
"Some are born coders, some achieve coding, and some have coding thrust upon
them." - Wi
, not what is actually is
existence. The wording is a bit misleading is all...
Craig
-Original Message-
From: Mark Wieder
To: use-livecode
Sent: Sun, Sep 7, 2014 11:23 am
Subject: Re: preOpenStack
Terence Heaford writes:
> Putting it in the card script does seem to be the ans
Earthednet-wp writes:
>
> Mark,
> Ok, you answered my concern. I guess it's another item to add to the
dictionary somehow.
Yeah, it's just one of those things that you learn along the way. It's only
intuitive in hindsight.
--
Mark Wieder
ahsoftw...@gmail.com
Mark,
Ok, you answered my concern. I guess it's another item to add to the dictionary
somehow.
Bill
William Prothero
http://es.earthednet.org
> On Sep 7, 2014, at 8:22 AM, Mark Wieder wrote:
>
> Terence Heaford writes:
>
>> Putting it in the card script does seem to be the answer.
>>
>> Had
Terence Heaford writes:
> Putting it in the card script does seem to be the answer.
>
> Had a quick look in the dictionary and I couldn’t find where it says do
not put it in the stack script.
> The dictionary just says the message is sent to the destination card when
you open a stack.
As you yo
Terence,
Interesting, but it seems counter-intuitive to have a handler that references
the stack being required to be on a card script. Which card? I assume it's the
card that first opens in the stack?
Bill
William Prothero
http://es.earthednet.org
> On Sep 7, 2014, at 12:02 AM, Terence Heaford
Thanks for your reply.
Putting it in the card script does seem to be the answer.
Had a quick look in the dictionary and I couldn’t find where it says do not put
it in the stack script.
The dictionary just says the message is sent to the destination card when you
open a stack.
It may be in some
Thanks for your reply.
Putting it in the card script does seem to be the answer.
Had a quick look in the dictionary and I couldn’t find where it says do not put
it in the stack script.
The dictionary just says the message is sent to the destination card when you
open a stack.
It may be in some
Terence-
Saturday, September 6, 2014, 4:26:23 AM, you wrote:
> I have a stack(main stack) which in the stack script contains a
> preopenstack handler that I use to set the size of the window before
> it shows.
The preopenstack and openstack class of handlers should be in the
script of the first
One of the nice things about attending the conferences is that you overhear
little asides the engineers drop into conversations. Yesterday one of them
said they'd rather we entered everything into the bug database, even if we
aren't positive it's really a bug. They'd rather know than miss some
> Thanks for your response, I am aware of this solution but
>
> Is what I described correct or a bug?
>
Honnestly I don't know. I had a similar problem as yours with
earlier versions of LC (4.5.3 IIRC), that's why I always use the
solution I mentioned. Therefore I don't if it also happens in
mor
If I understand correctly, what is happening is that the preopenstack message
is getting passed through the "MyOtherStack" script and ends up going to the
main stack script. One solution is to put an empty "on preopenstack" handler in
the "MyOtherStack" script, to the message won't get to the ma
Thanks for your response, I am aware of this solution but…
Is what I described correct or a bug?
Thanks
Terry
On 06 Sep 2014, at 12:32, j...@souslelogo.com wrote:
> Hello,
>
> When using preopenstack or openstack, I always check the name
> of the stack, no matter which version of LC.
>
> on
Thanks for your response, I am aware of this solution but…
Is what I described correct or a bug?
Thanks
Terry
On 06 Sep 2014, at 12:32, j...@souslelogo.com wrote:
> Hello,
>
> When using preopenstack or openstack, I always check the name
> of the stack, no matter which version of LC.
>
> o
Hello,
When using preopenstack or openstack, I always check the name
of the stack, no matter which version of LC.
on openStack
if short name of this stack contains "my main stack" then
-- do something
end if
end openStack
This way you're 100% safe.
Best
jbv
> I have a stack(main s
Richard,
Bug 9385.
I'm using that workaround but I don't like I.
--
Best regards,
Mark Schonewille
Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553
Download the Installer Maker Plugin 1.7 for LiveC
On 09/02/2012, at 12:02 PM, Mark Schonewille wrote:
Hi,
Why does the preOpenStack handler run when I use the palette command (even if
the lockmessages are true) and what can I do against it?
Weird - and shouldn't happen - seems like a bug to me. I guess you could
workaround it by setting a fl
Mark Schonewille wrote:
> Why does the preOpenStack handler run when I use the palette command
> (even if the lockmessages are true) and what can I do against it?
Any system messages sent while messages are locked is a bug. Please
submit the recipe.
As for workarounds, you might consider a s
Lots of options so I chose the to move my preOpenStack from the stack script
to script of card 1 and it works perfectly.
thanks,
On Tue, Dec 7, 2010 at 7:29 PM, Terry Judd wrote:
> This is normal behaviour. The ways around it are...
>
> 1. an empty preopenstack handler in the substack
> 2. stac
These aren't the droids you are looking for. Move along...
Bob
On Dec 7, 2010, at 11:34 PM, Mark Wieder wrote:
> There's a somewhat earlier version on revOnline with nag screens but
> otherwise fully functional.
>
> ...and...er...don't look at the PowerTools page. I haven't announced
> that o
Peter-
Tuesday, December 7, 2010, 11:08:46 PM, you wrote:
> That's a pretty nasty cough you have there Mark! How can I download
> PowerDebug? The link takes me to a place where I can buy it but the
> Downloads page just has Powertools (which also looks interesting).
There's a somewhat earlier
That's a pretty nasty cough you have there Mark! How can I download
PowerDebug? The link takes me to a place where I can buy it but the
Downloads page just has Powertools (which also looks interesting).
Pete Haworth
On Dec 7, 2010, at 10:12 PM, Mark Wieder wrote:
Peter-
Tuesday, Decembe
Peter-
Tuesday, December 7, 2010, 6:45:35 PM, you wrote:
> I can only confirm that I've had the same problem many times, wish I
> had a solution for it. Makes debugging pretty difficult.
I should probably point out that PowerDebug handles this (and many
other former annoyances) properly.
...a
This is normal behaviour. The ways around it are...
1. an empty preopenstack handler in the substack
2. stack specific code in the main stack preopenstack handler
on preopenstack
if the short name of me = [mainstack name] then
do stuff
end if
end preopenstack
3. move the preopenstack
Peter,
I also resubmitted it so the version would be updated. It's bug 9219. As a
workaround, instead of using a dot breakpoint, use the 'breakpoint' keyword.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe
I've reopened my bug report, so hopefully we can get it worked on.
___
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/listi
I can only confirm that I've had the same problem many times, wish I
had a solution for it. Makes debugging pretty difficult.
Pete Haworth
On Dec 7, 2010, at 6:36 PM, Mike Kerner wrote:
Unrelated to the other preOpenStack problem reported in 4.5.1
earlier by
someone else
I have a pre
On 07.12.2010 at 19:19 Uhr -0700 Glen Bojsza apparently wrote:
When the substack opens the preOpenStack of the mainstack tries to run which
generates an error since none of the objects on the mainstack are on the
substack.
Should preOpenStack only work with the stack that contains it?
If this i
I think I've run into that and got round it by checking the name of
"this stack" in the preOpenStack handler and only executing the rest
of the script if I'm in the mainstack. Actually, come to think about
it, that was in a preOpenCard handler for a card in the main stack,
not the main sta
Well, never mind, I guess, I see I reported this bug as 7006 way back in the
v. 3 days and it is still listed as "unconfirmed". I also see that now, as
then, if I use "breakpoint" instead of a dot breakpoint, things work ok.
___
use-livecode mailing list
If you move the preOpenStack handler to the script of the first card of the
mainstack, the substack won't trigger the handler. This is a common method of
handling "housekeeping" and other routines that you want run at startup, but
don't want triggered by substacks.
Regards,
Scott Rossi
Creati
40 matches
Mail list logo
