Clueless...

[Ceniza]

There's something strange going on with my system...

A few weeks ago I decided to reinstall XP. I made a backup first including MinGW, Code::Blocks (binaries, sources and config files), etc.

I reinstalled the OS, SP2 and a few more programs I use. Restored MinGW, Code::Blocks and such. Code::Blocks ran without problems. I registered the file associations and everything seemed to be fine.

Now, I decided to download some code and clicked a .c file. Code::Blocks was opened but the file was not, and the explorer window I clicked the file from was not responding. I closed Code::Blocks, the explorer window worked again and it threw a nice message box, saying something like: "There was a problem sending the command to the program". WTF? I thought the DDE bug was fixed long ago. What's funny is that it works just fine if I open a .cbp or .workspace file, and it was working without problems before I decided to reinstall the OS.

Another interesting thing is that sometimes it crashes on exit blaming DDE somewhere (report attached).

Well, since I had SVN 3333 I decided to update to the latest version (3459) and compile it. Surprise! It fails just the same.

Recompiled wx 2.6.3, rebuilt Code::Blocks... same thing.

I just cannot get it. It was working... it should be working... but it is not.

[attachment deleted by admin]

[mandrav]

This is a known issue. What's weird is it only happens with source files. Double-clicking a project in explorer works just fine...

[MortenMacFly]

Ceniza: Do you have another Editor/IDE installed (e.g. Visual Studio) that also tries to register the *.c/*.h (source file) extensions?
With regards, Morten.

[Ceniza]

A known issue? Before I reinstalled XP it was working just fine with source files, projects and workspaces. So it's now strange I got it working before?

Morten: Right now I don't have any extra IDE installed, even though I had Dev-C++, Visual C++ 2005 Express, Visual MinGW and MingW Studio installed when it was working. Could it have anything to do with it? I don't really feel like installing VC++ again

[mandrav]

A known issue? Before I reinstalled XP it was working just fine with source files, projects and workspaces. So it's now strange I got it working before?

Yes, it has appeared some time now. Although we changed nothing relevant, at least as far as I can tell. Could it be caused by a windows update?

[Ceniza]

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...

[thomas]

I have the same issue, but only with .h files, not with .c or .cpp, the issue exists for almost a year now.
When the DDE bug was allegedly fixed, I did not see it for a week or so, but more likely it never worked and I just failed to notice (I probably just did not click on a .h file).

We might get back to the idea about using memory maps to communicate rather than DDE

[Ceniza]

I just tried disabling plugins and thomas' favourite seems to be the guilty somehow. 25 plugins enabled and it has not problems loading files from Windows Explorer, but if I add CodeCompletion to the list then it fails silently and locks the explorer.

Even better: try to open a file having CodeCompletion enabled. It'll fail to load it, but then go to Plugins->Manage plugins and disable CodeCompletion and you'll see the file is magically loaded.

[edit]
Great, I just found a bug report already points to CodeCompletion as the guilty. After some tests I've just found the call to ClassBrowserBuilderThread::BuildTree seems to be the key to this problem, I just cannot find where inside ClassBrowserBuilderThread::BuildTree is it (location of the call: classbrowserbuilderthread.cpp line 97).

Disabling that line solves the problem, but then you won't get the tree in the Symbols tab. Any guesses?
[/edit]

[Ceniza]

Now I would like the Don to take a look at this, since he's more familiar with that plugin (attached file).

By applying that patch, ClassBrowserBuilderThread::Entry looks... useless (meaning the thread would be unnecessary). In the few tests I ran, Code::Blocks was able to load files without any problem and the plugin seemed to be working just fine like that.

I'm not aware of the side effects of that patch, but you could maybe spot them... or even better, see none so it can be applied to head :wink:

[attachment deleted by admin]

[Ceniza]

I've been playing a bit more, trying this and that, and so far I've got another patch that won't remove the thread's functionality (finally decided to check its real purpose) while fixing the problem with DDE.

I'll just apply it to head so people can start using it in nightlies and see how it goes. Just in case something goes wrong (I don't really see why it could), I bet it will be reported in the forums, which I'm constantly checking.