Menu

#1082 cannot open more than one instance of CB (Windows)

Next_Nightly
fixed
Bug_Report
2021-03-20
2021-03-15
Elena
No

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.

Discussion

  • Miguel Gimenez

    Miguel Gimenez - 2021-03-16

    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.

     
  • Teodor Petrov

    Teodor Petrov - 2021-03-16
    1. Then why we had the DDE stuff in the first place?
    2. What do we lose if we remove the DDE from the registry?
    3. Does reusing the instance still work if the settings are set for re-use and the dde stuff is removed?
    4. What does a user need to do in order to fix his/her associations? Do they need to manually delete stuff, press a button, it is fixed auto-magically?
    5. Do we need the DDE server in src/src/app.cpp after the removal?
    6. Is there any documentation about this?
     
  • Teodor Petrov

    Teodor Petrov - 2021-03-16
    • labels: --> UI, Windows
     
  • Teodor Petrov

    Teodor Petrov - 2021-03-16
    • Milestone: Undefined --> Next_Nightly
     
  • Miguel Gimenez

    Miguel Gimenez - 2021-03-17

    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.

    What does a user need to do in order to fix his/her associations? Do they need to manually delete stuff, press a button, it is fixed auto-magically?

    The proposed patch removes all ddeexec entries when you click on the Set now button on Environment settings.

     
  • Teodor Petrov

    Teodor Petrov - 2021-03-17

    OK, I'll commit. Can you write long and thorough commit message I can use?

     
  • Miguel Gimenez

    Miguel Gimenez - 2021-03-17

    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

     
  • Teodor Petrov

    Teodor Petrov - 2021-03-19
    • status: open --> fixed
    • assigned_to: Teodor Petrov
     
  • Morten MacFly

    Morten MacFly - 2021-03-20

    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.

     
  • Miguel Gimenez

    Miguel Gimenez - 2021-03-20

    No, the patch only removes automatic DDE calls when double clicking on an associated file on MSW. DDE is still there.

     

Log in to post a comment.