One of the things you can easily do in ARev is read an @RECORD from an alternate source. For example, if you want to convert an order into an invoice, you can read @RECORD from the ORDERS table, even though your window is associated with the INVOICES table. You can then save the record to the INVOICES table. Simple.

In OI, as is often discussed here, not so simple. I am looking for a simple way, given an @RECORD, to stuff it into a form. (e.g., as above, read it from the orders table into an invoice form).

I have found one technique, and I am wondering if anyone has any comments. Having learned earlier how to change the table association of a form at runtime (e.g. so that I can use the same form for both orders and invoices), I realized that the same technique could be used to have the form read @RECORD from one table into a form associated with another.

Say I have an INVOICE form, associated with the INVOICES table, and I want to stuff it with an @RECORD from the ORDERS table. I can do this

in the read event:

/*this snippet tells the form to use a different control as the source of the @ID, and to read from an alternate table */

WinID=@WINDOW

$Insert Oiwin_Comm_Init

JoinMap@=CUSTOMER_ORDERS'

CtrlList=Get_Property(@window, "CTRLMAP")

keyCtrl=@WINDOW:".ORDER_NO"

origKeyCtrl=@WINDOW:".INVOICE_NO"

invoiceID=Get_Property(origKeyCtrl,'DEFPROP')

Swap origKeyCtrl With keyCtrl in JoinMap@; * I think this is in JoinMap@–not sure what this does

Locate keyCtrl in CtrlList Using @FM Setting keyPos Then

 ctrlType=Get_Property(keyCtrl,"TYPE")

 KeyMap@=keyCtrl:@VM:ctrlType:@VM:keyPos

End

null=Set_Property(keyCtrl,'DEFPROP',orderID)

Forward_Event()

*at this point, @RECORD was read from the ORDERS table, and @ID is the order ID

/*this snippet sets everything back to normal*/

JoinMap@=CUSTOMER_INVOICES'

CtrlList=Get_Property(@window, "CTRLMAP")

keyCtrl=@WINDOW:".INVOICE_NO_FIX"

origKeyCtrl=@WINDOW:".ORDER_NO_FIX"

origID=Get_Property(origKeyCtrl,'DEFPROP')

Swap origKeyCtrl With keyCtrl in JoinMap@

Locate keyCtrl in CtrlList Using @FM Setting keyPos Then

 ctrlType=Get_Property(keyCtrl,"TYPE")

 KeyMap@=keyCtrl:@VM:ctrlType:@VM:keyPos

End

null=Set_Property(keyCtrl,'DEFPROP',invoiceID)

When you are done, you have read @RECORD from ORDERS,ORDER_ID, but

you are ready to save @RECORD to INVOICES, INVOICE_ID.

I haven't played with this enough yet to know of any dangers, aside from the fact that this seems to leave both the order record and the invoice record locked. Any comments, suggestions, or words of wisdom would be appreciated.

Thanks,

David

David,

One of the things you can easily do in ARev is read an @RECORD from an alternate source. For example, if you want to convert an order into an invoice, you can read @RECORD from the ORDERS table, even though your window is associated with the INVOICES table. You can then save the record to the INVOICES table. Simple.

Arev is a long time since for me, and I never knew it too well. But I'd probably agree with you that @Record was much better then. In OI I tend to avoid @Record as much as possible.

You seem to say you can slap an ORDERS record on an INVOICES record and the fields fit. So I assume your two tables have identical field structures up to a certain point. Or perhaps you've simplified the description of what you'd like to do with your @Record.

Can you make do with the following?:

- (1) Read the record from ORDERS with a plain read into a plain variable

- (2) Write the record to INVOICES with a plain write from that plain variable

- (3) Stuff the key control with the key

- (4) Send a READ to the window to get the record read.

Or is (2) too early to write the record to INVOICES?

If this is unacceptable… …hmm…

I've not thought deep and long about this, but some of the following is what I've done in similar situations:

- (1) Have something that knows the field structure of ORDERS records

- (2) Read the record from ORDERS with a plain read into a plain variable OrdersRecord

- (3) Establish info on the INVOICES windows' controls and fields - which controls are bound to which fields, etc

- (4) Stuff each OrdersRecord into the proper field of the INVOICES window. (1) This can be a procedure that looks up DICT.ORDERS, or an insert, created by such a procedure some time earlier. (3) I get the relevant data from CTRLMAP, and the COLUMN, POS and TYPE properties of all the controls. I establish data on both data fields and symbolics. (I stuff the data into a dynamic common, so I don't have to do it more than once per session.) (4) Phase 1: Stuff data fields. Phase 2: Send CALCULATE to each of the symbolics. I can supply you with code for (3) and (4), but it's often easier to write one's own. - Oystein - </QUOTE> —- === At 11 JUN 2002 09:56AM David Kafka wrote: === <QUOTE>You seem to say you can slap an ORDERS record on an INVOICES record and the fields fit. So I assume your two tables have identical field structures up to a certain point. Or perhaps you've simplified the description of what you'd like to do with your @Record. ]] ]]Can you make do with the following?: ]]- (1) Read the record from ORDERS with a plain read into a plain variable ]]- (2) Write the record to INVOICES with a plain write from that plain variable ]]- (3) Stuff the key control with the key ]]- (4) Send a READ to the window to get the record read. ]]Or is (2) too early to write the record to INVOICES? « Oystein, In this case, I am using the term "@RECORD" losely to mean "the record as read from or written to the table." For purposes of this discussion, we can just call it "RECORD." You are correct, the data structures of the two tables are almost identical. As a last resort, I toyed with the idea of reading the record from the orders table, writing it to the invoices table, and then reading it back, but that seems inelegant to me. I am thinking in ARev terms not just because of my long history as an ARev developer, but also because I am converting an ARev app, and also, because ARev has some wonderful capabilities that I refuse to give up without a fight. My ARev app is full of places where a record is "stuffed" into a form rather than simply read from a table. Users have the option of basing a sales order on a previous sales order, a previous invoice, a previous purchase order, or a blanket order, for example (and vice versa). The bill-of-materials system moves bills-of-material (actually production formulas/recipes) into a work order file. The work order system moves completed work orders into a completed file. In each case, the user has the opportunity to modify the information before saving it. The order/invoice form I am working with has about 50 data-bound controls, including an edittable with 18 columns. I would prefer not to have to address each control individually just to load the form, if I can avoid it. At first glance, the technique I am trying now, which "fools" the read event into reading from one table/id, but then switches tables/id's so that the write event writes to a different table/id seems to work in principal, and can be extended to most of my other requirements, I think. There are definitely issues with locking, which I will need to explore; the fact that the form leaves both records locked tells me that I don't have all the bases covered yet. I was wondering 3 things: 1. If anyone else has tried this approach, and if so, do they have any pointers. 2. Does anyone have a similar all-in-one solution (as opposed to a roll-your-own solution. (I hope the American idiom is OK?) 3. Any chance the RevSoft could expose the read/write code associated with forms, since that code obviously has to do these functions. David </QUOTE> —- === At 11 JUN 2002 11:22AM Don Miller - C3 Inc. wrote: === <QUOTE>David, I have an almost identical AREV app .. E.g., we take a customer sales order and turn it into one or more invoices (in the case of partial ships or blanket orders). The two files are identical except for the MV's that deal with ships, tax, total, ship-to address, etc. In converting the app to OI, I did the "ugly" rather than having to re-write a lot of processing code: 1. When invoice created, I check for a new record. If existing, then the logic is different. New record, OPEN "SALESORDERS" TO ORDFILE THEN .. LOCK THE ORDER .. READ ORDER RECORD .. GET THE NEXT AVAILABLE INVOICE # AND CHECK TO SEE IF VALID. OPEN "INVOICE" TO INVOICE THEN .. CHECK VALID. IF SO, THEN WRITE THE STATE OF THE ORDER AT THIS POINT TO THE INVOICE FILE. AND UNLOCK THE INVOICE FILE Do a Set_Property in the Invoice form to the Invoice # just written (the DEFPROP property), then force a read by sending a lostfocus event. Alternatively, you can read the record yourself by doing a FORWARD_EVENT and then continuing with your processing. Typically, I save the regenerated @RECORD into a user-defined variable .. OREC and then my old AREV logic for incremental updating will still work. I have a process that preceeds the write that decomposes the bound elements and reassembles @RECORD at that point. Then, everything can proceed as normal. You can check the data before writing (matching @RECORD to OREC, etc. and stop the write by returning 0 or .. FORWARD_EVENT and then do some post-write processing. At least that's what I do .. probably messy, and inelegant, but it works. If it ain't broke, don't fix it. Cheers .. Don Miller C3 Inc. </QUOTE> —- === At 13 JUN 2002 08:06AM The Sprezzatura Group wrote: === <QUOTE>I'm not sure if this should go on this thread or the OREC thread, but one of the OIWIN_COMM_INIT variables is OrigResultRow@, which is OREC. The Sprezzatura Group World Leaders in all things RevSoft </QUOTE> View this thread on the forum...