- This topic has 4 replies, 2 voices, and was last updated 3 weeks, 5 days ago by
.
-
Posts
-
* Improvement : maybe add an option in the copy/move window to choose a default action (keep, overwrite, rename) in case of read-only files, existing files or whatever that can stop the copy/move operation instead of a windows that pop-ups in the middle of the transfer
* Cosmetic : if a copy/move operation has been launched (or running), the preview in the taskbar is still showing the copy/move dialog
* Improvement : in case of failure, a dialog box would be interesting with the list of failures and actions. For instance, if there was no space left, maybe a retry would help. The list could also be exported to manually handle them later.
Hi HomeBoy,
(I moved your post from Issues and Bug to Feature Requests)- add an option in the copy/move window to choose a default action.
- Already in my backlog but lost from sight. I higher its prio.
- Preview in taskbar showing ghost copy/move window.
- I put a ticket in my backlog but honestly, I don’t even see how I can fix that. Windows handles the preview itself. I will see…
- Keep track of files manipulated
- This is also a feature I wanted, mainly to make an “undo” possible. But your use case is also inspiring. Ticket in my backlog
Thank you for the valuable input
Hi,
The issue “Preview in taskbar showing ghost copy/move window” has been fixed.
The problem was caused by the popup windows involved. They were implemented as full-fledged forms (borderstyle=sizable or dialog, with minimize, restore, and maximize buttons in the title bar). When closed, these forms were not destroyed but simply hidden.
Because of this, the Desktop Window Manager (DWM) treated them as independent windows, making them eligible for taskbar previews. It also appears that DWM does not properly react when such windows are merely hidden.
I had 2 options to fix it:
- Convert their BorderStyle to SizeToolWindow or ToolWindow
- Destroy/free the windows on closure
By converting these windows to ToolWindows (or SizeToolWindows), the issue disappears. In this configuration, DWM considers them as dependent “slave” windows of the main form, and therefore excludes them from taskbar previews.
For the lightweight windows, I opted for destruction/freeing on closure, as those windows are not computing-power-demanding when (re)created.
The improvement will be part of this month’s release
Great, I guess the other points will take some more time and will come in a bigger release version as it should for feature requests
- add an option in the copy/move window to choose a default action.
- You must be logged in to reply to this topic.