In AREV 3.12 one can define a default by calling a subroutine to provide a default. As I understand it, AREV would then look in the VOC file and then go run the routine and come back with the value.

I attempted to do this in OI and obviously this does not work else I would not be asking for help.

I need to understand more what OI does when it is asked to perform a certain routine, event, or whatever. How can I build a path (so to speak) so that it is flawless.

Thanks again for responding.

Dale

Dale,

You can use a function call to simulate the AREV behavior. Access the properties of the control and in the Default pulldown you can enter the name of the function to call.

For example: FORM_COMMUTER("DEFAULT_DATE")

In the function FORM_COMMUTER, RETURN the value to be used as the default.

DefDate=DAte()

Return DefDate

The only hitch I have found is that the default entry on an edit box is limited to the number of characters that can be seen in the entry control(it doesn't tickertape).

Hope This Helps

Don Merkey

National Software Systems

Thanks, I'll try this.

Dale

Dale,

Just a couple of comments about calling a function to return a default value.

While writing this I realized my main comment wasn't valid after all, leaving not much of importance. But I'll send the remaining comments anyway.

In his reply Don obviously used a real example but pruned it down. It seems Don has a general function Form_Commuter that can do a lot of different things. When he calls Form_Commuter with an argument "DEFAULT_DATE" it returns a default date (today's date). When he calls it with other values it does other stuff. If the only task of your function is to return today's date (let's assume your function is named Todays_Date), you don't need a parameter to tell it what to do. So you'll be tempted to define your Todays_Date function like

function Todays_Date() return Date()

and call it with

TODAYS_DATE()

Except functions must have at least one parameter. Or you'll get a runtime error. (Subroutines can do without.) (Btw - there's an error in the online help. The text states that functions must have parameters but subroutines needn't. But the syntax definitions say the opposite.) So you must define Todays_Date like

function Todays_Date( Dummy ) return Date()

and call it with e.g

TODAYS_DATE("")

(And do remember to use uppercase when you call the function.)

- Oystein -

Oystein ..

How about a Dictionary Symbolic as a default. Used to do this all the time with a {DICT_ITEM} notation in the Null Default place. Do-able in OI??

Don

Don,

Never tried ut. Until now. But it doesn't work. "Error loading program". And it isn't among the possible Default choices. Assume one must use FUNCNAME(…).

- Oystein -

Oystein ..

Yup! I get the same thing here. Probably due to the fact the @DICT and @RECORD, @ID are not loaded. Although AREV 3.x supported multi-table operations, it somehow managed to set these variables properly anyway. What a pity… since the DICT of the file has to be memory-resident for bound items anyway. I got around it this way:

put a hidden control containing the Dict Code on the form (ahead of the control to be filled out). Hang a script on the control to be updated to check to see if it contains anything and if not do a Get_Property on the default and a Set_Property on the control.

Don Miller

C3 Inc.

Don,

put a hidden control containing the Dict Code on the form (ahead of the control to be filled out).

Let's call the hidden control X and the control to be filled out Y.

What if the user clicks directly into Y - skipping X?

Hang a script on the control to be updated to check to see if it contains anything and if not do a Get_Property on the default and a Set_Property on the control.

But assume null is a legal value for field Y. What if the user leaves Y empty on purpose but before saving the row accidentally tabs into the field again? With your solution it now gets a default value after all. You might want to keep the scripting but put it into a function to be called the default FUNCNAME(…) way. Then you will take advantage of the standard default processing's ability to distinguish between cases when a default value should be displayed and when it shouldn't. Also it's slightly easier to maintain the app (for a different developer, or yourself 3 months later) when you don't hide the default stuff in GOTFOCUS handlers or whatever.

- Oystein "What if" Reigem -

[email protected]

View this thread on the forum...