CodeSnip v4.25.0 released (includes a fix of a fix for a fix)

It's nice to be able to release a version of CodeSnip containing new features instead of bug fixes. Except that this release also includes bug fixes, including episode 3 of the hibernation bug fix saga.

So what's new? Not a lot except for some new snippet export options:

  1. For the longest time you've been able to get a copy on the clipboard all the information about a snippet that gets displayed in the detail pane. Now you can finally save the information directly to a file. The only option is Rich Text Format just now, but more formats may make an appearance later.
  2. When exporting Pascal units and annotated snippet source code various formats can be chosen. HTML 5 format export files has now joined the list or plain text, Pascal, RTF and XHTML

Some annoying, but relatively trivial bugs have also been fixed. Go see the change log if you're curious.

But I can't close this post without mentioning the hibernation bug fix saga.

A third fix of the bug where CodeSnip sometimes crashes after hibernation has been rolled into this release. Now this doesn't mean that the previous fixes didn't work - they did. But, as I mentioned in my posts about releases v4.24.1 and v4.24.2, those fixes relied on dirty hacks of which I was ashamed.

So, along comes Oliver (@SirRufo on GitHub) with a patch that fixes the bug without all the hacks. I've gratefully included this patch in this release. No more shame for me! Thanks Oliver.

⮞ Get release v4.25.0 from GitHub

Here's CodeSnip displaying the new Save Snippet Information dialogue box:

And here it is again, showing the new HTML 5 option when saving annotated source code, and showing a preview of a weirdly named, but valid, function that I use to test the rendering of Unicode identifiers:


Comments

  1. Oliver7:44 am

    The problem with the previous fix was that it does not addresses all situations where the TreeView control gets recreated. I have a RDP session and after closing and reconnect I got that exception because of a WM_SYSCOLORCHANGE event. And there are a lot more reasons for that to happen.

    Now this should address any recreation although it feels somehow sus with that pointer in the game ;o)

    ReplyDelete
    Replies
    1. Delphidabbler10:33 am

      That's interesting that things other than hibernation could cause Windows to recreate the tree view. I'd only ever experienced the hibernation related problem.

      I agree that the pointer is a bit dodgy, but it's a much better solution than my original hack, especially given what you've just said.

      I have thought of storing an index into the IView list in the tree node instead of a pointer to the IView instance. But then the data field of the tree node would have to be type cast from Pointer to Integer, which I also don't like to do!! Using indices could cause other problems too.

      Delete
    2. Oliver11:42 am

      The most "natural" way would be using a pointer to a record which then has the valuable values. But that would only make sense when you have more than a single reference to an interface, as there is no difference in managing records in a collection or interface instances. It would only be one layer more for nothing.

      Delete
    3. Delphidabbler1:05 pm

      That's true. Certainly not worth loosing sleep over! Given this program is 20 years old this year and started life with Delphi 7, there's going to be a lot more worrying code hidden in there somewhere. I do keep discovering code I'd entirely forgotten about that I wish I'd not seen!

      Delete

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