How do I add to an onchange event?

Discussion in 'Javascript' started by nimhyea@gmail.com, Jan 14, 2008.

  1. Guest

    Hello I was wondering if it was possible to add to an already defined
    onchange event without having to re-write it completely.

    scenario:
    <input type="hidden" name="blah" value="" onChange="alert('hello');">

    <script ...>
    // want to add "world" alert, but since I still want to see
    "hello"...
    document.getElementById("blah").onchange = function()
    {alert("hello");alert("world");}
    </script>

    ideally I just want to concatenate like:
    document.getElementById("blah").onchange += function()
    {alert("world");}

    and not worry about what was there, but then I get a javascript error.

    Thanks for any help.
     
    , Jan 14, 2008
    #1
    1. Advertising

  2. Doug Gunnoe Guest

    On Jan 14, 1:28 pm, wrote:
    > Hello I was wondering if it was possible to add to an already defined
    > onchange event without having to re-write it completely.
    >
    > scenario:
    > <input type="hidden" name="blah" value="" onChange="alert('hello');">
    >
    > <script ...>
    >   // want to add "world" alert, but since I still want to see
    > "hello"...
    >   document.getElementById("blah").onchange = function()
    > {alert("hello");alert("world");}
    > </script>
    >
    > ideally I just want to concatenate like:
    >   document.getElementById("blah").onchange += function()
    > {alert("world");}
    >
    > and not worry about what was there, but then I get a javascript error.
    >
    > Thanks for any help.


    Interesting. So I tried it just to see what would happen.

    First I tried something similar to what you tried.

    <html>
    <head>
    <script>
    function dodo(){
    alert('world');
    }
    function doStuff(){
    var btn = document.getElementById('btn1');
    btn.onclick += "dodo();"
    alert(btn.onclick);
    }
    </script>
    </head>
    <body>
    <input id='btn1' type="button" onclick="alert('hello');" value="click
    me"/>
    <br>
    <input type="button" onclick="doStuff()" value="click me 1st" />
    </body>
    </html>

    And I get this when the doStuff function runs:

    http://polisick.com/test1.png

    And it is obvious that will not work, right?

    So when I just did this,

    <input id='btn1' type="button" onclick="alert('hello');dodo();"
    value="click me"/>

    Then 'dodo()' is inside the anonymous function like so.

    http://polisick.com/test2.png

    And I guess the one you did would just be showing something like:

    function anonymous(){
    alert('hello');
    }function(){alert('world')}

    So I guess you could do some string manipulation and get that
    alert('world') inside the anonymous function. Otherwise, someone else
    might have a better idea.
     
    Doug Gunnoe, Jan 14, 2008
    #2
    1. Advertising

  3. wrote:
    > Hello I was wondering if it was possible to add to an already defined
    > onchange event without having to re-write it completely.
    >
    > scenario:
    > <input type="hidden" name="blah" value="" onChange="alert('hello');">


    Since this element cannot be edited by the user, and so the `change' event
    will never occur for it, the `onChange' attribute (which should be
    `onchange') does not make sense here.

    That aside:

    > <script ...>
    > // want to add "world" alert, but since I still want to see
    > "hello"...
    > document.getElementById("blah").onchange = function()
    > {alert("hello");alert("world");}
    > </script>
    >
    > ideally I just want to concatenate like:
    > document.getElementById("blah").onchange += function()
    > {alert("world");}


    Features of the W3C-DOM and DOM Level 0 should not be combined untested;
    always avoid such reference worms. Besides, your element has a name, not an
    ID. Only MSHTML is this buggy to not care about that difference.

    > and not worry about what was there, but then I get a javascript error.


    Of course, although "a javascript error" is hardly a viable error
    description: http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1DontWork

    First, probably you have been trying to access properties of a non-object
    that document.getElementById() returns here.

    Second, you have been trying to concatenate (Function) object references; in
    the best case you have been trying to assign the equivalent of

    document.getElementById("blah").onchange = NaN;

    as the Function objects were converted to their Number representations in
    the script engine's attempt to satisfy your nonsensical demand.

    As for the latter, you were looking for something along the following instead:

    var _global = this, f = obj.onchange;

    obj.onchange = function(e)
    {
    if (!e)
    {
    e = (typeof _global.window != "undefined"
    && typeof window.event != "undefined"
    && window.event);
    }

    if (f)
    {
    f(e);
    }

    // arbitrary additional code
    window.alert("world");
    };

    // break circular reference to avoid memory leaks in IE
    obj = null;

    I have implemented this approach in the current version of
    _addEventListener() (or dhtml.addEventListener()) in
    http://PointedEars.de/scripts/dhtml.js as an alternative to MSHTML's buggy
    attachEvent() where EventTarget::addEventListener() from W3C DOM Level 2
    Events is not available. Comments are welcome.


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, Jan 14, 2008
    #3
  4. Doug Gunnoe Guest

    On Jan 14, 1:28 pm, wrote:
    > Hello I was wondering if it was possible to add to an already defined
    > onchange event without having to re-write it completely.
    >
    > scenario:
    > <input type="hidden" name="blah" value="" onChange="alert('hello');">
    >
    > <script ...>
    >   // want to add "world" alert, but since I still want to see
    > "hello"...
    >   document.getElementById("blah").onchange = function()
    > {alert("hello");alert("world");}
    > </script>
    >
    > ideally I just want to concatenate like:
    >   document.getElementById("blah").onchange += function()
    > {alert("world");}
    >
    > and not worry about what was there, but then I get a javascript error.
    >
    > Thanks for any help.


    I messed around with this some more.
    The following worked on IE 6. I did not try it on anything else.

    <html>
    <head>
    <script>
    function dodo(){
    alert('world');
    }
    function doStuff(){
    var btn = document.getElementById('btn1');
    var str = btn.onclick;
    str = str + '';
    str = str.substring(str.indexOf('{') + 1, str.indexOf('}'));
    btn.onclick = new Function(str + "dodo();");
    }
    </script>
    </head>
    <body>
    <input type="button" id="btn1" value="click me"
    onclick="alert('hello');" />
    <input type="button" value="click me 1st" onclick="doStuff()" />
    </body>
    </html>
     
    Doug Gunnoe, Jan 14, 2008
    #4
  5. SAM Guest

    a écrit :
    > Hello I was wondering if it was possible to add to an already defined
    > onchange event without having to re-write it completely.
    >
    > scenario:
    > <input type="hidden" name="blah" value="" onChange="alert('hello');">


    Here you'll need id="blah"
    if you use getElementById

    > <script ...>
    > // want to add "world" alert, but since I still want to see
    > "hello"...
    > document.getElementById("blah").onchange = function()
    > {alert("hello");alert("world");}
    > </script>
    >
    > ideally I just want to concatenate like:
    > document.getElementById("blah").onchange += function()
    > {alert("world");}


    If the problem was to get alert('Hello World)

    document.getElementById("blah").onchange = function() {
    alert('Hello World');}

    If you want to do what you tell, use the addEvent function
    (IE + others browsers) :

    function addEvent( obj, type, fn ) {
    if ( obj.attachEvent ) {
    obj['e'+type+fn] = fn;
    obj[type+fn] = function(){obj['e'+type+fn]( window.event );}
    obj.attachEvent( 'on'+type, obj[type+fn] );
    } else
    obj.addEventListener( type, fn, false );
    }

    addEvent(document.getElementById("blah"), 'change',
    function(){alert("world");});


    nota: that doesn't work with IE Mac nor NC4 ;-)

    Not sure that onchange works with an hidden field... ?
    --
    sm
     
    SAM, Jan 15, 2008
    #5
  6. AKS Guest

    On Jan 15, 1:27 am, Thomas 'PointedEars' Lahn <>
    wrote:

    > I have implemented this approach in the current version of
    > _addEventListener() (or dhtml.addEventListener()) inhttp://PointedEars.de/scripts/dhtml.jsas an alternative to MSHTML's buggy
    > attachEvent() where EventTarget::addEventListener() from W3C DOM Level 2
    > Events is not available. Comments are welcome.



    result = (o[sHandler] == fListener);

    -result- will always be false, but logically it must be true.
     
    AKS, Jan 15, 2008
    #6
  7. AKS wrote:
    > On Jan 15, 1:27 am, Thomas 'PointedEars' Lahn <>
    > wrote:
    >> I have implemented this approach in the current version of
    >> _addEventListener() (or dhtml.addEventListener()) inhttp://PointedEars.de/scripts/dhtml.jsas an alternative to MSHTML's buggy
    >> attachEvent() where EventTarget::addEventListener() from W3C DOM Level 2
    >> Events is not available. Comments are welcome.

    >
    > result = (o[sHandler] == fListener);
    >
    > -result- will always be false, but logically it must be true.


    Thanks. You are correct; that was a relic from the previous version. Fixed
    with

    var oldListener = o["on" + sEvent];
    var newListener = function(e)
    {
    if (!e)
    {
    e = (typeof _global.window != "undefined"
    && typeof window.event != "undefined"
    && window.event);
    }

    if (oldListener)
    {
    oldListener(e);
    }

    fListener(e);
    };

    o[sHandler] = newListener;

    result = (o[sHandler] == newListener);


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, Jan 15, 2008
    #7
  8. Randy Webb wrote:
    > Thomas 'PointedEars' Lahn said the following on 1/14/2008 3:27 PM:
    >> wrote:
    >>> Hello I was wondering if it was possible to add to an already defined
    >>> onchange event without having to re-write it completely.
    >>>
    >>> scenario:
    >>> <input type="hidden" name="blah" value="" onChange="alert('hello');">

    >> Since this element cannot be edited by the user, and so the `change' event
    >> will never occur for it, the `onChange' attribute (which should be
    >> `onchange') does not make sense here.

    >
    > Nonsense. It can be ONCHANGE, onChange, onchange, ONChange, or any other
    > capitalization you prefer. HTML is not case-sensitive.


    That is oversimplified. HTML *attribute names* are case-insensitive.[1]
    There are the following -- I think valid -- reasons for my recommendation:

    1. Consistent markup.
    2. Lowercase text compresses better.
    3. Reusing the code will be easier.

    YMMV.


    PointedEars
    ___________
    [1] http://www.w3.org/TR/html401/types.html#h-6.1
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, Jan 15, 2008
    #8
  9. David Mark Guest

    On Jan 15, 9:16 am, Thomas 'PointedEars' Lahn <>
    wrote:
    > AKS wrote:
    > > On Jan 15, 1:27 am, Thomas 'PointedEars' Lahn <>
    > > wrote:
    > >> I have implemented this approach in the current version of
    > >> _addEventListener() (or dhtml.addEventListener()) inhttp://PointedEars.de/scripts/dhtml.jsasan alternative to MSHTML's buggy
    > >> attachEvent() where EventTarget::addEventListener() from W3C DOM Level 2
    > >> Events is not available.  Comments are welcome.

    >
    > > result = (o[sHandler] == fListener);

    >
    > > -result- will always be false, but logically it must be true.

    >
    > Thanks.  You are correct; that was a relic from the previous version.  Fixed
    > with
    >
    >       var oldListener = o["on" + sEvent];
    >       var newListener = function(e)
    >       {
    >         if (!e)
    >         {
    >           e = (typeof _global.window != "undefined"
    >                && typeof window.event != "undefined"
    >                && window.event);
    >         }
    >


    If either of the first two tests fail, e will go from undefined to
    false. Also, you first check if window is a property of the Global
    Object, then turn right around and refer to the same identifier
    implicitly.

    This would seem sufficient:

    e = e || window.event;

    Or if you want to be more explicit:

    if (!e && _global.window) {
    e = _global.window.event;
    }

    It is hard to imagine an implementation that would throw an exception
    on [[Get]] for the window object. Methods of this (or any host
    object) are another story (as we have been over recently.)

    Or if you must:

    if (!e && typeof _global.window == 'object' && _global.window) {
    e = _global.window.event;
    }

    Or to be really paranoid about host object implementations:

    if (!e && typeof _global.window != 'undefined') {
    e = _global.window.event;
    }

    But show me one agent that returns anything other than "object" for
    typeof window. If there is one that screwy, who is to say that it
    wouldn't return a null value for window or throw a [[Get]] exception
    on window.event? The fact that such an agent could exist in the
    future is a good argument for encapsulating such tests in a central
    function (as we have also been over recently.) Regardless, there is
    no surefire way to know if a host object will throw an exception on
    evaluation.

    Either way, assuming no [[Get]] exceptions, e will be an event object
    or undefined (but never false.) Personally, I would use the first
    one, possibly checking for the existence of the window object prior to
    creating the function (or assigning the global event property as
    window and the Global Object share the same scope.) The second option
    would be:

    e = e || _global.event;

    Unless you think that IE8 or newer will give window a different scope
    than the Global object (obviously won't happen), then this is
    sufficient. Here's hoping that IE8 does away with the ridiculous
    global event object altogether.

    This snippet appears to be part of a general solution, which should
    take into account that elements passed may not reside in the same
    frame. Also, expandos are always a bad idea. If you must use them,
    you need to check the document.expando property first.

    Looking at the file it came from, I see a few other problems.

    if (typeof oScript.type != "undefined")
    {
    oScript.type = sType || "text/javascript";
    }

    if (typeof oScript.type != "undefined")
    {
    oScript.type = sType || "text/javascript";
    }

    That is clearly a copy and paste error.

    if (isMethod(typeof aHeads[0].appendChild))

    I assume this is a typo and isMethodType was meant.

    // makes the method applicable to Document and Element objects
    if (!o
    && typeof this.constructor != "undefined"
    && /Document|Element/.test(String(this.constructor)))
    {
    o = this;
    }

    You wouldn't augment host objects would you? Regardless, this is pure
    evil.

    Next line:

    if (o && isMethod(typeof o.getElementsByTagName))

    Same typo as before I assume.

    if (typeof HTMLDocument != "undefined"
    && typeof HTMLDocument.prototype != "undefined")
    {
    HTMLDocument.prototype.getElementsByTabIndex =
    getElementsByTabIndex;
    }

    if (typeof HTMLElement != "undefined"
    && typeof HTMLElement.prototype != "undefined")
    {
    HTMLElement.prototype.getElementsByTabIndex = getElementsByTabIndex;
    }

    OMG. No you didn't.

    Your attribute alias map lists rowspan, but not colspan. Both get and
    set attribute functions have problems. See the version proposed in
    the CWR project. It needs to be revised as I recently fixed a couple
    of problems, but it should indicate areas that you need to improve in
    your code.

    The get and set style property functions don't handle float properly.

    The show function is roughly equivalent to Prototype's, which is to
    say worthless.

    The getParent function is ambiguous as parentNode and parentElement
    are not equivalent.

    The getAbsPos function is severely lacking. For one it completely
    ignores borders.

    This looks wrong:

    if (typeof _global != "undefined")
    {
    var _global = this;
    }

    Perhaps you meant:

    if (typeof _global == "undefined")

    The test isn't needed anyway.

    var dhtml = new DHTML();

    Shouldn't this library be a singleton?

    Overall, feature testing should be pulled out of the functions and the
    repetitive comments should be trimmed. You should run it through
    JSLint as minification is to be expected (nobody wants to download all
    of those credits.)
     
    David Mark, Jan 15, 2008
    #9
  10. David Mark wrote:
    > [...] Thomas 'PointedEars' Lahn [...] wrote:
    > > AKS wrote:
    > > > On Jan 15, 1:27 am, Thomas 'PointedEars' Lahn <>
    > > > wrote:
    > > >> I have implemented this approach in the current version of
    > > >> _addEventListener() (or dhtml.addEventListener()) inhttp://PointedEars.de/scripts/dhtml.jsasanalternative to MSHTML's buggy
    > > >> attachEvent() where EventTarget::addEventListener() from W3C DOM Level 2
    > > >> Events is not available. Comments are welcome.
    > > >
    > > > result = (o[sHandler] == fListener);

    > >
    > > > -result- will always be false, but logically it must be true.

    > >
    > > Thanks. You are correct; that was a relic from the previous version. Fixed
    > > with
    > >
    > > var oldListener = o["on" + sEvent];
    > > var newListener = function(e)
    > > {
    > > if (!e)
    > > {
    > > e = (typeof _global.window != "undefined"
    > > && typeof window.event != "undefined"
    > > && window.event);
    > > }

    >
    > If either of the first two tests fail, e will go from undefined to
    > false.


    You are correct, but I don't think this will make a significant
    difference. Both values evaluate to `false' in a boolean expression.

    > Also, you first check if window is a property of the Global
    > Object, then turn right around and refer to the same identifier
    > implicitly.


    True, the `_global.' is probably error-prone here. Fixed.

    > This would seem sufficient:
    >
    > e = e || window.event;


    It would not.

    > Or if you want to be more explicit:
    >
    > if (!e && _global.window) {
    > e = _global.window.event;
    >
    > }


    That assumes that `window' would be a property of the Global Object
    which, on second thought, does not need to be the case. I am unsure
    as to whether to rely on the former or on the scope chain; I'll stick
    with the latter for the time being.

    > [...]
    > But show me one agent that returns anything other than "object" for
    > typeof window. If there is one that screwy, who is to say that it
    > wouldn't return a null value for window


    Good point, thanks. An additional type-converting test was necessary.

    > or throw a [[Get]] exception on window.event?


    There is no such thing as a [[Get]] exception. What are you aiming
    at?

    > [...]
    > This snippet appears to be part of a general solution, which should
    > take into account that elements passed may not reside in the same
    > frame.


    It is up to the caller to take that into account. If you have a
    suggestion to make, then make it:

    Talk is cheap. Show me the code. -- Linus Torvalds

    > Also, expandos are always a bad idea.


    I don't see where a host object would be augmented with a property
    here.

    > If you must use them, you need to check the document.expando property first.


    That would be relevant *for MSHTML only* iff a host object would be
    *augmented* here.

    > Looking at the file it came from, I see a few other problems.
    >
    > if (typeof oScript.type != "undefined")
    > {
    > oScript.type = sType || "text/javascript";
    > }
    >
    > if (typeof oScript.type != "undefined")
    > {
    > oScript.type = sType || "text/javascript";
    > }
    >
    > That is clearly a copy and paste error.


    Maybe not, however it is fixed now.

    > if (isMethod(typeof aHeads[0].appendChild))
    >
    > I assume this is a typo and isMethodType was meant.


    As no previous version of the method() in the repository handles the
    result of the typeof operation, it would have to be. The library uses
    the new isMethod() method now.

    > // makes the method applicable to Document and Element objects
    > if (!o
    > && typeof this.constructor != "undefined"
    > && /Document|Element/.test(String(this.constructor)))
    > {
    > o = this;
    > }
    >
    > You wouldn't augment host objects would you?


    I would augment a prototype object of a host object after careful
    feature tests. Why not? The fact that there is a prototype object
    conveys the implementor's intention that it be used accordingly, so it
    is not reasonable to assume that this would not work.

    > Regardless, this is pure evil.


    The explicit conversion to string was not necessary as
    RegExp.prototype.test() already does that; fixed. I can't find
    anything evil about this. Care to elaborate?

    > Next line:
    >
    > if (o &&isMethod(typeof o.getElementsByTagName))
    >
    > Same typo as before I assume.


    Fixed.

    > if (typeof HTMLDocument != "undefined"
    > && typeof HTMLDocument.prototype != "undefined")
    > {
    > HTMLDocument.prototype.getElementsByTabIndex =
    > getElementsByTabIndex;
    >
    > }
    >
    > if (typeof HTMLElement != "undefined"
    > && typeof HTMLElement.prototype != "undefined")
    > {
    > HTMLElement.prototype.getElementsByTabIndex = getElementsByTabIndex;
    >
    > }
    >
    > OMG. No you didn't.


    Again, why not?

    > Your attribute alias map lists rowspan, but not colspan.


    Fixed.

    > Both get and set attribute functions have problems. See the version proposed in
    > the CWR project.


    Maybe later.

    > It needs to be revised as I recently fixed a couple of problems,
    > but it should indicate areas that you need to improve in
    > your code.


    So it's only more cheap talk?

    > The get and set style property functions don't handle float properly.


    They do now.

    > The show function is roughly equivalent to Prototype's, which is to
    > say worthless.


    There is no "show function". If you mean display() or visibility(),
    you are mistaken.

    > The getParent function is ambiguous as parentNode and parentElement
    > are not equivalent.


    When would they not be equivalent?

    > The getAbsPos function is severely lacking. For one it completely
    > ignores borders.


    I'll look into that later.

    > This looks wrong:
    >
    > if (typeof _global != "undefined")
    > {
    > var _global = this;
    >
    > }
    >
    > Perhaps you meant:
    >
    > if (typeof _global == "undefined")


    Yes, I did; fixed.

    > The test isn't needed anyway.


    Yes, it was.

    > var dhtml = new DHTML();
    >
    > Shouldn't this library be a singleton?


    No, it should not. A singleton is a concept coming from class-based
    inheritance to start with.

    > Overall, feature testing should be pulled out of the functions and the
    > repetitive comments should be trimmed.


    There was and is going to be a version that has all JSdoc[tm] comments
    removed, and there is going to be a documentation written in a markup
    language generated from them.

    > You should run it through JSLint as minification is to be expected (nobody wants to download all
    > of those credits.)


    I have stated what I think about minifiers already. As for the
    credits, people will have to download the minimum of them (after the
    JSdoc[tm] is removed) because otherwise I could not distribute the
    library under the GNU GPL 2.0+.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Jan 17, 2008
    #10
  11. David Mark Guest

    On Jan 17, 11:31 am, "Thomas 'PointedEars' Lahn" <>
    wrote:
    > David Mark wrote:
    > > [...] Thomas 'PointedEars' Lahn [...] wrote:
    > > > AKS wrote:
    > > > > On Jan 15, 1:27 am, Thomas 'PointedEars' Lahn <>
    > > > > wrote:
    > > > >> I have implemented this approach in the current version of
    > > > >> _addEventListener() (or dhtml.addEventListener()) inhttp://PointedEars.de/scripts/dhtml.jsasanalternativeto MSHTML's buggy
    > > > >> attachEvent() where EventTarget::addEventListener() from W3C DOM Level 2
    > > > >> Events is not available.  Comments are welcome.

    >
    > > > > result = (o[sHandler] == fListener);

    >
    > > > > -result- will always be false, but logically it must be true.

    >
    > > > Thanks.  You are correct; that was a relic from the previous version..  Fixed
    > > > with

    >
    > > >       var oldListener = o["on" + sEvent];
    > > >       var newListener = function(e)
    > > >       {
    > > >         if (!e)
    > > >         {
    > > >           e = (typeof _global.window != "undefined"
    > > >                && typeof window.event != "undefined"
    > > >                && window.event);
    > > >         }

    >
    > > If either of the first two tests fail, e will go from undefined to
    > > false.

    >
    > You are correct, but I don't think this will make a significant
    > difference.  Both values evaluate to `false' in a boolean expression.


    It's just odd to pass false for e.

    >
    > > Also, you first check if window is a property of the Global
    > > Object, then turn right around and refer to the same identifier
    > > implicitly.

    >
    > True, the `_global.' is probably error-prone here.  Fixed.
    >
    > > This would seem sufficient:

    >
    > > e = e || window.event;

    >
    > It would not.
    >
    > > Or if you want to be more explicit:

    >
    > > if (!e && _global.window) {
    > >   e = _global.window.event;

    >
    > > }

    >
    > That assumes that `window' would be a property of the Global Object
    > which, on second thought, does not need to be the case.  I am unsure
    > as to whether to rely on the former or on the scope chain; I'll stick
    > with the latter for the time being.
    >
    > > [...]
    > > But show me one agent that returns anything other than "object" for
    > > typeof window.  If there is one that screwy, who is to say that it
    > > wouldn't return a null value for window

    >
    > Good point, thanks.  An additional type-converting test was necessary.
    >
    > > or throw a [[Get]] exception on window.event?

    >
    > There is no such thing as a [[Get]] exception.  What are you aiming
    > at?


    If you really don't know, then you have a very short memory. We
    discussed that to death two or three weeks ago. Host objects can do
    anything they want on [[Get]], including throwing an exception (like
    the href property of a news link.)

    >
    > > [...]
    > > This snippet appears to be part of a general solution, which should
    > > take into account that elements passed may not reside in the same
    > > frame.

    >
    > It is up to the caller to take that into account.  If you have a
    > suggestion to make, then make it:


    Then that should be documented. Otherwise, find the element's
    document (use ownerDocument if available, otherwise loop through its
    parentNodes until you hit a document node.) Then find the document's
    window using parentWindow or defaultView.

    >
    >   Talk is cheap. Show me the code. -- Linus Torvalds
    >
    > > Also, expandos are always a bad idea.

    >
    > I don't see where a host object would be augmented with a property
    > here.


    I thought I saw that you were storing an expando on element nodes
    somewhere in your event section. I'll have to re-read it if I still
    care by the end of this message.

    >
    > > If you must use them, you need to check the document.expando property first.

    >
    > That would be relevant *for MSHTML only* iff a host object would be
    > *augmented* here.


    Yes, so you check if it is undefined or true.

    >
    > > Looking at the file it came from, I see a few other problems.

    >
    > > if (typeof oScript.type != "undefined")
    > >       {
    > >         oScript.type = sType || "text/javascript";
    > >       }

    >
    > >       if (typeof oScript.type != "undefined")
    > >       {
    > >         oScript.type = sType || "text/javascript";
    > >       }

    >
    > > That is clearly a copy and paste error.

    >
    > Maybe not, however it is fixed now.


    The code so nice you wrote it twice.

    >
    > >  if (isMethod(typeof aHeads[0].appendChild))

    >
    > > I assume this is a typo and isMethodType was meant.

    >
    > As no previous version of the method() in the repository handles the
    > result of the typeof operation, it would have to be.  The library uses
    > the new isMethod() method now.


    And what would that be? You know you can't pass the method directly.

    >
    > > // makes the method applicable to Document and Element objects
    > >   if (!o
    > >       && typeof this.constructor != "undefined"
    > >       && /Document|Element/.test(String(this.constructor)))
    > >   {
    > >     o = this;
    > >   }

    >
    > > You wouldn't augment host objects would you?

    >
    > I would augment a prototype object of a host object after careful
    > feature tests.  Why not?  The fact that there is a prototype object
    > conveys the implementor's intention that it be used accordingly, so it
    > is not reasonable to assume that this would not work.


    You suddenly recommending such an approach seems highly illogical.

    >
    > > Regardless, this is pure evil.

    >
    > The explicit conversion to string was not necessary as
    > RegExp.prototype.test() already does that; fixed.  I can't find
    > anything evil about this.  Care to elaborate?


    Surely you jest. Converting a constructor to a string and then
    testing for "Document" or "Element?" What have you done with the real
    "PointedEars?"

    >
    > > Next line:

    >
    > >  if (o &&isMethod(typeof o.getElementsByTagName))

    >
    > > Same typo as before I assume.

    >
    > Fixed.
    >
    >
    >
    >
    >
    > > if (typeof HTMLDocument != "undefined"
    > >     && typeof HTMLDocument.prototype != "undefined")
    > > {
    > >   HTMLDocument.prototype.getElementsByTabIndex =
    > > getElementsByTabIndex;

    >
    > > }

    >
    > > if (typeof HTMLElement != "undefined"
    > >     && typeof HTMLElement.prototype != "undefined")
    > > {
    > >   HTMLElement.prototype.getElementsByTabIndex = getElementsByTabIndex;

    >
    > > }

    >
    > > OMG.  No you didn't.

    >
    > Again, why not?


    Again. You are kidding, right?

    >
    > > Your attribute alias map lists rowspan, but not colspan.

    >
    > Fixed.
    >
    > > Both get and set attribute functions have problems.  See the version proposed in
    > > the CWR project.

    >
    > Maybe later.
    >
    > > It needs to be revised as I recently fixed a couple of problems,
    > > but it should indicate areas that you need to improve in
    > > your code.

    >
    > So it's only more cheap talk?


    It is code that you would do well to read as your implementation of
    get/setAttribute is severely lacking. I am just giving you a heads up
    that the posted version is not perfect. I know of at least one typo.
    Regardless, it will point in you in the right direction.

    >
    > > The get and set style property functions don't handle float properly.

    >
    > They do now.
    >
    > > The show function is roughly equivalent to Prototype's, which is to
    > > say worthless.

    >
    > There is no "show function".  If you mean display() or visibility(),
    > you are mistaken.


    The display function. And I am not mistaken. It is worthless.

    >
    > > The getParent function is ambiguous as parentNode and parentElement
    > > are not equivalent.

    >
    > When would they not be equivalent?


    When the parent is not an element. Why would there be two of them in
    the first place if they were identical?

    >
    > > The getAbsPos function is severely lacking.  For one it completely
    > > ignores borders.

    >
    > I'll look into that later.


    Don't bother.

    >
    > > This looks wrong:

    >
    > > if (typeof _global != "undefined")
    > > {
    > >   var _global = this;

    >
    > > }

    >
    > > Perhaps you meant:

    >
    > > if (typeof _global == "undefined")

    >
    > Yes, I did; fixed.
    >
    > > The test isn't needed anyway.

    >
    > Yes, it was.
    >
    > > var dhtml = new DHTML();

    >
    > > Shouldn't this library be a singleton?

    >
    > No, it should not.  A singleton is a concept coming from class-based
    > inheritance to start with.


    You know full-well what I mean.

    >
    > > Overall, feature testing should be pulled out of the functions and the
    > > repetitive comments should be trimmed.

    >
    > There was and is going to be a version that has all JSdoc[tm] comments


    Cheap talk.

    > removed, and there is going to be a documentation written in a markup
    > language generated from them.


    More cheap talk. I wouldn't waste too much time packaging this thing.

    >
    > > You should run it through JSLint as minification is to be expected (nobody wants to download all
    > > of those credits.)

    >
    > I have stated what I think about minifiers already.  As for the


    Yet you crammed the thing full of redundant comments that beg to be
    stripped out by a minifier.

    > credits, people will have to download the minimum of them (after the
    > JSdoc[tm] is removed) because otherwise I could not distribute the
    > library under the GNU GPL 2.0+.


    Distribute it to whom?
     
    David Mark, Jan 17, 2008
    #11
  12. David Mark wrote:
    > [...] "Thomas 'PointedEars' Lahn" [...] wrote:
    >> David Mark wrote:
    >>> [...] Thomas 'PointedEars' Lahn [...] wrote:
    >>>> [...]
    >>>> if (!e)
    >>>> {
    >>>> e = (typeof _global.window != "undefined"
    >>>> && typeof window.event != "undefined"
    >>>> && window.event);
    >>>> }
    >>> If either of the first two tests fail, e will go from undefined to
    >>> false.

    >> You are correct, but I don't think this will make a significant
    >> difference. Both values evaluate to `false' in a boolean expression.

    >
    > It's just odd to pass false for e.


    Do you have a point to make here?

    >>> or throw a [[Get]] exception on window.event?

    >> There is no such thing as a [[Get]] exception. What are you aiming
    >> at?

    >
    > If you really don't know, then you have a very short memory. We
    > discussed that to death two or three weeks ago. Host objects can do
    > anything they want on [[Get]], including throwing an exception (like
    > the href property of a news link.)


    It has been demonstrated that the behavior of `typeof' for host objects is
    somewhat different than just a simple property access, so it is questionable
    whether your reasoning even applies here.

    >>> [...]
    >>> This snippet appears to be part of a general solution, which should
    >>> take into account that elements passed may not reside in the same
    >>> frame.

    >> It is up to the caller to take that into account. If you have a
    >> suggestion to make, then make it:

    >
    > Then that should be documented. Otherwise, find the element's
    > document (use ownerDocument if available, otherwise loop through its
    > parentNodes until you hit a document node.) Then find the document's
    > window using parentWindow or defaultView.


    I don't see a reason to, unless you back that up with a reasonable example.

    >>> If you must use them, you need to check the document.expando property first.

    >> That would be relevant *for MSHTML only* iff a host object would be
    >> *augmented* here.

    >
    > Yes, so you check if it is undefined or true.


    I said *iff*. If you only cared to read ...

    >>> Looking at the file it came from, I see a few other problems.
    >>> if (typeof oScript.type != "undefined")
    >>> {
    >>> oScript.type = sType || "text/javascript";
    >>> }
    >>> if (typeof oScript.type != "undefined")
    >>> {
    >>> oScript.type = sType || "text/javascript";
    >>> }
    >>> That is clearly a copy and paste error.

    >> Maybe not, however it is fixed now.

    >
    > The code so nice you wrote it twice.


    Goodness forbids you'll ever make a mistake! (*HUALP!*)

    >>> if (isMethod(typeof aHeads[0].appendChild))
    >>> I assume this is a typo and isMethodType was meant.

    >> As no previous version of the method() in the repository handles the


    The `()' should have been omitted here; just a reflex :)

    >> result of the typeof operation, it would have to be. The library uses
    >> the new isMethod() method now.

    >
    > And what would that be?


    Use the Source, Luke. It's the method that gets passed an object reference
    and a string value to designate the property to be tested which avoids the
    redundancy caused by passing the result of the `typeof' operation. I had
    that in store for a long time, slightly different though, but the discussion
    here convinced me that the approach was OK for most occasions.

    > You know you can't pass the method directly.


    Yes, I've known that long since, much longer than you are posting here.
    I really don't have time to be patronized by wannabes like you.

    >>> // makes the method applicable to Document and Element objects
    >>> if (!o
    >>> && typeof this.constructor != "undefined"
    >>> && /Document|Element/.test(String(this.constructor)))
    >>> {
    >>> o = this;
    >>> }
    >>> You wouldn't augment host objects would you?

    >> I would augment a prototype object of a host object after careful
    >> feature tests. Why not? The fact that there is a prototype object
    >> conveys the implementor's intention that it be used accordingly, so it
    >> is not reasonable to assume that this would not work.

    >
    > You suddenly recommending such an approach seems highly illogical.


    Only if one reads my postings with deliberately narrowed vision. The world
    isn't black and white, and I use conditions in some of my statements
    accordingly.

    >>> Regardless, this is pure evil.

    >> The explicit conversion to string was not necessary as
    >> RegExp.prototype.test() already does that; fixed. I can't find
    >> anything evil about this. Care to elaborate?

    >
    > Surely you jest. Converting a constructor to a string and then
    > testing for "Document" or "Element?"


    I am not testing for "Document" or "Element", but everything that it
    contains. That is how it works in Gecko-based UAs, the only UAs that
    support this particular feature to date. "Document" may be contained
    in "HTMLDocument", and "Element" is contained in the string representation
    of the constructor for any object that implements an element interface
    from W3C DOM Level 2 HTML.

    > What have you done with the real "PointedEars?"


    I am here. If you have nothing constructive to say, I suggest you be silent.

    >>> It needs to be revised as I recently fixed a couple of problems,
    >>> but it should indicate areas that you need to improve in
    >>> your code.

    >> So it's only more cheap talk?

    >
    > It is code that you would do well to read as your implementation of
    > get/setAttribute is severely lacking. I am just giving you a heads up
    > that the posted version is not perfect.


    There can be no perfect version. Both people and DOMs are not perfect.

    > I know of at least one typo.


    Then name it, for goodness' sake! Or simply shut up.

    > Regardless, it will point in you in the right direction.


    In a comment to my code, which you deem error-prone or even erroneous, you
    point me to source code that you imply still contains errors either. What
    ridiculous kind of pointer is that -- "find the errors"?

    >>> The show function is roughly equivalent to Prototype's, which is to
    >>> say worthless.

    >> There is no "show function". If you mean display() or visibility(),
    >> you are mistaken.

    >
    > The display function. And I am not mistaken. It is worthless.


    It is not, else I would not have written it. Your turn.

    >>> The getParent function is ambiguous as parentNode and parentElement
    >>> are not equivalent.

    >> When would they not be equivalent?

    >
    > When the parent is not an element. Why would there be two of them in
    > the first place if they were identical?


    Your logic is flawed. The first property is specified in the W3C DOM; the
    second one is defined only in the MSHTML DOM, and not supported elsewhere.
    The MSHTML DOM implements several features of the W3C DOM, including this
    one, since version 5.0(1). RTFM.

    The only case where a parent node property would not yield a reference to an
    element node object is the root node of the document tree. Both property
    values are `null' in that case. Probably you are confusing this with
    childNodes/children which include text nodes.

    >>> var dhtml = new DHTML();
    >>> Shouldn't this library be a singleton?

    >> No, it should not. A singleton is a concept coming from class-based
    >> inheritance to start with.

    >
    > You know full-well what I mean.


    I know what a singleton is, and it does not apply here. Period.

    >>> Overall, feature testing should be pulled out of the functions and the
    >>> repetitive comments should be trimmed.

    >> There was and is going to be a version that has all JSdoc[tm] comments

    >
    > Cheap talk.
    >
    >> removed, and there is going to be a documentation written in a markup
    >> language generated from them.

    >
    > More cheap talk. I wouldn't waste too much time packaging this thing.


    I really don't care anymore what you would do. I only mentioned it to
    rectify the false impression you were giving about it.

    >>> You should run it through JSLint as minification is to be expected (nobody wants to download all
    >>> of those credits.)

    >> I have stated what I think about minifiers already. As for the

    >
    > Yet you crammed the thing full of redundant comments that beg to be
    > stripped out by a minifier.


    The comments are not redundant, else I would not have included them. See
    above. And if you had read some of them you would not have had to jump to
    this many conclusions here.

    >> credits, people will have to download the minimum of them (after the
    >> JSdoc[tm] is removed) because otherwise I could not distribute the
    >> library under the GNU GPL 2.0+.

    >
    > Distribute it to whom?


    Having waded through all that destructive irrelevance, I'm sorry now to have
    even responded and actually felt obliged to thank you for the sound of your
    corrections. As despite my newsreader's killfile I saw your posting while
    doing research using Google Groups. I'm sorry for thinking it would
    actually be possible to engage in a civilized constructive discussion with
    you. I guess eventually I will have to revert the setting again :-(


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Jan 17, 2008
    #12
  13. David Mark Guest

    On Jan 17, 6:58 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > David Mark wrote:
    > > [...] "Thomas 'PointedEars' Lahn" [...] wrote:
    > >> David Mark wrote:
    > >>> [...] Thomas 'PointedEars' Lahn [...] wrote:
    > >>>> [...]
    > >>>> if (!e)
    > >>>> {
    > >>>> e = (typeof _global.window != "undefined"
    > >>>> && typeof window.event != "undefined"
    > >>>> && window.event);
    > >>>> }
    > >>> If either of the first two tests fail, e will go from undefined to
    > >>> false.
    > >> You are correct, but I don't think this will make a significant
    > >> difference. Both values evaluate to `false' in a boolean expression.

    >
    > > It's just odd to pass false for e.

    >
    > Do you have a point to make here?


    Yes and I made it.

    >
    > >>> or throw a [[Get]] exception on window.event?
    > >> There is no such thing as a [[Get]] exception. What are you aiming
    > >> at?

    >
    > > If you really don't know, then you have a very short memory. We
    > > discussed that to death two or three weeks ago. Host objects can do
    > > anything they want on [[Get]], including throwing an exception (like
    > > the href property of a news link.)

    >
    > It has been demonstrated that the behavior of `typeof' for host objects is
    > somewhat different than just a simple property access, so it is questionable
    > whether your reasoning even applies here.


    Not really.

    >
    > >>> [...]
    > >>> This snippet appears to be part of a general solution, which should
    > >>> take into account that elements passed may not reside in the same
    > >>> frame.
    > >> It is up to the caller to take that into account. If you have a
    > >> suggestion to make, then make it:

    >
    > > Then that should be documented. Otherwise, find the element's
    > > document (use ownerDocument if available, otherwise loop through its
    > > parentNodes until you hit a document node.) Then find the document's
    > > window using parentWindow or defaultView.

    >
    > I don't see a reason to, unless you back that up with a reasonable example.


    I already gave you the example (the passed element may reside in
    another frame.)

    >
    > >>> If you must use them, you need to check the document.expando property first.
    > >> That would be relevant *for MSHTML only* iff a host object would be
    > >> *augmented* here.

    >
    > > Yes, so you check if it is undefined or true.

    >
    > I said *iff*. If you only cared to read ...


    I was replying to the *for MSHTML only* part. Whether you are
    actually setting expandos or not is irrelevant to that particular
    comment.

    >
    > >>> Looking at the file it came from, I see a few other problems.
    > >>> if (typeof oScript.type != "undefined")
    > >>> {
    > >>> oScript.type = sType || "text/javascript";
    > >>> }
    > >>> if (typeof oScript.type != "undefined")
    > >>> {
    > >>> oScript.type = sType || "text/javascript";
    > >>> }
    > >>> That is clearly a copy and paste error.
    > >> Maybe not, however it is fixed now.

    >
    > > The code so nice you wrote it twice.

    >
    > Goodness forbids you'll ever make a mistake! (*HUALP!*)
    >
    > >>> if (isMethod(typeof aHeads[0].appendChild))
    > >>> I assume this is a typo and isMethodType was meant.
    > >> As no previous version of the method() in the repository handles the

    >
    > The `()' should have been omitted here; just a reflex :)
    >
    > >> result of the typeof operation, it would have to be. The library uses
    > >> the new isMethod() method now.

    >
    > > And what would that be?

    >
    > Use the Source, Luke. It's the method that gets passed an object reference
    > and a string value to designate the property to be tested which avoids the


    Ah, I see. So after all of the arguing against my "isHostMethod"
    function, you finally realized it made more sense than your
    "isMethodType" function and changed it accordingly. Glad I could
    help.

    > redundancy caused by passing the result of the `typeof' operation. I had
    > that in store for a long time, slightly different though, but the discussion
    > here convinced me that the approach was OK for most occasions.
    >
    > > You know you can't pass the method directly.

    >
    > Yes, I've known that long since, much longer than you are posting here.
    > I really don't have time to be patronized by wannabes like you.


    Oh brother. It's the old "I've been posting much longer than you"
    argument. And who on earth would "wannabe" you?

    >
    > >>> // makes the method applicable to Document and Element objects
    > >>> if (!o
    > >>> && typeof this.constructor != "undefined"
    > >>> && /Document|Element/.test(String(this.constructor)))
    > >>> {
    > >>> o = this;
    > >>> }
    > >>> You wouldn't augment host objects would you?
    > >> I would augment a prototype object of a host object after careful
    > >> feature tests. Why not? The fact that there is a prototype object
    > >> conveys the implementor's intention that it be used accordingly, so it
    > >> is not reasonable to assume that this would not work.

    >
    > > You suddenly recommending such an approach seems highly illogical.

    >
    > Only if one reads my postings with deliberately narrowed vision. The world
    > isn't black and white, and I use conditions in some of my statements
    > accordingly.


    Here you used conditions to augment HTMLElement and you know that
    won't work in IE. That makes for a lopsided interface.

    >
    > >>> Regardless, this is pure evil.
    > >> The explicit conversion to string was not necessary as
    > >> RegExp.prototype.test() already does that; fixed. I can't find
    > >> anything evil about this. Care to elaborate?

    >
    > > Surely you jest. Converting a constructor to a string and then
    > > testing for "Document" or "Element?"

    >
    > I am not testing for "Document" or "Element", but everything that it
    > contains. That is how it works in Gecko-based UAs, the only UAs that
    > support this particular feature to date. "Document" may be contained


    Exactly. That's one of the reasons it is a silly thing to do.

    > in "HTMLDocument", and "Element" is contained in the string representation
    > of the constructor for any object that implements an element interface
    > from W3C DOM Level 2 HTML.


    Seems to me that there is no guarantee of that.

    >
    > > What have you done with the real "PointedEars?"

    >
    > I am here. If you have nothing constructive to say, I suggest you be silent.


    LOL. Count the number of times you said "fixed" in the last post.

    >
    > >>> It needs to be revised as I recently fixed a couple of problems,
    > >>> but it should indicate areas that you need to improve in
    > >>> your code.
    > >> So it's only more cheap talk?

    >
    > > It is code that you would do well to read as your implementation of
    > > get/setAttribute is severely lacking. I am just giving you a heads up
    > > that the posted version is not perfect.

    >
    > There can be no perfect version. Both people and DOMs are not perfect.


    The last revision I posted to the CWR Trac server (before it went down
    over the holidays) was pretty close. I have tried to add a couple of
    revisions since, but the server has been down.

    >
    > > I know of at least one typo.

    >
    > Then name it, for goodness' sake! Or simply shut up.


    Good luck with that attitude. I will post my revisions when the
    server comes back up (it is down at the moment.)

    >
    > > Regardless, it will point in you in the right direction.

    >
    > In a comment to my code, which you deem error-prone or even erroneous, you
    > point me to source code that you imply still contains errors either. What
    > ridiculous kind of pointer is that -- "find the errors"?


    Everything is relative. Your entire approach is flawed. The proposed
    code in the CWR ticket will certainly illustrate why that is,
    regardless of any minor defects it may have. IIRC, the typo that
    (may) still exist in that ticket is in a regular expression and does
    not break anything (it just makes it slightly less consistent.)

    >
    > >>> The show function is roughly equivalent to Prototype's, which is to
    > >>> say worthless.
    > >> There is no "show function". If you mean display() or visibility(),
    > >> you are mistaken.

    >
    > > The display function. And I am not mistaken. It is worthless.

    >
    > It is not, else I would not have written it. Your turn.


    I'll pass on that one.

    >
    > >>> The getParent function is ambiguous as parentNode and parentElement
    > >>> are not equivalent.
    > >> When would they not be equivalent?

    >
    > > When the parent is not an element. Why would there be two of them in
    > > the first place if they were identical?

    >
    > Your logic is flawed. The first property is specified in the W3C DOM; the


    Yes.

    > second one is defined only in the MSHTML DOM, and not supported elsewhere.


    Right.

    > The MSHTML DOM implements several features of the W3C DOM, including this
    > one, since version 5.0(1). RTFM.


    I dom't have to. I know the MSHTML DOM implements parentNode and
    parentElement.

    >
    > The only case where a parent node property would not yield a reference to an
    > element node object is the root node of the document tree. Both property
    > values are `null' in that case. Probably you are confusing this with


    Wrong. The HTML element will yield a document node object with
    parentNode. It yields null with parentElement (as would be expected
    as a document node is not an element.) RTFM indeed.

    > childNodes/children which include text nodes.


    Hardly. And of course, childNodes and children are not equivalent
    either. The latter returns element and comment nodes only. The
    former includes text nodes.

    >
    > >>> var dhtml = new DHTML();
    > >>> Shouldn't this library be a singleton?
    > >> No, it should not. A singleton is a concept coming from class-based
    > >> inheritance to start with.

    >
    > > You know full-well what I mean.

    >
    > I know what a singleton is, and it does not apply here. Period.


    Of course it does. You are side-stepping the issue. Your DHTML
    constructor should simply be an object literal (as if you didn't
    understand that in the first place.)

    >
    > >>> Overall, feature testing should be pulled out of the functions and the
    > >>> repetitive comments should be trimmed.
    > >> There was and is going to be a version that has all JSdoc[tm] comments

    >
    > > Cheap talk.

    >
    > >> removed, and there is going to be a documentation written in a markup
    > >> language generated from them.

    >
    > > More cheap talk. I wouldn't waste too much time packaging this thing.

    >
    > I really don't care anymore what you would do. I only mentioned it to
    > rectify the false impression you were giving about it.


    Pardon? If the impressions I gave were false, why did you have to fix
    so many things as a result? A less socially challenged person would
    be grateful that I took the time to help them.

    >
    > >>> You should run it through JSLint as minification is to be expected (nobody wants to download all
    > >>> of those credits.)
    > >> I have stated what I think about minifiers already. As for the

    >
    > > Yet you crammed the thing full of redundant comments that beg to be
    > > stripped out by a minifier.

    >
    > The comments are not redundant, else I would not have included them. See


    LOL. Does every function need to have Author:"PointedEars" above it?

    > above. And if you had read some of them you would not have had to jump to
    > this many conclusions here.


    Clearly I jumped to no conclusions, else my comments wouldn't have
    generated so many bug fixes.

    >
    > >> credits, people will have to download the minimum of them (after the
    > >> JSdoc[tm] is removed) because otherwise I could not distribute the
    > >> library under the GNU GPL 2.0+.

    >
    > > Distribute it to whom?

    >
    > Having waded through all that destructive irrelevance, I'm sorry now to have
    > even responded and actually felt obliged to thank you for the sound of your
    > corrections. As despite my newsreader's killfile I saw your posting while
    > doing research using Google Groups. I'm sorry for thinking it would
    > actually be possible to engage in a civilized constructive discussion with
    > you. I guess eventually I will have to revert the setting again :-(


    Do your worst. :)
     
    David Mark, Jan 18, 2008
    #13
  14. Guest

    My goodness! So many options to consider! The addEvent was generally
    the option I was hoping for and doug's method has a new DIY charm
    about it. The extra discussion that this question spring boarded is
    rather interesting and I'll need to ponder it further to fully
    understand what's going on there. Thanks everyone!
     
    , Jan 19, 2008
    #14
  15. Doug Gunnoe Guest

    On Jan 19, 12:59 am, wrote:
    > My goodness! So many options to consider! The addEvent was generally
    > the option I was hoping for and doug's method has a new DIY charm
    > about it. The extra discussion that this question spring boarded is
    > rather interesting and I'll need to ponder it further to fully
    > understand what's going on there. Thanks everyone!


    lol. Thanks. 'DIY charm' is the nicest way I have ever heard to call
    something a hack.

    But hey, sometimes "it works" works, right? :)
     
    Doug Gunnoe, Jan 19, 2008
    #15
    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. Zeebra3
    Replies:
    5
    Views:
    5,126
    pelegk1
    Jul 15, 2007
  2. MDBloemker
    Replies:
    2
    Views:
    2,860
  3. Norm via DotNetMonster.com

    using the client side "onchange" event function

    Norm via DotNetMonster.com, Jun 15, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    4,861
    Norm via DotNetMonster.com
    Jun 15, 2005
  4. Jason Hartsoe

    Checkboxlist add onchange event

    Jason Hartsoe, Aug 1, 2008, in forum: ASP .Net
    Replies:
    1
    Views:
    774
    bruce barker
    Aug 1, 2008
  5. rekha
    Replies:
    0
    Views:
    2,597
    rekha
    Nov 25, 2008
Loading...

Share This Page