forums.silverfrost.com

[wahorger]

I posted this in "General" because it's not a bug, nor a problem. I just wonder if anyone else has worked on this.

It would be helpful to me (and my users) to be able to screen shot a window to include in a bug report. I have use of this capability to assist in providing up-to-date documentation as well.

Yes, I know I can manually do an ALT+PrtScrn and get the image of the window, but it would be helpful to have the program take the shot, make a file of the appropriate type, and save it for the User to include in an email.

It might be that ClearWin already has a capability to do that, but I am at a loss to figure out exactly how I can do that operation. Send a message to the Window?

Has anyone out there done this? And, if so, how?

Thanks, Bill

[PaulLaidler]

Bill

Try using the accelerator key: Windows Key + Shift + S.

Then click on the box in the bottom right corner.

Here is a link to a Youtube video...

https://www.youtube.com/watch?v=fapSyhyJBKE&feature=emb_imp_woyt

There is nothing that I can think of in ClearWin+ of this nature. There will be something that you can provide but it will depend on how much you expect your users to do. For example, it is possible to provide a button that automatically sends an email to to you.

[wahorger]

Paul, thanks for your response.

I want to make sure the user doesn't need to do much to achieve the capture. Using the Screen Snapshot is something I've been doing for my documentation. My workflow to get it in to documentation requires 9 steps, from snagging the image all the way through post-processing the image for the documentation. I want to make that simpler as well, and I think I can do that now. I want the user to only have to press one set of keys (using an accelerator), then drag-and-drop the image from that specific location into an e-mail. For some of my users, even that is asking a lot!

After I posted my original question, I stumbled across a Stack Overflow discussion and one of the techniques got my attention. You have to look about half way down the discussion to see it. It was using VK_* which reminded me of something I'd seen in the FTN95 documentation regarding %eb. So I poked around the MOD and INS files and found the references to the constants, and tried the code. It works!

https://stackoverflow.com/questions/24985315/c-program-to-take-a-screenshot

The FTN95 program I used to test this only fills the clipboard with the window, but does nothing more. I'm still working on expanding that part (successfully); not yet ready to share the details. It uses clipboard_to_screen_block@() and export_bmp@() and that part is working in a test mode. Stated another way, I can press the key sequence and a copy of the current window is made to a file.

My little test program is below, just grabbing the open window and getting it into the clipboard, nothing more.

[wahorger]

John, I've been using IrFanView for a couple of years now, and boy, is it a great program!

I'll look at what you are describing.

My little keyboard simulator is going to do what I want, namely save a file with a specific name (depending on the Window in use), and in the place where I want it.

My only regret (at this point) is that there is no EXPORT_PNG@() function.

Bill

[PaulLaidler]

Bill

I think that you will find that EXPORT_IMAGE@ works for .png files.

[PaulLaidler]

Thanks. PNG has now been added to this help topic ready for the next update.

[wahorger]

And thanks to you, Paul! Much appreciated.

I'm finding this technique both useful and thought provoking. Thought provoking in that the %cw I have embedded in a window does not seem to be consistently "capturable" by this sequence when I scroll back, then initiate the capture. It takes additional actions on my part to "force" the image to be a reflection of what I can see. It is a minor discrepancy

Using ALT+PrntScrn does not have this limitation. I have not yet figured out how to make both techniques yield the same result. I suspect that there is something that needs to be accomplished in the callback routine to cause the %cw window to "refresh" but remain at the same scrolled position.

Still, it is working and I am incorporating it into the code. The %ud attachment to the window is the "charm" in all this!

[wahorger]

Just a quick update in case anyone tries this technique.

It works great unless the window you are capturing contains a %cw (like debug output), or %lv. In those two cases, when the capture is initiated using the simulated keyboard events, you may or may not actually se the control contents properly displayed.

Best I can determine, it has to do with the window being "rendered". Apparently, the system ALT+PrntScrn forces the window to be fully rendered before the image is acquired OR it is using a different image grabbing technique. I say this because I can scroll the %cw window, do my grab and then do a system grab and the images are different, mine being the "old" version before scrolling. Usually. Meaning that if I take a system screen grab first, then the image I get will match it.

It is a bit confusing to me, but that's what I am seeing. I'll work on a sample program to illustrate the issue.

So for my use right now, I am using a two-key sequence. One to use the system utility (Alt+PrntScrn OR snapshot) then a function key to get and store the clipboard image.

[PaulLaidler]

For some purposes %re works just as well as %cw. It depends on what you need to do. There is also %eb and %tx.

[wahorger]

Paul, thanks for the suggestion.

My %cw windows is tied to the Fortran standard output unit for diagnostic and debugging messages, and for the user, to let them know when issues are detected.

So, no, the other options are not really applicable for me.

[wahorger]

"It's all a matter of time."

In my case, timing. To properly get an image from a simulated PrintScreen, sufficient time following the keyboard sequence must be allowed in order for the system to acquire the appropriate image.

The SLEEP1@() call was increased to 1 full second. I also bracketed the SLEEP1@() call with SET_CURSOR_WAITING@() calls to let the user know the image was being taken. This seems to solve the problems.

As a side note, EXPORT_IMAGE@() is stated as using the %gr drawing surface to a file. Unlike EXPORT_BMP@() which uses the HDIB to point to the memory that contains the DIB. When I tried using the EXPORT_IMAGE@() function, I saw no file created and no error thrown. My active window does not have a %gr area; this is what I anticipated.

[wahorger]

John, no, I could have saved to a GIF or PCX. These three file types appear to be the only ones that can used the HDIB handle and create the file.

I don't see any way to take an HDIB handle and create an internal DIB data array. If I could do that, then the number of options gets broader to include PNG and JPG as possible outputs. PNG is my preference.

[DanRRight]

Bill, I still do not get what do you want. Do you want the program which is independent of your program so that if your program crashes you can save the bug report? For that i use Snaggit which saves pictures or movies from any part of the screen you highlight with just one click before recording into MP4 file.

Or you want just to save the whole screen like PrintScreen is doing but different way through just one button or one combination of keys programmed by your own way in your own FTN95 program? In this case if your program crash you will not save any bug reports. But you still can save the bug report after you PrintScreen it usual Windows way and start your program again and save the clipboard information stored by PrintScreen into PCX and BMP files. I do that 25 years using Clearwin. Of course this one click saving of screen you made yourself for yourself is more convenient than a dozen of manipulations Windows way.

[wahorger]

Dan, no, and I see the confusion. First off, this capability is BUILT-IN to the program. I create a window AND a function key to take a snapshot. And, I name the image in my code ahead of time.

If I get an error (crash), my users are told how to take the information. Not that they actually do it, but they do sometimes. That is not what this capability is designed to do for me.

This is 2-fold capability.

For my users: If they have a screen/window they don't understand, they can get it, and send me the image. Not all of them are really computer savvy, and can included a clipboard image into an e-mail. Those that can, do just that. What can I say?

For me: As I modify/change the user interface, it is important to grab a screen shot for the on-line help documentation. With a specific name (the default is in my code). So my interface allows me to name each screen that can be grabbed by this method and save the image with the correct name for later inclusion. The latter part allows me to use my memory for other things!

That's what I am doing with it.

Bill

[DanRRight]

What could be done here more is to make instead of two steps save of the whole screen just one click save. Do anyone know what WinAPI command doing the action analogous to PrintScreen button push on keyboard which is to save the whole screen into clipboard?

Then instead of PrintScreen Button Push on keyboard + Save button Click on my program like i do today, i will just do one click and the whole screen will be saved into my preferred destination.

Additionally, i see that i have only 2 options to save - PCX and BMP. I did not touch this part for decades, do we have now PNG and JPG options as well?