[GH-ISSUE #170] [BUG] Deselecting all commands from submenu actually displays all commands instead of none in the submenu #166

New issue

Open

opened 2026-02-25 21:32:47 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 21:32:47 +03:00

Owner

Originally created by @ulu on GitHub (Aug 1, 2023).
Original GitHub issue: https://github.com/clechasseur/pathcopycopy/issues/170

Originally assigned to: @clechasseur on GitHub.

Describe the bug
removing all entries from submenu resulting in a garbaged submenu.

To Reproduce
Steps to reproduce the behavior:

go to UNC-Path and right right click on an entry
click on "Path Copy > Settings..."
remove all check marks
set check marks for "copy long UNC path" in "Main menu" and "Submenu"
click "OK" button
right right click on an UNC-Path entry
see a main menu entry for "copy long UNC path"
right right click on an UNC-Path entry
click on "Path Copy > "
see a Submenu with 2 entries: "copy long UNC path" and "Settings ..."
click on "Path Copy > Settings..."
remove all check marks
set check marks for "copy long UNC path" only in "Main menu"
click "OK" button
right right click on an UNC-Path entry
see a main menu entry for "copy long UNC path"
right right click on an UNC-Path entry
click on "Path Copy > "
[ERROR] see a Submenu with lots of entries

Expected behavior
I want to see no submenu entries except "Settings ..." if I have only "Main menu" entries. My preferred solution is to get rid of the menu entry in context menu (explorer right click) at all. The visibility of the submenu structure in context menu (explorer right click) should be configurable. Because the settings are accessible over windows menu and I only want the Opt-In features I checked in pathcopycopy configuration.

Screenshots
01_settings
02_garbaged_submenu

Software (please complete the following information):

OS: Windows 10 Enterprise, 22H2
Path Copy Copy Version 20.0

Originally created by @ulu on GitHub (Aug 1, 2023). Original GitHub issue: https://github.com/clechasseur/pathcopycopy/issues/170 Originally assigned to: @clechasseur on GitHub. **Describe the bug** removing all entries from submenu resulting in a garbaged submenu. **To Reproduce** Steps to reproduce the behavior: 1. go to UNC-Path and right right click on an entry 2. click on "Path Copy > Settings..." 3. remove all check marks 4. set check marks for "copy long UNC path" in "Main menu" and "Submenu" 6. click "OK" button 7. right right click on an UNC-Path entry 8. see a main menu entry for "copy long UNC path" 9. right right click on an UNC-Path entry 10. click on "Path Copy > " 11. see a Submenu with 2 entries: "copy long UNC path" and "Settings ..." 13. click on "Path Copy > Settings..." 14. remove all check marks 15. set check marks for "copy long UNC path" only in "Main menu" 16. click "OK" button 17. right right click on an UNC-Path entry 18. see a main menu entry for "copy long UNC path" 19. right right click on an UNC-Path entry 20. click on "Path Copy > " 21. **[ERROR]** see a Submenu with lots of entries **Expected behavior** I want to see no submenu entries except "Settings ..." if I have only "Main menu" entries. My preferred solution is to get rid of the menu entry in context menu (explorer right click) at all. The visibility of the submenu structure in context menu (explorer right click) should be configurable. Because the settings are accessible over windows menu and I only want the Opt-In features I checked in pathcopycopy configuration. **Screenshots** <img width="374" alt="01_settings" src="https://github.com/clechasseur/pathcopycopy/assets/809609/19900cdf-86bc-47c6-a905-83d6522b08ee"> <img width="146" alt="02_garbaged_submenu" src="https://github.com/clechasseur/pathcopycopy/assets/809609/ab816cf6-679f-4833-8683-d5bbed1a6957"> **Software (please complete the following information):** - OS: Windows 10 Enterprise, 22H2 - Path Copy Copy Version 20.0

kerem added the

bug

label

2026-02-25 21:32:47 +03:00

kerem commented

2026-02-25 21:32:47 +03:00

Author

Owner

@clechasseur commented on GitHub (Aug 2, 2023):

This is due to this part of the code:

https://github.com/clechasseur/pathcopycopy/blob/default/PathCopyCopy/src/PathCopyCopyContextMenuExt.cpp#L422-L423

I think this is due to a legacy behavior that should have been removed, but I'm not sure yet.

@clechasseur commented on GitHub (Aug 2, 2023): This is due to this part of the code: https://github.com/clechasseur/pathcopycopy/blob/default/PathCopyCopy/src/PathCopyCopyContextMenuExt.cpp#L422-L423 I think this is due to a legacy behavior that should have been removed, but I'm not sure yet.

kerem commented

2026-02-25 21:32:47 +03:00

Author

Owner

@ulu commented on GitHub (Aug 8, 2023):

Seems a good line to start. You could check it by removing the complete line from the code. But you will get a nullptr exception in line 429. So you have to guard this code with a check for a nullptr like
if (pvspPlugins != nullptr)
In addition I would not rely on the try-catch because it is forwarded in the catch block.

Currently I have no cpp environment installed. So I cannot help here at the moment...

@ulu commented on GitHub (Aug 8, 2023): Seems a good line to start. You could check it by removing the complete line from the code. But you will get a nullptr exception in [line 429](https://github.com/clechasseur/pathcopycopy/blob/f734e249e4636b2df07970d7a2655ed18faffb7b/PathCopyCopy/src/PathCopyCopyContextMenuExt.cpp#L429C46-L429C46 ). So you have to guard this code with a check for a nullptr like `if (pvspPlugins != nullptr)` In addition I would not rely on the try-catch because it is forwarded in the catch block. Currently I have no cpp environment installed. So I cannot help here at the moment...

kerem commented

2026-02-25 21:32:47 +03:00

Author

Owner

@clechasseur commented on GitHub (Aug 9, 2023):

I think this is mostly due to legacy behavior - the way to store commands displayed in the submenu has evolved quite a lot over the years and gone through at least two major refactorings. Now, we should consider an empty list to be different from the absence of a setting - we do that for the main menu, but not for the submenu, which is a bug.

@clechasseur commented on GitHub (Aug 9, 2023): I think this is mostly due to legacy behavior - the way to store commands displayed in the submenu has evolved quite a lot over the years and gone through at least two major refactorings. Now, we should consider an empty list to be different from the absence of a setting - we do that for the main menu, but not for the submenu, which is a bug.