Using ThrowProps in multiple classes?

[Big Bad Roo]

Gidday

 

I have my iPhone app screens each set up with a controller that instantiates a screen view eg Home, Screen 2 etc

 

Currently I have the ThrowProps example set up in each of these screen controllers - so each has mouseDownHandler, mouseUpHandler etc

 

I'm guessing this isn't they way you intended it to be used - is it possible to set it up so that you have one copy of the mousehandler functions in a class, and can feed that class' blitmask a movieclip from anywhere in your project for scrolling?

 

If so, any hints on how to set this up?

 

Cheers!

 

[GreenSock]

I had a difficult time understanding the question. You could certainly create a wrapper class of sorts that handles setting up the mouse handlers, velocity tracking, BlitMask setup, etc. and then just feed it a MovieClip and let it do its magic. Is that what you're asking? 

[Big Bad Roo]

Yeah - so that I'm not repeating the same scrolling code in all the screen controller classes.

[Big Bad Roo]

Working on it now.

 

Would it need to be instantiated in each class you use it in? Or is there another way that would be better to aim at?

 

The way I've got it now, my parent class is instantiating it like:

 

_scroll = new Scroll( mc, bounds, parentUI );

 

...where parent UI would be use, for example, in the mouseDownHandler like...

 

yOffset = _parentUI.mouseY - mc.y;

 

 

Problem with that is, the scroll class can only take that UI.

 

I'm still new to working with classes. I'll try a wildcard in the scroll classes constructor - see if it will accept parent UI. I'd still have to import all the UI classes into the scroll class, but that's still better than having to copy all the scroll code for every class that uses it.

[Big Bad Roo]

OK - the wildcard seems to do the trick in the constructor:

 

public function Scroll( _mc:Sprite, _bounds:Rectangle, _parentMC:* )
 

It's working the same as using just the ThrowProps demo code now. Not sure if it's bad practice passing a whole UI into the constructor, but it doesn't seem to trip up.