I'm attempting to create a Shift+Click action in a force-directed layout with the following code applied to node shapes:
.on("click",function(){
if(d3.event.shiftKey){
//do something
}
});
The code tends to function correctly, but will occasionally crash the browser (both Chrome and Safari crash). It seems that the crash occurs after the following sequence:
Click and drag cursor anywhere outside of node (so that the text cursor is revealed)
Hold down shift while holding down cursor outside of node (still shows text cursor)
Click node
update: It appears that this crash is not exclusive to my code. I can crash my browsers on any force-directed layout by doing the following: while keeping shift held down the whole time, click empty space, click node.
Perhaps some built-in shift functionality is getting in the way of D3's? The alt key works fine with my above code, for instance.
Thanks!
We have run into a similar situation and it appears to be a Chrome bug: https://bugs.webkit.org/show_bug.cgi?id=114745
Its possible that the default behavior in webkit where shift-click selects all text up to current cursor position is the mechanism for the crash.
We have not spent the time to track the specifics yet in d3 but as the bug report suggests it may be possible to get around it for now with a "blur" call on any formerly focused elements (see the bug report).
Related
I originally had code that set the focus to the first widget in a dialog, in the onInit method. But there were problems with it: if I pressed TAB, indeed focus moved to next control (wxTextCtrl), which got the blue 'focus' color, but the 'focus' color/highlight was not removed from previous focus widget. So now it looked like both first and second control had focus at the same time...
When cycling manually (by pressing TAB) full circle (till last control and then wrap around to the first), suddenly all worked well. That is, when moving focus from first control to next one, the first visually lost focus (blue color was removed) as it should. From now on, only one item had the focus color/highlight.
So instead of setting focus on the first control, I tried a different approach: I set the focus to the last control in the dialog, which is always the OK button. Next, I want to emulate programmatically that a TAB is pressed and received by the dialog. So I wrote this (inside Dialog::onInit):
m_buttonOK->SetFocus();
wxKeyEvent key;
key.SetEventObject(this);
key.SetEventType(wxEVT_CHAR);
key.m_keyCode=WXK_TAB;
ProcessWindowEvent(key);
Now the focus indeed moves away from the OK button, but it does not wrap around to the first control.
Only when I manually press TAB after the dialog opened, the first item gets focus.
Question: why does this wrapping around to set focus on first widget not work with the code shown above?
First of all, your initial problem is almost certainly related to not calling event.Skip() in one of your event handlers, see the note in wxFocusEvent documentation.
Second, you can't send wx events to the native windows, they don't know anything about it. In this particular case you can use wxWindow::Navigate() to do what you want, but generally speaking what you're doing simple can't, and won't, work reliably.
I am aware of this question, but that's different to what I am looking for, as the accepted answer hides the cursor.
I'm writing software that remaps the left mouse button to the left CTRL key.
I have it working, with one problem: when I hold down the CTRL key and drag the mouse pointer this feature often activates, which messes up my drag operation (it feels like trying to change direction running on ice).
So the Apple engineers must have disabled this feature while the left mouse button is down and re-enabled it when the button is released.
Something like this -- however when I inject my simulated mouse events, the feature does not disable.
What I'm getting at is: there must be some programmatic way of doing it, even if it is an internal Apple function. Unless Apple are using the solution in the linked answer, i.e. NSCursor.hide() and then manually drawing the cursor icon at the cursor location.
How can I accomplish this cleanly?
EDIT: A CGEventTap for NSEventTypeGesture or NSEventTypeMagnify fails to catch anything.
I have implemented a slickgrid and activated keyboard navigation.
When the users is scrolling down using the down-arrow key and reaches the last of the currently visible rows, the grid loads a whole new section of rows and places the selection at the top.
My user tests have all included a complaint about this behaviour as they all find the jump jarring.
I would like to implement behaviour, so the grid scrolls just one line at a time, when I press the down arrow while the last visible row is selected.
I was wondering if there might be some setting, I have overlooked, or if anyone has some suggestions for how to approach the task of adding this behaviour.
(the "problem" is the same, when you scroll upwards - only reversed of course)
This is controlled by the doPaging argument in scrollRowIntoView(row, doPaging) (https://github.com/mleibman/SlickGrid/blob/master/slick.grid.js#L2662). There's no setting to control that behavior, but you could easily add one.
It was initially written this way to make keyboard navigation faster since continuously navigating down doesn't have to do as much work as it would have if we were updating the grid on every 'row down'.
Whenever I write mouse handling code, the onmousedown/onmouseup/onmousemove model always seemed to force me to produce unnecessarily complex code that would still end up causing all sorts of UI bugs.
The main problem which I see even in major pieces of software these days is the "ghost mouse" event where you drag to outside the window and then let go. Once you return back into the window, the application still thinks you have the mouse down even though the button is up. This is especially annoying when you're trying to highlight something that goes to the border of the screen.
Is there a RIGHT way to write mouse code or is the entire model just flawed?
Ordinarily one captures the mouse events on mouse down so the mouse move and mouse up go through your code regardless of the caret moving out of you application window.
More recently this is a problem when running a VM or remote session, its difficult for apps in these to track the mouse outside of the machine screen area represented by a window on a host.
I'm not sure what environment you're attempting to track mouse buttons in, but the best way to handle this is to have a mouse listener that tracks onmouseup 100% of the time after you've detected onmousedown.
That way, it doesn't matter what screen region the user releases the mouse button in. It will reset no matter where it happens.
I'm creating a ToolTip window and adding tools to it using the flags
TTF_IDISHWND | TTF_SUBCLASS. (c++, win32)
I have a manifest file such that my program uses the new WindowsXP themes
(comctrl32 version 6).
When I hover over a registered tool, the tip appears.
Good.
When I click the mouse, the tip disappears.
Ok.
However, moving away from the tool and back
again does not make the tip re-appear. I need to hover over a different tool
and then come back to my tool to get the tip to come back.
When I remove my manifest file (to use the older non-XP comctrl32), the
problem goes away.
After doing some experimentation, I discovered the following differences
between ToolTips in Comctl32 version 5 (old) and Comctl32 version 6 (new):
New TTF_TRANSPARENT ToolTips (when used In-Place) actually return
HTCLIENT from WM_NCITTEST if a mouse button is down, thus getting
WM_LBUTTONDOWN and stealing focus for a moment before vanishing. This causes
the application's border to flash.
Old TTF_TRANSPARENT ToolTips always return HTTRANSPARENT from WM_NCHITTEST,
and thus never get WM_LBUTTONDOWN themselves and never steal focus. (This seems to be just aesthetic, but may impact the next point...)
New ToolTips seem not to get WM_TIMER events after a mouse-click, and
only resume getting (a bunch of) timer events after being de-activated and
re-activated. Thus, they do not re-display their tip window after a mouse
click and release.
Old ToolTips get a WM_TIMER message as soon as the mouse is moved again
after click/release, so they are ready to re-display their tip.
Thus, as a comctl32 workaround, I had to:
subclass the TOOLTIPS_CLASS window and always return HTTRANSPARENT from
WM_NCHITTEST if the tool asked for transparency.
avoid using TTF_SUBCLASS and rather process the mouse messages myself so
I could de-activate/re-activate upon receiving WM_xBUTTONUP.
I assume that the change in internal behavior was to accommodate the new "clickable" features in ToolTips like hyperlinks, but the hover behavior appears to be thus broken.
Does anyone know of a better solution than my subclass workaround? Am I missing some other point?
You're not the only one who has hit compatablity issues with tooltips between these DLLS.
I too have had nothing but trouble with the new tooltips in the themable common controls. We have already been monkeying with mouse messages and active/deactivating the tips before adding the manifest and theming our application - so it sounds like what your doing isn't too crazy.
We're still living with problems with TTN_NEEDTEXT messages being send constantly as the mouse moves (not just when hovering), positioning problems with large tips (maybe not something new), and odd unicode messages being sent instead of the ANSI versions (which I plan to post as a question at some point).
I don't know, but this sounds like a really "hard" problem (in the sense that all real-world) problems are really hard. I bet the underlying problem is something to do with the setting of the focus. Windows that manually do that are evil and generally suffer from all manner of bugs.