Hi Lars,
Since the script of any main stack is inserted in the message path,
you have many possibilities:
1. Put your code into the script of a card (handy when the main stack
has one card only).
2. Use groups (variant of the above).
3. Act accordingly to the calling object in your main stack handlers:
on preOpenstack
if the long ID of me <> the long ID of this stack then pass
preOpenstack
<statements for your main stack>
end preOpenStack
Use the same process for other system messages as openCard,
closeStack, etc.
Hope this helps.
Le 30 août 05 à 13:35, Lars Brehmer a écrit :
I have a problem with a preOpenCard handler in the stack script of
the main stack of a huge project, that I never had before. I've
totally redone a ton of things in the last 3 days, but I didn't
think any of these changes would change the general working of
it , yet something keeps cropping up that I haven't seen before
don't understand. I have managed to fix it in almost every case
but 2, which are kind of important. Maybe someone has the solution
for me ;-)
Here goes:
In my main stack there is a preOpenCard handler. Now, every time
one of my many subStacks is opened, the preOpenCard handler of the
main stack tries to run, and since it involves objects unique to
that stack, and the handler is trying to perform itself in the
subStack, I get an error, something like "oject doesn't exist, "
which is logical. In almost every case of this occurance, I solved
it by putting a "lock messages" in the handler in question before
the substack is opened. This works of course but when I just
double click on a stack in the application browser to open it, the
error of course still happens since messages are not locked. I can
live with that, as long as the stanalone functions correctly. One
problem though - some of the handlers in question call for a
substack to be paletted, and just locking messages before the
palette command doesn't prevent the error. This one I can't live
with, because these substacks open as palettes in front of other
stacks, and I don't the palette stack to disappear to the back when
you click on one of the stacks behind it. Now, before I made the
changes, the main stack had a preOpenCard handler, very much like
the new one, and it never tried to run as other stacks were
opened. Since my changes weren't all that drastic, I guess my
question is - what is it about main stack scripts that I don't
understand? Most of my subStacks have always had preOpenCard
handlers in their stack scripts, and they have never tried to run
at the wrong time. Only the main stack script does this.
What is different about main stack scripts? And if the lock
messages prevent it, why doesn't that work for a paletted substack?
Best Regards from Paris,
Eric Chatonet.
----------------------------------------------------------------
So Smart Software
For institutions, companies and associations
Built-to-order applications: management, multimedia, internet, etc.
Windows, Mac OS and Linux... With the French touch
Free plugins and tutorials on my website
----------------------------------------------------------------
Web site http://www.sosmartsoftware.com/
Email [EMAIL PROTECTED]/
Phone 33 (0)1 43 31 77 62
Mobile 33 (0)6 20 74 50 86
----------------------------------------------------------------
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
