Solution: Events like On Form Exit cannot run if you are inside custom button code. If you have custom navigation buttons that change which record you are on, those buttons should also perform any tasks normally handled On Form Exit.

I have been fighting an "intermittent" problem for too long!  But I think I may have located the culprit.

I have code in FormName/OnFormExit that does some Audit logging.  Typical lines are like this
Record = @TN(@XLR(........LastRecord +1 stuff
DateEntered = @Date
TimeEntered = @Time
AddedBy = @UserID

But I have run into instances when the code no longer worked.  Double checked, triple checked syntax etc.
Commented out lines, used WriteLn to track process, etc.  And suddenly it works again, for no reason.  Initially I thought it was just an XLR problem, but then realized that none of the code was working.

Well, there's always a reason, and I think I stumbled across the problem tonight.  I need to do more testing, but this is what I found.

If the first line of the programming section is blank, then the code does not run at all.
If I remove the first blank line, then the code runs.
I was able to fix this problem on two forms in an application by removing the blank liine.

The actual format of the programming section was a blank line, followed by a \\commented line, followed by code, like this:

//  Commented line is here, followed by code.  The line above is BLANK
Record = @TN(@XLR(........LastRecord +1 stuff
DateEntered = @Date
TimeEntered = @Time
.....
....
more code
.....
.......
 

I would like to know if anyonel elcs can duplicate this.  Using version 2.0.3, and this code is in FormName/OnFormExit section.  Don't know yet if it is limited to this one section, or just in this application.  I know that it can be duplicated in other databases within this same application.

Also of possible importance, is that this code may have been a result of XML import.  Don't think that should make a difference, but need to find out.

Aaargh.... will have to try different combinations.

Yes, I have navigation buttons, but don't recall whether I was using F9/F10 and/or nav icons at top or nav buttons I put on the form.  I will have to try all three versions with/without the blank line.  Based on you input, I suspect the blank line may have been coincidence, because I was looking so hard for the culprit.

There is a well hidden page for known problems and work arounds at http://www.lantica.com/Support/sesame_workarounds.html  But this has had no additions since 1.1.4.

I think it would be good to  have a section on the forum that contains known issues.  It would be right here, easy to find, and Read Only so only modified by Admiin.  This problem has cost me many hours of lost time.  This is the first I have heard about the F10 with navigation buttons issue.  And I am here every day, how those infrequent users?  

Thanks for the info Carl.

I can't get it to fail either!  I just got back here to change the title of the thread.  Don't want to mislead anyone.

It is obvious that I was using the buttons when it failed and the icons or F10 when it did not.
I just completed some tests using the four buillt in Navigation icons, F9, F10, and the four buttons that I added to the form.  All the built ins worked, but none of my buttons (one of them uses a macro).

This explains the "intermittent" nature of the problem.  Three ways to save a record and two out of three work.  And since the keyboard is easier to use, then the failure mode is probably used less frequently.

And yes, I also am stunned that I don't recall seeing this before.  Ray and I have been working on an intermittent "XLR" problem for days with no solution.  But this is obviously the cause.  I am sure he will be glad to be reminded about this also.

How about the solution?  Will this be in 2.0.4, or do I need to remove the Navigation buttons?  I suppose I could make a SuRoutine from the OnFormExit code, and call the SubRoutine in each of my navigation buttons.  That sounds like it may work.

Re the workaround comments.
1.  I still think that known problems should be listed here as a separate topic on the forum, especially if they don't have a work around.  If not listed here then perhaps a "sticky" with a link to that page.  The sticky item could be updated whenever there is a change to the workarounds page.

2.  I think items like this should be listed even if there is no work around.  There is a work around when you know about the problem.  The work around is "Don't Do This".

Thanks for listening.

Bob_Hansen wrote on Oct 27^th, 2007 at 5:34pm:


Yes, what you describe is what you need to do, as has been detailed in the link I gave you.

This is not a bug that needs to be fixed. It is a behavior of the program. If you take over Sesame's functions using your own command buttons, you need to take over everything that function does, not just part of it. The solution is to perform whatever code tasks need to be performed before leaving the record as part of your navigation button code.

Bob_Hansen wrote on Oct 27^th, 2007 at 6:26pm:

It doesn't check restrictions in SBasic, therefore there is no deferral, although the restriction behavior may interfere with your ability to force SBasic to move to a different record when the restrictions say the record cannot be saved.

Quote:

By the time On Form Enter is triggered, your command button code has usually completed and the event is able to run.

Quote:

It does behave the same way. The difference is that the menu tree is not running inside an SBasic event. Your command button is. This is only a factor if additional twists are thrown in, such as the presence of On Form Exit event code, which many people do not have.

Quote:

I'm sorry that we can't discuss this without such an emotional reaction. The behavior is consistent if you keep in mind that SBasic is not reentrant. If code is triggered while other code is running, it will be deferred until the prior code finishes. If you are no longer on the same record when the deferred code gets to its turn, it does not run to make sure we do not change values on the wrong record. Making a command button that moves to a different record when there is also On Form Exit code is one of many ways to create this condition.  Again, I'm mainly surprised by your vehemence because this behavior and the methods for dealing with it have been around since an early version of 1.x. These days, when we remind people about this one, they generally shrug and say "Oh, yeah."

In general, if you are going to leave a record in code, and you know that you have conditions where you don't want to leave the record, it's a good idea to check those conditions before instructing Sesame to leave the record.