Thanks for the suggestions everyone. Here's where I'm at.
Craig:
I moved the code to openCard, still the same problem.
Mike:
wait zero didn't fix it, nor did send in time with full path.
Mark:
Restructuring the code does, of course, work and is probably going to have
to be my workaround. The
There's a lot of stuff that doesn't work on preopenstack if your stack is the
premier mainstack of a standalone. This includes liburl, all externals, url
(files too), and some other things.
Just now someone couldn't speed up a complex object creation with lock
screen, so it seems that doesn't
Hi Björnke,
Am 20.03.2013 um 17:59 schrieb Björnke von Gierke b...@mac.com:
There's a lot of stuff that doesn't work on preopenstack if your stack is the
premier mainstack of a standalone. This includes liburl, all externals, url
(files too), and some other things.
but this is caused by
Hi Bjornke,
Yes, I've run into some of those issues with rev libraries and found that
shifting them to openCard fixed those issues. I must have missed the post
about the lock screen issue, but I've had that same issue too.
This is a new type of problem though, at least to me. No libraries or
Peter Haworth pete@... writes:
I guess I'm just very suspicious of anything other than really
straightforward commands in preOpenCard now.
Well, here's the thing. It's *pre*OpenCard because the card and its controls
haven't been instantiated yet. So sending a message to a control that doesn't
I set the visible of a stack to false, and put this in the stack script:
on opencard
send set the visible of me to true to me in 5 seconds
end opencard
I didn't try it in a standalone, but opening that in the dev environment
resulted in no visible change for 5 seconds, then the stack
OK, that makes sense, but how come I can set the text of option menus,
fields, etc without a problem if they don't exist yet? More to the point,
why isn't there some sort of runtime error if I try to address a control
that doesn't exist yet (Monte?)? That's what I mean about preOpenCard
being
Thanks Geoff. I had thought about moving things into openCard. I already
found I had to move some code that used libURLxxx from preOpenCard to
openCard because of the library not being loaded. Didn't think of the
visible part of it though, thanks for the idea.
Pete
lcSQL Software
Maybe I'm missing a subtlety of Mark's reply, but unless an object is
being created dynamically, it should be configurable during preOpenCard.
The whole reason for the preOpenCard message in the first place is to be
able to initialize/format stuff on the card before showing it. Now if a
control
Hi Scott,
That's my confusion too. I have several places where I adjust the
content/appearance of controls on the card and that all works fine, only
sending a message to a control seems to cause a problem.
It seems like the stack is in some partial state of initialization during
preOpenCard
--no handler anywhere
answer it
end mouseUp
yields unhandled. As it should.
Craig
-Original Message-
From: Scott Rossi sc...@tactilemedia.com
To: LiveCode Mail List use-livecode@lists.runrev.com
Sent: Wed, Mar 20, 2013 3:12 pm
Subject: Re: Sending mouseUp
Maybe I'm missing
, but it seems to
matter when and how it is invoked as well.
Craig
-Original Message-
From: Peter Haworth p...@lcsql.com
To: How to use LiveCode use-livecode@lists.runrev.com
Sent: Wed, Mar 20, 2013 3:09 pm
Subject: Re: Sending mouseUp
Thanks Geoff. I had thought about moving things
Hi Craig,
You're right that the button wasn't fully qualified initially, but no error
was thrown. That's another problem I've come across in preOpenCard - often
errors just don't get thrown. Plus red dot break points don't trigger
(although a breakpoint command does).
All in all, preOpenCard is
Out of curiosity I created a simple stack with one card and four buttons named
Button 1 though Button 4, each button just had the script;
on mouseUp
answer the short name of me
end mouseUp
then I put the following in the stack script;
on preOpenStack
testMessage1
end preOpenStack
on
Yep, that's my experience too. Don't remember all the combinations I tried
but here's the one that really surprised.
1. Ran LC and opened my stack from within it. Got the mouseUp problem.
2. Closed the stack and opened it again from within LC. All worked OK.
3. Closed the stack and removed it
, loading the short names somewhere
without any answer stuff?
Craig
-Original Message-
From: Paul Hibbert l...@pbh.on-rev.com
To: How to use LiveCode use-livecode@lists.runrev.com
Sent: Wed, Mar 20, 2013 5:06 pm
Subject: Re: Sending mouseUp
Out of curiosity I created a simple stack with one
Do you pass the messages as well in your problem stack? i.e. pass preOpenCard,
etc.
The IDE is dealing with a lot of things that a standalone isn't dealing with.
Just a thought,
Tom
-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com
On Mar 20, 2013, at 5:07 PM, Peter Haworth
Hi Tom,
I've changed my scripts so much that I'm not sure of the answer to that.
Good point though - I'll see if I can find a backup copy of the stack from
before I started changing it all around.
The dictionary seems to indicate it doesn't matter whether you pass
preOpenCard or not, at least in
names somewhere without any answer stuff?
Craig
-Original Message-
From: Paul Hibbert l...@pbh.on-rev.com
To: How to use LiveCode use-livecode@lists.runrev.com
Sent: Wed, Mar 20, 2013 5:06 pm
Subject: Re: Sending mouseUp
Out of curiosity I created a simple stack with one
Peter:
You may be done with this whole issue, but one thing you might try is
verifying that your stack is actually removed from memory before testing
as you describe. If the stack you're closing has a substack that doesn't
get closed, or there's some handler, pending message or other event
Thanks Scott, good thought. Not about checking openStacks, the bit about
nuking the entire site :-)
Pete
lcSQL Software http://www.lcsql.com
On Wed, Mar 20, 2013 at 2:29 PM, Scott Rossi sc...@tactilemedia.com wrote:
Peter:
You may be done with this whole issue, but one thing you might try
You might try hard pathing the send. If there is a context issue going on
that should solve it, and during preopencard I would wonder if the context
is incorrect when the send is done. so dispatch or send it to button
whatever card whatever of stack whatever to test and eliminate the
possibility.
Hi Mike,
Good thinking, I had not included the card and stack in the path to the
button. However, I changed that and still no joy.
What's really strange is that it contains handled after a dispatch to
the button, yet its clear the message is never making it that far.
I've narrowed this down a
Hmm might try the combination of the 2 things then. Do a send in time with
absolute pathing. Also i've noticed recently that inserting a wait 0 with
messages prior to where a problem like this occurs sometimes magically
fixes it. Its as if there is other housekeeping/engine stuff going on that
?
Craig Newman
-Original Message-
From: Mike Bonner bonnm...@gmail.com
To: How to use LiveCode use-livecode@lists.runrev.com
Sent: Tue, Mar 19, 2013 9:27 pm
Subject: Re: Sending mouseUp
Hmm might try the combination of the 2 things then. Do a send in time with
absolute pathing. Also i've
Pete-
Tuesday, March 19, 2013, 6:47:33 PM, Craig wrote:
Something like this has come up before. I remember that
preOpenCard is invoked before the card (and the stack?) is even
loaded into memory. I think. So there may be no valid target handler
yet available to access. Why the handled value
26 matches
Mail list logo