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 2 of 2 — ← Prev page 1 [2]

#31183

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:

> > 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.

Join the club, but this is more an issue of engineering (management of complexity in the face of the unknown) than science (discovery of truth through experimentation). The latter obviously takes more time than the former.


> > 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.

*one* experiment on your environment is not sufficient to dismiss the evidence raised in the linked articles, neither MDN's nor PPK's. At best it's additional information. 

> > 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.

Wouldn't the same criticism apply to your presentation?

> 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.

nor rule it out. 

> 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.)

But there is insufficient evidence to conclude such as neither you or I have any intention of running a gamut of tests across all combinations of OSes and browsers in order to get a definite answer on the state of affairs. 

> > […] 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.

The result of your single experiment isn't much better. It's simply more information

> > 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.

but

1- We don't have a range of target browsers nor OSes from the OP.
2- OSes outlive browsers
3- Evidence of which combinations no longer exhibit the bug(s) are not available
------
Therefore we can't conclude the absence nor presence in general

> 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.

Or they are both superficial and insufficient.

> > 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.

We know all-too-well that defensive programming is the name of the game in Web Development. As such I still hold that it is reasonable to assume the existence of the bug and program accordingly until sufficient evidence is presented
showing that it's no longer necessary to be concerned with.

Granted: MDN, PPK, and Bugzilla are not enough to come to a decision on this matter, nor is the addition of your one experiment and a handful that I would do on my systems. Thus I assume the worst. You want to call that FUD? Feel free. 

> > […] 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.

I'll look again, but I am still skeptical of it's limitation to such a specific instance.

> > 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.

Thank you for the summary. This is my summary claim:

forAll(browsers x operatingSystems)
	thereExists( (browser,operatingSystem) )
	suchThat bug(keyPress) exists

therefore
	write code in a manner that won't expose this bug.

If the de-facto truth is that a subset of that cross product is in use that doesn't have the issues mentioned, then of course the excessive defensiveness if unnecessary.

> I implore you to apply more critical thinking to *everything* that you read.

Unnecessary, and excessive on the web. If there are what appear to be credible claims of the past and possible still present bugs, then spending an inordinate time in verifying and reproducing those bugs is unreasonable. Again, I'm pointing to Engineering over Science.

Feel free to build another test framework like you did for your thesis[1], and we might put this matter to rest with enough volunteers for concrete evidence.

[1] <http://pointedears.de/scripts/test/es-matrix/>

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

#30737

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?

To respond to this part again in another way:

What are you trying to accomplish at a higher level? The solution may differ

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

#30741

In article <nkmg47$1b8k$2@gioia.aioe.org>, Janis Papanagnou
<janis_papanagnou@hotmail.com> 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.
>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).

Why do you want to avoid this?

What is your software doing when you want to know about the shift key?

You may wish to buy a book on javascript and read about events models
and what happens to events. Once you understand that a bit, by
experimenting, you can decide how to organise your software around what
javascript provides.

Also: ignore PointyHead. As you have discovered, he is a smartarse who
thinks that it is clever to write one-word answers to people seeking
help.

-- 
"People don't buy Microsoft for quality, they buy it for compatibility
with what Bob in accounting bought last year. Trace it back - they buy
Microsoft because the IBM Selectric didn't suck much" - P Seebach, afc

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

#30747

On 25.06.2016 23:33, Tim Streater wrote:
> In article <nkmg47$1b8k$2@gioia.aioe.org>, Janis Papanagnou
> <janis_papanagnou@hotmail.com> wrote:
>>
>> The information on that link seems to suggest installing event listener for
>> keyup/keydown (which I wanted to avoid).
> 
> Why do you want to avoid this?

Mainly because I was; (a) expecting that there might be a static method
that I didn't knew of, and (b) because it's not really an "event" that I
want to obtain, rather a *static* "state" property.

Now language concepts may make it impossible to support events (or to
support static keyboard states). That is important to know. But my JS
skills are very basic so it's necessary to get to know about that.

I don't mind using events for that purpose if that's the only possible
(or sensible) way to go. Actually my workaround is also based on events.
I just wanted to seek an elegant solution or an idiomatic solution.

> 
> What is your software doing when you want to know about the shift key?

Briefly; to change the behaviour of the function behind the button.

> 
> You may wish to buy a book on javascript and read about events models
> and what happens to events. Once you understand that a bit, by
> experimenting, you can decide how to organise your software around what
> javascript provides.

Yeah, I'm aware of that. But note (as mentioned elsewhere already) that
JS is not my primary proficiency. It appeared to me that I am asking only
a small, easy, and quickly answerable question in one line of code or so.
Despite having coded a couple thousand lines of code in JS I cannot spend
the time to learn it from scratch; there are far too many more important
other things where my focus lies. Despite what another poster had imputed
I searched the net, read specific articles on the issue, and experimented
with my actual code (my own ideas and what I found on the net) before and
also after placed my "small" question here.

> 
> Also: ignore PointyHead. As you have discovered, he is a smartarse who
> thinks that it is clever to write one-word answers to people seeking
> help.

Thanks for the support! Though I know him already from other groups where
I am (and he is, or was) active; he is in many killfiles because of such
sociopathic behaviour. It's not that he has not valuable knowledge, but
the problem is that he is incapable of (or just pathologically unwilling)
respecting people, can't focus on other's views, is seemingly inalterably
fixed on his own mindset, which seems to be considered the only valid one.
Usually, because of that, it's not worth discussing with him, so I agree.

Janis

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

#30748

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

>On 25.06.2016 23:33, Tim Streater wrote:
>> In article <nkmg47$1b8k$2@gioia.aioe.org>, Janis Papanagnou
>> <janis_papanagnou@hotmail.com> wrote:
>>>
>>> The information on that link seems to suggest installing event listener for
>>> keyup/keydown (which I wanted to avoid).
>> 
>> Why do you want to avoid this?
>
>Mainly because I was; (a) expecting that there might be a static method
>that I didn't knew of, and (b) because it's not really an "event" that I
>want to obtain, rather a *static* "state" property.
>
>Now language concepts may make it impossible to support events (or to
>support static keyboard states). That is important to know. But my JS
>skills are very basic so it's necessary to get to know about that.
>
>I don't mind using events for that purpose if that's the only possible
>(or sensible) way to go. Actually my workaround is also based on events.
>I just wanted to seek an elegant solution or an idiomatic solution.

Well, you saw Christoph's reply, I hope. That does exactly what you
want quite simply.

-- 
"The idea that Bill Gates has appeared like a knight in shining armour to
 lead all customers out of a mire of technological chaos neatly ignores 
 the fact that it was he who, by peddling second-rate technology, led them
 into it in the first place."                             - Douglas Adams

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

#30751

On 26.06.2016 01:23, Tim Streater wrote:
> 
> Well, you saw Christoph's reply, I hope. That does exactly what you
> want quite simply.

Yeah, it looks very promising. I will check it out as soon as possible.
Thanks again for the valuable hints and code samples!

Janis

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

#30757

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

>On 26.06.2016 01:23, Tim Streater wrote:
>> 
>> Well, you saw Christoph's reply, I hope. That does exactly what you
>> want quite simply.
>
>Yeah, it looks very promising. I will check it out as soon as possible.
>Thanks again for the valuable hints and code samples!

Did I post samples? Not sure that I did. I should have done though, as
what Christoph suggested is exactly what I do in my own code (along
with looking at other meta-kets when clicking), but it's so long since
I wrote it that I'd forgotten that (and I'm not really writing much
javascript at the minute).

But none the less if you intend to do a lot more with javascript a book
would be helpful, as there is usually discussion there, as well as
being a reference. The web is a good source but one should be skeptical
about the quality of the discussion.

-- 
"Please stop telling us what you feel. Please stop telling us what your 
intuition is. Your intuitive feelings are of no interest whatsoever, 
and nor are mine. I don't give a bugger what you feel, or what I feel. 
I want to know what the evidence shows."             -- Richard Dawkins

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

#30742 — Re: Interrogation of Shift-Key state - workaround

(Closing my own question.)

On 25.06.2016 14:59, 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.
> 
> 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?

Simple static interrogation of the Shift key seems impossible in Javascript,
as the replies in this thread seem to suggest.

In my system context (Linux) the workaround that I wanted to avoid works as
expected at least. So for folks who want to implement such functionality
and are interested in my workaround I post the code skeleton for reference.

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

    function f(arg)
    {
        if (shiftState) {
            alert("shift");
        } else {
            alert("no shift");
        }
        ...
    }


Have fun!

Janis

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

#30745 — Re: Interrogation of Shift-Key state - workaround

On 26.06.2016 at 00:33, Janis Papanagnou wrote:

> On 25.06.2016 14:59, Janis Papanagnou wrote:

>> I want to interrogate the boolean state of the Shift-Key (pressed or not).
> 
> In my system context (Linux) the workaround that I wanted to avoid works as
> expected at least. So for folks who want to implement such functionality
> and are interested in my workaround I post the code skeleton for reference.
>
> […]

In another reply you've mentioned that you're actually being interested
in interogating whether a shift key is pressed while a mouse button is
clicked.  For that purpose you don't need that workaround, but rather
can ask for whether a shift key is pressed in the click event handler
(as has been pointed out by others already[1]):

  someElement.addEventListener("click", function (event) {
    if (event.shiftKey) {
      alert("shift key pressed while mouse button clicked");
    }
  }

[1] Which have been actually more useful replies than this one, even
though that might not appear so to you. :)

-- 
Christoph M. Becker

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

#30749 — Re: Interrogation of Shift-Key state - workaround

On 26.06.2016 00:53, Christoph M. Becker wrote:
> On 26.06.2016 at 00:33, Janis Papanagnou wrote:
> 
>> On 25.06.2016 14:59, Janis Papanagnou wrote:
> 
>>> I want to interrogate the boolean state of the Shift-Key (pressed or not).
>>
>> In my system context (Linux) the workaround that I wanted to avoid works as
>> expected at least. So for folks who want to implement such functionality
>> and are interested in my workaround I post the code skeleton for reference.
>>
>> […]
> 
> In another reply you've mentioned that you're actually being interested
> in interogating whether a shift key is pressed while a mouse button is
> clicked.  For that purpose you don't need that workaround, but rather
> can ask for whether a shift key is pressed in the click event handler
> (as has been pointed out by others already[1]):

Oh, I suppose you mean that part where I answered: "Obviously I can't put
the ties together." Obviousy I wasn't able to derive functional code from
that statement. I tried some code variants but none was functional.

> 
>   someElement.addEventListener("click", function (event) {
>     if (event.shiftKey) {
>       alert("shift key pressed while mouse button clicked");
>     }
>   }

Thanks for this code sample; this is very valuable!

Janis

> 
> [1] Which have been actually more useful replies than this one, even
> though that might not appear so to you. :)

Even if it might not appear so to you, but your reply was actually much
more useful (to me) than some of the quibbling previous replies. :-)

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

#30753 — Re: Interrogation of Shift-Key state - workaround

On Saturday, June 25, 2016 at 6:31:37 PM UTC-5, Janis wrote:
> On 26.06.2016 00:53, Christoph M. Becker wrote:

> > In another reply you've mentioned that you're actually being interested
> > in interogating whether a shift key is pressed while a mouse button is
> > clicked.  For that purpose you don't need that workaround, but rather
> > can ask for whether a shift key is pressed in the click event handler
> > (as has been pointed out by others already[1]):
> 
> Oh, I suppose you mean that part where I answered: "Obviously I can't put
> the ties together." Obviousy I wasn't able to derive functional code from
> that statement. I tried some code variants but none was functional.

Which means you didn't click any of the links I provided, nor tried any of the code I posted. Oh well. Horses and water and something something...

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

#30754 — Re: Interrogation of Shift-Key state - workaround

On 26.06.2016 at 01:31, Janis Papanagnou:

> On 26.06.2016 00:53, Christoph M. Becker wrote:
>
>> [1] Which have been actually more useful replies than this one, even
>> though that might not appear so to you. :)
> 
> Even if it might not appear so to you, but your reply was actually much
> more useful (to me) than some of the quibbling previous replies. :-)

Well, you were hungry, and I gave you a fish – others started to teach
you how to fish for yourself. :)

-- 
Christoph M. Becker

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

#30752 — Re: Interrogation of Shift-Key state - workaround

On Saturday, June 25, 2016 at 5:33:57 PM UTC-5, Janis wrote:
> (Closing my own question.)

> Simple static interrogation of the Shift key seems impossible in Javascript,
> as the replies in this thread seem to suggest.

Nonsense

> In my system context (Linux) the workaround that I wanted to avoid works as
> expected at least. So for folks who want to implement such functionality
> and are interested in my workaround I post the code skeleton for reference.
> 
>     var shiftState = false;
>     function keyEvent (ev) { shiftState = ev.shiftKey; }
>     document.addEventListener("keydown", keyEvent);
>     document.addEventListener("keyup", keyEvent);
> 
>     function f(arg)
>     {
>         if (shiftState) {
>             alert("shift");
>         } else {
>             alert("no shift");
>         }
>         ...
>     }

Which is insufficient as pointed out already

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

#30750

On 06/25/2016 09:59 AM, 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,

Yes, it is, but the onkeyup event cannot be cancelled just in case you 
need to.

> then I could adjust some global variable that I can interrogate
> where I need that information. But that is bulky and seems unnecessary(?)
> complex.

A global variable is not a good idea. And you may capture the shift Key 
pressing whenever needed.

>
> 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?

Just a simple example using the onkeydown event to prevent Shift key:

// HTML
<label for="txt1">TextBox1</label>
<input id="txt1" onkeydown="return getKey(event);" type="text" />

<script type="text/javascript">
function getKey(e) {
   if (!e) e = window.event;
   if (e.shiftKey) {
     alert('shiftKey is not allowed.');
     return false;
   }
   return true;
}
</script>

-- 
Joao Rodrigues

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web