Hi. I’m trying to use a variable for the number in a limit statement in a filter expression. I cannot get it to work, and I wonder, is it because it is being interpreted as a string instead of an integer.
I just now got it to work by using a macro. I had tried running it through a macro before, but when I called the macro via double angle brackets, it failed to return what I wanted. When I call it via the $macrocall widget, it does work! I don’t know why.
Brian, I think I tried single brackets as well as double brackets, but still failed to get the field interpreted as a number, not a string. I could be wrong!
I did use a filter expression for the set–filter widget. [{$:/state/pagination}] … You used a transclusion syntax. .. The best way to test a filter is in the $:/AdvancedSearch : Fiter tab. If it shows something there is also should work as a filter parameter.
I did change the limit[<<pagecount>>] to limit<pagecount> Also see Special Parameters.
I did remove the rest[1] because I don’t know why it was there.
I did add !is[draft] … So draft tiddlers are not shown in the list. .. You may remove this, if you want to see them
In general. It is much easier for us to work with a “plain text” description of what you want to achieve than with some code that doesn’t work. … We are able to fix the syntax problems, but we still need to guess, if the end result is something you actually wanted.
Thank you for your patience and attention. I had not thought of using the search as a way to debug filters. I’m working on a simple pagination routine.
I’m wondering if the “number” parameter I specify below is handled the same whether I write:
<$macrocall $name=“build-link” number=‘1’ />
or
<<build-link 1>>
I think I was having trouble getting a filter to treat the number parameter as a 1, rather than text.
I’ve tried to get the value of “totaltidds” into the second filter statement below using single brackets, double brackets, dollar signs + parenthesis and just dollar signs. I don’t think any of those are being interpreted as a number.
Think of the brackets in filter syntax as part of the operand value that is used to indicate the type of the operand:
square brackets are for literal values (i.e. constants)
angle brackets are for references to variables
curly braces are for references to tiddler fields
There is no explicit type casting for numbers vs. text… if a filter operand requires a number (such as in compare:number:lt..., then it should contain only numeric digits (and possibly a leading “-” for negative numbers). If the operand contains any non-numeric characters, it defaults to having a numeric value of 0.
Note also that since the tiddler title in the above filter is just a constant text string, it is not necessary to use field:title[$:/state/pagination]get[text]. You can just write {$:/state/pagination}, which retrieves the contents of the text field from the named tiddler. Thus, your filter can be simplified to:
I have struggled with this repeatedly because I was thinking of those square brackets as immutable, just simple delimiters. Now I see where they are information too. Wow.