#348 Open a file by doubleclick makes Codeblocks 16.01 to reopen all previously opened files.

[Oliver S. Lazar]

I'm a professor for programming and this bug appeared on my system as well as on many systems of my students. When I open C-files by doubleclick and after that I close them again, lateron, when I want to open another file by doubleclick, all previously opened files are reopened.
This has happened with new the version 16.01 on a Linux Mint 64 bit and on a Windows 7 (64 Bit).

[ollydbg]

Hi, I guess this is a feature(I haven't tried yet). Because C::B may remember last opened files
You can disable this feature:
Menu->Settings->Environment Settings dialog->General settings->Open last open files?

[Oliver S. Lazar]

Hi, thanks for the hint. But that's not the solution. What You mentioned belongs to project files. My reported bug appears independent from a project. Nevertheless, I disabled this feature, but the same problem still exits. So, this really seems to be a bug, not a feature from my point of view.

[Jun]

It seems the bug is still there. This is quite annoying actually. I had to clean the recent open files history and restart C::B to avoid this.

[ollydbg]

I just tried it my self, I'm using the latest nightly build version (rev11021), and under Windows 7, I can't reproduce this bug, maybe, it is Linux only bug?

[Pavel Krobot]

Hi, it is not just Linux-only bug. Like author said, it happens on windows 7 (64-bit) too.

I am facing this problem after OS reinstalation and it's very irritating. However, my scenario is little bit different. If I open files from explorer (by doubleclick) everything works fine. Opening files via WinSCP or command line (like C:>"C:\Program Files (x86)\CodeBlocks\codeblocks.exe" SomeSource.cpp) causing this problem. Morever all already opened files flashes (got focus for a fraction of second one by one) and after the file is finaly openned, focus stays on some another file (different than openned one). When using split view, file is opened "randomly" in one of coding areas (not in that one where was last focus on a file).

If it would help in some way I can maybe provide a video of this strange behavior. I have installed Code::Blocks from "codeblocks-16.01mingw-setup.exe ", Win 7 64-bit, SP1.

[Pavel Krobot]

Is there any chance of solution, reply or else? Code::Blocks is nice but this "feature" is really irritating and making it unusable for me...

[bluehazzard]

i can not reproduce this with codeblocks 16.01 on linux mint 18...
i can try to look into the code and find the culprit, but i don't think this will help... Have you tried to delete the configuration files?
What are the settings in Settings->Environment->General settings->Interprocess comunication and Allow only one running instace... ?

[bluehazzard]

i can also not reproduce this with rev 11021 on linux mint 18

[Pavel Krobot]

I recorded a small sample video with described behavior if it would helps in some way ...

Edit: I've forgotten to add: It is fresh new installation of latest version of Code::Blocks (i.e. default settings), only one running instance allowed.

[bluehazzard]

ok, now i understand the problem. You do not close codeblocks but only the editors.

I can not reproduce this behaviour on windows 7 with the latest trunk and fresh config file. Have you tried a nightly build?
I can reproduce some problems (it wont open the file if only a single instance is allowed) on the mint machine. The interprocess communication seems to be broken. This is quite tricky to debug...

[Pavel Krobot]

I think that I tried a nightly before but to be sure I have tried a nightly from 1st March 2017 right now - same thing is happenning.

I would like to point out here what I have written in my first post:

If I open files from explorer (by doubleclick) everything works fine. Opening files via WinSCP or command line (like C:>"C:\Program Files (x86)\CodeBlocks\codeblocks.exe" SomeSource.cpp) causing this problem.

Opening from TotalCommander is fine also. That is, for me, there is only problem with opening via WinSCP (which is the most often for me) and via command line. Maybe the fact, that:

• A) from explorer/totalcommander:

  1. step: doubleclick file1.cpp -> starting codeblocks + open the file
  2. step: doubleclick file2.cpp -> open the file in running instance without the strange behavior

• B) from cmd.exe run (or doubleclicking from winscp):

  1. step: C:\PathTo\codeblocks.exe file1.cpp -> starting codeblocks + open the file
  2. step: C:\PathTo\codeblocks.exe file2.cpp -> open the file in running instance in a strange way

could lead to some solution.

[bluehazzard]

ok, i can reproduce the opening of multiple files and i can debug it.
With the debugger i found, that in app.cpp:1097

int CodeBlocksApp::ParseCmdLine(MainFrame* handlerFrame, const wxString& CmdLineString)
{
    // code shamelessely taken from the console wxWindows sample :)
    bool filesInCmdLine = false;
    // code line removed because sf interprets it as header ;(
    wxCmdLineParser& parser = *Manager::GetCmdLineParser();
    if ( CmdLineString.IsEmpty() )
        parser.SetCmdLine(argc, argv);
    else
        parser.SetCmdLine(CmdLineString);
    // wxApp::argc is a wxChar**

The parser has still stored the old command line values.
I have to read into it and check if it can/has to be cleared

[Pavel Krobot]

Ok, thanks for the info, hope it will helps.

[bluehazzard]

Ok, this seems to be a bug in wxWidgets that is fixed in wx3.1.

I can confirm that with wxWidgets 3.0 all seems to work. Also the layout and miss focus errors are gone. They all seem to come from loading the files redundantly.

The Bug in wxWidgets:
The m_parameters array does not get cleared on a new Parse call in cmdline.cpp:841. This is fixed in wx3.0

[bluehazzard]

related commit:
commit a84902e66547fef1c0251ebe39d7df7aead14fdc
Author: Vadim Zeitlin vadim@wxwidgets.org
Date: Fri Aug 29 11:56:23 2014 +0000

Allow wxCmdLineParser::Parse() to be called more than once.

Clear the previously collected parameters in the beginning to avoid
accumulating the results from several command lines.

Closes #16503.

[Teodor Petrov]

You need wx 3.0.2 to be more precise. I guess for wx2.8 we'll have to recreated the cmd line object.

[Teodor Petrov]

For the record on linux openning files from the command line doesn't seem to work in both wx2.8 and wx3.0 versions.

[Pavel Krobot]

Ok, thanks for the finding this one and for the solution :) ... So should I just compile codeblocks with wx3.0.2 or higher?

[Teodor Petrov]

Nope we should find a workaround to the problem. If you want fix now a safer option is to apply the patch to wx mentioned in trac ticket #16503. This way you want suffer all the wx3.x problems that we've not fixed yet.

[Pavel Krobot]

Huh, it was kind of painful while struggling with mingw instalations, but I finally managed to compile CodeBlocks from SVN with patched wx. Seems that it works fine now. Thanks for the solution, it is realy huge relief :).

Cheers!

[Miguel Gimenez]

wxWidgets problem, fixed in wx3.0.2