But it does give you that safe ground I referred to before to do whatever you want at that point in time. Test for conditions in the "onEntry EEP"and then react further based on the conditions..
There is where you could use Steven's NEXTTAB PREVTAB NEXTROW PREVROW or whatever... > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Karen > Tellef > Sent: Wednesday, August 26, 2015 9:10 AM > To: [email protected] > Subject: [RBASE-L] - Re: Need help with multi-tab form > > 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] <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] <mailto:[email protected]?> > > > To: karentellef <[email protected]> > <mailto:[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 > > > > > > > > > >
