Scroll the file window instead of the search control with mouse wheel

[Arthur]

Normally in windows and also in IMatch the mouse wheel is consumed by the control the mouse is hovered over. This is independent from the currently set focus. If the focus is set for example in the "Media & Folders" tree, it is still possible to scroll the categories panel without transfering focus.

This is different when it comes to the search box in the file window. If the focus is in the search box and the user uses the mouse wheel over the thumbnails below, the wheel events are consumed by the search box, which changes the search results. What the user wants to do, is to scroll the file window. Please change it, so that the search box is only scrolled with the mouse over it.

[ben]

+1
happens to me quite often, but couldn't be bothered so far to file a feature request

Ben

[Mario]

This is standard Windows behavior. Edit controls in Windows grab all messages. As soon as you have focused one it processes all messages, including wheel.
Working against that would be a tremendous effort and probably even dependent on the Windows version. Not something I would look into...

[Arthur]

This is sadly not true,

every box in IMatch except the search box in the file window behaves like requested by me. Take for example the "File Name" search box in the "Filter" panel. Or the search boxes in the category filter. They do nothing without the mouse over them, even when they are focused.

I am UI engineer in our company. Although we develop using WPF, the same is true for other technologies. The observed behavior often occures when the mouse is explicitly captured. This results in all events routed to this control, even if they do not belong there.

[sinus]

This "problem" I have very often.
It is very annoying, but after all I thought, ok, my mistake.

If this could be avoided by IMatch, this would be great!

+1

[Carlo Didier]

+1 very annoying indeed
same thing in other search boxes in IMatch

[Mario]

This is sadly not true,

every box in IMatch except the search box in the file window behaves like requested by me. Take for example the "File Name" search box in the "Filter" panel. Or the search boxes in the category filter. They do nothing without the mouse over them, even when they are focused.

I am UI engineer in our company. Although we develop using WPF, the same is true for other technologies. The observed behavior often occures when the mouse is explicitly captured. This results in all events routed to this control, even if they do not belong there.

As you are surely aware, the file window search bar input field is not a true edit field, it is a drop-down combo box.
It remember the last recently used search strings and you can open it via the arrow button on the right.

When you active the combo by clicking into it, and then you use the wheel, the combo box uses that to scroll between the elements in the drop-down list. You can try that out with other combo boxes or list boxes.

[Jingo]

Normally in windows and also in IMatch the mouse wheel is consumed by the control the mouse is hovered over. This is independent from the currently set focus. If the focus is set for example in the "Media & Folders" tree, it is still possible to scroll the categories panel without transfering focus.

This is different when it comes to the search box in the file window. If the focus is in the search box and the user uses the mouse wheel over the thumbnails below, the wheel events are consumed by the search box, which changes the search results. What the user wants to do, is to scroll the file window. Please change it, so that the search box is only scrolled with the mouse over it.

Hmmm.. I see the same behavior in MANY programs I use on a daily basis... just tried it for example in XYPlorer... if I have a drop down box open, move the mouse to a file window and try to scroll with the mouse wheel - it doesn't scroll because focus is on the dropdown box.. similar to the search dropdown in IMatch.

Not sure if it will work - but back in my Win 7 days I used to use a program called Katmouse (http://ehiti.de/katmouse/) to do what win10 does naturally now.. perhaps this will help your situation?

[Arthur]

I do not speak of opened drop downs. I speak of closed drop downs. The three other controls in Imatch I mentioned above are also dropdowns and they work. When a drop down is open, the window that appears is often a popup, which is a special win32 window, which captures the mouse. This is needed to close the popup, if the click goes outside of the control. After the popup is closed the mouse capture is normally released and the mouse events routed again to the control, the  mouse is over. The normal behavior for drop downs can be seen on drop downs in the category filter panel, below the category tree.

[Mario]

All combo boxes behave like that. When I click into the search box in the Category Filter you mentioned and use the wheel, it scrolls through the last recently used entries. Metadata Search, File Name, all work the same. When they got the focus, windows scrolls them when I use the wheel. This is the standard behavior.

[Arthur]

I think you do not understand me. So reconstruction steps:

Preconditions:
- Ensure a single monitor workspace, to prevent influences from other aspects.
- Ensure that there are enough photos in the file window, so that it can scroll.
- Do not open the drop downs while processing the steps.

1) Open category filter panel
2) Set focus to "Search" box
3) Move mouse to the scrollable part of the file window while focus ist still in the Category Panel, do NOT click
4) Use mouse wheel over the file window

=> File Window scrolls

In contrast to the search box in the file window:

1) Set focus to the search box in the file window
2) Move mouse to the scrollable part of the file window while focus ist still in the search box, do NOT click
3) Use mouse wheel over the file window

=> The search box scrolls


I have written a rapid prototype on how it should behave. See attachment. If everything is still OK, then I give up. Then it is OK.

[Mario]

I assume you mean the Category Panel in the Filter Panel?
The filter box in the Category filter is no drop-down, it's a regular edit box. Hence it has no use for the wheel and does not grab it.

Or do you mean the Category Filter below the Category Tree in the Category View? This is a drop-down and reacts on the wheel.

Examples for combo boxes are the file window search bar, the Metadata Search, the search input fields in the Category and Folder Filter property panels





All Windows drop-down (combo box) controls and list boxes react on the mouse wheel when they have the input focus.

[Carlo Didier]

All combo boxes behave like that. When I click into the search box in the Category Filter you mentioned and use the wheel, it scrolls through the last recently used entries. Metadata Search, File Name, all work the same. When they got the focus, windows scrolls them when I use the wheel. This is the standard behavior.

And that's exactly what's so annoying. Never used that drop-down / history feature of the search fields, but I always forget to first click when I want to scroll and boom, my search is killed ...

[Mario]

I plan to change the search to require an explicit <Return> as it seems that many people have problems with the automatic mode. This kills both problems, because an accidental scroll will change the search term but no longer trigger a search.

[Arthur]

I mean the fields: Combo Box => Uses wheel, exactly the field where "persons" is entered on your screen shot. Just set the focus there so that the caret is blinking, do not open the combo box drop down and then:

- Move mouse to the scrollable part of the "File Window" with enough photos in it so it is scrollable, do NOT click or change focus in any way.

NOTE: The focus is still in the "persons" field, but the mouse is over the file window

- Use mouse wheel over the file window

Now: The combo box still has focus, but the file window scrolls. Do you see that?

[Mario]

The file window search bar is a child of the file window. This means that it receives the scroll event when active and when you have the mouse over the file window. Message passing.

[Arthur]

Hm, messages are normally passed from children to parents. The visual tree of the file window is something like that:

File Window
- ToolBar
-- SearchBox
- ScrollViewer
-- TileCanvas (DirectX?)

This is why it is strange, that the SearchBox becomes mouse events, even if the mouse is in the ScrollViewer sibling. This should not happen.

I am not at home, so I cannot test it, but set the focus in the "persons" field. Move the mouse to the "Filter:" field below and use mouse wheel there without changing focus. I think the "Filter:" field will scroll.

[sinus]

I plan to change the search to require an explicit <Return> as it seems that many people have problems with the automatic mode. This kills both problems, because an accidental scroll will change the search term but no longer trigger a search.

For me personally this seems to be a good solution.

[Arthur]

Yes this would be a start. But the usability could still be improved by letting the file window scroll, while focus is in the search box. This allows the following cycles

enter search term -> scroll through results -> adapt  search term -> scroll through results -> ...

without changing focus.

@Mario But you might be right. When I look at this screenshot here

https://www.photools.com/community/index.php?action=dlattach;topic=5434.0;attach=12175;image

the scrollbar in the file window seems to cover the toolbar also. Seen on the top right side where it extends into the toolbar region.

If the visual tree is:

File Window
- Scroll Viewer
-- ToolBar
--- SearchBox
-- Tile Canvas

then it is clear while the search box consumes the scroll viewers events. Would explain the issue. Moving the part that does not scroll anyway out of the scroll viewer would resolve it. IMatch would look like this then: