I would like to create a vim shortcut with the action activated by hovering the mouse over some piece of code (compiler errors to get its description, suggestions, functions to get its parameters etc).
Is there any mapped action to it? I was not able to find what I am looking for in :actionlist.
Related
I broke something in my image (no idea what) and now my right-click menus only say "Why you see this menu, debug" -- what can I do to fix this ?
I can't really tell what happened unless you do what that text tells you:
click on the menu entry
in the workspace that appears evaluate menu debug
post the contents of the debugger here
update
We need to find out what error is being signaled. Open the debugger again like you did, then select the first entry. Click on it with the right mouse button and select "Copy to clipboard" from the popup.
Post the stack trace in you clipboard here.
Alternative: Put the whole image somewhere I can download it and I'll take a peek.
update 2
The reason why Smalltalk at: #Behavior put: Behavior didn't change anything is that Behavior is a global reference equivalent to Smalltalk at: #Behavior. The effect is that you store the RTGraphBuilder class at the same location again :).
Try this:
Smalltalk at: #Behavior put: ClassDescription superclass
The superclass of ClassDescription is Behavior and that link is independent of the global lookup.
I’m currently writing an MFC dialog app which has a menu. The menu displays correctly and the menu entries work correctly via mouse, accelerators, and hotkeys (e.g., to quit: Ctrl+Q or Alt+F,Q).
Unfortunately, the Enter key doesn’t seem to work. That is, pressing Alt+F will open the File menu and pressing ↑ will highlight the Quit entry, but pressing Enter will not select it.
I know that using menus in dialog apps can be a bit tricky, but I’ve done this successfully before. However, that was a long time ago with a customized VS wizard, so I am trying to remember how to do this from scratch. I tried checking my old code, but could not find anything in reference to VK_RETURN. (No, there’s nothing special in PreTranslateMessage.)
These two questions are related, but they want the dialog to receive the key, I need the menu to get it.
Does anyone know what the problem is and how to fix it?
The default behavior for right-clicking on most recent Linux distros is to select a menu item in a right-click menu upon releasing the right mouse button. While this saves some mouse presses, it is driving some of my Windows-trained (and rather vocal) coworkers completely bonkers, and a lot of searching has told me that there is no option to change this behavior in the distros they are using (mostly RHEL 6).
To make my work environment a little less volatile I would like to try to program a fix or patch for their systems to make right clicking work like they are used to (the menu does not even appear until the right mouse button is released), but I don't know what kinds of tutorials I should be looking for (shell scripts? C? etc.) in order to do this.
If I could be pointed in the right direction that would be lovely! (or if someone by chance already knows of a fix, that would work too, though a lot of Googling has told me that there does not appear to be one currently)
Follow the directions here:
https://unix.stackexchange.com/questions/20550/how-to-disable-the-forward-back-buttons-on-my-mouse
But instead of disabling the forward and back buttons, disable the right click mouse button. You can easily dump the resulting command into a shell script which calls xmodmap. Then you can make icons that disable and enable the right mouse button, for the times where they will need it.
I've got a Visual Studio extension that I am working on. I have implemented some error tagging, which works just fine. However, some of the errors reference other locations in the code. I would like that the user can click on these locations and be taken there. The definition for ErrorTag permits an Object as the tooltip, which is not terrifically helpful, and the documentation seemed quite resistant as to what this should actually be. So far I have only been able to use a String as a tooltip.
In addition, the error popup is destroyed when the user leaves the error text span. I would need it to remain whilst the user is still on the text span or the popup content. I have discovered a PopupStyles enumeration which can control this behaviour, but I am unsure how to apply it. I would need to use the DismissOnMouseLeaveTextOrContent member to set the appropriate behaviour.
How can I implement an interactive error tooltip?
Edit: I discovered that a UIElement is a valid argument here- I replaced the String with a Label, for example. Some formatting issues aside, I still need to know how to change the popup style.
The error popup is intended to be a static tooltip and nothing more. It's not supposed to be interactive.
The PopupStyles enumeration appears to be used for the ISpaceReservationManager and IToolTipProvider -- there's no real connection to the tagging API at all. What you might be able to do is listen for the IWpfTextView.MouseHover event, and then use one of these APIs to trigger the tooltip that can be interacted with.
Do anyone know why FocusOut event is not working on linux?
I have 1 enabled textbox and 3 disabled combobox.
I bind the textbox with FocusOut event where it will call a proc that enables or disables the 3 combobox.
It works perfectly on Windows. However, it doesn't seem to trigger the FocusOut event when this action is done on Linux. One weird thing is that if I click on buttons, FocusOut event seems to be triggered.
Could it be because my combobox are disabled?
But why does it work on Windows?
I really hope someone can help me please.
Thanks in advance.
I have observed in the past that some window managers steal the focus temporarily from Tk on each button click before setting it back; I suspect that this has to do with the way that key event handling works, but I am unable to check at the moment (due to being on OSX, where things are different). Because of the complexities involved, I'd suggest that if you bind to <FocusOut>, you should also check whether you get a <FocusIn> event shortly after; a little extra delay (e.g., 0.1s) before doing the update of the buttons' disabled status will not hurt.
Or you could hang the code to do the disabling off the entry widget validation engine, perhaps like this:
.e configure -validation focusout -validatecommand doButtonEnableDisable
The validation interface is the same for both the old style entry and the new style ttk::entry widgets. It's also supported by spinboxes. Just be aware that you need to return a boolean true from doButtonEnableDisable or you'll reject the change to the entry, and you should take care to ensure that your code does not produce an error or it will disable itself; the docs list the things to watch out for.