Albrecht: > I used your posted code unchanged under Windows (compiled with Cygwin/gcc), > and > it works and dumps the entire window in two pnm's (one chosen in the file > chooser, and "fig.pnm" when closing the window), no matter if a part of the > the > window is covered by the file chooser or not. This is true for FLTK 1.1 and > FLTK > 1.3 (current svn versions).
I just tested the code under Windows Vista, compiled using Dev-C++ and a devpak of FLTK 1.1.9. It worked perfectly. Some time ago I had a similar problem under Windows, I assumed (wrongly) that this time it would be the same: it was not. > I didn't find the time to test on Ubuntu though. Can you please tell us if you > can still see the problem on all your platforms (you wrote about Windows and > Ubuntu), or if this is platform dependent? If yes, then I might try to > reproduce > this on Linux (Ubuntu) as well. I don't remember that anything related has > changed between FLTK 1.1.9 and the current svn version(s), but can you also > try > the svn version or latest FLTK 1.3 snapshot and tell us what happens with > this? I could try FLTK 1.3 under Ubuntu, too. Ian: > Yes, although I'd really suggest that you override the draw() method > and do all the smarts in there - basically have it do the "ordinary" > stuff usually, and the "special" stuff to save the image only when a > capture is required. > I only suggest this because I have done this in the past and it > worked well... Worth a try, doubtless. >> Now the area of the main window which is covered by >> the Fl_File_Chooser when starting to save is dumped as a black region. > > That sounds very odd - this doesn't make much sense, really, as the > region that the file-chooser covered must surely be marked as > damaged, so it seems odd that it doesn't redraw...? As far as I can see, it is a Linux-related problem. I tried it at work (CentOS release 5.2 (Final)) and the results are the same as under Ubuntu. > OK, now that is very strange - I have had problems in the past with > grabbing images from the screen being elided by other windows, but > that's the whole point of the offscreen, of course, it should only > ever have the "wanted" drawing in it... Yes, it's dissapointing. >> I guess that a really quick-and-dirty solution would be to add >> a time delay before reading. > > Maybe, but that should not be necessary. I think understanding why > the offscreen doesn't do the Right Thing might be interesting too... Of course! :-) I mean, that's *the Right Thing*. Rodrigo _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
