Relative Paths For Portable Macros - Explaining SCRIPT_DIR and BMP_DIR

So you've written a macro which reads from a text file to get some config info. You put the text file in the same folder as your script and do this:

ReadFile>c:\users\myusername\documents\mymacros\config.txt,fileData

Now you want to put this macro on another PC or give it to a friend. You realise you are going to have to edit that line or the macro isn't going to work because his username is different or he has his profile on the D drive, or he wants to use a different location for his scripts.

You don't want to go editing your scripts every time you deploy them. What do you do?

Well there's a useful system variable available to all running macros called SCRIPT_DIR.

What is SCRIPT_DIR?

I call SCRIPT_DIR "Location of Self". Self being the macro that is running. The macro that refers to it.

So if we had a macro inside "C:\My Macros\" its SCRIPT_DIR value would be "C:\My Macros". If you then moved that macro to "E:\More Macros\" and ran it again SCRIPT_DIR would now be "E:\More Macros".

An easy way to demonstrate this would be to make a macro that just looks like this:

MessageModal>SCRIPT_DIR

Run that macro, then move the macro file (the .scp file) around. You'll see the message box simply show the location of the macro.

Or use the debugger. As soon as you start stepping through the script you'll see the value of SCRIPT_DIR in the watch list.

By default, after install, Macro Scheduler 14 happens to use My Documents\Macro Scheduler 14 as its main, default, macro location. So if you create a macro inside Macro Scheduler after install and look at SCRIPT_DIR it would show this same location.

But if you made a new macro group and linked it to a different folder, a macro in there would show that folder as its SCRIPT_DIR.

Now if you have Macro Scheduler Pro and compile this macro to a .exe and copy the .exe to let's say "C:\Temp Stuff\" and run the .exe you'll again see SCRIPT_DIR show "C:\Temp Stuff".

I think (I hope) I've done this explanation to death now.

SCRIPT_DIR is location of self. Self being the macro/script/exe that you are running.

Why is this useful? Well, if we go back to our original example where we want to read some config info from a text file and we want to easily deploy this macro to other PCs, we could now do:

ReadFile>%SCRIPT_DIR%\config.txt,fileData

And if we put config.txt in the same folder as the script/exe then it will always be able to read from it. To deploy we now copy the macro file (.scp file) and config.txt to any new folder/PC and the script will always be able to read config.txt, because it is looking for it in "location of self".

If you compile it to a .exe then just put config.txt into whichever folder you copy the .exe to.

If your script refers to many files, you may want to create a subfolder instead. E.g. you might have a folder called "Deploy" which you put all your files in and then:

ReadFile>%SCRIPT_DIR%\Deploy\config.txt,fileData

Then when you deploy your script (or an exe version of it) you just copy that subfolder in one.

By using SCRIPT_DIR we can more easily move macros around and prevent issues when people change or rename paths.

BMP_DIR - For Image Recognition Images.

When we first released the image recognition wizard we defaulted the location of captured images to the same location as the macro and used SCRIPT_DIR to refer to them as in the above example. So you had the script and all its images in the same folder. To deploy you copied the script and all images.

But this got a bit messy, especially if you had - as you would normally - lots of macros in the same folder. It also made it impossible for the compiler to copy those files automatically.

So we introduced something called BMP_DIR. It's another relative reference. It's really just %SCRIPT_DIR%\Subfolder where Subfolder is the same name as the running script.

So let's say you have a macro called "MyMacro" and looked at the value of BMP_DIR (either with the debugger or a simple message box). 

And let's say "MyMacro" was in "C:\Macros\". 

BMP_DIR would point to the path "C:\Macros\MyMacro". 

In other words it points to a subfolder inside SCRIPT_DIR which matches the name of the running macro.

This sub folder may not exist yet - and for all new ones - it won't. But the *reference* exists.

BMP_DIR points to a subfolder of the same name as the running script inside the folder containing the running script.

So, back to image recognition. When you run the Image Recognition Wizard and capture some images, you'll see the code that is produced point to those images inside BMP_DIR:

FindImagePos>%BMP_DIR%\image_1.bmp,SCREEN,0.7,1,XArr,YArr,NumFound,CCOEFF
If>NumFound>0
  MouseMove>XArr_0,YArr_0
  LClick
Endif

And if you were to open up Windows Explorer and navigate to the folder that contains your macro (by default this is likely to be Documents\Macro Scheduler 14) you'll see a new subfolder with the same name as your macro. That is your BMP_DIR for this macro.

Now, if you rename the macro from within Macro Scheduler you'll see the subfolder renamed accordingly. 

And if you have Macro Scheduler Pro and compile the macro to, say, F:\Deploy\MyMacro.exe, and leave the "Copy BMP Subfolder" option checked you'll see MyMacro.exe gets created in F:\Deploy along with a subfolder called "My Macro" containing the bitmaps.

If you copy or rename the script or exe manually, you'll need to copy/rename the subfolder too, or the macro will fail, because it won't find the BMP_DIR.