Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #12486 > unrolled thread

Restoring Control

Back to article view | Back to comp.lang.javascript

Contents

  Restoring Control Gene Wirchenko <genew@ocis.net> - 2012-03-07 17:11 -0800
    Re: Restoring Control Scott Sauyet <scott.sauyet@gmail.com> - 2012-03-08 04:39 -0800
      Re: Restoring Control Gene Wirchenko <genew@ocis.net> - 2012-03-08 08:17 -0800
        Re: Restoring Control Scott Sauyet <scott.sauyet@gmail.com> - 2012-03-10 17:45 -0800
          Re: Restoring Control Gene Wirchenko <genew@ocis.net> - 2012-03-10 23:53 -0800
            Re: Restoring Control Mike Duffy <Use_guestbook_page@website.in.sig> - 2012-03-11 16:54 +0000
              Re: Restoring Control Gene Wirchenko <genew@ocis.net> - 2012-03-11 20:52 -0700
                Re: Restoring Control Dr J R Stockton <reply1211@merlyn.demon.co.uk.not.invalid> - 2012-03-13 18:36 +0000
                  Re: Restoring Control Gene Wirchenko <genew@ocis.net> - 2012-03-13 19:49 -0700
      Re: Restoring Control David Mark <dmark.cinsoft@gmail.com> - 2012-03-12 16:55 -0700

#12486 — Restoring Control

Dear JavaScripters:

     In my form handler, I have a form reset.  This is confirmed using
confirm().  That causes the focus to move.  If the reset is confirmed,
then it is no matter: the form will be reinitialised.

     If the reset is denied, then I restore focus to the control that
had it just before then.  Unfortunately, this causes the onfocus code
to execute which .select()s the entire value (which is usually what is
wanted).

     What I would like to have happen in this case is that the
previous status of the control is restored.  The previous status that
I am concerned with is cursor position and what text is selected.

     How can I do this?  Is there a browser-independent way to do
this?

     What I have found seems to indicate that IE and Firefox have
different ways, and I am not sure exactly what the code does.

     Note that I am not concerned with getting said data but restoring
it.

     A good pointer would be very much appreciated.

     I have found a way that appears to work by using a couple of
globals, but I may need to be able to select very specific parts of a
control value so I am still interested.

Sincerely,

Gene Wirchenko

[toc] | [next] | [standalone]

#12493

On Mar 7, 8:11 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>      In my form handler, I have a form reset.  This is confirmed using
> confirm().  That causes the focus to move.  If the reset is confirmed,
> then it is no matter: the form will be reinitialised.
>
>      If the reset is denied, then I restore focus to the control that
> had it just before then.  Unfortunately, this causes the onfocus code
> to execute which .select()s the entire value (which is usually what is
> wanted).
>
>      What I would like to have happen in this case is that the
> previous status of the control is restored.  The previous status that
> I am concerned with is cursor position and what text is selected.
>
>      How can I do this?  Is there a browser-independent way to do
> this? [ ... ]

If as you say (in the bit I've elided), you know how to get this data,
then there is almost certainly a way to restore it.  You might look,
for instance, at the Range API. [1]  I don't know the current state of
browser support.  (The last time I had to deal with ranges was in
2004, I think!)  But there's at least one polyfill for older versions
of IE. [2]

But are you sure this is the required behavior?  If a user
intentionally focuses on a reset button, even if she later changes her
mind, she's not likely to expect that her cursor position and
selection would be retained.  Even setting focus on her last-focused
control seems odd to me.  It's your dime and your decision, but do
think carefully about user expectations here.

  -- Scott

[1] http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ranges.html
[2] http://code.google.com/p/ierange/

[toc] | [prev] | [next] | [standalone]

#12501

On Thu, 8 Mar 2012 04:39:10 -0800 (PST), Scott Sauyet
<scott.sauyet@gmail.com> wrote:

>On Mar 7, 8:11 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>>      In my form handler, I have a form reset.  This is confirmed using
>> confirm().  That causes the focus to move.  If the reset is confirmed,
>> then it is no matter: the form will be reinitialised.
>>
>>      If the reset is denied, then I restore focus to the control that
>> had it just before then.  Unfortunately, this causes the onfocus code
>> to execute which .select()s the entire value (which is usually what is
>> wanted).
>>
>>      What I would like to have happen in this case is that the
>> previous status of the control is restored.  The previous status that
>> I am concerned with is cursor position and what text is selected.
>>
>>      How can I do this?  Is there a browser-independent way to do
>> this? [ ... ]
>
>If as you say (in the bit I've elided), you know how to get this data,

     No, I do not.  I have figured out, in the current case, how to
not lose this status, at least on IE9.  I expect to need more in the
very short term.  See my thread about date entry.

>then there is almost certainly a way to restore it.  You might look,
>for instance, at the Range API. [1]  I don't know the current state of
>browser support.  (The last time I had to deal with ranges was in
>2004, I think!)  But there's at least one polyfill for older versions
>of IE. [2]
>
>But are you sure this is the required behavior?  If a user
>intentionally focuses on a reset button, even if she later changes her
>mind, she's not likely to expect that her cursor position and
>selection would be retained.  Even setting focus on her last-focused
>control seems odd to me.  It's your dime and your decision, but do
>think carefully about user expectations here.

     I would expect that.  My users probably will, too.  The users
will be coming from a desktop app.  One of the weirdnesses of the Web
is that pages often have significantly less control over the input
controls than a desktop app has over its input fields, *AND* this is
simply accepted as a so-called cost of using the Web.  It does not
have to be that way, though it is a fight to get away from it.

>[1] http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ranges.html
>[2] http://code.google.com/p/ierange/

     Thank you for the links.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12591

Gene Wirchenko wrote:
> Scott Sauyet wrote:
>> Gene Wirchenko wrote:

>>> [on canceling a form reset] I restore focus to the control that
>>> had it just before then.  Unfortunately, this causes the onfocus code
>>> to execute which .select()s the entire value (which is usually what is
>>> wanted).
>
>>>      What I would like to have happen in this case is that the
>>> previous status of the control is restored.  The previous status that
>>> I am concerned with is cursor position and what text is selected.
>
>> [A]re you sure this is the required behavior?  If a user
>> intentionally focuses on a reset button, even if she later changes her
>> mind, she's not likely to expect that her cursor position and
>> selection would be retained.  Even setting focus on her last-focused
>> control seems odd to me.  It's your dime and your decision, but do
>> think carefully about user expectations here.
>
>      I would expect that.  My users probably will, too.  The users
> will be coming from a desktop app.  One of the weirdnesses of the Web
> is that pages often have significantly less control over the input
> controls than a desktop app has over its input fields, *AND* this is
> simply accepted as a so-called cost of using the Web.  It does not
> have to be that way, though it is a fight to get away from it.

There is a tension between faithfully recreating the desktop
experience in the browser and using the browser's behavior to create a
common experience across a multitude of interfaces.  There is of
course no single best way to resolve that tension.  But the more you
try to override the default browser behavior, especially in how form
elements are handled, the harder it will be for new people to learn
how to use your system.

Sometimes that's fine.  I worked on a large system to replace an old
green-screen interface, and we slavishly copied all sorts of mainframe
input control behavior so that it was easier for current workers to
transition to the new system.

But we also created in parallel a more modern web interface, using
standard HTML controls with the addition of some drag-and-drop and
several custom-built widgets.  New data-entry hires were trained with
this interface.  The training time was reduced from eight weeks to
three.  When I left the project, there were still more people on the
older-style system than on the more modern one, and they were more
efficient as well.  But there was a small control group of new
trainees who went through the older-style training.  Of course, the
people on the newer system were working sooner than those on the
other.  But those on the new system were more efficient than those on
the older one with the same number of post-training weeks or
experience.  Although I was gone by then, I did learn that this
efficiency difference lasted for at least the first year of work.

The people working on the green-screen application and our port of it
still did not like the new app.  They found it too hard to use and
missed their favorite shortcuts.  The company, as far as I know was
not planning on trying to convert them over, but they no longer train
new recruits with it.  Those working on the standard web interface can
more easily move to other systems, as any new vendor systems have web
interfaces as well.

That's why I suggest that you consider this seriously.  Even if the
current experience can be entirely duplicated, it might still be
better to consider the simplicity of the standard web interface.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#12593

On Sat, 10 Mar 2012 17:45:58 -0800 (PST), Scott Sauyet
<scott.sauyet@gmail.com> wrote:

[snip]

>There is a tension between faithfully recreating the desktop
>experience in the browser and using the browser's behavior to create a
>common experience across a multitude of interfaces.  There is of
>course no single best way to resolve that tension.  But the more you
>try to override the default browser behavior, especially in how form
>elements are handled, the harder it will be for new people to learn
>how to use your system.

     The standard behaviour is to throw it all to the winds.  I want
more control.

[snip]

>That's why I suggest that you consider this seriously.  Even if the
>current experience can be entirely duplicated, it might still be
>better to consider the simplicity of the standard web interface.

     I am not interested in duplicating the existing app's behaviour,
but I do want to enable head-down data entry and have good front-end
data validation.

     Too many Websites are hostile to data entry, sometimes rather
nastily so.  I do not think that going to the Web should have to mean
throwing out successful models of DE.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12598

Gene Wirchenko <genew@ocis.net> wrote in 
news:n8mol79fnr2ro651qhqh8amemgbhbc148s@4ax.com:

> 
> Too many Websites are hostile to data entry, sometimes rather
> nastily so.

Like the ones that don't let you go back and change values in a previous 
page?

The worst are the ones that give script error messages and pop-up a window 
asking if you want to debug the script. Usually this happens after you have  
entered credit card info, and it is not clear if the financial transaction 
has yet been posted.

-- 
http://pages.videotron.ca/duffym/index.htm

[toc] | [prev] | [next] | [standalone]

#12604

On Sun, 11 Mar 2012 16:54:09 +0000 (UTC), Mike Duffy
<Use_guestbook_page@website.in.sig> wrote:

>Gene Wirchenko <genew@ocis.net> wrote in 
>news:n8mol79fnr2ro651qhqh8amemgbhbc148s@4ax.com:
>
>> 
>> Too many Websites are hostile to data entry, sometimes rather
>> nastily so.
>
>Like the ones that don't let you go back and change values in a previous 
>page?

     I was not even thinking of that, but those would make it onto a
Bad List.

>The worst are the ones that give script error messages and pop-up a window 
>asking if you want to debug the script. Usually this happens after you have  
>entered credit card info, and it is not clear if the financial transaction 
>has yet been posted.

     I was not thinking of those either.  Oh, my.  Even more things to
disapprove of.

     What I was thinking of is pages that work but not nicely.
Examples:

  1) Having to enter a date using dropdowns for each of year, month,
and day.

  2) Long dropdowns not laid out for ease of use.  Countries of the
world that are in alphabetical order are not so friendly considering
that a few will account for most entries.

  3) Pages that report errors that are not clear.  I ran across one
page while applying to a company.  It was not clear what was required
and what was optional.

  4) Insular data validation.  We do not have ZIP Codes in Canada,
etc.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12665

In comp.lang.javascript message <ubsql7tn8fr320443i6vl04vafmjiak3ps@4ax.
com>, Sun, 11 Mar 2012 20:52:51, Gene Wirchenko <genew@ocis.net> posted:

>  Countries of the
>world that are in alphabetical order are not so friendly considering
>that a few will account for most entries.

It would obviously be better to use reverse alphabetical order.

Actually, all countries should be present in alphabetical order; it
would be annoying for Uruguayans and similar to hasten to the bottom of
the list and find themselves apparently absent.
.
But, surely, a well-designed system will use cookies to remember the
most popular few choices, with code to put those at the top, then a
separator, then the full list.  Cookies could also remember popular
unlisted countries, such as Wales.

-- 
 (c) John Stockton, nr London UK  ?@merlyn.demon.co.uk  IE8 FF8 Op11 Sf5 Cr15
   news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
   <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
   <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[toc] | [prev] | [next] | [standalone]

#12677

On Tue, 13 Mar 2012 18:36:11 +0000, Dr J R Stockton
<reply1211@merlyn.demon.co.uk.not.invalid> wrote:

>In comp.lang.javascript message <ubsql7tn8fr320443i6vl04vafmjiak3ps@4ax.
>com>, Sun, 11 Mar 2012 20:52:51, Gene Wirchenko <genew@ocis.net> posted:
>
>>  Countries of the
>>world that are in alphabetical order are not so friendly considering
>>that a few will account for most entries.
>
>It would obviously be better to use reverse alphabetical order.
>
>Actually, all countries should be present in alphabetical order; it
>would be annoying for Uruguayans and similar to hasten to the bottom of
>the list and find themselves apparently absent.
>.
>But, surely, a well-designed system will use cookies to remember the
>most popular few choices, with code to put those at the top, then a

     That is what I am thinking of.

>separator, then the full list.  Cookies could also remember popular
>unlisted countries, such as Wales.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12622

On Mar 8, 8:39 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
> On Mar 7, 8:11 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>
> >      In my form handler, I have a form reset.  This is confirmed using
> > confirm().  That causes the focus to move.  If the reset is confirmed,
> > then it is no matter: the form will be reinitialised.
>
> >      If the reset is denied, then I restore focus to the control that
> > had it just before then.  Unfortunately, this causes the onfocus code
> > to execute which .select()s the entire value (which is usually what is
> > wanted).
>
> >      What I would like to have happen in this case is that the
> > previous status of the control is restored.  The previous status that
> > I am concerned with is cursor position and what text is selected.
>
> >      How can I do this?  Is there a browser-independent way to do
> > this? [ ... ]
>
> If as you say (in the bit I've elided), you know how to get this data,
> then there is almost certainly a way to restore it.  You might look,
> for instance, at the Range API. [1]  I don't know the current state of
> browser support.  (The last time I had to deal with ranges was in
> 2004, I think!)  But there's at least one polyfill for older versions
> of IE. [2]

The so-called "polyfills" are a bad way to go. For one, they require
host object feature detection/testing for everything they prop up. For
two, they have to do *everything* that the standards-based
implementations do (and you don't often need that).

And as I have worked extensively with the awful MSHTML range objects,
I have my doubts that there's a foolproof GP solution just floating
around out there.

/*
  Range iterator
 */

function RangeIterator(range) {
        this.range = range;
        if (range.collapsed)
                return;

//[TODO] ensure this works

That's what I thought.  Try the add-on for My Library or the one by
Tim Down (can't remember the project name).

Furthermore, it doesn't sound like the OP needs full-blown range
solution and they didn't mention old IE either. Implement a dynamic
API and you can forget the old IE6/7/8 range implementations without
breaking those browsers.

HTH

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web