The 11 october 2006 build is out.

[killerbot]

When I do it like Tiwag said, I can reproduce it also.

[thomas]

Using the artoj's snippet, I can reproduce it in 3049, but not in 3074.

Tiwag's example fails in both revisions, but only if you are at the very end of the file (i.e. if you have a closing curly brace, it does not fail).

[thomas]

Code

Index: nativeparser.cpp
===================================================================
--- nativeparser.cpp	(revision 3074)
+++ nativeparser.cpp	(working copy)
@@ -650,6 +650,10 @@
     {
         ++blockStart; // skip {
         int blockEnd = ed->GetControl()->GetCurrentPos();
+
+        if(blockStart >= blockEnd)
+            return false;
+
         wxString buffer = ed->GetControl()->GetTextRange(blockStart, blockEnd);
         buffer.Trim();
         if (!buffer.IsEmpty() && !parser->ParseBuffer(buffer, false, false, true))

[artoj]

<snip>

Hmm... I applied your patch and the assert seems to be fixed, but:

Code

#include <iostream>

class TestClass
{
	public:
		TestClass();
		~TestClass();
		int TestMethod() { return 0; }
};

int main() {
	TestClass* t = new TestClass();
	|
	return 0;
}

If I replace the pipe symbol with "t->" the code completion does not work (but I guess this is a different bug). If I again move the opening brace to new line, it works as expected.

[killerbot]

Code

Index: nativeparser.cpp
===================================================================
--- nativeparser.cpp	(revision 3074)
+++ nativeparser.cpp	(working copy)
@@ -650,6 +650,10 @@
     {
         ++blockStart; // skip {
         int blockEnd = ed->GetControl()->GetCurrentPos();
+
+        if(blockStart >= blockEnd)
+            return false;
+
         wxString buffer = ed->GetControl()->GetTextRange(blockStart, blockEnd);
         buffer.Trim();
         if (!buffer.IsEmpty() && !parser->ParseBuffer(buffer, false, false, true))

will this be committed ?

[mandrav]

will this be committed ?

Allow me to check this issue first myself...

[thomas]

If it works... feel free to commit it.

I don't know what the function in question is actually doing, but I stepped through it in the debugger until  the assert() fired off (which is in the line after my patch).
The watches window shows that blockEnd is at the last character of the file, and blockStart points beyond the end of the file. That doesn't make sense to me, and it is what triggers the assert(), too. So, no idea whether it is a good solution for the actual problem, but it avoids the assert error

[mandrav]

I committed the fix.

If it works... feel free to commit it.

Well, excuse me but I can't trust "it works" from you since you admittedly never use this functionality .
As a matter of fact, your patch fixed the assert but disabled code-completion (for these cases), lol.
So, the patch to your patch is this:

Code

-        if(blockStart >= blockEnd)
-            return false;
+       if (blockStart >= blockEnd)
+            blockStart = blockEnd;

[killerbot]

aaaaaaaaaaah : excellent teamwork  :lol: :lol: :lol: :lol:

[thomas]

Well, excuse me but I can't trust "it works" from you since you admittedly never use this functionality .

As it happens, I did, in order to pinpoint the location of the problem. And yes, I immediately regretted enabling CC again. 
Oh yes, and I did not say "it works". I said "I don't know what that function is supposed to do, but I got rid of the assert error"  That's why I did not commit it right away, but left for someone else to test.

I really wish one could actually use code completion. Believe me, I would use it if it was possible. However, turning on code completion practically makes the IDE unusable.  :lol:

It's not only about an occasional crash or an assertion, the annoying "freeze after save" and "freeze as you type" problems are back again, too.

[Maddin]

Thanks for the advanced tabbing!

But why is it that everytime I save a file the application totaly freezes for about 5 seconds?

EDIT: rev 3074 Windows Unicode

Code completion...

Is there any way to give the parsing thread lower priority?

EDIT:

However, turning on code completion practically makes the IDE unusable.  Laughing

oh ... then you have allready answered my question

[mandrav]

It's not only about an occasional crash or an assertion, the annoying "freeze after save" and "freeze as you type" problems are back again, too.

Is there any way to give the parsing thread lower priority?

Because everybody has his own opinions on things, allow me to clear this up:
The freeze has nothing to do with the parser threads. The freeze is for the symbols view to be updated. Although this should be running in its own thread, something is obviously wrong there. I 'm planning to fix it but I have to boot to Linux. So you have to wait until the weekend...

[tiwag]

I really wish one could actually use code completion. Believe me, I would use it if it was possible...

aaarrrrgh ! you should try it for a while instead of %&$§"§$%/(& ' ing

CC is usable, with all limitations, but it is a great help.
i like it and enjoy it that it gets better and better ...

[szaszafrasz]

A bug: file/import project/  "any" .
For example: when I try import "aabbcc.dsp", it says "aabbbcc.cbp" not found.

[mandrav]

A bug: file/import project/  "any" .
For example: when I try import "aabbcc.dsp", it says "aabbbcc.cbp" not found.

Try File->Open