assign prototype to event

[webgour]

Hello,

I am wondering why the following works, on IE6, but with an error : "Not
implemented".

function TEST(){}
TEST.prototype.Initialize = function()
{
var mImage = new Image();
var mDate = new Date();
var start = mDate.getTime();
mImage.onload = this.Alerting(start);//WORKS with ERROR "Not implemented"
//mImage.onload = function(){this.Alerting(start);}//ERROR "Object doesn't
support this property or method"
mImage.src = "winxp.gif";
}
TEST.prototype.Alerting = function(i_string){alert(i_string);}
var mTest = new TEST();
mTest.Initialize();

Can anybody guess why?
Thanks for your time.

[Walton]

mImage.onload = this.Alerting(start);//WORKS with ERROR "Not implemented"

this syntax is incorrect for what you're trying to do. you want
mImage.onload to be set to a function- you're setting it to whatever
is returned from that function call.
create an anonymous function that calls "Alerting(..)"

var _this = this; //important otherwise you will lose reference to
this TEST instance in the anonymous function and "this" will refer to
the image object (i think).

mImage.onload = function(start){_this.Alerting(start);}

[Richard Cornford]

webgour wrote:

I am wondering why the following works, on IE6, but with
an error : "Not implemented".

One of the reasons that the declaration "don't work" is not greeted with
praise when presented here, and nobody is too impressed with the
declaration "it works" is people who say things like "works, on IE6, but
with an error".

function TEST(){}
TEST.prototype.Initialize = function()
{
var mImage = new Image();
var mDate = new Date();
var start = mDate.getTime();
mImage.onload = this.Alerting(start);//WORKS with ERROR "Not
implemented"

The - Alerting - method of this object does not have a return statement
and so returns the undefined value by default. IE is objecting to the
idea of assigning an undefined value to an intrinsic event handler. Which
is not too unreasonable as it allows the assigning of a null value when a
handler is to be cleared and otherwise it makes no sense to attempt to
assign anything but a reference to a function to the - onload - property.

//mImage.onload = function(){this.Alerting(start);}//ERROR
"Object doesn't support this property or method"

In the context of an intrinsic event handling method triggered in
response to an event the - this - keyword will (or, will with DOM named
and usually will with Image objects) refer to the object to which the
function has been assigned, the Image object in this case. The Image
object has no Alerting method so IE tells you it does not support the
method called.

mImage.src = "winxp.gif";
}
TEST.prototype.Alerting = function(i_string){alert(i_string);}
var mTest = new TEST();
mTest.Initialize();

Can anybody guess why?

<snip>

You want a guess as well? How about on of VK's: "an OS-specific gc
failure with
references in window.frames collection".

Richard.

[Tom]

On Mar 12, 4:18 pm, "Richard Cornford" <[e-mail]>
wrote:

webgour wrote:

I am wondering why the following works, on IE6, but with
an error : "Not implemented".

One of the reasons that the declaration "don't work" is not greeted with
praise when presented here, and nobody is too impressed with the
declaration "it works" is people who say things like "works, on IE6, but
with an error".

function TEST(){}
TEST.prototype.Initialize = function()
{
var mImage = new Image();
var mDate = new Date();
var start = mDate.getTime();
mImage.onload = this.Alerting(start);//WORKS with ERROR "Not
implemented"

The - Alerting - method of this object does not have a return statement
and so returns the undefined value by default. IE is objecting to the
idea of assigning an undefined value to an intrinsic event handler. Which
is not too unreasonable as it allows the assigning of a null value when a
handler is to be cleared and otherwise it makes no sense to attempt to
assign anything but a reference to a function to the - onload - property.

//mImage.onload = function(){this.Alerting(start);}//ERROR
"Object doesn't support this property or method"

In the context of an intrinsic event handling method triggered in
response to an event the - this - keyword will (or, will with DOM named
and usually will with Image objects) refer to the object to which the
function has been assigned, the Image object in this case. The Image
object has no Alerting method so IE tells you it does not support the
method called.

mImage.src = "winxp.gif";
}
TEST.prototype.Alerting = function(i_string){alert(i_string);}
var mTest = new TEST();
mTest.Initialize();

Can anybody guess why?

<snip>

You want a guess as well? How about on of VK's: "an OS-specific gc
failure with
references in window.frames collection".

Richard.

I'd be real careful when assigning custom event handlers to predefined
objects in javascript. Different browsers handle that kind of
assignment very differently. Consider:

function TEST {
var mImage = new Image() ;
mImage.onload = TEST.prototype.something;
mImage.src = "whatever" ;
}
TEST.prototype.something = function() {
alert(this) ;
}

You'd expect every browser to alert "object Image" or "[object Image]"
or some variation on that, but in Safari you'll find that it returns
"object Window".

Had a similar problem a month ago:
http://groups.google.com/group/comp....rosera&rnum=1#

[Richard Cornford]

Tom wrote:

On Mar 12, 4:18 pm, Richard Cornford wrote:

<snip>

>In the context of an intrinsic event handling method triggered in
response to an event the - this - keyword will (or, will with DOM
named and usually will with Image objects) refer to the object to

^^^^^
That was a typeo for 'node'.

>which the function has been assigned, the Image object in this
case.

<snip>

I'd be real careful when assigning custom event handlers to
predefined objects in javascript.

Would you? How are you defining a "predefined object" here?

Different browsers handle that kind of
assignment very differently. Consider:

function TEST {
var mImage = new Image() ;
mImage.onload = TEST.prototype.something;
mImage.src = "whatever" ;
}
TEST.prototype.something = function() {
alert(this) ;
}

You'd expect every browser to alert "object Image" or
"[object Image]" or some variation on that,

<snip>

Would I? I don't think I would expect the Image object in IceBrowser 5 to
ever execute the assigned function (or request the image).

Richard.

[-Lost]

"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote in message
news:et*******************@news.demon.co.uk...

Would I? I don't think I would expect the Image object in IceBrowser 5 to ever execute
the assigned function (or request the image).

You have been talking about IceBrowser for years. I am guessing you are a developer?

-Lost

[Richard Cornford]

-Lost wrote:

Richard Cornford wrote:

>Would I? I don't think I would expect the Image object in
IceBrowser 5 to ever execute the assigned function (or
request the image).

You have been talking about IceBrowser for years.

Why not, as it is a fully dynamic, scriptable, W3C DOM standard web
browser?

I am guessing you are a developer?

I am, but if you are implying that I had anything to do with the writing
of IceBrowser you would be mistaken.

Richard.

[-Lost]

"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote in message
news:et*******************@news.demon.co.uk...

-Lost wrote:

>Richard Cornford wrote:

>>Would I? I don't think I would expect the Image object in
IceBrowser 5 to ever execute the assigned function (or
request the image).

You have been talking about IceBrowser for years.

Why not, as it is a fully dynamic, scriptable, W3C DOM standard web browser?

Indeed. Duly noted.

>I am guessing you are a developer?

I am, but if you are implying that I had anything to do with the writing of IceBrowser
you would be mistaken.

Aye, that I was. My mistake.

Might I inquire as to what you are developing in JavaScript nowadays? I read your
previous articles (granted, I sorely need to reread them).

-Lost

[Richard Cornford]

-Lost wrote:

Richard Cornford wrote:

>-Lost wrote:

<snip>

>>I am guessing you are a developer?

I am, but if you are implying that I had anything to do with
the writing of IceBrowser you would be mistaken.

Aye, that I was. My mistake.

Might I inquire as to what you are developing in JavaScript nowadays?
I read your previous articles (granted, I sorely need to reread them).

I am writing the client-side framework and UI for a large-scale web
application, and probably will be for some time to come (details beyond
those would be subject to a confidentiality agreement).

Richard.

[-Lost]

"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote in message
news:et*******************@news.demon.co.uk...

-Lost wrote:

>Richard Cornford wrote:

>>-Lost wrote:

<snip>

>>>I am guessing you are a developer?

I am, but if you are implying that I had anything to do with
the writing of IceBrowser you would be mistaken.

Aye, that I was. My mistake.

Might I inquire as to what you are developing in JavaScript nowadays?
I read your previous articles (granted, I sorely need to reread them).

I am writing the client-side framework and UI for a large-scale web application, and
probably will be for some time to come (details beyond those would be subject to a
confidentiality agreement).

Heh, fair enough. I was prying for ideas to be honest.

I cannot think of any "large-scale" applications by which to test my limited skills. I
would love to tinker with something bordering on several hundred lines as opposed to
barely a hundred.

-Lost

[Richard Cornford]

-Lost wrote:

Richard Cornford wrote:

>-Lost wrote:

<snip>

>>Might I inquire as to what you are developing in
JavaScript nowadays?

<snip>

>I am writing the client-side framework and UI for a large-scale
web application, and probably will be for some time to come
(details beyond those would be subject to a confidentiality
agreement).

Heh, fair enough. I was prying for ideas to be honest.

I cannot think of any "large-scale" applications by which to test
my limited skills.

We may have very different concepts of what "large-scale" is. I am
working with a client-side code base of 70,000 odd lines (with at least
60 times the server-side code), and you would not want to even attempt
that on your own or without being paid for it.

I would love to tinker with something bordering on several hundred
lines as opposed to barely a hundred.

One thing to remember is that your firsts attempts at anything will
likely be unsatisfactory. Once you have a handle on the langue and the
object model provided by the host the next things to learn are the
considerations that apply to the design, and you don't learn those
without trying and seeing where you fall short.

You could pick on anything, whether it has been done before (or done to
death) you can still try to do it better, or do it in your style. Even
the silly gimmicky things (that nasty 'falling snow' script, for example)
can be better done, and much learnt along the way.

Probably the most important thing is to expose your creations to
criticism, and then address those criticisms with practical changes.

Richard.

[-Lost]

"Richard Cornford" wrote in message news:et*******************@news.demon.co.uk...

-Lost wrote:

>Richard Cornford wrote:

>>-Lost wrote:

<snip>

>>>Might I inquire as to what you are developing in
JavaScript nowadays?

<snip>

>>I am writing the client-side framework and UI for a large-scale
web application, and probably will be for some time to come
(details beyond those would be subject to a confidentiality
agreement).

Heh, fair enough. I was prying for ideas to be honest.

I cannot think of any "large-scale" applications by which to test
my limited skills.

We may have very different concepts of what "large-scale" is. I am working with a
client-side code base of 70,000 odd lines (with at least 60 times the server-side code),
and you would not want to even attempt that on your own or without being paid for it.

Yet again, you are indeed correct. I could not even possibly imagine 70,000 lines of
JavaScript. I get queasy looking over a few hundred lines.

>I would love to tinker with something bordering on several hundred
lines as opposed to barely a hundred.

One thing to remember is that your firsts attempts at anything will likely be
unsatisfactory. Once you have a handle on the langue and the object model provided by
the host the next things to learn are the considerations that apply to the design, and
you don't learn those without trying and seeing where you fall short.

You could pick on anything, whether it has been done before (or done to death) you can
still try to do it better, or do it in your style. Even the silly gimmicky things (that
nasty 'falling snow' script, for example) can be better done, and much learnt along the
way.

Duly noted. I wrote one of those "falling" scripts in ActionScript many a month ago, and
have long thought about porting it to JavaScript. Of course, I was not about to brag
about it. : )

For example:

frame 1 {
Stage.showMenu = 'false';
Stage.scaleMode = 'noScale';
var snowflakes = 100;
var stagewidth = 600;
var stageheight = 200;
t = 0;
while (t != snowflakes) {
mc = _root.attachMovie('snowflake', 'snow' + t, t);
mc.dir = (30 + Math.random() * 30) * Math.PI / 180;
mc.speed = Math.random() * 8;
mc._yscale = 15 * mc.speed;
mc._xscale = mc._yscale;
mc._x = Math.random() * stagewidth;
mc._y = Math.random() * stageheight;
mc.onEnterFrame = function () {
var xspeed = Math.cos(this.dir) * this.speed;
var yspeed = Math.sin(this.dir) * this.speed;
this._x += xspeed;
this._y += yspeed;
if (this._x stagewidth) {
this._x = 0;
}
if (this._y stageheight) {
this._y = 0;
}
};

++t;
}
}
}

Sorry, to go OT with ActionScript, I just thought it wildly coincidental that you
mentioned a snowflake script.

Probably the most important thing is to expose your creations to criticism, and then
address those criticisms with practical changes.

Thank you for the wise advice. It is very much appreciated.

-Lost