Onmouseover, onmouseout question

Discussion in 'Javascript' started by peashoe, Jan 16, 2007.

  1. peashoe

    peashoe Guest

    I need to create a javascript that not only changes a picture, but also
    the link: here is an example of what I need www.myweddingfavors.com/
    I'm working on this website and have it half done:
    www.mygiftbasketideas.com - I also what the table to change color on
    mouseover - this is the code I am using so far:

    in the script.js
    if (document.images)
    {
    image2= new Image(100,100);
    image2.src="/store/images/P/romance.jpg";
    image3= new Image(100,100);
    image3.src="/store/images/P/welcome_baby_boy.jpg";
    image4= new Image(100,100);
    image4.src="/store/images/P/picnic.jpg";
    image5= new Image(100,100);
    image5.src="/store/images/P/vineyard.jpg";
    image6= new Image(100,100);
    image6.src="/store/images/P/european.jpg";
    image7= new Image(100,100);
    image7.src="/store/images/P/lasting.jpg";
    image8= new Image(100,100);
    image8.src="/store/images/P/birthday_celebrate.jpg";
    image9= new Image(100,100);
    image9.src="/store/images/P/patriotic.jpg";
    image10= new Image(100,100);
    image10.src="/store/images/P/tea.jpg";
    image11= new Image(100,100);
    image11.src="/store/images/P/thanks.jpg";
    image12= new Image(100,100);
    image12.src="/store/images/P/spa_pleasure.jpg";


    }

    function change1(picName,imgName)
    {
    if (document.images)
    {
    imgOn=eval(imgName + ".src");
    document[picName].src= imgOn;
    }
    }

    imgOn=eval(imgName + ".src");
    document[picName].src= imgOn;


    then on the HTML page:
    <table width="600" border="1" bordercolor="#993333" cellspacing="0"
    cellpadding="00">
    <tr>
    <th scope="col" align="left"><A href="#"><IMG alt=""
    src="{$ImagesDir}/romance.jpg" name="pic1" border=0></A></th>
    <th scope="col" valign="top">
    <table height="100%" width="200" cellspacing="0" cellpadding="0"
    border="1" background="/store/skin1/images/BACKGROUND.jpg"
    bordercolor="#993333">
    <tr><td width="200" height="30" align="left"><A
    onMouseover="change1('pic1','image2')"
    onMouseout="change1('pic1','image2')" title="Valentine Gifts"
    rel="nofollow" href="/Valentine-gift-basket.html">
    <div class="menu_text">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Valentine
    Gifts</div>
    </A></td></tr>...........

    How do I do both?
    Thanks in advance
    Lisa
    peashoe, Jan 16, 2007
    #1
    1. Advertising

  2. peashoe wrote:

    > I need to create a javascript that not only changes a picture, but also
    > the link: here is an example of what I need www.myweddingfavors.com/
    > I'm working on this website and have it half done:
    > www.mygiftbasketideas.com - I also what the table to change color on
    > mouseover - this is the code I am using so far:


    [snip code]

    > How do I do both?


    This demonstrates the principle:

    <!-- BEGIN -->
    <script type="text/javascript">
    linkimg_over = new Image();
    linkimg_over.src =
    'http://www.myweddingfavors.com/images/core/bridalBtn-over.gif';
    linkimg_out = new Image();
    linkimg_out.src =
    'http://www.myweddingfavors.com/images/core/bridalBtn.gif';
    otherimg_over = new Image();
    otherimg_over.src =
    'http://www.mygiftbasketideas.com/store/images/P/welcome_baby_boy.jpg';
    otherimg_out = new Image();
    otherimg_out.src =
    'http://www.mygiftbasketideas.com/store/images/P/birthday_celebrate.jpg';

    </script>

    <a href="#"
    onMouseover="
    document.getElementById('pic1').src = eval('linkimg_over.src');
    document.getElementById('pic2').src = eval('otherimg_over.src');
    "
    onMouseout="
    document.getElementById('pic1').src = eval('linkimg_out.src');
    document.getElementById('pic2').src = eval('otherimg_out.src');
    ">
    <img border="0" width="215" height="33" id="pic1"
    src="http://www.myweddingfavors.com/images/core/bridalBtn.gif">
    </a>
    <img id="pic2" border="0" width="400" height="350"
    src="http://www.mygiftbasketideas.com/store/images/P/birthday_celebrate.jpg">
    <!-- END -->

    In order to work around buffering issues, I suggest to add the
    following in your page's header section:

    <META HTTP-EQUIV="pragma" CONTENT="no-cache">
    <META HTTP-EQUIV="expires" CONTENT="-1">
    <META HTTP-EQUIV="cache-control" CONTENT="no-cache">

    Hope this helps,

    --
    Bart
    Bart Van der Donck, Jan 16, 2007
    #2
    1. Advertising

  3. Bart Van der Donck wrote:

    [...]
    > In order to work around buffering issues, I suggest to add the
    > following in your page's header section:
    >
    > <META HTTP-EQUIV="pragma" CONTENT="no-cache">
    > <META HTTP-EQUIV="expires" CONTENT="-1">
    > <META HTTP-EQUIV="cache-control" CONTENT="no-cache">


    Erm, I mean the opposite:

    <META HTTP-EQUIV="cache-control" CONTENT="cache">
    <META HTTP-EQUIV="expires" content="Sat, 31 Dec 2050 23:59:59 GMT">
    <META HTTP-EQUIV="pragma" CONTENT="cache">

    --
    Bart
    Bart Van der Donck, Jan 16, 2007
    #3
  4. Bart Van der Donck wrote:
    <snip>
    > <a href="#"
    > onMouseover="
    > document.getElementById('pic1').src = eval('linkimg_over.src');

    <snip>

    One of the more telling indicators of an - eval - abuse is where the
    argument to - eval - is a siring literal (rather than an expression
    combining string literals and variables, which is only almost always
    an - eval - abuse). There are no circumstances where the contents of
    such a string literal argument to - eval - cannot be used to replace the
    entire - eval - call. That is:-

    eval('linkimg_over.src');

    - can _always_ be replaced with:-

    linkimg_over.src

    - to _precisely_ the same effect (except for being shorter, clearer,
    (potentially much) faster, better supported and generally easier to
    debug if erroneous).


    Why use the general - document.getElementById('pic1') - to reference an
    IMG element when the DOM standard - document.images['pic1'] - is more
    self-documenting (you know from the source code that an IMG element is
    the intended subject of the operation) and potentially much faster
    (because of the size difference between the images collection and the
    entire document)?

    > In order to work around buffering issues,


    If there are "buffering issues" you should be able to state what they
    are (details, cause and effect relationships, symptoms and
    consequences). Otherwise you are just suggesting that there is a 'bogy
    man' named "buffering issues" out there, waiting to byte those who do
    not chant the traditional incantation. That is hardly a rout to
    understanding, and certainly not a rout to taking informed control over
    achieving a desired outcome in a system that is ultimately rational and
    logical.

    > I suggest to add the
    > following in your page's header section:
    >
    > <META HTTP-EQUIV="pragma" CONTENT="no-cache">
    > <META HTTP-EQUIV="expires" CONTENT="-1">
    > <META HTTP-EQUIV="cache-control" CONTENT="no-cache">

    <snip>

    There is nothing that requires (or even implies) that a UA should pay
    any attention to <META HTTP_EQUIV> elements in mark-up, and there is
    good reason to believe that even if a UA does it would not do so in
    preference to HTTP headers sent with a resource (and are subject to
    detailed specification). Rather than propose the cargo-cult/mystical
    inaction formulation of using META elements in the mark-up, why not
    propose the employment of the appropriate HTTP headers?

    Richard.
    Richard Cornford, Jan 16, 2007
    #4
  5. Richard Cornford wrote:

    > Bart Van der Donck wrote:
    > <snip>
    > > <a href="#"
    > > onMouseover="
    > > document.getElementById('pic1').src = eval('linkimg_over.src');

    > <snip>
    >
    > One of the more telling indicators of an - eval - abuse is where the
    > argument to - eval - is a siring literal (rather than an expression
    > combining string literals and variables, which is only almost always
    > an - eval - abuse). There are no circumstances where the contents of
    > such a string literal argument to - eval - cannot be used to replace the
    > entire - eval - call. That is:-
    >
    > eval('linkimg_over.src');
    >
    > - can _always_ be replaced with:-
    >
    > linkimg_over.src
    >
    > - to _precisely_ the same effect (except for being shorter, clearer,
    > (potentially much) faster, better supported and generally easier to
    > debug if erroneous).


    Then that is a better practice indeed.

    > Why use the general - document.getElementById('pic1') - to reference an
    > IMG element when the DOM standard - document.images['pic1'] - is more
    > self-documenting (you know from the source code that an IMG element is
    > the intended subject of the operation) and potentially much faster
    > (because of the size difference between the images collection and the
    > entire document)?


    I'ld say this is more a matter of preference of the coder.

    > > In order to work around buffering issues,

    >
    > If there are "buffering issues" you should be able to state what they
    > are (details, cause and effect relationships, symptoms and
    > consequences). Otherwise you are just suggesting that there is a 'bogy
    > man' named "buffering issues" out there, waiting to byte those who do
    > not chant the traditional incantation. That is hardly a rout to
    > understanding, and certainly not a rout to taking informed control over
    > achieving a desired outcome in a system that is ultimately rational and
    > logical.
    >
    > > I suggest to add the
    > > following in your page's header section:
    > >
    > > <META HTTP-EQUIV="pragma" CONTENT="no-cache">
    > > <META HTTP-EQUIV="expires" CONTENT="-1">
    > > <META HTTP-EQUIV="cache-control" CONTENT="no-cache">

    > <snip>
    >
    > There is nothing that requires (or even implies) that a UA should pay
    > any attention to <META HTTP_EQUIV> elements in mark-up, and there is
    > good reason to believe that even if a UA does it would not do so in
    > preference to HTTP headers sent with a resource (and are subject to
    > detailed specification). Rather than propose the cargo-cult/mystical
    > inaction formulation of using META elements in the mark-up, why not
    > propose the employment of the appropriate HTTP headers?


    I am not aware of an HTTP header that affects image preloading
    techniques from javascript, and I'ld be surprised if this would exist.

    Let me tell you why I counseled the use of those META headers. About
    two/three years ago I used such image preloading techniques in a
    geo-application. It worked well, but it appeared that in Microsoft
    Internet Explorer (I think 5.x at that time) the image buffer could be
    flushed sometimes so that the browser needed to fetch the image(s) back
    from server. It didn't happen too often though, but it did, and I had a
    feeling at that time that it had something to do with the code
    complexity of that project as well. Since I added the META-tags, the
    images were cached correctly and were always shown immediately.

    For me that was reason enough to start using them ever since for this
    kind of image preloading.

    --
    Bart
    Bart Van der Donck, Jan 16, 2007
    #5
  6. Bart Van der Donck wrote:
    > Richard Cornford wrote:
    >> Bart Van der Donck wrote:
    >> <snip>
    >> > <a href="#"
    >> > onMouseover="
    >> > document.getElementById('pic1').src = eval('linkimg_over.src');
    >> > <snip>

    >>
    >> One of the more telling indicators of an - eval - abuse is where
    >> the argument to - eval - is a siring literal (rather than an
    >> expression combining string literals and variables, which is
    >> only almost always an - eval - abuse). There are no circumstances
    >> where the contents of such a string literal argument to - eval -
    >> cannot be used to replace the entire - eval - call. That is:-
    >>
    >> eval('linkimg_over.src');
    >>
    >> - can _always_ be replaced with:-
    >>
    >> linkimg_over.src
    >>
    >> - to _precisely_ the same effect (except for being shorter,
    >> clearer, (potentially much) faster, better supported and
    >> generally easier to debug if erroneous).

    >
    > Then that is a better practice indeed.
    >
    >> Why use the general - document.getElementById('pic1') - to
    >> reference an IMG element when the DOM standard -
    >> document.images['pic1'] - is more self-documenting (you
    >> know from the source code that an IMG element is the
    >> intended subject of the operation) and potentially
    >> much faster (because of the size difference between the
    >> images collection and the entire document)?

    >
    > I'ld say this is more a matter of preference of the coder.


    And using - eval - on a single string literal is not just a matter of
    preference?

    There are 4 reasons for using - doucment.images - to reference IMG
    elements:-

    1. It is HTML DOM standard (which is an applicable standard
    in an environment where you are referencing (x)HTML IMG
    elements.
    2. It is back compatible (even referencing by ID attribute
    instead of by NAME attribute you have included IE 4 at
    zero additional coding effort).
    3. It is self-documenting (you know the subject is going to
    be an IMG element).
    4. It is potentially fastest (as the browser has pre-assembled
    a collection of all IMG elements on the page)

    While arguments in favour of using - getElementById - in its place are
    restricted to:-

    1. It is Core DOM standard.

    Is it really personal preference that would have someone use the latter
    over the former, or something else?

    >>> In order to work around buffering issues,

    >>
    >> If there are "buffering issues" you should be able to state
    >> what they are (details, cause and effect relationships,
    >> symptoms and consequences). Otherwise you are just suggesting
    >> that there is a 'bogy man' named "buffering issues" out there,
    >> waiting to byte those who do not chant the traditional
    >> incantation. That is hardly a rout to understanding, and
    >> certainly not a rout to taking informed control over
    >> achieving a desired outcome in a system that is ultimately
    >> rational and logical.
    >>
    >>> I suggest to add the
    >>> following in your page's header section:
    >>>
    >>> <META HTTP-EQUIV="pragma" CONTENT="no-cache">
    >>> <META HTTP-EQUIV="expires" CONTENT="-1">
    >>> <META HTTP-EQUIV="cache-control" CONTENT="no-cache">

    >> <snip>
    >>
    >> There is nothing that requires (or even implies) that a UA
    >> should pay any attention to <META HTTP_EQUIV> elements in
    >> mark-up, and there is good reason to believe that even if
    >> a UA does it would not do so in preference to HTTP headers
    >> sent with a resource (and are subject to detailed
    >> specification). Rather than propose the cargo-cult/mystical
    >> inaction formulation of using META elements in the mark-up,
    >> why not propose the employment of the appropriate HTTP
    >> headers?

    >
    > I am not aware of an HTTP header that affects image preloading
    > techniques from javascript, and I'ld be surprised if this would
    > exist.


    You don't think the HTTP pragam, expires and cache-control headers might
    come into this then? Do you actually appreciate what HTTP-EQUIV is
    supposed to mean in a META element (what aspect of HTTP the EQUIV is
    'equivalent' to)?

    > Let me tell you why I counseled the use of those META headers.
    > About two/three years ago I used such image preloading
    > techniques in a geo-application. It worked well, but it
    > appeared that in Microsoft Internet Explorer (I think 5.x
    > at that time) the image buffer could be flushed sometimes


    What is the "image buffer"? Are you talking about the browser's
    client-side cache, or images in a running browser's memory?

    > so that the browser needed to fetch the image(s)
    > back from server. It didn't happen too often though, but
    > it did, and I had a feeling at that time that it had
    > something to do with the code complexity of that project
    > as well.


    The HTTP headers sent with the images are much more likely to influence
    the frequency with which the browser sees the need to query the server
    for updates. From what I am reading I suspect that never knew what those
    headers were (and possible never knew they existed).

    > Since I added the META-tags, the images were cached
    > correctly and were always shown immediately.


    So you observed a coincidence, but never established a cause and effect
    relationship.

    > For me that was reason enough to start using them ever
    > since for this kind of image preloading.


    That is "programming by coincidence", and so not something you should be
    recommending to others. Most of the META tag cargo-cults have started
    that way (all praise the mighty HTTP-EQUIV; "META, META, Meta, meta,
    ....".)

    Richard.
    Richard Cornford, Jan 16, 2007
    #6
  7. peashoe

    dd Guest

    Bart Van der Donck wrote:
    > > Why use the general - document.getElementById('pic1') - to reference an
    > > IMG element when the DOM standard - document.images['pic1'] - is more

    >
    > I'ld say this is more a matter of preference of the coder.


    True, it is a preference of the coder, but it's somewhat
    inefficient to "ask" the browser to find something by looking
    through the whole DOM, when it can already restrict the
    search to the images array instead.

    It's equally inefficient to do getElementsByTagName('iframe')
    when document.frames[] gives you the same thing.

    ~dd
    dd, Jan 17, 2007
    #7
  8. peashoe

    dd Guest

    peashoe wrote:
    > I need to create a javascript that not only changes a picture, but also
    > the link: here is an example of what I need www.myweddingfavors.com/


    There's an array built for you by the browser called
    document.links. You can manipulate the links objects
    to change the target:

    document.links.target = some_alt_target;

    If you use an onmouseover event and call a function to
    do the change, you can reference the link object using
    the this keyword ( this.target ).

    ~dd
    dd, Jan 17, 2007
    #8
  9. Richard Cornford wrote:

    > Bart Van der Donck wrote:
    > > I am not aware of an HTTP header that affects image preloading
    > > techniques from javascript, and I'ld be surprised if this would
    > > exist.

    >
    > You don't think the HTTP pragam, expires and cache-control headers might
    > come into this then? Do you actually appreciate what HTTP-EQUIV is
    > supposed to mean in a META element (what aspect of HTTP the EQUIV is
    > 'equivalent' to)?


    The actual HTTP-headers are more important, yes. HTTP-EQUIV might help
    here or there and it certanly doesn't harm to repeat an HTTP header in
    HTTP-EQUIV. It's right that 'equivalent' is too much honour for these
    tags.

    > > Let me tell you why I counseled the use of those META headers.
    > > About two/three years ago I used such image preloading
    > > techniques in a geo-application. It worked well, but it
    > > appeared that in Microsoft Internet Explorer (I think 5.x
    > > at that time) the image buffer could be flushed sometimes

    >
    > What is the "image buffer"? Are you talking about the browser's
    > client-side cache, or images in a running browser's memory?


    I'm not sure about the exact distinction between those two. Just the
    images that were preloaded, stored in buffer and available for
    (immediate) referencing on the page.

    > > so that the browser needed to fetch the image(s)
    > > back from server. It didn't happen too often though, but
    > > it did, and I had a feeling at that time that it had
    > > something to do with the code complexity of that project
    > > as well.

    >
    > The HTTP headers sent with the images are much more likely to influence
    > the frequency with which the browser sees the need to query the server
    > for updates. From what I am reading I suspect that never knew what those
    > headers were (and possible never knew they existed).


    Then tell me, does javascript read out the image's HTTP headers in
    order to decide when it should flush the (preloaded) image ? I would be
    surprised if that were true.

    Working with such stuff seems very browser dependent and very dangerous
    to rely on. But yes, there is technically no problem at server side.

    > > Since I added the META-tags, the images were cached
    > > correctly and were always shown immediately.

    >
    > So you observed a coincidence, but never established a cause and effect
    > relationship.


    That is true up to a certain point. I tested my solution thoroughly and
    I concluded that it worked okay (which it still does until today, btw).
    I'm not sure how things work from your Sedes Sapientiae, but I have
    less-than-perfect expierences as well.

    > > For me that was reason enough to start using them ever
    > > since for this kind of image preloading.

    >
    > That is "programming by coincidence", and so not something you should be
    > recommending to others. Most of the META tag cargo-cults have started
    > that way (all praise the mighty HTTP-EQUIV; "META, META, Meta, meta,
    > ...".)


    It's not programming by coincidence, but a practical solution to a
    concrete problem.

    --
    Bart
    Bart Van der Donck, Jan 17, 2007
    #9
  10. Bart Van der Donck wrote:
    > Richard Cornford wrote:
    >
    >> Bart Van der Donck wrote:
    >>> I am not aware of an HTTP header that affects image
    >>> preloading techniques from javascript, and I'ld be
    >>> surprised if this would exist.

    >>
    >> You don't think the HTTP pragam, expires and cache-control
    >> headers might come into this then? Do you actually appreciate
    >> what HTTP-EQUIV is supposed to mean in a META element (what
    >> aspect of HTTP the EQUIV is 'equivalent' to)?

    >
    > The actual HTTP-headers are more important, yes. HTTP-EQUIV
    > might help here or there


    "Might help here or there"? Are we working with technology or offering
    prayers and sacrifices for a good harvest?

    > and it certanly doesn't harm to repeat an HTTP header in
    > HTTP-EQUIV.

    Web development is plagued with things that 'do no harm'. It should be
    important to distinguish between the things that do some good and the things
    that are no more that mystical incantations, and possibly the things that
    were once of some value but have not become redundant (and are continued
    because they are doing no harm so nothing exists to break the habit).

    An example of the latter is wrapping SCRIPT element contents in <!--
    .... -->, which, for a short period, was a good idea, but is now totally
    redundant but persist because it is (mostly) harmless. Unfortunately the way
    in which it persist is in people who operate on the basis of mystical
    incantation propose to others that this incantation is necessary when
    'conjuring' a SCRIPT element.

    > It's right that 'equivalent' is too much honour for these
    > tags.


    Absolutly.

    >>> Let me tell you why I counseled the use of those META headers.
    >>> About two/three years ago I used such image preloading
    >>> techniques in a geo-application. It worked well, but it
    >>> appeared that in Microsoft Internet Explorer (I think 5.x
    >>> at that time) the image buffer could be flushed sometimes

    >>
    >> What is the "image buffer"? Are you talking about the browser's
    >> client-side cache, or images in a running browser's memory?

    >
    > I'm not sure about the exact distinction between those two.
    > Just the images that were preloaded, stored in buffer and
    > available for (immediate) referencing on the page.


    The process that is labelled "preloading" is more a matter of pre-requesting
    an image, with the intention of moving it into the browser's local disc
    cache. The cachablitly of that image has a considerable impact on the
    usefulness of doing that.

    >>> so that the browser needed to fetch the image(s)
    >>> back from server. It didn't happen too often though, but
    >>> it did, and I had a feeling at that time that it had
    >>> something to do with the code complexity of that project
    >>> as well.

    >>
    >> The HTTP headers sent with the images are much more likely to
    >> influence the frequency with which the browser sees the need to
    >> query the server for updates. From what I am reading I suspect that
    >> never knew what those headers were (and possible never knew they
    >> existed).

    >
    > Then tell me, does javascript read out the image's HTTP headers
    > in order to decide when it should flush the (preloaded) image ?
    > I would be surprised if that were true.


    Javascript has no role in the decision as to whether an image is cached,
    used from the cache or re-loaded from the server. The browser makes that
    decision, but it certainly is considerably influenced in that decision which
    headers are sent with an image (or with the image last time it as requested,
    or instead of the image (in the case of a response to a 'If-Modified-Since"
    request where the server sees no update)).

    > Working with such stuff seems very browser dependent
    > and very dangerous to rely on.


    However something is "worked with", a starting position of understanding
    what HTTP provided for use in relation to caching would be of considerably
    value in determining how any browser may act outside of the specified
    behaviour (or fill in any 'gaps').

    > But yes, there is technically no problem at
    > server side.
    >
    >>> Since I added the META-tags, the images were cached
    >>> correctly and were always shown immediately.

    >>
    >> So you observed a coincidence, but never established a
    >> cause and effect relationship.

    >
    > That is true up to a certain point.


    You either establish a cause and effect relationship or you don't. There is
    no "up to a certain point" in that.

    > I tested my solution thoroughly and I concluded that it
    > worked okay (which it still does until today, btw).


    If your 'solution' was a coincidence (and the theory says it will have been
    as there is no reason to expect the cachability of an HTML page (assuming
    that the HTTP-EQUIVE META elements on the page will effect its cachablity
    (though they can do no more)) would influence the caching behaviour of image
    resources that are referenced from the page) but was in itself harmless then
    its repeated use ("tested ... thoroughly") would demonstrate nothing.

    > I'm not sure how things work from your Sedes Sapientiae,
    > but I have less-than-perfect expierences as well.


    Is that another bogeyman named "less-than-perfect expierences"?

    >>> For me that was reason enough to start using them ever
    >>> since for this kind of image preloading.

    >>
    >> That is "programming by coincidence", and so not something
    >> you should be recommending to others. Most of the META tag
    >> cargo-cults have started that way (all praise the mighty
    >> HTTP-EQUIV; "META, META, Meta, meta, ...".)

    >
    > It's not programming by coincidence,


    Demonstrate the cause and effect relationships and it may not be. But it
    looks to me as if you never even considered many of the factors that would
    be expected to influence the situation.

    > but a practical solution to a concrete problem.


    You do not even know for certain that it influenced the situation you
    described, let alone that it 'solved' anything. The most you are able to say
    it that it was not harmful.

    Richard.
    Richard Cornford, Jan 20, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tor Inge Rislaa
    Replies:
    3
    Views:
    16,104
    Jerry III
    Aug 6, 2003
  2. Rob Roberts
    Replies:
    3
    Views:
    34,583
    Nathan Sokalski
    Jan 28, 2006
  3. R.A.M.
    Replies:
    3
    Views:
    524
    Bergamot
    Nov 11, 2007
  4. Kurda Yon
    Replies:
    1
    Views:
    691
    Andy Dingley
    Feb 10, 2008
  5. Dave
    Replies:
    0
    Views:
    450
Loading...

Share This Page