It looks like it does, I'm pretty sure this happens in the
`panzoomarea_class_.init()` call:
~~~
PanZoomArea::PanZoomArea()
: // Mark this class as non-derived to allow C++ vfuncs to be skipped.
Glib::ObjectBase(nullptr),
Gtk::DrawingArea(Glib::ConstructParams(panzoomarea_class_.init())) {}
~~~
Which I've also pasted here:
~~~
const Glib::Class& PanZoomArea_Class::init() {
if (!gtype_) // create the GType if necessary
{
// Glib::Class has to know the class init function to clone custom
types.
class_init_func_ = &PanZoomArea_Class::class_init_function;
// This is actually just optimized away, apparently with no harm.
// Make sure that the parent type has been created.
// CppClassParent::CppObjectType::get_type();
// Create the wrapper type, with the same class/instance size as the
base
// type.
register_derived_type(gtk_panzoom_area_get_type());
// Add derived versions of interfaces, if the C type implements any
// interfaces:
}
return *this;
}
~~~
On Fri, May 1, 2020 at 3:08 PM Daniel Boles via gtkmm-list <
[email protected]> wrote:
> How does your generated constructor look? Does it register the new type
> with GObject?
>
> _______________________________________________
> gtkmm-list mailing list
> [email protected]
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>
_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
