I've just had two independent reports of problems with the A-Shell File > PrintScreen function no longer being able to launch the email client. One person claims that under ATE it's related to the choice of TELNET (works) vs SSH (doesn't) for the connection protocol (although that makes no sense to me yet). The other says it started when Office365 was installed.

I need to investigate it further but am starting this thread so that anyone else can benefit or participate.

The one thing I can say about it now is that it requires the MAPI interface (MAPI32.DLL, typically in a subdirectory of the Windows directory). MAPI allows an application to launch and pass setup information to the local mail client without knowing specifically which mail client it is). We need this capability in order to automatically attach the image and set up the skeleton of the message body (with background details about the versions, etc.)

Web-based mail clients, like Gmail and Office365 do not really support traditional MAPI, but do support the "mailto:" URL scheme. So it may be that we can add a configuration option to the Print Screen utility to use that method instead. However, I don't think it is generally allowed to specify an attachment via that interface (for security reasons). So the user would have to manually locate the screen image file (perhaps with a clue embedded in the message or in a popup window?), which is going to make it less convenient to use.

To be continued...

Working fine for me under:
* SSH (ATE 6.3.1542.2)
* Microsoft Outlook 2016 (with Office 365)

I can duplicate this problem on my pc when I run ATE with the "run as administrator" option.

why am I using the "run as administrator option ?

Well ...

[ The flipping telnet issue ]

When Windows 10 come out I stated noticing this new issue with some folks. ( and of course, I could not duplicate it on any of my computers. )

When you hit your "flip screen" button 15 times, the entire ATE windows would close.

At first, I thought it had to do with 64bit version, but later found that to be not true. I could never find a common denominator. But clearly is not an ATE issue rather a freakish Windows issue.

But I did find a work around: using SSH instead of Telnet for some reason resolved the issue.

Well ... I introduce you to:
[ the SSH permission error ]
So, then Windows10 come out with a security update, and (not all, but most) of these computers using SSH as a protocol, all of the sudden started getting error message about how they do not have access to use SSH.
So to fix this problem, I started having users "run as administrator" on the ATE icon.


So, it appears the resolution to this [ unable to link to MAPI ] could be resolved by fist figuring out how to resolve the initial [ flipping telnet ] issue.


I have looked in the ATE forum and found no discussion on this topic, so I assumed it is an isolated incident.

This is all so weird that I'm tempted to attribute it to "alternative facts". :rolleyes:

To begin with, it's hard to come up with a theory for why either protocol would be affected by PolyShell operations, since they take place entirely on the server side. The only downstream effect seen by ATE is an extra screen clear and screen paint operation. But if that were a problem, it would seem that merely chaining back and forth between a menu and a program (both of which probably start with a screen clear and paint) would trigger it as well.

On the other hand, anything that promotes migration from TELNET to SSH should be given some respect. So probably we should focus on the SSH privilege issue. But: a) I've never heard of this symptom; and b) a quick Internet search only turns up server-side issues, i.e. problems connecting to a Windows box, not from.

Any chance you can email me a screen capture of the error message?
(Sorry, couldn't resist.)

But seriously, the capture is immediately saved as \captures\img#.png so with a little extra effort it can be manually attached to an email. I'm reasonably hopeful that if we can identify the precise error.

You may be happy to know that I can reproduce the problem when running as administrator. In that case, clicking on the email button in the print screen utility causes it to hang for about 15 seconds (during which time the window is dead), and then reports the general MAPI error 2, which Microsoft helpfully documents as "One or more unspecified errors occurred. No message was sent."

In thinking about that though, it makes sense, assuming that your email client is already running in non-administrator mode. Typically the MAPI request just pops up a mail compose window within the existing mail client application; there's no practical way to do that as administrator if the application is already running as a normal user. To test that theory, I closed my mail client (Thunderbird), then tried the as-administrator print screen/email and it works fine (launching Thunderbird from scratch as administrator). And it continues to work fine after that, suggesting that one workaround would be to launch your email client as administrator too. (But note that the same problem occurs in reverse if a non-administrator ATE tries to send email via MAPI to an existing as-administrator email client process.)

So while that may be a functioning workaround, it seems too much like the tail wagging the dog. It would be much better to figure out why SSH is requiring you to run as administrator in the first place.

That said, we have to recognize that MAPI is fundamentally unreliable interface, since it has to dance along the edge of ever-tightening inter-process security issues, relies on ever-changing levels of support in the mail client (which we have no control over), and for that matter, is unlikely to ever work with web-based mail clients.

And the mailto: URL scheme, as mentioned above, suffers from the inability to specify an attachment. (Or more precisely, the protocol allows us to specify one, but it is routinely ignored due to security concerns.) We could embed a message in the body of the email instructing the user/sender to manually attach the image and providing the location, but that's pretty clunky.

If there is really a demand for easy-and-reliable emailing of screen captures that wasn't dependent on the local email client, the best solution is probably to implement an EMAILX-based email option. Somebody would have to configure the SMTP connection parameters in the aprntscrn.cfg file, and the user would be limited to just the short note already in the print screen dialog. And we'd have to prompt for the email address (without the benefit of the mail client's address book, although chances are the same address would be used nearly every time, so could also be saved as the default in the cfg file).