Re: Newbie still with probs...

[Carlos Pereira <carlos pehoe civil ist utl pt>]

> So... if the widgets are NOT declared gloablly I
> will have to pass each widget as an argument of the function isn't it? If
> not, how can I achive this? and aslo, is it very bad to declare all the
> widgets globally so that I do not have to pass them from one function to the
> other??

You have three ways to pass data to a callback function:

1) Create a structure, put all your stuff inside, an pass it
as the last (second or third argument, usually) argument
of your call back function. As this:

gtk_signal_connect (GTK_OBJECT (button), "clicked",
GTK_SIGNAL_FUNC (your_call_back_function), pointer_to_your_struct);

and then, in the callback:

void your_call_back_function (GtkWidget *widget, gpointer data)
{
your_type *struct = (your_type *) data;

2) Attach your data to a given widget, which address you know,
for example:

gtk_object_set_data (GTK_OBJECT (dialog), "your_entry", entry);

and then in the callback get it back:

entry = (GtkWidget *) gtk_object_get_data (GTK_OBJECT (dialog), "your_entry");

3) Use glabal variables. As you said, in general this is
very bad programming.

My suggestions:

The permanent information, like lists of objects, object properties,
etc... should be passed in a structure pointer. This structure
should also have a variable to allocate the dialog widget address, 
so you know in the callback where is the dialog, and in turn you know
where is everything else.

The temporary information, that is removed as soon as the
dialog is closed, should be passed as set_data/get_data to
avoid unnecessary data pollution. Attaching widget addresses
to the dialog window guarantees that everything is automatically
removed as soon as the dialog is removed. set_data/get_data is
not as fast and memory-friendly as passing a data pointer, but 
unless you have thousands of widgets in your dialog (which I 
really doubt), this is not a problem and makes everything
so much simpler to code and to understand.

If you have some general resources which never change, like, 
say, the number of r, g, b color bitplanes available, etc...
you can put all this inside a single big external structure 
and to avoid confusions give it the name of your app, so you 
will have app.r, app.g, app.b, etc..., your entire app will 
have exactly ONE external variable (with general stuff inside)
with the name of the app, so there is no confusion and is 
elegant!

Carlos