Re: Need help with textboxes
- From: Thomas 'PointedEars' Lahn <PointedEars@xxxxxx>
- Date: Tue, 18 Sep 2007 00:41:34 +0200
Daz wrote:
On Sep 16, 7:10 pm, Thomas 'PointedEars' Lahn <PointedE...@xxxxxx>
wrote:
Daz wrote:
You'll find that you get some strange behaviour, however, as the eventThat part is actually the only good advice in your posting.
fires the moment it's pressed, which is before it actually types a
character into the input box. I would recommend using "onkeyup"
instead.
Ouch... My purpose was to give an example that could be seen working,
not do do it for him. He wanted to know how to achieve, and I did that
in my example. It's not meant to be code that can be copied and handed
in as school work (if that's what it's for).
Still, would you agree that wrong examples serve little practical purpose?
If it's important to you that the characters appear almostIt will not, that is bad advice. ECMAScript implemenations are
instantaneously, you can use a timer. This means that just about each
character should appear as it's entered if the timer function executes
often enough, and will compensate for when a user holds down a key.
single-threaded, and system timer tick intervals may be higher
than the 50 ms alotted here.
It is also not necessary to use a timer function for "instantaneous"
appearance. Listening to mouse and keyboard events suffices.
Are you talking about recursion?
Hardly. What would recursion have to do with the above?
I'd be interested to see your implementation.
Why, the "implementation" is listen to mouse and keyboard events,
particularly mousedown, mouseup, click, keyup, keydown, and keypress.
setInterval("copyText()", 50)Because of the unknown timer tick interval, it is better to use
setTimeout() instead of setInterval() for time-critical processes.
That, I didn't know. What does setInterval() use then, if it's not
system ticks?
It does use system timer ticks which is the cause of the problem with it
when it comes to time-critical applications.
I was always under the impression that they were built
on the same foundations, but just worked differently.
I read an interesting and IMHO sound argument about setInterval() vs.
setTimeout() in another thread here not long ago, but I don't have the
reference anymore. IIRC, it goes like this:
ECMAScript implementations are single-threaded. window.setInterval()
*attempts* to execute code every n milliseconds despite of that. Consider
that at that time another process/thread has priority, there are two
possibilities: either the application will execute the interval code
at the next available tick, or it will execute it at the next planned
opportunity, n milliseconds after the tick that could not be used.
Either way, the supposed calls are likely to accumulate here.
With setTimeout(), the application will have no choice but to execute it
at the next available tick; and only then the new timeout will be set.
So nothing can accumulate then.
Both methods are proprietary properties of Window host objects and
should be called so: window.setTimeout(...), window.setInterval(...)
I know this, although I don't see much of a point...
Not calling them as methods of Window objects assumes that the Global Object
or an unknown host object in the scope chain has such host-defined
properties. This would be error-prone.
I suppose you write all of your global variable and functions like
that too?
Of course not. Those are properties of the Global Object, not of a host
object that may or may not be available as such and may or may not share
the Global Object's properties. If I would do what you assume, that would
be error-prone, too.
The JavaScript 1.5 Reference already states:
,-<http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects
|
| The [G]lobal [O]bject itself can be accessed by `this' in the global
| scope.
And rightly so; that is specified in ECMA-262 since its very first edition.
<p>`type="text"' is redundant as that is the default value.
Type a word.<br>
<input type="text" name="txtEnterValue">
<input name="txtEnterValue"
onkeyup="copyText(this.form)">
</p>Nonsense. The `p' element is to mark up *p*aragraphs. There is no
paragraph here, so the `div' element should be used instead.
That was the OP's code, and if that's what he wanted to do, that's
down to him. What's wrong with just answering a question rather than
answering a whole heap of questions he didn't even ask?
If you had the intention to give him a hint as how to solve his problem, it
would have been a Good Thing to post a reasonable example, even though the
original code was bad. That would not have involved "answering a whole head
of questions": a short note as to why it is bad along with the improved code
would have sufficed.
That this newsgroup is not a newsgroup dealing primarily with HTML is a
null argument; we are attempting to write good code here, no matter the
language. In fact, it turns out that bad HTML, CSS etc. code often is
the cause of a script written in an ECMAScript implementation not to
function. You simply can't build a house on quicksand.
Validation may reveal your problem - It wouldn't. The problem was with<p>See above.
The result should appear in this box as you type.<br>
<input type="text" name="txtOutput">
</p>Your markup is far from being syntactically or semantically correct.
</form>
</body>
</html>
Due to the former, it is unlikely to work consistently:http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you
the method (not even the JavaScript itself...
Validation may solve your problem - Again, it wouldn't.
You can not know that.
[...]
Validation is an indicator of cluefulness - I couldn't agree more, but
we are talking about HTML validation for a JavaScript problem, when
you know as well as I do that wasn't the problem. Also, it's pretty
obvious that the OP isn't experienced.
So the logical course of action would be to deny them access to further
knowledge?
Note that here, I've used a different method to get the information`forms' is not an array, see below. `children' is too limited, because
from the form. All forms and their children are stored in an array
called "forms",
a reference to a HTMLFormElement includes access to all its descendant elements.
That was my bad. I meant to actually say "object". That's exactly what
it is, but it does "act" like a multi-dimensional array.
It does not.
document.forms.anotherForm.elementNameThis is completely proprietary referencing, and so inherently error-prone.
Mostly standards-compliant and fully backwards-compatible referencing of the
above would be
document.forms["anotherForm"].elements["elementName"]
You can also access it like this:That is not standards-compliant either.
document["forms"]["anotherForm"]["someChildName"]
document["forms"]["anotherForm"]["elements"]["someChildName"]
would be.
Please could you post a link to the documentation that states this?
I did.
I have to admit, I did go through a time when I didn't know whether to
use dot notation or object literals. Generally, I use dot notation
unless I need to call on a dynamically generated property.
I use jslint.com to validate my HTML.
I put both of our lines of script into a variable, and checked it with
JSLint.
var el = document["forms"]["anotherForm"]["elements"]["someChildName"]
Error:
Implied global: document
Problem at line 1 character 19: ['forms'] is better written in dot
notation.
The statement is correct. That should have been only a warning, though.
var el = document["forms"]["anotherForm"]["elements"]["someChildName"]
Problem at line 1 character 28: ['anotherForm'] is better written in
dot notation.
That is incorrect, as I have pointed out and referred to reference material.
If you think my single line of code is wrong, perhaps you should take
it up with Douglas Crockford? I don't mean that in a horrible way, I'd
just be interested to see what he says.
jslint is a tool to check for possible errors and bad code style. It does
not recognize the context of a script. That is not really a flaw of it, but
something that has to be considered by people who use it.
As Douglas Crockford is a regular here, I am pretty sure he will comment on
that eventually.
Again, I didn't say my methods were correct, I simply stated that it
was another way of doing it.
Proposing bad style is a Bad Thing, period.
As I wrote, you could simply have refrained from replying to the OP.
A more knowledgable person than you would most certainly have replied
with a much better S/N ratio.
Although it should only be used if needed, as dot notation is betterIt would only be better if standards-compliant referencing was used.
and more consistent,No. Bracket property accessors allow their argument to be any string value.
Dot property accessors require their operand to be an identifier. Using
dot property accessors in favor of bracket property accessors will cause a
mix of dot and bracket property accessors in cases where the control name is
not an identifier. This is explained in the FAQ.
However, W3C DOM Level 2 HTML specifies that referencing the items of a
HTMLCollection object in an ECMAScript implementation is (only) supported
through the bracket property accessor, so there is not much choice here:
You mean "dereferencing"?
That would imply ECMAScript implementations have a concept of pointers,
which they have not.
http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html
(see the description for the namedItem() method of HTMLCollection objects)
and looks neater.Only a matter of opinion.
What you see above, is basically a multi dimensional array.Not at all. It is merely a sequence of property accesses, where the first
property access is resolved first, then the second, and so forth.
Then we'll have to agree to disagree. Perhaps it's just me,
No, it is a common misconception about the language, last but not least
transported or induced into the mind of beginners by bad books.
but it sounds like you just "described" a multi-dimensional array. I didn't
say it "was" a multi-dimensional array, I simply compared it to one.
Here's a multi-dimensional array:
There isn't. I have explained already why, mentioning exactly the below
example. But as you insist:
var arr = [];
That is creating a new Array object and assigning the reference to it
to the previously instantiated variable `arr'.
I will assume in the following for brevity that `arr' is a global variable.
arr["first_property"] = 1;
That is adding the `first_property' property with value 1 to the Array object.
arr.length remains 0. arr.join("") yields "", not "1".
arr["second_property"] = 2;
That is adding the `second_property' property with value 2 to the Array object.
arr.length remains 0. arr.join("") yields "", not "12".
arr["third_property"] = [];
That is adding the `third_property' property with a reference to a new Array
object to the Array object referenced with `arr'
arr.length remains 0. arr.join("") yields "", not "12".
arr["third_property"]["first_property"] = 4;
That is adding the `first_property' property with the value 0 as property of
the array object referenced by arr["third_property"].
Both arr.length and arr["third_property"].length remain 0. arr.join("")
yields "", not "124". arr["third_property"].join("") yields "", not "4".
arr["third_property"]["second_property"] = function() { alert(5); };
That is adding the `second_property' property with a reference to a new
Function object as property of the Array object referenced by
arr["third_property"].
Both arr.length and arr["third_property"].length remain 0. arr.join("")
yields "", not "124,function() { alert(5); }".
arr["third_property"].join("") yields "", not "4function() { alert(5); }".
arr["third_property"]["third_property"] = 6;
That is adding the `third_property' property with a reference to a new
Function object as property of the array object referenced by
arr["third_property"].
Both arr.length and arr["third_property"].length remain 0. arr.join("")
yields "", not "124,function() { alert(5); },6".
arr["third_property"].join("") yields "", not "4function() { alert(5); }6".
alert(arr.second_property);
That is calling the alert() method (of Window objects, error-prone called as
a method of the Global Object or another object in the scope chain). It is
passed the evaluation of the dot property access to the `arr' property of
the Global Object, which yields an (Array) object; that object has a
`second_property' property which is of type number; the value is converted
to string with ToString(), and (maybe) displayed.
arr.third_property.second_property();
That is evaluated as follows: `arr' is determined a property of the Global
Object, which yields an (Array) object; that object has a `third_property'
property which yields an (Array) object; that object has a second_property
property which is of type Function; the grammar dictates that because of
the (empty) parameter list and the absence of the `new' keyword, that
Function object must [[Call]]ed, which is then done.
Here's the equivilant object:
The only equivalence here is that all objects may have properties, and that
native objects, such as Object objects and Array objects, may be added
(user-defined) properties.
var obj = {}
This is creating a new Object object, and assigning a reference to the
previously instantiated variable `obj'. That object inherits only from
Object.prototype; not from Array.prototype as the object referenced with
`arr' does.
obj.first_property = 1;
I won't repeat the above. Suffice it to say that
obj["first_property"] = 1;
is (of course) equivalent. The difference is only the property accessor
syntax used.
obj.second_property = 2;
obj["second_property"] = 2;
obj.third_property = {}
obj["third_property"] = {};
obj.third_property.first_property = 4;
obj["third_property"].first_property = 4;
or
obj["third_property"]["first_property"] = 4;
obj.third_property.second_property = function() { alert(5) };
obj["third_property"].second_property = function() { alert(5) };
or
obj["third_property"]["second_property"] = function() { alert(5) };
obj.third_property.third_property = 6;
obj["third_property"].third_property = 6;
or
obj["third_property"]["third_property"] = 6;
alert(obj.second_property);
alert(obj["second_property"]);
or (better)
window.alert(obj["second_property"]);
obj.third_property.second_property();
obj["third_property"].second_property();
or
obj["third_property"]["second_property"]();
They are different methods of "Basically" achieving the same thing.
That much is true.
Array() is based on an object (as is everything else), the only
fundamental differences are the properties and methods.
There is much more to Array objects (see ECMA-262 Ed. 3), if array
properties are used.
As they are not used here, the fundamental difference is that the Array
object wastes more memory, and inherits more properties and methods from
its prototype object (which inherits from Object.prototype) that are not
used but can interfere.
So an Object object, which inherits only from Object.prototype, should
have been used in the first place (no matter the property access syntax used).
Please don't start ranting about recommendations and standards.
Mentioning recommendations and standards is only ranting for those who fail
to recognize their utmost significance when it comes to interoperability.
I am well aware that it's not standard,
You are not aware that the language specification explicitly allows that
approach for *native* objects. Which does not mean in any way that it would
be wise to (mis)use Array objects like this.
However, DOM interfaces are a completely different thing. The standard for
*that*, W3C DOM Level 2 HTML, states that bracket property accessors must be
used for referencing items of HTMLCollection objects. It is specified so,
period.
but it should illustrate that when I compared an object is basically a
multi-dimensional array, that there is truth in that.
Not in the least.
Again, I didn't say "it was", I simply compared them.
Your comparison was based on a (common) misconception.
ECMAScript implementations have no built-in concept of associative arrays,
i.e. arrays where the index may also be a non-numeric string. If such
referencing is used on Array objects, that is not adding elements to the
array data structure, but adding properties to the Array object which
encapsulates that data structure. As indicated by the Array object's
length property to yield an unchanged value.
You can also call on a form by it's position in the document array:Neither `document' nor `document.forms' are arrays. `document' is a
reference to an HTMLDocument object, and `document.forms' is therefore
a reference to an HTMLCollection object.
I didn't say it was...
But your statement at least implied this. Don't try to wind around that.
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-26809268
document.form[0][...]
(sic!)
You have destroyed the context.
My examples are from from perfect.Your misconceptions about the used languages and interfaces are numerous.
You should refrain from giving further advice until you have grasped the
basics of that, because any advice you might give in spite of that has a
very high probability of being bad advice. That would force more
knowledgeable people to correct most if not all of your postings and to
waste their time with that, in place of or in addition to investing time
to post good advice.
So in your effort to "not do someone's homework for them", you've
actually gone and done it for them.
You are confused. I have never stated that I would "not do someone's
homework for them" (although I would probably not do that without proper
compensation in any form). However, you made it necessary to correct your
wrong example and false statements (or implications, if you wish). If not
only you but also others, including the OP, can learn from that, so be it.
Still, the unlearning that is now required by them (again; if they even
recognized or understood the correction(s) which ended up being quite large
because of the sheer number of errors) would not have been necessary, and
could have been avoided in the first place.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@xxxxxxxxxxxxxxxx>
.
- Follow-Ups:
- Re: Need help with textboxes
- From: Daz
- Re: Need help with textboxes
- References:
- Need help with textboxes
- From: Kodiak
- Re: Need help with textboxes
- From: Daz
- Re: Need help with textboxes
- From: Thomas 'PointedEars' Lahn
- Re: Need help with textboxes
- From: Daz
- Need help with textboxes
- Prev by Date: Re: Button type and Submit type buttons behaving oddly...
- Next by Date: Re: Button type and Submit type buttons behaving oddly...
- Previous by thread: Re: Need help with textboxes
- Next by thread: Re: Need help with textboxes
- Index(es):
Relevant Pages
|