>>>I've spent some time tracing thru the code. It seems to me that the view not only has to be open, but also has to be the currently selected work area for the form to release properly. Is this right? Because for this one particular form, at release, the view is not in the currently selected work area.
>>>
>>>BTW, it doesn't happen if I close the form before exiting the app. It only happens when I do a Save after selecting exit from the menu.
>>>
>>>Thanks for all the help.
>>>
>>>Marcia.
>>
>>
>>I don't believe that the view has to be the currently selected work area. I think you have narrowed the problem down when it only happens using the menu exit and not when closing the form normally. I think this is a pretty common problem although different people can create it in different ways.
>>
>>Here is what I would suspect (being so far away and not seeing the code!) In your normal processing of the form, you do not close the form while a save is in progress. This is maybe handled by code from a close button or something (????). However, if the exit option from the menu is selected, it automatically tries to close the form without going through some 'prevent' code. Now, somewhere in the shutdown of your form, it realizes it shouldn't be closed without a save and so it calls the save routine. However, by this time, the release code in the form has already executed (although the form is still there!) That is, your form save method will not work if the release method has been called first!
>>
>>My first thoughts are to check the code in Release, Destroy and QueryUnload. QueryUnload is probably the routine you should call from the menu option, not release. I suggest this for the sake of consistency, because the standard window close (x, or whatever name it has) calls queryunload when selected. QueryUnload should call release. This wall all close options (button, x, menu) will be routed through the same code.
>>
>>Suppose your form is in edit or add mode and you choose the menu exit option. This tries to close the form which prompts you with a message do you want to save (yes or no). You choose yes, but the validation routines you have built in say there are problems with the data, go back and edit (maybe you have missing fields?) So now you are back in edit mode while your menu option is still trying to shutdown the system!
>>
>>What I have tried to do in my applications is to loop through all open forms, trying to close them (If queryunload returns true, release the form). If any forms queryunload returns false, I exit my quit routine without closing anything else. So I might close some forms, but not all because I've been told the user can't quit yet (and they probably received a message from queryunload that they form couldn't close yet).
>>
>>Once again, if you trace the sequence of events when you close okay, and when you close from the menu, there is likely a difference in the execution routines. You can even set event tracking (remove all the mouse stuff, paint etc) and you will see which events fire when.
>>
>>Hope this helps!
>Hi Bob.
>
>Thank you so much for trying to help me figure this out. I'm sorry, but I gave you some bad info...the problem DOES occur when I close the form using the 'x'. If I exit the form without making any changes, the error never occurs. It only occurs when I have pending changes and exit the form. If I save, my save method code executes just fine. BTW, if I change the datasession to default, rather than private, the problem goes away. After the last 2 days of trying to debug this, I am ready to go back to teaching shop in the junior high school...less stressful, ya know. Oh, one more piece of info...I have another form based on a different local view but on the same form class that works with no problem. The only difference is that the form that works takes its data from 2 base tables and the one with the problem takes its data from 3. Any ideas are gratefully accepted.
>
>Marcia

I have a couple of questions that hopefully will narrow things down.

1. You mentioned that closing with the 'x' with pending changes causes the same problem. Does this occur when you close with pending changes from a close button (or is the only available close at this time from the 'x')?

2. If you have a close button, what methods does it call?

3. Can you close the form normally if there are pending changes or is the option to do so unavailable (except with the 'x')?


Here's what I think. The problem is not the views or the private/default datasession. The problem is the release sequence that is being upset when there are pending changes. The private datasession may have been closed by the form before all of the validations that use the tables have fired. Because of the pending changes and the sequence of events, they do not happen in the right order.

If you create a log list of events (using the debug event tracking) when the form closes fine, and then again when the problem surfaces, you will probably see a method execute when you wouldn't think it should. Let me know if you need help using the event tracker (or just follow the shutdown with trace).

I have a rule that might be appropriate here:

If you've done everything right and it still doesn't work, then something you've done right is wrong.

That is, it may be time to look at things that are right and not the ones you suspect are wrong!