Open file in new UltraEdit window

Tookelso · PostMay 17, 2006#12006-05-17T20:43+00:00

Hello,

I do not have enabled Allow multiple instances in configuration. Most of the time I want to have all my documents open under the same window.

However, I have two screens at work, and it would be nice to open a new UltraEdit window sometimes.

Is there a quick/easy way to open a file in a new UltraEdit window, without going to the Settings and clicking Allow multiple instances?

Thanks, Nate

Acid · PostMay 18, 2006#22006-05-18T04:29+00:00

I know what you mean. As far as I know it is impossible to get an "edit" window out of UE. So if you really want a separate window on your second screen you will have to start a new instance of UE.

Although it is possible to resize UE so it covers most of your two screens. So you can move the edit windows around. The down side is that UE will cover most of your desktop and every time you want to type something UE will take focus and hide most of your desktop.

Mofi · PostMay 18, 2006#32006-05-18T10:48+00:00

Sorry, no! You cannot start a new instance of UltraEdit without enabling Allow multiple instances, except you use UltraEdit v13.10 or later.

I would suggest to write a feature request by email to IDM support (see email address at top of this page) and ask for a command line parameter which forces UltraEdit to ignore the multiple instances setting in the INI and always starts UE in a new instance. Then you would only need a shortcut or an UltraEdit tool to uedit32.exe with this parameter to start UE in a new instance without changing the setting. I would support this additional command line parameter feature request.

As workaround you can create copies of the uedit32.* files with a different file name like ue2.* in the same directory as uedit32.ini, enable once in ue2.ini the setting Multiple Instances to 1 and run uedit32.exe with the command line parameter /i="path to uedit32.ini\ue2.ini" via shortcut or UltraEdit user tool.

The disadvantage of the second INI file approach is that you have to make all settings now always twice and the histories (find, replace, ...) are different for standard instance and the second instance. There are also problems during updates to new major releases of UltraEdit. You have to always synchronize after an update the second INI with the content of the first INI with exception of the Multiple Instances setting.

To reduce the disadvantages of the second INI file approach as much as possible you could also create a batch file which has following commands:

@echo off
copy /y "path to uedit32.ini\uedit32.*" "path to uedit32.ini\ue2.*" >nul
"path to Xchang32.exe\Xchang32.exe" /s "path to uedit32.ini\ue2.ini" "Multiple Instances=0" "Multiple Instances=1" >nul
"path to uedit32.exe\uedit32.exe" "%1" /i="path to uedit32.ini\ue2.ini"

Xchang32.exe was a free 32-bit console application for replacing text in files from utilities package of Clay Ruth. Run this batch file via a shortcut or an UltraEdit user tool to start a new instance of UltraEdit with current stored settings of uedit32.ini.

Edit: Added "%1" to the last line of the batch file. Now it is possible to run the batch file with an UE user tool and pass the current file name with "%f" to the batch file to automatically open the current file in a new instance of UE.

It's even possible to open the current file in the new instance of UE and place the cursor exactly to the same position as it is in the current instance of UE. In the user tool the options %line% and %col% (in this sequence) must be used on the command line. And in the batch file you have to modify "%1" to "%1/%2/%3".

Tookelso · PostMay 18, 2006#42006-05-18T22:36+00:00

Thanks for the replies.

I made a feature request for Firefox like functionality. In Firefox, you can right click on a link, and select Open in New Window. In UltraEdit, you could right click in a file, and the option to open in a new window would be there.

I tried my own kludge. Here's how it goes:
I have a Perl script which goes into the INI file and changes Multiple Instances=0 to Multiple Instances=1.
Then the script calls UE, passing the currently open file name.
Then the script goes back into the INI and changes Multiple Instances=1 back to Multiple Instances=0.

In UltraEdit you have to go to Advanced - Tool Configuration and set up a new command where you call new_ue_window.pl "%f"

It *does* spawn a new window with your file in it.

However, it gets quirky from here.
Since you spawned a new UE window with Multiple Instances=0, then if you close the new Window, UE will overwrite the INI file with Multiple Instances=1.

As soon as you close the original UE window, the Multiple Instances=0 is restored. So if you can live with that, then this solution's o.k.

If anyone wants the Perl script, I attached it below. Copy and paste the following into a file and name it new_ue_window.pl.

You'll also need at least Perl 5.8.0 installed and in your PATH. UltraEdit also needs to be in your PATH.

Code: Select all

# new_ue_window.pl

# This Perl script modifies the ultra-edit INI file to 
# allow multiple instances.  It then calls ultra edit, passing
# ultra edit the name of the file.

use strict;
use warnings;

use POSIX qw/strftime/;
use File::Copy;

my $file = shift or die "ultra_edit.pl <1|0> 1 for multiple instances, 0 for not.";

my $INI_FILE = $ENV{APPDATA} . '/IDMComp/UltraEdit/uedit32.INI';
my $INI_BACKUP = $INI_FILE . '_' . strftime("%Y_%m_%d_%H_%M_%S", localtime());
   # Make a backup.
copy($INI_FILE, $INI_BACKUP) or 
   die "Could not copy '$INI_FILE' to '$INI_BACKUP' -- $!";

my $exe = $ENV{ProgramFiles} . '/IDMComp/UltraEdit/uedit32.exe';

turn_multiple(1);
system("start uedit32.exe $file");
sleep(2);
turn_multiple(0);

print "Finished";
exit 0;

sub turn_multiple {
       # 0 for off, 1 for on.
   my $allow_multiple = shift;
   
   my @settings;
       
   open FILE, $INI_FILE or die "Couldn't open '$file' -- $!";    
   while(<FILE>) {
       # print "Before '$_'\n";
       s/^Multiple Instances=\d/Multiple Instances=${allow_multiple}/;
       # print "$_";
       # print "After '$_'\n";
       push @settings, $_;
       
   }        
   close FILE;
   
       # Write INI file with new settings
   open FILE, ">", $INI_FILE or die "Couldn't open INI file '$file' -- $!";
   foreach my $setting(@settings) {
       print FILE $setting;
   }
   close FILE;    
}

PostMay 19, 2006#52006-05-19T05:03+00:00

I totally missed an obvious answer, and that is to have another program open the currently active document.

"Duh" on me.

We have TextPad 4 here at work. I just configured a Windows Command in UltraEdit that runs TextPad with the active file.

This will be good enough for now.

Thanks, Nate

Bego · PostMay 19, 2006#62006-05-19T10:55+00:00

Hi Tookelso,

hmm, I think Mofis approach is quite practicable.
--> there is always a "new" Ini derived from your "real" ini
--> No "quirky" stuff

rds Bego

PostMay 19, 2006#72006-05-19T16:21+00:00

When doing it with a batch file, a stupid console window stays open. I hate that and did not yet get rid of it.
So I made a VBScript file called ue_new_Instance.vbs.
You have to modify the red code-passages and have implement the copy too (I can live without an INI copy, I do this by hand from time to time).
I also made a link to this script in the "send to" Folder and named it "UltraEdit_NEW_INSTANCE". Quite comfortable now :-)

Option Explicit

Dim shell
Dim args
dim fil
DIM fso
DIM STRCMD1
DIM STRCMD2
dim STRINI
dim strCmd
dim QUOTE
QUOTE = """"
STRCMD1 = QUOTE & " C:\Program Files\Ultraedit\uedit32.exe" & QUOTE & " "
STRCMD2 = " /i=" & QUOTE & "C:\Program Files\Ultraedit\uedit32_new_Instance.ini" & QUOTE

set args = WScript.Arguments
if (args.Count > 1) Then
MeldungRaus "Wrong call"
Elseif (args.Count = 1) Then
fil = QUOTE & args.Item(0) & QUOTE
End If

Set fso = CreateObject("Scripting.FileSystemObject")

strCmd = STRCMD1 & fil & STRCMD2
'msgbox strCmd

set shell = WScript.CreateObject("WScript.Shell")
shell.Run strCmd , 1 , FALSE

wscript.quit

Sub MeldungRaus (strMeld)
wscript.echo strMeld
wscript.quit 1
End Sub

Mofi · PostMay 19, 2006#82006-05-19T17:14+00:00

Hi Bego!

Console windows are not automatically closing on your computer?

Look in your Windows directory for a file named _default.pif. Delete or rename it or click on it with the right mouse button and modify the properties of this DOS shortcut file which is used for all DOS programs without their own *.pif or *.lnk file.

See also the German article Einstellungen für alle DOS-Programme from the great German WinFAQ. A must have for German Windows experts.

Bego · PostMay 19, 2006#92006-05-19T23:27+00:00

Hi Mofi,

Doesn't the console window stay alive because the call is a synchronous call?

I renamed the pif to _default.pif.disabled and just started that test.bat:

@echo off
"c:\program files\tools\editor\ultraedit\uedit32.exe"

Still the console window is alive until I close UE :-(

With the VBS solution it certainly works fine. So for me it is just a minor (but nevertheless interesting) question.

Holaraiduliöh :-)

EDIT:
BTW, a cmd /c "c:\program files\tools\editor\ultraedit\uedit32.exe" also does not close the console window :-/

Mofi · PostMay 22, 2006#102006-05-22T10:44+00:00

Hi Bego,

You are right. My batch file works perfect on Windows 98, but on Windows XP the console window is not closing until the second instance of UltraEdit is closed. I looked into it and found out that UltraEdit must be started with the start command. So the last line for Windows 2000 / Windows XP must be

start "UltraEdit" "path to uedit32.exe\uedit32.exe" "%1" /i="path to uedit32.ini\ue2.ini"

Now the console window automatically close after UltraEdit is started when the batch file is executed with a shortcut. But it still does not close when the batch file is executed from within UltraEdit with DOS Command or a user tool, except the Alternate Capture Method is used. UEDOS32.EXE has an effect on closing the console window on Windows 2000/XP. I have not found yet the reason for the wait of the closing console window until all called tasks are closed. Maybe I will look into this issue sometime.

However, for Windows 2000/XP there are already two working solutions: the Perl script from Tookelso and the VB script from Bego. Thanks, guys!

Bego · PostMay 22, 2006#112006-05-22T13:13+00:00

Hi Mofi,

Hey, the start command really works as expected. Didn't know that command yet. :oops:
Has some interesting issues. look via

Code: Select all

start /?

Thanks Mofi, rds Bego

Mofi · PostMay 22, 2006#122006-05-22T16:22+00:00

Hi Bego,

if you use the start command in future please note: the window title is not really optional. The start command will interpret the first argument with double quotes always as title. So if anywhere in the whole command double quotes are used, a window title in double quotes must be specified too. This behavior has taken me two hours as I first time run into this issue.

Also note: The start command of Windows 9x does not have a "title" parameter and there are several other differences.

Bego · PostMay 22, 2006#132006-05-22T17:08+00:00

Hi Mofi,

I saw that too :-/

Many greetz to Redmond for Windows architecture from here

rds Bego

P.S.: If I didn't mention that before: We'll become Soccer World champions soon.

(I hope I did not perpetrate Fifa-licence-laws

)

deeptinker · PostMay 23, 2006#142006-05-23T00:21+00:00

I found out a long time ago that if I start UE/UES with a shortcut in Startup, UE/UES comes up and stays up. I can enter DOS commands that invoke UE/UES all day and I get an immediate return.

However, if UE/UES is NOT running, invoking the same command waits until UE/UES has exited before I get the prompt back.

Go figure.

Travis

Mofi · PostMay 23, 2006#152006-05-23T10:43+00:00

I detected this while testing the new instance start of UE too.

On Windows XP (and probable also Windows 2000/NT4) the Windows command interpreter cmd.exe is used for executing a batch file. If a Windows 32-bit GUI application is executed within this batch file, the command processor always waits for the termination of this application and so the batch file does not continue after starting the GUI application. To start a 32-bit GUI application within a batch file without waiting for the termination the command start must be used as I have already described. Use start /? in a command prompt window for details about the start command.

That is a totally different default mechanism as on Windows 9x where the virtual DOS machine (command.com) by default never waits for the exit of the started Windows GUI application and the start command must be used if the execution of the batch file should be halted until the GUI application has terminated.

The Windows command interpreter cmd.exe does by default not wait for the termination of a 32-bit GUI application if it is executed directly in an command prompt window and not within a batch file. This handling can be changed by disabling the command extensions either by the cmd.exe option /E:OFF for current call only or be setting the registry value of EnableExtensions to 0 under

HKEY_CURRENT_USER\Software\Microsoft\Command Processor
or
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor

deeptinker what you have seen and I too can be easily explained. If UE/UES is already running with Multiple Instances=0 and you start again the EXE, the new instance checks the INI parameter, then it checks if an instance of itself is already running. If this is true, the second instance sends a message to the first instance that it should itself bring to foreground and then the second instance terminates itself. The Windows command interpreter recognizes the termination of this started task and continues.

Exactly the same happens when I start Opera. If no Opera instance is currently running, the batch file does not continue until Opera is closed. But if an Opera instance is already running, it gets the focus, opens the file/link or a blank page in a new tab and then the batch file continues because the second instance of Opera has terminated itself.

So to get my batch file working on Windows NT4, Windows 2000 and Windows XP without an open console window until the second instance of UE is closed, use it with the start command and simply disable the capture option and the Show DOS Box option which is really not needed here.

And very helpful are Filemon, Regmon and Process Explorer from Sysinternals. Especially the tool Process Explorer can help a lot because you can see which application has started another application. And when clicking with the right mouse button on a running application and choose properties, it can be even seen very interesting things like the whole command line parameters used on starting the selected application.

UltraEdit, UltraCompare, UEStudio forums