Image gallery with thumbnails

21

nex,

nothing in flash will round by itself except pixel positions (_x,_y). there are probably more exceptions which i’ve missed here but generally that’s true. i guess the positions round for rendering reasons, i’m not sure. the guys at macromedia could give you a better answer.

xx needs to be initialised at the clips _x value because when you move the clip you go xx += amountToMove; _x = xx; so if xx is initialised at a value other than the clips _x, the first time it moves it will jump to whatever xx + amountTomove is.

this._parent, when called from one of the clips, will refer to whatever clip they’re in. if you’ve put all this code into _root and run it, that will be _root. otherwise wherever the code was run from.

lock and frontPic are variables. they could have just as easily been named punch and judy, but that wouldn’t have made as much sense. frontPic is set to equal whichever pic is in the front, lock is set true when pics are moving, and false when they’re not. it’s to prevent two pics from trying to move to the front at once.

if(!this._parent.lock) means if this._parent.lock is false.

so it it’s false we run the if block, else we skip it.

this._parent.lock = 1; is setting the aforementioned lock variable to true, that’s why changing it to whatever didn’t make a difference. you correctly surmised that changing it to 0 would have made a difference. setting it to false, null, undefined or (1==2) would have the same effect - they all evaluate to false. it’s a coding convention to use 1 and 0 as true and false.

if you look further down in the code, you can see where lock is set back to 0 to re-enable the clicks.

frontPic is a variable that holds a reference to whatever clip is in front. if the clip is in front we want it to go the back right? not the front. so we have to check and see if it’s in front. in actionscriptese it looks like:
if(this._parent.frontPic == this){

also if we’re bringing a clip up from the back we need to return the front clip to the back. how do we know which clip is in front? well, we know because we stored a reference to it in frontClip. if we’re only moving the front clip to the back, there will be no clip out front, so we set frontClip to null.

your summary at the end there is right on the money, that’s exactly what it does. i hope the purpose of the lock variable is clearer now.

anyone who thinks this is a hopeless cause has a very dim world view! ; )

keep hacking, it gets easier with practice.

22

thanks nex…

the only reason I asked, is I have the feeling that this client is going to want to redo his stuff in MX, due to the much smaller file size (this was done w/Generator and Flash 4)…

Thanks sbeener, your code will come in handy (I will have to modify it a bit, but it is so clean!), when and if he decides to go forward with his revamp…

Rev:elderly:

23

things are gettin clearer, lol, i can say that much.i never really figured it would have been this…involved, but its good for my brain, lol. i hope you dont mind answering all my ■■■■ questions, lol :slight_smile:

I understand that the following two functions are what happen when you click on a clip…depending on whether it is in the front or the back. However, i don’t understand what they are doing. i gather that the swapdeaths is what allows the newly sized clip to be seen.also i notice the code involving the current x and y positions and the scale, however i dont know much else…there’s very little code for all that i know it must do!!!

MovieClip.prototype.toFront = function(){
if(this._parent.frontPic) this._parent.frontPic.toBack();
this._parent.frontPic = this;
this.getDis(this._parent.bigx,this._parent.bigy,this._parent.bigs);
this.swapDepths(this._parent.topLevel);
this.onEnterFrame = transform;
}

MovieClip.prototype.toBack = function(){
this.getDis(this.smlx,this._parent.smly,this._parent.smls);
this.onEnterFrame = transform;
}