Field Rule events

[Cindy731]

I would like to use the code example in XBasic For Everyone, Chapter 16 (recently revised version). The code is attached to the Field Rule. It warns the user that a duplicate record may already exist when entering a new record. However, after the event fires, I would like the cursor to remain on that field

Any help will be gratefully appreciated.

[Jim Chapman]

RE: Field Rule events

Hi Cindy,

Context is everything. I don't have the book you are referring to so I don't know what code has already been defined. But as you are defining this at the field rule level you will have to realize that adding this code for a particular form may break when a different form based on the table is used. That being said, the code you need to add to the script will be something like this:

Myform = topparent.this
Myform:FieldName.activate()

Replace 'FieldName' with the real name of your field. Remember that just adding this to the end of the script will cause it to run regardless of whether or not the code found a duplicate, so you'd need to embed this in the if then or select statement otherwise you'll end up with a form loop taking you back to the field you want activated every time you try to leave the field.
You could test for a specific form and selectively run the above code although this may not always work as Alpha will assign an alias name if more than one instance of a form is in use, but you could always just check for the first significate characters.

Good luck,
Jim

[Tom Cone Jr]

RE: Field Rule events

Good morning Cindy & Jim,

Jim, I think Cindy is referring to Script 16-1 which is intended for the CanWriteField field rule (Events). The context, as you say, is everything. Here the script is intended for a table level field rule... it's not connected with a form layout. I'm not sure it's a good idea to embed form specific references into a table field rule (if it's even possible...) since the field rule script will fail using any other form, including the default form or browse.

Cindy, instead of using table level field rules when I am trying to adjust or set the input sequences for a particular form I use the events available in the form, and available in objects on the form. In your case I'd look at either the CanDepart or the OnDepart events of the firstname field object on your layout.

I think of it this way. Table level field rules are gatekeepers, defining *what* can be entered by the user. Form level events are used to define *how* the user opens and closes the gate.

Hope this helps.

-- tom

[JerryBrightbill]

RE: Field Rule events

Tom,
It is possible to embed form references in field rules succesfully, but very rarely necessary. I have one odd case where a field rule has a special application only in one form. Rather than writing the equivalent code into every form, I put the code in the field rules. I use the following if statement to check if the action is happening on the specific form.

if alltrim(topparent.name()) = "form name"
'action to take

In this way, the code will work if the action occurs on any form or browse.

Jerry

[Tom Cone Jr]

RE: Field Rule events

Jerry, thanks... I needed that!

On looking back I now see that perhaps Jim had something of the same sort in mind. (Sorry 'bout that, Jim.)

I'll keep your tip in mind for future use. In the meantime I'll also be wary of embedding the actual names of specific objects from a particular form in my table level field rules.

In Cindy's case it's likely that the field she is interested in bears the same object name as the field name in her table. But it's not guaranteed, and it's subject to change.

Incomplete or relative addressing of object names can be problematic too. The current form may or may not be identified using a reference to topparent.

-- tom

[JerryBrightbill]

RE: Field Rule events

Cindy,

I am also not familiar with the specific code you refer to, but the command cancel() will prevent the event from continuing. Check out the xbasic manual section on canceling events. In my copy, it is on page 75. If this is used at the end of the CanWriteField event in field rules, the cursor will stay on the field if the event fires.

Jerry

[whanigsberg]

RE: Field Rule events

Hi all,

I'm back home so I have access to documentation again. I have been watching this thread to see if someone else remembered this passage from the Xbasic manual.
-------------------------------
Script Context for Field Events
When a script attached to a field event is executing the this alias refers to the control on a form, or column in the case of a browse, to which the field is bound. For example, assume you have defined a field event for the Customer_Id field. Assume that you are using a form with a control called Cust_Id that is bound to the Customer_Id field. Assume that you try to edit the value in the Cust_Id control. This will cause the CanEditField event to fire. If the script that is executed uses the this alias, then the alias will refer to the Cust_Id control.
----------------------------------------
For me, the implication of this passage is that with good error trapping it shouldn't necessarily be bad practice to refer to form fields.

Bill

[Tom Cone Jr]

RE: Field Rule events

Bill, I see what you mean. The 'this' alias will apparently refer to the control on the form which is bound to the field regardless of what the control's actual name might be. I did not know you could do 'this'! (pardon the pun)

So, now that you're back from your travels, and presumably well rested and refreshed, do you want to take a crack at Cindy's original question?

-- tom

[Ken L Herrold]

RE: Field Rule events

Cindy, --- With your permission I have comments that concern this thread but not necessarily your problem.

Guys: With field rules I needed to get three character values from the set's header into fields of the browse - background during entry. When I declared a global variable and set the browse field's rule to 'calculated' with var->[variable name] the expression builder didn't balk. If that variable held a value everything worked - if it did'nt I'd get a trace warning. "Couldn't update field rules in db engine bla bla.."

I tried [and it's working] using a "lookupc" on the header as that 'calculated' field's value. You see, during entry I'm thinking the header is saved and indexes updated when the user moves into the browse during entry. Can you see if this method will be faulty in a networked environment? The lookup function is using the header's ID key and Index.

Thanks Cindy for letting be 'butt" in here.

Ken

[Jim Chapman]

RE: Field Rule events

Hello Ken,

The short answer is to wait until version 5 is available. V5 allows set level field rules as well as table level field rules. This is not the functionality that we had with Alpha 4 but it will allow situations like your's to work.

Dealing with the current version, you could write a little more complex expression that would write a blank "" value to the field if the variable didn't exist which should prevent the error message. As to the networking issue, it shouldn't be a problem other than a speed issue. I would tend to try to get away from the lookup() functions in field rules as much as possible, both for speed and other issues.

Good luck,
Jim

[Finian Lennon]

RE: Field Rule events

Ken:
For a long time we populated multiple child table values via lookups from the child to the header. However, on busy systems, these would occasionally fail and it became necessary to do something else. My "something else" is similar in concept to what you are doing.

I added a global variable to the header and child tables (not strictly necessary in practice, I think) but makes me feel secure. In the OnSave event for the table I concatenated the fields whose values I needed to write into the child table. I padded all fields so that the variable has a constant string length. So, every time a header record is saved, a variable of constant length 19 characters is created. Now, in the child, I can use substr(Var) to derive the values for each of the field default values I need.

In addition, since child records can be added without a header record having been saved, I added the same code to create the global variable to the OnFetch event of the data entry form. This way, the correct values are always available to the child table field rules. Works very well and is noticeably faster than the lookups.

Finian

[Ken L Herrold]

RE: Field Rule events

Thanks Jim and Finian!

Ken

[martinwcole]

RE: Field Rule events

Tom, I have found using field rule events as the easiest way to control events in an embedded browse, and use it all the time:

here is one example of using field rules for two different forms that use the same table:

at the onwrotefield for batteries->quantity:
if is_object(":batteries")
tbl=table.get("batteries")
tbl.amount=tbl.quantity * tbl.amt_each
:batteries:browse1.refresh()
:batteries:browse1.commit()
:batteries:button2.activate()
end if

at the cansaverecord event for the file:
if is_object(":edit batteries")
t=table.get("batteries")
if rtrim(var->company)="HAE"
t.amt_each=t.hae
elseif rtrim(var->company)="IHS"
t.amt_each=t.ihs
end if
:edit batteries:browse1.refresh()
end if

the A5 electronic manual also talks about this method in the "about objects" section

also, handy, with embedded browses, you can do things like this to control the 'cursor':

onrowchange:
if is_object(":batteries")
:batteries:browse1:amount.activate()
end if

note***** you have to put the colon in front of the object name in all cases

[whanigsberg]

RE: Field Rule events

Well, Tom, the code in question is attached to the firstname field's CanWriteField event. Cindy doesn't tell us what control (if any) is active when the code cancels the write process and I haven't checked this out but perhaps the first thing to try would be the line
...
cancel()
this.activate()
...
to set focus to the firstname field.

I haven't tried this but the documentation suggests that it should work.

Bill