How Does ORIG_XXX Work (OpenInsight Specific)
At 12 FEB 1998 02:33:45PM Robert Dunmire wrote:
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
At 13 FEB 1998 04:43PM Cameron Revelation wrote:
Robert,
ORIG_TEXT
For the most part, the ORIG_ properties are used to determine the property values when the window was started.
I'm trying to test to see if a value has been changed in an edittable.
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
At 16 FEB 1998 10:32AM Don Bakke wrote:
Cameron,
To get the original record as it was read, use the ORIG_ROWVALUE property.
I never saw that before. So this gets set during every 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…
At 16 FEB 1998 11:10PM Don Bakke wrote:
This should then replace my current method of setting a user-defined property (e.g. @ORIG_RECORD) and then retreiving it later?
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%?
At 17 FEB 1998 07:24AM Cameron Revelation wrote:
Don,
Now that we know what it doesn't do, any chance of adding an ORIG_RECORD property that works just like WC_OREC%?
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