Hello all, me again! Sigh.

This is a simple one (he typed confidently): Does OI support the prompt (ok, PROPERTY) default value of " (a single-double quote mark) which, in ARev, copied the value from the previous record in a data entry window?

If not, how do I do this?

Slowly but surely…

Mike Parrish

Mike,

The simple answer is "no, OI does not support this AREV feature." However, it's not too hard to implement. One way, although not the only way, would be to track the value of the previous record (or value in a control) using a user-defined property. Then write a custom default routine that retrieves the relevant value for the control(s) in question from the user-defined property and return the appropriate value.

We also use this technique to simulate Alt-O and Alt-C from AREV.

[email protected]

SRP Computer Solutions, Inc.

Don,

Oh my gawd, I think I'm finally getting the hang of it !!

So to replicate the default " action from ARev in OI, does this mean some custom code in the WRITE event of the database-attached form? I'm supposing a Forward_Event() call would be in order, no? I guess what I want to do is to pass the previous record into @USER1, converting the @VMs to @TMs and @FM to @VM, since there are probably about 20 or so prompts whose data I'd like to recall from the previous record and I'd like to leave @USER1 through free for other, similar processing with other databases.

If Forward_Event is the correct call to make, how best to implement it? I'm not sure I quite follow the Command Reference entry on this subroutine.

TIA,

Mike

*Set UDP to Current Record

@record=get_property(@Window,"RECORD")

set_property(@Window,"@WC_PREC",@record)

forward_event()

return 0

*To get prevAtRecord **

wc_prec%=get_property(@Window,"@PREC",@record)

This is from the top of my head and other people could have better methods, so wait for more responses (Actually I have a promoted event that does this write I assume - please dont ask me to explain promoted events ..now Don Bakke on the other hand..)

Barry

Mike,

A small correction on Barry's code: he used @WC_PREC in the first section of code but then uses @PREC in the second section of code. These should be the same. It doesn't matter which one you choose.

I would use @USER variables because they can't be tied to the specific form. In other words, if the user switches between active OI windows, @USER can only contain the previous record for one of them. So when your default logic executes it could pull data from a record related to a different table.

Barry is using the method I was recommending: User-Defined Properties (UDP's). These are nice because they can be dynamically created, can be associated with each form (which is what you want), and disappear when the relative form is closed.

Forward_Event() isn't necessary if you Return 1 rather than Return 0. All it does is allow the actual WRITE event to continue and do the actual writing of the record after your event code executes. If your Return 1, however, this will happen anyway.

Barry mentioned Promoted Events. We heartily recommend and use them as well. However, they aren't necessary to accomlish your application goals. Ultimately I would suggest you learn how to use them but if your learning curve is a bit high at the moment then wait awhile.

[email protected]

SRP Computer Solutions, Inc.

Don & Barry,

Thanks for the help!

In another life, while developing in ARev, I had need to make use of @USER variables to pass all sorts of data back and forth between windows (related or not), subroutines, stand-alone programs, etc. since they (the @USERs) weren't tied to a recursive level and were user-specific, so there was no fear of them being trampled on by other users working with the same windows. Since there is no Pre-Write hook in OI, I thought this should be done throught the WRITE event but not affecting the actual WRITE event itself (somewhere I saw some documentation that using Forward_Event would allow for pre- and post- event processing).

UDPs, eh? Hmmm…. I can hardly wait to see what sort of damage I cause!

BR,

Mike

Hello all,

I have finally gotten around to working on this process of saving to an @USER variable the about-to-be-saved record in an OI form so that I can mimic the " function from ARev.

In placing the code that Barry offered with minor editing, I wrote:

SavedRec=Get_Property(@window, "RECORD")

Set_Property(@window, "@USER1", SavedRec)

Return 1

I transfer from SavedRec to @USER1 cuz it doesn't make sense to me to initialize the @USER1 with Get_Property and then use @USER1 as the 2nd and 3rd arguments in Set_Property.

Anyway….I placed this in the WRITE event script for the form but when I have OI check the syntax I get the debugger message:

B105: Line 8. SET_PROPERTY has not been dimensioned or declared as a function.

I have tried this with and without a line "declare function SET_PROPERTY" to no avail.

First question: Should I not be placing code like this in the script for the event but in a separate stored procedure? That would seem like extra work to me….

Second question: it seems a little redundant, but should I be applying Set_Property to some variable, as in

SR=Set_Property(@window, "@USER1", SavedRec)???

Third question: Is the debug message I'm getting a red herring?

I haven't tested the code to see if it actually does initialize @USER1 with the record cuz I figure if I get a message saying that my syntax is wrong, I'm inclined to believe it, but it wouldn't surprise me if this actually did work. I'll see if that's the case while awaiting a reply from one of you OI Sages!

Thanks,

Mike

Mike,

First question: Should I not be placing code like this in the script for the event but in a separate stored procedure? That would seem like extra work to me….

It will work regardless of where the code is stored. However, we recommend that you get into the practice of storing all code related to the same window/form in a common routine. Routines like this are often called "commuter modules". This will help organize your code and make your development more efficient.

Second question: it seems a little redundant, but should I be applying Set_Property to some variable, as in SR=Set_Property(@window, "@USER1", SavedRec)???

It is very infrequent that you would need to do this. That is why many time you will see Set_Property called as a subroutine rather than a function.

Third question: Is the debug message I'm getting a red herring?

The debug message is because you never declared Set_Property as a subroutine.

[email protected]

SRP Computer Solutions, Inc.

Thanks, everyone, for all your help on this. I had endless grief over why Set_Property was not transferring any data to @USER1 when, after a night's sleep, I realized that @USER1 (along with @USER2, 3 & 4) are already defined system variables. So I transferred the data with a simple @user1=SavedRec, which worked perfectly.

Mike

View this thread on the forum...