forums.silverfrost.com

[Kenneth_Smith]

I don�t normally use an external monitor with my laptop, and I received some feedback from a user who does.

The following program creates a %gr region and has some controls to the right of this.

There is a menu item �To clipboard� which copies the whole window to the clipboard.

This works so long as the user has not moved the window onto a second display i.e. large monitor.

If the window is on the large monitor, the �To clipboard� operation does not capture the correct parts of the monitor display i.e. EXPORT_WINDOW_IMAGE@ fails in this scenario.

Is there a simple fix to this?

[Kenneth_Smith]

Here is a link to two images for the two scenarios described above:

https://www.dropbox.com/scl/fi/m0b9l1vkyu6oz4fclcbg9/example.pdf?rlkey=5nx1g978s847lp1ucley1vkgo&st=lk0fjqtt&dl=0

[JohnCampbell]

Ken,

It has been a long time since I wrote this code (~2005), but I recall I overcame this secondary screen problem by providing a window handle then selecting the graphics region I wanted to populate then dump.

The main %gr window was numbered by
i = winio@ ('%hw', hw_handle) ! return the handle of the current window.

However if I use other secondary (virtual) windows, then I have
handle(ii) = ii+10
i = create_graphics_region@ (handle(ii), nxpix+11, nypix+35)
i = select_graphics_object@ (handle(ii))

I then selected the window I wanted to be active and dumped to the file type with:
error_jpg = export_image@ (file_jpg) ! use .png format

The multiple secondary windows can be used to draw then display sinusoidal motion.

I don't recall the second physical screen being a problem. It must be in focus / selected.

I also utilised this approach for higher resolution dumps, by creating a larger
virtual graphics region (with a different handle) then selecting, then populating and finally dumping.

My graphics approach is to use a virtual screen of both 2d arrays for integer*1 pixel colour index ( up to 127 or 255 colours) and real*4 pixel depth to provide hidden line removal, then finalise by dumping the integer*4 pixel colours to the select_graphics_object@
These virtual screens were created large enough for the virtual size (4000 x 3000 at the time). This was all done before /64.
(when updating it was important to scan the screen in a contiguous way; I used by "y" and the arrays were transposed )

The approach of first selecting either %gr or virtual window, then exporting has worked with no problem.

[Kenneth_Smith]

John,

Thanks for your comments and observations.

EXPORT_WINDOW_IMAGE@ is a relatively new feature which allows you to capture the whole window including controls that surround the graphics region.

Here is the window I am trying to capture:

https://www.dropbox.com/scl/fi/b4ab0xr4jf4fwt4zaren3/Hist.jpg?rlkey=lltagidhpx600r5m6bdwe2i2s&st=59bnpptg&dl=0

There is an %ob2.1[invisible], the %pl graphics region is in the left box and in the right box I have a long list of information providing data using %`rf.

At first glance it appears that this information has been written to the right margin of a %pl region but this is not the case.

Nesting all these outputs via %`rf simplified the initial programming (I was being lazy) and all appeared to work fine a few months back when I wrote this program having just found EXPORT_WINDOW_IMAGE@ in cwplus.enh (no pivot on the %pl so no problems with these elements sliding downward).

Now I fear I may need to revise the code, remove all the %`rf and add all this information in a larger right margin within the %pl callback via DRAW_CHARACTERS@. I can then avoid the use of EXPORT_WINDOW_IMAGE@

So not quite the same as what you describe.

[PaulLaidler]

Ken

I have tested your program and it works for me. I use two monitors and it works both ways, when the slave monitor is to the right and when it is to the left.

When grabbing the client window, EXPORT_WINDOW_IMAGE@ calls

[Kenneth_Smith]

Paul,

Thanks for confirming that the sample program works correctly for you.

Encouraged by this I interrogated the system settings this morning, and I see there is an option:

System > Display > Scale & layout where scale was set at 125% (Recommended!)

When I change this to 100%, the issue with EXPORT_WINDOW_IMAGE@ vanishes . All other available settings (125%, 150%, 175%) have problems when the window is moved on to the external monitor.

I guess 125% is the default factory setting, as I don�t recall changing this.

Ken

[PaulLaidler]

Ken

I also see the fault when using a display scaling factor that is not 100%.

One way to fix this is to call

[Kenneth_Smith]

Paul,

Thanks for the one line fix.

This works well in my application: