Basically, trying to email from Print Screen gives an immediate -1 error.
We have tried this on a customer's PCs (who reported it had stopped working), my home PC and Steve's new home PC.
Each is a clean install of "Microsoft 365". The customer has recently moved to Office 365 and some have got new PCs. It is the new installs that are getting the error.
I have the feeling that MAPI is simply becoming too difficult to manage due to the constant efforts by Microsoft and others to block or otherwise cripple it so as to prevent abuse. It's easy to see why it's dangerous, at least in the mode where the email is sent without any user interaction. But it's not quite so easy to appreciate the security risk of allowing one application to launch the email agent to start a message, leaving it to the user to complete the operation. Nevertheless, none of the roadblocks put up seem to make this distinction.
So what does that leave? Sending the email via SMTP (perhaps with EMAILX) is one option, but it requires configuration details that users typically don't have at their fingertips, nor is it always easy for the dealer/installer to get that information for every single ATE install. It also requires another UI element if we want to allow additional text describing the reason for the capture (beyond the one line of Notes in the existing capture dialog). But it may still be workable in some environments, perhaps using a common CFG file on the server with the SMTP info that gets sync'ed to all the clients.
Or, as you suggest, we can just copy the image to the clipboard and leave it to the user to paste it into an email. I think that may require an A-Shell update to add another opcode to the AUI_IMAGE command to copy the captured image to the clipboard. Ideally, we'd like to pick up the text info as well (program, version, timestamp, etc.), but I don't think there is an easy way to share the clipboard between two different datasets. (We could, however, print it to a PDF and then email the PDF. We might even dangle the possibility of combining that with the emailing if you have PDFX?)
Im with you both there with the more and more and more complication and hurdles with emailing... If it saves a LOT of pain trying to keep the feature implemented and simple to use with any additional configuration then we happy with the Email-Icon it swapped out or an additional Copy to clipboard Icon? Im sure a few customer will say whats going on? Where it gone? but we can blame Micro...soft not Microsabio
But will go along with what everyone else thinks.. maybe its not an issue else where? Yet!?
I don't have too much to add here because I encourage my users to use the windows embedded "snipping tool" and most of them are also able to add comments , arrows and send me small parts of the screen instead of a full sized, and heavy, printscreen. Anyway, besides my efforts, I still receive emails with a 2MB Word document attached where, inside, there is a nice PrintScreen and comments.
I agree that a snipping tool (especially a deluxe one like SnagIt) is preferable to these full-screen shots. (And it vindicates Ty's original objection to including a print-screen utility in the first place, i.e. why try to re-invent the wheel, particularly when there are constant refinements, enhancements and compatibility issues to keep up with.) The one advantage of the built-in version was the fact that it might standardize the tech-support messages from customers, who might otherwise resort to sending huge Word files with absurdly sized images embedded, while lacking the critical but boring details like the program name, program version, A-Shell version, ATE version, timestamp, etc.
Maybe we should include a built-in function to copy all those details to the clipboard, and then somehow communicate to the user to use one of the innumerable screen capture tools to augment the email with any other images that seem relevant?
I would be happy to write up a clear page of directions for how to (a) use Windows' "Snip & Sketch" or "Snipping Tool" (S&S is new with Win10), (b) create a file with the results, and (c) send that file via email. We could post those directions on the MicroSabio website, and/or include it in the AshRef. It would be good information for the entire world of Windows users, but of course our interest is A-Shell users. The big question is: how to get A-Shell users to read it?
Although the snip & sketch instructions would be general, it doesn't have any place in our documentation, and I think the real goal here is not just to teach users how to take a screen capture, but how to easily generate useful and consistent tech support messages to send back to whoever provides support for them. That was the original goal of the A-Shell Print Screen utility, and I think it worked reasonably well except for the MAPI problem. But a critical part of that was, at least for me, the "envelope details". If you're going to try to script a procedure involving multiple operations (snip/sketch, email, capturing environmental details, adding notes, etc.) you're going to be deep into territory that is really should be under the direction and control of the dealer. There's nothing stopping dealers from doing that right now. They can even replace APRNTSCRN with an entirely different routine, perhaps one that just gives instructions like you're imagining, or even launches another snipping tool.
