External file changes on open edit sessions

Hi George,

I think the reason for your scenario isn't showing the error is that when you switch to Explorer, the SPFLite window loses focus.

When SPFLite regains it, you have an implicit ATTN event, so you never get the chance to press PF3.

In my case, the file is deleted by another process running at the same time. (yes, sorry... I'm pushing the envelope again).
So SPFLite remains the 'active' window and retains focus at all times.

The sequence of events is...

- I have a file open for editing - SPFLite has the input focus.
- The file in question is deleted by an external process, SPFlite still has the input focus.
- The next SPFLITE 'ATTN' event is caused by me, having realised that the file has gone, pressing PF3 (END).
- The current edit session / tab is closed as expected and I'm left looking at the previous edit tab.
- At the same time, the 'File may have been modified or Deleted. SPFLite cannot determine which" pop-up appears.
- I click OK (the only option)
- The Crash Intercept Pop-up appears, "...execution exception (C005) Select OK to attempt to save modified data..."
- I click OK.
- If there are other modified edit tabs open, another pop-up informs me of their 'crashsave' status and I click OK again.
- SPFLite closes.

The crash isn't a huge disaster because CrashSave does at least secure the other open tabs. That's good, but probably unreliable.

In my case, modifications in open tabs are often incomplete/inconsistent at the time SPFLite crashes.

Hi George,

I've just switched to latest release v22066.

I note you list "Add additional validation to internal pointers in the Tab removal process." in the change log.

If that relates to this crash bug, it hasn't fixed the problem.

(1) When I have an EDIT tab open (modified or not) AND

(2) an external process deletes the file being edited AND

(3) the next thing the user does is issue END command THEN

(4) the "...may have been modified or Deleted, SPFLite cannot determine which." pop-up occurs.

(5) The user dismissing (<OK>) the pop-up is immediately folllowed by an SPFLite crash.

Note that the pop-up in (4) only appears AFTER the user issued END command, causing the first Attn event in SPFLite since the deletion took place.

In my case, the file deletion is caused by an external program removing a temporary file, which I happen to have open in SPFLite.

I agree that I can avoid this with improved scheduling of the the external process and the SPFLite session, so it is unlikely to be a big problem for other users.

I also note that if I modify the file during the edit session, the END command (AUTOSAVE ON) works correctly, i.e. although the file HAS BEEN deleted, SPFLite SAVEs a new copy.

From my layman's perspective, the issue seems to be EITHER

 - The POP_Up Event code: What changes does this make internally other than pop-up the '...can't determine which...' panel?  OR

 - The Tab Removal Process: Which presumably occurs after the AUTOSAVE, if any.

I figure it is most probably the former, because why would the Tab Removal process process care if the file exists or not? SPFLite crashes in both caases.