The 09 December 2017 build (11246) is out.

[BlueHazzard]

- Open Code:Block project.
- Select a file in the "Projects" tab and quickly click inside the newly opened file (like cbeditor.cpp)

Result:

- The filename is added to the file where the mouse was clicked:

   C:\Download\gnu\codeblocks-code-10924-trunk\src\sdk\cbeditor.cpp

Running Win 7 64-bit.
CodeBlocks svn 11246, wx3.0.3 - 64-bit.

i can not reproduce this win7 64bit wx2.8 wx3.0 wx3.1
Are you using the middle mouse button?

[oBFusCATed]

Nope. The left button is enough to reproduce it. But it happens with default settings and there is a way to prevent it changing settings. I don't know which setting causes it yet...

[ambarj2009]

Hi.

I am testing this compilation (11246), the first thing I noticed in the editor is that the cursor does not respond at times. It often disappears and is not shown. Other times, there is a fixed mark of the cursor in a place through which it passed, although it is no longer there.

Regards.
Ambarj2009.

[stahta01]

Hi.

I am testing this compilation (11246), the first thing I noticed in the editor is that the cursor does not respond at times. It often disappears and is not shown. Other times, there is a fixed mark of the cursor in a place through which it passed, although it is no longer there.

Regards.
Ambarj2009.

Since, you failed to post your Operating System (OS) name and version; it is likely your post will be ignored.

Tim S.

[ambarj2009]

Hi.

I am testing this compilation (11246), the first thing I noticed in the editor is that the cursor does not respond at times. It often disappears and is not shown. Other times, there is a fixed mark of the cursor in a place through which it passed, although it is no longer there.

Regards.
Ambarj2009.

Since, you failed to post your Operating System (OS) name and version; it is likely your post will be ignored.

Tim S.

411/5000
Oh, all right, it's a Windows 10 Home 64 bit computer.

The fact is that I read the rules and I did not see where he said such a thing. I did not bother looking to see if this problem already exists or is detected. I'll have to read more and ask less.

I go back to my previous version until I solve it.

By the way, this problem started to appear since I started using Code::Blocks 64 bits versions.

Regards.

[oBFusCATed]

Yes, it is known problem with wx3.0 based nightlies. It will be fixed sometime in the future. When I don't know. If someone can debug it, then it will be best.

[oBFusCATed]

Would it be possible for windows people building wx3.x+64bit builds to test if the patch below resolves the problem with the editor redraw?

Code

diff --git a/src/src/main.cpp b/src/src/main.cpp
index 0ed4811..4707aa0 100644
--- a/src/src/main.cpp
+++ b/src/src/main.cpp
@@ -4321,7 +4321,15 @@ void MainFrame::OnEditorUpdateUI(CodeBlocksEvent& event)
     }
 
     if (Manager::Get()->GetEditorManager() && event.GetEditor() == Manager::Get()->GetEditorManager()->GetActiveEditor())
+    {
+#if defined(__WXMSW__) && wxCHECK_VERSION(3, 0, 0)
+        // Execute the code to update the status bar outside of the paint event for scintilla.
+        // Executing this function directly in the event handler causes redraw problems on Windows.
+        CallAfter(DoUpdateStatusBar);
+#else
         DoUpdateStatusBar();
+#endif // defined(__wxMSW__) && wxCHECK_VERSION(3, 0, 0)
+    }
 
     event.Skip();
 }
-- 

[Xaviou]

Hi

Would it be possible for windows people building wx3.x+64bit builds to test if the patch below resolves the problem with the editor redraw?

Code

diff --git a/src/src/main.cpp b/src/src/main.cpp
index 0ed4811..4707aa0 100644
--- a/src/src/main.cpp
+++ b/src/src/main.cpp
@@ -4321,7 +4321,15 @@ void MainFrame::OnEditorUpdateUI(CodeBlocksEvent& event)
     }
 
     if (Manager::Get()->GetEditorManager() && event.GetEditor() == Manager::Get()->GetEditorManager()->GetActiveEditor())
+    {
+#if defined(__WXMSW__) && wxCHECK_VERSION(3, 0, 0)
+        // Execute the code to update the status bar outside of the paint event for scintilla.
+        // Executing this function directly in the event handler causes redraw problems on Windows.
+        CallAfter(DoUpdateStatusBar);
+#else
         DoUpdateStatusBar();
+#endif // defined(__wxMSW__) && wxCHECK_VERSION(3, 0, 0)
+    }
 
     event.Skip();
 }
-- 

Well done : seems to do the job.

If one want to test, I've uploaded the corresponding build to my Google Drive (rev 11278):

• An archive containing the original build
• An archive containing the pathced build

Regards
Xav'

[oBFusCATed]

It is not a good job, just a workaround...
Is this 64bit or 32bit you're testing?

[Xaviou]

It is not a good job, just a workaround...
Is this 64bit or 32bit you're testing?

I've tested with wxWidgets 3.0.3 - 64 bits built with MinGW-TDM-5.1.0.

And I confirm that that problems I was talking about in this post disappeared.

Regards
Xav'