Granting permissions, taking controls and child prims in attachments

I have two scripts in an attachment which request permission to take controls. At the moment they're both in the same object - the root prim of the attachment. Everything works until one of the scripts releases controls. When this happens, the control() event handlers for both scripts stop working.

To get around this, I thought I might place each script requiring controls in their own child prims. This works, but now I have a new problem: both scripts request permission to take control when activated, even though they're in an attachment. Previously they didn't do this. It was my understanding that avatars automatically granted certain permissions to scripts in an attachment. Does this not apply when the script is in a child prim, and if so, is there a way to work around this restriction?

Automatically granting controls means you don't haev to request them

if you request permission it's going to ask for it

That isn't so.

It's good scripting habit to have your script request permissions even though your application would put the script in the position of automatic granting of permissions. When it asks under those conditions, the user will not see any confirmation box.

As for the original question, as far as I know, only the root prim gets automatic permissions on an attachment.

My suggestion is to have three scripts, where the third is the one that grabs the controls, then via link messages passes the control commands to the other scrips, which can act on or ignore the input as nessesary.

Jillian has the right idea - thanks! This does what I want. Unfortunately, it's slow as all get-out. I found passing control() events via link messages introduced a lot of delay in processing those messages. I suspect the delay is in the packaging, though. Throwing the key and two integers into a string, then undoing that on the other side via a llParseString2List() probably isn't the speediest way to handle it. Even now I'm thinking of other ways to set this up - I'll probably come up with a better solution in the shower tomorrow morning while waking up.

I did come up with an alternative for now, although it's not as clever. Instead of passing all the messages around, I simply introduced a boolean into each control() handler that enables/disables processing of any events passed to them. This appears to achieve the same effect, although I'm sure there's another pitfall I haven't learned about yet with this method. On the plus side, it requires less code rewriting.

Link messages let you:

1) Target the specific prim you're after. So you could send the relevant message to ONLY the relevant child prim.
2) Include a key, a string and an integer by default, and unpack them quickly at the other end. So you could send the key in the key field, one integer in the integer field and the other typecast to string and back in the other field is almost certainly faster than coding and decoding from lists.

Boolean coding is easy though, and ought to do the job I guess.

As a btw, not recoding it sounds like a timesaver, but rarely works out that way in my experience.