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


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

Wait on keyboard

Started byjonas.thornvall@gmail.com
First post2016-03-11 02:30 -0800
Last post2016-03-14 18:58 +0800
Articles 20 on this page of 63 — 10 participants

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


Contents

  Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 02:30 -0800
    Re: Wait on keyboard Tim Streater <timstreater@greenbee.net> - 2016-03-11 10:37 +0000
    Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 02:50 -0800
      Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 03:13 -0800
        Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 03:23 -0800
          Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 03:32 -0800
            Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 03:39 -0800
              Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 04:41 -0800
                Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 05:00 -0800
                  Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 05:43 -0800
        Re: Wait on keyboard Tim Streater <timstreater@greenbee.net> - 2016-03-11 12:13 +0000
    Re: Wait on keyboard "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-03-11 21:52 +0800
      Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 07:29 -0800
    Re: Wait on keyboard Stefan Weiss <krewecherl@gmail.com> - 2016-03-11 17:00 +0100
      Re: Wait on keyboard Stefan Weiss <krewecherl@gmail.com> - 2016-03-11 17:11 +0100
        Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 08:32 -0800
          Re: Wait on keyboard Stefan Weiss <krewecherl@gmail.com> - 2016-03-11 20:20 +0100
        Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 08:55 -0800
          Re: Wait on keyboard Aleksandro <aleksandro@gmx.com> - 2016-03-11 16:30 -0300
            Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 11:46 -0800
              Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 12:22 -0800
                Re: Wait on keyboard Aleksandro <aleksandro@gmx.com> - 2016-03-11 17:25 -0300
                  Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 12:32 -0800
                    Re: Wait on keyboard Aleksandro <aleksandro@gmx.com> - 2016-03-11 17:42 -0300
                      Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 12:52 -0800
                    Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-11 12:47 -0800
                    Re: Wait on keyboard "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-03-11 18:39 -0800
                Re: Wait on keyboard "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-03-11 18:37 -0800
                Re: Wait on keyboard John Harris <niam@jghnorth.org.uk.invalid> - 2016-03-12 13:16 +0000
                  Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-12 05:57 -0800
                    Re: Wait on keyboard John Harris <niam@jghnorth.org.uk.invalid> - 2016-03-13 10:31 +0000
                      Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-13 05:55 -0700
                        Re: Wait on keyboard "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-13 17:19 +0100
                        Re: Wait on keyboard Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-13 13:01 -0700
                          Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-13 15:19 -0700
                            Re: Wait on keyboard Aleksandro <aleksandro@gmx.com> - 2016-03-13 20:08 -0300
                              Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-13 21:45 -0700
                                Re: Wait on keyboard Aleksandro <aleksandro@gmx.com> - 2016-03-14 01:50 -0300
                                  Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-13 22:39 -0700
                                    Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-13 22:46 -0700
                                    Re: Wait on keyboard Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-14 11:54 -0700
                                Re: Wait on keyboard Tim Streater <timstreater@greenbee.net> - 2016-03-14 08:31 +0000
                                Re: Wait on keyboard John Harris <niam@jghnorth.org.uk.invalid> - 2016-03-14 10:43 +0000
                  Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-12 06:04 -0800
                    Re: Wait on keyboard "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-12 15:22 +0100
                      Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-12 07:46 -0800
                        Re: Wait on keyboard Tim Streater <timstreater@greenbee.net> - 2016-03-12 15:52 +0000
                        Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-12 09:25 -0800
                          Re: Wait on keyboard Aleksandro <aleksandro@gmx.com> - 2016-03-12 20:16 -0300
                            Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-12 15:57 -0800
                              Re: Wait on keyboard Aleksandro <aleksandro@gmx.com> - 2016-03-12 21:07 -0300
                              Re: Wait on keyboard Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-12 21:27 -0800
                                Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-13 03:08 -0700
                        Re: Wait on keyboard "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-12 23:30 +0100
                  Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-12 06:15 -0800
              Re: Wait on keyboard "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-03-11 18:33 -0800
                Re: Wait on keyboard jonas.thornvall@gmail.com - 2016-03-12 03:01 -0800
      Re: Wait on keyboard "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-03-11 18:30 -0800
      Re: Wait on keyboard Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-12 04:44 +0100
        Re: Wait on keyboard Stefan Weiss <krewecherl@gmail.com> - 2016-03-12 11:21 +0100
          Re: Wait on keyboard Stefan Weiss <krewecherl@gmail.com> - 2016-03-12 11:27 +0100
          Re: Wait on keyboard Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-12 14:44 +0100
      Re: Wait on keyboard "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-03-14 18:58 +0800

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →


#29988

FromScott Sauyet <scott.sauyet@gmail.com>
Date2016-03-14 11:54 -0700
Message-ID<36f7cb82-ce67-461a-888a-0bff96ff1ee4@googlegroups.com>
In reply to#29974
jonas.thornvall@gmail.com wrote: 
> Aleksandro wrote:
>> jonas.thornvall@gmail.com wrote:

>>> I wano to call functions on presskey.
>> 
>> And your problem is...?
>>
> That the examples i find want to me to be in a textfield or use 
> another "id" element to reach the keylisteener. There is no global
> keylistener?

You want to listen for any key press anywhere?
 So, if in a small village in Rompin, Malaysia, a young musical 
prodigy destined to write three great symphonies and redefine serious 
music, bringing both hope and despair to the classical music critic 
for the New York Times, destined to write the first song beamed to 
approaching alien spaceship, destined to love and lose six times 
before her tragic death at age 28 -- if she one warm evening in 
mid-June on a toy piano carved from a saman tree presses the key for 
middle-C, you want your code to capture that? 

Oh, are you looking only for computer keys? You want to capture the 
programmer thrilled to hit backspace one final time knowing that his 
system has reached that perfection in which there's nothing left to 
remove, the nuclear technician whose conscience finally wins out over 
her orders as she refuses to press the key for launch, pressing 
instead the one for abort, and the schoolchild -- who doesn't know his 
"keyboarding" class was once called "typing" -- gleefully banging on 
the "G", because that's how his name starts? 

No, you mean on your computer alone? That's a strange notion of 
"global", but never mind. So, then you want to capture the comma you 
agonize over in the email to a potential employer, to capture the 
ever-weaker, ever-despairing mashes on the F1 key as you look 
desperately for help, any help you can find in this unfeeling world, 
and to capture that up-arrow as your retro-game character bravely 
jumps from one falling block to another, and you find you've lost your 
sympathy for his two-dimensional plight? 

Or no, this is only for your browser? You need to capture the hesitant 
typing in the search bar as you stop once again stymied because you 
never remember if it's spelled "seperate" or "separate" and 
"desperate" or "desparate", the graceful way your pinkies spread 
across the diagonal to type CTRL-TAB, the speed at which you can hit 
ALT-Backspace when it turns out that link is actually not safe for 
work, the embarrassment of using CMD-P, and admitting that in the 
digital age, you still rely on dead-tree versions of far too many 
documents. 

You mean this is only for your current tab/window? That's all you care 
about? Why didn't you say so? 


    window.addEventListener("keyup", function (event) {
      // work with event.keyCode, event.shiftKey, event.altKey, etc.
    }, false);

(See `addEventListener` [1] and `KeyboardEvent` [2] for more 
information.) 
  
People have been telling you this for quite some time in this thread. 
If you were willing to get off your high horse and listen to them, you 
would have heard this quite a while ago. 


  [1]: <https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener>
  [2]: <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent>
  
  -- Scott

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


#29976

FromTim Streater <timstreater@greenbee.net>
Date2016-03-14 08:31 +0000
Message-ID<140320160831597237%timstreater@greenbee.net>
In reply to#29972
In article <c0352a15-5432-436a-8b29-823c9518050a@googlegroups.com>,
<jonas.thornvall@gmail.com> wrote:

>Den måndag 14 mars 2016 kl. 00:08:38 UTC+1 skrev Aleksandro:
>> On 13/03/16 19:19, jonas.thornvall@gmail.com wrote:
>> > I wano to call functions on presskey.
>> 
>> And your problem is...?
>That the examples i find want to me to be in a textfield or use another "id"
>element to reach the keylisteener. There is no global keylistener?

Why should there be? There are events, and two different models of
event propagation. You attach a handler to an element if you think the
event is relevant for that element. In your case I'd attach it to the
<body>.

-- 
"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]


#29979

FromJohn Harris <niam@jghnorth.org.uk.invalid>
Date2016-03-14 10:43 +0000
Message-ID<1d5deb5jprt9v7p4kt4jmhfvabpesgjqkj@4ax.com>
In reply to#29972
On Sun, 13 Mar 2016 21:45:52 -0700 (PDT), jonas.thornvall@gmail.com
wrote:

>Den måndag 14 mars 2016 kl. 00:08:38 UTC+1 skrev Aleksandro:
>> On 13/03/16 19:19, jonas.thornvall@gmail.com wrote:
>> > I wano to call functions on presskey.
>> 
>> And your problem is...?
>That the examples i find want to me to be in a textfield or use another "id" element to reach the keylisteener. There is no global keylistener?
  <snip>

Why is there no global keylistener? 

Well, because when the language started it was as small as possible.
Anything the user could program had to be programmed by the user. It
was not done by the compiler. Since then, some things have been added
to save the programmers having to do it themselves, but this has been
limited to the things a lot of people have demanded.

Obviously, not a lot of web designers want to get key presses outside
text input fields. Or perhaps the ones that do have made or purchased
a library that makes it easy for them.

  John

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


#29937

Fromjonas.thornvall@gmail.com
Date2016-03-12 06:04 -0800
Message-ID<cfd163f7-dc45-4cf1-b8cb-9f1b0b6c4993@googlegroups.com>
In reply to#29932
Den lördag 12 mars 2016 kl. 14:16:30 UTC+1 skrev John Harris:
> On Fri, 11 Mar 2016 12:22:29 -0800 (PST), jonas.thornvall@gmail.com
> wrote:
> 
>   <snip>
> >No these are anal people they can't fucking go for wait until (keypress=="32!) then do "what the fuck ever".
>   <snip>
> 
> You write 
>   wait until (keypress==32);
> in your program and it's legal because ECMAScript has been enhanced
> the way you wanted. But your program is running in the web server and
> there is *no* User Interface! 
> 
> What should the compiler do when it sees this? Obviously, it should
> send an e-mail to the ECMA committee saying that they are bloody
> idiots for putting such a stupid thing in the language.
> 
> 
> >Well you retarded, anal *MOTHERFUCKERS* are in for a wakeup call.
> 
> It looks as though the wakeup call has already hit a programmer who
> splashes code down without thinking and then discovers the all too
> predictable consequences.
> 
>   John

And you know as well as i that you can't run the same type of code using a JS serverside scripts as the clientside web browser script.  It is another type of interpreter, they are not equivalent.

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


#29939

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2016-03-12 15:22 +0100
Message-ID<XnsA5C99C64E1C14eejj99@194.109.6.166>
In reply to#29937
jonas.thornvall@gmail.com wrote on 12 Mar 2016 in comp.lang.javascript:

> And you know as well as i

So you are an expert on the knowledge of others?

I even doubt you yourself know what you know.
That would explain why you need to answer yourself in those long monologues.

> that you can't run the same type of code using
> a JS serverside scripts as the clientside web browser script.  It is
> another type of interpreter, they are not equivalent. 

Nonsense.

var a = 3 * 4;

runs exactly the same on serverside execution as on clientside execution.

The IE-Javascript engine and the ASP-Jscript engine have been exactly the 
same, except for the interface. The browser-engines of different browsers 
are different, but all have an interface to the DOM, the server-engine has 
no DOM interface. 

Usually there is no one around at the server to use a keyboard or look at a 
screen anyway. Many servers run hundreds of websites, so would need hundreds 
of keyboeard/screen/operators working around the clock.





-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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


#29941

Fromjonas.thornvall@gmail.com
Date2016-03-12 07:46 -0800
Message-ID<35b92d72-d65a-4866-b060-7b448d24d4f1@googlegroups.com>
In reply to#29939
Den lördag 12 mars 2016 kl. 15:23:04 UTC+1 skrev Evertjan.:
> jonas.thornvall@gmail.com wrote on 12 Mar 2016 in comp.lang.javascript:
> 
> > And you know as well as i
> 
> So you are an expert on the knowledge of others?
> 
> I even doubt you yourself know what you know.
> That would explain why you need to answer yourself in those long monologues.
> 
> > that you can't run the same type of code using
> > a JS serverside scripts as the clientside web browser script.  It is
> > another type of interpreter, they are not equivalent. 
> 
> Nonsense.
> 
> var a = 3 * 4;
> 
> runs exactly the same on serverside execution as on clientside execution.
> 
> The IE-Javascript engine and the ASP-Jscript engine have been exactly the 
> same, except for the interface. The browser-engines of different browsers 
> are different, but all have an interface to the DOM, the server-engine has 
> no DOM interface. 
> 
> Usually there is no one around at the server to use a keyboard or look at a 
> screen anyway. Many servers run hundreds of websites, so would need hundreds 
> of keyboeard/screen/operators working around the clock.
> 
> 
> 
> 
> 
> -- 
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

Oh gosh how stupid of me to think that keypress belonged to the UI, because that was what John Harris was talking about.

Timer of course don't but i can not really see why ***wait***  and ***keypress*** could not be part of the UI interface.

wait (mouseDown)
wait (keyPress=="32")

And i do not really see why something like

if (keyPress=="32") dosomething();

Can't be allowed i can only see benefits from a simplified approach of eventhandling. It is not different from setting a range for mouse driven function call.

if (mouseDown.x >= arr[t].rposX && mouseDown.x <= (arr[t].rposX + arr[t].rwidth) && mouseDown.y >= arr[t].rposY && mouseDown.y <= (arr[t].rposY + arr[t].rheigth))dosomething()

But you can see the difference in labour effort doing the function call.

And you could achieve alot of things like maka a real good texteditor or any other UI application that use keypress shortcuts to perform actions by calling functions. It would be quite another language and allow for different approaches creating UI. Personally i like click drag drop but that doesn't mean that keyboard driven eventhandling should be prohibited or be done with such agony of labour that people simply skip or refuse to use it in their applications.



Maybe there is a good reason for it not to be allowed or preference of choice, but then i would like to know it.

 

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


#29943

FromTim Streater <timstreater@greenbee.net>
Date2016-03-12 15:52 +0000
Message-ID<120320161552438741%timstreater@greenbee.net>
In reply to#29941
In article <35b92d72-d65a-4866-b060-7b448d24d4f1@googlegroups.com>,
<jonas.thornvall@gmail.com> wrote:

>And you could achieve alot of things like maka a real good texteditor or any
>other UI application that use keypress shortcuts to perform actions by calling
>functions. It would be quite another language and allow for different
>approaches creating UI. Personally i like click drag drop but that doesn't
>mean that keyboard driven eventhandling should be prohibited or be done with
>such agony of labour that people simply skip or refuse to use it in their
>applications.

Why are you having such difficulty with this? It's really very simple:

1) Attach onkeypress to something. In my example I attached it to the
<body>. One statement.

2) Decide what to do with the keypress. One statement.


What's so hard about two statements?

You method of doing:

  wait(keypress)

means your application STOPS while waiting for a key to be pressed.
What is the use of that?

-- 
New Socialism consists essentially in being seen to have your heart in 
the right place whilst your head is in the clouds and your hand is in 
someone else's pocket.

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


#29944

Fromjonas.thornvall@gmail.com
Date2016-03-12 09:25 -0800
Message-ID<516a9322-9783-40e9-a512-795e86df76c8@googlegroups.com>
In reply to#29941
Den lördag 12 mars 2016 kl. 16:47:11 UTC+1 skrev jonas.t...@gmail.com:
> Den lördag 12 mars 2016 kl. 15:23:04 UTC+1 skrev Evertjan.:
> > jonas.thornvall@gmail.com wrote on 12 Mar 2016 in comp.lang.javascript:
> > 
> > > And you know as well as i
> > 
> > So you are an expert on the knowledge of others?
> > 
> > I even doubt you yourself know what you know.
> > That would explain why you need to answer yourself in those long monologues.
> > 
> > > that you can't run the same type of code using
> > > a JS serverside scripts as the clientside web browser script.  It is
> > > another type of interpreter, they are not equivalent. 
> > 
> > Nonsense.
> > 
> > var a = 3 * 4;
> > 
> > runs exactly the same on serverside execution as on clientside execution.
> > 
> > The IE-Javascript engine and the ASP-Jscript engine have been exactly the 
> > same, except for the interface. The browser-engines of different browsers 
> > are different, but all have an interface to the DOM, the server-engine has 
> > no DOM interface. 
> > 
> > Usually there is no one around at the server to use a keyboard or look at a 
> > screen anyway. Many servers run hundreds of websites, so would need hundreds 
> > of keyboeard/screen/operators working around the clock.
> > 
> > 
> > 
> > 
> > 
> > -- 
> > Evertjan.
> > The Netherlands.
> > (Please change the x'es to dots in my emailaddress)
> 
> Oh gosh how stupid of me to think that keypress belonged to the UI, because that was what John Harris was talking about.
> 
> Timer of course don't but i can not really see why ***wait***  and ***keypress*** could not be part of the UI interface.
> 
> wait (mouseDown)
> wait (keyPress=="32")
> 
> And i do not really see why something like
> 
> if (keyPress=="32") dosomething();
> 
> Can't be allowed i can only see benefits from a simplified approach of eventhandling. It is not different from setting a range for mouse driven function call.
> 
> if (mouseDown.x >= arr[t].rposX && mouseDown.x <= (arr[t].rposX + arr[t].rwidth) && mouseDown.y >= arr[t].rposY && mouseDown.y <= (arr[t].rposY + arr[t].rheigth))dosomething()
> 
> But you can see the difference in labour effort doing the function call.
> 
> And you could achieve alot of things like maka a real good texteditor or any other UI application that use keypress shortcuts to perform actions by calling functions. It would be quite another language and allow for different approaches creating UI. Personally i like click drag drop but that doesn't mean that keyboard driven eventhandling should be prohibited or be done with such agony of labour that people simply skip or refuse to use it in their applications.
> 
> 
> 
> Maybe there is a good reason for it not to be allowed or preference of choice, but then i would like to know it.

Finally found some useful code.

<head>
    <script type="text/javascript">
        function Init () {
            var counter = document.getElementById ("counter");
            for (var i = 1; i < 1000; i++) {
                var option = new Option (i, i);
                counter.options.add (option);
            }
            counter.focus ();
        }

        function OnKeyPressCounter (event, counter) {
            var chCode = ('charCode' in event) ? event.charCode : event.keyCode;

            if (chCode == 43 /* + */) {
                if (counter.selectedIndex < counter.options.length - 1) {
                    counter.selectedIndex++;
                }
            }
            if (chCode == 45 /* - */) {
                if (counter.selectedIndex > 0) {
                    counter.selectedIndex--;
                }
            }
        }
    </script>
</head>
<body onload="Init ()">
    Use the + and - keys to increase/decrease the counter.
    <select id="counter" onkeypress="OnKeyPressCounter (event, this)" style="width:80px"></select>
</body>

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


#29947

FromAleksandro <aleksandro@gmx.com>
Date2016-03-12 20:16 -0300
Message-ID<nc27q5$ca5$1@dont-email.me>
In reply to#29944
On 12/03/16 14:25, jonas.thornvall@gmail.com wrote:
> Den lördag 12 mars 2016 kl. 16:47:11 UTC+1 skrev jonas.t...@gmail.com:
>> Den lördag 12 mars 2016 kl. 15:23:04 UTC+1 skrev Evertjan.:
>>> jonas.thornvall@gmail.com wrote on 12 Mar 2016 in comp.lang.javascript:
>>>
>>>> And you know as well as i
>>>
>>> So you are an expert on the knowledge of others?
>>>
>>> I even doubt you yourself know what you know.
>>> That would explain why you need to answer yourself in those long monologues.
>>>
>>>> that you can't run the same type of code using
>>>> a JS serverside scripts as the clientside web browser script.  It is
>>>> another type of interpreter, they are not equivalent. 
>>>
>>> Nonsense.
>>>
>>> var a = 3 * 4;
>>>
>>> runs exactly the same on serverside execution as on clientside execution.
>>>
>>> The IE-Javascript engine and the ASP-Jscript engine have been exactly the 
>>> same, except for the interface. The browser-engines of different browsers 
>>> are different, but all have an interface to the DOM, the server-engine has 
>>> no DOM interface. 
>>>
>>> Usually there is no one around at the server to use a keyboard or look at a 
>>> screen anyway. Many servers run hundreds of websites, so would need hundreds 
>>> of keyboeard/screen/operators working around the clock.
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> Evertjan.
>>> The Netherlands.
>>> (Please change the x'es to dots in my emailaddress)
>>
>> Oh gosh how stupid of me to think that keypress belonged to the UI, because that was what John Harris was talking about.
>>
>> Timer of course don't but i can not really see why ***wait***  and ***keypress*** could not be part of the UI interface.
>>
>> wait (mouseDown)
>> wait (keyPress=="32")
>>
>> And i do not really see why something like
>>
>> if (keyPress=="32") dosomething();
>>
>> Can't be allowed i can only see benefits from a simplified approach of eventhandling. It is not different from setting a range for mouse driven function call.
>>
>> if (mouseDown.x >= arr[t].rposX && mouseDown.x <= (arr[t].rposX + arr[t].rwidth) && mouseDown.y >= arr[t].rposY && mouseDown.y <= (arr[t].rposY + arr[t].rheigth))dosomething()
>>
>> But you can see the difference in labour effort doing the function call.
>>
>> And you could achieve alot of things like maka a real good texteditor or any other UI application that use keypress shortcuts to perform actions by calling functions. It would be quite another language and allow for different approaches creating UI. Personally i like click drag drop but that doesn't mean that keyboard driven eventhandling should be prohibited or be done with such agony of labour that people simply skip or refuse to use it in their applications.
>>
>>
>>
>> Maybe there is a good reason for it not to be allowed or preference of choice, but then i would like to know it.
> 
> Finally found some useful code.
> 
> <head>
>     <script type="text/javascript">
>         function Init () {
>             var counter = document.getElementById ("counter");
>             for (var i = 1; i < 1000; i++) {
>                 var option = new Option (i, i);
>                 counter.options.add (option);
>             }
>             counter.focus ();
>         }
> 
>         function OnKeyPressCounter (event, counter) {
>             var chCode = ('charCode' in event) ? event.charCode : event.keyCode;
> 
>             if (chCode == 43 /* + */) {
>                 if (counter.selectedIndex < counter.options.length - 1) {
>                     counter.selectedIndex++;
>                 }
>             }
>             if (chCode == 45 /* - */) {
>                 if (counter.selectedIndex > 0) {
>                     counter.selectedIndex--;
>                 }
>             }
>         }
>     </script>
> </head>
> <body onload="Init ()">
>     Use the + and - keys to increase/decrease the counter.
>     <select id="counter" onkeypress="OnKeyPressCounter (event, this)" style="width:80px"></select>
> </body>

By judging your excess “self confidence” I thought you would have
already figured how to do it by yourself. But now that I read what you
call “useful” code I am back to think you are rather clueless about
Javascript; that code is quite sloppy.

Everything would have been better if you asked nicely but well...

My suggestion, attach event listeners correctly from the script, you
might want to look on what bubbling is about.

If you have more questions, recognize it and ask, if you keep whining
like you have done then you better don't even bother asking, really.

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


#29949

Fromjonas.thornvall@gmail.com
Date2016-03-12 15:57 -0800
Message-ID<0a74df98-79bd-4e03-bfa1-dcbe81739ef9@googlegroups.com>
In reply to#29947
Den söndag 13 mars 2016 kl. 00:16:22 UTC+1 skrev Aleksandro:
> On 12/03/16 14:25, jonas.thornvall@gmail.com wrote:
> > Den lördag 12 mars 2016 kl. 16:47:11 UTC+1 skrev jonas.t...@gmail.com:
> >> Den lördag 12 mars 2016 kl. 15:23:04 UTC+1 skrev Evertjan.:
> >>> jonas.thornvall@gmail.com wrote on 12 Mar 2016 in comp.lang.javascript:
> >>>
> >>>> And you know as well as i
> >>>
> >>> So you are an expert on the knowledge of others?
> >>>
> >>> I even doubt you yourself know what you know.
> >>> That would explain why you need to answer yourself in those long monologues.
> >>>
> >>>> that you can't run the same type of code using
> >>>> a JS serverside scripts as the clientside web browser script.  It is
> >>>> another type of interpreter, they are not equivalent. 
> >>>
> >>> Nonsense.
> >>>
> >>> var a = 3 * 4;
> >>>
> >>> runs exactly the same on serverside execution as on clientside execution.
> >>>
> >>> The IE-Javascript engine and the ASP-Jscript engine have been exactly the 
> >>> same, except for the interface. The browser-engines of different browsers 
> >>> are different, but all have an interface to the DOM, the server-engine has 
> >>> no DOM interface. 
> >>>
> >>> Usually there is no one around at the server to use a keyboard or look at a 
> >>> screen anyway. Many servers run hundreds of websites, so would need hundreds 
> >>> of keyboeard/screen/operators working around the clock.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> -- 
> >>> Evertjan.
> >>> The Netherlands.
> >>> (Please change the x'es to dots in my emailaddress)
> >>
> >> Oh gosh how stupid of me to think that keypress belonged to the UI, because that was what John Harris was talking about.
> >>
> >> Timer of course don't but i can not really see why ***wait***  and ***keypress*** could not be part of the UI interface.
> >>
> >> wait (mouseDown)
> >> wait (keyPress=="32")
> >>
> >> And i do not really see why something like
> >>
> >> if (keyPress=="32") dosomething();
> >>
> >> Can't be allowed i can only see benefits from a simplified approach of eventhandling. It is not different from setting a range for mouse driven function call.
> >>
> >> if (mouseDown.x >= arr[t].rposX && mouseDown.x <= (arr[t].rposX + arr[t].rwidth) && mouseDown.y >= arr[t].rposY && mouseDown.y <= (arr[t].rposY + arr[t].rheigth))dosomething()
> >>
> >> But you can see the difference in labour effort doing the function call.
> >>
> >> And you could achieve alot of things like maka a real good texteditor or any other UI application that use keypress shortcuts to perform actions by calling functions. It would be quite another language and allow for different approaches creating UI. Personally i like click drag drop but that doesn't mean that keyboard driven eventhandling should be prohibited or be done with such agony of labour that people simply skip or refuse to use it in their applications.
> >>
> >>
> >>
> >> Maybe there is a good reason for it not to be allowed or preference of choice, but then i would like to know it.
> > 
> > Finally found some useful code.
> > 
> > <head>
> >     <script type="text/javascript">
> >         function Init () {
> >             var counter = document.getElementById ("counter");
> >             for (var i = 1; i < 1000; i++) {
> >                 var option = new Option (i, i);
> >                 counter.options.add (option);
> >             }
> >             counter.focus ();
> >         }
> > 
> >         function OnKeyPressCounter (event, counter) {
> >             var chCode = ('charCode' in event) ? event.charCode : event.keyCode;
> > 
> >             if (chCode == 43 /* + */) {
> >                 if (counter.selectedIndex < counter.options.length - 1) {
> >                     counter.selectedIndex++;
> >                 }
> >             }
> >             if (chCode == 45 /* - */) {
> >                 if (counter.selectedIndex > 0) {
> >                     counter.selectedIndex--;
> >                 }
> >             }
> >         }
> >     </script>
> > </head>
> > <body onload="Init ()">
> >     Use the + and - keys to increase/decrease the counter.
> >     <select id="counter" onkeypress="OnKeyPressCounter (event, this)" style="width:80px"></select>
> > </body>
> 
> By judging your excess "self confidence" I thought you would have
> already figured how to do it by yourself. But now that I read what you
> call "useful" code I am back to think you are rather clueless about
> Javascript; that code is quite sloppy.
> 
> Everything would have been better if you asked nicely but well...
> 
> My suggestion, attach event listeners correctly from the script, you
> might want to look on what bubbling is about.
> 
> If you have more questions, recognize it and ask, if you keep whining
> like you have done then you better don't even bother asking, really.

To be honest i have solutions that is far better than you people propose because your approaches really does not make sense. Only hard indoctrination learning howto pile shit can make one go your route. Fortunatly i am not quite there yet i still have a couple of braincells left in me.

But i must say both your defend of something that so obviously stupid and your quirky fix arounds that really doesn't solve the problem with pore structure annoys me. So i will fix it without even look at your flawed eventhandling, because in the end it is so stupid it is laughable.

I will write the few lines needed to get my debug.

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


#29950

FromAleksandro <aleksandro@gmx.com>
Date2016-03-12 21:07 -0300
Message-ID<nc2aq9$boh$1@dont-email.me>
In reply to#29949
On 12/03/16 20:57, jonas.thornvall@gmail.com wrote:
> Den söndag 13 mars 2016 kl. 00:16:22 UTC+1 skrev Aleksandro:
>> On 12/03/16 14:25, jonas.thornvall@gmail.com wrote:
>>> Den lördag 12 mars 2016 kl. 16:47:11 UTC+1 skrev jonas.t...@gmail.com:
>>>> Den lördag 12 mars 2016 kl. 15:23:04 UTC+1 skrev Evertjan.:
>>>>> jonas.thornvall@gmail.com wrote on 12 Mar 2016 in comp.lang.javascript:
>>>>>
>>>>>> And you know as well as i
>>>>>
>>>>> So you are an expert on the knowledge of others?
>>>>>
>>>>> I even doubt you yourself know what you know.
>>>>> That would explain why you need to answer yourself in those long monologues.
>>>>>
>>>>>> that you can't run the same type of code using
>>>>>> a JS serverside scripts as the clientside web browser script.  It is
>>>>>> another type of interpreter, they are not equivalent. 
>>>>>
>>>>> Nonsense.
>>>>>
>>>>> var a = 3 * 4;
>>>>>
>>>>> runs exactly the same on serverside execution as on clientside execution.
>>>>>
>>>>> The IE-Javascript engine and the ASP-Jscript engine have been exactly the 
>>>>> same, except for the interface. The browser-engines of different browsers 
>>>>> are different, but all have an interface to the DOM, the server-engine has 
>>>>> no DOM interface. 
>>>>>
>>>>> Usually there is no one around at the server to use a keyboard or look at a 
>>>>> screen anyway. Many servers run hundreds of websites, so would need hundreds 
>>>>> of keyboeard/screen/operators working around the clock.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Evertjan.
>>>>> The Netherlands.
>>>>> (Please change the x'es to dots in my emailaddress)
>>>>
>>>> Oh gosh how stupid of me to think that keypress belonged to the UI, because that was what John Harris was talking about.
>>>>
>>>> Timer of course don't but i can not really see why ***wait***  and ***keypress*** could not be part of the UI interface.
>>>>
>>>> wait (mouseDown)
>>>> wait (keyPress=="32")
>>>>
>>>> And i do not really see why something like
>>>>
>>>> if (keyPress=="32") dosomething();
>>>>
>>>> Can't be allowed i can only see benefits from a simplified approach of eventhandling. It is not different from setting a range for mouse driven function call.
>>>>
>>>> if (mouseDown.x >= arr[t].rposX && mouseDown.x <= (arr[t].rposX + arr[t].rwidth) && mouseDown.y >= arr[t].rposY && mouseDown.y <= (arr[t].rposY + arr[t].rheigth))dosomething()
>>>>
>>>> But you can see the difference in labour effort doing the function call.
>>>>
>>>> And you could achieve alot of things like maka a real good texteditor or any other UI application that use keypress shortcuts to perform actions by calling functions. It would be quite another language and allow for different approaches creating UI. Personally i like click drag drop but that doesn't mean that keyboard driven eventhandling should be prohibited or be done with such agony of labour that people simply skip or refuse to use it in their applications.
>>>>
>>>>
>>>>
>>>> Maybe there is a good reason for it not to be allowed or preference of choice, but then i would like to know it.
>>>
>>> Finally found some useful code.
>>>
>>> <head>
>>>     <script type="text/javascript">
>>>         function Init () {
>>>             var counter = document.getElementById ("counter");
>>>             for (var i = 1; i < 1000; i++) {
>>>                 var option = new Option (i, i);
>>>                 counter.options.add (option);
>>>             }
>>>             counter.focus ();
>>>         }
>>>
>>>         function OnKeyPressCounter (event, counter) {
>>>             var chCode = ('charCode' in event) ? event.charCode : event.keyCode;
>>>
>>>             if (chCode == 43 /* + */) {
>>>                 if (counter.selectedIndex < counter.options.length - 1) {
>>>                     counter.selectedIndex++;
>>>                 }
>>>             }
>>>             if (chCode == 45 /* - */) {
>>>                 if (counter.selectedIndex > 0) {
>>>                     counter.selectedIndex--;
>>>                 }
>>>             }
>>>         }
>>>     </script>
>>> </head>
>>> <body onload="Init ()">
>>>     Use the + and - keys to increase/decrease the counter.
>>>     <select id="counter" onkeypress="OnKeyPressCounter (event, this)" style="width:80px"></select>
>>> </body>
>>
>> By judging your excess "self confidence" I thought you would have
>> already figured how to do it by yourself. But now that I read what you
>> call "useful" code I am back to think you are rather clueless about
>> Javascript; that code is quite sloppy.
>>
>> Everything would have been better if you asked nicely but well...
>>
>> My suggestion, attach event listeners correctly from the script, you
>> might want to look on what bubbling is about.
>>
>> If you have more questions, recognize it and ask, if you keep whining
>> like you have done then you better don't even bother asking, really.
> 
> To be honest i have solutions that is far better than you people propose because your approaches really does not make sense. Only hard indoctrination learning howto pile shit can make one go your route. Fortunatly i am not quite there yet i still have a couple of braincells left in me.
> 
> But i must say both your defend of something that so obviously stupid and your quirky fix arounds that really doesn't solve the problem with pore structure annoys me. So i will fix it without even look at your flawed eventhandling, because in the end it is so stupid it is laughable.
> 
> I will write the few lines needed to get my debug.

lol

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


#29951

FromScott Sauyet <scott.sauyet@gmail.com>
Date2016-03-12 21:27 -0800
Message-ID<37ff468b-b170-4fbb-942e-ca2253547612@googlegroups.com>
In reply to#29949
jonas.thornvall@gmail.com wrote:
> To be honest i have solutions that is far better than you people 
> propose because your approaches really does not make sense.

Well, I for one am glad to hear it.  I'm really looking forward to
seeing your new approach.  I assume it will deal with all the constraints
of the original problem in a seamless fashion, to wit:

  * It will integrate all on-page user activity into a single
    API so that I as a programmer don't have to learn separate
    syntaxes for all the different input types and control types
    available.
  * It will work asynchronously, so that a programmer cannot lock
    up the users' browser with a naive call to the API.
  * It will keep to a syntax familiar to C++/Java programmers.
  * It will not dictate precisely where you track your activity,
    allowing instead any ancestor element of a targeted one
    to serve as the host of your activity.
  * Nonetheless, it will allow the programmer to decide in certain
    circumstances that the activity has been dealt with completely
    and stop anyone else that may have been waiting to hear about
    it from getting word.

As it took the original developer ten whole days to create the first
version of the language, we figure you should be given just as much 
time to write this critical feature.  So we expect to see it be 
ready 2016-03-23T00:30:00.

Please get back to us then and let us know the status... but not before
then.

Thanks,

  -- Scott

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


#29953

Fromjonas.thornvall@gmail.com
Date2016-03-13 03:08 -0700
Message-ID<03ecefb0-d734-4508-948b-c79e3c03bba9@googlegroups.com>
In reply to#29951
Den söndag 13 mars 2016 kl. 06:27:53 UTC+1 skrev Scott Sauyet:
> jonas.thornvall@gmail.com wrote:
> > To be honest i have solutions that is far better than you people 
> > propose because your approaches really does not make sense.
> 
> Well, I for one am glad to hear it.  I'm really looking forward to
> seeing your new approach.  I assume it will deal with all the constraints
> of the original problem in a seamless fashion, to wit:
> 
>   * It will integrate all on-page user activity into a single
>     API so that I as a programmer don't have to learn separate
>     syntaxes for all the different input types and control types
>     available.
>   * It will work asynchronously, so that a programmer cannot lock
>     up the users' browser with a naive call to the API.
>   * It will keep to a syntax familiar to C++/Java programmers.
>   * It will not dictate precisely where you track your activity,
>     allowing instead any ancestor element of a targeted one
>     to serve as the host of your activity.
>   * Nonetheless, it will allow the programmer to decide in certain
>     circumstances that the activity has been dealt with completely
>     and stop anyone else that may have been waiting to hear about
>     it from getting word.
> 
> As it took the original developer ten whole days to create the first
> version of the language, we figure you should be given just as much 
> time to write this critical feature.  So we expect to see it be 
> ready 2016-03-23T00:30:00.
> 
> Please get back to us then and let us know the status... but not before
> then.
> 
> Thanks,
> 
>   -- Scott

I think you missunderstood me Scott, i have solutions to my own efforts debugging the code without using the broken eventhandler.

Basicly i do not need your advice, but the eventhandling is a tiresome pile of  shit created out of convoluted confustion, it is by no means straightforward or efficient.

It suffer from a great deal of confustion on the programmers behalf.

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


#29945

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2016-03-12 23:30 +0100
Message-ID<XnsA5C9EF2ECDE71eejj99@194.109.6.166>
In reply to#29941
jonas.thornvall@gmail.com wrote on 12 Mar 2016 in comp.lang.javascript:

> Oh gosh how stupid of me 

You must be an even better judge of character, Jonas,
than I had thought.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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


#29938

Fromjonas.thornvall@gmail.com
Date2016-03-12 06:15 -0800
Message-ID<31fe4e8b-c348-4cec-9401-9c6a57ccf5e5@googlegroups.com>
In reply to#29932
Den lördag 12 mars 2016 kl. 14:16:30 UTC+1 skrev John Harris:
> On Fri, 11 Mar 2016 12:22:29 -0800 (PST), jonas.thornvall@gmail.com
> wrote:
> 
>   <snip>
> >No these are anal people they can't fucking go for wait until (keypress=="32!) then do "what the fuck ever".
>   <snip>
> 
> You write 
>   wait until (keypress==32);
> in your program and it's legal because ECMAScript has been enhanced
> the way you wanted. But your program is running in the web server and
> there is *no* User Interface! 
> 
> What should the compiler do when it sees this? Obviously, it should
> send an e-mail to the ECMA committee saying that they are bloody
> idiots for putting such a stupid thing in the language.
> 
> 
> >Well you retarded, anal *MOTHERFUCKERS* are in for a wakeup call.
> 
> It looks as though the wakeup call has already hit a programmer who
> splashes code down without thinking and then discovers the all too
> predictable consequences.
> 
>   John

And if i ever were to do any serverside scripting i am pretty sure i would go for Python instead, i think it has similar array and string features as javascript and it will probably execute alot faster and from there i will generate the HTML and javascript needed to run on the client.

I have done some serverside PHP generating both HTML and Javascript connectivity to mySQL and mimer databases. But it would not be sufficient for the things i would like to do now. And i know idea how you dream about executing serverside javascript using clientside code you just try to obfuscate the fact that the eventlisteners and eventhandling code in  Javascript is both insufficient and inadequate for the purpose it is meant to handle. Yes the people that programmed it should be sent to a dark corner and be ashamed about how their anal tendencies started to effect both usability and effeciency of the program language. Better yet they should start it all over with a sound approach.

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


#29924

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2016-03-11 18:33 -0800
Message-ID<e4fa3a7a-b754-42ea-ac95-372656a186c5@googlegroups.com>
In reply to#29915
On Friday, March 11, 2016 at 1:46:31 PM UTC-6, jonas.t...@gmail.com wrote:

> Well just as i told you, the idiots that implemented the eventhandler and listeners are not the same people that deigned the core language.

Care to cite even a single point of evidence for this?

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


#29931

Fromjonas.thornvall@gmail.com
Date2016-03-12 03:01 -0800
Message-ID<7f25e990-a5f8-47f2-ae7f-f62fdfa12e3b@googlegroups.com>
In reply to#29924
Den lördag 12 mars 2016 kl. 03:33:30 UTC+1 skrev Michael Haufe (TNO):
> On Friday, March 11, 2016 at 1:46:31 PM UTC-6, jonas.t...@gmail.com wrote:
> 
> > Well just as i told you, the idiots that implemented the eventhandler and listeners are not the same people that deigned the core language.
> 
> Care to cite even a single point of evidence for this?

The implementation

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


#29923

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2016-03-11 18:30 -0800
Message-ID<4ae045b4-d151-4392-9697-3ee0972bc9c9@googlegroups.com>
In reply to#29909
On Friday, March 11, 2016 at 10:00:44 AM UTC-6, Stefan Weiss wrote:
> I'm going to reply to the first message in this thread, because I don't
> know when you'll be done replying to yourself, and I don't want to
> interrupt your conversation.

+100

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


#29928

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2016-03-12 04:44 +0100
Message-ID<9658502.p6PyTM0SGn@PointedEars.de>
In reply to#29909
Stefan Weiss wrote:

> With a little generator magic, you can make individual functions
> pause-able:
> 
>     var jonas = S(function* (start, max)

In which ECMAScript implementation is this not a syntax error, and if there 
is any, what does it mean there?

>     {

I prefer and recommend to write the opening brace of a function expression 
on the same line as the “function” keyword, if possible, to distinguish it 
from a function declaration.

> […]
> PS (group): I hacked this function together rather quickly.

Or is this the explanation for the quoted code?

> It works, but I'm sure it can be improved quite a bit. If you find 
> anything, I'd love to hear about it.

You’re welcome.

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


#29929

FromStefan Weiss <krewecherl@gmail.com>
Date2016-03-12 11:21 +0100
Message-ID<nc0qjv$b4e$1@news.albasani.net>
In reply to#29928
On 03/12/2016 04:44, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
> 
>> With a little generator magic, you can make individual functions
>> pause-able:
>>
>>     var jonas = S(function* (start, max)
> 
> In which ECMAScript implementation is this not a syntax error, and if there 
> is any, what does it mean there?

That's the generator function syntax:
http://www.ecma-international.org/ecma-262/6.0/#sec-generator-function-definitions
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*

It's supported by current versions of Firefox, Chrome, Edge (with the
experimental flag), and others:
http://kangax.github.io/compat-table/es6/#test-generators_basic_functionality

>> PS (group): I hacked this function together rather quickly.
> 
> Or is this the explanation for the quoted code?

No, honest request for feedback :)

There's one problem that I'm aware of with this approach: while the
function is paused and waiting for a timeout or event, it's possible to
execute it again:

   jonas(3,4); jonas(5,6);

This calls next() on the same generator for both, exhausting it earlier
than expected, and eventually resulting in "TypeError: gen is null".
I couldn't find a simple solution for this yesterday, so my advice at
the moment is to not do that :)

- stefan

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


Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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


csiph-web