I've noticed that QBFREAD is a different event than the normal windows READ event. Is there a handy-dandy way to make QBF fire the READ event so that it would execute anything hooked to the READ event (particularly a script)?

Don Miller

C3 Inc.

Don,

Is there a QBFREAD event now? In 3.61, which is the version I use, there is no QBFREAD.

Or is this the old problem with the various QBF events (QBFFIRST, QBFPREV, QBFABS, QBFNEXT, QBFLAST) not using the ordinary READ?

In case do a search on

(QBF or QBFREAD) and READ

and you might get some ideas.

(I had a similar (?????) problem but solved it in a simpler fashion. I had this form where I stuffed QBFLIST with a result list, so the user could browse the list. But each row also had a reference to an image file that I wanted displayed in an IMG control. Neither the QBF events nor READ could do that, so I did it in a CHANGED event in the key control.)

- Oystein -

¹⁾)

Oystein ..

Here's my problem:

In the read-event of a window, I save away the original record contents by stuffing the property of @ORIG with the RECORD property.

Then, as the form is processed, I have a generalized commuter module that is called to check to see if the changes that the user is making are legal (for example, a new record behaves differently from a posted existing record which may have had transactions applied to it).

Then at save time I do some batch processing against the controls on the form which have been changed. (essentially this is a conversion of some older AREV code). @RECORD and OREC were grand!

My problem is that in QBF mode, the contents of @ORIG are never loaded such that every record looks like a new one and my commuter module fails. It looks to me as though the script for the read event is not

being processed:

NULL=FORWARD_EVENT ;* this will do the read

REC=GET_PROPERTY(@WINDOW,"RECORD")

SET_PROPERTY(@WINDOW,@ORIG,REC) ;* to save it away

RETURN 1

Don't know exactly why it fails.

Don Miller

Don,

This subject has come up before and I believe the response given by RTI (and in particular by Cameron) is to create your own QBFREAD event. I don't recall the exact way to do this (we haven't invested in QBF very much) but I believe it required using the EVENTDESIGNER tool which allows you to create your own events.

[email protected]

SRP Computer Solutions

Don,

I did some searching right after my previous post and discovered that the suggested approach is to tap into the existing QBF-based events, most particularly QBFNEXT and QBFPREV, and have those execute a Send_Event("READ") to the window. You can create promoted versions of these events thereby doing this once and never having to worry about them again.

[email protected]

SRP Computer Solutions

Don .. thanks for your research. Now I'll have to learn everything I didn't want to know about "Promoted Events".

Don Miller

Don,

On principle I agree with you, however, I highly recommend learning how to implement promoted events for other reasons because they can make your application much more efficient. For instance, I noticed that you set a user defined property to the value of the RECORD property during the READ event. We do the same thing. However, we have this being done in a promoted READ event so it is automated for every window in our application. Very cool stuff.

[email protected]

SRP Computer Solutions

Hi Don

Is there any doco on promoted events anywhere?

Thanks

Tony,

As I have always said, Sprezzatura has the best primer on this subject in their SENL Vol. 1 No. 7. I am sure it is still downloadable from their website.

[email protected]

SRP Computer Solutions

View this thread on the forum...