In the original posters message he had used g_signal_connect_swapped() so in this case his call-back function proto-type will look like

Code:

void user_function (gpointer user_data, GtkButton *button)

He had just chosen to ignore the final argument.

Also I would recommend not to use gtk_widget_set_name() as its intended use is for themes and styling and could have some unfortunate side effects. It would be better to stay with passing the data through the "gpointer user_data". So if the data is the same size or smaller than a pointer and the value does not need to change then just cast it and it will be passed on to the call-back function. Else just pass a pointer to an allocated section of memory with the data to be passed onto the call-back function.

Additionally you would be better off using a spin button than a GTK_ENTRY. That way you don't have to worry about when users may accidentally input a non umeric character. Also setting it to have no decimal places (i.e. an integer) will make the program more transparent to the user e.g. they might enter 0.4 and wonder why it's not going anywhere.Oh and check out glib for replacements for printf. If you're going to program in GTK you may as well make it platform independent.

@asdfgh2091Thanks for "pointing" this out. I did not know such things existed. I will look into this further as soon as I decypher all that.

@kepicaI think you are loosing me here. I have to study more what you said. At the moment, my user_function as you call it, I assume you refer to validate_position return long for two reason. One, I could not figure out how to handle the type conversion (I actually wanted Int) and also because it "validates" something, well to me it has to return some success or failure. I am still trying to figure this out.

@errolOk... I am so confused. I used g_signal_connect_swapped() because I think I could not get it to work by using g_signal_connect(). I read the docs and so far some of Andrew Krause book and I have a hard time understanding the concept. I am roughly at chapter three...ish.As a curiosity, that allocated section of memory you are refering too, can that be a function? The terminology "data" confuses me.

@PaulYeah, a spin button might be my next widget to play with. As far as it goes for multi-platform, that is not really my ambition at the moment.

You must follow the proto-types for each signal as it is in the documentation otherwise you may end up with very unexpected problems or crashes. Most signal call-back functions do not have a return value and if they do it is usually information for the GTK/Glib main loop mainly to say disconnect this signal or to carry on with other signal call-back functions or not.

The arguments passed to a call-back function will be any information relevant to that signal. So for the "clicked" for GtkWidget this is a pointer to the GtkButton the signal happened to. Then there is "gpointer user_data" this can be used for your own purposes and the value passed to the call-back functions is the value passed when you connected the signal. "user_data" can be an integer value if suitable cast. The way to do that is how "asdfgh2091" pointed out, doing it this way makes it very clear that what you are passing will be an integer and will do the casting properly for you. As it is a pointer it can point to anything, so it can pointer to a function, point to an area of data which could be anything such as an array of data or a structure.

Going back to your original call-back function for the "clicked" signal for GtkButton, you have done some things right and some things wrong.- The value you have returned from the call-back will be ignored as the signal is expecting the call-back function not to return a value. You would be better to check for any errors, bounds checking or other things within the call-back function.

- You have used g_signal_connect_swapped() to connect your signal. This basically places the "user_data" as the first argument. In your case you have chosen to ignore the other arguments, which is OK, but for some people this can be seen as bad.

As Paul said in his post a GtkSpinButton http://developer.gnome.org/gtk3/stable/GtkSpinButton.html would be better for setting data for a stepper motor. This way you can set the input range (minimum and maximum values) have only integer values allowed have up/down buttons and have all this handled for you by GTK. All you have to do is handle the higher level stuff of getting when the value changes and setting your stepper motor.

Also it is worth reading on the Glib library functions so that you know what is there. Much of it is very useful with helper functions for data structures, string handling (ASCII and UTF8 including conversion to and from other formats), threads, and many other utility functions. I have seen too many people write the same bit of code of between 5 to 20 lines repeatedly some times in slightly different ways each time and with this code not being easy to read. This can often be replaced with a single function call which is easy to see what it does.

Instead of dealing with user data, the validate_position function reads the button label.Obviously, if that was a multilingual application or if it was an icon that would be a problem.Anyone, feel free to comment on that aspect.Anyway function goes like so which by the way now returns void. :)

I did not implemented spin button yet. I want to understand the following first.I tried to fiddle around with the GPOINTER_TO_INT macro as suggested, but obviously it is not the way it works I guess. My stepper went on for quite a long spin LOL.

The docs say

Quote:

GPOINTER_TO_INT. Extracts an integer from a pointer. The integer must have been stored in the pointer with GINT_TO_POINTER().

I am not sure about your function enter_callback(), but if it is for a signal then it does not look right. :-/Note you should do some error checking on the text entry, as that could have anything entered into it including text and possibly overflow the integer, negative numbers and possibly return an unknown value. Think about using strtol() in the standard C library or g_ascii_strtoll() in Glib which have more error checking, so you know you have an error in the conversion, but you may want more checking else where.

Thanks errol. Now I get the principle of GINT_TO_POINTER ans its counterpart. Kind of interesting.

The enter_callback is an artifact. I did not even notice I copied it there. :)

I am in fact using strtol in the main of my stepper_main.c file to do some validation because I also run it from the command line or from a text file redirect. But I agree, doing some validation through the form is probably a good idea. It would be a good exercise anyway.

Who is online

Users browsing this forum: Google [Bot] and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum