Have just found a strange behaviour in Dialog Toolkit. I have this call:
set {intro_label2, theTop} to create label diag_intro_text_2 left inset 0 bottom 5 max width minWidth aligns center aligned control size small size
In macOS 10.14.6 and macOS 10.13.6, the resulting dialog shows diag_intro_text_2 correctly aligned to center. But, in macOS 12.4, that text is right aligned.
Is there something peculiar to macOS 12.4 that could be causing this ?
Thanks.
Yes, the underlying value of the constant used to specify alignment has changed – it’s a result of unifying divergent iOS and MacOS values.
You can work around thissue by changing the properties in the library. So this:
property NSLeftTextAlignment : a reference to 0
needs to become:
property NSLeftTextAlignment : a reference to current application's NSLeftTextAlignment
Do the same for the other alignments. They should then resolve correctly at runtime.
Shane, many thanks.
Where does Apple notify developers of such changes ? I find Apple’s documentation impenetrable.
BTW, Googling NSLeftTextAlignment results in this page: Apple Developer Documentation.
Apparently, NSLeftTextAlignment has been deprecated. How would NSTextAlignmentLeft be used ?
I’ve looked at the enumeration for NSTextAlignmentLRight and I’m totally lost. First it says:
Declaration
NSTextAlignmentRight = 2
But, then, there’s this note:
Note
In Mac apps, including apps built with Mac Catalyst, the value of this enumeration case is 1.
So, does that mean the declaration is really NSTextAlignmentRight = 1 ?
OK, I’ve updated the library to version 1.1.3 to fix this issue.
It was in release notes. It wasn’t well documented, but it didn’t affect most apps.
They’re the same thing, except they’ve changed a whole lot of names to a more consistent style, for the sake of Swift. It’s better in ASObjC to keep using the old version, unless compatibility doesn’t matter to you.
Shane, thank you for this.
I made what I thought were the required changes to the Toolkit code. It worked for a while with center alignment where I needed. But after a few days, Script Debugger started banging “Scripting Component Error” when I tried to compile my script. I was able to compile by commenting out a “display dialog” I use for testing. So, I could then run the script. I use a Try/On Error block to test the script. The TryBlock started reporting “Variable newWidth not defined” errors. I mucked around with my script some more and, then, consistently, I started getting “NSThread doesn’t understand the “isMainThread” message” errors on my script.
So, I reversed my changes to the Toolkit and all the errors ceased. Suggests I don’t know what changes to the Toolkit are need to get proper alignment in labels. These are the changes I made:
-- property NSLeftTextAlignment : a reference to 0
property NSLeftTextAlignment : a reference to current application's NSLeftTextAlignment
-- property NSCenterTextAlignment : a reference to 2
property NSCenterTextAlignment : a reference to current application's NSCenterTextAlignment
-- property NSRightTextAlignment : a reference to 1
property NSRightTextAlignment : a reference to current application's NSRightTextAlignment
Is there something else needed ?
In my script I call like this:
set {intro_label2, theTop} to create label diag_intro_text_2 left inset 0 bottom 5 max width minWidth aligns center aligned control size small size
Thanks.
It sounds like you might have multiple different versions. At any rate, the changes you made should not cause any of those errors. Restart?
Shane, many thanks for v1.1.3 of DTP. I’ve used that to make my project’s customisations and all is well.
I suspect I accidentally made a change which I didn’t notice and which caused the errors. Still got errors after quitting SD8 etc. So, I ditched my effort.
I spoke too soon. DTP v1.1.3 (with my customisations) crashes with “NSThread doesn’t understand the “isMainThread” message”. However, it only crashes if I call a DTP handler from a script running in osascript invoked by a Service. If I do the same but invoke osascript with an applet, there is no error. Also, there are no crashes in macOS 10.13.6 in both scenarios. And, no crashes if I use v1.1.2 of DTP (with same customisations).
Not sure what to do as yet. Might make using the Service to invoke osascript specific to macOS versions which work but, hide that function from macOS 12.4 and others as relevant.
That’s usually either a missing use statement, or an intermittent Apple bug where frameworks aren’t loaded.
Thanks. I suspect the latter – I can’t think of where there could be a missing use stmt. The DTP library is fine and the Service and other scripts have been working for months/years.
UPDATE: I’ve given up with v1.1.3 of DTP. I can’t find a way of stopping the NSThread error when calling from a Service. I tried the NSTextAlignmentRight/Left/Center form as in Apple’s documentation but it banged the NSThread error in every test. I tried adding use script DialogToolkitPlus in the Service but, that caused the Service to crash. I’d rather keep my function working and put up with right aligned instead of centre aligned text in the dialog. Thanks.
UPDATE: Did some more testing now that macOS 13 is maturing. Quick reminder: my applet spawns an AppleScript process in background with osascript. The new process shows a dialog using DTP.
Have found that DTP v1.1.3 does work with my applet but only if the spawned script process is in foreground. If it is spawned in background, the script runs properly but, the dialog created by DTP v1.1.3 does not show.
UPDATE 2 – I think I’ve had some progress.
My applet spawns a background process which uses the Dialog Toolkit Plus library to display an “enhanced window”. It has been working since 2017. It uses a customised copy of DTP Plus v1.1.2.
This year, however, I’ve found that if I edit the DTP library, the background process bangs an error “NSThread doesn’t understand the “isMainThread” message”. The edit can be anything including, just adding a comment line. I also get that error if I use a vanilla copy of DTP v1.1.3 instead of my customised version.
Today, I found that there is no error if I edit the DTP file with Script Editor instead of Script Debugger. So, for example, using Script Editor, I’ve fixed the old problem with alignment of text labels. I’ve tested in macOS Ventura and High Sierra with no errors.
So, my theory is that editing and saving the DTP script library using Script Debugger is doing something that Script Editor does not do and that difference is resulting in the NSThread errors I’ve been getting since March this year.
Can you send me copies of the same lib saved both ways?
UPDATE: Have noticed that the Quick Look feature in Finder shows the content of the “main.recover.rtf” file instead of the updated AppleScript code. So, I deleted the “main.recover.rtf” file from the DTP bundle and found the “NSThread doesn’t understand the isMainThread” message was not happening as much. Too early to tell if it is fixed but, seems to be so.
UPDATE AGAIN (hours later): Nope, now I get the “NSThread doesn’t understand the isMainThread” error no matter how I save the script library with or without the “main.recover.rtf” file. I’m going to have to backtrack through changes to find which change causes the error.
I’m having a similar error and am having a very hard time nailing it down. I’m a bit of a newb, so I’ll do my best to describe it. I have a handler that uses create buttons, create checkbox, create side labeled field, and display enhanced window and when I get an error, I get the same “NSThread doesn’t understand the isMainThread” error on all of them. I don’t tend to get the error when running the script in script debugger, but I do sometimes – not always – get the error seemingly randomly when I attach a keyboard shortcut to the script and use the shortcut. I also get the error when I use ‘run script file’ to run the script within another script, whether that script is run from a keyboard shortcut or from script debugger. Sometimes I make a small insignificant change in script debugger (like removing a log message line) and the error appears when I run the script directly from script debugger. When I just run handler with the dialog toolkit functions all by itself in a script, the problem doesn’t seem to occur, but I have tried adding in the rest of script piece by piece to see what is causing the error and it seems to show up when I add different components — I will add a piece and see the error, and then remove the piece and add it back in and not see the error for example. So I am at a bit of a loss. Do you have any advice for what to try or check? I am using Dialog Toolkit Plus version 1.1.3 and have tried reinstalling it. I on macOS Monterey 12.6 and am using script debugger 8.0.5.
Thanks in advance for any leads or guidance.
I’m afraid that as far as I can tell, it’s a system problem. It’s very frustrating, but I can’t see any pattern to it.
Welcome to the forum and to AppleScript !
Can you describe more about how you have arranged your scripts. For example:
I have a customised version of DTP stored inside my applet’s “Script Libraries” folder but one script in the applet uses a copy stored in ~/Library/Script Libraries. That script runs in background and is the only script which gets the NSThread error when calling DTP handlers. I’m working on a Mac Studio running macOS 13.1.
I do not get the error on an old version of my customised copy of DTP (from March 2022). The error only started for me when I added the DTP v1.1.3 changes to my customised copy in July. Also, I have found I get the error less often if I edit the DTP script in Script Editor instead of Script Debugger.
Yesterday, I worked up a new customised copy of DTP by using a copy which did not have the NSThread error. I used Script Editor for all the work on that copy of DTP. Testing through the process produced no NSThread errors. Throughout that process I did not edit my applet with Script Debugger.
Yesterday I also noticed that Finder’s “Quick Look” when used to show content of the DTP bundle, shows the content of a “main.recover.rtf” file instead of the current code in main.scpt. That probably isn’t relevant but I wonder why Quick Look doesn’t show the correct content.
I think that something happens to the DTP bundle when I save my applet in Script Debugger. I then get the NSThread error. So, I’m planning to maintain my customised copy of DTP using Script Editor separately and keep a “sacrificial” copy of DTP inside my bundle, in case editing and saving my applet in Script Debugger causes changes to the DTP bundle. The sacrificial copy will be the old one from March which doesn’t get the NSThread error. When I’m ready to release a new version of the applet, I’ll swap the real and sacrificial copies. I doubt that Script Debugger is the cause but, I’m trying to use processes that isolate the problem.
Cheers.
Thanks for the reply! My copy is stored in ~/Library/Script Libraries and I have not customized it. I think I opened it once in script debugger to look at it, but I definitely did not make any changes, though it might have compiled it. I know this is a newbie question, but if I download a new copy of a previous version of DTP and never open the main script in Script Debugger, but still edit code that calls DTP handlers in script debugger, would that be similar to the situation you are talking about? I am not sure about the technical definition of an applet and whether using DTP handlers within other scripts edited in script debugger counts as saving DTP as an applet in script debugger.
My copy is stored in ~/Library/Script Libraries and I have not customized it.
Somewhat different to my situation. Mine is also in ~/Library/Script Libraries but is customised and is used by a script which is run in background by osascript.
would that be similar to the situation you are talking about?
I don’t think so. But, I need to research more what happens when saving an applet in SD.
I am not sure about the technical definition of an applet
In Script Debugger
The resulting file will be a macOS application bundle. They are typically called “applets” because they are Applescript scripts with a small macOS binary that runs the script. Some people just call them applications – I do that when communicating with users who might not know about the distinction between applets and applications. Note that all applications in macOS are bundles.
Cheers.