Background color expression - Is there a "This value" option?

[oddgeir]

When setting background color as expression, I've only found documentation using a full recalculation of the value. 
Isn't there a "This value" option available? 

My impression is that there is an increased risk for discrepancy between the formula creating the value in the first place, and the expression used for display options. Also it adds work and complexity. The formula can be complex, and can also be changed several times. If the developer doesn't remember to also update the display expression the display may be misleading (Typically number being negative but expression still showing a positive color)

[Or]

Assuming you're dealing with a measure, and assuming you've created a master measure for it, you can reference the master measure by name, e.g. if you have a Total Sales measure which is Sum({1} Sales), you can reference it e.g.

if([Total Sales]<0,Red())

[oddgeir]

Yes, there are ways to mitigate, but then I guess your answer is "no", there's no way to address "what is end result", but I can create the end result as master, which then can be referred to by both value and formatting expression. 

This question came from creating a multi column table, with (potentially) fairly complex calculation in each of the column. It just struck me that to handle the design I had to redo all the value calculations, when I should be able to address the design directly. 

I have one table, I want to define how values are shown in this table, and should be able to copy&paste into all columns.  Instead I have to merge the calculation with design definition, and keep this synchronized in all the updates I do. To me this should be unnecessary complexity in a major BI tool. In Power BI this is straightforward https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-conditional-table-formatting 

[Or]

I don't think Qlik has the equivalent of a "This" reference. You can reference the measure by its name, you can reference a column by its number in the object, but referencing a column in its own properties using some sort of self-reference isn't something I've encountered with Qlik products (though there may be an option I'm not familiar with). You could open an Ideation request if you think this is something that should be added.

[marcus_sommer]

AFAIK there is no This-Reference within the Qlik objects - at least not within QlikView. There may some possibilities with the Sense-API's to create something in this way but it's rather not trivial and I'm not sure if it would be really expedient.

The reason for it is the order of all evaluations for an object. AFAIK the first measure will be the creation of the virtual table behind the object providing the dimensional context - by considering all specified fields in the dimensions as well as in the expressions - on which all applied aggregations are performed. Everything of valide field-names needs to be already there when the initialization of the object starts.

I think something similar happens with adhoc-variables created by a $-sign expansion within any part of the object - they will be calculated before the object is evaluated and the returning single-result of it is applied for each call. Also the script behaved in such a way because all queried fields must exists within the source - and it's not possible to check their exists during the load.

From a pure technically point of view there are surely ways to add at least one layer to a creation-statement to evaluate anything on-the-fly and/or to fetch any errors but it will of cause increase the complexity and decreasing the performance. IMO it's an intentionally design-decision from the earliest QlikView days to keep everything as simple as possible and to return the maximum of performance even if it's not the most comfortable behaviour for the user.

Beside this by using a parametrized variable for the expression you may be able to reduce the manually efforts significantly, which means you could copy the expression with this variable and then only adjusting the parameter(s). Further there is quite often much potential to reduce the UI complexity with a better prepared data-model. A quite good example are P&L views which many try to solve with a lot of (nested) if-loops and/or aggr() to query which accounts belong together, are positive/negative, any partial sums, whatever ... but everything could be done on a dimensional level and a single expression of sum(Value) would be sufficient. I think that's also possible for many other scenarios and often much simpler as solving it within the UI.