I have asked the client to look at the easy solution I did (displaying the clickable variable label), and told him that with more work I could possibly show buttons. I'll let you know how they respond.
In your first paragraph of the response, you said "from a stored procedure in the variable list". This is not a variable list, and I don't really want to convert it to one because then I would have to define a separate edit form for each row. You mention "region" in the rest of your email so I assume that was just an error? I can understand RBase knowing the top row in a variable list, but not so much the top row in a scrolling region. Karen In a message dated 9/16/2011 7:50:40 AM Central Daylight Time, [email protected] writes: > << > 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 > > > > > >
