[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== How Does ORIG_XXX Work (OpenInsight Specific) ====
=== At 12 FEB 1998 02:33:45PM Robert Dunmire wrote: ===
 
{{tag>"OpenInsight Specific"}}
 
<QUOTE>
I'm trying to test to see if a value has been changed in an edittable.



The Window name is FLT_WORKORDER and the edittable is BULK_DETAIL.  



I've done the line count and set up the loop for i to numlines then use, 



Org_Tank_No=Get_Property(@Window:".BULK_DETAIL","ORIG_TEXT")



All I get are null values in Org_Tank_No.  Where am I going wrong here. 



Thanks for any help you can give me 



Robert Dunmire

PERS1996@WIREDWEB.COM
</QUOTE>
----

=== At 13 FEB 1998 04:43PM Cameron Revelation wrote:  ===

<QUOTE>Robert,



[i]ORIG_TEXT[/i]



For the most part, the ORIG_ properties are used to determine the property values when the window was started.



[i]I'm trying to test to see if a value has been changed in an edittable.[/i]



To see if any data-bound control has changed, check the SAVEWARN property of @window.



To get the original record as it was read, use the ORIG_ROWVALUE property.



Cameron Purdy

info@revelation.com

</QUOTE>

----

=== At 16 FEB 1998 10:32AM Don Bakke wrote:  ===

<QUOTE>Cameron,



[i]To get the original record as it was read, use the ORIG_ROWVALUE property.[/i]



I never saw that before. So this gets set during [i]every[/i] READ? This should then replace my current method of setting a user-defined property (e.g. @ORIG_RECORD) and then retreiving it later? If so, cool...



dbakke@srpcs.com

[url=http://www.srpcs.com]SRP Computer Solutions[/url]

[img]http://www.srpcs.com/srpicon1.gif[/img]

</QUOTE>

----

=== At 16 FEB 1998 11:10PM Don Bakke wrote:  ===

<QUOTE>[i]This should then replace my current method of setting a user-defined property (e.g. @ORIG_RECORD) and then retreiving it later?[/i]



I had an opportunity to test this and it doesn't work quite the same as WC_OREC%. From what I could tell it gives you an @FM delimited variable of all the DEFPROP values for all the controls on the form, including the control(s) that hold the key. I can see some use for this but it unfortunately won't replace my current workaround.



Now that we know what it doesn't do, any chance of adding an ORIG_RECORD property that works just like WC_OREC%?



dbakke@srpcs.com

[url=http://www.srpcs.com]SRP Computer Solutions[/url]

[img]http://www.srpcs.com/srpicon1.gif[/img]

</QUOTE>

----

=== At 17 FEB 1998 07:24AM Cameron Revelation wrote:  ===

<QUOTE>Don,



[i]Now that we know what it doesn't do, any chance of adding an ORIG_RECORD property that works just like WC_OREC%?[/i]



Form I/O is control based, not record based as it was in Arev.  This means that there is no reason for the Form I/O logic to hold a "record" (either @record or orec).  I believe the implementation was designed to map to both LH and SQL well, including the support for multiple tables.  Unfortunately, LH-based forms are largely single-table and record-based.



In short, your current implementation with an @ property is a good solution.  You should promote the generic portion of your logic to application-level events which would avoid re-coding on individual forms.



Cameron Purdy

info@revelation.com

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=E6B40BF671E61CFE852565A9006B75CF|View this thread on the  forum...]]