Access to QSpinbox Buttons

[tescrin]

From what I can tell in the documentation the QSpinbox buttons are not derivatives of "QAbstractPushButtons" or anything handy; but that the QSpinBox actually handles the clicks and figures out whether they're within the button or text area?

I say this because it contains no button objects from what I can tell, nor any accessors to said buttons.

I've tried scrying the source code, but QSpinBox seems to inherit it's MouseEvents from QAbstractSpinBox and the source for those don't seem to imply there's even detection of where the click is happening.

Any help on how to talk to these buttons and/or their events would be greatly appreciated. Also curious as to the why (if it's not obvious.)

Thanks!

EDIT: Actually, I just need how they talk. I assume the "Why" is that because QLineEdit will handle it's own clicks, so the spinbox only need to handle clicks that QLineEdit didn't take already; and thus only deals with the "buttons", but I still don't know what's going on with the buttons.

[high_flyer]

http://www.qtcentre.org/threads/3899...-Button-Access

[tescrin]

I did end up reading that thread before (though had forgotten about it.) I had dismissed it as his solution seemed like a kluge at the time. Reviewing it again it looks better than it did.

I'm still curious about the *signal* that's emitted. I was thinking this was the boolean that controlled the up vs. down.

I could overwrite the mousePressEvent I guess, but then I'm re-implementing functionality rather than using the functionality that's already there. It seems like I should be able to tap into that boolean function they're using in the source.


I'll check back, but for now I guess I'll use that code snippet.

[high_flyer]

could overwrite the mousePressEvent I guess, but then I'm re-implementing functionality rather than using the functionality that's already there.

Not quite:

The default implementation implements the closing of popup widgets when you click outside the window. For other widget types it does nothing.

[tescrin]

What I meant was that they already have a function that detects which button was pressed. By writing a new one you're overwriting functionality (by capturing the mousepress that the side buttons want to detect) and re-implementing (as the function you are writing does the same thing as the one they've written.)


That said, spinbox gave me more issues an I was already 90% of the way to writing my own over the top of theirs, I finally just made my own using actual pushbuttons and getting rid of all of the excess functionality of the QDoubleSpinBox that was getting in my way :s.


EDIT: I should say that I understand where you're coming from, but I think the source code I looked at originally *was* mousePressEvent. Further, (predictably,) when I made my own mousePressEvent the spinbox acted much differently. Maybe I'm misunderstanding your point. Either way, this is just for discussion purposes now as I bypassed my need for a solution lol

[high_flyer]

Ok, but what is your goal?
If what you want/need is to catch the press event on the up/down buttons, and do something that QSpinBox doesn't do in addition to the original behaviour, then you can leave (call) the original functionality in your re-implementation and just add the part you need.

when I made my own mousePressEvent the spinbox acted much differently.

Differently but "good" or "bad" (in respect to your needs)?
If good, ok, if bad, you are doing something wrong.
But reimplementing doesn't have to mean you have to re implement the original implementation, you can use the original in yours, so I don't quite understand the problem you are seeing with the reimplementation of a method.