I've just posted a non-optimal update to my HashCompare script that attempts to give a quick and dirty way of comparing the hash values of two selected files (this was suggested in the script thread a lite alternative to using the dupe finder tool for two files).
In normal use in a lister - I thought calculation of checksums for files were fairly 'smart'. Where if you (for instance) have the hash column enabled, subsequent explicit Clipboard commands to get the hash into the clipboard run very fast because it's pulling the value from wherever populating the value in the columns caches it...
I was hoping I could benefit from the same inside a script... but based purely on the TIME it takes for my result dialog to popup AFTER running FSUtil.Hash following a previous Clipboard COPYNAMES command - it's not.
I posted it to the forum anyway - since the default behavior compared to how the thing used to work remains unchanged... so it won't bother people that only use the old feature to compare against a hash in the clipboard, and for people comparing small files - the double-calculation of the hash it won't be very noticeable.
That said - my question here is two-fold:
Can you pull the hash value from someplace in cache from a command.RunCommand("Clipboard COPYNAMES") call so that it returns immediately on a subsequent FSUtil.Hash() call to simulate the efficiencies of lister columns seeming to do the same for subsequent Clipboard calls?
I'll admit that the only reason I'm doing the Clipboard COPYNAMES call in the first place is because it gave me an easy PROGRESS dialog to display the progress of the hash calculation with while the TWO files hashes were being calculate in one RunCommand against both selected files... I'm not sure how to manually update a totally custom Progress dialog by running everything. The reference suggests all those Methods in the Progress object are meant for that - but do you have an example how I would combine the use of something like those methods so that I can both (a) show an overall progress of hash calculation and (b) still be able to store the hash for each file in a variable so that I can then compare them to provide a result? Would I have to run separate RunCommand("Clipboard COPYNAMES") calls for each file or something, and GetClip in between commands? Seems real klugey...
FSUtil.Hash won't return until the hash has completed, so there's no opportunity for a script to report the progress of it (since it does not report progress to the script in any way, until completion).
You could do it by implementing the hash algorithm in the script itself, and not calling FSUtil.Hash, but that might slow things down and would be a pain to do unless the code is already out there somewhere.
You could, but you'd only be able to show 0% (before any files have been done), 50% (after the 1st file), 100% (after the 2nd file).
The progress object is intended for scripts to report progress as they do things, not for changing how internal commands report progress.
Normally you'd run both commands as part of a single Command object, but obviously that doesn't make sense in the special case where you need to examine the clipboard between each command.
Hmmm... I get the sort of lack of per-file progress you just mentioned (0%, 50%, 100%) when running a single command (Clipboard COPYNAMES) against both files in a single RunCommand though?
I've made some changes and will post it it as is like this - but do you know why I'm NOT getting incremental progress indication with these settings for the progress object?
...given that both files are being calculated in one call to RunCommand, is there some other combo of properties/method use for the progress object that would yield the desired result?
With the same settings above (besides 'full progress' set to False) with a single file in the command, I get the granular progress indication I'd prefer with multiple files.
Since I get what you described with a SINGLE RunCommand call, I wonder if I try to break the hash calcs into separate RunCommand calls like I asked about - if I get what I'm after.
Nah - that didn't work. I guess you were describing using the AddLine method to run a command against each file?
But that gets executed by the Run method... I don't see where you'd ever have any indication to know when to use the various progress object methods to manually update progress, filenames, etc?
Are there any examples I could hack around with to better understand how to use it?
Odd too (and fortunate - since it provides the visual cue that things are still moving along) that the progress indicator BAR actually shows the per file progress even though the percent ticker in the progress dialog TITLE does NOT..........?
Is it a bug? Everything else updates (current filename changes on it's own, progress BAR updates sensibly), just not the percentage total in the title?
If you are making your own progress dialog, its your responsibility to tell it when to update the per-file progress. I don't see that in the code snippet above.
But wait - in my mad dash to try and change my outcome - I've gone back and forth. What I'm currently asking is for clarity on 2 things:
ONE:
with a SINGLE file in the command object, and a command string for RunCommand of 'Clipboard COPYNAME=hash3' --- a progress dialog with the same settings above (except for objProg.SetFiles = 1) shows incremental percentage changes in BOTH the BAR progress BAR as well as in the title as the hash is calculated for the single file. It also shows the name of the file... all without me having to explicitly populate any of that info.
with TWO files in the command object, and the same command string for RunCommand --- progress dialog with the same settings as above (now with objProg.SetFiles = 2) shows incremental percentage change in the progress BAR, and even updates the current filename as the first file finishes and second one starts... but the incremental percentage change in the TITLE follows the same 0/50/100 behavior we talked about.
The bug question is... with a single command object and a command being run on two files, why isn't the dialog able to show the percentage progress in the title when it otherwise seems to understand per file progress in othger parts of the dialog (progress BAR, filename updates, etc). I thought maybe un-commenting objProg.AddFiles 2, (objFile1.size + objFile2.size) wouild give the dialog a total size against which to measure overall progress, but that didn't help. With objProg.full = True, the second overall progress bar does indeed follow the same 0/50/100 update steps... so maybe it's just a happy accident that the other parts of the dialog update in a desirable way.
TWO: you said you didn't see any code in the snippet above for updating things myself. My question to that is:
in what situation (example) would I even be able to update the progress myself if I'm doing an operation involving multiple files? How would I even get progress of a SINGLE files operation to display in the dialog while Opus is performing the operation, never mind become aware when Opus begins operating on the ~next file?
Some of my difficulty is maybe trying to shoehorn the use of this progress dialog with the Clipboard COPYNAMES command? What if I was doing a Copy operation, or something else?
Use progress dialogs where your script controls everything and wants to report the progress of what it does. (Example: A script that reads a file 64KB at a time can update the progress dialog after each 64KB is read.)
Custom progress dialogs don't make sense with scripts that just run internal commands (unless you only want to show overall progress, updating between each command, and not per file). (Example: A script that calls a function or command which processes the whole file before returning has no opportunity to set the per-file progress.)
Well then I guess I'm inferring intent where there was none then... and it tracks with what you said:
[quote="Leo"]The progress object is intended for scripts to report progress as they do things, not for changing how internal commands report progress.
Normally you'd run both commands as part of a single Command object, but obviously that doesn't make sense in the special case where you need to examine the clipboard between each command.[/quote]
But if that is the case - I don't think it really made a whole lot of sense to bind the Progress object to the Command object then, which otherwise exists to let scripts "run Opus (internal) commands". And my latest attempt is indeed running both commands (well, still just a single command) in the single command object like you said above. So I'd have thought I'd get what I expected as far as overall progress indication in the title.
I'd say it may as well have just been a DOpus method like Dlg or something. Though we do otherwise get exactly what I want with a SINGLE file operation, so maybe that's just a happy accident?
That said... this whole conversation really boils down to "per file progress" and "overall progress" control in a multi-file operation scenario... If not a bug, since a command like 'Clipboard COPYNAMES' against a SINGLE file seems to report the calculation progress of the file towards the custom Progress objects percentage counter, could you consider it a feature request then to allow the Progress object to work as follows?
Given that:
multiple items in the command object
the TOP progress BAR in a full progress dialog clearly understand "per file progress" for each file as it's processed
the script specifies a total size for the overall operation (Progress.AddFiles with file count and total size (item1.size + item(n).size))
...then it would seem the Progress object would have access to everything it needs to show proper total progress of the overall operation as it process each file to both the Title percentage counter AND the full progress bar (top bar shows current file, bottom bar shows total progress for overall operation).
To be clear - the whole progress dialog part of this is obviously just a cosmetic thing that would be 'nice' to benefit from some refinement around. So, hardly a burning need or anything. Just seems tantalizingly close to having the plumbing needed to 'just make it work'.
As far as getting the hash value for comparison purposes, while I still think it would be great if hash calculation betwixt 'Clipboard COPYNAMES' and 'FSUtil.Hash()' were cached, I settled on just using the Clipboard command a single time on both files - and then split the results for each file on vbCrLf to get them separated into different vars. This is fine, and not horribly klugey since I'm controlling how much gets put in the clipboard by limiting the files in the command object to just 2.
But it's not ideal since I try to preserve whatever is in the clipboard before my script does it's work - then set it back to original state post-script. But this fails if there is non-text in the clipboard (i.e. if they've copied a big file to the clipboard to paste it into a folder before performing my comparison). VBScript naturally pukes over my attempt to save binary data into a var in the script . So since I have to use the clipboard to get my values for comparison purposes AND some bit of progress dialog, I have to trash whatever is in the clipboard before my script runs.
.
. So since I have to use the clipboard to get my values for comparison purposes AND some bit of progress dialog, I have to trash whatever is in the clipboard before my script runs.