Recent Posts

Pages: 1 2 3 [4] 5 6 7 8 9 10
31
Development / Re: Crash when using with SVG files
« Last post by ollydbg on October 02, 2022, 04:53:36 pm »
It was a misunderstanfing on my side, it is fixed now.

Good work.
32
Development / Re: Crash when using with SVG files
« Last post by Miguel Gimenez on October 02, 2022, 01:42:20 pm »
It was a misunderstanfing on my side, it is fixed now.
33
Development / Re: How to compile Code::Blocks 20.03 in 32-bit mode with TDM-GCC
« Last post by Anaflion on October 02, 2022, 12:55:14 pm »


If you are interested I can write a how-to telling all the steps for compiling C::B in both x86 and x64 flavours using TDM-GCC-64.

Hello!   

Yes, please.  If You would! 

I compiled my app and statically links and it x64 with libs by TDM-GCC and now i should make statically linked app x32.
34
Development / Re: Crash when using with SVG files
« Last post by gd_on on October 02, 2022, 12:53:52 pm »
In my own software, I use wxBitmapBundle::FromSVGFile() in wxWidgets 3.2.1 and never met such problems (until now ???)
35
Nightly builds / Re: The 01 October 2022 build (12932) is out.
« Last post by killerbot on October 02, 2022, 09:06:03 am »
the debug symbols are kicked out on the one of the nightlies, a strip pass is being executed.
36
Help / Re: Caret style = Block and selections?
« Last post by VbCl8ye2vyFPaP0M on October 02, 2022, 03:17:04 am »
Scintilla (and NotePad++) has now fixed this bug (even though apparently they call it a feature! :-)  ). See information in https://github.com/notepad-plus-plus/notepad-plus-plus/issues/11944
37
Nightly builds / Re: The 01 October 2022 build (12932) is out.
« Last post by Pecan on October 02, 2022, 02:36:11 am »
Downloaded and installed Nightly 12932. It executes correctly. Already had wx 3.2.1 on my Windows 10 (64-bit) platform.

Built a 64-bit version of C::B 12932 from source using Msys2. Attempting to run it, I got three dialog boxes telling me that Codeblocks.exe couldn't find an entry point in Codeblocks.exe, codeblocks.dll or wxmsw32u_gcc_custom.dll, and then exiting.

The only apparent differences readily noticeable were the sizes of wxmsw32u_gcc_custom.dll and wxmsw32u_gl_gcc_custom.dll between my version and the Nightly version. My versions of those DLL files were substantially larger.

Any ideas as to why wx 3.2.1 libraries would have different size DLL files on different platforms?

Make sure that wxWidgets and CodeBlocks are built with the same compiler.
38
Nightly builds / Re: The 01 October 2022 build (12932) is out.
« Last post by Frank_CB on October 02, 2022, 12:57:07 am »
Downloaded and installed Nightly 12932. It executes correctly. Already had wx 3.2.1 on my Windows 10 (64-bit) platform.

Built a 64-bit version of C::B 12932 from source using Msys2. Attempting to run it, I got three dialog boxes telling me that Codeblocks.exe couldn't find an entry point in Codeblocks.exe, codeblocks.dll or wxmsw32u_gcc_custom.dll, and then exiting.

The only apparent differences readily noticeable were the sizes of wxmsw32u_gcc_custom.dll and wxmsw32u_gl_gcc_custom.dll between my version and the Nightly version. My versions of those DLL files were substantially larger.

Any ideas as to why wx 3.2.1 libraries would have different size DLL files on different platforms?
39
Plugins development / Re: Code completion using LSP and clangd
« Last post by Pecan on October 01, 2022, 09:35:41 pm »
Since i have seen quite some string encoding related issues in this thread and many try-and-error attempts to solve them, i want to add my two cents to these issues.

Never do this:
Code
wxString contentsValue = contents.at("value").get<std::string>();

This converts the std::string into a wxString using the currently set C++ locale. A locale set in CodeBlocks. But this std::string does not come from CodeBlocks. Also, std::string has, at least on Windows, no support for UTF-8. However, this doesn't stop anyone from putting UTF-8 into such a string. As long as you don't use methods that depend on the locale, this is fine. The code snippet above does depend on the locale.

Now these two lines:
Code
std::string contentsValueStdString = contents.at("value").get<std::string>();
wxString contentsValue(contentsValueStdString.c_str(), wxConvUTF8);

These lines manually convert the std::string to a wxString by telling the wxString object that the std::string does contain UTF-8. Since the user post says this does fix the issue, apparently there is UTF-8 inside that std::string.

I suggest you figure out what encoding Clang does use and then check your code if you rely anywhere else on such automatic conversions. Also, wxWidgets offers the build option wxNO_UNSAFE_WXSTRING_CONV to disable such implicit conversions, but i am not sure if this does also work for std::string, they mention only C-Strings.

Hi, sodev, thanks for the advice.

If I remember correctly, the clangd_client use the UTF-8 format for it's input source. Normally I use UTF-8 for my source code, but my system(Windows) locale is not UTF-8.

I see that clangd's document: Protocol extensions UTF-8 offsets

It said it can support UTF-8.

@sodev
@ollydbg

Thanks for this. I'll get to work checking every use of std::string to wxString in the source.

Clangd by default uses utf16. But it allows the use of utf8 as an option.
40
Nightly builds / Re: The 01 October 2022 build (12932) is out.
« Last post by killerbot on October 01, 2022, 05:06:28 pm »
WX 3.2.1
Pages: 1 2 3 [4] 5 6 7 8 9 10