I had a user today report (and then show me) Opus expanding every drive (local and network) to 2 levels of subfolder. I don't see anything in the options that should cause that but it is happening. I don't know if anyone else is experiencing it yet. I tend to think not since it's very disruptive to the usage of the Folder Tree and no one else has reported it.
Could we see a screenshot of that, right after it happens?
Also of the Folder Tree settings if possible.
I'll get that tomorrow when the user is available again. I've tried to trigger it myself with Folder Tree settings and so far haven't been able to.
Remember the version I'm using is the latest debug version you guys made for me (prior to the one Jon just made which I expect to be installing tomorrow night). Prior to this current version no one had ever reported this happening.
Here are the images you requested. For confidentiality reasons I've had to blur the folder and file names.
Many thanks. That does seem strange, since the expanded folder there does not look related to any folder open in the folder tabs, at least from what I can see.
The tree has a hotkey, Numpad +, which will expand two levels down from the selection. (If the selection is not already expanded, it would happen on the second press.)
-
Is it possible that Numpad + is being pushed, maybe being used as a hotkey for something else at the same time, or intended for a different window without noticing Opus has focus? (Or via automation software, perhaps.)
-
An Opus script add-in which runs on lister or tab open could also cause something similar. Are any scripts installed? (Preferences/Toolbars/Scripts)
Thanks. I'll see if the Numpad + key suggestion leads anywhere. We don't have any automation software.
I can report that the user told me that when they logged on to the server (yes it's the server installation I'm having a problem with again) from home last night it didn't happen. Since it's the very same user profile and installation as when they use the server from their office computer that didn't make much sense to me. Perhaps there's something particular on this user's work computer that's sending the numpad + key to the server session. It being something in the Opus script add-in seems to be ruled out by this information.
A weird thing about it, I think, is that it expands every drive not just the one that the user's looking at in the file window(s).
The user has noticed that the problem seems to be linked to their saved Layout. I've got a backup of his configuration and will be exploring this problem using that backup.
On a related note, I'll be installing the latest beta from Jon tonight which might have an impact on the problem one way or another.
Re-saving the layout with the tree branches collapsed might be worth a try, although I think we only store the top-level expand/collapse state of the tree into layouts.
If you go to /dopusdata/Layouts and look at the .oll file for the layout, there should be a <tree_expand> section with the IDs of the top-level branches that are expanded. It's usually a list of GUIDs so is a bit opaque, but if there is a huge list there, instead of 0-10 or so items, then it might indicate something unexpected in the layout:
Unfortunately, that doesn't seem to be it. Here's that entire section in his Layout's .oll file
<tree_expand>
<tree1>
<item id="{B52C30E0-7FF9-47CC-B112-A3D9374CD79E}" />
</tree1>
<tree2>
<item id="{B52C30E0-7FF9-47CC-B112-A3D9374CD79E}" />
</tree2>
</tree_expand>
1 Like
Saving the Layout with the drives in the folder tree didn't help the issue, unfortunately.
From what I understand this issue started with the upgrade from DO 11 to DO 12 just like the other issue we just solved. I wonder if this user having so much of the folder tree expanded all the time would have had the effect of worsening the File List window update issue?
I have a backup of the user's DO profile and am going to explore it a bit myself this afternoon.
Would it be possible to test if restoring their config backup to another account and/or machine results in the problem occurring where it didn't before? That would confirm it's something somewhere in their config.
If it is, we can try to narrow down the part of the config that causes it. (I'm assuming it wouldn't be possible to email the whole config to us for confidentiality reasons, but if we can narrow it down to one place, it makes it easy to check a few files for data scrubbing and send just those to us.)
Re file changes, the tree being on or off is the main factor. I don't think it would have a huge impact to have more folders expanded in the tree, although with a really large number it would slow things a bit, just by having more tree items to search through when one needs to be found to update it.
That's exactly what plan to do but haven't had a chance to do yet.
You are probably right that I can't send you the configuration. I'm sure there's something confidential in it somewhere.
1 Like
I've interrupted myself for a few minutes to finally have a look at this user's Opus profile by restoring to my own profile. The problem occurred when I did that. So far I haven't found a cause for it.
I've been able to affect the issue by locking the folder tree. If I lock the folder tree then it doesn't auto expand.
However, I have noticed some other odd behavior
- the profile is to show the splash screen but doesn't show it when Opus is started
- if I navigate to a particular folder in the folder tree and then save the default lister the folder tree doesn't open to that folder when Opus is restarted
- if I save the default lister with My Computer selected the folder tree doesn't auto expand
- if I save the default list with a drive letter selected then the folder tree expands all drives to just 1 level
I'm starting to think that there's some kind of corruption in the user's Opus profile.
The splash screen will only be displayed if it is turned on, and if Opus is run in a way which doesn't cause a lister to open. If a lister opens then it'll cancel the splash screen. (Splash screen is to help new users who might launch the program in the background the first time and wonder why nothing happened or how to open a window.)
-
If only the tree (not the file display) is not going to the starting folder:
It might be taking too long to read folders into the tree so the auto-expansion eventually gives up. (That's to avoid a situation where you start using the tree and the directory listing finally comes back and starts moving things around underneath you.)
Selecting No content population at the top of Folder Tree / Options may help by reducing the number of folders which are read:
-
(Unlikely, given other context, but for completeness:) On the other hand, if the file display is not opening to the folder as well, it's probably not the default lister that's being opened.
(e.g. If the default lister is updated, but a saved layout is then loaded, the layout would be the same as it was before.)
If the tree prefs as still the same as before (copied above, from earlier in the thread), it has expand selected branch off, as well as the separate option to always expand My Computer, so that seems correct, I think?
So making it start in, say, C:\ results in C:\ and all the other drive letters all being expanded, showing the folders below each drive?
That I definitely cannot explain, at least yet.
You might be able to narrow down the cause by starting with a vanilla /dopusdata folder, then copying a few folders over at a time and seeing when the problem starts. That might be a quick way to isolate it to a particular config folder or file, and we can hone in farther from there.
It is definitely a strange one so far, but with it reproduced in another account we should be able to find a cause and change either the user's config or the code in Opus to cope with whatever is happening better. (Or both!)
Sorry, I lost track of this. I'll try to narrow it down by copying folders on Tuesday
The problem seems to be caused by this bit of the user's layout's .oll file. If I remove the stuff between the open and closing tree_expand then the problem goes away. We discussed this bit of the layout file previously.
<tree_expand>
<tree1>
<item id="{B52C30E0-7FF9-47CC-B112-A3D9374CD79E}" />
</tree1>
<tree2>
<item id="{B52C30E0-7FF9-47CC-B112-A3D9374CD79E}" />
</tree2>
</tree_expand>
Perhaps one or both of these are references to a folder that doesn't exist and Opus is expanding everything to try to find it?
That worked for me when I had copied enough of the user's profile folders into my own profile but removing those lines from the user's .oll file in their profile didn't help at all.
Wiping out the user's entire layout file didn't help, either. I'm going to give up on finding the source of this issue and try deleting their entire Opus profile and starting over from my default corporate profile. I expect to do that tonight. Hopefully the problem disappears after that.
That didn't work. I deleted the user's Opus folders in local and roaming AppData and it created new ones and I recreated the user's layout (dual vertical) with their default tabs and column arrangement and saved it as the default lister and they're reporting the issue continues.