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?

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 ?

    Subroutine Dump_jpg_func (message, prefix, ext)
!
!  dumps a .jpg, .png or .pcx file from active selected region
!
!    use mswin
    include <clearwin.ins>
!
    character message*(*), prefix*(*), ext*4
!
    integer*4 error_jpg, file_nn, nx, ny
    character file_jpg*80
    data file_nn / 0 /
!
!    develop a screen dump file name
!
      call get_next_dump_file (file_nn, file_jpg, prefix, ext)
       if (file_nn > 999) then
         error_jpg = -999
         goto 100
       end if
      write (*,*) 'Dumping screen to ',trim (file_jpg)
!
      error_jpg = export_image@ (file_jpg)
!
  100 call get_graphical_resolution@ ( nx, ny )
!
      write ( *,1000) ext, trim(file_jpg), nx, ny, error_jpg
      write (98,1000) ext, trim(file_jpg), nx, ny, error_jpg
 1000 format (a,' DUMP file ',a,  &
              ' Size : ',i0,' x ',i0,' (error=',i0,')')
!
      if (error_jpg > 0) then
         message = ext//' dump to '//file_jpg
      else if (error_jpg == -999) then
         message = 'Unable to open '//file_jpg
      else
         message = 'Unable to use '//file_jpg
      end if
!
      end subroutine Dump_jpg_func
 
      subroutine get_next_dump_file (file_nn, file_name, prefix, ext)
!
!    develop a screen dump file name
!
    integer*4 file_nn
    character file_name*(*), prefix*(*), ext*4
    integer*4 lu, get_file_unit
    external  get_file_unit
!
      lu = get_file_unit (90)
      close (unit=lu)
!
   11 file_nn = file_nn + 1
      if (file_nn > 999) return
!
      if (len_trim (prefix) > 0) then
         write (file_name, '(a,i3.3,a)') trim(prefix) // 'dump', file_nn, ext
      else
         write (file_name, '(a,i3.3,a)') 'dump', file_nn, ext
      end if
      open  (unit=lu, file=file_name, status='new', err=11)
      close (unit=lu, status='delete')
      end subroutine get_next_dump_file

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

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.

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. 😃 😉

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.

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

John

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

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

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

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.

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

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

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.

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: rem build del *.obj del *.mod del saplot.exe

build_stamp

rem  menu routines

ftn95 ceasap_module        /64 >>ftn95.tce
ftn95 saplot       /window /64 /inhibit_check 16 >>ftn95.tce
ftn95 saplot_menu  /window /64 /inhibit_check 16 >>ftn95.tce
ftn95  open        /window /64 >>ftn95.tce
ftn95  range       /window /64 >>ftn95.tce
ftn95  input       /window /64 >>ftn95.tce
ftn95  view        /window /64 >>ftn95.tce
ftn95  rotate      /window /64 >>ftn95.tce
ftn95  dummy       /window /64 >>ftn95.tce
 
rem  input routines

ftn95 sapinput             /64 >>ftn95.tce
ftn95  joints              /64 >>ftn95.tce
ftn95  read_joints         /64 >>ftn95.tce
...
ftn95 dump             /windows /64 >>%tce%
...

My question is: When do I need to use the /window option ?

In this context I think that you will need to use the SLINK64 /windows option.

With SLINK the option can usually be passed via FTN95 but not with SLINK64.

/windows is essentially a linker option. It sets a flag in the header of the executable.

Paul,

I have looked into the problem and I think I can say.

there is a stack corruption, as the return to the menu hangs; changing the return status =0,1 or 2 has no effect.

removing export_image@ does not change the error, so not the problem.

my routine to generate the .png file name is causing the problem.

On closer inspection, the code is a bit ugly, with a lack of iostat= options, then deleting then re-opening a file. As bad as it is, I thing Ver 8.20 fails with this. I shall change to using INQUIRE to test for file existence and see what happens. subroutine get_next_dump_file (file_nn, file_name, prefix, ext) ! ! develop a screen dump file name ! integer4 file_nn character file_name(), prefix(), ext4 integer*4 lu, get_file_unit external get_file_unit ! lu = get_file_unit (90) close (unit=lu) ! 11 file_nn = file_nn + 1 if (file_nn > 999) return ! if (len_trim (prefix) > 0) then write (file_name, '(a,i3.3,a)') trim(prefix) // 'dump', file_nn, ext else write (file_name, '(a,i3.3,a)') 'dump', file_nn, ext end if open (unit=lu, file=file_name, status='new', err=11) close (unit=lu, status='delete') end subroutine get_next_dump_file

The above fails with Ver 8.20 but not 8.10, while the new code works ! INQUIRE (FILE=file_name, EXIST=exist, OPENED=opened, IOSTAT=iostat)

John