Record, @Record, Atrecord.. again

Michael

Hey guys,

Trying to work out the best way to manipulate the current record in a data-bound form if the fields in question are Not bound to controls on the form. I.e. changing field X when field X isn't on the form.

In my Read promoted event, I'm doing another read to load the "full" record into a UDP. I've been under the impression that the RECORD and ATRECORD properties were really compiled as requested from the controls on the form, and that @RECORD is pretty much useless outside of a symbolic.. It's been adequate for what I'm doing; however, on a whim I put a debug in my Read event and, after the read, I checked both properties. I had manually added text to a field that is Not represented on the form. The text in question was in the field in both RECORD and ATRECORD. This leads me to wonder if these properties are truly built solely from the controls on the form, or if they are loaded elsewise.

So the question: Is the record as read in the Read event stored somewhere (without programmer assistance)? If so, can it be manipulated programagically and have the results written out at the Write event?

Thanks in advance!

Michael

Michael

Nevermind.. I got it.. It's not the Read that's the issue, it's the Write (really WriteV's)

DonBakke

I realize this is coming in late, but it occurred to me that you would be interested in the OIWIN_COMM_INIT insert. Sprezz does a good job of documenting this starting on page 16 of their August 1997 S/ENL.

Michael

Thanks Don.. I did take a look at the insert. I've used it before for the control info and the semantics.

I'm currently doing a write-before-the-write in my Write promoted event. That way, if data has changed in the record that is Not reflected on the form, that data will be on file and the system Write will fill in all the fields represented on the form. It works fine, but I'm wondering if there's a better way to handle it. I don't want to completely bypass the system write because of all the other stuff (unlocking, clearing, etc) that happens as part of the system write.

Is there a better way to do this than doing two writes?

DonBakke

Long ago I asked for a way to bind controls on the form that can't be bound in the normal way (e.g., ActiveX controls) so that all of this could still be managed by the semantic logic layer. Mike had agreed to consider it but later on he noted the logic at that level was a bit more complex than he had considered. So he put a pin in this idea. OI 10 supposedly resolves this, at least for ActiveX controls.

Our work around is to maintain hidden bound controls and use the pre-System READ/WRITE event handlers to transfer the data as needed so everything is still handled by the System handler. The only other solution I could recommend is to use your pre-System WRITE event event handler as a replacement and simply prevent the System handler from firing.

Michael

I've looked into doing the replacement idea; but if I do so, it bypasses All the processing of the system event (write, unlock, clear, etc.) and I need to code for those as well. Or am I getting something wrong? (Not the first time)

DonBakke

I don't think you are wrong. It's a all or nothing proposition.

Michael

When I tried a complete replacement before, different aspects of the write process seemed to not work quite properly when I tried to send the events separately. Thus, I went with the 2-write technique (write the buffered record, then allow the Write event). Since OI basically does Writev's for all the fields, the non-bound fields were not overwritten, so it worked. Just wondered if there was a better alternative. But outside of creating hidden prompts for the "non-bound" fields, I guess there isn't.

Thanks for your time!

Michael

Hola all,

I'm continuing to use the technique of maintaining a "shadow record" with all the changes that are made that are Not represented in ATRECORD. Pre-write, I write that out and then allow the system Write to do it's Writevs. It works well; but I do have 2 (hopefully) quick questions:

1. When I store the shadow record in a window @ property, I call it @RECORD. There doesn't seem to be a problem; but does anyone know if there is? Also, is there a problem assigning the record (after Get_Property) to variable @record, or do I Need to call it something else? I know OI's use of "@Record" is wacky.

2. Would there be a dis/advantage to using all non-bound fields and just doing all the file IO, setting properties, etc. in code? Besides not having to do the extra Write, that is. I'd just have to name the controls "ET_135_125", etc. to include the field #'s.

Thanks in advance!

Michael

AusMarkB

1. I can't speak definitively to this. I have a couple of instances where I do something along these lines but from memory I'm not totally sure what makes it work and what may be superfluous because I thought I needed it at the time.
2. The disadvantage of this approach is basically what you see. It's slower to get to the end result of a working window because you need to code every control. The advantage is you have complete control. I prefer this method and am used to doing it that way so it comes easy. My bias may well be because I cut my teeth on an app that was already designed this way so I've pretty much always done it that way.
I've since had experience with both and databound forms are certainly more convenient to quickly get from a to b but unless I'm under a serious time constraint, I'll code the IO myself. The more I use OLE controls (especially the SRP edittable) the more code I have to do anyway so by coding all the controls there's a consistent approach and not a need to read/write some by this method and some by that.

If you're going to take the "code all controls" approach I'd recommend using meaningful/descriptive control names and always use equates in the code. Don't use field numbers. You will inevitably change this as you go and equates/names make it easy to ensure you change all the places you need to. Field numbers tend to blend into each other. Plus it's easier to remember to iconv/oconv "el_date$" then it is to remember to do it to "EL_135"

Michael

I'm thinking to leave off coding and renaming all the controls. Except for maybe edittables. Actually I've seen ET's named after the field #'s contained therein. Not a bad idea in all.

I'm still pondering using the name @RECORD either as a window property or as a variable within a commuter module. I know it's "safe" to use something else, and I have done so; but if an Arev/OI programmer inherits one of my projects, I'd like it to be familiar. Every Revelation programmer knows what @RECORD is supposed to be. I just don't want to trip over anything system-related.

DonBakke

Setting the @RECORD system variable won't harm anything. Just be aware that OI might change it unexpectedly. Personally, I prefer to use UDPs.

I also agree that it is best to avoid using numbers as a reference in the UI. Think client/server design (i.e., decoupled) and you'll do yourself a favor in the long run.

@Michael, to answer your second question I must ask you a question...what's changed for you? Twice before in this thread you said this:

I've looked into doing the replacement idea; but if I do so, it bypasses All the processing of the system event (write, unlock, clear, etc.) and I need to code for those as well. Or am I getting something wrong? (Not the first time)

I took that to mean you've given this a fair consideration and thought the better of it.

Michael

I have indeed. It's easier and more convenient (and a Lot less code) to let the system write process do its thing. I just need to make sure the "shadow record" is posted first to cover all the fields that are not associated with a control. I wish I could just update ATRECORD with the values for those fields; but that would involve having a lot of extra controls.

This is a good compromise.

I am indeed using a UDP for the shadow record; but when I refer to it in code, I was considering using @RECORD. I guess I'll continue to play it safe. @REC or ATREC will do just fine I suppose.

Thanks!