It looks like the protected method FXFrame::drawFrame isn''t available
to my subclass of FXFrame. I suspect I need it, though.
My subclass of FXFrame is double-buffering. If I call "super" in my
onPaint method, FXFrame::onPaint erases the area onto which I am going
to blit the buffer, causing flicker. What I think I need is to call
FXFrame::drawFrame(dc, ...) when I''m constructing the image.
I got the idea of calling drawFrame from FX7Segment.cpp.
Is there another way to get FXFrame to draw the frame for me without
causing flicker?
I could just never mind the frame, as I don''t need it in this control.
It just seems like good (that is, unsurprising) design to do what
FXFrame does when subclassing it.
Fox 1.4.34, FXRuby 1.4.7, Debian testing.
Wayne Conrad
On Oct 22, 2006, at 11:28 AM, Wayne Conrad wrote:> It looks like the protected method FXFrame::drawFrame isn''t available > to my subclass of FXFrame. I suspect I need it, though.<snip> Yep. Because of how FXRuby works -- Ruby objects that are "peered" with C++ objects -- the protected and private methods aren''t visible from Ruby, even if you''re subclassing a FOX class. There is a workaround I can put in the code to make drawFrame() public, and I''ll be glad to do that for you in the next release if it helps, but it is of course not a general solution.
On Sun, Oct 22, 2006 at 12:32:57PM -0500, Lyle Johnson wrote:> There is a workaround I can put in the code to make drawFrame() > public, and I''ll be glad to do that for you in the next release if it > helps, but it is of course not a general solution.I didn''t figure there was a general solution. But to answer your question: Nobody''s income depends on being able to call that method. But the goofing around I''m doing would sure benefit from it. And, if the workaround is just ugly, it might not be worth it. I''d sure like it, though. Wayne Conrad