Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
https://status.github.com/messages

I have been working on Code::Blocks and wxWidgets issues today. And, I noticed github website was not showing my work.

The link above shows they know there is a problem.

Tim S.

2
Good. The change to scintilla is not welcome, because we want to keep it as close to the one in wx as possible.
3
Using Code::Blocks / Re: [HELP] How to change toolbar icons size?
« Last post by oBFusCATed on Yesterday at 11:49:26 pm »
@Daniel.1954: English is the language of the forum. Please use it otherwise the benefit of your posts is minimal!
4
Lorsqu'un texte comme ça m'apparait, c'est parce que j'ai oublié de mettre le «mingw32» dans le «Project build options»  «Linker settings» en tête de la liste des librairies. C'est le mieux que je puis faire pour toi.
5
Je puis mettre les dll's manquant à l'exécutable lors de la compilation de mon projet. Dans Build option... -> Pre/post build steps -> Post-build-steps, add cette ligne :
      ex:       cmd /c XCOPY C:\OpenGL-CB\SDL2\bin\*.dll $(TARGET_OUTPUT_DIR) /D /Y, ENSUITE COMPILE. Les fichiers dll's ajouter au bin\debug ou bin\release sont affichées
à la console de Code::Blocks. J'ai essayé avec cette syntaxe: project.AddCommandsAfterBuild(_T("XCOPY $(#sdl2)\\bin\\*.dll $(TARGET_OUTPUT_DIR) /D /Y"));  mais est refusé la commande:
project.AddCommandsAfterBuild  et le texte ne passe pas non plus. C'est tout ce que je connais pour t'aider.
Dans ton cas j'essaierais:  cmd /c mkdir abc ou cmd /c mkdir C:\Bozo\abc, sans guillemet, je l'ai essayé et ça fonctionne, that's all!
6
Je puis mettre les dll's manquant à l'exécutable lors de la compilation de mon projet. Dans Build option... -> Pre/post build steps -> Post-build-steps, add cette ligne :
      ex:       cmd /c XCOPY C:\OpenGL-CB\SDL2\bin\*.dll $(TARGET_OUTPUT_DIR) /D /Y, ENSUITE COMPILE. Les fichiers dll's ajouter au bin\debug ou bin\release sont affichées
à la console de Code::Blocks. J'ai essayé avec cette syntaxe: project.AddCommandsAfterBuild(_T("XCOPY $(#sdl2)\\bin\\*.dll $(TARGET_OUTPUT_DIR) /D /Y"));  mais est refusé la commande et le texte. C'est tout ce que je connais pour t'aider.
7
Using Code::Blocks / Re: [HELP] How to change toolbar icons size?
« Last post by Daniel.1954 on Yesterday at 08:50:09 pm »
Menu->Settings->environnement settings->view-> 2 choix: toolbar icons size et settings icons size
8
Help / VC Resource Compiler Issue
« Last post by Frank_CB on Yesterday at 07:46:29 pm »
Hello,

I'm using the most current release of CB 12.17, compiled from SVN source, on a desktop platform, using Windows 10 Home.

Using the newest release of Visual C++, from Microsoft, to provide the 64-bit compiler (cl.exe). resource compiler (rc.exe), linker (link.exe) and make (nmake.exe) executables, I can successfully generate Windows console-, gui-, mfc-, and wxWidgets-based applications outside of CB's IDE

However, only after copying rc.exe and rcdll.dll into an application's source folder, can I successfully generate the same applications within the IDE. CB's project files (.cbp) show a reference to 'windres', which is the resource compiler.from TDM-GCC-64's suite of executables. I found no referance to 'windres' in default.conf.

My work-around works, but it would be nice if I didn't have to resort to using it when I wanted to create a 64-bit application that includes resources.  Better yet, can someone explain why the work-around works?  It's almost like CB's looking for the resource compiler in the application's source folder and not where the toolchain says it's suppose to be.  Currently, rc.exe and rcdll.dll reside in a different folder than cl.exe, link.exe and nmake.exe.  That information is provided to the toolchain.

Regards,

Frank

P.S.  A .cbp file from a successfully built and executed wxWidgets sample is attached.





9
Nightly builds / Re: The 08 October 2018 build (11499) is out.
« Last post by stahta01 on Yesterday at 07:09:26 pm »
Normally, I guess the parser goes to an endless loop in this case. I can debug the parser, but I need a test project to reproduce this bug.
Any way, I will review the code changes made recently in the code completion plugin.
Thanks.
For what it's worth, Riban's observation that it seems to happen if you just leave CB idle in the background is an oddly reliable way of recreating the hang (anywhere from 30 minutes to an hour).

I also duplicated the problem no idea how long I let CB idle before seeing it.
I went away and saw the problem after I came back.

I plan on trying the fix suggested in the wx bug post and seeing if it works.
Edit: https://trac.wxwidgets.org/ticket/17094   [wxMSW] High CPU usage when application is idle
Will take several hours since first I have to confirm issue is in wx git master branch
Edit2: Will likely take several days; I will need to test the changes a lot for such a small piece of code.
Edit3: Failed to see problem with CB SVN 11503 and WX Git master less than 5 days old; when only using Core plugins.
Now going to try using core and contrib plugins and see if I can get high CB CPU usage.

Tim S.
10
Fixed in r11506

I did not apply the wxScintilla fix mentioned above since the error could be fixed in Dragscroll itself.
See  http://forums.codeblocks.org/index.php/topic,22807.msg155000.html#msg155000 for the wxSTC discussion.

Pages: [1] 2 3 4 5 6 ... 10