Cannot open new right-click menu before prompt is closed

[Cirn09]

Describe the bug
Currently ShellAnything is single-threaded, and some actions may block. Then explorer will always wait for ShellAnything. During this time, the new right-click menu cannot be opened.

To Reproduce
Take "Find a file..." written in "default.xml" as an example:

1. right click then click "Find a file...";
2. Put the prompt aside, go back to the window just now and right click again;
3. Before closing the window opened in the step 1, right-clicking will not call the context menu.

Expected behavior
ShellAnything should return immediately. The action should probably work in a new thread.

Screenshots
N/A

Environment

• OS: Windows 10, 19042.1165
• Version 0.5.1?

Additional context
N/A

[end2endzone]

I have looked at this issue and I have been easily able to reproduce it.

I am not certain that launching the actions handler in a separate thread might be the best way to solve the problem.
For example, with the "Find in files..." menu, the easiest way would be to spawn a new process with the start command for executing the dir command. The get such a behavior, the action could be changed to this:

        <exec path="${env.ComSpec}" basedir="${selection.path}" arguments="/C start &quot;Searching for ${findpattern}&quot; %ComSpec% /K dir /a /s /b &quot;${findpattern}&quot;" />

This solution would be appropriate for all leaf actions (the last action of a series) that have the potential to execute for a long period of time. However, with such a design, you loose the ability to know if the spawned process is successful or not (you only know if you spawn the process correctly or not.)

Another option would be to define an attribute to the <exec> action that indicate to spawn this action in a separate process. To issues, only the last action of a series could be spawn in a new thread.

If we go the multithread way, we will have to implement many locks at multiple locations to make the application thread-safe. We will also need a ThreadManager to handle all thread workers, monitors to know when a Actions run is completed or has return an issue. This is not a no-go but the task may be easily underestimated. For example, Windows Explorer periodically ask the shell extension if it can be unloaded, most of the time, the answer is yes unless it is executing something. If we have running threads or a thread leak (lets say a thread is in a deadlock), then the system may crash.

But my main concern about executing Actions of a menu in a separate thread is the Property System. More specifically the "selection-based properties". Right now, the property system is not "thread aware" which means that you cannot define a property that lives ONLY in the current thread. Without this functionality, if you execute the actions of two menus simultaneously, the selection-based properties of the second menu will overrides the selection-based properties of the first menu execution. This could easily lead to incorrect execution.

I am open to new ideas but I must admit that none of the design or workaround mentioned above seems like the perfect option to solve this problem. Any ideas ?

[end2endzone]

Reproducing configuration:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <shell>
    <menu separator="true" />
    <menu name="issue83">
      <actions>
        <message caption="Issue #93" title="You clicked on file/directory '${selection.filename}'" />
      </actions>
    </menu>
    <menu separator="true" />
  </shell>
</root>