DHTML Puzzle Problems :-(

Topic

New Reply

I am trying to get this to work

http://www.5ylac.s5.com/puzzle/

I copied the code from

http://www.webreference.com/dhtml/column8/

but theres work s and mine doesnt

want am i doing wrong ?

Filmmaker, gentleman and pearls before swine fan

http://WWW.5YLAC.S5.COM

Reply | Quote

Replies

This is complicated! What about it doesn’t work?

(I did find one piece that “locked in” to position and couldn’t be moved. Not sure if that is good or bad.)

By the way, you make a URL live here with before and after. Like this: http://www.5ylac.s5.com/puzzle/%5B/url%5D.

Reply | Quote

This is complicated! What about it doesn’t work?

(I did find one piece that “locked in” to position and couldn’t be moved. Not sure if that is good or bad.)

By the way, you make a URL live here with before and after. Like this: http://www.5ylac.s5.com/puzzle/%5B/url%5D.

Reply | Quote

Okay, I have a problem. Where are the other nine pieces?

Reply | Quote

Okay, I have a problem. Where are the other nine pieces?

Reply | Quote

This is some interesting script. I’ve never used rectangular clipping before, and it gives me some ideas for how to “reveal” a photo on an album page… but back to your puzzle.

I redid the puzzle and this time 6 pieces were “missing.” Using the IE5 developer accessories’ Document Tree, I determined that the “top” of one of the missing pieces was at -207 pixels, which obviously is hard to see on a normal monitor. This suggests that there’s a problem with the “randomizer” routine which breaks up the puzzle and plops the pieces all over the screen. Thinking it might help to maximize the screen, I refreshed it again and, without trying to solve it, checked the first few pieces. #3 had a top position of -110 pixels. Okay, we have a math problem.

Because the JPG file is taller than the area of the viewable browser window, the normally expected “end-of-range” value for the randomizing process is negative (at least on my display; your display may differ). The function that generates the top position of the piece uses this code:

temp = parseInt((Math.random() * (to-from)) + (from));

Because to is a negative number, this can return a value that is offscreen. You might edit the expression that creates the to value:

endT = (startT + document.body.offsetHeight) – puzzHeight;

(Earlier in our story, we set puzzHeight to the height of the JPG being solved:
puzzHeight = document.images[“imOrig”].height;
)[/list]Now, I don’t really understand this offsetHeight property. The following diagram from MSDN is the best thing I’ve seen that shows what it means in relation to other “heights”:

While body.offsetHeight isn’t listed, I assume it’s the full vertical area of white and light blue. So… that seems correct. This means that something needs to be added to the document itself to ensure that the body element has a height greater than the height of the JPG.

Upon further study, it appears that the grid.gif should be made to match the size of the JPG. This possibly could be done in script by setting its width and height attributes, but this would have to be done early enough that the offsetHeight of the body was calculated correctly. Otherwise, of course, it could be done by creating a new grid.gif that fit your JPG. [After testing] Well, that didn’t seem to work. Maybe ask the script’s authors what they suggest.

Reply | Quote

This is some interesting script. I’ve never used rectangular clipping before, and it gives me some ideas for how to “reveal” a photo on an album page… but back to your puzzle.

I redid the puzzle and this time 6 pieces were “missing.” Using the IE5 developer accessories’ Document Tree, I determined that the “top” of one of the missing pieces was at -207 pixels, which obviously is hard to see on a normal monitor. This suggests that there’s a problem with the “randomizer” routine which breaks up the puzzle and plops the pieces all over the screen. Thinking it might help to maximize the screen, I refreshed it again and, without trying to solve it, checked the first few pieces. #3 had a top position of -110 pixels. Okay, we have a math problem.

Because the JPG file is taller than the area of the viewable browser window, the normally expected “end-of-range” value for the randomizing process is negative (at least on my display; your display may differ). The function that generates the top position of the piece uses this code:

temp = parseInt((Math.random() * (to-from)) + (from));

Because to is a negative number, this can return a value that is offscreen. You might edit the expression that creates the to value:

endT = (startT + document.body.offsetHeight) – puzzHeight;

(Earlier in our story, we set puzzHeight to the height of the JPG being solved:
puzzHeight = document.images[“imOrig”].height;
)[/list]Now, I don’t really understand this offsetHeight property. The following diagram from MSDN is the best thing I’ve seen that shows what it means in relation to other “heights”:

While body.offsetHeight isn’t listed, I assume it’s the full vertical area of white and light blue. So… that seems correct. This means that something needs to be added to the document itself to ensure that the body element has a height greater than the height of the JPG.

Upon further study, it appears that the grid.gif should be made to match the size of the JPG. This possibly could be done in script by setting its width and height attributes, but this would have to be done early enough that the offsetHeight of the body was calculated correctly. Otherwise, of course, it could be done by creating a new grid.gif that fit your JPG. [After testing] Well, that didn’t seem to work. Maybe ask the script’s authors what they suggest.

Reply | Quote