Press/Release command used with Variables

Technical support and scripting issues

Moderators: Dorian (MJT support), JRL

Post Reply
gtdalsanto
Pro Scripter
Posts: 51
Joined: Tue Oct 03, 2006 4:22 pm
Location: Akron, Ohio
Contact:

Press/Release command used with Variables

Post by gtdalsanto » Thu Nov 02, 2006 3:50 pm

I am trying to create a subroutine that gets the function key that is desired to be pressed. Is there a way to do this by using a veriable with the Press instruction. I don't want to have to make a subroutine with 50 if>command=F1; if>command=F2;if>command=DOWN...etc.

I am trying to get the following to work, but so far have been unsuccessful. It seems as if variables will work for the iteration part of the press command, but a variable will not work for the inputkey. Any suggestions would be appreciated. Below is an example of what I am trying to do:


Let>NewInputKey=DOWN
Let>Iteration=5

Press %NewInputKey% * %Iteration%
Gary T. DalSanto
Inventive Software Designs, LLC
[email protected]

User avatar
Marcus Tettmar
Site Admin
Posts: 7378
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Thu Nov 02, 2006 5:03 pm

Unfortunately you can't do that because each Press whatever is a command in it's own right. The keystroke is part of the command name, not a parameter.

But here's a workaround:

Code: Select all

Let>NewInputKey=Enter
Let>Iteration=5

WriteLn>%TEMP_DIR%\pressscript.scp,r,Press %NewInputKey% * %Iteration%
Macro>%TEMP_DIR%\pressscript.scp
DeleteFile>%TEMP_DIR%\pressscript.scp
What this does is create a temporary script file with the appropriate Press command, runs it, then deletes it again!
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

gtdalsanto
Pro Scripter
Posts: 51
Joined: Tue Oct 03, 2006 4:22 pm
Location: Akron, Ohio
Contact:

Press/Release command

Post by gtdalsanto » Thu Nov 02, 2006 11:27 pm

Marcus,

Thanks for the quick response. I had the same thought of creating a script on the fly to build the command and then run it, but I figured I would ask if there is an easier way before I go to the trouble. Thanks for the code snippet, which will save me some time.
Gary T. DalSanto
Inventive Software Designs, LLC
[email protected]

User avatar
jpuziano
Automation Wizard
Posts: 1085
Joined: Sat Oct 30, 2004 12:00 am

Post by jpuziano » Fri Nov 03, 2006 7:31 am

Hi Marcus,

Thanks for the above but I assume Macro Scheduler would have to be installed on the machine for that to work.

Any way to do this if all you're running on a machine is a compiled macro? A VBScript method perhaps? Or is the long list of If statements, Labels and GoTos the only way at that point?

Just thinking out loud now... most Macro Scheduler commands accept variables. The Send> command can accept a variable (it would be quite limiting if it couldn't). I noticed the WaitKeyDown> command uses the VK codes by which every key on the keyboard (and other codes perhaps) can be represented. It also unfortunately cannot accept a variable (I tried it just to be sure).

Enhanced WaitKeyDown> command :?:

Could the WaitKeyDown> be enhanced so that in addition to how it works now, it also accepts a variable with the condition that the variable evaluates to either a single character or VKxxx where xxx is some number between 1 and 255? Or another approach might be a new command called WaitKeyDownVK> which accepts either a number from 1-255 directly or a variable which evaluates to a number between 1-255.

New PressVK> command :?:

A new PressVK> command could also be made along similar lines, accepting either a number 1-255 directly or a variable that evaluates to a number from 1-255. However, since some keys need to be released as well, would ReleaseVK> would be needed too? Not sure how workable this would be, might be hard to read and perhaps decipher what a script was doing if it sent a lot of keys using a command like this.

Enhanced Macro> command :?:

Also, the Macro> command. I am fairly certain it only works if the machine has Macro Scheduler installed on it. But what if the Macro> command was enhanced to be able to work from within a compiled macro without the need for Macro Scheduler installed on the machine? That would open up lots of possibilities. The compiled macro could create various .scp files on the fly, write them to disk, run them (pass value/s to them when run) and get results passed back through the MACRO_RESULT system variable.

Quite a few of the really interesting tricky techniques I see here involve code that writes code, writing some Macro Scheduler code to a file and then running that. It would be nice to be able to use these same advanced techniques with compiled macros as well. Anyone else agree?
jpuziano

Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post - :-)

User avatar
Marcus Tettmar
Site Admin
Posts: 7378
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Fri Nov 03, 2006 7:49 am

jpuziano wrote:Thanks for the above but I assume Macro Scheduler would have to be installed on the machine for that to work.
Why so? It uses the Macro command.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

User avatar
jpuziano
Automation Wizard
Posts: 1085
Joined: Sat Oct 30, 2004 12:00 am

Post by jpuziano » Fri Nov 03, 2006 8:16 am

mtettmar wrote:
jpuziano wrote:Thanks for the above but I assume Macro Scheduler would have to be installed on the machine for that to work.
Why so? It uses the Macro command.
I had thought the Macro> command would only work if running the script from Macro Scheduler itself, after all, that's where the code is that parses the .scp files. Are you saying that full .scp file parsing ability is built-in to a compiled .exe and the Macro> command within the .exe can access this ability to run any .scp it happens to point to? :shock:
jpuziano

Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post - :-)

User avatar
Marcus Tettmar
Site Admin
Posts: 7378
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Fri Nov 03, 2006 8:58 am

jpuziano wrote:
mtettmar wrote:
jpuziano wrote:Thanks for the above but I assume Macro Scheduler would have to be installed on the machine for that to work.
Why so? It uses the Macro command.
I had thought the Macro> command would only work if running the script from Macro Scheduler itself, after all, that's where the code is that parses the .scp files. Are you saying that full .scp file parsing ability is built-in to a compiled .exe and the Macro> command within the .exe can access this ability to run any .scp it happens to point to? :shock:
Yes, the Macro command works within compiled scripts. Always has done and I'm not aware of any statement to the contrary. All script commands are supported.

Re WaitKeyDown - that should accept a variable. Thanks for spotting that. Will add that to the list.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

User avatar
jpuziano
Automation Wizard
Posts: 1085
Joined: Sat Oct 30, 2004 12:00 am

Post by jpuziano » Fri Nov 03, 2006 9:31 am

mtettmar wrote:Yes, the Macro command works within compiled scripts. Always has done and I'm not aware of any statement to the contrary. All script commands are supported.
That's fantastic, thanks... :D
mtettmar wrote:Re WaitKeyDown - that should accept a variable. Thanks for spotting that. Will add that to the list.
Excellent... thanks again. :)
jpuziano

Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post - :-)

User avatar
Marcus Tettmar
Site Admin
Posts: 7378
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Fri Nov 03, 2006 9:35 am

I've just tested this and can find no issue with the WaitKeyDown function. It already supports variables correctly.

E.g.:

Let>thekey=VK101
WaitKeyDown>thekey
MessageModal>Hello

Works fine. Run it and then press number 5 on the number pad (ensuring Num Lock is on of course).
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

User avatar
jpuziano
Automation Wizard
Posts: 1085
Joined: Sat Oct 30, 2004 12:00 am

Post by jpuziano » Fri Nov 03, 2006 10:19 am

Hi Marcus,

I tested it with almost the same code you did, copied from the Help file... only now with Num Lock on... :oops:

OK it works but two things:

1) It only seems to work when you hold down the key for a long time. I can lightly tap the key several times and it makes a sound through the speakers each time (so it must be detecting that I pressed the key) however the MessageModal doesn't display. I have to hold the key down for a fairly long time for that to happen. Any idea why?

2) The Help for WaitKeyDown doesn't say it accepts variables or show an example using a variable, it just says:
Help File wrote:WaitKeyDown pauses execution until the specified key is pressed. For an ordinary character key specify the character of the key. For other keys use the virtual key code preceeded by VK:

WaitKeyDown>H - waits for the H key to be pressed

WaitKeyDown>VK101 - waits for virtual key code 101 (Numpad 5) to be pressed.
It's nice to see it say it can take a variable or see a variable used in an example.
jpuziano

Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post - :-)

User avatar
Marcus Tettmar
Site Admin
Posts: 7378
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Fri Nov 03, 2006 10:40 am

I would argue that we shouldn't need to explicitly state in each and every function topic that it can take a variable - that would get repetitive and would need a lot of additional text in the documentation. All function parameters can be variables. (At least they are meant to be - if you find a parameter that doesn't accept a variable let me know - it's probably a bug). I think this would be expected by anyone used to programming languages, and should be inherent in the design of the language. But perhaps not all would realise this. So I think it should only need saying once. In fact it is already explained in the Using Variables section:

"Variables can then be passed into other functions as one of the parameters"
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

User avatar
jpuziano
Automation Wizard
Posts: 1085
Joined: Sat Oct 30, 2004 12:00 am

Post by jpuziano » Sat Nov 04, 2006 1:06 am

mtettmar wrote:I would argue that we shouldn't need to explicitly state in each and every function topic that it can take a variable - that would get repetitive and would need a lot of additional text in the documentation. All function parameters can be variables. (At least they are meant to be - if you find a parameter that doesn't accept a variable let me know - it's probably a bug). I think this would be expected by anyone used to programming languages, and should be inherent in the design of the language. But perhaps not all would realise this. So I think it should only need saying once. In fact it is already explained in the Using Variables section:

"Variables can then be passed into other functions as one of the parameters"
OK, I see the above statement in the Help topic "User Defined Variables" but I would counter with:

- Many of your users are probably not programmers and may not know what to expect of commands in general.

- When users need help on a command, they may look for help *ONLY* on that command and not dig further. Maybe they're pressed for time or don't like wading through Help files but why doesn't matter; they needed Help, looked up a command they wanted to use and didn't get a full grasp of what it could do. To me, the Help file failed the user, not the other way around.

- A little extra text in the Help file is a small price to pay to ensure users get everything they need to use a command to its fullest with just one lookup.

- Great Help files are a valuable feature of any software product just like a great forum or great support... saving a few characters shouldn't prevent that.

- Some users may have never read help topics on variables or they may have skimmed them and your one blanket statement in the variables section didn't sink in.

- A user may have worked with one of the commands that was "non-standard", become familiar with the Help for that command and drawn some misleading conclusions. Here's an example of this:
Help File wrote:ConCat
*
ConCat>string1,string2

Concatenates string1 with string2. String1 must be a variable containing a string. String2 can be a literal string or a variable. The result is that string1 has string2 appended to it.
I saw that in this command, one of the parameters *had* to be a variable and the other could be *either* a variable or a literal string. I then assumed that potentially, any command might have similar requirements and further assumed that looking up each command would tell me what I needed to know.

By the way, ConCat> in the Help file contains a strange character, it looks like a minus sign or underline and it is positioned exactly where I've put an asterisk * in the above example. Is this character supposed to be there? No other Help entry has one of these. If its just a typo, please remove it.

And again, the above is just my feedback and opinions. None of it is ever meant to be taken in a negative light. While some of these things may be quite picky, attention to detail is the mark of a superior product. I wouldn't take time to mention these things if I didn't already think Macro Scheduler was a great product and getting better daily. Keep up the great work! :)
jpuziano

Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post - :-)

Post Reply
Sign up to our newsletter for free automation tips, tricks & discounts