Errors resolving assembly references 1

[rocheey]

Ive got a strange problem that started appearing when the speed of my connection to a remote site slowed down.

Ive got a macro/application that opens up assemblies, recurses out the part references, counts the parts, etc, and if the child part is a new part, opens the part file and exports the part configuration(s).

In the remote site, the users there made several assemblies, each in its own directory, each with the same file name as each other, and each using the same internal config name. Each assembly has child parts, and each child part has the same file name as each other, and each child part uses config names that are the same as each other.

In addition, all these parts were made on another drive/path that I have no access to, and were dragged over using windows explorer, so naturally, the internal references are not exact.

Suprisingly, I have (or Solidworks has) no problem resolving the references to the correct part files, UNTIL I have to open a model to export it. After export, I ensure the model is closed, the model is set to NOTHING, the assembly is closed, and the assembly is set to NOTHING.

But when I then open up the next assembly with the same name/config name/child part names, etc, the assembly opens up with the wrong parts in it. I do nothing to the assembly; it is opened read-only, and the code is passive; there is no code to modify any parts/assemblies.

This morning, I also added code to set the SW working directory to the assembly directory, as well as setting the windows currentDirectory to this same directory. Both calls worked successfully, but the problem persists...

WTF? Is the lock file not completely closing on the part file? Anyone?

 

[RawheadRex]

Do any of the components of the assembly have "in-context" relations to the parent assembly? If so, that might be part of the problem. I have dealt with something similar (but NOT identical) before.

I wrote an application about 6 months ago that takes a generic set of files (with parts containing "in-context" features) and copies them to a new location. The problem that I ran inot was when my utility opened the new SolidWorks file copies made updates to some basic physical dimensions (provided by the user) the "in-context" references didn't update because they still referenced the original generic assembly file. I dealt directly with SW API support and this problem ended up having an SPR issued.

Intuitively speaking, I get the sense that perhaps the same root cause is responsible for the problem that you're encountering. Definitely sounds like something you want to beat on your VAR or SW about.

Another thought that may or may not be relevant is in the distant past (98Plus, 99) when I was working on assemblies that were named identically but substantively different I clearly recall having a difficult time when having to switch between them. I would close out all of my files in my SW session and attempt to open the similar assembly only to have it pick up the wrong references (like you're talking about). The only way that found around this was to close out the SW session altogether and start it up again. This kind of rings familiar to me when I read what you're up against.

Maybe you could try having placing a line of code that kills the SW session at the end of your routine and putting the whole thing inside of a Loop or For...Next construct something like this:

For i = 1 to 6
<your code>
Set SWApp=Nothing
Next i

Just a thought. It might be worth a try just to see what happens when you kill the SW session and reopen it.

Good Luck,
Chris Gervais
Sr. Mechanical Designer
Lytron Corp.

 

[rocheey]

>>Do any of the components of the assembly have
>>&quot;in-context&quot; relations to the parent assembly?

Nope, this particular one is pretty straightforward:
3 parts, 6 mates, no incontext. FWIW, all 3 parts are
different configurations in the same part file.

And while I suppose I wasnt really expecting a 'magic button' answer for this one, I had hoped nonetheless. :/

What I will probably do as a workaround, since I am opening multiple assemblies, is just to open all the assemblies FIRST, without grabbing a ModelDoc at all, and just making a list of the referenced docs/configs. Once all the assemblies have been parsed, I will then go back thru and export any/all modeldocs.

 

[CSolids]

It is a good idea to explicitly re-reference the assembly to each of its child documents using
retval = SldWorks.ReplaceReferencedDocument ( referencingDocument, referencedDocument, newReference)

Granted, this is tedious business, but it often seems to be necessary when copying files through the API. The UI seems to do more than just changing the current working directory in figuring out the new file paths (anyone else here have some insights on this?). Without the UI, you get to do it all yourself!

 

[rocheey]

Well, Ive been poking around in the structured storage a lot lately, and Ive seen what I can only surmise is the last few *paths* the file was stored to. Perhaps this is part of the problem; but I doubt it's the entire problem; one assembly with 4 different parts came back thru as having 4 instances of the same part!