Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 24 JUN 2021 09:39:02PM Gerry Van Niekerk wrote:

OI 10.08.01

If you have a lostfocus quickevent in a form and the priority is set to true (or false for that matter)

why does the gotfocus event for the next prompt fire when I am not finish with the current lostfocust checking

the next PROMPT is an edit table.

Confused..

Gerry


At 25 JUN 2021 05:40AM Carl Pates wrote:

Gerry - what is in your LOSTFOCUS event?

Regards

Carl Pates


At 25 JUN 2021 06:11AM Gerry Van Niekerk wrote:

We check

Old value and current value

And if not the same call a msg

Continue or not,

While in the msg the next prompt focus fires

Had another prompt on same form where we also

call msg asking if the value is correct and the next

prompts value gets filled in while the msg is up

So seems when you call a msg the focus carries on.

From memory this was a similar problem way back in beta

Hope it makes sense

Gerry


At 25 JUN 2021 07:23AM Carl Pates wrote:

Hi Gerry,

I've just checked a copy of v9 and I see the same thing:

1) EDITLINE_1 has a LOSTFOCUS event that displays a message

2) EDITLINE_2 has a "default" value to insert a literal string when it gets the focus

Moving from 1 to 2 displays the message, but inserts the default value in EDITLINE_2 as well.

Same result if I put something in the validation property like a date validation.

This is as expected - events, by default, are asynchronous. So when you move from the first control to the next control:

1) Windows generates a WM_KILLFOCUS message for EDITLINE_1.

2) The PS translates this to a LOSTFOCUS event and places it in the event queue

3) EDITLINE_2 gets the focus

4) Windows generates a WM_SETFOCUS message

5) The PS translates this to a GOTFOCUS event and places it in the event queue

6) The PS checks the event queue and pulls off the LOSTFOCUS event, and executes it

7) You display a message in the LOSTFOCUS event

8) The message waits for you to do something - while this is happening the PS processes it's message queue, which in turn tells it that there's something in the event queue

9) It finds the GOTFOCUS event and executes it.

10) Eventually you dismiss the message and your LOSTFOCUS handler returns.

etc…

So, if you're going to display a message and you want to stop anything else happening you need to do what we do in the validation handler and clear the event queue before the message displays - here's the code we use:

   if validFlag else

      if status() <> 3 then

         * // status() = 3 is a special protocol for user conversions

         * // to suppress system error messages

         

         * // Chances are we've got a GOTFOCUS event in the queue that

         * // will get executed after this has finished, and this *might*

         * // trigger something like a DEFAULT process which means it 

         * // would get executed even though the focus has been shifted

         * // back.

         call exec_Method( "SYSTEM", "FLUSH" )



         statx = send_event( ctlId, "VALIDERR", ctlData : @fm : ctlValid : @fm : ctlValidMsg )

      end

   end

Regards

Carl

Carl Pates


At 25 JUN 2021 05:37PM Gerry Van Niekerk wrote:

Thanks. Carl

This is in my Arev conversion

Will try as above

Thx

Gerry

View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/41afc96f9299c447aafffb87d159454d.txt
  • Last modified: 2024/01/04 20:57
  • by 127.0.0.1