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 Mat
So, in the most recent version of my Devawriter Pro I have a script in
the preOpenStack
section of the stackScript:
on preOpenStack
send "mouseUp" to btn "CHECKIT"
end preOpenStack
btn "CHECKIT" checks the end-user's computer's MAC address
against a l
and stack files
FYI the compositor was doing really, really strange things on my mac so I
turned it off under development. Alsothe documentation and lesson on this is
really lean, so if anyone has better, more detailed guidelines for best
practices on this , please let us know:
I have this in t
Sannyasin Brahmanathaswami wrote:
> if we put
>
> on preopenStack
> answer "hello" with "OK"
> # do stuff here
> end preopenstack
>
> into the script of card 1 of a stack
>
> As a way to encapsulate the preopenstack from the message path
>
>
On 11/22/2016 4:15 PM, Sannyasin Brahmanathaswami wrote:
> on mouseUp
> preopenStack
> end mouseup
You have to send the message using send or dispatch (or call - see teh
dictionary for differences between these three methods). So:
on mouseUp
send "preOpenStack" to th
put the stuff you would perform in a handler and call that from preopenstack
and from your button mouseUp handler.
Bob S
> On Nov 22, 2016, at 13:15 , Sannyasin Brahmanathaswami
> wrote:
>
> if we put
>
> on preopenStack
> answer "hello" with "OK&q
if we put
on preopenStack
answer "hello" with "OK"
# do stuff here
end preopenstack
into the script of card 1 of a stack
As a way to encapsulate the preopenstack from the message path
and you put a button "Run" on the card:
on mouseUp
preopenStack
end mouseup
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 e
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
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
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 ano
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
thrust upon
> them." - William Shakespeare & Hugh Senior
>
> --
> View this message in context:
> http://runtime-revolution.278305.n4.nabble.com/preOpenStack-tp4682886p4682929.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
>
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
ng thrust upon
them." - William Shakespeare & Hugh Senior
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/preOpenStack-tp4682886p4682929.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
It actually is a bit counterintuitive that a card can receive a preOpenStack
message. After all, the whole (ostensible) idea is that "preOpenstack" is sent
before the stack opens, so how could there even be a card to send that message
to.
It is all mainly a matter of drawing, though
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
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 o
some other docs somewhere.
All the best
Terry
On 06 Sep 2014, at 17:08, Mark Wieder wrote:
> 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 se
some other docs somewhere.
All the best
Terry
On 06 Sep 2014, at 17:08, Mark Wieder wrote:
> 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 se
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
, 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
> 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, t
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 v
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 v
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
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.
One of the datagrids on the card of this stack executes:
on mouseDoubleUp theMouseButton
open stack “MyOtherStack" as sheet
end mouseDoubleUp
Thanks!
On Jun 9, 2013, at 11:09 PM, Scott Rossi wrote:
> Startup?
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 6/9/13 9:30 PM, "Dar Scott" wrote:
>
>> I forgot the name of the handler
Startup?
Regards,
Scott Rossi
Creative Director
Tactile Media, UX/UI Design
On 6/9/13 9:30 PM, "Dar Scott" wrote:
>I forgot the name of the handler that is called in an application before
>preOpenStack. "restart"? Doe
I forgot the name of the handler that is called in an application before
preOpenStack. "restart"? Does that still exist?
Dar
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe
Sorry, I read through the OP too quickly!
For Richard's case splitting the check between preOpenStack and openStack
should work, this is what I tested…
== subStack script ==
local sCondition
on preOpenStack
put the hilite of btn "badCondition" of stack "stack_1"
>>
>>
>> But this doesn't seem to stop openStack from getting called; I thought it
>> did.
>>
>> How do I cause the entire stack opening to abort from within preOpenStack?
>>
>> And on that line, I'm tracking a bug that is messing with
gt; answer "You can't do this yet because blah blah blah!"
> close this stack
> end if
>
>
> But this doesn't seem to stop openStack from getting called; I thought it
> did.
>
> How do I cause the entire stack opening to abort from within preOpenStack?
&
How do I cause the entire stack opening to abort from within preOpenStack?
And on that line, I'm tracking a bug that is messing with opening a card
with a datagrid. Apparently my grey column problem is linked to a livecode
supplied script that tries to "set the text of me to empty"
in 1.7 for LiveCode here http://qery.us/za
On 9 feb 2012, at 02:13, Richard Gaskin wrote:
> 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 syste
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 sett
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 cons
Thanks Craig,
Your thoughts on this are much appreciated. Darn right about the dangers!
Gregory
On Mon, Sep 12, 2011, at 1:00 PM, use-livecode-requ...@lists.runrev.com wrote:
> Gregory.
>
>
> Glad to see you have worked it out. It is a subtle danger, that other
> messages can insinuate the
Thanks Bob,
Another good tip to add to my notebook! Unintended re-initialization can bring
disastrous consequences. This, I have discovered. Sigh.
Gregory
On Mon, Sep 12, 2011, at 1:00 PM, use-livecode-requ...@lists.runrev.com wrote:
> One of the things I do to prevent re-initialization
The substacks had PreOpenStack handlers that called a library stack and
> sometimes emptied out some fields, but what they did not have OpenStack
> handlers. The absence of OpenStack handlers appears to have been the problem
> because, after the the sub-stack executes its own PreOpenS
ges.
Craig Newman
-Original Message-
From: Gregory Lypny
To: use-livecode
Sent: Sun, Sep 11, 2011 10:44 am
Subject: Re: Question About PreOpenStack
Hi Craig,
I had posted this right (see below) after you in message 21. On reflection,
the
behaviour makes sense, and so does Mark
Hi Craig,
I had posted this right (see below) after you in message 21. On reflection,
the behaviour makes sense, and so does Mark’s suggestion that I move the main
stack’s OpenStack handler to the card script.
Gregory
> Hi Mark and Jacqueline,
>
> The substacks had PreOpenStack
Good stuff. Thank you, Mark. I’ll give that a shot.
Regards,
Gregory
On Sun, Sep 11, 2011, at 1:00 PM, use-livecode-requ...@lists.runrev.com wrote:
> Hi Gregory,
>
> Instead of putting an openStack handler in every substack, it is much easier
> to move the openStack in your main stack from
cqueline,
>
> The substacks had PreOpenStack handlers that called a library stack and
> sometimes emptied out some fields, but what they did not have OpenStack
> handlers. The absence of OpenStack handlers appears to have been the problem
> because, after the the sub-stack execut
Hi Mark and Jacqueline,
The substacks had PreOpenStack handlers that called a library stack and
sometimes emptied out some fields, but what they did not have OpenStack
handlers. The absence of OpenStack handlers appears to have been the problem
because, after the the sub-stack executes its
Mark.
I assumed, as Jacque did, that there was a preOpenStack handler in the stack
script of the subStack. It was a long shot that there was a line passing that
message.
Also, as Jacque is typically wont to point out, and I did not know this,
subsequent navigation and returning within that
On 9/9/11 10:53 PM, Mark Wieder wrote:
I went back and read the original posting. It's not clear to me that
the preOpenStack handler in the substack isn't firing, just that the
preOpenStack handler in the mainstack *is* firing.
I could be misremembering, as they say. Gregory
Jacque-
Friday, September 9, 2011, 7:24:40 PM, you wrote:
> There has been some good info about how to block a preOpenStack handler
> from falling through to the mainstack, but I'm not sure that was the
> question. Gregory will have to verify, but as I understood it, he
There has been some good info about how to block a preOpenStack handler
from falling through to the mainstack, but I'm not sure that was the
question. Gregory will have to verify, but as I understood it, he has a
valid preOpenStack handler in a substack but it isn't executing.
Instea
Really?? I was under the impression that preOpenStack would not fire from the
first card because the stack was not open yet. You learn something new every
day!
Bob
On Sep 9, 2011, at 12:09 PM, Scott Rossi wrote:
> 3) move your preOpenStack handlers from the script of your mainstack into
&g
The other way of handling this is to have a mainstack that is really just a
splash stack + library, it doesn't even have to show itself on startup (put "on
preopenstack; hide this stack; end preopenstack" into the script of card 1 of
the mainstack). Then put whatever you want f
I always put empty preopenstack, openstack, preopencard,
and opencard handlers for my substacks. I also put in a closestack handler
in the substack that tells the substack to close. This seems like it should
just be a standard thing to do when making substacks. This will prevent any
stray messages
On 9/9/11 2:09 PM, Scott Rossi wrote:
Recently, Gregory Lypny wrote:
I have a main stack with a PreOpenStack handler and sub-stacks with
PreOpenStack handlers. Why is it that when I click a Go button in the main
stack that opens a sub-stack, the PreOpenStack handler in the main stack is
Scott-
Friday, September 9, 2011, 12:09:57 PM, you wrote:
> 3) move your preOpenStack handlers from the script of your mainstack into
> the card script of the first card of your mainstack
Indeed, the documentation states that the preOpenStack message is
"sent to the destination ca
Recently, Gregory Lypny wrote:
> I have a main stack with a PreOpenStack handler and sub-stacks with
> PreOpenStack handlers. Why is it that when I click a Go button in the main
> stack that opens a sub-stack, the PreOpenStack handler in the main stack is
> executed?
Messages fr
e the clipboard of your computer over a local network with Clipboard Link
http://clipboardlink.economy-x-talk.com
Op 9 sep. 2011 om 20:32 heeft Gregory Lypny het
volgende geschreven:
> I have a main stack with a PreOpenStack handler and sub-stacks with
> PreOpenStack handlers. Why is it
Hi.
I don't see this. I made a main stack and a substack. When I open the subStack
from the mainStack, I only get an answer from the preOpenstack handler in the
subStack stack script.
I only get an answer from the PreOpenstack handler in the mainStack stack
script.
You are not pa
I have a main stack with a PreOpenStack handler and sub-stacks with
PreOpenStack handlers. Why is it that when I click a Go button in the main
stack that opens a sub-stack, the PreOpenStack handler in the main stack is
executed?
Gregory
___
use
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 sub
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
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 h
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 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 s
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.
R
Unrelated to the other preOpenStack problem reported in 4.5.1 earlier by
someone else
I have a preOpenStack script with breakpoints in it. But the breakpoints
never cause the script editor to come forward. If I put an answer
"preOpenStack" line in the script the dialog will come u
Maybe it's me or should this not be happening. Livecode 4.5.1.
I have a mainstack that has a preOpenStack that does some house keeping...
I just added a substack that is opened from the mainstack by a user clicking
a button.
**There is NO preOpenStack in the substack
When the substack
77 matches
Mail list logo
