Post embedded brouse to parent form

[Debbie Keller]

Parent form with embedded brouse of the child database (one to many). After entering a record to the child database I want to have an action that will question if field-Action="Replacement" if yes then Take field-Date and change the parent form field-ReplacedLast to the Child field-Date, if not then don't do anything.
I'm not sure if I can do this at all because I'm using an embedded brouse. I have tried to do it with variables but I haven't gotten anywhere with that. I only end up with the date in the variable I don't know how to write it to the parent database and save it.
I hope someone can point me into the write direction.
Thanks.

[BRochford]

RE: Post embedded brouse to parent form

Debbie, remember of course that you have a child table, not a database - took me almost a year to start calling them tables. Looks like you should investigate the record events for your child table. If you have the 2nd edition of Xbasic for everyone, look at Chap. 12, it gives a good example of the CanSave Record event. I think you could do your checking in that event.

-Barry

[martinwcole]

RE: Post embedded brouse to parent form

also, at the browses "canrowchange" event, you can do something like this:

t=table.current(2) 'parent is 1, current(2) is the first child
if t.date1 > parentform:date1.value
parentform:date1.value=t.date1
end if

i'm fairly sure the canrowchange also handles the ondepart event for the browse. in other words, if they change the date1 value and then click back on the parent without changing rows in the browse, the script will fire anyway

[Tom Cone Jr]

RE: Post embedded brouse to parent form

Debbie,

Here's an example for you to play with, tear apart, and modify.

Unzip it to a separate folder. Do not mix it with your development work.

Open the Customers2 form. You'll find a simple form based on a two table set, consisting of Customers (the parent) and Transactions (the child). If you enter a new transaction record, and the Trans_Type field is "replacement", then the Trans_Date value from the same child table record is written to the Last_Replaced field in the Customers Table.

This is not a perfect solution, because you probably don't want the user to be able to change the Last_replaced value in Customers, if they go back and reclassify an earlier transaction, making it "Replacement" when it was originally something else. But perhaps it will give you some ideas about how to approach the problem.

My solution built on ideas from both Martin and Bill.

I used the OnSaveRecord event in the Transactions table to do the update to the Customers table.

I used the OnRowChange event in the Browse1 object on the form to refresh the displayed value of the Last_Replaced field in Customers table.

Hope this helps.

-- tom

[Tom Cone Jr]

RE: Post embedded brouse to parent form

Martin, I tried this approach and found that it updated the value in the parent record as I stepped through the child table record by record. This happened whether I was going forward or backward through the child table. I think she needs a solution which will trigger the updates only when she is entering a new child record, or possibly when she is changing a child record.

[Tom Cone Jr]

RE: Post embedded brouse to parent form

Martin, I'm sorry, let me clarify. I modified your suggestion, so that it did an update to the parent table whenever the transaction type was 'Replacement'. since this is what Debbie was looking for. Since I abandoned your idea of comparing the dates, and updating only if the current transaction date is more recent than the parent table value, I began to have too many updates occurring as I stepped through the table. As written, your approach will not automatically change all parent table records... it will happen whenever the current transaction date is more recent than the value stored in the parent table. -- tom

[martinwcole]

RE: Post embedded brouse to parent form

yes - I see what you mean. I read the question too quickly. I haven't looked at your solution yet, but if I were adding the record to the child table in the browse itself, (which I rarely do,) I think I would go to field rules, and possibly at the cansaverecord event for the child table, I might say

if is_object(":myform")
..t=table.get("childname")
..if t.action="Replacement"
....if t.datefield > :myform:formdate.value
......:myform:formdate.value=t.datefield
....end if
..end if
end if

[martinwcole]

RE: Post embedded brouse to parent form

Tom - I like your idea. However, if you test for the for the entry being made in that form, then you can use that child on another form, for some other reason, and the rule will not fire. Also you don't have to open a second instance of the parent. Since the change to the parent is made as a form:field.value - the current state of the parent is irrelevant (mode=0,1,2) and the form is immediately refreshed. Don't be afraid of addressing specific forms in the rules.

said the student to his mentor, smiling.

[Tom Cone Jr]

RE: Post embedded brouse to parent form

Martin, I see what you mean, and will study it more closely this weekend. You're writing changes to the table through the form. I'm writing changes to the table beneath the form. Do you suppose it's a hang over from my DOS coding days, where all changes *had* to be written to the table, and there was no such thing as a form? As I climb on to the psychologist's couch and make myself comfortable, I begin to wonder if, deep down, I don't truly trust Windows' form level objects?
(Or maybe it's just a plain old fashioned hangover, that's influencing my thinking this AM?)

-- tom

[martinwcole]

RE: Post embedded brouse to parent form

Well, I'm just glad, that after 2 1/2 years of you mentoring me, at least 333 times, I may have caught you once.

As you know, I came straight from 6.22 to A5 and windows - whew, what a transition! I have gradually used more and more of Alpha's features, each time scared of them.

A little distrust can be a good thing!

So far, I have not found anything that doesn't work in Alpha, once I learned it - with one very irritating exception: (DLL's) certain printer drivers, and perhaps video drivers, can cause Alpha to crash. Because I have my app on 11 computers, besides my own, it can be very frustrating. But, as luck would have it, the "computer from hell" is at a branch office only about 4 blocks from my house. So I go over there late at night, and work on it till it works on that computer. So far, if it works on that computer, it will work on any computer.

Anyway - thank's for all your help.