Okay, in both cases you’re using $action-setfield to set a field to the value of a variable, so let’s look at the variable.
[$(op-1)$[$(param-1)$]search:$(tbl-search-field-list-join)$:$(tbl-search-flag-list-join)$[$(tbl-search-param)$]limit[$(tid-limit)$]!prefix[$:/state/]]
Personally, I find it pretty hard to parse so many substitution variables in a row, so I replaced the ones you’re using as filter parameters with their corresponding <variable>
forms:
[$(op-1)$<param-1>search:$(tbl-search-field-list-join)$:$(tbl-search-flag-list-join)$<tbl-search-param>limit<tid-limit>!prefix[$:/state/]]
That’s better, but still hard to read at a glance. Let’s replace the operators with some appropriate stand-ins:
[tag<param-1>search:title,tags:casesensitive<tbl-search-param>limit<tid-limit>!prefix[$:/state/]]
Now we can compare this a bit more easily to the filter that wasn’t working as expected:
tbl_filter=[note[rad]]
tbl-filter={{{ [<currentTiddler>get[tbl-filter-value]] ~[<tbl_filter>] }}}
tbl-filter-minus-closing-bracket={{{ [<tbl-filter>removesuffix<closing-bracket>] }}}
comb-tbl-filter=`$(tbl-filter-minus-closing-bracket)$search:$(tbl-search-field-list-join)$:$(tbl-search-flag-list-join)$[$(tbl-search-param)$]limit[$(tid-limit)$]!prefix[$:/state/]]`
You have a lot of indirection going on here, but what I notice immediately is that your combined filter <<comb-tbl-filter>>
incorporates <<tbl-filter>>
… which, if you have clicked the button at least once, will always be the current value of the tbl-filter-value
field—which is the same field your button is modifying.
- This means that each time you click the button, it retrieves the current field value and then adds the new filter components (which might already be present in the field).
- Your properly-functioning filter doesn’t have this problem because it’s not starting from the target field’s current value, it’s just constructing a filter and then saving that filter to the field. It doesn’t matter what’s already in the field, because it will be overwritten anyway.
Assuming you want to be able to include ad hoc “starting” filters, here’s what I’d try:
\procedure update-filter() <$action-setfield $tiddler=<<currentTiddler>> tbl-filter-value=<<comb-tbl-filter>> $timestamp="yes"/>
<$let
tbl_filter="[note[rad]]"
starting-filter={{{ [<currentTiddler>get[tbl-start-filter]] ~[<tbl_filter>] }}}
limit={{{ [<currentTiddler>get[tbl-tid-limit]] ~[<tid_limit>] }}}
search-term={{!!tbl-search-param-value}}
search-fields={{{ [{!!tbl-search-field-list-value}split[ ]join[,]] }}}
search-flags={{{ [{!!tbl-search-flag-list-value}split[ ]join[,]] }}}
rb="]"
start-with={{{ [<starting-filter>removesuffix<rb>] }}}
comb-tbl-filter=`$(start-with)$search:$(search-fields)$:$(search-flags)$[$(search-term)$]limit[$(limit)$]!prefix[$:/state/]]`
>
<<starting-filter>>
<<comb-tbl-filter>>
<$button actions=<<update-filter>> tooltip="update filter steps">
Update
</$button>
I’ve taken the liberty of replacing some of your variable names with ones that were shorter and easier for me to parse, but the overall structure is pretty similar. The key difference is that I am storing what I’m calling the “starting filter” in a separate field, tbl-start-filter
. This means…
- It’s easier to edit this part of the filter, independent of the long combined filter, and
- You don’t get into loops trying to modify
tbl-filter-value
based on itself, and you don’t need my hacky <% if %>
workaround to disable the button when it shouldn’t be used.
Hope this helps!