Recent File Lists

Have you ever gone to open a file from your recent file list and find that it has gone?

This has happened to me often (in Word, NotePad++, and other programs) and it is extremely annoying especially if you can't remember where the file is stored.  The trouble is you come to rely on being able to open a special file (or several files) from the list and consequently forget where it is on the disk.  Then it takes a lot of time to go and find it.

For example, just now I went to open an Excel spreadsheet with a table of credit card numbers (test numbers not real ones for those of you who were wondering).  Because I had also been recently working with some test scripts in Excel spreadsheets the list of about 20 files in the recent file list did not include the file I needed anymore.  I searched my local disk and could not find it, and I really didn't have the time to search our large network drive.  (Luckily, I found a copy attached to an old email.)

This is why I find it surprising that I have not seen any other software copy my idea of the "Recent File Dialog" which has been in HexEdit for almost 10 years.  It basically keeps track of all the files you have ever opened (as well as the time you last opened it in HexEdit and other things), until you delete them from the list or clear the list completely.

If anybody knows of other software that has copied HexEdit's approach please let me know!

Windows 7

I guess the above problem is the reason that Windows 7 has added the facility for frequently used file lists.  For software that supports it you can right-click the program icon on the Taskbar and see a list of frequently used files (as well as the familiar recently used file list).  I applaud this improvement but there are additional advantages to the system provided in HexEdit ...

What if you have forgotten the name of the file but remember (or can work out) when you created it, modified it or last opened it.  You can sort the list of files in HexEdit on any column such as time created or modified, size, or the time you last opened it.

You can also use the category, keywords and comments fields (since HexEdit 3.2) to make it easy to find the files you are looking for.  See this forum post for more: http://hexedit.com/cgi-bin/ikonboard.cgi?act=ST;f=6;t=2.

Deleting Entries in the Recent File List

Another annoyance I just noticed with Excel (2007 version) is that you can't delete from the recent file list.  I right-clicked on a file in the list and, though a popup menu appeared, there was no option to remove the file from the list.

You may ask why would anyone want to do this?  There are many reasons:

• to remove a file from the list that you know you will never open again
• to remove a file that you know has been moved or deleted
• to remove a file that you don't want anyone to know you opened
• to remove unimportant files so that the list is not cluttered

This is easy in the HexEdit Recent File Dialog.  Just select the file or files and click the "Remove" button.

You can also have HexEdit automatically remove files from the list is they no longer exists on disk - for example, if they have been deleted.

When is a Leak not a Leak?

I received an email recently pointing out that HexEdit has memory leaks.  If you build and run the debug version of the new HexEdit 4.0 beta then when the program exits the debug heap spits out many messages about memory "leaks".  I have tracked down several of these "leaks" and it turns out they are not really leaks but one-off allocations for singleton objects.  This is not really a leak but better described as a "splash".

I think it is pretty poor of the MS CRT (Microsoft C run-time) to pronounce all non-deallocated memory as "leaks", especially as the CRT itself does one-off allocations (eg for the FILE table) but uses a special flag so that it's own "leaks" are hidden.  Often it is harmless or even desireable to not deallocate one-off objects.  But when the CRT debug heap uses the word "leak" it seems to create panic in some people who should know better.

I am pretty diligent about avoiding memory leaks.  Here I define a leak as a continual loss of memory during the running of the software (or some part or parts of the software) that eventually will result in memory exhaustion.  Typically this occurs when a function allocates an object on the heap but forgets to free it when it returns to the caller, leaving an unused but allocated block of memory.  Every time this function is called more memory is lost.

In modern C++, using auto_ptr and the like, it is fairly easy to avoid accidentally doing this.  Some of HexEdit was written before the advent of auto_ptr though; nevertheless I believe there are no such leaks in HexEdit.

My point is that I am not too bothered about all the messages about leaks from the debug CRT.  At various times I have tracked down many of these and they have always turned out to be harmless splashes.

However, I have worked in teams where the managers insists that all such "leaks" are fixed.   And if you have developers who are prone to introducing leaks then that is probably a good idea.  That way, when you do get a real leak it is not hidden amongst all the other bogus "leaks" in the debug CRT leak report.

On the other hand I have seen software which allocates a lot of global data (caching large amounts of data for performance reasons).  Insisting that all the objects on the heap are freed at program exit can mean that the program takes several minutes to exit.  In this sort of situation it is simpler and faster to simply exit and let the CRT/OS tidy up.

VLD

Anyway, I will endeavour to tidy up all the "leaks" in HexEdit.  Luckilly, there is a library that makes this easy, often trivial, to do.  See http://vld.codeplex.com for more information.

If you have ever used the MS CRT debug heap to try to track down memory leaks you know that it can be extremely tedious, sometimes nigh impossible.  The problem is that, although it tells you where the allocation was made, it tells you nothing of how the flow of control got to that specific allocation.  For example, there could be thousands of CStrings used in a program and there may be just one that was not deallocated.  Sometimes the contents of the memory (eg the text in the string) may give a clue but not always.

The beauty of VLD is it provides a "call stack"  that allows you to very quickly track down the problem piece of code.