I am trying to provide users 3 options when they zoom into a d3 chart with the mouse wheel with
d3.behavior.zoom():
zoom x and y: No modifiers
zoom x only: Hold Alt
zoom y only: Hold Shift
This works fine in firefox, but chrome is preventing my zoom from working when shift is held down. This same problem can be seen in in the d3 zoom example, if you hold down shift, the mouse wheel zoom no longer works:
http://bl.ocks.org/mbostock/3892919
I would try to use Ctrl instead of shift, but ctrl is already reserved for Browser Zoom Level.
Any idea if shift+mouse wheel is already reserved in chrome or if this something can be fixed in a future version of d3?
I had the same issue earlier today. When I investigated, I found that it was a "bug" in the d3 zoom behavior. You can find my pull request here: https://github.com/mbostock/d3/pull/1938.
If you look in the d3 repo at src/behavior/zoom.js:327, you'll see that the function is using d3.event.deltaY to get the scroll wheel delta, which is used to update the scale value. The problem is that, in Chrome, holding down the Shift key while scrolling scrolls the page horizontally, which sets deltaX instead of deltaY. Since d3 is only checking deltaY it gets a 0 value every time the Shift key is pressed.
Unfortunately I don't have a good work-around for you at the moment. In my case I may modify the d3 source file that we're using until/unless my fix is applied. Maybe someone else will have a better work-around.
Related
first off, I'm very new to using API's so please bear with me I'm on a steep learning curve !
I'm creating an application using Silverfrost Fortran FTN95.
I've been trying to initiate the opening of an initial Window within the program which uses the whole screen
useable area (the so-called WORKAREA in API parlance) but am having a problem.
Having used GET_WINDOW_LOCATION# API function within my Fortran code to obtain the dimensions and origin of the max possible area for
the window (without taskbar), I've then defined the 'origin' of the window to be at -n,-n where the border is n pixels thick and I've
increased the window dimensions by (2xn) in each direction so that the other 2 borders will be off-screen at top or under the taskbar at the bottom edge).
Anyway, I'm having difficulty obtaining exactly the same as produced via clicking the 'MAXimise button' on a window.
While the window produced itself seems to occupy the whole area available, when it appears the CAption appears right on the upper edge of the
CAption ba(i.e. not centre justified vertically).
Also, the MINimise, MAXimise and CLOSE buttons in top rh corner of window do not fill the whole depth of the CAption bar (they're about half the depth and indeed appear to be cut-off).
If I subsequently click the window 'MAXimise button' after initial window creation then the CAption and buttons re-align themselves correctly.
This is all illustrated in this image here:-
http://s1164.photobucket.com/user/john_pbucket/media/SilverfrostForumsImageFiles/MAXWIN-Summary_zpscajfx3vx.png.html
Note - I first created the full window with borders within the available screen area (this is the first example shown) where the window Border (8pix wide) is visible
The subsequent attempt to create the window as per the MAXimise button places the window at origin (-8,-8) and I increase the window dimensions by 16 (2xborder width) in each direction in order to get the borders off-screen, but thy're still there.
So, What series of Windows API commands should I be using exactly to get the window to open in a correctly maximised state, and are there any 'subtleties' of alignment and/or spacings I should be aware of which may be causing this problem?
I guess the question boils down to 'what sequence of API commands does the window MAXIMISE button execute ?' but I can't find an answer anywhere.
Maybe there are also some subtleties I need to know about with regard to any windows dimensions parameters which could be creating the anomaly ?
Any help/guidance would be appreciated. Thanks
I need obtain a MOUSE_DX and MOUSE_DY values where
MOUSE_DX is a difference between MOUSE_X and MOUSE_PREV_X
someone give stupid answer to my that i can hide cursor substract
succesive MOUSE_X between mouse move events, and when cursor
goes away from the centre of the sceen call ShowCursorPost to the
cantre of the screen - but this is a real hell : it is stupid perself also
calling ShowCursorPost generate fake mouse move events so
then I would need to filter out this fake movements then (It is hell)
Is there some more reasonable way of obtaining the MOUSE_DX
MOUSE_DY I need?
//EDIT (more explaining for questions )
I want to use mouse as a steering device - something like mowing yaw/pitch/roll of the camera
For this purpose I need to gest something like MOUSE_DELTA_X MOUSE_DELTA_Y
where such numbers are indeed the MOUSE_X-MOUSE_PREV_X where MOUSE_X/Y are
coordinates of the mouse cursor given to me by WM_MOUSEMOVE
allright - this works to some extent but not much:
I need the DX DY walues related to mouse movements but do not need
a mouse cursor at all, when mouse cursor hits the screen edge i will
not gest full DX but some cutted and then all zeros
To prevent this i call (as somebody advice me) SetCursorPos when
the cursor nears to the edge of the desktop (the window really becouse
I do not want him to exit my window) then I call SetCursorPos
to the centre of the client area (I also make cursor invisible, and
also clip it to the window size but it also brings a lot of
trouble, need to unclip the areo on alt+tab etc it is all tiresome
and it is all a complex workaround for such simple thing like obtaining
DX DY) I just do not need this f*cking invisible cursor moving on screen
at all here - but I need mouse DX DY only
but let assume that this machinery with invisible cursor is tiresomely
coded and debugged
the other trouble is that when I call SetCursorPos It also generates
fake mouse movement backward and it generates fake DX and DY then
(it is hard to filter - at least i do not know how to do it all
in a robust way)
(can this fake mouse move been easily filtered out?)
I did it all this invisible cursor clipping SetCursorPos and filtering
out the false DX DY but it is very ugly thing very error prone and
confusing - all this for simple obtaining (cursor independant/mouse
related)DX DY for every move - this is hell It made me a long hours to
debug this stuff so I am angry - this is coding hell - this is terribly
wrong so I am angry and need a good way of doing it
The WM_MOUSEMOVE event tells you the current position of the cursor. Well, it's actually the position of the cursor when the event was placed in the message queue, not quite the same thing. But the system does not keep track of the position of the cursor associated with the previous WM_MOUSEMOVE message. From this you can conclude that you will need to keep track of that.
So, do the following:
Declare variables to hold the previous cursor position.
Initialize those variables to the current cursor position.
Whenever you process WM_MOUSEMOVE you can compare the current position with the previous.
Once you have done that, update the previous cursor position to be equal to the current position, ready for the next WM_MOUSEMOVE message.
What you could try:
Use the ClipCursor function to confine the cursor inside your window, or a sub-rect.
When the mouse hit your "border", start a timer. Stop the timer when the mouse leaves the border.
On each timer tick, you could generate a fake DX or DY.
The idea is to have the behavior of many games: you move the mouse, hitting a border, and then all behave as if you were still moving the mouse.
I am making an application to control the mouse using an analog stick from a gamepad for Mac OS X (10.7.3).
Currently it is working pretty well, I can control the cursor in desktop and most games. But in Team Fortress 2, I cant control the aim, but can control the cursor in the menu. Mouse wheel and clicks works everywhere.
Another strange thing is that when I move the real mouse, the aim "jumps" the traveled distance from my "virtual mouse" before aiming normally, so it somewhat is receiving the events.
The game option "Raw mouse input" is disabled (I think it is not even supported in osx). And a similar application can controle the aim successfully.
I suspect the game is looking for "delta movement" or "relative movement" events or anything similar, but my code sets the position of the cursor using absolute positions. Not sute how to change this.
Here is the snippet of code used to send mouseMoved events:
EDIT: Crappy code removed!
.
EDIT:
Also, because I did this way, I need to check the screen bounds manually to prevent the cursor going Crazy. So in multi-screen setups, and when the user change the resolution, it gets worst. Would be so much better if I can just send the amount of movement and let the OS take care of constraining the cursor.
.
The question is:
I am doing the mouse move events the wrong way?
How can I fix this?
EDIT2:
So, that was just a stupid bug, sorry =P
I just forgot to call CGSetIntegerValueField(kCGEventMouseDeltaX, ...) (and Y) with the delta values... =P
Finally got this working, after just a few short hours of Googling and experimenting :) Looks like Rodrigo was trying to say that you have to call CGEventSetIntegerValueField on kCGMouseEventDeltaX and kCGMouseEventDeltaY on the mouse event after constructing it.
My code, using PyObjC:
from Quartz.CoreGraphics import (
CGEventCreate,
CGEventCreateMouseEvent,
CGEventGetLocation,
CGEventPost,
CGEventSetIntegerValueField,
kCGEventMouseMoved,
kCGHIDEventTap,
kCGMouseEventDeltaX,
kCGMouseEventDeltaY,
)
def mouse_delta(delta_x, delta_y):
"""
Send a MouseMoved event with the given deltaX and deltaY attributes,
but without changing the cursor location.
"""
# Might be a better way to get the current mouse location
x, y = CGEventGetLocation(CGEventCreate(None))
# The `mouseButton` parameter to CGEventCreateMouseEvent is ignored
# unless `mouseType` is kCGEventOtherMouse{Down,Dragged,Up},
# so let's just pass the value 0
event = CGEventCreateMouseEvent(None, kCGEventMouseMoved, (x, y), 0)
CGEventSetIntegerValueField(event, kCGMouseEventDeltaX, delta_x)
CGEventSetIntegerValueField(event, kCGMouseEventDeltaY, delta_y)
return CGEventPost(kCGHIDEventTap, event)
I'm looking to simulate a kiosk mode for Safari on Windows. OSX will not work with my input hardware and Chrome's GPU acceleration is too slow for the machine I'm using.
The only plausible solution [so far] is to run Safari and send an F11 (fullscreen) keystroke, but prevent the URL bar from expanding when the mouse reaches the top pixels of the screen.
I've looked and can't seem to find any good solution and would like to know if I can restrict the cursor movement from reaching the top pixel of the screen?
If anyone has any other solutions, that would be great!
You can use the ClipCursor function to do this.
Confines the cursor to a rectangular area on the screen. If a subsequent cursor position (set by the SetCursorPos function or the mouse) lies outside the rectangle, the system automatically adjusts the position to keep the cursor inside the rectangular area.
You can poll the cursor position and correct it using a timer, but this is not ideal. You could also cover the top bar by a transparent topmost window. This way, input will never reach the top bar.
EDIT: If Internet explorer is an option you have the possibility to use the COM object to embed what you need in a custom application. Other browsers might have similar APIs, but I'm not familiar with them.
We are developing an application that uses a plot to show data. We allow zooming in and out - no scrolling up and down is necessary.
Double click is used to zoom in, backspace to zoom out. + and - keys are zoom in and out
We have been unable to standardize on up and down arrows - does an up arrow typically mean zoom in or zoom out?
We are writing the code to do the zoom and it is a UI question - if there is a better site, please migrate.
Double-click to zoom and backspace to zoom out do not seem like an intuitive choice.
I'd say that +/- would make sense as zoom keys, like browsers do, but only if you combined them with a CTRL modifier.
Arrow keys are an absolute no-no for zoom. Arrow keys mean move caret, or scroll when there is no caret. Never use them for zoom.
Ctrl + + / - and Ctrl "Mouse Wheel" are the common zoom keys for web browsers.
Image viewers/editors and other specialized software might omit the Ctrl modifier if zooming is a common operation...
I'm not sure why you're allowing so many different methods for zooming in and out; consistency with other applications would suggest that if your app doesn't do scrolling, the arrows shouldn't do anything at all.
If you insist, I'd use up arrow for zooming in (making things larger) and down arrow for zooming out. Up would correspond with + and down would correspond with -, I think that would be the least confusing.
When you get around to wondering what the scroll wheel should do, check this old Joel On Software thread: http://discuss.joelonsoftware.com/default.asp?design.4.630539.38
To add onto to all these good answers... the Microsoft magnifier (the one that comes for free with the Intellipoint software, as opposed to the one that comes with the OS) uses another scheme: once the magnifier is visible, if you hold down the scroll wheel for a second, then the scroll wheel up/down begins to control the zoom in/out. Before this second timeout, the scroll wheel functions normally for the current window.