Thanks. Good, you have created the Row
and Column
attributes and not messed with the default value.
Sadly the rest is a mess. The agent fails because the query is not correct - via legacy support and best-guessing, the agent is is simply returning all item (bar itself) in the document. This is why in a test it is good to have a note that you know shouldn’t turn up in the query. As the query’s syntax doesn’t even make sense, it’s hard to guess what you wanted
OK, but the only part of that which is valid syntax is the ampersand in the middle! If you want to find a note whose Row
attribute value is 6
and whose Column
is 4
then you must have a note with those attribute values (but your TBX doesn’t) and the query would be:
$Row==4 & $Column==6
We’ve been through this several times and I’m at a loss as to why you aren’t following the instruction given rather than just guessing.
This is not correct. The ‘+’ sign in the text pane opens the Key Attributes configuration pop-over. That is not the same as the Key Attributes table. This is why your comment makes no sense. The pop-over lets you chose which attributes to want to see in the Key Attributes table for the note you currently have selected. Also Row
and Column
are User group attributes and could never be in any other group such as the Sandbox because all the other groups contain System attributes and you can’t add/delete attributes in those groups.
Below I use the Get Info dialog, for illustrative purposes—I know you are editing via the Key Attributes table, to show that Row
and Column
are indeed in the User attribute group:
Given the the Key Attributes set-up pop-over doesn’t edit values but simply configures which attributes are then shown in the Key Attributes table, my hunch is you tried to edit values using the pop-over. If so, why? Where in any documentation or advice have you been told to do that. In which case why try, when you have the Key Attributes table, which does allow this?
No, and this doesn’t make sense either.
Yes you should have! So, close…
Your Tansey note has this Key Attribute table:
As this literal string value is the same as your non-sensical agent query, I assume that you thought the two would match but they don’t. as explained above the agent is so confused it is just returning every note in the document and not just ‘Tansey’ which was the expectation.
Using the corrected query (i.e. $Row==4 & $Column==6
) your ‘Tansey’ note values for those attributes should be set accordingly. If I correct the agent query in your document it now finds nothing. If I set your ‘Tansey’ note with the correct values:
I’ve no idea what the other two notes do. They have MyNumber
set as a Key Attribute but the query doesn’t use that attribute.
OK, see if you can reproduce the correct result. Take you current doc, make the corrections I’ve described above and see if you can’t get a result as in the last screengrab.