Describe the bug
In the discussion for #1154, @jgfoster mentioned the problem of the tree views in browsers in an Idea Space do not draw correctly when initially opened (although this may occur at other times too). This is especially noticeable with the package folder tree in a new System Browser card, which can sometimes be seen to draw very briefly and is then erased to the tool background colour (which is usually silver grey). It also occurs, although apparently less frequently, when opening a normal class hierarchy browser, where the hierarchy tree will appear blank.
To Reproduce
Steps to reproduce the behavior:
Open a new Idea Space (e.g. press lightbulb icon on toolbar of the Dolphin launcher window)
In the Idea Space, open a System Browser (e.g. click on the first of the gear icons on the toolbar)
Note the appearance of the package folder tree top left. It is typically a blank background grey.
Move the mouse over the package folder, which will generally cause the underlying folder nodes to be drawn as the cursor moves over them.
Expected behavior
The browser views appear fully painted as they normally do outside an Idea Space
Screenshots
Please complete the following information):
OS: [e.g. Windows 10]
This issue was first noticed on Windows 10, but may occur on older versions.
Additional context
The fault is somewhat intermittent. It can occur repeatedly for a sustained period, and then stop happening. This makes it frustratingly difficult to diagnose/fix, as one is never quite sure whether some change has really affected it or not. However, it does appear to be a timing/ordering issue with the painting where one or more of the parents is erasing the tree after it has been painted. Setting WS_CLIPCHILDREN all the way up the containment hierarchy does appear to correct the issue, but requires some thought and experiment since it may cause other issues, and it doesn't seem like the right fix since it is not needed when the tools are opened outside an IdeaSpace, and the the z-order appears correct when viewed in Spy++. Also once created, the tabs do start to redraw correctly.
The problem is unique to tree views. Other controls, even similar complex controls like ListView, are unaffected. There must be something about the way SysTreeView32 implements erasing/painting that exposes the issue. The IdeaSpaceShell is recreating the views of the tools added to to remove the top-level view styles. The view instances themselves, however, are still ShellViews, and there may be something in the various Windows event handlers implemented in ShellView that should not be happening when the ShellView is not really a top-level window.
jgfoster
commented
6 months ago
Describe the bug In the discussion for #1154, @jgfoster mentioned the problem of the tree views in browsers in an Idea Space do not draw correctly when initially opened (although this may occur at other times too). This is especially noticeable with the package folder tree in a new System Browser card, which can sometimes be seen to draw very briefly and is then erased to the tool background colour (which is usually silver grey). It also occurs, although apparently less frequently, when opening a normal class hierarchy browser, where the hierarchy tree will appear blank.
To Reproduce Steps to reproduce the behavior:
Expected behavior The browser views appear fully painted as they normally do outside an Idea Space
Screenshots
Please complete the following information):
Additional context
The fault is somewhat intermittent. It can occur repeatedly for a sustained period, and then stop happening. This makes it frustratingly difficult to diagnose/fix, as one is never quite sure whether some change has really affected it or not. However, it does appear to be a timing/ordering issue with the painting where one or more of the parents is erasing the tree after it has been painted. Setting WS_CLIPCHILDREN all the way up the containment hierarchy does appear to correct the issue, but requires some thought and experiment since it may cause other issues, and it doesn't seem like the right fix since it is not needed when the tools are opened outside an IdeaSpace, and the the z-order appears correct when viewed in Spy++. Also once created, the tabs do start to redraw correctly. The problem is unique to tree views. Other controls, even similar complex controls like ListView, are unaffected. There must be something about the way SysTreeView32 implements erasing/painting that exposes the issue. The IdeaSpaceShell is recreating the views of the tools added to to remove the top-level view styles. The view instances themselves, however, are still ShellViews, and there may be something in the various Windows event handlers implemented in ShellView that should not be happening when the ShellView is not really a top-level window.