Re: [fltk.general] capture widget image -> minimal example

[MacArthur, Ian (SELEX GALILEO, UK)]

> > That is exactly what x.H does - it is a wrapper for the appropriate
> > platform-specific content. So you should include x.H on any 
> platform,
> > and the appropriate (X11, win32, OSX) stuff will then be included.
> 
> Ok, but this looks to me counter-intuitive ... I'd expect to 
> include win32.h when programming for windows, x.h for Linux 
> and so on, including win32.h when programming in Linux isn't 
> straightforward to me, nor it is to include x.h when 
> programming in windows ... 

But then you need to ifdef, which is not acceptable.

> I'm doing cross-platform 
> programming, so this happens. 

Sure, we all are, that's why we are here.

> Actually I'd like to include 
> one single graphics-layer.h which prepares everything for me.

Yes, that is correct. A single file that is used on *all* platforms is
definitely the way to go.
And that single file just happens to be called x.H - don't think of it
as being *nix specific (then it might have to be called X11.H anyway!)
rather it might be a shorthand for "eXtensions.H" or something.


> The point here is: is my complex widgets hierarchy held by 
> maxTreeContentScrollWindowGroup really redrawn? or does 
> redraw() do something else?

Redraw doesn't draw anything - it sets the damage flags, so that the
fltk core knows that a widget needs to be redrawn. Calling it from
within a draw method is unlikely to do what you intend, I think. 

I think you might be able to make your approach work by starting the
offscreen, then clearing your boolean and directly calling the widget
::draw() method again.
Then, when that returns, reset the boolean and end the offscreen.
Well, maybe that can work.



> another question is: how can I access the bitmap/pixmap held 
> by the offscreen? so far is fl_copy_offscreen copying back to 
> the screen, but I'd like to copy such a bitmap to some 
> library like libpng to save it to a file, but the real data 
> structure is hidden ... the  Fl_Offscreen turns out to be a 
> ulong (why?), so where is the real offscreen data?


You want fl_read_image().

>From the docs:

" Direct Image Reading

FLTK provides a single function for reading from the current window or
off-screen buffer into a RGB(A) image buffer.

uchar *fl_read_image(uchar *p, int X, int Y, int W, int H, int alpha =
0);

Read a RGB(A) image from the current window or off-screen buffer. The p
argument points to a buffer that can hold the image and must be at least
W*H*3 bytes when reading RGB images and W*H*4 bytes when reading RGBA
images. If NULL, fl_read_image() will create an array of the proper size
which can be freed using delete[].

The alpha parameter controls whether an alpha channel is created and the
value that is placed in the alpha channel. If 0, no alpha channel is
generated. "





SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 
3EL
A company registered in England & Wales.  Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk