«

Hello,

I'd like to mimic the way how default windows application button
behaves. Simple click is, of course, trivial. I am looking for this
specific behaviour:

1) If user presses the mouse button on the screen button, it sinks,
but does not engage;
2) Still holding the mouse button, if user moves mouse off the button,
it pops back without engaging. If user moves the still-pressed mouse
around the screen, no events will fire (ie, toolbar buttons do not
react the same way when they are simply mouseovered).
3) Now, if user (still holding the mouse button) moves the mouse back
over the button, it sinks again. So, it remembers the fact it was
clicked. Actually, this single button is the only screen element that
reacts to mouse movements. There are two areas on the screen -- the
button and the rest of the screen, and the button state (sunk/normal)
changes depending on where the mouse cusros currently is located.
4) If the user would release mouse button while in step 2 (in this
numbered list), the button would not fire. However, if user releases
mouse button while in step 3, the button engages.

Now, I understand that one web page srcipt can not lock down the
controls out of this browser window. But, I am looking for help how to
mimic this behaviour at least in the boundaries of active window.

Thanks,

Passiday

Le 12/26/08 5:32 PM, Passiday a écrit :
> Hello,
>
> I'd like to mimic the way how default windows application button
> behaves. Simple click is, of course, trivial. I am looking for this
> specific behaviour:
>
> 1) If user presses the mouse button on the screen button, it sinks,
> but does not engage;

I'have no "screen" button (never!)
or do you call "buttons" the picts of my folders on my desktop ?

> 2) Still holding the mouse button, if user moves mouse off the button,
> it pops back without engaging. If user moves the still-pressed mouse
> around the screen, no events will fire (ie, toolbar buttons do not
> react the same way when they are simply mouseovered).
> 3) Now, if user (still holding the mouse button) moves the mouse back
> over the button, it sinks again. So, it remembers the fact it was
> clicked. Actually, this single button is the only screen element that
> reacts to mouse movements. There are two areas on the screen -- the
> button and the rest of the screen, and the button state (sunk/normal)
> changes depending on where the mouse cusros currently is located.
> 4) If the user would release mouse button while in step 2 (in this
> numbered list), the button would not fire. However, if user releases
> mouse button while in step 3, the button engages.

it is quite (or very similar) what does the tag 'button' in my browsers
(in html file loaded in their window) with no JS.

What is the question ?

--
sm

> I'have no "screen" button (never!)
> or do you call "buttons" the picts of my folders on my desktop ?

Well, perhaps my terminology is bad -- I'm talking about just default
kind of button what you see in windows applications. Let's say, basic
"Ok" button on alert() message box would do as a good example.

> it is quite (or very similar) what does the tag 'button' in my browsers
> (in html file loaded in their window) with no JS.
>
> What is the question ?

Indeed it is, but I need some finer control - I need to know the time
when the button sinks, start running some JS code while it is in sunk
state, and stop running when it pops back. I need to change the button
image between three states (normal/mouseover/down). The HTML <button>
is nice, but does not allow this level of fine control.

Passiday

Passiday wrote:
> I'd like to mimic the way how default windows application button
> behaves. Simple click is, of course, trivial. I am looking for this
> specific behaviour:

Find some first thoughts about that below.

> 1) If user presses the mouse button on the screen button, it sinks,
> but does not engage;

If necessary, handle the `mousedown' event of the "screen button".

> 2) Still holding the mouse button, if user moves mouse off the button,
> it pops back without engaging. If user moves the still-pressed mouse
> around the screen, no events will fire (ie, toolbar buttons do not
> react the same way when they are simply mouseovered).

If necessary:

Handle the `mousedown' event of the "screen button". Store a reference to
the button object in a globally available property of a native object.
Capture the `mousemove' event (AFAIK event capturing is not available in all
DOMs) with regard to the previous `mousedown' event on the button; on the
default view object or the `html' (root) element object if possible (and
necessary), on the `body' element object otherwise. If the target object of
the event is not the button object (i.e., the target object reference does
not equal the previously stored object reference), prevent the default
action of the event and its further propagation.

> 3) Now, if user (still holding the mouse button) moves the mouse back
> over the button, it sinks again. So, it remembers the fact it was
> clicked. Actually, this single button is the only screen element that
> reacts to mouse movements. There are two areas on the screen -- the
> button and the rest of the screen, and the button state (sunk/normal)
> changes depending on where the mouse cusros currently is located.

See above.

> 4) If the user would release mouse button while in step 2 (in this
> numbered list), the button would not fire. However, if user releases
> mouse button while in step 3, the button engages.

If necessary:

Handle the `mouseup' event of the button, considering the previous `mousedown'.

However, it does not seem to be necessary to handle mouse events at all
if you use form buttons. Depends on the runtime environment and your
definition of "reacts to mouse movements", of course.

RTFM:

<http://www.w3.org/TR/html401/interact/forms.html>
<http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/>
<https://developer.mozilla.org/en/Gecko_DOM_Reference>
<http://msdn.microsoft.com/en-us/library/ms533051(VS.85).aspx>
<http://developer.apple.com/documentation/appleapplications/Conceptual/SafariJSProgTopics/WebKitJavaScript.html>
<http://www.opera.com/docs/specs/>
<http://api.kde.org/3.5-api/kdelibs-apidocs/khtml/html/namespaceDOM.html>


PointedEars

Thanks, Thomas, your replies helped me to get started.

Heres' link to my testcase, and there are also the questions that are
puzzling me right now. I'd be grateful, if someone could shed his
wisdom to point me to the right direction, how to solve those
questions:

http://testarea.s3.lv/JSButton/JSTest.html

Thanks,

Passiday.

Passiday wrote:
> Thanks, Thomas, your replies helped me to get started.

You are welcome.

> Heres' link to my testcase, and there are also the questions that are
> puzzling me right now. I'd be grateful, if someone could shed his
> wisdom to point me to the right direction, how to solve those
> questions:
>
> http://testarea.s3.lv/JSButton/JSTest.html

However, your questions belong in your posting (so they can be read without
Web access and without your readers copy-pasting them and inserting quote
characters manually[1]), and your test case should be Valid to begin with.

<http://jibbering.com/faq/#posting>
<http://validator.w3.org/check?uri=http://testarea.s3.lv/JSButton/JSTest.html&ss=1;verbose=1>


PointedEars
___________
[1] There are user agents, among them Thunderbird (with Ctrl-Shift-V), that
allow to do that more easily, but posting *your* questions is *your* job
nevertheless.

Hello Thomas,

> However, your questions belong in your posting (so they can be read without
> Web access and without your readers copy-pasting them and inserting quote
> characters manually[1]), and your test case should be Valid to begin with.

Thanks for the fair reprimand, I humbly submit and correct myself.

Here's link to valid testcase:
http://testarea.s3.lv/JSButton/JSTest.html

There I've set up a simple solution to track what events occour when
user moves/clicks mouse.

The questions that are puzzling me, are:

[Testing on MSIE 7.0.5730.11]
1. When performing mouse click on the button, it generates four event
sequence: a) mousedown, b) mouseup, c) click, and d) mousemove. Why
does it generate the d) mousemove event?

2. Default behaviour of mousemove event is cancelled, to avoid the
default drag action. Now the event sequence, when user clicks on the
button and drags the mouse cursor out of the button area, and releases
the button is the following: a) mousedown, b) series of mousemove, c)
mouseout, d) mousemove, e) mouseover, f) series of mousemove, and
finally g) mouseup. I am puzzled about the d) mousemove + e)
mouseover, as if happens exactly after the mouseout, when the cursor
has left the button area. It's confusing, because it makes the code
thinkg that the cursor has returned to the button area. Another thing
that surprised me, was that mousemove events keep firing even when the
cursor is being moved around outside the button area.

[Testing on FF 3.0.3]
3. Happily, there's no extra mousemove event after mouse click.
However, the [click]&[drag outside] doesn't work as I hoped, and I
feel there's something connected with the way how FF handles the event
capturing/bubbling.

I need some advice, how to fix this, with some sort of good
streamlined universal code. I need no backwards compatibility down to
Netscape 4, but having a code that would run on MSIE, FF and Opera
that are at their most recent updates, is a must.

Thanks for the advice!

Regards,

Passiday

Passiday wrote:
> [...]
> Here's link to valid testcase: http://testarea.s3.lv/JSButton/JSTest.html
>
> There I've set up a simple solution to track what events occour when user
> moves/clicks mouse.
>
> The questions that are puzzling me, are:
>
> [Testing on MSIE 7.0.5730.11] 1. When performing mouse click on the
> button, it generates four event sequence: a) mousedown, b) mouseup, c)
> click, and d) mousemove. Why does it generate the d) mousemove event?

Probably because you are changing the `src' property of the object being
clicked on mousedown and onmouseup. That causes a change of cursor shape
here[1] (because the image is loading), and the trigger coordinates of the
background hourglass cursor (`progress') might be slightly different than
those of the default cursor (`pointer').

> 2. Default behaviour of mousemove event is cancelled, to avoid the
> default drag action. Now the event sequence, when user clicks on the
> button and drags the mouse cursor out of the button area, and releases
> the button is the following: a) mousedown, b) series of mousemove, c)
> mouseout, d) mousemove, e) mouseover, f) series of mousemove, and finally
> g) mouseup. I am puzzled about the d) mousemove + e) mouseover, as if
> happens exactly after the mouseout, when the cursor has left the button
> area.

That appears to be a known peculiarity of the MSHTML DOM (it was pointed
out to me with regard to hoverMe). Check the window.event.fromEvent and
window.event.toEvent properties to find out.

<http://msdn.microsoft.com/en-us/library/ms535863(VS.85).aspx>

> It's confusing, because it makes the code thinkg that the cursor has
> returned to the button area.

If your code is starting to think, you better call Stockholm

> Another thing that surprised me, was that mousemove events keep firing
> even when the cursor is being moved around outside the button area.

See above.

> [Testing on FF 3.0.3] 3. Happily, there's no extra mousemove event after
> mouse click.

Yes, that's the Gecko DOM.

> However, the [click]&[drag outside] doesn't work as I hoped,
> and I feel there's something connected with the way how FF handles the
> event capturing/bubbling.

I think you need to prevent the default action of the corresponding event.
If you use Firebug's Log Events feature on the `img' element and its parent,
you will see that (at least) the following events occur when dragging the image:

mouseover, mousemove (in that order); draggesture, dragenter, dragover,
dragexit; mouseover, mousemove, mouseout (in that order).

> I need some advice, how to fix this, with some sort of good streamlined
> universal code. I need no backwards compatibility down to Netscape 4, but
> having a code that would run on MSIE, FF and Opera that are at their most
> recent updates, is a must.

Good luck!


PointedEars

[1] "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
from IEs4Linux 2.99.0.1 beta on wine-1.0.1-174-gc4039bd
on Debian GNU/Linux stable/lenny/unstable
on Linux 2.6.27.8-20081225.024056+0100 PREEMPT i686