I'd like to detect the shift key when a button is "clicked" in
Firefox/Mozilla. If the button is clicked with the mouse, no problem.
However, if the onclick event is keyboard originated, then my method is
not working. Same thing for SELECT elements.
The simple web page below shows the issue. Click with the mouse while
holding down the shift key, and the Shift key's status registers.
However, use Shift+Alt+o, or either (while the button has focus)
Shift+Space or Shift+Enter to kick off the onClick event and the shift
key is not detected. Works fine with IE 6 on my Win XP Pro.
<html><body><title>onClick and Shift key detection</title></head>
<body>
<button type=button accessKey=i
onclick="bclick(this,event)">on<u>C</u>lick</button>
<button type=button accessKey=a
onactivate="aclick(this,event)">on<u>A</u>ctivate</button>
<script type='text/javascript'>
function bclick(ctl,evt) {
evt = evt || window.event;
if (evt.shiftKey) alert("Shift key was pressed");
else alert("Shift key not detected");
}
function aclick(ctl, evt) {
/* evidently not working - see http://www.w3.org/TR/1999/WD-DOM-Lev...Events-UIEvent
*/
alert(evt.detail);
}
</script>
</body>
</html>
Any suggestions or comments?
Csaba Gabor from Vienna 7  7174 
Csaba Gabor wrote: I'd like to detect the shift key when a button is "clicked" in
Firefox/Mozilla. If the button is clicked with the mouse, no problem.
However, if the onclick event is keyboard originated, then my method is
not working. Same thing for SELECT elements.
The simple web page below shows the issue. Click with the mouse while
holding down the shift key, and the Shift key's status registers.
However, use Shift+Alt+o, or either (while the button has focus)
Shift+Alt+O could trigger another application as well. Shift+Alt+C triggers
a new KNotes note here, for example.
But what should that trigger in your case anyway? You have no accesskey="o"
anywhere.
Shift+Space or Shift+Enter to kick off the onClick event and the shift
key is not detected. Works fine with IE 6 on my Win XP Pro.
<html><body><title>onClick and Shift key detection</title></head>
Your markup is not Valid. Scripts operating on or within not Valid markup
are unlikely to work properly. <URL:http://validator.w3.org/>
Probably someone told you this before.
<body>
<button type=button accessKey=i
All attribute values should be quoted, no matter the value.
onclick="bclick(this,event)">on<u>C</u>lick</button>
Should you not underline the `i' if the accessibility key is "i"?
Ahhh -- but Alt+i triggers the history context menu with the Tab list here.
<button type=button accessKey=a
onactivate="aclick(this,event)">on<u>A</u>ctivate</button>
This is an element not defined before HTML 4.0, so it is even more
imperative that you declare the document type. However, no HTML
element has an `onactivate' attribute.
<script type='text/javascript'>
function bclick(ctl,evt) {
evt = evt || window.event;
if (!evt) evt = window.event;
if (evt)
{
if (evt.shiftKey) alert("Shift key was pressed");
else alert("Shift key not detected");
It would be better if you displayed the value of evt.shiftKey, because
it may be `undefined', which also evaluates to `false' in a boolean
expression.
}
function aclick(ctl, evt) {
/* evidently not working - see
http://www.w3.org/TR/1999/WD-DOM-Lev...Events-UIEvent
^^
Working Drafts MUST NOT be used as reference material. Use this instead:
<URL:http://www.w3.org/TR/DOM-Level-2/events.html#Events-UIEvent>
*/
alert(evt.detail);
However, I fail to see the relevance to your problem:
| The `detail' attribute inherited from UIEvent indicates the number of
| times a mouse button has been pressed and released over the same screen
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| location during a user action. The attribute value is 1 when the user
| begins this action and increments by 1 for each full sequence of pressing
| and releasing. If the user moves the mouse between the mousedown and
| mouseup the value will be set to 0, indicating that no click is occurring.
evt.detail works in Firefox 1.5.0.1/Linux -- for _mouse_ events.
Furthermore, the `onclick' code is is not added as event listener to the
target element using one of the W3C DOM Level 2 Events methods, so it is
not surprising that the behavior is different that you expect. However,
even if you do use addEventListener() it does not work as you expect.
The obvious reason is that `click' is specified as a mouse event, but
you trigger its intrinsic event handler with a keyboard event.
There is no DOM standard for keyboard events yet; there is a Working Draft
of W3C DOM Level 3 Events that includes the first time ever. So it is also
not surprising that Gecko-based and IE-based UAs work differently here.
[...]
Any suggestions or comments?
[x] done
PointedEars
Thomas 'PointedEars' Lahn wrote: Csaba Gabor wrote: I'd like to detect the shift key when a button is "clicked" in
Firefox/Mozilla. If the button is clicked with the mouse, no problem.
However, if the onclick event is keyboard originated, then my method is
not working. Same thing for SELECT elements.
The simple web page below shows the issue. Click with the mouse while
holding down the shift key, and the Shift key's status registers.
However, use Shift+Alt+o, or either (while the button has focus)
Shift+Alt+O could trigger another application as well. Shift+Alt+C triggers
a new KNotes note here, for example.
....
Your markup is not Valid. Scripts operating on or within not Valid markup
Sigh. There were several errors in the offered page, including <body>
appearing twice. Sorry about that. It was late and my transference
was poor. That should have been accessKey=c and Shift+Alt+c in the
text. Here's a proper page I have the beef with:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<title>onClick and Shift key detection</title></head>
<body>
<script type='text/javascript'>
function bclick(ctl,evt) {
evt = evt || window.event;
if (evt.shiftKey) alert("Shift key was pressed");
else alert("Shift key not detected");
}
</script>
<button type=button accessKey=c
onclick="bclick(this,event)">on<u>C</u>lick</button>
</body></html>
are unlikely to work properly. <URL:http://validator.w3.org/>
Not in my experience. If we define working properly as performing in
the way that the author believes it should. Appears to me most of the
pages I visit, including biggies such as google.com, amazon.com,
chase.com, and wired.com do not have a DOCTYPE at the top and yet these
pages work as (I think) they should in the browsers I use, FF and IE.
Browsers tend to be quite forgiving about sloppy markup, not that that
justifies it.
At the same time, unless possibly dealing with layout issues, I can't
think that that DOCTYPE or <meta ... content...> has EVER affected me
in the pages I've written. Except that as I recall, the validator used
to pout when <meta ... content...> was not in my pages and now, lo and
behold, it is no longer necessary. Thus, the motivation is really low
to install that terrifically ugly line at the top of my pages.
<button type=button accessKey=a
onactivate="aclick(this,event)">on<u>A</u>ctivate</button>
This is an element not defined before HTML 4.0, so it is even more
imperative that you declare the document type. However, no HTML
element has an `onactivate' attribute.
This is another thing that I forgot to mention. Turns out that IE 6
has an onactivate and it fires when button gets focus - I didn't look
into it. And detail there is not defined. This differs markedly from
what I read the intention of onactivate to be on the page I referenced.
}
function aclick(ctl, evt) {
/* evidently not working - see
http://www.w3.org/TR/1999/WD-DOM-Lev...Events-UIEvent
^^
Working Drafts MUST NOT be used as reference material. Use this instead:
<URL:http://www.w3.org/TR/DOM-Level-2/events.html#Events-UIEvent>
Thanks
However, I fail to see the relevance to your problem:
| The `detail' attribute inherited from UIEvent indicates the number of
| times a mouse button has been pressed and released over the same screen
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| location during a user action. The attribute value is 1 when the user
Yes, but detail in that working draft for onactivate said:
A numerical argument is provided to give an indication of the type of
activation that occurs: 1 for a simple activation (e.g. a simple click
or Enter), 2 for hyperactivation (for instance a double click or Shift
Enter).
From that I imagined that it might possibly be related to Shift, it it
worked at all. That was the only reason for the inclusion of the 2nd
button. But since we're on the topic, I put in an event listener for
DOMActivate and it fired when the button was clicked, but event.detail
was undefined for it.
....
Furthermore, the `onclick' code is is not added as event listener to the
target element using one of the W3C DOM Level 2 Events methods, so it is
not surprising that the behavior is different that you expect. However,
even if you do use addEventListener() it does not work as you expect.
I don't understand this - I must be missing your meaning. Are you
saying that putting onclick="..." in an element's tag is not
sanctioned?
The obvious reason is that `click' is specified as a mouse event, but
you trigger its intrinsic event handler with a keyboard event.
Ah. The meat. About shiftKey (of type boolean, readonly) it says:
Used to indicate whether the 'shift' key was depressed during the
firing of the event.
It is not qualified with "if due to a mouse click". If the event
fires, shiftKey should be set with the shiftKey's status at the time
that event fired, regardless of why the event fired.
There is no DOM standard for keyboard events yet; there is a Working Draft
of W3C DOM Level 3 Events that includes the first time ever. So it is also
not surprising that Gecko-based and IE-based UAs work differently here.
Thanks: http://www.w3.org/TR/DOM-Level-3-Events/
Csaba
Csaba Gabor wrote: Thomas 'PointedEars' Lahn wrote: Csaba Gabor wrote: > I'd like to detect the shift key when a button is "clicked" in
> Firefox/Mozilla. If the button is clicked with the mouse, no problem.
> However, if the onclick event is keyboard originated, then my method is
> not working. Same thing for SELECT elements.
>
> The simple web page below shows the issue. Click with the mouse while
> holding down the shift key, and the Shift key's status registers.
> However, use Shift+Alt+o, or either (while the button has focus)
Shift+Alt+O could trigger another application as well. Shift+Alt+C
triggers a new KNotes note here, for example.
...
Your markup is not Valid. Scripts operating on or within not Valid
markup are unlikely to work properly. <URL:http://validator.w3.org/>
Not in my experience. If we define working properly as performing in
the way that the author believes it should.
But where, when, and for how long?
Appears to me most of the pages I visit, including biggies such as
google.com, amazon.com, chase.com, and wired.com do not have a DOCTYPE
at the top and yet these pages work as (I think) they should in the
browsers I use, FF and IE.
^^^^^^^^^^^^^^^^^^^^^^^^^^ Browsers tend to be quite forgiving about sloppy markup,
^^^^^^^^^^
You see?
not that that justifies it.
Exactly.
[...] > <button type=button accessKey=a
> onactivate="aclick(this,event)">on<u>A</u>ctivate</button>
This is an element not defined before HTML 4.0, so it is even more
imperative that you declare the document type. However, no HTML
element has an `onactivate' attribute.
This is another thing that I forgot to mention. Turns out that IE 6
has an onactivate and it fires when button gets focus - I didn't look
into it. And detail there is not defined. This differs markedly from
what I read the intention of onactivate to be on the page I referenced.
What IE does or does not define is irrelevant regarding interoperability.
> }
> function aclick(ctl, evt) {
> /* evidently not working - see
>
>
http://www.w3.org/TR/1999/WD-DOM-Lev...Events-UIEvent ^^
Working Drafts MUST NOT be used as reference material. Use this instead:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^ <URL:http://www.w3.org/TR/DOM-Level-2/events.html#Events-UIEvent>
Thanks
However, I fail to see the relevance to your problem:
| The `detail' attribute inherited from UIEvent indicates the number of
| times a mouse button has been pressed and released over the same screen
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| location during a user action. The attribute value is 1 when the user
Yes, but detail in that working draft for onactivate said: [...]
Whatever it says is not relevant /because/ it is only a _Working Draft_.
I put in an event listener for DOMActivate and it fired when the button
was clicked, but event.detail was undefined for it.
The UIEvent::view property, and the UIEvent::initUIEvent() method are
not supported, too. It would appear that the Gecko DOM does not fully
implement the User Interface event module and the UIEvent interface of
W3C DOM Level 2 Events. That would be a bug either way, since its
document.implementation.hasFeature("UIEvents", "2.0") yields `true'.
Furthermore, the `onclick' code is is not added as event listener to the
target element using one of the W3C DOM Level 2 Events methods, so it is
not surprising that the behavior is different that you expect. However,
even if you do use addEventListener() it does not work as you expect.
I don't understand this - I must be missing your meaning. Are you
saying that putting onclick="..." in an element's tag is not
sanctioned?
It is sanctioned; `onclick' is an intrinsic event handler attribute in
(X)HTML. However, you are expecting a keyboard event, when it triggers
an event handler for a mouse event (click) that is attached to that
attribute, to work like a mouse event. Shift key-press detection works
with an intrinsic keyboard event handler, like `onkeypress', in Firefox
1.5.0.1/Linux, where it would appear that Gecko 1.8 implements (at least
partially) the Keyboard Event module and the KeyboardEvent interface of
the current W3C DOM Level 3 Events Working Group Note (see below).
The obvious reason is that `click' is specified as a mouse event, but
you trigger its intrinsic event handler with a keyboard event.
Ah. The meat. About shiftKey (of type boolean, readonly) it says:
Used to indicate whether the 'shift' key was depressed during the
firing of the event.
It is not qualified with "if due to a mouse click". [...]
| // Introduced in DOM Level 2:
| interface MouseEvent : UIEvent {
| [...]
| readonly attribute boolean shiftKey;
If the event fires, shiftKey should be set with the shiftKey's status
at the time that event fired, regardless of why the event fired.
No. It is a mouse event, but you triggered its intrinsic event handler
with a keyboard event. Neither are keyboard events specified yet, nor is
specified how event listeners for mouse events should work if triggered
by a keyboard event.
And I have showed that your expectations about the Shift key are not
practical in web browsers, as the Shift key in combination with the Alt
key and/or other keys usually triggers other features or applications in
graphical environments. So it is at least unwise to rely on that key
combination for a Web document except of one in a controlled environment. There is no DOM standard for keyboard events yet; there is a Working
Draft of W3C DOM Level 3 Events that includes the first time ever.
So it is also not surprising that Gecko-based and IE-based UAs work
differently here.
Thanks: http://www.w3.org/TR/DOM-Level-3-Events/
Yes, it is still a Working Group Note, not a Recommendation:
| This document contains the Document Object Model Level 3 Events
| specification and is a W3C Working Group Note. It is based on the
| feedback during the Last Call period. The W3C DOM Working Group
| participants do not expect to provide interoperable implementations
| of this module.
| [...]
| Publication as a Working Group Note does not imply endorsement by the
| W3C Membership. This is a draft document and may be updated, replaced
| or obsoleted by other documents at any time.
PointedEars
Thomas 'PointedEars' Lahn wrote: Csaba Gabor wrote:
Thomas 'PointedEars' Lahn wrote: Csaba Gabor wrote:
I'd like to detect the shift key when a button is "clicked" in
Firefox/Mozilla. If the button is clicked with the mouse, no problem.
However, if the onclick event is keyboard originated, then my method is
not working. Same thing for SELECT elements.
.... <button type=button accessKey=a
onactivate="aclick(this,event)">on<u>A</u>ctivate</button>
This is an element not defined before HTML 4.0, so it is even more
imperative that you declare the document type. However, no HTML
element has an `onactivate' attribute. This is another thing that I forgot to mention. Turns out that IE 6
has an onactivate and it fires when button gets focus - I didn't look
into it. And detail there is not defined. This differs markedly from
what I read the intention of onactivate to be on the page I referenced.
What IE does or does not define is irrelevant regarding interoperability.
On the contrary, IE's definitions are highly relevant, especially where
interoperability is concerned. Furthermore, when there is not a clear
standard defined, Mozilla looks to IE and very often will implement the
same thing exactly because IE has already defined it.
}
function aclick(ctl, evt) {
/* evidently not working - see
http://www.w3.org/TR/1999/WD-DOM-Lev...Events-UIEvent ^^
Working Drafts MUST NOT be used as reference material. Use this instead: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^ <URL:http://www.w3.org/TR/DOM-Level-2/events.html#Events-UIEvent>
Thanks
However, I fail to see the relevance to your problem:
| The `detail' attribute inherited from UIEvent indicates the number of
| times a mouse button has been pressed and released over the same screen
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| location during a user action. The attribute value is 1 when the user
Yes, but detail in that working draft for onactivate said: [...]
Whatever it says is not relevant /because/ it is only a _Working Draft_.
There's that word again. Relevancy is always in relationship to
something else. You said Working Drafts MUST NOT be used as reference
material. Well and good, I didn't look carefully enough.
Then you continued on saying you failed to see the relevance to my problem
thus referencing it yourself, by implication. So I explained how it
WOULD HAVE BEEN been relevant, rather than making any claim about it
applying now. So what it says may not be relevant to the issue,
but it is very relevant to my thinking about the problem.
Which IS relevant.
....
The obvious reason is that `click' is specified as a mouse event, but
you trigger its intrinsic event handler with a keyboard event.
Ah. The meat. About shiftKey (of type boolean, readonly) it says:
Used to indicate whether the 'shift' key was depressed during the
firing of the event.
It is not qualified with "if due to a mouse click". [...]
| // Introduced in DOM Level 2:
| interface MouseEvent : UIEvent {
| [...]
| readonly attribute boolean shiftKey;
If the event fires, shiftKey should be set with the shiftKey's status
at the time that event fired, regardless of why the event fired.
No.
Evidently a gratuitous no.
It is a mouse event, but you triggered its intrinsic event handler
with a keyboard event. Neither are keyboard events specified yet, nor is
specified how event listeners for mouse events should work if triggered
by a keyboard event.
On the contrary, I pointed it out in my previous post.
I have not read anywhere in the docs that say that the mouse events may
only fire when the mouse is being used. That would be untrue, anyway,
since a click fires when the space bar is depressed when a button has
focus. Furthermore, the click event states certain circumstances under
which it will happen, and does not say anything about when it will not
happen.
All this does not remove the burden of obligation, according to the
spec, of providing a shiftKey status, regardless of the reason for
which the event fired.
http://www.w3.org/TR/DOM-Level-2-Eve...gs-mouseevents
And I have showed that your expectations about the Shift key are not
practical in web browsers,
Hogwash. You have shown very little about my expectations indeed.
Firing off a gratuitous "No" and a few irrelevant it's not relevants
does not mean that my expectations are not reasonable or practical.
That's the problem with saying "No, you can't do it that way" -
it's not very constructive because there may be other ways.
In fact, it is possible to determine the shift key state by using
a combination of onkeydown, onkeyup, onclick, ... to keep track of
its state for those situations when it is not supplied in the event
object, which is far messier than it should be.
as the Shift key in combination with the Alt
key and/or other keys usually triggers other features or applications in
graphical environments.
Well, I would only be interested in the shift key state when
my event handler fires.
So it is at least unwise to rely on that key
combination for a Web document except of one in a controlled environment.
Huh? I'm not relying on a specific key combination. I just want
to know about the shift key.
There is no DOM standard for keyboard events yet; there is a Working
Draft of W3C DOM Level 3 Events that includes the first time ever.
So it is also not surprising that Gecko-based and IE-based UAs work
differently here.
Thanks: http://www.w3.org/TR/DOM-Level-3-Events/
Yes, it is still a Working Group Note, not a Recommendation:
| This document contains the Document Object Model Level 3 Events
| specification and is a W3C Working Group Note. It is based on the
| feedback during the Last Call period. The W3C DOM Working Group
| participants do not expect to provide interoperable implementations
| of this module.
| [...]
| Publication as a Working Group Note does not imply endorsement by the
| W3C Membership. This is a draft document and may be updated, replaced
| or obsoleted by other documents at any time.
Csaba Gabor wrote: Thomas 'PointedEars' Lahn wrote: Csaba Gabor wrote: Thomas 'PointedEars' Lahn wrote:
Csaba Gabor wrote:
> <button type=button accessKey=a
> onactivate="aclick(this,event)">on<u>A</u>ctivate</button>
This is an element not defined before HTML 4.0, so it is even more
imperative that you declare the document type. However, no HTML
element has an `onactivate' attribute.
This is another thing that I forgot to mention. Turns out that IE 6
has an onactivate and it fires when button gets focus - I didn't look
into it. And detail there is not defined. This differs markedly from
what I read the intention of onactivate to be on the page I referenced. What IE does or does not define is irrelevant regarding interoperability.
On the contrary, IE's definitions are highly relevant, especially where
interoperability is concerned.
No, it is not. The above markup is not Valid.
Furthermore, when there is not a clear standard defined, Mozilla looks to
IE and very often will implement the same thing exactly because IE has
already defined it.
There are not only Geckos and IEs.
Your calendar is off by exactly one month, BTW.
PointedEars
Csaba Gabor said the following on 4/23/2006 12:43 PM: Thomas 'PointedEars' Lahn wrote:
<snip>
And I have showed that your expectations about the Shift key are not
practical in web browsers,
Hogwash. You have shown very little about my expectations indeed.
Firing off a gratuitous "No" and a few irrelevant it's not relevants
does not mean that my expectations are not reasonable or practical.
Welcome to Thomas' world of thinking.
That's the problem with saying "No, you can't do it that way" -
it's not very constructive because there may be other ways.
In fact, it is possible to determine the shift key state by using
a combination of onkeydown, onkeyup, onclick, ... to keep track of
its state for those situations when it is not supplied in the event
object, which is far messier than it should be.
I am not sure I agree with that. But, I have not read this entire
thread. Have you come up with a way to know its "state" when the page is
loaded? Whether the CapsLock key is locked or not will affect the Shift
Key State.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb wrote: Csaba Gabor said the following on 4/23/2006 about Lahn no mongering: That's the problem with saying "No, you can't do it that way" -
it's not very constructive because there may be other ways.
In fact, it is possible to determine the shift key state by using
a combination of onkeydown, onkeyup, onclick, ... to keep track of
its state for those situations when it is not supplied in the event
object, which is far messier than it should be.
I am not sure I agree with that. But, I have not read this entire
thread. Have you come up with a way to know its "state" when the page is
loaded?
No I have not. But for my purposes I am interested in knowing the
state of the shift key upon a (button) click event firing, and for that
it is sufficient: a click is either generated by an actual mouse click
(in which case I can know the shift status from the event object) or
some key on the keyboard must be pressed in which case I get keydown
and keypress events that I must process to know the shift key state.
There are other scenarios (with pulling down select elements, if I
remember correctly) where this approach might not be sufficient because
some events get 'eaten'.
Whether the CapsLock key is locked or not will affect the Shift Key State.
Could you give an example here? As far as I know, it's not the case.
CapsLock affects how keystrokes get translated to characters, but it
doesn't affect the Shift Key State. Thus, if you have CapsLock on and
press a q, the character generated is Q, but event.shiftKey will be
false. Conversely, if you then press Shift+q, you'll get a q, but
event.shiftKey will be true. You can check it out at:
https://bugzilla.mozilla.org/attachment.cgi?id=219883
(part of https://bugzilla.mozilla.org/show_bug.cgi?id=335538)
Csaba
The rest of this is just nother PointedEars INC post with factual
error.
I wonder if he thinks it's still April.
Thomas 'PointedEars' Lahn wrote: Csaba Gabor wrote:
Thomas 'PointedEars' Lahn wrote: Csaba Gabor wrote:
Thomas 'PointedEars' Lahn wrote:
> Csaba Gabor wrote:
>> <button type=button accessKey=a
>> onactivate="aclick(this,event)">on<u>A</u>ctivate</button>
> This is an element not defined before HTML 4.0, so it is even more
> imperative that you declare the document type. However, no HTML
> element has an `onactivate' attribute.
This is another thing that I forgot to mention. Turns out that IE 6
has an onactivate and it fires when button gets focus - I didn't look
into it. And detail there is not defined. This differs markedly from
what I read the intention of onactivate to be on the page I referenced.
What IE does or does not define is irrelevant regarding interoperability.
On the contrary, IE's definitions are highly relevant, especially where
interoperability is concerned.
No, it is not. The above markup is not Valid.
Furthermore, when there is not a clear standard defined, Mozilla looks to
IE and very often will implement the same thing exactly because IE has
already defined it.
There are not only Geckos and IEs.
Your calendar is off by exactly one month, BTW.
PointedEars This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Antioch |
last post by:
Ok, so Im a newb python programmer and I'm trying to create a simple python web-application. The program is simply going to read in pairs of words, parse them into a dictionary file, then randomly...
|
by: Paul Cooper |
last post by:
Dear All,
I am working on a piece of Javascript code that needs to detect a
mouse-click, shift-click and control-click. The code is not my own -
it is a part of a much larger suite of routines....
|
by: Ghulam |
last post by:
I am using an Access 2k ADP (Converted into ADE) front end and SQL 2K
on the backend. Although I taught pretty much myself into these
concept with the help of some publications and users group...
|
by: maniac |
last post by:
Hey guys, I'm new here, just a simple question.
I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's...
|
by: User10 |
last post by:
Can some one provide an algorithm for motion detection between two jpeg
frames? Or can you provide a more appropriate group to post this on?
Thanks!
|
by: Vijay Kumar R. Zanvar |
last post by:
I do not know much about shift sequence(7.1.1#5).
Can somebody enlighten me, giving some examples?
Regards,
Vijay Kumar R. Zanvar
--
Calvin: Hi Mom! I'm making my own newspaper to report...
|
by: LinuxGuy |
last post by:
Hi,
I want to add bits to present number. Shift operator pushes bits and
add '0' at the end.
I want to shift bits and want to add 1 at end
Ex,
1)
|
by: saumya.agarwal |
last post by:
Hi,
I am using libxml2 for xml parsing. When the client application sends
data to libxml2 in UTF-8 format, it works fine.
But, I have a scenarion in which the client application sends data to...
|
by: lokeshrajoria |
last post by:
hello everyone,
i have problem with left shift...can you solve this....
i want to write a simple function which will give output is 32 bit frame:
if input type == 0 -...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
