Joe has reported a problem with AUI_IMAGE, which turns out to be a bug, but I thought it might be instructive to review the procedure I went through to figure this out, since it may clarify some aspects of AUI_IMAGE with ATE, as well as use fo the Debug Message window.

The basic complaint was that under A-Shell/Linux using ATE, the following attempt to display an image failed with STATUS=2 (file not found):
Sure enough, I try something similar in the SOSLIB program IMAGE[908,32] and I get the same results.

What to do?

Step 1: turn on the debug window to see what's happening. (Ctrl+Shift+double right click, choose Debug Window; then right click on the window, pick Properties, and check the ATE trace option.)

Step 2: run the test program
Step 3: examine the debug window, which looks like this:

(I removed traces that weren't relevant.) The ones that are relevant are:

0) Which shows the file being transferred via TAB(-10,22) to the to the %ATECACHEDIR%. (See the topic Extended TAB(-10,x) Commands in the Development Guide for details.)

To verify that it worked, I go to the Settings | Connection Properties | Misc dialog to see what the Local Cache directories are set to, where I see:

Temp: %MIAME%\cache
Perm: %MIAME%\permcache

Not remembering where I installed ATE, I could either look at the properties of the shortcut used to launch ATE to find out the base directory (which %MIAME% will be set to), or use the File | Open Local Session option to open up an A-Shell session underneath ATE, where I could use the DIR command to see if this file exists:

.DIR/H "%MIAME%\cache\sample.bmp"
0 406-011-310-110

Note the need for the quotes around the file spec. Also note that DIR mysteriously displays a "0" for the size of non-AMOS-style filespecs, but the fact that it shows a hash and doesn't complain indicates that the file surely exists. I could also use the PWD command to see what directory I'm in, from which I can guess the %MIAME% definition:

.PWD
C:\PROGRAM FILES\MICROSABIO\ATEFR1\DSK0\001004

(From the above, I could deduce that %MIAME%\cache is equivalent to C:\PROGRAM FILES\MICROSABIO\ATEFR1\cache and locate it in Explorer).

So far, so good, the file seems to have transferred correctly, so why didn't it display?

Back to the trace, the next interesting line is 7,
which shows a TAB(-10,35) command, at the end of which is the mysterious spec "%ATECACHEDIR%\IMAGE.RUN". (TAB(-10,35) is the internal TAB form of the AUI_IMAGE command.)

Without getting into the details of the parameters for that command, we can easily surmise that %ATECACHEDIR%\IMAGE.RUN is not the filespec we are hoping to display. So we have a bug.

A little farther down in the trace at line 9, we see another interesting line which starts with "findlocalfile" and one of those mangled 8.3 filespecs ending with IMAGE.RUN.

What is happening here is that whenever ATE looks for an image file (including icons used in buttons), it checks the specified filespec, and if not successful, then checks the %ATECACHE% and %ATEPERMCACHE% directories for the file. (In this case, they are all the same, which may be another bug, since I configured the permcache directory to be %MIAME%\permcache, but in general, it would look in three places before giving up on the file - the requested spec, the temp cache and the perm cache.) As an aside, the reason why the path has been mangled into 8.3 format is because the InstallShield installation program did that to the path in the shortcut which launched ATE. (Yes, it's time to update the install program, but other than being ugly, that in itself is not a problem, and you could fix it by just adjusting the shortcut properties.)

But getting back to our problem, the sample does reveal a bug in AUI_IMAGE, which I'll fix in 976.5. The bug is caused by the fact that the image spec was clearly a native spec (/vm/miame/dsk0/908032/sample.bmp) and thus we didn't need to call the filespec translator on it. But when we got to the point where we needed to form the filespec of the PC copy of the file (after it was transferred), it was falsely using the output of the last filespec translation, which in this case was IMAGE.RUN (from RUN IMAGE).

One workaround is to change the image filespec from native to AMOS-style format, which brings up an issue in AUI_IMAGE with ATE which I discovered a documentation gap for.

If I change //vm/miame/dsk0/908032/sample.bmp to the AMOS equivalent of simply SAMPLE.BMP, how does AUI_IMAGE know whether that should be treated as a host file or a file already on the PC? (In the case of the /vm/miame... spec, it knows that it is a host spec because of the forward slashes. Conversely, if the image spec had backslashes, it would know that it was a PC spec. But with neither, it assumes AMOS, and needs to translate it. But should the translation be relative to the host or the PC?)

The answer is: it assumes that an ambiguous filespec is on the client PC. In order to override that assumption, there is a previously undocumented flag, &h10 (now defined in the latest ashell.def as IMGF_FORCEXFER = &h10). So, the workaround for my sample program is as follows:

The 20 (16+4) forces AUI_IMAGE to consider the image file sample.bmp as residing on the host, so it translates it to the native spec /vm/miame/dsk0/908032/sample.bmp and then transfers it to the PC. The forced translation in this case worked around the bug.

Note that the flag 16 (IMGF_FORCEXFER) would nearly always be required if using ATE to connect to a Windows host (with ATSD), since in that case, even native host image specs would be Windows specs and thus assumed to be relative to the PC.

Of course this would only work if you could reference the image file as an AMOS-style filespec. Going back to Joe's original file (/var/www/images/20/small/5175-205.jpg), in order to reference this as an AMOS-style file, he'd have to create a DEVICE definition something like this:

DEVICE=IMG0:[1,1] /var/www/images/20/small/

Then, he could call the image IMG0:[1M1]5175-205.JPG (even though AMOS filespecs aren't supposed to contain dashes, this is a loophole that is permitted under A-Shell.)

BTW, you can almost always get the latest ASHELL.DEF file from http://www.microsabio.net/aftp/907016/ashell.def

Also note that in this case, the bug fix is on the UNIX side, so if the workaround proposed isn't convenient, you'll need to get the 4.9.976.5+ update for A-Shell/UNIX.