Under normal circumstances Settings --> Preferences --> Scripts displays a window listing all available scripts.
However, if the "Events" VB script generates an error, the list of available scripts is blank and other weird things happen, specifically:
[ul]An attempt to open a selected file via the context menu or button with (for example) Notepad fails. Nothing happens.
Exiting Opus appears to work (icon disappears from system tray) but dopus.exe still shows up in Windows Task Manager and has to be manually killed.[/ul]
I triggered this by adding a code fragment to Jon's Example Event Script. The demo code shown below works. When a lister is opened it simply displays a pop up message box with the name of the layout, or blank. If you comment out the Msgbox statement and uncomment the error generating Call statement the Call MsgBox script error is logged in the Script Output log and the problems I have described manifest themselves, at least for me.
[code]' Called whenever a lister is opened
Function OnOpenLister(ByRef OpenListerData)
' Display the name of the layout (or blank)
Msgbox(OpenListerData.Lister.layout)
' Call MsgBox "Hello world"
I can't reproduce any of this unfortunately. Modifying the script as you describe causes that script to not appear in the script list (because its parsing failed) but none of the other symptoms are apparent.
I tried again with a vanilla Opus 11 configuration in a VM and, like you said, none of the symptoms were immediately apparent. However, with the broken script in place in the Script AddIns folder I shut down and rebooted and the symptoms returned. From further experimentation the symptoms also manifest themselves (for me) after exiting and restarting Opus with the duff script in place.
Wow, I've had multiple levels of breakage as a result of my script hackery...
Depending on how badly I write a line of code, I've had a few of the problems you've described here... as well as much worse breakage. In one test, after probably already destabilizing things and not being able to get drag-n-drop to accept scripts, and then MANUALLY copying in test scripts... just one line of code that did an if check on a .result property caused really bad breakage. I could navigate around listers normally, buttons worked ok, but there was no response to some keyboard keys. Notably, I couldn't delete ANY files - not even through the RMB context menu. I had to resort to opening a CLI prompt in order to do a del of the file before then exiting and restarting Opus (needing to also kill the process).
Moral of the story: write better code or write some batch files to do some script file and process cleanup between tests...
A bit concerned that we might see hackish scripts being shared with others that may FUBAR ppl's Opus
FWIW: the if check I was talking about that caused the inability to delete files was simply an un-encapsulated reference:
if afterFolderChangeData.result
...without parentheses. But of course, reverting to this syntax once I've restarted everything and things are working properly only generates a parsing error on d-n-d, it doesn't repro the breakage I mentioned. Like I said, I think I had already gotten the interface into a funky state through other goofs, but then this one broke it good as a bonus. Weird... but probably has to do with why you couldn't break things as bad Jon simply by adding a faulty line of code. I think you have to already have had some other issues and things get ~increasingly unstable. If I can find a way to reliably go from stable to super-unstable - I'll chime back.
or write some batch files to do some script file and process cleanup between tests...