I have been examining how lostfocus works when the user moves from one window to another and back again. When the user's focus moves from one window to another, the window losing the focus should wait for focus to return before processing. Triggering a lostfocus process otherwise generally will mean trying to validate half-entered data.

Well, here's how OI seems to handle this circumstance. When a user clicks on another window, OI acts as if the user had moved to another prompt in the same form. The control losing focus FIRST performs the control's INVALUE function to validate the data. Then any LostFocus quickevent is triggered, then promoted events, etc.

When a control lostfocus event processing, and the user changes focus to some other window, the event processing can be circumvented and executed correctly by:

1) Surrounding the control's lostfocus handler with the code

NewFocus=Get_Property( Window, "FOCUS" )

If Self NE NewFocus Then

• put lostfocus handler code here….

End

2) Promoting the Gotfocus event for Window controls, and using the code

PROMOTED_GOTFOCUS( CtrlEntID, CtrlClassID, PrevFocusID )

If PrevFocusID NE CtrlEntId Then

Status=Send_Event( PrevFocusID, "LOSTFOCUS" )

End

Then the control's lostfocus event code is triggered only if the control really lost focus WHEN PROCESSING WITHIN ITS FORM.

However, if the control has data validation, the data validation will fire off as soon as the control loses focus, come what may. The same issue exists with Read on LostFocus, etc.

I realize that some developers might be upset if the OI lostfocus processing were fixed to fire off only when losing focus WITHIN THE FORM. What do other developers think on this issue?

Gerald,

I think this might solve your problem with LOSTFOCUS…

The "LOSTFOCUS" event has 4 arguments…

1) CTRLENTID

2) CTRLCLASSID

3) FLAG

4) FOCUSID

The "FLAG" argument values are as follows…

0) Focus has moved to another application window.

1) Focus has moved to another OI control.

2) Lostfocus generated as a response to a menu event.

So if you were to check the "FLAG" argument you can eliminate your problem. Maybe something like this… if the "FLAG" variable is not equal to 1 then exit the lostfocus proceedure with a value of 1. Note that the return value of "1" is so that the "event processing" can continue.

IF FLAG NE 1 THEN

RETURN 1

END

Thanks, Richard.

I do know about the Flag parameter, which can be used in quick events coded within the form scripts. However, this does not solve problems with lostfocus READ or data validation.

So what I am asking is, should OI be changed to provide the correct processing sequence for lostfocus? Of course, I say yes, but I want to know if other developers agree or disagree. How about you?

Gerald

So what I am asking is, should OI be changed to provide the correct processing sequence for lostfocus? Of course, I say yes, but I want to know if other developers agree or disagree. How about you?

In a word, no, I don't agree. There are many known issues that would be nice if fixed. However, as you hinted at in your original post, this would be a major problem for existing OI applications. Revelation has a long standing and firm policy to not "fix" problems when they have been around for a while and expected to have workarounds.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

Thank you for the response. Just because there might be a workaround for a bug, does not mean it should not be fixed, of course. Here, I am not totally convinced that OI's behavior is a bug. I am hoping someone will come up and say, "and here's why OI should behave the way it does."

Gerald

Gerald

There may be an instance where you want the lostfocus event to fire when a form is inactivated (I havn't come across one yet). Using the 'flag' parameter (I suggest in a promoted lostfocus event) ensures that all possibilities are covered.

That's one argument that might suggest it's by design rather than a bug.

Bob Watson

View this thread on the forum...