I'm getting strange results when Copy follows Rename in the same button and would appreciate any help or advice.
I'm using a rename preset with *.jpg as ‘Old Name’ and {shootingtime|D#yyMMdd-T#HHmmss}.JPG as ‘New Name’, and the button I'm playing with is this:
Rename PRESET="Pics from camera" RECURSE FROM *.jpg
Copy MOVE RENAMEWHENSAME.
Anomaly 1:
With a single file as source (test.jpg) the button always fails with the warning: ‘An error occurred moving ‘test.jpg’. The system cannot find the file specified. (2)’. It seems that Rename is too slow to complete before Copy begins. Using @confirm between the commands I found that a two second delay makes it work – but I can’t see a way to program delays.
Anomaly 2:
I can't see why it's needed, but if I delete ‘FROM *.jpg’ in the first line, the second line of the script fails to work with source files that have already been renamed to the final form. (This might happen occasionally anyway, but especially so if item1 has made the button fail midway. You then end up with some source files that have been renamed but not transferred. You then need to reselect them and click the button again to complete the transfer).
So here are two questions for anyone that can help:
Is there a way to add a delay between commands in a button?
You'll confuse Opus by running things after a rename command since it doesn't update the list of files to work on between the two commands.
You may be able to work around the problem by creating a User Command which contains just the second line, then run that User Command instead of the second line.
That should work because User Commands effectively re-evaluate which files are selected.
Also, if you are moving files around on the same device then you can do everything within just the rename command by including \ characters in the new name. That won't work if you're moving across devices though, since you cannot rename a file from one drive to another (you have to do a copy-then-delete instead).
It shouldn't be required and probably isn't doing what you want, either. If you use FROM *.jpg then the Rename command will completely ignore your file selection and instead rename all the *.jpg files in the current folder, whether they are selected or not.
If you see the Rename dialog when running the command, instead of it applying the preset without showing the dialog, then please post a screenshot showing what the rename preset does.
Thanks for the thoughtful response. Hadn't noticed the User Command before so will look into that tomorrow. (Have to go out tonight, grrr).
By the way you're right about a delay not working. I realised I could use a *.bat file to add a delay but it didn't help, whereas using @confirm does.
The reason I felt I ought to be able to this was a review of DOpus8 at monroeworld.com/reviews/dopus8/7.php. Quote [my italics]: "There are two things that make copying and moving easier in Dopus. First, during the operation, you can rename them on the fly. This is useful if you are copying generic files from one device to another (like from digital camera media) and need to rename them as you copy - file by file - "
The FROM issue remains mysterious. The effect of it was definitely repeatable. Later I changed to this to eliminate any possible complications from using a Preset. It behaves the same as the previous version with Preset and FROM included.
Rename FROM *.jpg TO {shootingtime|D#yyMMdd-T#HHmmss}.JPG FILEINFO RECURSE
Copy MOVE RENAMEWHENSAME
I'm puzzled that *.jpg in 'Old Name' in the preset didn't eliminate the need for FROM *.jpg in the script
I need to include *.jpg in at some stage because I don't want it to accidentally rampage thro' non-jpg files if/when I select them by mistake.
Regarding 'the Rename dialog [appear] when running the command, instead of it applying the preset without showing the dialog...' - I've never seen this, so no problem there.
Another thing that's bothering me is that my current rename button is fatal for files that have no camera data in it. It deletes the name and leaves just jpg'. Can't yet see any way to trap this out.
I've put the line Copy MOVE RENAMEWHENSAME into a User Command as you suggested making the button:
Rename FROM *.jpg TO {shootingtime|D#yyMMdd-T#HHmmss}.JPG FILEINFO RECURSE
Upload_from_cam.
This gives the error every time as before, but calling a 2-second delay between the two commands makes it work about half the time, and with a 3-second delay it's worked every time so far. (This is using the same two jpgs each time).
So this is the command that works:
Rename FROM *.jpg TO {shootingtime|D#yyMMdd-T#HHmmss}.JPG FILEINFO RECURSE
C:\Documents and Settings\DT\Desktop\delay.bat
Upload_from_cam,
and the bat file contains
@echo off
ping -n 3 127.0.0.1.
Feels like a bodge, but at least now it's working. Thanks for the advice.
Hmm, I guess the problem is the Copy works based on the lister's file selection, and the lister takes a moment to see that the files have been renamed, so that's why you need the delay... Bit of a pain that.
You can copy-and-rename files in a single command, but I think only using basic wildcards. It's only the Rename command that will let you insert the camera date into the name.
Perhaps the only safe way to do this is to write a VBScript rename preset which does the file copying, but maybe that isn't worth the effort. The simplest thing to do would be make a three-button where the left-click does the rename (with a @nodeselect) and the right-click does the copy. Then you left-click the button, wait a moment until it's all done, and right-click the button. Not as nice as a one-click solution but very easy to do and still pretty speedy.
It'd be nice is all the file information fields could be used with the Copy command and not just the Rename command. Might be worth filing that as a feature request to GPSoft.
Actually, running things after a rename command should generally be ok, except in some cases where the command parser can get confused.
Your first problem was caused by the FROM *.jpg argument to the Rename command. As Leo explained, this makes the Rename command ignore any file selection in the current Lister, and work on all JPG files in the current folder. More seriously, however, this also "detaches" the Rename from the other commands in the button, meaning they won't know about any changes made by the Rename command.
The solution is to either a) take out the FROM *.jpg, or b) add the *.jpg to both commands, so they are both working from the same point-of-view.
For example, I think you'll find that the following works fine:
Rename PRESET="Pics from camera" RECURSE FROM *.jpg
Copy *.jpg MOVE RENAMEWHENSAME
Similarly, you could take the *.jpg out from both commands and it should still work. The important thing is that both commands are working from the same set of files.
(nb: there is an additional complication without the *.jpg as you've discovered - any files that didn't get renamed are excluded from the copy command. This is because when they don't get renamed they are deemed to have "failed" and so no further action will take place on them. This is actually part of the design of the Rename command, but it does cause problems in multiple-command situations like this so I'll look at possibly modifying this behavior.)
There is a known problem with User commands mixed with the Rename command - the User command doesn't inherit the knowledge of renamed files and so rebuilds its file list from the Lister directly, which may not have updated in time. This will be fixed in the next version.
Jon,
Thanks to you and Nudel for analysing the problems in the original post so carefully. It's great to have such effective support
The version below works nicely (apart from the niggle with {dlgfolder} that I raised in [Apparent Bug In {digfolder})).
I'm not quite sure if 'the known problem' accounts for both of these or just for the delay, but to work, it definitely seems to need the delay and to have COPY separated off into its own User Command. Anyway I'm happy to leave it for now, and revisit after the next revision of DOpus.
Set DEST=Right
CreateFolder NAME {dlgfolder|Choose folder for the pictures|/mypictures{date|yyyy-MM-dd} add title} READAUTO=dual
Set TREE=On,Dual
Go REFRESH=tree @confirm Rename and transfer files?|Yes|No
Rename FROM *.jpg TO {cameramodel}{shootingtime|D#yyMMdd-T#HHmmss}.JPG FILEINFO RECURSE @runmode min
D:\My Documents (DAT)\Batch and Search Files\3s delay for Dopus.bat
Upload_cam_to_My_Pics
(Upload_cam_to_My_Pics contains: Copy FILE "F:\DCIM\100CASIO*" TO {destpath$} MOVE RENAMEWHENSAME).
You're right - I was a bit dim there. I'd missed that the 'known problem' only referred to the case where you mix User Commands with Rename. (Well, it was the end of a busy day...).
Anyway I've confirmed that these two examples work fine:
Rename TO {shootingtime|D#yyMMdd-T#HHmmss}.JPG FILEINFO RECURSE FROM *.jpg
Copy *.jpg MOVE RENAMEWHENSAME
Rename TO {shootingtime|D#yyMMdd-T#HHmmss}.JPG FILEINFO RECURSE
Copy MOVE RENAMEWHENSAME.
I prefer the second because I can select a subset of pictures for download and leave the others in the camera. However it seems I have to lose this feature if I want Rename to put the renamed files into a folder based on Camera Model. The example below renames into the new folder but, while only the selected files get renamed, Copy obeys the wild card and all files get moved. Yet without the wild card, Copy fails with a 'can't find file' error.
Rename TO {cameramodel}{shootingtime|D#yyMMdd-T#HHmmss}.JPG FILEINFO RECURSE
Copy * MOVE RENAMEWHENSAME.
So this isn't much use and it's better to add FROM *.jpg to Rename. Then it works on all jpgs in the camera and they're all treated equally.
