Re: different handling of wxPaintEvent or scrolling in Linux and windows
Thomas Zehbe
> Thomas Zehbe wrote:
> > Am Mittwoch, 30. August 2006 17:29 schrieb Robin Dunn:
> >> The Panel's paint event is for painting on the panel, not the scrolled
> >> window. If you want to have the scrolled window updated correctly then
> >> you should give it a EVT_PAINT handler and draw the bitmap there.
> >
> > I already thought something like that. Adding the event handler to the
> > panel is just what happens when I use Dialogblocks generating handler
> > entries. So I'll have to subclass the scrolled window or push an event
> > handler.
> >
> > But what shouldn't work definitly works on Linux ...
>
> Probably because scrolling the scrolled window somehow causes the panel
> (or part of it) to be invalidated so your EVT_PAINT handler happened to
> be called at the right time to make it appear to be working properly.
Didn't expect it, but the story goes on. I subclassed a wxScrolledWindow with
an OnPaint handler and a zoom Method. Its added to a panels boxsizer with
wxGROW|wxALL options. Scrolling now works as it should in both Linux and
Windows.
But in the panel there is a slider to zoom the image from 1 to 200% of its
original size. This works as espected on Linux. This means that everytime the
sliders position is changed the picture is redrawn (posting a wxPaintEvent to
scrolled window in the zoom method).
On windows the image is only redrawn if the image/bitmap is smaller than the
visible portion of the scrolled windows in at least one direction. If I
continually enlarge it, the redraw stops just when the image in both
directions gets larger than the visble portion of the scrolled window.
I think that this is not what could be expected ...
Regards,
Thomas
--
Dipl.-Ing. Thomas Zehbe
INGENION GmbH
Kuhweide 6
31552 Apelern
Fon: 05043 / 40 57 90 4
Fax: 05043 / 40 57 90 7
Thomas Zehbe
I have a panel:
class igTeilOv: public wxPanel
{
DECLARE_DYNAMIC_CLASS( igTeilOv )
...
wich contains amongst other elements a wxScrolledWindow, on wich I paint an
image.
Thers is a registerd OnPaint() function:
BEGIN_EVENT_TABLE( igTeilOv, wxPanel )
...
EVT_PAINT( igTeilOv::OnPaint )
...
In the OnPaint() function a wxBitmap is created from the stored wxImage and
drawn to the wxPaintDC:
wxPaintDC dc(mDcPanel);
mDcPanel->DoPrepareDC(dc);
dc.DrawBitmap( wxBitmap(*mImage), 0, 0, true );
where mDcPanel is a Pointer to the wxScrolledWindow :-) (it's just a test
routine).
The virtual size of the scrolleWindow is set to the size of the picture which
should be rendered. If it's to large for the window scrollbars appear.
Under Linux the picture is automatically redrawn when it is scrolled. Under
Windows not.
Is it a bug or a feature? Do I something wrong?
Thomas Zehbe
> The Panel's paint event is for painting on the panel, not the scrolled
> window. If you want to have the scrolled window updated correctly then
> you should give it a EVT_PAINT handler and draw the bitmap there.
I already thought something like that. Adding the event handler to the panel
is just what happens when I use Dialogblocks generating handler entries. So
I'll have to subclass the scrolled window or push an event handler.
But what shouldn't work definitly works on Linux ...
Thanks,
Robin Dunn
The Panel's paint event is for painting on the panel, not the scrolled
window. If you want to have the scrolled window updated correctly then
you should give it a EVT_PAINT handler and draw the bitmap there.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn
> Am Mittwoch, 30. August 2006 17:29 schrieb Robin Dunn:
>> The Panel's paint event is for painting on the panel, not the scrolled
>> window. If you want to have the scrolled window updated correctly then
>> you should give it a EVT_PAINT handler and draw the bitmap there.
> I already thought something like that. Adding the event handler to the panel
> is just what happens when I use Dialogblocks generating handler entries. So
> I'll have to subclass the scrolled window or push an event handler.
>
> But what shouldn't work definitly works on Linux ...
Probably because scrolling the scrolled window somehow causes the panel
(or part of it) to be invalidated so your EVT_PAINT handler happened to
be called at the right time to make it appear to be working properly.
--