Thanks for your answer! So, as my app is a Glade app, I can use that lookup_widget() function you mentioned? Otherwise I would use your function :-)
Thanks again On 10/23/05, Gus Koppel <[EMAIL PROTECTED]> wrote: > César Leonardo Blum Silveira wrote: > > > I have a few doubts about the way I code my GTK applications. One of > > them is: Is it ok to use many global variables for the widgets? For > > example, in a glade app where callbacks are of the form > > > > void callback(GtkWidget *widget) > > > > I can only have access to the widget that received the signal, but > > what if I want to make it change a property of another widget? Should > > I use a global variable or should I try getting the toplevel widget > > and then decending to the "neighbour" widget I want to make changes > > on? > > Opinions about it certainly differ. Some people may prefer global > variables for all important widgets for two reasons: 1. it's the very > fastest way to get pointers to widgets, 2. it's okay for them to deal > with large amounts of global vars (despite known problems that could > result with them on larger scale applications). > > However, I think the majority of programmers prefers to avoid global > variables whenever possible. Both for stylistic as well as for > complexity reasons. Having to keep track of global variables for somee > (or many) widgets is more difficult and error-prone than not needing to > do so. With the exception of toplevel (or popup) windows I don't use any > global vars to store pointers to widgets in them. > > Instead, during program execution I refer to widgets by name. The name > property of widgets, if being used properly, is a wonderful and well > readable way to refer to widgets. It's a glimpse of high-level (or > scripting) language programming in C(++). This way you don't need to > juggle with numerous global variables and their (possibly frequent) > proper initialization (and deinitialization) at all. > > It's certainly a bit slower than directly accessing a global variable of > which the memory address is directly known at execution time and doesn't > need to be determined. However, the speed impact should be neglegible > unless you plan to search for far more than some 1000s different widgets > per second (or signal handler). Performance limitations of GTK+ > applications are not caused by this sort of custom functions, anyway. > > Since this way of easy programming appears not to be supported > officially by GTK+ I use my own simple function for this purpose: > widget_find_by_name (), retrievable at > http://www.spamkiller.bytechase.cx/democode/widget_find_by_name.c > > For instance, if you have a window named "W_Main" and a text field named > "I_Value" in it then you can simply refer to the latter from within > any callback by something like this: > > { > GtkWidget *i_value = WFBN ("I_Value"); > gtk_widget_do_this (i_value, ...); > gtk_widget_do_that (i_value, ...); > } > > For other windows you may (or may not) simply define similar macros like > WFBN_WIN2 (...) for instance. > > BTW, the difference between my function and lookup_widget(), provided by > Glade, is that my function is absolutely independent from Glade and > doesn't need any further precautions like lookup_widget() does. It just > suggests you to set the "name" property of widgets appropriately. > _______________________________________________ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- César Leonardo Blum Silveira Graduando em Ciência da Computação - Unisinos Centro de Simulação de Humanos Virtuais http://cesarbs.blogspot.com/ MSN: cesarbs490 _at_ msn _dot_ com ICQ: 170861826 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
