JavaFX 1.x had a blockinMouse property you could set to stop events propagating down to nodes below (for instance a right click to bring up a context menu when you'd just want it on the top node.)
I'm struggling to find an equivalent in JavaFX 2 though, I'm assuming it must be somewhere but the only things I've dug up online have been similar complaints, and I'd like to avoid the brute force style answer that's listed there.
Seems I was approaching this the wrong way - the solution was to simply call consume(); on the event in the top most node to stop the event propagating down to the lower nodes. The mouseTransparent property was similar but not what I was after, it just controls whether the node receives mouse events or just passes them on (similar to the old glasspane like approaches.)
In JavaFX 2 this is called: pointerTransparent.
Related
I am working on some inherited code and I ran across something I've not seen in LabVIEW before...see attached screenshot. Notice when I right-click on the property node and try to find the Terminal...Terminal is grayed out. When I find the Control, it takes me to a blank spot on the front panel that has absolutely no controls (I've ensured that the Control has Visible=True by programmatically setting and verifying that property). I've never seen a Control without a Terminal...what's up? Using LabVIEW 2012.
After quite a bit of digging, I found the answer:
It turns out that the Property Node is pointing (linked) to a control which is buried inside a cluster.
The lesson here is: if Find >> Terminal is grayed out, it's possible (likely) that the control to which the Property Node is linked is inside a cluster. I re-created the scenario with this mini-example:
Finally, I couldn't find the front panel control at the onset because it had its Visible attribute set to false inside the cluster (the cluster was visible, but not the element within the cluster) and it was physically placed far away from the other controls within the cluster, AND it was placed on a hidden Tab page.
Tab Order in Visual Studio does not work for me for some reason.
I am making a VB.NET plugin for a cad program called Rhinocreos 5.
I have everything set perfect, and I don't know what the cause of it is.
I am using .Show() instead of .ShowDialog(), because I need that thread open and I don't feel like doing any thread management (not paid enough lol)
Does anyone have any pointers for this? Has anyone else ran into a tab problem with Rhino5 and .NET?
EDIT**
Seems I have to use a MODELESS Form for a rhino plugin.... So I wont have any tab keys or arrow keys unless I do a hook. But since I need to make the plugin future proof (in case I am no longer working here), I won't be doing that either. But thanks for the answers, comments, and awesome downvotes.
Very difficult to guess what's going on from the information you have provided, but I'd check the following things in the following order:
The disobedient form is open and has focus.
The form has controls in it.
At least some of the controls are enabled, focusable have their TabStop set to true.
There is no low-level keyboard handling in action (PreviewKeyDown, hooks etc).
Finally I'd call ShowDialog() instead of Show(), passing main form as parameter (to make disobedient form a child of main form) and see if that makes a difference.
It was a modeless form inside of Rhino3D as a plugin.
Rhino3D uses all plugins in the main thread. So tab is not an option.
The workaround was to tag all controls with a tag work (I used "tabMe")
Then I store all the controls in a List myTabbyControls.
Each time I press tab, I would cycle through the list.
But thanks for the down votes. It's the running joke of SO.
In my current project I am working with a specific implementation of the jface ProjectionViewer attached to a TextEditor nested in a MultiPageEditor.
My task is now to implement a custom reaction to Ctrl-Z, and from what I get this is best done by attaching a specific implementation of IUndoHandler to the Viewer, all of that would be no problem.
But, pressing Ctrl-Z while having that TextEditor focused fails to cause any reaction that would be expected. While clicking "Undo Typing" in the context menu, which displays the associated key combination Ctrl-Z causes the TextViewerUndoManager.DocumentUndoListener's notification method is called, no line of code in the TextViewerUndoManager is touched when pressing Ctrl-Z.
As a possible source of this problem I assumed that maybe a handler might be defined for this key combination in an extension point, since I had previously experimented with this mechanism, but the plugin.xml does not define any key combinations nor undo handlers apart from one that is associated with a special context menu for a different widget.
It might be worth to note that Ctrl-C and Ctrl-V work as intended.
I need to find out what happens when Ctrl-Z is pressed and why nothing is relayed to the TextViewerUndoManager.
It would be very helpful if someone could describe the progress how eclipse handles these key combinations normally and decides which command is appropriate.
Thanks in advance
Cntrl+Z- undo is processed using OperationHistorySupport. Look at UndoActionHandler class.
Binding support is implemented using keydown event filter using WorkbenchKeyboard ( all keydown events first filtered using this class. this is how BindingService was implemented). This will figure out correspond command for the key binding.
DocumentUndoManager.UndoableTextChange is where undo operation is handled.
Sorry in advance for the vague conditions in which the problem below occurs. It is very intermittent, and I have not pinned down a consistent set of steps that reproduce it yet. (Which is why I'm asking for some general or common things that might cause it)
The application I'm working on consists of MonoDevelop.Components.Docking dock frames. There is a tabbed group of panels in one if the frames, and one of them has a GtkTreeView in it. Every now and then, the nodes of the Treeview will not expand when clicking on the + button. This does not go away until restarting the application.
However, since I have not been able to consistently reproduce it, I'm kind of at a loss of what to look for/mess with to fix it. So does anyone have any ideas on what might generally cause the nodes to not expand when clicked? Or any better steps I should try in order to reproduce it?
I have found this occurs when a disabled node is in the TreeView. In my case it was a project in the solution pad of MonoDevelop that was set to not build in the current configuration. When I removed the project, all other nodes in the TreeView started working again immediately.
You can use the arrow right/left keys to expand/collapse nodes.
It may be related to a Gtk bug:
https://bugzilla.gnome.org/show_bug.cgi?id=675835
which was fixed recently:
http://git.gnome.org/browse/gtk+/commit/gtk?h=gtk-2-24&id=b32a9eb691920f21ad3b9127c833aaba15727c4b
I have created a NSStatusItem and I have assigned two key equivalents within interface builder (Xcode 4.0). These are for the preference menu cmd-, and the quit option cmd-q. Both of these will work when the Menu is highlighted/open but will not work otherwise even if the application is the foremost. Any ideas on why this is happening or how I can change this?
The operating system passes key events that it doesn't handle to the front application, which compares them to any key equivalents in its main menu and current window. They are not compared to items in the status bar, and since the status bar is actually a different application, it won't matter that your application is in the foreground. When you have the menu open, it is the window in focus. This is why it works in those circumstances.
Since the status item is only active while the menu is open, you need to get the key equivalents using one of two other methods. The first, newer method is to use event taps. I have never used this, so I can't advise on how to set it up. The other, older option, is to use hot keys. This method may become unsupported in the future, but if you are interested I posted an example in this answer.
My guess: your NSMenu is not in the responder chain. If you can figure out how to get it in there, you can probably get this to work.