Renamer: PascalScript predefined variable request

azazell0 · 2006-07-10 11:00

Hi,

I'd like to start with that ReNamer is freakin' great, I use it all the time. It's just too good to be free. And yet it is Thank you.

However, there is one little thing I miss from the PascalScript part: a predefined array variable which contains ALL the files added to the project. There are occasions when the new file name can only be determined by looking at the other ones.

What do you think?

den4b · 2006-07-10 11:27

Hi azazell0, and thanks for you kind words

Now, to your suggestion... I had that idea before, but I was turned away from it. I could let people access the array of File Objects that represent the files table, but that would give users TOO MUCH POWER, so little mistakes could lead to horrible problems! Also, I could create an array of strings, and put paths for all files in the table, but that leads to potential performance and resource-related drawbacks, i.e. imagine the case when you have thousands of files, and paths can be upto 256 characters. And in most of the cases that array would not even be used. Maybe it would be better for you to actually re-create a list of files from the table, within PascalScript rule? I could add functions to scan directories... What do you think?

azazell0 · 2006-07-10 12:22

Denis Kozlov wrote:

I could let people access the array of File Objects that represent the files table, but that would give users TOO MUCH POWER, so little mistakes could lead to horrible problems!

Maybe you could add a procedure enabling access with the name EnableAccessToFileObjectsWarningVeryF___inDangerous. Or at least warn the user in the help file with big red letters. Maybe it's possible (I don't know Delphi too well) to create a wrapper object or function with restricted access.

Denis Kozlov wrote:

Also, I could create an array of strings, and put paths for all files in the table, but that leads to potential performance and resource-related drawbacks, i.e. imagine the case when you have thousands of files, and paths can be upto 256 characters. And in most of the cases that array would not even be used.

I can only say what I told before: just warn the user. Before the whole renaming process, you could also scan the rules if any of them actually uses this big array and only register it when they do.

Denis Kozlov wrote:

Maybe it would be better for you to actually re-create a list of files from the table, within PascalScript rule?

I'm not sure if I get you right, but as I see that'd require to build the whole string array again and again on applying the rule to each file. Now THAT'd be slow.

den4b · 2006-07-10 14:57

azazell0 wrote:

Maybe you could add a procedure enabling access with the name EnableAccessToFileObjectsWarningVeryF___inDangerous. Or at least warn the user in the help file with big red letters. Maybe it's possible (I don't know Delphi too well) to create a wrapper object or function with restricted access.

A bit of an overkill

azazell0 wrote:

I can only say what I told before: just warn the user. Before the whole renaming process, you could also scan the rules if any of them actually uses this big array and only register it when they do.

That would require complete parsing of the code, since the variable name for an array can be in text somewhere or anywhere else in the code, like: a := "here is a name of a FilesArray variable"...

azazell0 wrote:

I'm not sure if I get you right, but as I see that'd require to build the whole string array again and again on applying the rule to each file. Now THAT'd be slow.

Hehe It would be slow if you would be constructing that array for each file! But have a look at the sample script in PascalScript rule called "Initialize renaming code". With that template you could create an array of files once, and then just use it on every file... I think this is the way to go! So, should I add functions for scanning directories?

azazell0 · 2006-07-11 21:08

Sorry for responding late.

Denis Kozlov wrote:

Hehe It would be slow if you would be constructing that array for each file! But have a look at the sample script in PascalScript rule called "Initialize renaming code". With that template you could create an array of files once, and then just use it on every file... I think this is the way to go! So, should I add functions for scanning directories?

Yes, that would be great. Altough (probably because of my thin knowledge ) I still don't get why it's easier to create a directory scanning function than one that accesses the file list. (You don't need to document your file object list variable name - yes, it could be retrived by some tricky reverse engineering, but hackers know what they're doing anyway.)

den4b · 2006-07-12 11:51

I've added it

Download the latest development version: ReNamerBeta.zip

And then use this code:

var
  Files: TStringsArray;
  Scanned: Boolean;
  I: Integer;
begin
  if not Scanned then
    begin
    WideScanDir('C:\TEMP', Files, true, true, '');
    Scanned := True;
    end;
  if I < WideArrayLength(Files) then
    FileName := WideExtractFileName(Files[i])
  else
    FileName := 'NOT ENOUGHT FILES';
  I := I + 1;
end.

Code above will scan folder 'C:\TEMP' recursively (only once) and will assign filenames that it will get as new names to the files in the table...

azazell0 · 2006-07-13 15:37

Thanks! It works great, except... well, I'm not even sure it can be considered a bug, but maybe:

var
  Files: TStringsArray;
  Scanned: Boolean;
  I: Integer;
  j: integer;
begin
  if not Scanned then
    begin
    WideScanDir('C:\TEMP', Files, true, true, '');
    Scanned := True;
    end;
  if I < WideArrayLength(Files) then begin
    if i = WideArrayLength(Files) - 1 then
      j := 0
    else
      j := i + 1;
    FileName := WideExtractFileName(Files[j])
  end else
    FileName := 'NOT ENOUGH FILES';
  I := I + 1;
end.

This code switches the file list by one (each file gets the next one's name, with the last one getting the first's), and, as it can be predicted, results in n=WideArrayLength(Files) errors, probably because ReNamer can rename files only directly. Maybe it's a good idea to check the file list for such same-name errors, and if it's the case, rename the original files in two steps: first, to something like ~renamer~0000001.tmp, then to the target names.

Hope it helps. Thank you once again.

den4b · 2006-07-14 10:48

What do you achieve with your modifications? 1-st file will get 2-nd filename, 2-nd file will get 3-rd filename, ... and the last file will get 1-st filename, everything else from that point will get "NOT ENOUGH FILES" name. Why would you shift the names? Alternatively, you could simply switch the last and first items of the Files array, that would do the same job...

azazell0 wrote:

...as it can be predicted, results in n=WideArrayLength(Files) errors, probably because ReNamer can rename files only directly.

Now I'm completely confused :dead: . It will result in "Amount of files in the table" - "Length of the Files array" virtual errors, since exactly that amount of files will have a "NOT ENOUGH FILES" filename (if thats what you meant by errors). And what does "ReNamer can rename files only directly" mean? ReNamer renames whatever you tell it to rename, to whatever you tell it to rename to - is that called "directly", what is "un-directly" then? Thats why you have checkboxes beside files, so you can uncheck those files that collide, just before renaming, and do something else to them later...

Renaming in two steps sound very dodgy, what happens if temporary filename is also taken, or some error occurs, or something else happens... I don't think its a good idea.

azazell0 · 2006-07-15 08:49

First, this script is meant to be used on a folder without subfolders, with all its contents previously dragged to ReNamer. Therefore, there will be no files with NOT ENOUGH FILES name (it's left in my script because it's based on yours.)

If you've got the first column files, this script would generate the second column names:

cat.txt --> dog.txt
dog.txt --> mouse.txt
mouse.txt --> rabbit.txt
rabbit.txt --> cat.txt

Now, obviously you can't instruct ReNamer to simply loop over the elements of the list and do a rename from the first name to the second one (that's what I meant by 'direct renaming'), because the new dog.txt would overwrite the old one, there'd be data loss and nothing to rename. (ReNamer checks this and that's the reason for the errors.) However, the desired result is perfectly legal, because at the very end, there'd be no filename collisions.

That's why I recommended detecting this type of error (when there are no duplicates in the final list, but at least some of the new file names match the old ones), and when it's present, do a two-step rename (since there is no other generalized solution for that case).

This problem can arise with conventional (non-Pascal) rename rules, too. Suppose you have about a thousand files called data_0549.dat, data_0550.dat, data_0551.dat etc. You want to rename these so that they start with 1 instead of 549: data_0001.dat, data_0002.dat, data_0003.dat etc. It's obvious that after 548 there will be errors, and the two-step rename is the only generalized solution for this kind of problem. (Of course, you have to rename in two steps only the files that can't be renamed the direct way: for example, in the previous scenario you can rename 0549 to 0001, 0550 to 0002 ... 1095 to 0547, 1096 to 0548 without any problems. After it, however, you need to use two-step rename for the other files. It may be slow and have other problems, but it's the only way and renamer must be prepared for every rename-related issue. )

Edit:
Well, actually, if you just rename the files directly in the correct order, there will be no errors, because when you need 549 as the target name, it's already gone. It's a bad example (but still, ReNamer displays an error in the preview). So let us suppose that you have about a thousand data_0549.dat, data_0550.dat, data_0551.dat etc. files and want to rename them starting with 1001. There you've got your error

den4b · 2006-07-17 10:41

Not "direct" renaming will spell disaster some day. Because user will not be aware of that, whatever he sees - thats what he expects to get renamed, and if ReNamer says there are validation violations - then user should simply reconsider the rules that he/she uses. I'm strongly against temporary steps, since there are really a lot of things that can go wrong, and if they will go wrong - user will lost, and files may be lost as well.

There is always a workaround for problems like yours... Add "_" underscore (or any other character or sequence of characters that don't appear in the name) to every new name, thus, making sure filenames do not clash and ReNamer says it is "Ok" to rename. After renaming, simply remove the "_" underscore (or anything else that you have inserted) to get your desired filenames.

I always used underscores in my cases...
What do you think about that?

den4b Forum

#1 2006-07-10 11:00

Renamer: PascalScript predefined variable request

#2 2006-07-10 11:27

Re: Renamer: PascalScript predefined variable request

#3 2006-07-10 12:22

Re: Renamer: PascalScript predefined variable request

#4 2006-07-10 14:57

Re: Renamer: PascalScript predefined variable request

#5 2006-07-11 21:08

Re: Renamer: PascalScript predefined variable request

#6 2006-07-12 11:51

Re: Renamer: PascalScript predefined variable request

#7 2006-07-13 15:37

Re: Renamer: PascalScript predefined variable request

#8 2006-07-14 10:48

Re: Renamer: PascalScript predefined variable request

#9 2006-07-15 08:49

Re: Renamer: PascalScript predefined variable request

#10 2006-07-17 10:41

Re: Renamer: PascalScript predefined variable request

Board footer