PDA

View Full Version : [DHTML] Swiss Army Interactive Image slide show



jscheuer1
12-21-2006, 04:39 AM
1) CODE TITLE: Swiss Army Interactive Image slide show

2) AUTHOR NAME/NOTES: An update by jscheuer1

3) DESCRIPTION: This is realy just an OO update to:

Interactive image slideshow with text description (http://www.dynamicdrive.com/dynamicindex14/interslide.htm)

But, it has many more options:

Top or bottom controls
Starts running or stopped or in a manual only mode
Easily adapts to images instead of buttons for controls
Descriptions and image counts are optional
Optionally linked with optional global and/or individual targets per show's links, as well as optional global and/or individual specifications for new windows.
Optional mouse over pause
Can graceful accommodate differing image sizes if optional width and/or height settings are configured properly to largest width and/or height of images. (this option isn't completely graceful in IE with the IE fade option for some reason, hopefully this can be overcome)
It can Fade in IE 6+

A simple two parameter call:


new inter_slide(image_array_name, interval)

on the page will place a show there. All other options have defaults, so may be skipped. The demo has three shows on it. The first is with the defaults + IE fading only. The other two show off most of the rest of the options.

4) URL TO CODE:

http://home.comcast.net/~jscheuer1/side/files/interactive_slide_oo_opcity_hvr.htm

ddadmin
12-21-2006, 07:21 AM
Ooh now this looks nice! I was going to rewrite the Interactive image slideshow very soon due to it being completely outdated, but I guess there's no point now.

Looking at the script, I can see how some of the exposed properties may be a little confusing to newbies, ie:


slides2.desc_prefix='<b>Description:<\/b> '; //string prefix for image descriptions display
slides2.controls_top=1; //use for top controls
slides2.counter=1; //use to show image count
slides2.no_auto=1; //use to make show completely user operated (no play button, starts in stopped mode)
slides2.use_alt=1; //use for descriptions as images alt attributes
slides2.use_title=1; //use for descriptions as images title attributes

Can you briefly describe those that may not be immediately apparent to people that I can post on the script page?

Thanks!

jscheuer1
12-21-2006, 08:28 PM
Well, the:


slides#.

part is just assigning a property to the array object of a particular slideshow. None of them are required. The properties are all commented as to what they do, except for these two:


//Notes: slides#.target will set a target for a slide group, will be overridden by slides#[#][3], if present
//slides#.specs will set new window specifications for a slide group, will be overridden by slides#[#][4], if present

which are described at the end of the configuration area in the above quoted note.

I'm not sure if I can get much clearer than that. Here I've put them all together:


desc_prefix='<b>Description:<\/b> ' //string prefix for image descriptions display
controls_top=1 //use for top controls
counter=1 //use to show image count
width=140 //use to set width of widest image if dimensions vary, may also be set in the call as the 2nd parameter
height=225 //use to set height of tallest image if dimensions vary, may also be set in the call as the 3rd parameter
no_auto=1 //use to make show completely user operated (no play button, starts in stopped mode)
use_alt=1 //use descriptions as the images' alt attributes
use_title=1 //use descriptions as the images' title attributes
nofade=1 //use for no fade-in, fade-out effect for this show
border=2 //set border width for images (number of pixels)
border_color='lightblue' //set border color for images (string) - use color name or hex value with # prefix
border_style='ridge' //set border style for for images (string) - requires border_color be set
no_descriptions=1 //use for no descriptions displayed for this slide show
pause=1 //use for pause onmouseover
image_controls=1 //use images for controls instead of the default buttons
manual_start=1 //start show in manual mode (stopped)
button_highlight='#cccccc' //onmouseover background-color for image buttons (string) (requires image_controls=1) - use color name or hex value with # prefix
target='_new' //will set a target for a slide group, will be overridden by array_name[#][3], if present
specs='width=300, height=250, top=150, left=200, scrollbars, resizable, location' //will set new window specifications for a slide group, will be overridden by array_name[#][4], if present
random=1 //set a random slide sequence on each page load
fadecolor='blue' //set fading images' background color, defaults to white (string) - use color name or hex value with # prefix
no_controls=1 //use for a slide show with no controls
delay=3000 //set miliseconds delay between slides for a given show, may also be set in the call as the last parameter
jumpto=1 //use for added controls to jump to a particular image by its number
no_added_linebreaks=1; //use for no added line breaks in formatting of texts and controls
//use below for customized onclick event for linked images:
onclick="window.open(this.href,this.target,'top=0, left=0, width='+screen.availWidth+', height='+screen.availHeight);return false;"


You could get rid of the //'s and make this into table as a configuration guide. The main point is that folks understand that these are all optional. The slide show will look like the first one on my current demo page without any them (except the iefade, the first one has just that one option). The next most important thing is that each one can be used only with the array name of a show, as mentioned earlier:

array_name.property=value

Literals must be quoted, numbers should not.

Added later:

I'm so close to this thing, that I forgot an important concept that users would need to know. The options that have a value of 1 are boolean. So, not having them is the same as setting them to 0 and, any value other than 0 or false is the same as 1. The one's with string values will default to an empty string if not used, except for the image button's background (highlight) color (only used if using images as controls) which defaults to yellow.

So, in the case of the description prefix (a string), without it set at all, you get just the description, without a prefix. For the specs (string), you get a full new window if none are specified (same as you do with the window.open method).

Edit (12/27/06):
iefade has been replaced with a default cross browser fade adapted from the Ultimate Fade-in Slideshow script. To opt out of fading, use nofade as shown in the updated properties definitions above. This type of fading doesn't have the problem I was having with iefade.

ddadmin
12-21-2006, 11:03 PM
Thanks John, I appreciate the extensive commentary, it would certainly come in handy when I'm constructing the script page. I'm leaning towards creating a table showing all the properties and their function, since inline in the script as is can appear a little daunting for some.

I gather with the last comment that this script is still a work in progress, so I'll only start constructing the script page when it's ready.

jscheuer1
12-27-2006, 06:18 AM
OK, I've updated the demo link from my first post and edited my previous message to reflect added and changed properties. I leaned heavily on the Ultimate Fade-in Slide Show for the updated code but, retained the best of the interactive features like incremental preloading via the onload event attribute of the image tag.

Two neat features, the slideshows can set their own width and height (this can even be used with shows having varying dimensions if the first two images are both the same dimensions and are the highest and widest). The default slide show needs only an array of images with descriptions and a call to this array. No parameters other than the array name and no properties are required. Width and height and delay values can be set in the call or as properties of the array. If set in the call, width and height may be set or omitted as a pair, the delay parameter just has to be the last of 4 or last of 2 parameters (the array name is always the 1st parameter).

I've tested the (expletive deleted) out of this script now but, would like to see others take it through its paces a bit.

Tested in:
IE 4.01 through 7 (includes 5.01, 5.5 and 6 - all in their sp2 versions, if any)
NS's 4, 7.2, and 8.0.1 (both FF and IE modes)
FF 1.5.0.9 and some earlier versions (not tested in FF 2)
Opera 8 and 9.01

Version 4 browsers just get a plain slide show.

The fading works in Opera, FF, NS and IE starting at their respective versions that support opacity of any stripe and will work in recent Safari browsers. The script should work in Safari but, I cannot be certain of that.

djr33
12-27-2006, 06:52 AM
I can test in safari if you want.
(and mac IE5 and FF, too)

jscheuer1
12-28-2006, 07:00 AM
I can test in safari if you want.
(and mac IE5 and FF, too)

You could already have had a look at it in that browser and the others, if you were so inclined.

Twey
12-28-2006, 10:21 AM
Confirmed to work in Konqueror 3.5.5. However:
function inter_slide(){
if(!document.images||arguments.length==0)
return;
var imgs=arguments[0];
var width=null, height=null, delay=null;
if(arguments.length==2)
delay=arguments[1];
else if(arguments.length==3||arguments.length==4)
width=arguments[1], height=arguments[2], delay=arguments[3]? arguments[3] : null;I really don't like the way you've done this. The usual way is to specify the optional arguments formally, then check if they're undefined. This would seem to me to make much more sense semantically.
function inter_slide(imgs, width, height, delay) {
if(!document.images || arguments.length==0)
return;
var width = width || null,
height = height || null,
delay = delay || null;I know it's not quite as flexible as using the arguments collection the way you were, but I think the original would confuse people (heck, it confused me anyway). Of course, it would be better still to have only the necessary arguments passed to the constructor, then set anything else using member functions.
ief=document.body.filters? 'filter:progid:DXImageTransform.Microsoft.alpha(opacity=0);' : typeof document.body.style.opacity=='string'? 'opacity:0;' : 'opacity:0.10;-moz-opacity:0.10;-khtml-opacity:0.10;';
The original Alpha filter should probably work on IE/Mac too.
document.write('<br>')document.write() has a nasty habit of slowing down page loads. By using the DOM, you can avoid document.write(), represent the structure of your document, and cater for different markup languages (XHTML being currently the most prominent) without having to change your code.

But yes, the effect is nice. I wish you'd indent your code :p

jscheuer1
12-28-2006, 01:49 PM
Confirmed to work in Konqueror 3.5.5. However:
function inter_slide(){
if(!document.images||arguments.length==0)
return;
var imgs=arguments[0];
var width=null, height=null, delay=null;
if(argum . . .I really don't like the way you've done this. The usual way is to specify the optional arguments formally, then check if they're undefined. This would seem to me to make much more sense semantically.
function inter_slide(imgs, width, height, delay) {
if(!document.images || arguments.length==0)
return;
var width = width || null,
height = height || null,
delay = delay || null;I know it's not quite as flexible . . .

Yes, not as flexible. And perhaps only confusing to someone who writes scripts and/or who relies on looking at the code instead of following the instructions (as given in the body of the demo):


<script type="text/javascript">
//Notes on Parameters: The only required parameter is the slides_array_name. If Width is used, so must Height.
//Interval is optional too. It is always last, either fourth after Width and Height or second after Slides_array_name.
//Usage: new inter_slide(Slides_array_name, Width, Height, Interval)
new inter_slide(slides)

</script>


The original Alpha filter should probably work on IE/Mac too.
document.write('<br>')document.write() has a nasty habit of slowing down page loads. By using the DOM, you can avoid document.write(), represent the structure of your document, and cater for different markup languages (XHTML being currently the most prominent) without having to change your code.

But yes, the effect is nice. I wish you'd indent your code :p

About the alpha filter - I found that the 'advanced' method for setting it initially worked just fine in IE 5.5 which requires the older method:


if (this.tempobj.filters&&this.tempobj.filters[0]){
if (typeof this.tempobj.filters[0].opacity=="number") //if IE6+
this.tempobj.filters[0].opacity=this.degree
else //else if IE5.5-
this.tempobj.style.filter="alpha(opacity="+this.degree+")"
}

for manipulating it later on in the script. On the other hand, IE 5 wouldn't use either method of setting it initially. This leads me to think that IE Mac would probably be the same as one or the other of these. For anyone inclined to test the theory, the image buttons for next and previous in the third demo show will dim (while the show is in play mode) in IE browsers supporting the older method of both setting and manipulating the alpha filter.

On doc'write - It has been my experience that IE often has problems with the DOM even when done correctly. The demo code takes 3.4 seconds to load for a simulated dial up user (this is not including the images). The connection I tested at was 80% efficiency of the most common dial up speed (v90 I think it is called - 56kb/sec, something like that). I'm not sure how much the DOM would trim off of that. At higher speeds, it is an insignificant amount of time, less than a second. What takes the most time in most slide shows is loading the images. This one only loads as it goes, keeping one step ahead of itself so, that cuts down on the real load-time hog.

About indenting code - I've always found that confusing - both to read and to write. I think it is a matter of personal taste.

Thanks for the Konq test!

Twey
12-28-2006, 08:40 PM
On doc'write - It has been my experience that IE often has problems with the DOM even when done correctly.There are quite a few bugs in its implementation. I don't think any need apply here, though.
The demo code takes 3.4 seconds to load for a simulated dial up user (this is not including the images).The connection speed won't have an effect on the impact of document.write(). Rather, it would be to do with the CPU speed (and resources available to the browser, of course). Also, there are other disadvantages associated with document.write(), mostly those associated with innerHTML: it represents the DOM as a string, requires the code to be changed in order to represent the DOM in a different way (e.g. XHTML), &c.
About the alpha filter - I found that the 'advanced' method for setting it initially worked just fine in IE 5.5 which requires the older method:Whoops, didn't see that. Sorry.
Yes, not as flexible.Hence the use of setter methods for optional parameters, which allows more flexibility than either method.
And perhaps only confusing to someone who writes scripts and/or who relies on looking at the code instead of following the instructionsWell, possibly, but one should always endeavour to write clear code.
About indenting code - I've always found that confusing - both to read and to write. I think it is a matter of personal taste.Really? I've never before come across someone who actually felt that indented code reduced comprehensibility. Odd. As you say, perhaps a matter of personal taste (although one worth acquiring, I would think, due to the extra information available at a glance).
Thanks for the Konq test!Quite welcome :) The fade doesn't work, of course.

jscheuer1
12-29-2006, 03:28 AM
Quite a bit to respond to here, Twey. I think that for the most part I've already stated my view so will leave it at that and agree to disagree. One thing about the code that you may have missed as regards the parameters and setters is that all parameters are also properties of both the array and the instance of the function object. As properties of the array, they can easily be set just after declaring the array. I see this as the preferred method but, for folks who need a very basic implementation, they can use what I like to think of as the 'command line', the call in the body.

Incidentally, I've also included the ability to override some key properties for individual array items. None of this must concern the casual user but, comes in handy when customizing the script in an advanced manner.

There is a hierarchy of precedence for any given parameter/property. The array must be specified. If nothing else is specified, the defaults are used. If something is defined in the call, it overrides the default value. If something is set as a property of the array, it overrides the corresponding parameter (if any and if set) as well as the default value. Finally, if something is set for an individual array item, it overrides all other similar settings made at any of the previous levels but, only for that item.

The only other thing I want to add to the discussion at this point is about indenting code. The reason that I find it confusing is that different folks indent differently. Later edits to code not done by the original author or done when the original author is in a different mood may indent differently than the rest of the code.

I do like to follow some conventions in coding to keep it clearer than it might otherwise be but, have been increasingly abandoning even some of these for shortcut/shorthand methods. I do like, for the most part:


function(){
body of function
}

with a blank line between functions. I do not like curly brackets where none are needed, drives me up a wall for some reason. When I see an opening curly bracket, I think, "This is a condition that requires more than one instruction to respond to or, it is a function or collection of some sort." When these brackets are used unnecessarily, it slows down my reading of the code.

I think this stems from an old ambition of mine to be able read and write machine code - something I probably will never realize. However, with such a relatively simple language as javascript, I don't want to be slowed down by what I see as extra punctuation, indentation or spaces.

When I see something indented, I think, "What is that doing way over there? It belongs here with the code that it is associated with." Same thing with style. Much too much indenting is used with that at times. What could be clearer than:


selector {
property:value;
}

?

Gets down off of his soapbox. :)

Twey
12-29-2006, 12:15 PM
I do not like curly brackets where none are needed, drives me up a wall for some reason. When I see an opening curly bracket, I think, "This is a condition that requires more than one instruction to respond to or, it is a function or collection of some sort." When these brackets are used unnecessarily, it slows down my reading of the code.Agreed.
I think this stems from an old ambition of mine to be able read and write machine codex86? An assembly language is a lot easier to read and can accomplish the same goals, honest :)
However, with such a relatively simple language as javascriptAu contraire. Any language based on the hardware (be it a mnemonic language or raw opcodes) will be intrinsically very simple. Keeping track of the logic behind it can be harder, though.
I don't want to be slowed down by what I see as extra punctuation, indentation or spaces.But when extra information can be garnered from the level of indentation, doesn't it make sense? If I see:
}
}... I have to scroll up through the code, looking at the end of each line, keeping count of how many braces are open for each statement, in order to find what the second brace actually contains. However, in a consistently indented script, no matter what the style, I can look at:
}
}and see that the latter brace has no further levels of nesting, and that everything outside it is in the global scope. I can even find out where it began much more easily, by simply scrolling up and looking for a line that starts in the same column.

jscheuer1
12-29-2006, 04:27 PM
If I see:
}
}... I have to scroll up through the code, looking at the end of each line, keeping count . . . in a consistently indented script, no matter what the style, I can look at:
}
}and see that the latter brace has no further levels of nesting

Emphasis added. Ah, and therein lies the rub. Each and every level of nesting must be consistently indented and very often aren't. Even if it is consistent, that's precious little information. This same sort of information can be yielded by a blank line after all currently relevant open braces are closed. It might be properly indented but, have a different logic than you think without really looking at the rest of the code. Where's the opener for the nested brace? It really should be here (at least relative to the margin):


{
{
}
}

But, often it is at the end of a line of other code that sets the condition or opens the function.

A syntax sensitive editor makes child's play of ferreting out these 'back-traces' in either situation but, with all code indented to the same 0 width left margin, it just looks neater and is easier to follow for me. There is a much greater chance that all lines will be visible even in a narrow editor window without wrapping and the flow of the code seems more fluid without all that indenting. This also relates to my distaste for needless curly brackets. When you combine that with indented nesting, you get needless indentations, which just compounds the problem.

For me it may be a matter of trust. I don't trust anyone to write their code in a manner that will be easier for me to read than is yielded by one instruction/test per line and, many coders don't even keep it that simple. If I see nesting indents I think, "This may be an indication of the flow of the code or, it may not be."

As I said at the outset, to each their own - it is a matter of personal preference. Mine is tending toward even more 'obscure' code, for example - I now prefer:


iss[this.issid=iss.length]=this;

to:


iss[iss.length]=this;
this.issid=iss.length-1;

But, there was a time when I would have viewed the former as too obscure.

Twey
12-30-2006, 12:27 AM
Each and every level of nesting must be consistently indented and very often aren't.If you've written it, you can be reasonably sure that they will be :)
This also relates to my distaste for needless curly brackets. When you combine that with indented nesting, you get needless indentations, which just compounds the problem.There are two styles for this too: same line
if(condition) statement;and indented:
if(condition)
statement;I prefer the former, which seems to read more logically (as we do indeed say in English, "if condition statement") but there is the problem of longer lines, which the latter solves.
But, often it is at the end of a line of other code that sets the condition or opens the function.Yes, there are two styles, sometimes called Java-like and C-like, after the languages in which they are/were predominant. Java-like block statements look like:
keyword {
code;
}... whereas C-like block statements look like:
keyword
{
code;
}Personally, I favour the former for sheer brevity. With either style, all one must do to locate a matching brace is look up or down the column until one hits some code.
Mine is tending toward even more 'obscure' code, for example - I now prefer:
iss[this.issid=iss.length]=this;to:
iss[iss.length]=this; this.issid=iss.length-1;Ah, yes. I must try to keep this tendency in check: I have a habit of cramming as much into one statement as I can, which is all very fine and good, but especially in Python, I find myself compressing
def containsGreaterThanFive(mylist):
for x in mylist:
if x > 4:
print "yes"
return
print "no"into
def containsGreaterThanFive(mylist):
print (len([x for x in mylist if x > 4]) > 0 and "yes" or "no")There were worse examples (one particular statement took up five lines in my editor) but none I can recall from memory.

ddadmin
12-30-2006, 01:48 AM
One advantage of using document.write() I find is that you don't have to wait for the entire document to have loaded before you can invoke and start working with the output. Going through the DOM (ie: appendChild()) requires that extra step of checking and waiting for the body onload event before proceeding.

Regarding indenting, firstly, I'm sure everyone knows I belong to the same camp as John's :) I haven't indented mainly due to laziness, and that when I do, I find it quite time consuming keeping track of all the various levels of containerships, plus the extra bytes it adds to the script. Lately I have began making an effort to be considerate to people who may study the source, by commenting and using blank lines to separate various methods of, say, a custom object. I may start indenting next, you never know. :)

Back to the original topic, I don't have access to a Mac unfortunately, so can't test the script out in that platform. But whenever you think it's ready John, I can put it up.

Thanks,

jscheuer1
12-30-2006, 06:16 AM
I will update for Safari if I can get a reliable test in that browser and there are any correctable issues. I've updated the properties post and the demo and have added another demo. The script is now external:

http://home.comcast.net/~jscheuer1/side/files/sai_ss.js

The two demos are now:

http://home.comcast.net/~jscheuer1/side/files/interactive_slide_oo_opcity_hvr.htm

and:

http://home.comcast.net/~jscheuer1/side/files/iss_ext.htm

As far as I am concerned, you can put it up.

djr33
12-30-2006, 06:26 AM
I say indendation is crucial for long scripts, but fine if not present for short bits.
Certainly it's nice, as twey said, to be able to see the root level by having at least the overall brackets at the right spot, with everything else indented a bit.

jscheuer1
12-31-2006, 05:45 AM
Well, I know I said this was ready, and it was. However I just added some capabilities. Just one for the array properties and I've updated that post to reflect the addition (border_style). I've also added a way to override for individual images the background color, and a way for individual images to have no border, even if one is set for images using the array properties.

I did this because I was playing with the script and the second demo, comparing it to the way these images are displayed on the site that has given permission for their inclusion in the demo. Then I got a little creative as well. There is very little added code to the script itself and these overrides can remain undocumented for simplicity's sake on the demo page.

jscheuer1
01-01-2007, 09:56 AM
News Flash!! A major minor bug has surfaced in dial-up simulations. The text can get ahead of the images in certain cases. I think the fix will be to populate the text along with the images into the rotating canvasses but, need to work out the details.

Please hold off posting the script to the DD library until I can get this ironed out.

djr33
01-02-2007, 10:40 PM
You could already have had a look at it in that browser and the others, if you were so inclined.
I've been away and just had my laptop (windows) available.

Now that I'm back to my mac, here ya go:

Safari seems just fine. No problems I can see. Tested all examples on all pages (quickly, but, I think, thoroughly).
Anything particular I should look for?

Firefox (mac) is fine. No surprise there.

IE 5 mac has big issues. The controls for the most part work. Hitting the stop or next buttons does the right behaviour for the buttons, such as enabling/disabling buttons. However, that's just about it. The images do NOT appear, the image numbers do not appear or change on clicking, the background doesn't change on the second example, and, basically, I just get a large blank white area. What's particularly interesting, though, is that the image number doesn't even show up. That might imply that there's something incompatible with the overall code to set/change the image, rather than displaying the image itself.

No big surprise with IE5mac, either, since it always has javascript issues. :p
But... if you could get that working, probably a good idea, since it's the secondary browser (comes installed) with OSX (and some use it due to familiarity and don't use safari 'cause it looks different), and it's the primary browser with OS9- (though I am testing on OSX at the moment, but I will say that I'd assume the javascript parser is the same, since it's the same version and such, though I can't comment. If anything, OSX would be improved, since it is newer).
(I also remember that back in the days of OS9 I had netscape, but I think that was installed with some program, for the help files, I believe, and didn't come with the system. But that's probably irrelevant, since I can't test anyway. However, would be nice if I could test, since I'm curious if it's just as bad as IE5.)

Twey
01-02-2007, 10:51 PM
IE5 is seriously broken. I don't bother with it any more -- I doubt much of the Web renders properly in it. My own site, for example, uses a very simple layout, not something I'd expect even IE to get wrong, but I took one look at it in IE5 (Win), laughed, and deleted the browser.

djr33
01-03-2007, 06:17 PM
:D

Yeah.... no real dissagreement here. However, if you DO get it to work in IE5, that's a big accomplishment ;)

I figure if it works in IE5 it'll work in anything, so that's a great test. ;)

Twey
01-03-2007, 07:51 PM
If only it were a little more standards-compliant, so we could say that :p

jscheuer1
01-03-2007, 09:47 PM
This script actually works in IE 4 +. In version 4 it is a simple slide slow with no controls, descriptions, fading, etc. In IE 5.01 sp2 under win XP, you get everything except fading. Apparently IE 5 Mac is not com-pitiable (intentional misspelling). Thanks for the Safari test!

djr33
01-04-2007, 06:06 AM
Yeah, IE5 mac is more screwy than PC, I believe. Never tested with IE5 PC. It may have to do with version 5.5 having improvements. (My mac, now having moved into my dorm room, is now sitting on the floor, not setup-- first day was today, or I'd check for sure, but I believe I just have 5.0 and that's the last mac version made. I might be off here, though.)

jscheuer1
01-05-2007, 10:11 PM
I will update for Safari if I can get a reliable test in that browser and there are any correctable issues. I've updated the properties post and the demo and have added another demo. The script is now external:

http://home.comcast.net/~jscheuer1/side/files/sai_ss.js

The two demos are now:

http://home.comcast.net/~jscheuer1/side/files/interactive_slide_oo_opcity_hvr.htm

and:

http://home.comcast.net/~jscheuer1/side/files/iss_ext.htm

As far as I am concerned, you can put it up.


News Flash!! A major minor bug has surfaced in dial-up simulations. The text can get ahead of the images in certain cases. I think the fix will be to populate the text along with the images into the rotating canvasses but, need to work out the details.

Please hold off posting the script to the DD library until I can get this ironed out.

OK, this bug has been annihilated, the script is ready to go. The fix wasn't as simple as I thought due to layout considerations and working on it turned up a more serious bug. All is well now as far as I can see. The script works in IE (win) 4+ (fading starts at v 5.5), NN 4, NS 7.2+ (including most if not all FF's - tested up to 1.5.0.9), Opera 9.0+. djr33 says it works in Safari but not IE 5 Mac. Version 4 browsers just get a simple slide show, no controls, fading, etc.

ddadmin
01-06-2007, 11:06 AM
Awesome, thanks for all the checking. It's probably more than what I do with most scripts :). The next script added should be this one.

ddadmin
01-11-2007, 08:55 AM
Just an update that the script is now posted! http://www.dynamicdrive.com/dynamicindex14/swissarmy/index.htm

jscheuer1
01-12-2007, 02:20 AM
Just an update that the script is now posted! http://www.dynamicdrive.com/dynamicindex14/swissarmy/index.htm

Looking good! I think we will need to beef it up a bit though. I take it that you are still planning on adding the table of available, as you are calling them, 'inline' options from post #3 in this thread as we previously discussed? No rush. Believe me, I know how hard it can be to find time these days (more on that below).

One thing I noticed is that though the image photo9.jpg is now on your server (Mona Lisa), the image used is actually a thumbnail version - photo9_thumb.jpg - which you can snag here:

http://home.comcast.net/~jscheuer1/side/files/photo9_thumb.jpg

or just change it to photo9.jpg in the source code of the demo page, your choice.

Now, I would like to add another demo for this script and some additional text about some of the more advanced features - not to mention a similar text for Omni Slide, as I have previously mentioned. However, I am in the midst of a major home remodeling project and am hard up against one of the busiest times (tax time) of the year for me so, I may be limiting my time for DD and the forums to just whatever I see as 'recreational' until I get through this period of a month or three. I really want to get to these additions though, so I may find a way to squeeze them in sooner, I'll keep you posted.

P.S. I like the custom buttons that you came up with for your version of the image buttons demo.

ddadmin
01-15-2007, 12:59 AM
Hi John:
Yep, I mainly just wanted to get this script out there ASAP, so omitted some things such as the documentation inline on the page. I'll get to that very soon, plus your requests above as well.


However, I am in the midst of a major home remodelling project and am hard up against one of the busiest times (tax time) of the year...

Not a problem at all! We all have lives outside the internet, not to mention DD. You don't need to explain your absence unless you're in some trouble and need my help. :) Good luck with the remodelling, I know it can be a lot of fun. I liken it to playing Legos for grownups :)

borbs
01-22-2007, 03:11 AM
Hi!

Is there a way for me to get ONLY the prev and next buttons working?
I want my slideshow to autostart and the users go forward or back. JUST it.
I don't think that "stop" do go forward is a good idea...

How can I do that?!

Thanx!

jscheuer1
01-22-2007, 03:29 AM
Hi!

Is there a way for me to get ONLY the prev and next buttons working?
I want my slideshow to autostart and the users go forward or back. JUST it.
I don't think that "stop" do go forward is a good idea...

How can I do that?!

Thanx!

Please Post any further communication on this subject in your original thread in the help section.

This script can do many things but, for the user to assume manual control, it must first be stopped. As currently written it cannot be both moving automatically and at the same time be under the control of the user. In fact, I'm not aware of any slide show that can do that.

Please Post any further communication on this subject in your original thread in the help section.

Victor
05-09-2007, 06:01 AM
Thanks John for this script. I've been tried on Safari and IE 6 (XP SP 2).
It works fine on Safari.
With IE, it looks like the browser keeps loading the images forever ...
(my test slides with 6 images of 25 Kb)
Have you seen this ?

Thanks.

jscheuer1
05-09-2007, 02:00 PM
Thanks John for this script. I've been tried on Safari and IE 6 (XP SP 2).
It works fine on Safari.
With IE, it looks like the browser keeps loading the images forever ...
(my test slides with 6 images of 25 Kb)
Have you seen this ?

Thanks.

All further questions on this script should be posted in the main help section:

http://www.dynamicdrive.com/forums/forumdisplay.php?f=2

To answer this question - it probably means one or more of your images is misnamed or missing. For more help, post a new thread in the main help section.

Locking Thread