I have a problem with a button I created to activate a trigger, where the button retains focus when I really wish it wouldn't.
As I said, I have a trigger that is launched by a button (it performs a synchronize, if that's at all relevant). I tend to use it a lot after I update an entry, instead of clicking the "Save" icon, so I don't forget to do the sync later.
After I click on my "sync" button and the operation completes, the cursor begins blinking in the search text box (which is just to the right of the "Lock Workspace" icon). There is a highlight around the search text entry field, and the current value (if any) in the text field is selected (highlighted).
At this point, if I start typing, the existing entry in the text field is replaced by whatever I type. Alternatively, I can press an arrow key to navigate within the text box which leaves the original entry alone but allows me to edit it.
That sounds perfectly normal, right?
So the next logical step after entering a search string is to press RETURN to execute the search.
What happens next I hesitate to even call a bug, but because of my finger habits, its certainly an irritation.
The search doesn't execute. When I press RETURN, my custom button is once again selected and activated, and the trigger controlled by the button fires again.
I can easily avoid this by clicking my mouse in the text box. Clicking it doesn't change the highlighting in any way (although the existing selected text is no longer selected). However, now the focus "really is" in the text box.
But if I don't, the trigger fires. And I have my number of iterations set pretty steeply. On my slower laptop, the sync can take about five seconds or so.
I'm typically using the search box because I'm looking for something, and often I'm in a hurry (trying to login or something). Those seconds feel like a LIFETIME to me. While its synchronizing, a modal dialog box opens, and I can no longer manipulate the window in any way, except to drag to modal dialog around.
I don't really consider it a bug, but I just find myself doing the same thing over and over. I can't seem to train myself to click in the search box before hitting return. It doesn't seem natural that I'm typing, but if I hit return, the return goes to some other control than the one I'm typing in. Instead I have to take my hand off the keyboard, manipulate the mouse, then return to the keyboard to press RETURN.
There may be a clue to the behaviour in the tab order. I noticed that I can press tab to navigate, but surprisingly, it doesn't go from the text box to the custom button located just after it (well, it probably wasn't in the text box - it just looked like it was).
Instead, tab jumps down to the the folder window. A second tab moves me to the listing screen. A third takes me to the "New" icon on the tool bar.
But the FOURTH tab... takes me back to the group window. In other words, I can tab off of the search/button, but neither of them are in the tab order, and they are no longer reachable by tabbing. Now I REALLY have to use the mouse to get back to the text field.
The REALLY interesting part is if I use Shift-tab ("back tab"). The first shift-tab finally moves the highlight to my custom button, which I think accurately represents the real state of the window. The next shift tab takes me to the listing window, the next to the folder window.
The next shift-tab I expected to take me to the "New" button. But it doesn't. It takes me back to the custom button I defined.
That's when I realized that when the focus is anywhere on the toolbar, you use the arrow keys to navigate left and right on the tool icons. If I hit left arrow when on focus is on "New", then focus shifts to the custom button. But if I hit left arrow again, it finally does go to the text box, but from a keyboard navigation point of view, I'm "stuck" because I can't use the arrow keys to move to another icon in the toolbar.
Instead, I need to tab out of the text field. But that now takes me off of the toolbar completely, so I have to tab "back".
Apparently another facet is that I can only tab "in" to the toolbar on the left, or shift-tab into the toolbar on the right. It doesn't retain any memory of whether any other tool was previously selected.
When I read this, it all sounds mostly like standard Windows behavior. And since what it seems to be doing is returning focus to the end of the toolbar, perhaps that can't even be changed (without some ungodly custom widgets).
I did think of one idea, but I'm not a GUI guy so I don't know if it would help, hurt or have no effect. Besides the RETURN key, another way to start the search is to pull it down (oh yeah, its not a text box, its a select box, isn't it?) and whatever entry I click on will instantly be searched for. Something I've seen occasional in web-speak is a submit button to allow you to click something to initiate the search for whatever is currently displayed in the text box. I'm not sure if adding an extra control to perform the RETURN function would offer an opportunity to enhance the keyboard navigation operation, but I thought it was worth mentioning.
But anyway, just submitting a "ticket" on it (I'm not really going to) makes me feel better, so I'm not quite as irritated when it happens now.
So, thanks for listening!
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some of the UI quirks regarding the toolbar and search box have been noted before, but I don't think anyone's ever gone into such detail about them.
Thank you for your post; it will be valuable if and when Dominik gets around to reexamining this part of the code - or if some other competent programmer ever wants to attempt to write a patch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After I click on my "sync" button and the operation completes, the cursor begins blinking in the search text box
I also have a sync button. The only action it performs is "Synchronize active database with a file/URL". I can confirm this behavior.
It appears the the behavior of selecting the seach box is a property of the sync function itself becasue a manual sync using 'File>Synchronize>Synchronize with File...' also selects the quick search box.
... after entering a search string...[I] press RETURN to execute the search,....the search doesn't execute....my custom button is once again selected and activated, and the trigger controlled by the button fires again.
I can't confirm this behavior. On my system, search (after button triggered sync) executes correctly, an entry is selected (not the sync button), and the trigger does not fire again.
Make sure you are using the latest version, KeePass 2.30
Try simplifying your trigger(s).
Try disabling all other triggers.
Look for the possibility of infinite loops. These can occur if the trigger system contains save events, because a sync action is classified as a save.
There may be a clue to the behaviour in the tab order...
The normal tab order leaving the search box (if a search is not exectued) is to select a group. However if a search is executed, an entry is selected instead (probably the first match). At the moment I don't think the tab order is an issue.
The first shift-tab finally moves the highlight to my custom button,
I observe different behavior, but again I don't suspect tab order.
But if I don't, the trigger fires. And I have my number of iterations set pretty steeply. On my slower laptop, the sync can take about five seconds or so.
This side effect is a separate issue.
It is likely that you can optimize your configuration to minimize these delays without sacrificing security. How many database copies are involved in your synchronization scheme and how are they arranged?
e.g. Is your synchronization scheme an AXB config?:
local db A <=sync=> cental db X <=sync=> local db B
where central db X could be a cloud or LAN database
Last edit: wellread1 2015-09-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a problem with a button I created to activate a trigger, where the button retains focus when I really wish it wouldn't.
As I said, I have a trigger that is launched by a button (it performs a synchronize, if that's at all relevant). I tend to use it a lot after I update an entry, instead of clicking the "Save" icon, so I don't forget to do the sync later.
After I click on my "sync" button and the operation completes, the cursor begins blinking in the search text box (which is just to the right of the "Lock Workspace" icon). There is a highlight around the search text entry field, and the current value (if any) in the text field is selected (highlighted).
At this point, if I start typing, the existing entry in the text field is replaced by whatever I type. Alternatively, I can press an arrow key to navigate within the text box which leaves the original entry alone but allows me to edit it.
That sounds perfectly normal, right?
So the next logical step after entering a search string is to press RETURN to execute the search.
What happens next I hesitate to even call a bug, but because of my finger habits, its certainly an irritation.
The search doesn't execute. When I press RETURN, my custom button is once again selected and activated, and the trigger controlled by the button fires again.
I can easily avoid this by clicking my mouse in the text box. Clicking it doesn't change the highlighting in any way (although the existing selected text is no longer selected). However, now the focus "really is" in the text box.
But if I don't, the trigger fires. And I have my number of iterations set pretty steeply. On my slower laptop, the sync can take about five seconds or so.
I'm typically using the search box because I'm looking for something, and often I'm in a hurry (trying to login or something). Those seconds feel like a LIFETIME to me. While its synchronizing, a modal dialog box opens, and I can no longer manipulate the window in any way, except to drag to modal dialog around.
I don't really consider it a bug, but I just find myself doing the same thing over and over. I can't seem to train myself to click in the search box before hitting return. It doesn't seem natural that I'm typing, but if I hit return, the return goes to some other control than the one I'm typing in. Instead I have to take my hand off the keyboard, manipulate the mouse, then return to the keyboard to press RETURN.
There may be a clue to the behaviour in the tab order. I noticed that I can press tab to navigate, but surprisingly, it doesn't go from the text box to the custom button located just after it (well, it probably wasn't in the text box - it just looked like it was).
Instead, tab jumps down to the the folder window. A second tab moves me to the listing screen. A third takes me to the "New" icon on the tool bar.
But the FOURTH tab... takes me back to the group window. In other words, I can tab off of the search/button, but neither of them are in the tab order, and they are no longer reachable by tabbing. Now I REALLY have to use the mouse to get back to the text field.
The REALLY interesting part is if I use Shift-tab ("back tab"). The first shift-tab finally moves the highlight to my custom button, which I think accurately represents the real state of the window. The next shift tab takes me to the listing window, the next to the folder window.
The next shift-tab I expected to take me to the "New" button. But it doesn't. It takes me back to the custom button I defined.
That's when I realized that when the focus is anywhere on the toolbar, you use the arrow keys to navigate left and right on the tool icons. If I hit left arrow when on focus is on "New", then focus shifts to the custom button. But if I hit left arrow again, it finally does go to the text box, but from a keyboard navigation point of view, I'm "stuck" because I can't use the arrow keys to move to another icon in the toolbar.
Instead, I need to tab out of the text field. But that now takes me off of the toolbar completely, so I have to tab "back".
Apparently another facet is that I can only tab "in" to the toolbar on the left, or shift-tab into the toolbar on the right. It doesn't retain any memory of whether any other tool was previously selected.
When I read this, it all sounds mostly like standard Windows behavior. And since what it seems to be doing is returning focus to the end of the toolbar, perhaps that can't even be changed (without some ungodly custom widgets).
I did think of one idea, but I'm not a GUI guy so I don't know if it would help, hurt or have no effect. Besides the RETURN key, another way to start the search is to pull it down (oh yeah, its not a text box, its a select box, isn't it?) and whatever entry I click on will instantly be searched for. Something I've seen occasional in web-speak is a submit button to allow you to click something to initiate the search for whatever is currently displayed in the text box. I'm not sure if adding an extra control to perform the RETURN function would offer an opportunity to enhance the keyboard navigation operation, but I thought it was worth mentioning.
But anyway, just submitting a "ticket" on it (I'm not really going to) makes me feel better, so I'm not quite as irritated when it happens now.
So, thanks for listening!
Jim
Some of the UI quirks regarding the toolbar and search box have been noted before, but I don't think anyone's ever gone into such detail about them.
Thank you for your post; it will be valuable if and when Dominik gets around to reexamining this part of the code - or if some other competent programmer ever wants to attempt to write a patch.
I also have a sync button. The only action it performs is "Synchronize active database with a file/URL". I can confirm this behavior.
It appears the the behavior of selecting the seach box is a property of the sync function itself becasue a manual sync using 'File>Synchronize>Synchronize with File...' also selects the quick search box.
I can't confirm this behavior. On my system, search (after button triggered sync) executes correctly, an entry is selected (not the sync button), and the trigger does not fire again.
The normal tab order leaving the search box (if a search is not exectued) is to select a group. However if a search is executed, an entry is selected instead (probably the first match). At the moment I don't think the tab order is an issue.
I observe different behavior, but again I don't suspect tab order.
This side effect is a separate issue.
It is likely that you can optimize your configuration to minimize these delays without sacrificing security. How many database copies are involved in your synchronization scheme and how are they arranged?
e.g. Is your synchronization scheme an AXB config?:
Last edit: wellread1 2015-09-11