945 (but not a recent regression): FC modifies clipboard when it closes
Posted: 05.03.2026, 11:53
As I can't reliably reproduce this issue, this isn't going to be the best bug report, but I hope it is more useful than not reporting the issue at all.
Often, when I completely close FreeCommander (FreeCommander XE 2026 Build 945 64-bit non public on Windows 11), it will copy content to the clipboard. The content is either empty (likely just spaces, CRLF, or nulls) or the pathnames of the current selection (or perhaps pathnames of the last files copied in FC before I closed it).
I notice this because I use the excellent CopyQ clipboard manager, and I have it configured to display a popup containing the clipboard contents whenever anything is copied to the clipboard.
I've spent a good amount of time trying to isolate when FC exhibits this issue, but I have yet to be successful in generating reliable STR.
This isn't a recent regression. I've noticed this for quite some time (many months, perhaps even years), but I've been hoping to be able to generate reliable STR before posting about the issue.
Perhaps others are able to generate reliable STR, or Marek will be able to fix the issue without them.
Often, when I completely close FreeCommander (FreeCommander XE 2026 Build 945 64-bit non public on Windows 11), it will copy content to the clipboard. The content is either empty (likely just spaces, CRLF, or nulls) or the pathnames of the current selection (or perhaps pathnames of the last files copied in FC before I closed it).
I notice this because I use the excellent CopyQ clipboard manager, and I have it configured to display a popup containing the clipboard contents whenever anything is copied to the clipboard.
I've spent a good amount of time trying to isolate when FC exhibits this issue, but I have yet to be successful in generating reliable STR.
This isn't a recent regression. I've noticed this for quite some time (many months, perhaps even years), but I've been hoping to be able to generate reliable STR before posting about the issue.
Perhaps others are able to generate reliable STR, or Marek will be able to fix the issue without them.