In some procedure of OpenInsight I modernize the @RECORD. Is there some form that immediately it is reflected in the associate controls and the property "RECORD" of the Window?. In other words, to make the same thing that is in AREV: "WC_DISPLAY_ACTION%=REDISPLAY_ALL$" (after modifying the @RECORD programmatically) worse in OpenInsight???

Thank you from already.

Luis,

Since OI doesn't associate @RECORD in the bi-directional way that AREV does, you have to write your own tool to do this. I believe Don Miller has written his own routines for this and he may be willing to send these to you.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Or how about sending a write event followed by a read event of the same record?

There are a couple of ways you can do this (depending on what you're trying to accomplish):

1. Try to manipulate the RECORD property of a form and maintain the structure of @RECORD yourself. This is usually done on the CHANGED event of controls in the form. Tedious to say the least since you don't have any good way to handle multiple changes to the same form element. I save the original record (as read from disk) in a user-defined structure @ORIG and then compare the current data to the corresponding @ORIG to figger out what to do.

2. Since the Form-I/O logic comes directly from the data in the bound controls, you can create what @RECORD will be just before the Write event and do any Pre-Save processing you need (incremental updates of other DB structures or other files).

3. You can Write the current record and read it back to get what has been done.

4. If you need to fiddle @RECORD to get symbolics to work, I would strongly recommend recoding your symbolics to use braces {} notation so that you can issue a CALCULATE call from within the form. In this way, all you have to do is set the DEFPROP of a control and send a CALCULATE event to the related controls (if the form doesn't do this for you).

I don't think that sending you the application specific code would be much help to you unless you understood what the underlying processes called were doing.

HTH

Don Miller

C3 Inc.

Robert,

The one main problem with this approach is that your record is now committed to disk.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

I remember when I was first playing around with MDI screens, you taught me/us a cute trick. Save the "record as read" somewhere handy. As you flick between mdi children, write away the changes, but if the user decides they don't want the changes, write back the record as read. It works really well.

I'll admit it might be a bit of a sledge hammer approach in this case, but quite workable nevertheless.

By the way, the first MDI Parent, has now gone forth and multiplied. There are now lots of children, cousins, uncles and grandchildren. In just a few generations, we plan on taking over the world.

Thanks for your help back then…

View this thread on the forum...