Suggestions from Andrew

Andrew · 2008-08-12 17:31

Just a few suggestions for ReNamer...

1) If the filter settings are as follows:

then both files and folders are added to the list. Now if we sort by some column, then the file and folder names get mixed up. I couldn't find a way to separate files and folders again except by emptying the list and re-adding everything. Sorting by extension, size etc. works, only as long as no file exists that isn't 0 bytes in size or has no extension. If such a file exists, then it gets mixed up with the folders too.

So I propose a "sort by file/folder" option in ReNamer.

2) WideScanDirForFiles() and WideScanDirForFolders() seem to return the files/folders in order of creation on disk. Is there some way they could return a sorted list?

3) Similarly, when the above filter settings are set, then the files/folders are added from "outside to in", in order of creation. So if we have A\B created first and then A\A, the file list will show:

A
A\B
A\A

Now the problem is, we cannot rename all these folders according to a single rule as it will only rename A and then fail, since now A\B doesn't exist. So how about an optional "inside to out" order such as:

A\A
A\B
A

so that we can freely rename the inner folders and at last the outer?

4) Can we have a global boolean PascalScript constant that is set to True by the program if the Rename button has been pressed, and to False if the Preview button has been pressed? The problem is that FileReadLine(), FileAppendContent(), FileWriteContent() etc. run every time Preview is pressed, which may not be what the script author intended. Popping up a confirmation dialog every time is not the best solution and is irritating. Instead if we can simply have something like:

if(RENAME) then          // or if(RENAME == true) then
begin
  // code to run *only* during actual rename
end;

eR@SeR · 2008-08-12 19:49

I just want to ask you why you've opened new topic, when you have your own created already with similar name??? ReNamer Suggestions and Queries :|

I'm asking you to move your suggestions there or somewhere else. Thanks

Last edited by eR@SeR (2008-08-12 19:50)

krtek · 2008-08-12 20:47

According 4th suggestion...
First of all I think it's worth mentioning that it showed up in following topic:
http://www.den4b.com/forum/viewtopic.php?id=489&p=1

I think it is a really nice idea. But I guess it has few drawbacks.
The problem is that when you click Preview (or use autopreview) ReNamer makes a map of old names-new names. And when you press Rename, program uses that list to rename files WITHOUT building it again.
Forcing building the list when you press Rename is out of option because you may want to make some adjustments to new names produced by your set of rules and they would be destroyed by that forced preview before renaming.
So making that suggestion come true will need changing the way Rename operation works.
I can see two options:
1. When you press Rename ReNamer (apart of renaming files according to files table) checks all your PascalScripts seeking for special part of the script and executes it. The question is, should it be done before or after actual renaming.
2. We could have a special rule for storing user requested data (eg. counters) which would not affect preview operation, but would be executed during renaming...
But this would need some kind of communication between that rule and other rules (like scripts, serialize etc.) to retrieve needed variables...

Any other ideas?

Last edited by krtek (2008-08-13 17:46)

eR@SeR · 2008-08-12 22:28

krtek wrote:

I guess it has something in common with a general request for not mixing few problems in one topic.

Can you make this more clear?

den4b wrote:

Anyway, I strongly agree that topics should have proper/descriptive subjects, so users can have at least a clue on what the topic is about just by reading its subject...

As you/I quoted Denis and he said on the other way than me. I cannot see what is ambiguously?

Create NEW topic with specific title and no problem. As I said, the title of topic is same as "ReNamer Suggestions and Queries" just without "and Queries".

This topic is too General: you have numerous suggestions... I hope that you get me?

Andrew · 2008-08-13 10:58

First of all eR@SeR, it has already been mentioned by krtek what Denis and Stefan have already told me about opening a new topic for every suggestion/suggestion group (see also http://www.den4b.com/forum/viewtopic.php?pid=2206#p2206 for more). I wholeheartedly agree that the topic title could have been more descriptive, but seeing as how the suggestions/queries were not all connected, I just couldn't think of a title that would describe them all.

Thus your suggestion of including these new points in that old topic of mine is totally the opposite of what others have told me, which is really confusing. I plan to go with what Denis, Stefan and krtek have said and will keep these new points in this separate topic without merging them with the old, as - i) they are not connected at all, and ii) the new points would likely be ignored if I kept adding to an old topic. Hope you understand my point of view and also what krtek has said above. Now as krtek rightly pointed out, let this off-topic discussion end here and let's move on. If you guys want to delete your off-topic posts here, please feel free to do so so that we can focus on the points raised.

Now on to the actual topic at hand...

krtek wrote:

BTW, according 4th suggestion...
First of all I think it's worth mentioning that it showed up in following topic:
http://www.den4b.com/forum/viewtopic.php?id=489&p=1

Yes, it was mentioned there somewhat, and I guess by me! That topic gave me the idea for this suggestion and since that topic wasn't in the Suggestions forum section and wasn't a good place to propose a new feature, I included it here in this new topic in the correct forum section. Hope that clears all doubts!

krtek wrote:

I think it is a really nice idea. But I guess it has few drawbacks.
The problem is that when you click Preview (or use autopreview) ReNamer makes a map of old names-new names. And when you press Rename, program uses that list to rename files WITHOUT building it again.

Hmm... To test this, I wrote the following very simple PascalScript:

begin
  FileName := InputBox('Input', 'Enter any word', '') + '_' + FileName;
end.

It should ask the user to enter a word for each file and rename that file by adding that word to the filename.

On adding a few files and pressing the Rename button without pressing the Preview button first, I got this error:

If I Preview first, then it's ok. If I save it as a preset and run it from the command-line, then also it is ok. So if it can run from the command-line (where no preview has occurred), why can't it run when I directly press Rename before pressing Preview?

Anyway, I think the script proves that ReNamer first builds the new name list and only then actually renames the files, even if there are scripts present.

krtek wrote:

Forcing building the list when you press Rename is out of option because you may want to make some adjustments to new names produced by your set of rules and they would be destroyed by that forced preview before renaming.

Ok, I get it. This means that scripts are run only during a preview and never after the new file list is created. So manual changes can be made to the new file list later, but scripts cannot change the new file list later. This is what is causing the problem. Thus even if we skip certain parts of the code when a preview is done, those parts cannot run later while renaming because the scripts aren't re-run, right?

I guess I answered my own question: "So if it can run from the command-line (where no preview has occurred), why can't it run when I directly press Rename before pressing Preview?" Since while running from the command-line no manual renaming can be done, so a preview does indeed occur, the script is run, the new name list is built and the files are renamed accordingly. But running within the program doesn't cause the script to run when the Rename button is pressed since manual renaming is the culprit. That's why the dialog box says "Click Preview button"!

Ok, now what to do about this? Here are my suggestions, ranked from most desirable to least:

1) One way would be to disable manual renaming when scripts are active. After all, the script is being used to rename all the files, right? If a user wants to manually rename some files after the script has run, he can do it in the next round after disabling/removing the script from the rules list.

If this is done, scripts can then safely run both during preview and rename, and we could have the value of a Boolean read-only variable, say IS_PREVIEW, set to True when the Preview button is pressed (and naturally to False if the Rename button is pressed). This will also remove that error mentioned above and the script I've written will run successfully even if only the Rename button is pressed.

2) If the above is not feasible, then how about this... Our main problem is just that re-running the scripts on rename will destroy the manual renaming done by the user after the preview, right? So it's just a matter of saving the manual renaming and applying it after the script runs. So if a user presses Preview and then F2 and renames some files, the new names for those files should be saved in a 2D string array like this:

{ "OldName1", "NewName1",
  "OldName2", "NewName2",
  ...
  "OldNameN", "NewNameN" }

Now on pressing Rename, the scripts should run and finally, one more round of renaming should be done where the files mentioned in the array are given their final names according to what the user specified. Or else if multiple renaming for some files is too much (though it will make things much simpler), then internally the scripts should run only on the files that haven't been manually renamed. Finally the remaining files should be renamed according to the values stored in the 2D array.

Either way, this will solve our problem and again, scripts can safely run both during preview and rename, and we can have the value of IS_PREVIEW set to True when the Preview button is pressed, or to False otherwise.

What do you (and Denis!) think?

krtek · 2008-08-13 12:29

Andrew,
The link to topic of origin was only to give a context I'm glad you make a suggestion topic out of it.

Andrew wrote:

1) One way would be to disable manual renaming when scripts are active.

No, no, no and once more no!
The thing is that possibility of seeing old names during manual renaming REALLY ease the process (and sometimes is essential to success).
If you will be made to do it in two steps, you will lose possibility to compare old name with new name and check if that's what you wanted.
The simplest example of the problem is UpperCase for surnames. You won't get any script to know if that word should start with uppercase. You can only set a general rule, more or less sensitive to your needs, but still only general.
Now you run a preview and then go through the list of old names looking for upper-cased letters and you act accordingly to what you find.
If you split it into two steps...then there will be NO original upper-cased letters during manual renaming and you will have to carefully read whole list of new names looking for anything that possibly should start with uppercase.

Andrew wrote:

if a user presses Preview and then F2 and renames some files, the new names for those files should be saved in a 2D string array.
(...)
Now on pressing Rename, the scripts should run and finally, one more round of renaming should be done where the files mentioned in the array are given their final names according to what the user specified.

That's better, but I remember that someone already proposed something like that (probably eR@SeR) and it was considered hard to implement.

And there are another few drawbacks.
The main is: What if you add a rule after Preview and before Rename? The results are unpredictable.
Adding option "autopreview on rename" causes danger of not knowing what will happen. Now you know that when you press Rename files will be renamed (or tried to be renamed) accordingly to the files table which you SEE (or even SAW and CHECKED).
Autopreview on rename brings unpredictability to the process, because you can't be sure that the result will be the same as the one you see in the files table (you can add or disable/enable a rule before preview and rename, you can have a bug in your script etc.).

And finally it would change whole philosophy of the application's way of doing things. For me that philosophy is good, because it is extremally simple and thus reliable and invulnerable.

krtek wrote:

1. When you press Rename ReNamer (apart of renaming files according to files table) checks all your PascalScripts seeking for special part of the script and executes it. The question is, should it be done before or after actual renaming.
2. We could have a special rule for storing user requested data (eg. counters) which would not affect preview operation, but would be executed during renaming...
But this would need some kind of communication between that rule and other rules (like scripts, serialize etc.) to retrieve needed variables...

Whats more I can see now, that my solutions are also useless. They both would need an execution of whole scripts (not only some special part) because only during execution counters and other variables are initialized and get their correct values.
So any of these suggestions would need an execution of all the rules in the rules table WITHOUT affecting the files table.
And here we are again face to face with possibility of bugs in scripts and differences in results between executions of the script.
I really have no idea how to solve that problem...

Last edited by krtek (2008-08-13 12:32)

Andrew · 2008-08-13 18:05

krtek wrote:

No, no, no and once more no!
The thing is that possibility of seeing old names during manual renaming REALLY ease the process (and sometimes is essential to success).
If you will be made to do it in two steps, you will lose possibility to compare old name with new name and check if that's what you wanted.

Ok, ok! I am convinced that it was a bad idea...

krtek wrote:

That's better, but I remember that someone already proposed something like that (probably eR@SeR) and it was considered hard to implement.

Are you sure? I couldn't find such a post. Maybe Denis can weigh in on this issue and say whether it is feasible or not?

krtek wrote:

And there are another few drawbacks.
The main is: What if you add a rule after Preview and before Rename? The results are unpredictable.
Adding option "autopreview on rename" causes danger of not knowing what will happen. Now you know that when you press Rename files will be renamed (or tried to be renamed) accordingly to the files table which you SEE (or even SAW and CHECKED).

But krtek, the very fact that we are discussing different code execution paths during Preview and Rename means that we are discussing the possibility of the file list not being final! After all, if you have a script with some code like this:

if(IS_PREVIEW)
begin
  // code to run during Preview
end
else
begin
  // code to run during Rename
end;

then this means that even after Preview, the file list may not be final as the code to run during Rename may change it.

So the point to be pondered now is, is there some way around this without upsetting the existing way of doing things too much? Even I have no idea now so I'm going to think about it some more (maybe a lot more... ) and then post again.

den4b · 2008-11-18 02:17

I just want to make few comments (i know, "finally", sorry for the delay):

* IS_PREVIEW / RENAME flags are useless, because their state will never change. Remember: rules are applying ONLY during the Preview process, and NOT when you press Rename.

* WideScanDirForFiles() and WideScanDirForFolders() will always return files/folders in the order they are returned by the system. You, on the other hand, can write a little script to sort them later

den4b Forum

#1 2008-08-12 17:31

Suggestions from Andrew

#2 2008-08-12 19:49

Re: Suggestions from Andrew

#3 2008-08-12 20:47

Re: Suggestions from Andrew

#4 2008-08-12 22:28

Re: Suggestions from Andrew

#5 2008-08-13 10:58

Re: Suggestions from Andrew

#6 2008-08-13 12:29

Re: Suggestions from Andrew

#7 2008-08-13 18:05

Re: Suggestions from Andrew

#8 2008-11-18 02:17

Re: Suggestions from Andrew

Board footer