BTW: The problem with the production script is that urgent anymore, since I discovered the workaround (switching to English on the server running it). However, it’s frustrating to not know what’s going on.
Can you share the error message (and perhaps a rough translation)? You might also try logging pDateString at the time of the error.
Can you isolate this to a simpler script you can share?
But at least we’re out of the oodgie-boodgie woods.
Yes. I’ll do that later
I’ll try
Right. At least att the moment. I’m still confused by the different behavior at different times. Maybe I’ll find beamed into those woods again later.
@ShaneStanley The logged error you asked about was (my translation):
checkInstanceStatus: Can't make quoted form of false into type Unicode text.] – where "checkInstanceStatus " is the name of that handler, proving the error happens inside it.
So I inserted some logging in the production script (code signed) – and did’t get any errors concerting handling of dates – or any errors at all! The script stepped thru all the steps in that handler.
The other possible source for the errors could be parameters passed to it. They originates from globals that are changed from false to strings by sub handlers called from the run handler, and, in a later stage, are passed as parameters to the date comparing function.
So I Iogged these parameters from the date comparison handler as well – and they were fine! Also this time he script gave no errors at all.
I didn’t modify anything in the script anywhere– expend inserting simple strings to log strings in a simplified way. (Like this: do shell script "echo " & quoted form of ("myConfigSource: " & myConfigSource) & " >> ~/Desktop/simpleLog.log")
So when I try to identify the exact errors by logging or making sample scripts - they always slips my hand. And, since I have a workaround for the specific case, it’s time to give up, I don’t want to waste more of my time, or yours, with it.
Anyway, thanks for the interest you have shown to try to help me solve it!
That rings alarm bells. Your error suggests false is being passed where a string is expected.
Clearly. Two phenomenons are notable here:
-
When the script is code signed and run in Mojave (probably with language as another parameter) these globals have kept their original values, despite redefinitions along the way. The redefinitions didn’t stick, or the globals are not really global. This resembles the issues that I had with properties very much!
-
The problem with the globals disappeared when I inserted my write to file-commands.
Actually I have experienced an issue, resembling number 2 above (not number 1), with another applet. This applet has also been in use for many years, but on client Macs. It searches for files in several folders on a server, by asking Finder for ’every file of entire contents of folder x’ in a repeat loop. These folders contain a lot of files. But running that script in Mojave, code signed, every such search gave an empty list as result. When I just inserted a dialog immediately after the search command in that repeat (without changing any variables) it suddenly worked – resulting in long lists of files as before. Replacing the dialogs with `delay 0.1` also did the trick, as probably writing something to a file or other commands would have done. (My final solution was to replaced the Finder command with `do shell script "find...`. That works fine, without any need for a dialog, delay or other command inserted).