Regarding v11.5.1

Hi o)

Thanks for this! If this works the way I think it does -> a new mega awesomeness from you guys! o) I suggested this some years ago and still have many usecases for this, just great!
To make sure we're talking about the same: It will allow me to parse files content on my own and display something from there in those new custom columns, yes? o)
Is this fully documented already or do I need to ask holes into you? o)

Thanks, one more time! o)

Yep, pretty much :slight_smile:

Just press F1... :slight_smile:

Did "F1" and clicked me all through, but got a question. o)

// scriptColData is a ScriptColumnData object. first check that this is the right column (it should be since we only added one) if (scriptColData.col != "IsModified") return;
In case I added multiple columns, why would OnIsModified() be called for other columns I added?
I guess this will occur, if I add another column in OnInit() and use the same method for both or more than one column in general.

But if I add a single column or multiple columns with each having its own method, the column name check is not needed - true or not true? o)

Thanks!

True, that was just there as an example.

Alright, thanks! o)

I noticed that a script column shows a single zero "0" for all files and folders until a value has been returned. Is that intentional?
What do you think about some kind of default value while no value has been returned? "Scanning.." or similar could be shown while no data got back yet.

Using script columns in combination with filter labels (working excellent!) is something which may lead to very "busy" machines. Do you have some suggestions on this?
I added a condition to stop the column method if the current path does not match, where I need these labels to be working e.g.

Thx! o)

Btw: The marked link in the documentation is wrong I guess, it leads to the Func object, not ScriptCommandData.


It doesn't do that here. Do you see the same thing with the example Is Modified column?

It's all done on a background thread, but what the script/filter does is up to you :slight_smile:

It doesn't do that here. Do you see the same thing with the example Is Modified column?
[/quote]
I could reproduce the "0" behaviour with my MovieDB Script, but only within Infotips
In actual columns I have empty cells until a valid value is shown.

Yes, for me it happens with the example IsModified column as well. I was not able to get a proper screenshot as those zeros show up and dissolve very quickly, but I managed to get at least one zero in the shot. Along the dottet line its all zeros for about half a second or so after hitting F5 e.g.


Maybe it's important to mention that I make use of some filter labels, the bold files at the top are created/accessed/modified within 1h e.g. and I'm always in dual mode, with the viewer pane open, no tree.

Are you in Flat View there as well?

No, this is details mode. Though there is quite a number of files in this directory, it happens as well if there are just 10 subdirectories or 5 files in a lister.
The zeros in the column disappear faster then, but they are still noticeable for a break of a second.

Ta. We should have a fix for this in the next beta.

Just tried multicol feature of v11.5.2 and I find it very sweet, thanks! o) What I feel a bit uncomfortable with is, how the script columns are referenced in general though.

If you have a lister which is using columns from a script and exit DO, rename the scriptfile and restart DO, the columns are empty and invalid, because DO somehow refers to the file(name) of the script. Shouldn't DO be pleased to find the columns in the renamed scriptfile, which has the same "data.name" as before?

When you use set columnsadd="scp:/", refers to "data.name" from OnInit(data), DO does not care about the scripts filename in this case and that makes life easy, as these commands will work as long as there is a script with and coming from OnInit().

What's the reason for the reference to the script's filename in the first example and shouldn't we get rid of it, if we can? o)

ps:
I'm thinking of renaming/replacing scriptfiles to try new things or use updated versions from the forum. If I'm correct, right now you would need to remove and re-add all columns affected in any lister, format, layout etc. if you change the filename of the script. I expect these script-filenames to be changed a lot when playing with good/old version and new/unstable or similar.

It's because columns are referenced internally as ID numbers, and the IDs are used as a lookup to an automatically assigned script GUID plus the column name.
If you rename a script it will get a new GUID and therefore the lookup table won't find it.

One way around this would be to allow scripts to provide their own GUID so that Opus wouldn't have to automatically create one. We'll look at adding that.

Maybe it's a good idea to have those script-names and things equally fine-graded as it is for columns right now?
For columns you have a property for internal script identification (name), a property for displaying (header) and a property for the menus when choosing (label).

For scripts and user-experience the "needs" are kind of equal it seems, as DO may need a property to identify the script (guid), a property for humans with something short to show up it in the prefs/scripts-section (label) and a shorter name for usage in commands and buttons (name). The latter might serve as guid already, cannot tell, but despite that static guid/name thing to keep functionality on rename, a general script label would also be nice for the list of scripts (to get a custom sort-order e.g.). A scripts name/id is not very friendly to the eye there in most cases. That lengthy description is perfect as it is now I think (visible on demand if selected).

I added a namespace to script filenames and "name"-properties to line up scripts in the prefs/scripts section and the "script addins"-folder.
That really looks sorted now, maybe you agree, but abusing the "name" property as a script-label is no good for script-columns, just like renaming their files.


The reason why I renamed all files and internal script names is because it got messy lately, if you add several scripts for testing purposes yourself or just download stuff from here.
I couldn't really tell what script does what just by looking at the name in the prefs, as they all were totally different. Apparently there's no style guide for naming scripts (yet? o), but by introducing these prefixes, I kind of feel more in control of what a script is for and why it's there.

A single script could add columns, commands and events, so categorising them wouldn't make sense, unless the same script could appear in more than one category (which is possible but could be confusing).

I'm not sure the categories matter most of the time, do they? Browsers have lots of extensions in a flat list and it has never seemed a problem. Maybe it would be nice to be able to filter the list by turning categories on and off, but I think it will be unusual for anyone to have so many scripts installed at once, and need to look at them so often, that they'll really need it.

Yes. o) Actually I didn't aim at convincing you on these categories or naming guidelines, sorry if that's the impression I gave.

My intention with these screenshots was mainly to emphasize the idea of that script internal guid-thing Jon mentioned. You simply don't expect scripts/columns to fail, because you changed the filename.
Also adding the possibility to have labels for scripts, to untie the internal name from the overview here again, would make this complete I think.

As said, I'm with you regarding categories or filters for the script overview. But who knows, some years from now, you build a script-store there? That scripting feature really is potent! o)