The “Resume” button should stay accessible even if there are already resumed or completed downloads in the selection

[abolibibelot1980]

When I want to batch-resume a selection of downloads which have the “Queued” status, the “Resume” button is greyed out if there happens to be a few or even a single one in the selection which either has already been completed, or has already been resumed (and they can be tricky to identify since their status switches regularly between “Searching” and “Queued”, and nothing distinguishes a download with the “Queued” status which has already been resumed from a download with the “Queued” status which is actually queued). So the “Resume” button should remain accessible (both on the strip separating the “Downloads“ and “Uploads” areas and through the context menu) even if the selection contains downloads which can not be resumed.
Strangely, “Resume” remains accessible if a selection contains both already resumed downloads and paused downloads, or if there is even a single paused download in a selection containing any number of downloads with any other status.

Also : just now doing some tests as I was writing the above sentence, I accidentally deleted two downloads because the “cancel” button suddenly appeared where the “pause” button was a quarter of a second before ! (And there is no confirmation when cancelling non-started downloads.) There is enough space in that strip separating the “Downloads” area from the “Uploads” area for all available buttons to stay where they are instead of constantly moving and disappearing and reappearing depending on the status of the download(s) currently selected, it would prevent mishaps like this.

Not quite related, but there should be a plain text list of all downloads in the queue (like the “downloads.txt” file in eMule) — that would come in handy in a case like this for instance, to identify which downloads have been accidentally cancelled.
And recently, on 2022-12-18 precisely, I noticed that Shareaza had spontaneously removed 186 downloads during startup. I first noticed that many .partial files did not have an associated .sd file, then, as I was occupied with something else entirely, I found out that many .sd files were in the “recycle bin”, with various deletion dates, and in particular 186 deleted on 2022-12-18. I activated the “General.DebugLog” option, so I could check what happened that day at that time, and there is simply a list of “Cleared download...” notifications, with no explanation whatsoever. So I have no clue what happened. The previous session was interrupted by a BSOD, but none of those .sd file appears corrupted. I simply restored them (at the same time as I launched v. 2.7.10.4 2022-12-27 for the first time, coincidentally), and apparently all of the corresponding downloads were loaded with no issue (they all appeared at the top of the queue, since, I suppose, the “DownloadGroups.dat” file, which apparently determines the sorting order of files, no longer had them referenced). And the two downloads I accidentally cancelled were among those 186, so at least that should make it a bit easier to pinpoint which ones are missing.

[20:13:20] Loading skin: Shareaza OS
[20:13:22] Cleared download "E:\TELECHARGEMENTS\Shareaza\fichiers en cours\ed2k_42378b4b8fc47194431d893871c91787.sd".
[...]
[20:15:25] Cleared download "E:\TELECHARGEMENTS\Shareaza\fichiers en cours\ttr_ZZJYBOTPY5IBXMSF54XGLDTAILEBUHPIIPZ3XVA.sd".
[20:17:08] Starting Shareaza network core...
[20:17:08] Accepting incoming TCP connections on 0.0.0.0 port 35683.

And one more thing (I'm starting to sound like lieutenant Columbo !) : it would certainly be more convenient if that log file (which can be quite huge — I set it to the maximum size of 50MB) included the dates... (Either at the start of each line, or at least at the start of a new day.)