How to use more than 25 user tools?

Windoze · Oct 25, 2009#12009-10-25T22:35+00:00

Hi,

does UE/UES provide a ole-automation interface so it can be scripted from another application?
Conversely, does the internal js script engine or the macros provide the equavalent of a 'createObject' ?

I understand that UE/S is not intended as a full blown IDE, but it would be very nice to have either of those if they don't exist already.

It's sort of a PITA to have to burn up one or more of the ten F10 external commands to run something else ... pretty clunky actually.

I did search for this subject, but no results ... maybe I searched the wrong thing... surprising actually.

thanks for the assist.

Mofi · Oct 26, 2009#22009-10-26T09:07+00:00

I think such an interface does not exist. But for a definite answer on this question you better ask IDM support. I think from within scripts or macros only the up to 25 user tools can be executed.

Of course with using a batch file you can run hundreds of external tools with various parameters when you pass as first parameter to the batch file which tool should be executed and all the other parameters. For example the command line for the batch file in the user tool configuration could be:

C:\path to the batch file\RunTool.bat %sel%

The batch file RunTool.bat starts with:

@echo off
if "%1"=="1" goto Tool1
if "%1"=="2" goto Tool2
if "%1"=="3" goto Tool3
if "%1"=="4" goto Tool4
if "%1"=="5" goto Tool5

And you call this user tool from within a macro with

NewFile
"3 "first parameter for tool 3" "second parameter for tool 3""
SelectToTop
RunTool "case sensitive name of the tool"
CloseFile NoSave

Windoze · Oct 26, 2009#32009-10-26T23:10+00:00

Mofi, thanks for the detailed reply.

Yes this will work sort of - launching through a batch file is 'old school'. I was trying to avoid a back-to-the-future scenario as this method has many inherent issues and limitations. The best, but functionally limited, way around this is to write a windows scripting host VBS (.vbs) script file or a Jscript (.js) file (not to be confused with the java scripter *inside* UE/UES) and then use the F10 or F9 launch method to fire that external script. Use wscript for F10, cscript for F9, passing parms in on the command line. The scripter passes them into the script for you to parse at your leasure. This is cleaner and far less clunky than the old DOS batch file "%1"=="1" goto lable. (Although I do really appreciate your taking the time to show *exactly* what to code to make it work!). BTW, the scripting host has been part of 'dows since around SP1 or SP2 on XP. Try just renaming an empty "New Text Document.txt" to "New Text Document.vbs" and watch the magic.

I used UE a long while ago. Recently purchased UES - had expected to find at least an OLE automation interface. That's been part of Windows since the Stone Age. Actually I had expected the entire internals of the editor to be exposed as some flavor of a .NET/COM/OLE interface.

I will contact cust.sup as you suggested. Maybe I'll voice my opinion on the interface - but as that stuff is old that for the UE/S programmers no doubt they made a decision sometime back *not* to have a public interface into the editor's guts.

thanks for your time.

Mofi · Oct 27, 2009#42009-10-27T09:28+00:00

Yes, Windows Scripting Host (vbs) is more powerful than command line interpreter (batch file). But most virus scanner applications warn all the time when running a new VBS file while on a batch file there is no warning. So when I post a public solution I prefer a batch file solution because no problems with virus scanner and therefore no feedback like "My virus scanner reports that the VBS file is dangerous" or "It does not work" (because virus scanner blocks the interpretation of the vbs file).

OLE is fine, but even in Microsoft applications it is not working well. Have you ever embedded a MS Visio 2007 drawing as OLE object into a MS Word document, gave the Word document to somebody else having Visio also installed, but a different version (2003 instead of 2007) and double clicked on the Visio OLE object in the Word document to edit it with Visio 2003? It does not work, no error message, simply nothing. It is even difficult to delete the OLE object in this case from the Word file. That's just one problem I have had with embedded OLE objects. In the meantime we don't use anymore embedded OLE objects. Too much problems in the past. The OLE interface works as long as the user does not give the documents somebody else and do not exchange the applications on his/her computer. As you may notice, I'm personally not a fan of the OLE interface.

Windoze · Oct 27, 2009#52009-10-27T14:14+00:00

Mofi, Yes, I agree with everything you point out. Interesting contrast I hadn't thought of: you have to be conscientious of the techniques you describe here publicly, while I was asking for me and perhaps some coworkers.

Right, OLE is pretty lame - especially the embedded mess you describe. COM was/is much better, .NET better still (but the latter has some overhead, as you know).

I guess we make due with what we have available to us, eh? Still, I can't help but feel at times that we are working, like Mr. Spock said, with "stone knives and bear skins".

Here is another very cool way I found to make a workable solution. This is a Killer App, well worth investigating if you have to do computer drudge work:

autohotkey.com

cheers