Author Topic: The 13 December 2020 build (12240) is out.  (Read 17263 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5291
The 13 December 2020 build (12240) is out.
« on: December 13, 2020, 10:43:55 am »
new PATCHED wx dll , please download these too and replace your old ones !!!

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw31u_gcc_cb_wx313_2D_gcc810-mingw64-2.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls8.1.0.7z


The 13 December 2020 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2020/CB_20201213_rev12240_win64.7z
  - Linux :
   none

The current SDK version is : 2.4.0

Resolved Fixed:

  • wxContribItems: Remove warnings about deprecated wxPen and wxBrush styles in wxContribItems (ticket #1037, thanks Miguel Gimenez)
  • wxContribItems: Remove warnings about deprecated wxPen and wxBrush styles in wxContribItems (ticket #1037, thanks Miguel Gimenez)
  • UI: Make the script console to use the Message logs' font size
  • UI: Use the same logic for the default value of the "Message logs' font size"

Regressions/Confirmed/Annoying/Common bugs:



    Offline stahta01

    • Lives here!
    • ****
    • Posts: 7130
      • My Best Post
    Re: The 13 December 2020 build (12240) is out.
    « Reply #1 on: December 13, 2020, 11:16:44 am »
    new PATCHED wx dll , please download these too and replace your old ones !!!

    The wxWidgets DLL on the download link was the same as the one I downloaded with the last nightly.
    Is the link wrong?

    Tim S.
    C Programmer working to learn more about C++ and Git.
    On Windows 7 64 bit and Windows 10 32 bit.
    On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
    --
    When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

    Offline omlk

    • Multiple posting newcomer
    • *
    • Posts: 58
    Re: The 13 December 2020 build (12240) is out.
    « Reply #2 on: December 13, 2020, 07:51:43 pm »
    Why not use MSYS2 for compiling Code::Blocks? MSYS2 include MinGW gcc v11?
    « Last Edit: December 15, 2020, 10:04:17 am by omlk »

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13306
      • Travis build status
    Re: The 13 December 2020 build (12240) is out.
    « Reply #3 on: December 14, 2020, 01:24:03 am »
    omlk: What would we gain?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline gh_origin

    • Multiple posting newcomer
    • *
    • Posts: 48
    Re: The 13 December 2020 build (12240) is out.
    « Reply #4 on: December 14, 2020, 04:38:05 am »
    omlk: What would we gain?

    A Unix-like build environment. Produces native binaries using MinGW, doesn't need to ship another DLL like Cygwin. But there is MSYS2 DLL for anyone need a POSIX compatibility layer.

    BTW, if you choose to go forward with LSP and CCLS, then MSYS2 is a good choice. You have to depend on it anyway. Offering CodeBlocks packages on MSYS2 (co-operate with the MSYS2 team), so installing CodeBlocks with all the needed stuffs for CCLS made easy with just pacman -S codeblocks, pacman will handle all of the dependencies for you, the users don't need to setup CCLS packages themselves before able to use CodeBlocks.

    Please note, there is Qt Creator and complete Qt5 packages for MSYS2 for a while. It's nothing wrong for CodeBlocks to follow. Employing MSYS2 also lower the maintenance efforts, as we now using the same Unix-like environment across platforms, no need to set Windows specific stuffs anymore.

    And also, if you choose to continue to distribute CodeBlocks binaries like what you are doing now alongside with/instead of MSYS2 packages of CodeBlocks, you still need to bundle MSYS2 related stuffs for CCLS anyway. So using the same environment really helps avoiding a lot of troubles.

    Offline stahta01

    • Lives here!
    • ****
    • Posts: 7130
      • My Best Post
    Re: The 13 December 2020 build (12240) is out.
    « Reply #5 on: December 14, 2020, 06:33:30 am »
    omlk: What would we gain?

    A Unix-like build environment. Produces native binaries using MinGW, doesn't need to ship another DLL like Cygwin. But there is MSYS2 DLL for anyone need a POSIX compatibility layer.

    BTW, if you choose to go forward with LSP and CCLS, then MSYS2 is a good choice. You have to depend on it anyway. Offering CodeBlocks packages on MSYS2 (co-operate with the MSYS2 team), so installing CodeBlocks with all the needed stuffs for CCLS made easy with just pacman -S codeblocks, pacman will handle all of the dependencies for you, the users don't need to setup CCLS packages themselves before able to use CodeBlocks.

    Please note, there is Qt Creator and complete Qt5 packages for MSYS2 for a while. It's nothing wrong for CodeBlocks to follow. Employing MSYS2 also lower the maintenance efforts, as we now using the same Unix-like environment across platforms, no need to set Windows specific stuffs anymore.

    And also, if you choose to continue to distribute CodeBlocks binaries like what you are doing now alongside with/instead of MSYS2 packages of CodeBlocks, you still need to bundle MSYS2 related stuffs for CCLS anyway. So using the same environment really helps avoiding a lot of troubles.

    I have tried off and on to get the CB configure/make method of build to work under MSys2 and I have failed!
    I am now using edited CB Projects to build CB under MSys2 and it works reasonably well.

    Tim S.
    C Programmer working to learn more about C++ and Git.
    On Windows 7 64 bit and Windows 10 32 bit.
    On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
    --
    When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

    Offline omlk

    • Multiple posting newcomer
    • *
    • Posts: 58
    Re: The 13 December 2020 build (12240) is out.
    « Reply #6 on: December 14, 2020, 10:32:02 am »
    omlk: What would we gain?

    А step into the future.  ;)

    Offline omlk

    • Multiple posting newcomer
    • *
    • Posts: 58
    « Last Edit: December 15, 2020, 09:50:50 am by omlk »

    Offline stahta01

    • Lives here!
    • ****
    • Posts: 7130
      • My Best Post
    Re: The 13 December 2020 build (12240) is out.
    « Reply #8 on: December 14, 2020, 12:20:17 pm »
    Pay attention!
    -fcommon

    https://gcc.gnu.org/gcc-10/changes.html

    Please think! The CB Team can already use a newer GCC 10 Compiler without using MSys2.

    Tim S.
    C Programmer working to learn more about C++ and Git.
    On Windows 7 64 bit and Windows 10 32 bit.
    On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
    --
    When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13306
      • Travis build status
    Re: The 13 December 2020 build (12240) is out.
    « Reply #9 on: December 14, 2020, 12:47:16 pm »
    А step into the future.  ;)
    Ok, you can troll and waste our time, but what else would we gain?
    Is GCC 10 faster to build?
    Does it produce faster binaries?
    Does it actually work? :)
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13306
      • Travis build status
    Re: The 13 December 2020 build (12240) is out.
    « Reply #10 on: December 14, 2020, 12:50:20 pm »
    Pay attention!
    -fcommon

    https://gcc.gnu.org/gcc-10/changes.html
    Why should we care about a C only flag?
    You continue to be trolling.

    p.s. You can use GCC 10 for your projects. You're not obliged to use the compiler we use. You have to use the same compiler if you want to do binary C::B plugins.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline omlk

    • Multiple posting newcomer
    • *
    • Posts: 58
    Re: The 13 December 2020 build (12240) is out.
    « Reply #11 on: December 14, 2020, 02:40:18 pm »
    Please think! The CB Team can already use a newer GCC 10 Compiler without using MSys2.

    Tim S.

    Okay, I'll explain why I don't think gcc,g++ 10 is used. Because http://sourceforge.net only has the latest buggy version 8.1.0. If the development team used to get the build C::B Linux, it would have long been used gcc,g++ 10, as well as the impression that builds in Windows.If my guess is wrong, please tell me exactly where I went wrong.
    « Last Edit: December 14, 2020, 02:45:56 pm by omlk »

    Offline omlk

    • Multiple posting newcomer
    • *
    • Posts: 58
    Re: The 13 December 2020 build (12240) is out.
    « Reply #12 on: December 14, 2020, 03:12:17 pm »
    А step into the future.  ;)
    Ok, you can troll and waste our time, but what else would we gain?
    Is GCC 10 faster to build?
    Does it produce faster binaries?
    Does it actually work? :)

    I wasn't going to troll you or waste your precious time on nonsense.

    Offline gh_origin

    • Multiple posting newcomer
    • *
    • Posts: 48
    Re: The 13 December 2020 build (12240) is out.
    « Reply #13 on: December 14, 2020, 04:06:17 pm »
    I have tried off and on to get the CB configure/make method of build to work under MSys2 and I have failed!
    I am now using edited CB Projects to build CB under MSys2 and it works reasonably well.

    Tim S.

    The problem is with make. Not MinGW! This is why you could use MSYS2's MinGW to build CodeBlocks using CodeBlocks successfully.
    Please note that mingw32-make's Makefiles and make's Makefiles are incompatible.
    I think you should regenerate it using autoconf -i -f and try again.
    This is the reason why CodeLite has 'CodeLite Makefile Generator' and 'CodeLite Makefile Generator - UNIX'.
    I always hope someday CodeBlocks could have the Makefile generator ability of CodeLite.
    CodeLite also supports cmake. But I don't use cmake, so I don't care.

    Offline gh_origin

    • Multiple posting newcomer
    • *
    • Posts: 48
    Re: The 13 December 2020 build (12240) is out.
    « Reply #14 on: December 14, 2020, 04:08:35 pm »
    Please think! The CB Team can already use a newer GCC 10 Compiler without using MSys2.

    Tim S.

    I don't think so. If I recall it right, CodeBlocks need CXXFLAGS='-fpermissive' when building with higher GCC. Correct me if I'm wrong.

    Offline gh_origin

    • Multiple posting newcomer
    • *
    • Posts: 48
    Re: The 13 December 2020 build (12240) is out.
    « Reply #15 on: December 14, 2020, 04:12:31 pm »
    Okay, I'll explain why I don't think gcc,g++ 10 is used. Because http://sourceforge.net only has the latest buggy version 8.1.0. If the development team used to get the build C::B Linux, it would have long been used gcc,g++ 10, as well as the impression that builds in Windows.If my guess is wrong, please tell me exactly where I went wrong.

    The CodeBlocks projects used to use TDM GCC before it was abandoned. They just switched to MinGW64 for the last release.
    Now TDM GCC is back. It's nothing wrong for them to switching back to it again:

    https://jmeubank.github.io/tdm-gcc/download/

    Your reasons was wrong. I would say they should switch to MSYS2 because of CCLS and their future dependence of LSP.
    « Last Edit: December 14, 2020, 04:24:39 pm by gh_origin »

    Offline gh_origin

    • Multiple posting newcomer
    • *
    • Posts: 48
    Re: The 13 December 2020 build (12240) is out.
    « Reply #16 on: December 14, 2020, 04:22:13 pm »
    I wasn't going to troll you or waste your precious time on nonsense.

    I don't think you are trolling, too. You are just annoying and it takes energy to address your wrong statements so I just try my best to avoid talking with you.

    But this is the last time I use CodeBlocks so it's no longer a problem for me.

    I no longer have to teach Programming anymore. I'm back teaching Elementary Math only.

    They hired a new teacher to teach Programming for the students and he switched to VSCode, as I and my students have done all of the cleaning job so the sample code no longer depends on any Borland specific features and compile cleanly under TDM GCC 9.2 and Clang 11 with -std=gnu++98 now. It's a bit sad that the code still not yet conforms to C++11.

    Bye everyone. And good luck to you all with your new adventure with LSP and CCLS.

    Offline stahta01

    • Lives here!
    • ****
    • Posts: 7130
      • My Best Post
    Re: The 13 December 2020 build (12240) is out.
    « Reply #17 on: December 14, 2020, 05:54:05 pm »
    I have tried off and on to get the CB configure/make method of build to work under MSys2 and I have failed!
    I am now using edited CB Projects to build CB under MSys2 and it works reasonably well.

    Tim S.

    The problem is with make. Not MinGW! This is why you could use MSYS2's MinGW to build CodeBlocks using CodeBlocks successfully.
    Please note that mingw32-make's Makefiles and make's Makefiles are incompatible.
    I think you should regenerate it using autoconf -i -f and try again.
    This is the reason why CodeLite has 'CodeLite Makefile Generator' and 'CodeLite Makefile Generator - UNIX'.
    I always hope someday CodeBlocks could have the Makefile generator ability of CodeLite.
    CodeLite also supports cmake. But I don't use cmake, so I don't care.

    I use MSys2 all the time! Have you even once created an MSys2 package?

    I am going to write you off as someone who knows little about what they post; till you list for me the packages in MSys2 you have contributed to!

    Tim S.


    C Programmer working to learn more about C++ and Git.
    On Windows 7 64 bit and Windows 10 32 bit.
    On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
    --
    When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

    Offline killerbot

    • Administrator
    • Lives here!
    • *****
    • Posts: 5291
    Re: The 13 December 2020 build (12240) is out.
    « Reply #18 on: December 14, 2020, 06:10:01 pm »
    new PATCHED wx dll , please download these too and replace your old ones !!!

    The wxWidgets DLL on the download link was the same as the one I downloaded with the last nightly.
    Is the link wrong?

    Tim S.

    no, but I repeat this some time, since not everybody see every nightly. Wil ltry to do a better job on this and on the next nightly remove it.

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 176
    Re: The 13 December 2020 build (12240) is out.
    « Reply #19 on: December 17, 2020, 09:49:35 am »
    Dear Code::Blocks Developers.


    I still face that the symbol-browser is not available in the nightly.

    Thus I rebuild Code::Blocks base on the patch http://forums.codeblocks.org/index.php/topic,23580.60.html from Miguel Gimenez http://forums.codeblocks.org/index.php?action=profile;u=34306 by my self.

    I have done the same since the symbol-browser was disabled but I never faced issues with it.
    • From my point of view a symbol-browser is an essential part of an IDE like Code::Blocks.
    • Thus I like to ask you to integrate it again with the nightly build.
    • In the case that some users still face issues with it, you may deactivate it by default and add a warning visible when the user is activating it.
    • This way the single user could decide, if symbol-browser becomes active or not.


    I wish you and all C::B users a marry Christmas and a happy new year.

    Take care about you and stay healthy,
                                                           Eckard Klotz.

    Offline Miguel Gimenez

    • Lives here!
    • ****
    • Posts: 710
    Re: The 13 December 2020 build (12240) is out.
    « Reply #20 on: December 17, 2020, 10:30:56 am »
    There is a fully threaded version of my patch for the symbol browser, see https://sourceforge.net/p/codeblocks/tickets/1031/. If you use it and have any problem please report it in the ticket (and if it works as it should please also report).

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5345
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 13 December 2020 build (12240) is out.
    « Reply #21 on: December 17, 2020, 11:12:08 am »
    Dear Code::Blocks Developers.


    I still face that the symbol-browser is not available in the nightly.

    Thus I rebuild Code::Blocks base on the patch http://forums.codeblocks.org/index.php/topic,23580.60.html from Miguel Gimenez http://forums.codeblocks.org/index.php?action=profile;u=34306 by my self.

    I have done the same since the symbol-browser was disabled but I never faced issues with it.
    • From my point of view a symbol-browser is an essential part of an IDE like Code::Blocks.
    • Thus I like to ask you to integrate it again with the nightly build.
    • In the case that some users still face issues with it, you may deactivate it by default and add a warning visible when the user is activating it.
    • This way the single user could decide, if symbol-browser becomes active or not.


    I wish you and all C::B users a marry Christmas and a happy new year.

    Take care about you and stay healthy,
                                                           Eckard Klotz.

    Hi, you can also look at this post:
    Re: Symbols browser issue of CC has been fixed for my Linux

    I have a custom build binary in github.
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 176
    Re: The 13 December 2020 build (12240) is out.
    « Reply #22 on: December 17, 2020, 01:22:14 pm »
    Hello Miguel Gimenez and Ollydbg.

    Thanks for your reply and all the effort you have taken so far to make the symbol-browser run again.
    • The symbol-browser is working for me without any crash.
    • I will add a more detailed report to your both discussions, you provided the links for.

    What I wanted suggest in this nightly discussion is to add it again to the nightly release again to the next nightlies.
    • You spend so much work in it.
    • So when will the symbol-browser be available again in the normal nightlies and releases?

    Take care and stay healthy,
                                           Eckard Klotz.

    Offline gh_origin

    • Multiple posting newcomer
    • *
    • Posts: 48
    Re: The 13 December 2020 build (12240) is out.
    « Reply #23 on: December 20, 2020, 09:03:38 am »
    I use MSys2 all the time! Have you even once created an MSys2 package?

    I am going to write you off as someone who knows little about what they post; till you list for me the packages in MSys2 you have contributed to!

    Tim S.

    I used Manjaro Linux but not really MSYS2. I have setup MSYS2, let it there, but don't use it much. All of my writings are just what I thought what it should be. I have no way to back it up. I have experience with the pacman package manager but never created any packages either for Arch or MSYS2.

    So, I just wrote what I thought to be right. Honestly, I have no basis for it other than my own experience and reasoning. It could be all wrong.

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 176
    Re: The 13 December 2020 build (12240) is out.
    « Reply #24 on: January 10, 2021, 04:59:02 pm »
    Hello All.

    I wish a happy new year for all Code::Blocks Developers as well as for all Code::Blocks Users.


    Unfortunately I face currently some issues with the Undo functionality of the editor.

    Sometimes a change done in one step for several lines could only be undone line for line. Commenting out several lines by using [Ctrl][Shift][C] is an example for this
    But more confusing is that several independent changes are some times undone in one single step even only the last change should really be undone.

    I'm working with the revision 12240 build by my self on Windows 10.

    The only modifications I have done are


    Somewhere here in the Code::Blocks forum I already read that this issue is already known and that the used Scintilla library-version is the reason.
    Thus I assume that somebody is already working on it.
     
    However, is it possible to clear the undo-queue manually from time to time to ensure that old changes which should definitely be kept will not be undone?

    Please stay well and healthy,
                                             Eckard Klotz.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13306
      • Travis build status
    Re: The 13 December 2020 build (12240) is out.
    « Reply #25 on: January 10, 2021, 06:57:45 pm »
    Edit -> Clear changes history?

    No, it is not a known problem. Give link or post a ticket on sf.net with exact steps to reproduce the problem.
    Also first make sure that geany/scite/codelite/notepad++ behave differently.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 176
    Re: The 13 December 2020 build (12240) is out.
    « Reply #26 on: January 17, 2021, 10:43:29 am »
    Hello oBFusCATed.

    Thanks for your reply and please accept my apologize for my late answer.

    First of all thanks for your tip where to find the "Clear changes history" item.

    Quote
    No, it is not a known problem.

    Quote
    Also first make sure that geany/scite/codelite/notepad++ behave differently.
    • I'm unsure what you mean with mentioning the behaviour of other tools.
    • As far as I understand it it is a problem located in a third-party library used with Code::Blocks.
    • So I understand, that it has to be solved by the third party project.
    • Never the less it is a already known problem. Otherwise you would not mention the other tools.
    • Or do you expect that I as user of Code::Blocks set up a bug-report in the third-party project with the statement, that the third-party library results in a problem with Code::Blocks?

    Quote
    Give link or post a ticket on sf.net with exact steps to reproduce the problem.
    • I think this is the key-question.
    • I completely understand, that with out an reproduce able example it will be not possible to search for the reason.
    • And yes you are right, the examples in the discussion mentioned above are working with C/Cpp and H files.
    • However, over the time and randomly I still face the issue with C/Cpp and H files.
    • Thus the problem is definitely not solved.
    • What I can tell you is, that it happens if you edit several files in parallel.
      • Yesterday I made first some in a header-file in different lines. 
      • Than I modified some other files (cpp). 
      • And when I than turned back to the header to undo the last modification of one line, the editor removed the change in an additional line also.
    • It seams that the Undo memory will be corrupted over the time or the module is compressing the oldest modifications to one.
    • Unfortunately I was not able to reproduce this effect to provide it as an reproduce able example.

    But my main request was how to clear the undo-history and this question was answered by you. So once again thanks for your support.

    Stay well and healthy,
                                    Eckard Klotz.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13306
      • Travis build status
    Re: The 13 December 2020 build (12240) is out.
    « Reply #27 on: January 17, 2021, 01:39:11 pm »
    Quote
    Also first make sure that geany/scite/codelite/notepad++ behave differently.
    • I'm unsure what you mean with mentioning the behaviour of other tools.
    • As far as I understand it it is a problem located in a third-party library used with Code::Blocks.
    • So I understand, that it has to be solved by the third party project.
    • Never the less it is a already known problem. Otherwise you would not mention the other tools.
    • Or do you expect that I as user of Code::Blocks set up a bug-report in the third-party project with the statement, that the third-party library results in a problem with Code::Blocks?

    You're overthinking. We don't know where the problem happens, yet.
    So testing other uses of the library could reveal if it is in the library or in C::B.
    I've never said to log any issues in another project's.
    We're currently investigating where the problem happens.

    • What I can tell you is, that it happens if you edit several files in parallel.
    It will be quite surprising if this is related to multiple files. I think the undo data structures in the editor are not shared between files - we have a wxScintilla object for every tab (if split we have two such objects).

    Are you sure the lexer is set correctly. You can make .cpp/.h files to behave like plaintext files if you switch the lexer.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 176
    Re: The 13 December 2020 build (12240) is out.
    « Reply #28 on: January 18, 2021, 05:02:56 pm »
    Hello oBFusCATed.

    Let's skip the first point even I'm confused about. But I think at the end it is not helping anybody.

    Quote
    It will be quite surprising if this is related to multiple files. I think the undo data structures in the editor are not shared between files - we have a wxScintilla object for every tab (if split we have two such objects).
    As I wrote at the end it happens "randomly". But I faced several times that it happens when I'm stepping back to a file I have edited some time ago.

    What is with my assumption that it is associated with the age of the change I want to redo?
    In the documentation of Scintilla you provided via link (in the bug-report discussion) they write "...  It will continue to collect undoable actions until memory runs out. ...". But they don't mention what happens when memory runs out.

    Furthermore they write "... These transactions can be nested and only the top-level sequences are undone as units. ..."
    Could it be that this nesting will be done with older undoable actions ?

    Quote
    Are you sure the lexer is set correctly. You can make .cpp/.h files to behave like plaintext files if you switch the lexer.
    Actually I have not modified or changed the lexer. However, could you please provide some more details about the doubt you have in mind.
    May be I have really modified it without noticing it.

    Stay well and healthy,
                                    Eckard Klotz.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13306
      • Travis build status
    Re: The 13 December 2020 build (12240) is out.
    « Reply #29 on: January 18, 2021, 05:47:49 pm »
    What is with my assumption that it is associated with the age of the change I want to redo?
    I doubt there is something called age in the Undo data structure, but I don't know how it works in details, so you might be correct or not. I just think that this assumption doesn't seems plausible.

    In the documentation of Scintilla you provided via link (in the bug-report discussion) they write "...  It will continue to collect undoable actions until memory runs out. ...". But they don't mention what happens when memory runs out.
    C::B crashes, probably.

    Furthermore they write "... These transactions can be nested and only the top-level sequences are undone as units. ..."
    Could it be that this nesting will be done with older undoable actions ?
    This is not user visible. It is meant to group multiple actions in a single undo operation. Say you have an operation "replace all AAA with BBB", to implement it you'll do multiple scintilla actions and  if you don't group them the user would be able to (or have to) undo every single replace operation. The nesting feature allows composing operations without too much hassle and surprises (there are some places where we don't use this api and the results aren't good).

    Actually I have not modified or changed the lexer. However, could you please provide some more details about the doubt you have in mind.
    May be I have really modified it without noticing it.
    I don't ask if you've modified the C/C++ lexer, but if you're using it or not when the bug happens. Edit -> Highlight mode or the combo in the status bar would tell you.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 176
    Re: The 13 December 2020 build (12240) is out.
    « Reply #30 on: January 20, 2021, 05:05:32 pm »
    Hello oBFusCATed.

    Quote
    I don't ask if you've modified the C/C++ lexer, but if you're using it or not when the bug happens. Edit -> Highlight mode or the combo in the status bar would tell you.

    I used in all cases the the lexer / highlight mode chosen by Code::Blocks C/Cpp.
    • I do not remember to have chosen an other lexer / highlight mode manually in the last years with Code::Blocks.
    • Actually this would make no sense for me, sice I never faced problems with the highlighting for my C and Cpp projects.
    • I use Code::Blocks for editing C and Cpp projects only.

    Stay well and healthy,
                                    Eckard Klotz.