I have ported my application to be built with Visual Studio 2013.
After building it, I found that the resizing mouse shape is interchanged.
The first shape of mouse pointer appears when I want to resize a vertical splitter and the second one appears when I want to resize a horizontal splitter: this behavior is new. In the previous release of my tool, the first one appears when I want to resize a horizontal splitter and the second one appears when I want to resize a vertical splitter.
I didn't change anything in the code. How can I make it to reproduce the old behavior?
We found that we use a third party MFC libraries and we use the cursors from them; in the new release, they have swapped the names of the icons of the cursors and this is the root cause of this problem. As a workaround, we have swapped the names to give the old behavior.
Related
Premise: I need to change the colors of the default CScrollBar defined in MFC (thumb + track + arrows), but after doing some research I realized that this isn't exactly an easy task.
Question: would it be better if I tried to draw OVER the existing scrollbar, or should I create a new scrollbar control from scratch?
If I limited myself to drawing on it, I would have the advantage of not having to manage all the messages that deal with the other features of the scrollbar (in addition to the drawing), but it is VERY complicated to find all the points where windows redraws the bar, since the scrollbar is not redrawn only in the OnPaint() method.
If I redo it from scratch, I would no longer have the problem of identifying all the points where the bar is redrawn ... but on the other hand I should reimplement all the scrollbar features from scratch.
I've already looked at this link:
https://www.codeproject.com/Articles/14724/Replace-a-Window-s-Internal-Scrollbar-with-a-custo
but the proposed method does not seem to work for newer versions of Windows (from Vista onwards).
Any advice is appreciated, thanks in advance.
We had exactly the same problem and your attempt to overdraw the original scrollbar was what we tried first. We dropped that attempt again due to some issues, which I don't remember in detail (not receiving all mouse or draw messages, flickering, ...). Our solution was some effort, but works now:
We implemented first a class CCustomScrollBar, which is NOT derived from CScrollBar, because the CScrollBar is just a wrapper around the Windows implementation and overwriting OnPaint() doesn't work perfect. And yes, all things must be implemented from scratch.
Second we implemented a template class CWndCustomScrollBar keeping two CCustomScrollBars and managing all around them as a standard window would do with its embedded scrollbars. The free client area then can be achieved via a method GetClientRectWithoutScrollBar() to work similar as a standard window would do.
I stumbled upon a strange problem today on one of my client's Windows XP SP 3: deleting with BACKSPACE or DELETE buttons a text from a CEdit won't work. To be more accurate, i place the cursor at the end of the text, and hitting the BACKSPACE button will result in moving the text cursor to the left, but deleted characters won't dissapear. The actual delete takes place, because if i force a refresh of the window, the deleted characters are missing.
I guess is a paint issue, but i can't find what's wrong and how to work around it, and i couldn't reproduce the bug elsewhere.
I checked the code, and the CEdits that behave like that have no events overriden, and no special properties set.
My answer is a guess: You overwrote WM_CTLCOLOREDIT and you are returning a NULL Brush to draw transparent.
The result is what you see. Without the capability to overwrite the background the edit control shows artifacts...
This "trick" of drawing transparent in Standard controls isn't a real good one but it is spread all over the Internet so that everybody uses it without knowing the drawbacks. Usually this works only for static controls that don't change.
I discovered that in the latest Qt versions (currently I use 5.4.1 but it was the same in 5.2) if I add several items to a QComboBox and I position the mouse cursor in specific positions it will scroll itself which is really annoying ... I think.
I've got a very simple GUI created in Qt Designer. It only contains one QComboBox. I added a lot of items (30) to it to be able to check this bug. If the first N items are visible it cannot be reproduced, but if I scroll down a little, and then position the mouse as on the image with the red dot and starts moving the mouse around it then the auto scrolling started.
It does not seem like a great bug, but when you just want to move the mouse cursor away and it results that the list scrolls away.
UPDATE:
I found out that it can be only reproduced if the first item in the list is an empty string. Without that it works just fine.
It is a bug in the version of Qt 5.4.1. Reported.
I'm using Qt5 in Windows. I just created a simple little widgets project in Qt Creator. I have a QMainWindow with a text edit widget inside. I enabled vertical layout, so the text edit consumes the full size of the inside of the main window (which is what I want, I'm trying to create a small notepad app).
As I drag the bottom right corner of the main window during the preview (I click the green triangle in the bottom left) I'm seeing a slight delay in the child widget's resizing. It doesn't exactly resize with the parent window on the same render frame (it seems like it is 1-2 render frames behind).
I remember years ago dealing with render lag like this in old school Win32 API. I remember I had to do double-buffered rendering into an offscreen bitmap to fix it (or something along those lines; been a long time).
Is there a way to fix this "render lag" in Qt? I can only imagine this is specific to Windows and might not impact other platforms, although I have not tested. If I need to provide more information let me know.
It is likely a Windows problem, not Qt's. The more GUI-heavy your window is the more noticeable it is.
I investigated the same issue a while ago. We had a rather GUI-heavy window, with several widgets displaying 2D and 3D views of data. Resizing the window using lower-right corner resulted in a resize-redraw horror. Unfortunately it looks like the problem is not Qt related but rather the way that Windows handles redrawing a resized window. I was able to notice the problem even in the file explorer on Windows 7. Qt is indeed using double buffering by default (as mentioned in the comment by #Bim). I also tried explicitly triggering Qt's repaint events. This helped a little, but did not solve the problem. So after many efforts we just decided to live with it.
I have a top-level Qt widget with the FramelessWindowHint flag and the WA_TranslucentBackground attribute set. It has several children, each of which draws an image on it. They are not in a layout. Instead, I simply move them around when something changes (it is not user-resizable).
There are two states to the window - a big state and a small state. When I switch between them, I resize the window and reposition the children. The problem is that as the window resizes, a black box is briefly flashed on the top-level window before the images are painted over it.
The problem goes away if I disable Aero. I found brief mention of this problem being fixed in an article describing a new release of Qt (this release is long past), but it still doesn't work.
Any ideas why?
Thanks!
I don't have experience with Qt specifically, but I have worked with other windowing toolkits. Typically you see this kind of flashing when you are drawing updates directly to the screen. The fix is to instead use Double buffering, which basically means that you render your updates into an offscreen buffer (a bitmap of some sort, in the purest sense of the word), and then copy the entire updated image to screen in a single, fast operation.
The reason you only see the flickering sometimes is simply an artifact of how quickly your screen refreshes versus how quickly the updates are drawn. If you get "lucky" then all the updates occur between screen refreshes and you may not see any flicker.