IDEA: Drag Drop renamer

[skwire]

I was using "move".

-magician62 (November 05, 2018, 07:25 AM)

Are you moving them to a different drive?  If so, that's the same thing as a copy and will typically take longer than moving files to a different location on the same drive (which, as 4wd mentioned, is just renaming the file).

[magician62]

Files have no need to move. Rename is in same location.

The code used is

[Select]

# DND-Rename.ps1
for ($i = 1; $i -lt $args.Count; $i++) {
Move-Item $args[$i] ($args[$i] -replace "(\.[^.]+$)", "$($args[0])`$1")
}

[magician62]

Have encountered an occasional issue with larger batches.

Though have not been able to narrow down. The number of files it will process seems to vary I started at 1000 error. Stepped down to around 300 error, then dropped close to above 255, worked Went back to 400, worked.
All filenames are of the same length.

Now it gets weird. The time taken for similar size batches is varying quite wildly, so something else must be going on.

[Ath]

You could try to disable your antivirus... that is usually adding a lot of unpredictability to Windows' responsetimes.

[4wd]

Windows has a command line length limit.

Dropping too many files on it at once can exceed that limit.

But seems weird that it disallows then allows the same number.

Not sure whether Windows will break it into multiple commands.

[magician62]

Windows has a command line length limit.

Dropping too many files on it at once can exceed that limit.

But seems weird that it disallows then allows the same number.

Not sure whether Windows will break it into multiple commands.

-4wd (November 05, 2018, 04:38 PM)

This is what I was finding weird. I had expected I could drop the number to a point which would give me a clue. But to then accept greater numbers made little sense. The only thing I could think of was something interrupted the process. I will just have to make sure I don't try and rename too big a group

Accepted, it's not a perfect solution, but it has proven the concept works, and although it can be quite slow on larger batches. I would say having all the species in one screen does allow for a general increase in speed and easier processing.

The biggest time consumer is creating the shortcuts and setting icons.

I got the shortcut creation time down  creating a text list of all the species, prefixing with underscore and replacing spaces with underscore. Then prefixing the whole lot with the command. I then duplicated the shortcut 150 times renamed to species and finally properties to change the command inside.

I still have to finish the icon side

The concept will work for just about anything I want to add.

I also suffix with location, so have used the same technique for that too. Saves having to open a renaming program and select to create a rule for the change.

I can see a full fledged drag drop with creation from a data list would benefit those who predominantly use a mouse. 

All i need to do now is figure the best way of handling which camera in the filename.

[magician62]

Well it worked for a while.

Big issue was the number of files/speed.

When I had more than 1000 files it was far quicker to use alternative renaming utils, due to needing to submit 4 batches or more, but alternative methods did put at risk consistency.

Changing the shortcut as the appended name part evolved, was quite tedious, with over 200 different choices.

Over recent days, many of the shortcuts have failed to work, though they look identical format when propertied. My initial thought was use of () or{} brackets, but even [] which I had originally used has become an issue  Windows 10 is preparing for the fall up[date, I wonder if it has messed with this method.

I did use KodeZwerg's Shortcut Tuner  to tweak the Targets, maybe that has had an impact on this type of link.

Though even starting from scratch seems to have a problem, check it is not the AV. SO in effect back to square 1

[magician62]

OK, I believe I have identified part of the issue why it wasn't working as expected.

After using the suffix format "_Species_Name" I found it became cluttered, so tweaked it to _(Species_Names) which improved readability.
I also used the same technique to append the Location before the species name using "_(Location). Again it worked well, but didn't provide enough separation from "_Species_Name" so I decided to change the type of brackets fro Curved () to Square [], and that is when it all went wrong!

It looks like you can have a multitude of curved brackets, but as soon as you add a square bracket, no further additions will work!

Valid
_(Species_Names) _(Species_Names) _(Species_Names) _(Species_Names)
_(Species_Names)_[Location]
_[Location]

Not Valid
_[Location]_(Species_Names)
_[Location]_[Location]

Obviously, you wouldn't have two locations, but it does illustrate the issue of bracket type, thus limiting the methods usefulness

Also You can use Curly bracket {} but I can't tell the difference between curved. You can not use greater or less than <> either.

I assume this is down to the way Powershell works?

Maybe an AHK driven interface is the way to go in the long run, to make the whole thing faster and easier to configure for different uses using "profiles". Unfortunately I lack those skills