Re: signal on selecting a row in TreeView
Praveen, Connect a function with following prototype to signal_changed of Gtk::TreeView void YourClass::YourFunction(void) This function is going to be called each time there is a change in selection (for multiple selections as well) You might want to consider using Gtk::Selection (RefPtr returned from a called to YourTreeView.get_selection()) if you have multiple selection enabled for the tree view. You'll find the above story in better detail in the link below. http://developer.gnome.org/gtkmm-tutorial/3.0/sec-treeview-selection.html.en (Its the same for Gtkmm 2.x as well) regards Mohith Manoj, Asst. Manager (RD), Skanray Technologies PVT.LTD Web: www.skanray.com Mob: +919886742571 Ph : +918212415559 Fax: +918212403344 On 16 August 2012 11:09 AM, Praveen Tiwari wrote: Can any body help me to figure out the name of the signal raised on selecting a row (single click on row) in a TreeView, i am using Liststrore as a model . Thanks in advance ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: signal printing to terminal
On 02/05/2012 04:59, Jamie Lahowetz wrote:
This is probably a fairly easy question but Im very new to c++ and gtkmm and
am
trying to connect a signal to a glade created entry. when return is pressed
the
text is grabbed from the entry and displays in the terminal... only nothing
happens. A little help would be nice as to what im doing wrong. Thank you.
It looks like you're trying to retrieve a widget from Gtk::Builder and use a
derived class to handle it... only that you're not hooking it all up properly,
so Gtk::Builder does not know about your derived class at all.
Looking at the Gtkmm documentation, it looks like
Gtk::Builder::get_widget_derived() is what you want, rather than
Gtk::Builder::get_widget().
main.cpp:
#include gtkmm.h
#include iostream
#include terminal.h
int main(int argc, char *argv[])
{
//required to start application methods
Gtk::Main kit(argc, argv);
Gtk::Window *mainwindow;
Try using MainWindow *mainwindow; here..
//Load the GtkBuilder file
Glib::RefPtrGtk::Builder refBuilder = Gtk::Builder::create();
try
{
refBuilder-add_from_file(
hprcc.glade);
}
catch(const Glib::FileError ex)
{
std::cerr FileError: ex.what() std::endl;
return 1;
}
catch(const Glib::MarkupError ex)
{
std::cerr MarkupError: ex.what() std::endl;
return 1;
}
catch(const Gtk::BuilderError ex)
{
std::cerr BuilderError: ex.what() std::endl;
return 1;
}
//get the main window widget
refBuilder-get_widget(mainwindow, mainwindow);
and get refBuilder-get_widget_derived (mainwindow, mainwindow);
//start the event loop
kit.run(*mainwindow);
return 0;
}
[...]
--
Kind regards,
Loong Jin
signature.asc
Description: OpenPGP digital signature
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
RE: Signal dispatching slowed down after upgrade
From: BALLABIO GERARDO From: Krzysztof Kosiński [mailto:tweenk...@gmail.com] The slowdown is not caused by signal emission, but by modify_bg. If you write a custom expose handler that draws the cells, the updates are instantaneous. See the attached file. Wow. I still don't understand why modify_bg would be that slow, but at least I can work around it, so thank you. I think now I understand. I guess that modify_bg doesn't just change the background of the widget, but also sends an expose event to have it redrawn. Indeed I removed the queue_draw() call from my example and the cells still get updated. So if I change the background of 400 cells, 400 expose events are queued and it takes quite a lot of time to process them. (Yet the previous Debian release did it much faster, and I don't think it's a theming issue, I'm using the same standard Clearlooks theme, as far as I can see only the wallpaper has changed. So I'd still think it's a regression.) Is there a way to merge all those events into a single one? I suppose that would give a major speedup. Also, can anybody answer my further question (quoted below)? But now I have another question. If I move the pointer around with no buttons pressed, the cells change color every time it enters a new cell. But if I press any button and move the pointer while keeping it pressed, then nothing happens any more. Only when I release the button the cell where the pointer is at that moment is activated. In other words, it seems that pressing buttons inhibits the generation of enter_notify events. I've tried also with pointer_motion events, but it does exactly the same thing (except it doesn't activate the cell even when I release the button). I want the program to behave in the same way whether buttons are pressed or not. How can I do that? Thank you Gerardo ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
RE: Signal dispatching slowed down after upgrade
From: Krzysztof Kosiński [mailto:tweenk...@gmail.com] The slowdown is not caused by signal emission, but by modify_bg. If you write a custom expose handler that draws the cells, the updates are instantaneous. See the attached file. Wow. I still don't understand why modify_bg would be that slow, but at least I can work around it, so thank you. But now I have another question. If I move the pointer around with no buttons pressed, the cells change color every time it enters a new cell. But if I press any button and move the pointer while keeping it pressed, then nothing happens any more. Only when I release the button the cell where the pointer is at that moment is activated. In other words, it seems that pressing buttons inhibits the generation of enter_notify events. I've tried also with pointer_motion events, but it does exactly the same thing (except it doesn't activate the cell even when I release the button). I want the program to behave in the same way whether buttons are pressed or not. How can I do that? Thanks again. Gerardo ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal dispatching slowed down after upgrade
2011/2/14 BALLABIO GERARDO gerardo.balla...@esterni.gruppo.mps.it:
Hi all,
in the last weekend I upgraded my computer to the new stable version of
Debian (version 6.0.0, released a few days ago). After the upgrade, a gtkmm
program of mine has become less responsive to the point of being barely
usable. Apparently the dispatching of signals is now much slower than it used
to be, and when a lot of them are connected (in my program there are more
than 100), it becomes very noticeable.
The slowdown is not caused by signal emission, but by modify_bg. If
you write a custom expose handler that draws the cells, the updates
are instantaneous. See the attached file.
Regards, Krzysztof
#include gtkmm.h
class Cell : public Gtk::EventBox
{
private:
int number;
protected:
sigc::signalvoid, int activate;
virtual bool on_enter_notify_event(GdkEventCrossing *event)
{ activate.emit(number); return true; }
virtual bool on_expose_event(GdkEventExpose *event)
{
Glib::RefPtrGdk::Window window = get_window();
if (!window) return true;
Cairo::RefPtrCairo::Context cr = window-create_cairo_context();
if(event) {
cr-rectangle(event-area.x, event-area.y,
event-area.width, event-area.height);
cr-clip();
}
switch(state) {
case 0:
cr-set_source_rgb(1, 0, 0);
break;
case 1:
cr-set_source_rgb(0, 1, 0);
break;
default:
cr-set_source_rgb(0, 0, 1);
break;
}
cr-paint();
return true;
}
public:
Cell() {
add_events(Gdk::ENTER_NOTIFY_MASK | Gdk::EXPOSURE_MASK);
set_app_paintable(true);
}
void set_number(int n) { number = n; }
sigc::signalvoid, int signal_activate() { return activate; }
int state;
};
class MainWindow : public Gtk::Window
{
private:
static const int rows = 20, cols = 20, cellsize = 20;
Gtk::Table table;
Cell cell[rows*cols];
int active;
void set_active(int n);
public:
MainWindow();
};
MainWindow::MainWindow()
{
set_default_size(cols * cellsize, rows * cellsize);
add(table);
table.set_homogeneous(true);
table.set_row_spacings(2);
table.set_col_spacings(2);
// set up cells
for (int i=0; irows*cols; ++i)
{
cell[i].set_number(i);
int irow = i / rows, icol = i % rows;
table.attach(cell[i], irow, irow + 1, icol, icol + 1);
// connect signal
cell[i].signal_activate().connect
(sigc::mem_fun(*this, MainWindow::set_active));
}
set_active(-rows - 1); // start with no active row nor column
show_all_children();
}
void MainWindow::set_active(int n)
{
active = n;
// update cell colors
const Gdk::Color colors[] = {
Gdk::Color(red), Gdk::Color(green), Gdk::Color(blue),
};
int arow = active / rows, acol = active % rows;
for (int i=0; irows*cols; ++i)
{
int irow = i / rows, icol = i % rows,
col = (irow == arow ? 1 : 0) + (icol == acol ? 1 : 0);
cell[i].state = col;
//cell[i].queue_draw();
}
// redraw
queue_draw();
}
int main(int argc, char *argv[])
{
Gtk::Main kit(argc, argv);
MainWindow window;
Gtk::Main::run(window);
return 0;
}
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal dispatching slowed down after upgrade
On Mon, 2011-02-14 at 14:28 +0100, Krzysztof Kosiński wrote: 2011/2/14 BALLABIO GERARDO gerardo.balla...@esterni.gruppo.mps.it: Hi all, in the last weekend I upgraded my computer to the new stable version of Debian (version 6.0.0, released a few days ago). After the upgrade, a gtkmm program of mine has become less responsive to the point of being barely usable. Apparently the dispatching of signals is now much slower than it used to be, and when a lot of them are connected (in my program there are more than 100), it becomes very noticeable. The slowdown is not caused by signal emission, but by modify_bg. If you write a custom expose handler that draws the cells, the updates are instantaneous. See the attached file. Maybe the use of a different theme is causing the change in performance. It's worth trying with other themes. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: signal
Mark Roberts wrote: Dear pch0317, Hi list I have problem. I can't find which signal is related to emit when I move cursor above widget. I use: widget.signal_button_press_event().connect(sigc::mem_fun(*this, Something1)); when I want to use Something1 function when i click on widget and widget.signal_button_release_event().connect(sigc::mem_fun(*this, Something2)); when I want to use Something2 function when I release mouse button. How I must type to use Something3 when I move cursor above widget. For when mouse pointer moves from outside the widget to inside, use signal_enter_notify_event(). For when it moves back outside, use signal_leave_notify_event(). In order to catch any mouse movement within your widget, use signal_motion_notify_event(). Remember that your users might not all be using a mouse. In particular, lots of people use the keyboard to navigate dialogs. I hope you are all having good weather (though I know it is unlikely). Mark Thank Mark I choose signal_motion_notify_event() but when I compile my program ... eBox.set_events(Gdk::ALL_EVENTS_MASK); eBox.signal_motion_notify_event().connect(sigc::mem_fun(*this, Interfejs::about)); ... the error occur: /usr/include/sigc++-2.0/sigc++/functors/slot.h: In static member function ‘static T_return sigc::internal::slot_call1T_functor, T_return, T_arg1::call_it(sigc::internal::slot_rep*, typename sigc::type_traitT_arg3::take) [with T_functor = sigc::bound_mem_functor0void, Interfejs, T_return = bool, T_arg1 = GdkEventMotion*]’: /usr/include/sigc++-2.0/sigc++/functors/slot.h:144: instantiated from ‘static void* (* sigc::internal::slot_call1T_functor, T_return, T_arg1::address())(void*) [with T_functor = sigc::bound_mem_functor0void, Interfejs, T_return = bool, T_arg1 = GdkEventMotion*]’ /usr/include/sigc++-2.0/sigc++/functors/slot.h:529: instantiated from ‘sigc::slot1T_return, T_arg1::slot1(const T_functor) [with T_functor = sigc::bound_mem_functor0void, Interfejs, T_return = bool, T_arg1 = GdkEventMotion*]’ /usr/include/sigc++-2.0/sigc++/functors/slot.h:1157: instantiated from ‘sigc::slotT_return, T_arg1, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil::slot(const T_functor) [with T_functor = sigc::bound_mem_functor0void, Interfejs, T_return = bool, T_arg1 = GdkEventMotion*]’ interface.cpp:163: instantiated from here /usr/include/sigc++-2.0/sigc++/functors/slot.h:137: error: void value not ignored as it ought to be /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h: In member function ‘typename sigc::adaptor_functorT_functor::deduce_result_typeT_arg1, void, void, void, void, void, void::type sigc::adaptor_functorT_functor::operator()(T_arg1) const [with T_arg1 = GdkEventMotion* const, T_functor = sigc::bound_mem_functor0void, Interfejs]’: /usr/include/sigc++-2.0/sigc++/functors/slot.h:137: instantiated from ‘static T_return sigc::internal::slot_call1T_functor, T_return, T_arg1::call_it(sigc::internal::slot_rep*, typename sigc::type_traitT_arg3::take) [with T_functor = sigc::bound_mem_functor0void, Interfejs, T_return = bool, T_arg1 = GdkEventMotion*]’ /usr/include/sigc++-2.0/sigc++/functors/slot.h:144: instantiated from ‘static void* (* sigc::internal::slot_call1T_functor, T_return, T_arg1::address())(void*) [with T_functor = sigc::bound_mem_functor0void, Interfejs, T_return = bool, T_arg1 = GdkEventMotion*]’ /usr/include/sigc++-2.0/sigc++/functors/slot.h:529: instantiated from ‘sigc::slot1T_return, T_arg1::slot1(const T_functor) [with T_functor = sigc::bound_mem_functor0void, Interfejs, T_return = bool, T_arg1 = GdkEventMotion*]’ /usr/include/sigc++-2.0/sigc++/functors/slot.h:1157: instantiated from ‘sigc::slotT_return, T_arg1, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil::slot(const T_functor) [with T_functor = sigc::bound_mem_functor0void, Interfejs, T_return = bool, T_arg1 = GdkEventMotion*]’ interface.cpp:163: instantiated from here /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:84: error: no match for call to ‘(sigc::bound_mem_functor0void, Interfejs) (GdkEventMotion* const)’ /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1786: note: candidates are: T_return sigc::bound_mem_functor0T_return, T_obj::operator()() const [with T_return = void, T_obj = Interfejs] /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:84: error: return-statement with a value, in function returning 'void' What am I doing wrong? ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: signal
Dear pch0317, I choose signal_motion_notify_event() but when I compile my program ... eBox.set_events(Gdk::ALL_EVENTS_MASK); eBox.signal_motion_notify_event().connect(sigc::mem_fun(*this, Interfejs::about)); the error occur: [...] /usr/include/sigc++-2.0/sigc++/functors/slot.h:137: error: void value not ignored as it ought to be [...] What am I doing wrong? It looks as if Interfejs::about has the wrong type. Look at the documentation to see what function type signal_motion_notify_event() expects. In particular, the error message mentions the return value. Hope this helps, Mark Roberts ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: signal
Dear pch0317, Hi list I have problem. I can't find which signal is related to emit when I move cursor above widget. I use: widget.signal_button_press_event().connect(sigc::mem_fun(*this, Something1)); when I want to use Something1 function when i click on widget and widget.signal_button_release_event().connect(sigc::mem_fun(*this, Something2)); when I want to use Something2 function when I release mouse button. How I must type to use Something3 when I move cursor above widget. For when mouse pointer moves from outside the widget to inside, use signal_enter_notify_event(). For when it moves back outside, use signal_leave_notify_event(). In order to catch any mouse movement within your widget, use signal_motion_notify_event(). Remember that your users might not all be using a mouse. In particular, lots of people use the keyboard to navigate dialogs. I hope you are all having good weather (though I know it is unlikely). Mark ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal for unselected in a treeview widget
You can for example set a select-function: http://www.gtkmm.org/docs/gtkmm-2.4/docs/reference/html/classGtk_1_1TreeSelection.html#7c408b8e2b45b4a65a2a9ad66d9602cf That way you can monitor any selection changes in detail. 2008/9/11, Paulo Flabiano Smorigo [EMAIL PROTECTED]: Hi everyone, I have a treeview with the set_hover_selection(true). So when you put the mouse over a row, it's selected. But I want to create a signal when the user unselect the row. Like a mouse_out, I don't know... Thanks in advance... Paulo Flabiano Smorigo -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal to other class
Yes you just need a pointer or reference to an instance of FunctionA, like
this:
FunctionA * instance = new FunctionA;
...
FunctionB::FunctionB()
{
...
button.signal_clicked().connect(sigc::mem_fun( *instance,
FunctionA::onButtonClick ));
...
}
2008/8/6 Paulo Flabiano Smorigo [EMAIL PROTECTED]
Hi everyone,
I'm new with this signal stuff and maybe I'm zone out but is it possible to
create a signal that calls a function from other class?
Like that:
FunctionB::FunctionB()
{
...
button.signal_clicked().connect(sigc::mem_fun(*this,
FunctionA::onButtonClick));
...
}
FunctionA::FunctionA()
{
...
...
}
FunctionA::onButtonClick()
{
std::ccout TESTE std:endl;
}
--
P.F.Smorigo
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal for treeview row change
I think that you are looking for signal_cursor_changed() but you should take care about the focus. On 10/8/07, Andreas Volz [EMAIL PROTECTED] wrote: Hello, I use this to connect a signal handler in a treeview: m_siteTreeView.signal_row_activated().connect(sigc::mem_fun(*this, SideBar::onTreeviewRowActivated) But the signal is only thrown if I double click on a row. But I like a signal if I normal click the treeview. regards Andreas ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal for treeview row change
On 10/8/07, Andreas Volz [EMAIL PROTECTED] wrote: Hello, I use this to connect a signal handler in a treeview: m_siteTreeView.signal_row_activated().connect(sigc::mem_fun(*this, SideBar::onTreeviewRowActivated) But the signal is only thrown if I double click on a row. But I like a signal if I normal click the treeview. It depends on what exactly you are trying to do, but you might be able to use the Gtk::TreeSelection::signal_changed() signal. Alternately, you could possibly use Gtk::TreeView::signal_button_press_event() signal in conjunction with Gtk::TreeView::get_path_at_pos(). -- jonner ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal handler problem while linking
Am Freitag, den 02.02.2007, 22:45 +0100 schrieb Tomek Lorek:
Hi there,
I've got another thing that I can't go through: my sources are
compiling properly but the final linking fails with:
addtask.o: In function `AddTask::AddTask(Glib::RefPtrGnome::Glade::Xml)':
addtask.cpp:(.text+0x490): undefined reference to `AddTask::on_ok_clicked()'
addtask.cpp:(.text+0x54a): undefined reference to
`AddTask::on_cancel_clicked()'
addtask.cpp:(.text+0x604): undefined reference to
`AddTask::on_open_calendar_clicked()'
The linker message says it all: you need to provide implementations of
these methods, not just the declarations.
[snip]
if (m_wOpenCalendar) {
m_wOpenCalendar-signal_clicked().connect(SigC::slot(on_open_calendar_clicked));
}
}
I had to make my signal handlers static, because it was impossible to
make a reference to a non-static member.
Use SigC::slot(*this, AddTask::on_ok_clicked) to connect a non-static
method. By the way, you must be using pretty old versions of gtkmm and
libsigc++, since the syntax changed from SigC::Slot() to sigc::mem_fun()
quite a while ago.
--Daniel
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal emitted when Gtk::ColourSelectionDialog's close button is clicked
On Sat, 2006-06-10 at 10:59 +0800, weijie wrote: Hi, What is the signal emitted when a Gtk::ColourSelectionDialog's close button is clicked? i am using libglademm. For example, if i want to connect a signal handler to a button's signal_clicked() event, i use this: exitbtn-signal_clicked().connect( sigc::ptr_fun(on_exitbtn_clicked) ); So which signal should i use for a colour selection dialog? the docs are not helpful here. can anyone please point me to a site containing all the signals emitted, espically in the context of libglademm? thanks! wei jie I guess you would want to handle Gtk::Dialog::signal_response. Or you could use Gtk::Dialog::run(), which blocks until the dialog has been closed. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal for when the selected row in a TreeView Changes
On Thu, 2006-02-23 at 18:30 +0100, Nathan Hüsken wrote: Hello together, I want run function whenever a different row is selected in a TreeView (using the list model). Now I tried to connect to the signal_row_activated signal, but that does not work at all :( What signal should I connect to? treeview.get_selection()-signal_changed() John ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal when a file changes
Hello Andrew! Can someone give me a simple code example or point at a references that shows a good way to signal a gtkmm application that a file changed? I use gtk_timeout_add in GTK+. CU Michael -- Michael Ott, e-mail: [EMAIL PROTECTED], www.zolnott.de I am registered as user #275453 with the Linux Counter, http://counter.li.org. pgpuxChkV5fq1.pgp Description: PGP signature ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: signal within a signal handler
On 9/9/05, Murray Cumming [EMAIL PROTECTED] wrote: On Thu, 2005-09-08 at 09:09 -0500, Jonathon Jongsma wrote: On 9/8/05, Murray Cumming [EMAIL PROTECTED] wrote: On Tue, 2005-09-06 at 08:26 -0500, Jonathon Jongsma wrote: I'm curious, is it legal to emit a signal within a handler for another signal? Yes, absolutely. The reason I'm asking is that I'm trying to do such a thing and I keep getting a segfault when the event occurs. gdb or valgrind will give more information. Here's the backtrace from gdb. Unfortunately that doesn't tell me much, but maybe investigating the variables at that point would be informative. But this looks to me like some kind of memory problem (one of the objects involved is invalid because it has already been deleted, was never instantiated, or has been bad-casted from some other pointer) so valgrind is likely to show the problem. If even that doesn't help, then it's time to break the program down until you isolate the problem. [snip] -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com I just wanted to follow up on this in case any other Debian users experience this problem. Apparently I managed to apt-get upgrade myself to a state where my default compiler was g++-4.0 but my gtkmm and / or sigc++ was still compiled with 3.x (This C++ ABI transition is no fun at all if you're trying to develop C++ programs). I didn't notice the warning at first since everything seemed to work fine until I tried handling a custom signal, at which point it segfaulted. After realizing this and fixing it, the program worked just fine. Thanks, Jonathon ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: signal within a signal handler
On Thu, 2005-09-08 at 09:09 -0500, Jonathon Jongsma wrote: On 9/8/05, Murray Cumming [EMAIL PROTECTED] wrote: On Tue, 2005-09-06 at 08:26 -0500, Jonathon Jongsma wrote: I'm curious, is it legal to emit a signal within a handler for another signal? Yes, absolutely. The reason I'm asking is that I'm trying to do such a thing and I keep getting a segfault when the event occurs. gdb or valgrind will give more information. Here's the backtrace from gdb. Unfortunately that doesn't tell me much, but maybe investigating the variables at that point would be informative. But this looks to me like some kind of memory problem (one of the objects involved is invalid because it has already been deleted, was never instantiated, or has been bad-casted from some other pointer) so valgrind is likely to show the problem. If even that doesn't help, then it's time to break the program down until you isolate the problem. [snip] -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: signal within a signal handler
On 9/8/05, Murray Cumming [EMAIL PROTECTED] wrote:
On Tue, 2005-09-06 at 08:26 -0500, Jonathon Jongsma wrote:
I'm curious, is it legal to emit a signal within a handler for another
signal?
Yes, absolutely.
The reason I'm asking is that I'm trying to do such a thing
and I keep getting a segfault when the event occurs.
gdb or valgrind will give more information.
Here's the backtrace from gdb. item #2 is obviously my handler for a
button_release_event, which then emits my custom signal. I'm afraid
that I can't figure a lot out from this backtrace -- do you see
anything obvious here? (code is shown below)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 12572)]
0x40ccd37e in std::_List_node_base::swap () from /usr/lib/libstdc++.so.6
(gdb) bt
#0 0x40ccd37e in std::_List_node_base::swap () from /usr/lib/libstdc++.so.6
#1 0x0807dabe in sigc::internal::signal_emit0bool, sigc::nil::emit (
impl=0x817d748) at stl_list.h:901
#2 0x08078c4f in gcs::Widgets::ColorSwatch::on_button_release_event (
this=0x19, e=0x8254d20) at signal.h:1608
#3 0x4021d6c2 in Gtk::Widget_Class::button_release_event_callback ()
from /usr/lib/libgtkmm-2.4.so.1
#4 0x4078747e in _gtk_marshal_BOOLEAN__BOXED ()
from /usr/lib/libgtk-x11-2.0.so.0
#5 0x40a71f18 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
#6 0x40a725bb in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#7 0x40a81c72 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0
#8 0x40a82c05 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#9 0x40a831fe in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#10 0x40876cf7 in gtk_widget_send_expose () from /usr/lib/libgtk-x11-2.0.so.0
#11 0x40785f92 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x40784de6 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x409868e5 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0
#14 0x40c243f1 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#15 0x40c27647 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#16 0x40c27b98 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#17 0x40784693 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#18 0x401b3359 in Gtk::Main::run_impl () from /usr/lib/libgtkmm-2.4.so.1
#19 0x401b31a3 in Gtk::Main::run () from /usr/lib/libgtkmm-2.4.so.1
#20 0x0806de26 in main (argc=1, argv=0xb644) at main.cc:73
Here's my on_button_release_event code:
bool ColorSwatch::on_button_release_event(GdkEventButton *e)
{
//if (e-type == GDK_BUTTON_RELEASE)
{
if (e-button == 1)
{
// User pressed left mouse button
m_signal_selected.emit();
debug(In on_button_press_event; emitted signal_selected());
}
}
return true;
}
m_signal_selected is defined as follows:
sigc::signalbool m_signal_selected;
I've registered a handler for m_signal_selected in the constructor of
the class as follows:
m_signal_selected.connect(sigc::mem_fun(*this, ColorSwatch::on_test));
The handler on_test is defined as follows:
bool ColorSwatch::on_test()
{
debug(on_test);
return true;
}
When I register even a trivial handler for m_signal_selected (such as
on_test shown above), I get a segmentation fault (backtrace shown
above). When I have no signal handler registered for
m_signal_selected, the signal emits but no segfault occurs.
I'd be grateful for any help anyone can provide.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal handling
Diego Fdez. Durn diego at goedi.net writes: Does this work ? m_TreeView.get_column(0)-signal_clicked().connect( bind( sigc::mem_fun(*this, ExampleWindow::column_clicked), 0 ) ); No. :( However I did a workaround in which I get column when I am calling cellrenderer e.g. void ExampleWindow::m_cellrenderer_location_validated_on_edited (const Glib::ustring path ... Thank you for your time anyway. Rok ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal handling
Diego Fdez. Durn diego at goedi.net writes:
Try:
m_TreeView.get_column(0)-signal_clicked().connect(bindint
(sigc::mem_fun(*this, ExampleWindow::column_clicked)));
I think that the example you are trying to compile is for a previous
version of gtkmm that the libraries you are using. Use upgraded
examples :)
Hi.
Thank you for you quick answer.
m_TreeView.get_column(0)-signal_clicked().connect(sigc::bindint
(sigc::mem_fun(*this, ExampleWindow::column_clicked),0 ));
did the trick, however I do not get any output from function I'm calling.
Function is:
void ExampleWindow::column_clicked(int column)
{
std::cout just something std::endl;
}
Best,
Rok
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Signal handling
El mié, 06-04-2005 a las 09:56 +, Rok Jaklic escribió:
Diego Fdez. Durán diego at goedi.net writes:
Try:
m_TreeView.get_column(0)-signal_clicked().connect(bindint
(sigc::mem_fun(*this, ExampleWindow::column_clicked)));
I think that the example you are trying to compile is for a previous
version of gtkmm that the libraries you are using. Use upgraded
examples :)
Hi.
Thank you for you quick answer.
m_TreeView.get_column(0)-signal_clicked().connect(sigc::bindint
(sigc::mem_fun(*this, ExampleWindow::column_clicked),0 ));
Does this work ?
m_TreeView.get_column(0)-signal_clicked().connect(
bind( sigc::mem_fun(*this, ExampleWindow::column_clicked), 0 ) );
did the trick, however I do not get any output from function I'm calling.
Function is:
void ExampleWindow::column_clicked(int column)
{
std::cout just something std::endl;
}
Best,
Rok
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
--
---
Diego Fdez. Durán [EMAIL PROTECTED]
Web: http://www.goedi.net
GPG ID: 90D266BB
---
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: signal handling
rob page wrote: should on_enter_notify be returning a bool instead of a void? hahaha I am a real dumbass!! thx alot or the help :-) ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
