I am able to obtain the list of all windows using _NET_CLIENT_LIST Atom property of x11. Using that, I choose a particular window of my interest, say the gedit window, and use XSetInputFocus and that will perfectly set the keyboard inputs and controls to the gedit window.
Now my question is, is there a similar function in X11 such that we can set the mouse focus to a particular window, such that any mouse clicks or selections will be confined to that particular window only.
I tried XGrabPointer, but with no success. It will simply freeze the mouse and no further mouse inputs will be displayed on screen (like mouse clicks; I can just see the mouse pointer, I can also move it, but it doesn't perform any click operations).
You should be able to poll for mouse events and, if the user tries to move out of the rectangle you should be able to reposition it. If you don't keep the pointer out of the other window(s), I don't think you can prevent mouse clicks from reaching them, but that may be possible.
Related
I am using xlib draw a figure and give some events as input to draw certain on the window.I want to know how can i save these events results? Because on window resize all my results disappears.
How can i save the results of each event so that on resize(where it calls the expose event) the results of previous events remains on the screen.
As I remember xlib if you loose content of the window when resizing it means you didn't register your callback for refresh event. Copy your drawing code into this callback and everything should be ok.
This is kind of a hard question to describe, and I've searched for about an hour now to no avail.
Essentially, picture a small 'flyout' window like the Windows 7 Wireless Control or the Volume Slider from the system tray(notification area). When you click on the icon, the application pops up with focus, and if you click off of it, the window destroys itself.
I thought it woudl be easily solved by simply having my window destroy it self when it loses focus (I've been listening for WM_KILLFOCUS), but the problem is, if the icon is clicked, my window does not always get focus. Since this isn't the case, if the user clicks my icon, and then clicks away because it was a mistake (on the desktop say), then how can I set my app to close?
I've tried messing with SPY++ but checking the volume control / wireless control apps are proving difficult as they disappear when I try to get their window/process handles.
Thanks!
The usual way this is implemented is by starting a timer on the window creation. If the window gets the focus before the timer has triggered, this means the user has interacted with the window. In this case, the window will just stop the timer and will destroy itself when it loses the focus. In the case the window did not get the focus before the timer was triggered, the window will destroy itself on the timer event.
This is also usually combined with opacity animation, so that the window is fading out while waiting for the user. Sort of a visual feedback to the user that it will be soon gone. However, the opacity animation is used mostly for notification toasts, and is rarely used for control windows like the volume control.
The alternative is to force set the focus in your window when the user interacts with your systray icon.
Also note that if your window is a top-level window, the preferred message to listen is not WM_KILLFOCUS, but WM_ACTIVATE and WM_MOUSEACTIVATE. You can also listen to WM_NCACTIVATE, but that one has some specifics, if you are doing a custom non-client area.
Update: You can set the focus to your window by calling either SetActiveWindow or SetFocus on it when you create it (or when you make it visible, if you're hiding it).
A long, long time ago I wrote a drop-in replacement for the Windows 3.1 Task Manager that accomplished this by handling WM_ACTIVATEAPP. Give that a try.
Have you looked into the Popup? That one will disappear once you click outside it (unless you set StaysOpen to true).
On System.Windows.UIElement there is a CaptureMouse() and a paired ReleaseMouseCapture() method. In this WPF DragDrop sample they call CaptureMouse on MouseDown and release it on MouseUp. The documentation in MSDN is about as useless as it comes - "CaptureMouse -> Captures the mouse."
In my head before trying it I assumed that it somehow locked the mouse inside the UIElement bounds, but that's clearly not the case when I try it. From experimenting, it seems to have something to do with responding to events when the mouse is outside of the UIElement, but not wanting to be a cargo cult programmer I don't want to just use it because the example does, I'd like an authoritative description of what it means.
From Capture and Uncapture the Mouse on MSDN:
When an object captures the mouse, all mouse related events are treated as if the object with mouse capture perform the event, even if the mouse pointer is over another object.
Only the capturing control receives the mouse events until released.
Capturing the mouse is useful for dragging because all the dragging code can exist in the one control, rather than being spread over multiple controls.
When it has captured the mouse, a control will receive mouse events even if the mouse pointer is no longer within its bounding area.
Typically, it's used for:
Drag and drop
Buttons (to handle Mouse Up when you put the mouse down on the button and move the mouse before you release the button)
The Silverlight 2 documentation for it has a more verbose description, I don't know why it isn't a part of the 3.5 documentation page too:
When an object has captured the mouse, that object receives mouse input whether or not the mouse pointer is within its bounding area. The mouse is typically only captured during simulated drag operations.
...
It works the same with WPF, and so the reason it is used with DragDrop, is that is how the
it knows to report back to the control being dragged from when the mouse may be outside of that control. If you comment out the MyCanvas.Capture() and the Capture(Null) (which clears it) then you can no longer drop.
I've created a WPF application where the title bar and chrome are turned off. I have a border around the entire app, with the idea that it would act like the chrome in some regards. The first thing I'm trying to do is have the mousemove event capture the movement of the mouse when the mouse is clicked, so that the window moves with the mouse. The problem is that if the mouse moves too quickly, it manages to leave the window and therefore the mousemove no longer fires. I've been able to do this with a normal WinForm with no problems regardless of the speed of the mouse. Is there any way to do this more efficiently, or perhaps tune the polling of the mousemove? Perhaps a different container other than border that would perform better?
Try Me.DragMove in the window's left click event handler. It much better than most custom solutions.
When the user clicks you should capture the mouse (see Mouse.Capture). That way, you'll get the mouse events regardless of whether the mouse cursor is over your element or not.
I am working a WPF application, where I have maintained a Menu Bar with Input Gestures i.e keyboard Shortcuts.
For Save As menu item, I have kept Ctrl+A as per User's requirement. It works fine as far as the focus is on the main window.
Now my problem is, suppose use has navigated in some Listbox in window, and if he presses Ctrl+A, then Select All functionality takes places for the list box and Save As dialog box does not get called (as i have done the command binding for this input gesture)
Any idea how can I avoid this? and yes, I can not change my input gesture. It has to be Ctrl+A. :)
Thanks
I think you could change the command bindings on the list box object to remove the binding for the command. Look at the ListBox.CommandBindings list.
You could also turn off Focusable on the ListBox so that it never receives keyboard commands.
You could also check out the eventing model. You could probably catch the keydown as the preview events "bubble up" from the root of the logical tree and then they are passed down from the end element down. They can be marked as handled on the way up or the way back down.