Conditional Back/Forward Buttons

A neat feature of QlikView's built-in back/forward buttons is that they are available only when relevant‒i.e. when a back or forward selection is possible. This article will teach you how to create this same conditional effect in your own back and forward buttons!

Whether you wish to remove the native QlikView toolbar altogether (a fairly common request) or simply wish to add your own additional back and forward buttons to an application, is is often useful to replicate the native buttons' conditionally-enabled nature. It is sometimes viewed as inelegant to have a "back" button that appears to be available for clicking even when no previous selection has been made. For example, here is how custom buttons typically look in a QlikView application:
When no back or forward selection is actually available in the QlikView application, however, users can get confused by these buttons. The native QlikView toolbar makes these buttons conditionally available but can we replicate this same appearance with custom buttons? Yes, we can! Let's start by discussing what back/forward buttons actually control.
The first and most obvious thing that back/forward buttons control are field selections. We can use the Back and Forward sets in set analysis to quickly tell us whether or not a Back or Forward selection is possible. The simplest way to do so is to first pick a field that is virtually never completely zero/null; the primary measure field from the fact table is typically a good choice (for instance, "Sales"). We can then use the Back and Forward sets to check if the sum of this field is zero:

Note that one great feature of this solution is that separate logic need not be written for island dimensions. Although a selection on an island dimension would not affect a measure in the fact table, the Back and Forward sets only check whether the sum of the measure is valid‒i.e. whether the sets themselves are valid.
Aside from field selections, back/forward in QlikView also controls variables value states. The good news is that the above syntax will work equally well to check for, and set, variable states. If your application makes only light use of variables, then the above should be all that you need.
However, if your application uses variables heavily, the back/forward action can be significantly more challenging to implement. That is because there are two general types of variables in QlikView: variables that the user understands that he/she interacts with (such as by clicking a button that hides a chart, for example) and behind-the-scenes variables (such as those automatically updated based on a trigger). For instance, it is not unusual for one button to actually set multiple variables at the same time. In that situation, the native QlikView back action will undo only the last variable that the button sets. This is often undesirable, since the variables may depend on each other in such a way that updating only one does not make sense. Unfortunately, there is no simple way to fix this problem. Without resorting to macros (which will not work in AJAX), QlikView does not have a method to programmatically control the number of backward/forward steps to take. Likewise, QlikView also does not have a way to set multiple variables with a single action. While there is no universal solution to this problem, one possible workaround would be to:
  1. Set a "vBack" variable whenever a button that changes multiple variables is clicked. This variable should be set to a single value that would indicate the previous back state. For example, if buttons control your timeframe through the setting of several variables, and after your timeframe is set to "YTD" you change it to "MTD," the "MTD" button should set vBack to "YTD."
  2. Create an OnAnySelect trigger that sets vBack to null.
  3. Create a button with a standard Back action. Conditionally hide this button if vBack is not equal to null.
  4. Create a second button in the same position as the above button that is to be displayed when vBack is not equal to null. Create a series of Set Variable actions on this button, using the vBack variable to determine which ones to change. For instance, if we only want to change vTimeframe if vBack is a timeframe variable, then we can create an action on vTimeframe to say: =if(vBack='MTD',vCurrentMonth,vTimeframe). By setting an ELSE condition equal to the variable itself, we ensure that we do not modify variables that should not be affected. Note that it is this step that makes the implementation of back/forward buttons in variable-heavy applications so challenging‒you may potentially need to create hundreds of actions with conditions such as these, something that can be quite time-consuming.
Using the Conditions
Leaving aside the advanced variable scenario above, we can use the "simple" conditional formulas to control button color and/or hiding. For instance, we can create a text object "button" and set the background color of the text object as follows: if(sum({$1} Sales)<>0,blue(),lightgray()). Since if a back/forward action is not available there is no harm in clicking on the button, the button actions can be native Back and Forward actions. Alternatively, if you wish to use button objects instead of text objects, you can use the Enable Condition box on the General tab of the button properties to set a condition by which the button will be enabled. Finally, you can use the Layout >> Show >> Conditional box to hide the button entirely when a back/forward state is not available.
To see the solutions discussed in this article in detail, take a look at our free design demo:
Infinity Insight Demo.qvw
This entry was posted in Development, Tips & Tricks and tagged , , , , . Bookmark the permalink.

2 Responses to Conditional Back/Forward Buttons

  1. Neno says:

    Hi, I just want to ask why to develop something that already exist in the original application? Beside that if you remove the QV toolbar you will remove possibilities to select Bookmarks, to lock/unlock selections, to make annotations, to select a report, to start a collaboration session, etc.

    If getting one more line on the screen is a reason then be aware you will need space for customized toolbar anyway.

    I can’t see a single reason for it and would like to hear some.


  2. Neno, there are actually many reasons why you may want to develop something like this. The primary reason is to give you users the ability to go back when they’ve clicked on a button that simultaneously sets several variables and makes several selections. If you use the native QlikView Back button, it will just undo the last step, requiring users to press it several times. It is much more elegant to create a button that seamlessly undoes a series of actions with a single click.


Leave a Reply

Your email address will not be published. Required fields are marked *

Notify via email when new comments are added

Blog Home