Let's say I have an wall where user can have only N windows. I should restrict the user from setting one window over another. He can move, resize them but he cannot overlap them. To ignore the invalid moves I am catching the moveEvents and if the event->pos() is an invalid position I reset the geometry to the event->oldPos(). Well this approach is not working for resizeEvent. Why I can't use same approach on resize? How can I solve this problem? P.S Setting maximumSize and minimumSize is not a good idea, it's to consuming because of my implementation.
When a user resized a window or resize is called Qt sets Qt::WA_WState_ConfigPending flag to true and starts internal resize operations. During these operations you receive resizeEvent. If you try to call resize there Qt just checks that the flag is set and ignores new resize until previous one is finished, however it sends resizeEvent again with the same data and you get into an endless recursion.
You can use this trick to overcome the check:
void widget::resizeEvent(QResizeEvent* e)
{
if (e->size().width() > 800)
{
setAttribute(Qt::WA_WState_ConfigPending, false);
resize(e->oldSize());
}
}
However, you still get blinking of the window, because it's already resized when you get resizeEvent. Actually OS resizes a window and then sends WM_SIZE message to a window to handle the change, that's why you have to deal with the result of the resize operation.
Related
On Windows 7 to be specific, while I don't think it matters.
We have all seen this issue in countless desktop applications, especially games that tend not to use OS-supplied controls: when the screen changes programmatically under a motionless mouse cursor (as opposed to user moving the cursor to a new widget), they go out of sync. Either the cursor does not change or the widget is not painted as it should be with the cursor inside it - obviously the widget's mouse enter event is not triggered. If you shake the mouse a bit without even leaving the widget, the thing fixes itself.
Sadly, Qt 5.7 shares this widespread problem. The first solution to come to mind is to move the mouse programmatically to (0, 0) and back by Windows means. However, it's not cross-platform(ish). Any better ideas?
I don't know if your question is still actual
You can override method underMouse() with following code:
bool MyWidget::underMouse()
{
return rect().contains(mapFromGlobal(QCursor::pos()));
}
Events moveEvent or resizeEvent in the rest panels will be definitely triggered when splitter resizes panel. All you need is check if widget is under mouse and then invoke enterEvent() manually
I found two solutions.
The first one is a simple hack: Call widget->hide() and then immediately widget->show(). This will reevaluate and update the widget's visual state depending on whether it is under mouse cursor or not, even if the cursor has not moved. But I would not recommend this solution because it might have some unwanted side effects. Though I have not encountered any yet.
The second solution is better because it does not look like a hack and it probably does not have any side effects:
widget->setAttribute(Qt::WA_UnderCursor, qApp->widgetAt(QCursor::pos()) == widget);
widget->update();
The code is assumed to be called from widget's parent. But you can adjust it and calle it from any other place. Note: it is better to use QApplication::widgetAt() than widget->rect().contains(), which is suggested in another answers, because in the latter case we would get false positives for widgets which are overlayed by other widgets.
What is actually complicated, is to find the place in code from where you should call this. Because there can be many sources of the widget's motion - moving withing its parent, moving of parent(s), resizing, resizing of parent(s), scrolling etc. This is probably the reason why this would be too complicated to implement this to standard Qt widget library. It would be probably a performance killer in some scenarios. (my guess)
Just to show my usage: I am moving a whole container widget which contains many child widgets. Subsequently one of the child widgets may get under the cursor after the container is moved. So I call:
containerWidget->move(dx, dy); // this moves the container
for (QWidget *child : containerWidget->findChildren<QWidget*>())
{
child->setAttribute(Qt::WA_UnderMouse, qApp->widgetAt(QCursor::pos()) == child);
child->update();
}
I have some problems. Hope anyone can help me.
I have a Qwidget1 and Qwidget2. Qwidget1 have a widget that promote to Qwidget2. Both Qwidget1 and Qwidget2 have paintEvent. I have writed "qDebug()<< "Update"; " in paint event of Qwidget1. When I run project, I see a word "Update" has been printed a lot of times. So why Qwidget1 execute paint event a lot of times. How can I fix it, just execute paint event when show Qwidget1 at the first time and when I call update.
This is expected behavior. Your code works like it should. From Qt documentation:
A paint event is a request to repaint all or part of a widget. It can
happen for one of the following reasons:
repaint() or update() was invoked,
the widget was obscured and has now been uncovered,
or many other reasons.
There can be any number of situations when a window or its part becomes invalidated and has to be repainted. Such situations include, but are not limited to:
window size change (including minimizing / maximizing / restoring the window);
mouse pointer passing over a widget - it may or may not trigger repaint;
other window moving over the window in question.
When it happens, Windows will send the WM_PAINT message to the application. You could check whether or not the number of WM_PAINT messages received matches the number of paintEvent calls, but I doubt Qt adds any significant overhead.
I have a main window with 3 child: hwndTocBox (left panel), hwndSplitter and hwndCanvas (right panel).
hwndTocBox has a child hwndTreeView, which is a TreeView control. When I drag hwndSplitter to the right (i.e want to make hwndTocBox and hence hwndTreeView bigger), the content (and background?) of hwndCanvas and hwndSplitter will remain for a while. (When I drag the splitter to the left, there is no problem at all.)
When hwndSplitter is draged, it uses DeferWindowPos() to resize and move hwndTocBox, hwndSplitter and hwndCanvas. When hwndTocBox is resized, in WM_SIZE case of its windows procedure, it resizes hwndTreeView (still using DeferWindowPos(), since it resizes not only hwndTreeView but also others).
I have tried to use CLIPCHILDREN and WS_CLIPSIBLINGS in several places, but it doesn't solve the problem.
Why the contents remain there for a while and erased later?
Could you indicate me how to solve this issue, please.
You'll need to repaint the portions of the window that you've resized, otherwise you'll get these strange artifacts. There's a reason they look like smears, because that's almost exactly what they are. A certain portion of the content was painted and appeared on screen normally. Then you resized the window. The portion that had already been painted was not repainted because you didn't invalidate it, but the newly-exposed portion had to be repainted because there was nothing there before.
The fix is simple: add a call to the InvalidateRect() function at the bottom of your resizing code to ensure that the portion of the window you're resizing gets redrawn the next time that the window processes a WM_PAINT message.
If you want to make sure that a WM_PAINT message gets processed immediately (resulting in the immediate redrawing of your window's affected regions), follow up with a call to the UpdateWindow() function. But this really shouldn't be necessary. It's much more efficient to postpone all of the redrawing to later when everything is finalized, rather than doing it incrementally. Relatively speaking, repainting a window is an expensive operation.
I have a QWidget and i need to do some actions (refresh a picture in widget) when resize event ends. How can i catch this action?
I need to catch moment when user ENDs all his resize actions by releasing mouse button. It is not a good practice in my application to refresh image every pixel resized. It should calls only when mouse released and resize actions ends.
I am just tried to reimplement QMouseReleaseEvent to catch it, but it do not works when user presses on the border of widget to resize it. It means does not working in our situation.
Then i was tried to create my own QSizeGrip and insert it on the bottom of my widget, but reimplemented event QMouseReleaseEvent again did not work in it. Event did not generates any time user released mouse. I do not know why.
Anybody can help me with that problem?
Thanks in advance.
The timeout method is a decent idea, but if the user is resizing and then pauses for longer than the timer's interval then you end up not getting the true "user is done resizing the window" event. Setting the interval longer makes that situation less likely, but by doing that, you end up having a long delay between the time the user finished resizing and the time your function gets called. In my search for a solution, I found quite a few people solving it using the timer method, so apparently it's reliable enough for some use cases, but I think it's a bit hacky.
I like mhstnsc's idea, so after implementing it, I decided to add some code here that might be of use to someone trying to do something similar.
You could easily adapt it to catch the "user is done moving the window" event by making a m_bUserIsMoving flag and overriding "void MainWindow::moveEvent(QMoveEvent* pEvent)". I'm using it to save a config file whenever the user finishes resizing or moving the window, so that the last position will always be saved even if the app is killed in an unclean manner.
// constructor
MainWindow::MainWindow(QWidget* pParent, Qt::WindowFlags flags) : QMainWindow(pParent, flags)
{
m_bUserIsResizing = false;
qApp->installEventFilter(this);
}
// this will be called when any event in the application occurs
bool MainWindow::eventFilter(QObject* pObj, QEvent* pEvent)
{
// We need to check for both types of mouse release, because it can vary on which type happens when resizing.
if ((pEvent->type() == QEvent::MouseButtonRelease) || (pEvent->type() == QEvent::NonClientAreaMouseButtonRelease)) {
QMouseEvent* pMouseEvent = dynamic_cast<QMouseEvent*>(pEvent);
if ((pMouseEvent->button() == Qt::MouseButton::LeftButton) && m_bUserIsResizing) {
printf("Gotcha!\n");
m_bUserIsResizing = false; // reset user resizing flag
}
}
return QObject::eventFilter(pObj, pEvent); // pass it on without eating it
}
// override from QWidget that triggers whenever the user resizes the window
void MainWindow::resizeEvent(QResizeEvent* pEvent) { m_bUserIsResizing = true; }
It's slightly more complicated than the timer, but more robust.
I've do it in this way:
inherit my class from QWidget
define private variable int timerId = 0
overload QWidget::resizeEvent and QObject::timerEvent
void MapLoader::resizeEvent(QResizeEvent *){
if (timerId){
killTimer(timerId);
timerId = 0;
}
timerId = startTimer(5000/*delay beetween ends of resize and your action*/);
}
void MapLoader::timerEvent(QTimerEvent *te){
/*your actions here*/
killTimer(te->timerId());
timerId = 0;
}
Mouse events on windows decoration are managed by the underlying window system, this is why you can't catch them as you tried.
I had the same issue once, the solution I chose was to (re)start a singleshot QTimer on each resize event, and only process the update after the timer interval elapsed. Not very sexy but I did not find any other workaround..
Another way would be to install an event filter for the app and get all the events of the application, trap mouse press and mouse release and do not update the window in between .
"Installing an event filter on QCoreApplication::instance(). Such an event filter is able to process all events for all widgets, so it's just as powerful as reimplementing notify(); furthermore, it's possible to have more than one application-global event filter. Global event filters even see mouse events for disabled widgets. Note that application event filters are only called for objects that live in the main thread."
My Qt app uses image windows and does complex layered rebuilds, which can take some time even on a very fast machine. So not having the window redraw with every change in the window frame size was important to me so the response to the window frame resize would not be laggy.
So I solved it this way:
In my image window, I have enabled mouse tracking:
setMouseTracking(true);
Then, in the window class, I have a boolean, puntme; this is set when a resize event is caught:
bool puntme;
Then, in the mousemove event:
void imgWindow::mouseMoveEvent(QMouseEvent* event)
{
if (puntme)
{
puntme = false;
needRebuild = true;
update();
}
...
Basically, what this does is as soon as the user moves the mouse over the window -- which is a pretty natural thing for them to do if they were just resizing it -- then the window redraws with the new size. It doesn't happen during the resize, because Qt isn't forwarding move moves then.
Instead, during the resize, I just scale up an already existing bitmap, which gives a crude approximation of the change in scale with necessarily handling the actual newly more-or-less available resolution.
Worst case, user resizes, moves away from the window, and leaves the crudely scaled bitmap in place until the come back to it, at which point it will duly update to the actual new displayed bitmap == scale/size conditions.
There's no perfect way - what is really needed here is for Qt to provide (user has stopped resizing window" message, but in lieu of that, this has been working well for me.
I want to allow a user to drag my Win32 window around only inside the working area of the desktop. In other words, they shouldn't be able to have any part of the window extend outside the monitor(s) nor should the window overlap the taskbar.
I'd like to do it in a way that does cause any stuttering. Handling WM_MOVE messages and calling MoveWindow() to reposition the window if it goes off works, but I don't like the flickering effect that's caused by MoveWindow().
I also tried handling WM_MOVING which prevents the need to call MoveWindow() by altering the destination rectangle before the move actually happens. This resolves the flickering problem, but another issue I run into is that the cursor some times gets aways from the window when a drag occurs allowing the user to drag the window around while the cursor is not even inside the window.
How do I constrain my window without running into these issues?
Windows are, ultimately, positioned via the SetWindowPos API.
SetWindowPos starts by validating its parameters by sending the window being sized or moved a WM_WINDOWPOSCHANGING message, and then a WM_WINDOWPOSCHANGED message notifying the window proc of the changed size and/or position.
DefWindowProc handling of these messages is to, in turn, send WM_GETMINMAXINFO and then WM_SIZE or WM_MOVE messages.
Anyway, handle WM_WINDOWPOSCHANGING to filter both user, and code, based attempts to position a window out of bounds.
Keep in mind that users with multi-monitor setups may have a desktop that extends into negative x- and y-coordinates, or that is not rectangular. Also, some users use alternative window managers such as LiteStep, which implement virtual desktops by moving them off-screen; if you try to fight this, your application will break for these users.
You can do this by handling the WM_MOVING message and changing the RECT pointed to by the lParam.
lParam: Pointer to a RECT structure with the current position of the window, in screen coordinates. To change the position of the drag rectangle, an application must change the members of this structure.
you may also want to handle WM_ENTERSIZEMOVE to know when the window is beginning to move, and WM_EXITSIZEMOVE
WM_GETMINMAXINFO is what you seem to be looking for.