Hi Anreas!

Consider the following two application-registered classes:


/**
* Cvar
*/
class Cvar
{
public:
/* object properties */

/* object behaviors */
void _beh_0_(const String&in, const String&in, const uint);&s
void _beh_0_(const Cvar&in);&s

/* object methods */
void reset();
void set(String&in);
void set(float);
void set(int);
void set(double);
void forceSet(String&in);
void forceSet(float);
void forceSet(int);
void forceSet(double);
bool get_modified() const;
bool get_boolean() const;
int get_integer() const;
float get_value() const;
String@ get_name() const;
String@ get_string() const;
String@ get_defaultString() const;
String@ get_latchedString() const;
};

/**
* ElementFormControl
*/
class ElementFormControl
{
public:
/* object properties */

/* object behaviors */
Element@ _beh_9_();&s

/* object methods */
String@ get_name() const;
void set_name(const String&in);
String@ get_value() const;
void set_value(const String&in);
bool get_submitted() const;
bool get_disabled() const;
void set_disabled(bool);
};




And the following code:


ElementFormControl @login_form_username;
...
Cvar mm_user( "cl_mm_user", "", 0 );
mm_user.set( login_form_username.value );


Now when the code above is compiled, Angelscript produces the following error:

ERROR: _script_1i/profile.rml 91:13: Multiple matching signatures to 'Cvar::set(const String&)'
ANGELSCRIPT: _script_1i/profile.rml 91:13: void Cvar::set(double)
ANGELSCRIPT: _script_1i/profile.rml 91:13: void Cvar::set(float)
ANGELSCRIPT: _script_1i/profile.rml 91:13: void Cvar::set(int)
[/quote]

Changing the code to:

Cvar mm_user( "cl_mm_user", "", 0 );
String @val = login_form_username.value;
mm_user.set( val );


fixes the error but is kinda ugly. Any idea why this is happening?

I'm not sure. I'll have to test it myself.

It does look like a bug though. Intuitively the compiler should be selecting the set(String&) version, but for some it was not even considered.

I just tested this, and worked correctly on the latest WIP. The script compiled without error, and it correctly chose the set(String &in) method.

Which version of AngelScript are you using? I've made several bug fixes for property accessors in the latest releases, and one of those may have fixed your problem too.

2.23.1 with a few patches from trunk

OK.

Can you try the following test? If it reproduces the problem for you, then we can conclude that the problem really has been fixed. If it doesn't reproduce it, then perhaps you can show me what changes are need to reproduce it.



{
engine = asCreateScriptEngine(ANGELSCRIPT_VERSION);
engine->SetMessageCallback(asMETHOD(CBufferedOutStream, Callback), &bout, asCALL_THISCALL);

RegisterScriptString(engine);

bout.buffer = "";

engine->RegisterObjectType("Cvar", sizeof(int), asOBJ_VALUE | asOBJ_POD);
engine->RegisterObjectBehaviour("Cvar", asBEHAVE_CONSTRUCT, "void f(const string &in, const string &in, const uint)", asFUNCTION(0), asCALL_GENERIC);
engine->RegisterObjectMethod("Cvar", "void set(string&in)", asFUNCTION(0), asCALL_GENERIC);
engine->RegisterObjectMethod("Cvar", "void set(float)", asFUNCTION(0), asCALL_GENERIC);
engine->RegisterObjectMethod("Cvar", "void set(int)", asFUNCTION(0), asCALL_GENERIC);
engine->RegisterObjectMethod("Cvar", "void set(double)", asFUNCTION(0), asCALL_GENERIC);

engine->RegisterObjectType("ElementFormControl", 0, asOBJ_REF | asOBJ_NOCOUNT);
engine->RegisterObjectMethod("ElementFormControl", "string@ get_value() const", asFUNCTION(0), asCALL_GENERIC);
engine->RegisterObjectMethod("ElementFormControl", "void set_value(const string&in)", asFUNCTION(0), asCALL_GENERIC);

mod = engine->GetModule("test", asGM_ALWAYS_CREATE);
mod->AddScriptSection("test",
"void func() \n"
"{ \n"
" ElementFormControl @login_form_username; \n"
" Cvar mm_user( 'cl_mm_user', '', 0 ); \n"
" mm_user.set( login_form_username.value ); \n"
"} \n");
r = mod->Build();
if( r < 0 )
TEST_FAILED;

if( bout.buffer != "" )
{
printf("%s", bout.buffer.c_str());
TEST_FAILED;
}

engine->Release();
}


This is embarassing but I can't reproduce the issue with your test code either. Pretty sure I had no typos/errors in the code before posting it here. Bizarre.

Let's consider the case closed, if I encounter it again I'll just make a new bug report then.