452 ObjectPAL: Event model

VERSIONS: All , written for Paradox 5

SUBJECT: Disable hilite

BY: MARK PAUKER
Date: 17 January 1996

QUESTION:
How can I disable the highlight of a field in a record object DEFINITELY.

This is a very difficult thing to do because there isn't really one centralized place where you can trap for the highlight. You'll probably need to trap several events, although depending on the problem you are having (I didn't completely follow it in your message), one thing you might try is to use fail() rather than setErrorCode() in your attempt to disable the setFocus method. Using fail() to cancel a built-in method can be almost identical to setErrorCode(), except it is a bit "stronger" in some cases.

The way to do this is, rather than using setErrorCode() use:

errorLog(UserError, "")
fail()

This will place a warning error on the error stack and then completely abort the processing of the setFocus() method. (Simply issuing the fail() without placing the warning error could cause the error dialog to be invoked in some cases, so it's best to place the warning error on the stack first, which will remove that possibility.)

I don't find that setting an error code disables the field's highlight. The only way I've effectively been able to disable the setFocus method is to use the technique I mentioned.

That having been said, if I understand you correctly I think you're looking at this from the wrong angle. You're treating this as a display issue rather than a focus issue. You don't really want to inhibit the display of the focus within the field. Instead you want to inhibit the field's obtaining focus. This is a subtle but important distinction. Thus the object that you really want to have focus is the record.

I suggest that you place the following line in each field's arrive method, or trap centrally in the form's preFilter if you prefer:

container.moveTo()

This will effectively prevent the field from receiving focus, and will send focus to the record. The only problem is that this will prevent the tableFrame from scrolling when using the up and down arrow keys. To solve this problem, put the following code in the record object's action method:

               if eventInfo.id() = MoveDown then
                  self.action(DataNextRecord)
                  disableDefault
               else
                  if eventInfo.id() = MoveUp then
                     self.action(DataPriorRecord)
                     disableDefault
                  endIf
               endIf

As far as the actual highlighting of the record is concerned, there are several reasonably well known (albeit more complicated than they should have to be) techniques, and since your message sounded like you had that pretty well in hand, I won't bother covering that here.

I'm using the passevent key word in the arrive method of every field (this bubbles the event to the record) following by a seterrorcode

Quite honestly, I'm not sure what this will do. The arrive event is a notification event, and thus passing it up will notify the record that it has been arrived in, when in fact that is not necessarily true. Issuing the setErrorCode tells Paradox that an error occurred upon arrival into the field, and thus the entire event chain should be canceled. The problem with this is that the arrival has already all but occurred. IMO, the only place it makes sense to issue a setErrorCode within the movement chain is in the canDepart or the canArrive methods.

The bottom line is, regardless of whether or not your code stops the highlight from appearing upon arrival into the field, the fact is that the active object is still the field. Thus you are prone to the quirks of Paradox such as trying to highlight the active object in certain situations. On the other hand, my code literally makes the record the active object. (Place a button on the form that issues: message(active'name) and you'll see what I mean.) Thus there's no issue about Paradox causing a field to become highlighted because no field is active.

I think that this is what you're asking for, but...

P.S. In the code sample I sent previously, I neglected to include a check for the actions FieldForward and FieldBackward. You should treat FieldForward exactly the same way you treat MoveDown, and you should treat FieldBackward exactly the same as you treat MoveUp.

To index