simple scripting, part 1

[nikos]

remember when we talked about scripting xplorer2? I have developed a little something about it, using Deskrule as the usual test bed:

http://zabkat.com/test/dr_macros.zip (beta, just unpack somewhere and run)

press F9 key to start macro editor (listview must be active) or right click on the window titlebar to find the command
The dialog shows a few of the available instructions; more commands in manual, press F1 on the macro dialog

it is meant to automate the execution of commands and dialogs, so you could collate many actions and ease repetitive tasks. It is very simple and IMHO easy to understand and use. No more menuhack required!

There are a few ways to introduce variability with a little imagination, e.g. the INPUT instruction.

Arguably the non-orthodox nature of deskrule GUI limits the usefulness of macros (e.g try to access command in a drop-down toolbar button or to set text on rule boxes) but this is just a test for xplorer2 down the road

Have a go with it and let me know what do you think about it. Are there any other elementary instructions required?

ps the "documentation" is here

[nikos]

if anyone's interested (I am not holding my breath ), deskrule v1.52 has been released as "final", including the macro capability.
it's a simple language but quite powerful too, e.g. try to work your head around this script:

Code: Select all

FINDWND "search results"
STORE $1 # listview (search result) window
GETCOUNT $2 # total items, process in reverse

LABEL loop
POP $1
SELECT $2
CMENU rename
WAIT 100 # for edit box to appear
FINDCLASS edit
GETTEXT $0
CANCEL
MESSAGE $0 
DECR $2
JUMPOK loop

download version 1.52 from here: www.zabkat.com/deskrule

[Kilmatead]

As the loop is $2 dependant, what's the $1 used for? Its value is the stored window and popped... some kind of SetFocus-equivalent or something, so the loop doesn't go errantly walkabout singing its merry song to all and sundry? Isn't that what parentwnd is for?

[nikos]

if you read the fine manual, many of the commands rely on the $0 register (last result). If you think about it, SELECT $2 is vague. Select in what? That's where the stored window in $1 comes from/for.

the complications in this script come from the loop. If there was no loop, things should be much cleaner and simpler

[Kilmatead]

I have read the fine, fine, manual, and I've been a-pushin' and a-poppin' registers since you were hiding under the reeds of your mud-hut frightened of Ο Γάτος Με Το Καπέλο! And since I never liked the back-asswards (or ass-backwards) ways that registers work, my brain naturally rebels and defaults to a more causation-based procedural logic than yours does. "The last result is piped from one command to its successor automatically"... except when they're HWND's, apparently.

That being said, there is a great quote in there about "...note the roundabout way to initialize the counter variable using POP then STORE", which is classic as it's not only the reverse of this particular example, it also reads as an admission of a guilty conscience!

Guilty of what, we know not, but fans of the glorious Jean-Baptiste Clamence will love ya for the off-hand sentiment.

[nikos]

to keep things simple I set a roof of maximum one argument per instruction (plus the hidden last result). As I said, for simple things you don't need variables at all, nor popping them