> > > 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.
Yes, they are ugly ... but would this be the only way to go? > > 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. Aha, well, this way it makes sense ... i felt confused, it's not stated anywhere > > 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. Well, I was trying exactly this, to trigger draw() at the group widget holding the complex structure, but I get a weird compile error ... > > 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. " Thanx! I couldn't figure it out. btw, int X, int Y, are the coordinates where fl_read_image starts to read and int W, int H are the width and height, I suppose ... documentation bug? well, this will be the pixmap then. but what is it then a Fl_Offscreen variable? this is just typed as ulong, I can't figure out its real meaning _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
