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

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

Interrogation of Shift-Key state

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

Contents

  Interrogation of Shift-Key state Janis Papanagnou <janis_papanagnou@hotmail.com> - 2016-06-25 14:59 +0200
    Re: Interrogation of Shift-Key state Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-06-25 17:18 +0200
      Re: Interrogation of Shift-Key state Janis Papanagnou <janis_papanagnou@hotmail.com> - 2016-06-25 19:47 +0200
        Re: Interrogation of Shift-Key state Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-06-25 20:07 +0200
    Re: Interrogation of Shift-Key state "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-25 08:51 -0700
      Re: Interrogation of Shift-Key state Janis Papanagnou <janis_papanagnou@hotmail.com> - 2016-06-25 19:47 +0200
        Re: Interrogation of Shift-Key state Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-06-25 20:17 +0200
          Re: Interrogation of Shift-Key state Janis Papanagnou <janis_papanagnou@hotmail.com> - 2016-06-25 21:16 +0200
            Re: Interrogation of Shift-Key state Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-06-25 22:33 +0200
              Re: Interrogation of Shift-Key state Janis Papanagnou <janis_papanagnou@hotmail.com> - 2016-06-26 00:49 +0200
                Re: Interrogation of Shift-Key state Tim Streater <timstreater@greenbee.net> - 2016-06-26 00:06 +0100
                Re: Interrogation of Shift-Key state Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-06-26 11:05 +0200
        Re: Interrogation of Shift-Key state "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-25 12:17 -0700
          Re: Interrogation of Shift-Key state "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-25 12:23 -0700
          Re: Interrogation of Shift-Key state Janis Papanagnou <janis_papanagnou@hotmail.com> - 2016-06-26 00:34 +0200
          Re: Interrogation of Shift-Key state Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-18 20:29 +0200
            Re: Interrogation of Shift-Key state "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-18 15:17 -0700
              Re: Interrogation of Shift-Key state Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-20 07:23 +0200
                Re: Interrogation of Shift-Key state "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-20 00:03 -0700
                  Re: Interrogation of Shift-Key state Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-20 11:48 +0200
                    Re: Interrogation of Shift-Key state "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-25 13:39 -0700
        Re: Interrogation of Shift-Key state "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-25 12:20 -0700
        Re: Interrogation of Shift-Key state Tim Streater <timstreater@greenbee.net> - 2016-06-25 22:33 +0100
          Re: Interrogation of Shift-Key state Janis Papanagnou <janis_papanagnou@hotmail.com> - 2016-06-26 01:18 +0200
            Re: Interrogation of Shift-Key state Tim Streater <timstreater@greenbee.net> - 2016-06-26 00:23 +0100
              Re: Interrogation of Shift-Key state Janis Papanagnou <janis_papanagnou@hotmail.com> - 2016-06-26 01:37 +0200
                Re: Interrogation of Shift-Key state Tim Streater <timstreater@greenbee.net> - 2016-06-26 09:41 +0100
    Re: Interrogation of Shift-Key state - workaround Janis Papanagnou <janis_papanagnou@hotmail.com> - 2016-06-26 00:33 +0200
      Re: Interrogation of Shift-Key state - workaround "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-26 00:53 +0200
        Re: Interrogation of Shift-Key state - workaround Janis Papanagnou <janis_papanagnou@hotmail.com> - 2016-06-26 01:31 +0200
          Re: Interrogation of Shift-Key state - workaround "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-25 16:52 -0700
          Re: Interrogation of Shift-Key state - workaround "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-26 01:56 +0200
      Re: Interrogation of Shift-Key state - workaround "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-25 16:50 -0700
    Re: Interrogation of Shift-Key state Joao Rodrigues <jr@none.com> - 2016-06-25 20:34 -0300

Page 1 of 2  [1] 2  Next page →

#30719 — Interrogation of Shift-Key state

I want to interrogate the boolean state of the Shift-Key (pressed or not).

I learned it is possible to define event-handlers to control keyup/keydown
events, then I could adjust some global variable that I can interrogate
where I need that information. But that is bulky and seems unnecessary(?)
complex.

My application context is a function that is triggered when a button is
pressed. Is there a simple way to just interrogate the Shift-Key status
in that function?

Janis

[toc] | [next] | [standalone]

#30723

Janis Papanagnou wrote:

> I want to interrogate the boolean state of the Shift-Key (pressed or not).
> 
> I learned it is possible to define event-handlers to control keyup/keydown
> events, then I could adjust some global variable that I can interrogate
> where I need that information. But that is bulky and seems unnecessary(?)
> complex.

It would be error-prone and unnecessary, indeed.

> My application context is a function that is triggered when a button is
> pressed. Is there a simple way to just interrogate the Shift-Key status
> in that function?

Yes.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#30729

On 25.06.2016 17:18, Thomas 'PointedEars' Lahn wrote:
> Janis Papanagnou wrote:
> 
>> I want to interrogate the boolean state of the Shift-Key (pressed or not).
>>
>> I learned it is possible to define event-handlers to control keyup/keydown
>> events, then I could adjust some global variable that I can interrogate
>> where I need that information. But that is bulky and seems unnecessary(?)
>> complex.
> 
> It would be error-prone and unnecessary, indeed.
> 
>> My application context is a function that is triggered when a button is
>> pressed. Is there a simple way to just interrogate the Shift-Key status
>> in that function?
> 
> Yes.

How?

> 

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

#30731

Janis Papanagnou wrote:

> On 25.06.2016 17:18, Thomas 'PointedEars' Lahn wrote:
>> Janis Papanagnou wrote:
>>> My application context is a function that is triggered when a button is
>>> pressed. Is there a simple way to just interrogate the Shift-Key status
>>> in that function?
>> Yes.
> 
> How?

In the W3C/WHATWG DOM, an event listener is passed a reference to the event 
object as first argument (if you need to support the legacy MSHTML DOM as 
well, you need to read the “window.event” property instead).  Event objects 
have a “shiftKey” property whose value is “true” if the Shift key was 
pressed when the event was fired, “false” otherwise.  And you can pass the 
property value to your function.

HTH

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#30724

On Saturday, June 25, 2016 at 7:59:13 AM UTC-5, Janis wrote:
> I want to interrogate the boolean state of the Shift-Key (pressed or not).
> 
> I learned it is possible to define event-handlers to control keyup/keydown
> events, then I could adjust some global variable that I can interrogate
> where I need that information. But that is bulky and seems unnecessary(?)
> complex.
> 
> My application context is a function that is triggered when a button is
> pressed. Is there a simple way to just interrogate the Shift-Key status
> in that function?

I suggest reading a bit on this:

<https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent>

It can be "simple" if you make it so. 

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

#30730

On 25.06.2016 17:51, Michael Haufe (TNO) wrote:
> On Saturday, June 25, 2016 at 7:59:13 AM UTC-5, Janis wrote:
>> I want to interrogate the boolean state of the Shift-Key (pressed or not).
>>
>> I learned it is possible to define event-handlers to control keyup/keydown
>> events, then I could adjust some global variable that I can interrogate
>> where I need that information. But that is bulky and seems unnecessary(?)
>> complex.
>>
>> My application context is a function that is triggered when a button is
>> pressed. Is there a simple way to just interrogate the Shift-Key status
>> in that function?
> 
> I suggest reading a bit on this:
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent>
> 
> It can be "simple" if you make it so. 

Hmm.. - you seem to be very stingy here with providing "simple" information.
If it "can be so simple", would it be possible to just post the way to go,
please?

The information on that link seems to suggest installing event listener for
keyup/keydown (which I wanted to avoid). Or following the 'keyboardEvent()'
link on the above 'keyboadEvent' link suggests using a KeyboardEvent() object.
My naive tries on the latter (yes, I don't know much of these issues; else I
wouldn't ask the question here), e.g.

        var x = new KeyboardEvent("keypress");
        if (x.shiftKey) {
            alert("shift");
        } else {
            alert("no shift");
        }

were ineffective, though, so more concrete input would be appreciated.

Janis

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

#30733

Janis Papanagnou wrote:

> On 25.06.2016 17:51, Michael Haufe (TNO) wrote:
>> I suggest reading a bit on this:
>> 
>> <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent>
>> 
>> It can be "simple" if you make it so.
> 
> Hmm.. - you seem to be very stingy here with providing "simple"
> information. If it "can be so simple", would it be possible to just post
> the way to go, please?

No.  Do your own homework.

> The information on that link

Resource/document; _not_ “link”.  The (hyper)link is the *reference* to the 
resource/document instead.

> seems to suggest installing event listener for keyup/keydown […]

It does not.

> (which I wanted to avoid).

Why do you want to avoid using the keydown/keyup events?

> Or following the 'keyboardEvent()' link on the above 'keyboadEvent' link 
> suggests using a KeyboardEvent() object. My naive tries on the latter
> (yes, I don't know much of these issues; else I wouldn't ask the question
> here), e.g.
> 
>         var x = new KeyboardEvent("keypress");
>         if (x.shiftKey) {
>             alert("shift");
>         } else {
>             alert("no shift");
>         }
> 
> were ineffective, though, so more concrete input would be appreciated.

You should read more carefully.  With the above you *create* the keyboard 
event object (and can simulate keypresses by dispatching it to elements).  

You need to use the keyboard event object that the runtime environment 
creates for you, and dispatches to your event listener, instead.

<https://www.w3.org/TR/2015/REC-dom-20151119/#events>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#30735

On 25.06.2016 20:17, Thomas 'PointedEars' Lahn wrote:
[...]
> 
> Why do you want to avoid using the keydown/keyup events?

The samples I saw seemed to have suggested to have to install event handler
functions, "addEventListener()", which would be bulky. (There is also an
aspect why events *might* not be appropriate in my case; please see below
for details on "state" vs. "event" in my case.)

> 
>> Or following the 'keyboardEvent()' link on the above 'keyboadEvent' link 
>> suggests using a KeyboardEvent() object. My naive tries on the latter
>> (yes, I don't know much of these issues; else I wouldn't ask the question
>> here), e.g.
>>
>>         var x = new KeyboardEvent("keypress");
>>         if (x.shiftKey) {
>>             alert("shift");
>>         } else {
>>             alert("no shift");
>>         }
>>
>> were ineffective, though, so more concrete input would be appreciated.
> 
> You should read more carefully.  With the above you *create* the keyboard 
> event object (and can simulate keypresses by dispatching it to elements). 

Okay.

> 
> You need to use the keyboard event object that the runtime environment 
> creates for you, and dispatches to your event listener, instead.

This is obviously what I don't understand. Which one is it? The function
I want to implement is the following; I press the 'shift' key (the event
is irrelevant _at that stage_), and then I click a button. There's a
onclick function associated with that button, and in that function I want
to interrogate the *state* of the 'shift' key (where the 'shift'-pressed
event is long gone; unless I have installed a handler and memorized the
'shift' keypress-event). To me it seems that the concept of an *event*
handler would not be appropriate here (unless I memorize such events
earlier, through an event listener); rather I wanted a simple *state*
interrogation. From what has been posted thus far I cannot see whether
it is possible at all to interrogate keyboard states. Or whether there's
an event based approach that's as simple as I would have hoped there
exists one. All I need is a boolean function, like keyboard.isShift().

> 
> <https://www.w3.org/TR/2015/REC-dom-20151119/#events>

Please be aware that posting links to standards is often not that helpful
to non-experts as it is to experts; the documents rely on knowledge that
someone not familiar with many aspects of javascript just doesn't have.
In other words, they often result in yet more questions than the one asked.
Also, spreading many technical terms like "W3C/WHATWG DOM" may show that
you are an expert, but they don't help someone who is comming here to get
information on a specific, small, and isolated question. Not everyone who
is asking questions has the background of being proficient in Javascript,
nor the goal become an expert. I'm, for example, while proficient in many
aspects of Computer Science and IT, not targetting in getting a thorough
understanding on Javascript. I just hope it is possible to get the piece
of a jigsaw I need to solve the problem that is (still) an obstacle to me.

Janis

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

#30740

Janis Papanagnou wrote:

> On 25.06.2016 20:17, Thomas 'PointedEars' Lahn wrote:
>> Why do you want to avoid using the keydown/keyup events?
> 
> The samples I saw seemed to have suggested to have to install event
> handler functions, "addEventListener()",

EventTarget::addEventListener() is the DOM method that allows you to *add* 
event _listeners_ for an event to an object; it is available on all objects 
that implement the EventTarget interface.  You do not have to use it if the 
markup language, as in the case of HTML5, provides event-handler attributes 
(like “onclick”), or if the DOM implementation, as in the case of all of 
them (AFAIK), provides short-hand properties (like “.onclick”).

But it has the advantage – despite the possibility of user-defined wrappers 
that can do the same – of being able to add *more than one event listener 
for an event* to the same object.

You may want to use it if you are sure that all target environments support 
it for an event target, and if you want to use event bubbling or separate 
script code from markup; for example, it is a good idea if you need the same 
*complex* functionality in several documents because if anything changes in 
the functionality, you only need to change it in one place in the script, 
not in the markup (the markup then only says, e.g. by means of the “class” 
attribute, on which elements the functionality should be available).

> which would be bulky.

What is that supposed to mean?

> (There is also an aspect why events *might* not be appropriate in my 
> case; please see below for details on "state" vs. "event" in my case.)

Events are appropriate in your case and the only way to solve your problem.
With user interaction in a Web browser at least, you (have to) use event-
driven programming.

>> You need to use the keyboard event object that the runtime environment
>> creates for you, and dispatches to your event listener, instead.
> 
> This is obviously what I don't understand. Which one is it?

Pardon?

> The function I want to implement is the following; I press the 'shift' key
> (the event is irrelevant _at that stage_), and then I click a button.
> There's a onclick function associated with that button,

What you call “a onclick function” is an event listener for the “click” 
event on that button to which applies what I said before.

> and in that function I want to interrogate the *state* of the 'shift' key
> (where the 'shift'-pressed event is long gone; unless I have installed a 
> handler and memorized the 'shift' keypress-event).

Apparently you have not realized yet that the “shiftKey” property is not 
only available on keyboard events.  However, you would have *known* *had* 
*you* *tried* *it* *out*.  See also the FAQ on debugging.

>> <https://www.w3.org/TR/2015/REC-dom-20151119/#events>
> 
> Please be aware that posting links to standards is often not that helpful
> to non-experts as it is to experts;

In this case it is.  (You have not even read what I referred you to, have 
you?)

> the documents rely on knowledge that someone not familiar with many
> aspects of javascript just doesn't have.

There is no “javascript”, see the ECMAScript Support Matrix (URI in my sig).

> [rant]

<http://catb.org/esr/faqs/smart-questions.html>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#30744

On 25.06.2016 22:33, Thomas 'PointedEars' Lahn wrote:
> Janis Papanagnou wrote:
> 
>> which would be bulky.
> 
> What is that supposed to mean?

That is suposed to mean that comparably a lot code is required as opposed
to a static state interrogation. To be more concrete, the workaround that
at least seems to work in my context is

    var shiftState = false;
    function keyEvent (ev) { shiftState = ev.shiftKey; }
    document.addEventListener("keydown", keyEvent);
    document.addEventListener("keyup", keyEvent);
    ...
    function f () { if (shiftState) ... }

as opposed to a (desired, but obviously non-existing)

    function f () { if (keyboard.shiftPressed()) ... }

Given that I'm not sure that the shift key event will be correctly handled
in other environments as well the former might not only be bulky but also
non-portable. (Portability is no requirement, though, but it would be nice
to have a wider support).

> 
>> (There is also an aspect why events *might* not be appropriate in my 
>> case; please see below for details on "state" vs. "event" in my case.)
> 
> Events are appropriate in your case and the only way to solve your problem.

So that finally answers my questions (Subject: Interrogation of Shift-Key
state); I learned that the keyboard state can not be interrogated directly.
Thanks.

> 
>>> You need to use the keyboard event object that the runtime environment
>>> creates for you, and dispatches to your event listener, instead.
>>
>> This is obviously what I don't understand. Which one is it?
> 
> Pardon?

You said "the keyboard event object"; I didn't understand which [existing]
object that actually is.

> 
>> The function I want to implement is the following; I press the 'shift' key
>> (the event is irrelevant _at that stage_), and then I click a button.
>> There's a onclick function associated with that button,
> 
> What you call “a onclick function” is an event listener for the “click” 
> event on that button to which applies what I said before.

Obviously I can't put the ties together. :-(

I have
	<input type="button" ... onclick="f(10)">

and the function

        function f(n)
        {
          if (SHIFTSTATE) { alert("shift"); } else { alert("no shift"); }
          ...
        }

I still don't see how to access the "event" here to define SHIFTSTATE.

> 
>> and in that function I want to interrogate the *state* of the 'shift' key
>> (where the 'shift'-pressed event is long gone; unless I have installed a 
>> handler and memorized the 'shift' keypress-event).
> 
> Apparently you have not realized yet that the “shiftKey” property is not 
> only available on keyboard events. 

For my purpose it's in the first place irrelevant; all I wanted to know is
whether there's a simple keyboard shift-key state interrogation or not.[*]

Janis

[*] There was a simple "Yes." statement of yours in your first posting; yet
it seems that this well known sociopathic short reply was wrong, given what
I read in subsequent replies. Anyway; plain answers like "yes" or "no" without
concrete substance are (while "logically" correct) anyway completely useless
as are all the other insinuations, like not having read text behind links,
like not having tried out anything, not knowing how to post questions, etc.
This behaviour of yours is well known. For years. I guess this won't change.
Anyway. Good luck.

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

#30746

In article <nkn1q4$856$1@gioia.aioe.org>, Janis Papanagnou
<janis_papanagnou@hotmail.com> wrote:

>On 25.06.2016 22:33, Thomas 'PointedEars' Lahn wrote:

>So that finally answers my questions (Subject: Interrogation of Shift-Key
>state); I learned that the keyboard state can not be interrogated directly.
>Thanks.

No.

You generate an event object when you click the button. If there is no
event handler listening for it, that event object will quickly
disappear. If you add one for the click event, you can check the state
of the shift-key in that, as Christoph said in his reply.

>>>> You need to use the keyboard event object that the runtime environment
>>>> creates for you, and dispatches to your event listener, instead.
>>>
>>> This is obviously what I don't understand. Which one is it?
>> 
>> Pardon?
>
>You said "the keyboard event object"; I didn't understand which [existing]
>object that actually is.
>
>> 
>>> The function I want to implement is the following; I press the 'shift' key
>>> (the event is irrelevant _at that stage_), and then I click a button.
>>> There's a onclick function associated with that button,
>> 
>> What you call “a onclick function” is an event listener for the “click” 
>> event on that button to which applies what I said before.

I'm guessing that when PointyHead said "keyboard event object" he
actually meant "click event object". And your handler for that should
check the state of the shift key. So the event is not irrelevant.

-- 
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

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

#30758

Janis Papanagnou wrote:

> [*] There was a simple "Yes." statement of yours in your first posting;
> [yet it seems that this well known sociopathic short reply was wrong,

No, *you* are wrong.

> given what I read in subsequent replies. Anyway; plain answers like "yes" 
> or "no" without concrete substance are (while "logically" correct) anyway
> completely useless as are all the other insinuations, like not having read
> text behind links, like not having tried out anything, not knowing how to
> post questions, etc. This behaviour of yours is well known. For years. I
> guess this won't change. Anyway. Good luck.

Since you had finally posted some code, I had written the (trivial) 
correction, and a working solution, further above.  Then I had to read this.  
As a result, I have cut the rest of my posting.  You have yet to deserve it.

*plonk*

F'up2 poster

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#30736

On Saturday, June 25, 2016 at 12:47:58 PM UTC-5, Janis wrote:
> On 25.06.2016 17:51, Michael Haufe (TNO) wrote:
> > On Saturday, June 25, 2016 at 7:59:13 AM UTC-5, Janis wrote:
> >> I want to interrogate the boolean state of the Shift-Key (pressed or not).
> >>
> >> I learned it is possible to define event-handlers to control keyup/keydown
> >> events, then I could adjust some global variable that I can interrogate
> >> where I need that information. But that is bulky and seems unnecessary(?)
> >> complex.
> >>
> >> My application context is a function that is triggered when a button is
> >> pressed. Is there a simple way to just interrogate the Shift-Key status
> >> in that function?
> > 
> > I suggest reading a bit on this:
> > 
> > <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent>
> > 
> > It can be "simple" if you make it so. 
> 
> Hmm.. - you seem to be very stingy here with providing "simple" information.

From experience I've learned that questions on this particular topic tend to be the wrong questions.

> If it "can be so simple", would it be possible to just post the way to go,
> please?

The point is that it depends. From your question:

"I want to interrogate the boolean state of the Shift-Key (pressed or not)."

But from the reference I provided you can see that:

"When a key is pressed and held down, it begins to auto-repeat. This results in a sequence of events similar to the following being dispatched:"

<https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Auto-repeat_handling>

So depending on your platform targets, there is a good chance you're going to be getting some contradictory information in some cases (keydown followed by a keypress and possibly by keyup somewhere in there in repetition)

Which means you are now looking at the keypress event. Luckily, the event that is raised has a property called "shiftKey" which you can interrogate. So now your left with the problem of telling the difference between someone holding down the shift key and someone mashing on the keyboard in succession.

> The information on that link seems to suggest installing event listener for
> keyup/keydown (which I wanted to avoid). Or following the 'keyboardEvent()'
> link on the above 'keyboadEvent' link suggests using a KeyboardEvent() object.
> My naive tries on the latter (yes, I don't know much of these issues; else I
> wouldn't ask the question here), e.g.
> 
>         var x = new KeyboardEvent("keypress");
>         if (x.shiftKey) {
>             alert("shift");
>         } else {
>             alert("no shift");
>         }
> 
> were ineffective, though, so more concrete input would be appreciated.


Besides the issues raised thus far, in FireFox Windows (at least), simply hitting the shift key alone is not enough to raise the event. You have to hit another non-special key as well. You can play with this here:

<http://codepen.io/mlhaufe/pen/zBNWXq?editors=0011>

For archival purposes, the linked to code is below:

function shiftListener(e){ console.log("Shift pressed: " + e.shiftKey)}

document.addEventListener("keypress",shiftListener)

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

#30738

On Saturday, June 25, 2016 at 2:17:59 PM UTC-5, Michael Haufe (TNO) wrote:

> Besides the issues raised thus far, in FireFox Windows (at least), simply hitting the shift key alone is not enough to raise the event. You have to hit another non-special key as well. You can play with this here:
> 
> <http://codepen.io/mlhaufe/pen/zBNWXq?editors=0011>
> 
> For archival purposes, the linked to code is below:
> 
> function shiftListener(e){ console.log("Shift pressed: " + e.shiftKey)}
> 
> document.addEventListener("keypress",shiftListener)

I've just added a click listener as well which shows that the state of the shiftKey can be interrogated on that event:

document.addEventListener("click",shiftListener)

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

#30743

On 25.06.2016 21:17, Michael Haufe (TNO) wrote:
> 
> From experience I've learned that questions on this particular topic tend to be the wrong questions.

My original question was: "Is there a simple way to just interrogate the
Shift-Key status in that function?" - I don't see anything that could be
wrong with it. - From my perspective I just saw a lot quibbling responses.

> 
>> If it "can be so simple", would it be possible to just post the way to go,
>> please?
> 
> The point is that it depends. From your question:
> 
> "I want to interrogate the boolean state of the Shift-Key (pressed or not)."
> 
> But from the reference I provided you can see that:
> 
> "When a key is pressed and held down, it begins to auto-repeat. This results in a sequence of events similar to the following being dispatched:"

When I had been deeper in keyboard issues (25+ years ago) I seem to recall
that the control keys (Alt, Ctrl, Shift, etc.) [typically] won't create
repeating events. Notwithstanding other valid points that were meanwhile
posted, that's why event repetitions might not be an issue here, but yet
more so if the event system could have been avoided for state interrogation.

Thanks anyway for responding.

Janis

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

#31112

[Catching up on some old threads, with updated scorefile, in a break.]

Michael Haufe (TNO) wrote:

> On Saturday, June 25, 2016 at 12:47:58 PM UTC-5, Janis wrote:
>> If it "can be so simple", would it be possible to just post the way to
>> go, please?
> 
> The point is that it depends. From your question:
> 
> "I want to interrogate the boolean state of the Shift-Key (pressed or
> not)."
> 
> But from the reference I provided you can see that:
> 
> "When a key is pressed and held down, it begins to auto-repeat. This
> results in a sequence of events similar to the following being
> dispatched:"
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Auto-repeat_handling>

Auto-repeat is not supposed to happen for modifier keys like the Shift key.  
(Because) there is no logic in that: auto-repeat is a keyboard driver 
feature that is intended to make typing on a computer keyboard like on a 
typewriter easier.  For example, if you need to type a separator line of 
dashes or equals signs in a plain-text document, or quickly remove a lot of 
characters with Backspace/Delete; also, it is intended to make scrolling 
with the arrow keys or the Page Up/Down keys easier.

Some (IMHO borken) keyboard drivers (for Windows) do it anyway.  But even 
with auto-repeat, while there are several “keydown” and, for non-character 
keys, “keypress”, events for the same key code, there is only one “keyup” 
event when the key is released.  Keyboard events in Web user agents 
certainly do not range among the best pieces of software design, but they 
are not *that* ill-designed either.

This can be easily tested, for example with

  document.onkeydown = document.onkeyup = document.onkeypress =
    function (e) {
      console.log(e.type, e.keyCode, e.charCode);
    };

or, in older user agents:
  
  document.body.innerHTML = "";
  document.onkeydown = document.onkeyup = document.onkeypress =
    function (e) {
      if (!e) e = window.event;
      document.body.innerHTML +=
        ([e.type, e.keyCode, e.charCode].join(", ") + "<br>\n");
    };

> So depending on your platform targets, there is a good chance you're going
> to be getting some contradictory information in some cases (keydown
> followed by a keypress and possibly by keyup somewhere in there in
> repetition)

Name one.
 
> Which means you are now looking at the keypress event. Luckily, the event
> that is raised has a property called "shiftKey" which you can interrogate.

The *proprietary/legacy* “keypress” event is not fired for non-character 
keys; never has been.  This is how you can tell apart, for example, the 
right arrow key ({keyCode: 39, charCode: 0}) and the apostrophe key 
({keyCode: 39, charCode: 39}}; on my laptop with Swiss German keyboard 
layout, YMMV).

[The MSHTML DOM event model up to including IE 8 (and IE 9 in Compatibility 
Mode) is a “conflated” one (see “Legacy key models” in the specification 
below) that does not have the “charCode” property.  Just confirmed again in 
resurrected IE 6 to 8, thanks to ievms.]

<https://www.w3.org/TR/uievents/>

> So now your left with the problem of telling the difference between
> someone holding down the shift key and someone mashing on the keyboard in
> succession.

Most certainly not.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#31113

On Thursday, August 18, 2016 at 1:29:19 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> [Catching up on some old threads, with updated scorefile, in a break.]
> 
> Michael Haufe (TNO) wrote:

> > So depending on your platform targets, there is a good chance you're going
> > to be getting some contradictory information in some cases (keydown
> > followed by a keypress and possibly by keyup somewhere in there in
> > repetition)
> 
> Name one.

<https://bugzilla.mozilla.org/show_bug.cgi?id=602812>

> > Which means you are now looking at the keypress event. Luckily, the event
> > that is raised has a property called "shiftKey" which you can interrogate.
> 
> The *proprietary/legacy* “keypress” event is not fired for non-character 
> keys; never has been.  This is how you can tell apart, for example, the 
> right arrow key ({keyCode: 39, charCode: 0}) and the apostrophe key 
> ({keyCode: 39, charCode: 39}}; on my laptop with Swiss German keyboard 
> layout, YMMV).

See the above link

> > So now your left with the problem of telling the difference between
> > someone holding down the shift key and someone mashing on the keyboard in
> > succession.
> 
> Most certainly not.

Again, see the above link.

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

#31120

Michael Haufe (TNO) wrote:

> On Thursday, August 18, 2016 at 1:29:19 PM UTC-5, Thomas 'PointedEars'
> Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > So depending on your platform targets, there is a good chance you're
>> > going to be getting some contradictory information in some cases
>> > (keydown followed by a keypress and possibly by keyup somewhere in
>> > there in repetition)
>> Name one.
> 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=602812>

There is nothing there that corroborates your belief.
 
>> > Which means you are now looking at the keypress event. Luckily, the
>> > event that is raised has a property called "shiftKey" which you can
>> > interrogate.
>> 
>> The *proprietary/legacy* “keypress” event is not fired for non-character
>> keys; never has been.  This is how you can tell apart, for example, the
>> right arrow key ({keyCode: 39, charCode: 0}) and the apostrophe key
>> ({keyCode: 39, charCode: 39}}; on my laptop with Swiss German keyboard
>> layout, YMMV).
> 
> See the above link

BTDT.  It says that *in Firefox*

- “On Windows, CapsLock, NumLock and ScrollLock [did not dispatch the 
  ‘keypress’] event.

- On Linux, CapsLock, NumLock and ScrollLock [dispatched the ‘keypress’]
  event.

- On Mac, CapsLock dispatched only [the ‘keydown’] event, [the] NumLock key 
  (without Fn key, i.e., external keyboard's NumLock key) dispatched the 
  ‘keydown’, ‘keypress’, and ‘keyup’ events.  The NumLock key with Fn key
  and ScrollLock key don't dispatch any key events.”

from before “2010-10-08 01:55 PDT” when that bug was reported to before 
“2013-07-23 11:04:32 PDT” when it was FIXED.

Who cares?

“Currently, neither modifier keys nor dead keys cause keypress event(s).” 
(AISB)
 
>> > So now your left with the problem of telling the difference between
>> > someone holding down the shift key and someone mashing on the keyboard
>> > in succession.
>> Most certainly not.
> 
> Again, see the above link.

There is neither a mention that the “keyup” event would be fired while the 
Shift key were held down, nor is the Shift key mentioned there.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#31122

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Michael Haufe (TNO) wrote:
> >> > So depending on your platform targets, there is a good chance you're
> >> > going to be getting some contradictory information in some cases
> >> > (keydown followed by a keypress and possibly by keyup somewhere in
> >> > there in repetition)
> >> Name one.
> > 
> > <https://bugzilla.mozilla.org/show_bug.cgi?id=602812>
> 
> There is nothing there that corroborates your belief.

Platforms are listed in there as well as in the original link I posted earlier. What exactly are you trying to criticize here? You don't believe the events repeat as listed in the original MDN article? Or you don't like that I generalized the MDN link to include the Shift key in the list of non-character items? 

If you're criticizing the first, that's hard to believe. So I'll assume you're complaining about the latter (which MIGHT be justified depending on platform target), but I hedged my bet by not assuming 100% consistent behavior. I know PPK has discovered inconsistencies in the shift key behavior in the past as well [1], so it isn't unreasonable to be conservative in this case in the absence of information about specific platform targets.

> >> > Which means you are now looking at the keypress event. Luckily, the
> >> > event that is raised has a property called "shiftKey" which you can
> >> > interrogate.
> >> 
> >> The *proprietary/legacy* “keypress” event is not fired for non-character
> >> keys; never has been.  This is how you can tell apart, for example, the
> >> right arrow key ({keyCode: 39, charCode: 0}) and the apostrophe key
> >> ({keyCode: 39, charCode: 39}}; on my laptop with Swiss German keyboard
> >> layout, YMMV).
> > 
> > See the above link
> 
> BTDT.  It says that *in Firefox*

You said it's not fired, and never has been. The link contradicts that claim.

> - “On Windows, CapsLock, NumLock and ScrollLock [did not dispatch the 
>   ‘keypress’] event.
> 
> - On Linux, CapsLock, NumLock and ScrollLock [dispatched the ‘keypress’]
>   event.
> 
> - On Mac, CapsLock dispatched only [the ‘keydown’] event, [the] NumLock key 
>   (without Fn key, i.e., external keyboard's NumLock key) dispatched the 
>   ‘keydown’, ‘keypress’, and ‘keyup’ events.  The NumLock key with Fn key
>   and ScrollLock key don't dispatch any key events.”
> 
> from before “2010-10-08 01:55 PDT” when that bug was reported to before 
> “2013-07-23 11:04:32 PDT” when it was FIXED.
> 
> Who cares?

Apparently you. You claimed: 

"The *proprietary/legacy* “keypress” event is not fired for non-character keys; never has been."

Which is evidently not true, but when presented with reference you now no longer care? Seems like a bad faith criticism from where I'm sitting.

> “Currently, neither modifier keys nor dead keys cause keypress event(s).” 
> (AISB)

That's not what you said before. You've added the qualifier "Currently" where earlier you said "never".

> >> > So now your left with the problem of telling the difference between
> >> > someone holding down the shift key and someone mashing on the keyboard
> >> > in succession.
> >> Most certainly not.
> > 
> > Again, see the above link.
> 
> There is neither a mention that the “keyup” event would be fired while the 
> Shift key were held down, nor is the Shift key mentioned there.

I don't know what you're trying to criticize here either then. "Most certainly not" what?

The link I posted earlier states:

"Auto-repeat on some GTK environments such as Ubuntu 9.4

In some GTK-based environments, auto-repeat dispatches a native key-up event automatically during auto-repeat, and there's no way for Gecko to know the difference between a repeated series of keypresses and an auto-repeat. On those platforms, then, an auto-repeat key will generate the following sequence of events:

    keydown
    keypress
    keyup
    keydown
    keypress
    keyup
    <<repeating until the user releases the key>>
    keyup"

Can you summarize your criticism(s) into a single paragraph for clarity?

[1] <http://www.quirksmode.org/dom/events/keys.html>

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

#31128

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> Michael Haufe (TNO) wrote:
>> >> > So depending on your platform targets, there is a good chance you're
>> >> > going to be getting some contradictory information in some cases
>> >> > (keydown followed by a keypress and possibly by keyup somewhere in
>> >> > there in repetition)
>> >> Name one.
>> > <https://bugzilla.mozilla.org/show_bug.cgi?id=602812>
>> There is nothing there that corroborates your belief.
> 
> Platforms are listed in there as well as in the original link I posted
> earlier. What exactly are you trying to criticize here?

That you are jumping to conclusions, (unintentionally, I trust) spreading 
FUD.

> You don't believe the events repeat as listed in the original MDN article?

No.  First of all, I am trained in *scientific* thinking, so I am naturally 
skeptic: I do not just believe, I demand *evidence* supporting statements.  
Second, as a result, I *think* that statements made in such a way cannot be 
a solid basis for design decisions.  Third, my *tests* in 
navigator.userAgent === "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) 
Gecko/20100101 Firefox/38.0 Iceweasel/38.1.0" (note the Gecko version), 
using the test code I posted, do not confirm the statements: in all 
instances, there is only one “keyup” event for such keys.

> Or you don't like that I generalized the MDN link to include the Shift key
> in the list of non-character items?

Once again, this is not personal; it does not matter whether *I* *like* it.
It was *fallacious*.

You have claimed “a good chance” that what you describe is going to happen.
Evidently it is not such, not even remotely.
 
> If you're criticizing the first, that's hard to believe.

How so?  It is a wiki, not reference material written solely by Mozilla.org 
developers or developers working for the Mozilla Corporation.  It is peer-
reviewed, (which is good; although not on a regular basis, AFAIK, which is 
not so good) but until that happened, anyone could have written any nonsense 
there.

As you can see, I am using a rather old Firefox on GNU/Linux (due to 
distribution limitations: I do not want systemd running on my computers) in 
which I cannot confirm those claims.

It is possible that I do not meet the requirements of the (imprecisely 
formulated) observations there: I am using Debian GNU/Linux, not Ubuntu 
(which is Debian-based), so I am using (naturally) the GTK(+) variant of 
Firefox (then rebranded by Debian as “Iceweasel” due to licensing issues, 
but the relevant codebase should be the same), and I am running it from
KDE, not a GNOME-based desktop environment.

However, I find it more likely that the person writing this part of the 
article (which would have been about 7 years ago; the history will tell for 
sure) has encountered the edge-case bug fixed three years ago or earlier,
if that.  (See below.)

> […] I know PPK has discovered inconsistencies in the shift key
> behavior in the past as well [1],
> 
> [1] <http://www.quirksmode.org/dom/events/keys.html>

How far in the past, and how detailed?  You are wrong if you think that 
descriptions like “Shift keys” in “FF 7.0 Win” are detailed enough findings.  
It is curious that you do not realize that as the bug report that you 
referred to shows it.

> so it isn't unreasonable to be conservative in this case in the absence of
> information about specific platform targets.

It is unreasonable in the absence of platform target information if the 
versions in question have met their end-of-life long ago, and the browser 
bugs in that regard, that existed only for a short period of time, have been 
fixed long ago.  For what we now know, it is possible that PPK has tested 
those versions of Firefox, and only those, where the bug described in the 
bug report existed.

Also, PPK does not say anything about “keyup” events repeating when a key is 
held down.  Was his testing insufficient, or is the MDN article section the 
result of superficial testing?  They cannot be both correct unless there 
were edge-case bugs.

>> >> > Which means you are now looking at the keypress event. Luckily, the
>> >> > event that is raised has a property called "shiftKey" which you can
>> >> > interrogate.
>> >> The *proprietary/legacy* “keypress” event is not fired for
>> >> non-character
>> >> keys; never has been.  This is how you can tell apart, for example,
>> >> the right arrow key ({keyCode: 39, charCode: 0}) and the apostrophe
>> >> key ({keyCode: 39, charCode: 39}}; on my laptop with Swiss German
>> >> keyboard layout, YMMV).
>> > 
>> > See the above link
>> 
>> BTDT.  It says that *in Firefox*
> 
> You said it's not fired, and never has been. The link contradicts that
> claim.

Edge-case bugs aside of course.  You make it sound as if this had not been 
an edge-case bug and it would be reasonable to be considered everywhere for 
all eternity.
 
> […] You claimed:
> 
> "The *proprietary/legacy* “keypress” event is not fired for non-character
> keys; never has been."
> 
> Which is evidently not true, but when presented with reference you now no
> longer care? Seems like a bad faith criticism from where I'm sitting.
> 
>> “Currently, neither modifier keys nor dead keys cause keypress event(s).”
>> (AISB)
> 
> That's not what you said before. You've added the qualifier "Currently"
> where earlier you said "never".

I am well aware that the bug report disproves the “never has been” in my 
statement.  However, it does not disprove the argument as it was meant: This 
behavior was not by design, it *was* a *bug*.  It *existed* only on *one* 
browser on *one* platform for a *short* period of time, a considerable time 
ago.  And it did not occur with the key in question.
 
> Can you summarize your criticism(s) into a single paragraph for clarity?

The claim made in MDN, which you are primarily basing your argument on, is 
too vague to begin with.  It is also specious: There never was a 9.4 version 
of Ubuntu.  Ubuntu versions are released semianually, where the major 
version indicates the year, and the *two-digit* minor version indicates the 
month of the release.  There was a Ubuntu _9.04_ (“Jaunty Jackalope”) 
released in 2009-04; it was not a Long Term Support release, so support for 
it ended 2010-10-23 with Ubuntu 10.10 (“Maverick Meerkat”) [that was 6 to 7 
years ago; nobody in their right mind should use that version anymore].  And 
Ubuntu is particularly quick in adopting new Firefox versions.

I implore you to apply more critical thinking to *everything* that you read.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web