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 20 JUL 1999 11:19:19AM Donald Bakke wrote:

As time goes on, some of our users have become quite adept at using our systems and have become pretty quick at data entry…perhaps too quick. Many, if not most, of our forms have a SEQKEY set. Normally when the user presses the enter key all goes well, i.e. the cursor moves to the next control and the window's title displays "" at the top.

However, occasionally the latter process doesn't happen. The SEQKEY appears in the key, the cursor moves to the next control, but the window title doesn't say "" and other signs that the READ event didn't fire are also evident. For example, some of our forms use promoted READ events to enable/disable Save buttons and menus. So when the READ event doesn't fire (promoted and system level) the form won't show the normal behavour of enabling the Save buttons and menus and showing "" in the title.

What can we do about this? How is it that the READ event can be suppressed this way? We would appreciate any ideas on this.

Thanks,

[email protected]

SRP Computer Solutions


At 20 JUL 1999 07:09PM Cameron Purdy wrote:

Don,

I do not know based on your description, but I have forwarded the question to Gene.

Cameron Purdy

Revelation Software


At 21 JUL 1999 09:22AM Gene Gleyzer wrote:

Don,

The SEQKEY processing happens on GOTFOCUS event for a corresponding field in a case when the field is empty. The READ event gets fired out of LOSTFOCUS event for a non-empty key field. It's quite possible for LOSTFOCUS event be delayed (queued) because of the SEQKEY processing (which may perform a couple of relatively expensive IO operation). However, the only way for LOSTFOCUS to be killed is calling Utility("FLUSH") or Set_Property("SYSTEM", "BLOCK_EVENTS", TRUE$). Could you check whether your generic event handlers for GOTFOCUS (or any MFS for the data file) do any of those requests? If not, I would need to have some reproducible (or at least likely to happen) scenario to figure this out…

Gene


At 21 JUL 1999 03:16PM Donald Bakke wrote:

Hi Gene,

I can tell you with absolute confidence that neither of those two processes are used in our application. This problem is easily reproducible on a very simple form with a SEQKEY set. The trick is to enter one row and immediately after saving the record (i.e. pressing F9, for instance) start pressing the enter key. The default key will appear (as you described it would) and the cursor will move to the next control, but somehow the READ doesn't fire. So if all you need is a way to duplicate the problem in order to look at it some more that should do it for you.

Thanks,

[email protected]

SRP Computer Solutions


At 27 JUL 1999 10:29AM Donald Bakke wrote:

Hi Gene,

I was wondering if you have had any progress on this issue. At the very least, have you been able to duplicate the problem?

Thanks,

[email protected]

SRP Computer Solutions

View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/971b04c9244d1524852567b400542aa4.txt
  • Last modified: 2023/12/30 11:57
  • by 127.0.0.1