The reason the x-axis of your visual adjusts based on the slicer is that they are both representing the same data from the
The calculated table you created
DateRangePeriod defines a range of dates based on some predefined periods like “Yesterday”, “Last Week”, “Last Month”, etc. When you use a slicer with this table, you’re essentially selecting a subset of dates.
Your y-axis is
[Close price] and it’s defined as
Close price = CALCULATE(MAX(AAPL[Adj Close]), Dates[Date]=MAX(Dates[Date]))
It’s calculating the maximum adjusted close price for the most recent date in the
Dates table. This measure doesn’t take the date range from the slicer into account, hence it will always return the adjusted close price for the latest date irrespective of the slicer selection.
Try this measure instead:
Close price =
, Dates[Date] IN VALUES(DateRangePeriod[Date])
Instead of always using the latest date, this revision now considers all the dates from the selected range in the slicer.
This assumes that each date has only one adjusted close price. If there’s any possibility of multiple entries for the same date, this measure will return incorrect results. If, on the other hand, you want to see the maximum closing price over the selected range (i.e., highest closing price in the selected period), then the measure should use the MAX aggregation.
When you select a date range using the slicer, the
DateRangePeriod table gets filtered. Since there’s a bidirectional relationship between
AAPL , the filter context also propagates back to the
AAPL table. This means that not only does the
Dates table get filtered based on the slicer selection, but the
AAPL table also gets filtered to show only rows corresponding to the selected dates.
Perhaps you want that bidirectional filter because you want other visuals (that don’t explicitly use the
DateRangePeriod table) to also respond to the slicer selection. For example, if you have another visual that simply plots data from the
AAPL table without any measures, the bidirectional filter will ensure that this visual also gets updated based on the slicer selection. Or, you may have other measures that aggregate data from the
AAPL table and you want them to respect the slicer’s date range without explicitly referencing the
DateRangePeriod table in those measures.
You don’t need that bidirectional filter if you are only interested in filtering the
AAPL table based on the slicer when you are explicitly referencing the
DateRangePeriod table in your measures. In this case, making the relationship one-directional (from
AAPL ) and explicitly using the
DateRangePeriod table in your measures will suffice.
I say that because bidirectional filters can cause problems like circular referencing and make your data model hard to understand. They can also degrade performance.
I hope this helps.