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.
Related
Let me say at outset that I'm using old technology by today's standards! This happens in MFC on Visual Studio 2005 and running under WinXP. (If it 'aint broke.... ;-) )
I have a dialog based app which has a CTabCtrl with two tabs. Each contains a CListCtrl. These work perfectly under normal circumstances. They populate correctly and show and hide as they should. When I first open the application the display selection is correct. If I then minimize the dialog and restore, the CList Ctrl does not show, the tab is blank. It is the only control which has this problem. Another CListCtrl outside of the CTabCtrl does show up correctly. If I then swap tabs and back again, the other tab shows up then the first appears as normal.
This does not happen if I access any other part of the dialog before minimising, it is only when minimising is the absolute first action I take. It also happens with the CListCtrl I have in the other tab if I set this tab to be selected on startup in OnInitDialog where I set up the CTabCtrl.
I have actually solved the effect of this problem by adding into my OnSysCommand(...) the following:
if ((nID & 0xFFF0) == SC_RESTORE)
{
m_ctrlReadList.Invalidate();
}
but it bugs me that I'm adding code to solve a problem which only happens in such odd circumstances. I can't help thinking that there is something I have missed in the setup which is leading to this behaviour. Can anyone offer any explanation as to what is causing it in the first place?
My explanation is based on the facts of what I have found but this has been a learning experience for me so apologies if I get some of it a little confused, I'm still letting it settle in my mind.
Along with this problem I found another which turned out to be relevant. From the nature of the program I'm writing, my CListCtrls needed fixed width headers. Now that turned out to be another thing I couldn't set up! I just needed to prevent the user from grabbing and resizing the header's dividers or double clicking them to autosize, and of course there is functionality in the CListCtrl based on its child CHeaderCtrl to set this up isn't there? Well apparently not. LVS_EX_HEADERDRAGDROP for example isn't the way.
So I explored trying to capture messages which would allow me to myself, and what do you know, I couldn't! I could trap a few but not the ones I needed. I was looking for HDN_BEGINTRACK and HDN_DIVIDERDBLCLICK. (We won't go into the fact that you HAVE TO deal with both A and W versions of those separately!) The CHeaderCtrl is a child of the CListCtrl but it sends its messages back to the CDialog as the CListCtrl's parent. I tried there using both my list's and 0 as ID which headers apparently use. Many of them just plain didn't appear there at all.
So I created my own CListCtrl class inheriting from CListCtrl, overrode OnNotify and they turned up there. I simply prevented CListCtrl::On Notify from being called for those messages and it worked, no resize functionality at all.
I also played with the Z-order too which could have been relevant. I didn't explain earlier but this and another list are on two tabs, exactly aligned over each other. Selecting the tabs HIDEs and SHOWs each of the lists in turn. The other list had no display problems even when I changed the default display in OnInitDialog to show it at start up.
It was under the problematic one. So changing the Z-order in OnInitDialog where I set them up - did nothing! And to rub it in that second list was also unresizeable by default just as I wanted and I couldn't find out why. Their Properties listed exactly the same and there was nowhere in the code where any different aspect was set manually for either, they were effectively theoretically identical, but practically not so. So frustrating!!!
And the upshot of it is that now that the header resize issue is solved my display problem has vanished too! It looks to me and to a few others out there too who report similar symptoms as myself as though the CListCtrl is another one of the slightly flaky ones and needs a little massaging to get the best out of it.
I hope that makes sense to those of you out there who know this control well. I was surprised how simple the solution was, but it also surprised me that the diagnostic process was so difficult. It may of course come down to the ageing system I work within. Nowadays I do this only for fun and the expense of updating VS from 2005 for occasional use is not a high priority. I am sure that some of the symptoms will not show under other build and run environments but it may be worth having the issue and my solution on record somewhere for Google to find for others.
I would like to create some windows on a linux desktop for simple layout purposes. I need to avoid user input going to these windows (and I suppose avoiding the windows from gaining focus should suffice for that to happen).
I think that I can do this with the xprop command, by setting the WM_HINTS property, but I haven't found specific documentation on how to do it.
By the way, for an mplayer window, I can do this by using the option -input nodefault-bindings:conf=/dev/null. I simply need a general solution which I can enforce at a low level on any application's window.
Thanks!
A window indicates whether it wants to receive keyboard input by setting the KeyPress and KeyRelease bits in its event mask. If you do not want your window to receive keyboard input, simply do not set those event in CreateWindow()'s event mask. See http://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:ChangeWindowAttributes for more information.
Additionally, you should also set the input focus hints for your window to "NoFocus", as described in section 4.1.7 of ICCCM: http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
If you want to fiddle with other applications' windows, you should be able to change their attributes and hints, although this may result in undesirable behavior and/or side effects.
I'm working on a I/O verification tool based on Linux in a game project. It is written in C++, and,since using the same I/O module as our game, it's based on OIS 1.2. Thus, though all I need is to print users' inputs on the console, I still need to create a window for OIS.
So here comes my question: How can I create a mapped window while it is still invisible and processes keyboard events?
I can't unmapped the window in that it won't process any keyboard event anymore. I also can't find function for show/hide a window.(maybe I search through a wrong diretion...)
My little tool works fine now except there is a stupid top-level empty window which needs to be focused for processing keyboard events...
Any advise is welcomed.
Thanks!!!
After reading this post: Linux/X11 input library without creating a window,
I realized my problem was that I misunderstood the philosophy of X11. All I need to do is simply pass the root window handle to OIS, and set the x11_grabkeyboard flag as true. The only drawback is maybe I can hardly debug my program with gdb since the keyboard is grabbed...
Though my situation is solved, there is one thing left.
Every article I read said an InputOnly window won't be visible and is capable for handling input events, while my InputOnly window is absolutely visible after mapped...
Maybe it's my Linux, or again, a misunderstanding...
while designing my user control, i encountered the following problem:
i would like to set the UserControl.CanGetFocus to false, which is not possible due an error message telling me that a control unable to receive focus can not contain elements who are able to receive focus.
but as i don't want them to actually receive any focus, i would like to disable this for the child-objects as well as for my user control. i can barely believe that there's no possiblity to prevent the child-controls to receive focus, no matter of what type they are? i currently use imageboxes and pictureboxes.
already searched using google, always leading to the result that the property cannot be set to false under these conditions...
If you put the picturebox in a frame and the disable the frame then it will not receive mouse events. Doing this in combination with setting the tabstop to false will prevent the picturebox from receiving focus.
I've used this technique in the past to create a checkbox usercontrol that can be made read-only.
You can set the TabStop property of the childcontrol to False.
Have you tried just using Image controls? If I recall correctly they're lightweight and shouldn't capture focus, whereas a PictureBox is always going to be able (in theory) to capture focus. Depending on your need, this may be sufficient.
Can you set an enabled property to false?
You might want to look at this article.
http://support.microsoft.com/kb/180216
Sounds like you have a problem. The only known workaround is to set the UserControl's Enabled property to False instead of setting the CanGetFocus property. But then, of course you would not be able to respond to clicks and things.
It's been a while, but the solution to this that we used for years was to catch the received-focus event (sorry, can't remember what it is) and then explicitly force th focus to something else. It's kludgey, and not easy (because of the vagaries of event-ordering and reordering in VB/Com Windows), but it got the job done.
Is there a way to override the "undo" and "select all" in right click context menu of the browser over textarea?
Thank you.
You cannot edit the browser's built-in context menu, but you can disable it and replace it with your own using the oncontextmenu event on the window object. I would caution that this is often a bad idea. Users expect to find the built-in context menu and are often frustrated when it isn't there.
I know you can prevent the whole context menu from opening by registering to the click() event, doing some cross-browser mumbo-jumbo to get wich button was clicked, and then return false if the right one was clicked.
However, I don't think it's possible to modify the context menu itself, at least not using javascript.
I should add that you may want to rethink why you're doing this. This will never be a protection against anything (some try to prevent copying images from their website), as it may simply be disabled by turning javascript off.
UPDATE: Ok, so you don't want to prevent users to do things, bug have them doing things your way. Then, I guess the best thing to do is :
Provide users with a toolbar that allow them to do these things (and thus making them use your actions instead of the default one
Map the usual keyboard shortcuts to your actions (Ctrl+A, Ctrl+Z, etc...)
Replace the right click menu with your own.
You mentionned in another comment that you cannot reproduce copy/paste, which is correct, but you can implement you own clipboard (that will only work for your webapp) if you really have to.