I've been tring to get an edit line to default to a symbolic

field's @ans. Both the edit line properties in a control on a form and the column attributes in table builder have a default prompt.

How, or can I put the field name to a symbolic field in to use as the

default? I was hoping to use {field_name} but it does'nt seem to work.

Need some Defaults for Dummies HELP ???

Hi S

This is generally where I get out my commuter event these days, ie a routine that you call from the quick event, so I don't have the same code in every piece of event script code. (Be brave and feed "Commuter" to the search engine)

I tried using defaults with bound tables, but when you are creating a new record, it doesn't work very well because even though you might have a fixed value symbolic, there is nothing there until you save.

So I put stuff in the create form event or the post read event and in the got focus event, things like

* init

this_ctrl=@WINDOW : ".THIS_CTRL_NAME"

* go do what needs doing to retrieve default eg

default_val=XLATE("SETUP", "DEFAULT", 1, "X")

* now set the value on the form

void=SET_PROPERTY(this_ctrl, "TEXT", default_val)

* I use SET_PROPERTY, GET_PROPERTY instead of the shortcut "-]"

* because "-]" doesn't work in the STDPROC commuter routine

* I also assign all my window controls to variables/constants

* in one place (like an initialisation routine) because if you spell

* a control name wrong, your program will happily return nothing

* and continue executing, where as if you spell a variable name

* wrong it usually complains about it being unassigned. This method * confines the number of places I can stuff up to one:

* the init routine.

Scott, LMS

Thanks Scott.

I'm still kind of confused about how to do this one. Here is

what I've got.

I have a Vehicle table and a Vehicle_Maintenance table. These

are attached Arev files.

In the Vehicle file, field 2 is a multivalued list of persons

assigned. The last person in this list is the current person

assigned. When a new person is assigned to the vehicle, a value

is inserted into the field and the new name is entered.

In the Vehicle_Maintenance file, field 19 is the field I need to

have to default to the current person assigned to the vehicle. In

Arev, I have a symbolic that xlates value 1,1 from the name field

in the Vehicle file. When you are entering a new record into the

Vehicle_Maintenance file, this symbolic field uses the vehicle Id

as a key to retrive the name from the Vehicle file. This all works

very well in arev.

I hope this is all clear and understandable.

Any ideas on this?

S,

Your problem is to set the default value of a field, right? I don't agree with Scott about using GOTFOCUS handlers and stuff. It's better to use the standard default mechanism.

But Arev probably allows more than OI. I think you might have to make a function that gets the value from the symbolic, and then use that function in your edit line's Default setting.

Tricky?

If I'm wrong I'm confident somebody will set me right.

- Oystein -

DECLARE FUNCTION SET_PROPERTY

Well I just tried puting this code in the create event of

my form.

NAME_CTRL=@WINDOW:".NAME"

NAMES=XLATE("VEHICLE",{VEHICLE_NUMBER},2,"X")

THIS_NAME=NAMES

DEFAULT_VAL=THIS_NAME

VOID=SET_PROPERTY(NAME_CTRL,"TEXT",DEFAULT_VAL)

RETURN 1

I got an RTP27 error. ??? This is a little over my head.

I could'nt get it to give me this error a second time.

Maybe it was just some cosmic rays going around in the

building. Guess I'll scrap this idea.

Hi S

I'd probably get the vehicle number directly rather than using {}. You may need to put it in the READ event post event bit (look up how forward_event works) - not sure you can use {} to get stuff from a record in the create event because that comes before the read event ie I don't see how the program will be able to evaluate {VEHICLE_NUMBER} in the create event…

Is it working now? Are you working now? I should be sleeping and for some NY reason I can't.

Scott

S,

I think you get the RTP27 error because you use {} without @Dict, @Record and @Id having been set.

- Oystein -

S,

Do you really want to set that default value already in the CREATE handler? For all I know it might be exactly what you need. But normally a default value for an edit line would appear at the time the user arrived at that edit line and not sooner. Instead of having code like

... ... ...

... ... ...

... ... ...

Default_Val=...

Void=Set_Property( Name_Ctrl, "TEXT", Default_Val )

in the CREATE handler you could use the standard default mechanism for an edit control. Make a function like

function Name_Default( Dummy )

... ... ...

... ... ...

... ... ...

Default_Val=...

return Default_Val

or something, and set the Default of the edit line to

NAME_DEFAULT('')

Now I haven't detailed how to get that

... ... ...

... ... ...

... ... ...

Default_Val=...

portion of your code right. Will you manage?

I hope I don't come across as totally insensitive, sitting here writing about software problems like nothing happened. Inside I weep for all the victims of the terrorist attacks.

- Oystein -

Oystein ..

Thank you for your comment. There is a certain almost bizarre sense of unreality to the whole thing. I have a good friend who was working about a block from the WTC and managed to help rescue a couple of his friends from Tower 1 (the first one hit). We talked about it for about an hour last evening.

As you know, RTI's offices are less than 20 miles from NYC and Mike's sentiments were well put. I live right between NYC and Boston .. and I spend a good deal of time in the Washington DC area playing bluegrass music (been a serious hobby for a long time now). None of my friends there work at the Pentagon so they're safe. But oddly, I have a friend who lives less than a mile from the PA, MD border where the aborted attempt at Camp David crashed. His family saw the smoke and heard the explosion.

Frankly .. I'm looking forward to a little R&R in London in two weeks. Hope to hook up with Andrew and the Sprezz gang while I'm there. I think I need a break from this.

Again .. thank all of you for your kind sentiments.

Don Miller

C3 Inc.

Hi Oystein,

Yesterday when I was responding to this problem I almost

commented on the bad situation in NY but I bit my toung.

Today I'm having a really hard time thinging or doing just

about anything. I'm just hart sick.

The folling is some code I put in the lostfocust of the

Vehicle_number control of my Form. I really feel dumb with

coding in OI. Please bear with me and use detailed examples.

I need to see as much detailed coding syntex as possible.

I'm thinking when leaving the Vehicle_number control I'll

have the key needed to xlate the curr_name I need. So what I

need to do is make a function to do that and use the return

value as the default in the Name control. I just don't know

how or where to do it.

Also in this lostfocust I already had some code to change color.

So I wasn't sure about the return thing. Return Default_Name and

Return 1?

Check this out and help teach me to code what I'm thinking.

Thanks.

COMPILE FUNCTION NAME_DEFAULT( DEFAULT_NAME,)

DECLARE FUNCTION SET_PROPERTY

DECLARE FUNCTION GET_PROPERTY

EQUATE white$ to 16777215

background_color=SET_PROPERTY(@WINDOW:".VEHICLE_NUMBER","BACKCOLOR",white$)

VEH_NUM=GET_PROPERTY(@WINDOW,".VEHICLE_NUMBER")

NAMES=XLATE("VEHICLE",VEH_NUM,2,"X")

CURR_NAME=NAMES

DEFAULT_NAME=CURR_NAME

RETURN DEFAULT_NAME

RETURN 1

*PS This of course didn't Compile

S,

In the LOSTFOCUS handler of VEHICLE_NUMBER just set BACKCOLOR. Don't worry about the NAME field's default value yet. Put the following code in the LOSTFOCUS handler:

DECLARE FUNCTION SET_PROPERTY
EQUATE white$ to 16777215
background_color=SET_PROPERTY(@WINDOW:".VEHICLE_NUMBER","BACKCOLOR",white$)

Then end that handler with a RETURN 0 or RETURN 1 - that's the choices you have in a (scripted) handler. It might not matter much which one you use. It depends on the circumstances. But I assume in general RETURN 1 is the safest here. (You can read about the difference in the OpenInsight for Workgroups Help file (not System Editor's Help file) - do F1 from the OpenInsight main window, then select Guide to Application Development and Event Driven Programming.)

Note that there shouldn't be any compile function( … ) line in a scripted handler like this.

Then for the default value handling of your NAME control write the following function as a Stored Procedure in System Editor:

function Name_Default( Dummy )
	DECLARE FUNCTION SET_PROPERTY
	DECLARE FUNCTION GET_PROPERTY
	VEH_NUM=GET_PROPERTY(@WINDOW:".VEHICLE_NUMBER","TEXT")
	NAMES=XLATE("VEHICLE",VEH_NUM,2,"X")
	CURR_NAME=NAMES
	DEFAULT_NAME=CURR_NAME
RETURN DEFAULT_NAME

Then put the following in the Default setting of the NAME edit line (and here you must use uppercase):

NAME_DEFAULT('')

So almost all your code was correct, but placed and wrapped a bit wrong. (Btw - in case you reuse your original lines instead of copying from here, note there was a couple of errors in your GET_PROPERTY line - a comma instead of a colon, and a missing "TEXT" property.)

Now I haven't checked everything in your code, like if your white$ is correct or if the Xlate looks OK.

- Oystein -

Hi Oystein,

Thanks for all the help. I'm learning. This is what we did

yesterday befor I read your last response this morning. I

would like to hear your opion on it also.

Thanks agin.

Steve Bell

THIS WAS PUT IN THE GET_FOCUS OF THE NAME CONTROL. DECLARE FUNCTION SET_PROPERTY DECLARE FUNCTION GET_PROPERTY *DEBUG EQUATE yellow$ to 65535 EQUATE BLACK$ TO 0 VEH_NUM=' FGC=SET_PROPERTY(@WINDOW:".NAME","FORECOLOR",BLACK$) background_color=SET_PROPERTY(@WINDOW:".NAME","BACKCOLOR",yellow$) VEH_NUM=GET_PROPERTY(@WINDOW:".VEHICLE_NUMBER", "TEXT") ORG_NAME=GET_PROPERTY(@WINDOW:".NAME", "TEXT") IF ORG_NAME=' THEN NAMES=XLATE("VEHICLE",VEH_NUM,2,"X") CURR_NAME=NAMES DEFAULTPROPERTY=SET_PROPERTY(@WINDOW:".NAME","DEFPROP",CURR_NAME) END ELSE RETURN 1 END RETURN 1 This seems to work also. Would you're way be better?

S,

Haven't got the time now to read your posting properly. It seems you use the GOTFOCUS handler to set the default value. It might be better than CREATE, but I recommend using the Default stuff instead because the latter's more intelligent.

E.g, say your client tabs through the form more than once before saving. Say he declines the NAME default value the first time and keys in his own value. What happens the second time he enters the NAME field? Will your handler overwrite the user's value with the default value again? There's a couple of cases like that which the standard Default handling does better.

- Oystein -

Oystein .. et al

It would be a good idea to check for the existance of any data in the control before doing this. If the user moves about the form and then returns and the GOTFOCUS event gets fired, it will overwrite what's there.

FOO=GET_PROPERTY(CTRLENTID,"TEXT")

RETVAL='

IF LEN(FOO)=0 THEN

…do your default

…and set RETVAL

END

RETURN RETVAL

Don Miller

C3 Inc.

OK Oystein,

I did the Stored Procedure in System Editor like you said.

Now guess what?

When I try to tab through the form, the default value still

stays in the control and would get saved if F9ed. You have

to go back and delete the default in the control.

What gives? It shouldn't do this should it?

Don,

Overwrite? If you do it with a very simple GOTFOCUS handler - yes. But not if you do it like I suggest - have a function call in the Default setting of the field. Or?

In my last reply to S Bell I said the Default method had one other advantage over a simple GOTFOCUS. That there was a different special case it handled automatically. But that might not be true. So a GOTFOCUS handler that doesn't overwrite might be just as good as a Default function call.

- Oystein -

S,

Must confess I no longer know what you're after. I went back and read your second posting in this thread. There you say: In the Vehicle_Maintenance file, field 19 is the field I need to have to default to the current person assigned to the vehicle. In Arev, I have a symbolic that xlates value 1,1 from the name field in the Vehicle file.

Now what is it you really want? In Arev you used a symbolic. Why can't you use one in OI?

As I understand the concept a default value is something one would use for a data field, not a symbolic. And a data field is stored, of course.

- Oystein -

Hi Oystein,

Sorry for all the confusion. Let me try to explain agin.

In a record in the Vehicle file, a multivalue field called

NAME, is a list of people that have been assigned to that

vehicle. The user's insert a line to add each new person that

is assigned. So the most current person asssined is always at

the top of the list. If they need for any reason to look at who

was assigned in the past, they go in and look back in the list.

Also a date assigned field is associated with each name.

 In the Vehicle_Maintenance file, each record is used to track monthly maintenance on each Vehicle. The users wants the person assigned to the vehicle at that time. The next month may have a new person assigned. The symbolic field used to always return the current

person's name. I have used this same idea in other systems where we have a multivalued list of subjects and a certion one is needed to

fill a field. You may need the first one, last one, or maybe one in a

case that the date field associated matches some other date.

I hope this makes a little more cents to you.

S,

I thought you said you had a solution that worked in Arev. I assume in your Arev app you had a form bound to the Vehicle_Maintenance table. And that table contained the much discussed symbolic field. I assume the Vehicle_Maintenance form had a field (or whatever edit controls are called in Arev) bound to that symbolic field.

If so - why can't you do the same in OI? Why bother with CREATE handlers, GOTFOCUS handlers and Default settings? Why not just use the same symbolic?

- Oystein -

Oystein,

Well that's what I tried to do in the first place. OI,s

control default prompt doesn't except a field name. Arev,s

does. You just enter that symbolic field name in {} in the

default prompt. Using this symbolic field in a stored procedure

works, except for not being able to tab through the control.

A default in OI doesn't seem to be an option to the user. Once

you enter to control, you either take the default or wipe it out

and enter somthing else. Maybe the user will just have to live with that. I have one system here with a field somthing like this that is a protected field. The Auditors insisted it be that way. As long as the user remembers when to use the tab and when to use the enter key it works OK. But when they slip up, guess who gets to fix things.

Somtimes things are just a pain in the Butt.

S,

Well that's what I tried to do in the first place. OI,s control default prompt doesn't except a field name. Arev,s does. You just enter that symbolic field name in {} in the default prompt.

Tell me - why don't you show the symbolic field itself? Why go via the default value of another control? Or is it very important that the value doesn't show until the user arrives at the control?

- Oystein -

Hi Oystein,

I'm not sure what you mean.

Anyway I took a closer look at how using my symbolic field in a stored proceedure and using the return value in the default slot works. I see all the user needs to do is hit the delete key if they

don't want to use what the proceedure returns. That's not so bad.

I'm OK with the way this works. Most likely they will always use the

name the proceedure returns. This whole thing is mostly a entry speed convenience.

I'm sorry for all the confusion this has caused. I guess I didn't do

such a good job explaining what I was tring to do.

The good side is I learned soom good stuff about stored proceedures

and control defaults.

I hope you won't cringe the next time you see my name on a posting.

S,

I hope you won't cringe …

I've done too much user support for that. And now also teaching programming for Arts and Humanities students.

- Oystein -

View this thread on the forum...