Long running bug fixed in CodeSnip v4.24.1

This has been a  l o n g  time coming.

For several years a nasty access violation bug has been lurking inside CodeSnip. It crashed the program when the computer was resumed from hibernation, but only sometimes. Because the bug was intermittent and required numerous hibernation / resume cycles to be run before it finally cropped up it defied diagnosis for a long, long time.

Until now. Or up until someone finds my fix doesn't work for them!

⮞ Get the fix from GitHub EDIT: no, don't get it - I'm releasing a fix for the fix soon. See comments below.

For an explanation of what was causing this little horror of a bug, see the longer post on the CodeSnip Blog.



Comments

  1. Oliver8:11 am

    This comment has been removed by a blog administrator.

    ReplyDelete
    Replies
    1. Delphidabbler10:03 am

      Sorry Oliver - I deleted your comment by mistake when trying to delete a botched reply.

      For reference the comment said:

      "The PBT_APMPOWERSTATUSCHANGE occurs many times even without suspend/standby (on laptops when the battery is full, ac plugged in/out, charging). It would be better to check for the PBT_APMRESUMESUSPEND or PBT_APMRESUMEAUTOMATIC events to handle it"

      Delete
    2. Delphidabbler10:09 am

      Thanks for that Oliver.

      I did try handling PBT_APMRESUMESUSPEND but unfortunately Windows destroys and recreates the tree view after that event is received. I've just tested it and the same goes for PBT_APMRESUMEAUTOMATIC.

      Anyhow, I've taken what you've said about PBT_APMPOWERSTATUSCHANGE on board and have gone back to hacking TTreeView to be able to overload CreateWnd for the existing tree view component.

      I'm now only using PBT_APMSUSPEND to set an event handler that only gets called if Windows destroys and recreates the treeview. The event handler gets called from the hacked CreateWnd only if is called after a resume and if there are nil object references. The event handler redisplays the tree view with all the required object references in place.

      There will be a new blog post once I've tested this hack!

      Delete
    3. Oliver11:13 am

      If made a small test app and I did not get that PBT_APMPOWERSTATUSCHANGE event. But if, as you said, the PBT_APMRESUMEAUTOMATIC occurs before and the PBT_APMPOWERSTATUSCHANGE after the recreation then you could set a flag on the resume event and rebuild the tree after change event only if the flag ist set.

      Delete
    4. Delphidabbler1:37 pm

      Thanks for testing the PBT_xxx messages. Given that you're not getting the same events as me, I'm starting to think it's a little unsafe to rely on PBT_APMPOWERSTATUSCHANGE at all.

      I've been tinkering with numerous OutputDebugString calls and confirmed that the hack of TtreeView is working without relying on PBT_APMPOWERSTATUSCHANGE.

      I'm now wandering if there's a way of not using these events at all. More tests needed!

      Delete
  2. Delphidabbler8:32 am

    This comment has been removed by the author.

    ReplyDelete

Post a Comment

Comments are very welcome, but please don't comment here if:

1) You have a query about, or a bug report for, one of my programs or libraries. Most of my posts contain a link to the relevant repository where there will be an issue tracker you can use.

2) You have a query about any 3rd party programs I feature, please address them to the developer(s) - there will be a link in the post.

3) You're one of the tiny, tiny minority who are aggressive or abusive - in the bin you go and reported you will be!

Thanks

Popular posts from this blog

Initialising dynamic arrays

When writing some unit tests a while ago I found myself needing to initialise some dynamic arrays with test data. It would be nice if we could do something like this: var A : array of Integer ; begin A := ( 1 , 2 , 3 , 4 ) ; // !! WRONG end ; but we can't. So I decided to write some functions to initialise dynamic arrays to the contents of another array, be it a constant, a literal or another dynamic array. The result was a set of overloaded routines, one for each data type I needed to handle, for example for Integer and string arrays I had: function CloneArray ( const A : array of Integer ) : TIntegerDynArray ; overload ; var Idx : Integer ; begin SetLength ( Result , Length ( A ) ) ; for Idx := Low ( A ) to High ( A ) do Result [ Idx - Low ( A ) ] := A [ Idx ] ; end ; function CloneArray ( const A : array of string ) : TStringDynArray ; overload ; var Idx : Integer ; begin SetLength ( Result , Len...
Read more

Deleting elements from a dynamic array

In my blog " Initialising Dynamic Arrays " I mentioned I have been writing some unit tests that needed numerous repetative array initialisation operations. Well, one of the other common operations I found myself writing was the deletion of items from dynamic arrays. So I decided to find a generic way of doing this. Assuming we know the index of the item to be deleted we need the equivalent of Delphi's built-in Delete procedure for strings. If you read the previous post you won't be surprised to learn that I decided to further extend the Generics.Collections.TArray class by adding to the TArrayEx class I introduced there. My first attempt emulates Delphi's Delete procedure by deleting the array element in-place: i.e. it updates the array passed as a parameter. Unsurprisingly the method is called DeleteInPlace . Here's how it goes: type TArrayEx = class ( TArray ) public .. . class procedure DeleteInPlace < T > ( var A : ...
Read more