One note is found. Its prototype is pNote and its ReviewDate is 3/14/18, 9:37 AM. “today” is currently 11/15/17, 3:18 PM (I got this by defining DisplayExpression for a note that adds date(“today”) to its $Name).
How can $ReviewDate<date(“today”) evaluate to true? Or have I once again left a typo somewhere?
I can’t replicate this in a new document (same app version). Was the alias already there and then you changed the query? I only ask in case the issue is that the agent isn’t updating properly.
FWIW, I tested with the query $ReviewDate<date("today") as the rest of the query isn’t evaluated if the first query term isn’t matched. I’m on a UK (day/month order) but used the same 2018 date time as you and it’s still 15 Nov here.
Is it possible that $ReviewDate was entered incorrectly – e.g., it is actually 3/14/1918 and not 3/14/2018? The two dates will look alike in the KA list – e.g., here the date shown was entered as 3/14/1918 and the query (correctly) finds it:
It’s 2018. I clicked the small calendar next to the date and up popped March 14, 2018. The date was auto calculated by a Rule: $ReviewDate |= date($Created+“4 months”);
Can you post a link to a small TBX that shows this error? Answers above have addressed the obvious possible missteps. Seeming the error live would help.
Mark, the alias came up after I entered the Query in the Action Inspector and pressed Enter. I experimented by cutting out
& ($Prototype == “pTicker” | $Prototype == “pReference” | $Prototype==“pNote”);
from the original query and did get three more aliases that had other prototypes. Each of those had ReviewDate of 6/15/01. If I paste the string back in and press Enter, these three disappear and the lone 3/14/18 remains.
Well, things have been solved. I decided to follow my advice from an earlier post about a problem with some other agent - to reboot the Mac. That did it. I’ve played around a little with the agent described above (cutting and pasting parts of the Query string and testing each version)) and everything seems fine. The end result with the Query as originally specified is no alias. Correct.
I don’t know what the problem was, I’ve used the Mac off and on all day without running into any glitches. Oh well.
[addition] Earlier today I did have some repeated crashes with TB (sorry, I forgot about these). Each time I reinvoked it and continued my work. Now I suspect some TB/system file that was corrupted - but would that remain after crash and invoke? It’s the only thing I can think of.
I find the app very stable (even in my role as a beta tester) but if I do manage to crash it, most often the cause is me feeding an incomplete or bad query to the app. Not by intent, mind you, but an unspotted typo can confused the query parser to hang or at worst crash.
Of course, whilst learning/experimenting the scope for (inadvertently) creating bad queries is great and thus can give a false impression of instability. The good news is that the auto-saving built-in invariably captures all but the last few seconds of change - though that does normally include the malformed query.
Aside, do email any crash logs to Eastgate as even without the source doc/info they may help point to something that can be fixed improved.
I’m certainly not finding the auto-saving of a tbx file happening. A crash just happened to me. I was not working on agent rules or queries, just clicking on a note in the left panel to invoke it and boom. TB crashed. Actually, I’ve been using TB with this file for awhile and agents have been behaving quite nicely. Instead, today I was just jumping around looking at various notes.
I also note that the “close” (red circle) icon in upper left of window has the small inner dot turned on until I manually save the file. The Preferences window is quite bare, no option to turn on/off auto-save.
Running MacOS 10.12.6 and TB 7.3.1 (b 292).
The crash log - there’s no reference to it in the menus. My MacPilot doesn’t list a log that includes data for TB. Where do I find it?
Firstly, auto-save such as you may remember from pre-v6 no longer exists. It is now part of the Apple Frameworks on which Tinderbox is built. If I recall is is the ‘versioning’ seen in the menu File → Revert To…
Beyond than, if you use Time Machine there is further auto-save support.\If you have a crash, TB generally recovers all the data up to very recently before the crash. The black-in-red ‘dirty’ document dot is easily explained. If your documents has agents and the agents are set to update automatically, the document is constantly being changed. It is also (above) being auto-saved in the background. If you have a crash you should - my experience, at least, recover everything except the most recent inputs. Whilst it might seem frustrating not to recover the most recent keystrokes, those are likely the cause of the crash so you’d be in a closed loop. Separately, agents will just pick up where they left off.
I don’t (even as a beta user) find Tinderbox to be a crash-prone app. Clearly, if you do find a crash condition, replicating will (as one should expect) replicate the crash though in this case it is an error on the user’s part. until the cause is fixed a repeatable crash condition is just that. In the case where you do get a crash, it is in your interests to email the crash log to support (info@eastgate.com) so there is information to start addressing the issue.
Open the Console application. In High Sierra’s console, select the User Reports section on the sidebar. The crash reports are here. They are listed alphabetically, so scroll down to the Tinderbox crash(es), click Share in the toolbar, choose Mail and send the selected report(s) to Eastgate.
