RE: [gtkmm] textbuffer's signal_erase

[Joshua A Gagnon <gagnon WPI EDU>]

It's funny that you would say that. I tried subclassing the TextBuffer
since the docs said then you had the choice of whether your code when
before or after the gtkmm code. That would definitely solve the problem,
but I ran into the problem you forsaw with the RefPtr. Much googling
couldn't find a way to subclass something with a RefPtr. I got stuff that
compiled, but didn't seem to do anything. A cout statement in the
destructor didn't even fire. It seems like I need to override the create()
method, but I have know clue how to do that!! I think you've got the right
idea though, once we know how to execute it.

On Wed, 13 Aug 2003, joey yandle wrote:

> I had similar issues with TreeView and drag'n'drop.  If I connected to the
> signals, then by the time the signal fired things had already changed out
> from under me.  But if I subclassed and overrode the vfunc, things worked
> as expected.
>
> So my suggestion would be to subclass TextBuffer.  This will be a little
> weird, since it's a RefPtr/create style class; Murray, is this doable?
>
> _________________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
>