<< Larry: Wow, I am clueless how you could get that to work when use a scrolling region or even f8/f7 to move through the scrolling region! How can you possibly know which numbered row is the top one?? >>
The trick is to run code from a stored procedure in the variable list (that, define a variable = (CALL SetButtons(NumberColumn)) where SetButtons is a stored procedure that you write. Because R:Base evaluates the variable list for every row in the form every time you change records you can use the stored procedure to figure out the number (from NumberColumn) for the top row in the region. Once you know that, it's pretty easy to query the database rows that correspond to each row in the region (and therefore correspond to one of the floating buttons). The code in the stored procedure is a little tricky because R:Base evaluates the rows in it's own order, not top to bottom. But the whole thing takes about 15 lines of code. << I doubt the users ever resize the form. >> Resizing the *form* is okay, as long as you don't anchor the region to the top *and* bottom (in which case, the row height of the region will change and you'd have to move the buttons around). Stretching the region horizontally is okay, you can anchor the button to the right of the form if necessary and it will move accordingly. I never anchor regions top and bottom because I don't like the effect of resizing (it makes the rows bigger and smaller instead of adding more rows at the same height, like a grid). But I imagine you could even handle a vertical region resize by including code in the form's OnResize event. << I could probably add a column to the table that could be dynamically numbered starting with #1. What would happen if within the form the user wants to delete or add rows (both of which I allow)? >> This would be tricky. Delete would not be too hard, but you'd have to renumber the rows right after deleting. Adding rows would be trickier, because I think that the row will initially appear in the control at the end or above or below the focused row when you hit DUPROW. You'd probably have to open and close the table to get it to appear in it's sorted location, which is important for this system to work. Or perhaps you could figure out where it's going to "appear" on the screen and then number it correctly for that location. (If you can figure out how ONLY allow the users to ADD rows at the end of the region this problem becomes easier). I'm pretty sure both of these could be handled -- if by no other expedient then by closing and reopening the form when rows are added or deleted. -- Larry
