Yeah, it could be caused by some update made by some program I haven't installed yet. It'd be nice to know which one
I've been checking app.cpp and found some interesting things:
- When you open a project or workspace, it seems to be loaded through CodeBlocksApp::ParseCmdLine. Any other file is just ignored here.
- Opening a project or workspace will also block the explorer window it was lanuched from.
- Closing Code::Blocks will cause a lovely crash in these cases. It seems when the DDE Server is shut down, because Code::Blocks is closing, it detects the [Open] "message" and tries to execute it through DDEConnection::OnExecute. Trying to open the file causes the crash.
So, it seems to be a problem in the DDE server processing those "messages" on start, like if it was not aware of the "message".
But here is another test trying to prove if the "message" was queued:
- I tried to open a .c file. Code::Blocks was launched, but the file was not, and the explorer window became irresponsive (known behaviour).
- I opened another explorer window and tried to open another .c file. This one was opened in the running Code::Blocks, but the first one remained silent, and the other explorer window was still irresponsive.
I wonder if destroying the DDE Server and recreating it just before leaving CodeBlocksApp::OnInit would be too hacky...
It could be a matter of timing: the "message" being sent before the DDE Server is created because it's heavily delayed. A wxWidgets and/or Windows bug solved when some random DLL gets updated. The need of creating the DDE Server before calling some function.
I'll be trying the hacky way in the meanwhile...