Ok, look at this scenario: You need to get some info from metadata of an audio file to do some stuff. Right now you just can use a rename script trick to do that, and that sometimes is not pleasant as it should be, or you need to make some changes to a string or another scenario when you need to receive info, process it, and then return it.
So I think in a new way to do this things in Dopus: Functions.
Functions will be like actual commands, someones can be built-in, and the user wil also can create his own.
The use and sintax could be very similar to vbscript, and can get parameters and always return a variable (byref can be implemented also).
So in the command you can do something like:
@set artist=getArtist(FileName)
where getArtist is a predefined Function. Can you imagine how that useful could be?
Any impression is welcome, so please drop here your suggestions and ideas(even if you think this is stupid). maybe the DOpus team can implement this in v11.
Hopefully...
Sure, it would be incredibly useful. But this one little statement has a huge implication. You're essentially suggesting that GPSoft implement their own custom programming language and runtime environment. That's not trivial... and is something I believe they've said in the past wasn't likely to happen.
I make fairly good use of the ability to abuse rename scripts to do things I can't do natively in Opus. And I'm frequently a bit frustrated with the limitations involved in using this technique. I think something that would give us much more capability withOUT requiring GPSoft to implement their own entire programming environment, would be to just greatly expand the scope of the inputs and outputs that are possible using the same technique currently used for the rename script stuff.
What I mean by this is, I'm happy to continue using vbscript, or jscript, or perl or whatever... It would probably provide a more robust set of options for handling data than would likely be the case if GPSoft were to implement their own native system. But either way, I don't think the thing that would be most useful is dependent on pre-defined vs custom "functions" one way or another. The REAL trick to giving us more functionality is Opus allowing the use of a richer set of variables to pass file data/metadata into the function. As abusing rename script functionality has proven, once you've got relevant data to work with, you can do whatever you want inside the script itself. The trick is pulling relevant data INTO the script, and then doing something useful WITH the data once you've processed it in your script.
So, being able to define your own custom 'functions' still wouldn't get you very far unless Opus expanded what data you could pass INTO a function. That's the first half of what would be needed to make the scripting capability much more useful. I think the other half is then allowing you to RETURN data from the function back into the normal scope of the button, hotkey, whatever - in a way that could be used in normal internal Opus commands. In other words, if I could set FUNCTION specific OUTPUT variables to some value, then reference those variables as if I had set them using @set in the button itself, then I'm open to lots of possibilities that don't have unwanted drawbacks - like resorting to dopusrt.exe results in... The obvious example being, I can then most likely do Opus "undo" operations against proper Opus internal functions called within the button/hotkey/etc; unlike what happens if you call dopusrt.exe to do "stuff" with the files...
I'm about 12 pints in... so maybe not thinking all this through rationally or explaining my opinion very well. Guess I'll read this back to myself in the morning .
We may expand where and how you can use VBScript (and other ActiveScripting languages) within Opus in the future. That's the best path to get this kind of functionality, and will be more robust & open-ended than adding more to our custom command stuff (although we might add some more things to that as well, if it makes sense pragmatically; but not function calls, they belong in proper scripting/programming languages, which are on our long-term roadmap).
Right, basically what I was describing... I think the details will matter of course. Right now, for what data is pulled in from the files being operating on by the rename function(s), its sensible to only pull in strFileName, strFilePath, fIsFolder, strOldName, and strNewName as a starting point. I wonder if you'll devise new functions - with other specific inputs / data types you'll automatically pass the data in for based on the function-type. In other words, maybe a function that specifically pulls in file attrs, maybe another for media-based metadata, etc.
I think that'd be fine as long as we could run a function against selected items... work with whatever data that particular function exposes and exit, have access to variables back out in the parent button code for use with normal Opus commands, and then potentially still run 'other' functions against the file. Otherwise, as a catch all it might be nice to have sort of a 'super-function' that you could send in a large collection of file attributes, and metadata. Without one or the other - we might find ourselves limited as far as being able to work with different types of data that you might have otherwise separated out and only make accessible in specific typed functions.
Some thoughts from the peanut gallery...