Script execution from command line on a running instance does not work!

[macxicon]

Has anybody found a solution yet for not being able to start a script on an already running ultraedit ?

The demand is as simple as it can be:
C:\SYS\Tools\UltraEdit>uedit32 /s="scripts\ufccopy.js"

This results in:
C:\SYS\Tools\UltraEdit\="scripts\ufccopy.js contains an invalid path.

- No matter what option you use (/s /m /xyz) the result is always the same.
- notice the single "
- Tried using full path specs, specifying an additional file, enclosing all and everything in "

I suppose this to be definitely a bug, bubbling up through all the previous versions, i gave a try.
Very annoying - i my case it quashes two days work of coding !!
(no - using a new instance of ue is not an option)

Maybe anyone can help ?

[Mofi]

That is not possible. I have listed some reasons at Always get error message when running a macro/script via command line parameter. Don't know what your script ufccopy.js is for and why you run it from command line and why you want that it is executed by an active instance of UltraEdit.

[macxicon]

Thanks for your answer Mofi - but unfortunately it IS true.
Of course taken into account the -not-so-subtle- difference of using /fni (instead of /foi).

With /fni behavior is as expected, the script is executed in a new instance of UE.
Using /foi (or no option) EVERY /option seems to be replaced by the the current installation path of UE, which is definitely a BUG my book.

This is the core behavior problem - all other stated "solutions" - using full paths, enclosing quotation marks, at least one file as an argument ..
are just "side effects" of this.

In my case i'm stuck to using a single instance of UE because i would call it 100times a day on the same (project) files - changing back and forth the edited data with another environment (uniface).
Currently i'm thinking about workarounds like DDE or sending windows messages ... (.. or shooting sparrows with canons:)

greez back from -the-other-end-of-austria-

[macxicon]

Heads up on totally weird commandline behavior:
All tests done by startting ue from installation dir.

uedit32 "/s=C:\SYS\Tools\UltraEdit\scripts\ufccopy.js" => C:\s=C:\SYS\Tools\UltraEdit\scripts\ufccopy.js contains an invalid path.

uedit32 " /s=C:\SYS\Tools\UltraEdit\scripts\ufccopy.js" => C:\SYS\Tools\UltraEdit\=C:\SYS\Tools\UltraEdit\scripts\ufccopy.js contains an invalid path.

uedit32 " /s=C:\SYS\Tools\UltraEdit\scripts\ufccopy.js" => C:\SYS\Tools\UltraEdit\ =C:\SYS\Tools\UltraEdit\scripts\ufccopy.js contains an invalid path.

uedit32 "uedit32.exe /s=C:\SYS\Tools\UltraEdit\scripts\ufccopy.js" => C:\SYS\Tools\UltraEdit\uedit32.exe =C:\SYS\Tools\UltraEdit\scripts\ufccopy.js contains an invalid path.

uedit32 "uedit32.exe /sC:\SYS\Tools\UltraEdit\scripts\ufccopy.js" => C:\SYS\Tools\UltraEdit\uedit32.exe C:\SYS\Tools\UltraEdit\scripts\ufccopy.js contains an invalid path.

[Mofi]

What should your tests with completely wrong command lines demonstrate? That UltraEdit is not able to find out what you mean when you specify the command line parameters completely wrong?

What I below write is what I think happens internally from a programmers view.

UltraEdit can be called with file names without full name (complete path + name of file with extension), i.e. with relative paths. Because of working directory for the called UltraEdit instance can be completely different to the working directory of already running UltraEdit instance, the new instance must pass the relative file names as full file name to the already running instance. Therefore every parameter which can't be identified as one of the described command line options, for example because of wrong usage of double quotes, is interpreted as file name. I suppose that UltraEdit uses Windows kernel function GetFullPathNameW for those strings not starting with [A-Za-z]:\ or \\computername\sharename\ (or all "file name" parameters) and passes the returned string to first instance of UE or uses this string in case the called instance is the first instance. And it must be taken into account that it is possible to call UltraEdit with a file name for a new file. So the file as specified on command line must not exist, just the path. So without testing I think what you see in the error message dialog is what function GetFullPathNameW creates from the input strings.

I don't know if you know that Windows respectively the startup code of the compiler used for the executable parses the command line string and the main function of the application gets already a list of strings for evaluating.

[macxicon]

Hi Mofi

I guess your assumptions what's going on are not completely accurate
What i tried to show playing with the commandline was just that a completely wright cl gives totally weird error.
And a totally wrong cl results in a message saying ".. contains invalid path" even though all path's displayed are perfectly fine.
Ok but i agree - this leads to totally nothing and was just experimental

As i found out in the meantime there are huge code parts in the game here.
In short: UE checks for another running instance if found calls GlobalAddAtom() and sends (an already wrong) cl to it's instance.
U can easily check this out with something like:
hWin = WinFindM("UltraEdit");
hAtom = GlobalAddAtom("/s=yourclhere");
SendMessage(hWin, 0xC144, 0, hAtom);
GlobalDeleteAtom((TU16)hAtom);
This sends a correct cl from your app -> resulting in the same strange Message -> bad luck

I also found out, that the receiving end in UE then messes it up completely, probably not recognizing it as a cl-option, instead replaces '/' with '\' (thinks option is a file) ..
OK - again - this leads to nada-land.

But the nice thing is, by fooling around with this i found a (already working) workaround.
I simply register my ufccopy.js (or what else) with a hotkey in my case ctl-alt-F12 (never hit by user).
When i now send a hot-key simulation message from my app to UE via:
SendMessage(hWinUE, WM_NOTIFY(0x111), 0x0001FF78, 0)
voila - all the mimicry is in action - I'm now able to call and execute ufccopy.js on a running instance !

Maybe this can help others if in need
greez
macX

[Mofi]

Wow, you have really looked deeply into this. After all your work on looking what is not well done when passing the command line parameters from a new instance to another instance, you have hopefully sent the summary and conclusion of your investigation to IDM by email. Would be pity to through away the results of your investigation and not telling the IDM developers what's going wrong and what could be improved.

[macxicon]

Didn't send it - but will !

[mtnkidd]

Hey, I had the same problem and solved it easily by changing the Tool Configuration to "Allow multiple instances". Works now even without /fni argument.