| |
| |
Implementing resume() is easy as it is a method of the printer class. Both functions are one-liners that will be inlined by the compiler, so they really only are a shortcut in the header.
I am still torn if it should be push(screen)/pop() or pop()/push(printer). If the pushed context is a another surface, the second solution would be wrong. So Fl_Printer::suspend() { Fl_Surface_Device::push_current(Fl_Display_Device::display_device()); } Fl_Printer::resume() { Fl_Surface_Device::pop_current(); } are a good solution IMHO to hide the surface handling if a user absolutely must call Fl::wait() for some reason.
So, yes, that would be Manolo's suggestion.
Thanks all for looking into this! Albrecht Schlosser schrieb am Montag, 13. Juni 2022 um 18:23:56 UTC+2:
On 6/12/22 13:40 'melcher....@...' via fltk.coredev wrote:
As Manolo wrote, adding
Fl_Surface_Device::push_current(Fl_Display_Device::display_device());
before Fl::wait(); and
Fl_Surface_Device::pop_current();
after Fl::wait(); would work. So, to answer the "other" question: if we added such new methods I'd
suggest to `pop` the drawing context in `suspend()` and `push` the
printer context in `resume()`. This would make these methods independent
of the "previous" context - which would be very likely but not
necessarily the "display" context.
I have no idea how to implement such a `resume()` method that would push
the pre-existing printer context back on the stack but I guess Manolo
would know?
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/8100ce56-1e09-472f-bde5-9bb4ea5f81a4n%40googlegroups.com.
[ Direct Link to Message ] | |
|
| |
