Using mouse's scroll wheel with list MetaData

I have a good deal of Custom MetaData fields defined.

No matter which field I might give the focus to (e.g., I click inside a text type MetaData field), if I’m scrolling the Custom MetaData pane using my mouse’s scroll wheel—and my mouse cursor passes over a list type field—suddenly (and though that field is not in focus), I’m suddenly scrolling through the values of that list (that is to say, involuntarily changing the selected list value!)

:cry:

:imp:

If I keep a steady hand (hah!) and keep the mouse cursor over the Custom MetaData pane’s scrollbar itself, no problem.

But if I stray over the Custom MetaData pane while passing over a list field, I start changing things!

You really need to have a field in focus for the scroll wheel to have any affect on it!

As a less than ideal solution, I’ve moved all my list fields to the end of my Custom MetaData pane to avoid this issue in the future.

It kinda messes with my flow though. :neutral_face:

I wonder if you are not seeing some of this issue [url]Recurring Issue: Font Menu Crashing]. In my limited testing, most of the dropdown menus in Scrivener seem to be affected for some folks. I was only able to sort of duplicate it when I cranked up the speed and sensitivity of my mouse settings in Windows (no separate mouse driver settings). It seems to affect some folks with mouse/pointing device drivers outside of the basic controls within Windows itself. Not having one of those mice/pointing devices, I can’t tell for certain.

I . . . don’t think so. (?) Perhaps. I changed my Select a pointer speed setting in my Mouse Properties box, but that did nothing.

I cannot seem to find anywhere to change my mouse’s sensitivity, but it might be one of those buried things.

It’s rather frustrating, in that I had my Custom MetaData organized by function within my process (Act details here, Scene details there, Cleanup procedures down there, and Editing notes all together over there) but now I have all the list items moved to the very bottom of the Custom MetaData subpanel just so I don’t accidentally scroll over them and change something.

[As an unrelated side wish, it would be nice if the Custom MetaData itself could have user defind subcategories to group all items with a related purpose (editing, cleanup, scenes, etc.), but that seems like it could be add a level of difficulty for development when they’ve got enough needed features to implement.]

I still assert that if I haven’t selected a “list” type Custom MetaData field by intent, scrolling over it shouldn’t cause it to involuntarily change the list value to something other than what I have selected intentionally.

Sorry, was just an idea. I don’t seem to have this issue and can’t replicate it.

I managed to replicate this (in under a minute). I have a project that uses a fair amount of list metadata (in fact, most of my metadata is what a programmer might call “enumerated lists”).

The problem happens for me when the mouse is directly over the data field (which, of course, happens when you’re scrolling through your metadata). It resembles somewhat the earlier issue with accidental selection of items in the label/status fields, but this time has nothing to do with the speed of your mouse movement. Scrivener simply assumes that if you’re hovering the mouse over the metadata list (even for a millisecond) that you want to scroll through the list items.

I don’t know how this one should be solved, though. On the one hand, I can use the scroll bar and simply avoid the issue. But, as mentioned, this requires a workflow change if we’re accustomed to scrolling through the items. Perhaps when scrolling through the metadata items, Scrivener should not assume we’re trying to change the metadata of an item unless we click on it? Not sure how the Mac version works.

More observations: It isn’t limited to Custom MetaData, nor do you need so many fields that you even need to scroll the MetaData pane. I don’t usually have the General MetaData panel open, but I had a project I wanted to test this out on and it had very little Custom MetaData, and none of it were list types, so I opened the General MetaData panel and found the same behavior.

And, surprise, when I scrolled through the only built-in list type there (Section type) it changed the values until it got to the end of the list (which is Edit…, which caused the Project Settings dialog to pop up.) And since I have my PC set up to move the mouse to the default button of dialogs, it jumps my mouse elsewhere suddenly, which was unexpected and unnerving.

And, sure, I can change my workflow, but I am a creature of habit and it’s taking time to remember to work around something that probably ought not to be happening in the first place.

It’s not the end of the world, but it would be nicer if that wasn’t how it worked.

I’m still hoping this is something that can be fixed sometime. Just saying.

FWIW, I am aware there may be constraints that are difficult to get around, but I’m hoping it’s being thought about occasionally, because this behavior is unfortunate, disruptive, and somewhat annoying.

Again, just saying.

I have the same problem.
Version: 3.1.1.0 (1463331) 64-bit - 03 nov. 2021

In my experience (usually on Mac touchpad), it’s normal for scrolling to affect what’s under the cursor. I’m typing in Chrome right now, but if I move the cursor to Finder and use two-finger scrolling gestures, it affects the Finder window. For the same thing to happen in Scrivener is not surprising.

Yeah, it is the expected behaviour, but it is dangerous in Scrivener as the mouse wheel can change some precious metadata. Maybe one of these solutions could avoid it:

  • Disabling mouse wheel over that panel (the obvious solution but I don’t know if it is easy to do)
  • A “lock” option check next to the metadata name.
  • Clicking (or mouse wheel) in the specific metadata could open a popup window to select the data inside, just like the Project Keywords floating window.
  • Moving mouse wheel over metadata could trigger a popup window just asking if you are sure of the change (probably the worst solution, maybe the easiest to implement).

I don’t know the best way.
Collapsing that menu is not useful as you can not se the metadata.

By the way, a custom metadata consisting in a list of checkboxes maybe would be nice.