QSplitter/SplitterMoved

[MrGarbage]

Hi,

I have a QSplitter controlling a QTreeWidget on top and a
group of 4 buttons on the bottom. I have placed the 4 buttons
in a frame who has a fixed height and a max height which
is only slightly larger than its min height.

What I want to do is catch the direction of the vertical
scroller movement and hide/show one or more of the
buttons in the frame.

This works to the extent that the frame corectly resizes
when I hide/show a button.

My problem is determining where the vertical scrollbar
has moved.

Catching the splitterMoved Signal only tells me the
new position. Hiding or Showing one of the buttons
results in a resizeEvent for the XMLtree and another
splitterMoved Signal call with the new position.


I need a way to differentiate between a splitterMoved Signal
due to a resizing and one from an actual move of the splitter
handle. It would be nice if they generated different event types
but they don't..

Thanks

Mark

[seveninches]

My problem is determining where the vertical scrollbar
has moved.

Catching the splitterMoved Signal only tells me the
new position. Hiding or Showing one of the buttons
results in a resizeEvent for the XMLtree and another
splitterMoved Signal call with the new position.

So your problem seems to be not where the vertical scrollbar has moved, but how it has been moved (using mouse or programmatically).

The easiest method seems to be to check the mouse cursor position and probably button state; if it's on the splitter and the button is down, the splitter has been moved by mouse; otherwise by program.

More reliable method is to reimplement void mousePressEvent() and mouseReleaseEvent() in your splitter subclass to set some kind of variable regarding current mouse position, and check this variable in your splitterMoved() handler.

If it's not what you want, could you please elaborate?

[jpn]

One idea could be to try putting those buttons inside a simple wrapper widget. This wrapper widget would simply show/hide the buttons accordingly in its resizeEvent(). This way you wouldn't have to rely on the signal at all...