Our client, an SI on behalf of their end user reached out requesting this feature. When asked to elaborate on the need, the impact of not having this feature and the desired end goal, the client provided the following explanation:
"The need is driven by the customer. Their current app has a screenshot button in the menu that they can use to quickly note the state of things or show us or their controls resource when something is malfunctioning or looks weird. They use it as a training and communication tool.
Since their app is widescreen, it should be printed landscape to give the best picture and to show the screen in a legible font. It can be difficult to read some of the numbers on the screen when printed in portrait because it's half as big as it would be in landscape.
The lack of this feature did cost me a fair amount of time trying to figure out some other way to fix this issue, which I ultimately failed to do. I think it's hard to say how much money or time it costs the customer regularly, but if it means that some of their operators who can't see as well choose to write down the state of the screens when they need to instead of simply clicking the button, that could eventually add up.
Desired end goal for me would be to add functionality to the PrintScreen() function that allows the developer to specify the orientation of the print. Something like this addition in blue: PrintScreen (ScreenOption, PrintOption, PrintOrientation) Where PrintOrientation is an integer from 0-2, 0 = auto (And is assumed if no number is provided), 1 = portrait, and 2 = landscape.
So then PrintScreen(1,1) would be the same as PrintScreen(1,1,0), which means no existing code would break, but in my case, I could call PrintScreen(1,1,2) and get a landscape print. "