Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Squirrel 3.1 and new bindings
oBFusCATed:
Thanks for testing. So next week would be push time...
The failures are expected and are bugs in the API. I'll take a look at some of them soon.
The permission/sandbox/access system is also totally broken and what you see is totally normal unfortunately. At the moment I don't intend to fix it, I've looked at this and I don't have the time required to untangle it. :(
oBFusCATed:
Pushed in both svn and git...
The_GTA:
Thank you very much for your work on the project scripting system, oBFusCATed! While I have not yet tested this special Code::Blocks version I am very inclined to do so because most of my projects use the Squirrel based scripting system for inter-project static library dependency resolution! You see, scripting is the only way to apply build-time properties - including preprocessor definitions and when-existing static library inclusion - when they truly matter. In fact, I have even grown much experience of build-scripting and a fancy to writing these!
Thus let me share some of my experience with you. Maybe it can lead to a better scripting system design:
* The _T syntax of scripts is very annoying. In the official Code::Blocks build forgetting to use the _T could even crash the entire IDE. Since you mention that the "==" should now just work, this makes me really happy. Please make use of strings as natural as possible.
* How about adding a script function to add C/C++ preprocessor definitions into the compilation unit? After all, there is such an option in the IDE and it would be only natural to add a direct equivalent into the build scripting system. Having a direct function does also promote the idea of build script preprocessor definitions inspection, a well-needed addition to the existing #ifdef appliance check and color-highlighting features.
Looking forward to further developments! 👍
oBFusCATed:
--- Quote from: The_GTA on May 11, 2021, 07:27:16 pm ---
* The _T syntax of scripts is very annoying. In the official Code::Blocks build forgetting to use the _T could even crash the entire IDE. Since you mention that the "==" should now just work, this makes me really happy. Please make use of strings as natural as possible.
* How about adding a script function to add C/C++ preprocessor definitions into the compilation unit? After all, there is such an option in the IDE and it would be only natural to add a direct equivalent into the build scripting system. Having a direct function does also promote the idea of build script preprocessor definitions inspection, a well-needed addition to the existing #ifdef appliance check and color-highlighting features.
--- End quote ---
1. Try the new version and tell me if something doesn't work. Keep in mind that string <->wxString casts aren't universal and might not work everywhere. But if there are crashes don't hesitate to report them. There is already a night build.
2. No idea what you're talking about. Please be more specific.
--- Quote from: The_GTA on May 11, 2021, 07:27:16 pm ---Looking forward to further developments! 👍
--- End quote ---
The only reason I've spend so much time on this is because the ond binding failed in closures, and I needed those to make debugger testing work. I hope to spend my time on something a bit more productive now.
BlueHazzard:
Has someone tested the wxWidgets wizard on linux?
I have a problem, but i am not 100% sure if i have a broken installation or if it is a bug:
latest codeblocks trunk, linux mint 20
1) Create a new wxWidgets project
2) Name the project "test"
3) choose wxSmith as editor
4) finish the project
The generated source files have the name
--- Code: ---testApp.cpp
testApp.h
testMain.cpp
testMain.h
--- End code ---
But the include is
--- Code: ---#include "TESTMain.h"
--- End code ---
also the class is called
--- Code: ---TESTDialog
--- End code ---
instead of
--- Code: ---testDialog
--- End code ---
Now i get compilation errors about "TESTMain.h" not found
Afternote:
i have the same bug on windows, but because windows is case insensitive it does not trigger compilation error
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version