Good morning, I’m new and learning.
I have an agent that collects notes from a watch folder based on text files.
The query for this agent is: $Text.contains("#work") & !($Tags.contains(“work”)).
The reason for the second condition is that i don’t want to collect again an alias when I remove a note to put it in a different position on the map.
For that scope I have set an action on remove: $Tags=$Tags+“work”;$Prototype=“Integrated1”. The First action should add the tag “work” that should be the condition for the agent to not collect that element again.
It doesn’t work because in a first moment the tag work is added properly but after a few seconds, when the agent recalculate again, the tag disappear and is set to none.
Maybe the condition !($Tags.contains(“work”)) isn’t correct?
Thanks for any help.
Not knowing other details of your set-up, the issue could be the sequence of these actions:
- The first step sets $Tags to a new value, but then…
- The second step assigns a new prototype, including the prototype’s values for $Tags. Thus the action in the first step gets overwritten (presumably). That would also explain the time-lag you report.
If you reverse the order of those steps, you would avoid the over-writing or re-setting of $Tags values.
(And, as others will point out, the forum software here converts normal quotes into “curly” typographical quotes, “like this.” For coding, as you’re aware, they need to be straight quotes. To display straight quotes in the forum, select the word in quotes and apply the “preformatted” button from the editing tool bar. It’s the one that looks like this </> , and its result is quotes "like this."
Thanks for the prompt answer Mr James,
Unfortunately reversing order of remove actions doesn’t solve the issue.
I have tried also removing all prototype assignment actions and now I have only this on the agent:
Query:
$Text.contains("#work") & !($Tags.contains("work"))
Remove action:
$Tags=$Tags+"work"
The behavior remains the same, after a few seconds the tag “work” is removed and the alias of the item is created again inside the agent.
Any other idea?
Thanks again
Hmmm! Obviously I don’t know what else is set up within the file. (And, of course, Eastgate support is the place that could really tell you, if you were willing to send them the file. My experience over the years is that – unlike, say, Facebook – Eastgate is very good about just looking at structural issues and not in any other way using, storing, or looking at your data.)
Based on your explanation, it seems that the file has to contain some rule, action, agent, or other process that is un-doing what your Remove action does. (You’ve confirmed that your Remove action works, since you initially see the “work” tag. So there must be some other rule or process undoing it, because otherwise the tag would not remove itself.)
So, two suggestions: 1) Send the file to Eastgate, vagueing up some of the data if you want. Or 2) Look very carefully at all prototypes and containers to see what rules or actions might be involved there, including ones you might have forgotten about, that could be having the over-write effect.
Good luck!
Update People who are more expert than I am in query-syntax than I am may have advice on the agent-query itself. It’s conceivable that the query term $Text.contains("#work") introduces some complexity I’m not aware of, which would mean that the agent keeps re-matching items even when it seems that they should be excluded.
Or, conceivably this is a .contains-vs-.icontains issue? The experts can tell you.
The problem seem solved, I have create a list attribute named $Area that does the work of $tags attribute. And for the moment it’s ok, when “work” is assigned to $area, the item is not collected again from the agent.
Tinderbox give us a lot of alternative weapons to be used for the same work.
Remain the fact that I don’t understand why $tags.didn’t work. Maybe because $tags is a set and $area is a list attribute? And what is the difference? Who nows? But Maybe this Is a question for another section of the forum( I have to read better the documentation and look for answer on other topics I know)
ciao
At this point I would make the smallest possible test file with enough notes to test only this aspect of your work. If this test alone doesn’t work then you’ve localised the cause and can deconstruct further. Otherwise you know the failure is other code in your larger file that’s causing the problem.
It always feels like less effort to have one more try in situ before starting a stand-alone test but generally it’s a time saver as often the ‘fault’ isn’t what you assumed it to be.
Here, without seeing your file - or a smaller test file showing the same problem, it is hard to speculate as to the exact cause.
Thank you Mark and James
I have solved the issue, working from the outline perspective I found my error.
I don’t say you the solution, I’m ashamed. 