When using a QListWidget in batched layout mode, whenever more items are added than the batch size, the list widget blinks for a short time when switching from the old list to the new list. This means, the list widget shows no items, and the scroll bar handle is set to a seemingly random size.
Have you ever encountered this, can this be resolved somehow? I'm using Qt 4.7.4. I should probably add that I'm not using any hidden items.
I had this issue also and spent hours combing through the sea that is Qt widget rendering. Ultimately, like you, I traced the problem back to the batch processing of the QListView. It appears, that when batch processing is enabled, Qt fires off an internal timer to perform incremental layout adjustments of the underlying scroll view. During these incremental layouts, when the scroll bar is visible, the update region is not computed correctly (it's too big and does not account for the regions occupied by the scroll widget(s) themselves). The result is a bad update region that subsequently finds its way into the viewport update which has the unfortunate side-effect of clearing the entire client area without rendering any of the ListViewItems.
Once the batch processing is complete, the final viewport update correctly computes the layout geometry (with the scroll bar) and produces a valid update region; the visible elements in the list are then redrawn.
The behavior worsens as the number of items in the list grows (relative to the batch size). For example, if your list grows from 500 to 50000 items and a batch size of 50, there is a proportionate increase in the number of "bad repaint" events which are triggered causing the view to visibly flicker even more. :(
These incremental (and failed) viewport updates also appear to be cause the apparent spazmodic behavior in the scrollbar handle position that you describe.
The root of this issue appears related to this "hack" that was added to
QListView::doItemsLayout() as commented here:
// showing the scroll bars will trigger a resize event,
// so we set the state to expanding to avoid
// triggering another layout
QAbstractItemView::State oldState = state();
setState(ExpandingState);
I suppose you could override QListView::doItemsLayout() and provide your own batch processing which handles scroll bars properly, but personally I'm too old and lazy to be cleaning up someone else's poo. Switching to SinglePass eliminated the problem entirely. Seamless flicker-free rendering and the scroll bar behavior you've come to expect and love. Yay.
Related
I am writing an application in C++ using WinAPI.
I have a ListView of items with checkboxes and a scrollbar. Sometimes I need to disable the whole thing. When I call EnableWindow() to do that, the behavior of ListView is ok. It gets disabled, none of the contents are accessible any more. However checkboxes and scrollbar still look normal (not grayed out as the rest of the element).
Is it possible to grey out all parts within the ListView?
Enabled
Disabled
Normal disabled checkbox looks liks this: <- this is how I would expect to see checkboxes in the ListView, same applies to the scrollbar.
Regarding the checkboxes, the documentation for LVS_EX_CHECKBOXES says:
When set to this style, the control creates and sets a state image list with two images using DrawFrameControl. State image 1 is the unchecked box, and state image 2 is the checked box. Setting the state image to zero removes the check box.
You can therefore just change those images at indices 1 and 2 in the image list to their properly disabled variants when you are disabling the whole control.
The process itself of course varies depending on the framework you are using (if any), but generally will be along the lines of creating an Image List of SM_CXSMICON×SM_CYSMICON icons, creating a bitmap (2*SM_CXSMICON × SM_CYSMICON) pixels big, selecting it into a Memory DC for drawing, calling DrawFrameControl(..., DFC_BUTTON, DFCS_BUTTONCHECK | DFCS_FLAT | ..., ...) twice as appropriate, then using that bitmap in the Image List (and saving the previous IL to restore when the window is enabled again).
Regarding the scroll bar, you cannot get access to the implicit scrollbar as a separate window, so I don't think you can easily make it look more disabled without resorting to more custom drawing hacks for the non-client area of the List View.
Or creating an explicit scroll bar control yourself, but then you need to make sure it behaves the same as the original one, changes when the list view items change, respects right-to-left locale and so on.
It might be a bit of a challenge to get all the offsets and possibly transparency right even for the custom checkbox images described above. Even though this is how the List View control itself does it, it might not be worth the effort in the end.
My objective is to have a CToolBar derivative which has a single control on it (a CMFCShellTreeCtrl).
Something like:
class CFileTreeBar : public CToolBar
Whenever it is asked to compute its size, I want to respond that it is either a fixed minimum, or the size of the client area of the dock bar to which it is docked. In other words, it should consume the entire height of the dock bar + a fixed width (this is being docked on the left - exactly as Explorer lays out its folder tree on the left).
Hence, in CFileTreeBar::CalcFixedLayout it responds with height based on GetParent()->GetWindowRect(rect), and a width of 250pix.
Then in OnSize, the CFileTreeBar resizes its CMFCShellTreeCtrl to consume our client rect (maximizes our only control).
This works beautifully for when the control bar is initially displayed. And it works great when resizing the window by dragging a corner. The CaclFixedLayout returns a different value from its previous value (because the window size changed) and so it computes that it should consume the entire vertical space and eventually I get an WM_SIZE message telling my control bar to resize, which causes me to update the size of the CMFCShellTreeCtrl.
Where I am struggling is when hitting "maximize" button on the CFrameWnd. In this case, for reasons I don't really understand, the CalcFixedLayout is called but the dock bar has its old size (it hasn't been updated to the new sized based on being maximized yet). This causes my code to respond that the size should be the same as it was previously - which causes MFC frame work to not issue a resize (we're already the size we claim we need to be).
Hence, a moment later the dock bar is expanded to consume the whole vertical space, but my control bar and its underlying shell tree are not resized - but left behind with the stale size.
The problem happens also when going from maximized to restored. At that point the call to CalcFixedLayout indicates that we should be as tall as the maximized window (its current size), and now the frame work kicks off the resizing code which ends up making us larger than the dock bar (once it is resized down to restored size), and we disappear below the bottom of the dock bar (clipped by it's maximum vertical extent).
Questions
Is there a good tutorial or white paper showing the overview of how dockbars and control bars are supposed to interact in MFC? i.e. a complete description of how this frame work is supposed to hang together properly? Understanding how these pieces fit together and are intended to work coherently would go a long way towards avoiding hacking it to work, allowing me to write something round to fit the round hole, so to speak.
Is there an example project similar to this that anyone is aware of? Having to figure this junk out is incredibly time consuming - if there is an example somewhere which does this, then that would be great...
Dockable and resizable toolbar is quite complicated to code, there is one in codeproject which is quite good. You can study the source code to see how the author do it.
http://www.codeproject.com/Articles/6/CSizingControlBar-a-resizable-control-bar
I have a ListView-like control that displays a list of items of various heights. The contents of the list, and the heights of the items can change – a background thread is populating the list and calculating the layout of each item, possibly even while the user is scrolling the content.
Which brings me to my question: How do I display a useful vertical scrollbar for this view? I’ve seen cases (notably web browsers) where the slider “jumps away” from the mouse cursor while the user is dragging it, the result of the underlying content growing in height. I don’t want that.
So far
Instead of the slider representing the viewport height relative to the content height, maybe it could represent a point in a timeline instead? (The items are sorted by timestamp). This would at least prevent the scrollbar from changing as item layouts are calculated.
Get rid of the scrollbar altogether and use a forward/backward rocker switch like the one used in Picasa (the further the slider is pulled upwards or downwards, the faster the view is scrolled, until the user releases the slider). If I take this route, are there any controls you can recommend?
I am using Qt, but this applies to UI design in general.
IMO the fundamental problem with a classic scrollbar is that due to background population, the valid range is changing - and thus, the meaning of a scrollbar position changes.
If you can predict the full range of items, you can still provide a scrollbar and replace yet-unknown items with "loading...".
Otherwise, a rocker (is that an official name?) would be the next best thing to use.
However, since you have a dedicated scale (timeline), it might be better to have separate buttons that jump a dedicated time (e.g. one minute, one hour, one day, ..). For a fancier look, you could create a rocker with "hot" areas that jump for a specific time, whereas the areas inbetween are interpolated (linear or or logarithmic, depending on the scale to cover).
i.e. line this (drawing just the "backward" half):
--------------------------
|##|XXXXXXX|##|XXXXXXX|##|
--------------------------
-1h -1m -1s
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.
I have a CDHTMLDialog running in IE that has a fixed size that I chose, and runs in a fixed window to match this size.
My problem is that the user can zoom on it (by ctrl-mousewheel) causing my html to be larger or smaller than the window which looks awkward and adds annoying scrollbars. Also, the user might use ctrl-+ or ctrl-- to change the html size, which also causes my CDHTMLDialog to become larger or smaller (though only on navigation after changing size).
Anyone maybe has an idea on how to prevent all zooms on the CDHTMLDialog, including wheel and ctrl-+?
Found it :)
Upon document complete I run the following:
CComVariant vZoom = 100;
m_pBrowserApp->ExecWB(OLECMDID_OPTICAL_ZOOM, OLECMDEXECOPT_DODEFAULT,&vZoom, NULL);
Which resets zoom in my DHTMLDialog to 100%.
Source: Here