If I have a simple <input type="text"> and never mess with its value property, I can undo (and redo) my actions at will [I mean, keyboard typing and clipboard cut and paste].
But once some event sets its value the undo stack is gone. I understand that for an arbitrary event it would be very hard (and unnatural, from user perspective) to define how the undo stack should cope with changes introduced by direct attribution to value.
But I'm thinking about edit events, like <input>'s own input and paste events (to give you some context, I'm planning to apply some field masking).
Is it possible to change the object associated with the event (InputEvent and ClipboardEvent) instead of manipulating the value property, so the stack can be preserved? Or otherwise inform "the stack" programmatically how to "undo from here"?
Related
To my knowledge, read-only fields are used primarily by keyboard-only users so they can focus on the input and copy/paste containing value. But what about fields with no value? Should those be treated as disabled since they don't carry any information to the user and from that point of view, it's same like having a disabled button.
Edit:
Those fields are metadata from various sources and if they are empty, most likely it's not even important what they represent because it doesn't add any value to the context, if they can't be updated.
Short Answer
No they should be left as readonly.
Long Answer
You need to think about when to use each one:
readonly
readonly fields are to display information back to people.
If that field happens to be blank it should still be returned as people can see that the field exists and contains no information.
This is the same for people who use a screen reader, they get to the field, see it is readonly, get the field announced and that it is currently empty. All useful information.
This information will automatically be read out when the form is being read back as well which is useful.
disabled
disabled, however, implies that the field cannot be modified at this moment.
Some screen readers do not read these out by default unless you specifically focus the field with JS etc.
VoiceOver will skip disabled fields - this is not useful if you need the information to be accessible (for example if this is confirmation of previously entered information, skipping an entire field could cause confusion and cause people to go back to check they hadn't missed something on the form).
So which should you use for an empty field?
readonly if this is relaying information back to a user. They can still focus the field, hear the field label and that it is empty.
disabled if this control currently serves no purpose on the page (and is not likely to!) as it will be skipped entirely.
disabled should be used with caution due to the point I mentioned earlier that some screen readers (VoiceOver) will skip disabled fields..
Generally the rule is - does the user need to know that the field was left / is blank - use a readonly. Is this field not going to be used / not relevant while inputting information, use disabled.
If in doubt use readonly, it will cause less harm than an erroneous disabled attribute.
I was slightly surprised to find out that the onChange event in an html document is fired on a text input or textarea not at the very moment when its value actually changes, but only when focus leaves the element (if its value has changed, of course).
So I was looking for the specification that states that, and I can't find it. I can find millions of tutorials explaining that, including W3Schools' ones, but I can't find the standard that defines when the event is expected to be fired.
In the HTML5 specification itself, the event's name is listed but nothing is said about it:
http://www.w3.org/html/wg/drafts/html/master/
In this other spec, "DOM level 3 Events Specification", it is not even mentioned:
http://www.w3.org/TR/DOM-Level-3-Events/
So what is the standard that defines it?
It's briefly mentioned in the Intrinsic events section of the W3C 4.01 specification:
"The onchange event occurs when a control loses the input focus and its
value has been modified since gaining focus".
It's also mentioned a little more extensively on MSDN:
"This event is fired when the contents are committed and not while the
value is changing. For example, on a text box, this event is not fired
while the user is typing, but rather when the user commits the change
by leaving the text box that has focus.
In addition, this event is executed before the code specified by onblur when the control is also
losing the focus."
Finally, on the MDN:
Depending on the kind of the form element being changed and the way
the user interacts with the element, the change event fires at a
different moment:
When the element is activated (by clicking or using the keyboard) for <input type="radio"> and <input type="checkbox">;
When the user commits the change explicitly (e.g. by selecting a value from a <select>'s dropdown with a mouse click, by selecting a date from a date pickier for <input type="date">, by selecting a file
in the file picker for <input type="file">, etc.);
When the element loses focus after its value was changed, but not committed (e.g. after editing the value of <textarea> or <input type="text">).
Another potentially useful link - WhatWg - specification - change event.
I think I'm looking directly at an Access 2003 bug. Here's what I did (I think):
I'm developing a Continuous Form (i.e. multiple records per page).
I have an unbound textbox in the background of the Details section. Under Data Properties, I have Enabled=No and Locked=Yes. (In other words, I don't want the user to select it. I only want it for the background color)
This textbox also has some conditional formatting to change the background color for that row. (e.g. If we haven't spoken to that customer in awhile, the background for that record is red)
If I choose a record where the conditional formatting is active (i.e. the background is red), I can actually click on this textbox. There's not much that I can do, of course, but this shouldn't happen and surely would be confusing to the end-users.
Has anyone else seen this? What's your workaround?
Enabled is a property that can be controlled via conditional formatting. By default when you add a new condition, the Enabled property is set to True. If you don't want your control to be enabled you must explicitly set Enabled = False within the conditional formatting rule.
The property is toggled via a button in the lower right corner of the conditional formatting dialog. It's easy to miss (I forget about it all the time).
Personally, I think the property should be three-way: True, False, or Inherit (with Inherit as the default). Unfortunately, Access forces you to be explicit when adding conditional formatting rules and state whether the rule should make the control Enabled or Disabled.
Here's my workaround (I was waiting to see if anyone else would suggest something better. Apparently not.)
In my conditionally formatted textbox, add an Event Procedure for GotFocus. Enter this code: Me.Txt_FocusHere.SetFocus.
Make a 2nd unbound text box somewhere on the form. Shrink it until it's just 1 line thick. Call it Txt_FocusHere.
So whenever the user clicks on the colored background, the focus is immediately taken to this dummy textbox which can't store any data and is so small that the user doesn't see the blinking cursor.
I successfully used the method on the following page: http://www.mvps.org/access/forms/frm0047.htm - "Changing the Background Color of the Current Record in a Continuous Form"
Working in both A2003 & A2007.
How do we ensure that a selected TextBox gets the focus when the form loads? If we put MyTextBox.SetFocus in the Form_Load then we get the error:
can't move the focus to the control
This form is designed for rapid data entry, and the form somewhat rearranges itself based on the last used settings. So there are several different textboxes any of which may need the focus depending on the user. We can't just fix it in design time by giving MyTextBox TabIndex=0.
The help says something about calling Repaint which just doesn't make any sense at all:
You can move the focus only to a
visible control or form. A form and
controls on a form aren't visible
until the form's Load event has
finished. Therefore, if you use the
SetFocus method in a form's Load event
to move the focus to that form, you
must use the Repaint method before the
SetFocus method.
The best bet in this case, is to ensure that the textbox to get focus is numbered 0 in the Tab Index property.
You cant set the focus as the controls don’t really exist yet, try putting the code in the OnActivate event instead
Or just put a DoCmd.Repaint in the OnLoad event before trying to set the focus. Both should work but I'm not near a computer to check
In my experience, I've always gotten that error when the control I was trying to set focus to was either 1)not visible or 2)not enabled. I assume you've already checked those, but it would be worth double checking at runtime when you get the error message (especially since you said you are shuffling the controls at runtime).
I use the .SetFocus method pretty regularly without trouble. I don't recall ever getting an error message when setting focus to a control that already has it as Remou stated in his answer.
I believe there is also a third case that occurs if you try to set focus to a control in the form header/footer of a bound form that has had all of its records filtered out. I know that situation causes "disappearing" contents in an unbound combo box, but I think it may also play havoc with the SetFocus method. If you are opening the form in Data Entry mode, though, that should not be an issue.
Move SetFocus to the form's On Current event. Should work then unless perhaps the form's record source contains no records and you've set the form's Allow Additions property to No. In that case your text box will not be available to SetFocus on, but in my testing it doesn't throw an error.
I have an input tag. This tag does not have the autocomplete feature turned off, thus, one does not necessarily need to release a key to change the value of this field and focus another one. My question is: how can I detect ANY value changes of this particular field, like e. g.
<input onvaluechange="//do following..." />
The JavaScript attribute onchange does not fire on change of value, only on changes like blur, focus, etc...
EDIT: It also doesn't necessarily be a key press. Due to the autocompletion, the user can simply mouse-click the autocompletion result to change the value. This would not fire an onkeydown event.
It also doesn't necessarily be a key press. Due to the autocompletion
...and many other non-key-based operations, such as right-click-cut/paste, drag and drop, undo/redo, spellchecker adjustments and so on.
HTML5 defines an oninput event to catch all direct changes.
Unfortunately browser support today isn't there (no support in IE, and there are some bugs in others), so all you can do if you really need to detect all changes to an input value earlier than onchange is to use setInterval to add a poller that constantly compares against the previous value.
Detecting "value" of input text field after a keydown event in the text field?
I had a similar problem and binding to a dozen of different events just doesn't cut it, since there are so many different ways of changing input value, as bobince noted.
So - I ended up writing dead simple jQuery monitoring plugin that's generic in nature.
With it you can monitor input value changes, textarea text changes, div content changes, etc:
https://github.com/nixd3v/monitor
Tracking div content changes:
$.monitor('add', function(){return $("div#someDiv").html()}, function(){
console.log('Div content changed');
});
Tracking input value changes:
$.monitor('add', function(){return $("#password").val()}, function(){
console.log('input value changed');
});
It also uses a loop of course, however, not through setInterval, but rather through using setTimeout along with a self-executing anonymous function:
(function(){
// do some stuff
setTimeout(arguments.callee, 100);
})();
What this does - this guarantees, that the next call is not made before your code was executed. If you use polling in your code - this is the right way of doing it.
You can use the onKeyPress attribute to monitor changes typed in by the user.
For example:
<input type='input' onKeyPress='SomeScriptMethod();'>