Hi Kent!
On Fri, Jun 18, 2010 at 6:10 AM, Kent Hansen <[email protected]> wrote:
> If overloaded slots and/or QtScript's handling of them is busted, then
> we'd like to know about it. "Check the number of arguments given and
> call the proper method" is what QtScript should do already. You will get
> ambiguity errors if QtScript's argument conversion can't uniquely
> determine what overload to call though; is that what's happening? What
> are the signatures of these methods, and how do you resolve which
> overload to call from your QtScript binding?
As an example, the two C++ methods that I have:
inline QString i18n (const char *text)
{
return ki18n(text).toString();
}
template <typename A1>
inline QString i18n (const char *text, const A1 &a1)
{
STATIC_ASSERT_NOT_LITERAL_STRING(A1)
return ki18n(text).subs(a1).toString();
}
(and there is some others autogenerated).
and this is the binding:
QScriptValue jsi18n(QScriptContext *context, QScriptEngine *engine)
{
Q_UNUSED(engine)
if (context->argumentCount() < 1) {
return context->throwError(i18n("i18n() takes at least one argument"));
}
KLocalizedString message = ki18n(context->argument(0).toString().toUtf8());
const int numArgs = context->argumentCount();
for (int i = 1; i < numArgs; ++i) {
message = message.subs(context->argument(i).toString());
}
return message.toString();
}
void bindI18N(QScriptEngine *engine)
{
QScriptValue global = engine->globalObject();
global.setProperty("i18n", engine->newFunction(jsi18n));
}
> I _think_ you should be able to get the engine by creating a C++ slot
> that takes a QScriptValue as argument, call that slot from QML, and call
> QScriptValue::engine() on the argument. If thats works, it effectively
> means we do already expose the QtScript API in public, but not with the
> intention to use the full API (e.g., it should be fine to call
> toNumber() on the QScriptValue, but not, say, installing a custom
> QScriptEngineAgent on the engine()).
I will try this and let you know about the results!
> Hmm, taking this idea further, did you try subclassing QScriptable? Then
> you could get at the arguments and thisObject() too. :-)
Seems like a good idea too ;)
> Adding an overload of QDeclarativeContext::setContextProperty() that
> takes a QScriptValue would seem intuitive.
If the first works, this would be nice!
I'll try coding what you suggested and will be back with the results.
Thanks for your time and suggestions!
BR,
--
-------------------------------------------------------
Artur Duque de Souza
openBossa
INdT - Instituto Nokia de Tecnologia
-------------------------------------------------------
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
-------------------------------------------------------
_______________________________________________
Qt-qml mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-qml