That was one of the first things I tried, Mike! But nope, if you go into the variable edit, it does not trigger the "save row" of the previous table. Has to land into a database edit of another table.
Karen -----Original Message----- From: MikeB <[email protected]> To: karentellef <[email protected]> Sent: Tue, Aug 25, 2015 5:51 pm Subject: [RBASE-L] - Re: Need help with multi-tab form . 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. Wouldn't you use a variable edit field instead? > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Karen > Tellef > Sent: Tuesday, August 25, 2015 5:57 PM > To: [email protected] > Subject: [RBASE-L] - Re: Need help with multi-tab form > > 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 > > 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]> > <mailto:[email protected]> > To: karentellef <[email protected]> <mailto:[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 > > > >
