If the nextrow/prevrow doesn't work (I'm away so I haven't been able to test it), then a hidden field would indeed work nicely. I've done that before. Usually in the "on design action" I type form comments in there, and I explain what and where these hidden fields are. But again I would need a dummy column in my table that they can safely land on where a keystroke wouldn't change good data.
Karen -----Original Message----- From: Albert <[email protected]> To: karentellef <[email protected]> Sent: Tue, Aug 25, 2015 2:49 pm Subject: [RBASE-L] - Re: Need help with multi-tab form Razzak suggests the use of a hidden field for a purpose like this. I've read on the list here about hiding a field behind another field to avoid the problems of selecting a data field with user errors resulting. Albert On 2015-08-25 9:32 AM, Karen Tellef wrote: I can set the focus to ANY field in the Sales table, and that will cause the Payments row to be saved, the calculation made, and the table refreshed (so no need for another "on entry eep") My only issue with this is that they did NOT want me to set focus into a Sales field. They're very paranoid about their clerks making inadvertent changes so they love that clicking on a tab header doesn't put them into the data, that the user would have to then click yet again to get put into the data. They think that's safer. There are no junk unused columns in the table that I can locate on the form. So maybe I should just add a new dummy column to the table and set the focus to that field. That way the user would still have to do something to get to an actual data field. I'd have to ask them if that's acceptable. Karen -----Original Message----- From: Albert <[email protected]> To: karentellef <[email protected]> Sent: Tue, Aug 25, 2015 10:10 am Subject: [RBASE-L] - Re: Need help with multi-tab form Karen, Can you set focus on arrival in the sales table tab to the field to be updated, and then run the calculation in an on entry eep? Albert On 2015-08-25 8:32 AM, Karen Tellef wrote: My dilemna: very old (1980s) RBase database, designed by someone other than me. Not very relational in that there is a Sales table and a Payments table, but there is a column called TotalPayments in the Sales table that has a total of the payments so that a computed column Balance can be calculated. In the DOS system, there is a separate form for Payments, so on closing that form it's very easy to compute the total payments and update the Sales table before bringing the Sales form back up. In 9.5, they LOVE the idea of a form with multiple tabs, so I have Sales on tab 1, and Payments on tab 2. Here's what works: If you're in Payments, I have an "on row save" eep so that if they change the amount it sums the payments, updates the Sales table and refreshes the Sales table. So if you save the row and then click back into tab 1, viola it's there. What doesn't work: If you change a Payment amount and, while still in that row, click to tab 1, your row is not yet saved so nothing has been changed. I can see that if I then physically click into a Sales field on tab 1, it then saves my payments and does a refresh. But just clicking on the tab 1 header does not save the data. I tried putting identical code in the "on leave section" of Payments, but that does not evaluate if you click to another tab or even if you [esc] out of the form. I know I can do something like trap the payment going into the field, trap it going out of the field, and if it's different than do a "saverow", but that takes away the ability of the user to change their mind about the change. What I also tried: I can do a "change tab eep" on tab 1 so that it puts focus into a Sales field. That works cuz it forces a save. Only issue is that this client worries about people making inadvertent changes so they don't want them put "into" the data unless they click. So unless I add a "dummy" field into the table..... Any other ideas? Karen
