Hello Mechman, does your work around only address the slow file load? I ask because disabling SW icons using ShellExView works perfectly for me on that front, but losing the display of unique SW icons is a deal breaker for me. If your approach also keeps the native SW icons, I would be ecstatic.
I also agree with you that if the preview pane worked with SW, that would be a huge bonus.
BTW… I have made both our VAR and Solidworks aware of the issue. SW support did respond, and asked for more input. I have not found the time to respond yet, but I am encouraged they expressed interest. I will update when new info warrants.
Well, I'd just like to add that I'm now using Solidworks 2016 and the issue still persists. The only way I've found to eliminate the problem is to disable the shell extensions for displaying listview icons.
For Jon, Leo. One thing I have noticed with the shell extensions enabled is this: navigating to a folder in opus with a lot (100+) solidworks files causes the lister (in details view) to populate after quite a few (15+) seconds time. After this time, each file is showing its contents in the icon as it should. Doing the same thing in Windows Explorer does something quite different. The listview in explorer is populated immediately. However, Windows Explorer, AFTER populating the listview then proceeds to display the file contents in the icon a file at a time and is quite slow in doing this. It is as if opus is processing ALL the files in the list first behind the scenes and then displaying the list in the lister whereas explorer displays the list first then processes the files one at a time afterwards.
That observation was actually very helpful. We're going to make a change in the next beta which (fingers crossed) may help with this problem. If you could give it a try once the beta is released and report back that would be great.
Thanks Paul! That is how I actually identified the Solidworks issue. For what it's worth, I'm running SW15. And also, I experience exactly what you have with explorer.........list quickly populates and THEN shows the icons.
I agree mostly with the recent posts, but it should be made clear that while windows explorer’s rendering of the icons does lag its near instantaneous list population, it is still quite quick. It also is a one-time issue per explorer session – that is, if you navigate away from the folder and back again, the icons remain cached and are still there with zero lag for the remainder of a given session.
The issue with DO is a long file list can take 15 seconds, 30 seconds, and longer to load the file list every time you navigate in, out, and then back into the same folder… very frustrating.
One additional piece of info. I too turn off the icon display with shexview. Consequently I use thumbnail mode in DO to browse SW files. Unfortunately this seems to sometimes cause DO to start hogging the CPU… constantly running at 13%, and sometimes a constant 25%. Closing SW and the SW folders does nothing. I have to kill the DO process and re-launch to bring it back to the typical DO < 1%
But this is not consistent… for example, I was unable to duplicate the behavior prior to this post, so this may be specific to my setup.
In any event, I sure hope your next beta fix works… I too will have my fingers crossed. When is the release date that will contain the fix?
The change Jon is talking about will only speed up the initial display of the list of files.
I will not affect the thumbnails issue, which sounds like the Solidworks thumbnail shell extension has issues. ShellExView to disable it is the best way to test that theory.
It sounds like the Solidworks shell extensions have issues in general, so while we may be able to make changes which improve some things, it is still worth asking them to investigate and improve the underlying problem, and that's still something we cannot do as it is in their code.
e.g. There's no reason for the icon loading to be so slow in Opus and Explorer, even if the initial list of files can be made to display faster. If so much really needs to be calculated per-file, just to display their icons, then they should be caching the data so it doesn't have to be calculated every time.
I have just come off the telephone to my Solidworks VAR and didn't get that much joy from them. Basically, because it's only an issue for a very small number of users (those with Solidworks AND Dopus) they (Solidworks) would be very unlikely to even entertain a fix. They work on the principle of the more people that raise a bug report or enhancement request then the more likely it is to be addressed. As the number of people with a problem (as reported on this site) is only a handful if that, then I think we've got no chance of getting Solidworks to address their buggy shell extenstions and will have to live with it.
It's an issue with Explorer as well, just less of one. Something is wrong if it takes their icon handler so long to come back with an icon, and if their thumbnailer gets stuck in infinite loops (based on the descriptions in this thread; it could end up being something else).
Perhaps Paul’s lag is much more than mine, but for me, WE renders icons or thumbnails in a about 2 seconds max (and always has for the 16 years I have used SW). That is hardly torturous when compared to the 15+ second lag in DO. And again, the DO lag is every time you go to a folder with SW files. At least with WE, there is no lag when returning to previously opened folder.
I know the folks at DO always point back to SW as the problem, but how is it that every other 3rd party explorer program (that I have tried) has managed to crack this nut? FreeCommander, Q-Dir, Explorer ++, xplorer2, etc. None of these free programs has the problem. In fact FreeCommander instantaneously displays the list AND icons/thumbnails.
I don’t want to sound like I am bashing DO, after all, I first bought DO10, paid for the upgrade to DO11, and will do so again when DO12 is released. I constantly tell others about how awesome DO is (and demo it using my thumb drive DO install), and I imagine some of them have purchased the program as a result. But this continued “defect” when working with SW files is enormously irritating. Sorry for the rant, but the fact that other (free) explorer replacement programs have solved the SW issue (or more accurately, their programs just don’t have the problem) is very frustrating to deal with in a paid-for program.
I also agree with the Paul that it is highly unlikely SW will ever address the issue. The number complaints have to reach a critical mass to gain any traction. And even then, it may be years before it gets incorporated. SW has many tens of thousands of users, so getting them to move is an inertial challenge.
Please wait for the change and see if it helps. If it does then the rest becomes irrelevant. (And many other file managers behave like Explorer because they are thin wrappers around the same components as Explorer. We could equally point out that every other 3rd party icon extension does not take several seconds to supply an icon when asked by Opus or anything else, if you want to assign blame to where it really belongs.)
The change is that we think we've found a place where SolidWorks (and other extensions) may have been called when requesting the generic icon for a file, which is displayed as a placeholder while Opus waits for the proper icon (which is done on a background thread, and will continue to call extensions including SolidWorks).
That doesn't make it our responsibility, if the underlying issue is still in SW.
We can make improvements to Opus, and sometimes add workarounds, but we cannot fix everything that is caused by other software. Just don't expect us to fix all the problems in other people's software, and complain if we don't or can't, while you don't complain to the vendor who is responsible because you're already sure they will ignore you.
Frankly, sometimes it feels like vendors who ignore everyone are rewarded for doing so, while we get punished for listening, engaging, and trying to help even when it is not our problem.
I for one am happy with what GPSoftware has done, and is doing with regard to this issue and I'm certainly not apportioning blame on GPSoftware. I firmly believe this is a Solidworks only issue.
With regard to this statement, I'm on your side. When dealing with large multinational companies such as Dassault Systèmes (Solidworks parent company) the little man counts for nothing. GPSoftware is to be commended for the help and support it provides; even when the problem lies outside of your hands. I'm more than happy with the service, support and product that GPSoftware provides. I wouldn't part with my hard earned readdies to upgrade to the latest version if I wasn't.
I anxiously await the potential fix – do you know when that will be rolled out?
Sorry if I hurt anyone’s feelings in my previous post, but I thought I had made it crystal clear I think DO is a fantastic program, and will continue to use/buy/recommend to others regardless of whether this issue is resolved or not. As far as my not complaining to the VAR or SW directly because I am sure I will be ignored – you must have me confused with someone else. I HAVE brought it to the attention of both! When I find some time, I will try and track down the SPR (their equivalent to a ticket number). I just don’t have any faith it will ever get addressed due to the lack of complaint volume.
BTW - your statement that other replacement programs are merely “thin wrappers around the same components as Explorer” is helpful. That intuitively makes sense as to why they would not have the lag issue (as I imagine DO is complete standalone code).
Finally, you are not wrong that interacting directly with your user base can lead to feeling unappreciated. A thousand apologies if I made you feel that way. So let me state for the record – I love you man! And that love will only grow if this issue goes away.
If you can find the SPR i'll certainly add my support to it. Although, if their support in fixing it is anything like them sorting out their other bugs then we're doomed! Solidworks 2016 STILL has a bug in it from as far back as version 2010 to do with renaming display states. I have often told them via their crash dialogue box that their software sucks!