Jump to content
  • 0

Windows 6.4.2 note list scroll bar will not drag to top note and stay


aFassas

Idea

Ever since upgrading my Windows EN client to version 6.4.2.3788, I have had an issue with the following behavior, when using Note List View "top list" or "side list":

When you click and drag the note list window scroll bar up to the top, it bounces back down so that the top notes are not showing.  The scrolling in the note list works correctly if you left click on the scroll up button.  It also works if you select a note in the list and then press the "home" button.  The ability to drag the note list scroll bar to the top worked in previous versions of the windows client.

I am on a 64-bit Intel PC, MS Windows 7 Pro SP1 (64-bit) OS.  This issue is the same on both my home and work computers.  Same hardware and OS.

Link to post

41 replies to this idea

Recommended Posts

  • 0
  • Level 5*

Hi.  This has been reported before - and I can confirm the issue is still present in the current beta.  Clicking in the note list to select it and Ctrl+Home on the keyboard will jump to the top of the list,  and if you have a 'placeholder' note there which has a left-panel shortcut,  you can jump with a mouse click.

  • Like 1
Link to post
  • 0

I am aware of the other proper ways to get to the top of the Note List.  Sometimes, clicking and dragging the scroll bar is just the handiest way. 

Thank you, I was not aware that this was previously reported. 

Just wanting to give Evernote team the opportunity to not have random unplanned software behavior in their user interface.

  • Like 1
Link to post
  • 0

Another nasty bit about this dragging the scroll bar behavior; if you are dragging the scroll bar and would like to stop the view with a particular note visible, it jumps about a screen view full from where you release the mouse button on the scroll bar.  Thus, making it impossible to actually stop the scrolling (by dragging the scroll bar) at a particular note in view.  It appears that the focus of the scroll bar window is offset by slightly more than the visible screen list of notes.

Link to post
  • 0
  • Level 5*
13 minutes ago, aFassas said:

Another nasty bit about this dragging the scroll bar behavior; if you are dragging the scroll bar and would like to stop the view with a particular note visible, it jumps about a screen view full from where you release the mouse button on the scroll bar.  Thus, making it impossible to actually stop the scrolling (by dragging the scroll bar) at a particular note in view.  It appears that the focus of the scroll bar window is offset by slightly more than the visible screen list of notes.

You can always use page up and page down to navigate the list....But I agree having the scroll bar actually stop at where you are in the list would be a nice touch.

Link to post
  • 0

All the solutions that require using the keyboard to scroll instead of using the mouse and the scrollbar are throwbacks to the curses library (24x80 screens.)

If the scrollbar isn't useful, take it off and save everybody 10 pixels.

If EN actually looks/listens and wants to fix this problem properly, I suggest using some ideas from Windows <gasp> and allowing right-click in the scrollbar and being able to choose some options such as: Top, Bottom, Here, Page Up/Down, Scroll, etc. Of course it would be really fine if dragging that little scroller to the top would make the list actually scroll to the top.I know it's not just a "lag" thing since that action works just fine using the keyboard.

Link to post
  • 0

I suffer from this exact problem, and it is quite surprising (understatement) to me that a glitch of these proportions has not been escalated after all this time.  It is this type of issue and the absence of any response other than slightly absurd workarounds proposed here for a non-functioning scrollbar in lengthy and pointless discussions, even calling it a 'feature request' (lol - could not make that one up) which provokes the thought: 'Evernote in its current form and with these policies is surely doomed'.

Link to post
  • 0
  • Level 5*
2 hours ago, ballyhoo said:

I suffer from this exact problem, and it is quite surprising (understatement) to me that a glitch of these proportions has not been escalated after all this time.  It is this type of issue and the absence of any response other than slightly absurd workarounds proposed here for a non-functioning scrollbar in lengthy and pointless discussions, even calling it a 'feature request' (lol - could not make that one up) which provokes the thought: 'Evernote in its current form and with these policies is surely doomed'.

Happy Birthday to this thread - briefly active 12 months ago with nary a comment since.  The linked thread expired at about the same time,  so I'd say this hasn't been a problem for most users for nearly a year.  Also most people are up to version 6.7 or 6.9 and Evernote are pushing out a beta 6.12,  so a lot of bug fixing has gone on behind the scenes.

Link to post
  • 0

Happy birthday thread (belatedly)!  And happy birthday this to this feature, still there on a recently rebuilt Windows 10, with 6.11.2.7027 .  Time to rejoin the others, just grin and bear it - really doesn't matter, it's just a scrollbar!  Hey, think big picture, dude. :)

Link to post
  • 0
  • Level 5*
On ‎2018‎-‎04‎-‎22 at 8:56 AM, ballyhoo said:

I suffer from this exact problem, and it is quite surprising (understatement) to me that a glitch of these proportions has not been escalated after all this time.  It is this type of issue and the absence of any response other than slightly absurd workarounds proposed here for a non-functioning scrollbar in lengthy and pointless discussions, even calling it a 'feature request' (lol - could not make that one up) which provokes the thought: 'Evernote in its current form and with these policies is surely doomed'.

I agree. I usually don't post in threads like this, but keeping this bug for so long is kind of ridiculous.. Thank god for the Home button on the keyboard..

Link to post
  • 0

I updated to 6.13 and I see that "scrollable as expected" in the release notes but the behavior hasn't changed.  If you drag the scroll bar handle all the way to the top it does not scroll to the top of the list -- when you release it "jumps back" a bit further down.  Only way to get to the top fast is to use keyboard, which is kind of annoying.  

Link to post
  • 0

It's true, unfortunately.  I thought EN would test their bugfixes before announcing them fixed.  *sigh*

As an aside to @gustavgi : my home key is broken, which is why I fixate on this - I have no shortcut AFAIK and can't be troubled to map another key.  

Link to post
  • 0

Bug (not a feature!) still there after all these years.

In reply to gazumped who thinks the problem has gone away or people just don't care: It has continued to bother me but I get tired of complaining and waiting. I think others may come to this forum and see that the problem is still there and not enter their own reports.

 

Link to post
  • 0

Either I'm a little stupid and do not understand your problem or it is not seen here and it depends on a EN-Windows combination that causes the error. I'm using EN-6.13.14 on a Windows-10.0.17134.112 desktop. My scroll bar works fine in all note list formats. With mouse and|or keyboard.

But oups... If I move the scroll bar with the mouse and move the cursor app. 3 cm right or left away from the bar (during drag operation), the slider jumps to where the operation started. But this is normal Windows behaviour and can be seen in other windows also (i.e. browser and others).

Link to post
  • 0

Also Windows 10 (Version 1803 - Build 17134.165) and EN 6.13.14. I would doubt my own sanity but several others have seen this condition for many months as the prior conversation shows.

I have submitted bug reports to EN at least a year ago and they accepted my logs/etc. but there has been no fixes that I can see. 

Yes, the "But oups..." is how all scrollbars that I know of operate. If you move the mouse pointer outside of the proximity of the scrollbar it releases the scrollbar. That isn't really relevant to this discussion. Thanks for trying tho!  

Link to post
  • 0

Not that EN listens/looks/cares about these discussions (which are hosted in their domain), but could we get some type of acknowledgement?

I don't know how EN is built but frequently packages rely on DLLs which may, or may not, be first on the search list. I have a lot of application development software on my systems including various versions of Qt. Could some foreign library conflict cause a problem for some and not others (Eldorado for example)?

 

Link to post
  • 0
  • Level 5*
7 hours ago, Eldorado said:

or it is not seen here and it depends on a EN-Windows combination that causes the error.

If you have a long note list and attempt to drag the cursor to the bottom of the list the cursor will bounce back up and focus will not be at the bottom of the list.  Drag works okay for shorter lists, but not for long ones.  And hasn't for as long as I can remember.

Link to post
  • 0
  • Level 5*
9 hours ago, CalS said:

If you have a long note list and attempt to drag the cursor to the bottom of the list the cursor will bounce back up and focus will not be at the bottom of the list.  Drag works okay for shorter lists, but not for long ones.  And hasn't for as long as I can remember.

I did a quick test on this. In my tests, if you  quickly drag the scroll thumb and the mouse goes  off of the bottom of the scroll area (or off the top, for that matter) before you release the left mouse button, it bounces back to its original position. If you drag more slowly, it will stick at the end (top or bottom). It's not clear to me what the actual trigger is that causes it to bounce rather than stick when you're dragging slowly.

I'll note that what Evernote does actually appears to be pretty common behavior for Windows applications; the first several application I tried it with (Chrome, Tortoise SVN, NotePad++, BeyondCompare, even Windows File Explorer) exhibited this as well, almost identically. Visual Studio seemed to be better at it, but I could make it show the same behavior as well. Only MS Word seemed to handle this one correctly (or in the the desired way, as the correct behavior is apparently debatable), though like all of the others that I tried, it doesn't handle a similar scenario: if you quickly drag the scroll thumb and the mouse goes off of the side of the scroll area and you then release the mouse button, the scroll thumb will bounce back to its original position.

The speed of the drag does seem to make a difference in whether the scroll thumb bounces or sticks to the end. Not sure why that is; somewhere in the MouseMove, LeftButtonDown. and MouseLeave handling, there's something else happening that depends on drag speed.

Not sure that is is an argument for or against here, just reporting on how other applications appear to handle the same scenario.

Link to post
  • 0

Jefito - this is "normal" behavior for scrollbars in general, whether EN/other apps, Windows/Linux/etc. When the mouse leaves the vicinity of the scrollbar (#pixels TBD), whether off the top/bottom/left/right, the scrollbar logic is disengaged and whatever positioning has been performed is reverted.

What most of us are talking about is dragging, slowly or quickly, the bar to the top or the bottom - not letting the cursor leave the scrollbar vicinity. When most of us that have complained do this, the scrollbar follows the cursor to the top or bottom and then when the mouse button is released it snaps back to some position less than the top or bottom. In a 8,000 item notes list, it might take me back to a position 400-600 notes away from the top/bottom. If I am bored, I can keep dragging the bar back to the top with a subsequent snap-back; repeating this will get me within visible range of the top or bottom.

The slowness or quickness of the drag does not seem to matter much. Of course if you are quickly dragging you might leave the scrollbar activation area and cause the position to revert as mentioned in the first para.

 

Link to post
  • 0

Now I can see the problem with a list of more than 4k notes :-)

But in my case the slider does not bounce back to the original position. If I release the mouse button at the upper or lower end it bounces back only some lines. So the first (or last) notes cannot be seen.

If I start the drag operation nearly at the end and release it at the end, the bounce-back amount is  lower than if I start at the middle of the list. It seems that the amount depends on the count of lines that have to be scrolled until the end. After the third or fourth try, I can reach the real end of the list...

Maybe the screen resolution has any impact? I've 3.440x1.440 pixels on my screen...

And: for me EN is the only application that shows this effekt. Chrome, NotePad++ and VS work correct. 

Link to post
  • 0

Eldorado - thanks for following up on this.

I've had this problem on 1024x768, 1920x1200, and 3840x2160. Don't think resolution is the issue.

Yes, as far as I know in 20 years of using windowed apps with scrollbars, EN is the only app that has this difficulty. Must be a home-grown windowing system.

Link to post
  • 0
  • Level 5*
18 minutes ago, Eldorado said:

Now I can see the problem with a list of more than 4k notes ?

But in my case the slider does not bounce back to the original position. If I release the mouse button at the upper or lower end it bounces back only some lines. So the first (or last) notes cannot be seen.

If I start the drag operation nearly at the end and release it at the end, the bounce-back amount is  lower than if I start at the middle of the list. It seems that the amount depends on the count of lines that have to be scrolled until the end. After the third or fourth try, I can reach the real end of the list...

Maybe the screen resolution has any impact? I've 3.440x1.440 pixels on my screen...

And: for me EN is the only application that shows this effekt. Chrome, NotePad++ and VS work correct. 

Yup, any drag in a long list of notes in EN jumps at the end of the drag in the opposite direction of the drag, no matter how sloooow the drag.  Clueless as to resolution impact,  I have 1920x1080.  Workarounds I use anymore are the Home/End keys and created/updated searches to get someplace in the middle.  

Side note, I use MediaMonkey for my music and I have more songs than notes.   MM works as expected, drag the slider to the bottom and focus is at the bottom not somewhere lower than where I started the drag.  A 3000 folder list in File Explorer drags to the bottom, no bounce back.  Seems to only be EN for me.  FWIW.

Link to post
  • 0
  • Level 5*

Sorry folks, just reporting what I'm seeing. I even switched to Top list view (? @CalS) to test the original scenario, though it seemed to behave much the same as snippet view (my usual). I can draw the scroll thumb to any location without bounce in a long list (2400+ notes in my work case; maybe I'll try it at home where I have more notes), and it works fine. This is version 6.13.14, btw. Nothing special about my system  Maybe I'm missing something (wouldn't be the first time), and I'm not sure why I'm getting different results from other users, but I certainly see the same (or very similar) behavior in other applications. *shrug* 

 

Link to post
  • 0

Hi, Jefito - it sounds like you have two separate accounts with EN since your Notes lists aren't the same. Could one of them be Enterprise and therefore have different characteristics?

I don't want to belabor this unless others think it is important.  Thanks --- ripwit

Link to post
  • 0

http://youtu.be/C9OSc4FcYpo?hd=1  is a short demo - saves all the chatter.

didn't mean to leave the sound on.  you might want to mute it.

I'd say in my experience, this is unique to EN.

"and that's all I got to say about that" - Forrest Gump

Link to post
  • 0
  • Level 5*
1 hour ago, ripwit said:

Hi, Jefito - it sounds like you have two separate accounts with EN since your Notes lists aren't the same. Could one of them be Enterprise and therefore have different characteristics?

Two separate accounts, one premium, and one basic (which I used in testing above), with notebooks shared both ways across. Same client, and very unlikely that their behaviors would differ based on subscription level (though stranger things have happened).

7 minutes ago, ballyhoo said:

http://youtu.be/C9OSc4FcYpo?hd=1  is a short demo - saves all the chatter.

didn't mean to leave the sound on.  you might want to mute it.

I'd say in my experience, this is unique to EN.

"and that's all I got to say about that" - Forrest Gump

As I say, I'm not seeing any of that, but with ~2400 notes (all I have here). Will try later on with more when I get home. I pull the scroll thumb to the top, it stays at the top of the scroll area, no bounce. Pull it to the bottom, it stays on the bottom. Except if I pull too quickly, in which case there's some mouse distance/limit that bounces it back to its starting point, but we know that that's a special case.

Link to post
  • 0
  • Level 5*
2 hours ago, jefito said:

I even switched to Top list view

Finally coming over from the dark side!  ?

Who knows what the differences in systems might be, but this drag issue.  I did some created searches for a test, only took a few minutes.  The results are repeatable.  YMMV but it looks like a list of 3500 notes or so has the issue.  My system anyway.

  • 38220 notes fails
  • 7251 notes fails
  • 5173 notes fails
  • 4073 notes fails
  • 3717 notes fails
  • 3510 notes fails
  • 3305 notes works
  • 3119 notes works
  • 2926 notes works
  • 2550 notes works
Link to post
  • 0
  • Level 5*
3 minutes ago, CalS said:

Finally coming over from the dark side!  ?

Haha, this is not a case of "Once you go Top, you'll never want to stop". I switched back almost immediately. I'm not saying that Top List doesn't have its uses, but for me, Snippet view is much more often useful for my day to day.

The list size thing certainly seems suspicious, though...

Link to post
  • 0

Thanks for that good set of tests!

I can't reliably duplicate it using my various notebook sizes. Some seem to work with around 3,000 entries and others don't.

I've actually starting to see another behavior I hadn't noticed before. When I have explicitly positioned the Notes list cursor at a particular note (mid-list) and then tried to drag the scrollbar up or down from there, it looks like there is the same lag.

If this is local/off-site caching issues it could be part of it but it sounds more serious.

 

Link to post
  • 0
  • Level 5*
3 minutes ago, jefito said:

Haha, this is not a case of "Once you go Top, you'll never want to stop". I switched back almost immediately. I'm not saying that Top List doesn't have its uses, but for me, Snippet view is much more often useful for my day to day.

The list size thing certainly seems suspicious, though...

For clarity, it's side list view that is the preferred view in my household. 

Link to post
  • 0

Thanks, CalS. I have long used the Top List view and it appears that the Snippet view might not see this problem.

Being too anal(yst) for my own good, I now wonder if the Snippet doesn't pull more info from the servers and is therefore able to keep the lists in synch.

Link to post
  • 0
  • Level 5*
13 minutes ago, ripwit said:

Thanks, CalS. I have long used the Top List view and it appears that the Snippet view might not see this problem.

Being too anal(yst) for my own good, I now wonder if the Snippet doesn't pull more info from the servers and is therefore able to keep the lists in synch.

I switched to Snippet for a second and the drag does work as expected.  Drag to the bottom and the focus sticks.  A plus for Snippet until the bug gets fixed in Side list I suppose.

Link to post
  • 0
  • Level 5*

OK, back home. Tested with ~3400 notes and higher (up to 7000). All of these exhibited the bad bounce. That would be enough for me to go on, if I were tasked with looking into it.

Some nice detective work going on here. :) 

  • Like 1
Link to post
  • 0
  • Level 5*
1 hour ago, ballyhoo said:

Is this fixed now...  for real?  Cannot believe it!  Scrollbar seems to work! This is too good to be true!! 

2.5 years have just flashed by.

?? and you're still using the same version of Evernote ??

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...