@RECORD in OI question. (OpenInsight Specific)
At 30 OCT 1998 09:49:53AM R. Brooks wrote:
I read an article outlining some concerns when migrating or sharing an OI app with ARev. I the article(s) it mentioned that @RECORD should not be used in the same way as ARev because OI does not
update this dynamically.
Does this mean that I should chance all my symbolics in OI that reference @RECORD that might be "Calculated" from a form control?
Or should I only be concerned with scripts,event-handlers and stored procedures?
At 30 OCT 1998 04:24PM Dave Pociu wrote:
The main difference is the fact that the data in @RECORD is not what gets written to the table. At Write time, the information is actually gathered from each control without anything to do with @RECORD.
On the other hand @RECORD still exists, and gets updated every time a control is changed. That means that your symbolics that reference @RECORD will still work in OI.
However, any scripts, stored procedures that modified @RECORD so that the information there can be posted to the screen controls later will not work anymore. You will need to update the individual form controls with the right data.
In a nut shell, @RECORD has become a "READ-ONLY" variable; making any changes to it in form processing is useless.
Personally, when migrating from AREV I found this a very cumbersome thing. I built 2 major subroutines, one that gathers screen data from selected controls in a variable ( in @RECORD or some other variable name), and one that allows me to automatically post the variable's data back to the screen controls. With this I can still use @RECORD (and thus my old AREV code), but let OI write by using the screen control data. This not only allowed me to keep my AREV logic that dealt with @RECORD/@PSEUDO intact, and cut down tremendously on bugs because I didn't have to make any logic changes.
Hope this sheds some light on the matter
Dave
At 31 OCT 1998 11:55AM Don Bakke wrote:
Everything Dave said is correct, however you should also be aware that certain methods of programmatically updating controls will not update @RECORD until WRITE time. For instance, setting the TEXT property of a databound control will not trigger a change in @RECORD immediately but the use of DEFPROP property will. So for any procedure that needs to dynamically update the screen, it is generally best to use DEFPROP or INVALUE. That way @RECORD is always current.
dbakke@srpcs.com
