By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,665 Members | 2,212 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,665 IT Pros & Developers. It's quick & easy.

Cursor missing input box

P: n/a

We have a problem demonstrated by the following HTML document.
To see the problem type HV in the first field then use the mouse cursor to
click into the Staff code input box.
You will find that the cursor has ended up in the prompt field rather than
the input.
I think it is due the table dynamically resizing when the description is
added to the second cell, so where your cursor clicked no longer contains
the location of the input box. Is there a fix for this, or a way round it
but we would still like to have dynamic tables ?

Here is the HTML to test it:

<html>
<head>
<TITLE>TEST OF TABLE CHANGE</TITLE>
<SCRIPT TYPE="text/javascript">
function STypeChange() {
switch (document.all.VCLTY.value) {
case 'HV':
document.all.displaydesVCLTY.innerText = ' Health Visitor';
break;
case 'GP':
document.all.displaydesVCLTY.innerText = ' General Practitioner';
break;
default:
document.all.displaydesVCLTY.innerText = '';
break;
}
}
function SCodeChange() {
switch (document.all.VCL.value) {
case 'HV01':
document.all.displaydesVCL.innerText = ' Mary Jane Lewis';
break;
case 'GP01':
document.all.displaydesVCL.innerText = ' Dr BOB JONES';
break;
default:
document.all.displaydesVCL.innerText = '';
break;
}
}
</SCRIPT>
</head>
<body>
TABLE TEST
<BR>
<table width=100% border=0>
<tr>
<td>Staff Type</td><td><INPUT TYPE="TEXT" NAME="VCLTY" SIZE=6
ONCHANGE="STypeChange()"><span id='displaydesVCLTY'
class='TITLE1'></span></td>
<td id='codecell'>Staff Code</td><td><INPUT TYPE="TEXT" NAME="VCL" SIZE=6
ONCHANGE="SCodeChange()"><span id='displaydesVCL'
class='TITLE1'></span></td>
</tr>
</table>
</body>
</html>
Jul 20 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
"Gary Holt" <ga*******@operamail.com> wrote:
We have a problem demonstrated by the following HTML document.
A URL is more friendly than a chunk of code, and you do want us to be
friendly, don't you?
To see the problem type HV in the first field then use the mouse cursor to
click into the Staff code input box.
You will find that the cursor has ended up in the prompt field rather than
the input.
Problem in IE6. No problem in Opera 7. No problem in Mozilla 1.6 but
the text doesn't appear either. document.all is a Microsoftism and is
not supported by all browsers. And what happens for visitors with no
JS at all?
I think it is due the table dynamically resizing when the description is
added to the second cell, so where your cursor clicked no longer contains
the location of the input box. Is there a fix for this, or a way round it
but we would still like to have dynamic tables ?


Specify the column widths in percentages. They'll still flex with the
page width but will remain fixed as text is added of removed to the
individual cells.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #2

P: n/a
>We have a problem demonstrated by the following HTML document.

A URL is more friendly than a chunk of code, and you do want us to be
friendly, don't you?
[Griffiths, Wendy] Sorry for the code, but the page is behind our firewall.
To see the problem type HV in the first field then use the mouse cursor to
click into the Staff code input box.
You will find that the cursor has ended up in the prompt field rather than
the input.
Problem in IE6. No problem in Opera 7. No problem in Mozilla 1.6 but
the text doesn't appear either. document.all is a Microsoftism and is
not supported by all browsers. And what happens for visitors with no
JS at all?
[Griffiths, Wendy] I thought as much. I'm not at all surprised that it is
only a problem in IE, but thanks for confirming that. The page is part of a
web application we are producing, so we dictate what browser the
user must use to access it and we specify that it's only compatible with IE.
I think it is due the table dynamically resizing when the description is
added to the second cell, so where your cursor clicked no longer contains
the location of the input box. Is there a fix for this, or a way round
it
but we would still like to have dynamic tables ?


Specify the column widths in percentages. They'll still flex with the
page width but will remain fixed as text is added of removed to the
individual cells.
[Griffiths, Wendy] Unfortunately that's not an option. Because of the
nature
of the beast the contents of each cell is variable. It's dynamically
generated
on the fly, so we can not specify specific widths as they might not
accommodate
the contents, so it is appropriate that IE decide what space to allocate.
[Griffiths, Wendy] Thanks for looking at it anyway.
Jul 20 '05 #3

P: n/a
Gary Holt (or Wendy Griffiths) wrote:
I thought as much. I'm not at all surprised that it is
only a problem in IE, but thanks for confirming that. The page is part of a
web application we are producing, so we dictate what browser the
user must use to access it and we specify that it's only compatible with IE.


Why? Inability to write decent code?

Think what happens a few years down the line when the company chucks out
Microsoft. Oh, wait - you get paid to upgrade your application so it works...

--
Mark.
Jul 20 '05 #4

P: n/a
"Gary Holt" <ga*******@operamail.com> wrote:
A URL is more friendly than a chunk of code, and you do want us to be
friendly, don't you?
[Griffiths, Wendy] Sorry for the code, but the page is behind our
firewall.


What on &Planet; are you talking about? You have some very strange
quotation style, which makes your message mostly an enigma: who's saying
what, and how does Wendy Griffiths relate to the discussion?

Anyway, if you cannot post a URL, you can hardly have a question about a
specific page relating the HTML authoring for the _World Wide Web_.
And quite evidently your question was about JavaScript, not HTML. Whether
it's the question you _should_ be asking is a different matter...

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #5

P: n/a
Sorry if we have used the wrong news group, to clear up the matter Wendy and
myself (Gary) are the developers of a web engine ! Developers then use a vb
front end developed by our selved to configure a database, with the end
result being a dynamical/on the fly web pages based on a database tables for
each user of our web application.
As the application will only be on corporate intranets at present we are
only using IE but with time we hope to add other browsers to the engine.

Sorry that for not being able to post a url but as typical for large firms
we have fire walls stopping us from doing this.
Jul 20 '05 #6

P: n/a
Gary Holt wrote:
As the application will only be on corporate intranets at present we are
only using IE but with time we hope to add other browsers to the engine.


Get it right first time, or all of your future work will be spaghetti code
to try to work around all the IE-specific stuff you've written.

--
Mark.
Jul 20 '05 #7

P: n/a
Mark,

Just to clarify, we do not code any of the web pages. They are all generated
on the fly dynamicaly by our problem, therefore
we will just need to revisit parts of our engine.

Gary
Jul 20 '05 #8

P: n/a
"Gary Holt" <ga*******@operamail.com> wrote:
Just to clarify, we do not code any of the web pages. They are all generated
on the fly dynamicaly by our problem,
Typos can be very telling.
therefore we will just need to revisit parts of our engine.


You should be aware that the standard compliant way of doing things
document.getElementById() is supported by IE5+, Gecko (hence NN6+,
Mozilla, Camino, FireFox, etc.), Opera, Safari, etc. whilst the
document.all method you use is only supported by IE4+ and Opera 7.

So unless you think that you'll have more potential end users with IE4
than all the other browsers put together why go with the non-standard
technique?

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #9

P: n/a
On Wed, 12 May 2004 09:26:11 GMT, Gary Holt <ga*******@operamail.com>
wrote:
we do not code any of the web pages. They are all generated
on the fly dynamicaly by our problem,


That is the funniest typo I've read all week.
Jul 20 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.