7.55b1: Edit file within a zip

[wanderer]

There seems to be a problem when entering into a zip archive and pressing F4 to edit a file. The editor application is opened, it says it has opened the file but not data is loaded.

The file to be edited is actually unpacked in %TEMP%\_tc folder but it's immediately deleted, forcing the editor to create a new file. Typing some dummy data, saving the file and exiting the editor does nothing (one would expect the usual "do you wish to update the packed file" prompt from TC).

[ghisler(Author)]

What editor do you use? There are some editors which are launched with a small tool (e.g. editor1.exe) which immediately starts another one (e.g. editor2.exe) and then closes. When TC sees that editor1 closes, it deletes the file immediately (but only if you have an EditWaitTime line in your wincmd.ini). Similar things can happen with multiple document editors if the editor was already running when you press F4.

[wanderer]

Indeed, that must be the case. I use the OpenFileTC utility but i've never faced that problem with older TC versions.

I've done some research, and found why this happens. So far i've been working on a PC with Kaspersky Antivirus for Workstations 6.0MP3 version. The setup i've described worked just fine. I recently upgraded to Kaspersky Antivirus for Workstations 6.0MP4 and after that, this problem appeared. If i disable the antivirus, everything works as before. It seems something has changed (perhaps it takes more time to scan) in the new Kaspersky version.

I've set EditWaitTime=5 in my INI but nothing has changed (the problem is still there when KAV is active). Can anything be done about it in order to work as before?

[ghisler(Author)]

Can you try a larger EditWaitTime value?

[wanderer]

After a restart of the PC, i tested values up to 5000 and it seems to work better now. It even works with 5 most of the time.

I don't understand 2 things though.

1. When EditWaitTime exists in the INI, almost all of the times TC pops up the "click on close when the temp file can be deleted" window. It always does that at the same amount of time (at about 2-3 seconds) after F4 is pressed, regardless of the EditWaitTime value. It doesn't matter if EditWaitTime=5 or 500 or 5000, the "click on close" window will appear after about 3 seconds. Is that what should happen? Does the value of EditWaitTime matter to TC or it just checks for a positive value?

2. When TC starts the external editor, it should normally know its process ID. Why all the complication of EditWaitTime and not just periodically check if the process has terminated?

[ghisler(Author)]

1. No, the value matters. If you make it too large and the program is closed immediately by the user, you will still get this dialog...

2. It does it when there is no process ID. For example, if the program already runs, then ShellExecuteEx passes the file name via DDE to the running program and does NOT return any process ID. Also in the case where editor1.exe starts editor2.exe and exits, the process ID would quickly become invalid, so TC would unload the file.

Maybe you have any better ideas how to handle it?

[wanderer]

...and does NOT return any process ID.

I see. So, there seems to be no way to track it. At least no easy and safe way...

Maybe you have any better ideas how to handle it?

Nope, unfortunately not. I have some thoughts but they're either unsafe or too complex and probably not worth it. It seems the way you've implemented it may not be the most convenient but it seems a good and safe one.

Anyway, thanks for all the clarifications.