forums.silverfrost.com

[silicondale]

I have been using %gr with recover_dib_block@ / put_dib_block@ to copy the graphics window to a jpeg file, and write_graphics_to_gif@ to write to a gif file.

I tried the same thing with %pl (both Simpleplot and native versions) but of course this doesn't work.

Can anyone advise how to write a %pl graphics window to jpeg or gif (or any other graphics file format for that matter)? I know I could use standard screen-grab programs to do the job but that is messy.

Would be good to have some general way of writing the contents of ANY graphic or text window to a graphics file. Perhaps it already exists but I've overlooked it?

[JohnCampbell]

I would recommend to use a .png format, rather than .gif, as the colour palette that is reproduced is much better.
The following code works for me for a %gr region, where the approach is for the "active selected region". This may be applied to the %pl region via i = select_graphics_object@ (w_handle), where w_handle is an I*4 handle provided to %gr. There may be an equivalent to %pl ?

[silicondale]

Thanks for the quick reply, John. The only reason for GIF as an option is user demand. I also prefer PNG. I'll try out that code, but as you say it's probably dependent on being able to get a handle for the %pl graphics region

[Kenneth_Smith]

This should work as John has suggested.

Hidden at the bottom of the %pl help file (Paul had to point me to this):-

%`PL provides for a user indentifier for the %PL control that can be used in a call to SELECT_GRAPHIC_OBJECT@ but this call is not needed within a %^PL callback because the corresponding object will already be selected.

I have been able to dump %pl graphics simply using the call back function when the user right clicks on the %pl region.

[silicondale]

Magic! Inserted the code into my program and it worked a treat. I had been hitting my head against a brick wall with the DIB_BLOCK calls giving access violations. Many thanks, John.

Ken - yes, I saw that bit about %`pl but couldn't find any other documentation for it. So I put it in my %pl call and added an 'ighandle' argument at the end of the argument list - it didn't seem to object to that.

Now I just have to join the rest of you tackling the bugs in the native %pl.

[silicondale]

Hi John-S

I can see the problems in producing a completely general 'export image' functionality, as you've pointed out! However, a simple-minded approach would be to export everything which is currently visible within the window, i.e. including any %gr-style child windows, text content, controls. Menus (in the menu bar at the top of the window) aren't generally going to be visible within the window if not being used at the time.

There is also the case of scrolling - anything that is scrolled out of view probably should not be exported - because it wouldn't fit within the window area! Of course for a Clearwin text window (such as the Fortran standard output stream) this can be done easily using get_clearwin_text@

So what I suggest is basically a "snapshot" capture of everything tat the user sees in the window, and nothing else.

[JohnCampbell]

My screen dump code has stopped working at Ver 8.20 /64.
Reverting to 8.10 /64 and it all works ok.

After calling Subroutine Dump_jpg_func, the .png file is successfully created (error_jpg = 1), then the screen is updated with the message, then the program hangs. Lots of scope for where the problem could be, but I suspect :
error_jpg = export_image@ (file_jpg)

Any ideas ?

John

[PaulLaidler]

John

I you can send me a demo then I will aim to identify the problem.

[JohnCampbell]

Hi Paul,

I tried the program the next day (after restarting pc) and it worked ok !!
Clearly there was something that hung up the main menu thread, but it may have not been dumping a .png file dump.
At the moment it is not reproducible so I will keep more details if it happens again.

John

[JohnCampbell]

I am still getting this intermittent error, but not every time.
Using /64 version, after I select to dump the %gr region to .png file,
the return is error code = 1, then I report this to my .log file and control sort of returns to the %mn menu,
I can click on the menu or sub menus, but nothing works.
Other times all is ok, so not sure what is causing the hang.
I have not been changing this large program lately, so will take some time to get up to speed on what is happening.
Most of my interrupt functions return =1, although I notice there are =2 being discussed. Should I review this ?

John

[PaulLaidler]

John

Callback functions should normally return 2 unless you want the screen to update because of changes made within the callback. For an screen update return 1.

If you have a program that occasionally fails and you are able to make it available for testing then I could try it and maybe take a look to see if there is something that could be going wrong.

[JohnCampbell]

Paul,

I shall review the interrupt functions that return to the menu and check their return values. (Are return values described in ftn95.chm ?)

Then if I can get a version that can repeat the failure then I will package up and send. There are about 250 .f90 file in the build, but hopefully the problem is limited to the .png file dumping and menu management (only a few) files.
It looks as if control is not being properly returned to the menu (thread?).
If the problem could be outside the .png routines, possibly in the image generation then I think I've found another breakout of Dan's devilry.

John

[PaulLaidler]

ftn95.chm>Clearwin+>Format Windows>Callback functions.

[JohnCampbell]

I have made a first pass at generating a simple test program, with %gr window and a few %mn options.
Runs no problems in Ver 8.20 !!
Not a simple error with export_image@

I need to make it more complex example or identify my program bug.

[JohnCampbell]

Paul,

I have checked the compile options I am using. I have a mix of:
/64
/window /64
/window /64 /inhibit_check 16

The start of the build .bat is: