View Full Version : Arrgg - RollOver in nested MC not working with RollOver on parent MC

06-27-2003, 07:04 PM
Having some trouble on what seems like it should be a simple one.

I am trying to build an animated menu - something almost identical to the launcher menu on OSX - Buuuut....

My problem seems to be getting two RollOver calls to work together.
Here is the structure:

- menu_mc.onRollOver....
//move menu_mc to the right

- menu_mc.button1_mc.onRollOver...
//highlight button1

- menu_mc.button2_mc.onRollOver...
//hightlight button2

When the rollover on menu_mc is disabled the buttons work fine.

I've put a zipped fla file up here if someone would please take a look:

sorry for the long name here.

Thanks to anyone who can help

06-27-2003, 08:19 PM
Hi Birdsong,
Had a quick look, and I closed it rapidly. That's the problem with stuff like this not documented very well. It takes ages to figure out what he has done, especially how he used the path _parent._parent etc. So the best thing I would do if you don't want to start from scratch is look what it is supposed to do (it did work before you adapted it?) and build a small tryout i.e. a button in a clip.
Use the debugger and output lists to see what handlers you have and try to compare this with the code from William James.

A handler on a MC and a handler on a button in that clip should work ok though. But you have to be carefull with pathing, as a small mistake stops it from working all together.
Good luck

06-27-2003, 09:36 PM
I was having trouble with this, sounds related...

When I had a button in a movie, all worked fine.

Then I place that on a new stage and asign onRollover to it so that i can do something if you touch entire movie.

But now the button doesn't work in the original movie clip.

Made this simple example because I ran into this when working on a navigation bar....
run it and see all you can do is stop it, open the movie clip of the dot itself and run that (alt-ctrl-enter) and see it works fine...

06-28-2003, 02:37 PM
mvhall --- LOL! thats my code. I'm WJ. sorry about the documentation. And I thought it was ok. LOL! But I completely see your point. sorry about that. Learning fast.

after checking out your test lowprofile and mvhall's critique, I built a simplified version. And there is definately a conflict when you have two movie clips with overlapping hit areas. Like your test lowprofile, the parent movieclip Roll Over diables child Roll Overs. what can be said except - WTF?

But, I think I found a work around is to put all the Roll Over actions in the child clip. and then pull some stunts with the hit area and visiblity or alpha settings of the child.

- Atomic

06-28-2003, 07:29 PM
Hi Birdsong,
Sorry, I thought you borrowed the code, and then ran into problems. I presumed (wrongly obvious) that you would not have the kind of problems after you have done so much work.
The only problem I distill from your comments is that you have two hotspots on top. Well this does not work as you've realised, so what you suggested is maybe the right way or try something that the parent hotspot makes itself invisible (parameter _visible=0) and then the ones below become active. Maybe you can do something clever to do this after a short timedelay.

I am working on something now that has multiple clips, and in every clip pictures with each an onPress handler.
By only activating one page (read MC) with the _visible parameter I get access to the right handlers. If you need to make the pictures invisible without the handlers being disabled, use the alpha parameter. Maybe this is of any help?


06-28-2003, 08:35 PM
I like the idea of turning one hot spot on and the other off... however, in the example I gave. I don't think you can do that? Because you have an instance of the movie clip itselt. If you make that invisible the whole movie goes away. Then you can't press the button in that movie.

06-28-2003, 08:57 PM
still LOL -

Thank you both for your suggestions. I've also found a couple other work arounds. Certainly nesting the functionality in the child clip works fine. I've also been able to use an onMouseMove with if statements checking active coordinates to elicite the same effect. The thing I don't like about the onMouseMove, is that this, theoretically should run up the processor time, since it is constantly running through an if statement every time the mouse moves. YUCK! A senior member on the MM Flash Forum suggested putting an invisble mc with an onRollOver UNDER the child clips to manage the areas which are not covered by the child clips (this also assumes using my first work around in conjunction).

Thanks again mvhall and lowprofile

mvhall - your idea with hidding the clip, or maybe using mc.enable (true/false)?? to deactivate the functionality could work, although I have not tried any of these yet... On this note though I did read something which might be pertinent (spelling? - sorry). What I read, and again, I am sure there is some senior member can clear this up, the onRollOver treats mc like a button, and when that is done you disable the properties of the mc class???!! If I am getting this right...this means that in my example, when onRollOver is attached to the parent mc it becomes a button and that has functional consequences. What those are I am a little dumb on now. Again - Not sure if this is right and would like to know. When I get around to it I will research it.

Ok - I'm done, I'm getting annoyingly theoretical.

Thanks again.

06-28-2003, 09:56 PM
Hi Birdsong,
Never heard of attaching a handler to an MC disables properties?
Which ones? Are you sure you don't mean converting a MC into a button? Let us know if that is really true, and which properties disappear.

Yep that MC.enable also works but a hotspot you don't see so if you would have more buttons or MC's with handlers in a clip it would disable them all with visible=0 whereas I am not sure the enable does the same.

Going to hit the sack,
Have fun.

06-28-2003, 09:59 PM
Oh yeh btw , that onMouseMove function is to be avoided, especially when you've got an older pc, it slows things noticeably down.