Question on multiple 'states' / scenarios

[#1]

Not sure how to best tackle this so I am looking for some advice please.

I have a simple data model that currently cannot be changed - consisting of a Calender , a claim table and a note table , all relationally linked. from Calendar to claim to notes.

I have three scenarios within the data where users want to investigate the data.

1) What is going on currently within the data ? (AllDates)

2) What is going on Between a defined period ? (FromDate ToDate)

3) What is new ? (FromDate)

Within these scenarios there are flags within the data that define certain records as of interest - (subFlag)

My initial thoughts were to create some variables that let the users select the scenario they want to look at, via a button and then use set selection to define the data they see using the variables .

I can set the variables and have the selection criteria set up - all working

My problem is I'm not quite sure how to nest the statements for 3 variables ? or even if this is the best approach ?

Simple test layout so far -- the buttons on the right define the scenario and set the variable - the top text elements confirm the initial all scenarios and sum all data requests .. -

Some advice would be appreciated or best practice thanks ...

[evan_kurowski]

This looks like a clean, orderly start and nice work on getting all your expressions up on the top bar set up.

For the buttons sequencing along the right side, can you get by with one variable? 

Something like vShowScenario can be assigned 'New', 'Range', or 'All'?  Or maybe chain a list of concatenated values 'R','A','N'.

[#3]

Evan, thanks for the reply and good spot - yes I could use one variable and change the value to take into account the three scenarios - the question remains though how do I deal with the nested statements ?

for example - within any text box it currently looks like this for the fist variable

=if ($(v_Selected) = 1, num(COUNT (distinct FLDRID),'#,##0'))

how do I then take into account the next two ? where v_Selected =2 or v_Selected =3 ?

What would the statement look like - as an example the next statement would need to take into account the following variable as well for the purposes of Set analysis ? and similar for the third scenario ?

=if ($(v_Selected) = 2, num(COUNT ({$<$(v_SubroCount)>} distinct FLDRID),'#,##0')

Evan Kurowski

[evan_kurowski · Accepted solution]

Hello Robin,

There's a lot of different approaches that can be taken at this point, and the favorability of these are always falling in and out of vogue, but here are some examples:

1.  You could copy this to 3 sheets, cloning your outer border navigation objects.  Then the charts are all hardcoded to one type of data area calculations.  Then the sheets are all hidden.  Pressing the button for a particular sheet makes the sheet visible and brings the user to it (downside: maintaining multiple sets of parallel objects makes for complicated adjustments and maintenance)

2.  You could embed multiple layers of objects in the same page with a "show/hide" system.  The conditional show expression reveals Chart 1 while Chart 2 or 3 are hidden, then a button press will toggle revealing Chart 2 while Chart 1,3 are hidden, etc..  (downside: requires maintaining show/hide logic and remembering to sequence layers and logic of not just visible set of objects, but hidden set.  Also can be complicated maintenance)

3. Make one set of chart objects, that is visible all the time, but the calculations/expressions in the objects are conditional based on meeting logic criteria.  This method has been growing in usage, but many of the options that allow using conditional expressions, dimensions, etc.. some of these were only added in relatively recent QV versions, and were not always available to earlier developers.  (downside: while you only have to maintain one set of objects, expect that the coded complexity of each object will probably increase.  It is handling the rendering possibilities of what in other approaches would've been split into multiple objects).

If you decide to go with a single set of "flexible" objects, let's take into account the possibility that the number of your scenarios might expand just beyond 3 options.  What if they add a 4th, 5th, nth option... so stacking IF statements in burgeoning chains starts to get complex.

Maybe start incorporating the Pick() function (the user-interface equivalent of a SWITCH or CASE statement)  i.e.

Pick($(v_Selected),

        Expression1,

        Expression2,

        ...

        ExpressionN)

Also in the chart objects, make use of the CONDITIONAL expressions to toggle dimensions/expressions (shown here)

Lastly, you could move away from a toggle system based off of a variable and instead switch your toggle system to correlate to field selections.  Imagine if instead of keeping your scenario possibilities stored as values of your variable, you switched them to rows in a table.  Then associated with each row in that table is another field which contains the type of calculation you'd like to perform when that row is in selection.  This is probably the most flexible and expandable approach of all, but requires the clearest understanding of syntax and data-modelling to get this working right.

Imagine a table like:

Scenario	Expression
All	Sum(FACT)
Range	Sum({<DATE={">= $(start) <= $(end)"}>} FACT)
New	Sum({<DATE={">= $(new)"}>} FACT)
MyNewScenario	Count(FACT)

Select a single entry in the field Scenario, and now the Expression will follow.  The neat thing about this, is if you add more scenarios it should be a minimal amount of adjustment to get the chart objects to adapt to additional calculations. (i.e. you're not returning to the Pick()'s and IF()'s and saying "let's manually adjust to handle a 4th condition.. ok, now we have a 5th let's go back again, etc..).

[#5]

Evan, that's a great answer and thanks, I think for ease of use for now the PICK function works. I will have to explore the fourth option further once I get past this. Should I get stuck am I ok to come back on the PICK process?

And once again thanks for the patience and great advice

Robin.

[evan_kurowski]

Sure Robin, and thank you.

Pick() is a fine approach, just wanted to help you be aware of your options.

[#7]

All now working as expected on the Claim data set, utilising the the PICK() function Evan so thanks for the education, greatly appreciated. I'll get back to you once I move onto the Notes data set - as this gets a little bit more complex with how I need to expand out the data . (not as simple as just the relationship between the claim and note)

Thanks again

Robin/