Running 10.0.8.1 but i have confirmed the same event chain is in v7.3

I have several data bound forms that execute a read event following lost focus on the key field (this is expected and handled at the system level). Immediately following the READ the form is populated and the cursor is moved to the next tab field on the form. This process generates a LOSTFOCUS event on the key field followed by a 'CHANGED' event on the new focus field.

There are no other CHANGED events on fields populated by the READ. It makes no sense to me to have a CHANGED event when the only thing that happened is the data is populated from the record. I would have expected the system to issue a GOTFOCUS event on the field where the cursor is placed.

Is this normal behavior and can it be modified to generate the GOTFOCUS event instead of the CHANGED event ? If not, is it possible to trap a post read event before any other events are issued (so I can issue the GOTFOCUS event within code). Do I have to trap the CHANGED and somehow determine it's from a READ event ?

I'm looking for a generic solution so I don't have to have special code on every data bound form

Thanks

bb

I have several data bound forms that execute a read event following lost focus on the key field (this is expected and handled at the system level). Immediately following the READ the form is populated and the cursor is moved to the next tab field on the form. This process generates a LOSTFOCUS event on the key field followed by a 'CHANGED' event on the new focus field.

So far this is expected behavior.

There are no other CHANGED events on fields populated by the READ. It makes no sense to me to have a CHANGED event when the only thing that happened is the data is populated from the record.

This is not expected behavior. Each control with a CHANGED event handler should get triggered.

I would have expected the system to issue a GOTFOCUS event on the field where the cursor is placed…Is this normal behavior and can it be modified to generate the GOTFOCUS event instead of the CHANGED event ?

No, this is not normal behavior. You should be getting a GOTFOCUS event for the next control as you expected.

I'm looking for a generic solution so I don't have to have special code on every data bound form

Normal behavior is the generic solution you are after. There seems to be something in your system that is causing this unexpected behavior. The typical culprits are:

• Script event handlers that return 0.
• Promoted event handlers that return 0.
• Event which are no longer enforced.

Don Bakke

SRP Computer Solutions, Inc.

Hi Brad,

If you use the Event Spy do you see the GOTFOCUS event being looked for at all?

Running a quick test here I see a GOTFOCUS event as you can see in the following output from the event spy (databound form - 1 key and 3 data edit lines - each of them have a CHANGE event defined):

RUN_EVENT executing : LOSTFOCUS for CP_TEST_ZZDM_CONTACTS_MENU.PK_ID

RUN_EVENT calling:SYSPROG*LOSTFOCUS..OIWIN* ...

RUN_EVENT executing : READ for CP_TEST_ZZDM_CONTACTS_MENU

RUN_EVENT calling:SYSPROG*READ.WINDOW.OIWIN* ...

RUN_EVENT calling:SYSPROG*..OIWIN* ...

RUN_EVENT calling:SYSPROG*..OIWIN* ...

RUN_EVENT executing : GOTFOCUS for CP_TEST_ZZDM_CONTACTS_MENU.TITLE

RUN_EVENT calling:SYSPROG*GOTFOCUS..OIWIN* ...

RUN_EVENT calling:SYSPROG*..OIWIN* ...

RUN_EVENT executing : EDITSTATECHANGED for CP_TEST_ZZDM_CONTACTS_MENU.PK_ID

RUN_EVENT calling:SYSPROG*EDITSTATECHANGED..OIWIN* ...

RUN_EVENT calling:SYSPROG*..OIWIN* ...

RUN_EVENT executing : CHANGED for CP_TEST_ZZDM_CONTACTS_MENU.TITLE

RUN_EVENT calling:SYSPROG*CHANGED*CP_TEST_ZZDM_CONTACTS_MENU.TITLE ...

RUN_EVENT calling:SYSPROG*..OIWIN* ...

RUN_EVENT executing : CHANGED for CP_TEST_ZZDM_CONTACTS_MENU.FORENAME

RUN_EVENT calling:SYSPROG*CHANGED*CP_TEST_ZZDM_CONTACTS_MENU.FORENAME ...

RUN_EVENT calling:SYSPROG*..OIWIN* ...

RUN_EVENT executing : CHANGED for CP_TEST_ZZDM_CONTACTS_MENU.SURNAME

RUN_EVENT calling:SYSPROG*CHANGED*CP_TEST_ZZDM_CONTACTS_MENU.SURNAME ...

RUN_EVENT calling:SYSPROG*..OIWIN* ...

RUN_EVENT executing : LOSTFOCUS for CP_TEST_ZZDM_CONTACTS_MENU.TITLE

RUN_EVENT calling:SYSPROG*LOSTFOCUS..OIWIN* ...

RUN_EVENT calling:SYSPROG*..OIWIN* ...

FYI - The sequence that generates this is:

Windows triggers a WM_KILLFOCUS message which puts a LOSTFOCUS event in the PS event queue

Windows triggers a WM_GOTFOCUS message which puts a GOTFOCUS event in the PS event queue

The PS pulls the LOSTFOCUS event from the queue and executes the READ event (no queuing)

The READ event populates the controls - as each edit field is set Windows triggers an EN_CHANGED notification, which causes the PS to put a CHANGED event in the event queue

The PS pulls the GOTFOCUS event from the queue

The PS pulls each CHANGED event from the queue

As you can see from the above we don't really have a choice about the CHANGED event - it's raised because Windows says so - I'm sure it could be suppressed but it would need some sort of internal flag to stop it, because it would break existing apps otherwise.

Regards

Carl Pates

I learned about a new tool EVENT SPY. Much better and easier way to trace events that using my code. So awesome thanks !!!

Using my new tool I was able to determine the system events flowed as they are supposed to after the READ (including the CHANGED event for each field). This also help explain why the default commute I inherited is written as it is. The event SPY shows the GOTFOCUS event fired at the system level but is not firing my promoted event. This is unrelated to the READ event as it never fires for any field regardless of how it's getting FOCUS. This following trace is click into a field and back out of it.

RUN_EVENT executing : GOTFOCUS for W_MO.MO_NO

RUN_EVENT calling:SYSPROG*GOTFOCUS..OIWIN* …

RUN_EVENT calling:SYSPROG*..OIWIN* …

RUN_EVENT executing : LOSTFOCUS for W_MO.MO_NO

RUN_EVENT calling:ESSEX302*LOSTFOCUS..OIWIN* …

RUN_EVENT calling:SYSPROG*LOSTFOCUS..OIWIN* …

RUN_EVENT calling:SYSPROG*..OIWIN* …

I have a promoted event identical to the LOSTFOCUS set GOTFOCUS but it not being fired. I tried deleting the promoted event and recreating it but that did not resolve the issue. The errant promoted event is set up as "ESSEX302*GOTFOCUS..OIWIN*".

If as Don suggested the GOTFOCUS promoted event is no longer enforced how do I correct it (it's not one I can turn off/on in event designer) ?

As always, thanks in advance.

bb

Hi Brad,

In v10 the GOTFOCUS is enforced by the PS itself, so you can't turn it off. The fact that you have an actual event script for the MO_NO control means that a GOTFOCUS chain will be picked up and executed even if GOTFOCUS wasn't enforced.

(FYI - events are enforced from the Event Configuration dialog which you can find on the IDE Tools/Form Designer menu.)

So we need to find out why ESSEX302*GOTFOCUS..OIWIN* is not being included in the chain for MO_NO. One way to do this is to use the Event Spy to see what it looks for before it decides on the chain of events to use, but this is only done once and is then cached.

You can clear the cache however, and watch what it does when it loads again. What you could try is something like this:

1) Run your W_MO form

2) Go to the System Monitor and turn on the event spy

3) In the system monitor use the "GC" command to purge all of the system caches

4) Click on your control.

5) See what the Event Spy reports it's looking for. Does it mention your missing promoted event at all?

Carl Pates

View this thread on the Works forum...