Numerical Entry Boxes dragging "Jump To"

I must say, and I know it has been said before, when having to do a lot of fiddly cropping, sizing and positioning, the jump to feature - that is to say once you have traveled about halfway through the range, it jumps to the far end - is a very painful thing. Was it supposed to be a time saver? I might commit an act of very out of character violence against the next client who smirks at me and says "no, not that far!".
If it was changed to be velocity sensitive it might be better but my efforts to avoid the jump to the far extreme have all failed bar going a bit and stopping and going a bit more which of course then inspires the client to say "no, further...to the XXXX, like I said".

I do love the system despite my whinging and today I am pleased to announce that I have become the proud owner of a Blackmagic Pocket Cinema Camera 4K!

I have smooth mouse response with no issues in numerical entry boxes. It may be an OS mouse issue. Which entry fields are giving you the most trouble?

It's probably worth putting your system details in your signature too, as it will help diagnose specific issues.

Everything in the timeline inspector. Crop, position, scale - text position.
Move a pic to the top - it starts to move and then jumps out of sight...go the other way and it comes back in.
If it was a windows issue it would be great...if I could find the solution.

W10 1803

I think this has been noted before and I get frustrated at the same behaviour (happens on DR14 and DR15).

For example, when dragging the mouse pointer on an X or Y position box to move (say) a text item around the screen, suddenly the text will jump hugely and the numeric value increases dramatically. This is not new behaviour and others have complained before.

Yes! Exactly. I think, if it was written into the code, it was thought to be a convenience but I would rather it didn’t happen. A shift to go really fast and an alt to go really slow would be ideal. At the moment I position things with trepidation.

Confirm ....v16 Beta7... still this real nuisance

-faxxe

once you have traveled about halfway through the range, it jumps to the far end - is a very painful thing.

I HATE this behavior, and actually consider it a bug. I'm constantly trying to get my X or Y Position into palace and the damn things go wild on me. WTF!

I HATE this behavior, and actually consider it a bug. I'm constantly trying to get my X or Y Position into palace and the damn things go wild on me. WTF!

+1

And for me, since every project I do at the moment involves UHD footage on a 1080 timeline with re-faming and added pans, tilts and zooms it's a constant fight with every shot.

It seems to me to relate to when the mouse pointer would be hitting the edge of the screen. My clunky workaround is to make movements in small sections, letting go of the mouse and the pressing it again, but even then I often miss it.

...movements in small sections, letting go of the mouse and the pressing it again, but even then I often miss it.

Tell me about it!
I have been a pig in clover (yes, clover) with the editing advancements but this is a real downer.

Can we do forum polls? Would the gurus of code implement changes if enough users push for it?

...maybe the poll should not be open to the “I just downloaded a scalpel and now looking for a surgery forum” league...

...movements in small sections, letting go of the mouse and the pressing it again, but even then I often miss it.

Tell me about it!
I have been a pig in clover (yes, clover) with the editing advancements but this is a real downer.

Can we do forum polls? Would the gurus of code implement changes if enough users push for it?

...maybe the poll should not be open to the “I just downloaded a scalpel and now looking for a surgery forum” league...

None of the Mac systems I use show this issue. It may be a Windows version issue only.

Same bug here, running on Windows 10.

I have the impression that it happens when you move the cursor from one screen to another while dragging values, but I might be wrong.

I have the impression that it happens when you move the cursor from one screen to another while dragging values, but I might be wrong.

I don’t think so. I think if you grab the Y position on the inspector transform and make a steady vertical reposition it will jump to the far extreme.

Everything in the timeline inspector. Crop, position, scale - text position.
Move a pic to the top - it starts to move and then jumps out of sight...go the other way and it comes back in.
If it was a windows issue it would be great...if I could find the solution.

W10 1803

Same here on Win10 1809, Studio Beta 7.

Can we have some input here from BMD?

Is this behaviour ever going to be changed or is it part of the spec (for some unknown reason). As you can see, lots of people (including myself) find it incredibly annoying!

Thanks in advance.

I do like to see ongoing interest in the things that I think are worthy of imminent attention!

Been seeing this in Studio 15 & 16 since I started with Resolve. It's most irritating. I can reproduce it in any text box which changes stuff by mouse dragging in a text box, e.g, when changing position X & Y.

To reproduce: put mouse cursor in control box, drag at a consistent speed to the right, then - BAM! - it jumps hugely requiring a reset. I'm then forced into doing tiny little repeated mouse grabs (rather than one big one) in order to side-step this issue.

Animated GIF here showing steady movement in Position X box as I drag the mouse to the right. It goes from 0 to 800 or so steadily then leaps to 2500 or so. All the "mouseable" text inputs can fail in the same way so far as I can see. It seems to fail when the (invisible) mouse passes over another control?

Ah, my animated GIF tool seems to have unwittingly revealed the hidden mouse movements which you don't normally see in Resolve itself when mouse-dragging in a text input control!

More experimentation with ScreenToGif seems to reveal that scrolling to the right when in a text box at some point causes the mouse to invisibly wrap back to the left of the current Resolve window and then move across it left-to-right until it reaches the point where it started from - hence the huge jump in the text box values. I tried messing with my mouse settings locally but nothing seems to stop this bug on the user side in Windows 10.

As an ex-dev myself, I'll bet there is a debug mode switch which can unhide the mouse pointer so that the devs can confirm my theory if this ever gets pushed upwards as a proper bug, which it undoubtedly is! Possibly doesn't happen on other platforms due to their totally different underlying UI management.

Interesting findings, Bob! Great sleuthing and keeping the thread alive!
Windows users are surely a large part of the user group and knowing they face this annoyance will be starting to give the dev team a burning desire to make their lives better.

Yep, experiencing this in DR16 Studio Beta 7 on Windows 10 but it has been has been an issue in DR15 too.

Here's my little sketch from another post about this issue:

BM Beta screen edge.jpg (28.58 KiB) Viewed 26052 times

This makes it very difficult when trying to fitness positioning/cropping etc and has been the absolute worst bug trying to conform sequences with lots of photos / repos required.

This issue has developed quite a swell...

I see that Dwaine responded to another post in this forum just 20 minutes ago... but nothing on this topic.

I don't feel the love

[Dwaine Maggart]

I respond to things in my possible purview. This would seem to require some dev team love.

I resolve to love Resolve....if we can just get this little jump hump out of the equation...

I respond to things in my possible purview. This would seem to require some dev team love.

Thanks Dwaine... I'm sure you'll rattle the appropriate chains

This has infuriated me for multiple versions. I suspected it was something to do with multiple monitors because my colleague who has one large monitor doesn't claim to experience it.

This has infuriated me for multiple versions.

Welcome to the push, Mike.
They’re going to have it sorted by....B8?

This has infuriated me for multiple versions. I suspected it was something to do with multiple monitors because my colleague who has one large monitor doesn't claim to experience it.

I don't think so, because the effect also occurs with only one monitor.

I don't think so, because the effect also occurs with only one monitor.

He also uses a Wacom whereas I only use a mouse so not sure if that has anything to do with it.

This would seem to require some dev team love.

Hi,
while cutting a 4K video on a 2K timeline, I also have this problem of jumping footage while dragging the position with my mouse.
Other as the previous users over here, I am using Linux and here I just work on a bigger project with many zoom-ins and position changes within zoomed 4K footage.

Using stable version 16.0 or latest public 16.1 beta 2 makes no difference, the behavior is still the same, maybe the jump starts later than on earlier versions, but it still jumps.
In a german-speaking resolve board, all users could reproduce the same issue on various installations from 15.3 to 16.0 stable or latest beta. We found out, that not only Windows10 or Linux installations but also Mac installations show the same behaviour.
Still hoping, this will be fixed some time.

Other than this, I really love DVR, even if I just really start working with it - while leaving Adobe after 20 years!

Greetings,
Cy

I know this issue that hampers my work everyday in every part of the platform when using a mouse to “slide” a value up or down will be fixed as soon as possible.

Come on BMD... this is clearly an issue that affects a *lot* of people (including myself) and is incredibly frustrating. Can we have this fixed before you again throw in a raft of new features please? It's not that we're not thankful for the features but this is a problem that goes *WAY* back and it's almost as if we're being totally ignored.

For anyone shooting in 4K and reframing for HD, this is very frustrating.

Yes, Jim, very frustrating!
It is very frustrating when you make info booth thingies with dozens of stills that need to be arranged
in pleasant layouts that change every 6 seconds or so. That have text around them and captions. Every time you change something, it shoots out the window. It might be fun if they added a randomness generator - it could end up anywhere!
How about: your pulling a key in Fusion...you trim a value and just as it starts to look good...it jumps to an extreme value and you have to start over...
Please, please, please!

I saw it in win and linux.

Frustrating.

whew...so it's not just me, or something dumb I'm doing - always a first for everything haha

win10, wacom and mouse. but not with tangent wave.

Hey, Jeff!
There has been some speculation that Wacom might have something to do with this issue but probably, rather than wasting time speculating over what curious coding conflict might be responsible, leave it to the coding gurus at Blackmagic to improve our daily experience!

I've never used a Wacom. Just a plain wired mouse.

I still have the issue.

FWIW - I've had since first using resolve - 5 years ago. Variety of win7 and win10 machines

BMD *are* aware of it, and presumably how many customers are affected and frustrated (infuriated?) by it.

I think three versions without a fix is very strange.

Perhaps they don't know how to fix it... perhaps some legacy code for which the source was lost during the handover or which as faded through the ravages of time

Awareness is the first step to action!

BMD *are* aware of it, and presumably how many customers are affected and frustrated (infuriated?) by it.

I think three versions without a fix is very strange.

Perhaps they don't know how to fix it... perhaps some legacy code for which the source was lost during the handover or which as faded through the ravages of time

three versions?

what about three years....

Since I saw Rohit posting in this forum I thought I'd give this issue a bump and hope to see a response.

In my tests it would seem that the jump occurs at the point where the original mouse cursor would have left the monitor extents. So on a single monitor setup (which is all I have), I click into the Position X box and drag to the right the equivalent mouse distance such that my cursor would have hit the right edge of the monitor - it's at that point that it jumps. Similarly if I click and move to the left (a much greater mouse distance) when I move to the point where my cursor would have hit the left edge, the jump occurs).

If I just do successive little click, drag, release, click, drag release the jump never occurs.

Seems to be the same with the other parameters as well (rotation, zoom, anchor, etc.) - and I also see this in the Fusion page so at least it's consistent.

Is this what everyone else is seeing?

Is it possible to take legal action (BMD causing me to develop a drinking problem)? Lol

Another +1. I thought this was something to do with my dodgy multi-screen setup. But clearly not ....

A deeply frustrating thing, that jumping. Especially because I record with multiple 4K camera's and edit in 720P (as a one-man-video-band this delivers me the greatest editing space with a decent video-output).

Then you're not left with half the picture (as in the animated gif), but the whole thing disappears completely! If I correct it to eagerly it jumps again invisible to the other side.

Yes, day to day, operationally, it is probably the lowest point in the user experience. It is apparently only in Linux and Windows...I don’t know what the user base ratios are like but I get the feeling that combined, Linux and Windows is probably only 8 - 10% of the user base, that’s why it’s not a burning issue. I am burning when I am dealing with it.

Just found out that if you hold the ALT key while altering the Inspector settings, all goes slower. The jumps are still there, but far less dramatic.

Same happens on my system. Dual monitor setup. It jumps quite soon while dragging possition values. I hope this gets fixed soon! Resolve Studio 16.1

I am not sure it is dual monitors. It seems to be windows and linux.
It is clearly a big hurdle to fix. AI: easy. Numerical value mouse adjust bug: live with it...