Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > HTML > Clicking on Disabled Controls: What Happens?

Reply
Thread Tools

Clicking on Disabled Controls: What Happens?

 
 
Evertjan.
Guest
Posts: n/a
 
      04-16-2012
Gene Wirchenko wrote on 16 apr 2012 in comp.lang.javascript:

> On 14 Apr 2012 10:35:50 GMT, "Evertjan."
> <(E-Mail Removed)> wrote:
>
>>Gene Wirchenko wrote on 13 apr 2012 in comp.lang.javascript:
>>> This is posted to both comp.lang.javascript and alt.html, because
>>> it might have to do with either JavaScript or HTML. I expect that it
>>> is the former, but.

>>
>>> My form handler is coming along slowly, but the results are nice.
>>> I am now adding buttons for handling modes (adding, updating,
>>> deleting). When data entry is being done, only some of the controls
>>> are enabled. If a button or input control is disabled, it can get
>>> weird.

>>
>>Only if your code does not account for those states.
>>I suggest you write code that incorporates all possible states.

>
> How fatuous!
>
> Of course, I am trying to write code that handles all possible
> cases.


But why "weird"?

Surely it is not weird if you do not incorporate certain states.
The results then follow whatever is the way single browser tries
to second guess you.

> That is why I post questions to these newsgroups.


Why are again and again prescribing the confine of the responses.

At least my responses are not answers because this is usenet, and not a
helpdesk.

>
>>> Suppose that DE is being done. Call the current input control
>>> Workpoint.

>>
>> What is DE?

>
> A common abbreviation in the industry for "Data Entry".


What "the" industry?

This is a NG for javascriipt adepts and javascript casual interested,
not specialized for the industrious of an industry,
though they are welnome too,
as long as they not claim the local linguo.

I seem to remember a similar claiming by another group,
some transponders, on linguo, equally not done.


>> What is Workpoint?

>
> Reread the second sentence of the paragraph.
> [snip]
>
> You sure work hard to misunderstand.


You sure work hard to upset the NG-ers that try to help,
not only you, but also or moreso others
that think they have questions like yours.

So prescribing we do not need to address cross-browser issues and not to
address the user-unfriendliness of your validation-routine does not hold
for a NG.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
 
Reply With Quote
 
 
 
 
Gene Wirchenko
Guest
Posts: n/a
 
      04-16-2012
On Mon, 16 Apr 2012 18:52:52 +1000, Jeff North <(E-Mail Removed)>
wrote:

>On Sun, 15 Apr 2012 20:51:42 -0700, in comp.lang.javascript Gene
>Wirchenko <(E-Mail Removed)>
><(E-Mail Removed)> wrote:
>
>>| On Sat, 14 Apr 2012 23:58:59 +1000, Jeff North <(E-Mail Removed)>
>>| wrote:


[snip]

>>| >You need to tell the browser which control is to have focus.
>>|
>>| First, I need to detect that I have to.

>
>Incorrect. YOU need to keep track of what controls have the focus so
>you can return to it if there is an error or such.


I do keep track of it. What I need to detect is that a disabled
item has been clicked on. Then, I could shift focus back. I
currently know of no way to detect this.

>>| The onfocus for the
>>| disabled control (if it is a control that is clicked on) does not
>>| fire.

>
>And that is standard GUI practice. If you think about it, why should a
>disabled control react to anything because if it did then it wouldn't
>be disabled.


Exactly, but the focus still shifts. It would make more sense to
me if clicking on something disabled did not case a focus shift. Think
about it for a moment. If something is disabled, why should it do
anything?

>>| If it did, I could simply check that the control was disabled,
>>| and if so, then push the focus back.
>>|
>>| Though, if the click is on something not a control, that approach
>>| would not work. (Maybe, there is something DOMish that would solve
>>| this. I do not know much about manipulating via the DOM.)
>>|
>>| I need to know where to put the code to set the focus back. Since
>>| I am unable to detect which object is getting focus, becoming active,
>>| or whatever it is, I do not know where to put the code.

>
>Try the onFocus event to store the control's name.


I already know which control had the focus (Workpoint). I need
to detect that the focus is going to go into the weeds. After all, it
is sometimes perfectly legitimate for focus to go off a control -- A
field's validation does succeed sometimes -- and I need to
diferentiate the cases.

>>| >>| The focus, despite not showing on the form, can be moved. If I
>>| >>| press [Tab] immediately after this, the focus moves to the first
>>| >>| enabled control on the form. This is weird.
>>| >
>>| >Not really, the focus is where you last clicked.
>>|
>>| Actually, no. I can click on a disabled input control later on
>>| the form, then tab, and the focus moves to the first enabled control,
>>| and this is before both Workpoint and the control just clicked on.

>
>And that is the way it should work. The disabled control has the
>(invisible) focus so when you press the tab key the focus moves to the
>next non-disabled control (as you have amply demonstrated).


Well, no. As I have posted, tabbing does not move to the next
non-disabled control but rather to the FIRST non-disabled control.

[snip]

>It is - stop fighting the GUI and your life will be much simpler.


I want the GUI to work for my end users. At this point, clicking
in weird places causes weird things. I want to avoid this. Why does
the GUI make this so difficult?

I also do not want the workflow messed up. If someone
accidentally clicks on Add while updating a row, I would rather than
nothing happened. The GUI makes this difficult.

>Have you looked at the HTML5 attributes of placeholder and required?


No.


If worse comes to worse, I may simply give up on the disabled
property. I could come up with two versions of CSS for each control:
normal and pseudo-disabled. In the pseudo-disabled, the control would
get the focus, I could detect that the control is not live, and I
could then send the focus back where it belongs. Mind you, this would
not solve the problem of a click where there is no control.

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
 
 
 
Neil Gould
Guest
Posts: n/a
 
      04-16-2012
Gene Wirchenko wrote:
[big snip]
> I do keep track of it. What I need to detect is that a disabled
> item has been clicked on. Then, I could shift focus back. I
> currently know of no way to detect this.
> [...]
>
> Exactly, but the focus still shifts. It would make more sense to
> me if clicking on something disabled did not case a focus shift. Think
> about it for a moment. If something is disabled, why should it do
> anything?
>

Why is it necessary to display disabled items? I realize that you would like
to have a stable UI for your users, but it may be possible to achieve that
by only presenting relevant options. Two other ideas are to provide a
bell/buzzer event for disabled items, or to use graphic elements that look
like the disabled items but can't be clicked on and won't be part of the tab
order.

--
best regards,

Neil



 
Reply With Quote
 
Tim Streater
Guest
Posts: n/a
 
      04-16-2012
In article <jmhk1v$j3k$(E-Mail Removed)>,
"Neil Gould" <(E-Mail Removed)> wrote:

> Gene Wirchenko wrote:
> [big snip]
> > I do keep track of it. What I need to detect is that a disabled
> > item has been clicked on. Then, I could shift focus back. I
> > currently know of no way to detect this.
> > [...]
> >
> > Exactly, but the focus still shifts. It would make more sense to
> > me if clicking on something disabled did not case a focus shift. Think
> > about it for a moment. If something is disabled, why should it do
> > anything?
> >

> Why is it necessary to display disabled items? I realize that you would like
> to have a stable UI for your users, but it may be possible to achieve that
> by only presenting relevant options.


I display disabled items in order to display the data to the user. When
they want to edit it, and have the edits be saved, they click the 'Edit'
button, part of the effect of which is to enable all those disabled
textareas. The user then edits, and clicks 'Save'. Part of the tidy-up
action is then to disable the textareas again.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
 
Reply With Quote
 
Jonathan N. Little
Guest
Posts: n/a
 
      04-16-2012
Gene Wirchenko wrote:
> On Mon, 16 Apr 2012 18:52:52 +1000, Jeff North<(E-Mail Removed)>
> wrote:
>
>> On Sun, 15 Apr 2012 20:51:42 -0700, in comp.lang.javascript Gene
>> Wirchenko<(E-Mail Removed)>
>> <(E-Mail Removed)> wrote:
>>
>>> | On Sat, 14 Apr 2012 23:58:59 +1000, Jeff North<(E-Mail Removed)>
>>> | wrote:

>
> [snip]
>
>>> |>You need to tell the browser which control is to have focus.
>>> |
>>> | First, I need to detect that I have to.

>>
>> Incorrect. YOU need to keep track of what controls have the focus so
>> you can return to it if there is an error or such.

>
> I do keep track of it. What I need to detect is that a disabled
> item has been clicked on. Then, I could shift focus back. I
> currently know of no way to detect this.


IF it is disabled it cannot obtain focus so you "detect" it by detecting
the focus is *not* on it.

>
>>> | The onfocus for the
>>> | disabled control (if it is a control that is clicked on) does not
>>> | fire.

>>
>> And that is standard GUI practice. If you think about it, why should a
>> disabled control react to anything because if it did then it wouldn't
>> be disabled.

>
> Exactly, but the focus still shifts. It would make more sense to
> me if clicking on something disabled did not case a focus shift. Think
> about it for a moment. If something is disabled, why should it do
> anything?



It shifts but not to the disabled control. Use tab or click and see for
yourself:


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>template</title>
<script type="text/javascript">
function announce(me){
var msg=document.getElementById('status');
msg.firstChild.nodeValue='Focus on ' + me.id;
}
</script>

</head>
<body>

<form>
<ul>
<li id="status">Status</li>
<li>
<label>foo</label>
<input type="text" name="foo" id="foo" onfocus="announce(this)">
</li>
<li>
<label>bar</label>
<input type="text" name="bar" id="bar" disabled onfocus="announce(this)">
</li>
<li>
<label>baz</label>
<input type="text" name="baz" id="baz" onfocus="announce(this)">
</li>
<li>
<label>bin</label>
<input type="text" name="bin" id="bin" onfocus="announce(this)">
</li>
</ul>
</form>

</body>
</html>


--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ASP.NET 2.0 Buttons allowed to be disabled after clicking Rick ASP .Net Web Controls 0 06-07-2005 03:56 AM
I want to be able to access the internet by opening my browser and not right clicking and then clicking connect. James Johnson Computer Support 1 05-15-2004 03:40 AM
Mozilla not responding whem clicking on a link Johan Firefox 9 01-09-2004 12:48 PM
Firebird: Clicking mouse wheel on xml page makes window go blank. Quivis Firefox 4 12-30-2003 09:14 PM
clicking on links LaBulle Firefox 1 08-27-2003 08:22 PM



Advertisments