Newbie Needs help with function arguments
Dave Edwards
I've finally realised that I'm not going to get anywhere on the web without
knowing a little javascript, so i've decided to try and write a little
function that will change the value of a textbox dependant on wether or not
a checkbox is clicked, the following script works fine
<script language="JavaScript" type="text/JavaScript">
<!--
function CB_checkbox() {
if(document.form1.c1.checked)document.form1.v1.value='10'; else
document.form1.v1.value=""; }
//-->
</script>
<form name="form1" method="post" action="">
<input name="c1" type="checkbox" id="c1" onClick="CB_checkbox"
value="checkbox">
<input name="v1" type="text" id="v1" size="8" >
</form>
However when I try to use arguments to make the function reuseable it works
a little strangely, checking the checkbox puts the value in the checkbox,
but unticking doesn't remove the value, What am I doing wrong???
<script language="JavaScript" type="text/JavaScript">
<!--
function CB_checkbox(txtval,chkbox) {
var chkstr='this.form1.'+chkbox+'.checked'
if(chkstr)document.form1.v1.value=txtval; else document.form1.v1.value=""; }
//-->
</script>
<form name="form1" method="post" action="">
<input name="c1" type="checkbox" id="c1" onClick="CB_checkbox(40,'c1')"
value="checkbox">
<input name="v1" type="text" id="v1" size="8" >
</form>
If someone could point me in the right direction, i would be massively
grateful.
Cheers
Charlie.
Dave Edwards
"Dave Edwards" <no...@none.com> wrote in message
news:tYIPc.612$UA2...@newsfe3-gui.ntli.net...
Harag
wrote:
>Hi all,
[snip]
>However when I try to use arguments to make the function reuseable it works
>a little strangely, checking the checkbox puts the value in the checkbox,
>but unticking doesn't remove the value, What am I doing wrong???
>
> <script language="JavaScript" type="text/JavaScript">
take out the language="JavaScript" part, only the type= is needed
><!--
No need to comment out your scripts, no one really use the old
browsers anymore
>function CB_checkbox(txtval,chkbox) {
>var chkstr='this.form1.'+chkbox+'.checked'
>if(chkstr)document.form1.v1.value=txtval; else document.form1.v1.value=""; }
from your other message, try not to use eval, try the following lines
instead of the above 2.
var chkstr = document.form1.elements[chkbox].checked;
var v = document.form1.v1;
// Following line is like a if (...) {...} else {...}
(chkstr) ? v.value = txtval : v.value = '';
I always use single quote in Javascript and double quotes in HTML, as
you see from your onclick below, makes things easier IMHO.
>//-->
Again, not needed.
HTH,
Al.
Dave Edwards
"Harag" <haragRE...@softhome.com> wrote in message
news:95pug0hbv3i3ksjm3...@4ax.com...
G Roydor
Dave Edwards a écrit:
> Hi all,
> I've finally realised that I'm not going to get anywhere on the web without
> knowing a little javascript, so i've decided to try and write a little
> function that will change the value of a textbox dependant on wether or not
> a checkbox is clicked, the following script works fine
>
> <script language="JavaScript" type="text/JavaScript">
> <!--
> function CB_checkbox() {
> if(document.form1.c1.checked)document.form1.v1.value='10'; else
> document.form1.v1.value=""; }
> //-->
> </script>
> <form name="form1" method="post" action="">
> <input name="c1" type="checkbox" id="c1" onClick="CB_checkbox"
> value="checkbox">
> <input name="v1" type="text" id="v1" size="8" >
> </form>
>
> However when I try to use arguments to make the function reuseable it works
> a little strangely, checking the checkbox puts the value in the checkbox,
> but unticking doesn't remove the value, What am I doing wrong???
>
> <script language="JavaScript" type="text/JavaScript">
> <!--
> function CB_checkbox(txtval,chkbox) {
> var chkstr='this.form1.'+chkbox+'.checked'
var chkstr='this.form1.'+chkbox;
> if(chkstr)document.form1.v1.value=txtval; else document.form1.v1.value=""; }
if(chkstr.checked){
document.form1.v1.value=txtval;
Richard Cornford
> I've finally realised that I'm not going to get anywhere
> on the web without knowing a little javascript,
You may have heard the expression "A little knowledge is a dangerous
thing". All around the world there are web sites where someone who knew
a little javascript has decided to put that knowledge into use and
included inadequate scripts, with directly harmful consequences (for the
users of those sites and often (especially in a commercial context) for
the owners of those sights).
Javascript is not a difficult language to learn, or even to understand
(once you are familiar with the specification (ECMA 262 3rd edition)) as
it is not that big (no accompanying large collection of
APIs/libraries/packages). One of the main challenges it offers as a
language is its flexibility in allowing a range of styles of
implementation (object orientated, procedural and functional), and
leaving the author to decide which style (or combination of styles) best
suites the situation.
The difficult part of writing javascript for the Internet is the web
browser environments in which it will be executed. And it is less a
problem of code writing than it is a problem of script design. Browsers
differ in their capabilities, and the (numeric by type) majority of
browsers cannot execute javascript at all (and all of the browsers that
can execute javascript offer a user configurable option to disable it).
Any script capable browser may or may not offer the features required by
any given script, and any browser client may be incapable of executing
scripts at all. As a result all scripts will fail on some clients (no
matter how spectacular they may be on script enabled modern dynamic
desktop browsers).
The challenge in browser scripting is to recognise the inevitability of
those failures and to design for it. To get the most from a script and
the capabilities of the client browser when they are available, but
without letting the use of the script stand in the way of the viability
of the underlying web pages. Unfortunately that takes a more than a
little javascript knowledge to achieve. It requires an awareness of the
issues, a willingness to tackle the issues, a great deal of though and
planning, quite a lot of practice and extensive cross-browser testing.
An involved and difficult task that leaves many 'javascript authors'
preferring to look around for any convenient excuse (often statistical)
for ignoring the issues entirely (but they never end up knowing how to
write cross-browser scripts that way).
> so i've decided to try and write a little function
> that will change the value of a textbox dependant
> on wether or not a checkbox is clicked, the following
> script works fine
That isn't actually true, the following HTML snippet doesn't do anything
because the - CB_checkbox - function is never called.
> <script language="JavaScript" type="text/JavaScript">
^^^^^^^^^^^^^^^^^^^^^
Valid HTML 4 requires the TYPE attribute. The LANGUAGE attribute is
deprecated (and cannot be used with the strict DTDs). Providing the
required TYPE attribute renders the LANGUAGE attribute redundant, it can
be (so probably should be) omitted.
> <!--
^^^^
Warping the contents of script elements in HTML style comments is an
obsolete practice. Be extremely wary of any source of browser scripting
information that recommends the practice without a valid explanation
(which will not include any suggestions of 'hiding' anything from 'older
browsers') as it is likely to be either out of date or uninformed
(therefor technically suspect). (The browsers that did not recognise the
SCRPT element are two generations older than the oldest browsers still
in use).
> function CB_checkbox() {
> if(document.form1.c1.checked)document.form1.v1.value='10';
Is a named form always available as a named property of the - document -
object? Well in scriptable HTML web browsers it probably is (nobody has
yet been able to name a browser where that is not the case) but it
probably isn't safe to assume that it will be.
<URL: http://jibbering.com/faq/faq_notes/form_access.html >
The property accessor - document.form1 - may be undefined in any browser
environment, in which case the property accessor - document.form1.c1 -
will produce an "object is null or undefined" style error when it tries
to resolve "c1" as a named property of something that is not an object.
Generally scripts should not be allowed to fail by erroring (and such
failures can be avoided with suitably defensive programming).
The W3C HTML DOM specification includes a - document.forms - collection
as a formalisation of a common pre-existing browser feature. As such -
document.forms - can be expected to be available in future HTML DOMs and
is back-compatible with all scriptable browsers known to understand what
a from is. On the other hand, some older XHTML DOM implementations did
not include it either, so while it (as the W3C DOM specified method)
should be preferred over accessing a named form as a property of the -
document - it still would not be safe to assume its availability.
The best approach to handling the variability of the browser environment
is through feature detection:-
<URL: http://jibbering.com/faq/faq_notes/not_browser_detect.html >
- in which the availability of the various browser features is verified
prior to their use, and the results of various operations (such as the
retrieval of a reference to a form) are verified prior to their
employment:-
function CB_checkbox() {
var formRef = (document.forms&&document.forms['form1'])||null;
var formEls = (formRef&&formRef.elements)||null;
var cBox = (formEls&&formEls['c1'])||null;
if(cBox && frmEls["v1"]){
if(cBox.checked){
frmEls["v1"].value='10';
}else{
frmEls["v1"].value="";
}
}
}
Testing all browser features prior to use is necessary to create a
reliable Internet browser script. Scripts must fail under their own
control in order to exhibit planned behaviour when they fail and
properly take advantage of having been designed with the inevitability
of that failure in mind ("clean degradation"). However, filling a
function with feature detecting tests and repeating those tests on every
invocation can be very inefficient. For a simple script, or something
that is only expected to be executed once (such as form validation) then
efficiency is not necessarily on overriding considerations. But with
DHTML style scripts an inefficient implementation can be the difference
between a viable script and something that is unusable (remember that
the machines on which browsers are operating in an Internet context may
not be using the latest and fastest hardware).
While it is essential to perform feature detection prior to the use of
any feature it is not necessarily necessary to do so prior to each use
of that feature. Javascript is a wonderfully dynamic language and allows
considerable run-time modification of its own structures. A "gateway"
strategy can be applied to feature detecting, with an initial
configuration upon first use of a script that will do the necessary
feature detection, and then either allow the scripting of those features
without re-testing (when they are available). Or will permanently deny
the use of those features (when unavailable) by, say, replacing
functions with alternatives that may be harmless dummies, or may do no
more than return a constant value to signify the unavailability of their
required features (to facilitate controlled degradation).
The above function could be re-written:-
function CB_checkbox() {
if(
document.forms &&
document.forms.length &&
document.forms['form1'] &&
document.forms[0].elements &&
document.forms[0].elements['c1'] &&
document.forms[0].elements['v1']
){
/* all required features are available so replace
- CB_checkbox - with a fucntion that does the work
but does not repeat the feature detection. this assumes
that no scirpt will remove the form from the document:-
*/
CB_checkbox = function(){
var frmEls = document.forms[0].elements
var cBox = frmEls['c1'];
if(cBox && frmEls["v1"]){
if(cBox.checked){
frmEls["v1"].value='10';
}else{
frmEls["v1"].value="";
}
}
}
}else{
CB_checkbox = function(){
return; //harmles dummy fucntion.
}
}
CB_checkbox(); //call the replacemnt function.
}
- so that its first invocation did the "gateway" testing and re-assigned
the value of - CB_checkbox - to one of two functions. The first (when
the gateway is passed) does the work without re-testing the browser's
support for the required features. The second is a harmless dummy that
attempts nothing, but cannot error in doing so. The first invocation
ends by calling this now function, subsequent calls just use which ever
of the new functions has been assigned to - CG_checkbox - directly
(avoiding the need to repeat the tests).
In this example the difference between the two will not be significant.
> else document.form1.v1.value=""; }
You may observe that I use a very formal style in my code authoring.
Progressively indenting the contents of block statements and, for
example, deliberately wrapping the statements associated with - if -
and - else - in a block statement even though a single-statement - if -
does not require that. This application of arbitrary formal structure to
source code is unnecessary (in the sense that the code would work just
the same without it) but has been generally found to be advantageous in
programming as it aids human understanding of the code, and can reduce
the risk of introducing errors when modifying code. Programming is an
activity that benefits from a disciplined approach.
I would recommend that you adopt some similar approach to formal code
structuring in your development code (deployed code can be
machine-stripped of its formatting if that is seen to be advantageous).
See:-
<URL: http://jibbering.com/faq/faq_notes/pots1.html >
- for more information on the subject, especially in relation to extra
considerations needed in newsgroup posts.
> //-->
> </script>
> <form name="form1" method="post" action="">
> <input name="c1" type="checkbox" id="c1"
> onClick="CB_checkbox" value="checkbox">
^^^^^^^^^^^
This line of code does not actually call the - CB_checkbox - function.
It is usually counter productive to be posting code that is not the
original code (or is not a specially prepared cut-down version that
_has_been_verified_ as exhibiting the pertinent behaviour).
> <input name="v1" type="text" id="v1" size="8" >
> </form>
>
> However when I try to use arguments to make the function
> reuseable it works a little strangely, checking the checkbox
> puts the value in the checkbox, but unticking doesn't remove
> the value, What am I doing wrong???
Javascript is a loosely typed language that performs automatic type
conversion:
> <script language="JavaScript" type="text/JavaScript">
> <!--
> function CB_checkbox(txtval,chkbox) {
> var chkstr='this.form1.'+chkbox+'.checked'
The - chkstr - local variable is being assigned a string value above.
> if(chkstr)document.form1.v1.value=txtval; else
All non empty strings type-convert to boolean false. Using - chkstr - as
the expression in an - if - statement will have it internally
type-converted to boolean to allow the - if - statement to make its
decision. The non-empty string is true so the first branch is always
executed.
There are two types of property accessor in javascript. The dot notation
property accessor and the bracket notation property accessor. The latter
allows string literals and string expression to be used in the place of
property names. It looks to me like your function wants to be using a
bracket notation property accessor:-
<URL: http://jibbering.com/faq/faq_notes/square_brackets.html >
So:-
var chkstr = this.form1[chkbox].checked;
(but the use of the W3C HTML DOM specified collections would probably be
better.)
> document.form1.v1.value=""; } //-->
> </script>
>
> <form name="form1" method="post" action="">
> <input name="c1" type="checkbox" id="c1"
> onClick="CB_checkbox(40,'c1')" value="checkbox">
In the context of the call to - CB_checkbox - from the event handling
method of the checkbox with the ID/name "c1", passing the identifier
string "c1" is not necessarily the best way of making the code
re-usable. An alternative would be to pass a reference to the
corresponding checkbox element directly. Such a reference is always
available in the code of an event handling method as - this -, which
refers to the element on which the even handler is a method.
So with:-
onClick="CB_checkbox(40, this);"
- the function becomes:-
function CB_checkbox(txtval, chkbox){
var target;
if(
chkbox &&
chkbox.form &&
chkbox.form.elements &&
(target = chkbox.form.elements["v1"])
){
if(chkbox.checked){
target.valu e= txtval;
}else{
target.value = "";
}
}
}
- The checkbox element is passed by reference and so dose not need to be
resolved against the DOM, its name/ID is no longer important. The -
form - property of the checkbox element can be used to reference the
containing form, again without the need to be interested in the name of
the containing form.
> <input name="v1" type="text" id="v1" size="8" >
> </form>
>
> If someone could point me in the right direction, i
> would be massively grateful.
Bracket notation, never use - eval - to resolve property accessors.
Design scripts with the certainty that they will fail somewhere always
in mind. Read the comp.lang.javascript FAQ (and linked resources).
Richard.
George Hester
__________________________________
"Richard Cornford" <> wrote in message
news:ceo837$44o$1$8302...@news.demon.co.uk...
>
> Richard.
>
Thanks Richard
George Hester
Yann-Erwan Perio
That goes against my trimming habits, but full quote is deserved here;
this is one of the best introduction I've ever read about javascript and
browser scripting.
Hmm, the check for cBox and frmEls["v1"] doesn't need to be done, and
you're mixing simple and double quotes to define a string token;
regardless, this piece of code exhibits a remarkable aesthetics (in
addition of the strong conception).
The use of the square bracket notation proves to be definitely superior
to the point accessor, the CB_checkbox definitions and calls are simply
perfect and provide a subtile end to the procedure, the indentation and
block points are nicely thought; even the frmEls repeating, which could
have been avoided with a variable declaration, participates
interestingly in the function presentation.
A refreshing and charming piece of code (made me quite happy, after
hours of VBA coding)! What material are you studying these days?
Richard Cornford
> Richard Cornford wrote:
<snip>
> That goes against my trimming habits, but full quote is
> deserved here; this is one of the best introduction I've
> ever read about javascript and browser scripting.
Thank you. 3 or 4 more attempts and I might manage to properly express
my feelings on the subject to the extent that it becomes worth including
it in a web page (probably as an improved introduction to
not_browser_detect.html in the faq notes).
>> function CB_checkbox() {
<snip>
>> CB_checkbox(); //call the replacemnt function.
>> }
>
> Hmm, the check for cBox and frmEls["v1"] doesn't need to be
> done, and you're mixing simple and double quotes to define
> a string token;
The mixed quotes are a consequence of copy-and-paste, and there are some
other errors like using - forms['form1'] - in the "gateway" tests where
I should have used - forms[0] - and - forms[0] - in the inner function
where it should have been the form name. I banged it out too quickly,
more as an illustration of the test and re-configure strategy than as a
serious function (as - CB_checkbox - was far too specific to deserve
that type of treatment).
> regardless, this piece of code exhibits a remarkable
> aesthetics (in addition of the strong conception).
I have been reviewing the use of code such as:-
var funcName = (fucntion(){
...
return (fucntion(){
...
return something;
});
})();
- to create useful closures inline as a page loads, and I have decided
that rather than creating the containing scope inline with the one-time
execution of a function expression it might often be better to use code
such as:-
function funcName(){
function innerFunction(){
...
return something;
}
...
return (funcName = innerFunction)();
}
- and have the closure created, and any one-time configuration
performed, on the first invocation of the function. Deferring
configuration until initial use. There is a nice "Russian Doll" aspect
to this code design (and it is something that is only possible with a
dynamic language like javascript).
I have even been working one of these functions with many levels of this
nested re-configuration that I think you would appreciate, for a problem
that can only be completely decided under some conditions. Prior to
those conditions applying a 'best guess' can be used, but it is a choice
between up to 3 objects. At any point variable conditions may allow the
elimination of one, or both, of those objects, maybe allowing the code
to use only an optimum function to read properties form the one last
object.
The initial function invocation does the "gateway" testing and replaces
itself with a function that attempts to eliminate one of the objects, or
make the best guess as to which of the 3 to use temporarily. If that
function can eliminate one object it replaces itself with a function
that attempts to eliminate one of the two remaining, or guesses between
them. And when conditions allow two objects to be eliminated the
function is replaced with the function that only reports from the one
remaining object.
The initial function call may be able to fall-through to that final one
object reporting function, or find itself having to stop at an
intermediate stage, from where a subsequent call may find conditions
have changed enough to continue the process of re-configuring (refining)
towards the final function. (I promise to post the code when I have
finished properly (cross-browser) testing it).
<snip>
> ... What material are you studying these days?
Accessible scripting has been the subject of most of my recent active
research and experimentation. I have been monitoring the WAI activity
relating to scripting, though they appear to be floundering a bit at the
moment. I tend to see that as the next challenge I should be addressing
(as usual, looking for something hard enough to be interesting).
I am continuing my experiments with approaching code re-use by creating
many small, cohesive and primitive low-level cross-browser interfaces
(as I have written about a couple of times recently). Which is the
activity driving the re-configuring function ideas described above. I am
planing to write a formal description of the idea, with examples of some
of the techniques and code I have been using and where they would be
best applied.
And I have been re-reading Grady Booch's "Object-Orientated Analysis and
Design" (ISBN 0-8053-5340-2), but only while commuting (though I have
been doing a lot of that lately).
Richard.
Yann-Erwan Perio
> (...), and I have decided
> that rather than creating the containing scope inline with the one-time
> execution of a function expression it might often be better to use code
> such as:-
>
> function funcName(){
> function innerFunction(){
> ...
> return something;
> }
> ...
> return (funcName = innerFunction)();
> }
>
> - and have the closure created, and any one-time configuration
> performed, on the first invocation of the function. Deferring
> configuration until initial use. There is a nice "Russian Doll" aspect
> to this code design (and it is something that is only possible with a
> dynamic language like javascript).
That reminds me of the mouseover/load init procedure you had pointed out
before, and I realize the value of such a proposal with functions.
I was reluctant to use this pattern before though, originally because:
- the name of the function is fixed and cannot be changed independently
of the function implementation, which would break the beauty of the
interface (dynamism); I'm now ready to accept this for structuring code,
as it clearly brings a better accuracy in the init phase;
- accidental closures, where the returned inner function would keep
references to possibly useless variables; I even preferred using the
function constructor, even if the resulting code was nothing more than
ugly. This is a beginner's fault, as the closure formed can easily be
controlled.
The use you've presented with the checkbox function is an excellent
demonstration, and I intend to spend some time on this in the future.
> I have even been working one of these functions with many levels of this
> nested re-configuration that I think you would appreciate, for a problem
> that can only be completely decided under some conditions. Prior to
> those conditions applying a 'best guess' can be used, but it is a choice
> between up to 3 objects. At any point variable conditions may allow the
> elimination of one, or both, of those objects, maybe allowing the code
> to use only an optimum function to read properties form the one last
> object.
Though the concept is a direct consequence of the contingencies of
browser scripting, I still have to see a fully developped application of
the problem (although your latest scripts did have a very serious
capability-check strategy). I'll read your proposal with pleasure, as I
usually do.
> Accessible scripting has been the subject of most of my recent active
> research and experimentation. I have been monitoring the WAI activity
> relating to scripting, though they appear to be floundering a bit at the
> moment. I tend to see that as the next challenge I should be addressing
> (as usual, looking for something hard enough to be interesting).
I'd noted your interest in this matter, and the area indeed presents big
challenges. I still have to investigate the references (I've just read
the "specs" once), but doesn't feel that enthusiatic for the moment. I
think I'll experiment more with javascript scopes and functions (the
'with' technique you'd presented once, and using functions as objects to
define behaviors) before playing with advanced accessibility problems.
I feel a bit sorry not to be able to contribute more to the group these
days, all the more you've exposed lots of interesting trends (did you
notice the growing interest with javascript closures? Conceptions
patterns should start to emerge soon, based on your tireless work); I'm
on the verge of finishing a highly demanding mission and expect to come
back to javascript and browser scripting soon enough, to try all the
interesting stuff I've read these last months and, I hope, pay back the
pleasure I've had to read your articles and code:-)
Cheers,
Yep.
Richard Cornford
> Richard Cornford wrote:
>> ... . There is a nice "Russian Doll" aspect to
>> this code design (and it is something that is only
>> possible with a dynamic language like javascript).
>
> That reminds me of the mouseover/load init procedure
> you had pointed out before, and I realize the value
> of such a proposal with functions.
There is a clear line of progression through these ideas. Some of the
earliest javascript I wrote (objectively bad in retrospect) branched in
every function and method call in order to handle different browsers
(and not even that many at the time) and it didn't take much for me to
recognise what a terrible idea that was. I think I was writing with too
much of a Java mindset at the time and hadn't fully appreciated how
dynamic javascript is. Now I realise I am pushing to see how far a
dynamic language can go.
> I was reluctant to use this pattern before though,
> originally because:- the name of the function is fixed
> and cannot be changed independently of the function
> implementation, which would break the beauty of the
> interface (dynamism); I'm now ready to accept this for
> structuring code, as it clearly brings a better accuracy
> in the init phase;
I thought about the function name aspect of the two formulations. With
the function expression executed inline and returning a function object
the name used as an identifier is unimportant to the code within the
function expression. But if the function referred to by that identifier
is to be re-assigned from within that function then the name is
important and effectively fixed (or should be though of as fixed).
However, if a function name is thought of as a public interface to an
object (function object) with an internal implementation (its function
body) then the function name should be conceptually part of the object,
not independent of it (the interface belongs to its object).
The circumstances under which a change of name is most likely to be
desirable would be when there was found to be a naming conflict in the
applicable scope. But if the function name had been well chosen to start
with (to express what the function actually did) then a naming conflict
would suggest two functions that did the same task, so rather than
re-naming one the obvious solution would be to only be using one of
them.
So while it would be nice to keep the extra flexibility I really don't
think much is being sacrificed in abandoning it (and the actual
difference is that changing a name involves updating the code in several
places instead of just one (albeit and obvious one), so it still isn't
imposible).
> - accidental closures, where the returned inner function
> would keep references to possibly useless variables; I even
> preferred using the function constructor, even if the resulting
> code was nothing more than ugly. This is a beginner's fault,
> as the closure formed can easily be controlled.
Closure-wise, the most problematic aspect of the 'Russian Doll'
functions is when they need parameters that include object references.
They would be preserved in the closure formed unless actively nulled.
Making returning values form the inner function call a bit more involved
than it might otherwise be.
Often forming a closure at that level can be a useful thing to be doing.
For example, an inner function using an array (possibly of data) might
have it created in the closure and re-used by the inner function,
instead of re-creating it on each invocation (or letting it be global,
with all the extra namespace considerations that follow from global
variables).
<snip>
> (did you notice the growing interest with javascript closures?
I had noticed. I don't know how much of it is coincidence (it is maybe
just the time for the use of closures) and how much is a consequence of
the availability of an explanation of the mechanism. Google is at least
returning closures.html on the first page of search results for
javascirpt+closures now (along with the hundreds of pages on road,
school, hospital, etc, closures that include the (useless) observation
that the user's browser does not support javascript, culled from
NOSCRIPT tags. It is no wonder decent information on the subject was
hard to find.).
> Conceptions patterns should start to emerge soon, ...
What I have seen so far has been fairly simple, but maybe enough to get
the ball rolling. There does appear to be some resistance in the form of
misconception-based dogmas about the extent of additional memory use
involved and especially memory leak problems (both of which would be
diminished with a proper understanding of the mechanism), and a belief
that Safari and Konqueror do not support them (which, when pursued,
appears to be because they don't support function reference arguments
to - setTimout - (at least until recently), but we have known how to
deal with that for well over a year now. ;-)
<snip>
> ... expect to come back to javascript and browser scripting
> soon enough, to try all the interesting stuff I've read
> these last months ...
Good, you usually manage to see ways of applying these types of ideas
that never occur to me, but often inspire new lines of thought in me.
:)
Richard.
Michael Winter
wrote:
[snip]
> // Following line is like a if (...) {...} else {...}
> (chkstr) ? v.value = txtval : v.value = '';
Wouldn't
v.value = chkstr ? txtval : '';
be more sensible?
[snip]
Mike
--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail
Harag
<M.Wi...@blueyonder.co.invalid> wrote:
>On Tue, 03 Aug 2004 11:18:59 +0100, Harag <haragRE...@softhome.com>
>wrote:
>
>[snip]
>
>> // Following line is like a if (...) {...} else {...}
>> (chkstr) ? v.value = txtval : v.value = '';
>
>Wouldn't
>
> v.value = chkstr ? txtval : '';
>
>be more sensible?
>
>[snip]
>
Doh, (slaps head) yea it would :) thanks for pointing that out.
Al.