Crash after Logout

[mmehr2]

Scenario: You've started MSW. You open the Remote Installations dialog and press Connect, but then decide you don't want to. You press Logout and Close. Sometime later, up to 5 minutes or so, MSW crashes.

[mmehr2]

Happened to me in my last testing. This is due to the Subscribe loop's ongoing transaction not being canceled by the disconnection procedures. Should be an easy fix, involving a kDisconnecting state (perhaps) while we wait for the pubnub_cancel() to happen. No freeing of the context should be required if we do everything correctly. This may also require cancellation of publish operations in progress as well, such as the new Script (not File) Transfer feature. (The Rich Edit control contents should be able to be copied directly into my transfer buffer and back, rather than needing a file. Might save some time starting up scroll mode, too.)

[mmehr2]

This was actually fixed in code on Mon 3/19. Forgot to update here. No kDisconnecting implemented so far tho. Lowering priority, converting to enhancement.

[mmehr2]

Work tasks:

• [x] - Design the async interactions and delineate responsibilities.
• [x] -- Implement the PN channel level.
• [x] -- Implement the PN comm level.
• [x] -- Implement the remote comm level.
• [x] -- Implement the UI level.
• [x] - Implement the full kDisconnecting loop so that Login/Logout are state-switched properly.
• [x] - Implement full loop for both Connect and Disconnect state switching.
• [x] - Check the state implementation use in the RemoteDialog class.
• [x] - Gray out buttons during "ing" states so no extra commands are generated (and ignore them anyway). Re-enable on status posting.

[mmehr2]

Description of work: Login and Logout, Connect and Disconnect functions need to be reworked with my new design of separate Sender and Receiver channels in mind. These can be asynchronous sometimes (especially Logout and Disconnect, when an operation is being canceled), so they definitely need to have a decoupled UI in that the buttons that start the function need to be disabled while it is going on. Then at the end, a message is posted to the parent window (of the remote comm class) designating that the operation completed and containing a status code and message. This can be used to re-enable the action buttons and display a status result to the user.

Most of the work is in getting the state machine correct. The UI work should be a simple matter of implementing the disable/re-enable, and then adding a way to display the return status, perhaps with a different status message designed for users.

[mmehr2]

NOTE: Once in a connected conversation, in many cases it may not be necessary (or desirable) to treat every transaction as "modal" as described above. For simplicity and speed, I'll rely on event logging for data, and just signal the UI with a code number. During scrolling, all these would be ignored. During script file transfer phase (preceding scrolling) there may be some benefit of displaying the transfer progress, but this is an extra feature not envisioned for the initial release.

[mmehr2]

This level of activity is now coded and finally working. Closing this, will file bugs as separate issues.