Restricting Data Basis for Scatter Chart

[#1]

Hello,

i have two scatter charts.

Each has to use different data basis ie - i have only one table and the first chart has to use the whole dataset, and the second chart has to use only subset of the initial dataset.

My question is - when defining dimension in scatter chart (it's actually bubble chart) how can I make this SUBSET available to the chart?
Now both charts have the following dimensin "Unique_ID".

The second chart has to have Unique_ID when the condition is met - when values in a column  "M" are not NULL and are not empty strings.

How can I implement this behaviour? With set analysis syntax?

Thx!

[hic]

The expressions in a Scatter chart are the x and y positions of the dots. If you use an expression like

   Avg( If( Len(Trim( M )) >0, Xpos ))

you will restrict the number of data points just like you want.

To use set analysis, it is simplest if you define the above condition as a field in the script:

  If( Len(Trim( M )) >0, 1, 0 ) as M_IsOK

and then use the following expression

  Avg( {$<M_IsOK={1}>} Xpos )

HIC

[#3]

Hi Henric

Is it best practice to always put the $ identifier rather than leave it blank?  I am hosting a webinar today on set analysis and would like to clarify that if there is a compelling reason to include rather than exclude as the default.

[#4]

The $ identifier denotes that you're specifying the set that you're looking at are the current selections.  In most cases you'll probably want to use that

[hic]

No, there is no compelling reason in one or the other direction.

I personally think it is important to be explicit - so my code and my formulas are easy to read. So I always use {$<...>} instead of {<...>}, so the dollar sign is clearly visible. But the two expressions are in most cases the same.

The only case when they are not the same, is if you use alternate states. Then {$<...>} means default state whereas {<...>} means inherited state.

HIC

[#6]

thank you Henric!  One more question I want to clarify before my webinar.

the -= (not equal to) is always followed by the red underline indicating an error in the formula even though it works.  Is this a bug or is there another step needed to take to remove this.  I have just lived with it over the years. 

ok, maybe 2 questions

In addition, when you put in a field name in an aggregate function and you do not get the case correct but you spelled it correctly, it will not give you an error indicator but the expression will obviously not work.  We found this at at the first master summit and it took us a bit to notice the case problem.  Is this also a bug or is it just not possible for it to recognize case.

[#7]

Thank you Robert.  Using the $ is the same as omitting it so i was wanting to confirm if there is any reason at all that would benefit by including rather than omitting it as default.

[#8]

I have found in my limited experience that the editor is not always accurate.

[#9]

Jacob, would love to get your feedback on other things you may have noticed.  So far I have only experienced the

-= issue and the case issue

I have been working with Qlikview for about 7 years now I think, I am losing track but I am still learning new things every single day.  There is so much flexibility with Qlikview.

[hic]

I think you could classify both as bugs. The problem is that the color coding doesn't always follow syntax...

HIC