Mouse button 3 xworkplace drag scrolling

[abwillis]

Xworkplace mouse button 3 drag scrolling does not work with eftepm but is a feature I sorely miss.

[Gregg Young]

I don't use this feature. Can you give me a better description of what you want. Thanks

[Alfredo Fernández Díaz]

When ticket #79 is gone and I am able to use the PM version for real, I'll have a look at this. Speaking of which, isn't this a PM-only feature?

I see the feature works with E (which obviously predates XWP), so it does not require applications to be XWP-aware per se, but does it work with any VIO programs?

[Alfredo Fernández Díaz]

Self-reply: yes, it is supposed to work with VIO programs as well. Just take any command prompt window, and shrink it with the mouse so the scroll bars appear ;)

Gregg, if you are reading this, XWorkPlace inserts a second "Distribution" page in the Mouse object in the System Configuration folder. There is a checkbox called "MB3 drag scrolling" which activates this feature. From XWP help:

---

If "MB3 drag scrolling" is enabled, you can scroll the contents of any window which has either vertical or horizontal scroll bars, simply by holding down mouse button 3 and dragging the mouse while mouse button 3 is down. This has the advantage that you don't have to move the mouse to the scroll bars first and is really handy once you get used to it. This should work with any PM window, theoretically.

---

I've tried to take a screenshot but can't get to capture the mouse pointer. Just try it.

Edit. FireFox, et al. implement this independently of XWP, so you have probably have seen it. I like having this ON system-wide.

[Alfredo Fernández Díaz]

Changed to eFTE_PM, not core. This works in VIO windows because those are handled by PM itself, but obviously only very special VIO programs will react to PM messages within their own window, if they are even received (I have no idea).

And turns out MB3 dragging actually works, sort of (whereas it didn't work at all in classic FTE).

'MB3 drag scroll' has two modes, basically: 'line-wise' and 'amplified'.

I guess most people have it set to the default 'line-wise', and it works on PM windows with scroll bars pretty much like Mozilla applications do. In eFTE-PM, OTOH, the cursor will go up but never down.

But if you set this to 'amplified', then eFTE-PM behaves just like all other applications do with 'line-wise'. So things are a bit more interesting than I thought ;)

I've tried to trace PM messages on mouse events but got nowhere (useful). Round 2 must be postponed until I go through the PM reference properly.

[Alfredo Fernández Díaz]

After some research and more PM message tracing I think I am pretty clear on how all of this works now, although I have been baffled at times--turns out *different*, *standard* (IBM) applications behave differently when using seemingly identical controls. I'm documenting my findings here to start working on this bug later.

Some clarifications first just in case. Terminology for parameters, etc. adopted from IBM's PM reference:

1) 'MB3 drag scrolling' (MB3DS) is a feature present in newer Mozilla and other applications, such as the XWorkPlace WPS extension, or the older HotScroll. The description in XWP reference is quoted above. Scroll on PM windows with scroll bars starts when MB3 goes down while the mouse pointer is over the window contents, and the mouse is dragged. Contents then scroll following the mouse movement just like the regular scroll bars were used. This has the advantage of not having to reach for them.

2) With XWP installed, no MB3-specific code is necessary within PM applications to enable this scrolling method, as XWP sends all the necessary PM messages when this feature is activated. This I have confirmed tracing PM messages, and should work 'theoretically' with all PM applications (but doesn't with current eFTE2-PM). It actually works with E, the old system editor that predates XWP, and many other applications -- we can be fairly sure what doesn't work in eFTE2-PM is a bug in it.

3) MB3DS can be set to work either of two ways: 'line-wise (fixed)' or 'amplified'.

3.1a) When MB3DS is in 'line-wise (fixed)' mode:

Every single time the mouse is dragged south a certain distance, TWO (2) WM_VSCROLL messages are sent sequentially. First, uscmd = SB_LINEDOWN, then uscmd = SB_ENDSCROLL with sslider value 1 both times. That second ENDSCROLL message is in consonance with MB3 being released not triggering a new message (it would be unnecessary).

OTOH Clicking the regular scrollbar bottom arrow will keep sending WM_VSCROLL messages where uscmd = SB_LINEDOWN as long as MB1 is held; releasing the arrow will send another WM_VSCROLL message with uscmd = SB_ENDSCROLL; sslider value is 0 at all times.

The only difference I have been able to spot between MB3DS and regular PM scrolling with the bar arrows seems to lie in the sslider value. Apparently SB_LINE* messages are ignored down when sslider = 1, God knows why, and this MB3DS style does not work on it.

3.1b) Scrolling upwards behaves exactly the same, replacing SB_LINEDOWN with SB_LINEUP.

3.1c) All of the above is paralleled too for WM_HSCROLL messages.

3.2) When MB3DS is in 'amplified' mode:

Dragging the mouse sends WM_xSCROLL messages where uscmd = SB_SLIDERTRACK, and sslider varies as the mouse is dragged up and down while MB3 is down.

When MB3 is released, scrolling is terminated, and a WM_VSCROLL is sent with uscmd = SB_SLIDERPOSITION and the last slider position in sslider.

As for regular, bar-based scrolling, when clicking on the slider and dragging the mouse, WM_xSCROLL generated messages have uscmd = SB_SLIDERTRACK, and sslider reflects the slider position within the bar (1 = top). When the mouse button is released, the scrolling stops and a WM_xSCROLL message is sent with uscmd = SB_SLIDERPOSITION, and the last slider position in sslider.

These are exactly the same messages that MB3DS 'amplified' mode sends, and, as one might expect, both scrolling methods work exactly the same in eFTEPM.

Now, assuming (because this is harder to test) equal controls in different applications produce the same messages, not all applications react the same way to them. For example, while dragging the scroll bar sliders in IBM's view, windows contents are updated as the slider is dragged, whereas in IBM's system editor E, window contents are not updated until the slider is released. This gives the idea that some leeway is given for application developers when implementing scroll.

MB3DS/amplified updates window contents while dragging currently, and I am happy with that so I won't touch it. TTBOMK there is also only one way for 3MBDS/line-wise to work, so I am open to anything I may have overlooked -- but I expect no surprises in that front.

[Alfredo Fernández Díaz]

Edit: long story short, I needed to re-do my research a couple times :( and promised to keep updating comment 5 as I got better info. Ah, the joys of sleep deprivation ;)

[Alfredo Fernández Díaz]

And it is fixed now, sort of :)

By that I mean that it works for me now, and I expect it to work without glitches (I wouldn't be sending my code upstream otherwise), but I would consider the current fix code as 'weak', or prone to maybe trigger unforeseen stuff in the future:

The obvious and quick solution (a shameless hack) based on my research above was to patch line-wise MB3DS PM scroll messages to make them look exactly like they come from the scroll arrow controls themselves. Lo and behold, it works now. Case closed?

This is done in g_pm.cpp, in the VM_VSCROLL/VM_HSCROLL handling blocks of code starting around line 2425. But all the code there apparently does is, set up some other (perhaps) core routines to handle the scroll. That means those must look later at some trace of the scroll messages in the PM layer (to abide by the regular ones, and actually do the scroll or not as needed, and ignore some other messages—or be defeated by my 'clever' patch). That is where proper code analysis and case handling should be done, but I just can't find the spot where it all happens :(

Andi, could you please build (or I can send you a private build) and test this? Although MB3DS is nice, I never missed it in FTE—we probably use the editors differently, so you are more likely to bump into anything else this may trigger.

If I haven't heard from you in, say two weeks, I'll close this as fixed—maybe I'll open a new ticket based on this to address the code weakness later.

[Gregg Young]

I just built this. In brief testing it works as expected. I don't see any new problems

[abwillis]

I had done the same thing as Greg had done(about the same time(, removed the MB3 references and had not thought it worked until Greg told me to change to line-wise. This code works the same for it. It does work for line-wise here now but the text is really jiggly while it scrolls and keeps jiggling even after I release and will continue to scroll if I had the mouse really pulled down.
By jiggly, I mean the text is bouncing up and down in place as it moves so that it is barely discernible. Amplified is smooth by comparison.

[Alfredo Fernández Díaz]

Scroll by dragging the slider (eq. MB3DS-amplified) should always be smoother, as long as you can drag the slider steadily, than moving the text one fixed amount at a time, then stop--as you get with M3BDS-line, arrow-based, or key-based scrolling for that matter (in principle, the three do that exact, same thing inside eFTE2). None of those is particularly "smooth" here in any application, but text always moves in the same direction. With that out of the way, are other applications/editors 'jittery' too when you use MB3DS in line-mode? E, AE, EPM?

Basically I wonder how making MB3DS messages look like regular scrollbar PM messages can make the application work differently in your system, unless there is *something else* in it... what happens if you click a scroll arrow (MB1) so the text scrolls for a while? What if you scroll using the keyboard arrows? Oh, and what about lateral scroll?

Perhaps "keeps jiggling even after I release and will continue to scroll" is the key to it -- I definitely don't see that here. Gregg?

Also, I have seen what *I* would call jittery scroll with wheeled mice which have their wheel combined onto the middle button -- this is usually because of problems with the wheel itself rather than the underlying button (and it's hard enough to push the wheel for MB3 clicks and not have it spin at all, so they, ah... suck). What kind of mouse are you using?

[Gregg Young]

In line mode I see the jiggling. It does continue for a short time after I stop scrolling. It works fine in amplified mode. Now e works fine in line mode (moves a line at a time). However amplified mode in e doesn't work as I would expect. The slider moves but the file doesn't scroll with it. When you stop scrolling the file jumps to the new location.

[Gregg Young]

Andy you should sign up for the email groups.

Send email to: efte-user-on AT 2rosenthals DOT com and reply to the confirmation email.

Send email to: efte-dev-on AT 2rosenthals DOT com and reply to the confirmation email.

Web archives of lists are available here:

​​http://lists.2rosenthals.com/efte-dev/List.html
​​http://lists.2rosenthals.com/efte-user/List.html

[Alfredo Fernández Díaz]

Yes, there's no uniform standard and E makes no scroll refresh with MB3DS/ampli until you release the slider. I mentioned that in comment 5 (first to last paragraph). IBM's View does what you expect. That's why I concluded IBM must have allowed for some leeway in actual implementation of scroll in containers.

AE behaves like E, and I would think it's the standard MLE control they use, but I have no quick way to check -- BTW NewView works like IBM's View too but I had a quick look at the sources and I think it does not use standard MLE.

[Alfredo Fernández Díaz]

Anyway, Gregg, I assume if you said 'works as expected' in comment 8 but now you see the jiggling you had it set to ampli before and switched to line-wise?

I definitely don't see the jiggling here so I think it must be some other difference between our systems. I am on MCP2 + XWP 1.0.9 here, I imagine you both have latest XWP (which is the source of MB3DS messages)? I'll check that on a toy system later, but meanwhile it would be nice to have more extensive comparisons of the effects of different scroll methods as mentioned above.

[Gregg Young]

Replying to mrwarper:

Anyway, Gregg, I assume if you said 'works as expected' in comment 8 but now you see the jiggling you had it set to ampli before and switched to line-wise?

Yes

I definitely don't see the jiggling here so I think it must be some other difference between our systems. I am on MCP2 + XWP 1.0.9 here, I imagine you both have latest XWP (which is the source of MB3DS messages)?

I am testing on ArcaOS 5.01 with the latest ANXWP version.

Increasing the minimum pixels get rid of the jiggling but makes it harder to start the drag scroll.

EPM works fine in both modes. The file scrolls smoothly with the mouse move.

I'm using a Logitech MK710 mouse. It is hard to get the drag started (often I need to press the wheel 4-5 time before it starts) This is true in all the editors/viewers. I have mapped mouse button 3 to another button but using it only works in SeaMonkey? (haven't tried Firefox) not any of the editors. I think this function is build in to the Mozilla browsers. So they don't use XWP for this.

Basically I wonder how making MB3DS messages look like regular scrollbar PM messages can make the application work differently in your system, unless there is *something else* in it... what happens if you click a scroll arrow (MB1) so the text scrolls for a while? What if you scroll using the keyboard arrows? Oh, and what about lateral scroll?

All the vertical scroll methods work fine. The text blurs slightly at speed but that is expected. The horizontal scroll using the arrow key isn't smooth. It moves in a jump after ~10 key presses.

FM2's Newview doesn't display the jiggling in line mode and the text follows the mouse in amplified mode.

[Gregg Young]

CS[190]