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!

Comments

  • I think you have well summarized the options available to OI developers. Our "something else" has generally been UDPs which we gather in the WRITE event handler and then write the record ourselves.

    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.
  • I ended up creating a UDP called @Record (clever huh?). I have to update the thing on lostfocus (or poschanged) for every. single. control. I put it in my master PE handler and it works.. just "feels" kludgey.

    Always open to suggestions tho..

    Thanks!
  • I agree, it is kludgey, but - to be honest - so is trying to emulate AREV functionality in OI. That is not meant to be a dig, but we stopped trying to replicate AREV in OI years ago because of the constant conflict between the different paradigms.

    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.
  • Is there a good way to simply stuff the contents of my UDP into Atrecord (or whatever) just before a write? OI seems to rebuild Atrecord immediately before writing, so I have to replace the write with my own stuff. Which also means handling the locking, unlocking, close, clear events, etc. myself.

    I know, I know.. whine, whine, whine.. lol
  • Michael - ATRECORD itself isn't used to write the data to disk. It is just a property that is bound to the controls. Thus, setting the field positions of ATRECORD for controls that don't exist on the form won't help you. In the end, OI still queries each control on the form and essentially performs a WriteV command.
  • So I've gone the route of keeping all the changes in a UDP and replacing the usual read/write/clear/close processes. It actually works, but is a pain to maintain.

    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 honestly don't know but that is potential snag in your plan. I'm inclined to think that if all these hidden columns are SV to begin with then you won't see any empty values appearing in your data. I would only be worried if you had mixed MV and SV columns bound to this edit table. Also, it may not matter to you, but the edit table control cannot store @SVM characters.
  • So it cannot store the @SVM at all, or it just treats it like text? There would be no manipulation within the hidden edittable

    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.
  • Internally the control treats @SVM as a column separator. Thus, if you push @SVM data into the control, you will find that it will get broken up into multiple visible columns.

    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.
  • Interesting.. In the DEFPROP, ARRAY and INVALUE properties, the columns are @FM delimited and the rows within are @VM delimited. For the LIST property it's flipped.

    Not doubting you, but I'm surprised @SVM would result in separate columns.

    Still looking for my ultimate generic solution. Thanks!
  • You are thinking of this in terms of a data delimiters. I'm describing a delimiter used internally by the control. I might be over-simplifying the issue, but I believe this is similar to how the text box control internally uses CR/LF to delimit lines but eventually it swaps these for @TM when the data is saved. The edit table control is a third-party tool, so it probably reserved @SVM (Char(252)) for its own internal use.
  • Does the ET do anything weird with the pipe "|"? i need something safe to swap out with the @SVM temporarily
  • That's treated as a regular character.
  • Is there a good (or possible) way to build a databound edittable on the fly? I have the tablename, fieldnames and numbers; but I can't see where set_property would let me assign them to columns.
  • Do you have in SYSPROG the old source for Popup_Sub (1997), it builds the edittable on the fly, you might be able to work out how it does it(good luck)
  • I don't think I have it. The databound part is what I don't know how to achieve.
  • I don't think you'll find any place where an example of this is readily available other than searching the WORKS forum. I recommend going to Sprezz's white papers portal and review their documentation on OpenInsight Window structures.
Sign In or Register to comment.