Changes between Version 1 and Version 2 of Ticket #76, comment 5


Ignore:
Timestamp:
Dec 24, 2017, 10:42:51 AM (6 years ago)
Author:
Alfredo Fernández Díaz
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #76, comment 5

    v1 v2  
    1 After some research and more PM message tracing I think I am pretty clear on how all of this works; I'll be documenting it here to start working later. First some clarifications just in case. Terminology for parameters, etc. adopted from IBM's PM reference:
     1After 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.
    22
    3 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 on the window interior, and the mouse is dragged. Content then scrolls following the mouse movement just like the regular scroll bars were used. This has the advantage of not having to reach for them.
     3Some clarifications first just in case. Terminology for parameters, etc. adopted from IBM's PM reference:
    44
    5 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 actually works with E, the old system editor that predates XWP, and should work 'in theory' with all PM applications (but doesn't with current eFTE2-PM).
     51) '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.
    66
    7 3.1a When MB3DS is in 'line-wise (fixed)' mode:
     72) 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.
    88
    9 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 sslide value 1 both times. That second ENDSCROLL message is in consonance with MB3 being released not triggering a new message (it would be unnecessary).
     93) MB3DS can be set to work either of two ways: 'line-wise (fixed)' or 'amplified'.
    1010
    11 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.
     113.1a) When MB3DS is in 'line-wise (fixed)' mode:
    1212
    13 Thus the difference between MB3DS and regular PM scrolling with arrows seems to lie in the sslide value. Apparently SB_LINE* messages are ignored by eFTE code when sslider = 0, and this MB3DS style does not work on it.
     13Every 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).
    1414
    15 3.1b Scrolling upwards behaves exactly the same, replacing SB_LINEDOWN with SB_LINEUP.
     15OTOH 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.
    1616
    17 3.1c All of the above is paralleled too for WM_HSCROLL messages.
     17The 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.
     18
     193.1b) Scrolling upwards behaves exactly the same, replacing SB_LINEDOWN with SB_LINEUP.
     20
     213.1c) All of the above is paralleled too for WM_HSCROLL messages.
    1822
    19233.2) When MB3DS is in 'amplified' mode:
    2024
    21 Dragging the mouse sends WM_VSCROLL messages where uscmd = SB_SLIDERTRACK, and sslider varies as the mouse is dragged up and down while MB3 is down.
     25Dragging 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.
    2226
    2327When MB3 is released, scrolling is terminated, and a WM_VSCROLL is sent with uscmd = SB_SLIDERPOSITION and the last slider position in sslider.
    2428
    25 As for bar-based scrolling, when clicking on the slider and dragging the mouse, WM_VSCROLL generated messages have usmd = 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_VSCROLL message is sent with ucmd = SB_SLIDERPOSITION, and the last slider position in sslider.
     29As 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.
    2630
    2731These are exactly the same messages that MB3DS 'amplified' mode sends, and, as one might expect, both scrolling methods work exactly the same in eFTEPM.
    28 ----
    29 So, in principle, "all that's left to do" :) is accommodate these not-so-special PM messages in the WM_VSCROLL handling block of g_pm.cpp, starting ca. line 1410 and make eFTE2 react to them with the corresponding evCommand / cmVScrollMove, etc. Specific MB3 code (it seems there is currently some, commented out) can be left for the future, if any specific use for it is found.
     32
     33Now, 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.
     34
     35MB3DS/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.