Qlik Community

Ask a Question

Qlik Design Blog

All about product and Qlik solutions: scripting, data modeling, visual design, extensions, best practices, etc.

Welcome to our newly redesigned Qlik Community! Read our blog to learn about all the new updates: READ BLOG and REPORTED ISSUES

There are several good reasons not to use macros in QlikView.


First of all, macros are run using Microsoft COM Automation. They will run client-side and work fine if you use the Desktop or the IE PlugIn, which both are Windows executables. But if you use the Ajax client, there are severe limitations since the macros now need to run on the server instead of on the client. For a server, there are both technical limitations and security implications that have forced us to restrict the capabilities of macros.


So, if you want to use the Ajax client, you should avoid macros.




Secondly, a common beginner’s mistake is to use macros to build logic into QlikView; logic that almost always works better if QlikView’s own out-of-the-box functionality is used.  An example is assigning a value to a variable every time a selection is made: In other tools you would use a trigger and a macro, but in QlikView this is not needed: You should instead define your variable using an equals sign and the appropriate expression.


Further, many problems can be solved by using a smart data model instead of macros.


Macros often confuse the user. A user wants a predictable behavior and macros often do exactly the opposite: They create behaviors that exist in some places but not in other. This is counter-intuitive.


Finally, if the macro is long or complex, it will often push QlikView into an unstable situation. We have often seen this in documents sent to our support organization. The reason is probably a poor fit between the synchronous, sequential execution of a macro and QlikView’s internal asynchronous, multi-threaded computation.


From a development perspective, the macro feature is a secondary functionality. In the development process, it will rarely get first priority when compared to the “native” functionality: I.e. in the choice between keeping macro functionality unchanged and improving the out-of-the-box functionality, the QlikView development team will often choose the latter. This means that you can get a changed macro behavior when you upgrade your QlikView installation.




Some facts around macros:


  • Single-Threaded?
    Macros are in their nature sequential – i.e. in a way single-threaded. But this is not the same as saying that all calculations started by macros are single-threaded. For instance, if a macro makes a selection that causes a chart to be calculated, both the logical inference and the chart calculation are multi-threaded. As they should be.
  • Clears cache?
    No. A macro does not clear the cache. (Unless you use the macro in the picture above...)
  • Clears the Back-Forward stack?
    No. A macro does not clear the Back-Forward stack.
  • Clears the Undo-Redo stack?
    Yes, if the macro contains layout changes, the Undo-Redo stack will be cleared.


So, I strongly recommend you don't use macros, unless it is in a Desktop environment. And there they should be short and concise! On a server you should instead use Actions.


There is however one thing that may confuse the user more than macros. And that is Triggers. If a macro or an action is started from a nicely labeled button, then the user will understand what happens.


But if the macro instead is triggered by some other event, e.g. the changing of a variable value, we have a very different situation. Then you will most likely create a non-intuitive behavior.


Macros are Bad, but Triggers are Worse.




See also

The Key to Heaven


I completely agree.  I hardly ever use actions either, but the one time I did use them extensively some years back, I remember having trouble understanding the sequence in which a list of actions were executed.  The ascend and descend buttons to order a list of actions gave me the impression the actions were executed sequentially, but I remember having trouble doing things like first selecting a value, then assigning a resulting value to a variable, then clearing the selection, and making a another selection based on the same variable all in one action list.  Any insight on how actions are executed?


As usual, great article! I think there will be a lot of comments around it because macros are the most popular discussion topic.

Everybody is different and everybody wants to differentiate. Custom behaviors, custom data export, emails, custom software integration, time saving automation tasks... all possible with macros.

Yes, macros are bad, but it's the necessary evil.

BTW, any words on the QlikView NEXT API? How the new changes are going to affect the third party tools (like NPrinting, QV Mail,...)?


It's a shame but unfortunately fact....

Macros can be very useful though, especially when actions don't give you the flexibility.

Adding bookmarks done via a macro allows you the define the bookmark. Why are these basic parameter settings missing from the inbuilt action.....?

Not applicable

Henric, I use macro's to define functions in the load script for calculations that are not available with QV functions. For example when I need to a newton-raphson optimisation (iterative process). And offcourse in the user interface to export multiple charts at once. 

MVP & Luminary
MVP & Luminary

Hi Henric, Completely agree with all your points here.  I often post responses on the Community stating that to do that you will need to use a Macro - so don't do it.

Triggers, when used sparingly, can be very useful - but I have seen some real train wrecks where the developer has set a bunch of selections on the On Tab Change event, totally confusing the users.



I agree with all of the above: Though BAD, macros are sometimes still necessary. And also I use them... However, I think it is important to set a base line - the initial approach must be not to use macros. They are the last resort.

@Richard Pearce: I agree. Actions should be able to do that.

@Mathias Vanden Auweele: You are right that you sometimes need to define your own functions - especially the iterative like Newton-Raphson, or to generate Poisson distributed random numbers (something which I have done using a macro function). I would just like to have another way than macros for that...