Well, I use UEStudio for working with projects and UltraEdit for quick editing text files of any type. Therefore I have checked the configuration setting
Allow multiple instances in UltraEdit resulting in opening always a new instance when double clicking on a file within an archive opened by WinRAR for viewing or editing. However, for being able to answer your questions, I unchecked this setting of UltraEdit, closed UltraEdit to force update of uedit32.ini and started UltraEdit again with opening a file on hard disk.
WinRAR
WinRAR has a configuration dialog titled
Viewer. It can be configured in this dialog if double clicking on a file inside an archive results in
- displaying the file contents with internal viewer of WinRAR,
- opening the file with an external viewer like UltraEdit (full file name of exe can be defined in same dialog),
- open the file with associated program according to registry,
- or ask the user which of the 3 other options should be used for the file.
I set
external viewer and later tested also with
associated program resulting in same behavior.
So what happened as I double clicked on a file within a ZIP archive opened in WinRAR.
- WinRAR extracted the file to an automatically created subdirectory with a random number in directory name in TEMP folder.
- Next WinRAR called uedit32.exe with the full name of the file as command line parameter.
- A second instance of UltraEdit started which detected that multiple instances is not allowed and an instance of UltraEdit is already present. Therefore the second instance passed the file name to already running instance and then the second instance exited itself. This resulted in no action of WinRAR.
- The file is now opened in UltraEdit and can be edited and saved.
- After switching back to WinRAR, WinRAR displays a message box informing the user that the file was modified and if the ZIP archive should be updated. Although I have just saved the file in UltraEdit, but not closed the file or exited UltraEdit, WinRAR updates the archive with the modified file on a positive confirmation of the question.
- I can close the file in UltraEdit now or continue editing and save it again. It does not matter what I do with the file in UltraEdit. WinRAR keeps the file extracted to the TEMP folder and scans the file properties for changes. Whenever the file is changed again, WinRAR asks if archive should be updated again with the modified file.
- WinRAR deletes the file on exit of WinRAR.
So instead of observing the called application on exit, WinRAR observes the extracted file for changes to determine if the user should be asked for updating the archive with a modified file. That's a very good method, isn't it.
Rhapdog can possible code an AutoHotkey script which
- saves current file in UE/UES (with Ctrl+S),
- closes the file in UE/UES (with Ctrl+F4),
- switches to WinRAR window,
- confirms the question with YES.
Total Commander (TC)
Total Commander is like 7-Zip, it observes exit of the called application to determine what to do with the extracted file. However, there is one important difference.
If the file is modified, saved and closed in already running instance of UE instead of the instance started shortly by TC, but UltraEdit continues running, TC asks the user if the file should be deleted now after called application has exited. The user has the choice to confirm the deletion of the file, or send the message box to background and later confirm it. In case the editing of the file is finished and therefore the deletion can be confirmed, TC does not simply delete it. TC first checks if the file was modified and if this is the case, asks the user if the modified file should be packed into the archive before deleting it.
The option to send the message box to background and later confirm the deletion of the file has the advantage, that the user can continue working with TC while the file is still opened in the editor, not in the called instance which terminated itself, but that does not matter. So the user can take a long time for finishing the editing, before the queued message box is brought to front, deletion is confirmed and modified file is packed to the archive.
The TC method has therefore 2 disadvantages in comparison to WinRAR method.
- A button must be pressed on 2 dialogs instead of just one as in WinRAR.
- If UE was not already running while TC called UE for editing the file, UE must be closed to trigger TC to check modification of the file, update the archive after confirmation and delete it.
The advantage of the TC method is that the file is not kept in TEMP folder until TC is closed which is often not done for a very long time (several days on my usage because of using hibernate mode). For WinRAR it is no problem to keep the file extracted in TEMP folder until WinRAR is closed because usually nobody has WinRAR open a very long time.
7-Zip
I have perhaps also a solution for 7-Zip. 7-Zip observes exit of called application and it is not possible to add command line parameters. So what about calling UE respectively UES indirectly by configuring a batch file as editor. The batch file contains following line:
@start "7-Zip File Edit" /wait "full path to uedit32.exe or uedit64.exe or uestudio.exe" /fni %1
@ just hides the command line in the opened console window on call of the batch file.
start is an internal command of cmd.exe to launch GUI applications.
"7-Zip File Edit" defines a title for the window. This parameter of command
start is optional, but a title in double quotes must be given if anything else is enclosed in double quotes on the command line or
start will interpret this double quoted string as title.
/wait is an important parameter of command
start for this usage. It results in not continuing batch file processing until the started application has terminated and therefore 7-Zip does not trigger checking the extracted file for a modification.
The next parameter for command
start is the full name of the executable to call. The double quotes are necessary if a space character is part of the path.
/fni is an UE/UES parameter to force a new instance ignoring configuration setting
Allow multiple instances.
And
%1 holds the value of first parameter which is the full name of the file to edit.
%1 contains already the full name with double quote characters if 7-Zip called the batch file with the file name in double quotes as it should do.
That should work.
Also possible would be that the batch file removes the archive file attribute, calls UE or UES without fni and then periodically checks if archive attribute is set again on the file which happens on saving the file in UE/UES. Then the batch file terminates and 7-Zip continues.
It would be also possible that the batch file stores current modification date of the file in an environment variable, calls UE/UES normally and then periodically checks if last modification date of the files change to determine when to exit the batch.
Wait for 1 second within a batch file requires a small tool or other solutions. I have seen solutions like using ping.exe for a wait loop in batch jobs, but there are enough wait utilities in WWW which can be used to get a periodic check, let's say every second, within a batch file on archive attribute or last modification date change. One of these commands is Microsoft's Sleep tool, see
Batch file SLEEP Command.
Update:
There is the setting
Maintain separate process for each file opened from external application at
Advanced - Configuration - Application Layout - Miscellaneous available since UltraEdit v18.10 and UEStudio v12.00 with
Allow multiple instances not enabled. With this setting enabled it is possible to use only 1 instance of UltraEdit for any files opened by any application and nevertheless let applications like 7-Zip think a separate UltraEdit process is running as long as the file is opened in the single instance of UltraEdit.