[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changes in frame/window code
From: |
Eli Zaretskii |
Subject: |
Re: Changes in frame/window code |
Date: |
Tue, 19 Aug 2014 18:15:58 +0300 |
> Date: Mon, 18 Aug 2014 19:22:46 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
>
> > Date: Mon, 18 Aug 2014 18:11:19 +0200
> > From: martin rudalics <address@hidden>
> > CC: address@hidden
> >
> > > but it's still unclear to me why this problem is not visible
> > > in L2R buffers.
> >
> > Because for L2R I count the part from the leftmost position to the start
> > of the scroll bar thumb which is unaffected by the size of the thumb?
No, that wasn't it, see below.
> > > . The erratic behavior seems to be due to our own code resetting the
> > > thumb position right after I drag the thumb to some new position.
> > > The code which causes this seems to be -- surprise, surprise --
> > > set_horizontal_scroll_bar that calls
> > > set_horizontal_scroll_bar_hook passing it the previous position.
> > > I didn't yet figure out why this affects only R2L lines.
> >
> > You mean that w->hscroll has its previous value in
> >
> > start = w->hscroll * FRAME_COLUMN_WIDTH (WINDOW_XFRAME (w));
> >
> > in xdisp.c although w->hscroll was in between changed by
> > `scroll-bar-horizontal-drag-1'?
>
> I didn't analyze this further, but it should be easy to verify.
I found the reason for this: w32_horizontal_scroll_bar_handle_click
reported bogus (always -1) values in the Y part of '(X . Y)' member of
the click event, when I drag the thumb. That value is not used in L2R
paragraphs, so L2R buffers were not affected.
This is now fixed in trunk r117715.
Btw, I don't understand why in w32_horizontal_scroll_bar_handle_click
you overwrite the value reported from GetScrollInfo by
HIWORD(msg->msg.wParam). My reading of MSDN documentation is that
they recommend to do it the other way around, since GetScrollInfo is
not limited to 16-bit values. If using the values reported by
GetScrollInfo doesn't work well, perhaps that's because for
SB_THUMBTRACK message you need to use SIF_TRACKPOS and si.nTrackPos
rather than SIF_POS and si.nPos.
- Re: Changes in frame/window code, (continued)
- Re: Changes in frame/window code, martin rudalics, 2014/08/16
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/16
- Re: Changes in frame/window code, martin rudalics, 2014/08/16
- Re: Changes in frame/window code, martin rudalics, 2014/08/16
- Re: Changes in frame/window code, martin rudalics, 2014/08/16
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/17
- Re: Changes in frame/window code, martin rudalics, 2014/08/18
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/18
- Re: Changes in frame/window code, martin rudalics, 2014/08/18
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/18
- Re: Changes in frame/window code,
Eli Zaretskii <=
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/20
- Re: Changes in frame/window code, martin rudalics, 2014/08/20
- Re: Changes in frame/window code, martin rudalics, 2014/08/20
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/20
- Re: Changes in frame/window code, martin rudalics, 2014/08/28
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/28
- Re: Changes in frame/window code, martin rudalics, 2014/08/28
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/28
- Re: Changes in frame/window code, martin rudalics, 2014/08/29
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/29