Revelation,

We submitted this post regarding READ event failures last July. This issue still continues to be a problem and we have not heard of any new progress on your part since our last interchange. Please update us on the status of this since this is causing our clients understandable frustration with their OI application.

Thank you,

SRP Computer Solutions

In the previous posting of this problem, Gene G. had responded:

"I would need to have some reproducible (or at least likely to happen) scenario to figure this out…"

Could you post this info? Thanx.

RevSoft Tech Support

Don:

I started with OI 3.71, no promoted events. I made a simple table with two fields, painted a form with two prompts, the first one a seqkey.

By hammering on the f9 key I am able to get the message 'ALL KEY VALUES ARE EMPTY'. This tells me that I m breaking into the event chain while the lostfocus/seqkey stuff is firing. I'll bet there is a Yield() in the code, perhaps lock else loop Yield()…repeat on the %SK% part. I'll try to find that out.

Bob

That information was already provided in the response to that very request. However, it appears that Bob from WinWin was able to duplicate the problem so I assume the matter is being brought to the next level.

Thank you very much for your quick reply.

SRP Computer Solutions

Bob,

Thank you for duplicating the issue and for your investigation into the problem. We are eager to hear about your findings.

SRP Computer Solutions

Don-

The code providing the default looks straightforward-

(paraphrased)

Call utility('CURSOR', 'H')

gosub get.seq.no

IF LEN(SEQ.NO) THEN

    ctlData=SEQ.NO

    NEW.NO=ctlData

    FLAG=1

    LOOP

        READ REC FROM File, ctlData THEN

            IF FLAG=1 THEN

                NEW.NO += 1

            END

        END ELSE

            IF FLAG=1 THEN

                IF NEW.NO ] SEQ.NO THEN

                    WRITE NEW.NO TO Dict,SEQ.KEY else

                    end

                END

                FLAG=2

            END

            LOCK File, ctlData THEN

               FLAG=FALSE$

            END

        END

    WHILE FLAG

        ctlData += 1

    REPEAT

    UNLOCK File, ctlData else

    end

END

UNLOCK Dict,SEQ.KEY else

end

Call utility('CURSOR', 'A')

Either the read and write are taking too long, or the Utility call allows a yield() into the mix.

Hope it helps-

Mike Ruane

Mike/Revelation Support,

What you provided is interesting but the real help would be a fix to the problem. Please correct us if we are wrong here but this is how we, as a multiple Works Revelation customer, expect things to work:

1. If this is a legitimate bug in the system then a fix should be provided. At the very least we should be told that this has been acknowledged and will be put into the SPR so we can track its progress. Since it seems that you have confirmed this to be a bug then we believe this should be the response we get.

2. If this is not a bug, but rather a feature or change in normal behavior that we are requesting, then what you have provided might be helpful.

If this is all we receive then it appears that we are being told: "Yes, this is a bug and here is the pseudo code to help you understand why it's a bug. However, the only way to fix this would be to provide your own workaround." This kind of response does not seem appropriate to the nature of the problem and the consequences it causes end users.

If we are being too hasty with this then we apologize. Our fear is that this is the end of the discussion but we would really like something more useful. Even if we were told this has been put into the SPR but it has too low of a priority to get taken care of any time soon then at least point us into a direction where we can fix the problem ourselves in the right way. For instance, should/can we simply replace the GET_SEQKEY routine to fix the problem? Are there calls to other routines that need to be replaced as well? If the problem is due to the Yield() statement will removing this cause other problems to occur? These are questions that are difficult to tell without the same access to the source that you have. Hopefully we can work together to quickly fix the problem.

Thank you,

SRP Computer Solutions

Don-

Sorry if my answer wasn't satisfactory- let me try to explain better.

We've been through the code and didn't see any yield() or errors. I would make the call that this is a feature and not a bug.

The behavior results from the conflicting goals of procedurally determining the next available key, and the results of an event driven action.

Resolving this (from you, the developer's point of view ) could be accomplished by making the window more modal, or by creating your own SeqKey type routine, or by writing more defensive event handlers- (e.g. on the write event, put in a check for the existence of a key, and do a return 0 or 1 accordingly).

We would reccommend that last approach as the most effective strategy in an event driven environment. Each event should measure the state of the system and respond appropriately.

Meanwhile, the issue has been entered in the SPR and is slated for review in a future release of OI.

Hope this helps a little more-

Mike Ruane

Mike,

Thank you for your additional comments. We will attempt to work around it for the time being based on your information.

However, we would like to understand this statement a little more:

I would make the call that this is a feature and not a bug…The behavior results from the conflicting goals of procedurally determining the next available key, and the results of an event driven action.

It seems to us that being able to accept the next default key and input data into a screen without any complications does not constitute a "feature". Please remember that this is a problem with the simplest screens (i.e. no promoted events, no fancy buttons, etc.) as Bob's earlier post affirmed. Are we missing something?

SRP Computer Solutions

]] … Are we missing something?

Don the answer is "I think so", and I include myself in the "we".

In Arev I used to complain about the fact that a user could not interrupt a long running select.

Here we have a situation where the user CAN interrupt a "long running" get_next_key.

It is long running in that it takes longer to come back than

the user takes to punch the next key.

The "something" is whether I want to enforce a procedural sequence – do not listen to events until seqkey stops running –

or architect for an event driven application, where I allow the user to generate events at will while I code event handlers to

respond appropriately. There is not a right or wrong answer here. Procedural code is easier on the developer, Event-Driven code is easier on the user.

In the case of SEQKEY it seems obvious that the thing should fill out before the next event is completed.

We have reviewed the code behind the lostfocus and cannot find any special manipulation of the event chain.

To accomplish the goal of holding off other events while filling in the seqkey WOULD require messing with the event chain.

In my experience I have found that when the need to write a lot of code on an event handler to make sure it is accomplishes a function is often a symptom that the

function belongs on a different event. Filling in the sequential key with a GotFocus, OI's default behaviour, is a carryover from Arev.

Perhaps filling it as part of the write event is more appropriate.

I do not have a right or wrong approach.

I think you have found a profound/subtle example where

assumptions we ( and OpenInsight) carry from Arev cause problems in the windows environment.

Hope this helps.

Bob

P.S

I believe the QWERTY keyboard is the first attempt by a developer to prevent users from firing events faster than the system can hadle them.

Wouldn't BLOCK_EVENTS handle any stray events?

The Sprezzatura Group

World leaders in all things RevSoft

Good Idea.

Block events helps.

I tried it with my simple window.

In gotfocus of my control I put

was=Set_Property("SYSTEM","BLOCK_EVENTS",1)

call Forward_Event()

was=Set_Property("SYSTEM","BLOCK_EVENTS",0)

Tested window.

Hit f9 many times.

Took longer, but was able to get 'ALL key values are empty'

Edited write event, added

IF len(Get_Property(CtrlEntId,'ID')) else

  return 0

end

Stopped getting message. Defensive coding of write event solved my test window's problem, but not Don's problem.

I think the general lesson is that events scripts need to fend for themselves.

For SEQKEY I will fool around with different approaches. Welcome all contributions.

Hope this helps

Bob

[notag]What Mike is saying is that the original designers of the product [<I>specifically designed</I>] the sequential counter not to work. Hence this is a feature. A bug is an [<I>unintended</I>] feature. As FOLDOC says a bug is [<I>An unwanted and unintended property of a program or piece of hardware, especially one that causes it to malfunction. </I>].

Althought to be fair he may be using FOLDOC's sixth definition of feature, namely [<I>A bug that has been documented. To call something a feature sometimes means the author of the program did not consider the particular case, and that the program responded in a way that was unexpected but not strictly incorrect. A standard joke is that a bug can be turned into a feature simply by documenting it (then theoretically no one can complain about it because it's in the manual), or even by simply declaring it to be good. "That's not a bug, that's a feature!" is a common catch-phrase. Apparently there is a Volkswagen Beetle in San Francisco whose license plate reads "FEATURE". </I>]

We however come down firmly on the side of this being a bug and describing it as a feature being a euphemism for "Don't expect it to be fixed in the forseeable future".

[<A HREF="http://www.sprezzatura.com" onMouseOver="window.status='Click here to visit our web site?';return(true)">The Sprezzatura Group</A>]

[<I>World Leaders in all things RevSoft</I>]

[<img src="http://www.sprezzatura.com/zz.gif">]

[<script language="javascript">function openNewPage () {window.location.href=(document.TOCNavigator.pageToGoTo.options[document.TOCNavigator.pageToGoTo.selectedIndex].value);document.TOCNavigator.pageToGoTo.selectedIndex="0";}end hiding from non-JS browsers –></script>] [<FORM ACTION "" METHOD=GET NAME="TOCNavigator" <SELECT NAME="pageToGoTo" SIZE=1 onChange="openNewPage()"> <OPTION>Pull down this menu to choose whereabouts on the Sprezz site to go <OPTION VALUE="http://www.sprezzatura.com">Home Page <OPTION VALUE="http://www.sprezzatura.com/whatsnew.htm">What's New <OPTION VALUE="http://www.sprezzatura.com/senl.htm">SENL <OPTION VALUE="http://www.sprezzatura.com/patches.htm">Download S/LIST <OPTION VALUE="mailto:[email protected]">Send mail to support at Sprezzatura <OPTION VALUE="mailto:[email protected]">Send mail to sales at Sprezzatura </SELECT> </FORM>][/notag] </QUOTE> —- === At 03 APR 2000 09:18AM Mike Ruane wrote: === <QUOTE>Actually, I am not saying "that the original designers of the product specifically designed the sequential counter not to work". Far from it. It would seem to me that there are thousands (tens of thousands?) of SEQKEY defaults working in OpenInsight forms that work correctly. Any disagreements with that presumption? There are certain cases where the SEQKEY is impractical to use, for one reason or another. Don's case is one of them. His users apparently enter data faster that the SEQKEY logic and code can keep up with. By adapting his code he can meet his users needs. Mike Ruane </QUOTE> —- === At 03 APR 2000 09:34AM Donald Bakke wrote: === <QUOTE>Mike, It would seem to me that there are thousands (tens of thousands?) of SEQKEY defaults working in OpenInsight forms that work correctly. If all it required were the users of these applications to start entering their data faster to cause the problem then we would have to say that none of them work correctly. We doubt seriously that the Revelation programmers knew that this was the expected behavior from the beginning. Otherwise we should have been told somewhere that the use of SEQKEY is only guaranteed to work normally if the end users do not input their data too fast. Then nobody would would have found this to be an adequate tool for who wants to worry about the possibility that their users might eventually get really familiar with the system and start breaking it by working too quickly? We would be in complete agreement with you if this problem was caused by the interference of custom event programming on our part but that isn't the case here. SRP Computer Solutions </QUOTE> —- === At 03 APR 2000 02:42PM Bob Carten wrote: === <QUOTE>Don: Uncle. Let's call it a bug. As Mike posted earlier the issue has been logged and slated for review in a future release. Because neither Mike nor I found an obvious problem in the code and 'BLOCK_EVENTS' does not prevent the problem, I don't think a quick fix is coming. Bob. </QUOTE> —- === At 03 APR 2000 02:56PM Donald Bakke wrote: === <QUOTE>Bob, Well a moral victory is better than nothing at all! Actually, we made the assumption that even though this was logged that a quick fix would be be arriving soon either way. We also want you and Mike to know very clearly that we do value your efforts in looking into this problem and that we know that issues or priority are out of our domain. Perhaps one issue you can answer rather quickly would be helpful: Is GET_SEQKEY the routine that gets called by OI? Can we write a replacement routine for this and just return the next sequential key as a function and have this work the same way. (BTW, we understand that nothing in the GET_SEQKEY may force this to work but we are willing to try.) Thanks, SRP Computer Solutions </QUOTE> —- === At 03 APR 2000 06:49PM Bob Carten wrote: === <QUOTE>Don: There is no system program called get_seqkey. The seqkey code is buried as Gosubs in oiwin_gotfocus, which is called by the system event handler SYSPROG*GOTFOCUS..OIWIN. I thought we might be able to wrap around that code , if default is SEQKEY then call my_focus else call oi_focus This looks impractical, though, because oiwin_gotfocus is doing more than just defaulting. I also see where the semantic logic layer plays with gotfocus events after a read. I recommend leaving the gotfocus code as is. It is easy enough to write your own function and call that instead. There is one posted from a while back. Search on SEQKEY. it goes like: function get_next_id(CtrlEntId, parameters) declare function UnAssigned, QueryParam, Get_Property * Queryparam is just inet_queryparam except queryparam=request, not request * should throw in a block_events next_id=' If UnAssigned(CtrlEntId) then CtrlEntId=' if Unassigned(parameters) then parameters=' table=QueryParam(parameters,'TABLE') if len(table) else table=Get_Property(CtrlEntId,'TABLE') end if len(table) else return end open table to f_file then open 'DICT.':table to d_file then * Should handle failed lock with delay loop lock d_file,'%SK%' then done=' read next_key from d_file,'%SK%' then loop read test from f_file, next_key then next_key+=1 end else done=1 end until done repeat end unlock d_file, '%SK%' else err=unlock failed' end end else err=lock failed' end end else err=dict open failed' end end else err=file open failed' end if len(err) then Call Set_Status(1,err) return end else return next_id end *** As for where to put the call to your version of the above you can try it instead of SEQKEY the default area – i think you will have the same trouble. In the end I think you will need to code defensively, especially around the gotfocus behavior. Event handlers that need ID filled in will need to check the ID property of the window, as I did with the write event on my simple form. Hope this helps. Bob </QUOTE> —- === At 04 APR 2000 09:44AM The Sprezzatura Group wrote: === <QUOTE>As any long time Revelation developer should know, SEQKEY or %SK% is unreliable at best. Developers have been complaining for years about overwriting records, locking not occuring, sequences out of order and the list goes on. It's one of those known things that most programers have written code around long ago, those little bugs we love to hate and give the product it's special idiosyncracies. The problem is not in this code, which simply returns back a value. The problem would be in either one of the calling routines, which are OIWIN_GOTFOCUS SYSPROG*GOTFOCUS..OIWIN* RUN_EVENT or something in PS. It would seem that since the key is being loaded, something is happening after the gotfocus event is processed and before the lost focus event is processed, since lostfocus would/should generate the read. Perhaps when working too fast, PS is not stacking all its requests or firing requests out of order. The target area for bug hunting should be in sections of the code dealing with the random action OS, not the single threaded, linear OI/OE engine. The Sprezzatura Group World leaders in all things RevSoft[/i]

View this thread on the Works forum...