NOTE: Not all bindings should have an emptyCtor(). For example, scripts should not have the ability to create, say, a new "cbProject". Instead, it should go through the standard route: GetProjectManager().NewProject(). Another thing to note about emptyCtor() is that it imposes certain requirements on the C++ class, like that your C++ object must have a public copy constructor (but this is a requirement anyway). Look for an example in all basic classes (e.g., cbEditor). Copy constructors have been added to them which do nothing, just throw an error. They are not used by scripting (SqPlus has been patched for this) but they must exist nevertheless. Anyway, these are some "advanced" scripting issues which will become clearer once the basics are more clear. All of the wxWidgets GUI controls have private copy-ctors btw.
* NoConstructor
* CopyOnly
* NoCopy
I'm still trying to port c::b to sqart, and in looks good so wide. The only problem i encounter is a bit in the UNICODE section. What is the minimal wx-version it is supported in c::b?The minimal wx version to build C::B is 2.8.12.
I also try to implement a better way to use XRC Dialogs from squirrel. In my current implementation I use a lot wx2.9 API. Is it somehow acceptable to use this feature only with wx2.9 or should i try to implement it also for wx2.8 (witch would be a little bit of a pain in the ass). The old API would not change. So any script witch runs with the current version of c::b will work also in the new implementation...C::B will finally swith to use wx 3.0+ if wx released and becomes stable, but please note that this will take years to happen as I can expect. You see currently there are many issues when build C::B against wx 2.9.x +, This means C::B will use wx 2.8.x for quite a long time I think. :(
greetings
4. If 1 is not possible we should probably look for other scripting engines (lua or python), because squirrel is pretty limited in additional libraries.
I use ZeroBrane Studio which is implemented in Lua entirely which uses wxLua as its GUI; it works flawlessly, especially its autocompletion mechanism. I would go for either Lua or Python which I know both for C::B expansion.I personally like squirrel because of the c++ syntax, so i'm not willing to do the work for porting c::b to a other scripting language (specially python, the ugliest language i have seen (after basic ;) ) )
so are there any protests against porting c::b?On the contrary. I tried doing that myself a bit over year or so ago, but gave up because of something. Don't actually remember what it was... I think it was difficult to bind enum values or something, and I didn't find a good solution, and then I didn't have time... or something.
if not, is there a special technique to provide patches for such big changes? Like branches with git...Morten could probably create a branch and give you write access to this branch, I guess. Other than that, the only way I see is modifying your local copy and creating a huge patch afterwards, which admittedly stinks.
I'm still trying to port c::b to sqart, and in looks good so wide. The only problem i encounter is a bit in the UNICODE section. What is the minimal wx-version it is supported in c::b? If it is >2.8.4 there are no problems because there exists the function wxString::ToUTF8 and wxString::FromUTF8, but with a smaller version i have to look again.wx>2.8.4 is okay, I think at the moment we require something like 2.8.9 or 2.8.12.
I also try to implement a better way to use XRC Dialogs from squirrel. In my current implementation I use a lot wx2.9 API. Is it somehow acceptable to use this feature only with wx2.9 or should i try to implement it also for wx2.8 (witch would be a little bit of a pain in the ass). The old API would not change. So any script witch runs with the current version of c::b will work also in the new implementation...I'd prefer if you provide API for 2.8 and 2.9. We'll support 2.8 for quite a while, I suppose, more than a year.
so are there any protests against porting c::b?On the contrary. I tried doing that myself a bit over year or so ago, but gave up because of something. Don't actually remember what it was... I think it was difficult to bind enum values or something, and I didn't find a good solution, and then I didn't have time... or something.
If you can get this to work, that would be awesome.
Found it: http://forums.codeblocks.org/index.php/topic,16507.0.html
> print(::EXT_WORKSPACE);
workspace
> EXT_WORKSPACE.MakeUpper();
> print(EXT_WORKSPACE);
WORKSPACE