Since upgrading to 9.1.1.7, I have the following misbehaviour from DO :
After pressing a button on one of the toolbars, the filepane is not reacting at all.
For instance, you click the a button like this in the toolbar :
<?xml version="1.0"?>
<button display="both" icon_size="large">
<label>I:\down</label>
<tip>Go to download dir</tip>
<icon1>68</icon1>
<function type="normal">
<instruction>Go i:\down</instruction>
</function>
</button>
...the filepane goes to the correct directory, but it doesn't react to a keypress following it.
For instance, you press the button and then enter s to select the first item starting with an s ... the filepane isn't reacting at all !
You have to click inside the filepane after having clicked the button, this misbehaviour didn't happen before.
Can you go BACK to v9.1.1.6 and prove that it's something in 9.1.1.7 that definitely "broke"?
Also, is I:\Down a "network" drive mapping and/or are there lots of files in that folder nowadays? Could it just be that it's taking time to enumerate that folder before the file display can respond and become active, and would that really be an "opus" specific issue? What happens if you enter that folder in Explorer after just expanding through the folder tree, or otherwise write a batch file to launch explorer to open in that path? Comparison?
Will downgrade to 9116 in a moment.
I:\down is a normal directory in a normal partition, no network involved.
About the enumerating, Whenever I click a button, the directory contents appear jast as fast as it should be, so i don't think it has something to with enumerating.
Explorer behaves perfectly in that folder, just like it does with any drive/folder.
I expect it some "misbehaviour" in the button-click routine (sorry, I'm not a programmer) in the sence that it is taking too much time before it gives the filepane the focus.
Will install 9116, in a few moments, just a sec...
After clicking a button, and immediately pressing a letter the filepane reacts immediately.
So, The problem has indeed been introduced in version 9.1.1.7
With all my "directory shortcut" buttons, after clicking them, I can, instantly, enter a letter and the filepane jumps immediately.
I would advice more users to test this out with the newest version.
Clicking a shortcut button like the one below :
<?xml version="1.0"?>
<button display="both" icon_size="large">
<label>Program Files</label>
<icon1>39</icon1>
<function type="normal">
<instruction>C:\Program Files\</instruction>
</function>
</button>
... and then immediately pressing a letter to jump to the first occurence, in version 9117, it doesn't react for like 5 to 10 seconds, even worse, if you DO press a letter directly after clicking a button, the filepane will never react, you have to give it focus by clicking anywhere in the filepane.
So, please, I can now officially confirm that this bug is only present in version 9.1.1.7 (any view mode).
I just tried it here. I have made the following observation. If I click the button and not move the mouse away from the button nothing happens. But if I move the mouse away from the button all is working well.
This behaviour is the same for all similar buttons
Using the button code provided above at [Filepane not getting focus after toolbar button pressed) , I confirm different behavior in 9.1.1.7 than in 9.1.1.6 . However, I don't find an amount of time between clicking the button and typing a letter to be relevant. Neither do I find that one has to click in the lister after clicking the button in order to be able to type a letter.
My findings are the same as those of xbprm, namely, as long as the mouse pointer remains on the button, keyboard action does nothing. As soon as the pointer is moved off the button, the keyboard works.
In 9.1.1.6, the keyboard works while the pointer remains on the button.
As rcoleman correctly says, In 9.1.1.6, the keyboard works while the pointer remains on the button.
It's specifically irritating for keyboard users (which most of us are, I don't think many people will use the mouse to scroll and find the file "twain.dll" in the Windows folder, I believe most users just type "tw" and have their file in focus).
I think it is normal user behaviour to click a button, and then directly use the keyboard.
Just as been said, in version 9.1.1.6 all worked out well, now people suddenly have to move their mousepointer over the filepane in order for it to react to keyboard input.
Nitpicking, probably, but the mouse pointer doesn't have to be moved over the file pane. It just has to be moved off the button.
Actually, I can now simplify the description of the problem to "the keyboard is inoperative when the mouse pointer is on a tool bar button". It doesn't matter whether a button has been used to navigate or even whether a button has been clicked.
I was about to post about that misbehaviour point since 9.1.1.7 update (very annoying to people who use keyboard to browse their lists like me). I'm glad you all guys handled things.
