How to figure out if an input box exists without getting an error

[Stefan Mueller]

I can display the value of the following input box with
alert(parent.My Frame.document. MyForm.MyInput. value);

But if the frame, the form or the input box doesn't exist I get of course an
error message.
How can I figure out before I display the value if the frame 'MyFrame', the
form 'MyForm' and also the input box 'MyInput' exists without getting an
error message?

Stefan

[Matt Kruse]

Matt Kruse wrote:

A shorter function which does match the original functionality is:
function dec() { return (secret-- > 0); }

Uh, that's not right either, since a value of 0 would be decremented.
What you probably would need is:

function dec(){ return (secret>0 && secret-- && true); }

However, that's even less clear than the original, IMO.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Dr John Stockton]

JRS: In article <Y_************ **@news.optus.n et.au>, dated Tue, 22 Nov
2005 06:35:36, seen in news:comp.lang. javascript, RobG
<rg***@iinet.ne t.au> posted :

Interesting to note that Douglas Crockford in his article /Private
Members in JavaScript/ includes this:
function dec() {
if (secret > 0) {
secret -= 1;
return true;
} else {
return false;
}
}
which could be reduced to:

function dec() {return secret && secret--};

Well, the latter, whether right or wrong, is pretty inscrutable. OTOH I
much dislike anything resembling
if () return true ; else return false
and I'd prefer something like

function dec() { var OK = secret > 0
if (OK) secret--
return OK }

or

function dec() { var OK = secret > 0
secret -= OK
return OK }

function dec() { var OK = secret > 0
secret -= OK
return OK }
--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Richard Cornford]

Tony wrote:

It is commonly recommended that if statements that only have
a single statement following them still use a block statement,
with the single statement within that block. This avoids
confusion as to the logic of the if statement and avoids
mistakes when adding lines of code.

Hah - that's funny.

I was told about a week or so ago in alt.www.webmaster that
people who did that were "unskilled" programmers, and shouldn't
be programming.

There are many skills involved in programming. One of the more useful
ones is the ability to recognise that everyone makes mistakes and
observe that some practices significantly reduce, or remove, the
potential to make entire classes of mistakes. Saving yourself from
making (and dealing with the consequences of) unnecessary mistakes is
widely seen as a good idea.

Experience can teach you that particular practices contribute to more
effective programming, or common sense can recognise the reasoned
arguments in favour of those practices presented by more experienced
programmes.

Being able to recognise what an un-blocked - if - statement should do is
not a significant skill (it is virtually a pre-requisite for programming
at all), while being able to minimise the amount of time spent thinking
at the level of individual code statements contributes to the larger
task of programming. Humans (no matter how skilled) have a finite
ability to conceive complexity, you can appreciate more complex systems
more fully if you can avoid having to squander that ability thinking
about the lowest level details of a system. And with experience in
programming often comes the requirement to work on more complex systems.

Your (self implied)'skille d' but apparently inexperienced mentor is
setting himself up to learn why blocking - if - statements is a
recommended practice the hard way (or to never recognise it an make
the task of programming harder than it needs to be forever).

In the event that he ever finds himself working for a software house (as
a programmer) the odds are good that he will find himself having to work
to a formal coding standards document that will just say 'all - if -
statements will be blocked, end of story'. The benefits accumulate in a
collaborative environment. If it was a question of skill you would not
find experienced programmers imposing such rules on their junior
colleagues, but this is one of the coding style rules that pays off.

Richard.

[Matt Kruse]

Richard Cornford wrote:

Humans (no matter how skilled)
have a finite ability to conceive complexity, you can appreciate more
complex systems more fully if you can avoid having to squander that
ability thinking about the lowest level details of a system.

Ah, a great argument in favor of general-purpose functions and libraries!
Thanks, Richard! ;)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Thomas 'PointedEars' Lahn]

Matt Kruse wrote:

Thomas 'PointedEars' Lahn wrote:

Matt Kruse wrote:

Thomas 'PointedEars' Lahn wrote:
can and should be expressed as
if (parent.frames['MyFrame']
&& parent.MyFrame. document
Try:
if (parent.frames['MyFrame'] && parent.frames['MyFrame'].document) Yes, yes, I dare forgetting to change one property accessor which
bears almost no meaning in that context regarding any known user
agent, if that.

Your original syntax had a potential name collision with a global variable
named "MyFrame", which very well might be a realistic case, and very well
might cause a problem.

You're right, and sorry if I have been too harsh on you. It was late (or
rather early :)) However, from the feature test I used I thought/think it
to be self-evident that I just missed the correction of the original code
for that single line.
My correction was to that potential problem, and not intended to be a
complete solution for the OP.

ACK
Regards,
PointedEars

[Kevin]

Richard Cornford wrote:

In the event that he ever finds himself working for a software house (as
a programmer) the odds are good that he will find himself having to work
to a formal coding standards document that will just say 'all - if -
statements will be blocked, end of story'. The benefits accumulate in a
collaborative environment. If it was a question of skill you would not
find experienced programmers imposing such rules on their junior
colleagues, but this is one of the coding style rules that pays off.

Quite true about style rules. For example, in our group, we forbid
using the usual (to us, horrible) form of blocks:

if (foo) {
if (bar) {
do_this();
}
}

and instead mandate:

if (foo)
{
if (bar)
{
do_this()
}
}

We find it much easier to see the nesting and catch mistakes that way.
Many times the "old" ways come from the days of green screen terminals
and limited viewing space. (I come from the "enter binary code with
switches" days ;-)

The upshot is, it's not a huge deal as long as you can adapt for
different situations.

Cheers, Kev
Verizon Field Force R&D

[Richard Cornford]

Kevin wrote:

Richard Cornford wrote:

In the event that he ever finds himself working for a software
house (as a programmer) the odds are good that he will find
himself having to work to a formal coding standards document
that will just say 'all - if - statements will be blocked, end
of story'. The benefits accumulate in a collaborative environment.
If it was a question of skill you would not find experienced
programmers imposing such rules on their junior colleagues, but
this is one of the coding style rules that pays off.
Quite true about style rules. For example, in our group, we
forbid using the usual (to us, horrible) form of blocks:

if (foo) {
if (bar) {
do_this();
}
}

and instead mandate:

if (foo)
{
if (bar)
{
do_this()
}
}

We find it much easier to see the nesting and catch mistakes
that way.

In terms of being able to see the nesting I have never perceived much
difference between those two styles. I really don't like the style that
goes:-

if (foo)
{
if (bar)
{
do_this()
}
}

- because that style does seem to confuse the relationship between the
contents of a block and the statement that contains them. I also don't
like the way a statement starts at one level of indentation and ends at
another.

Ultimately I think people favour the indenting style that they are most
familiar with, or first learnt. But the benefits of everyone who is
working with the same code using the same indenting style or so obvious
that it is not surprising that organisations should impose such styles
as rules.

As it happens, if I write Java I am required to use your preferred
style. But our style rules for javascript mandate the first style,
partly because it is my preference (I had quite an influence of the
javascript style rules document and none at all over the Java document)
but justified by an explicit desire to keep syntactically similar Java
and javascript visually distinct. At least in part because the two can
appear together in JSP and it is beneficial for the language of
immediate interest to be easily identified. (At least, that is how I
sold my style preference ;)
Many times the "old" ways come from the days of green screen
terminals and limited viewing space. ...
Apart from RPG programmers working on back-office systems for financial
services, I have never even seen anyone working on a green screen.
Strangely though, our Java style document mandates that no single line
of code should be longer than 80 characters, which sounds like a
hang-over from those days.
The upshot is, it's not a huge deal as long as you can adapt
for different situations.

Obviously since it is beneficial for everyone working on the same code
to be using the same style it is necessary to be able to adapt to
whatever style rules apply. But some practices that are essentially a
matter of style are more significant than others. For example, the
(progressive) indenting of blocks is such a good idea that it should be
done regardless of the specific format that such indentation uses. I
suspect that the practice of blocking all - if - statements is more akin
to the practice of indentation in terms of its general benefits for all
programmers (in languages where it is allowed) and so more significant
than the choice of indentation format would be.

Richard.

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

Kevin wrote:

Many times the "old" ways come from the days of green screen
terminals and limited viewing space. ...

Apart from RPG programmers working on back-office systems for financial
services, I have never even seen anyone working on a green screen.
Strangely though, our Java style document mandates that no single line
of code should be longer than 80 characters, which sounds like a
hang-over from those days.

Not necessarily. For example, code is maintained on text terminals
(such as via SSH) much more easier if it does not exceed 80 characters
per line. Furthermore, as journalists well know, humans have problems
to perceive both closely wrapped and broad or unwrapped text. Thus the
80 characters per line are a reasonable agreement, adhering to both the
human condition and the technical minimum standards. (That is also why
it is not recommended to post endless long lines in Usenet, and it is
to do line-break at 72 to 76 characters on each line, facilitated by
the automatic line-break feature of most user agents.)
Regards,
PointedEars

[Jasen Betts]

On 2005-11-27, Thomas 'PointedEars' Lahn <Po*********@we b.de> wrote:

Richard Cornford wrote:

Kevin wrote:

Many times the "old" ways come from the days of green screen
terminals and limited viewing space. ...
Apart from RPG programmers working on back-office systems for financial
services, I have never even seen anyone working on a green screen.
Strangely though, our Java style document mandates that no single line
of code should be longer than 80 characters, which sounds like a
hang-over from those days.

Not necessarily. For example, code is maintained on text terminals
(such as via SSH) much more easier if it does not exceed 80 characters
per line.

most decent editors aren't fussed by the display width (or length),
I regularly run this one (jed) at over 100 columns, it handles
display resizing on the fly...

AFAIK there aren't many sighted people using fixed width displays.
Furthermore, as journalists well know, humans have problems
to perceive both closely wrapped and broad or unwrapped text.
Thus the 80 characters per line are a reasonable agreement,

I read some RFC that suggeested 65 characters as a line length limit.

Bye.
Jasen