Is there a need for this capability?

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

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.

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.

	winapp
	PROGRAM MAIN
        use mswin
        integer:: i,j,width,height
        i = winio@('This is a test%lw',j)
	call keybd_event(VK_MENU, 0, 0, 0)!; //Alt Press
	call keybd_event(VK_SNAPSHOT, 0, 0, 0)!; //PrntScrn Press


	call keybd_event(VK_SNAPSHOT, 0, KEYEVENTF_KEYUP, 0)!; //PrntScrn Release
	call keybd_event(VK_MENU, 0, KEYEVENTF_KEYUP, 0)!; //Alt Release
        call sleep1@(0.5) ! this was 0.1 in the 'C' program
        if(sizeof_clipboard_bitmap@(width,height).ne.0) then
		print *,width,height
        	pause
        endif
        end

There are some things about this that don't quite work in the 'real world' testing as I'd like. It seems I have to do the control sequence twice to get the first one done. It is like the first set of sequences gets 'lost'. But, after the first one, it all seems to work just fine. It might be that I am pressing the keys when the accelerator is recognized (CTRL+SHIFT+F8), and if I choose a different key sequence (a single F key perhaps), it will work more reliably. I may need to flush the keyboard buffer before I simulate the screen grab. etc. etc.

And, maybe this has some other unintended consequences. I'll let you know what I find!

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

Bill

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

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

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!

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.

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

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.

'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.

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.

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.

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

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?

My approach is a 'DUMP' menu option which dumps a .png file of the active window using export_image@ (file_png), where file_png is an automatically generated file name with an optional extension of .png, .jpg, .pcx, .gif or .bmp. (check the latest documentation for export_image@)

I do find that .png is the best option and is what I always select.

'automatic' name generation can be a problem, as you can forget what file name refers to what image, which Bill did indicate he has better addressed.

Dan, what I did is exactly what you describe, but I assigned a function key to the callback. And, yes, currently for a non=%gr window, you have to emulate the Alt+PrntScrn key sequence (with delays), then can save only as BMP or PCX. Paul has said that PNG will be added at the next release.

John, from the documentation, the export_image@() is useful only for graphics windows (%gr) which I am not using. Therefore PNG etc. are not available to be saved. I did try the export_image@() call in my code (JIC), but nothing was saved and there was no error message or fault detected.

Here's a stripped down version of how I have the Alt+PrntScrn working.

        call keybd_event(VK_MENU,       z'45', KEYEVENTF_EXTENDEDKEY,                   0)!; //Alt Press
        call keybd_event(VK_SNAPSHOT,   z'45', KEYEVENTF_EXTENDEDKEY,                   0)!; //PrntScrn Press


        call keybd_event(VK_SNAPSHOT,   z'45', KEYEVENTF_KEYUP+KEYEVENTF_EXTENDEDKEY,   0)!; //PrntScrn Release
        call keybd_event(VK_MENU,       z'45', KEYEVENTF_KEYUP+KEYEVENTF_EXTENDEDKEY,   0)!; //Alt Release

        call set_cursor_waiting@(1)
        call sleep1@(2.0) ! sleep long enough to allow the image to be grabbed from the open window
        call set_cursor_waiting@(0)

        my_error=sizeof_clipboard_bitmap@(actual_width,actual_height) ! will detect if the capture actually did work
        if(my_error.ne.0) then ! the capture worked
                if(clipboard_to_screen_block@(hdib).ne.0) then ! this does the grab into local memory
                        call export_bmp@(hdib,NEW_FILENAME,my_error)
                        call release_screen_dib@(hdib) ! release the memory  clipboard_to_screen_block@()
                endif
        endif

Bill

Can you remind me about what is missing.

Paul,

I believe export_png@() and export_JPG@() using the arguments for HDIB, file name, and error code would be most helpful to round out the capability.

Bill

Thanks. I have made a note of this request.