Little Hotfix:
If a command was defined with only a direct parameter or a result type, the entries were stored outside the command block.
Edit: See Last Build
3 Likes
Would sure like to use this to inspect .scptd file sdefs too.
Also, does anyone know where the sdef file for Standard Additions is?
/System/Library/ScriptingAdditions/StandardAdditions.osax/Contents/Resources/StandardAdditions.sdef
2 Likes
I have a feeling I’m missing something simple. On the left is the library I want to add a dictionary to. On the right is the dictionary xml with one command in one suite. The library script won’t compile.
What am I missing?
Restart the Script Debugger after changing the .sdef file.
Edit: And check the codes in the dictionary (Window → Sdef Validator).
I had problems in the Script Debugger, if they are not correct.
Apparently they have to start with the code of the Suite and the length must also fit.
Safari.scptd.zip (9.6 KB)
1 Like
Thanks, that was helpful. The version with the four-character code I posted was me trying different variations. Quitting and relaunching SD did the trick.
WARNING: Be careful when using the last version provided by Dirk.
Can anyone confirm the following issue?
As a test, open any (copy of a) dictionary.
Just add a single character in any description, save the file and re-open it with Sdef Editor.
You will get this kind of alert:
Then open it in a text editor. You will see that the close tag for every parameter [</parameter>] is missing:
People have different preferences, but as someone who has written a few dictionaries, I used SDEF Editor, and I also wrote my own. But I went back to using BBEdit and some copy-and-paste. I just found it quicker, less error-prone, and ultimately more comfortable. Might just be me.
1 Like
This is the same problem as with the direct parameters or the result type. At many places in the code a:
[node appendChild:childNode];
executed and then a property:
[node setEmpty:![node hasChildren]];
set. But sometimes not and if setEmpty is “YES”, the node is closed with “/>” instead of including the child nodes. In some places (for example, in the result type), a:
[node setEmpty:YES];
is explicitly executed. No idea why. A list of text or similar is in my opinion valid as a return.
I have created a new build in which setEmpty:NO is set if child nodes are present:
1 Like
I’m using both, I find Sdef Editor helpful for spotting errors.
Making good progress (I think).
A quick question: As I’m testing I have the dictionary open in BBEdit and a the library script and a testing script open in SD.
When I quit SD I get an alert in BBEdit saying the document (the sdef file) has been changed, and I have the option of keeping my changes (in bbedit) or reloading from disk.
So, my question, out of curiosity, is how and why is SD changing the sdef file, and is there something I need to be aware of?
I suspect it’s just the result of the way packages are saved – there can be some copying going on.
1 Like
@tempelmann’s issue was that the app chokes on the CocoaStandard.sdef file:
Here’s a few files that the editor cannot open:
/System/Library/ScriptingDefinitions/CocoaStandard.sdef - does not like
<access-group identifier="*"/>
/System/Library/ScriptingAdditions/StandardAdditions.osax/Contents/Resources/StandardAdditions.sdef - does not like multiple types:<type list="yes"><type type="text"/><type type="number"/></type>
I was about to install the original version to run on Mojave when I found this open issue. Unfortunately, @Dirk’s new version requires Catalina or later so I can’t test it. I agree that it’s pretty important whether or not @Dirk 's new version has the same problems.
Does it?
The new Version has currently the same problems with:
<type list="yes">
I will see what I can do when I have more time.
1 Like
If I’m redacting CocoaStandard.sdef for use in my app, if I remove those problematic elements manually, the Sdef Editor should then work as intended, right?
New Version:
Sdef Editor (Intel - 64-bit V 1.9.1).zip (1.4 MB)
Changes:
Apple has introduced a new list type in the Sdef definition:
<direct-parameter description="a list of items to display">
<type list="yes">
<type type="text"/>
<type type="number"/>
</type>
</direct-parameter>This type is not recognized by the Sdef Editor during import, because the source code is very old.
The new version converts the list type to this format:
<direct-parameter description="a list of items to display">
<type type="text" list="yes"/>
<type type="number" list="yes"/>
</direct-parameter>The result should be the same.
Edit: The result is not completely identical. For example, with the Sdef Editor it is not possible to define a type "list of text or number". Therefore "list of text or list of number" is used instead during import.
2 Likes
New Build for Apple Silicon & Intel-64-bit:
Sdef Editor (Apple Silicon & Intel 64-bit V 1.9.2).zip (1.8 MB)
5 Likes
Hi @Dirk ,
After some quick tests, the app seems to behaves well here (macOS 12.6.8, intel processor).
[Not a big deal but did you noticed that the app crashes when moving a command or a parameter in the ‘Suites’ pane? This issue was already there on the previous version.]
Thank you for sharing. As @estockly says, you’re a gentleman!
1 Like
Hi Jonas,
There are a few places where the app crashes. The source code is very old and I was glad that I was able to compile it (the app was still 32 bit and therefore no longer ran with current macOS versions).
In terms of content, I have only made a few changes so that Sdef files can be open and created. I would also like to leave it at that, because it is not my code and my app. It is essentially only recompiled.
1 Like