Hua, managed to track down this pretty ugly bug...

What happened - when I modified some files outside of codeblocks and switched back to codeblocks, a dialog asking me whether the files should be reloaded appeared but the whole system got frozen - and I mean really the whole system - I couldn't click anything at all and couldn't use the keyboard either (fortunately I could switch to virtual console with ctrl+F2 and kill codeblocks from there). After some testing, I noticed that this happened only when I was fast enough and clicked the editor before the reload message appeared.

OK, this is the reason for this behaviour: wxscintilla calls CaptureMouse() on the scintilla window when you click it and ReleaseMouse() on button up. Works fine unless it's interrupted by something else - a modal dialog window for example. In this case, interesting thing happens - you can only work with the modal dialog (because it's modal) but you cannot because the window below it has the capture - total deadlock.

So basically the main change of this path is that I release the mouse capture in ScintillaWX::DoLoseFocus(). I have also slightly simplified the SetMouseCapture and HaveMouseCapture methods so they are easier to reason about.

This should also fix the thing described at the end of app.cpp - CheckForExternallyModifiedFiles() should be callable directly and the mouse shouldn't be in "selecting mode" because it shouldn't have capture any more. I'll post a patch for this when the current patch gets tested and approved.

Very nice one... I am happy to test...

You can easily reproduce the original bug by making a selection of some code and while selecting it, pressing Ctrl+F (search dialog appears and everythong freezes).

Looking at the patch again, I think that from scintilla point of view, SetMouseCapture(false) should come to SetFocusState() - then it's common for all platforms. I'll submit this patch to the scintilla developer and get some feedback from him.

If interested, here is the discussion I had with Neil Hodgson about the problem:

http://groups.google.com/group/scintilla-interest/browse_thread/thread/ef55d73b71bf1459

O... having applied this patch results in the following:

If I scroll an editor using the scrollbar the text in the editor gets selected (???). This is surely a bug. So that's not a good solution... Any advise / update?!

Hmm, interesting - what exactly do you do? I can't reproduce this behavior - but it also could be platform-dependent...

What may be worth trying is to revert this patch and only keep the call

SetMouseCapture(false);

in ScintillaWX::DoGainFocus(). The change made to the other functions was merely a simplification but possibly (for some unknown reason) not correct.

Btw. thanks for the clarification of wxScintilla development on scintilla mailing list. Are there any plans for codeblocks to use STC instead of wxScintilla?

It's on Windows (XP an Vista at least).

All you need to do is the following:

- open a project

- open a file in an editor

- point the cursor to any line (e.g. in the middle) of your code

- scroll the editor using the scrollbars

--> The text in continuously being selected starting from the cursors position (meaning the selection increases / decreases the more you scroll).

OK, I can't reproduce it under Linux (and in the following two weeks I won't have enough time to install a development environment under Windows).

However, I probably know why there is a difference between Windows and Linux - under Windows the scrollbar is a part of the window while under gtk it's a separate window. So under Windows even if you are using the scrollbar, it appears as if you were inside the window and had your mouse button pressed - and you get the selected text.

Please try if what I have suggested in my previous post helps (it's a new revision of this patch). If it does, please let me know - it'll save a lot of my time not having to build codeblocks under Windows.

...give me some time. I am rather busy atm. I'll report back.

Seems to work that way. I've applied it in the scintilla branch which will be merged soon into trunk.

Good to hear!

By the way, could you please apply 002802 to scintilla branch as well? It's the only issue that prevents codeblocks from being compiled by gcc 3.3.3 (and I'd guess the same holds for older gcc's as well). If you look at the patch, it just splits one line of declarations into two lines of equivalent declarations so no bug can be hidden here. I really wonder why the old gcc doesn't like that...

Applied 002802 into trunk, scintilla branch is no longer active (was merged into trunk).