BMP_DIR

[armsys]

How is the new variable BMP_DIR being applied?
Suppose:-
[1] all scripts are stored in: C:\MJT\Script
[2] all images are stored in: C:\MJT\Script\Image\
[3] HKEY_USERS\Software\MJTNET\Msched14\\DataDir is set to: C:\MJT\Script

Then, what?
Can you show us some examples?
Thanks.

[Marcus Tettmar]

It has nothing to do with any of those.

BMP_DIR = %SCRIPT_DIR%\%SCRIPT_NAME%

So if your script is in C:\MyScripts and it is called Script1.scp then BMP_DIR would equal C:\MyScripts\Script1\

Open a macro and hit F8 and you'll see BMP_DIR in the watch list and you'll see.

What this means is that you can create a folder that is the same name as the script and use it to store images you use in your script and refer to them with BMP_DIR. And then if you need to move your script just move Script1.scp and the Script1 subfolder. Makes moving all supporting image files quicker and easier.

Finally, the image recognition wizard automatically generate the BMP_DIR (if it doesn't already exist) and saves captures there and uses BMP_DIR in the resulting output code.

[armsys]

Marcus,
Thanks for your crystal clear explanation.
After reading your post and experimenting it with debugger, I understand that:
1. BMP_DIR (variable) is automatically generated by Macro Scheduler.
2. BMP_DIR assumes by default an image folder being named after the currently running script.
The only (minor) issue is what if the script name is changed.
Nonetheless, I like the BMP_DIR idea. The images can be better organized and faster located. Before v14, I consolidated all images into a single folder.
Thanks for the new time-saving feature.

[Marcus Tettmar]

If you rename the script it will rename the bmp dir too.

[djs]

Problem is, when you 'include' a scriptfile into the main file and the include file has bmp files, it doesn't seem to work.

Well, everything almost works, but the bmp files are stored incorrectly and you have to move them.

Is there anyway to set the bmp_dir to be %SCRIPT_DIR%\images? This would work MUCH better for me.

Dan

[Phil Pendlebury]

Problem is, when you 'include' a scriptfile into the main file and the include file has bmp files, it doesn't seem to work.

Well, everything almost works, but the bmp files are stored incorrectly and you have to move them.

Is there anyway to set the bmp_dir to be %SCRIPT_DIR%\images? This would work MUCH better for me.

Dan

Not for me as many of my scripts already have images stored in a subfolder "images" and then sub folders to that. Having MS take over the "images" var would really mess things up. If this were to be implemented it would have to be optional, as I suspect many others already use "images".

[Marcus Tettmar]

Problem is, when you 'include' a scriptfile into the main file and the include file has bmp files, it doesn't seem to work.

Well, everything almost works, but the bmp files are stored incorrectly and you have to move them.

Is there anyway to set the bmp_dir to be %SCRIPT_DIR%\images? This would work MUCH better for me.

Dan

This is not true and cannot be true: The code in include files becomes part of the main script code. So what you say makes no sense. BMP_DIR would remain exactly the same. If you include a script file and step through with the debugger or even put a MessageModal>BMP_DIR anywhere in the code or in the included code you will see it does not change.

[djs]

I agree it doesn't change during the execution of the script, but the code wizard changes during creation when you are dealing with includes, at least I assume that is why my images didn't work when I did it.

I'll try it again today and pay more attention. I just know the images I did in the include file part of the script didn't work correctly, but it might have been caused by something different.

Dan

[Marcus Tettmar]

I agree it doesn't change during the execution of the script, but the code wizard changes during creation when you are dealing with includes

No, it definitely doesn't. The code wizard doesn't know anything about includes - they are meaningless if the script is not running.

[djs]

You are making my point for me, but we are talking about 2 different things.

When you run the image wizard, it creates a bmp file and puts it in the directory %SCRIPT_DIR%\%MACRO_NAME%. This works well when you run that file, no problem, BMP_DIR is correct.

When you create the image file, but then that script file is included into another file, those images are suddenly in the wrong directory, since bmp_dir doesn't change directories.

For me, from a support viewpoint, its easier to have all of my bmps in a single directory, and its easier to code that anyway (image wizard excluded).

I haven't found out yet what happens when I compile these files.

Dan

P.S. This thread has made me understand how this works much better, which makes it a lot less of an issue.

[Marcus Tettmar]

Ok, I see. Well in your case then, if you are creating a script that you will later include then you have some options:

1. Don't use the wizard - use the image capture tool instead and hand-code. Experts may prefer that.

2. Use the image capture tool to capture your images, save them where you want and then if you want to use the image recognition wizard use the button that pulls an already existing file.

3. If the master script you are including in doesn't already have it's own BMP_DIR then just rename the BMP_DIR.

4. Do a quick search/replace on BMP_DIR in the include script and replace with %SCRIPT_DIR%\myname

Remember that the main purpose of the wizard is to keep things simple and it is therefore primarily designed for beginners and for the most common use case. I don't want to add too many options to the wizard which might confuse and would be used by a minority.

The Image Capture Tool under the Tools menu can be used to capture images and save them wherever you want. So if you have an unusual use-case or an expert coder you might prefer to use that.

[djs]

Ahh yes, hand-coding is what I've been doing. Separate create image, not a big deal.

I just never wanted to consider myself an expert

So, what you call hand-coding, I'll call copy and paste!

Dan