question about mainStack scripts

[Eric Chatonet]

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        eric.chatonet at sosmartsoftware.com/
Phone        33 (0)1 43 31 77 62
Mobile        33 (0)6 20 74 50 86
----------------------------------------------------------------