Re: spin buttons

Here is what I'd have done to solve the problem. My method might not be
ideal for your case, but I'd use it because I tend to not mess with gui
code unless it's actually the view that i want to change, not the model.
Here it is:

(1) Make the 3 spin buttons (with their 3 adjustments).
(2) If the valid range of a spin button is from x to y inclusive, set
the range instead to (x-s) to (y+s) inclusive, where s is the step (s =
1 in your case, since it is dates).
(3) Set a function foo to be the handler for the value_changed signal
for all 3 adjustments.
(4) In foo, see if any value is (x-s) or (y+s) for each adjustment. If
it is, change (x-s) to y or (y+s) to x, depending on which it is, and
then bump the other adjustment up or down, again depending on which it
(5) Your 4th spin button (i don't know what it does), can choose a
similar approach, in that the handler for it's adjustment's
value_changed does changes appropriately.

(6) If this was for the year-month-day thing, as you said, then it's
easy to modify step (4) so that instead of just checking for (x-s) or
(y+s), it will check for anything exceeding the correct range at any
point in time. For example, if the month was 2 (feb), then it would wrap
the date if it went over 28 (or 29 for leap years), and increment the
month to 3 (march).
(7) The reason I like this approach is that, like I said, it isn't
dependent on gui code at all, and so is easier to reuse elsewhere.

On 14 Feb 2001 15:28:27 -0700, Jeff Shipman wrote:
> > The difference would be that your function gets called by connecting it
> > to the value_changed signal of the three adjustments of the three
> > buttons. Your function would then read all 3 adjustments and then
> > set_value them to whatever you want. That way your algorithm code
> > doesn't get intersperced in your gui code, making it easier to call that
> > algorithm code from that other function you were talking about.
> >
> > Oh, and to answer your question, i don't think gtk_adjustment_set_value
> > will set the click_child of the spin button.
> I don't connect it to the adjustment because then I have no
> way of knowing which of the three spinbuttons were pressed,
> and therefore I have no access to click_child which I MUST have.
> I must have this because I need to know whether the value is
> going up or down. This is because the value needs to wrap around.
> If I was to simply set_value on it, then it would not wrap and
> instead would stop at the maximum value. This is why I use
> gtk_spin_button_spin() in my handler rather than set_value.
> My handler already takes care of the three spin buttons as long
> as you click on one of those three. The problem arises from
> a fourth spin button that needs to affect those spinbuttons but
> its value is completely different. I would like to just tell
> it to spin up or down the proper amount of times, but when
> my handler goes to check if it's going up or down, it doesn't
> know (because gtk_spin_button_spin()) doesn't set click_child and
> again, I must know whether the up or down arrow was clicked. If
> I could cause the up or down arrow to manually be clicked rather than
> using gtk_spin_button_spin() then that would solve my problem
> of click_child not being set.
> I suppose there is a way to differentiate between the three
> different adjustments after all (using the widget passed in),
> but this really doesn't change my situation any.
> Again, it works fine using one of the three spin buttons, but if
> I use the fourth one, it just spins up to the maximum and stops
> (because there's no click_child).
> Jeff "Shippy" Shipman     E-Mail: shippy nmt edu
> Computer Science Major    ICQ: 1786493
> New Mexico Institute of Mining and Technology
> Homepage:

|   LOBAN AMAAN RAHMAN  <-- anagram of -->  AHA! AN ABNORMAL MAN!   |
|     loban earthling net, loban caltech edu,     |

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]