Compile command line paramaters

[obfusc88]

What do I need to do to compile a script that will take in four command line parameters?

Command line syntax will be like this:
Executable.exe height width length area

Complied script will be like this:

Code: Select all

Let>height=parameter1
Let>width=parameter2
Let>length=parameter3
Let>area=parameter5

/*
Error checking:
Check that all 4 values exist else error message
Check that all values are numbers vs. text
Check that all are integers else use Int or Round?

Do calculation stuff with height, width, length, area
Send Messages with different content based on results of calculations
*/

When I compile the script, do I add some type of values to the parameter field, or is that only for Macro Scheduler options?

I don't know how to set up the first four lines to pick up the paramaters from the command line.
The compiled file name will be MakePlans.exe
The command line will be something like this:
MakePlans.exe 15 15 18 1800

[JRL]

I'm sure there are many ways but the way I do it is I use either a forward slash "/" or a hyphen "-" as my parameter delimiter on the command line with the executable. Then in the script I acquire the parameters with Separate>%command_line%,/,param or Separate>%command_line%,-,param

The parameters will start with the variable Param_2 (Param_1 is the path and file name). One advantage to using the forward slash is that it's an illegal file name character. A hyphen could conceivably be in the path or in your file name and therefore throw the separate variable list out of whack.

You might also need to remove spaces from the Param_x variable values. this can easily be accomplished by either running stringreplace> replacing %space% with nothing on the command_line variable or each param_x variable individually.

For example:

StringReplace>%command_line%,%space%,,command_line
Separate>%command_line%,/,param

In your case Param_2 will be the height, Param_3 will be the width, etc.

Hope this makes sense.

[Bob Hansen]

JRL has given a great explanation.

The secret to making this happen is the Macro Scheduler system variable %COMMAND_LINE%.

See HELP on system variables and Separate

Your command line would be broken down with Separate> like this:
MakePlans.exe/15/15/18/1800 would be separated into 5 components
returnvar_1 = MakePlans.exe
returnvar_2 = 15
returnvar_3 = 15
returnvar_4 = 18
returnvar_5 = 1800

Note that I have no spaces between the parameter values and the delimiter. That eliminates the need to remove trailing spaces, but it is not as easy to read.

[Marcus Tettmar]

I hope I'm not missing the point here, but I think you're all making this far more complicated than it needs to be. My answer is you don't need to do anything. Macro Scheduler does it for you.

Let's say you have the following script:

MessageModal>height
MessageModal>width
MessageModal>length
MessageModal>area

For this example the macro is rather pointless and just displays those four values in modal message boxes.

Compile it to an EXE.

Of course if you run this on its own without any command line parameters you will see the literal values "height", "width", "length", and "area" appear in the message boxes.

Now run the exe like this:

MakePlans.exe /height=10 /width=50 /length=30 /area=15000

Now you will see the values 10, 50, 30 and 15000 in each message box.

This works for non-compiled scripts also:

msched.exe MakePlans /height=10 /width=50 /length=30 /area=15000

See the section in the help file called "Command line options".

If you want to first check to ensure the variables exist (have been passed on the command line) use the Assigned command.

While JRL and Bob are right that you can use COMMAND_LINE and parse it yourself, you really don't need to, unless I have missed something here.

[Bob Hansen]

Wow, such a dummy, me!

For about 4-5 years I have used values like that for called macros, but for compiled files I have parsed the %command_line%.

When I had one macro call another one, I have just passed along the variables like you showed, Marcus. I did not even think that the compiled version might perform like a regular macro script.

Thanks for that alternative method. I think I will probably stay with parsing %command_line% for human key entries, but will use the listed variable pairs in programmed scripts, makes it much easier to read and understand.

[obfusc88]

Thanks to everyone for the ideas.

I have the following script, but seems to be having a timing problem.

If I single step through, the Move/Resize happen instantly.
If I run the macro from the Editor with command line defined, it runs instantly.
If I run msched scriptname /parameters, then it works, but takes about 5 seconds
If I run a compiled version of the same script, it takes about 20 seconds.

Here is the script to set the size and position of the window FLTK Notes:

Code: Select all

Let>Title=FLTK Notes

SetFocus>%Title%

ResizeWindow>%Title%,%Width%,%Height%
MoveWindow>%Title%,%TopLeftX%,%TopLeftY%

Label>End

I am expecting the compiled version to move/resize the window immediately, not in 25 seconds.

Here is the command line:
PositionFLTK.exe /TopLeftX=300 /TopLeftY=600 /Width=600 /Height=200

I get the same delays if I use the %command_line% parsing that was suggested, no real difference between them for timing.

[JRL]

Don't know why it would be slow unless it has something to do with your application. I amended your script to move/resize notepad.

Code: Select all

Let>Title=NotePad*

SetFocus>%Title%

ResizeWindow>%Title%,%Width%,%Height%
MoveWindow>%Title%,%TopLeftX%,%TopLeftY%

Label>End

compiled it to an exe named Rtest.exe, opened notepad and typed the following at a DOS command prompt. (My macro scheduler directory is my working directory so no path is needed.)
rtest /TopLeftX=300 /TopLeftY=600 /Width=600 /Height=200

The notepad window was moved and resized before my finger was completely removed from the enter key.

[obfusc88]

Thank you JRL for trying out that script. I did not try it on a few other screens but I will try that to see if they behave like normal. Maybe this should be under a different thread, because I don't think it is about passing parameters any longer. That has been solved.

The window that I am working with "FLTK Notes" is a window that is generated from a "non-windows" program. It was written in a cross platfrom Open Source language, I think it is called FLTK, and I have had other problems, like using Hot Keys, etc. Things just don't seem to work like "windows" designs.

Do I need to contact the authors of that program, but what do I ask them about? I don't know enough about programming languages or Windows programs specs. Is there some special area or interface or library or something I need to have them check?

Or is it the way that Macro Scheduler deals with the windows? Is this a Macro Scheduler bug? Does it need to be modified to deal with some special needs not yet covered?

[obfusc88]

I changed the program so that I could use it for any window. I added another parameter to the command line for the window title.

Here is the code:

Code: Select all

Label>Start
Let>Title=%Title%*

SetFocus>%Title%

ResizeWindow>%Title%,%Width%,%Height%
MoveWindow>%Title%,%TopLeftX%,%TopLeftY%

Label>End

I compiled the file as WindowSpot.exe
Here is a sample ot the command line with syntax:
WindowSpot.exe /Title=Notepad /TopLeftX=300 /TopLeftY=600 /Width=600 /Height=200

Well, all windows that I try have the same delay. I have tried with FLTK Notes, Notepad, Paint, PowerDesk and they all have the same delay of about 20 seconds before being moved and resized. So, this is not just from FLTK programs, it is happening with normal windows programs too.

Using Macro Scheduler 10.1.15, Windows XP PRO-SP2

[JRL]

Try this script. It will tell you how long the script took to complete.

Code: Select all

VBSTART
VBEND
VBEval>timer,starttime

Label>Start
Let>Title=%Title%*

SetFocus>%Title%

ResizeWindow>%Title%,%Width%,%Height%
MoveWindow>%Title%,%TopLeftX%,%TopLeftY%

VBEval>timer-%starttime%,totaltime
Message>Seconds elapsed = %totaltime%
Wait>3

Label>End

My suspicion is that there is something other than Macro Scheduler at play here. Perhaps virus or malware software or a sluggish video driver or some process that hogs video resourses.

How are you executing the "command line" process. Are you running from "Start">"run", are you running from a DOS prompt, did you perhaps create a shortcut? This info may or may not be useful but if I know how you are running the executable I'll run exactly the same way and see if I have any issues.

[obfusc88]

OK, I am closer to eliminating the problem.

The executable that I was running was on a shared network machine, not on the local machine. I was running the command line in a DOS window. I copied the executable to the local drive, and the time dropped from 20+ seconds to <3 seconds. And I can probably live with that.

I also negelected to mention that I did include an icon in the compiled file. I thought that perhaps that was causiing some delay, could not imagine why, but still looking for clues. So I recompiled without the ican, but it made no difference. I have not yet run the script with the time logs, again, I may be able to live with 3 seconds when the executable is on the local machine.

But it was a surprise to see that long a delay across the network, a simple workgroup of 6 xp and 98 machines.

And thanks again for your help and suggestions.