Odd icon (text?) positioning in filer (and !Paint I think)

I have noticed that sometimes when resizing (I think) filer windows, the icons shift over to the left, still visible, but without the usual left margin. I think I saw a similar behaviour in !Paint, although I could have been mistaken. Sorry to be vague about this. It has happened on a number of occasions, but I haven’t narrowed it down to a repeatable situation. When it occurs, it is irksome because the filer is really the main “UI” of RISC OS and is usually so good!

I’ve never seen this … what version of the filer are you using and are you using any 3rd party patches? (eg QFiler)

No plugins, and it has been the case for a number of builds AFAIK. Possibly because I’m running at 1920×1080 or 1680×1050 in the omap build. I’ll try and get a screenshot or something. Had hoped others had seen it.

Ah, repeated, and tracked it down. It’s daft, but could still be classified as a bug.

Basically, the problem stems from me using a top end Logitech mouse with fancy scroll wheel. Not only does it scroll up and down (which works fine in the filer), but it (the wheel) also clicks right and left to horizontally scroll. When trying to click the wheel for a “menu” click, sometimes I’m applying diagonal pressure and resulting in a horizontal scroll. The filer responds by moving the window contents left and right, as if scrolling left and right.

Where the “bug” comes in, of course, is that the filer shouldn’t be horizontally scrollable, because the contents auto-format to the current width. But the bounding box is no doubt huge, in order to facilitate the drag-resizing necessary as part of this design.

I’m not really sure how one would go about fixing this, except intercepting these horizontal scroll requests and realizing they don’t make sense in the context of the filer.

I’d welcome thoughts, but I understand if this doesn’t really register on the roadmap, as it is at best an “oddity” rather than a hardcode “bug”.

I’m not really sure how one would go about fixing this, except intercepting these horizontal scroll requests and realizing they don’t make sense in the context of the filer.

I don’t think this would be difficult to fix, but you may be heading in the wrong direction here. If you meant intercepting Scroll_Request (PRM3-89), this probably wouldn’t work as the user you describe is using a wheel-device, not clicking on an arrow or scroll bar.

What I believe would need to happen is for the Filer to manually zeroise the horizontal scroll value before all calls to Wimp_OpenWindow (there can’t be that many). This would have the effect you describe, with minimal coding effort.

For what it is worth an Apple USB Mighty Mouse plugged into an ARMini showed the effect very readily.

Surely this is a fault in the wheel-mouse code. It can’t be solved just by altering the Filer. Any number of apps may have windows with a work area larger than the visible extent and no horizontal scroll bar. The wheel mouse driver (whatever software that is) should be paying attention to whether the window has scroll bars before sending the scroll requests.