I have a bound form and would like to prevent the Read Event from firing when the Key control (default=%SEQKEY%") has lostfocus but the focus is going to be another window.

If I set the retVal to 0 it does prevent the Read Event but the Lostfocus event does not refire when returning to the Window and moving to the next control? Setting to 1 will process the Read Event when I do not want to.

John

John,

I have promoted LOSTFOCUS, GOTFOCUS, and READ events which handle this. The general idea is that the LOSTFOCUS event has a parameter which indicates whether a control in a window lost focus, of if the focus went to another window or another application. If the window lost focus, I put the focus control name in a UDP. Then on GOTFOCUS, I check the UDP to determine if the window is receiving focus, and clear the UDP. If a different control receives focus, I perform a LOSTFOCUS of the control name saved in the UDP. READ processing is yet a bit more complex, but you could figure it out from the description above. Or, ask to see the ATLAS framework source code.

John

we handle this in our 'lostfocus' event in commuter module like below .. note that the case statement filters out the controls that either 'are us' (cur control) or other controls we don't want stuff happening on. on a key field we would put the 'read' in the 'case 1' section.

lostfocus:

continue=TRUE$ ;* expecting to go on

begin case

case control=EDL_CUSTNBR'

/*

abstract: on lostfocus perform various actions

incoming:

outgoing: ans set according to function

internal: msgDsiplay

external:

*/

*check next control .. we might be exiting .. or Lookup

nextCtrl=get_property(@window,'FOCUS')

begin case

case nextCtrl=ctrlEntId

* again .. do nothing .. probably returning from other

* window ..

case nextCtrl=window:'.PUB_LOOKUP_CUSTOMER'

* do nothing .. the button event chain should handle it

case nextCtrl=window:'.PUB_CLEAR'

* do nothing .. the button event chain should handle it

case nextCtrl=window:'.PUB_CLOSE'

* do nothing .. the button event chain should handle it

case nextCtrl=window:'.PUB_SAVE'

* do nothing .. the button event chain should handle it

case 1

* any other control forces the validate ..

*** do the processing

end case

return

Dave,

What happens in your code when the focus control on the return is not the same as when the user left the window? Don't you lose the LOSTFOCUS?

John,

Gerald's method is generally what we do as well. To simplify matters we would clear the default value that is in the Key ID control. That way, if focus returns to this window and control, the default logic will execute again and when the end user leaves the control then the LOSTFOCUS-]READ event chain will execute normally.

We also do something similar when the window is being minimized, which causes a LOSTFOCUS event to execute. So, our LOSTFOCUS event (which is promoted like Gerald's) always checks to see if the form is minimized. If so, then we clear the Key ID control and wait for the form to be restored.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

I don't think so .. we have been using this code for a while .. BUT i might have cut out the wrong section

FWIW, I can't duplicate this in 7.2, but that's using SEQKEY, not %SEQKEY%, in case they are different.

But, in general, databound forms do not always do all of their processing logic of the GOTFOCUS_VALUE prompt is the same as current prompt, because then nothing has changed, so perhaps a little modification on a gotfocus might be all the code you need.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Dave,

I was being polite, but I guess I'm not good at it. Your note implied that John need only worry about LOSTFOCUS, and I wanted to show that GOTFOCUS is involved as well. But then, if GOTFOCUS is involved, your LOSTFOCUS code would have to save the prevfocus control name somewhere so that GOTFOCUS could use it.

Don Bakke points out that many of us have written code to fix this exact problem, and we seem to expect that each new developer will write this same code. I appreciate your candor in showing your code. Similarly, I have offered to make the ATLAS framework open source, so that all OI developers would have access to (I hope) decent code solving this and a host of other problems. Then developers could focus on the real application problems they want to solve…. better stop now, I'm starting to rant….

I use a modification of Don's code (also promoted lostfocus) and just check to see if the focus is a pushbutton type or a different window (turns out that minimizing is just a special case of moving to a different window - so my code replaced some of Don's logic and handles both with one test). I could be wrong, but checking the gotfocus and read events, I didn't really see any extra logic to handle this (but they do additional things).

Of course, the lostfocus event does other things (like making sure you aren't trying to move off a key field except to another key field, if any key fields are blank - which prevents read errors with missing key parts, etc).

rant ?? i don't believe either of us could be accused of ranting

View this thread on the Works forum...