CodeSnip crashes after resume from hibernation

[delphidabbler]

When CodeSnip is running and Windows is hibernated and resumed CodeSnip crashes with an unrecoverable exception.

Selecting "Terminate" sometimes results in an endless loop and the process has to be killed with task manager.

[delphidabbler]

This is a long standing, intractable bug. Dunno why it didn't make it into issues until now.

I suspect it's something to do with the web browser control, but haven't confirmed it. (❌😊 probably not see #70 (comment))

[delphidabbler]

Just tried 5 hibernations with CodeSnip running from the Delphi XE debugger and stand-alone and not a single crash.

⚠️ This is going to be hard to track down!

[delphidabbler]

Crash happened today while debugging.

A stack trace indicates that that exception is a fault reading a zero pointer in the Overview pane. The culprit would appear to be an IView (non)instance.

I think I'd never selected anything in the Overview pane before the crash, which could explain the null pointer exception.

[delphidabbler]

Had another crash under the debugger.

Crash is reported as occurring in line

Result := ViewItem.IsUserDefined;

Stack trace is (method followed by indented line in method, where available), with method raising exception listed at top:

TOverviewFrame.TTVDraw.IsUserDefinedNode
    Result := ViewItem.IsUserDefined;
TSnippetsTVDraw.CustomDrawItem
    TV.Canvas.Font.Color :=
      Preferences.DBHeadingColours[IsUserDefinedNode(Node)];
TCustomTreeView.CustomDrawItem
TCustomTreeView.CNNotify
TControl.WndProc
TWinControl.WndProc
TCustomTreeView.WndProc
DoControlMsg
TWinControl.WndProc
TWinControl.MainWndProc
StdWndProc
{various calls into user32 & common controls library}
TWinControl.DefaultHandler
TWinControl.WndProc
TCustomTreeView.WndProc
StdWinProc
{various calls into user32}
TTreeNode.SetText
TTreeNodes.ReadNodeData
TCustomTreeView.CreateWnd
TWinControl.CreateHandle
TWinControl.UpdateControlState
TWinControl.CMRecreateWnd
TControl.WndProc
TWinControl.WndProc
TCustomTreeView.WndProc
TWinControl.RecreateWnd
TWinControl.WndProc
TCustomTreeView.WndProc

[delphidabbler]

It seems that the problem is that, sometimes (not always) Windows recreates the tree view displayed in the overview pane and all its nodes. The tree view nodes are custom classes that have a property that reference an IView instance relating to the displayed items. Unfortunately when Windows recreates the nodes the IView property is set to nil.

This explains the nil IView references that have been causing the access violation.

The solution used in the fix is to handle the Windows messages sent when the computer hibernates and resumes. On hibernation the state of the tree view is recorded. On restoration we assume that the tree view is corrupted and so forcibly rebuild it and restore the saved state.

There is a problem thought. The message we handle is issued twice after resuming from hibernation. There is no easy way to tell which message has been issued. Therefore the tree view is rebuilt twice. There is not much performance penalty to this, so we can let it go. The potential problem is that if the tree view is recreated it happens after the 1st message and before the 2nd. Should, for example, the message only be triggered once then the bug will be back!

Even after all this it is possible that the program will redraw the tree view before the IView instances are restored. I've added code to the tree node custom drawing code to test if a node's IView instance is nil. This leads to some nodes not being drawn correctly. However, this doesn't matter because the tree view is forcibly redrawn again after the IView instances are restored.

All in all, I've not totally happy with this solution, which is more of a work around than a fix, but it's the best I can come up with without completely revising the overview frame code.

This fix was implemented at commit 58be37c.

[delphidabbler]

Just tried 5 hibernations with CodeSnip running from the Delphi XE debugger and stand-alone and not a single crash.

To replicate I can force this by closing and opening the lid of my laptop, then hibernating it and restoring using the power button. This is strange because closing the lid is configured to do nothing!