Loading ...
Sorry, an error occurred while loading the content.

Re: Scrolling with the mouse scroll wheel when a window is "split"

Expand Messages
  • DBaldon
    I m just now getting back to looking into this. The first thing I did was download the latest version and fixes to see if the behavior was changed. For me, it
    Message 1 of 6 , Oct 1, 2007
    • 0 Attachment
      I'm just now getting back to looking into this. The first thing I did
      was download the latest version and fixes to see if the behavior was
      changed. For me, it has not not. The same behavior I described in my
      original post still exists.

      --- In editplus@yahoogroups.com, "Michael L. Jones" <mljones1947@...>
      wrote:
      >
      > I can't reproduce the behavior you described. When I click in either
      > pane to give it focus, that pane scrolls with the mouse scroll wheel
      > no matter where the mouse pointer is located. (I am using the latest
      > beta version, so it's possible that something was fixed. BTW, a
      > release candidate is being tested, so the new version will probably be
      > out be out soon.)
      >
      > Regarding scrolling based on mouse pointer position rather than window
      > focus, I think that would violate the principle of the mouse impacting
      > the window (pane, etc.) with focus.
      >
      > There is an "X-Mouse" setting in TweakUI that emulates the X-Windows
      > standard of giving focus to the window the mouse pointer is over.
      > Maybe you should investigate that.
      >
      > Oops. I just checked it out, and the split panes in EditPlus do not
      > receive focus when under the mouse pointer. Not being an X-Windows
      > guy, I don't know if the standard is supposed to apply to split panes.
      > If it is, the problem is in the X-Windows emulation, because Excel
      > behaves the same as EditPlus.
      >
      > --- In editplus@yahoogroups.com, "DBaldon" dbaldon@ wrote:
      > >
      > > I have noticed that if I have a window split (using the splitter bar
      > > or Split command) I have to have the mouse pointer in the lower pane
      > > for the scrolling to occur in the upper pane. If the lower pane has
      > > the focus the mouse pointer can be in either the upper or lower pane
      > > and the scrolling will occur. It seems to me that the pane that has
      > > the focus should scroll regardless of the location of the mouse
      > > pointer OR the pane that the mouse pointer is over should scroll. My
      > > personal preference is the latter. I don't think you should need to
      > > change the focus for the scrolling to occur.
      > >
      >
    • DBaldon
      I m back. [;;)] This issue has come up again as I m dealing with the same issue in another program (it s author has reproduced the problem but has no
      Message 2 of 6 , May 8, 2008
      • 0 Attachment
        I'm back. [;;)]

        This issue has come up again as I'm dealing with the same issue in
        another program (it's author has reproduced the problem but has no
        resolution yet). I observed the same behavior yesterday in the Directory
        window. I have mine set so the top 1/3 is for folders and the bottom 2/3
        for files. If I single click a folder (not opening it) and then try to
        scroll the list with the mouse wheel it doesn't scroll. Now if I move
        the mouse over the pane where a file would be, the scroll wheel works.
        The same applies to the files section of the Directory window. Comparing
        that to the behavior of a document pane, it will scroll only when the
        mouse is within it's borders. This is the way I believe things should
        work. Actually I don't think you should have to click a window first
        before being able to scroll it. Just having the mouse over the window
        should cause that window to scroll. I believe this is a matter of being
        aware of which window the mouse is in and then sending the scroll events
        to that window.

        BTW, I'm now using v3.01 (446)

        --- In editplus@yahoogroups.com, "DBaldon" <dbaldon@...> wrote:
        >
        > I'm just now getting back to looking into this. The first thing I did
        > was download the latest version and fixes to see if the behavior was
        > changed. For me, it has not not. The same behavior I described in my
        > original post still exists.
        >
        > --- In editplus@yahoogroups.com, "Michael L. Jones" mljones1947@
        > wrote:
        > >
        > > I can't reproduce the behavior you described. When I click in either
        > > pane to give it focus, that pane scrolls with the mouse scroll wheel
        > > no matter where the mouse pointer is located. (I am using the latest
        > > beta version, so it's possible that something was fixed. BTW, a
        > > release candidate is being tested, so the new version will probably
        be
        > > out be out soon.)
        > >
        > > Regarding scrolling based on mouse pointer position rather than
        window
        > > focus, I think that would violate the principle of the mouse
        impacting
        > > the window (pane, etc.) with focus.
        > >
        > > There is an "X-Mouse" setting in TweakUI that emulates the X-Windows
        > > standard of giving focus to the window the mouse pointer is over.
        > > Maybe you should investigate that.
        > >
        > > Oops. I just checked it out, and the split panes in EditPlus do not
        > > receive focus when under the mouse pointer. Not being an X-Windows
        > > guy, I don't know if the standard is supposed to apply to split
        panes.
        > > If it is, the problem is in the X-Windows emulation, because Excel
        > > behaves the same as EditPlus.
        > >
        > > --- In editplus@yahoogroups.com, "DBaldon" dbaldon@ wrote:
        > > >
        > > > I have noticed that if I have a window split (using the splitter
        bar
        > > > or Split command) I have to have the mouse pointer in the lower
        pane
        > > > for the scrolling to occur in the upper pane. If the lower pane
        has
        > > > the focus the mouse pointer can be in either the upper or lower
        pane
        > > > and the scrolling will occur. It seems to me that the pane that
        has
        > > > the focus should scroll regardless of the location of the mouse
        > > > pointer OR the pane that the mouse pointer is over should scroll.
        My
        > > > personal preference is the latter. I don't think you should need
        to
        > > > change the focus for the scrolling to occur.
        > > >
        > >
        >



        [Non-text portions of this message have been removed]
      • Michael L. Jones
        Let s see if we agree on a couple of things: Pressing a key should perform some action in the window (considering lists and splits as windows) that has focus.
        Message 3 of 6 , May 8, 2008
        • 0 Attachment
          Let's see if we agree on a couple of things: Pressing a key should
          perform some action in the window (considering lists and splits as
          windows) that has focus. The scroll wheel should scroll the window
          that has focus.

          If we agree on that, then the question becomes: Can two different
          windows have focus, one for the keyboard and one for the mouse?
          Microsoft thinks that the answer is no. In Windows, the operating
          system, windows only get focus for the mouse when you click in them,
          not when the mouse moves over them.

          Open Windows Explorer with the folder list displayed and play around
          with it. It behaves exactly like EditPlus. This makes sense, since
          most Windows-specific programs use native Windows controls or
          something subclassed from them.

          Now open Firefox, display the bookmarks or history list on the left
          and play around with it. It behaves the way you prefer. (I'm
          sure that there are other examples besides Firefox, but it's what came
          to mind.) Could this be because Firefox is portable across operating
          systems and does not use native Windows controls? (Note that Internet
          Explorer behaves the same as Windows Explorer.)

          So, which is correct? I'd say that EditPlus is following the Windows
          standard, good or bad, established by Microsoft. I think that your
          complaint should be directed to Windows, not to EditPlus.

          --- In editplus@yahoogroups.com, "DBaldon" <dbaldon@...> wrote:
          >
          > I'm back. [;;)]
          >
          > This issue has come up again as I'm dealing with the same issue in
          > another program (it's author has reproduced the problem but has no
          > resolution yet). I observed the same behavior yesterday in the Directory
          > window. I have mine set so the top 1/3 is for folders and the bottom 2/3
          > for files. If I single click a folder (not opening it) and then try to
          > scroll the list with the mouse wheel it doesn't scroll. Now if I move
          > the mouse over the pane where a file would be, the scroll wheel works.
          > The same applies to the files section of the Directory window. Comparing
          > that to the behavior of a document pane, it will scroll only when the
          > mouse is within it's borders. This is the way I believe things should
          > work. Actually I don't think you should have to click a window first
          > before being able to scroll it. Just having the mouse over the window
          > should cause that window to scroll. I believe this is a matter of being
          > aware of which window the mouse is in and then sending the scroll events
          > to that window.
          >
          > BTW, I'm now using v3.01 (446)
          >
          > --- In editplus@yahoogroups.com, "DBaldon" <dbaldon@> wrote:
          > >
          > > I'm just now getting back to looking into this. The first thing I did
          > > was download the latest version and fixes to see if the behavior was
          > > changed. For me, it has not not. The same behavior I described in my
          > > original post still exists.
          > >
          > > --- In editplus@yahoogroups.com, "Michael L. Jones" mljones1947@
          > > wrote:
          > > >
          > > > I can't reproduce the behavior you described. When I click in either
          > > > pane to give it focus, that pane scrolls with the mouse scroll wheel
          > > > no matter where the mouse pointer is located. (I am using the latest
          > > > beta version, so it's possible that something was fixed. BTW, a
          > > > release candidate is being tested, so the new version will probably
          > be
          > > > out be out soon.)
          > > >
          > > > Regarding scrolling based on mouse pointer position rather than
          > window
          > > > focus, I think that would violate the principle of the mouse
          > impacting
          > > > the window (pane, etc.) with focus.
          > > >
          > > > There is an "X-Mouse" setting in TweakUI that emulates the X-Windows
          > > > standard of giving focus to the window the mouse pointer is over.
          > > > Maybe you should investigate that.
          > > >
          > > > Oops. I just checked it out, and the split panes in EditPlus do not
          > > > receive focus when under the mouse pointer. Not being an X-Windows
          > > > guy, I don't know if the standard is supposed to apply to split
          > panes.
          > > > If it is, the problem is in the X-Windows emulation, because Excel
          > > > behaves the same as EditPlus.
          > > >
          > > > --- In editplus@yahoogroups.com, "DBaldon" dbaldon@ wrote:
          > > > >
          > > > > I have noticed that if I have a window split (using the splitter
          > bar
          > > > > or Split command) I have to have the mouse pointer in the lower
          > pane
          > > > > for the scrolling to occur in the upper pane. If the lower pane
          > has
          > > > > the focus the mouse pointer can be in either the upper or lower
          > pane
          > > > > and the scrolling will occur. It seems to me that the pane that
          > has
          > > > > the focus should scroll regardless of the location of the mouse
          > > > > pointer OR the pane that the mouse pointer is over should scroll.
          > My
          > > > > personal preference is the latter. I don't think you should need
          > to
          > > > > change the focus for the scrolling to occur.
          > > > >
          > > >
          > >
          >
          >
          >
          > [Non-text portions of this message have been removed]
          >
        • Gary
          Very nice analysis of the situation, Michael. I wasn t aware of the scrollwheel behavior in Firefox and had to go try it out immediately. Very cool, I must
          Message 4 of 6 , May 9, 2008
          • 0 Attachment
            Very nice analysis of the situation, Michael.

            I wasn't aware of the scrollwheel behavior in Firefox and had to go
            try it out immediately. Very cool, I must say. That should be a
            configurable option in EditPlus. Sure it may be difficult to implement
            technically, but that's what programming is all about: jumping through
            hoops to make things as easy for the user as possible.

            This wouldn't be the first time that Firefox has set a UI standard for
            EditPlus to follow. Now, I'm not sure if I can single handedly take
            credit for this feature getting implemented, but I did request that
            EditPlus make the document selector buttons re-orderable via drag &
            drop, just like you can drag & drop the order of the tabs in Firefox.

            I was told that you can reorder the tabs in via the Window list. I
            argued back that I used EditPlus and Firefox together all the time and
            that I couldn't count how many times that I've instinctively tried to
            drag those darn things around in EditPlus. Sure enough, the feature
            showed up in v3. I'm very happy now :)



            --- In editplus@yahoogroups.com, "Michael L. Jones" <mljones1947@...>
            wrote:
            >
            > Let's see if we agree on a couple of things: Pressing a key should
            > perform some action in the window (considering lists and splits as
            > windows) that has focus. The scroll wheel should scroll the window
            > that has focus.
            >
            > If we agree on that, then the question becomes: Can two different
            > windows have focus, one for the keyboard and one for the mouse?
            > Microsoft thinks that the answer is no. In Windows, the operating
            > system, windows only get focus for the mouse when you click in them,
            > not when the mouse moves over them.
            >
            > Open Windows Explorer with the folder list displayed and play around
            > with it. It behaves exactly like EditPlus. This makes sense, since
            > most Windows-specific programs use native Windows controls or
            > something subclassed from them.
            >
            > Now open Firefox, display the bookmarks or history list on the left
            > and play around with it. It behaves the way you prefer. (I'm
            > sure that there are other examples besides Firefox, but it's what came
            > to mind.) Could this be because Firefox is portable across operating
            > systems and does not use native Windows controls? (Note that Internet
            > Explorer behaves the same as Windows Explorer.)
            >
            > So, which is correct? I'd say that EditPlus is following the Windows
            > standard, good or bad, established by Microsoft. I think that your
            > complaint should be directed to Windows, not to EditPlus.
          Your message has been successfully submitted and would be delivered to recipients shortly.