Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Simulating @Record
Hola, esteemed colleagues!
As we all know, in a databound form, @Record does not work in OI as it did in Arev. If you make changes to @Record (or to the OI Window property Atrecord), the changes are not "kept"/written unless the field position is associated with a control on the form. Thus, if one has a lot of fields in the current "@Record" that need to be updated that the user doesn't need to see, they have to either be placed on invisible controls or "something else".
My current client has a Lot of such fields which are updated in code that don't (normally) appear on the form. I have a workaround; but I'm interested in others' ideas as to how to (simply) achieve the goal of being able to update fields that are not on the form.. i.e. the "something else".
Is there a generally-accepted means to do this?
Gratzi, y'all!
As we all know, in a databound form, @Record does not work in OI as it did in Arev. If you make changes to @Record (or to the OI Window property Atrecord), the changes are not "kept"/written unless the field position is associated with a control on the form. Thus, if one has a lot of fields in the current "@Record" that need to be updated that the user doesn't need to see, they have to either be placed on invisible controls or "something else".
My current client has a Lot of such fields which are updated in code that don't (normally) appear on the form. I have a workaround; but I'm interested in others' ideas as to how to (simply) achieve the goal of being able to update fields that are not on the form.. i.e. the "something else".
Is there a generally-accepted means to do this?
Gratzi, y'all!
Comments
Sometimes this is a good candidate for an MFS. So, allow the form to write the data it knows about but use the MFS to update the fields it doesn't know about.
Always open to suggestions tho..
Thanks!
Your use case is different than I assumed based on your original post. You aren't simply looking to update the hidden fields at write time. You apparently have a need to update these fields during data entry. In that case I think you have no choice but to do what you are doing.
BTW, storing data in memory to be written to disk later is, itself, not a kludge. That is quite common in any environment.
I know, I know.. whine, whine, whine.. lol
I want something generic that I can use in all my databound forms. I've thought of having one hidden edittable that I would build in the create event with columns for all the fields that are not referenced by other controls. Then just updating ATRECORD should work, should it not?
The only problem I foresee is that some of the fields are not just MV but SV. Will putting them in an edittable screw up the MV/SV if the edittable is never actually edited?
I suppose I could swap out the @SVM with something else post-read and swap it back pre-write.
I'm just not liking the spider web that has resulted from completely replacing all the "normal" OI functions.
I think the original designers of OI never expected @SVM characters to be embedded so they used it as the internal delimiter for the edit table structure. It is possible that Revelation resolved this in later versions of the product, but it's been too long since I've worked with the native edit table control, especially for storing this kind of data.
Not doubting you, but I'm surprised @SVM would result in separate columns.
Still looking for my ultimate generic solution. Thanks!