{"id":39,"date":"2013-11-17T22:38:26","date_gmt":"2013-11-18T03:38:26","guid":{"rendered":"http:\/\/www.integrityautomatedsystems.com\/blog\/?p=39"},"modified":"2023-03-31T22:38:28","modified_gmt":"2023-03-31T22:38:28","slug":"saving-statedata-without-defining-a-bunch-of-temporary-variables","status":"publish","type":"post","link":"http:\/\/integrityautomatedsystems.com\/index.php\/2013\/11\/saving-statedata-without-defining-a-bunch-of-temporary-variables\/","title":{"rendered":"Saving state\/data without defining a bunch of temporary variables"},"content":{"rendered":"

\"2013-11-14<\/a><\/p>\n

 <\/p>\n

Variable Scope<\/h3>\n

In RDMLX (The LANSA language), variables have a global scope. This means that it’s really easy at times to accidentally clobber a field which you are using, by using the field for more than one purpose. It can be argued that all fields should only be used for one purpose in a program, but there are scenarios where this can happen. E.g. You may be using a field to represent the selected value in a drop down list, and you may also be using the same field to populate the value when building the list.<\/p>\n

Global variables have historically been a cause of subtle bugs. A couple of options exist to try and alleviate this problem. Any code that would be better with a local variable scope can always be externalized into a reusable component (The first option). This will also go a long way to minimize coupling. However, if you do not want to re-architect your program, but still need to prevent your variable from becoming contaminated, you could always backup your variables at a convenient location and restore it later when you need the saved values back (the second option).<\/p>\n

Use a List<\/h3>\n

If the save and restore have to handle more than a few variables, it becomes cumbersome if you are just using temporary variables to store the data.<\/p>\n

The solution shown in the image above defines a working list with one record. Then when you want to backup the data, you merely do an ADD_ENTRY to_list(#LISTNAME). And voila, you have saved the current state of these fields. Once you are ready to restore the state of the fields, you can do a GET_ENTRY number(1) from_list(#LISTNAME) and you variables have been restored.<\/p>\n

This techniques tends to reduce the need for work fields, and can reduce the coding required to accomplish the same task.
\nLess work fields and less code = less bugs.<\/p>\n

Andy<\/p>\n

LinkedIn<\/a>
\nhttps:\/\/plus.google.com\/+AndyBain<\/a>
\n@jandybain<\/a><\/p>\n