Hello,
yep, any reasons for that behaviour?
Many thanks and greetings
opusfreak
The information in the list is populated by the script's Init function.
If the Init function cannot run, the information cannot be populated (and you can't do anything with the script), and the script is not listed.
It would still be nice if there would be some kind of indicator for scripts that failed to init/load. This topic comes up now and then for DO script beginners and even for advanced users it is confusing at times I guess. I got quite a list in there and it's really hard to to tell if you're just to dumb/tired to find the specific list entry you're looking for or wether a script is really not in there because it failed.
Since the list is sorted by script filenames but shows scripts by their internal name, it's also not clear where to look exactly if the list is longer than a handful items.
I try to help myself with some kind of external/internal naming schema, which works for me most of the time, but other script authors and people getting into this do not and then it can be challenging to locate the right entry (if it's there o).
I agree with tbone on this. I have also got tricked by it, and the difference between the filename and the script name has also mucked me up. But more important and constructive is first, making it easy to to see which scripts in the script addins folder have errors, and secondly, making it easy to edit and correct them.
Accordingly, this is what I would like to see in the Preferences list when a script doesn't run:
- The filename greyed out, indicating that the script is faulty (unfortunately the script name requires the script to run).
- No details on selection, and greyed-out 'About' and 'Config' (these three also require the script to run).
- Leaving only a working '&Edit' button so that the user can easily edit the script with the default file editor.
The flashing icon on the status bar and the error in the script log isn't enough information?
I turned on the status bar, which I usually have off to save real estate.
I turned on utilities panel for logs, and cleared all its entries.
I opened the Preferences panel at addins.
Then I opened a well-running script in the editor, changed function OnInit (initData) to function XXXOnInit (initData), and saved it — I'm very capable of making such silly typos along with countless other errors.
Result: No flashing icon or other change on my status bar, no error message in the log file, but the script disappeared from Preferences.
As for the log file, I've had things go wrong and only realised days later when the logs had all gone.
If the script doesn't even have an init function then it must be a script you are editing yourself. No one would release such a script for other people to install. So you know about the script and having a line for it in the scripts page would not tell you anything new, nor help diagnose the problem.
Perhaps it should generate an error in the log to help when writing scripts (I'll look into that today, and also errors for scripts that need a higher version).
If you're writing scripts then you definitely want the status bar or script log open tp catch other errors.
Actually, having looked at this properly now, the OnInit function is optional (and documented as such in the manual, which I'd forgotten).
If a script has no OnInit it will still appear in the list of scripts as long as it handles one or more events:
If it handles no events and has no OnInit, then it won't appear in the script list, and is assumed to not be an Opus script.
I think Julianons way of forcing a missing script by masking the OnInit function might not match real world scenarios. Trivial syntax errors, wrong file encodings, unexpected BOMs or incorrect file extensions are more common and lead to what this is about I assume.
The Prefs page was never intended to be the main route for script authors to design their scripts through - it's a way for users of scripts to install and manage them. If you're working on a script you should doing it through the /dopusdata/Script AddIns folder and you should presumably know the name of the script file you're currently working on.
I say, the prefs script page is visited more often by people who do the scripts! o) Script authors go there and manage they scripts just like users do, but they go there for other reasons as well.
To temporarily disable specific scripts e.g., because you think some might clash with what your are inventing right now or to develop, fix and test script config items. So this area is looked at by script authors much more often than by regular users, which (assumingly) place their downloads there and forget about them. I also use the "standard" ScriptWizard about dialog, which is part of many scripts and trigger script updates or uploads from there or to remove scripts from the list by renaming them to *.dis.
I do this from there, because the SW about dialog is a nice way to look what filename is behind a script, since you cannot see that elsewhere. I do not know what other people name their scripts and there are quite some creations out there for which you have trouble matching the script name to the file name.
We are drifting a bit here, but that script page has some more flaws actually, what I am thinking of is:
-
A multi column layout showing script name, file name and status.
Showing script and file name would totally clear up the current guessings regarding script name and file mappings.
It's quite often other peoples script I look into to give some help or discover how they did particular things, so knowing script name and filename is not something you always do and keep track of. -
Each column sortable so you also get very fast to the "failed", "unknown", "disabled" and "active" scripts via the status column.
-
Move the current information banner that pops up when clicking on a script to a static area below the column control.
That way the list would finally stop jumping around when selecting, disabling or activating scripts. -
Add a "disable scripting completly" checkbox, which does not affect current active/disabled status of scripts.
Right now it's not comfortable to deactivate some or all and re-activate only those that were active before when your tests are done.
Disabling scripting in general is required at times to track down issues or check "standard" behaviour to be able to give clear reportings.
Moving back and forth all the scripts is not really an option. -
Remember last selected script when leaving the scripts prefs page.
Currently it's no joy finding your current "victim" in a list of about 100 entries again and again. Especially if you work on config items you tend to open the prefs, search for script, open config, change things and leave the prefs to start over the next minute. After at least three times in a row this is quite inconvenient. -
I remember we once were kidding about a filter field to quickly search for specific scripts, I dare to say, we need that now. o)
With the new dialog system I expect a lot of new contributions, I already have a handful ideas alone, so there will not be less scripts in the future, the scripts page should adapt to that situation and make it easy for everyone to keep track of what's going on. If I'd be mean I'd say: "The script prefs page was not finished in v11", but I'm not mean of course. o)
Sorry for the wall of text, but this is something I wanted to tell you and the world in an appropriate situation for quite some time. o)
Thanks! o)
Holy sh*t, once posted this looks even longer! I must leave now. o)
Thanks for the suggestions. "Some" of them have made it into beta 6 
jon, this is very much nicer and user-friendly already. Just to be as difficult as I could, I again changed function OnInit (initData) to function XXXOnInit (initData), but this time the script was greyed out, with Status: Failed (methods). And I could still edit the script from the Preferences page. That's very good.
- But now there is a rather dangerous bug. When I hover over the icons at the top, I am told that:
Delete has accelerator key Alt+D,
Edit has accelerator key Alt+E.
They have been swapped around, however. Alt+E brings up the delete confirmation, and Alt+D opens the script in the editor.
Not all the buttons and accelerator keys are working yet — understandably — and the Alt+B shortcut is behaving strangely. (Also, shouldn't it be Alt+H to correspond to the question mark icon?)
- Then a minor disaster struck. Just to check things, I unticked one script and pressed 'Apply'. All the scripts went off!!! Then I tried, but failed, to get them back on, but after pressing various keys and doing various things, like restarting DOpus, they all stayed off. Eventually, I moved all their files to another directory, checked that the panel was empty, then moved them back — they had come back, but were still off. Then I pressed a few more keys, and they all magically came back on again. There is some problem here that I have not diagnosed.
2 sounds like you pushed the disable-all-scripts button (or its hotkey) at the end of the icons above the list of scripts.
leo, I've now found that the behaviour in 2 above is the result of another bug. The 'strange behaviour' that I mentioned of the Alt+B shortcut is that it highlights the 'Disable All Scripts' button. What I didn't realise is that it also 'clicked' that button, in such a way that when I unticked a script and pressed 'Apply', all the scripts were disabled, and I didn't know how to turn them on again. That means that there are actually three problems here:
A. Hovering on 'Disable All Scripts' informs the user that the shortcut is Alt+L, whereas in fact Alt+L appears to do nothing. The actual shortcut at the moment is Alt+B, yet it is supposed to be the shortcut of 'About'.
B. The action of 'disabling all scripts' should occur straight away, preferably with a confirmation dialogue. If nothing is done straight away, then unticking a script and ticking 'Apply' should cancel that previously chosen action and just disable the one script — instead, the previously chosen action is remembered and used to overrule the current action.
C. I've now found that the 'Disable All Scripts' button is a toggle (provided that you always click 'Apply' afterwards). This means that the button should change to 'Enable All Scripts', with a corresponding green tick icon, after all scripts are disabled.
But please do keep working on this new Preferences screen, because it is so much more useful.
The hotkeys are mixed-up. We'll fix that.
The disable-all-scripts button is highlighted when active, since it is a toggle button.
There are three conventions for the labels of toggle buttons, and Opus uses the one where the label always says what the button controls, and the state of the button indicates if it is on or off.
Some programs change the labels to indicate either the current state, or the state you will get when you push the button, both of which are confusing IMO as it's rarely clear which convention they are using and which state the option is currently in. On the other hand, if the label never changes, only the on/off state, then the convention is clear. (It's also how every other toggle button in Opus works and has always worked.)
Thanks, leo. That explains a great deal, and I hadn't ever realised the ambiguity about the two conflicting conventions.
As I expect you already know, the problem with shortcut keys is not confined to the Scripts page of Preferences. Some of the shortcuts promised in the hover-text seem to be missing or mucked up in:
Display --> Images
Favorites and Recent --> Favorites List, Folder Aliases, Labels, Label Assignments
File Operations --> Filters
Folder --> Folder Formats
Folder Tabs --> Tab Groups
Layouts and Styles--> Layouts, Styles
Toolbars --> Icons, Scripts, Toolbar Sets
Because this is all Beta, I'll make two further remarks:
- The shortcut letters are rather odd and unsystematic. For example, D, E, L and T are all used in various places for 'Delete'.
- It would be really nice if pressing the Alt key would bring up the shortcut letters near the icons, as in Word. After all, the point of a shortcut is to avoid using the mouse.
The recent changes to the script prefs page are Awesome 02 and quite unexpected, but I won't complain about the latter, thank you very much! o))
Some issues still there in b7 with remembering the last selected script, but given the great change, not something to moan about either. Will report issues in detail once I get down to testdriving and using the script page in more detail.
Hello all,
interesting exchange of ideas, really 
!
Is there any chance to include the new/some of the features already in Directory Opus 11?
Many thanks and greetings
opusfreak