"Edit" button on "Find Files" window

[VdgR]

Please add an "Edit" button to "Find Files" window after "View" button.
Why TC still does not support it?
Also I think we should support clicking "F4" for selected file (including external editor support).

I really miss this feature.
Thanks.

[Horst.Epp]

Next time search the forum before making new threads about old wishes

[VdgR]

I did search the forum. I did not find anything. Sorry.
Can you provide the link to corresponding topic please?
Any chances that the suggested change will be implemented?

[hi5]

Various solutions here http://ghisler.ch/board/viewtopic.php?t=37921&highlight=

[VdgR]

I think that ability to use F4 key in "Find Files" will be a great improvement. It is so simple to implement.

I agree with AntonDudarenko:
"why you should monitor actions from editor's side?
we are talking about the listbox with results of searching!
it should be not matter - what was done with files from this list."

I miss this feature very much.

Maybe Author will review this after 1 year since the last discussion and he will change his mind.

[ghisler(Author)]

The problem is that the user can actually change files with F4! This causes a lot of problems:
1. The search results have to be updated
2. When the user edits a file from FTP or a file system plugin, it needs to be re-uploaded when it is saved
3. When the user edits a file from an archive, it needs to be re-packed when it is saved
4. The user may close the search dialog before closing the editor, and later save the file. This is especially bad when using a standalone search.

[MVV]

User may still have one of these files already opened...
User may open file properties and rename file from it...
Another user may upload new version of the file to server after TC have finished the search...
Search result may become invalid after feeding to listbox where TC allows everything...

I argee with others that you shouldn't try to prevent all possible incorrect usings of TC functions, especially in cost of usability. View, edit, delete - these all may be useful from search dialog directly, there is no need to block them.

[petermad]

2MVV
Well put - I agree +++

[Horst.Epp]

2MVV
Support +++

[nsp]

The problem is that the user can actually change files with F4! This causes a lot of problems:
1. The search results have to be updated
2. When the user edits a file from FTP or a file system plugin, it needs to be re-uploaded when it is saved
3. When the user edits a file from an archive, it needs to be re-packed when it is saved
4. The user may close the search dialog before closing the editor, and later save the file. This is especially bad when using a standalone search.

1) Why do you want to reload the search ?
If I edit a file with an external application or another file manager, will you reload the search ?

2/3) What is different from doing it later ?

4) I do not see what is related to the search dialog ?
The search process is to search and find !
All the actions you do from the dynamic display of result are file manipulations and not anymore part of the search process.
Do you have an event manager of unitary file action independent from your UI ?

[Hacker]

Christian,
I have to agree here, I don't think anyone expects the search results to update on-the-fly.
This might change when we have the built-in index I dream about, but that is not relevant in the nearest future.

Roman