:).
nRet = (asERetCodes) pScriptEngine->RegisterObjectType("CellPoint", sizeof(CellPoint), asOBJ_VALUE | asOBJ_POD | asOBJ_APP_PRIMITIVE); nRet = (asERetCodes) pScriptEngine->RegisterObjectProperty("CellPoint", "uint row", offsetof(CellPoint, row)); assert( nRet >= 0 ); nRet = (asERetCodes) pScriptEngine->RegisterObjectProperty("CellPoint", "uint column", offsetof(CellPoint, column)); assert( nRet >= 0 );
I register the CellPoint like this. Since I lazy to write all the constructor and deconstrutor for the cellpont.
I tried to register Cellpoint as asOBJ_VALUE | asOBJ_APP_CLASS_CDA, it works properly inside of application.
My question is: wat's difference between to use my old type registration and new one?
Since the Cellpoint is really a row and column, which both are int, so is there a way that I do not need to register the constructor, deconstructor, assignment operator? which the script will auto handle those? This is y I choose to register as a value+pod+primitive.
I try combination of value+pod, the script does not allow registration continue.
Any suggestion?
Thanks.
Quote:
Original post by WitchLord
How is the CellPoint type implemented? And how is it registered?
Depending on how it is implemented and how it is registered you may have a mismatch in how AngelScript thinks it should send the ScriptObject reference and how C++ expects to receive it. Return values that are stored in memory, rather than in the registers, require a hidden parameter before the oficial parameters that gives the location where the function should put the return value.
My guess is that C++ expects the CellPoint type to be returned in memory (thus require the hidden parameter), but you've not registered the type correctly making AngelScript think the type will be returned in the registers. This would make C++ use the ScriptObject reference as the hidden parameter, and take whatever else is on the stack after that as the ScriptObject reference (the value 4 that you're seeing).
The fact that printScriptObject works properly makes this cause even more probable, since it returns void, thus don't expect any hidden parameter.
Regards,
Andreas