Hi again,
One last question and again it's about browses.
Now that Tim has sorted out the off end trigger for me (Thanks Tim), is it possible to scroll the browse as the user is using the mouse to move the scroll bar?
At themoment the browse stays where it started until the user lets go of the mouse and then it snaps to the new position. This can be quite annoying when browsing long lists for a specific item.
I have a feeling it's something to do with Scroll-notify trigger or something?
Thanks for any help!
Oliver
.. is it possible to scroll the browse as the user is using the mouse to move the scroll bar?
I think it is close to impossible to keep an ordinal row selected in the view port while scrolling with the scrollbar. There are no events fired while you scroll. The only event that is fired while you scroll through the records is the ROW-DISPLAY event. This event is intended for row coloring and highligting and nothing else. It has (very) restricted access to the browse and fires each time a row is displayed/redisplayed (not only when using the scrollbar).
At themoment the browse stays where it started until the user lets go of the mouse and then it snaps to the new position. This can be quite annoying when browsing long lists for a specific item.
It sounds as you are using the adm2 browse (?) or some other batching solution as this is not built in browse widget behavior. But even if this is not built in behavior it is actually quite difficult to change it to a less annoying behavior (assuming we are discussing batching behavior). The "correct" behavior would be to keep the currently selected position(s) (also when not visible) while scrolling (as is the default behavior). The problem with this when batching is that you need to reopen the query to show the new batch. Keeping the currently selected rows selected would thus require some repositioning, which is rather difficult if it has to be done outside the view port while keeping/showing the new batch visible at the bottom of the view port.