wxruby development - Sep 2006 - ObjectPreviouslyDeleted when trying to paint

Hi,

I''m running into something along the lines of bug 5383. I''m
hoping I''m
doing something obviously wrong and that someone can point me in the
right direction.

I''ve got a custom paint event handler:

  def on_paint
    puts "mainframe on_paint"
    paint do |dc|
      dc.clear
      @cl.draw dc
    end
  end

Then I''ve got a key press handler that changes @cl and calls refresh
on the frame to get it to redraw. Without calling refresh, things seem
to be fine. (Although obviously my app doesn''t display the changed
state.) With the refresh, I get:

mainframe on_paint
./View/mainframe.rb:79:in `clear'': in method ''Clear'',
argument 1 of
type ''wxWindowDC *'' (ObjectPreviouslyDeleted)
        from ./View/mainframe.rb:79:in `on_paint''
        from ./View/mainframe.rb:78:in `paint''
        from ./View/mainframe.rb:78:in `on_paint''
        from ./View/mainframe.rb:29:in `initialize''
...

Anyone have an idea of what might be going on? Is there a "better" way
to trigger the redraw?

Thanks in advance,

-- 
Toby Butzon

Toby Butzon wrote:
> mainframe on_paint
> ./View/mainframe.rb:79:in `clear'': in method
''Clear'', argument 1 of
> type ''wxWindowDC *'' (ObjectPreviouslyDeleted)
>         from ./View/mainframe.rb:79:in `on_paint''
>         from ./View/mainframe.rb:78:in `paint''
>         from ./View/mainframe.rb:78:in `on_paint''
>         from ./View/mainframe.rb:29:in `initialize''
> ...
> 
> Anyone have an idea of what might be going on? Is there a
"better" way
> to trigger the redraw?
As far as I know, you are doing everything exactly right.

I have seen the same problem, but haven''t yet had time to debug it. It 
seems to be a bug in paint (which we added as a bit of sugar on top of 
raw wx), so you should be able to work around it for now by creating 
your own PaintDC inside your on_paint method. This might cause a memory 
leak (not certain) so when paint is working again your should switch 
back to it.

In your case, something like:

   def on_paint
     puts "mainframe on_paint"
     dc = Wx::PaintDC.new(self)
     dc.clear
     @cl.draw dc
   end


Kevin

This one seems like really high priority, since it is a feature specific 
to wxruby. If we want people to do things "the right way", we should 
indoctrinate them from the start. Probably a release blocker for 0.0.38 
(not for 0.0.37 because I still think we should push that one out asap 
to avoid confusion with the 2 different .36 gems floating around).

This paint thing used to work, so I''m hoping it will be an easy fix. I 
just haven''t had a chance to look at it. Maybe this weekend.

Kevin


Kevin Smith wrote:
> Toby Butzon wrote:
>> mainframe on_paint
>> ./View/mainframe.rb:79:in `clear'': in method
''Clear'', argument 1 of
>> type ''wxWindowDC *'' (ObjectPreviouslyDeleted)
>>         from ./View/mainframe.rb:79:in `on_paint''
>>         from ./View/mainframe.rb:78:in `paint''
>>         from ./View/mainframe.rb:78:in `on_paint''
>>         from ./View/mainframe.rb:29:in `initialize''
>> ...
>>
>> Anyone have an idea of what might be going on? Is there a
"better" way
>> to trigger the redraw?
> 
> As far as I know, you are doing everything exactly right.
> 
> I have seen the same problem, but haven''t yet had time to debug
it. It
> seems to be a bug in paint (which we added as a bit of sugar on top of 
> raw wx), so you should be able to work around it for now by creating 
> your own PaintDC inside your on_paint method. This might cause a memory 
> leak (not certain) so when paint is working again your should switch 
> back to it.
> 
> In your case, something like:
> 
>    def on_paint
>      puts "mainframe on_paint"
>      dc = Wx::PaintDC.new(self)
>      dc.clear
>      @cl.draw dc
>    end
> 
> 
> Kevin
> 
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users

Kevin Smith wrote:
> This one seems like really high priority, since it is a feature specific 
> to wxruby. If we want people to do things "the right way", we
should
> indoctrinate them from the start. Probably a release blocker for 0.0.38 
> (not for 0.0.37 because I still think we should push that one out asap 
> to avoid confusion with the 2 different .36 gems floating around).
>
> This paint thing used to work, so I''m hoping it will be an easy
fix. I
> just haven''t had a chance to look at it. Maybe this weekend.
>
I think it''s just more of our memory management issues.

Kevin Smith wrote:
> This one seems like really high priority, since it is a feature specific 
> to wxruby. 
I agree this should be a high priority fix. Rather than waiting around 
trying to fix the SWIG wrapper, how about redoing this method in Ruby, 
something like (untested):

def paint
  yield Wx::PaintDC(self)
end

It would leave us with a possible memory leak, but that''s something we 
need to address more generally down the line. Perhaps better than 
carrying along a crasher?

alex

Alex Fenton wrote:
> I agree this should be a high priority fix. Rather than waiting around 
> trying to fix the SWIG wrapper, how about redoing this method in Ruby, 
> something like (untested):
> 
> def paint
>   yield Wx::PaintDC(self)
> end
Brilliant. As long as we remember to do the right thing eventually, I 
would be very happy with this approach as a short-term solution.

Thanks!

Kevin