In windows I can't have different projects opened in different codeblocks instances, even if I disable both environment options Allow only one running instance and Use an already running instance. In addition I must point out that these two options sound conflicting/redundant.
If you are referring to this thread the problem is not about multiple instances of C::B but wrong behaviour when double clicking on a CBP file with C::B already running.
C::B uses your settings to open a new instance of C::B or use the open one, but if you have a running instance then the ddeesec entry in the registry makes MSW connect via DDE with the running instance instead of opening a new one, regardless of your settings. Removing these entries prevents MSW from messing with DDE.
The attached patch fixes this issue.
Looks like the ddeexec entry in the registry was the first approach to reusing a previous instance of the program: create a DDE server on C::B and let MSW do the client work automatically.
Later, possibility of multiple instances and options for opening on the current instance or on a new one were added, and the code got a DDE client to communicate with the previous instance of C::B if needed. This code works OK, but nobody removed the (now unneeded) ddeexec key, so MSW still calls the previous instance using DDE instead of opening a new one. The new code isn't even executed.
So DDE is still needed, but MSW must be out of the way.
Information about how ddeexec works is here.
The proposed patch removes all ddeexec entries when you click on the Set now button on Environment settings.
OK, I'll commit. Can you write long and thorough commit message I can use?
I will try:
No longer enable DDE in file associations when associating files in MSW, and disable it if already present. The DDE mechanism is already integrated in C::B and it is interfering with the instance management settings,
After this commit you can disable DDE in an existing installation just clicking on "Set now" in Environment settings.
Background:
MSW has a built-in mechanism for connecting to an already running instance of a program (via DDE) instead of running a new instance. This mechanism uses a registry key named ddeexec containing information about the DDE server and the desired topic ("command").
This simple method works well when only one instance of the program is allowed. When support for multiple instances was added then new options were created: "Allow only one running instance" and "Use an already running instance if possible". This was not supported by the simple ddeexec mechanism, so code was added to CodeblocksApp::OnInit() to manage the new options.
Now C::B is able to manage existing instances, but nobody removed the ddeexec entries in the registry, so MSW still reuses an existing instance instead of creating a new one, defeating the new code. The solution is removal of ddeexec from all entries.
How ddeexec works:
https://docs.microsoft.com/en-us/windows/win32/shell/how-to-associate-verbs-with-dde-commands
One note: From what I see this removes the DDE feature completely. DDE could also used on Windows to automate build processes, if properly used. So while this patch indeed fixes the bug mentioned but also removes the ability to script-control C::B from outside in case you really use just one instance (which is an option).
So this solution is not perfect... just my 2 cents here.
A better solution is to check if you are in single instance mode and then allow DDE commands. Additionally besides opening a file we could literally add any operation via DDE to kind of "remote-control" C::B. I do so for other applications at my work, also using the wx-DDE mechanisms with nice benefits.
No, the patch only removes automatic DDE calls when double clicking on an associated file on MSW. DDE is still there.