Can't use setOptions method for a visualization

[Anonymous]

There is an example of how to set options for a visualization - setOptions method ‒ Qlik Sense:

var app = qlik.openApp('c31e2aba-3b46-4b13-8b87-c5c2514dea1d');

app.visualization.get('xGhjKl').then(function(vis){

vis.setOptions({title:"Now improved"});

});

However, it is not working and giving me this error:

After some investigation I figured out that the problem applies only for string fields (title in example code is a string field).

The problem can be solved by wrapping a string with single quotes:

vis.setOptions({title:'"Now improved"'});

My question is, why there is such inconsistency? To create a visualization with title option I simply can pass it without quotes:

app.visualization.create('barchart',null,{title:"Title"});

However if a try to setOptions for my visualization I need to wrap my title with a single quotes.

Is it an intended behaviour or it is a bug?

Here is a jsFiddle for this issue.

Working:

Edit fiddle - JSFiddle

Not working:

Edit fiddle - JSFiddle

Message was edited by: Yan Ivan Evdokimov Added jsFiddle.

[Anonymous]

I figured out that this problem exists for the newest API version - 3.1.

For 2.2 you can setOptions without wrapping a string with quotes.

[alextimofeyev]

akl‌, can you help out?

[Alexander_Thor · Accepted solution]

Hmm, interesting. Ye, that's pretty confusing.

Explanation why:

When you call visualization.create() you interact directly with the Capabilities API and it will wire up the object for you and return the model. The model itself will expose a set of wrapper methods for the Engine API.

One of those methods is the setOptions() method which translates under the hood into the Engine API method ApplyPatches on the Generic Object class.

The ApplyPatches method needs properly encoded values to be able to tell integers and strings apart. That's why the strings in setOptions have to be either wrapped in single (or double depending on how you declare your string) quotes or escaped by a \.

However we should probably perform some additional type checking so you don't have to escape your strings.

(ping aaz‌)

[Anonymous]

That is exactly what I thought. Thank you for answer.

Is it known when it will be fixed?

[Aiham_Azmeh]

Hi Yan,

We're on it, probably next public release.

[rav]

Hi Yan Ivan!

I cannot reproduce the issue anymore in your fiddles nor in my personal setup. It seems like the issue was fixed in the latest service release. 3.1.1.

Regards

Rikard Samvik