bool getValue(void)
And i tried to declare it like this in AngelScript:
r = mEngine->RegisterObjectMethod("ControlBool","bool getValue(void)",asMETHOD(WrapControlBool,getValue),asCALL_THISCALL); assert( r >= 0 );
And it doesn't work .
I had to remove the void from my AngelScript declaration for it to work like this:
r = mEngine->RegisterObjectMethod("ControlBool","bool getValue()",asMETHOD(WrapControlBool,getValue),asCALL_THISCALL); assert( r >= 0 );
I know it is not too much C++ style, but my remains of C languages make me continue to use it.
That's it ;)
Humm perhaps another strategy question,
In My application each time i click on a control, it redefines a GlobalProperty control in AngelScript and execute the command associated with engine.ExecuteString()?
Is there another way to envisage that (i am thinking of context and precompiled script perhaps) in this case or does it seems to you a solution as is?
A great thanks anyway :D
DaesDemon
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Declaration of void, and strategy question
Author
First a good news, i finished my prototype to have my application interface completly created and controlled by AngelScript, and it is working very well and ask not too much work.
It will simplify my life a very big lot :) and i would like to thanks AngelScript people for that.
Now just for information in the last hours , i was stuck on a problem that make me some times to understand.
I have a member function declared like that in a class:
I'm pleased that you got your prototype working and that you are satisfied with AngelScript. Let me know when I can put up a link to your project on the AngelScript users page. [smile]
I've changed the engine interface slightly for AngelScript 2.4.0 WIP 2, in an effort to make it easier to fix problems that arise while configuring the engine. The idea now is that you should set the output message stream right after creating the script engine, that way the engine will be able to give your human-readable messages that tells you what's wrong with the declarations used in the register methods.
I'll also continue to change the way object types are registered, to force the correct usage, so that the application writer can more easily avoid difficult detect bugs. A common bug is for example to register a complex class, but not its assignment behaviour, which make AngelScript do a bitwise copy of the object in assignments, where it should have called the class's assignment operator. In a future version AngelScript will force the registration of the assignment behaviour, and other required behaviours, though the application can explicitly tell the engine to do bitwise copy if that is wanted. The thing is that AngelScript will not make any assumptions that may be potentially disastrous.
Your way of handling the events in the scripts seems to be working well. But using contexts would make it more optimized, and would also allow you to pass parameters to the event handler, instead of storing them in global properties.
Internally ExecuteString() wraps the string in a function declaration, compiles it, and executes it using a context. This makes it quite slow. Though for events that occur relatively rarely, such as user input, you'll probably never notice this.
I've changed the engine interface slightly for AngelScript 2.4.0 WIP 2, in an effort to make it easier to fix problems that arise while configuring the engine. The idea now is that you should set the output message stream right after creating the script engine, that way the engine will be able to give your human-readable messages that tells you what's wrong with the declarations used in the register methods.
I'll also continue to change the way object types are registered, to force the correct usage, so that the application writer can more easily avoid difficult detect bugs. A common bug is for example to register a complex class, but not its assignment behaviour, which make AngelScript do a bitwise copy of the object in assignments, where it should have called the class's assignment operator. In a future version AngelScript will force the registration of the assignment behaviour, and other required behaviours, though the application can explicitly tell the engine to do bitwise copy if that is wanted. The thing is that AngelScript will not make any assumptions that may be potentially disastrous.
Your way of handling the events in the scripts seems to be working well. But using contexts would make it more optimized, and would also allow you to pass parameters to the event handler, instead of storing them in global properties.
Internally ExecuteString() wraps the string in a function declaration, compiles it, and executes it using a context. This makes it quite slow. Though for events that occur relatively rarely, such as user input, you'll probably never notice this.
Author
Quote: Original post by WitchLord
I'm pleased that you got your prototype working and that you are satisfied with AngelScript. Let me know when I can put up a link to your project on the AngelScript users page. [smile]
I'll surely inform you when i will have a site project open. Anyway, i am thinking that you will heard of me before as i 'll probably need your help again to understand subtil mechanisms of script writing with Angel ;) Thanks for your quick support, that is really helpfull.
Quote:
I've changed the engine interface slightly for AngelScript 2.4.0 WIP 2, in an effort to make it easier to fix problems that arise while configuring the engine. The idea now is that you should set the output message stream right after creating the script engine, that way the engine will be able to give your human-readable messages that tells you what's wrong with the declarations used in the register methods.
Yes i am thinking that that would be of great help mainly for basic users like me ;) discovering syntax as the main problem in script wrinting is the debuging part. I tried to make a dump of the engine state with theses functions:
[source language=c++] // Script functions int GetFunctionCount(const char *module); int GetFunctionIDByIndex(const char *module, int index); int GetFunctionIDByName(const char *module, const char *name); int GetFunctionIDByDecl(const char *module, const char *decl); const char *GetFunctionDeclaration(int funcID, int *length = 0); const char *GetFunctionName(int funcID, int *length = 0); const char *GetFunctionSection(int funcID, int *length = 0); // Script global variables int GetGlobalVarCount(const char *module); int GetGlobalVarIDByIndex(const char *module, int index); int GetGlobalVarIDByName(const char *module, const char *name); int GetGlobalVarIDByDecl(const char *module, const char *decl); const char *GetGlobalVarDeclaration(int gvarID, int *length = 0); const char *GetGlobalVarName(int gvarID, int *length = 0); void *GetGlobalVarPointer(int gvarID); int GetTypeIdByDecl(const char *module, const char *decl); const char *GetTypeDeclaration(int typeId, int *length = 0);Quote:
I'll also continue to change the way object types are registered, to force the correct usage, so that the application writer can more easily avoid difficult detect bugs. A common bug is for example to register a complex class, but not its assignment behaviour, which make AngelScript do a bitwise copy of the object in assignments, where it should have called the class's assignment operator. In a future version AngelScript will force the registration of the assignment behaviour, and other required behaviours, though the application can explicitly tell the engine to do bitwise copy if that is wanted. The thing is that AngelScript will not make any assumptions that may be potentially disastrous.
One of the great advantage of AngelScript for me is the C typed syntax which almost make me think of writing C++ and i don't find the declaration too much difficult comparing to others scripts languages.
So the best for me would be to be able to use all C++ mechanism as it in AngelScript, and this is almost the case (except for pointers and some operators missing), so it is very usable with some little imagination as you showed me in the forum.
To say the truth i try lua before, and it was not as understandable as AngelScript Documentation so i flip to AngelScript. Obviously i don't know all the mechanism of AngelScript as i have only code with it for a week now and i am sure there is some hidden treasures that will make my coder life more peaceful :)
Quote:
Your way of handling the events in the scripts seems to be working well. But using contexts would make it more optimized, and would also allow you to pass parameters to the event handler, instead of storing them in global properties.
Internally ExecuteString() wraps the string in a function declaration, compiles it, and executes it using a context. This makes it quite slow. Though for events that occur relatively rarely, such as user input, you'll probably never notice this.
Yes i understand ExecuteString is a kind of interpreter for string and it is why i'd ask that. But in my case, i will have loads of string commands like this:
Panel.getObject().showBoundingBoxes(Control.getValue())or Control.setValue(Panel.getObject().getShowBoundingBoxes())So as far as i have understood of context, i would have to:
1) make a wrapping function for each of my command string with my old global property in parameters (control in this case)
2) Put every function in a module
3) Build the module
4) And Each time i use a control :
a) Prepare a context for executing the function i need
a) Send the Parameters to the wrap
b) Execute the context
c) get the result params if one
The advantage of this method is that the script would be precompiled but as you said as i only requires very little command string , it would not make a great difference in this case.
So for the moment , i will work a little on the project as it is now, and i will see later to put everything to precompiled state as it will not be hard to change my Script preparations and executing procedure.
See you later
Regards
DaesDemon
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
