XYplorer Beta Club

Currently, a user must choose whether to check or uncheck the Shell Integration setting "Show the 64-bit context menu."

- If checked, the user only sees the 64-bit context menu.
- If unchecked, the user sees the 32-bit context menu, which includes the option to "Show 64-bit Context Menu."

(Understanding the issues with callback mechanisms) would it be straightforward to implement an optional configuration:

"Show 64-bit and 32-bit context menus side-by-side"
...where the 32-bit menu is displayed first, then retained on-screen while the 64-bit menu is displayed simultaneously to the immediate right? In this situation, the user could select any option from either menu. For menu items in the 32-bit menu with rollover submenus, the rollovers would simply appear over (occluding) the 64-bit menu a bit.

-----------------------------

The rationale: For users who must work quickly, having to choose between 64-bit and 32-bit menus currently creates a slowdown as follows:
1. After opening a context menu, the user must scrutinize the list, always thinking "The option might not be here but in the other-bitness menu."
2. Sometimes the sought item is in the first-shown menu; fabulous. If not...
2. If the 64-bit context menu is default, and the needed item is missing, the user must either change the setting or set up and rely on key combos, etc.
3. If the 32-bit context menu is default, the user must first scan the list and, not finding the needed item, open a secondary menu.

This current arrangement is a decent solution to the problem of 32-bit vs. 64-bit menus, but through its structure it incurs excess clicks/actions. For busy, fast-paced work, those can add up to significant efficiency decreases.

Beyond the clicks, the inherent uncertainty of trying to remember in which menu the sought item exists creates hesitation in the user. On its own, this contributes to slowdown: If the user knew a sought item must certainly be onscreen - since all 64-bit and 32-bit options are being shown - then the situation is more conducive for the user to quickly zoom in on the needed item. As it is currently, the user is looking and thinking "Maybe I need to change the menu to find what I need." This mindset tends to cause the user to slowdown and think rather than quickly locate an item.

A big plus one.

I tested it with AHK and got two menus , but it seems a bit weird.

Norn wrote: ↑07 Mar 2023 10:39 I tested it with AHK and got two menus , but it seems a bit weird.

Really? I would have thought that's technically impossible in Windows.

If you don't select the AHK menu on the right, it won't disappear automatically, and I don't know how to make it disappear when shifting focus.

Surprising.

That looks like a _shell context menu_ and a _user created_ (inside AHK) menu at the same time. But this would be about displaying _two shell context menus_ simultaneously

highend wrote: ↑07 Mar 2023 12:41 That looks like a _shell context menu_ and a _user created_ (inside AHK) menu at the same time. But this would be about displaying _two shell context menus_ simultaneously

I modified the AHK script for testing and it works the same.

What does that have to do with two Windows shell menus at the same time?

popupcontextmenu <xy>, 64; popupcontextmenu <xy>, 32;
Next to each other...

This shows that my wish is possible.
viewtopic.php?t=24482

*sigh*. Shell context menus^^

Idea sounds cool, to be able to open both menus side by side would be useful.

Via two AHK scripts.

There has to be a way to, if 32bit menu is loaded first, programmatically check for items that would be loaded in the 64bit menu, and (invisibibly by regex compare) include _missing_ items from that menu as links in the opened visible 32bit menu (listed as links to the 64bit shell dll's). This way of merging the menus should be done by all 32bit applications that want to more seamlessly include 64bit shells as I see it.

Alternatively make a 3rd context menu (by the same way) that is a seamless merge of the 32bit and 64bit context menus, and only have this menu load inside XYplorer, including all fantastic XYplorer special items that are found in the 32bit menu now.

Just a thought, now that I could need such myself to more easily make an ahk script that {blind} right-clicked and pressed certain hotkey to select a certain menu item (but the item I'm after is in the 64bit menu, so the script becomes longer / execution delayed).

Long live XYplorer.

@lenient
Your "There has to be a way..." is only your wish regardless of how context menu works.
XY can't see what shell extensions display as the final result !
That's a chain of context menu handlers, and each one decides what it displays.