Filter box gets blocked after deleting filter expression with keyboard

When I delete filtering expressions using the new Manage history... option then after closing of that window I can either right away use my mouse wheel to go through the remaining filtering expression - or - hover over the Filter box in order for it to register my wheel moves. [That difference depends on where the focus was when I started and also on if some other filtering expression was applied before closing of the window]

But when I delete filtering expressions from the Filer box using SHIFT + DELETE then mouse wheel movements are not registered unless I click in that box. And that is user un-friendly / illogical

[Version 3.16 x64; with Auto-apply filter option turned on]

Could you follow the rules for bug reports:

So far I don't see a step-by-step description and I doubt that the filter box is really "blocked" and cannot be activated again, so probably, the topic does not explain the problem.

Now what exact part of

needs further description that would have to be enclosed in an instruction like this:

#1] Move the pointer of your input electrical device called mouse over the are located on the right side where it says "Filter:"

#2] Press with your finger [or in any other way] a button that is located on the left side of that "mouse" [do not worry - it is not a real mouse, i.e. an animal, but a non-animated object so it will not bite you]

#3] Turn with your finger [or in any other way] a wheel located most likely in the middle between the left and right button of your mouse in a backward fashion. A constantly changing data should appear in the box as you continue the scrolling of the wheel

#4] Stop scrolling whenever you feel like

#5] Now on your input electrical device called keyboard press simultaneously keys or buttons described as SHIFT and DELETE. If you do not see such then you are most likely using a wrong device: a musical keyboard instead of a computer keyboard

#6] Now once again execute a rotary motion of wheel of the mouse - but this time it can also be [or even has to be] a forward motion [depending on whether you had chose the last entry from your list or not]

#7] Observe if the data changes in a way like it did during execution of instruction from point #3. If it does then you are not experiencing this bug

#8] But data does not changes when turning the wheel, then most likely you are experiencing that bug. To be sure execute again the instruction from point #2

#9] Observe again if now the data changes in a way like it did during execution of instruction from point #3. If it now does then you did experience that bug during steps #7-8

???

So, apparently, you have 2 scenarios, one with and one without hovering.
Also, it looks to me like there are dependencies like

and I misst the result you got and the result that you expected for each of the scenarios and dependencies.

For me it would be much easier to have these split up into individual instructions where I can follow each step and see if I get the same result.
Right now, I have to speculate what might have happened in your environment in the meantime, so whether your oberservation was a one-off or something reproduceable.

I think that the tone in the second post is not at all helpful and I would, if I were you, seriously consider to delete the whole post and return to descriptions based on comprehensible observations and facts. This includes judgements like

which does not help to narrow down any real bug.

That whole

part was pretty much unimportant at all. Important was the

section which contained a stand-alone instruction for repetition of the bug


As for non-helpful judgements

If I see something illogical coming out from inconsistency of software behavior, I report is a illogical. And that might be a manifestation of a bug or just normal intended behavior that happens to be inconsistent with other behaviors of that program. In that second case it becomes in me eyes user un-friendly behavior. Thus my comment you have cited


As for the tone of my previous answer

I cannot help it- my brain rewards me with pleasure when succumbing to such style of written or spoken utterance, triggered by certain interactions

Then please try to adjust your posts and style so that you come to the point more directly.
Otherwise it is absolutely tiring for me so filter the irrelevant from the relevant parts.

And in respect to

that may be as it is but is hardly ever a bug. If you don't like a particular kind of behaviour then issue a change request.
But ringing the alarm in the shape of a bug report for something that you do not like blocks the time to analyze the real bugs.
You have been with the forum long enough so that you know how to participate.

What you noticed is absolutely normal Windows behaviour and it has been like that for ages.
Try it with any dropdown box in MP3tag or any other application where a user input is possible for a dropdown list: there are 2 modes.

  • scroll mode
  • edit mode

and you switch between the 2 either with another click or Cursor down

Also see:

It's intended behavior: after editing, the mouse wheel gets enabled in dropdown fields either by opening the list or pressing keys arrow up or arrow down.

Moved to #bug-reports:no-bugs

But intended by you personally - and you do not plan to change this?

Or intended in the sense that it is just how Windows behaves in regards to this - thus cannot be changed or would be very hard to change?

What would be the difference in the end?

The same as with Mp3tag vs. WAV?

For the longest time that file format was not intended to be supported by this program - but the developer finally gave in and surprised users with including WAVs

Exactly.
And in those days MP3tag worked as intended. It was no bug that WAV was not supported.
And that is the way it is now.
Only, in this case, the cause may be a different one as I am convinced that this is the way Windows works.

Closed this topic, see Scroll wheel in Filter Box does not always work for previous discussion on this topic with OP.