Two pieces of AppleScript: one works, one fails—why?

DEVONthink
25

Have you tried 5.31.2021?

26

Yes - and again just now: same error. Please don’t spend too much of your time now on this, I’m getting quite embarrassed about the whole thing! If you have any more ideas, at leisure, just return to the thread when you have time.

Stephen

27

No need to be embarrassed.
We’ve all had our :thinking::face_with_symbols_over_mouth: moments in automation.
I’m sure we’re just missing some little detail.

In the replies, is the expected filename, i.e. with the expected date, reported?

1 Like
28

Thanks for the good cheer! Am sure it’s something quite stupid but have been hammering away at the wretched thing for 24+ hours without getting anywhere!

Let’s relax and come back to it some time. Thanks so much for the support, as usual.

Stephen

29

You’re welcome :slight_smile:

30 
tell application "Script Editor"
	display dialog "Enter the link date as DD/MM/YYYY" default answer "01/07/2021"
		--> {button returned:"OK", text returned:"31/05/2021"}
end tell
tell application "DEVONthink 3"
	open database "/Users/stapp/Documents/DevonThink/Diaries.dtBase2"
		--> database id 3
	search "name:Monday 31 May 2021.md"
		--> {}
Result:
error "Can’t get item 1 of {}." number -1728 from item 1 of {}

Stephen

31

You’re right. That’s even weirder. The date itself is
current date given «class Krtn»:{weekday:"wday"} --> date "Freitag, 23. Juli 2021 um 19:14:26"
According to script editor.
I give up.

32

Don’t despair. A date object is displayed using the system’s locale settings. The constants are not coming from that displayed text. They are separate properties of the date object. The display is not the object (“Ceci n’est pas une pipe)”

And there is a way to get a date object to display in a language that’s not the system’s.

33

Now my brain hurts (and the listing you linked to messes up UTF-8 characters :wink: But I see that you had your hands in this AppleScript solution, too – better to think twice next time I comment a post of yours :wink:

Here’s what I’d do in JavaScript

 const locale = "de-AT";
 const weekdayFmt = new Intl.DateTimeFormat(locale, {weekday: "long"});
 const monthFmt = new Intl.DateTimeFormat(locale, {month: "long"});
 const today = new Date();
 today.setMonth(0); /* change month to January to get a more interesting output */
 const weekday = weekdayFmt.format(today);
 const month = monthFmt.format(today);
 console.log(`It's a ${weekday} in ${month}`);

which tells me It's a Samstag in Jänner, which is a really nice touch for our Austrian friends. I find this approach a tad more convenient and robust than fiddling around with locale files that might be stored in another location in a new version of macOS (and/or change the order of lines or whatever).

But I agree, it is feasible. And date/time are a never-ending source of joy and fun:

Dankjewel!

34

I have the impression that @Stephen_C and @BLUEFROG are using different ways to search for the record: @Stephen_C does something with (contents of …) whereas @BLUEFROG uses search. Could that make a difference?

35

Just a wild guess: one of those literal spaces may not be only a space. Replace them with constant ‘space’ [heh]:

set theTarget to wDay & space & dateDay & space & dateMonth & space & dateYear & ".md" as text
36

Sorry, catching up with everything…

Not now - see this earlier post in the thread.

The reason I think that’s not the problem is this: why the devil does it work if I delete the default date in the input dialog and then input that default date manually, but then if I input any other date in place of the default it fails? Clearly the default date must be being processed by the code in exactly the same manner as any alternative date, surely? So why does one work and the other fail?

Am slightly battered now but tomorrow if I get the chance I’ll try with many alternative dates (I have thousands of records - covering every day of the past 40+ years - with which to experiment!) to see if any of them work (although I’m not optimistic). Something completely bizarre is going on and I simply don’t for the moment know what it is. I don’t think I’m being completely stupid but am beginning to wonder!

Stephen

37

You didn’t identify what’s not working
For myself (Canadian)
Script 1 generated targetRecord Thursday 1 July 2021.md
Script 2 generated targetRecord Thursday 7 January 2021.md

38

Stephen, are you running the script from Script Editor or from within DT (as an embedded script in a rule)? If from Script Editor, could you please post a replies window as Jim did in this response?

39

Sorry - what happens is that the first script finds the UUID of any record - whether that of the default answer or that of any other date I input in place of the default answer. (In other words, it does exactly what I want.) The second script will always find the UUID of the record shown as the default answer (even if I change the default answer in the script to a different date) but will never find the UUID of a record with a different date which I input manually (even if that record exists and can be found by changing the default answer, in the script, to the date of that record).

I’m running from Script Editor for debugging purposes and posted here the response given in the editor when the second script fails.

Edit: removed edit for further testing of script.

Edit and correction: script now finds the record if default date is 01/07/2021 but fails on most (all?) changes to that default date (even though the relevant records exist).

Stephen

40

There may be a little good news. Following a lot of cutting and pasting of results from Script Editor and checking manual search results in DT it appears as if the problem may be resolved by dispensing with the .md extension when assembling the file name in the script. If that is present (even when manually searching in DT) entries seem not to be found. Removing the extension produces promising looking results from the script (in that the script actually produces a UUID). I still need to check that the UUIDs produced are those of the actual, relevant entries.

For those who have assisted, many, many thanks. I guess the problem is that I have 18,000+ markdown files all divided into relevant years and with a generated table of contents for each year. (The latter being the reaon I need to check that the UUIDs are not being produced from the tables of contents.) That means I have an awful lot more records than those of you who have been kind enough to test.

Life has to go on…I’ll do some more testing later. In the meantime, huge apologies for the length of this thread and the work generated for all who have tried to help.

Stephen :pray:

41

No need to apologize!
Just the other day I belabored my parents with a diatribe on some changes I need to make to our documentation. When I was done, my father astutely said, “Sometimes it really helps to jus talk things through out loud.” :slight_smile:

PS: Are you showing extensions via DEVONthink’s Prefererences > General?

1 Like
42

Jim, you are always so kind and supportive: I can’t express how much that’s appreciated: thank you.

Yes - Show filename extensions is checked.

Stephen

43

You’re very welcome :slight_smile:

Thanks for checking that out.

Yes, excluding the extension from the string would be a good idea.

I would also suggest using the search form I mentioned. It’s basically the same as typing in a search in the toolbar search field, just tell DEVONthink to do it via AppleScript. You can edd search prefixes in the query to target Markdown files, just as you would in a normal search, so…

set foundRecord to (search "name:" & targetRecord & " kind:markdown") in (database "11")

would only return matching Markdown files.

44

Yes, I’ve done that, thanks.

That’s most helpful, thanks.

I think, at the end of this exhausting and exhaustive thread, we are home and dry…at last.

Stephen

1 Like