One of the previous SD versions had a problem that caused a script file been saved, after being compiled, and when reopened would open up uncompiled. Saving it again didn’t change the problem. Restarting SD didn’t do any good. I eventually went as far as to do a safe boot on the iMac and the problem still remained. None of the files, 28 in all, could be fixed by just resaving them. But if I did a recompile on the bad files every worked fine until I reopened them later. However if I opened a new SD window using SD 6.0.4, copied the text from the misbehaving script and pasted it to the new window then saved the new script everything worked fine with the new script. I could close the window, reopen it and it came up compiled.
I noticed this when I opened some older files yesterday. It’s not a big problem. But I wanted to mention this in case others run into the same problem. It was pretty simple to fix this after I figured out how to fix it. I enclosed one of the problem files in this post in case you wanted to look at it. These files were saved around the beginning of the month. But I’m not sure if the last save caused the problems.
By the way I’ve always been curious how the auto update for SD 5 to SD 6 files went. After so many hundreds of tests I was hoping it worked well.
Logical comparisons & bitwise operations.scpt.zip (3.1 KB)
This isn’t a Script Debugger issue. The example document you provided carries
.scpt filename extension but is actually a text document and should have the
Script Debugger is forgiving in this situation and sniffs the content of the file to ensure it can open the document despite the incorrect filename extension.
I am very confused by by your reply. I created that file in Script Debugger. I never did any saves to the file without using script debugger and it definitely started out as a compiled script. I never changed the file extension. This only happened with SD.
Perhaps I was not clear enough. I’m “not” saying SD doesn’t work now. I’m saying for a while a past version most likely caused a problem which has comply gone away with a later version of SD. I was only passing it on because another SD user might come across a file like that. So I was giving you a “heads up” in case someone else reports the problem. There is no action for you to take because the problem with SD doing that is gone.
I am curious why SD didn’t just save a compiled version overtop the text file. When I tried doing a save from the file menu with command-S it just wrote the same text file over top the old text file even though the file extension was scpt. I didn’t think SD would do that. That’s probably I never thought of checking if the file was a text file. I assume SD notices what actually loads into SD and treats the script accordingly.
I’m sorry if I gave you the wrong impression about what I was reporting.
I cannot explain how your document became a text file. I am simply reporting to you that the file has somehow become a text file.
I don’t have a memory of the problem you refer to so, as it seems that problem is resolved, I focused on what was in front of me. When I opened your script it appeared as uncompiled which puzzled me and suggested a SD problem may still exist. When I saved, closed and re-opened, the script was once again uncompiled. When I looked further I discovered that the document was actually text, despite its filename extension, which fully explained SD’s behaviour.
Yes, SD will retain the script’s name and type. Once loaded, when you do a save, SD will create the same kind of file (regardless of filename extension) as it opened. You can do a Save As operation (selecting a different script type and overwriting the existing file) to covert the script into a compiled script.
I’ll add that SD’s behaviour in this area arose out of my experience of users not appreciating the meaning of
.applescript. I’ve had users complain bitterly to me that the filename extension should not matter - SD should do the right thing regardless of filename extension.
Over time, SD has become more and more forgiving of incorrect filename extensions. More so than Apple’s Script Editor.
I’m baffled by that opinion. Each file type serves a specific purpose and the file extension, whether .applescript, .scpt, .scptd, or .app, tells me at a glance the capabilities of each particular script. I don’t like surprises.
In fact, my choice would be for Debugger to warn me if I’m using an incorrect extension and offer to correct it for me. Maybe you need a new preference setting: “Allow loosey-goosey file extensions”.
As am I. Failure to use the correct filename extension is a user error.
I think Apple’s choice of
.applescript for text scripts was unfortunate and caused confusion for people new to AppleScript.
By now I wish I hadn’t mentioned the problem. I was tying to do Mark a favor and it turned into a big deal. But I love Script Debugger. I absolutely love ScriptDebugger. It’s my favorite software. Mark and Shane have done a fantastic job with it and I have nothing but complements for ScriptDebugger. If I had to guess for whatever reason I probably saved a compiled script in Script Debugger as a .applescript text file and something happened and the extension didn’t get changed. That could have been something on my Mac that caused the problem or ScriptDebugger. But in any case it wasn’t a big deal, not data was lost, and it was easily fixed. Long live ScriptDebugger and it’s creators
Sorry to have made such a big deal of your post. This has come up several times in the past and, as I say, I’ve been beaten up by some users in the past about SD’s failure to open misnamed scripts. The suggestion that SD should somehow alert users when there is a script type/extension mismatch is a good one.
I was worried I offended you somehow by reporting it. I guess I stumbled onto a sore spot for you. I will tread more lightly with file extension mismatches in the future ScriptDebugger is great, it’s that wild ASObj-C that drives me crazy. One day I think it’s so great and I do something I’d never thought I’d be able to do. Then the next day I struggle with ASObj-C only to find out many hours later that what I was trying to do isn’t possible in ASObj-C because of the way the bridge works. Now “that” can drive a person crazy. Inexplicable bizarre file extension mutations, that’s just normal computer stuff
I actually started a FileMaker pro database on everything I’ve ever done that worked ASObj-C. I record everything I used successfully: classes, methods, constants, … Thanks for all the many things you’ve done and keep doing.