All of the involved code would be too messy to post here but I hope this is enough...In the following DynamicObject implementation, getProperty is never called with the "windowtitle" property name :
class OSCJSObject : public DynamicObject
{
public:
// constructor etc omitted here
bool hasProperty(const Identifier& id) const
{
if (id == Identifier("windowtitle"))
return true;
return DynamicObject::hasProperty(id);
}
const var& getProperty(const Identifier& id) const
{
if (id == Identifier("windowtitle"))
{
return m_component->getParentComponent()->getName();
}
return DynamicObject::getProperty(id);
}
};
Most curiously and annoyingly, setProperty DOES work as expected. So JavaScript code like :
app.windowtitle="test title"; works.
But code like :
app.print(app.windowtitle); does not. "undefined" is printed out. (The print method has been tested to work.)
My first suspicion was that I got the getProperty signature wrong in some subtle way. However, the function IS called by Juce sometimes, it is looking for a property "prototype" (or some such) many times. If I put a breakpoint at the
return m_component->getParentComponent()->getName(); line, it is never triggered. Using Visual Studio 2015 Community Edition on Windows 7 64 bit here.
Yeah, for a lot of the JS parser, it'll use the DynamicObject's NamedValueSet directly, instead of going via the getProperty virtual method - this is mainly done for speed and simplicity, but does make it hard to create active properties that perform some sort of actual task.
The "fix" would be to actually use the NamedValueSet to store this value, and update it when it changes, or to implement it as a function rather than a property.
I've thought about changing DynamicObject and replacing the two property accessors with a single method that returns a var*, and that would be a breaking change for people's code.
It's a shame we can't use overload getProperty and hasProperty when using the JavaScript engine. This would make the scripting a lot more flexible. I can understand you use the NamedValueSet directly to improve speed but you don't state it anywhere that you can't properly overload the DynamicObject methods, so these questions will keep popping up because right now the implementation is not clear. I would argue that it's ok to make changes that break people's code as i think just a few percent of the JUCE user base is actually using your scripting engine atm. I think there is still a lot to improve on the scripting part and at least making sure the use of DynamicObjects is correct will make it easier for us to build on it.
I really like the fact that you've added the Javascript features and i would really like to see it to mature it even more. It's easy to use just because of the DynamicObject approach.
Agreed! Will think about this. Like I said above, the ideal way to do this would be to change the way that DynamicObject works, so it's a question of deciding whether this is important enough to justify breaking people's existing code.
