A fellow DPL 3 user has the following problem with DPL3, even after a clean re-install. The Folders pane only shows the Desktop icon and the folder tree is collapsed. The Expand/Collapse icons are not shown. The folder tree cannot be opened. Double-clicking the Desktop icon has no effect and since the Expand/Collapse icons are not there, they obviously can’t be used to open the folder tree. There’s nothing that can be done to get the folder tree opened.
Anyone having seen this problem with Windows 8.1 ?
The root cause of this problem has been found : the HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders was missing. Problem solved.
However, this raises a problem regarding how the TreeView control in the Folders panel is programmed. On the affected system, all applications using the TreeView control were functioning normally. Only DPL had a problem. I did some monitoring during the DPL startup and I found that it was always trying to access the above mentioned registry key (Desktop value), probably to retrieve the user’s desktop path in order to provide the root item of the TreeView. If the key doesn’t exist, there’s obviously a problem.
Since the absence of the registry key was only affecting DPL, I’m wondering whether the code managing the TreeView control is retrieving the user’s Desktop path directly from the registry instead of using the relevant API. Windows has fallback mechanisms allowing to return a valid answer even if something is wrong in the registry. If only DPL fails when the registry key is missing, this seems to indicate that it tries to retrieve this information from the registry directly. After restoring that key with default values, DPL worked again normally.
So maybe a quick look at this code could be worthy.
Do you know why this registry key was missing on your system? Have you ever installed any application that could modify the standard look’n’feel of your Windows?
Our file system control is based on some 3rd party library that we use to extract information about file system objects. It in turn may directly access the Windows registry. In any case your information is useful for us and gives us a good track for investigation so we can improve PhotoLab and make it resistant to that operating system corruption.
As mentioned in the OP, this was not my system. So, I don’t have any information about what happened on this machine.
If it does, drop it or modify it. The .Net Framework has enough classes allowing to access such information through the Windows API. I have been programming Windows since the beginning and there’s one thing I have learned very early : ascending compatibility has always been maintained by Microsoft provided one uses the relevant APIs to access information instead of assuming that such or such data will always be available at the same place. The same rule applies to data types : using “official” data types in Windows code has always made maintenance easier.
As a developer, I also used third-party libraries but only when the source code was provided. This way, I was able to detect and fix bugs in these tools.
