I have a lot of Solidworks CAD files in various folders on my computer. When trying to access these folders using opus the lister takes a LONG time (5-10 seconds typically) to populate say 50 files when using Details mode. The time taken appears to bare a relationship to how many files are in the folder. At first I thought that this was because Opus was trying to draw an icon which represents the CAD model, so I turned on generic icons for all folders. This made no difference. Using windows explorer (in Details mode) does not exhibit this delay - it is pretty much instantaneous and I get the icon representing the cad model. What I have noticed is, if I use thumbnails view in opus the delay is less (typically 2-3 seconds) even though opus gives me a nice large thumbnail of the CAD model. Any thoughts/fixes for this slow behaviour in details mode? Could it be that in Details mode opus is trying to access some metadata that it doesn't in thumbnails mode?
Readind the wiki entry, this paragraph may be what is causing the problem:
SolidWorks files use the Microsoft Structured Storage file format. This means that there are various files embedded within each SLDDRW (drawing files), SLDPRT (part files), SLDASM (assembly files) file, including preview bitmaps and metadata sub-files. Various third-party tools (see COM Structured storage) can be used to extract these sub-files, although the subfiles in many cases use proprietary binary file formats.
Solidworks 2010 SP3.1 opens/saves following file formats:
Which columns do you have displayed? Try turning off all columns except Name and see if it is still slow.
File formats which use structured storage can trigger deep virus scans which cause delays when the files are opened (which Opus will do to populate certain columns), although it'd be odd (but not impossible) if they're only triggered by details and not thumbnails mode.
If you have any label-filters set up which use tags or other metadata, try disabling them.
Also, try using ShellExView to disable shell extensions which may be involved, particular ones to do with Solidworks. (After disabling them, fully exit Opus, then re-open it.)
Thanks for the help Leo. Disabling all columns except filename made no difference. Disabling the shell extensions has cured the problem. The only problem now is that I don't see (obviously) a thumbnail of the CAD model - which is very useful as a lot of models are filed by part number; not description. Now I know what the issue is, I'll selectively reinstate the shell extensions to see if I can get the right balance of thumbnails and speed in opus.
I've seen a Process Monitor log from someone else which showed the Solidworks shell extension apparently causing long delays when obtaining icons or thumbnails for Solidworks files, and it looks like the shell extension causes issues outside of Opus as well.
This thread may be useful to anyone experiencing slow directory reading or other problems when Solidworks files are involved:
In just the last few days, I also began experiencing extensive delays for any folder that contains SolidWorks files... more files = longer the delay... sometimes as long as 30 seconds to display the list for large file counts.
I have been using Opus since August 2011. Since that time, I have used Solidworks 2010, 2011, and 2012 with zero problems. A few days ago, I installed SW 2014, and the delays began. Ironically though, the day prior to installing SW2014, DO 10.5.5.0 was auto-downloaded and installed, so I cannot be sure which one (or both) is the culprit. I installed DO 11 (trial version) to see if that would resolve the problem, but it does not. I also downloaded and installed the sldShellExtServer.exe (as noted in Leo's post above) and disabled the suggested extensions, which does resolve the delay, but at the expense of not showing the unique SW icons for parts, assemblies, and drawings. This for me is a deal breaker, as I am dependent upon proper icon display when searching file lists.
Files are (still) displayed instantaneously in Windows Explorer (as already noted by Paul), which means it has to be something in DO. Is it possible to roll back to a 10.5.4.0? I know there was no delay with that specific version, albeit that was with SW2012 (reminder that SW2014 and DO10.5.5.0 were ironically installed back to back). I figure this might at least eliminate one more variable.
I found a bunch of older DO versions that are downloadable at blog.dopus.com/, but every time I downloaded one of the "older" versions and checked the file properties, it indicated the version was actually 10.5.5.0 (so I did not bother to install). I am in desperation mode... Solidworks is my livelihood's life blood, and I cannot go back to WE! Please help...
Very little changed between 10.5.4.0 and 10.5.5.0, and nothing in any area likely to affect what you're seeing.
Since SolidWorks has caused problems in the past, it seems a safe bet the problem is with it.
It not causing problems in Explorer is not surprising since Explorer is the one thing SolidWorks will have tested with. Some slight difference in how Opus works must be causing them to go wrong in some way, but what the difference is or why is impossible for anyone except the SolidWorks authors to diagnose, since doing so would require the source code to their shell extensions.
Hello Leo, thanks for the speedy response. However, I think you may have misread my post. You said:
The point I was trying to make about previous versions of SW with DO, was that until now, I have never had any issues. Perhaps you are referring to other programs that SW has had other problems with?
I understand the predicament of not having SW source code to assist in diagnosis, but I would still like to try DO 10.5.4 as a possible solution. In the 14 years I have used SW, I am amazed out how many times I have tried a fix that seemed unrelated to the issue at hand, yet when implemented, the problem went away... what can it hurt to try?
More importantly, I dread uninstalling SW2014 (at 7gb) and then reinstalling SW2012 (at 6gb) just to check to see if that is where the problem lies. That is bit of an undertaking, not to mention all the orphaned registry entries that would result. Though I do have Revo Uninstaller, so that helps a lot.
I ask again, is there a way for me to download 10.5.4 so I can test out my theory?
Thank you for providing the 10.5.4 for testing. As you predicted, the older version did not resolve the issue, but it was a relatively painless test to carryout. However, I discovered something interesting prior to performing the reinstall.
I mentioned in my 1st post that I had disabled the various SW shell extensions using the ShellExView program. After re-enabling the extensions (so I could see my beloved SW icons again), the delay has, inexplicably, is now significantly less. And this is after 2 days straight of lengthy delays with many reboots. Make no mistake, there is still a delay... 1 to 2 seconds on my set up (ASUS P8Z77-V Deluxe MoBo, core i7 3770K overclocked to 4.2gHz, 2x SSD in Raid config, 16gb RAM). While this delay is still very aggravating given how many times I navigate in and out of my CAD folders, at least I am no longer on the verge of chucking my box across the room (like I was when it was taking 5, 10 or more seconds to load a file list).
I love Opus, and as stated previously, depend on SW for my income, but this delay, reduced though it may be, is a huge deal. Surely you guys can consult with a SW VAR in your neck of the woods and explain the situation? SW is, like you folks, very responsive to customers. I would be shocked if they were not willing, nay, enthusiastic! at the prospect of finding a mutually beneficial solution. OK, I may be overselling it a bit, but I really believe they would very cooperative in rooting out the issue.
We don't have SW installed or a licence to use it, and know nothing about it, and we're not customers of theirs, so we're not really in a position to report bugs to them about their software. We could only send them to this thread and, if they can't reproduce the problem, ask them to contact you for details of your setup and files.
It'd be better if you contact them directly, since they'll probably need more information from you. We can provide them with an Opus licence if they need one for longer than the 60 day trial period and we'd be happy to talk to them if they raise any issues, but they are the only ones who can actually investigate the problem as the problem is happening within their code, which we don't have.
I realize you are not their customer, but figured that ultimately any solution would have to be done in conjunction with GPSoftware, so I was just cutting out the middleman (me!). I will call our SW VAR tomorrow and make them aware (if they are not already) of the issue for their next SP.
You do mention something interesting though... like DO (and most software I suppose) SW offers a 30 day trial period as well. Perhaps you can download it and see the problem first hand? Here is a link: mcad.com/solidworks-free-trial/
This is the reason I've not upgraded my version of Opus 9. In my opinion this is not a Solidworks problem, because Explorer works correctly as does Explorer². When using Opus it usually takes 5 to 12 seconds to open a folder with SW files.
The only reason I keep using it is for the sync function and even then I mostly use Syncback.
There can be lots of reasons a problem in a shell extension only happens in Opus and not Explorer. Most extensions are only tested with Explorer and thus may accidentally rely on quirks of how Explorer uses them or other things which are true in Explorer but not actually part of the API.
Equally, I can say that "no other shell extension is causing this problem in Opus, so it must be Solidworks." If the SW shell extension is disabled, the problem goes away, according to an earlier post. That is removing SW code from the picture while not changing any of the Opus code involved. Thus is seems likely that the SW code is involved in the problem.
Neither of us can know for sure when we know so little at this stage, and it doesn't matter who is to blame; it only matters that there is an incompatibility and then comes down to who is physically able to investigate and fix it.
We cannot investigate or fix this as we do not have access to Solidworks or its source code. You need to report it to them if you want to see it fixed. If they diagnose it and think there is something wrong on the Opus side, then we can address it, but even if that is the case they are the only ones who can do the initial investigation.
Have you reported the problem to them as well? What did they say?
I appreciate the reply and will ask Solidworks support to look at the issue, although not holding my breath. It would be great to be able to get back to using Opus with my Solidworks files.
I have a fix for this problem which a past colleague came up with.
I'll be keeping a look out for when you get the preview working for Solidworks and shout myself and upgrade of Opus.
Open up Registry Editor:
Find your extension (for this example I am using .SLDPRT)
Go to
HKEY_CLASSES_ROOT
SldPart.Document
Shellex
IconHandler
Rename the icon handler to anything you wish. (I used what they recommended, so in the future can see why it was renamed ) the above word IconHandler now becomes
IconHandler-renamedtodisableaddinthathangsopus
This must be done for all extensions that Solidworks uses
.SLDPRT, .SLDASM & .SLDDRW
Do the same for
HKEY_CLASSES_ROOT\SldAssem.Document
Shellex
IconHandler
&
HKEY_CLASSES_ROOT\SldDraw.Document
Shellex
IconHandler
The registry will create a new Icon Handler when you do this to these 3 entries and close Registry Editor.
Restart Windows
Then open Opus and it should read directory fast again.
@Mechman... just an FYI, that what you did there manually is not much different than the guidance Leo gave the original poster:
...so for anyone looking for the same "workaround" (i.e. this isn't a "fix" as you're disabling the shell extensions that are triggering the problem - and I think most people would want it to just ~work without hanging instead of disabling the extensions), you might be better off using the ShellExView utility Leo mentioned - particularly if you're not comfortable editing the registry manually.
From the comment:
...does that mean you've reported the compatibility issue to SolidWorks and are hopeful a real fix is in fact on the way?
Steje.. I had tried that before and actually downloaded the utility that did disable it. It worked once, then the problem came back. Could have just been me, I don't know, but this workaround is still working.
Hello All, just a quick reminder... for any of the fixes (ShellEx or regedit) to work you have to fully exit Opus. I fixed this on two PCs correctly a year ago but today I was fussing with a 3rd PC and forgot to FULLY exit Opus and was frustrated that the "fix" did not work. Once I fully exited and re-initialized Opus it worked correctly. I blame it on brain rot (beer?) Love Opus!
