Skip to main content
Announcements
Introducing Qlik Answers: A plug-and-play, Generative AI powered RAG solution. READ ALL ABOUT IT!
cancel
Showing results for 
Search instead for 
Did you mean: 
johnw
Champion III
Champion III

multiple data views, each with multiple associated selections

Simple version of the question:

How can I make it easy for my users to switch between different common views of the data, where each view involves multiple selections being made? How can I make it clear which view they are currently using, IF they're using one of the common views?

Long version of the question:

I want the user to be able to make a common set of selections across multiple fields with a single click. Let's call each such set a "view" of the data. These views should be mutually exclusive - you aren't required to select one, but if you do, you should only be able to select one.

When they click on a view, in addition to making the appropriate selections, I want an indication (other than just the field selections), showing which view they are now using.

If they then CHANGE the selections directly, such as by adding or removing a type, I want the view indicator to go away or change so that they know they're no longer using that view.

At the top of the screen in this example are my two attempts at this.

At the left is a simple list box. It is connected to a "View" table, and each view is directly connected by ID to the rows that are appropriate to this view. There's an action on the "View" field selection that says if anything is selected, select the minimum value. That enforces the "0-1 but not many" requirement. That's fairly simple, but doesn't quite match what I'd like. If you make further selections within the view, the view remains highlighted, where I'd like it to instead go away. If you make selections outside of the view, the view goes away, but so do ALL of the view's "selections". I want my selection outside of the view to merely override a single field, not to remove the view entirely. In other words, if I'm in View ALX, and I select Status N, I do want the view selection to disappear, but for me to now be looking at ANX instead of at just N.

To the right of the view list box are buttons that on the surface behave exactly like I want. When you click one, it selects the desired values for the desired fields. A calculated color for the background of the button checks the current selections. If they match that button exactly, it shows in light green, otherwise it's gray.

The problem with the buttons is the way they check whether that view is active, the getcurrentselections() function. The problem happens when the actions selecting the data end up EXCLUDING something that we would then make in a later selection. In this case, the later selection doesn't occur, and we thus don't realize that we're in that view. You can demonstrate that to yourself if you go into the script and change the autogenerate to some small number, like 10. In that case, it is likely that some of the desired combinations won't generate. At that point, clicking on the View button will make the selections it can, but won't always highlight.

Now, for this simple case, we COULD say that that's "working as designed". Since we weren't able to make all the selections, we're not really in that view. In my real application, though, that isn't relevant. For instance, we might have products that we only produce a couple times a year, and one of our View selections might be to just show the current month of data. If we DID produce that product that month, we want it in the view. But if we didn't, we are STILL in that view. The mere fact that we didn't happen to produce that product that month doesn't change how we're viewing the data, only what data we can see in that view. Also, since the selections are more dynamic than indicated in the example, I don't think I can use bookmarks, not that I can think how they'd do anything but simplify the selections, which doesn't solve the remaining problem.

So ONE solution would be to come up with a way of driving the button color that wouldn't fail when not everything that CAN be in the view IS in the view.

I'm also open to different ideas, up to and including COMPLETELY different things like, "Create three separate applications, one for each view, and do the view as the default selections for that application" or "You're wasting your time. Users won't like this. Just make them do the selections manually." I am, in this case, merely guessing what will be simplest for my users to switch between different common ways of looking at the data. They didn't specifically request this exact feature to be implemented this exact way.

Thoughts?

Edit: The text in the example is the same as the text above. You don't need to read it twice. I just thought it might be convenient to have the text available WHILE you're looking at the example.

1 Solution

Accepted Solutions
johnw
Champion III
Champion III
Author

OK, solved it. It required using macros instead of actions, but I've realized that was required anyway. My first action was to clear all fields. But actions don't necessarily execute sequentially, so the clear could occur after some or all of the selections. That didn't happen to me, but I'm not taking chances. Macros let me make certain I execute everything in sequence.

The trick to recognizing that the current selections match the view is to STORE the current selections when you first click on the button for the view. So I clear, do all my selections, then assign getcurrentselections('/') to a variable associated with that view, such as variable ABLM for view ABLM. Then in the calculated color, I just need to check that getcurrentselections('/')=ABLM.

When done that way, even if not all selections are possible, the list I'm checking will be what WAS possible, so I'll still make the "selected" view green. I THINK that's all I needed to make this work reliably.

View solution in original post

1 Reply
johnw
Champion III
Champion III
Author

OK, solved it. It required using macros instead of actions, but I've realized that was required anyway. My first action was to clear all fields. But actions don't necessarily execute sequentially, so the clear could occur after some or all of the selections. That didn't happen to me, but I'm not taking chances. Macros let me make certain I execute everything in sequence.

The trick to recognizing that the current selections match the view is to STORE the current selections when you first click on the button for the view. So I clear, do all my selections, then assign getcurrentselections('/') to a variable associated with that view, such as variable ABLM for view ABLM. Then in the calculated color, I just need to check that getcurrentselections('/')=ABLM.

When done that way, even if not all selections are possible, the list I'm checking will be what WAS possible, so I'll still make the "selected" view green. I THINK that's all I needed to make this work reliably.