This regards DT4 beta 1 on macOS 15.3.2
If I select “Any” in the top row instead of “All”, DT crashes reliably. And there’s more trouble in the search, or rather in the relationship between the dialog (as shown here) and the textual input field.
Please let me know if you need any more information on the crash like activity monitor files etc.
The crash and console log and the entered search term would be useful, thanks. Is a verification of the database(s) successful?
The DB reopens just fine. Same for verification, no errors reported.
See the screenshot above. I started with typing mdbetrag>1000 and then switched to the interactive dialog by clicking on the cog.
Send the Konsole.log by e-mail to you
I received only the crash log, thanks, but not yet the Console.log. But after looking at the crash log it seems to be caused by broken preferences. It’s the system’ s handling (actually updating & saving) of the preferences that crashes.
The current version of Sequoia is 15.4.
Unfortunately no hints in the log and the crash is not caused by our code. Does rebooting fix this or updating to 15.4 or deleting the preferences?
I’m aware of the current Sequoia version. Just not so keen on Apple’s purported AI features …
I’ll try that later (rebooting). Deleting the preferences … how would I go about that?
E.g. via the Terminal: defaults delete com.devon-technologies.think But maybe you’d want to backup the file ~/Library/Preferences/com.devon-technologies.think.plist first.
Ok, a restart of the Mac seemed to have fixed the problem. What remains is the date issue (if it is one):
As you can see, I set the creation date to 2022-01-01T00:00:00 in the search dialog. In the input field, the date is reproduced as “2023-12-31 23:00:00 +0000”. I take it that the time is “adjusted” to GMT automagically? Regardless, if I type a time search string like that or change the previous one (i.e. with a space between the date and the time as well as between the time and the “0000” (which should be something else, imo, if it’s ment to indicate timezone), the dialog shows a completely garbled search (eg the time part is interpreted as a string for the “all” field).
Playing around: If I use a “T” instead of a space in the input field, the “All” field disappears from the dialog. So, it seems to be a one-way transliteration error from the dialog to the input field, where the “T” is changed to a space. The same holds for the time zone. So, the string should be transliterated from the dialog to the input field as
“YYYY-MM-DDThh:mm:ss[±]xxZ”
I doubt that time should be normalized to GMT or UTC if the user enters it in the dialog.
