Re: [glade--]Treeview->signal_select_cursor_row not written properly, but what is proper?

Mark Jones schrieb:
> I have a tree view.  I wanted to have a signal for when a row is
> selected.  So the best signal I saw was select_cursor_row, so I put that
> on it in Glade.  glade-- generates code that does not compile though.

I'd vote for
   treeview1->get_selection()->signal_changed().connect(...)

> 
> The code it generates:
> 
> myTreeview->signal_select_cursor_row().connect(SigC::slot(*this,
> &myDialog_glade::on_myTreeview_select_cursor_row));
> 
> The compiler error:
> 
> no matching function for call to 
> `Glib::SignalProxy1<void, bool>::connect (SigC::Slot0<void>)'
> /usr/include/gtkmm-2.0/glibmm/signalproxy.h:134: candidates are:
> SigC::Connection Glib::SignalProxy1<R, 
> P1>::connect (const SigC::Slot1<R, P1> &, bool = true) [with R = void,
> P1 = bool]
> 
> I tried playing with it, but could not find a good combination that
> worked.  

fixed in CVS, look into treeview.cc when you want to learn how to do this.

> 
> There are two issues:
> - how to do that properly
see above
> - using that, a fix for glademm
fixed.

> Anyone know how to connect to that signal?

by hand :-( . If you propose a way to specify that you want the 
selection's changed signal to get connected to, I'd happily implement 
the code generation part. Specifying "get_selection()->changed" might be 
an idea, or "selection:changed" (which both translate to illegal C 
code). I wonder how glade manages this in C code.

    Christof