A couple of Ideas (requirements?)

[a-rico]

Hello, everybody:

First of all, I have Search/Find/Read many threads in the forum about Macro-Support.

I have a couple of Ideas that may be somewhat cheaper to implement and may help to bring us all (the users) some of the functionality of a macro-language.

=== Use a (scripted)Tool instead of a macro ===

A solution may be the use of a Tool instead of a Macro.

But right now, the Tool creation right now is somewhat difficult (to the average user) because the tool needs to be a .exe

One alternative is that Textpad have the ability to Invoque a Script-Engine and execute some Code, and let that Code to process the <selected-text> or the <full-text> of the file that is being processed.

The Script-Code could "live" in the Clip-Library. Right now the options of a Clip is [Replace-Selection (on/off)]; the options could be enhanced to have an [Script Code] option in order to let TextPad Identify that that Clip is actually a Script Code, and Textpad could Call the Configurated Script-Engine and Execute the Code contained in the Clip, passing the configured arguments and the <selected-text>

Maybe Textpad could have a Configuration entry to Define the executable to Call (just like the Tools), and with that the users can select any Script-Engine installed in their Machines. Another posibility of that is the use of an Alternate Language like AWK; and Textpad would execute AWK (just like any other Script-Engine) and let AWK execute the Clip and receive the arguments.


Saludos

Alex

[ben_josephs]

Well, in a literal sense, a TextPad tool must be a .exe file, but this file might be an interpreter for your favourite scripting language.

There are many languages suitable for the sorts of manipulations required for this job. Two crucial requirements are sophisticated string handling and the ability to interact with elements of TextPad's window. Clipboard handling is also required, as that is the only way that TextPad provides for passing text to a tool.

It happens that I am familiar with Perl, so that is what I mostly use. String handling is built into Perl; GUI interaction is supported by the Win32::GuiTest module (http://sourceforge.net/projects/winguitest, http://www.piotrkaluski.com/files/wingu ... itest.html); and clipboard handling is provided by the CPAN module Win32::Clipboard. There are many other scripting languages (e.g., Python, Ruby, Tcl, ECMAscript, 4NT) that should be suitable, provided that GUI control and clipboard handling are built in or modules are available for them.

Here is a small Perl example that opens the Find dialogue box with the Regular expression check box unselected:

Code: Select all

use Win32::GuiTest qw ( :FUNC ) ;

SendKeys '{F5}' ;
my   $findWin    = WaitWindowLike undef, 'Find', '#32770' ;
my ( $regexChk ) = FindWindowLike $findWin, 'Regular \&expression' ;
UnCheckButton $regexChk ;

Of course, tool writing would be made a lot easier if TextPad provided an interface into some of its own internal functions and data structures.

[a-rico]

I know what you mean, but that is non natural way of interacting with an app.

And another issue, is that the people whom try to use this approach have to have a more-than-average knowledge of how windows works, have to know what a window handle is, and what can they do with it.

You have made your point, but I think that most users does not have or want to have to build a complex script to make a simple task.

In order to provide basic (but enougth) interaction with a Script-Engine, TextPad do not have to expose or provide a full set of objects and/or methods to interact with.

It will be sufficient that TextPad calls the engine, and pass the elements to perform the task:
1) The Script to be Executed
2) The <selected-text> on witch to apply the script.
3) Some extra arguments
And catch the Output of the Run of the Script.

That way, the script to be executed, will just need to know how to do the task its gonna do. It does not need to know how to get a Window-Handle, How to get the text of that Window, etc.

As I exposed in my previous post, I think a convenient way to store the script is within the Clip-Library. With that; the clips would become scripted clips that would bring more power to TextPad.

Anyway thanks for your response.

[ben_josephs]

I largely agree with you. I was indicating that (for script authors at least) there is a way round some of the limitations of TextPad's current tool mechanism. Writing tools is not as easy as it should be, and there is much that you can't do.