Or a read only field such as the PK for that table. When they land on
it, they cannot change it, but will be on the row.
Albert
On 2015-08-25 3:57 PM, Karen Tellef wrote:
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
